Растянутый HA\DRS кластер vSphere 5

Ранее тема растянутых кластеров vSphere затрагивалась в посте об обеспечении катастрофоустойчивости. С тех пор вышла vSphere 5 и появились новшества, связанные в том числе и с растянутыми кластерами:

• технология vSphere Metro Storage Cluster, которая призвана работать в растянутыми VMware HA кластерами;
• vMotion стал возможен на сетях с большими задержками (для Metro vMotion допустима задержка до 10мс);
• переработана технология VMware HA (нет зависимости от DNS,  нет принципа разделения  хостов на primary / secondary и связанных с ним ограничений, появился datastore heartbeating).

В настоящий момент единственным устройством, которое сертифицировано для  vSphere Metro Storage Cluster является VLEX.
EMC VPLEX - решение виртуализации сети хранения данных.

• VPLEX позволяет  объединить ресурсы различных дисковых массивов (необязательно производства EMC) в единый логический пул внутри одного сайта (VPLEX Local) и между сайтами (VPLEX Metro).
• VPLEX обеспечивает репликацию данных между сайтами синхронную (VPLEX Metro до 150 км) и асинхронную (VPLEX Geo ~ 1000 км).
• VPLEX Metro позволяет осуществлять чтение\запись локально на массивы обоих сайтов, тома которых входят в пул распределенного тома (технология AccessAnywhere).

Защита от split brane распределенного тома в VPLEX Metro осуществляется с помощью компонента VPLEX Cluster Witness и назначения для каждого распределенного виртуального тома prefered site и non-prefered site. При разрыве синхронизации между устройствами VPEX  возможность чтения\записи на распределенный том остается только на prefered site,  а non-prefered site останавливает операции ввода\вывода. Виртуальная машина Cluster Witness располагается на третьем независимом сайте, связывается с VPLEX по IP и координирует обработку сбоев.

Плюсы схемы с растянутым кластером vSphere и VPLEX Metro очевидны:

• Наиболее полное использование кластерных технологий vSphere: DRS, HA, vMotion, Storage DRS, т. е. возможна балансировка нагрузки между сайтами, более гибкая балансировка нагрузки на дисковые массивы, и, конечно же, катастрофоустойчивость.
• Защита от аварий дисковых массивов на сайте.
• Обеспечивается непрерывность доступности сервисов при необходимости обслуживания сайта либо его плановой недоступности (предупреждение отказов).

Моменты, на которые следует обратить внимание при проектировании растянутых HA\DRS кластеров:

• Наличие нескольких адресов изоляции (isolation addresses) поможет более четко определять изоляцию хостов. Это важно при работе на двух сайтах, когда есть вероятность разделения сети.
• На каждом сайте должен быть heartbeat datastore, расположенный на нераспределенном (локальном для сайта) томе.
• С помощью предпочтительных (Should) правил DRS VM-Host Affinity возможно\нужно распределять виртуальные машины по сайтам так, чтобы операции ввода\вывода на распределенный том выполнялись локально на сайте. Такая рекомендация есть в KB2007545, где говорится, что предпочтительно, чтобы виртуальные машины были запущены на стороне prefered site. Это поможет снизить влияние аварий, когда разделяются системы хранения или полностью разделяются сайты. Правда, такое правило ограничит автоматическую балансировку нагрузки между сайтами.
• Для сервисов, состоящих из нескольких виртуальных машин, группировать эти виртуальные машины на одном сайте правилами DRS VM-Host Affinity, т.е не разносить отдельный сервис по сайтам.
• Для vmkernel и виртуальных машин требуется растянутая сеть на уровне L2. Вещь довольно сложная и дорогая.
• В этой схеме есть только один vCenter, и доступность его при аварии сайта нужно как-то обеспечить (располагать на третьем сайте; использовать VMware Heartbeat, и если это виртуальная машина,  не располагать ее на распределенном томе).

Источники:
Yellow Bricks: vSphere 5.0 HA and metro / stretched cluster solutions
Deshifrator's blog: vSphere 5: High Availability - Промежуточные итоги
blog.scottlowe.org: Updated Stretched Cluster Presentation
Vierual Geek: VMworld 2011 content: BCO2479 - Understanding vSphere Stretched Clusters, Disaster Recovery, and Planned Workload Mobility