Розгортаючи єдиний сервер на новому обладнанні, ви віртуалізуєте його чи ні?

Є кілька питань, які я знайшов на ServerFault, що натякають на цю тему, і, хоча це може бути дещо засноване на думці, я думаю, що він може потрапити в категорію "хороший суб'єктивний", виходячи з наведеного нижче:

Конструктивні суб'єктивні питання:

* tend to have long, not short, answers
* have a constructive, fair, and impartial tone
* invite sharing experiences over opinions
* insist that opinion be backed up with facts and references
* are more than just mindless social fun

Так що з шляху.

Я допомагаю іншому sysadmin, який замінює старіший фізичний сервер під управлінням Windows 2003, і ​​він прагне не лише замінити апаратне забезпечення, але і "оновити" до 2012 R2 в процесі.

У нашій дискусії про його апаратне забезпечення заміни ми обговорили можливість встановлення ESXi, а потім зробити "сервер" 2012 року VM та перемістити старі програми / файли / ролі з сервера 2003 року на VM замість установки, що не використовується VM на нове обладнання.

Він не сприймає жодного разу протягом наступних кількох років необхідність переміщати що-небудь інше в VM або створювати додаткові VM, тож врешті-решт це буде або нове обладнання, що працює у звичайній інсталяції, або нове обладнання, що працює на одній машині VM на ESXi.

Мій власний досвід все ще схиляється до віртуального комп'ютера, для цього немає справді переконливої ​​причини, крім можливостей, які можуть виникнути для створення додаткових віртуальних машин. Але зараз є додатковий накладний та керуючий аспект гіпервізора, хоча я відчув кращі можливості управління та можливості звітування за допомогою VM.

Тож, маючи надію сподіватися, що це може залишитися у категорії «хороший суб’єктивний», щоб допомогти іншим у майбутньому, який досвід / факти / посилання / конструктивні відповіді ви повинні допомогти підтримати будь-який результат (віртуалізація чи не єдиний «сервер») ?

