![](https://habrastorage.org/storage/habraeffect/90/06/9006dd428fe42adf5ac7e6c9ef7d5226.png)
В 2007 году, консалтинговое агентство Forrester провело опрос 250 IT-специалистов, с целью оценить риски аварий для IT, как внутри датацентра, так и вне его, например риски природных аварий и катастроф.
После обработки и публикации результатов стало понятно, что привычное средство обеспечения отказоустойчивости в виде, например, традиционного «дублирующего, избыточного контроллера и RAID» может защитить всего от 31% всех возможных отказов.
На графике вы видите также такие IT-дизастеры как отказы электропитания (" — что случилось с вашим электричеством? — Оно моргнуло." ), проблемы с ПО ("…и будет закрыто"), человеческие ошибки ("как ты сказал имя тома, который надо было размонтировать и грохнуть?"), ошибки сетевых настроек (" — а какой интерфейс использовать? — попробуй eth0."), а также и разнообразные природные (и не очень) катаклизмы, такие как пожары, наводнения и так далее.
Таким образом становится ясно, что традиционные средства защиты работоспособности данных защищают его, увы, недостаточно, сколько бы «девяток» вам ни обещали в рекламе. И когда стоимость потери или простоя данных становится весьма существенной, встает вопрос поиска решения, обеспечивающего большую надежность, чем решения традиционные.
Обычно для защиты данных от локальных катастроф, будь то отказ электропитания, пожар, "проведение следственных мероприятий", и прочих подобных форс-мажорных событий, используется метод репликации данных на удаленное хранилище. Подобные средства сегодня предлагают почти все производители систем хранения.
Однако для начинающих знакомство с отказоустойчивыми решениями часто бывает сюрпризом то, что наличие репликации и удаленной копии ваших рабочих данных еще не означает настоящей отказоустойчивости.
Данные-то у вас сохранены, но для того, чтобы этими данными воспользоваться зачастую нужны довольно обширные перенастройки. Надо разорвать репликацию с уже не работающего источника, перевести копию в онлайн, объяснить серверам, что данные теперь лежат не на этой системе (с такими-то IP и WWPN), а вот на той, с совсем другими адресами и свойствами.
Нужно перепроверить все настройки, переписать их (не забыть и не перепутать), убедиться, что все запустится, и лишь после этого ваши сервера будут готовы к тому, чтобы запуститься с сохраненной реплики.
Все это часто усложняется тем, что на системе хранит данные не одно приложение, а, обычно, множество разных, каждое со своими правилами и способами организации отказоустойчивости, зачастую управляются эти реплики разными способами, создаются в разных программах, и так далее.
Кроме того сам процесс переключения, зачастую, происходит неединообразно.
Делается это где-то совсем вручную, где-то полуавтоматически, но, как правило, какого-то общего решения, не отдельно для каждого приложения, а для всей инфраструктуры в целом — нет.
А ведь системой хранения на предприятии зачастую пользуются многие десятки различных приложений. И весь этот «переезд» надо проделать для каждого из них!
Нет, не зря, ой не зря русский народ приравнивает два переезда к одному пожару.
Так почему бы не возложить все эти задачи непосредственно на сам контроллер системы хранения? Почему бы не сделать систему хранения, которая бы переключалась на свою «реплику» просто и «прозрачно» для приложений?
Вот из этой такой простой идеи и родился NetApp Metrocluster — программно-аппаратное решение распределенной кластерной системы хранения.
Идея, легшая в основу Metrocluster, была, как часто у NetApp, простая и остроумная.
К каждому контроллеру из пары, составляющей кластер (пока, к сожалению, контроллера может быть только два), на текущей площадке подключены два набора дисков. Один набор — его собственный, а второй — точная синхронная копия данных набора дисков «соседа». Кроме этого, так как современные диски FC имеют два равноправных «порта» доступа, каждый диск подключен одним портом к локальному, а вторым — к удаленному контроллеру, «крест накрест», каждый контроллер, таким образом, имеет доступ как к основному набору дисков, так и к копии, однако в конкретный момент времени, пока не случился cluster takeover, может работать только со «своим набором». Каждая запись, поступающая на контроллер, синхронно зеркалируется на «второй комплект» дисков у соседа.
В случае же аварии или любого «нештатного события» контроллер, в дополнение к доступу к «своим» данным, получает доступ к данным партнера по кластеру, а также переносит на себя все его ресурсы, такие как IP-адреса его интерфейсов Ethernet, WWPN интерфейсов FC, имена LUN-ов и «сетевых шар», DNS-имена, и так далее, так что после переключения приложения продолжают работать «как и раньше», просто обслуживает их данные другой контроллер.
Просто удивительно, почему никто из основных вендоров систем хранения не реализовал такую простую но эффективную модель (нечто очень похожее по идее, правда, сейчас пытается начать продавать EMC в своем продукте VPLEX).
NetApp Metrocluster существует в двух вариантах. Это так называемый Stretched Metrocluster, в котором максимальное расстояние разноса его компонентов определяется допустимой длиной специального кабеля кластерного интерконнекта, не более 500 метров; и Switched Metrocluster, при котором длина ограничивается только предельной длиной канала Longhaul LW Fibre Channel, в настоящий момент — 100 км.
(На картинке с сайта VMware показано использование Metrocluster для VMware vSphere FT, но на ее месте могут быть любые приложения)
![image](https://habrastorage.org/storage/habraeffect/26/c4/26c4c870b6ea857708f3007f156d055f.png)
Sretched Metrocluster работает точно также как более дорогой и сложный Switched Metrocluster, но может защитить, главным образом, от «локальных» аварий, например выносом «половинки» хранилища на другой этаж, в соседний модуль датацентра, или в соседнее здание в пределах 500 метров кабеля. Но даже такой, локальный вариант, поможет сохранить работоспособность при пожаре в датацентре, «выемке», локальном отказе электропитания, и так далее.
Switched Merocluster предлагает уже полноценную распределенную систему хранения, которая может защитить и от ряда стихийных бедствий (например NetApp Metrocluster использует турецкое производство заводов Ford Motors, одно из основных промпредприятий которого расположено в сейсмически опасном районе).
![image](https://habrastorage.org/storage/habraeffect/bd/35/bd357d80a527029cab4bfbc4948c7b47.png)
Таким образом, вы можете сделать систему хранения, в которой одна половина будет находиться в Москве, а другая, например, в Зеленограде, причем работать обе половины будут синхронно, словно логически единая структура. Сервера московского датацентра будут работать с половинкой системы хранения на своей площадке, а сервера Мытищ или Долгопрудного — своей, но при этом, в случае сбоя (например отказа питания в датацентре, выхода из строя любой части системы хранения, выхода из строя дисков, контроллера, или же канала передачи данных меду датацентрами) данные останутся доступны.
Любой сбой или комбинация таких сбоев не приводит к недоступности данных, а процесс переключения и восстановления работоспособности осуществляется одной простой командой. Сами же программные приложения, использующие хранение данных на Metrocluster, за пределами самого факта переключения контроллера, не требуют перенастройки, и работа кластера для них полностью, как принято говорить, «прозрачна».
Для полной ясности давайте рассмотрим возможные сценарии сбоев.
Самый простой вариант — отказ хоста.
Приложение поднимается средствами серверной кластеризации на хосте 2, и продолжает работать, получая доступ к данным через «фабрику» исходного датацентра к хранилищу 1. (Синими линиями показывается путь доступа к данным)
![image](https://habrastorage.org/storage/habraeffect/f4/a6/f4a69f2d467d205427524824174747cd.png)
Также обычная история — отказ контроллера системы хранения.
Как и в ранее показанном случае — переключение доступа автоматическое.
![image](https://habrastorage.org/storage/habraeffect/d2/4f/d24fd99478ec997044a901462de9d886.png)
Драма нарастает. Отказ половины хранилища целиком. Оператор или контролирующее ПО принимает решение о cluster takeover, которое осуществляется за несколько секунд одной командой cf takeover, и происходит прозрачно для приложений.
![image](https://habrastorage.org/storage/habraeffect/d6/3c/d63c199a66bd9eecc6af661edf2957c5.png)
Катастрофа. Потерян целиком датацентр, вместе с хостами и половиной системы хранения. Доступ к данным сохранен. Второй контроллер кластера обслуживает «свои» данные как обычно, а данные партнера — с его копии на своем сайте.
![image](https://habrastorage.org/storage/habraeffect/ec/8d/ec8d547f5e79200e85e8482ff64be636.png)
Разрыв канала связи. Контроллеры кластера изолированы. Работа продолжается нормальным образом, при восстановлении связи произойдет ресинхронизация плексов. Для предотвращения ситуации split brain, если ваше ПО может такую ситуацию создать, возможно понадобится сайт-арбитр — «tiebreaker».
![image](https://habrastorage.org/storage/habraeffect/c5/9a/c59a75147148d10ee5581f6ee83e10e9.png)
Конечно решение в целом получается непростое и недешевое (хотя и дешевле, чем аналоги). Два комплекта дисков для данных (этакий распределенный Network RAID-1), по одному на каждой площадке, выделенная внутренняя «фабрика» FC-коммутации, через которую осуществляется связь внутри «кластера хранения» и взаимная синхронная репликация данных между площадками, но в тех случаях, когда надо обеспечить работу не "в 31% случаев", а «всегда», когда стоимость простоя или повреждения данных высока, организации предпочитают не экономить.
Впрочем, с выходом новых серий систем хранения FAS3200/6200, в которых набор лицензий для организации метрокластера уже включен в базовую поставку, сделан шаг к более массовому применению этого решения.