OnCommand Shift туда и обратно

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

Уже некоторое время существует решение для ускоренной миграции из VMware в Hyper-V,   разработанное с участием NetApp - MAT4Shift. Основная сложность в миграции - необходимость конвертировать диск с данными, а это требует существенных затрат времени (и ресурсов СХД). Если использовать только MAT (Microsoft Automation Toolkit), миграция 1ТБ диска может занять несколько часов. MAT4Shift за счет использования технологии FlexClone в СХД (да-да, конечно требуется не только утилита, но и СХД NetApp FAS) позволяет радикально сократить время миграции. Скорость возрастает, так как фактически не происходит конвертации данных, изменяются только заголовки и метаданные, после этого VMDK “превращается” в VHDX диск. Утилита также удаляет vmware tools и вносит необходимые изменения в настройки сетевых интерфейсов и VLAN. Время миграции виртуальной машины из VMware в Hyper-V сокращается от нескольких часов до всего нескольких минут.

Несмотря на достигнутые результаты, хочется еще, как минимум, конвертировать VM и из Hyper-V в VMware. Чтобы закрыть вопрос миграции в гетерогенной виртуальной среде, NetApp выпустил отдельный продукт - NetApp OnCommand Shift. Именно благодаря ему можно без лишних затрат времени и при минимальном участии администраторов производить миграции VM из VMware в Hyper-V и наоборот.

Как же осуществляется миграция?

• ПО собирает данные о настройках виртуальной машины, которые необходимо будет воспроизвести после миграции.
• Создается клон виртуальной машины (технология FlexClone в СХД NetApp FAS). Независимо от размера диска VM, процесс клонирования происходит практически мгновенно.
• Происходит автоматизированное удаление утилит (VMware tools или Hyper-V Integration tools).
• Дальше некоторое время требуется для настоящей магии - замены метаданных и заголовков в снимке диска (VMDK/VHDX). Сами данные не изменяются, а так как объем метаданных сравнительно небольшой, время конвертации диска мало зависит от размера исходных данных.
• Если необходимо, устанавливается новый набор утилит.
• Переносятся настройки, сохраненные на первом этапе. После миграции будут сохранены все сетевые настройки, подключения к VLAN и названия сетевых подключений. 

  

Если нужно перенести не одну, а сразу несколько VM, автоматизировать процесс поможет модуль OnCommand Shift PowerShell. 

Еще одним преимуществом OnCommand Shift является то, что у нас нет необходимости в двукратном увеличении дискового пространства - данные в новом формате занимают те же самые блоки, что и данные до миграции. Это может быть достаточно важно при планировании массовых миграций.

Поддерживаемые гипервизоры: VMware ESXi 5.0 и выше, Microsoft Windows Server 2008R2 Hyper-V и выше. На NetApp должна быть установлена Clustered Data ONTAP 8.2 и выше, также потребуется создать виртуальную машину (требования самые скромные), в которой и будет выполняться OnCommand Shift. 

Да, все это бесплатно, но работает только для владельцев СХД NetApp - остальным придется либо тратить на миграцию больше времени, либо искать альтернативы (про которые я, впрочем, пока не слышал).

Понравился пост? Подпишись через RSS, Email или twitter!

HP StoreOnce VSA - теперь и бесплатно!

Как получить бесплатную систему дедубликации для хранения резервных копий совершенно бесплатно? Сейчас — запросто! HP раздает всем желающим лицензии на 1ТБ StoreOnce VSA абсолютно бесплатно, то есть даром! Выпущены версии для всех наиболее распространенных гипервизоров: VMware, Hyper-V и KVM.

Уже довольно давно (я и про это упоминал здесь) можно получить в совершенно бесплатное использование лицензию на 1ТБ дискового пространства HP StoreVirtual VSA. Это отличный старт для экспериментов, для пилотных инсталляций, когда еще нет больших требований к объему дисков. Бесплатный 1ТБ StoreVirtual VSA вполне может даже стать неплохой основой своего рода «микро-конвергентного» решения для филиала, где стоит задача минимизировать простой при сбоях, но нет возможности строить серьезное решение. Теперь программную систему хранения данных можно дополнить программной системой хранения резервных копий.

