1

Компания Netwell ‐ российский дистрибьютор высокотехнологичного оборудования. Основные направления деятельности – сетевые технологии, системы хранения данных, сетевая и информационная безопасность. Netwell является официальным дистрибьютором компании NetApp.

NETAPP TECHNICAL REPORT

VMware vSphere 5 на NetApp MetroCluster

Santhosh Devaraju, Ashish Nainwal, NetApp

February 2013 | TR-4128

2

Оглавление 1 Введение............................................................................................................................................ 4

1.1 Целевая аудитория ..................................................................................................................... 4

1.2 Цели документа .......................................................................................................................... 4

1.3 Требования к уровню знаний читателя ...................................................................................... 4

2 Основы ............................................................................................................................................... 5

2.1 Бизнес-требования ..................................................................................................................... 5

2.2 Решение непрерывной доступности для системы vSphere ....................................................... 5

Что такое vSphere Metro Storage Cluster? ..................................................................................... 6

3 Введение в NetApp MetroCluster....................................................................................................... 9

3.1 Компоненты MetroCluster .......................................................................................................... 9

3.2 Типы MetroCluster ..................................................................................................................... 10

Топология Stretched MetroCluster (SMC) ..................................................................................... 10

Конфигурация Stretched MetroCluster ........................................................................................ 11

Конфигурация Stretch MetroCluster в вариантах Dual и Twin ..................................................... 12

Топология Fabric-Attached MetroCluster (FMC) ........................................................................... 13

Конфигурация Fabric-Attached MetroCluster ............................................................................... 13

4 Обзор решения vSphere .................................................................................................................. 14

4.1 Обеспечение доступности vCenter ........................................................................................... 14

Способ 1: Защита vCenter Virtual Machine с помощью VMware HA Cluster ................................ 15

Способ 2: Установка vCenter в собственный кластер ................................................................. 15

Способ 3: Защита vCenter с использованием VMware vCenter Heartbeat Solution .................... 15

4.2 Реализация vSphere HA на NetApp MetroCluster...................................................................... 17

Обзор ........................................................................................................................................... 17

4.3 Реализация VMware DRS на NetApp MetroCluster ................................................................... 18

4.4 Реализация VMware Storage DRS на NetApp MetroCluster ....................................................... 18

5 Руководство по разработке архитектуры и внедрению ................................................................. 19

5.1 Конфигурирование NetApp Storage .......................................................................................... 19

5.2 Конфигурирование VMware vSphere ........................................................................................ 21

Конфигурирование vSphere HA для NetApp MetroCluster .......................................................... 21

Конфигурирование VMware DRS Groups в vSphere 5 на NetApp MetroCluster ........................... 23

Конфигурирование DRS Rules в vSphere 5 на NetApp MetroCluster ............................................ 24

Создание Datastore Cluster .......................................................................................................... 26

6 Ситуации использования MetroCluster ........................................................................................... 27

6.1 Отказ одного из путей к системе хранения .............................................................................. 27

3

6.2 Отказ хоста ESX.......................................................................................................................... 28

6.3 Изоляция хоста ESX ................................................................................................................... 29

6.4 Отказ сервера vCenter .............................................................................................................. 29

6.5 Отказ межкоммутаторного линка ............................................................................................ 30

Отказ межкоммутаторного линка в сети управления (Management Network) .......................... 30

Отказ межкоммутаторного линка в сети хранения (Storage Network)....................................... 31

Отказ межкоммутаторного линка между контроллерами NetApp Fabric MetroCluster ........... 32

6.6 Отказ всех ISL или полной потери датацентра ......................................................................... 33

6.7 Отказ контроллера системы хранения ..................................................................................... 34

6.8 Отказ дисковой полки .............................................................................................................. 36

6.9 Потеря сайта целиком .............................................................................................................. 37

7 Комбинированные тесты (Отказы на обоих сайтах) ....................................................................... 38

8 Выводы ............................................................................................................................................ 39

Об авторах ........................................................................................................................................... 40

История изменений ............................................................................................................................ 40

4

1 Введение Данный документ предлагает введение в решение NetApp® MetroCluster™ для систем серверной

виртуализации VMware vSphere® 5.0 и новее. Он содержит детальное рассмотрение архитектуры

высокодоступного решения NetApp MetroCluster, с использованием ведущего в индустрии

решения виртуализации серверной инфраструктуры VMware vSphere. Рассмотрены также

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

рассмотрена тема процедуры внедрения.

1.1 Целевая аудитория Документ предназначен для следующей аудитории:

Пользователи систем хранения NetApp и партнеры, желающие реализовать решение

непрерывной доступности данных для среды виртуальной серверной инфраструктуры,

использующей VMware® vSphere 5.0 и новее и системы хранения NetApp FAS.

Конечные пользователи, интересующиеся решениями непрерывной доступности данных

для производственных задач, или для задач разработки/тестирования (dev/test).

1.2 Цели документа Целью данного документа является:

Дать общий обзор архитектуры решения непрерывности бизнеса в среде виртуальной

инфраструктуры

Детально рассмотреть дизайн, а также рекомендации по наилучшим методам

конфигурирования

Рассмотреть в общих чертах основные области применения, а также возможные сценарии

отказов и реакцию системы на них

Документ не включают в себя следующие смежные темы:

Данный документ не заменяет собой официальное руководство и документацию NetApp и

VMware по соответствующим продуктам, использованным в решении, или от иных

производителей оборудования (например, производителей коммутаторов), упомянутых в

документе.

Данный документ не обсуждает темы, связанные с влиянием на производительность при

возникновении события катастрофы, с точки зрения конечного пользователя.

Этот документ не заменяет документы и сервисы, предоставляемые службами professional

services NetApp и VMware.

Этот документ не рассматривает решения регионального размера (с большим разносом

узлов). Если вам нужен именно продукт с разносом узлов в масштабах региона, свяжитесь

с сотрудниками NetApp.

1.3 Требования к уровню знаний читателя Документ предполагает знакомство читателя со следующими темами:

Базовые знания о технологиях виртуализации VMware и продуктах:

o VMware vCenter™ 5.0 и новее

o VMware vSphere 5.0 и новее

Базовые знания об устройстве и работе систем хранения NetApp и OS NetApp Data ONTAP®

5

2 Основы

2.1 Бизнес-требования Постоянно меняющиеся бизнес-задачи и экспоненциальный рост создают непрерывное давление

в области доступности данных и непрерывности бизнеса. Так как все больше бизнес-критичных

решений размещается в так называемых «виртуальных датацентрах», это увеличивает акцент на

увеличении надежности инфраструктуры. Такое улучшение позволяет компаниям извлекать

экономические и эксплуатационные преимущества виртуализации без ущерба для доступности и

качества услуг. Планирование надежной высокодоступной инфраструктуры решения в системе

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

Эффективная, высокодоступная виртуализованная инфраструктура это легко развертываемое и

легко управляемое решение, обеспечивающее высокие стандарты надежности, без компромиссов

