Підводні камені віртуалізації / вивчені уроки

Які підводні камені чи уроки ви засвоїли після перетворення наявного обладнання у віртуалізоване середовище? Чи є щось, що ви намагалися віртуалізувати, але ніколи більше не зробите?

ЗАВЖДИ виймайте будь-який віртуальний носій (CD / DVD / Floppy), коли ви закінчите, як цього не зробите, часто зупиняє vMotion у своїх треках.

Правильно налаштуйте NTP та DNS, це позбавить вас від роздумів про самогубство :)

Ніколи не може бути достатньо пам’яті чи пам’яті.

Переконайтеся, що у вас є віддалений доступ, без ОС, до ваших машин, таких як система iLO HP.

Зберігайте сховище файлів OS / App .ISO.

Це не пряма відповідь на ваше запитання, але в надії, що хтось вбереже себе від виривання волосся в майбутньому, знайшовши цю відповідь - клинкові сервери HP не постачаються за допомогою типового біта "VT" за замовчуванням, ви повинні ввімкнути це в BIOS (F9). Без цього ESX 3.5U4 не видає корисної помилки, ні він просто зависає перед встановленням коду :(

Для відповіді на запитання - підводні камені, пов'язані з міграцією P2V.

По-перше - міграції P2V працюють дуже добре здебільшого. Чим чистіші і новіші системи, тим краще, але навіть із міграцією старих (NT4 систем) рівень моєї успішності після більш ніж сотні міграцій у різних середовищах становив близько 90%. Це системи, які мігрували та передавались у виробництво в запланований день (ну переважно в нічний час). У мене коли-небудь була одна система, яку нам довелося вимкнути після очевидно успішної міграції - SQL-коробка, яка потребувала більше кінських сил CPU, ніж платформа могла коли-небудь доставити. VMware Converter хороший і безкоштовний (для непідприємницької версії), Platespin дуже хороший (але дорогий).

Це сказало - є чого уникати.

Кластери MSCS Ви можете змусити їх працювати, але це ніколи не чудова ідея, і Microsoft майже точно не допоможе вам жодним чином, якщо у вас виникнуть проблеми пізніше. Натомість будуйте нові автономні системи.

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

Якщо ви плануєте змінити імена системи або ip-адреси (або обидва) під час міграції, спочатку подумайте, чи не робити цього, і якщо у вас абсолютно немає вибору, то переконайтеся, що у вас є люди, які розуміють, як ці зміни можуть вплинути на систем, про які йдеться. Моєю найгіршою міграцією коли-небудь був сервер RSE ACE, який використовується для автентифікації DMZ, розташованого VPN, де клієнт відмовився слухати мої заперечення і наполягав на зміні імені, і ip-адреси під час міграції.

Пов’язане з вищесказаним - якщо у вас є що-небудь інше, ніж повністю плоска мережа, тоді створіть кілька тестових віртуальних машин і переконайтесь на 100% впевненості, що ваші VM-мережі ідеально копіюють фізичні, з яких ви мігруєте.

У середовищах Windows AD завжди переконайтеся, що у вас є локальний обліковий запис адміністратора, який буде переміщено. І протестуйте його, перш ніж мігрувати.

Переконайтесь, що у вас є гарне уявлення про те, як триватимуть багато часу. Час копіювання P2V буде змінюватися залежно від доступної пропускної здатності мережі (очевидно), але також може суттєво вплинути на кількість файлів у кожному томі, що переміщується. Це особливо проблема з міграцією Platespin NT4 * систем, але вплине на будь-яке копіювання програмного забезпечення P2V на рівні файлу (що зазвичай застосовується, якщо ви вирішите змінити розмір томів). Швидкість копіювання 70-80Мегабайт в секунду можлива за допомогою мереж GigE, відносно швидкого джерела та хорошого налаштування цілі, але 20-30Мегабайт / сек є більш типовим і для вищезгаданих NT-систем із 100Meg мережами та великою кількістю файлів, які я бачив. спад в діапазон 50кілобайт / сек.

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

• Заздалегідь створіть надійну стратегію резервного копіювання. Вирішіть, чи збираєтесь ви створювати резервну копію VM так, ніби він був на голому металі, чи збираєтесь робити резервну копію віртуальних жорстких дисків у сховищах даних (або обох). Взагалі кажучи, я виявив, що мій необхідний слід резервного копіювання спочатку значно збільшився, тому будьте готові до початкового спайка, де ви могли б створити резервну копію як старої фізичної машини, так і нового VM, перш ніж ви отримаєте всі перегини.
• Поширення VM також є на що слідкувати. Після того, як віртуалізація починає зніматися, прагнення перенести все в VM стає великим. Хоча це може спрацювати, ви, ймовірно, не замовляли достатньо апаратного забезпечення безпосередньо з батареї.
• Я думаю, що є машини, які неможливо перетворити, та інші машини, які, ймовірно, не повинні бути перетворені. Хоча приємно мати можливість взяти 10-річну фізичну машину і клонувати її до ВМ, з бородавками та ін., Безумовно, є сценарії, де вам краще буде створити
  чисту ОС та перемістити предмети з фізичної машини. Іноді вам краще не конвертувати через павутиння.
• Будьте готові використовувати багато мережевих портів. Якщо у вас є системи, які працюють на різних VLANS, і в той час, коли окремі порти можуть бути виконані, слід, мабуть, мати окремі порти для своїх VLAN, що подаються у ваш vSwitch. Якщо ви хочете надмірності, і ви використовуєте iSCSI, ви можете переглядати безліч операційних мереж.

З мого досвіду, будьте ДУЖЕ уважні до свого носія інформації. Ми поїхали з iSCSI SAN, який виявився, що підтримує лише 100Mbit з'єднання. Запуск одного VM в системі був не поганий, два були менш адекватними ... і до того моменту, як ми досягли нашої цілі 8 ВМ, вони були жахливими.

Мій особистий урок засвоєний: Перевірте рейтинг IOPS та прочитайте більше відгуків про продукт, який стосується способу використання пристрою зберігання даних

Ще одна зручна річ, яку я навчився ... Створення «резервного» зображення диска після встановлення бази та загартування пришвидшить збірку будь-якої іншої системи, і це дуже зручна річ, яку потрібно тримати навколо.

Намагайтеся не запускати сервери виробничих баз даних у віртуальному середовищі. Накладні витрати на введення / виведення неприпустимі. У нас виникли великі проблеми, коли наша DBA дозволила віртуалізувати наш основний сервер MSSQL. Запитання запускали тисячі мілісекунд. Коли ми переконали їх перенести його у спеціальний ящик, відбулося збільшення на 10000% пропускної здатності та швидкості.

Використовуйте відновлювальну мережу для руху vmotion / vmkernel. Ви не хочете, щоб відключення віртуальних машин було лише тому, що перезавантажений перемикач.

Ох, і залиште один сервер DC / DNS / DHCP поза віртуалізацією. Ваші користувачі будуть ненавидіти вас менше, якщо ви отримаєте серйозну аварію SAN.

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

Інструменти P2V можуть несподівано відбитися від вас, зруйнувавши фізичну машину (у мене конвертер VMWare вбив машину, я намагався один раз P2V, на щастя це була лише тестова міграція). Будьте готові до відновлення системи з нуля. Так, це може бути шанс від 1000 до одного, але ви хочете бути таким?

VMWare Converter створює віртуальні машини, які завантажуються з scsi. Віртуальні машини MS не можуть завантажуватися з scsi. [редагувати - мабуть, версія 4 перетворювача тепер дозволяє вам вказати SCSI або IDE, я люблю цих хлопців]

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

Крім того, VMWare Converter вирішить завдання, при яких MS SCVMM зіб'є з ладу руки.

Принесіть багато оперативної пам’яті.

Не робіть нічого, доки не встановлені інструменти віртуалізації (чи то VMWare чи MS).

Якщо ви збираєтеся перенести його на іншу платформу / версію, видаліть вищезгадані інструменти.

Зверніть увагу на обмеження процесора. P2V 2-х процесорних Windows 2000 навчив мене, що підтримується лише 1.

• 2000 р. - 1 ядро
• 2003 р. - 2 ядра
• 2008 р. - 4 ядра

Якщо ви збираєтесь використовувати SAN для зберігання зображень VM, переконайтесь, що ви маркуєте свої пристрої та хости ДУЖЕ ЧИСТО. Видалення відображень хост-диска на SAN робить жахливі речі, якщо вони все ще використовуються віртуальними машинами.

Microsoft не підтримає Exchange 2003, що працює в VMware (принаймні, це було офіційною відповіддю). З великим скручуванням рук нам вдалося отримати від них неофіційну підтримку, але це викликало додаткові головні болі в умовах уже напруженої кризи.

Багато з них специфічні для VMware:

• Якщо вона погано працює як фізична машина, вона буде погано працювати як віртуальна машина.
• ISO Cold Clone - ваш друг
• Сміття в, ​​сміття поза. Якщо ви P2Ving старіших систем, вони можуть залишити зайвий слід. Див. Розділ Перегляд обладнання Ghost після P2V , необхідні кроки після P2V та p2v-script.pdf
• Переконайтесь, що ваші гостьові операційні системи підтримуються вашим програмним забезпеченням P2V.
• Windows 2000 може зашкодити драйверам SCSI

Дурний роздратування щодо VMware: різні версії VMware використовують різні драйвери SCSI для своїх віртуальних дискових пристроїв. Витратити цілком можливо за 2 години до розгляду цього варіанту.

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

1. Ретельно плануючи деталі вперед. Особливо виконайте домашнє завдання, яке не можна віртуалізувати.

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

3. Реалізуйте w / SAN як накопичувач, що зберігає всі зображення VM.

4. Запустіть ESX або ESX (i) або Hyper-V, щоб отримати найбільшу продуктивність.

Можливо, більше, але це все зараз. :)