Минимальные требования для установки: 2 x vCPU (2.2GHz), 16GB vRAM. Ничего запредельного.

Поддерживаются все популярные программы резервного копирования. Детальный список можно найти здесь: www.hp.com/go/ebs Думаю, что при некотором желании можно запустить и что-то типа бесплатной Bacula — StoreOnce можно настроить как VTL, NFS, CIFS или Catalist target.

Обратите внимание, что никто не запрещает использовать бесплатную лицензию в продуктивной среде — это плюс. Важно помнить, что никакой технической поддержки ждать не стоит — она предназначается для владельцев коммерческих лицензий. Еще одно, последнее ограничение бесплатной версии — нельзя расширить объем свыше 1ТБ, но можно без проблем «проапгрейдить» систему до коммерческой лицензии и получить 4ТБ, 10ТБ или даже 50ТБ. Апгрейд проходит совершенно прозрачно для уже сохраненных данных — они продолжают быть доступны для восстановления при аварии. А если и этого мало, то пора переходить на аппаратную реализацию, где объемы могут достигать сотни ТБ, а скорости десятков ТБ в час.

Важно заметить, что 1ТБ это «честный» объем — после дедубликации, а так как система предназначена для хранения бэкапов, то фактический полезный объем, при степени дедубликации 1:20, составит уже 20ТБ.

Остальной функционал полной версии доступен и для бесплатных пользователей. Среди интересных возможностей — шифрование данные и поддержка репликации (можно например установить в филиале, если на центральной площадке уже используется StoreOnce).

Но, как это часто бывает, бесплатный сыр встречается редко. Ровно через три года карета Золушки, как в сказке, превратится в самую обычную тыкву! Бесплатная лицензия выдается сроком на 3 года и, когда лицензия заканчивается, все резервные копии продолжают оставаться доступными — можно реплицировать их на другую систему, можно восстанавливать данные, но записать новые уже нельзя. По окончании срока действия лицензии, StoreOnce VSA перейдет в режим «только для чтения». Спасти вас может коммерческая лицензия — после покупки и активации, продолжайте полноценное использование продукта. Впрочем, если 3 года система проработала успешно в продуктиве, то пора и полноценную лицензию покупать. А наиболее экономные пользователи найдут способ получить свежую бесплатную лицензию (если они еще будут раздаваться) и реплицировать данные из старой бесплатной VSA на новую. Для наших админов нет нерешаемых задач! Но нужно быть готовыми к такому развитию событий.

Скачать образ виртуальной машины (и зарегистрировать лицензию) можно здесь: www.hp.com/go/FreeBackup

Понравился пост? Подпишись через RSS, Email или twitter!

Еще раз про vVol - теперь для владельцев NetApp

Про vVol я уже писал здесь. На прошлой неделе стали доступны для загрузки Virtual Storage Console 6.0 и VASA Provider 6.0 for Clustered Data ONTAP. Это два необходимых компонента для начала работы с virtual volumes в vSphere 6.0 и Data ONTAP.

Virtual Storage Console крайне полезный плагин vCenter, который пригодится любому владельцу СХД NetApp, независимо от планов на использование vSphere 6 или virtual volumes. Я буду очень удивлен, если кто-то из администраторов еще не использует его — решение подавляющего большинства задач управления системой хранения упрощается в разы. 

VASA Provider это отдельная виртуальная машина (на базе Linux), которая и реализует двустороннее взаимодействие между vCenter Server и системой хранения.

Конечно нужно помнить, что виртуальную машину с VASA Provider нельзя размещать на vVol — сервер ESXi не сможет начать работать с vVol до тех пор, пока не будет запущен VASA Provider. Это в равной степени относится и к vCenter — для него тоже нужно использовать только обычный датастор.

