Metrocluster (part 2)

Как мы уже рассматривали выше, межкластерное соединение по длине ограничено возможностями канала Infiniband, по которому осуществляется взаимный согласованный доступ между узлами, и его физическими характеристиками. Таким образом нам доступна дистанция разноса узлов кластера в 30 метров без каких-либо дополнительных средств. Что же, если мы хотим создать кластерную систему, разнесенную для катастрофоустойчивости на значительно большее расстоняие?
Для этого создана система, под названием «Metrocluster».
Давайте рассмотрим подробнее из чего она состоит, что дает по сравнению со стандартным кластером NetApp, и как работает.

Одной из проблем, которую вынуждена решать кластерная система любого производителя, есть проблема «split brain». Это ситуация, когда, в результате разрыва соединения между кластерами, оба узла кластера считают себя выжившими, а партнера – мертвым. ?? пытаются взаимно перехватить ресурсы соседа. В ряде случаев им это удается, и мы получаем в результате две несинхронизированных и различных копии данных, одну на дисках, подключенных к одному узлу, другую – к другому, оба продолжавших работать.
Кроме того, констроллер узла может потерять связь разным способом, не только межкластерную связь, но также и связь с дисками, причем также и одновременно и то и то. Логика кластерного монитора должна правильно обрабатывать такие ситуации и находить решения для продолжения работы и восстановленя доступности ресурсов.

Для разрешения этих проблем, каждая «голова» кластера владеет группой «своих» дисков, а также зеркальной копией дисков соседа. ??, соответственно, сосед также.

NetApp Metrocluster scheme

А тут я хочу напомнить, что в настоящее время NetApp имеет две версии своего ПО для контороллеров, «классическая» линейка, в настоящее время носящая номер 7, и новая, версия X, которая пока еще не имеет всего богатства функционала «классической» версии, однако в отличие от «классика», ограниченного всего двумя узлами в кластере, позволяет строить grid-кластеры с количеством узлов до 24. В скором времени ожидается полное слияние «традиционной» и «новой» версии как по функционалу, так и по поддержке платформ, таким образом пользователи систем NetApp смогут строить многоузловые распределенные кластерные системы хранения.

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

Метрокластер есть по сути комбинация из опции Local SyncMirror, опции синхронной репликации, «зеркала» данных, и опции кластера системы NetApp.

Метрокластер может существовать в варианте Stretched Metrocluster, то есть «растянутого», при этом, для расстояний до 300 метров, используется специальный оптический кабель и конвертеры «медного» Infiniband в оптический канал. Обычно это довольно ограниченный по своим возможностям вариант, но в ряде случаев он выбирается, если нет смысла городить полноценный огород ради разноса узлов системы на 200 метров.
Второй вариант принято называть Switched Metrocluster. При этом создается специальная выделенная «фабрика» для дисков системы с помощью FC-коммутаторов партнера NetApp, компании Brocade (в настоящее время используются коммутаторы Brocade 200E с лицензией Full Fabric). В качестве канала данных между двумя половинами «фабрики» используется 4GB Longwave FC optics с соответствующими трансиверами. Дальность «разноса» узлов кластера в конфигурации Switched Metrocluster может достигать 10 км  - расстояния, доступного для Longwave FC. Дальнейшее его увеличение приводит к увеличению задержек и «пологости» фронтов сигналов вследствие конечности скорости света в оптоволокне, что и является, в данном случае, ограничением.
Необходимость же жестко выдерживать временные  скоростные характеристики следует из самой логики, принципа работы. Ведь весь «метрокластер», как структура, представляет из себя не просто логически единую структуру, но и физически в значительной степени однородную.
Это позволяет рассматривать данные, размещенные на устройстве Metrocluster как не только отказоустойчивые, но и совершенно прозрачно для приложений и использующих их «потребителей» распределенные, с точки зрения как просто распределенный «жесткий диск». В этом и заключается основное отличие и преимущество перед решениями иных производителей систем хранения, которые предлагают либо локальный, «катастрофонеустойчивый» кластер, либо распределенную синхронную или асинхронную, более или менее непрозрачно действующую для приложений пользователя.

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

Подробнее по теме:

TR-3548: MetroCluster Design & Implementation Guide

TR-3517:  MetroCluster Upgrade Planning Guide

TR-3614:  Implementing Oracle Database 11g Running with Direct NFS Client on Network Appliance MetroCluster

TR-3606:  High Availability and Disaster Recovery for VMware Using NetApp SnapMirror and MetroCluster

Комментарии (7)

  1. Alex:

    Роман, все-таки не очень понятно, каким образом НетАпп решает проблему split-brain’а. Например, в случае обрывов всех каналов связи между двумя разнесенными площадками. Как в этом случае наличие зеркальной копии “соседа” позволяет решить проблему?

  2. Чорт, спалили :-D
    Еще когда писал ведь думал, что как-то не получается у меня “на пальцах” все описать, кто-нибудь обязательно спросит подробностей. ;)
    Не расскажу, увы. Возможно позже вернусь к этой теме, пока же могу только махнуть “манами”. :)

  3. Alex:

    :))
    все же, насколько я понимаю, проблему сплит-брейна программными средствами (при отсутствии третьего арбитра) не решить, как ни крути.

  4. bbk:

    Вопрос Alex’а о split-brain’е так и не прояснился?

  5. bbk:

    Это решается за счет внешнего “кворумного” стораджа, расположенного на “третьем” сайте, решение описано в TR3816 Providing Zero Downtime for Enterprise Applications Using Oracle Real Application Cluster on Extended Distance Cluster, Oracle Automatic Storage Management Normal Redundancy, and NetApp MetroCluster

    или за счет софтового решения, в виде плагина к MS SCOM.

  6. bbk:

    Есть ли решение, арбитр для метрокластера, у НетАпп’а, для случая разрыва всех коммуникаций между площаками, чтобы не ждать админа который скажет cf forcetecover, а автоматизировать процесс?

  7. bbk:

    Во-первых - выше я же привел источники, посмотрите.

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

Оставить комментарий