Кластер высокой доступности

Кластер Arkvory продолжает работать, когда отказывает один сервер площадки. Два или три Linux-сервера держат одинаковую копию одного блочного тома. Один сервер активный — на нём работает Arkvory. Если он отказывает, менеджер кластера изолирует его (fencing) и запускает Arkvory на другом сервере с теми же данными.

Кластер защищает от потери сервера, диска или сетевого канала внутри одной площадки. От потери всей площадки он не защищает: для этого держите зеркала на другой площадке и резервные копии вне кластера.

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

• Один том, синхронные копии. DRBD 9 копирует каждую запись тома на другие серверы до того, как запись завершится (protocol C). На томе лежит вся установка: база данных, хранилище, конфигурация и релизы. Каталог и байты файлов не расходятся.
• Где работает Arkvory, решает Pacemaker. Corosync и Pacemaker держат кворум, выбирают активный сервер и запускают по порядку: том, файловую систему, службы в том виде, в каком они сохранены на томе (arkvory-units), базу данных, arkvory-replica, API, worker, агента резервных копий, таймер обновлений и виртуальный IP-адрес. Собственных выборов у Arkvory нет.
• Fencing обязателен. Прежде чем другой сервер примет работу, Pacemaker выключает отказавший сервер через устройство питания (IPMI, iDRAC, iLO, Redfish, PDU) или гипервизор. Без fencing два сервера могли бы писать одновременно. Кластер без fencing не запускается.
• Две копии для каждой подтверждённой записи. Arkvory отвечает на запись успехом, только когда она лежит минимум в двух полных копиях (см. Запись). Когда копии не хватает, запись останавливается, а чтение продолжается.

Профиль	Серверы с данными	Свидетель	Когда отказывает один сервер с данными
ha-2	2	обязателен: небольшой сервер без данных, на нём corosync-qnetd и tiebreaker DRBD	Запись стоит до возврата сервера или решения оператора
ha-3	3	не нужен: три сервера решают большинством	Запись продолжается: остаются две копии

Рекомендуемый профиль — ha-3. ha-2 дешевле и честно останавливает запись вместо того, чтобы держать данные в одной копии.

Кластер работает с нативными пакетами Linux. Установки на Windows и в Docker Compose остаются отдельными серверами с зеркалами и резервными копиями.

Запись и копии

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

Каждый запрос, который меняет данные (HTTP API, реестр контейнеров, Git LFS, npm), проверяется дважды:

• до выполнения — по копиям за последнюю секунду;
• после фиксации и синхронизации данных — по свежему чтению состояния тома.

Когда полных копий меньше, чем нужно записи, клиент получает HTTP 503 с кодом unavailable, причиной replication_degraded и заголовком Retry-After, но никогда не 2xx. Статус задачи завершения загрузки (GET /api/v1/jobs/{id}) проверяется так же: по нему клиент узнаёт, что большая загрузка опубликована.

503 после фиксации означает, что операция может лежать только в одной копии. Повторите запрос с тем же Idempotency-Key: повтор вернёт уже существующий результат, а его 2xx подтвердит его, как только снова будут две копии.

Чтение, скачивание, консоль, вход и выход, отзыв и пакетный запрос Git LFS работают, пока запись остановлена.

Администратор, вошедший в консоль, видит баннер, пока запись остановлена или действует решение об одной копии.

Требования

• Два или три сервера с данными с одинаковым дистрибутивом Linux, одной версией пакета Arkvory и диском (или логическим томом) полного размера для тома на каждом. Рассчитывайте на всё хранилище плюс базу данных.
• Для ha-2 — третий небольшой сервер-свидетель. Диск для данных ему не нужен, Arkvory на нём не работает.
• Сеть между серверами с малой задержкой. Каждая запись ждёт остальные серверы, поэтому задержка добавляется к каждой записи. По возможности используйте выделенный канал.
• DRBD 9 (модуль ядра и drbd-utils 9; многие дистрибутивы поставляют старый модуль 8.4, поэтому берите пакеты LINBIT), pacemaker, pcs, corosync, resource-agents (в Ubuntu — resource-agents-base и resource-agents-extra), агенты fencing для вашего оборудования. Для ha-2: corosync-qdevice на серверах с данными и corosync-qnetd на свидетеле.
• Устройство fencing для каждого сервера с данными и учётные данные к нему.
• Свободный IP-адрес в сети серверов. Клиенты подключаются к этому виртуальному адресу.
• TLS-сертификат для виртуального адреса. Храните сертификат и ключ на томе, чтобы каждый сервер находил их по одному пути.