Кроме того, бакап и еще раз бэкап! Потеря как базы данных, так и самого VASA Provider может запросто прикончить вашу сверхсовременную и технологичную инфраструктуру. Новые технологии несут нам не только счастье и радость, но и лишние заботы! Хотя для сложной инфраструктуры польза от использования vVol конечно есть — администратор получает очень гибкий инструмент для автоматизированного управления как на уровне отдельной виртуальной машины, так и на уровне групп.

Да, на текущий момент в матрице совместимости vSphere нет поддержки vVols в Data ONTAP 8.3 - пока только 8.2.3.

Мне лично больше нравится реализация VASA  Provider в HP 3Par — он работает не в отдельной виртуальной машине, а “внутри” системы хранения. Такой вариант мне кажется более удобным для пользователя, хотя до первой проблемы однозначно не скажешь! :) 

Понравился пост? Подпишись через RSS, Email или twitter!

Пора прорубать окна в контейнерах!

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

Многие наверное еще осенью слышали обещание Microsoft о грядущей поддержке Docker в новой версии Windows. И вот, пришла пора узнать подробности — вчера в Microsoft было сразу два анонса, имеющих непосредственное отношение к контейнерам.

Во-первых, это контейнеры Hyper-V. Благодаря интеграции с Docker, код, работающий в рамках одного контейнера, изолирован от процессов в операционной системы и процессов в других контейнеров. Hyper-V контейнеры можно будет развертывать как обычный Windows Server контейнер, так и в виде виртуальной машины Hyper-V — довольно интересная опция, которая может стать аргументом для принятия технологии корпоративным сектором. Управление обоими видами контейнеров осуществляется через Docker.

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

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

• уменьшение размера VHD-файла на 93%
• потребуется на 92% меньше патчей — (возможно речь идет о потенциальном количестве, за счет сокращения числа устанавливаемых сервисов)
• снижение числа перезагрузок на 80%

Чтобы все это достичь пришлось избавиться от GUI, отказаться от поддержки 32 битных приложений, MSI и от целого ряда других, стандартных для Server Core, компонентов. В том числе, нет поддержи локальной авторизации и RDP — все управление осуществляется только удаленно через PowerShell и WMI. Для обеспечения удобства управления нас ждут изменения в PowerShell — будут поддерживаться, например, передача файлов и удаленная отладка. Кроме того, планируется представить новые web-утилиты как замену локальных инструментов управления.

Так как Nano Server это именно переработанная версия Windows Server, то полная совместимость с API (в рамках оставшихся в Nano Server компонентов) упростит разработку нового ПО. Visual Studio будет полностью поддерживаться, так что экосистема не должна оказаться пустой. 

Например, в Chef плотно занимаются интеграцией с Nano Server, заявляя о том, что новая платформа (Nano Server плюс автоматизация от Chef) станет отличным решением для разработки в стиле DevOps.

Само собой, Nano Server будет и отличной базой для развертывания на нем контейнеров Windows Server и Hyper-V контейнеров. В мире Linux аналог уже доступен — Red Hat Enterprise Linux Atomic Host.

Уже в конце апреля, на конференции Build 2015, можно будет увидеть контейнеры Windows «живьем».

Источник:

http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx

Понравился пост? Подпишись через RSS, Email или twitter!

SCSI Decoder

Нашел в почте письмо от RedHat про полезную утилиту - SCSI Decoder.

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

Справа увидим список найденных ошибок, а после нажатия "DECODE" получим не только детальное описание ошибки, но и ссылку на возможное решение проблемы. В данном примере это будет:

SCSI error: return code = 0x08000002 - Illegal Request
* We are getting errors only for first LUN coming from Storage * This LUN is the command device coming from Hitachi Array * Error snippet from messages file: ~~~ kernel: sd 5:0:0:0: SCSI error: r
https://access.redhat.com/solutions/369363

Вот и все! С высокой вероятностью мы получим решение проблемы в пару кликов. И не забываем, что ошибки SCSI это не только SCSI диски (которые поди найди сейчас), но и например СХД, подключенные по FC.

