Привет, Хабр! Меня зовут Андрей Капустин, я менеджер продукта в компании VK Tech. Для построения систем хранения и обработки данных по объектам мы часто используем различные СУБД, которые объединяем в большие геораспределенные кластеры. Кластер СУБД содержит данные, необходимые для функционирования Mission Critical процессов, поэтому нам необходимо гарантировать постоянную доступность, обеспечить отсутствие потерь и минимизировать время предоставления данных по запросу.

Прочитав эту статью, вы узнаете, как в геораспределенном кластере СУБД Tarantool реализуются механизмы отказоустойчивости и обеспечивается гарантия защиты данных: 

• если есть ошибки при проведении регламентных работ;

• при чрезвычайных ситуациях, приводящих к полной недоступности ЦОДа / серверного оборудования или нарушению сетевой связности;

• если есть ошибки при разработке прикладного ПО, приводящие к полной недоступности кластера СУБД.

Отказоустойчивость

Основной механизм повышения надежности сервисов — это добавление в архитектуру резервных копий (реплик) данных, которые объединяются в репликасет внутри кластера БД. СУБД обеспечивает механизм выбора мастера в репликасете (например, по алгоритму RAFT) и выполнение репликации данных «мастер-реплика» в синхронном или асинхронном режиме. 

Уровень надежности СУБД можно оценить на основе параметров: 

• RPO (Recovery Point Objective) — максимальный период, за который допустимо потерять данные во время сбоя. Другими словами, это предельное время задержки в репликации данных внутри кластера.

• RTO (Recovery Time Objective) — максимальный период, в течение которого система может быть недоступной во время сбоя. Другими словами, это предельное время, за которое мы должны восстановить доступность ИТ-сервисов для клиентов после сбоя. 

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

В идеальном мире мы должны стремиться к значениям RPO = 0, RTO = 0, но на практике всегда есть ограничения, которые мы можем минимизировать, в том числе выбирая способ репликации данных. 

Ниже мы рассмотрим варианты репликации, поддерживаемые в кластере СУБД Tarantool. 

Асинхронная репликация Tarantool 

Последовательность действий: 

1. Приложение отправляет транзакцию в мастер-ноду А1.

2. Мастер А1 выполняет COMMIT, добавляет транзакцию в WAL и уведомляет приложение.

3. Транзакция из WAL-ноды А1 реплицируется во все реплики в кластере.

4. Реплика А2 подтверждает добавление транзакции.

5. Реплика А3 подтверждает добавление транзакции.

6. Реплика А4 подтверждает добавление транзакции.

Преимущества: 

• Максимальная скорость работы кластера, так как для выполнения COMMIT не требуется ждать репликации данных по всему кластеру.

• Минимальные задержки, так как лаг репликации для ноды зависит только от скорости передачи данных в эту конкретную реплику.

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

Недостатки: 

• RPO > 0, так как возможна потеря данных при отказе мастера до момента, когда одна из реплик станет новым мастером.

• RTO > 0, так как необходимо время для переключения на новый мастер при отказе старого.

• Изменение топологии/конфигурации кластера требует остановки работы всего кластера СУБД.

Синхронная репликация Tarantool 

Последовательность действий: 

1. Приложение отправляет транзакцию в мастер-ноду А1.

2. Мастер А1 добавляет транзакцию в WAL и реплицирует во все реплики в кластере.

3. Реплика А2 подтверждает добавление транзакции.

4. Реплика А3 подтверждает добавление транзакции.

5. Реплика А4 подтверждает добавление транзакции.

6. Мастер А1 собирает кворум — должно быть получено N/2+1 подтверждений от реплик кластера, после чего выполняет COMMIT (если кворум не достигнут, то происходит ROLLBACK) транзакции и уведомляет приложение. 

Преимущества: 

• RPO = 0, то есть при синхронной репликации потери данных в кластере отсутствуют.

Недостатки: 

• Непредсказуемое время обработки транзакции, так как необходимо собрать кворум от реплик.

• Снижение общей скорости работы кластера, так как любая реплика может стать узким местом.

• Отсутствие кворума приводит к полной остановке записи данных в кластер.

• RTO > 0, так как необходимо время для переключения на новый мастер при отказе старого.

Катастрофоустойчивость

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

Очевидно, что для обеспечения катастрофоустойчивости нам необходимо резервировать кластер целиком. Таким образом, нам необходимы как минимум два независимых кластера СУБД, для которых требуется наличие механизмов синхронизации данных и правила Stand-in-замены/переключения мастера с минимальным RTO. 

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

Tarantool Clusters Federation

Продукт Tarantool Clusters Federation (TCF) — решение класса xDCR (Cross Data Center Replication) для межЦОДовой асинхронной репликации данных между кластерами СУБД Tarantool. 

Инсталляция TCF управляет парой идентичных кластеров Tarantool и в каждый момент времени определяет, какой кластер выполняет функции мастера (Active): 

