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

Сегодня продолжаем говорить о VMware SRM. Для тех, кто пропустил первую часть, рекомендую с ней ознакомиться.

Почему SRM?
Главный вопрос, волнующий системных администраторов - зачем защищать виртуальные машины с помощью репликации и SRM?

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

Во-вторых, SRM обеспечивает универсальную защиту для любых сервисов, запущенных внутри виртуальных машин. Администратор виртуальной инфраструктуры в теории может и не знать, что запущено внутри: файловый сервер или СУБД Oracle, процесс настройки ВМ во всех случаях будет одинаковым.

Однако никто не требует ломать существующую работающую систему и строить все с нуля. SRM не призван заменить существующие механизмы по обеспечению катастрофоустойчивости, а лишь помочь там, где этих механизмов нет, или они труднореализуемы. Немногие инфраструктуры проектируются и развертываются с учетом отказоустойчивости. Развертывание системы, которая бы обеспечивала защиту всех сервисов, может потребовать больших финансовых и временных затрат, что вступает в диссонанс с частым требованием бизнеса предоставить рабочее решение "сейчас" (как пример: "вчера").

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

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

Например, кластер на базе Microsoft Failover Cluster, несмотря на имеющиеся возможности по автоматизации переключения при отказе одного или нескольких узлов, требует наличия кворума - дополнительных узлов, общего диска или сетевой папки, которые придется размещать в третьем сайте для предотвращения split brain. Аналогичный пример с Microsoft SQL Server Database Mirroring, которому для автоматического переключения требуется сервер-свидетель.

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

1. Получить доступ к средствам управления резервным сайтом.
2. На резервной СХД остановить задания репликации, активировать реплицированные LUN'ы, презентовать их серверам виртуализации в резервном сайте.
3. Из консоли управления vSphere Client переподписать и смонтировать все хранилища, расположенные на реплицированных LUN'ах.
4. Зарегистрировать и добавить ВМ в нужные папки и пулы ресурсов. Подключить виртуальные сетевые адаптеры к нужным виртуальным коммутаторам.
5. Запустить ВМ в заданном порядке, при необходимости, изменить настройки сетевых адаптеров.
6. Проверить работоспособность ВМ.

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

SRM прямо из коробки автоматизирует вышеуказанные операции и позволяет выполнять их практически без вмешательства человека, не считая задачи по нажиманию "большой" красной кнопки и финальной проверки работы ВМ, хотя они также поддаются некоторой автоматизации.

SRM позволяет реализовывать как классическую схему резервирования, включающую один основной и один резервный сайт (active-passive), так и гораздо более сложные, например, схему N+1 с несколькими активными и одним общим (shared) резервным сайтом, или схему active-active, когда оба сайта могут одновременно выполнять рабочую нагрузку и являться резервными друг для друга. Для каждого сайта (основного или резервного) требуется собственный экземпляр VMware vCenter Server.

SRM лицензируется по количеству защищаемых ВМ и доступен в двух редакциях: Standard (~195$) и Enterprise (~495$) между которыми существует ровно одно различие - максимальное количество защищаемых виртуальных машин. Для версии Standard количество защищаемых ВМ не должно превышать 75, для Enterprise - неограниченно. Других различий между редакциями SRM нет.

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

Интерфейс SRM не предполагает автоматический запуск плана восстановления, это задача ответственного администратора, который должен оценить критичность сбоя и в нужный момент нажать на “красную кнопку”. Хотя эту задачу и можно автоматизировать с помощью скриптов, но этого крайне не рекомендуется делать.

С точки зрения SRM, сайт – это один или несколько серверов ESXi, подключенных к общей СХД и управляемые одним экземпляром VMware vCenter Server. При развертывании SRM в качестве сайта могут выступать как отдельные ЦОДы, расположенные в сотнях километров друг от друга, или серверные помещения на разных этажах одного здания, так и соседние стойки в одной серверной комнате. Расстояние между ЦОДами ограничено исключительно возможностью организовать каналы передачи данных с требуемыми характеристиками для репликации данных между СХД (см. требования вендора СХД), сам SRM не накладывает здесь никаких ограничений.

Начиная с версии 5.0 SRM помимо репликации на уровне СХД, имеет и встроенные механизмы репликации.

Репликация СХД, как правило, выполняется по отдельным каналам передачи данных (Fibre Channel или iSCSI) может быть как синхронной, так и асинхронной, но реплицирует хранилище VMFS целиком и все ВМ на нем. При репликации средствами СХД следует принимать в расчет следующие лимиты:

Параметр	Значение
Protected virtual machines per protection group	500
Protected virtual machines	1000
Protection groups per recovery plan	150
Datastore groups	150
Concurent recoveries	10

Если при развертывании SRM планируется использовать хранилище, не поддерживающее репликацию, то копирование отдельных ВМ может выполняться с помощью vSphere Replication. Преимущества использования vSphere Replication заключаются в том, что он не требует покупки дополнительных лицензий и настройки репликации на уровне СХД;  к недостаткам можно отнести то, что репликация идет по обычной сети, поддерживается только асинхронная репликация (интервал репликации не чаще раз в 15 минут, не реже раз в 24 часа), кроме того невозможно создавать консистентные реплики для приложений внутри ВМ (всевозможные базы данных).

При репликации vSphere Replication следует принимать в расчет следующие лимиты:

Параметр	Значение
Protected virtual machines per protection group	500
Protected virtual machines	500
Protection groups per recovery plan	250
Datastore groups	250
Concurent recoveries	10

Про другие ограничения vSphere Replication можно прочитать тут и тут.

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

В общем случае можно выделить несколько вариантов организации сети. Каждый из них имеет свои преимущества и недостатки:

• Сквозная IP адресация в обоих сайтах.
• Разные подсети в обоих сайтах.
• Мигрирующая подсеть.

Сквозная IP-адресация позволяет использовать единое адресное пространство во всех сайтах (т.н. Stretched VLAN). Данный вариант является самым простым для администраторов систем виртуализации, но может потребовать больших вложений в модернизацию сетевой инфраструктуры. Одно дело, когда сайты находятся в пределах одного здания на расстоянии нескольких сотен метров, и совсем другое, когда их разделяют сотни километров – такое распределенное решение может быть гораздо сложнее в поддержке, да и аренда или прокладка высокоскоростных линий связи влетит в копеечку.

В случае использования различных сетей (например, 192.168.1.0/24 в основном сайте и 192.168.2.0/24 в резервном), SRM может менять настройки виртуальных адаптеров для ВМ, которые задаются администратором при настройке плана восстановления. В качестве альтернативного варианта может использовать DHCP для назначения сетевых параметров. Однако следует понимать, что далеко не все службы спокойно переносят смену IP адресов, кроме того для некоторых ВМ может потребоваться дополнительная настройка приложений и служб из-за смены адресов.

Наконец все защищаемые ВМ можно располагать в отдельной сети, которая будет “переезжать” в резервный сайт вместе с ВМ, что в общем случае потребует изменения настроек и маршрутизации на сетевом оборудовании.

При установке и начальной конфигурации, серверы SRM настраиваются на взаимодействие с серверами vCenter Server и СХД в локальном сайте. Для интеграции с СХД на серверы SRM устанавливается специализированный агент – Storage Replication Adapter (для каждой поддерживаемой модели СХД существует свой SRA). При помощи данного агента SRM может подключаться к СХД, получать информацию о хранилищах данных и контролировать репликацию. SRA доступны для загрузки с сайта VMware. Список совместимых СХД можно посмотреть здесь.

Для хранения конфигурации SRM используется база данных Microsoft SQL Server (можно использовать Express редакцию). Для каждого сайта необходим свой собственный сервер БД. Кроме того, в каждом сайте должно быть развернуто, по крайней мере, по одному серверу-контроллеру домена и DNS серверу для корректной работы восстанавливаемых служб и приложений. ВМ с контроллерами домена вообще не рекомендуется защищать с помощью SRM из-за USN Rollback.

После выполнения установки и первоначальной настройки SRM, в резервном сайте создается план восстановления (Recovery Plan) на случай сбоя, который определяет перечень ВМ, подлежащих восстановлению, порядок восстановления ВМ, а также набор дополнительных операций (исполняемых сценариев), выполняемые при восстановлении. SRM позволяет администратору создавать несколько планов для разных случаев и при необходимости активировать любой из них.

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

SRM поддерживает два варианта переключения (Failover) с основного сайта не резервный: запланированный и незапланированный.

В случае запланированного переключения, когда требуется провести какие-либо работы в основном сайте (например: отключение питания, перенос оборудования и т.п.), администратор заранее запускает процесс миграции ВМ. SRM выключает все защищаемые  виртуальные машины в основном сайте, запускает репликацию на СХД и проверяет, что она успешно выполняется, после чего запускает реплики ВМ в резервном сайте. Тем самым все ВМ переносятся в резервный сайт, и гарантируется целостность данных внутри ВМ, пускай и ценой некоторого кратковременного простоя.

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