в отношении производительности или экономической эффективности.

VMware, со своими возможностями высокой доступности и отказоустойчивости, обеспечивает

единообразную защиту от сбоев оборудования или программного обеспечения в среде

виртуализованной IT-среды.

NetApp MetroCluster это экономически эффективное решение синхронной репликации данных,

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

городской распределенной системы, для защиты от катастрофических событий или аппаратных

поломок и простоев. NetApp MetroCluster обеспечивает автоматическое восстановление при

любом отказе любого отдельного компонента системы, и высокоэффективное восстановление

«одной командой» в случае катастрофических событий на одном из сайтов. Он обеспечивает

решение с «нулевыми потерями данных» и восстановление за минуты, тем самым значительно

улучшая показатели RPO и RTO компании.

Скомбинировав решения VMware - high availability (HA) и fault tolerance (FT) с технологиями

NetApp MetroCluster вы получаете выдающийся продукт для защиты бизнес-критичных задач,

приложений и ресурсов компании. Эта комбинация предлагает архитектурно простое и

высоконадежное решение непрерывной доступности данных и работы приложений, способных

полностью устранить как плановые, так и внеплановые простои в среде «виртуального

датацентра».

Каждое из этих решений рассматривается вкратце в главе 2.2, «Решение непрерывной

доступности для системы vSphere».

2.2 Решение непрерывной доступности для системы vSphere NetApp Unified Storage Architecture предлагает гибкую и масштабируемую платформу хранения.

Все системы хранения NetApp FAS используют внутри специализированную операционную

систему Data ONTAP для организации доступа к хранимым данным по протоколам SAN (FC/FCoE,

iSCSI) и NFS.

NetApp MetroCluster использует функциональность NetApp High Availability (controller failover, CFO)

для автоматической защиты от отказов контроллера. Дополнительно, MetroCluster использует

технологию local SyncMirror®, что обеспечивает кластерный файловер (переключение ресурсов и

доступа к данным, при выходе из строя, с отказавшего узла на исправный) при внешних событиях

катастрофического характера (controller failover on demand, CFOD). Избыточность оборудования и

6

географическая его распределенность позволяют достичь предельно высокого уровня

доступности данных. Local SyncMirror синхронно реплицирует данные между двумя половинами

хранилища MetroCluster, путем записи данных на два так называемых «плекса» (plex, сегмент

дискового хранилища): локальный plex (на локально расположенной дисковой полке) активно

обслуживающей запросы данных, и удаленный plex (на удаленной полке) в штатном режиме

использования запросы на доступ к данным не обслуживающий. В случае отказа на локальной

дисковой полке, удаленная дисковая полка прозрачно для пользователя перехватывает

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

как используется так называемая синхронная репликация (зеркалирование). Аппаратное

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

диски, дисковые полки, кабели, коммутаторы (в конфигурации Fabric MetroCluster), и адаптеры,

все они дублированы.

Кластер VMware HA/DRS создается из двух сайтов, использующих хост-сервера под управлением

ESXi™ 5.0 или 5.1, и управляются vCenter Server 5.0 или 5.1. Средства управления vSphere, vMotion®,

и сеть виртуальных машин соединяет с помощью избыточной сети два этих сайта, а vCenter Server

управляет кластером HA/DRS, состоящим из хостов ESXi на обоих сайтах.

Что такое vSphere Metro Storage Cluster?

vSphere Metro Storage Cluster (vMSC) это новая сертифицированная конфигурация VMware.

Конфигурация vMSC разработана для обслуживания задачи высокой доступности данных, с

использованием распределения на два физических и логических месторасположения. Системы

хранения поддерживаются VMware после успешной их сертификации на соответствие

требованиям программы vMSC. Все поддерживаемые системы хранения указаны в VMware

Storage Compatibility Guide.

Для подробностей о требованиях к дизайну vSphere Metro Storage Cluster, смотрите следующие

документы:

vSphere 5.x Support with NetApp MetroCluster

VMware vSphere Metro Storage Cluster - Case Study

В зависимости от планируемого расстояния разноса сайтов, NetApp MetroCluster для vSphere

может быть построен в двух разных вариантах конфигурации:

Stretched MetroCluster

Fabric MetroCluster

7

Рисунок 1 показывает общую топологию конфигурации Stretched MetroCluster.

Рис. 1) Общая топология конфигурации Stretched MetroCluster.

8

Рисунок 2 показывает общую топологию конфигурации Fabric MetroCluster.

Рис. 1) Общая топология конфигурации Fabric MetroCluster.

9

3 Введение в NetApp MetroCluster MetroCluster это интегрированное, высокодоступное решение обеспечения непрерывности

бизнеса, разработанное для создание распределенной по территории кампуса или города

системы хранения. В случае катастрофических событий, влияющих на датацентр, MetroCluster

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

удаленный датацентр. Все операции продолжаются немедленно, без потери данных и с

минимальным административным вмешательством.

Процесс переключения (takeover process) занимает считаные минуты, и не прерывает работу

пользователей системы. Пользователи системы получают предельно быстрое восстановление

работы их сервисов, если сравнивать это с другими, аналогичными решениями Disaster Recovery,

которые, часто, предлагают время восстановление работы от часов до дней. MetroCluster состоит

из следующих составных частей.

Контроллеры, работающие в режиме Active-Active. Обеспечивают высокую

доступность, функцию переключения при отказе (failover) между устройствами как на

локальном, так и между локальным и удаленным сайтами.

SyncMirror. Обеспечивает непрерывную копию данных на удаленный сайт. Данные

доступны только удаленному хранилищу после операции переключения (failover).

Cluster Remote. Предоставляют механизм, с помощью которого администратор

позволяет определить факт отказа на сайте и инициировать процесс переключения на

удаленный сайт.

Дополнительно, если основной и удаленный сайты расположены на расстоянии более 500 метров

друг от друга, необходима пара выделенных под эти операции FC-коммутаторов,

обеспечивающих связь между сайтами на большом расстоянии.

3.1 Компоненты MetroCluster Конфигурация NetApp MetroCluster включает в себя как аппаратные, так и программные

компоненты, которые перечислены в таблицах 1 и 2.

Таблица 1) Аппаратные компоненты MetroCluster.

No. Аппаратный компонент

1. HA-пара контроллеров FAS, с OS Data ONTAP.

2. Четыре коммутатора Fibre Channel (FC) с поддерживаемой версией прошивки, поставляемой NetApp, по паре на каждом из двух сайтов (в случае конфигурации Fabric-MetroCluster). Модели коммутаторов могут быть различными (но обязательно поддерживаемыми) между фабриками, но должны быть идентичными в пределах одной фабрики. Эти коммутаторы должны использоваться исключительно под задачи MetroCluster, и не могут использоваться под какие-либо иные задачи, чем MetroCluster. Кроме этого следует учесть, что установка этих выделенных и изолированных коммутаторов обязательна, существующая инфраструктура коммутации FC на сайтах пользователя не может быть использована под задачи межсайтовой коммуникации MetroCluster.

