Назад | Перейти на главную страницу

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

Какие подводные камни или уроки, извлеченные после преобразования существующего оборудования в виртуализированную среду? Есть ли что-нибудь, что вы пытались виртуализировать, но больше никогда не сделаете?

ВСЕГДА извлекайте любой виртуальный носитель (CD / DVD / Floppy) после того, как вы закончили, поскольку в противном случае vMotion часто останавливается на его дорожках.

Правильно настройте NTP и DNS, это избавит вас от мыслей о самоубийстве :)

Вам никогда не может хватить памяти или хранилища.

Убедитесь, что у вас есть удаленный доступ без ОС к вашим машинам, таким как система HP iLO.

Храните репозиторий файлов OS / App .ISO.

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

Чтобы ответить на заданный вопрос - подводные камни, связанные с миграцией P2V.

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

Тем не менее - есть вещи, которых следует избегать.

Кластеры MSCS. Вы можете заставить их работать, но это никогда не бывает хорошей идеей, и Microsoft почти наверняка никоим образом не поможет вам, если у вас возникнут проблемы позже. Вместо этого создавайте новые автономные системы.

Большие SQL-серверы - упор на большие. Они должны были быть заранее отмечены красным флажком из POV требований к процессору, но не поддавайтесь искушению переместить его, если вы не уверены, что целевая виртуальная машина будет иметь достаточно места для ЦП.

Если вы планируете изменить имена системы или IP-адреса (или и то, и другое) во время миграции, сначала рассмотрите возможность этого не делать, и если у вас абсолютно нет выбора, убедитесь, что у вас есть люди, которые понимают, как эти изменения могут повлиять на рассматриваемые системы. Моей худшей миграцией в истории был сервер RSA ACE, используемый для аутентификации VPN, расположенной в DMZ, где клиент отказывался прислушиваться к моим возражениям и настаивал на изменении как имени, так и IP-адреса во время миграции.

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

В средах Windows AD всегда убедитесь, что у вас есть локальная учетная запись администратора на переносимом сервере. И протестируйте его перед переносом.

Убедитесь, что вы хорошо представляете, сколько времени займет работа. Время копирования P2V будет варьироваться в зависимости от доступной пропускной способности сети (очевидно), но также может сильно зависеть от количества файлов в каждом переносимом томе. Это особенно проблема с Platespin, переносящая системы NT4 *, но повлияет на любое копирование программного обеспечения P2V на уровне файлов (что обычно применяется, если вы решите изменить размер томов). Скорость копирования 70-80 мегабайт в секунду возможна с сетями GigE, относительно быстрым источником и хорошей целевой настройкой, но 20-30 мегабайт / с более типичны и для вышеупомянутых систем NT с сетями 100 мегабайт и большим количеством файлов я видел скорости копирования. упадет до диапазона 50 килобайт / сек.

  • В идеале вы бы избавились от них, но у некоторых людей нет такой роскоши, и получить такую ​​ОС с совершенно неисправимым оборудованием, на котором она, вероятно, работает, почти всегда хорошая идея.
  • Заранее разработайте надежную стратегию резервного копирования. Решите, собираетесь ли вы создавать резервную копию виртуальной машины, как если бы она была на «голом железе», или вы собираетесь создавать резервные копии виртуальных жестких дисков в хранилищах данных (или в обоих хранилищах). Вообще говоря, я обнаружил, что вначале объем необходимых резервных копий значительно увеличился, поэтому будьте готовы к первоначальному всплеску, когда вы, возможно, будете выполнять резервное копирование как старой физической машины, так и новой виртуальной машины, прежде чем вы устраните все недостатки.
  • Также стоит остерегаться разрастания ВМ. Когда виртуализация начинает набирать обороты, желание перенести все на виртуальную машину становится огромным. Хотя это может сработать, вы, вероятно, сразу заказали недостаточно оборудования.
  • Я думаю, что есть машины, которые нельзя преобразовать, и другие машины, которые, вероятно, не следует преобразовывать. Хотя приятно иметь возможность взять физическую машину 10-летней давности и клонировать ее на виртуальную машину, с проблемами и всем остальным, безусловно, есть сценарии, в которых вам было бы лучше построить
    очистить ОС и перенести объекты с физической машины. Иногда лучше не конвертировать по паутине.
  • Будьте готовы использовать множество сетевых портов. Если у вас есть системы, которые работают на разных VLAN, в то время как отдельные порты могут быть объединены в транкинг, вы, вероятно, захотите, чтобы отдельные порты для ваших VLAN входили в ваш vSwitch. Если вам нужна избыточность и вы используете iSCSI, вам может понадобиться множество сетевых адаптеров.

По моему опыту, будьте ОЧЕНЬ осторожны с носителем информации. Мы выбрали iSCSI SAN, который, как оказалось, поддерживает только 100-мегабитные соединения. Запускать одну виртуальную машину в системе было неплохо, двух было недостаточно ... и к тому времени, когда мы достигли нашей цели в 8 виртуальных машин, они были ужасны.

Мой личный урок: проверьте рейтинг IOPS и прочитайте больше отзывов о продукте которые связаны с тем, как вы собираетесь использовать запоминающее устройство