Для доступа к декодеру потребуется логин на Red Hat Customer Portal, но никакие подписки и прочие затратные мероприятия от вас не требуются.

С интересом потратил часть вчерашнего вечера на поиск в почте писем с вопросами про ошибки и скармливание этих ошибок в декодер - когда-то можно было много времени сэкономить на этом!

Понравился пост? Подпишись через RSS, Email или twitter!

Data Ontap 8.3 GA - новости и изменения

Я совсем недавно уже писал про одно из нововведений в cDOT 8.3 - поддержку MetroCluster, но считаю нужным упомянуть и другие возможности, которые пользователи получат в новой версии. Список изменений весьма обширен - более 40 из 90 страниц отведены перечислению именно новых возможностей.

Что первым бросается в глаза? Конечно система управления - теперь System Manager интегрирован в Data ONTAP! Больше не нужно устанавливать на компьютер приложение, мучаться с версиями Java - достаточно открыть браузер, набрать адрес и после этого мы получаем полноценную систему управления (на HTML5). Уверен, это это придется по душе очень многим админам!

Еще одна приятная возможность для администратора - можно сильно упростить жизнь за счет использования 'network subnet'. Вместо того, чтобы назначать каждому логическому интерфейсу (LIF) конкретный адрес, администратор назначает пул адресов для широковещательного домена (broadcast domain). А уже при создании LIF, ему присваивается адрес из пула. Такой подход может быть крайне удобен в больших и часто меняющихся инфраструктурах. 

Использование IP Spaces для изоляции SVM - еще одна возможность для построения развитой инфраструктуры. IP Spaces позволяют получать доступ к кластеру из несвязанных подсетей - даже если клиенты имеют одинаковые адреса:

В данном случае, клиенты в IPSpace A физически отделены от клиентов IPSpace B, но работают с одним кластером. Эта возможность актуальна для компаний, которые предоставляют системы NetApp в аренду "по кусочкам".

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

В больших конфигурациях, можно получить слишком большое количество путей от хоста до LUN - это является проблемой управления, но может влиять и на производительность. Для того, чтобы поддержать число путей в рамках разумных границ, теперь используется технология Selective LUN Mapping (SLM) - хост видит только нужные пути до системы, а лишние спрятаны (но могут быть включены при необходимости. Коллеги писали об этом совсем недавно (есть примеры команд).

Автоматизация процесса обновления ПО. Еще одна "крутая фишка". В самых разных ситуациях я сталкивался с тем, что система работает, на ней наблюдаются какие-то проблемы (не критичные, но малоприятные). Спрашиваешь, а почему не обновить на новый микрокод - там же есть исправление как раз вашей проблемы? "Мы бы с удовольствием, но для нас очень проблематично выделить время на обновление и столкнуться с угрозой остановки сервиса. Кроме того, это очень сложная процедура." И это длится год за годом!  Теперь такая проблема больше не должна волновать - администратору достаточно всего трех команд, чтобы запустить процесс обновления:

cluster image package get
cluster image validate
cluster image update 

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

cluster image show-update-progress

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

Обновлять систему стало легко, но так ли просто обновить несколько кластеров сразу на нескольких площадках, объединенных в единую инфраструктуру? Далеко не факт. Но если мы используем репликацию (Snap Mirror), то для ее  нормального функционирования нужно было поддерживать одинаковые версии и всегда обновлять сначала "получателя" данных. В случае, если репликация идет в обе стороны, приходится останавливать SnapMirror на время апгрейда. Теперь у нас есть version-flexible SnapMirror, благодаря которому можно спокойно обновлять любой из узлов без остановки репликации. Еще одна задача администрирования решена! Для поддержки распределенной отказоустойчивый инфраструктуры это очень важное нововведение.

Раз уж затронули SnapMirror, то теперь при передаче данных используется компрессия, что позволяет снижать нагрузку на сеть и каналы связи. Не могу сдержаться - FalconStor NSS умел так делать еще лет 10 тому назад! :) В любом случае, это еще один плюс в копилку.