Помимо функционала восстановления инфраструктуры в резервном сайте, SRM также предоставляет возможность переноса ВМ обратно из резервного сайта в основной (Failback). Для этого администратор предварительно должен запустить операцию Reprotect, которая, по сути, перенастраивает репликацию СХД и все защищаемые группы и планы восстановления в обратную сторону, т.е. меняет местами основной и резервный сайты. После чего может быть выполнено запланированное переключение с резервного сайта на основной (SRM погасит ВМ в резервном сайте, выполнит репликацию и запустит реплики ВМ в основном сайте).

Однако это работает только в том случае, если SRM, vCenter Server и СХД в основном сайте доступны. Если СХД или SRM в основном сайте были уничтожены, то придется настраивать репликацию и SRM с нуля, также как при развертывании нового SRM.

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

Заключение
Сегодня мы рассмотрели ключевые возможности SRM и варианты его использования для защиты виртуальной инфраструктуры. В следующий раз мы рассмотрим процедуру подготовки и установки SRM.

При подготовке статьи использовались следующие материалы:

1. VMware Site Recovery Manager Administration Guide.

Катастрофоустойчивая инфраструктура на базе 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

Обзор Citrix XenServer vSwitch Controller

Одним из нововведений, появившихся в Citrix XenServer 5.6 SP1, стал vSwitch Controller - специализированный управляющий виртуальный сервер (Virtual Appliance), расширающий функционал виртуальных коммутаторов XenServer.

После установки vSwitch Controller у администратора появляется возможность анализировать сетевой трафик с помощью RSPAN, собирать статистику (Netflow), настраивать списки контроля доступа (ACL - Access Control List), ограничивать исходящий трафик ВМ и настраивать частные виртуальные сети между несколькими хостами XenServer (Cross-Server Private Network).

Citrix XenServer 6.0 не принес никаких изменений в функционал vSwitch Controller за исключением добавления дополнительного режима применения ACL для виртуальных коммутаторов (Fail-Open) на случай выхода из строя управляющего сервера.

Рассмотрим подробнее возможности контроллера.

Возможности vSwitch Controller
vSwitch Controller доступен в редакции Citrix XenServer Advanced и выше. Процедура установки управляющего сервера крайне проста - достаточно загрузить образ ВМ в формате .xva с сайта Citrix, импортировать его, используя XenCenter, запустить и выполнить первоначальную настройку, задав сетевые настройки и пароль администратора.

Управление контроллером осуществляется через Web-интерфейс (из CLI виртуальной оснастки доступны всего несколько команд, задающих сетевые настройки и позволяющие выключить или перезагрузить ВМ).

Для управления серверами XenServer требуется добавить их в пул ресурсов (Resource Pool), один контроллер может управлять несколькими пулами, но у каждого пула может быть только один управляющий контроллер.

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

Контроллер ведет учет сетевого трафика и может отображать статистику и отрисовывать графики на основе собранной информации. Доступны несколько вариантов отображения: по IP адресам источника и приемника, по виртуальным машинам, по используемым протоколам и приложениям.

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

Для детального анализа сетевого трафика предназначен RSPAN, который позволяет дублировать весь траффик, проходящий через определенную виртуальную сеть, виртуальную машину или виртуальный сетевой адаптер, и помечать его определенным VLAN ID. Создав отдельную виртуальную сеть с аналогичным VLAN ID, вы сможете анализировать его с помощью ВМ с программой для мониторинга, например: Microsoft Network Monitor или Wireshark.

Для защиты виртуальных машин и ограничения входящего и исходящего трафика можно настроить правила разрешающие или запрещающие трафик по определенным портам. В правилах возможно указать протокол (TCP, UDP, номер порта и т.д.), направление трафика (исходящий, входящий, в любую сторону), IP адрес источника.

Правила можно задавать на нескольких уровнях: глобальном, уровне пула ресурсов, виртуальной сети, виртуальной машины, виртуального сетевого адаптера. Кроме того, почти на всех уровнях можно задавать два типа правил - стандартные (Default) и обязательные (Mandatory). Обязательные правила всегда имеют приоритет над стандартными. При обработке пакета происходит сверка со списком правил, пока не будет найдено подходящее правило, после чего пакет принимается или отбрасывается. Порядок проверки правил следующий:

1. Обязательные правила на глобальном уровне.
2. Обязательные правила на уровне пула ресурсов.
3. Обязательные правила на уровне виртуальной сети.
4. Обязательные правила на уровне виртуальной машины.
5. Правила на уровне виртуального адаптера.
6. Стандартные правила на уровне виртуальной машины.
7. Стандартные правила на уровне виртуально сети.
8. Стандартные правила на уровне пула ресурсов.
9. Стандартные правила на глобальном уровне.

При использовании списков контроля доступа следует учитывать один важный момент. В случае недоступности контроллера (например при его выключении), все ACL перестают применяться, и ВМ могут беспрепятственно отправлять и получать пакеты. Такой режим носит название fail-open и в XenServer 6.0 используется по умолчанию. Альтернательный режим fail-safe, доступный еще в XenServer 5.6 SP1, обеспечивает большую безопасность и позволяет сохранить ACL для существующих ВМ при недоступности контроллера, однако имеет ряд побочных эффектов. Например, при смене IP адреса у ВМ, все входящие и исходящие пакеты начинают блокироваться, тоже самое происходит при создании и добавлении новых ВМ в пул или подключении виртуальных адаптеров к существующим ВМ, или миграции ВМ с помощью XenMotion между хостами. Наконец, если хост XenServer перезагрузится и контроллер все еще будет недоступен, все закешированные ACL будут удалены, и весь трафик ВМ будет запрещен. Так что будьте крайне осторожны с данным режимом.

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

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

Частные сети создаются из консоли XenCenter.

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

Если вы планируете передавать большие объемы трафика между ВМ, рекомендуется создать отдельную управляющую подсеть и подключить ее к отдельным физическим адаптерам серверов.

Заключение
Как видите, vSwitch Controller предоставляет администраторам серверов виртуализации достаточно интересные возможности по мониторингу и контролю сетевого трафика, сравнимые с возможностями, доступными в решениях конкурента - VMware vNetwork Distributed Switches и VMware vShield App, и категорически рекомендуется к развертыванию при наличии соответствующих лицензий на Citrix XenServer. Однако, следует помнить, что vSwitch Controller не имеет встроенных механизмов обеспечения отказоустойчивости, поэтому повышать доступность ВМ придется сторонними средствами.

Hitachi Data Protection Suite и VMware vSphere 5

Есть такой продукт для резервного копирования - Hitachi Data Protection Suite (он же CommVault Simpana), который помимо всего прочего умеет бекапить виртуальные машины VMware vSphere. Оказывается, что при работе с VMware vSphere 5.0 у него есть определенные проблемы.

Во-первых, если вы используете хранилище с VMFS 5, то резервное копирование ВМ в режиме SAN будет завершаться с ошибкой: "Error opening virtual machine disk".

В качестве временного решения можно переключиться в режим NBD или NBD SSL (бекап по сети).

Чтобы исправить данную проблему вам потребуется установить на сервер с media агентом обновленную версию VMware vSphere 5.0 Virtual Disk Development Kit (загрузить можно с сайта VMware).

Во-вторых, при попытке восстановления отдельных файлов ВМ или всей ВМ целиком, задача также завершается с ошибкой, что недоступна сеть или сетевая служба. В журнале событий по этому поводу можно найти сообщение: "Either the application has not called WSAStartup, or WSAStartup failed.". Что интересно, проблема возникает только на Windows Server 2008 (x86 или x64), и единственный известный мне способ ее решения - установить CommVault на Windows Server 2008 R2.

VMware VCP 5

На прошлой неделе у меня появилось немного свободного времени, поэтому я решил обновиться до VCP 5. Благо, как и в случае апгрейда VCP 3 -> VCP 4, все, что требуется нынешним обладателям статуса - это успеть до февраля сдать экзамен VCP-510.

Экзамен все также сдается в тестовых центрах VUE (я сдавал в Москве, в УЦ Softline) и стоит 175$ за попытку сдачи. Экзамен включает в себя 85 вопросов, на которые отводится 90 минут (+30 минут для тех, у кого английский не родной язык, а также +15 минут на предварительный опрос).

Экзамен достаточно сильно отличается от VCP-410. Во-первых, он стал сложнее. Если в предыдущем экзамене мне попалось достаточно много вопросов на максимумы и на командную строку, то в новом их было от силы штук 5 (возможно мне так повезло).

Во-вторых, поменялся подход - теперь в вопросах частенько описывают некую ситуацию или показывают картинку и спрашивают "что следует делать?". Т.е. текста, который требуется прочитать и понять стало больше. В итоге первый прогон мне удалось завершить за 1.5 часа, так что дополнительное время оказались как нельзя кстати.