[оновлення] ось ще одна. Застосуйте останню прошивку до хост-сервера. У мене був такий, який я не робив, який давав мені фіолетовий екран раз на кілька днів і повністю розбив сервер.

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

Перш ніж перейти до роботи зі своїм рішенням щодо віртуалізації:

• Переконайтеся, що ви знаєте, як створити резервну копію та відновити VM. Використання знімка може не підтримуватися, як у Windows DC
• Запитайте свого редактора, чи підтримується його рішення всередині VM. Microsoft підтримує список підтримуваного програмного забезпечення всередині VM: KB 897613
• Оскільки створити VM дуже просто, люди прагнуть генерувати новий VM для кожного запиту. Тоді у вас більше VM, ніж планується підтримувати ваше рішення.

Чи є щось, що ви намагалися віртуалізувати, але ніколи більше не зробите?

Я б не сказав, що я б не спробував це ще раз, але багатошарова віртуалізація не приємно мати справу.

Під шаром я маю на увазі запуск xen або esx на віртуалізованому обладнанні, такому як Egenera, HP Virtual Connect або Cisco UCS. Це звучить як гарна ідея, але для відладки може бути багато часу.

У VMWare знайте, де закінчуються знімки. У нас було налаштовано закінчитись в LUN на SAN із самими файлами VM. Технолог практикував процес зйомки на LUN, який був майже повним. Пізніше він чомусь перезавантажив VM, і файли журналів змусили VM не запускатися. Це було трохи удачі, яка приводить нас до того, що LUN є повним як причина.

Якщо ви їдете з динамічно розширюється VHD, то переконайтеся, що ви йдете досить великі. Якщо ви їдете зі 100 Гб, а в кінцевому підсумку ви використовуєте лише 20 ... немає великого. Однак якщо ви поїхали з 25, то перед вами ще робота.