У заказчиков, использующих SnapVault появлиась возможность восстанавливать данные на уровне отдельных файлов (технология On-Demand Data Management). Данные доступны пользователю сразу и он может с ними работать, пока происходит копирование на основную систему.

Перейдем к производительности и эффективности хранения.

Больше не записываем нули на диски! Для томов с включенной дедупликацией, в онлайне находятся блоки из одних нулей и они не записываются на диски (Inline zero write detection and elimination). В VMware, например, мы создаем eager zeroed диски, чтобы обеспечить неизменный уровень производительности, но из-за архитектуры WAFL, нам нет нужды записывать нули на диски. Кроме того, существуют и другие специфические задачи, когда за счет исключения нулевых блоков, мы получаем заметный прирост производительности.

Еще одно направление оптимизации - All-Flash Optimized personality.  Для All-Flash систем мы отказываемся от всех алгоритмов по оптимизации работы с обычными дисками, так как все это бесполезно для SSD дисков. Как следствие, производительность системы возрастает, а там, где борьба идет за микросекунду, любая оптимизация может быть критичной. AFF personality доступна только для FAS80xx и не позволяет использовать обычные диски - только SSD.

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

Следить за производительностью стало удобнее - собирать статистику можно уже не на уровне агрегата, а на уровне отдельного тома (qos statistics volume show).

Что касается эффективности, то самая большая проблема в младших системах (с небольшим числом дисков) это объяснить заказчику, куда делось все то дисковое пространство, за которое он заплатил. Для каждого контроллера отдельные диски выделим под root (рекомендуется RAID-DP) плюс еще пара дисков в резерв (spare). И вот, в самой младшей системе от 12 дисков осталось 2 под данные.

Да, конечно, можно немного "поколдовать" и улучшить ситуацию (здесь RAID4, там один spare диск) - в результате, что-то подходящее можно собрать. Но, во-первых, это нужно делать руками (и игнорировать предупреждения системы), а, во-вторых, даже в этом случае, мы получаем не слишком-то большой объем. Поэтому систему из 12 дисков сложно использовать как active-active, так как на одном из контроллеров будет всегда слишком мало дисков. Наконец-то, в Data ONTAP 8.3 появилось решение - Advanced Disk Partitioning (ADP).  После метрокластера, мне кажется, это вторая по значимости новость - можно на одних и тех же физических дисках размещать два агрегата - для root и для данных. Причем, для root мы можем собрать RAID-DP и два spare "блока", а для данных  один резервный блок. Теперь конфигураций с 12ю дисками можно уже пользоваться "из коробки" - полезного пространства стало гораздо больше.

И даже для системы с 12 дисками можно использовать active-active режим работы (полезная емкость конечно ниже, но мы можем делить нагрузку между контроллерами):

ADP очень хорошо работает и для AFF конфигураций - стоимость SSD дисков довольно высока и "выбрасывать" их на создание рутового агрегата довольно расточительно. Благодаря ADP, AFF система будет показывать лучшую экономику, при сравнении с конкурентами, чем ранее.

И третьим плюсом от ADP является оптимизация нагрузки на SSD диски в FashPool - на одних и тех же дисках можно создать агрегаты для каждого из контроллеров. Широкий страйпинг позволит обеспечить лучшую производительность системы.

Advanced Disk Partitioning можно использовать на младших системах (22хх) для совмещения root и data агрегатов на одних дисках, всех AFF конфигурациях и для всех систем в FlashPool.

В версии 8.3 также существенно увеличен максимальный объем FlashPool - рост в 4 раза:

FAS8080 EX	144 TiB
FAS8060	72 TiB
FAS8040	48 TiB
FAS8020	24 TiB
FAS25xx	16 TiB

