Привет всем, кто уже поборол похмелье после праздников!

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

Кластер создается нажатием ПКМ на датацентре и выбором соответствующего пункта:

Обзываем его как-нибудь оригинально, фичи пока не включаем, их разберем попозже:

Здесь мы можем включить режим улучшенной совместимости для «живой миграции» vMotion, так называемый EVC Mode:

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

Например: у нас есть 3 хоста — 1 из них с процом Intel поколения «Nehalem», а два других «Sandy Bridge», то здесь рекоммендуется установить EVC for Intel с опцией «Nehalem» (более старое поколение). При этом, новомодные фичи процессоров «Sandy Bridge», которые отсутствуют в «Nehalem» использоваться не будут, для обеспечения совместимости.

Также, в описаном случае, при попытке добавления в этот винигрет еще более старого сервера, например «Penrym» — вывалится ошибка совместимости и хост не добавится.

Само собой, при включенном EVC mode для Intel серверов, не получится добавить в кластер сервер AMD и наоборот.

Если данную опцию не включать, то в кластер можно миксовать любые сервера и при этом будет работать VMware HA. НО!! нужно учитывать, что vMotion между AMD и Intel работать не будет, а между поколениями одного производителя может работать нестабильно, что очень важно, при работе VMware DRS в автоматическом режиме (об этом позже).

Для тестовой среды, EVC я не включаю (Disable EVC).

Едем дальше. Здесь можно выбрать место хранения swap файлов виртуальных машин (не путать с файлами/разделами подкачки операционной системы!!):

В большинстве случаев, данная настройка остается дефолтной и файлы подкачки виртуальных машин хранятся в папке виртуальной машины с расширением *.vswp (подробнее здесь), но иногда данные файлы выносят на отдельное хранилище (например на локальные диски сервера) по разным причинам — начиная от экономии дорогостоящего общего хранилища и заканчивая ускорением работы с файлами подкачки посредством вынесения их на более быстрые диски (например SSD).

Оставляем по дефолту, нажимаем Next -> Finish.

После того как кластер создан, закидываем в него подготовленные узлы путем перетаскивания (Drag-and-Drop):

Смешно, но другого способа добавить хост в кластер я не знаю :)) Поэтому — «только винда, тольно драг-н-дроп!».

После добавления хостов, дерево будет выглядеть как-то так:

Теперь все хосты и их виртуальные машины отображаются под кластером на одном уровне («Смешались в кучу кони, люди….»).

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

Самое время их настроить! Тыцаем ПКМ на кластере и выбираем «Edit Settings«:

Разберемся сначала с VMware HA — технологией обеспечения отказоустойчивости виртуальных машин. Для этого включаем галочкой данную опцию как на скрине выше, после чего у нас появляется несколько дополнительных пунктов в левой колонке.

Первая, и наверное, наиболее важная из них — vSphere HA:

На скрине — все настройки по дефолту.

В верхней части находится опция включения/отключения мониторинга узлов по сети, так называемые «хартбиты» (Heartbeats) с помощью которых узлы «пингуют» друг дружку по сети и на основе этих, так называемых пингов, делают выводы о доступности или недоступности своих товарищей.

Данную галочку рекомендуется снимать перед проведением работ в сети, которые могут привести к потере коннекта в сети управления ESXi, для предотвращения ложных срабатываний VMware HA.

Следующие 2 раздела определяют технологию резервации ресурсов кластера, для обеспечения гарантированного перезапуска виртуальных машин в случае выхода из стоя одного или нескольких узлов и срабатывания VMware HA.

В средней колонке мы либо включаем либо отключаем принудительную резервацию ресурсов, а в нижней — определяем технологию, по которой будет рассчитываться количество ресурсов, которые необходимо зарезервировать (при включенном Admission Control).

Просто для понимания, что значит зарезервированные ресурсы — в контексте VMware HA кластера, это ресурсы, которые будут свободны, и будут простаивать, то есть, будет определенный лимит, когда свободные ресурсы у кластера еще вроде как есть, но запустить еще одну или несколько виртуальных машин система не даст, т.к. эти ресурсы на «черный день».

Черный день наступает тогда, когда дохнет один или несколько хостов кластера, соответственно, общее количество ресурсов на кластере уменьшается, а нагрузка остается прежней (ну не всегда, но как пример) и для того, что бы на всю нагрузку хватило ресурсов и виртуалки не ушли глубоко в SWAP — используются ранее зарезервированные ресурсы.

Пытался объяснить на пальцах, но получилось все равно достаточно муторно… В любом случае, долго останавливаться на этих опциях не буду, т.к. это тема отдельной статьи, а то и не одной. Если вкратце, то названия опций говорят сами за себя, а для тестовой среды можно оставить настройки по-умолчанию, или поставить Admission Control «Disable», что я и сделал:

Дальше идут опции виртуальных машин в контесте VMware HA:

Здесь настраиваются 2 вещи: приоритет перезапуска виртуальных машин в случае отказа ESXi узла, на котором они работают и реакцию VMware HA на так называемую «изоляцию» узла:

Оба эти параметра, как видим, настраиваются как глобально, так и для каждой ВМ отдельно.

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

Детальней про изоляцию напишу в другой раз.

Следующим пунктом идет настройка мониторинга виртуальных машин, а именно — состояния их ОС:

Если мы включим данную опцию, то гипервизор будет периодически «пинговать» операционную систему виртуальной машины через VMware Tools и в случае отсутствия отклика — перезапускать виртуальную машину с помощью «Reset«.

