VMware Metro Stretched Cluster: вопросы из зала

Задали мне вопрос, а точнее даже два, насчет механизмов работы растянутых кластеров. Ну и соотв. как их проектировать.
Предварительное условие: растянутый метрокластер поверх EMC VPLEX.

1) Нужно ли 2 vCenter?

Ответ: нет. В метрокластере работает HA, и при падении одного из сайтов vCenter будет перезапущен на оставшемся. Разумеется, vCenter должен находиться на LUN, защищенном VPLEX.

2) Что произойдет с dvSwitch, если упадет vCenter.

Ответ: ничего. Проблема может возникнуть только, если происходит полное падение инфраструктуры, и все без исключения хосты стартуют при остановленном vCenter. В случае с падением 1 сайта все иначе - все хосты на сайте 2 уже загружены, сконфигурированы и работают без проблем. Поэтому vCenter будет просто перезапущен на сайте 2 посредством HA, и вся инфраструктура продолжит свою работу.

Перезапуск виртуальной машины: в кластер или в ресурсный пул?

Недавно меня спросили: виртуальная машина, перезапущенная HA, попадёт в свой ресурсный пул или в корневой ресурсный пул кластера?

Когда HA перезапускает ВМ после сбоя он размещает её в корневом ресурсном пуле кластера, а уже DRS перемещает её в соответствующий ресурсный пул. Так как, по умолчанию, DRS вызывается каждые 5 минут, то максимальное время которое ВМ будет работать вне ресурсного пула – 5 минут.

Как насчёт долей (shares)? Что если ВМ были назначены высокие значения доли, или, что может быть хуже, низкие? Ведь в течении этих 5 минут в ожидании запуска DRS относительные доли данной ВМ могут доминировать над дочерними объектами, или, наоборот, ВМ может столкнуться с недостатком ресурсов из-за других ВМ.

Для решения возможных проблем HA «выравнивает» значение долей данной ВМ перед её запуском. Данный процесс гарантирует, что ВМ получит количество ресурсов равное тому, которое бы она получила если бы была размещена в своём ресурсном пуле. После того как DRS поместит ВМ в соответствующий ресурсный пул ВМ снова будут возвращены её значения долей.

http://blogs.vmware.com/

Комбинирование разных типов affinity rules

Недавно заказчик спросил меня можно ли комбинировать affinity rules типа VM-host и VM-VM anti-affinity rules, какое влияние это окажет на систему и какие минусы такого решения.

Пример сценария
В данном примере две ВМ являют собой одно приложение, кластеризованное на уровне  приложения. ВМ 1 и 2 предоставляют сервис для  App-cluster1, точно также настроены  App-cluster2 и App-cluster3. Вычислительный кластер состоит из 6 хостов. Требование заказчика состоит в том, чтобы каждое кластеризованное приложение работало на собственных физическах серверах. Также разные приложения не должны размещаться на одном физическом сервере за исключением ситуаций обслуживания серверов. Виртуальные машины одного кластера приложений не могут работать на одном сервере.

Построение кластеров. Clouds NN 2012

23-24 августа я выступал на Clouds NN 2012 с темой "Как строить геораспределенные облака". Получилась, на мой взгляд, отличная презентация на тему видов кластеров.

* Для управления необходимо кликать по слайду, или жать пробел - слайды с анимацией.

vSphere Admission Control

Когда мы говорим про контроль доступа, или же admission control, мы обычно имеем в виду политики HA, хотя это не единственная функция, использующая контроль доступа. DRS, Storage DRS, да и сами ESXi хосты имеют свой собственный механизм контроля доступа. Предлагаю детально взглянуть на то, чем же является механизм контроля доступа, и какое участие он принимает в запуске виртуальной машины.

Какова же основная функция контроля доступа? Мне нравится называть эту функцию командой виртуальных балансировщиков. Admission control разработан, чтобы гарантировать предоставление виртуальной машине требуемое и настроенное количество ресурсов. Последняя часть предыдущей фразы и объясняет суть контроля доступа.

Изменения в обработке отказа СХД в vSphere 5.0 U1

О том какие бывают типа отказа СХД и чем отличает APD от PDL можно прочитать в данной статье.