Сборка кластера

Команды ниже используют имя ресурса по умолчанию arkvory, каталог установки /opt/proanima-arkvory и /dev/vg0/arkvory как диск под томом. Выполняйте их от root.

1. На каждом сервере с данными распакуйте пакет Arkvory, не устанавливая его. Это добавит файлы и команду arkvory и ничего не создаст в /opt/proanima-arkvory:

   dpkg --unpack Arkvory-amd64.deb

   С пакетом RPM установите файлы, не выполняя его скрипты: rpm -i --noscripts Arkvory-x86_64.rpm. На первом сервере вы вместо этого установите пакет обычным образом на шаге 5, поэтому план на шаге 2 составьте на другом сервере с данными.

2. На одном сервере с данными составьте план. Он запишет ресурс DRBD и команды Pacemaker в каталог для проверки:

   arkvory cluster-plan --cluster ha-2 \
     --nodes node-a=10.0.0.11,node-b=10.0.0.12 --witness witness=10.0.0.13 \
     --disk /dev/vg0/arkvory --fence-agent fence_ipmilan \
     --virtual-ip 10.0.0.100/24 --output /root/arkvory-plan

   Для ha-3 перечислите в --nodes три сервера и не указывайте --witness. Необязательные параметры: --cluster-resource, --drbd-minor (по умолчанию 0), --drbd-port (по умолчанию 7789), --filesystem (xfs или ext4, по умолчанию xfs). Имена должны совпадать с именами хостов серверов. Адреса — IPv4.

3. Скопируйте arkvory.res в /etc/drbd.d/ на каждый сервер, включая свидетеля. Создайте метаданные на серверах с данными и поднимите ресурс везде:

   drbdadm create-md arkvory   # только серверы с данными
   drbdadm up arkvory          # каждый сервер

   На свидетеле также выполните systemctl enable drbd@arkvory.service, чтобы tiebreaker поднимался после перезапуска.

   План позволяет вернувшейся копии ресинхронизироваться не медленнее 20 МБ/с даже под нагрузкой записи и не быстрее 1 ГБ/с. Задайте c-min-rate и c-max-rate в секции disk под пропускную способность канала репликации.

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

   drbdadm new-current-uuid --clear-bitmap arkvory/0
   drbdadm primary arkvory
   mkfs.xfs /dev/drbd0
   mkdir -p /opt/proanima-arkvory && mount /dev/drbd0 /opt/proanima-arkvory

5. Установите Arkvory на смонтированный том (с RPM: rpm -i Arkvory-x86_64.rpm вместо dpkg --configure), положите на том файлы TLS и включите режим кластера:

   dpkg --configure proanima-arkvory
   install -d -m 0750 -o root -g arkvory /opt/proanima-arkvory/config/tls
   install -m 0644 tls.crt /opt/proanima-arkvory/config/tls/tls.crt
   install -m 0640 -g arkvory tls.key /opt/proanima-arkvory/config/tls/tls.key
   arkvory configure --root /opt/proanima-arkvory --tls-cert /opt/proanima-arkvory/config/tls/tls.crt --tls-key /opt/proanima-arkvory/config/tls/tls.key --listen-host 0.0.0.0
   arkvory configure --root /opt/proanima-arkvory --cluster ha-2

   configure --cluster проверяет, что каталог установки — смонтированное устройство DRBD, что этот сервер основной и что полны хотя бы две копии. Команда запускает arkvory-replica, включает подтверждение записи только при двух полных копиях и отключает автозапуск служб Arkvory: дальше их запускает Pacemaker. Если шаг не удался, восстанавливается конфигурация отдельного сервера.