3. Адаптер Fibre Channel-Virtual interface (FC-VI) для передачи данных кластерного интерконнекта, за исключением варианта Stretched MetroCluster, с кабелем FC-VI длиной менее 30m. Это требование обязательно для моделей FAS31xx, 32xx, и 62xx.

10

4. Конвертер Copper/Fiber для кластерного интерконнекта. Только для FAS9xx, 30xx, и 60xx.

5. Необходимые кабеля и SFP.

6. Минимум четыре порта FC initiator (storage adapters).

7. Дополнительные дисковые полки для размещения зеркалированных данных.

8. В случае использования полок SAS, необходимо использование устройств FibreBridges 6500N, по два на стек полок SAS.

9. Fabric-attached MetroCluster требует наличия выделенных линков dark fiber (неиспользуемого никаким другим сигналом) оптоволокна между сайтами, причем могут быть использованы решения xWDM, поддерживаемые производителями коммутаторов.

Внимание: Проверьте по сайту NetApp MetroCluster Compatibility Matrix поддерживаемые

модели, версии прошивок/fabric OS, и версии Data ONTAP.

Таблица 2 показывает программные компоненты NetApp MetroCluster.

Таблица 2) Программные компоненты MetroCluster.

No. Программные компоненты и лицензии на каждом контроллере и коммутаторе

Для контроллера FAS Для коммутатора Brocade Для коммутатора Cisco

1. cluster – для операций переключения (failover) контроллеров.

Brocade extended distance

license – для межсайтовой связи ( более 10км)

Cisco® ENTERPRISE_PKG – для увеличения buffer-to-buffer credits

2. syncmirror_local – для синхронного зеркалирова-ния данных между сайтами

Brocade ports-on-demand

(POD) – для масштабирования коммута-тора по портам

Cisco PORT_ACTIVATION_PKG – для масштабирования коммутатора по портам

3. cluster_remote – для переключения между сайтами в случае катастрофы

Cisco FM_SERVER_PKG – (опционально) для включения Cisco Fabric Manager GUI

3.2 Типы MetroCluster MetroCluster может быть сконфигурирован в двух вариантах.

Топология Stretched MetroCluster (SMC)

Stretched MetroCluster это конфигурация, когда реализовано прямое подключение между HA-

парами на ограниченном расстоянии между ними (обычно это кампусная сеть, или расстояние

между соседними зданиями). Эта конфигурация обеспечивает избыточность и

катастрофоустойчивость на расстоянии разноса до 500 метров. Stretched MetroCluster

обеспечивает зеркалирование данных и дополнительные возможности по запуску переключения

(failover), если сайт целиком окажется недоступным.

Также как обычная конфигурация mirrored active-active, Stretched MetroCluster содержит две

полных копии данных или файловых систем. Эти копии называются «плексы» (plex), и всякий раз,

когда Data ONTAP пишет данные на диски, эти копии одновременно и синхронно обновляются.

Однако в отличие от конфигурации mirrored active-active, MetroCluster обеспечивает не просто

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

целиком (контроллер и/или диски) окажется поврежден или недоступен.

11

Рисунок 3 показывает архитектуру Stretched MetroCluster.

Рис. 3) Топология архитектуры Stretched MetroCluster.

Внимание: Расстояние указывает реальную предельную длину кабелей между локальным и

удаленным сайтом. Не оценивайте расстояние «по прямой», так как в реальности,

фактически проложенное кабельное соединение между сайтами может быть не

прямым, и значительно длиннее, чем оцененное «на глаз», «по прямой».

Конфигурация Stretched MetroCluster

Рисунок 4 показывает типичную конфигурацию Stretched MetroCluster с использованием

контроллеров FAS32XX single controller на каждом сайте, с подключенными полками DS14MK4-FC.

12

Рис. 4) Конфигурация Stretched MetroCluster.

Эталонная конфигурация Stretched MetroCluster включает:

HA-пару контроллеров FAS32XX, один размещенный на сайте 1, и другой – на сайте 2.

Пару полок DS14MK4 на сайте 1 и сайте 2

Внимание: Для подробного рассмотрения конфигурации Stretched MetroCluster, смотрите главу 6

Stretched MetroCluster Considerations.

Конфигурация Stretch MetroCluster в вариантах Dual и Twin

Stretched MetroCluster поддерживает конфигурацию контроллеров dual MetroCluster с

использованием корпуса с одним контроллером, соединенным с другим таким же корпусом с

одним контроллером (single-head chassis) также как и конфигурацию twin MetroCluster, сходную с

dual MetroCluster, с контроллером A на локальном сайте, соединенного с контроллером A на

удаленном сайте, и контроллером B на локальном, соединенном с контроллером B на удаленном

сайте. Рисунки 5 и 6 показывают конфигурации dual и twin Stretch MetroCluster соответственно.

Рис. 5) dual MetroCluster.

13

Рис. 6) twin MetroCluster.

Топология Fabric-Attached MetroCluster (FMC)

Конфигурация, называемая Fabric-attached MetroCluster, предназначена для построения систем,

разнесенной на расстояние свыше 500 метров (вплоть до 160 км), причем используется

соединение двух узлов пары с помощью выделенных для этой цели четырех коммутаторов

Brocade или Cisco, в конфигурации dual-fabric для достижения максимальной надежности и

избыточности. Fabric-attached MetroCluster использует функцию SyncMirror для построения

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

хранилища на одном из сайтов. Целостность данных сохраняется, даже если данные расположены

на более чем одном aggregate.

Рисунок 7 показывает архитектуру Fabric-attached MetroCluster.

Рис. 7) Fabric-attached MetroCluster.

Внимание: Расстояние указывает реальную предельную длину кабелей между локальным и

удаленным сайтом. Не оценивайте расстояние «по прямой», так как в реальности,

фактически проложенное кабельное соединение между сайтами может быть не

прямым, и значительно длиннее, чем оцененное «на глаз», «по прямой».

Конфигурация Fabric-Attached MetroCluster

Рисунок 8 показывает пример типичного Fabric-attached MetroCluster в конфигурации из двух

одноконтроллерных шасси FAS62XX на каждом из двух сайтов, с подключенными дисковыми

полками DS14MK4-FC и коммутаторами Brocade 5100.

14

Рис. 8) Конфигурация Fabric-attached MetroCluster.

Эталонная конфигурация Fabric-attached MetroCluster включает:

HA-пару контроллеров FAS32XX, один размещенный на сайте 1, и другой – на сайте 2.

Две пары полок DS14MK4 на сайте 1 и сайте 2

4 Обзор решения vSphere VMware vCenter это инструмент централизованного администрирования кластера ESX®, который

помогает администраторам виртуальных машин выполнять основные действия с ними, такие как

создание VM, операции vMotion, DRS, и так далее. Он также играет важную роль для систем

VMware View™, vCloud®. Виртуальная инфраструктура VMware должна быть разработана исходя из

идеи максимальной доступности.

