В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик | К списку авторов | К списку публикаций

Обеспечение высокой степени доступности геораспределенных виртуальных ЦОДовEnsuring high availability of geo-allocated virtual data centers

Непредвиденные сбои угрожают любой организации, вне зависимости от ее размера или вида деятельности. Эти инциденты могут носить как чрезвычайный характер (например, природные катаклизмы, эпидемии), так и, что более вероятно, бытовой (аварии, прорывы трубопроводов, сбои электроснабжения и т.п.). Вызванные подобными инцидентами нарушения в работе организации влияют на конечных потребителей услуг, вызывая как финансовые потери, так и негативно влияя на репутацию компании. Избежать этих рисков помогают в том числе геораспределенные виртуализированные ЦОДы, благодаря защите от прерывания деятельности компании, снижению вероятности появления перебоев в работе и обеспечению условий для восстановления рабочего процесса.

Unexpected failures threaten any organization, regardless of its size or type of business. These incidents may be both emergencies (e.g. natural disasters, epidemics) and, most likely, of an everyday nature (accidents, burst pipes, power supply failures, etc.). The interruptions in operation caused by such incidents have a severe impact on the organization’s customers inflicting financial damage and negatively affecting business reputation. These risks can be avoided through different measures, including geo-located virtualized data processing centers (DPC), thanks to their business interruption (BI) protection algorithms, reducing the BI probability, and enabling the conditions for recovery of normal operation.

Дмитрий Соловьев
Технический директор Stack Group

Ключевые слова:

виртуальные ЦОДы

Keywords:

virtual data centers

В начале 2000-х гг. компания VMware первой представила свой x86 гипервизор, вызвав до этого неведомый Boom-эффект. Запуск изолированных друг от друга операционных систем на одном физическом сервере позволил резко сократить количество физического оборудования и добиться высокого процента утилизации ресурсов.

Поняв все преимущества виртуализации, к середине-концу 2000-х гг. крупнейшие компании из Fortune 500 полностью или почти полностью трансформировали подход к архитектуре своих информационных систем. Резко вырос спрос на специалистов в области виртуализации, обучение данной технологии, специалистов по поддержке.

С одной стороны, применение виртуализации несло большое количество плюсов, с другой стороны, оставалась главная проблема: если раньше выход из строя сервера приводил к недоступности отдельного приложения, то теперь недоступность отдельных узлов затрагивала всю инфраструктуру. Переход к виртуализации потребовал пересмотра процедур Business Continuity и Disaster Recovery. Многие компании начали задумываться о создании резервных площадок.

Системы хранения данных

Для решения данной проблемы компания VMware представила продукт Site Recovery Manager (SRM), который представлял собой простой набор скриптов, помогал автоматизировать репликацию на уровне системы хранения данных и переключение на резервную площадку в случае запланированного переключения или незапланированного сбоя. Главными недостатками продукта были сложность и стоимость подготовительных работ.

В этот период на рынке появилось большое количество компаний, которые стали предлагать репликацию не на уровне систем хранения данных, а на уровне сервера либо отдельно взятого приложения. Следуя за общим трендом, компания VMware также представила свою репликацию на уровне гипервизора – vSphere Replication, удачно интегрировав его с Site Recovery Manager.

В качестве частного решения для конкретного заказчика на текущий момент применяется Site Recovery Manager с репликацией на уровне системы хранения данных, так как этот вариант позволяет добиться минимальных RTO/RPO для защиты виртуальных машин. Часть компаний использует репликацию на уровне гипервизора, что существенно удешевляет решение, но увеличивает RPO.

Альтернативные решения

Альтернативным вариантом может выступать построение VMware vSphere Metro Storage Cluster. Типичными примерами таких систем выступают решения HPE 3PAR Peer Persistence, NetApp Metrocluster, EMC VPLEX. Суть данных решений заключается в синхронной репликации данных между площадками и использовании стандартных механизмов обеспечения отказоустойчивости VMware HA. Решение, как правило, не подразумевает возможность проведения тестирования переключения между площадками и имеет ограничения по дистанции в случае требования синхронной репликации.

Сетевая инфраструктура