6. Остановите Arkvory на первом сервере и освободите том:

   arkvory cluster-release --root /opt/proanima-arkvory

   Команда по порядку останавливает службы Arkvory, отмонтирует том и делает этот сервер вторичным.

7. На каждом другом сервере с данными по очереди подготовьте сервер:

   arkvory cluster-node --root /opt/proanima-arkvory
   dpkg --configure proanima-arkvory   # только .deb; с RPM больше ничего не нужно

   cluster-node берёт том, подготавливает сервер и снова освобождает том, даже если шаг не удался; сообщается первая ошибка. --cluster-resource нужен, только если ресурс называется не arkvory. Команда отказывается работать на сервере, который уже обслуживает кластер со смонтированным томом (сначала освободите том командой cluster-release), и пока Pacemaker управляет группой Arkvory, потому что тогда том принадлежит кластеру: добавляйте сервер в работающий кластер, как описано в разделе Замена сервера. cluster-node создаёт служебные учётные записи с теми же идентификаторами пользователя и группы, что на первом сервере (файлы на томе принадлежат им), и устанавливает те же службы без автозапуска. Если учётная запись уже есть с другими идентификаторами, команда останавливается и говорит, какие идентификаторы задать. Каждый раз, когда сервер становится активным, arkvory-units сначала берёт службы с тома, поэтому настройки, изменённые позже на активном сервере (например, хранилище резервных копий), действуют и после переключения.

8. Настройте кластер Corosync через pcs на серверах с данными (pcs host auth, pcs cluster setup, pcs cluster start --all). В Debian и Ubuntu сначала выполните pcs cluster destroy на каждом сервере с данными: пакеты устанавливают образец конфигурации Corosync, который pcs принимает за существующий кластер. Не выполняйте pcs cluster enable: изолированный сервер должен возвращаться в кластер, только когда его запускаете вы. Для ha-2 также аутентифицируйте свидетеля и выполните на нём pcs qdevice setup model net --enable --start. В Debian и Ubuntu пакет уже настроил устройство кворума для своей служебной учётной записи: вместо этого выполните там systemctl enable --now corosync-qnetd.

9. Откройте /root/arkvory-plan/pacemaker.sh. Замените каждый <agent parameters: …> параметрами вашего устройства fencing: его адресом, логином, файлом пароля или ключом и розеткой или портом этого сервера. Затем выполните скрипт на одном сервере с данными:

   sh /root/arkvory-plan/pacemaker.sh

   Скрипт собирает всю конфигурацию в файле и применяет её разом: fencing, политику кворума, ресурс DRBD, группу Arkvory и её ограничения.

10. Проверьте кластер на активном сервере:

    arkvory cluster-check --root /opt/proanima-arkvory

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

11. Один раз докажите fencing: изолируйте каждый резервный сервер и дождитесь его возвращения (см. Проверка fencing).

Направьте клиентов и DNS-имя на виртуальный адрес.

Повседневная работа

Выполняйте эти команды от root. cluster-status, cluster-single-copy и cluster-kit читают том, поэтому запускайте их на активном сервере; cluster-check, cluster-switchover и cluster-fence-test работают на любом сервере с данными.

Команда	Что делает
arkvory cluster-status --root <dir>	Профиль, роль этого сервера, полные и требуемые копии и решение оператора, если есть, — в JSON
arkvory cluster-check --root <dir>	Все проверки здорового кластера; завершается с ошибкой, если одна не прошла
arkvory cluster-switchover --root <dir> --to <server>	Плановый перенос Arkvory на другой сервер с данными; отказ, если у целевого сервера нет полной копии
arkvory cluster-fence-test --root <dir> --node <standby> [--yes]	Изолирует резервный сервер, чтобы доказать его устройство fencing; активный сервер не принимается
arkvory cluster-single-copy --root <dir> --until <time> --reason <text>	Разрешает запись в одну копию до срока; см. Одна копия
arkvory cluster-kit --root <dir> --output <file>	На активном сервере: файл, который нужен новому серверу для подключения; см. Замена сервера
arkvory cluster-node --root <dir> --kit <file>	На новом сервере: подключает его по этому файлу, не беря том