Я кратко описал только часть тех новых возможностей, которые стали доступны после выхода версии 8.3 Data ONTAP. Кто-то конечно мог уже попробовать и оценить многие из перечисленных возможностей, обновившись еще на 8.3 RC1 версию, но сейчас, когда GA уже здесь, можно планировать апгрейд и тем, кто не решался использовать ранние версии. Безусловно, очень важно внимательно изучить документацию перед апгрейдом - всегда есть нюансы.

Почитать на тему:

Clustered Data ONTAP 8.3 Release Notes
Clustered Data ONTAP 8.3 Network Management Guide
Clustered Data ONTAP 8.3 SAN Administration Guide
Clustered Data ONTAP 8.3 Physical Storage Management Guide

Понравился пост? Подпишись через RSS, Email или twitter!

Data ONTAP 8.3 и MetroCluster

На прошлой неделе объявлено о GA версии 8.3 Clustered Data ONTAP - внутри довольно много нововведений. Больше “совместимой” 7-mode версии нет - только clustered вариант. Но одним из ключевых изменений я вижу вот это:

"Starting with Data ONTAP 8.3, MetroCluster configurations are supported in clustered Data ONTAP."

Начиная с Data ONTAP 8.3 в clustered Data ONTAP поддерживаются конфигурации MetroCluster.

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

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

• RPO, Recovery Point Objective - максимально допустимая потеря данных при сбое
• RTO, Recovery Time Objective - максимально допустимое время восстановления сервис СХД (обеспечение доступности данных для приложений)

Отказоустойчивость в системах с MetroCluster в Data ONTAP 8.3 базируется на двух столпах:

• NDO (NonDisruptive Operation) при большинстве локальных сбоев внутри датацентра (отдельные компоненты, узел кластера, сбои сети и т.п.). Кроме того, обеспечивается непрерывность обслуживания и во время проведения планового обслуживания системы.
• Непосредственно MetroCluster повышает доступность за счет наличия второго датацентра и зеркалирования данных на удаленную систему

Между узлами кластера обеспечивается автоматическое переключение в рамках одного датацентра и ручное переключение нагрузки при полном сбое в основном ЦОДе. При этом, заказчик получает нулевой RPO (данные не теряются) и RTO порядка 120 секунд для запланированных переключений между площадками и порядка несколько минут для “аварийных” переключений (администратору достаточно выполнить только одну команду).

Функционирование MetroCluster “прозрачно” для ОС и прикладных приложений, поэтому нет необходимости во внесении  существенных изменений в имеющуюся инфраструктуру. Переход на резервную площадку не требует переподключения хостов к SAN или NFS ресурсам, так как все пути до СХД остаются неизменными. Только для SMB клиентам понадобится подключиться заново (в силу ограничений протокола).

MetroCluster интегрирован непосредственно в Data ONTAP и не требует никаких дополнительных лицензий - нужно только правильно спланировать архитектуру системы.

Больше нет разделения на Fabric MetroCluster (FMC) и strech MetroCluster (SMC) - есть только один MetroCluster, который может быть использован на расстояниях до 200км.

Как уже наверное стало понятно из вышесказанного, в новой версии мы больше не “растягиваем” одну пару контроллеров между площадками, а размещаем на каждой площадке по HA-паре. Несомненный плюс такого подхода - снимается одно из главных возражений против использования метрокластера, которое регулярно приходилось слышать. А что будет, если у нас выйдет из строя один контроллер? Раньше нас ждал переезд на вторую площадку (как правило, в ручном режиме) и, безусловно, такие мероприятия доставляют мало удовольствия. В то же время, исследования показывают, что незапланированные проблемы, приводящие к выходу из строя целой площадки составляют всего около 1% от всех возможных нештатных ситуаций. Чаще всего вообще причина остановки - плановое обслуживание. Прозрачное переключение между узлами в HA-паре позволяет практически полностью избавиться от такого рода проблем - теперь плановые работы можно проводить именно “по плану”.

Что же нужно, чтобы “построить” MetroCluser?

