Минимальным количеством зон отказа для нормального функционирования кластера Кибер Инфраструктура является три зоны. Например, для стандартной организации геораспределенного метро-кластера необходимо три ЦОД.
В случае организации кластера из двух ЦОД возникает ряд проблем с будущей эксплуатацией и отказоустойчивостью, решение которых представлено в данной статье.
При потере одной из двух зон отказа:
- Теряется кворум сервисов Метаданных
- Блокируется запись в хранилище, т.к. остается одна зона отказа из двух
- Кластер остается без избыточности данных
Проблема с кворумом Метаданных решается добавлением одного хоста с минимальным количеством дисков (например, ВМ или неттоп) в третьей зоне отказа с дополнительным сервисом Метаданных.
Для решения проблемы с блокировкой записи в оставшейся зоне отказа и восстановления избыточности данных предлагается один из следующих вариантов.
Решения из данной статьи могут быть применены аналогично к кластеру из двух узлов, а не из двух ЦОД.
В случае использования только сервисов доступа к данным ABGW (Хранилище резервных копий) или S3 (Объектное хранилище) можно настроить гео-репликацию между двумя ЦОД. Такое решение обеспечит два уровня избыточности, одну в каждом из ЦОД и две реплики между ЦОД. Таким образом, при потере ЦОД будет сохранен уровень избыточности данных, который позволит выдержать любой последующий отказ оборудования в оставшемся ЦОД. Однако кластер уже не будет являться метро-кластером, так как репликация между ЦОД является асинхронной и в случае с ABGW в каждый момент времени активным является только один ЦОД.
Разбиение каждого из ЦОД на две логических стойки (в каждой стойке может быть бесконечное число узлов) и выставление зоны отказа 'Стойка' с избыточностью при помощи 3 реплик или кодирования 2+2. В таком случае при отказе ЦОД будет потеряно две зоны отказа из четырех, что гарантирует доступность данных на запись и чтение. Недостатком такого подхода является увеличение издержек на хранение данных на 50% по сравнению, соответственно, с двумя репликами.
В таком варианте, чтобы при потере комнаты (двух стоек) не заблокировалась запись до момента восстановления второй реплики в оставшихся двух стойках, необходимо использовать нестандартную схему репликации 3:1 (с минимальным порогом на запись в 1 реплику). В случае дисков ВМ это можно сделать в консоли на любом узле кластера:
vinfra service compute storage-policy set --replicas 3:1 <Имя политики хранения>
Для обеспечения избыточности данных после потери одного из ЦОД необходимо использовать схему из 4 реплик с минимальным порогом на запись в 2 реплики:
vinfra service compute storage-policy set --replicas 4:2 <Имя политики хранения>
С такой схемой избыточности оставшийся ЦОД сможет выдержать даже последующие отказы внутренних зон без необходимости ожидания восстановления избыточности за счет добавления стоек или возврата второго ЦОД.
Для уменьшения издержек и сохранения при этом избыточности после отказа одного из ЦОД добавьте в каждый ЦОД по 4 логических стойки и используйте схему избыточного кодирования 3+5 (167% издержек вместо 300% при использовании 4 реплик).
Для настройки автоматического восстановления избыточности данных после отказа одного из ЦОД обратитесь к статье 337.
Для настройки эвакуации всех виртуальных машин из отказавшего ЦОД обратитесь к статье 235.
Для возможности записи новых данных в оставшийся после катастрофы ЦОД обратитесь к статье 447.
Разрешить кластеру временами не иметь избыточности для достижения возможности непрерывной записи. См. подробности в этой статье.
После отказа одного из ЦОД нужно вручную понизить зону отказа с 'комната' до 'узел', чтобы кластер начал функционировать в нормальном режиме. После такого действия в кластере появляется достаточное количество зон отказа для функционирования. Недостатком такого подхода является необходимость ручного вмешательства (а следовательно недоступность сервисов на некоторое время после инцидента), а также длительное восстановление кластера, во время которого недопустимы отказы ни одного из узлов оставшегося ЦОД.
В случае кластера из двух узлов, нужно менять зону отказа с 'узел' на 'диск' в данном варианте решения.
Выставление параметра mds.alloc.strict_failure_domain=0 для хранилища. Это позволит хранилищу автоматически понизить зону отказа на 'узел' в случае отказа одной из комнат.
# vstorage -c $(cat /mnt/vstorage/.vstorage.info/clustername) set-config mds.alloc.strict_failure_domain=0
У данного подхода есть ряд следующих сопутствующих недостатков:
- Нет 100% гарантии что данные точно будут зареплицированы полностью. В ходе жизни кластера часть реплик может быть вытеснена больше на один из ЦОД по различным причинам и в случае отказа одного из ЦОД могут быть потеряны данные (если на одной стороне была частичная деградация и часть реплик или все были недоступны, и эта сторона была в полу-рабочем состоянии). Т.е. после любой деградации в кластере необходимо активировать опцию в значение 1 и после восстановления снова выставлять значение 0.
- Автоматически данные не переедут назад после восстановление зоны отказа. Нужно активировать опцию в значение 1 и после восстановления снова выставлять значение 0.