pcs status показывает кластер так, как его видит Pacemaker.

В консоли

Администраторы находят Кластер в меню кластерной установки. Страница показывает схему кластера, сервер, который обслуживает сейчас, полные копии, принимается ли запись, и каждый другой сервер с его соединением и копией (Полная, Догоняет или Отсутствует). Ниже Что дальше называет один шаг, подходящий к текущему состоянию, с его командой: плановое переключение, пока все копии полные, возврат или замену сервера, пока копии не хватает (и в ha-3, пока запись идёт с двумя копиями), и способ завершить решение об одной копии. Страница сама обновляется каждые 15 секунд.

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

Плановое переключение

cluster-switchover просит Pacemaker перенести группу, ждёт до 5 минут, пока Arkvory заработает на целевом сервере, и затем снимает временное правило размещения. Команда отклоняется, пока у целевого сервера нет собственной полной копии, например пока он ресинхронизируется. Соединения со старым сервером во время переноса рвутся, клиенты повторяют запросы. Обратно Arkvory сам не переезжает.

Проверка fencing

cluster-fence-test сначала выполняет проверки cluster-check и отказывается работать, если одна из них не прошла. В ha-2 изоляция единственного резервного сервера останавливает запись, пока он не вернётся, поэтому команда также требует --yes. Она перезапускает резервный сервер через его устройство fencing. После перезапуска запустите на этом сервере кластер командой pcs cluster start. Службы кластера после перезапуска сами не стартуют (шаг 8 из Сборки кластера), поэтому изолированный сервер без вас не вернётся.

Обновления

Установите новый пакет на каждый сервер с данными. На резервных серверах пакет только заменяет файлы программы, потому что релиз лежит на томе. На активном сервере пакет применяет релиз: Arkvory просит Pacemaker не трогать группу, останавливает службы, выполняет миграции, запускает службы, ждёт готовности и возвращает группу Pacemaker. Автоматические обновления на активном сервере работают так же. Если не удались и обновление, и его откат, группа остаётся без управления Pacemaker и переключения не происходит: устраните причину, затем выполните pcs resource cleanup arkvory и pcs resource manage arkvory.

Не запускайте и не останавливайте службы Arkvory через systemctl на сервере кластера: Pacemaker сочтёт это отказом. Для плановой остановки всей службы используйте pcs resource disable arkvory и pcs resource enable arkvory.

Отказы

Что произошло	ha-2	ha-3
Отказал резервный сервер	Изолирован. Чтение продолжается, запись получает 503 replication_degraded	Изолирован. Чтение и запись продолжаются
Отказал активный сервер	Изолирован, Arkvory запускается на другом сервере. Чтение возвращается, запись ждёт вторую копию	Изолирован, Arkvory запускается на другом сервере. Чтение и запись возвращаются
Разрыв сети между серверами с данными	Свидетель отдаёт кворум одной стороне, другая изолируется. Двух писателей не бывает	Сторона большинства продолжает, другой сервер изолируется
Отказали два участника из трёх (в ha-2 — сервер с данными и свидетель)	У последнего сервера нет кворума: Arkvory останавливается. Писателя без кворума не бывает. Верните серверы (см. ниже)	Так же для двух серверов с данными
Fencing не работает	Переключения нет. Arkvory остаётся остановленным, пока fencing не пройдёт	Так же

Чтобы вернуть изолированный сервер:

1. Устраните причину и включите сервер.
2. Выполните на нём pcs cluster start.
3. Том ресинхронизирует изменённые блоки. Запись возобновится сама, когда снова будут все нужные полные копии; ход показывает arkvory cluster-status.

После потери кворума запустите кластер на каждом вернувшемся сервере. Pacemaker снова запустит Arkvory на сервере с самой свежей копией. Сервер, потерявший кворум последним, по пути может быть изолирован ещё раз, потому что не смог остановиться чисто: после его перезапуска снова запустите на нём кластер.

Если fencing не сработал и вы его починили, очистите неудачные попытки на работающем сервере, чтобы Pacemaker попробовал снова: pcs stonith history cleanup <server> и pcs resource cleanup.

