Катастрофоустойчивая инфраструктура на базе VMware SRM (Часть I)

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

В этих статьях я хотел бы рассказать об актуальной 5-й версии продукта, а также описать процедуру его установки и настройки и работу в связке с СХД NetApp.

Но если вы думаете, что я начну первую статью с хвалебных од в честь SRM или с примера конфигурирования СХД, то спешу Вас разочаровать. В первой части я хотел бы рассказать о некоторых базовых вещах, без которых будет сложно описать все преимущества, недостатки и особенности работы SRM.

Вступление
Сразу же хочется ответить на главный вопрос - зачем защищаться от катастроф? Почему не использовать обычный порошок средства обеспечения отказоустойчивости?

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

Конечно, можно положиться на русский авось. А можно оценить риски, величину потерь в случае возникновения того или иного сбоя и сравнить со стоимостью внедрения катастрофоустойчивого решения, написать технико-экономическое обоснование, подсчитать ROI, TCO... и решиться на внедрение SRM.

Проницательный читатель, немного знакомый с SRM, возможно скажет: “ - Зачем мне покупать отдельный продукт, который, по существу, не обеспечивает никакого дополнительного функционала, если я могу практически все то же самое сделать вручную или с помощью скриптов?” - и будет по-своему прав. Однако в критической ситуации, коей, безусловно, является падение виртуальной инфраструктуры и всех сервисов, запущенных в ней, человек имеет свойство паниковать и совершать ошибки. В некоторых случаях цена такой ошибки может многократно превысить стоимость и SRM, резервного ЦОДа и всей виртуальной инфраструктуры.

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

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

Сбои можно классифицировать в зависимости от причины возникновения:

• Аппаратные сбои. К ним можно отнести, например, выход из строя каких-либо отдельных компонентов серверов или СХД (дисков, вентиляторов, блоков питания, плат расширения, портов). От таких сбоев защититься можно, устранив единую точку отказа (дублирование по схеме N+N или N+1). Однако следует помнить, что следует дублировать не только внутренние компоненты, про отдельные узлы системы, например, Ethernet и Fibre Channel коммутаторы, серверы или контроллеры СХД также не следует забывать.
• Программные сбои, которые могут возникать из-за ошибок в коде или программной несовместимости компонентов. Обычно такие сбои не приводят к  прекращению работы всей инфраструктуры, если не брать в расчет масштабных вирусных эпидемий или массовую установку проблемного драйвера или обновления. Защититься от программных сбоев можно, разворачивая поддерживаемые и рекомендованные производителями конфигурации, ставя только проверенное ПО, и тестируя обновления перед их установкой в производственную среду.
• Человеческий фактор не ограничивается только злобной уборщицей, попавшей по недосмотру в серверную, или проделками пьяных администраторов. Зачастую обычная невнимательность или банальная некомпетентность сотрудников могут привести к печальным последствиям. Гораздо хуже, если сбой вызван из-за предумышленных действий (саботажа) компетентного сотрудника, имеющего доступ к системе.
• Форс-мажоры. Практически непредсказуемы по причине возникновения и степени воздействия. Обычно затрагивают все компоненты инфраструктуры сразу, Среди примеров: пожары, наводнения, ураганы, либо более частые - такие как отключение электроэнергии, поломка системы кондиционирования, люди в черных масках с автоматами...

Приведенный перечень является далеко неполным, но позволит администратору определиться с наиболее вероятными причинами сбоев и подготовить таблицу возможных рисков и потерь, к которым они могут привести, а также методами противодействия.

Помимо причины возникновения, сбои можно классифицировать по тому, приводят ли они к потере данных или нет.

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

Во-первых, многие приложения и службы имеют встроенные механизмы защиты данных. Так, например, файловые серверы на базе Windows могут реплицировать файлы и папки, используя протокол DFS, контроллеры домена реплицуруют объекты службы каталога, для баз данных Exchange или SQL можно настроить зеркалирование.

Во-вторых можно использовать универсальные методы защиты данных, такие как:

• Резервное копирование.
• Кластеризация СХД.
• Репликация данных.

Рассмотрим каждый из них подробнее.

Резервное копирование
Как известно администраторы делятся на тех, кто еще не делает резервные копии, и на тех, кто уже делает.

К плюсам резервного копирования относятся:

• Распространённость решений.
• Создание копий данных, актуальных на определенный момент времени.
• Возможность длительного хранения копий данных (архивирование).
• Поддержка различных носителей для хранения копий: магнитные, ленточные, оптические накопители.
• Возможность резервировать и восстанавливать только те данные, которые требуются (выборочное резервное копирование/восстановление).
• Применение разных политик по частоте резервного копирования и длительности хранения для разного типа данных.

Недостатки большинства систем резервного копирования в полной мере характеризуются двумя терминами: RTO и RPO.

(RTO - Recovery Time Objective - это время на восстановление системы после сбоя). Перед тем, как данные снова станут доступны для использования, их требуется восстановить из резервной копии.

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

Этот недостаток присущ для большинства систем резервного копирования, хотя существуют и  исключения, компания Veeam предоставляет продукт для резервного копирования Veeam Backup & Replication, который позволяет монтировать резервные копии в виде NFS хранилища, и напрямую запускать с них ВМ, а после переносить их на основное хранилище с помощью Storage vMotion.

RPO (Recovery Point Objective или точка восстановления) характеризуется временем, прошедшим с момента последнего резервного копирования данных, и также тем объемом данных, которые были изменены, и соответственно, могут быть потеряны из-за сбоя.

Например, если резервная копия базы была сделана в час дня, в два часа дня в базу были внесены изменения, а в три часа на ЦОД упала бомба, то при восстановлении будут получены данные актуальные на час дня и потеряются все изменения сделанные после.

Таким образом, чем чаще наша система выполняет резервное копирование, тем меньше показатель RPO, большинство СРК позволяют создавать резервные копии хоть каждые 15 минут. Проблемы начинаются в тех случаях, когда для особо критичных сервисов этого может быть недостаточно.

Отдельным пунктом можно выделить мгновенные снимки (snapshots), поддерживаемые большинством СХД, которые хотя и не в полной мере являются резервными копиями, но также позволяют сохранить копию данных на определенный момент времени. Мгновенные снимки могут создаваться администратором вручную или по расписанию, а также использоваться для создания полноценных резервных копий или репликации данных.

Кластеризация СХД
Другой метод защиты данных основан на кластеризации СХД. У разных вендоров технологии обеспечивающие кластеризацию могут называться по разному, у кого-то это синхронизация, у кого-то зеркалирование, но идея одна. Несколько узлов СХД объединяются, и представляются для всех потребителей дисковых ресурсов единым логическим хранилищем (как правило, узлов два, но в некоторых решения их может быть и больше). Внутри хранилища обеспечивается избыточность хранения LUN'ов, таким образом, что отказ одного из узлов не приводит к потере доступа к LUN'у с данными для клиента.

В качестве примеров кластерных СХД можно привести:

• HP P4000 (Lefthand).
• NetApp MetroCluster.
• EMC VPLEX Metro.
• Falconstor Network Storage Server.
• Другие..

При желании можно сделать кластеризованное хранилище из серверов, используя Linux + DRBD + HA + iSCSI Target/NFS Export + пару-другую скриптов.

Даже у VMware есть собственный продукт (vSphere Storage Appliance), позволяющий объединить локальные хранилища серверов виртуализации, однако у него есть ряд серьезных ограничений.

Преимущества кластеризации СХД:

• Нулевое время простоя в случае отказа одного из узлов.
• Прозрачная работа для клиентов. Не требуют ручного переключения с одного узла на другой.
• Возможность организации территориально распределенной СХД (Metro или многосайтового кластера). В этом случае, один из узлов СХД может находиться в одном ЦОДе, второй - в другом ЦОДе расположенном в десятках или даже сотнях километров от первого.

Недостатки кластеризации СХД:

• Стоимость. Как правило, такие решения представляют собой отдельные линейки СХД midrange или enterprise уровня, или же требуют покупки дополнительных весьма недешевых лицензий.
• Требование наличия высокоскоростных каналов передачи данных между узлами СХД.
• В случае распределенной СХД, вероятность возникновения Split Brain.

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

В этом случае возможна такая ситуация, когда оба узла посчитают себя активными и станут предоставлять доступ к LUN'у для своей части клиентов. В этом случае может произойти рассинхронизация копий LUN'а, и часть актуальных данных может оказаться в копии, принадлежащей одному узлу, а часть - другому.

