НОВОЕ В МЕТРОКЛАСТЕРАХ

Привет, читатели Хабра! В прошлой статье мы рассказали о простом средстве катастрофоустойчивости в системах хранения AERODISK ENGINE – о репликации. В этой статье мы погрузимся в более сложную и интересную тему – метрокластер, то есть средство автоматизированной защиты от катастроф для двух ЦОД-ов, позволяющее работать ЦОД-ам в режиме active-active. Расскажем, покажем, сломаем и починим.

DevLink-М1 (Арбитр сети RS485) предназначен для минимизации коллизий при одновременном включении в сеть RS-485 двух Master-устройств, опрашивающих подключенные приборы. DevLink-М1 представляет собой автономное устройство без органов управления, выполненное в корпусе из ABS-пластика с креплением на DIN-рейку.

• Возможность включения в сеть RS-485 двух Master-устройств.
• Работа в 3-х режимах: покоя, монопольный, аварийный.
• Самодиагностика работы (встроенные диагностические выходы).

• 

  АСУ, шкафы управления и др.

• 

  DevLink-C1000 и др.

• 

  мини-, полнофункциональные и др.

• 

  DevLink-P200 и др.

• 

  Контроллеры сбора данных

  DevLink-D600 и др.

• 

  DevLink-A10 и др.

• 

  Арбитры сети RS485

  DevLink-М1 и др.

• 

  DB9-винт и др.

• 

  ElNet MC и др.

• 

  стандарт, люкс, эконом и др.

• Содержание

  1. ТЕСТИРОВАНИЕ
  2. КОММУНИКАЦИИ
  3. СИСТЕМЫ АВТОМАТИКИ
  4. Как обычно, в начале теория
  5. Для чего это нужно?
  6. Как это работает?
  7. Как работает арбитр и в чем его задача?
  8. Теперь погрузимся в детали работы арбитра
  9. Рассмотрим плюсы и минусы метрокластера
  10. Стандарты и Руководящие документы
  11. Краш-тест
  12. Несколько рабочих кейсов
  13. Кто первый встал, того и тапки
  14. Уговор дороже денег
  15. А что с Арбитром?
  16. Когда репликации не переключаются в Primary автоматически?
  17. Когда репликации автоматически переключаются в Secondary?
  18. Арбитраж (в передаче данных)
  19. Настройка метрокластера
  20. Настраиваем арбитра
  21. Вспомним матчасть
  22. Планирование метрокластера
  23. Площадки
  24. Коммутация и сеть
  25. Конфигурация арбитра
  26. Архитектура решения
  27. Обзор новой архитектуры метрокластера
  28. АРБИТР (компьютерная программа)
  29. Подводим итог
  30. Подводим итог

  ТЕСТИРОВАНИЕ

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

• КОММУНИКАЦИИ

  Устройства поддерживают GSM/GPRS и могут применяться в составе M2M систем. Коммуникационные устройства DevLink обладают всеми необходимыми сертификатами.

• СИСТЕМЫ АВТОМАТИКИ

  По Вашему техническому заданию специалисты фирмы разработают системы комплектной автоматики различных объектов (котельных, ИТП и т.д.) на базе устройств серии DevLink.

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

Мы гарантируем ответ в течение 8 рабочих часов!

адрес для заявок: dkv@nt-rt.ru

• 

  029 — Громова Марина

  Здравствуйте! Я могу вам чем-то помочь?

Оператор набирает сообщение

! Какая продукция Вас интересует?

Задайте вопрос прямо сейчас:

Как обычно, в начале теория

Метрокластер – это кластер, разнесенный на несколько площадок в пределах города или района. Слово «кластер» нам явно намекает на то, что комплекс автоматизирован, то есть переключение узлов кластера в случае сбоев (failover) происходит автоматически.

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

Для чего это нужно?

Основная цель, которую преследуют заказчики, используя те или иные реализации метрокластера – минимизировать RTO (Recovery Time Objective). То есть минимизировать время восстановления ИТ-услуг после сбоя. Если использовать обычную репликацию, то время восстановления будет всегда больше времени восстановления при метрокластере. Почему? Очень просто. Администратор должен быть на рабочем месте и переключить репликацию руками, а метрокластер это делает автоматически.

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

