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

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

Требования к подсистеме питания

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

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

Схема питанияТребования к сетевой подсистеме

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

  1. отказоустойчивость соединений;
  2. отказоустойчивость коммутаторов.

Отказоустойчивость соединений достигается за счет избыточности сетевых каналов сервер-коммутаторов. Избыточность достигается дублированием физических каналов. Для упрощения управления каналами несколько физических каналов рассматриваются как один логический. Такая технология называется агрегированием каналов.

Для осуществления агрегирования в сетях Ethernet разработан протокол LACP (Link Aggregation Control Protocol). Агрегированные каналы LACP используются как для повышения пропускной способности, так и для повышения отказоустойчивости. Использование LACP в некоторых случаях позволяет обнаружить повреждённый канал, который при использовании обычной статической агрегации обнаружен бы не был. Описывается стандартом IEEE 802.3ad.
LACP

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

STP+LACP
Для такой конфигурации требуется задействовать алгоритм связующего дерева (Spanning-Tree Algorithm) на обоих коммутаторах. Это позволит гарантировать, что только одно соединение будет в данный момент активным. Таким образом, предотвращается ситуация, когда пакеты начинают циркулировать между соединениями.

Распределенное агрегирование

Для реализации агрегирования каналов при подключении через разные коммутаторы не
существует единого стандарта. В коммутаторах Hewlett-Packard серий 2920, 3500, 8200, поддерживается распределенное агрегирование портов. Распределенное агрегирование позволяет объединять порты, которые находятся на разных коммутаторах. С помощью сообщений проприетарного протокола, пара коммутаторов согласовывает настройки и для остальных устройств распределенный агрегат выглядит как агрегат с одним коммутатором[2].

HP LACPНа каждом из пары коммутаторов, между которыми настраивается распределенный транк должны быть настроены два специальных интерфейса:

  • ISC-интерфейс (InterSwitch-Connect) — через этот интерфейс коммутаторы обмениваются информацией для того, чтобы пара коммутаторов для других устройств выглядела как один коммутатор. Это может быть один физический интерфейс или агрегат.
  • Keepalive-интерфейс — интерфейс 3-его уровня, который используется для передачи сообщений keepalive при падении ISC-интерфейса, для того чтобы определить вышел из строя ISC-интерфейс или весь коммутатор.

Ограничения распределенного агрегирования:

  • можно настроить только между двумя коммутаторами;
  • на каждом из коммутаторов в одном распределенном транке может быть не более 4 портов;
  • может быть настроено только в статическом режиме: LACP или без протокола.

Изолированные подсети

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

  1. сетевой обмер прикладных задач может негативно сказываться на скорости работы разделяемых хранилищ данных;
  2. сетевые сбои прикладных приложений могут привести к нарушениям функционирования ПО управления кластером;
  3. невозможность использования IP-адресов в качестве управляемого ресурса кластера.

Преодоление данных проблем возможно путём сегментирования и изоляции трех функциональных подсетей: прикладной, управления, хранилища данных. В сеть управления включаются, помимо серверов, устройства фенсинга: БРП, IPMI. Данный сегмент обслуживает только ПО кластера высокой готовности. Сеть хранилища данных объединят все устройства хранения данных (SAN, NAS).

Сегменты сети рекомендуется изолировать физически, т.е. использовать независимые сети с выделенным сетевым оборудованием. В случае невозможности физического изолирования необходимо использовать логическое разделение на основе VLAN, с настройкой QoS для разных сегментов.

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

Требования к вычислительным узлам

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

Электропитание. Для обеспечения требований отказоустойчивости по питанию
каждый сервер должен быть оснащён двумя блоками питания. Каждый блок питания должен быть достаточной мощности для работы сервера в случае отказа второго блока питания. Также необходима функция горячей замены блока питания без выключения сервера.

Подсистема хранения. При отсутствии выделенной системы хранения данных
должна обеспечиваться отказоустойчивая конфигурация подсистемы хранения. Рекомендуется использовать RAID массив в отказоустойчивой конфигурации (уровни 1, 6) с безбатарейным дублёром кэшем (на основе флеш-памяти).

Сеть. Для обеспечения сетевой избыточности необходимо как минимум два сетевых интерфейса Ethernet, обладающих одинаковыми характеристиками. При использовании сетевого агрегирования рекомендуется объединять сетевые интерфейсы с различных сетевых плат. Такая схема устойчива к отказу одной из сетевых плат или PCI(PCI-E) моста.

Фенсинг

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

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

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

Узловой фенсинг

Узловой фенсинг может производиться следующими устройствами:

  1. источником бесперебойного питания;
  2. управляемым распределителем питания;
  3. устройством управления серверами-лезвиями;
  4. интерфейсом удаленного управления (IPMI, IBM RSA, HP iLO, Dell DRAC).

Подключение к перечисленным устройствам, как правило, производится по нерезервируемому интерфейсу Ethernet. При отказе сетевого коммутатора, к которому подключены устройства, следует отказ подсистемы фенсинга. Для повышения надежности подсистемы необходимо наличие резервной цепочки фенсинга. Распространенным вариантом является использование в качестве основного канала интерфейса удаленного управления (IPMI), а в качестве резервного — управляемого распределителя питания.

0 комментариев

Что у нас
нового

Блог

«Моно» для Astra Linux Special Edition 1.7

2 марта 2022

Выпущена версия программного комплекса «Моно» для Astra Linux Special Edition 1.7. 

ГосJava 2020.3

1 августа 2020

Команда Лаборатории 50 подготовила сборку ГосJava версии 2020.3.

Наши
контакты

Связаться с нами

Телефон 8 (812) 981-68-09
Электронная почта team@lab50.net





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