4.1 Обеспечение доступности vCenter Дизайн основывается на требовании высокой доступности сервиса, и должен гарантировать, что

заявленный уровень достижим.

15

Способ 1: Защита vCenter Virtual Machine с помощью VMware HA Cluster

В этом случае vCenter устанавливается в виртуальной машине внутри VMware HA cluster. В случае

отказа хост-сервера, виртуальная машина vCenter перезапускается на выжившем хосте ESX,

входящем в кластер HA. В таком варианте решения, работа виртуальной машины vCenter будет на

какое-то время прервана, поскольку VM должна быть перезапущена на другом хосте.

Рисунок 9 поясняет работу данного решения.

Рис. 9) VMware HA.

Способ 2: Установка vCenter в собственный кластер

Другим способом развертывания vCenter Server является помещение его в его собственный

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

Если система хранения, несущая на себе экземпляр кластера vCenter находится на сбойном сайте,

то необходимо выполнить процедуры NetApp CFOD recovery.

Для подробностей о том, как использовать Microsoft Cluster Service (MSCS), смотрите VMware KB.

Для подробностей об использовании Oracle® RAC, для Oracle Databases смотрите VMware RAC

Deployment Guide.

Способ 3: Защита vCenter с использованием VMware vCenter Heartbeat Solution

Поскольку VMware vCenter Server используется для управления множеством приложений

максимального уровня доступности, он также должен рассматриваться как приложение

16

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

высокую доступность сервера VMware vCenter Server. В этом нам может помочь VMware vCenter

Server Heartbeat.

VMware vCenter Server Heartbeat это решение обеспечения высокой доступности платформы

управления VMware vCenter. Архитектурно, vCenter Server Heartbeat это реализация модели active-

passive для клона vCenter Server, работающего на физических или виртуальных машинах.

Дополнительно к оборудованию сервера и сети vCenter Server Heartbeat наблюдает действующий

экземпляр vCenter Server, состояние его базы данных, и его нижележащей операционной системы.

В случае отказа узел, бывший в пассивном состоянии, активизируется, и vCenter Server Heartbeat

перезапускает сервис vCenter.

Переключение может осуществляться как через LAN, так и через WAN.

Для подробностей об установке и настройке VMware vCenter Server Heartbeat, смотрите документ

VMware vCenter Server Heartbeat.

Защищает VMware vCenter Server путем мониторинга работы его компонентов,

включая VMware License Server и плагины

Минимизирует простой критичных функций, таких как VMware vMotion и VMware DRS

Защищает производительность, функциональность уведомлений VMware vCenter

Server, и иные важные функции

Обеспечивает автоматическое переключение сервера VMware vCenter Server

Позволяет администраторам планировать периоды обслуживания и производить

ручное переключение на резервный сервер на этот период

Защищает и восстанавливает целостность базы VMware vCenter Server

Защищает критичные элементы системы, такие как конфигурация, inventory, и другую

информацию, хранящуюся в базе VMware vCenter Server, даже когда база установлена

на отдельном сервере

Рисунок 10 показывает конфигурацию vCenter Server Heartbeat, использованную для данного

решения. Основная и вторичная VM vCenter Server развернуты на различных серверах ESX на

разных сайтах, и используют раздельные датасторы на локальном для них контроллере NetApp в

конфигурации MetroCluster. Канал vCenter Server Heartbeat сконфигурирован на соединение через

межсайтовую сеть LAN.

17

Рис. 10) vCenter Heartbeat solution.

4.2 Реализация vSphere HA на NetApp MetroCluster

Обзор

vSphere HA обеспечивает высокую доступность для виртуальных машин, группируя VM и хосты,

размещенные в кластере. Хосты в кластере мониторятся и, в случае отказа, виртуальные машины с

отказавшего хоста, перезапускаются на хостах, оставшихся рабочими.

В решении NetApp MetroCluster solution for vSphere, механизм VMware vSphere HA обеспечивает

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

VM на оставшихся доступными хостах ESX.

Когда создан кластер HA, все хосты, в него включенные, участвуют в «выборах» главного хоста,

или «мастер-хоста». Каждый ведомый, или «slave»-хост посылает сетевые сигналы на мастер-хост,

так называемые network heartbeat. В свою очередь мастер-хост также рассылает heartbeats

членам кластера. Задача мастер-хоста определить, что «slave»-хост отказал, и рестартовать

запущенные на нем на момент отказа VM на других, доступных хостах. Slave-хосты мониторят

состояние своих VM и посылают сообщения на мастер-хост о любых изменениях их состояния.

Они также наблюдают за состоянием мастера, принимая от него heartbeats. Если мастер-хост

внезапно становится недоступным, то остальные хосты инициируют процедуру новых «выборов».

18

Архитектура HA в vSphere 5.0 была существенно изменена, и сейчас используются несколько

различных механизмов для определения отказа хоста или сетевой изоляции; в ранних версиях

network heartbeat был единственным механизмом для детектирования отказа. Продолжая

использовать network heartbeat, VMware добавила в работу HA дополнительный механизм:

datastore heartbeating. Datastore heartbeating используется мастер-хостом в случае, когда он не

может связаться с ведомым хостом через сеть management network. Используя datastore

heartbeating он может определить, действительно ли искомый хост отказал, или же просто

отрезан от сети.

Для подробного рассмотрения темы vSphere HA, смотрите соответствующий документ VMware:

vSphere Availability.

Рекомендуем

Вдобавок к механизмам heartbeat, NetApp рекомендует определить и добавить так называемый Isolation IP address в настройки vSphere HA. Это увеличит надежность определения ситуации сетевой изоляции.

4.3 Реализация VMware DRS на NetApp MetroCluster VMware DRS это функциональность, которая аггрегирует ресурсы хоста в кластере и может

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

VMware DRS вычисляет объемы потребных ресурсов CPU и памяти, а затем распределяет VM по

хостам кластера для равномерной их загрузки. Многие возможности VMware DRS используются

также и системой NetApp MetroCluster.

Используя правила «VM–host affinity» в VMware DRS, можно создавать логическое разделение

между сайтами A и B, таким образом, чтобы VM запускался на хосте на том же сайте, где

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

системы хранения их обслуживающий. Также VM–host affinity rules позволяют виртуальным

машинам оставаться локальными по отношению к системе хранения в случае отказов в сетевом

соединении между сайтами.

4.4 Реализация VMware Storage DRS на NetApp MetroCluster Функция VMware Storage DRS позволяет объединять датасторы в единый логический модуль

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

порог storage I/O control.

Storage I/O control включен по умолчанию на DRS-кластере с включенным Storage DRS. Storage I/O

control (SIOC) позволяет администратору управлять объемом операций ввода-вывода,

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

ввода-вывода для более важных машин, за счет ограничения мене важных.

Storage DRS использует Storage vMotion для миграции виртуальных машин на другие датасторы,

внутри кластера датасторов. При использовании системы NetApp MetroCluster крайне желательно,

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

VM исполняется на хосте на сайте A, то предпочтительно, чтобы она мигрировала по датасторам