Соответственно RTO в случае отсутствия метрокластера или бессмертного админа 99-ого уровня
дежурной службы администраторов будет равным сумме времени переключения всех систем и максимальному промежутку времени, через который администратор гарантированно начнет работать с СХД и смежными системами.

Таким образом приходим к очевидному выводу, что метрокластер нужно использовать в случае, если требование к RTO – минуты, а не часы или дни. То есть, когда в случае самого страшного падения ЦОД-а ИТ-департамент должен обеспечить бизнесу время восстановления доступа к ИТ-услугам в течение минут, а то и секунд.

Как это работает?

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

• оптоволокно в качестве физики, 10 гигабитный Ethernet (или выше);
• расстояние между ЦОД-ами не более 40 километров;
• задержка канала оптики между ЦОД-ами (между СХД) до 5 миллисекунд (оптимально 2).

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

Итак, для передачи данных между СХД используется синхронная реплика, а каким образом реплики автоматически переключаются и самое главное, как избежать split-brain? Для этого на уровне выше используется дополнительная сущность — арбитр.

Как работает арбитр и в чем его задача?

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

Арбитр выполняет постоянный мониторинг всех СХД в метрокластере и в случае недоступности той или иной системы хранения он, после подтверждения недоступности от ещё одного участника кластера (одной из «живых» СХД), принимает решение о запуске процедуры переключения правил репликации и о маппинге.

Очень важный момент. Арбитр всегда должен находится на площадке, отличной от тех, на которых находятся СХД, то есть ни в ЦОД-е 1, где стоит СХД 1, ни в ЦОД-е 2, где установлена СХД 2.

Почему? Потому что только так арбитр с помощью одной из выживших СХД может однозначно и безошибочно определить падение любой из двух площадок, где установлены СХД. Любые другие способы размещения арбитра, могут привести к split-brain-у.

Теперь погрузимся в детали работы арбитра

На арбитре запущены несколько служб, которые постоянно опрашивают все контроллеры СХД. Если результат опроса отличается от предыдущего (доступен/недоступен), то он записывается в небольшую базу данных, которая работает также на арбитре.

Рассмотрим логику работы арбитра более подробно.

Шаг 1. Определение недоступности.
Событием-сигналом об отказе СХД является отсутствие пинга с обоих контроллеров одной СХД в течение 5 секунд.

Шаг 2. Запуск процедуры переключения.
После того, как арбитр понял, что одна из СХД недоступна, он отправляет запрос на «живую» СХД с целью удостовериться, что «мертвая» СХД, действительно, умерла.

После получения такой команды от арбитра, вторая (живая) СХД дополнительно проверяет доступность упавшей первой СХД и, если её нет, отправляет арбитру подтверждение его догадки. С ХД, действительно, недоступна.

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

Зачем нужна дополнительная проверка? Для кворума. То есть большинство из общего нечетного

количества участников кластера должны подтвердить падение одного из узлов кластера. Только тогда это решение будет точно верным. Это нужно для того, чтобы избежать ошибочного переключения и, соответственно, split-brain-а.

Шаг 2 по времени занимает примерно 5 — 10 секунд, таким образом, с учетом времени, необходимого на определение недоступности (5 секунд), в течение 10 – 15 секунд после аварии LUN-ы c упавшей СХД будут автоматически доступны для работы с живой СХД.

Понятное дело, что для того чтобы избежать разрыва соединения с хостами, нужно также позаботиться о корректной настройке тайм-аутов на хостах. Рекомендуемый тайм-аут составляет не менее 30 секунд. Это не даст возможности хосту разорвать соединение с СХД во время переключения нагрузки при аварии и сможет гарантировать отсутствие прерывания ввода-вывода.

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

На самом деле все не так-то просто.

Рассмотрим плюсы и минусы метрокластера

Итак, мы поняли, что очевидными плюсами метрокластера по сравнению с обычной репликацией являются:

• Полная автоматизация, обеспечивающая минимальное время восстановления в случае катастрофы;
• И всё :-).

А теперь, внимание, минусы:

• Стоимость решения. Хотя метрокластер в системах Аэродиск не требует дополнительного лицензирования (используется та же лицензия, что и на реплику), стоимость решения будет все равно ещё выше, чем с использованием синхронной репликации. Потребуется реализовать все требования для синхронной реплики, плюс требования для метрокластера, связанные с дополнительной коммутацией и дополнительной площадкой (см. планирование метрокластера);
• Сложность решения. Метрокластер устроен значительно сложнее, чем обычная реплика, и требует значительно больше внимания и трудозатрат на планирование, настройку и документирование.