В-третьих, в отличии от VCP-410 мне не встретилось ни одного вопроса по VMware vShield, VMware vCenter Orchestrator или VMware SRM, но было много вопросов по новым технологиям и продуктам, появившимся в vSphere 5. Многие вопросы строятся на знании отличий 4-й версии от 5-ки.

В-четвертых, просто немыслимое количество вопросов с несколькими вариантами ответов, мне показалось, что их даже больше, чем вопросов с одним вариантом ответа.

При подготовке я пользовался документацией с сайта и VMware VCP510 Exam Blueprint. В качестве тестовых вопросов я использовал VCP on vSphere 5 Mock Exam и VCP5 Practice Exams, но оба оказались довольно далеки от вопросов в реальном экзамене.

Итоговый результат: 400 из 500 возможных, с чем себя и поздравляю.

P.S. интересно, как скоро VMware обновит VCAP до 5-ой версии? :-)

VMware vSphere Storage APIs for Storage Awareness для СХД HP

Одним из нововведений, появившихся в vSphere 5.0, стал vSphere Storage APIs for Storage Awareness (VASA), позволяющий администратору упростить процедуру выбора хранилища для размещения виртуальных машин. Если раньше администратор мог полагаться только на свою хорошую память, либо на политику именования хранилищ, что, как правило, могло приводило к названиям вроде "01_HP_P2000G3_iSCSI_RAID5_SAS_NOREPL_LUN0", то теперь стало возможным видеть и другие параметры хранилища (т.н. Storage Capabilities, например: интерфейс подключения СХД, уровень RAID массива, поддержка репликации, физическое расположение, поддержка "тонких" томов и т.п.) прямо из интерфейса vSphere Client.

Все параметры хранилища разделяются на два типа: системные (system), определяемые производителем системы хранения, и пользовательские (user-defined), задающиеся администратором виртуальной инфраструктуры. Для каждого хранилища может быть предопределено несколько системных параметров и только один пользовательский параметр.

Для отображения параметров хранилища требуется зарегистрировать провайдера (Storage Provider) соответствующего производителя СХД. Так, например, для СХД производства HP (HP Storageworks P2000, P4000, EVA, XP) служба провайдера входит в состав HP Insight Control Storage Module for vCenter версии 6.3 и выше, который доступен для загрузки с сайта HP.

Инсталляция HP Insight Control Storage Module довольно проста и не требует никаких специфичных навыков. После установки вам потребуется выполнить базовые настройки интеграции в Insight Control for vCenter Setup Wizard и добавить ваши СХД с помощью Storage Administrator Portal.

Далее с помощью клиента VMware vSphere зарегистрируйте HP Insight Control Storage Module в окне Storage Providers.

Вам потребуется указать URL к серверу в формате "HTTPS://<ИМЯ_СЕРВЕРА>:<ПОРТ>/vasa_provider_ws/vasaService" (порт по умолчанию: 3518), на котором установлен HP Insight Control Storage Module, а также учетные данные для подключения.

После завершения настройки в свойствах каждого хранилища появятся соответствующие ему системные параметры.

Кроме того, вы сможете создавать профили хранилищ, используя соответствующие системные параметры.

При создании ВМ и выборе соответствующего профиля вы сможете увидеть, какие хранилища соответствуют заданным требованиям.

Аналогично при переносе виртуальной машины с одного хранилища на другое.

Загрузка VMware ESXi по iSCSI

Одним из нововведений, появившихся в VMware ESXi 4.1, стала возможность загрузки с iSCSI хранилищ с помощью сетевых адаптеров, поддерживающих iBFT (iSCSI Boot Firmware Table) и VMware Software iSCSI Initiator.

Однако, будьте внимательны если планируете использовать подобный вариант загрузки в VMware ESXi 5.0.

Так, например, с серверами HP Proliant BL460c G6 с интегрированными адаптерами NC532i (они же Broadcom NetXtrem II BCM57711E) такой вариант может не заработать. Причина заключается в том, что в новой версии ESXi, в качестве типа разметки диска используется GPT, а не MBR. Существующая версия загрузчика iSCSI Boot (v4.2.10) не поддерживает GPT диски, выводя при загрузке сообщение: [iBoot-04]: Bootable partition is not found.

В качестве варианта решения проблемы, вы можете предварительно поставить на iSCSI том ESXi 4.1, после чего обновить его до 5.0. В этом случае, установщик оставит тип разметки MBR и вы сможете загрузиться по iSCSI.