только лишь сайта A. Если же это невозможно, например в результате потери всех датасторов

сайта A, то только тогда виртуальная машина могла бы перейти на датасторы сайта B, и

продолжить выполняться, пусть и с потерей части производительности за счет того, что операции

ввода-вывода в таком случае пойдут через межсайтовый линк.

19

NetApp рекомендует создавать кластер датасторов с учетом правил site affinity; это позволит

датастору с правилом site affinity к сайту A не перепутываться с датастором с site affinity к сайту B.

Рекомендуем

Вне зависимости от того, была ли VM создана заново, или мигрирована с помощью Storage vMotion, NetApp настоятельно рекомендует, чтобы все правила VMware DRS, определенные для этой виртуальной машины, были вручную обновлены соответствующим образом. Это позволяет установить для виртуальной машины правила affinity на уровне сайта, как для хоста, так и для датастора, и снизить оверхед для сети и хранилища.

5 Руководство по разработке архитектуры и внедрению

5.1 Конфигурирование NetApp Storage В случае полного отказа контроллера системы хранения и/или всех связанных с ним дисковых

полок, должна быть выполнена процедура ручного failover для системы MetroCluster. Когда опция

change_fsid установлена в OFF (на контроллерах под управлением Data ONTAP version 7.2.4 или

выше), после выполнения ручного MetroCluster failover UUID-ы зеркалированных LUN

сохраняются, и дополнительные шаги для распознавания томов VMFS на стороне ESX Server не

требуются. После того, как тома VMFS обнаружены и распознаны, VM могут быть включены

вручную.

Рекомендуем

Установите значение параметра cf.takeover.change_fsid в OFF. Эта опция поддерживается в Data ONTAP version 7.2.4 и новее.

На системе хранения NetApp FAS, работающей под управление Data ONTAP старее версии 7.2.4,

после выполнения ручного MetroCluster failover зеркалированные LUN-ы не сохраняют LUN UUID

исходных LUN. Когда такие LUN-ы несут на себе файловую систему VMFS-3, тома определяются

ESX Server 3.x как Snapshot™ LUN. Сходным образом, если RAW LUN, который был смаппирован

как RDM (Raw Device Mapping) реплицируется или зеркалируется средствами MetroCluster,

метаданные этого RDM должны быть пересозданы для того, чтобы соответствовать

реплицируемому или зеркалированному LUN. Для того чтобы хост ESX получил доступ к тому

VMFS на зеркалированном LUN-е, см. VMware KB 1001783.

Рис. 11) Установка параметра cf.takeover.change_fsid в OFF.

На контроллерах FAS должны быть лицензированы следующие опции:

cluster, cluster_remote, syncmirror_local

iSCSI, FCP и/или NFS

20

Установка и настройка MetroCluster и software-based disk ownership должны быть

проведены в соответствии с руководствами:

o High-Availability and MetroCluster Configuration Guide

o MetroCluster Design and Implementation Guide

На контроллерах FAS обоих сайтов, тома типа flexible должны быть созданы внутри

идентичных aggregate , для каждого из используемых типов датасторов ESX: VMFS (FC

и iSCSI) и NFS.

Рекомендуем

Virtual Storage Console for VMware vSphere это плагин к vCenter Server, который обеспечивает управление хранилищем виртуальных машин из среды VMware. NetApp рекомендует использовать NetApp Virtual Storage Console for vSphere для управления датасторами на системе хранения NetApp в среде VMware vSphere.

Рисунок 12 показывает схему физического и логического хранилища при установке NetApp

MetroCluster.

Рис. 12) Физическое и логическое конфигурирование хранилища на контроллерах NetApp FAS при

установке MetroCluster.

21

5.2 Конфигурирование VMware vSphere

Конфигурирование vSphere HA для NetApp MetroCluster

Следующие шаги помогут пользователю сконфигурировать настройки HA для существующего

кластера ESX.

1. Подключитесь к vCenter, используя vSphere Client.

2. Выберите вид Hosts and Clusters.

3. Щелкните правой клавишей мыши на существующем кластере и выберите «Edit Settings».

4. Выберите опцию «Turn On vSphere HA».

5. На левой панели выберите vSphere HA и убедитесь, что опция «Host Monitoring» выбрана.

6. Выберите disable для настроек Admission Control, так как основная цель решения это

обеспечение максимальной доступности, пусть и в определенный ущерб

производительности в случае отказа хоста.

7. Этот шаг опционален. Выберите «Advanced Options» для того, чтобы добавить Isolation

address указав параметр das.isolationaddress и его IP-адрес.

22

8. Приоритет рестарта VM может быть настроен в соответствии с вашими требованиями, по

умолчанию все виртуальные машины рестартуют с приоритетом «Medium».

9. Для настроек Host Isolation response NetApp рекомендует значение «Leave Powered On».

Рекомендуем

Использовав параметр реакции на Host Isolation как «Leave Powered On», вы можете устранить нежелательный простой виртуальных машин во время их рестарта в случае, когда отказ в сети управления не означает одновременного отказа в сети самой виртуальной машины.

Внимание: В среде iSCSI/NFS, в которой сеть управления (management network) коррелирует с

сетью IP storage network, хосту невозможно определить, когда он полностью

изолирован. В таких системах будет лучше изменить эту настройку на значение

«Shutdown», что позволит корректно выключить виртуальные машины, даже несмотря

на то, что уведомление о полной изоляции и не поступит. Это также устранит

проблему возникновения ситуации split-brain.

23

10. Настройки VM Monitoring могут быть настроены в соответствии с вашими потребностями.

11. В разделе Datastore Heartbeating выберите «Select any of the cluster datastores taking into

account my preferences».

12. Щелкните OK.

Конфигурирование VMware DRS Groups в vSphere 5 на NetApp MetroCluster

Приведенные ниже шаги помогут создать группу DRS для VM и хостов. Этот этап необходим для

конфигурирования правил.

1. Подключитесь к vCenter, используя vSphere Client.

24

2. В клиенте vSphere щелкните правой клавишей на кластере в панели inventory и выберите

Edit Settings.

3. Выберите закладку DRS Group Manager.

4. Создайте две virtual machine DRS groups, одну для локального, и одну для удаленного

сайта.

5. Добавьте VM соответствующих сайтов в эти группы.

6. Создайте две DRS-группы хостов (host DRS groups), одну для локального, и одну для

удаленного сайта.

7. Добавьте хосты в соответствующие им группы.

Конфигурирование DRS Rules в vSphere 5 на NetApp MetroCluster

Следующие шаги помогут создать правило DRS на сайтах A и B.

1. В клиенте vSphere, щелкните правой клавишей на кластере в inventory и выберите Edit

Settings.

2. Выберите закладку Rules.

3. Щелкните Add.

4. В диалоге Rule укажите имя создаваемого правила.

5. В меню Type, укажите Virtual Machines to Hosts.

6. Выберите virtual machine DRS group и host DRS group для которых будет применяться

создаваемое правило.

25

