Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.
"Интегрирован" - означает, что любая нештатная ситуация, случившаяся с хостами ESXi должна быть обработана на стороне обоих механизмов, а также решение этой проблемы находится в компетенции поддержки VMware. И правда - ведь отказавший хост ESXi нарушает целостность обоих кластеров, поскольку предоставляет и ресурсы хранилищ, и вычислительные ресурсы.
При этом, например, в случае каких-нибудь сбоев в сети может произойти "разделение" кластеров на сегменты, что может повлечь неоднозначность в их поведении, поскольку они используют разные сети для поддержания кластера (хождения хартбитов).
Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:
Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:
Вот тут и возникает 3 основных вопроса:
- Какие хранилища нужно использовать в качестве datastore heartbeat?
- Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
- Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?
Ну а в статье на блогах VMware даются вот такие ответы:
1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.
2. По поводу isolation address есть следующие рекомендации:
- При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
- Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
- Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.
3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:
| Не-VSAN машина (не хранится на хранилищах Virtual SAN) | Да | Да | Leave Powered On | ВМ работает нормально - зачем что-то делать? |
| Не-VSAN машина | Да | Нет | Leave Powered On | Подходит для большинства сценариев. Если же доступ машины к сети очень критичен и не критично состояние ее памяти - надо ставить Power Off, чтобы она рестартовала на других хостах (координация восстановления будет через сеть VSAN). Дефолтно же лучше оставить Leave Powered On. |
| VSAN и не-VSAN машина | Нет | Да | Leave Powered On или Power Off | См. таблицу ниже |
| VSAN и не-VSAN машина | Нет | Нет | Leave Powered On или Power Off | См. таблицу ниже |
А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:
| Нет | Да | Да | Leave Powered On | Важно состояние памяти ВМ. Так как есть доступ к хартбит-хранилищам, то ВМ не стартует на других хостах |
| Нет | Да | Нет | Power Off | Надо выключить ВМ, так как есть вероятность того, что ее вторая копия стартанет в другом сегменте разделенной сети. |
| Да | Нет | Да | Leave Powered On | Нет смысла выключать ВМ, так как хост-мастер операций не сможет инициировать ее восстановление, так как все хосты друг от друга изолированы. |
Логика тут в принципе понятна, но в каждой конкретной ситуации может быть масса тонкостей касательно различных сценариев разделения и сбоев в сети, так что эти таблички лишь определяют направление мысли, а не дают готового рецепта.