В vSphere 5.0 НА никак не реагировал на изменения состояние СХД, и если у ВМ пропадал доступ к данным считалось, что так и должно быть, и ВМ продолжит работать или будет перезапущена администратором после решения проблем с СХД.

В vSphere 5.0 U1 был представлен новый механизм, который позволяет менять поведение НА в случае потери доступа (PDL) к массиву. Управлять реакцией НА в можно с помощью двух опций: disk.terminateVMOnPDLDefault, параметры которой редактируются в файле /etc/vmware/settings, и das.maskCleanShutdownEnabled, параметры которой редактируются в расширенных свойствах НА кластера.

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

Также при наступлении аварийной ситуации в логе vmkernel будут появляться следующие сообщения:

2012-03-14T13:39:25.085Z cpu7:4499)WARNING: VSCSI: 4055: handle 8198(vscsi4:0):opened by wid 4499 (vmm0:fri-iscsi-02) has Permanent Device Loss. Killing world group leader 4491
2012-03-14T13:39:25.085Z cpu7:4499)WARNING: World: vm 4491: 3173: VMMWorld group leader = 4499, members = 1

Оригинал: Duncan Epping

HA: перевыборы Primary Node

Как уже было написано ранее в "HA Deepdive: Primary nodes", при наступлении HA-события (умер хост) перевыборы Primary Node не происходят.

Часто спрашивают - почему так?

Ответ: перевыборы Primary Node происходят при введении хоста в Maintenance Mode или при отключении от кластера (перевод в состояние "Disconnected"). При наступлении же HA-события, хосту присваивается статус "Not Responding". И соотв. требует отключения хоста вручную, поскольку при "Not Responding" vCenter не может определить, что же именно произошло с хостом.

HA Advanced Settings

Продолжаю публикацию всего, что относится к HA :)

В документе vCenter Performance Best Practices появилось упоминание о двух новых расширенных параметрах HA.

das.perHostConcurrentFailoversLimit

Одновременно при наступлении HA-события может быть перезапущено до 32 ВМ на одном хосте (по умолчанию). Число 32 выбрано, чтобы избежать перегрузки хоста при битве ВМ за ресурсы. При помощи данного параметра можно изменить количество одновременных рестартов и сократить общее время восстановления, однако это может привести к росту среднего времени восстановления ВМ. Рекомендуется использовать значение по умолчанию.

das.sensorPollingFreq

Этот параметр управляет интервалом опроса. HA опрашивает систему для обновления общей информации о кластере (сколько ВМ запущено и т.д.) В vSphere 4.0 установлен интервал 1 секунда, в vSphere 4.1 - 10 секунд. Меньшее значение дает более быстрый перезапуск ВМ, а большее - эластичность кластера, если требуется массовое включение ВМ в большом кластере. Может принимать значения от 1 до 30 секунд.

Источник: Duncan Epping (www.yellow-bricks.com)

HA/DRS и нормализованные Shares

Неделю назад я уже упомянул о важном нововведении в vSphere 4.1, нормализованных shares.

Что же это такое?

При failover'е HA помещает ВМ в корневой ресурс-пул, и если при этом ВМ сама находилась в ресурс-пуле и имела высокое значение shares, то она будет иметь то же самое значение shares и после failover'а.

Предположим, что у нас есть 3 ВМ, 2 из которых находятся в специальном ресурс-пуле Resource Pool A. У VM1 1000 shares, у Resource Pool A - 2000. При этом в ресурс пуле находятся еще 2 ВМ, каждая из которых имеет по 10000 shares. Напомню, что shares в данном случае действуют только в пределах ресурс-пула, и обе ВМ имеют соотв. по 50%. Т.е. VM1 имеет 33% ресурсов, VM2 и VM3 по 50% от 66% ресурс-пула -> все три ВМ имеют по 33% ресурсов.

HA: если не хватает ресурсов

Как вы, наверное, уже помните, при наступлении HA события агенты сначала проверяют наличие свободных ресурсов. Но что, если ресурсов недостаточно? Как все это работает?

А вот как:

Процесс vpxa слушает сообщения hostd об изменениях уровня доступности ресурсов (а именно изменениях незарезервированных ресурсов) и пересылает информацию процессу aam, принимающему решения о failover'е. Но чтобы не спамить aam, vpxa ждет пока изменение составит как минимум 5%. Получив сообщение об изменении доступности ресурсов aam проверяет, нет ли в очереди на failover виртуальных машин, ожидающих ресурсов, и если доступных ресурсов становится достаточно, то failover происходит - машина перезапускается.