7. Убедитесь, что VM и host DRS groups, созданные на сайте A, выбраны для правила,

назначаемого сайту A.

8. Выберите спецификацию «Should run on hosts in group».

9. Повторите шаги с 3 по 7 для добавления другого аналогичного правила на сайте B.

10. Щелкните OK.

Рекомендуем

NetApp настоятельно рекомендует определять правило «Should run on hosts in group» вместо «Must run on hosts in group». В случае отказа хоста на сайте A, VM сайта A потребуется рестартовать на хосте сайта B с использованием vSphere HA, но соответствующее правило не позволяет HA рестартовать VMs на сайте B, так как задано «жесткое» правило. Предлагаемое выше правило, это «мягкое» правило, которое может быть нарушено в случае работы HA, и позволяет выбрать доступность, вместо производительности.

Внимание: Вы можете создать действие (event), основанное на уведомление о событии (alarm),

которое случится, когда VM нарушит правило VM-Host affinity rule. В клиенте vSphere

Client, добавьте новое уведомление о событии виртуальной машины, и выберите «VM

is violating VM-Host Affinity Rule» как триггер события. Для подробного рассмотрения

темы создания и редактирования уведомлений о событиях (alarms), смотрите

руководство vSphere Monitoring and Performance.

Рисунок 13 показывает, как установить правило DRS.

Рис. 13) Правила DRS.

26

Создание Datastore Cluster

Следующие шаги помогут создать кластер датасторов.

1. Подключитесь к vCenter используя vSphere Client.

2. В группе Datastores and Datastore Clusters в vSphere Client inventory, щелкните правой

клавишей на объекте datacenter и выберите New Datastore Cluster.

3. Дайте имя кластеру датасторов, и убедитесь, что опция «Turn on Storage DRS» установлена.

4. Для SDRS automation level, проверьте, что установлено «No Automation (Manual Mode)».

Рекомендуем

NetApp рекомендует использовать Storage DRS в ручном режиме, что позволит администратору самостоятельно решать и управлять тем, когда должна осуществляться миграция.

5. Убедитесь, что установка «Enable I/O metric for SDRS recommendations» выбрана; величина

может быть оставлена в значении по умолчанию.

6. Выберите соответствующий кластер хостов.

7. На экране Select Datastores убедитесь, что выбраны только датасторы сайта A; таким

образом, они будут частью кластера датасторов сайта A.

8. Повторите шаги с 1 по 6 для создания кластера датасторов сайта B, и убедитесь, что

выбраны только датасторы сайта B.

27

6 Ситуации использования MetroCluster

6.1 Отказ одного из путей к системе хранения В этом сценарии развития событий, если такие компоненты, как порт HBA, сетевой порт, порт

коммутатора, или кабель FC/Ethernet выходит из строя, соответствующий путь к системе хранения

помечается как неработающий («dead») хостом ESX. Если сконфигурировано несколько путей к

системе хранения для обеспечения отказоустойчивости и надежности на уровне порта

HBA/сети/коммутатора, ESX в идеальном случае сама производит замену пути на исправный.

Виртуальные машины продолжают работать в обычном режиме, так как данные идут по

оставшемуся, резервному пути к системе хранения.

В системе MetroCluster в этом сценарии никаких действий не производится, все датасторы

остаются доступны соответствующим им сайтам и хостам.

Рекомендуем

В системах, использующих тома, подключенные по NFS/iSCSI, NetApp рекомендует иметь как минимум два сетевых линка, сконфигурированных на порт vmkernel стандартного vSwitch и столько же в портгруппе, где интерфейс NFS vmkernel смаплен на distributed vSwitch. NIC teaming может быть сконфигурирован как active-active или как active-standby. Кроме того, для iSCSI LUNs, требуется сконфигурировать multipathing интерфейсов vmkernel с адаптерами iSCSI. Для подробностей смотрите документацию по vSphere.

Рекомендуем

В системах, использующих Fibre Channel LUNs, NetApp рекомендует иметь, по меньшей мере, два HBA, что гарантирует отказоустойчивость на уровне HBA/port. NetApp также рекомендует использовать зонирование по принципу «single initiator to single target». Следует использовать Virtual Storage Console (VSC) для корректной установки политик multipathing.

28

6.2 Отказ хоста ESX Рисунок 14 показывает случай отказа хоста ESX.

Рис. 14) Отказ хоста ESX.

В этом сценарии, если хост ESX выходит из строя, главный узел (master node) кластера VMware HA

определяет факт выхода из строя по тому факту, что он перестает получать сигналы network

heartbeats. Для определения того факта, что хост в самом деле перестал работать целиком, а не,

например, случился обрыв сетевого соединения, master node наблюдает также за операциями

datastore heartbeats и, наконец, если и их не обнаружено, выполняется последняя проверка,

путем пингования искомого хоста в сети управления (management network). Если все эти попытки

неуспешны, то master node объявляет о том, что соответствующий хост вышел из строя, и все

виртуальные машины, запущенные ранее на этом хосте, перезагружаются и запускаются на

оставшихся хостах кластера.

Может получиться так, что виртуальные машины могут стартовать на хосте ESX на другом сайте,

чем тот, где расположены их дисковые ресурсы. Однако определение правил DRS affinity rules

скорректирует это, если подобные правила окажутся нарушены, путем перемещения VM назад, на

оставшиеся доступными хосты соответствующего сайта. В случае, если DRS переведен в ручной

режим, NetApp рекомендует запустить DRS и применить его рекомендации по правильному

размещению виртуальных машин.

В системе MetroCluster в этом сценарии никаких действий не производится, все датасторы

остаются доступны соответствующим им сайтам и хостам.

29

6.3 Изоляция хоста ESX Рисунок 15 показывает случай изоляции хоста ESX от основной системы.

Рис. 15) Изоляция хоста ESX.

В этом сценарии развития событий, если сеть управления (management network) на хосте ESX

недоступна, master node кластера VMware HA перестанет принимать network heartbeats от

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

определения действительно ли хост вышел из строя, или же возникла только сетевая изоляция от

мастер-узла, он будет наблюдать за datastore heartbeat. Если обмен с датастором наблюдается, то

master node будет считать, что произошла потеря сетевого соединения, а хост жив. В зависимости

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

остановлены все виртуальные машины на нем, или же, напротив, все VM могут быть оставлены в

рабочем состоянии. Интервал определения изоляции по умолчанию – 30 минут.

В системе MetroCluster в этом сценарии никаких действий не производится, все датасторы

остаются доступны соответствующим им сайтам и хостам.

6.4 Отказ сервера vCenter В этом сценарии, если сервис vCenter недоступен, единственный сервис, который окажется

недоступен вместе с ним, это функциональность DRS, такие операции, как балансировка нагрузки

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

машины продолжат работать без перебоев на соответствующих им хостах, пока не случится отказ

соответствующего хоста, тогда VMware HA инициирует перезапуск VM на оставшемся доступном

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

другого сайта, по отношении к используемым дисковым ресурсам, и это может вести к снижению