Для организации сетевой связанности между ЦОДами обычно применяются схемы "точка – точка" или построение VPN-туннелей. Первый вариант представляет собой более дорогую реализацию, но имеет более высокие показатели доступности, второй вариант дешевле, но возникает вопрос совместимости технологий производителей, применяемых на площадках. В основном заказчики все же выбирают единого поставщика, и этот выбор определяет используемые технологии. Если производитель сетевого оборудования Cisco, то, скорее всего, применяется проприетарный DMVPN, если Juniper, то возможно использование ADVPN. Для большей унификации решения стоит посмотреть в сторону виртуализации сетей - все управление организовано программным обеспечением (Control Plane), сетевое оборудование выступает в роли портов (Data Plane). Решений на рынке сейчас предостаточно: VMware NSX, Cumulus, Big Switch и т.д.

Публичное облако

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

Причин для этого может быть несколько. Вот некоторые из них:

строить и обслуживать собственную DR-площадку дорого и не всегда обоснованно, особенно если для компании IT - не профильное направление бизнеса;
лицензии и поддержка ПО и "железо" порой требуются на все площадки, независимо от того, что активная из них только одна;
дублирующие каналы связи как до основных площадок, так и резервных могут составлять существенную часть бюджета.

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

Кластеризация на уровне приложений

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

построение зеркала баз;
настройка доставки журналов;
настройка репликации баз;
построение Windows Server Failover Cluster и кластеризация роли MSSQLServer;
построение Windows Server Failover Cluster и настройка групп доступности AlwaysOn.

Нет идеального решения на все случаи. Каждый вариант имеет свои преимущества и недостатки, например, построение зеркала баз позволит удешевить стоимость лицензий на ПО, однако потребует перенастройки приложения на зеркальную базу, что скажется на времени восстановления. Применение групп доступности Always ON хорошо подходит для локального использования или гибридной схемы "заказчик - провайдер", но требует более старшей редакции Enterprise.

Сторонние средства репликации

К сожалению, не все программное обеспечение, используемое в компании, подразумевает возможность встроенных средств кластеризации. Не все программное обеспечение доступно в плане лицензионной политики его применения. Хорошей альтернативой "родной" репликации приложения или в случае ее отсутствия станет использование сторонних решений, таких как DoubleTake или Zerto. Многие из этих компаний уже давно существуют на рынке, и если раньше позиционирование было больше в сторону защиты физических серверов, то теперь многие компании пополнили свой портфель решениями для виртуализации.

Уровень автоматизации катастрофоустойчивой схемы

Одними из важных моментов, влияющих на показатель RTO, выступают:

режимы работы кластера;
схема переключения на реплицированную копию.

Режимы работы кластера

Существует несколько режимов работы катастрофоустойчивого кластера:

режим холодного резервирования (active/passive), когда в один момент времени функционирует только один узел, а резервный находится в режиме ожидания;
режим горячего резерва (active/active) - в этом режиме оба узла работают постоянно, запросы между ними распределяются и используются специальные механизмы блокировки записей для избегания рассинхронизации данных.

Схема переключения на реплицированную копию - актуально для схемы (active/passive)

Переключение на резервную копию может осуществляться вручную - хорошим примером выступает ПО SRM, где после возникновения чрезвычайной ситуации вручную запускается заранее созданный план восстановления. Данная схема имеет серьезный изъян, заключающийся во времени реакции дежурного, так как он может попросту не заметить происшествие и показатель RTO может превысить желаемый результат.

Для решения этой проблемы существуют механизмы автоматического переключения на резервную площадку. В данной схеме узлы на удаленной площадке обмениваются особыми пакетами Heartbeat, в которых содержится информация о доступности сервиса. Основной задачей выступает необходимость удостовериться, что ЧС действительно произошло, а не просто потерялась связь между площадками, иначе оба узла начнут работать параллельно, и это неминуемо приведет к рассинхронизации данных. Для решения данного вопроса используется механизм голосования (Quorum). Для этого на третьей площадке создается сервер-свидетель (Witness) в виде файловой шары, после чего при потере пакетов Heartbeat между площадками начинается голосование, резервная площадка запрашивает у сервера-свидетеля данные о возможности переключения (видит ли свидетель основную площадку), и в случае недоступности основной площадки для обоих узлов происходит переключение на резервную площадку.

Литература