Вопрос: а сколько ВМ будет ждать в очереди?
Ответ: пока не появятся свободные ресурсы.

Вопрос: как это сочетается с das.vmrestartcount?
Ответ: никак не сочетается, das.vmrestartcount отвечает за количество попыток перезапуска ВМ при достаточных ресурсах. В данном случае рассматривается ситуация с недостаточными ресурсами и перезапуска не происходит. Как только ресурсов станет достаточно - вступит в действие das.vmrestartcount.

Новые HA Maximums в vSphere 4.1 и интеграция с DRS

Есть несколько изменений в vSphere 4.1, на которые стоит обратить внимание. Одно из очень приятных изменений в Configuration Maximums.

Новые максимумы HA

• 32 хоста в кластере
• 320 ВМ на хост
• 3,000 ВМ на кластер

Иными словами:

• у вас может быть 10 хостов с 300 ВМ на каждом
• или 20 хостов со 150 ВМ
• или 32 с 93 ВМ

Выбор HA Primary Nodes в vSphere 4.1

В VMware HA есть очень важная вещь, называемая Primary Nodes. Проблема с Primary Nodes заключается в том, что нельзя контролировать какие именно хосты станут Primary, что соотв. негативным образом отражается на отказоустойчивости инфраструктуры, построенной на блейд серверах. Если все Primary хосты окажутся в одной блейд-корзине, то при падении этой корзины полностью ложится HA.

В vSphere 4.1 появилась новая тонкая настройка HA - предпочитаемые Primary Nodes.

das.preferredPrimaries = hostname1 hostname2 hostname3
или
das.preferredPrimaries = 192.168.1.1,192.168.1.2,192.168.1.3

Разделять список хостов можно пробелом или запятой. Также необязательно указывать обязательно пять хостов, можно меньше (тогда оставшиеся будут выбраны традиционным способом) или больше (тогда Primary станут первые 5 из них).

Внимание! Эта функциональность не является даже экспериментальной, она просто не поддерживается, и категорически не рекомендуется к использованию в продуктивной среде.

Источник: Duncan Epping (yellow-bricks.com)

Улучшения работы HA в vSphere 4.0 update 2

Одна из часто встречающихся проблем в среде с iSCSI/NFS и VMware HA до vSphere 4.0u2 - split brain.

Для начала попробую объяснить, что такое split brain. Предположим, что у нас такая инфраструктура:

• 4 хоста
• iSCSI / NFS хранилище
• Isolation response: leave powered on

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

1. Хост ESX001 полностью изолирован, включая сеть хранения данных (у нас ведь iSCSI/NFS), но виртуальные машины не выключаются, поскольку ответ на изоляцию "leave powered on".
2. Через 15 секунд оставшиеся неизолированными хосты начнут перезапускать виртуальные машины.
3. Поскольку iSCSI/NFS сеть также изолирована от ESX001, блокировки на VMDK файлах истекут по таймауту, и оставшиеся хосты смогут загрузить ВМ.
4. Когда ESX001 вернется из изоляции, у него все еще останутся в памяти запущенные VMX процессы. И теперь начнется "пинг-понг" с vCenter - ВМ начнут переключаться то на ESX001, то на другие хосты.

В update 2 ESX(i) автоматически определяет, что блокировка VMDK была утеряна и ВМ автоматически выключаются, чтобы избежать "пинг-понга". HA также создаст соответствующий event, который можно будет увидеть в vCenter.

Оригинал: Duncan Epping

HA: Как работает “das.maxvmrestartcount”?

В статье "HA Deepdive: Isolation" было написано о появившемся в vSphere 4.0 параметре das.maxvmrestartcount.

Так как же конкретно происходит перезапуск ВМ и какое влияение имеет этот параметр?

При наступлении HA события, т.е. падении хоста с запущенной виртуальной машиной, HA будет пытаться перезапустить машину на одном из хостов в кластере. Если попытка не удалась, то HA увеличивает на единицу счетчик попыток перезапуска. Первая повторная попытка будет произведена через две минуты, вторая - через 4, каждая последующая через 8 минут. И так до тех пор, пока ВМ не включится либо счетчик не превысит значение das.maxvmrestartcount.