производительности и росту latency дисковых операций. После восстановления

работоспособности vCenter, включившийся DRS исправит ситуацию в соответствии с host-VM

affinity rule.

В системе MetroCluster в этом сценарии никаких действий не производится, все датасторы

остаются доступны соответствующим им сайтам и хостам.

30

6.5 Отказ межкоммутаторного линка

Отказ межкоммутаторного линка в сети управления (Management Network)

Рисунок 16 показывает случай отказа межкоммутаторного линка в сети управления (management

network).

Рис. 16) Отказ межкоммутаторного линка в сети управления.

В этом варианте развития событий, если межсайтовое соединение в сети управления нарушено,

хост ESX на сайте A не сможет связаться с хостами ESX на другом сайте. Это ведет к разрыву

сетевой связности системы, так как хосты ESX соответствующего сайта не могут посылать network

heartbeats на master node VMware HA-кластера. Это приведет к тому, что сеть управления

разделится на два сегмента, с master node на каждой из них, которые защитят VM от отказа хостов

на соответствующем им сайте.

В системе MetroCluster в этом сценарии никаких действий не производится, все виртуальные

машины остаются в запущенном состоянии, все датасторы остаются доступны соответствующим

им сайтам и хостам.

31

Отказ межкоммутаторного линка в сети хранения (Storage Network)

Рисунок 17 показывает случай отказа межкоммутаторного линка в сети передачи данных.

Рис. 17) Отказ межкоммутаторного линка в сети передачи данных.

В этом сценарии, если межсайтовый линк (ISL) сети передачи данных перестает работать, хосты

сайта A теряют доступ к томам/LUN-ам системы хранения на сайте B и наоборот. Правила VMware

DRS заданы для хостов и их ресурсов хранения таким образом, чтобы виртуальные машины не

мигрировали на хосты, находящиеся на ином, чем их дисковый ресурс, сайте, поэтому в

описанном сценарии VM и их дисковые ресурсы остаются на одном сайте, и доступны даже при

разрыве связности сети хранения между сайтами.

В системе MetroCluster в этом сценарии никаких действий не производится, все виртуальные

машины остаются в запущенном состоянии, все датасторы остаются доступны соответствующим

им сайтам и хостам.

Если по какой-либо причине правила (affinity rule) нарушаются, и виртуальная машина на сайте A

использует ресурсы хранения (тома или LUN-ы) на сайте B, виртуальная машина будет продолжать

получать данные с него через ISL. Если и ISL выходит из строя, то VM на сайте A, работающая с

дисками сайта B, не сможет писать на диски. В этом случае, однако, VMware HA не сработает, так

32

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

машины следует вручную остановить и перезапустить на соответствующем им сайте, устраняя

«кросс-сайтные» связи между VM и их дисками.

Отказ межкоммутаторного линка между контроллерами NetApp Fabric MetroCluster

Рисунок 18 показывает случай отказа межкоммутаторного линка между контроллерами NetApp

Fabric MetroCluster.

Рис. 18) Отказ межкоммутаторного линка между контроллерами NetApp Fabric MetroCluster.

В этом варианте развития событий, если линк ISL между контроллерами в конфигурации Fabric

MetroCluster перестает работать, автоматический файловер контроллеров отключается, но

дисковые тома/LUN-ы на соответствующих контроллерах остаются доступны своим хостам на их

сайтах.

Скриншот ниже взят с консоли, когда зарегистрирован обрыв межсайтового линка, в данном

случае вы видите вывод команды cf status.

33

6.6 Отказ всех ISL или полной потери датацентра Рисунок 19 показывает отказ всех ISL (interswitch links, межкоммутаторных линков) разом.

Figure 19) Отказ всех ISL разом.

В этом сценарии развития событий, все линки ISL между сайтами разорваны и оба сайта

изолированы друг от друга. Как обсуждалось в сценарии, рассмотренном ранее, отказ ISL сети

управления (management network) и сети хранения (storage network), не влияет на работу самих

виртуальных машин, даже при полном разрыве всех ISL.

После того, как хосты ESX оказались разделены между сайтами, агент vSphere HA проверит

datastore heartbeats и, на каждом из сайтов, локальные хосты ESX смогут послать datastore

34

heartbeats на используемые ими тома/LUN. Хосты на сайте A станут считать, что другие хосты,

расположенные на сайте B вышли из строя, так как с ними нет ни сетевого обмена, ни сигналов

datastore heartbeats. vSphere HA на сайте A будет пытаться перезапустить виртуальные машины с

сайта B, которые рассматриваются переставшими работать, так как датасторы сайта B стали

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

развиваться и на сайте B.

NetApp рекомендует определить, что какая-либо виртуальная машина нарушает правила DRS.

Виртуальная машина, запущенная с удаленного сайта, перейдет в остановленное состояние, так

как не сможет связаться с датастором удаленного сайта, и vSphere HA перезапустит такую VM на

локальном сайте. После того, как ISL вернутся в работу, виртуальные машины, которые были

запущены на удаленном сайте, будут остановлены, так как невозможно существование в системе

двух экземпляров VM с идентичными MAC-адресами.

6.7 Отказ контроллера системы хранения Рисунок 20 показывает случай отказа контроллера системы хранения.

Рис. 20) Отказ контроллера системы хранения.

В этом сценарии развития событий, если контроллер системы хранения отказывает на одном из

сайтов, все сервисы контроллера на отказавшем сайте будут переведены на контроллер на другом

35

сайте. Работающий контроллер начнет обслуживать данные с дисковых полок отказавшего сайта,

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

ESX на сайте с отказом потеряют доступ к отказавшему контроллеру и инициируют переключение

на путь к контроллеру, оставшемуся рабочим., доступ к которому будет осуществляться через ISL

коммутаторов сети хранения.

Виртуальные машины продолжат свою работу в прежнем режиме, так как сохранится рабочий

второй путь к тем же самым томам /LUN-ам. Дополнительно, vSphere HA не предпримет никаких

действий, так как master node в кластере по-прежнему будет получать network heartbeats.

Возможна более сложная ситуация, при которой отказ контроллера на сайте повлечет также отказ

и дисков, дисковых полок и дисковых ресурсов соответствующего сайта. В этой ситуации,

необходимо провести ручное переключение на второй контроллер с помощью процедуры

controller failover on demand (CFOD); Это переведет все сервисы и ресурсы с отказавшего

контроллера на оставшийся рабочим контроллер, а также plexes или зеркальные aggregates,

работавшие в режиме read-only станут доступны на запись. Это редкий случай развития событий в

датацентре, когда отказывают одновременно и контроллер, и дисковые полки разом, но такая

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

целиком, или отказ на уровне backend-коммутатора может приводить к такой ситуации.

После того, как отказавший контроллер возвращается в рабочее состояние, необходимо провести

операцию failback, или возврата перенесенных ресурсов и сервисов на исходный контроллер,

после того, как все дисковые структуры восстановят зеркальность копий. В ситуации, когда