В итоге. Метрокластер – это, безусловно, очень технологичное и хорошее решение, когда вам реально нужно обеспечить RTO в секунды или минуты.
Но если такой задачи нет, и RTO в часы – это для бизнеса ОК, то нет смысла стрелять из пушки по воробьям. Достаточно обычной рабоче-крестьянской репликации, поскольку метрокластер вызовет дополнительные расходы и усложнение ИТ-инфраструктуры.

Стандарты и Руководящие документы

Краш-тест

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

Для этого мы эмулируем полный отказ одной из СХД, физически выключив оба её контроллера, запустив предварительно копирование большого файла на LUN, который должен активироваться на другой СХД.

Отключаем одну СХД. На второй СХД видим алерты и сообщения в логах о том, что пропала связь с соседней системой. Если настроены оповещения по SMTP или SNMP мониторинг, то админу придут соответствующие оповещения.

Ровно через 10 секунд (видно на обоих скриншотах) репликационная связь METRO (та, что была Primary на упавшей СХД) автоматически стала Primary на работающей СХД. Задействовав существующий мапинг, LUN TEST остался доступен хосту, запись немного просела (в пределах обещанных 10 процентов), но не прервалась.

Тест завершен успешно.

1. ГОСТ Р 50304-92 Системы для сопряжения радиоэлектронных средств интерфейсные. Термины и определения. Часть 3. 3 Организация данных и средств управления
2. Таненбаум Э. Архитектура компьютера. 5-е изд. 2007

Несколько рабочих кейсов

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

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

Кто первый встал, того и тапки

Алгоритм данного подхода заключается в том, что при включении узел репликации пытается обнаружить соседа. Если сосед обнаружен и имеет статус Primary, то узел становится Secondary и начинает реплицировать данные на себя. Если же конкурентов в сети не видно, то самое время стартовать в Primary и брать на себя всю ответственность за ситуацию.

В идеальном мире всё работает идеально. Проблемы начинаются тогда, когда в дело вступают внешние условия. Например, сетевое соединение между узлом Primary на СХД1 и узлом Secondary на СХД2 пропадает, а в это время, как назло, происходит отказ одного из контроллеров СХД2, на котором активен этот узел репликации. Дисковая группа меняет владельца, происходит автоматическая обработка failover’а между контроллерами СХД, а простыми словами – аварийный переезд группы.

Уговор дороже денег

Как полностью исключить возможность появления данной ситуации? Конечно, если используется метрокластер, можно спросить Арбитр. Но если действительно нестабильна сеть и связь СХД2 с Арбитром временно отсутствует? К тому же, хотелось бы такую же гарантию получить и при использовании функционала удаленной репликации без метрокластера.

Каждый узел репликации имеет уникальный идентификатор, а также хранит у себя идентификатор узла Primary. Идентификаторы узлов (node_id) генерируются при создании репликационной связи, а при ручном переключении из Secondary в Primary идентификаторы Primary (primary_id) меняются на обоих узлах.

Так как же мы можем быть уверены, что никто наши тапки не займет раньше времени? Самое время научиться договариваться! Конечно, договориться мы сможем только в том случае, если получим ответ с удаленного узла, запросив у него primary_id из его конфигурации. К примеру, узлы репликации A и B включаются одновременно, узел A займет позицию Primary только в случае выполнения следующего равенства. В противном случае ситуация потребует ручного вмешательства, и пользователь должен будет сам поднять актуальную площадку.

А что с Арбитром?

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

Первым делом решили добавить веб-интерфейс. Встречает нас здесь системная панель, где в режиме реального времени отображается состояние обеих СХД в кластере.

На первых порах никуда и без системного журнала, решили мы. Сюда записываются все важные системные сообщения, например, о недоступности контроллеров СХД, о передаче аварийного сигнала failover с Арбитра на СХД.

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

Основная задача Арбитра – по-прежнему мониторинг доступности управляющих интерфейсов СХД в кластере. В случае недоступности первой площадки, аварийный сигнал будет отправлен на вторую. Узлы репликации будут подняты в Primary в автоматическом режиме с временным интервалом от 10 до 60 секунд, в зависимости от количества и объёма ресурсов площадки.