Многие используют эту опцию, а я предпочитаю ее оставлять в дефолтном отключенном состоянии. Почему? Да хотя бы потому, что не всегда отсутствие отзыва от VMware Tools, означает что ОС виртуалки зависла, или вывалилась в синий экран, иногда могут банально зависнуть VMware Tools и в таком случае это приведет к ложному срабатыванию и перезапуску абсолютно рабочей виртуальной машины = неприятная ситуация.

Как правило, для мониторинга сервисов и уж тем более — приложений, в том числе и проактивного, у нормального админа используется отдельная система мониторинга наподобии Nagios, Cacti, Zabbix и т.д.. Правда и они не лишены недостатков, но там хотя бы все достаточно гибко настраивается, но как говориться — на вкус и цвет…

Следующая настройка касается такой интересной штуки, как Datastore Heartbeating и используется эта штука, как раз таки для определения изоляции хоста:

Здесь указывается, какие из общих хранилищ (кст, рекомендуется минимум 2) использовать для Datastore Heartbeating. Рекомендую эту опцию как в тестовой среде, так и в продакшене, оставлять по умолчанию.

Далее нажимаем «Ок» для применения всех настроек и наблюдаем процесс настройки HA агентов на узлах кластера:

После того, как данная процедура закончится (обычно меньше минуты) наблюдаем такую бяку:

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

Для тестовой среды можно либо игнорить, либо отключить это предупреждение, что бы не мозолило глаз (о том, как это сделать я писал здесь).

Итого, на данный момент мы имеем отказоустойчивый кластер VMware HA, который обеспечивает перезапуск виртуальных машин, в случае физических сбоев оборудования.

Теперь, если мы наступим на виртуальную машину, то во вкладке «Summary» увидим:

Если, конечно, мы не выбрали «Do not restart» для данной виртуальной машины.

Теперь вкратце про еще одну кластерную фичу VMware — «Distributed Resource Scheduler (DRS)».

Включается она там же где и HA — в «Edit Settings» кластера:

Идем по пунктам. Режим работы кластера:

В принципе, описания опций говорят сами за себя.

В ручном («Manual») режиме, vCenter будет выдавать рекомендации о баллансировке виртуальных машин между узлами кластера, и будет требовать подтверждения от администратора. Рекомендации генерируются согласно алгоритму работы DRS.

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

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

Настройка «Migration treshold» определяет «чувствительность» алгоритма, то есть, чем более «агрессивная» эта настройка, тем более ровным слоем виртуальные машины будут распределяться между узлами. На практике существует несколько нюансов, при использовании этих опций, постараюсь подробно рассказать об этом в другой раз.

Группы и правила DRS:

Данный функционал существует для прописывания дополнительной логики в схеме работы DRS. Например, можно создать группу из 2-х виртуальных машин и задать правило, согласно которому, данные виртуальные машины будут все время располагаться на разных узлах, или на одном узле.

Настройка режима работы DRS может быть сделана для каждой виртуальной машины отдельно:

Аналогично, как и в случае VMware HA.

Настройки VMware DPM (Distributed Power Management):

Настраиваются 3 уровня автоматизации подобно как и в DRS.

Точно так же, можно настраивать отдельно для каждого узла:

Фича очень интересная, но не очень популярная и полезная, по крайней мере — на просторах СНГ.

Суть ее заключается в том, что бы в моменты невысокой нагрузки на сервера (например — ночью или на выходных), все виртуальные машины могут автоматически сгружаться на один или несколько серверов, в целях консолидации, а освобожденные сервера переводятся в сон, для экономии энергии. Ну и когда нагрузка возрастает, спящие сервера просыпаются и на них опять распределяются виртуалки.

Как я уже сказал — данная опция используется редко.

После того, как нажмем «ОК» — кластер готов.

Для управление и монаторинга DRS, существует специальный интерфейс, в виде вкладки для кластера:

Здесь можно посмотреть рекомендации (для ручного и полуавтомата) и применить их, и посмотреть историю переездов, проблемы при переездах и т.п. (на варнинги на хостах не обращайте внимания, это матюки насчет datastore heartbeats :)).

Обязательно не забываем что для работы VMware DRS, на узлах кластера должен быть настроен vMotion.

Тестирование работы кластера.

Для наглядного тестирования VMware HA, можно сделать следующее:

• виртуальную машину, размещенную на общем хранилище, запускаем на одном из узлов кластера
• для большей наглядности, устанавливаем ОС в виртуалку, настраиваем сеть и запускаем пинги на нее
• имитируем отказ узла, на котором работает ВМ (например — жестко отключаем питание сервера)
• наблюдаем процесс перезапуска виртуальной машины на другом узле

По идее, через несколько минут (обычно 2-3 минуты) виртуальная машина перезапустится, о чем будут свидетельствовать возобновившиеся пинги.

С VMware DRS все немного сложнее…

• несколько виртуальных машин, размещенных на общем хранилище, запускаем на одном из узлов кластера и пытаемся их нагрузить, что бы количество используемой RAM сервера перевалила за половину, при этом второй узел кластера должен быть свободен
• в зависимости от настроек режимов автоматизации, VMware DRS либо выдаст рекомендации на соответствующей вкладке, либо автоматически запустит миграцию части виртуальных машин на другой узел с помощью vMotion

В заключение.

К сожалению, т.к. этот гайд писался очень долго, не получилось его сделать полноценным HOWTO, но может это и к лучшему, потому что для читателей он может послужить предпосылкой к детальному изучению данной предметной области :)

Очень многие моменты я упустил, т.к. гайд получился и без того большим и занудным, да и задолбался я его писать, если честно :)) Что-то буду детально освещать в последующих статьях, а на какие-то вопросы могу ответить в комментариях и в личке.

Поэтому, как говорится — не пинайте сильно, задавайте вопросы и пожелания для последующих статей, буду дополнять все вышесказанное ;)