| Тип виртуальной машины (рабочей нагрузки)
| Рекомендации по планированию, настройке и развертыванию
|
Microsoft NLB (network load balancer)
Типы приложений: Microsoft IIS, VPN, ISA |
VMware рекомендует использовать режим Multicast. Виртуальная машина должна быть подключена к отдельной группе портов (Port Group), где установлен параметр Forged Transmits, так как эффективный MAC-адрес ВМ может отличаться от MAC-адреса источника, указанного в заголовке пакета. |
Кластеры Microsoft Clustering Services (MSCS - гайд)
(Кластеры Veritas не поддерживаются со стороны VMware, но поддерживаются со стороны Symantec).
Типичные приложения: Microsoft Exchange, DHCP, SQL |
Требует использования протокола Fibre Channel. Протоколы iSCSI (внешний с хоста ESXi), NFS, FCoE - не поддерживаются для кластеров MSCS на базе общего диска в виртуальных средах. Возможные варианты кластеров: Cluster in a Box, Cluster Across Boxes, Standby Host. Также возможно использование кластера с общим диском (Exchange, SQL) или без общего диска (NLB, Exchange CCR)
Для кластеров из ВМ на разных хостах ESXi (Cluster Across Boxes) поддерживаются только RDM-диски в режиме физической или виртуальной совместимости.
Рекомендации:
- использовать Anti-affinity rules (причем правила ВМ-ВМ использовать не рекомендуется, так как VMware HA не соблюдает это правило при восстановлении машин, необходимо использовать правила ВМ-хост)
- использовать reservation 100% для RAM. Нужно обратить внимание, что это приведет к изменению размера слота HA с дефолтными настройками.
- тип диска должен быть eagerzerothick
- для хартбитов потребуется 2 порта физического адаптера на хосте ESXi
- для Cluster Across Boxes нужно использовать Physical RDM (рекомендация VMware)
- нужно поддерживать одинаковую версию ESXi на обоих хостах для ВМ кластера
- нельзя ставить политику путей Round Robin
- для использования MSCS в ВМ совместно с VMware SRM потребует "растяжения" VLAN'ов между датацентрами (часто этого много чего еще требует)
Для защиты на уровне компонентов приложений можно использовать Symantec Application HA |
| Microsoft Exchange |
Если требуется CCR (clustered continuous replication), то нужно использовать MSCS. |
| ПО Oracle (СУБД) |
Нужно учитывать модель лицензирования Oracle, которая может оказаться дорогой по причине необходимости лицензирования нескольких или всех хостов кластера VMware HA/DRS.
Рекомендации:
- не использовать привязку ВМ к ядрам в целях уменьшения затрат на лицензирование, так как Oracle не признает ее
- учитывать хосты, где может оказаться виртуальная машина с Oracle (опять-таки, задавать правила VM-Host)
Аналогично эти моменты следует учитывать для приложений, для которых нет особенных правил лицензирования под виртуализацию. |
| Приложения, собираемые в пул (например, пул Application-серверов, работающих на уровне разделения соединений к БД) |
Необходимо использовать Affinity Rules на уровне VM-Host, чтобы машины не собирались на одном или паре хостов ESXi. Для пар виртуальных серверов "основной-резервный" также нужно создавать такие правила и документировать их, так как большое количество пар создают большое количество правил, в которых легко запутаться. |
| Виртуальные машины обеспечивающие централизованный мониторинг и безопасность (Security VM) |
ВМ, которые подлежат мониторингу и нет, нужно разделять на уровне групп портов. Также требуется применять Distributed Switch, чтобы использовать port mirroring или netflow. |
| Приложения, лицензируемые с привязкой к MAC-адресу |
При переносе физического сервера в ВМ его MAC меняется. Чтобы разрешить получение пакетов такой виртуальной машиной, нужно выделить ее в отдельную группу портов, задать старый MAC-адрес и установить параметр MAC address changes. |
| Приложения с чувствительными данными (персональные данные, конфиденциальные данные) |
VMware не имеет встроенного шифрования виртуальных дисков vmdk, поэтому любой желающий администратор может просто забрать виртуальную машину и скопировать данные с ее vmdk.
Рекомендации:
В качестве бесплатных средств можно порекомендовать:
|
| Приложения, требующие непрерывной доступности (Fault Tolerance) |
Такие приложения работают в кластере FT, который интегрирован с VMware HA. К сожалению, пока этот кластер может создаваться с 1 vCPU у защищенной машины (а бизнес-критичные приложения требуют, как правило, 2 и более vCPU). Отметим, что релиз технологии FT для нескольких vCPU намечался на vSphere 5.1, но будет выпущен в vSphere 6.0.
Рекомендации:
|
| Контроллеры домена (Domain Controllers) |
Основная статья KB касательно поддержки контроллеров домена в среде VMware vSphere 5 находится тут: Virtualizing existing domain controllers. Основные проблемы и решения для виртуализованных контроллеров домена можно почитать здесь. У Microsoft есть также своя статья на эту тему.
Полноценная поддержка виртуализованных контроллеров домена Active Directory появится в vSphere 5.1. Windows Server 8, который исполняется в виртуальной машине, на самом деле в курсе, что он работает в ВМ. Это означает, что создание и удаление снапшота такой машины не приведет к проблемам с AD, возникающих с номером последовательного обновления (Update Sequence Number, USN) контроллера. Ранее при восстановлении из снапшота из-за проблем с USN могла остановиться репликация данных каталога. Теперь Microsoft добавила технологию Generation ID, которая позволяет виртуальному контроллеру домена знать, последняя ли версия каталога им используется. За счет этого решаются проблемы с репликацией при откате к снапшоту, а также появляется возможность клонирования виртуальных машин с контроллерами домена.
Что нужно учитывать при виртуализации контроллеров домена:
- Держите контроллеры на разных хостах ESXi, для чего используется все тот же механизм Anti-affinity VM to Host
- Имейте хотя бы один контроллер домена на физической машине (так как компоненты среды виртуализации зависят от AD)
- Не используйте встроенную службу синхронизации времени через VMware Tools. Для этого есть свои средства.
- Не делайте suspend виртуальной машин с контроллером.
- Не восстанавливайте контроллер из снапшота (описано выше)
- По возможности не делайте P2V-миграцию контроллера домена (просто промоутьте новый в виртуальной среде), ну а если, все-таки, делаете то, само собой, только "холодную" миграцию и не используйте customization options
|
| Серверы с прицепленными USB-устройствами |
Начиная с VMware vSphere 4.1, поддерживается проброс USB-устройств в виртуальные машин и даже их vMotion. Помните об этих устройствах при восстановлении ВМ (на другой хост или другой DR-сайт). В vSphere 5.0 появилась возможность проброса USB через vSphere Client.
Основная статья KB про проброс USB в виртуальные машины: USB support for ESX/ESXi 4.1 and ESXi 5.0
C USB-ключом 1С все делается точно так же (а по этой ссылке использование бесплатного USBIP). Для тех, кто любит видеогайды: http://youtu.be/seJQGtyDOX4. |
| Приложения с большим количеством IOPS |
Используйте большое количество шпинделей на Datastore, где хранятся такие приложения. Используйте tiering хранилищ, технологию Storage I/O Control (и трэшхолды), абсолютные лимиты ввода-вывода и т.п. Осуществляйте постоянный мониторинг производительности хранилищ со стороны vSphere и со стороны СХД. |
| Приложения, использующие большой размер блока |
Microsoft SharePoint использует размер блока 256 КБ. Таким образом, 400 IOPS, генерируемых такой виртуальной машиной, забьет гигабитный линк полностью. Для таких приложений лучше использовать протоколы FC или FCoE. Помните, что приложение с размером блока в 1 МБ с легкостью забьет гигабитный линк. |
| Приложение, потребляющее большое количество памяти |
VMware HA при восстановлении не учитывает Admission Control, соответственно такая машина может попасть на хост с малым количеством доступных ресурсов и продолжить работать на нем. Чтобы этого не произошло, нужно использовать привязку ВМ к хостам ESXi (Host to VM), правильно планировать ресурсы и отслеживать ситуацию после сбоев. |
| Приложение требующее больших кадров Jumbo Frames |
Раньше была проблема с Jumbo Frames и драйвером vmxnet3, теперь она решена (в vSphere 5.0 Update 1). Помните, что поддержка Jumbo Frames должна быть на всех компонентах сети (guest OS, port group, vSwitch, physical switch). Не все поддерживает размер кадра в 9000 (актуальное значение можно проверить пингом). |
| Приложения на физических серверах с загрузкой 95% и высокой очередью по CPU |
Такие приложения виртуализовывать не нужно, пока не разберетесь по каким причинам это происходит. Возможно, в отдельных случаях имеет смысл использовать CPU Limit для ВМ (например, это машина для разработки). Главное это где-то зафиксировать, чтобы потом не недоумевать, почему она так медленно работает. |
| Приложения, чувствительные к точности времени |
В виртуальных машинах время может "убегать" от реального (до 10 секунд). Основной документ, как с этим бороться: "Timekeeping in VMware Virtual Machines". |
| Приложения в группе ВМ с зависимостями, которым требуется определенный порядок включения/выключения в штатной и аварийной ситуации |
Для штатных ситуаций используйте виртуальные сервисы vApp (тут подробнее), где можно задавать периоды времени между загрузкой ВМ в группе. Для нештатных ситуаций можно использовать механизм Restart Priority в VMware HA. Также в случае события HA при восстановлении (перезагрузке) одной машины, другим машинам из группы может также потребоваться перезагрузка - это потребует дополнительной автоматизации данной операции (что стоит обсудить с владельцем приложения). |
| Приложения, использующие специфический набор инструкций процессора. |
Если в кластере используются процессоры разных моделей, то при vMotion виртуальной машины - приложение может не получить все необходимые инструкции процессора (если оно об этом не заботится). Кластер EVC в этом случае не поможет - так как различия в инструкциях максируются. На эту тему смотрим статью Detecting and Using CPU Features in Applications. |
На этом пока все. Что по-вашему еще сюда можно добавить?
RSS