Чуть более наглядно. Предположим, что хост рухнул в 11:59:45, тогда попытки перезапуска ВМ состоятся в:

• 12:00 (после 15 секундного таймаута)
• 12:02 (+2 минуты)
• 12:04 (+4 минуты)
• 12:12 (+8 минут)
• 12:20 (+8 минут)
• 12:28 (+8 минут)

Иными словами, при значении das.maxvmrestartcount по умолчанию равном 5, перезапуск ВМ может занять до получаса (разумеется, при неудачных попытках). При увеличении das.maxvmrestartcount каждая последующая попытка будет так же происходить через 8 минут.

За информацию благодарность Duncan Epping.

vSphere 4.1: HA - что нового

Просочилась информация о новых фишках HA в vSphere 4.1

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

HA Deepdive: Host Selection

1. Slots
2. Primary nodes
3. Isolation
4. Host selection

При разговоре об HA возникает резонный вопрос: как HA выбирает хост(ы) для перезапуска ВМ с умершего хоста? Именно этот вопрос я задал Данкану Эппингу (Duncan Epping).

Все достаточно просто и вместе с тем немного сложно. HA мониторит незарезервированные ресурсы каждого хоста в кластере, и соотв. хост с наибольшими незарезервированными ресурсами становится первым на очереди. Необходимо отдельно подчеркнуть, что мониторингом занимаются HA-агенты, а не DRS. Как известно, DRS - это часть vCenter, в то время как HA работает независимо от vCenter.
Арифметика, связанная со слотами, в данном случае также не при чем, слоты используются только для контроля ресурсов кластера и работы Admission Control.

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

В общем виде процесс выглядит так:

1. Упорядочить доступные хосты по количеству незарезервированных ресурсов
2. Проверить совместимость (сеть / datastore)
3. Старт!
Upd: Уточнение. Для каждой ВМ HA выбирает хост независимо, причем в 4.0 выбирался хост с наибольшим количеством незаразервированных ресурсов, а в 4.1 в алгоритм выбора хоста добавился критерий "с наименьшим количеством ВМ, подлежащих рестарту", чтобы обеспечить лучшее распределение ВМ по хостам. Разумеется, данный алгоритм выбора работает только для кластеров, в которых не указан конкретный failover хост.

Red Hat Enterprise Virtualization: HA [ha ha]

Eric Gray снова радует подробностями о реализации платформы Red Hat Enterprise Virtualization.

RHEV имеет функцию отказоустойчивости, аналогичную VMware HA. Что говорит нам об этом Red Hat?

Но...

Конфигурация отказоустойчивого кластера VMware vSphere

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

Специально для ITBand.ru, с картинками :)

HA Deepdive: Isolation

1. Slots
2. Primary nodes
3. Isolation
4. Host selection

Говоря об HA и переключениях, инициированных HA, необходимо помнить о такой настройке как "isolation response" (ответ на изоляцию). Ответ на изоляцию - это действие, которые предпринимает HA при обнаружении изоляции, недоступности heartbeat сети. На сегодня существует три возможных варианта: "power off" (жесткое выключение ВМ), "leave powered on" (оставить включенными) и "shut down" (мягкое выключение).

До версии ESX 3.5 U2 / vCenter 2.5U2 ответ на изоляцию по умолчанию при создании нового кластера был "power off". В ESX 3.5 U3 / vCenter 2.5 U3 ответ был изменен на “leave powered on”, а в ESX 4.0 / vCenter 4.0 стал "shut down". Обязательно помните об этом при настройке новой среды, возможно, будет необходимо изменить ответ по умолчанию на какой-то конкретный для нужд заказчика.

Грабли: Установка AppSpeed не проходит

Продолжим бег по граблям. Итак,

Грабли: AppSpeed успешно развернулся из OVF, но не проходит первичная настройка с проблемой "Reconfigure virtual machine appspeed-srv - Insufficient resources to satisfy configured failover level for HA."

Причина: AppSpeed требует резерва в 3 GHz, что приводит к срабатыванию Admission Control в HA кластере. Подробнее - здесь.

Лечение: в Advanced Settings для HA выставить das.slotCpuInMHz в более-менее разумное значение. Я поставил 512 MHz.