В настоящее время я планирую более отказоустойчивую настройку для настройки почты моей организации. В настоящее время у нас есть две машины в разных центрах обработки данных, которые мы планируем использовать для этого, одна из которых является физическим хостом, а другая - «виртуальной машиной» lxc.
План состоит в том, чтобы сделать физический хост нашим основным почтовым сервером (давайте назовем его server1), а виртуальную машину (позвольте назвать этот server2) вторичным через DNS, чтобы, когда server1 выйдет из строя, server2 мог взять на себя, пока мы не получим другой снова работает.
Как и в случае с lxc, я не могу делать такие необычные вещи, как использование DRBD или даже GlusterFS из-за проблем с разрешениями, мой выбор для репликации данных довольно ограничен.
Поскольку мне лично нравится dbmail, я подумал об использовании его вместе с Postgres, чтобы позаботиться о хранилище. Итак, в основном я думаю о том, чтобы иметь dbmail со своим собственным postgres, работающим на server1, а также еще один dbmail и еще один postgres на server2.
Возникает вопрос: какие есть варианты для того, чтобы эти два сервера postgres были синхронизированы без каких-либо причуд, таких как drbd или распределенная файловая система, чтобы, когда server1 выходит из строя, server2 просто продолжает работать с того места, где остановился server1.
В встроенная репликация в базе данных, либо с помощью функции Streaming Replication версии 9.0 и выше, либо с помощью более старого подхода Log-Shipping, нацелены на решение такого рода проблем. В любом случае синхронизация двух снимков базы данных на уровне файловой системы - сложная проблема. Заставьте репликацию работать, и если ваш мастер выйдет из строя, вам придется вручную запустить резервный сервер, а затем изменить адрес DNS, чтобы он указывал на него. Клиентов, разговаривающих с базой данных, нужно будет отключить, чтобы они также подключились повторно; Таймауты TCP / IP иногда могут быть довольно длинными. Чтобы получить все подробности обо всем этом, нужно потрудиться, но не все простое решение для обеспечения высокой доступности. Аппаратное обеспечение может выйти из строя по множеству странных причин.
Вы можете ожидать, что некоторые данные могут быть потеряны в случае сбоя - зафиксированы на главном сервере, а затем отключаются перед репликацией. В PostgreSQL 9.1 может показаться, что вы можете избавиться от этой возможности с помощью синхронной репликации. Но и это не даст того, что вы хотите; никаких коммитов не произойдет, если после того, как вы его включите, не будут работать хотя бы два сервера.
Все это предполагает, что вся интересная информация о состоянии находится внутри базы данных, и что она не является локальной для каждого dbmail. Вы, наверное, знаете, что это не проблема.
Практически всегда плохая идея - иметь разные настройки на первичном и вторичном серверах отказоустойчивой системы.
Я вижу вариант, в котором вы бы использовали репликацию PostgreSQL и стандартное программное обеспечение кластеризации Linux (пульс и т. Д.) Для переключения ролей. Вам также придется управлять IP-адресом, а не помещать вторичный в свой почтовый DNS.