Сценарии использования Picodata

Данная статья содержит общий обзор типовых сценариев использования Picodata со следующих позиций:

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

Серверы и экземпляры СУБД

Каждый экземпляр СУБД Picodata требует для работы отдельное ядро ЦП. Каждый вычислительный узел (сервер) имеет, как правило, множество ядер ЦП, что позволяет реализовывать разные варианты топологии кластера СУБД. Ниже описаны типовые схемы развёртывания экземпляров СУБД на серверах.

Один сервер, один кластер

Данный вариант соответствует сценарию локального запуска Picodata на одном сервере. У такого кластера будут следующие свойства:

• удобный способ протестировать функции Picodata
• удобство настройки и администрирования кластера
• отсутствие сохранности данных при выходе из строя сервера

Несколько серверов, один кластер

Стандартный вариант организации распределённого кластера СУБД. При использовании репликации (например, с фактором 2), кластер будет иметь следующие свойства:

• шардирование таблиц по разным экземплярам СУБД
• сохранность данных при отказе одного сервера
• горизонтальное масштабирование кластера за счёт добавления серверов

Варианты геораспределённого развёртывания

Программное обеспечение Picodata предназначено для геораспределённого катастрофоустойчивого внедрения. Для этого кластер СУБД следует развёрнуть так, чтобы недоступность или потеря части узлов не приводила к выходу из строя всего кластера.

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

Отказоустойчивость распределённой СУБД

Механизм отказоустойчивости в Picodata основан на поддержании кворума в Raft-группе с помощью голосующих узлов. Максимальное число голосующих узлов в любом кластере — 5. Варианты распределения узлов между локациями лежат в основе разных сценариев геораспределённого использования Picodata. Основой данного подхода является распределение узлов кластера между несколькими датацентрами. Рассмотрим основные варианты такого распределения.

Два датацентра и вынесенный арбитр

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

• при выходе из строя 1 из датацентров с данными: оставшийся датацентр и вынесенный арбитр поддерживают кворум в Raft, кластер сохраняет доступность несмотря на потерю части узлов
• при выходе из строя вынесенного арбитра: никакие данные не теряются, в кластере сохраняется кворум Raft, у администратора СУБД есть возможность восстановить топологию кластера путём добавления нового арбитра

Основное преимущество этого подхода состоит в том, что даже при отказе одного из дата центров кластер не теряется управляемости: то есть, способности добавлять и удалять узлы. Таким образом, у администратора сохраняется возможность восстановить кластер из деградированного состояния: заменить выбывшие из строя узлы, удалив их из кластера командой picodata expel и добавив вместо них узлы в доступной локации.

Три датацентра

Хранящиеся в кластере данные располагаются в трёх датацентрах, два из которых содержит по 2 голосующих узла, и третий — 1 голосующий узел. Данная конфигурация похожа на предыдущую (общим количеством локаций), но имеет важное отличие:

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

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

Обработка отказов

Варианты отказов

Отказы разных типов и уровней оказывают различное влияние на работоспособность кластера и доступность его узлов. Полная доступность узла предполагает соблюдение следующих критериев:

• узел участвует в маршрутизации запросов в кластере
• возможность читать и изменять данные на узле
• доступность команд администрирования.

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

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

	Последствие	Минимальная доступность узла	Как починить	Требуется перезапуск инстанса?
Переполнение файловой системы	Невозможно сохранять WAL-журналы и снэпшот-файлы инстанса	✅	Освободить место на диске	❌
Отказ жёсткого диска	Невозможно сохранять WAL-журналы и снэпшот-файлы инстанса	✅	Замена диска, переинициализация (rebootstrap) инстанса на сервере	✅
Временная потеря сетевой связности с инстансом на стороне клиента	Выпадение инстанса из кластера, задействование реплики на другом узле	❌	Восстановить доступ к инстансу по сети, инстанс сам вернётся в кластер в роли follower	❌
Отказ сетевой карты/маршрутизатора на стороне сервера	Выпадение инстанса из кластера, задействование реплики на другом узле	❌	Восстановление оборудования, перезапуск сервера и инстанса	✅

Защита от приведённых выше отказов предполагает резервирование, соответственно, накопителя в сервере, самого сервера, серверной стойки или же всего датацентра, в котором они размещены.

Варианты развёртывания

Ниже приведена таблица, в которой указаны вариант развёртывания кластера Picodata с точки зрения устойчивости к разным видам отказов. Слева направо растёт масштаб аварии, а сверху вниз — уровень защиты схемы развёртывания. Предполагается, что реплики данных и голосующие узлы разнесены по разным физическим серверам и что кластер сохраняет Raft-кворум.

Схема резервирования	Отказ экземпляра СУБД	Отказ сервера	Отказ стойки / локальной сети / питания в ДЦ	Отказ целого ДЦ	Вывод
Любое количество узлов кластера на одном сервере	✅	❌	❌	❌	Один сервер остаётся единым доменом отказа: его потеря останавливает весь кластер.
Несколько серверов в одном ДЦ	✅	✅	🟡	❌	Компромиссная схема: защищает от локальных отказов, но не от потери всего ДЦ.
Три и более ДЦ	✅	✅	✅	✅	Наиболее надёжная схема: переживает потерю одного ДЦ и сохраняет доступность кластера.

✅ — кластер сохраняет кворум и продолжает работать автоматически.

🟡 — защита зависит от того, насколько реплики разнесены по разным серверам и стойкам; часть сценариев приводит к деградации, например к режиму read-only.

❌ — отказ этого уровня остаётся общим доменом отказа для всей схемы.

Здесь под отказом сервера понимаются, например, отказ диска, потеря питания или отказ сетевой карты, а под отказом ДЦ — потеря питания или сети всего датацентра.