Еще одна полезная вещь, которую я усвоил ... Создание «резервного» образа диска после базовой установки и усиления защиты ускорит сборку любой другой системы, и это очень удобная вещь, которую нужно держать под рукой.

Используйте избыточную сеть для трафика vmotion / vmkernel. Вы не хотите, чтобы виртуальные машины выключались только из-за перезагрузки коммутатора.

Да, и оставьте один DC / DNS / DHCP-сервер вне виртуализации. Ваши пользователи будут меньше ненавидеть вас, если вы получите серьезный сбой SAN.

Старайтесь не запускать производственные серверы баз данных в виртуальной среде. Накладные расходы на ввод-вывод недопустимы. У нас были огромные проблемы, когда наш администратор баз данных позволил виртуализировать наш основной сервер MSSQL. Запросы выполнялись за тысячи миллисекунд. Когда мы убедили их переместить его обратно в специальный ящик, производительность и скорость увеличились на 10 000%.

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

Инструменты P2V могут неожиданно обернуться против вас, разрушив физическую машину (у меня был конвертер VMWare, который уничтожил машину, которую я однажды пытался выполнить с помощью P2V, к счастью, это была всего лишь тестовая миграция). Будьте готовы восстанавливать систему с нуля. Да, это, возможно, шанс 1000 к одному, но ВЫ хотите им стать?

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

Если вы собираетесь виртуализировать не-ACPI физическая машина, купите программное обеспечение для этой цели. (если у вас нет пары недель на увлекательное путешествие в поисках открытий!)

Кроме того, VMWare Converter возьмется за работу, на которую MS SCVMM будет в отчаянии.

Принесите много оперативной памяти.

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

Если вы собираетесь перенести его на другую платформу / версию, удалите вышеупомянутые инструменты.

Следите за ограничениями вашего процессора. P2V из двух процессоров Windows 2000 научил меня, что поддерживается только один.

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

Если вы собираетесь использовать SAN для хранения образов виртуальных машин, убедитесь, что вы ОЧЕНЬ ЧЕТКО маркируете свои устройства и хосты. Удаление сопоставлений хост-диск в SAN приводит к ужасным последствиям, если они все еще используются виртуальными машинами.

Многие из них относятся к VMware:

  • Если он плохо работает как физическая машина, он будет плохо работать как виртуальная машина.
  • Холодный клон ISO - ваш друг
  • Мусор на входе, мусор на выходе. Если вы используете старые системы P2V, они могут оставить ненужный след. Видеть Просмотр призрачного оборудования после P2V, Шаги, необходимые после P2V, и p2v-scripts.pdf
  • Убедитесь, что ваши гостевые операционные системы поддерживаются вашим программным обеспечением P2V.
  • Windows 2000 может быть проблемой в отношении драйверов SCSI

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

Глупое раздражение по поводу VMware: разные версии VMware используют разные драйверы SCSI для своих виртуальных дисковых устройств. Вполне возможно потратить 2 часа, прежде чем рассматривать этот вариант.

Есть ли что-нибудь, что вы пытались виртуализировать, но больше никогда не сделаете?

Я бы не сказал, что не буду пробовать снова, но многоуровневая виртуализация неприятна.

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

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

Прежде чем приступить к работе с вашим решением виртуализации:

  • Убедитесь, что вы умеете делать резервную копию И восстанавливать виртуальную машину. Использование снимка может не поддерживаться, как в Windows DC.
  • Спросите своего редактора, поддерживается ли его решение внутри виртуальной машины. Microsoft поддерживает список поддерживаемого программного обеспечения внутри виртуальной машины: KB 897613
  • Поскольку создать виртуальную машину очень просто, люди склонны создавать новую виртуальную машину для каждого запроса. Тогда у вас будет больше виртуальных машин, чем планируется для поддержки вашего решения.

Что ж, у меня пока нет ужасных историй о том, как я занимаюсь виртуализацией. Тем не менее, несколько замечаний.

  1. Тщательное планирование в деталях вперед. Особенно поработайте над тем, что нельзя виртуализировать.

  2. Если поставщик приложения, работающего на вашем сервере, не поддерживает виртуальную среду, подождите, пока он не поддержит.

  3. Внедрить с SAN в качестве хранилища для всех образов виртуальных машин.

  4. Запустите ESX, ESX (i) или Hyper-V, чтобы добиться максимальной производительности.

Может и больше, но пока это все. :)

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

В VMWare знайте, куда попадают снимки. Мы настроили наш так, чтобы он попадал в LUN в SAN с самими файлами виртуальной машины. Техник практиковал процесс создания снимков на LUN, который был почти заполнен. Позже он по какой-то причине перезагрузил виртуальную машину, и из-за файлов журнала виртуальная машина не запускалась. Это была небольшая удача, которая привела нас к тому, что LUN был заполнен как причина.

Если вы выберете динамически расширяемый VHD, убедитесь, что он достаточно большой. Если вы выберете 100 ГБ и в конечном итоге используете только 20 ... не беда. Однако, если вы выбрали 25, у вас впереди есть работа.