У загальному випадку перевагою розміщення автономного сервера на гіпервізорі є захист у майбутньому. Це робить майбутнє розширення або оновлення набагато простішим, набагато швидшим і, як результат, дешевшим. Основний недолік - додаткова складність та вартість (не обов'язково фінансово, але з точки зору людини-години та часу).

Отже, щоб приймати рішення, я задаю собі три питання (і зазвичай вважаю за краще поставити сервер на гіпервізор, для чого це варто).

1. Наскільки велика додаткова вартість гіпервізора?
   • Фінансово це, як правило, мінімально або не існує.
     • І VMware, і Microsoft мають ліцензійні варіанти, що дозволяють безкоштовно запускати хост і одного гостя, і цього достатньо для більшості автономних серверів, виняток становлять сервери, які особливо потребують ресурсів.
   • З точки зору управління та ресурсів, визначення вартості може бути дещо складніше.
     • Ви, в основному, подвоюєте витрати на підтримку системи, тому що тепер у вас є дві системи для контролю, управління та постійного оновлення з патчами та оновленнями (гостьова ОС та хост-ОС).
       • Для більшості застосувань це не велика справа, оскільки підтримувати один сервер не так страшно, але для деяких особливо малих або особливо технічно складних організацій це може викликати серйозне занепокоєння.
     • Ви також додаєте необхідні технічні навички. Тепер замість того, щоб просто потребувати того, хто може завантажувати оновлення з Windows Update, вам потрібен хтось, хто знає достатньо, щоб керувати та підтримувати середовище віртуалізації.
       • Знову ж таки, це не проблема, але іноді це більше, ніж організація може впоратися.
         
         
2. Наскільки велика вигода від простоти оновлення чи розширення?
   • Це зводиться до того, наскільки ймовірним є майбутнє розширення, оскільки, очевидно, якщо вони не розширять або модернізують свої серверні активи, ця вигода дорівнює нулю.
     • Якщо це тип організації, який просто збирається забити сервер у кут і забути про нього протягом 10 років, поки його все одно не потрібно замінити, немає сенсу.
     • Якщо вони, ймовірно, зростуть організаційно або навіть просто технічно (скажімо, додаючи нові сервери з різними ролями, а не просто мати універсальний сервер), то це дає досить значну користь.
       
       
3. Які переваги в даний час ?
   • Віртуалізація приносить користь поза межами майбутнього, а в деяких випадках використання вони можуть бути істотними.
     • Найбільш очевидний - це можливість створювати знімки та тривіально відновлювати резервні копії, перш ніж робити щось у системі, тому, якщо це піде погано, ви можете повернутися в один клік.
     • Можливість експериментувати з іншими віртуальними машинами (і грати в гру «що якщо») - це ще одна, про яку я бачив, як менеджмент схвилював. На мої гроші найбільша перевага - це додаткова портативність, яку ви отримуєте від запуску виробничого сервера на гіпервізорі. Якщо щось піде не так, і ви потрапите в ситуацію відновлення після аварій або відновлення з резервного копіювання, відновити диск диска на машині, що працює на тому ж гіпервізорі, майже нескінченно легше, ніж намагатися відновити голий метал.

Я думаю, що віртуалізована операційна система є важливим фактором, поряд із вимогами до продуктивності та потенціалом для розширення / зростання. Сьогоднішні сервери часто надмірно потужні для застосувань та операційних систем, які ми використовуємо. На мій досвід, більшість стандартних систем Windows не можуть ефективно використовувати ресурси, доступні на сучасному сервері з двома сокетами . За допомогою Linux я використав деякі інструменти управління детальними ресурсами ( cgroups ) та контейнери ( LXC ) для кращого використання фізичних систем. Але ринок, безумовно, орієнтований на обладнання, оптимізоване для віртуалізації.

Це означає, що я віртуолізував односистемні системи, а не голий метал, встановлений у кількох ситуаціях. Загальні причини:

• Ліцензування - зменшення кількості програм, які ліцензують, грунтуючись на жорстких ядрах, сокетах або обмеженнях пам'яті ( без урахування тенденцій сучасних обчислень ). Див.: Вимкнути серцевини процесора у біосах?

• Переносність - віртуалізація сервера витягує VM з обладнання. Це робить зміни платформи менш руйнівними і дозволяє ВМ посилатися на стандартні віртуалізовані пристрої / компоненти. Мені вдалося зберегти старі ( але критичні ) системи Windows 2000 на життєзабезпеченні за допомогою цього підходу.

• Майбутнє розширення - зараз у мене є клієнт, у якого контролер домену Windows 2003 працює на апаратному забезпеченні 2001 року. Я будую для них нову єдину хост-систему ESXi, в якій буде розміщений новий тимчасовий контролер R2 2012 R2. Але більше VM будуть слідувати. У цій конфігурації я можу запропонувати надійне розширення ресурсів без додаткових витрат на обладнання.

Мінуси, які роблять це з одним хостом / єдиним VM, - це управління. Я підходжу з точки зору VMware, але в минулому ESXi був трохи привітнішим до цієї домовленості. Сьогодні вимога веб-клієнта vSphere та обмежений доступ до основних функцій роблять запуск рішення з одним хостом ( і єдиним VM ) менш привабливим.

Інші міркування - скалічений апаратний моніторинг та більша складність, пов'язана із загальними зовнішніми периферійними пристроями (USB-пристрої / стрічковий накопичувач / резервні копії / UPS-рішення ). Сьогоднішні гіпервізори дійсно хочуть стати частиною більшого набору управління.

Є кілька переваг для віртуалізації одного сервера. Перше, що спадає на думку, - це

• Створення знімків
• Імпорт / експорт віртуальних машин (наприклад, експортуйте VM як .OVF, щоб розробники могли завантажити його в Workstation або Player, щоб мати точну копію сервера)
• Легко клонуйте або перетворіть у шаблон (бо коли ви вирішите, що відеомашини начебто приємні)
• Легко доступні для додавання додаткових віртуальних машин у майбутньому

Я думаю, що найважливішим із них були б можливості знімків. У нашій компанії ми використовуємо VMWare всюди, тому для нас було б доцільно мати сервер "готовим" до того, коли є потреба в більшій кількості віртуальних машин.

Це не довга відповідь, але все одно:

Найбільш переконливою причиною використання гіпервізора для одного сервера, особливо для чогось на зразок Windows Server, є те, що ви маєте повну технічну абстракцію для виробничої ОС і можете просто перенести її на абсолютно нове серверне обладнання без проблем, якщо виникне потреба. Я вважаю це справжньою цінністю, що значно переважає недоліки того, що практичний непотрібний гіпервізор працює на задньому плані.

Я не збираюся надавати тут детальну відповідь, як інші, тому я просто скажу, що мені важче і важче в ці дні виправдати встановлення ОС сервера на голий метал на відміну від встановлення гіпервізора (з вашого вибір) та віртуалізація навантажень. Переваги цього, на мій погляд,:

1. Вигідна вартість. Зрештою, якщо мені потрібно розгорнути додаткові навантаження, мені не доведеться виділяти більше обладнання для цих додаткових навантажень. У деяких випадках, використовуючи Hyper-V, я навіть можу заощадити на своїх ліцензійних витратах.

2. Простота розгортання та перерозподілу.

3. Простота впровадження високої доступності та відмови.

4. Переносність. Я, швидше за все, можу переміщувати VM майже де завгодно, якщо мені потрібно зняти з експлуатації або передавати аутсорсинг поточному хосту.

5. Майбутня перевірка. Ваш колег sysadmin, можливо, не бачить майбутньої потреби в інфраструктурі на основі гіпервізора, але я гадаю, що протягом 12 - 24 місяців він захоче, і він буде радий, що вирішив піти по маршруту віртуалізації, якщо він насправді вибере цей маршрут .

6. Аварійного відновлення. Я можу створити резервну копію цілого VM та відновити його або копіювати на інший хост за лічені хвилини.

І так далі, і так далі ...

Ось кілька причин, чому я б сказав, що VM краще:

• Вбудований "KVM over IP" (свого роду) - ви можете віддалено отримувати доступ до свого сервера на консолі, не потребуючи KVM через IP. Іноді ви просто не хочете щось робити над RDP і вам потрібен консольний доступ. За допомогою VM ви запускаєте інструмент управління, який вибираєте (XenCenter, vSphere Client тощо), і ви знаходитесь на консолі вашої віртуальної машини.

• З віртуальними машинами (і для серверів, що не належать до VM, з моїм KVM через IP) мені більше не доводиться годинами перебувати в холодному серверному залі.

• Перехід на нове обладнання - оновлення ОС убік, щоб укласти нове обладнання потрібно перенести систему, переміщати речі тощо. З VM вам (зазвичай) нічого не потрібно робити. Ви модернізуєте обладнання, поставите файли VM на нове обладнання та запустіть.

• Поки ніхто не передбачає майбутнього VM, " якщо ти його побудуєш, вони прийдуть ". Вам захочеться закрутити новий VM, щоб тестувати щось та спробувати нові речі тощо. Можливо, є набагато більше можливостей.

• Відеомагнітофони дають вам змогу повернутись за допомогою знімка, скопіювати його, зробити клон VM (під час виконання) та потім розкрутити його - чи тестувати щось перед тим, як викласти його, чи просто мати секунду спочатку. Є багато речей, які можна зробити зі знімками VM та подібними зображеннями.

• Надмірність - якщо ви запустили другий сервер VM, у вас може бути надлишкове обладнання, і поки я не знаю про поточні схеми ліцензування VMWare, XenServer тепер XenMotion, мабуть, є частиною безкоштовного пакету, так що накладні витрати можуть не застосовуватися.

Причини, по яких я б не використовував VM:

• Накладні - навряд чи, але, очевидно, є якісь накладні витрати.

• Більш складний в управлінні - трохи складніший, але його легко вивчити. Якщо ви не збираєтеся в масово великій віртуалізованій обстановці, тренування є дрібницею.

Я заходжу пізно і відчуваю, що люди вже зробили деякі моменти, які я хотів би зробити, але коротко резюмую:

• Захист у майбутньому: простіше додати більше оперативної пам’яті / процесора / диска / тощо. як виникає потреба.
• Переносність: простіше перейти до нового обладнання, особливо у випадку катастрофи.
• Віртуалізація краще, ніж зберігати жахливе старе обладнання, щоб запустити те, чого ви не можете позбутися.
• Програмне забезпечення для управління часто таке ж приємне, як KVM або DRAC. (Крім того, якщо вам трапиться успадкувати щось, куди відійшов попередній адміністратор, не залишаючи свого пароля, ви можете використовувати їх як "фізичний доступ", щоб прорватися. Так само зручно, як і різаки болтів у мене в машині з тієї ж причини - попередня Адміністратор на одному завданні використовував замок на апаратному забезпеченні. Я успадкував сервери, але не ключ.)
• Зйомка та створення копій, щоб я міг перевірити ризикові процедури перед їх розгортанням.

Однак те, про що ще ніхто не згадував, і, мабуть, слід згадати: Якщо ви знаходитесь у магазині, де люди можуть потребувати тестового сервера, і, ймовірно, вирішите цю потребу, захопивши запасний робочий стіл і ляпнувши ОС сервера на цьому, можливість запропонувати їм VM, швидше за все, задовольнить ваші та їх потреби. Віртуалізація нового сервера може стати "причиною" дозволити майбутнє віртуальне розширення. (І, чесно кажучи, якщо ви не в такому магазині, ви, мабуть, вже маєте віртуалізацію.)

Звичайно, не все віртуалізується. Я набрав фізичне обладнання для програмного забезпечення для управління, яке включало PXE, описуючи їм, що їм потрібно зробити, щоб вимкнути розвантаження сегмента TCP ( PXE працює як однонога собака з TSO увімкнено , але вони повинні були б вимкнути її для всієї віртуальної VLAN, і вони були відмовлені це робити). Отже, якщо новий сервер є чимось достатньо спеціалізованим, щоб бути непридатним, ну, не майте на увазі.

Але, забороняючи такий тип спеціалізації, мені варто було б позбутися від купу (потенційно некерованих) машин класу ПК, на яких працює операційна система серверів, що лежать зараз, або в майбутньому.

Абсолютно я віртуалізую, коли можу. Це дозволяє мені підготуватися до наступного:

• Повне резервне копіювання системи, яке набагато простіше зробити, а також часто і дешевше.
• Операційна система може бути портативною, я можу перемістити ВМ на інший хост, якщо мені потрібно, з тимчасовим простоєм і без кластеру, це не має значення в цей момент.
• Ліцензування Windows за певних умов може здешевити
• Якщо не вистачає обладнання, я можу використовувати виробничі системи для тестування оновлень (не найкраща практика, але бюджет, бюджет ...), після того, як зробити знімок. Не можна цього робити на звичайному хості, якщо це не завантаження з дорогого SAN
• Отримуючи мінімально можливе кінцеве обладнання сервера, я все одно отримую більше ресурсів, ніж могло знадобитися для певної ролі сервера. Можна також покращити обладнання та використовувати все це з VM.
• Функції віртуалізації часто можуть замінити зайве програмне забезпечення. Наприклад, я часто налаштовував подвійне захоплення і ніколи не відмовлявся, налаштовував DR-репліки серверів Windows. За допомогою віртуалізації я можу це зробити на рівні гіпервізора, використовуючи набагато дешевші технології та використовуючи більш надійні та гнучкі рішення.

Коротше кажучи, якщо на сервері не буде запущено певне програмне забезпечення, яке має обмеження, забороняючи йому віртуалізуватися (суворі запити затримки введення в мережу чи диск зазвичай затримуються, а з правильним обладнанням навіть ті, які досягаються за допомогою віртуалізації), я намагаюся тримати речі максимально віртуальний.

Однією з причин, на яку я можу подумати про віртуалізацію одного сервера у VM на одному хості, є здатність, яку він дає вам потім возитися з тестовим середовищем для цього "сервера".

Якщо апаратне забезпечення більш ніж здатне, ви можете клонувати серверну машину та вилучити її здібності NIC / мережі та ізолювати цей клон як "тестову платформу", щоб зіпсуватись перед тим, як спробувати те ж саме на "виробничому" сервері. Прикладом може бути те, якщо на сервері запущено програмне забезпечення ERP, і ви хочете перевірити, що буде, якщо ви запустили певний скрипт проти програмного забезпечення / бази даних ERP. Ви могли це зробити на клонованому ВМ спочатку як тест. Потім це можна зробити разом із знімком живого VM перед розгортанням на ньому, з додатковою перевагою того, що він знає, що він повинен працювати добре.

Створення того ж клонованого "тестового" середовища можна виконати за допомогою P2V існуючого фізичного сервера, але тоді вам знадобиться додатковий фізичний хост, щоб розмістити новий тестовий VM ... апаратне забезпечення (яке сьогодні майже завжди є надмірним для однієї VM)

Якщо ваш випадок використання не вимагає 100% енергії від виділеного обладнання, то я б щоразу виходив віртуальним. Він забезпечує гнучкість, можливість знімка та вбудований доступ до консолі (навіть якщо ви також повинні використовуватись поза межами управління)

Єдиний момент, який є досить дотичним до головного питання:

Нещодавно у мене був VM, диск якого був недостатньо великим. Він працював над тим, що генерувало велику кількість даних у реляційній базі даних, яка з міркувань продуктивності повинна була знаходитися на одній машині.

Розгорнувши зображення диска вдвічі, я дійшов до того етапу, коли на хості не було достатньо місця для безпечного копіювання та розширення зображення. Я врятував би мені пару днів роботи, щоб це зробити з самого початку на спеціальній машині, навіть якщо це був дешевий ПК, а не високопродуктивний сервер.

Завдяки спеціальній машині ви можете її просто вимкнути та додати більше дисків. Якщо це сервер, на якому працюють інші VM, якщо ви не маєте запасних відсіків гарячої заміни, у вас можуть виникнути проблеми з його вимкненням.