Использование головного узла ZFS в качестве сервера базы данных?

Я использую NAS с двойной головкой на базе ZFS для кластерного хранилища высокой доступности на основе рекомендованной архитектуры Nexenta, как показано здесь:

Диски в 1 JBOD будут хранить файлы базы данных для одной базы данных Postgres 4 ТБ, а диски в другом JBOD хранят 20 ТБ больших необработанных двоичных плоских файлов (результаты кластеризации для моделирования столкновений крупных звездных объектов). Другими словами, JBOD, поддерживающий файлы Postgres, будет обрабатывать в основном случайные рабочие нагрузки, в то время как JBOD, поддерживающий результаты моделирования, будет обрабатывать в основном последовательные рабочие нагрузки. Оба головных узла имеют 256 ГБ памяти и 16 ядер. Кластер имеет около 200 ядер, каждое из которых поддерживает сеанс Postgres, поэтому я ожидаю около 200 одновременных сеансов.

Мне интересно, разумно ли в моей установке, чтобы головные узлы ZFS действовали одновременно как зеркальная пара серверов баз данных Postgres для моего кластера? Единственные недостатки, которые я вижу:

Меньшая гибкость для масштабирования моей инфраструктуры.
Немного ниже уровень избыточности.
Ограниченные ресурсы памяти и процессора для Postgres.

Тем не менее, преимущество, которое я вижу, состоит в том, что ZFS в любом случае довольно глупа в отношении автоматического перехода на другой ресурс, и мне не нужно тратить много времени на то, чтобы каждый сервер баз данных Postgres выяснил, вышел ли из строя головной узел, поскольку он выйдет из строя вместе с головным. узел.

— elleciel
источник

PostgreSQL не может быть запущен в любой форме совместно используемого хранилища. Попытки сделать это потерпят неудачу. Попытки обойти средства защиты, чтобы остановить вас (например, перемещение / скрытие postmaster.pid), приведут к серьезному повреждению данных.

— Крейг Рингер

@CraigRinger Хм, это противоречит wiki.postgresql.org/wiki/Shared_Storage ?

— elleciel

Вы можете запустить его, если абсолютно гарантируете, что только один почтмейстер может одновременно обращаться к каталогу данных. Хороший STONITH / ограждение является абсолютным требованием, чтобы избежать повреждения больших данных. Лично я бы не сделал этого. Это также исключает преимущества, о которых вы говорите - автоматическое определение основного / живого сервера и т. Д. - потому что вам нужно управлять аварийным переключением.

— Крейг Рингер

Я пересмотрел вики-страницу, чтобы сделать ее более понятной; спасибо за указание на это.

— Крейг Рингер

Это не имеет смысла. Решение Nexenta HA использует кластеризацию RSF-1 . Похоже, вы делаете это с ZFS на Linux без RSF-1. Имейте в виду, ZFS в Linux на самом деле не имеет возможности кластеризации, поэтому ссылка на Nexenta не применяется. Что вы должны получить, имея два головных узла?

— Ewwhite

Вы не можете иметь два экземпляра Postgres («кластеры» в терминологии Postgres), действующих на одни и те же физические файлы.

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

Если вам нужна высокая доступность, то решением проблемы может стать отказоустойчивость с помощью STONITH. вам нужно убедиться, что затем оборудование восстановлено, оно не пытается открыть базу данных, пока ее обслуживает второй узел.

— Jasen
источник