• Кластер в статусе Active принимает запросы от приложения.

• Кластер в статусе Passive содержит копию данных мастер-кластера. 

Состояния кластеров позволяют управлять переключением трафика между ними.

При переключении трафика с одного кластера на другой состояния кластеров меняются на противоположные. Так, активный кластер становится пассивным, а пассивный — активным. 

Непосредственно изменяет статус кластера с Active на Passive Lua-роль TCF — Worker. Он должен быть запущен на каждом инстансе обоих кластеров, что позволяет одновременно переводить статус Passive → Active для резервного кластера.

Стать активным может только работоспособный (здоровый) кластер. 

Изменение состояния кластера

В TCF существует два способа переключения состояния кластеров: 

• Ручная смена — если требуется явно переключить состояния у работоспособных кластеров (например, при восстановлении после аварии): 

  • через стандартный End-point в HTTP API;

  • по кнопке в WEB GUI.

• Автоматическая смена — если Coordinator обнаружил неполадки на активном кластере: 

  • Для мониторинга состояния кластеров TCF использует внешний State provider на базе ETCD или Tarantool.

  • Coordinator взаимодействует с внешним State provider для определения состояния инстансов Storages и Routers: 

    • в случае ETCD — через http-запросы;

    • для Tarantool Config Storage используются iproto-запросы.

  • В кластере должен быть здоров хотя бы один роутер, и этот роутер является мастером своего репликасета.

  • У каждого репликасета в кластере должен быть работоспособный мастер-узел.

Компоненты TCF

Репликацию данных между парой кластеров выполняют входящие в состав TCF GO-компоненты Gateway и Destination, которые разворачиваются отдельно от кластера СУБД. 

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

Для обеспечения бесперебойной репликации в случае отказа Gateway/Destination рекомендуется развернуть несколько экземпляров каждого компонента, но активным в каждый момент времени будет только одна пара Gateway — Destination, выполняющая репликацию из Active в Passive: 

1. Gateway работает с активным кластером: 

   • подключается к кластеру Tarantool как анонимная реплика;

   • читает репликационный поток с инстансов типа Storage.

2. Destination работает с резервным кластером: 

   • получает данные из Gateway;

   • анализирует полученный bucket_id для каждой транзакции;

   • через инстансы типа Router получает информацию о топологии;

   • маршрутизирует данные на инстансы типа Storage в соответствии с bucket_id.

Схемы репликации с помощью TCF

Давайте разберем типовые топологии распределенных кластеров СУБД и способы обеспечения отказоустойчивости c использованием TCF.

Два локальных кластера в двух ЦОД

Это базовая схема использования TCF, когда в пару к работающему кластеру мы добавляем идентичный Stand-in-кластер в другом ЦОДе. 

Далее мы связываем кластеры через конфигурационный файл TCF и выбираем мастера. 

По умолчанию работает пара Gateway-1/Destination-1, при переключении мастера трафик автоматически переключается на пару Gateway-2/Destination-2. 

Идентичными мы считаем кластеры при соблюдении следующих условий: 

• Одинаковая схема данных 

  • Для Key-value СУБД необходимо совпадение структуры таблиц БД для обязательных полей.

  • «Хвост» необязательных полей будет реплицирован из мастера AS IS.

• Одинаковое количество бакетов

  • Распределение бакетов по инстансам внутри кластера зависит только от Affinity-функции модуля шардирования (v_shard), поэтому для TCF достаточно наличия всех bucket_id в обоих кластерах — количество Storage может не совпадать (см. схему ниже).

  • Ребаллансинг bucket_id между инстансами активного кластера можно выполнять без остановки TCF.

Два кластера в трех ЦОДах

В большинстве случаев основной (мастер) кластер расположен в нескольких ЦОДах, то есть кластер является растянутым — это своего рода отраслевой Best practice в финтехе. 

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

В Казахстане это требование уже закреплено законодательно. 

В итоге мы получаем растянутый мастер-кластер в двух близких ЦОДах и сильно удаленный резервный кластер с репликацией через TCF (см. схему ниже): 

TCF — это решение класса xDCR для построения отказоустойчивой инфраструктуры кластеров Tarantool. Продукт прошел сертификацию ФСТЭК и внесен в Реестр российского ПО (РРПО). 

TCF из коробки обеспечивает надежность функционирования распределенных мультиЦОДовых кластеров на базе основных БД Tarantool (Tarantool DataBase, Tarantool Data Grid), а также может использоваться как инструмент миграции данных при переводе текущих инсталляций на базе Cartridge-приложений на новые версии продуктов экосистемы Tarantool Enterprise Edition 3.x. 

Закажите демо, чтобы протестировать все функции. И подписывайтесь на канал Tarantool в телеграме, чтобы читать все актуальные новости и практические советы.