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

Проработать материал: HA Xen Cluster with DRBD, LVM and heartbeat

Ещё вариант: Использование доменов Xen поверх DRBD-устройств

DRBD поверх LVM имеет смысл только если предполагается часть виртуальных машин размещать на одном сервере, а часть на другом. В этом случае при отказе одного из серверов произойдёт перезагрузка только виртуальных машин, работавших на отказавшем сервере. Но в любом случае, любой из серверов должен обладать ресурсами, достаточными для работы всех виртуальных машин. Минус этого подхода в том, что при изменении размеров логических томов нужно будет выполнять это на обоих серверах, а затем обновлять метаданные DRBD. Так же при создании нового логического тома необходимо будет добавлять конфигурацию DRBD для взаимной синхронизации этих логических томов на обоих серверах.

LVM поверх DRBD позволяет не делать одно и то же на двух серверах виртуализации, если нужно изменить размер логического тома или создать новый. Так же не нужно делать никаких манипуляций с конфигурацией и метаданными DRBD. Ещё одно перимущество заключается в том, что в конфигурации виртуальных машин можно будет ссылаться на имена LVM-томов, что более наглядно. Недостаток у этой схемы один - виртуалки в кластере должны работать только на одном из серверов, а второй будет в резерве. В случае отказа резервного сервера все виртуалки продолжают работать без каких-либо перезагрузок. Но в случае отказа основного сервера все виртуальные машины перезагружаются уже на резервном сервере.

Стоит учитывать, что производительность DRBD, судя по отзывам, значительно ниже локальных дисков. Дело в том, что в DRBD записанным кластер считается лишь тогда, когда он записан на оба узла, а сеть вносит задержку.

Отдельная тема - это отказоустойчивость СУБД.

Вот тут есть описание, как настроить репликацию в MySQL в режиме Master-Master: Как настроить MySQL Master-Master репликацию?

Вот тут можно почитать про опыт эксплуатации: Опыт эксплуатации MySQL Master-Master — как пережить аварию датацентра

Вот тут про настройку потоковой репликации в PostgreSQL: Потоковая репликация в PostgreSQL и пример фейловера

Для дублирования СУБД без существенной потери производительности стоит использовать средства репликации СУБД. Варианты репликации - синхронная и асинхронная. Только синхронная репликация обеспечивает гарантию, что подтверждённая транзакция не будет потеряна. Синхронная репликация, насколько мне известно, не реализована ни в MySQL, ни в PostgreSQL. Реализована только асинхронная репликация, что означает, что последние применённые на одном из сверверов данные, в случае его отказа, могут быть потеряны на резервном. Но у асинхронной репликации есть и достоинства - она работает быстрее, не задерживая выполнение запросов. Также репликация классифицируется по механизму - репликация на уровне запросов, на уровне строк или смешанная. В случае MySQL можно без проблем использовать репликацию Master-Master, но только если запросы по обновлению данных приходят только на один из узлов. Если запросы на обновление распределять по двум узлам, то могут возникать конфликты правок. В случае с PostgreSQL наиболее надёжным и простым способом репликации является встроенная "потоковая репликация", но в этом случае доступен только режим Master-Slave с возможной сменой ролей.