автоматический failback отключен, оператору необходимо выполнить ручную операцию failback из

командной строки контроллера.

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

падение производительности, так как доступ к данным производится к удаленному дисковому

разделу через межсайтовый линк.

Скриншот консоли, приведенный ниже, показывает момент, когда контроллер сайта A отключился

по причине kernel panic, дисковые полки сайта A остались доступны через контроллер сайта B.

Подобный сценарий можно использовать, например, при плановом обслуживании и обновлении

OS и firmware контроллера. В процессе обновления микропрограммы прошивки контроллера,

контроллер необходимо перезагрузить. Такие простои в работе при плановом обслуживании

являются серьезной проблемой для систем Tier 1 и 2. В системах хранения NetApp FAS,

работающих в режиме HA-пары, даже если необходима перезагрузка контроллера (это может

быть вызвано разными причинами, такими как обновление прошивки и OS, изменения в

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

контроллер, который возьмет на себя все сервисы отключаемого. После того, как контроллер

вернется в онлайн, процесс обратного переноса ресурсов (failback) запускается с рабочего

контроллера, что возвращает сервисы на оригинальный контроллер.

36

Приведенный ниже скриншот взят в момент, когда на сайте B контроллер обновлял прошивку, и

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

операций на контроллер сайта A.

6.8 Отказ дисковой полки Рисунок 21 показывает случай отказа дисковой полки.

Рис. 21) Отказ дисковой полки.

В рассматриваемой ситуации, если отказ произошел на дисковой полке сайта A, несущей

тома/LUN-ы, используемые машинами сайта A (выше на рисунке показан такой отказ одной

полки), тогда соответствующая дисковая полка сайта B, где хранится зеркальная копия данных

отказавшей полки, переводится в режим read-write и становится доступной хостам ESX. В системе

37

MetroCluster в сценарии, когда возник отказ одной из половин зеркальной копии данных, никаких

действий не производится, все виртуальные машины остаются в запущенном состоянии, все

датасторы остаются доступны соответствующим им сайтам и хостам.

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

падение производительности, так как доступ к данным производится к удаленному дисковому

разделу через межсайтовый линк.

6.9 Потеря сайта целиком Рисунок 22 показывает случай потери одного сайта полностью.

Рис. 22) Потеря целиком сайта.

В данном сценарии развития событий, если случился полный отказ сайта A, хосты ESX на сайте B

перестанут получать сигнал heartbeat с хостов ESX сайта A, так как они окажутся отключенными, то

хосты ESX сайта B будут сперва ожидать возобновление сигналов heartbeats. Если heartbeats от

датасторов не возобновляются, хосты ESX сайта A будут объявлены потерянными, и будет сделана

попытка перезапустить виртуальные машины, базировавшиеся на сайте A, на хостах сайта B. Во

время этого периода, пользователи могут инициировать процесс controller failure on demand, что

восстановит все сервисы хранения сайта A на сайте B. После того, как тома и LUN-ы сайта A станут

38

доступны на сайте B, будет возможно получить доступ к виртуальным машинам сайта A и

перезапустить их.

Рекомендуем

Процесс controller failover on demand следует запустить не позднее 30 минут с момента потери сайта, потому что vSphere HA прекратит попытки перезапустить VM с отказавшего сайта через 30 минут с момента отказа.

Приведенный скриншот консоли взят во время события полного отказа сайта B. Контроллер

системы хранения на сайте A перехватил все сервисы отказавшего контроллера в ходе

выполненного ручной «имитации отказа» (controller failure on demand, CFOD) с консоли

контроллера на сайте A.

7 Комбинированные тесты (Отказы на обоих сайтах) Таблица 3) Комбинированный тест 1: Отказ хост-сервера ESX на сайте 1 и контроллера на сайте 2.

Tests Performed 1. Отключим питание всех хостов ESX на сайте 1. 2. Отключим питание контроллера сайта 2.

Expected Results Контроллер на сайте 1 автоматически перехватывает задачи и ресурсы отключенного контроллера.

Все VM, бывшие на сайте 1, рестартуют на сайте 2.

Actual Results Фактический результат соответствует ожидаемому. Тест проходит как и следует.

MetroCluster Behavior Контроллер-партнер с сайта 1 выполняет автоматический перехват задач и ресурсов.

VMware HA Behavior VM, работавшие на отказавшем хосте, автоматически перезапускаются на рабочем узле.

39

Таблица 4) Комбинированный тест 2: Отказ дисковых полок на обоих сайтах.

Действия 1. Отключим питание дискового пула 0 на сайте 1. 2. Отключим питание дискового пула 0 на сайте 2.

Ожидаемый результат VM не должны заметить каких-либо изменений и продолжают работать штатным образом.

VM в DRS-группе не мигрируют. Фактический результат Фактический результат соответствует ожидаемому. Тест проходит как

и следует.

Поведение MetroCluster Срабатывания MetroCluster не происходит. Данные обслуживаются с зеркальной копии.

Поведение VMware HA Срабатывания HA не происходит

Влияние на доступность Нет.

Таблица 5) Комбинированный тест 3: Отказ контроллера и дисковой полки.

Действия 1. Отключим питание контроллера сайта 1. 2. Отключим питание дискового пула 0 на сайте 2.

Ожидаемый результат VM не должны заметить каких-либо изменений и продолжают работать штатным образом.

VM в DRS-группе не мигрируют. Фактический результат Фактический результат соответствует ожидаемому. Тест проходит как

и следует.

Поведение MetroCluster Оставшийся контроллер выполняет автоматический перехват задач и ресурсов.

Поведение VMware HA Срабатывания HA не происходит.

Влияние на доступность Нет.

8 Выводы Обилие решений высокой доступности присутствующее на рынке делает непростым процесс

выбора оптимального варианта для обеспечения непрерывности вашего бизнеса, того, который

поможет интегрироваться в ваше бизнес-решение и удовлетворить всем его требованиям. Этот

документ представляет консолидированное решение с использованием NetApp MetroCluster для

VMware vSphere HA, лучшее в своем классе промышленное решение непрерывности бизнеса.

Это решение предлагает универсальный подход к удовлетворению бизнес-требований по

обеспечению постоянной доступности, и обеспечивает реализацию требований по обеспечению

заданных бизнесом параметров RPO и RTO. Данное решение позволяет устранить как плановые,

так и внеплановые простои и периоды недоступности, и может работать при любых сценариях

отказов. Ключевой особенностью решения является плотная интеграция между VMware и NetApp,

и их High Available и Fault Tolerance опциями. Это упрощает внедрение и обслуживание

бескомпромиссного катастрофоустойчивого решения с максимальным уровнем устойчивости и

экономической эффективности.

40

Об авторах Ashish Nainwal и Santhosh Devaraju – инженеры технического маркетинга в группе NetApp

Infrastructure and Cloud Enablement group, они занимаются вопросами решениями непрерывности

бизнеса, использующими продукты NetApp.

История изменений Версия Дата публикации Содержание изменений

1.0 Февраль 2013 Исходная версия