Бороться с этим можно различными способами: использовать несколько независимых маршрутов, или организовать третий ЦОД с узлом-арбитром, который будет доступен для узлов кластера по независимым каналам связи и позволит определить, какому из узлов СХД должен принадлежать тот или иной LUN.

Еще один негативный момент использование кластеризации заключается в том, что данные защищаются на уровне физического оборудования, но не на логическом. Любые изменения внутри LUN'а мгновенно синхронизируются, если какой-либо файл или виртуальная машина будет удалена, то это мгновенно отразится на всех копиях. Для того, чтобы иметь возможность "отменить" сделанные изменения следует использовать резервное копирование, мгновенные снимки или асинхронную репликацию.

Репликация
Репликация позволяет настроить копирование по заданному расписанию данных с основного хранилища на резервное. При необходимости, администратор может приостановить репликацию и переключить клиентов на резервное хранилище. Репликация между СХД выполняется на блочном уровне и передает только измененные блоки данных, а не все файлы или LUN'ы целиком.

Функционал репликации есть у большинства вендоров СХД, если не брать в расчет Home Office NAS'ы, где репликация выполняется с помощью какого-нибудь rsync, то, например, в СХД entry уровня HP StorageWorks P2000 G3 появилась такая возможность.

Преимущества:

• Поддержка большим количеством СХД.
• Меньшие требования к каналам передачи данных. 
• Возможность реплицировать данные одного источника на несколько целевых хранилищ.
• Реплики данных могут использоваться для создания резервных копий или тестирования.

Недостатки.

• Прежде всего надо понимать, что исходное хранилище и целевое хранилище - это два разных хранилища с точки зрения клиентов (у реплицированного и исходного LUN'а  различается идентификатор и серийный номер, у контроллеров, участвующих в репликации разные WWN'ы, IP адреса, IQN имена).
• Переключение между хранилищами и презентование реплицированного LUN'а занимает определенное время и обычно выполняется администратором вручную.
• Кроме того, для асинхронной репликации возможна потеря части данных (в зависимости от частоты репликации).

Условной можно разделить репликацию на два типа:

• Синхронная.
• Асинхронная.

Синхронная репликация очень похожа на синхронизацию данных в кластеризованных СХД, подтверждение операции записи на исходное хранилище отправляется клиенту только после того, как данные будут записаны на резервное хранилище.

К недостаткам синхронной репликации можно отнести высокие требования к каналам связи (фактически такие же как у кластеризованных хранилищ).

Кроме того, при использовании синхронной репликации, у администратора нет возможности "отменить" изменения, сделанные на исходном хранилище (если какие-либо данные удаляются на исходном хранилище, то измененные блоки сразу же копируются, и данные удаляются с резервного хранилища). Для восстановления данных в этом случае потребуется использовать резервные копии или мгновенные снимки.

В свою очередь асинхронная репликация позволяет копировать данные по расписанию (раз в день, раз в час, раз в 5 минут).
Преимущества:

• Меньшие требования к каналам связи (зачастую для асинхронной репликации применяется также сжатие передаваемых данных, что позволяет еще больше снизить требования к каналам).
• Обычно реплицированный LUN содержит несколько точек восстановления (мгновенных снимков), необходимых для корректной работы репликации и на случай, если администратор решить вернуться к одной из них.

Недостатки:

• В случае отказа основного хранилища возможна потеря данных, которые не успели реплицироваться на резервное хранилище.

Рассмотренные выше варианты защиты данных не исключают друг-друга и в ряде случаев могут применяться совместно. Если говорить непосредственно о VMware SRM, то весь функционал продукта строится как раз вокруг возможности репликации данных средствами СХД (хотя стоит отметить, что в последней на сегодня 5-й версии появилась возможность организовать репликацию средствами SRM). Но об этом в следующий раз.

Заключение
Не исключено, что придирчивый читатель скажет: "- Как можно было написать столько текста, не вставив ни одной картинки, и практически ничего не сказать о VMware SRM?" Честно говоря - сам в шоке. Однако, тема организации катастрофоустойчивого решения является благодатной почвой для моего словоблудия, надеюсь в следующий раз мне удастся порадовать вас большей конкретикой и техническими деталями.

Продолжение в следующей части: http://blog.vmpress.org/2012/02/vmware-srm-ii.html