GFM: децентрализованная альтернатива Patroni и etcd для PostgreSQL на базе P2P-меша с In-Memory управлением

PostgreSQL: Как собрать HA-кластер без «комитетов» и лишних сущностей

Если вы когда-нибудь настраивали Patroni, то знаете это чувство: чтобы просто следить за одной базой, вам нужно построить вокруг неё целый город. Тут у нас etcd, там Consul, здесь зоопарк зависимостей, а вон там отдельный бюджет на железо под систему управления. Это напоминает попытку установить охранную систему, которая потребляет больше электричества, чем защищаемый объект.

Классика HA строится на «централизованном консенсусе». Это когда три сервера управления спорят между собой, кто из двух серверов базы данных сейчас главный. Я решил, что пора перестать плодить сущности.

Познакомьтесь с GFM (Gorgona Failover Manager). Это менеджер отказоустойчивости, который работает на принципах P2P-меша.

В чем фокус?

Главная проблема Patroni, ему нужен DCS (Distributed Consensus Store). Это внешняя точка отказа, которую саму надо резервировать. GFM же использует Gorgona Mesh, децентрализованную сеть, где узлы общаются друг с другом напрямую через зашифрованные каналы.

Никаких etcd. Никаких «совещаний директоров». Каждая нода сама себе хозяин.

Преимущества для тех, кто ценит чистоту кода и железа:

1. Изоляция инстансов. На одном мощном сервере можно поднять X кластеров Postgres. У каждого будет свой cluster_id, свои порты и свои лимиты памяти. GFM не путается в ногах у соседа благодаря Systemd-шаблонам и уникальным лок-файлам.

2. Математика вместо голосования. Лидер выбирается не по «симпатиям» алгоритма Рафт, а по LSN (Log Sequence Number). Кто реально дальше всех продвинулся по записи данных — тот и мастер. Если LSN одинаковый, смотрим на имя хоста в алфавитном порядке. Просто, детерминировано, надежно.

3. Безопасность. Шифрование здесь не «опция», которую надо настраивать три дня с сертификатами, а фундамент. Весь управляющий трафик идет внутри P2P-меша «из коробки».

Секретное оружие: Gorgonad в памяти

А теперь вишенка на торте. У gorgonad (сердце нашего меша) есть режим работы полностью в памяти.

Зачем писать сообщения управления на диск, создавая лишнюю I/O нагрузку и оставляя следы? В этом режиме база событий и очередей живет только в RAM. Если питание вырубится, она просто исчезнет, не оставив мусора. Это дает бешеную скорость отклика: управляющие сигналы пролетают по сети быстрее, чем диск успеет «чихнуть». Для систем, где задержки критичны (привет, высоконагруженная 1С), это спасение.

Почему это важно для 1С и не только?

Админы 1С боятся Postgres, потому что он кажется им хрупким. С GFM всё становится предсказуемым. Мы добавили автоматическую привязку к NUMA-узлам и жесткую изоляцию ресурсов через cgroups. Базы больше не «воруют» память друг у друга, а виртуальный IP (VIP) переезжает за мастером автоматически.

Итог простой: Если вам нравится администрировать облако из десяти сервисов ради одной базы Patroni ваш выбор. Если вам нужно, чтобы база просто работала, переключалась как часы и не требовала «комитета по кворуму» на каждом шагу, попробуйте P2P-подход.

Это работает быстро, весит мало и не задает лишних вопросов. Как раз в моем вкусе.

https://github.com/psqlmaster/gorgona/blob/master/plugins/gfm/readme.md

Перейти на панель управления можно по следующей ссылке
Для входа используйте следующие учетные данные: Имя пользователя: demo Пароль: demo

Что внутри стека:

• GFM: Python-демон управления.

• Gorgonad + Gorgona: P2P Mesh сервер / клиент.

• Shell-скрипты: Smart-ребилд (pg_rewind + pg_basebackup).

• Никакого etcd. Вообще.

Stay decentralized.