Замена сервера

Если сервер с данными потерян навсегда, замените его новым с тем же именем и адресом. Arkvory всё это время продолжает работать на активном сервере; запись возобновится, когда новая копия станет полной.

1. На новом сервере установите тот же дистрибутив Linux, DRBD, Pacemaker и агенты fencing и распакуйте ту же версию пакета Arkvory, как на шаге 1 из Сборки кластера. Для ha-2 также установите corosync-qdevice.

2. На активном сервере запишите файл, который нужен новому серверу: имя ресурса, идентификаторы служебных учётных записей и службы.

   arkvory cluster-kit --root /opt/proanima-arkvory --output /root/arkvory-node.kit

   Скопируйте его на новый сервер по защищённому каналу. Секретов в нём нет, но он описывает кластер.

3. На новом сервере подключитесь с этим файлом. Том для этого не нужен:

   arkvory cluster-node --root /opt/proanima-arkvory --kit /root/arkvory-node.kit
   dpkg --configure proanima-arkvory   # только .deb

4. Скопируйте /etc/drbd.d/arkvory.res с другого сервера с данными, затем создайте метаданные и поднимите ресурс. Новая копия начнёт заполняться с активного сервера:

   drbdadm create-md arkvory
   drbdadm up arkvory

5. Замените участника кластера: на активном сервере выполните pcs host auth <server>, pcs cluster node remove <server>, затем pcs cluster node add <server> addr=<address> --start. Устройство fencing сервера сохраняет свою конфигурацию, если новый сервер отвечает на те же настройки устройства; иначе обновите её командой pcs stonith update.

6. Следите за Кластер в консоли или за arkvory cluster-status: сервер показывает Догоняет, пока его копия не станет полной. После этого запись возобновится сама.

7. Докажите устройство fencing нового сервера командой arkvory cluster-fence-test --node <server> --yes и выполните arkvory cluster-check.

Одна копия

Если сервер с данными отсутствует долго (например, меняют диск) и остановка записи обходится дороже риска, оператор может на ограниченное время разрешить запись в одну копию:

arkvory cluster-single-copy --root /opt/proanima-arkvory --until 2026-10-12T18:00:00Z --reason "замена диска на node-b"

• Срок — не дальше 7 дней и с указанием зоны: Z для UTC или смещение, например +03:00. Без зоны команда отказывается работать, потому что активный сервер прочитал бы срок в своём местном времени. Команда работает, только пока копий не хватает.
• Пока решение действует, потеря активного сервера теряет записи, подтверждённые после решения.
• Решение видно в баннере консоли, в метрике arkvory_replication_required_copies и в оповещении ArkvorySingleCopyWrites.
• Оно заканчивается в срок, по --off или само, как только снова все копии полные. Следующая потеря снова останавливает запись.

Мониторинг

GET /health/ready на активном сервере остаётся 200, пока запись остановлена, чтобы мониторинг не переносил здоровый сервер. Поле writable равно false, а поле replication показывает copies, required и singleCopyUntil; replication равно null, если копии не удаётся прочитать. Для администраторов в нём также есть node (сервер, который отвечает), profile и peers — другие серверы с их соединением и копией; их показывает страница консоли. У отдельного сервера поля replication нет.

Метрика	Что значит
arkvory_replication_copies	Полные копии при последней проверке
arkvory_replication_required_copies	Сколько копий нужно записи: 2, или 1 при решении об одной копии
arkvory_replication_writes_refused_total	Записи, получившие 503 replication_degraded
arkvory_replication_check_failures_total	Неудачные чтения состояния копий

Правила оповещений в deploy/monitoring/arkvory-alerts.yml включают ArkvoryReplicationDegraded, ArkvorySingleCopyWrites и ArkvoryReplicationCheckFailing. Следите и за самим кластером: запускайте arkvory cluster-check по расписанию и оповещайте по коду выхода или используйте мониторинг вашей установки Pacemaker. См. Мониторинг.

Резервные копии

Агент резервных копий работает только на активном сервере, в составе группы. Держите хранилище копий вне тома кластера, например на NAS. См. Резервные копии.