В основе работы мониторинга лежит протокол ICMP (ping и проверка доступности определенных портов). В основе работы управляющих сигналов лежит технология SSH, проверенная временем. Дело в том, что сама по себе СХД — монструозная система, в которой используется многообразие технологий и протоколов ввода-вывода. По этой причине не всегда приходится рассчитывать и ориентироваться на состояние веб-сервисов. Ведь нарушение функционирования веб-сервисов совсем не означает, что хостами потеряны блочный или файловый доступы 🙂

Когда репликации не переключаются в Primary автоматически?

Повторимся, метрокластер — технически сложная система, в работе которой задействовано много различных технологий и сервисов. Допустим, Арбитр потерял СХД1 и отправил сигнал бедствия на СХД2, но мы всё равно должны убедиться, что вызов не ложный 🙂

СХД2 переключит узлы репликации в Primary и поднимет VIP’ы метрокластера только в случае выполнения следующих условий:

1. Управляющие интерфейсы СХД1 недоступны с СХД2.

2. Репликации на СХД2 находятся в состоянии «разрыв соединения».

Когда репликации автоматически переключаются в Secondary?

У нас по-прежнему стоит задача защититься от двойного Primary и split-brain. Представим, что со стороны СХД1 потеряна связь с СХД2 и Арбитром. Узлы репликации оказываются изолированы и возникает риск автоматического переключения Арбитром на площадку с СХД2. В этом случае в течение 5 секунд все узлы репликации Primary (если таковые имеются) автоматически переключатся в Secondary.

Однако на описанном выше мы, естественно, не останавливаемся. У нас есть дорожная карта по развитию функционала метрокластера, и её реализация позволит переживать значительно большее количество сценариев отказов. Например, мы планируем отдельно мониторить все виды трафика по отдельности: СХД-Хост, СХД-СХД, управление СХД, что позволит очень гибко настраивать именно сетевое взаимодействие. Так как сейчас есть ряд ограничений при настройке сетевого взаимодействия между СХД и “внешним” миром в схеме с метрокластером.

Арбитраж (в передаче данных)

Текущая версия страницы пока не проверялась
опытными участниками и может значительно отличаться от версии
, проверенной 7 ноября 2021 года; проверки требует 1 правка
.

Настройка метрокластера

Настройка метрокластера очень похожа на настройку обычной репликации, которую мы описали в предыдущей статье
. Поэтому сосредоточимся только на отличиях. Мы настроили в лаборатории стенд, основанный на архитектуре выше, только в минимальном варианте: две СХД, соединённые по 10G Ethernet между собой, два коммутатора 10G и один хост, который смотрит через коммутаторы на обе СХД портами 10G. Арбитр работает на виртуальной машине.

При настройке виртуальных IP (VIP) для реплики следует выбрать тип VIP – для метрокластера.

Создали две репликационные связи для двух LUN-ов и распределили их по двум СХД: LUN TEST Primary на СХД1 (связь METRO), LUN TEST2 Primary для СХД2 (связь METRO2).

Для них мы настроили два одинаковых таргета (в нашем случае iSCSI, но поддерживается и FC, логика настройки та же).

Для репликационных связей сделали маппинги на каждой СХД.

Настроили multipath и презентовали на хост.

Настраиваем арбитра

С самим арбитром особо делать ничего не надо, его нужно просто включить на третьей площадке, задать ему IP и настроить к нему доступ по ICMP и SSH. Сама же настройка выполняется с самих СХД. При этом настройку арбитра достаточно выполнить один раз на любом из контроллеров СХД в метрокластере, эти настройки будут распространены на все контроллеры автоматически.

В разделе Удаленная репликация>> Метрокластер (на любом контроллере)>> кнопка «Сконфигурировать».

Вводим IP арбитра, а также управляющие интерфейсы двух контроллеров удаленной СХД.

После этого нужно включить все службы (кнопка «Всё перезапустить»). В случае перенастройки в будущем службы нужно обязательно перезапускать, чтобы настройки вступили в силу.

Проверяем, что все службы запущены.

На этом настройка метрокластера завершена.

Вспомним матчасть

