LINUX.ORG.RU
ФорумAdmin

web HA-кластер на двух нодах

 , , , ,


0

1

Приветствую.

Имеются две серверные машины, которые держат веб-портал. Поддомены раскиданы по обеим машинам, для снижения общей нагрузки. Отказоустойчивость тихо плачет в сторонке Решил сделать отказоустойчивый кластер на базе этих двух машин.

Текущая архитектура: фронтенд nginx (на обеих серверах), бэкенд php-fpm (на обеих серверах). Машины связаны линком в 1 гигабит, однако обе имеют отдельный внешний канал.

Предполагаемая архитектура: HAProxy (на первой машине) на внешнем интерфейсе и фронтенды (nginx) + бэкенды (php-fpm) на локальных.

Специально хочу уточнить, что идея с RRDNS режется на корню кэширующими серверами провайдеров, отдающих единственный IP. Поэтому принято решение использовать балансировщик нагрузки HAProxy на первую серверную машину (она имеет более широкий канал).

То есть в теории будет так: запрос клиент попадает на балансировщик, который отправляет запрос на одну из нод. В случае отказа второй ноды балансировщик будет использовать только первую ноду, в случае отказа первой ноды (и балансировщика), увы, придется менять A-записи на неймсерверах и поднимать nginx на внешнем интерфейсе.

Однако, плюс этого решения в том, что все поддомены (сайты) будут доступны, а не только часть с работающего сервера (как это сейчас).

Возможно, мое решение не совсем верное и я хотел бы услышать ваши советы по этому поводу, но, как я понимаю, в данном случае отказоустойчивость предполагает наличие распределенной файловой системы, имеющей поддержку двусторонней репликации (так как придется хранить полные копии сайтов на обеих машинах, а также синхронизировать все изменения). Поэтому мне наиболее интересен именно этот момент и я жду ваших советов по выбору такой фс (отмечу, что сайты в большинстве содержат мелкие файлы, сильно крупных нет, максимум в 10-15 мегабайт, а в среднем не превышая мегабайт).

Спасибо за внимание! Жду ваших советов.

p.s. роутера нет в наличии :)


Провайдерские днсы закэшируют обе A-записи. ФС - ocfs2вполне себе работает, многие довольны gfs2

leave ★★★★★ ()

Специально хочу уточнить, что идея с RRDNS режется на корню кэширующими серверами провайдеров, отдающих единственный IP.

Лучше всего - сменить провайдера или объяснить этому - насколько он не прав. Если это никак невозможно - использовать corosync+pacemaker для переезда этого ip-адреса на живую ноду.
Будет достигнут практически нулевой простой при падении любого сервера.

в данном случае отказоустойчивость предполагает наличие распределенной файловой системы, имеющей поддержку двусторонней репликации

drbd+ocfs2

Отдельный вопрос про хранение сессий, если они у вас имеются.
Тут есть несколько вариантов - использование haproxy для «sticky session», опять же хранение их на ФС drbd+ocfs2, multi-master memcached.

cm26inc ()

У тебя как-то все свалено в одну кучу: хай-авайлабилити, балансировка нагрузки и еще распределенная файловая система в придачу. Ты по пунктам реализовывай, а то все сразу надорвешься, там подводных камней хватает.

HA это pacemaker + corosync. Для уверенного HA-кластера нужно три ноды, а не две как у тебя, но можно и из двух, понимая ограничения (ситуация потери связи между узлами, split-brain)

С распределенными файловыми системами тоже не очень гладко. Я настраивал гластер и он до сих пор работает, но на тот момент, не знаю как сейчас он не умел по заранее заданным правилам разрешать конфликты при репликации. Это та задача с которой прийдется столкнуться в случае аварии. Если данных мало и они обновляются не регулярно, то rsync лучшее решение.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.