Мы уже немало писали о EMC VPLEX (тут, тут и тут) - решении для виртуализации сети хранения данных SAN, которое позволяет объединить ресурсы различных дисковых массивов различных производителей в единый логический пул на уровне датацентра или нескольких географически разнесенных датацентров. Это позволяет гибко подходить к распределению дискового пространства и осуществлять централизованный мониторинг и контроль дисковых ресурсов.
Также мы писали и о компании Nicira, купленной некоторое время назад компанией VMware и предлагающей решение Network Virtualization Platform (NVP), предназначенное для виртуализации сетей в рамках концепции Software-defined networking (SDN). Работает оно на базе технологии VXLAN и является основой будущего продукта VMware NSX.
Теперь компании EMC и VMware выпустили видеоролик, раскрывающий преимущества совместного использования этих двух решений:
В ролике показывается, что VPLEX и Nicira имеют высокую степень интеграции в рамках общей концепции автоматизированного датацентра. Например, при увеличении трафика репликации продукт Nicira адаптивно реагирует на это событие и увеличивает доступную полосу пропускания для VPLEX при возрастании нагрузки, а также уменьшает полосу при ее падении. Это особенно актуально в географически разнесенных датацентрах с ограниченными каналами и высокими требованиями по доступности приложений.
С 21 по 24 мая проводилась конференция EMC World 2012, где одной из главных тем были, конечно же, решения по защите данных и балансировки нагрузки между географически распределенными датацентрами. Прежде всего были анонсированы решения EMC VPLEX 5.1 и RecoverPoint 3.5:
По-прежнему, SRA-адаптера для совместного решения VMware SRM+VPLEX до сих пор нет, потому как, похоже, нет окончательной ясности, нужен ли SRM, когда есть VPLEX Metro с синхронизированными томами между датацентрами и "растянутый кластер" VMware vMSC (vSphere Metro Storage Cluster) между хостами датацентров. Безусловно, сотрудники EMC говорят, что решения взаимодополняющие (т.к. SRM - это план восстановления после сбоев, а не схема катастрофоустойчивости), но пока SRM предлагается использовать только в схеме с решением для защиты данных EMC RecoverPoint, для которого SRA-адаптер уже есть:
Появилась также поддержка разнесенных active/active кластеров Oracle RAC в EMC VPLEX:
С точки зрения vSphere Metro Storage Cluster также появилась пара интересных новостей. Во-первых, документ "VMware vSphere Metro Storage Cluster Case Study", описываещий различные сценарии отказов в растянутом кластере высокой доступности (vMSC), построенном между двумя географически разнесенными площадками:
Мы уже писали о решении EMC VPLEX, которое позволяет организовать катастрофоустойчивую архитектуру хранилищ для виртуальных машин за счет организации синхронного распределенного виртуального тома (Disrtibuted Virtual Volume).
Семейство продуктов EMC VPLEX с операционной системой EMC GeoSynchrony является решением по объединению на основе сети SAN. Технология EMC VPLEX Metro позволяет объединить дисковые ресурсы массивов, находящихся на двух географически разделенных площадках в единый пул хранения. Со стороны серверов ESX / ESXi на обеих площадках доступен один виртуальный логический том, который обладает свойством катастрофоустойчивости, поскольку данные физически хранятся и синхронизируются на обеих площадках.
Данная технология интегрирована с технологией отказоустойчивости VMware HA за счет поддержки структуры vSphere Metro Storage Cluster, что позволяет использовать их совместно для обработки различных вариантов сбоев в виртуальной инфраструктуре. К тому же, EMC VPLEX - это единственное сертифицированное VMware решение для организации географически "растянутых" кластеров VMware HA.
В географически разнесенных ЦОД, хранилища которых синхронизированы с помощью VPLEX, есть важная проблема – является ли нарушение связи между узлами кластеров VPLEX следствием сбоя сети или сбоя на площадке. Она затрагивает и кластеры VPLEX, которые находятся в различных географических точках. Система EMC VPLEX обрабатывает сбой сети путем автоматического прекращения всех операций ввода-вывода в устройстве («отключение») на одной из двух площадок в зависимости от набора преопределенных правил. Операции ввода-вывода в то же устройство на другой площадке продолжают выполняться в обычном режиме. Поскольку правила применяются к каждому устройству в отдельности, в случае разделения сети активные устройства могут присутствовать на обеих площадках. Для предотвращения этого используется Cluster Witness - компонент на сторонней площадке, отвечающий за мониторинг доступности основной и резервной площадки.
При отказе различных компонентов ИТ-инфраструктуры и каналов связи могут возникнуть различные ситуации как для кластера VPLEX, так и для кластера VMware HA, которые успешно обрабатываются и теоретически весьма мало ситуаций, которые могут привести к потере данных. Однако есть ситуации (и они всегда будут в распределенных ЦОД - именно потому RTO=0 это Objective, а не Requirement), когда нельзя автоматизировать операции по восстановлению и требуется вмешательство администратора, который выполнит наиболее правильное действие.
Вот как VPLEX совместно с HA обрабатывают различные варианты сбоев:
Сценарий
Поведение VPLEX
Влияние на кластер VMware HA
Отказ одного из путей порта
VPLEX back-end
(BE) к дисковому массиву.
VPLEX прозрачно переключится на альтернативный путь, без влияния на работу распределенных виртуальных томов (Distributed Virtual Volumes).
Отсутствует.
Отказ одного из путей к порту VPLEX front-end
(FE) от хост-сервера.
Сервер ESXi за счет встроенного механизма работы по нескольким путям переключится на резервный путь к распределенным виртуальным томам.
Отсутствует.
Выход из строя массива
на основной площадке.
VPLEX продолжит обслуживать виртуальные тома, используя дисковый массив резервной площадки. Когда основной дисковый массив восстановится после сбоя, тома основного дискового массива будут автоматически синхронизированы с резервного.
Отсутствует.
Выход из строя массива на резервной площадке.
VPLEX продолжит обслуживать виртуальные тома, используя дисковый массив основной площадки. Когда резервный дисковый массив восстановится после сбоя, тома резервного дискового массива будут автоматически синхронизированы с основного.
Отсутствует.
Выход из строя одного из устройств VPLEX Director.
VPLEX продолжит обслуживать виртуальные тома, перенаправив запросы на другие директоры кластера VPLEX.
Отсутствует.
Полная потеря основной площадки (катастрофа), включая все хосты ESXi и компоненты кластера VPLEX (обнаруживается с помощью Cluster Witness).
VPLEX продолжит обслуживать запросы ввода-вывода на дисковом массиве резервной площадки. Когда основная площадка восстановится, виртуальные тома будут синхронизированы с резервной площадки.
Виртуальные машины основной площадки будут перезапущены на хостах резервной площадки.
Полная потеря резервной площадки (катастрофа), включая все хосты ESXi и компоненты кластера VPLEX (обнаруживается с помощью Cluster Witness).
VPLEX продолжит обслуживать запросы ввода-вывода на дисковом массиве основной площадки. Когда резервная площадка восстановится, виртуальные тома будут синхронизированы с основной площадки.
Виртуальные машины резервной площадки будут перезапущены на хостах основной площадки.
Множественный выход из строя хост-серверов в рамках одной из площадок.
Отсутствует
Механизм VMware HA перезапустит виртуальные машины на оставшихся хостах кластера HA.
Выход из строя сети сигналов доступности в рамках одной из площадок.
Отсутствует.
HA продолжит обмен сигналами доступности через общие хранилища (см. тут), что не повлечет за собой аварийного восстановления.
Все пути к хосту ESXi находятся в состоянии APD (All Paths down) – т.е. временно отсутствует доступ к хранилищам (виртуальным томам).
Отсутствует.
В этом случае необходимо перезапустить сервер ESXi, что приведет к перезапуску виртуальных машин в кластере HA на других хост-серверах кластера HA.
Разрыв канала репликации между устройствами VPLEX при сохранении сети управления.
На резервной площадке VPLEX переводит виртуальные тома в режим I/O Failure (что запрещает работу с ними). На основной площадке виртуальные тома продолжают оставаться доступными виртуальным машинам.
На основной площадке виртуальные машины продолжают функционировать. На резервной площадке виртуальные машины получают ошибку ввода-вывода и выключаются. Механизм VMware HA (VM Monitoring) восстанавливает их на резервной площадке.
Сбой кластера VPLEX (компоненты кластера на обеих площадках недоступны, но хосты ESXi не испытывают проблем работы по SAN и СПД).
Запросы ввода-вывода для всех виртуальных томов продолжат обслуживаться на основной площадке.
Хосты ESXi на резервной площадке перейдут в состояние APD. Это потребует их перезагрузки для восстановления виртуальных машин.
Одновременный полный выход из строя обеих площадок.
После восстановления площадок VPLEX продолжит обслуживать запросы ввода-вывода (в первую очередь следует запустить дисковые массивы на обеих площадках).
Хосты ESXi должны быть включены только после того, как компоненты VPLEX будут восстановлены, а виртуальные тома синхронизированы. При включении хостов ESXi виртуальные машины будут восстановлены механизмом VMware HA.
Выход из строя одного из директоров VPLEX на одной из площадок, а также выход дискового массива на противоположной площадке (резервная площадка для виртуального тома).
Оставшиеся директоры кластера VPLEX продолжат обслуживать доступ к виртуальным томам, используя дисковый массив, являющийся для них основным.
Отсутствует
Разрыв сети сигналов доступности (heartbeat) на одной из площадок и разрыв коммуникаций VPLEX между площадками (отличие от выхода из строя площадки понимает Cluster Witness).
VPLEX прекращает обслуживать запросы ввода-вывода для виртуальных томов, у которых дисковые массивы помечены как резервные. Обмен продолжится только с дисковыми массивами, являющимися основными для виртуальных томов.
На основной площадке виртуальные машины продолжат исполняться. Для VMware HA – это ситуация «split-brain» (хосты резервной площадки считают себя оставшимися работоспособными в кластере и пытаются включить виртуальные машины). При включении ВМ на хостах резервной площадки будет получена ошибка ввода-вывода. В этой ситуации необходимо вручную перерегистрировать виртуальные машины резервной площадки на основной.
Том VPLEX оказывается недоступен (например, случайно удален из консоли управления).
VPLEX продолжит обслуживать запросы ввода-вывода с резервной площадки, где том доступен.
Все хосты ESXi работающие с томом VPLEX получают ошибку ввода-вывода и переходят в состояние PDL (Permanent Device Loss). В результате компонент VM Monitoring останавливает виртуальные машины, после чего они запускаются на хостах другой площадки.
Разрыв соединения между компонентами VPLEX на обеих площадках и одновременных выход из строя соединения VPLEX Cluster Witness к основной площадке.
VPLEX прекращает обслуживать запросы ввода-вывода к виртуальным томам на резервной площадке и продолжает работу с томами основной площадки.
Виртуальные машины на резервной площадке завершат работу по ошибке ввода-вывода, они могут быть вручную зарегистрированы и запущены на резервной площадке.
Разрыв соединения между компонентами VPLEX на обеих площадках и одновременных выход из строя соединения VPLEX Cluster Witness к основной площадке.
VPLEX прекращает обслуживать запросы ввода-вывода к виртуальным томам на основной площадке и продолжает работу с томами резервной площадки.
Виртуальные машины на основной площадке завершат работу по ошибке ввода-вывода, они могут быть вручную зарегистрированы и запущены на резервной площадке.
Сбой компонента VPLEX Cluster Witness.
VPLEX продолжает обслуживать запросы ввода-вывода на обеих площадках.
Отсутствует.
Сбой компонента VPLEX Management Server на одной из площадок.
Отсутствует.
Отсутствует.
Отказ сервера управления виртуальной инфраструктурой VMware vCenter
Отсутствует.
На механизм VMware HA и восстановления виртуальных машин это не повлияет. Однако правила размещения и балансировки виртуальных машин по хост-серверам прекратят работать.
Как видите, все ситуации обрабатываются разумно и корректно. Тут обязательным должно быть наличие VPLEX Cluster Witness, который отличит выход из строя линков между ЦОД от выхода из строя одного из ЦОД, о чем он скажет им обоим.
Также надо отметить, что полной автоматизации восстановления тут нельзя добиться, как говорится, "by design".
Скоро нам придется участвовать в интереснейшем проекте - построение "растянутого" кластера VMware vSphere 5 на базе технологии и оборудования EMC VPLEX Metro с поддержкой возможностей VMware HA и vMotion для отказоустойчивости и распределения нагрузки между географически распределенными ЦОД.
Вообще говоря, решение EMC VPLEX весьма новое и анонсировано было только в прошлом году, но сейчас для нашего заказчика уже едут модули VPLEX Metro и мы будем строить active-active конфигурацию ЦОД (расстояние небольшое - где-то 3-5 км) для виртуальных машин.
Для начала EMC VPLEX - это решение для виртуализации сети хранения данных SAN, которое позволяет объединить ресурсы различных дисковых массивов различных производителей в единый логический пул на уровне датацентра. Это позволяет гибко подходить к распределению дискового пространства и осуществлять централизованный мониторинг и контроль дисковых ресурсов. Эта технология называется EMC VPLEX Local:
С физической точки зрения EMC VPLEX Local представляет собой набор VPLEX-директоров (кластер), работающих в режиме отказоустойчивости и балансировки нагрузки, которые представляют собой промежуточный слой между SAN предприятия и дисковыми массивами в рамках одного ЦОД:
В этом подходе есть очень много преимуществ (например, mirroring томов двух массивов на случай отказа одного из них), но мы на них останавливаться не будем, поскольку нам гораздо более интересна технология EMC VPLEX Metro, которая позволяет объединить дисковые ресурсы двух географически разделенных площадок в единый пул хранения (обоим площадкам виден один логический том), который обладает свойством катастрофоустойчивости (и внутри него на уровне HA - отказоустойчивости), поскольку данные физически хранятся и синхронизируются на обоих площадках. В плане VMware vSphere это выглядит так:
То есть для хост-серверов VMware ESXi, расположенных на двух площадках есть одно виртуальное хранилище (Datastore), т.е. тот самый Virtualized LUN, на котором они видят виртуальные машины, исполняющиеся на разных площадках (т.е. режим active-active - разные сервисы на разных площадках но на одном хранилище). Хосты ESXi видят VPLEX-директоры как таргеты, а сами VPLEX-директоры являются инициаторами по отношению к дисковым массивам.
Все это обеспечивается технологией EMC AccessAnywhere, которая позволяет работать хостам в режиме read/write на массивы обоих узлов, тома которых входят в общий пул виртуальных LUN.
Надо сказать, что технология EMC VPLEX Metro поддерживается на расстояниях между ЦОД в диапазоне до 100-150 км (и несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало.
До появления VMware vSphere 5 существовали некоторые варианты конфигураций для инфраструктуры виртуализации с использованием общих томов обоих площадок (с поддержкой vMotion), но растянутые HA-кластеры не поддерживались.
С выходом vSphere 5 появилась технология vSphere Metro Storage Cluster (vMSC), поддерживаемая на сегодняшний день только для решения EMC VPLEX, но поддерживаемая полностью согласно HCL в плане технологий HA и vMotion:
Обратите внимание на компонент посередине - это виртуальная машина VPLEX Witness, которая представляет собой "свидетеля", наблюдающего за обоими площадками (сам он расположен на третьей площадке - то есть ни на одном из двух ЦОД, чтобы его не затронула авария ни на одном из ЦОД), который может отличить падения линка по сети SAN и LAN между ЦОД (экскаватор разрезал провода) от падения одного из ЦОД (например, попадание ракеты) за счет мониторинга площадок по IP-соединению. В зависимости от этих обстоятельств персонал организации может предпринять те или иные действия, либо они могут быть выполнены автоматически по определенным правилам.
Теперь если у нас выходит из строя основной сайт A, то механизм VMware HA перезагружает его ВМ на сайте B, обслуживая их ввод-вывод уже с этой площадки, где находится выжившая копия виртуального хранилища. То же самое у нас происходит и при массовом отказе хост-серверов ESXi на основной площадке (например, дематериализация блейд-корзины) - виртуальные машины перезапускаются на хостах растянутого кластера сайта B.
Абсолютно аналогична и ситуация с отказами на стороне сайта B, где тоже есть активные нагрузки - его машины передут на сайт A. Когда сайт восстановится (в обоих случаях с отказом и для A, и для B) - виртуальный том будет синхронизирован на обоих площадках (т.е. Failback полностью поддерживается). Все остальные возможные ситуации отказов рассмотрены тут.
Если откажет только сеть управления для хостов ESXi на одной площадке - то умный VMware HA оставит её виртуальные машины запущенными, поскольку есть механизм для обмена хартбитами через Datastore (см. тут).
Что касается VMware vMotion, DRS и Storage vMotion - они также поддерживаются при использовании решения EMC VPLEX Metro. Это позволяет переносить нагрузки виртуальных машин (как вычислительную, так и хранилище - vmdk-диски) между ЦОД без простоя сервисов. Это открывает возможности не только для катастрофоустойчивости, но и для таких стратегий, как follow the sun и follow the moon (но 100 км для них мало, специально для них сделана технология EMC VPLEX Geo - там уже 2000 км и 50 мс latency).
Самое интересное, что скоро приедет этот самый VPLEX на обе площадки (где уже есть DWDM-канал и единый SAN) - поэтому мы все будем реально настраивать, что, безусловно, круто. Так что ждите чего-нибудь про это дело интересного.
Таги: VMware, HA, Metro, EMC, Storage, vMotion, DRS, VPLEX
RSS