Метрокластер – достаточно трудоемкий функционал, основанный на возможностях удаленной блочной репликации и механизмах взаимодействия узлов по протоколу iSCSI. Основными преимуществами являются автоматизация и надежность – метрокластер предназначен не только для автоматической обработки failover’а между площадками с СХД, но и для предотвращения возможных конфликтов и коллизий. Давайте вспомним верхнеуровневую модель построения метрокластера.

Система основана на вычислительной сети, состоящей из трех компонентов: ЦОД с СХД-1, ЦОД с СХД2, отдельный узел под названием Арбитр.

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

Дисковая группа – объединение физических дисков в одно логическое пространство с целью повышения производительности и отказоустойчивости. Логический том – слой абстракции, позволяющий распределять и управлять пространством дисковой группы. Узел репликации — программный элемент, отвечающий за передачу и синхронизацию данных между двумя логическими томами.

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

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

Планирование метрокластера

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

Площадки

Как указано выше, для метрокластера необходимо минимум три площадки. Два ЦОД-а, где будут работать СХД и смежные системы, а также третья площадка, где будет работать арбитр.

Рекомендуемой расстояние между ЦОД-ами – не более 40 километров. Большее расстояние с высокой вероятностью вызовет дополнительные задержки, которые в случае метрокластера крайне нежелательны. Напомним, задержки должны быть до 5 миллисекунд, хотя желательно уложиться в 2.

Задержки рекомендуется проверять также в процессе планирования. Любой более или менее взрослый провайдер, предоставляющий оптоволокно между ЦОД-ами, качественную проверку может организовать довольно быстро.

Что касается задержек до арбитра (то есть между третьей площадкой и двумя первыми), то рекомендуемый порог задержек до 200 миллисекунд, то есть подойдет обычное корпоративное VPN-соединение поверх сети Интернет.

Коммутация и сеть

В отличии от схемы с репликацией, где достаточно соединить между собой СХД с разных площадок, схема с метрокластером требует соединения хостов с обеими СХД на разных площадках. Чтобы было понятнее, в чем отличие, обе схемы указаны ниже.

Как видно из схемы, у нас хосты площадки 1 смотрят и на СХД1, и на СХД 2. Также наоборот, хосты площадки 2 смотрят и на СХД 2 и на СХД1. То есть каждый хост видит обе СХД. Это обязательное условие работы метрокластера.