• Для связи между площадками используются FC линки, которых желательно иметь не менее четырех.
• Также потребуется установить на каждой площадке по 2 FC коммутатора
• Все контроллеры должны иметь доступ к дискам на всех площадках, поэтому дисковые полки нельзя подключить через SAS напрямую, а нужно использовать FC-SAS гейты (ATTO 6500N).
• Желательно на каждой площадке установить не менее 4 дисковых полок (минимум 2). Когда каждая полка содержит диски только одного пула, администрировать систему заметно проще - не нужно вручную назначать диски контроллерам, а значит и запутаться вероятность ниже.
• По FC-VI карте в каждый контроллер
• Все правильно подключить и настроить :)

После этого, каждый контроллер в двух HA-парах начнет синхронно зеркалировать все изменяющиеся данные (включая информацию о конфигурации) на вторую площадку. На самом деле, на каждой площадке может быть и больше двух контроллеров - у нас же clustered Data ONTAP! 

Как видим, получается не такую уж и маленькую система. При этом, совсем младшие модели будут иметь много ограничений по доступным портам - часть слотов расширения займут FC-VI карты.

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

Помимо данных, зеркалируется и содержимое NVRAM контроллеров. Поэтому каждый контроллер использует для “своих” нужд только четверть от общего объема NVRAM и реплицирует данные на два других контроллера (локального и удаленного партнера). В нормальном режиме функционирования в NVRAM каждого контроллера, помимо "своих" данных, есть еще и данные двух других контроллеров (в NVRAM контроллера A1 - данные из NVRAM контроллеров A2 и B1). Еще четверть резервируется на случай выхода из строя одного из контроллеров после сбоя на площадке, т.е. на случай, когда у нас останется в живых только один контроллер из четырех. И даже в этом случае система будет продолжать работать! 

Конечно, думая о внедрении MetroCluster, мы должны помнить и об ограничениях:

• Нельзя защитить только часть данных - в MetroCluster должны дублироваться абсолютно все данные. На двух площадках всегда должно быть одинаковое количество дисковых ресурсов и нельзя создать агрегат без зеркалирования. Конечно можно на одной площадке использовать 60% доступных локальных дисковых ресурсов, а на второй 40%. Такая схема будет поддерживаться, но зеркалировать нужно все.
• Не поддерживаются Infinite Volumes.
• Не поддерживается Advanced Disk Partitioning.
• Не поддерживается NSE (NetApp Storage Encryption). Если требуется шифрование, можно использовать виртуализацию СХД и подключить сторонние системы, которые такой режим поддерживают.
• Действуют ограничения на количество SSD дисков в стеке полок (не более 48). Кроме того, рекомендуется не смешивать в одной полке SSD и обычные диски.
• Ограничение конкретной модели FAS на число дисков распространяется не на HA-пару, а на 4 контроллера (т.е. на две площадки), так что на каждой площадке может быть не более 50% от возможного числа дисков.
• Рекомендуется “ручное” переключение между площадками в случае сбоя
• Восстановление всегда "ручная” операция, требующая вмешательства администратора СХД 

Еще несколько слов про переключение между площадками. Рекомендация делать переключения вручную неслучайна - вероятность выхода целой площадки из строя весьма мала, но последствия могут быть самыми разными, поэтому важно понимать что мы делаем и зачем. Кроме того, может быть ситуация, когда обе площадки живы, а вот канал связи между ними потерян - в таком случае, никакие переключения делать не стоит. Обычно в таких случаях используется третья площадка, которая “следит” за происходящим. В случае с MetroCluster есть т.н. tiebreaker software, который и выполняет эту роль. Да, с его помощью можно полностью автоматизировать переключение на резервную площадку при сбое, но, поверьте, это не самая лучшая идея. Поэтому лучше использовать этот софт только как средство дополнительного мониторинга.

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

Почитать по теме:

Data ONTAP 8.3 Release Notes

NetApp MetroCluster Product Documentation

TR-3982: Introduction to Clustered Data ONTAP 

Понравился пост? Подпишись через RSS, Email или twitter!