Рекомендации при использовании VMware VI

Портал VMGuru.nl выдает зачетные рекомендации для использования виртуальной инфраструктуры VMware.
Эти рекомендации особенно полезны при создании новой инфраструктуры, хотя и для существующей будут полезны. Переведем 😉
Рекомендации касаются:
– ESX(i);
– vCenter;
– Лицензирование;
– СХД;
– Сеть;
– Виртуальные машины.

ESX(i)
– Проверьте, что ваше железо входит в список HCL. Иначе может заведется сервер, а может и нет. И уж точно при наличии проблем их не будет решать служба техподдержки.
– Перед установкой vSphere обязательно включите опции аппаратной виртуализации и DEP. Если не включить Intel VT или AMD-V, то на vSphere не запустятся x64-ВМ. Выход – переустановка vSphere.
– Обязательно отключите ВСЕ внешние хранилища ВМ перед установкой гипервизора. Восстанавливать ВМ с отформатированного раздела гораздо дольше.
– Если вы остановились на VMware ESX, рекомендуется использовать следующие параметры для таблицы разделов:

* – автоматически создается при установке, но не отображается.
Также рекомендуется переименовать локальное хранилище VMFS из Storage1 в, например, Local@host1.
– Не выполняйте вход на ESX через SSH под учетной записью root. Лучше создайте специальную запись и входите под ней. Сильно рекомендуется использование Active Directory.
– Не используйте агенты в сервис-консоли без очень крайней необходимости.
– Синхронизация времени важна (впрочем, про нее уже много говорилось).
Лицензирование
– Так как “большие” лицензии vSphere лицензируются по процессорам, добываем как можно более быстрые процессоры.
vCenter
– физический или виртуальный vCenter. Выбирать между физическим или виртуальным стоит по наличию у вас религиозных предпочтений или же по размеру вашей инфраструктуры.
* Менее 10 ESX:
virtual server/1 vCPU/3GB RAM/Windows 32 or 64 bit.
* От 10 до 50 ESX:
virtual server/2 vCPUs/4GB RAM/Windows 32 or 64 bit (рекомендуется 64 bit).
* От 50 до 200 ESX:
Physical or virtual server (рекомендуется виртуальный)/4 vCPUs/4GB RAM/Windows 32 or 64 bit (рекомендуется 64 bit).
* Более 200 ESX:
Physical server/4 vCPUs/8GB RAM/Windows 64Bit.
Примечание автора: в третьей версии vCenter использовал ГОРАЗДО меньше оперативной памяти.
– DRS и HA. Рекомендуем исключить vCenter из списка машин, раскидываемых DRS. При настройке HA и запуска ВМ необходимо, чтобы до запуска vCenter была запущена инфраструктура, на которую он опирается (AD, DNS, SQL). Да и сам vCenter нужно запускать раньше остальных ВМ.
– Зависимости vCenter. Если SQL и vCenter установлены на одной машине, настройте зависимость службы vCenter от службы SQL. Если у вас полностью виртуальная инфраструктура и вам необходимо сначала загрузить ESX, а затем запускается DNS, можно прописать необходимые адреса в файл hosts на хостах.
– Не устанавливайте Update Manager поверх vCenter – исключительно из соображений безопасности.
– Выбор кластера. Правильно спланировать кластер достаточно сложно. Запоминайте – размер HA-кластера в vSphere ограничен 32 хостами и 1280 ВМ. Также в кластере есть пять основных узлов, остальные второстепенны. Основными узлами назначаются первые пять узлов кластера. При планировании катастрофоустойчивого решения не забывайте разносить их по разным шасси или серверным. Ну и не забывайте оставить запас, чтобы ваши ВМ могли запуститься в кластере при сбое хотя бы одного узла.
СХД
– Шпиндели и рейды. С количеством ЖД все понятно – больше дисков – больше производительность. С уровнями рейдов все сложнее – надо учитывать требования к скорости, доступности, емкости. К примеру, R10/SATA может быть быстрее, чем R5/SAS.
– Количество ВМ на ЛУН. Тут рекомендация – иметь несколько небольших ЛУН вместо одного большого. VMware рекомендует выкладывать на ЛУН 16-20 серверных ВМ или 30-40 десктопных. Я же рекомендую не больше 16 ВМ.
Примечание автора: во-первых, это связано со спецификой изменения метаданных тома VMFS. Во-вторых, если ваши ЛУНы лежат на разных рейд-группах, умный сторадж сможет их сбалансировать по обоим контроллерам и увеличить производительность за счет использования обоих контроллеров.
– Размер ЛУНа. Исходя из количества ВМ – 16 серверов, добавляя 1-20%, мы получим 400-600ГБ.
– VMDK или RDM. Вообще говоря, расточительно отдавать под каждую ВМ по ЛУНу. Тем не менее, если размер диска больше 20 гигабайт, лучше используйте RDM (я бы все-таки использовал RDM начиная от 50 или даже от 100ГБ). Преимуществ по производительности RDM не несет. Кроме того, есть два режима работы с RDM – физический и виртуальный. В физическом ВМ работает напрямую с SAN, в виртуальном – через гипервизор. Соответственно, работают, например, снимки и создание шаблонов для таких ВМ.
– Размер блока VMFS.
Block size Maximum file size
1 MB 256 GB
2 MB 512 GB
4 MB 1024 GB
8 MB 2048 GB
К примеру, если у вас ЛУН от 400 до 600ГБ и вы используете RDM для дисков больших 20ГБ, вам вполне подойдет размер блока в 1Мб. При использовании тонких дисков, чем меньше у вас размер блока, тем быстрее прирастает тонкий диск. Зато увеличивается количество SCSI-блокировок. Хотя я всегда использую размер блока в 1Мб и НИ РАЗУ не сталкивался с тормозами из-за этих блокировок.
– thin on thin (игра слов). Никогда не используйте тонкие диски на “тонких” ЛУНах. Наблюдаются значительные тормоза.
– Создавайте хранилище с ISO. Удобно для отслеживания версий ПО и для обслуживания ВМ.
Примечание автора: я использую обычную SMB-шару для аналогичных целей. Единственный минус моего варианта – образы отключаются, как только я закрываю vSphere Client.
– Выравнивание дисков. Про него уже много говорилось, например, тут. Суть в том, что у вас есть одни блоки данных на СХД, вторые – на системе VMFS, третьи – в файловой системе на VMDK. Если они смещены относительно друг друга, получается каша. Для выравнивания можно использовать vOptimizer WasteFinder.
Примечание автора: один компетентный товарищ считает, что разницу в плюс/минус 5-10% вполне можно считать погрешностью измерений. Я проверял этот тезис про выравнивание (правда, без гипервизора) на массиве из 6 SCSI-дисках – разницы не увидел.
Сеть
– Разделяйте трафик управления, IP-сетей и ВМ. Лучший способ сделать это – создать разные виртуальные коммутаторы под отдельные виды трафика.
– Используйте отказоустойчивую сеть. Сетевой адаптер с двумя “ногами” не предоставляет отказоустойчивого подключения априори.
– Не усложняйте себе жизнь (Avoid Ether Channels/Link Aggregation). Без лишней нужды не прибегайте к настройкам балансировки нагрузки на свитчах.
– Скорость сети и тип дуплекса. Суть в том, чтобы выставить параметры подключения руками в “Full Duplex, 1Gb/s” как на стороне хоста, так и на стороне свитча. В этом случае больше шансов, что у вас заведется WoL.
Примечание автора: эта же рекомендация действует и для обычных серверов. Кроме того, я рекомендую вначале выставить с обеих сторон автоопределение и удостовериться, что сеть поднимается на 1Gb/s_FD. У меня был прецендент – сетка поднималась только на 100Mb/s_FD. Когда выставил руками гигабит, сеть начала нестабильно работать.
– DMZ. Нет ничего страшного в том, чтобы разместить DMZ на ESX совместно с внутренней сетью. Главное, правильно настроить.
Виртуальные машины
– Удаляйте неиспользуемое аппаратное обеспечение. Особенно этот совет актуален при конвертации P2V.
– Отключайте неиспользуемые сервисы. А еще лучше, отключайте их через групповые политики.
– Запускайте ВМ с минимумом ресурсов. Добавить аппаратных ресурсов в ВМ гораздо проще, чем в физический сервер (особенно если есть запас по мощности). Кроме того, если вы зарезервируете за ВМ определенные ресурсы, их никто не сможет использовать, даже если они простаивают.
Также здесь приводится классический пример. У моих заказчиков был Exchange 2007 сервер с четырьмя виртуальными процессорами и кучей ОЗУ. Сервер жутко тормозил. Удалили два процессора – стало гораздо лучше. Вообще оставили один – сервер просто залетал.
Вот и сказке конец…