Само собой, нет надобности каждый хост тянуть оптическим шнурком в другой ЦОД, никаких портов и шнурков не хватит. Все эти соединения должны выполнятся через коммутаторы Ethernet 10G+ или FibreChannel 8G+ (FC только для соединения хостов и СХД для IO, канал репликации пока доступен только по IP (Ethernet 10G+).

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

• Подсеть для репликации, по которой будут синхронизироваться данные между СХД. Их может быть несколько, в данном случае не имеет значения, все зависит от текущей (уже реализованной) топологии сети. Если их две, то, очевидно, должна быть настроена маршрутизация между ними;
• Подсети хранения данных, через которые хосты будут получать доступ к ресурсам СХД (если это iSCSI). Таких подсетей должно быть по одной в каждом ЦОД-е;
• Управляющие подсети, то есть три маршрутизируемые подсети на трех площадках, из которых осуществляется управление СХД, а также там расположен арбитр.

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

Разделение разного трафика по разным подсетям крайне важно (особенно важно отделить реплику от ввода-вывода), поскольку если смешать весь трафик в одну «толстую» подсеть, то этим трафиком будет невозможно управлять, а в условиях двух ЦОД-ов это ещё может вызвать различные варианты сетевых коллизий. В этот вопрос мы в рамках этой статьи сильно погружаться не будем, поскольку о планировании растянутой между ЦОД-ами сети можно почитать на ресурсах производителей сетевого оборудования, где это очень подробно описано.

Конфигурация арбитра

Арбитру необходимо обеспечить доступ ко всем управляющим интерфейсам СХД по протоколам ICMP и SSH. Также следует подумать об отказоустойчивости арбитра. Тут есть нюанс.

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

• Работа метрокластера в штатном режиме не изменится, т.к. арбтир на работу метрокластера в штатном режиме не влияет абсолютно никак (его задача — вовремя переключить нагрузку между ЦОД-ами)
• При этом если арбитр по той или иной причине упадёт и «проспит» аварию в ЦОД-е, то никакого переключения не произойдёт, потому что некому будет отдать нужные команды на переключение и организовать кворум. В этом случае метрокластер превратится в обычную схему с репликацией, которую придется во время катастрофы переключать руками, что повлияет на RTO.

Что из этого следует? Если реально нужно обеспечить минимальный показатель RTO, требуется обеспечить отказоустойчивость арбитра. Для этого есть два варианта:

• Запустить виртуалку с арбитром на отказоустойчивом гипервизоре, благо все взрослые гипервизоры поддерживают отказоустойчивость;
• Если на третьей площадке (в условном офисе) лень ставить нормальный кластер
  нет существующего кластера гиперивозоров, то мы предусмотрели аппаратный вариант арбитра, который выполнен в коробке 2U, в которой работают два обычных x-86 сервера и который может пережить локальный отказ.

Мы настоятельно рекомендуем обеспечить отказоустойчивость арбитра несмотря на то, что в штатном режиме он метрокластеру не нужен. Но как показывает и теория, и практика, если строить действительно надежную катастрофоустойчивую инфраструктуру, то лучше перестраховаться. Лучше защитить себя и бизнес от «закона подлости», то есть от выхода из строя одновременно и арбитра, и одной из площадок, где стоит СХД.

Архитектура решения

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

LUN-ы следует равномерно распределять по двум площадкам, чтобы избегать сильной перегрузки. При этом при сайзинге в обоих ЦОД-ах следует закладывать не только двойной объем (который необходим для хранения данных одновременно на двух СХД), но и двойную производительность в IOPS и MB/s, чтобы не допускать деградации приложений в условиях отказа одного из ЦОД-ов.

Отдельно отметим, что при должном подходе к сайзингу (то есть, при условии, что мы предусмотрели должные верхние границы IOPS и MB/s, а также необходимые ресурсы CPU и RAM) при отказе одной из СХД в метрокластере не будет серьезной просадки производительности в условиях временной работы на одной СХД.

Это объясняется тем, что в условиях работы одновременно двух площадок, работающая синхронная репликация «съедает» половину производительности при записи, поскольку каждую транзакцию нужно записывать на две СХД (аналогично RAID-1/10). Так, при отказе одной из СХД, влияние репликации временно (пока не поднимется отказавшая СХД) пропадает, и мы получаем двукратный прирост производительности на запись. После того, как LUN-ы отказавшей СХД перезапустились на работающей СХД, этот двукратный прирост пропадает за счёт того, что появляется нагрузка с LUN-ов другой СХД, и мы возвращаемся к тому же уровню производительности, который у нас был до «падения», но только в рамках уже одной площадки.

С помощью грамотного сайзинга можно обеспечить условия, при которых отказ целой СХД пользователи не почувствуют совсем. Но ещё раз повторимся, это требует очень внимательного сайзинга, за которым, кстати, можно бесплатно к нам обратиться :-).

Обзор новой архитектуры метрокластера

Всем привет! На связи АЭРОДИСК!

В этой статье мы снова хотим затронуть тему метрокластера. Сегодня мы раскроем подробнее некоторые технические аспекты, расскажем, как менялись архитектурные подходы к реализации логики этого сложного функционала и чем были обоснованы эти изменения, а также обозначим, в каком направлении движемся сейчас.  Послушать про это и позадавать вопросы в режиме онлайн можно будет на вебинаре «Около ИТ», который пройдёт 5 сентября 2023 г. в 15:00
– Регистрируйтесь по ссылке


.

АРБИТР (компьютерная программа)

Текущая версия страницы пока не проверялась
опытными участниками и может значительно отличаться от версии
, проверенной 19 сентября 2022 года; проверки требуют 4 правки
.

Подводим итог

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

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

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

И напоминаем, что ждем вас на нашем вебинаре «Около ИТ» 5 сентября по ссылке

,
на котором мы подробнее расскажем про функционал метрокластера и ответим на ваши вопросы.

Подводим итог

Текущая реализация метрокластера в системах хранения AERODISK Engine N-серии в полной мере позволяет решать задачи, где требуется исключить или минимизировать время простоя ИТ-услуг и обеспечить их работу в режиме 24/7/365 с минимальными трудозатратами.

Спасибо, ждем продуктивной дискуссии.