LINUX.ORG.RU
ФорумAdmin

Отказоустойчивость сервера


4

4

Добрый день. Я столкнулся с задачей обеспечения отказоустойчивости довольно-таки высоконагруженного проекта (nginx+php-fpm+mysql).

Вопрос в том, как этого добиться. На первый взглят приходят идеи дублирования всех трёх компонентов так:

nginx1 -> php-fpm1 -> mysql-master
   |
keepalived          /
   |
nginx2 -> php-fpm2    mysql-slave
keekalived, думаю, будет работать в режиме с двумя ip-адресами (первый мастер на одном сервере, второй мастер на другом), которые будут оба записаны в A-записе DNS-сервера.

Вопросов несколько. Правильно ли я пытаюсь сделать или может быть лучше использовать другие варианты? Достаточно ли использовать два сервера, на которых будет по три виртуальных машины? Может сделать так, чтобы nginx обращался через upstrem к серверам php-fpm по очереди или только к своему? Для master и slave mysql можно тоже использовать keepalived? Как раздавать статику, которой довольно много (общее хранилище?), и как будут работать оба nginx с одним, например, nfs сервером?

keekalived, думаю, будет работать в режиме с двумя ip-адресами (первый мастер на одном сервере, второй мастер на другом), которые будут оба записаны в A-записе DNS-сервера.

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

Не-не-не

upstrem к серверам php-fpm по очереди или только к своему

А тебе HA или LB надо?

Как раздавать статику, которой довольно много (общее хранилище?)

Я бы cloudfront от амазона взял

и как будут работать оба nginx с одним, например, nfs сервером?

А тут бы лучше какую кластерную фс взял, или подобную штуку. Ты сначала определись, тебе нужен отказоустойчивый или с балансировкой нагрузки? Если HA - 2-ух серверов хватит. Если LB + HA то это буду костыли.

kukara4 ()

Это, если таки решишь LB, То не забудь мемкеш для синхронизации сессий на серверах

kukara4 ()
Последнее исправление: kukara4 (всего исправлений: 1)
Ответ на: комментарий от kukara4

Не-не-не

М?

А тебе HA или LB надо?

Надо HA.

Я бы cloudfront от амазона взял

Боюсь, дороговато будет. Хотя спасибо, подумаю.

А тут бы лучше какую кластерную фс взял, или подобную штуку

GFS? Не слишком большой оверхед?

Если LB + HA то это буду костыли.

Мне достаточно HA, но интересно, почему костыли?

generator ★★★ ()
Ответ на: комментарий от generator

Не зная других подробностей, бы исключил из связки master/slave вообще. Все демоны настраиваются на локальную работу. Фактически сделать обычный standalone. Но все информация храниться на drbd разделах. Из кластера тебе нужен был бы только drbd + heartbeat или что там еще советуют.

Мне достаточно HA, но интересно, почему костыли?

Больше точек отказа. Да и не строить никто таких вещей на 2-ух железяках.

GFS? Не слишком большой оверхед?

Какой-то гластерф, но мне больше нравится вариант банального rsync. Но опять таки, не зная задач, сложно советовать что-то по синхронизации файлов.

М?

С ДНС'ом будут проблемы, 2 записи, кеширование, ttl ... Та не. Для этих задач есть плавающий адрес сервиса.

kukara4 ()

Если нужен *только* HA, то pacemaker + drbd (в синхронном режиме) + фс твой выбор. Ставишь ext4 в режим data=journal, на нём всё (базы, сайты и т.п.) и реплицируешь его по drbd на второй сервер.

При отказе первого на втором drbd перейдёт в primary, смонтируется ФС (будут какие-то потери, возможно, но не более чем при просто падении сервера), повесится айпишник на интерфейсе, запустятся демоны, MySQL (у тебя же InnoDB, я надеюсь?) перечитает транзакции и всё заведется.

Я так лет 5 назад почту делал с базой и всеми делами, на переключение аварийное уходило около минуты, ФС правда был рейзерфс, но не суть. Основное время - MySQL и его накатывание транзакций.

blind_oracle ★★★★★ ()
Последнее исправление: blind_oracle (всего исправлений: 1)

У проксмокса есть готовое решение на-кластера, мануал у них на сайте. Строится как раз на дрбд.

stave ★★★★★ ()
Ответ на: комментарий от stave

А, только при реализации единственная заковыка в фенсинге. У меня однажды ноды циклично друг дружку перегружали часов 12 подряд пока заметили. Хорошо это было во время плановых работ.

stave ★★★★★ ()
Ответ на: комментарий от kukara4

Да и не строить никто таких вещей на 2-ух железяках.

А если как-то так сделать, что думаешь?

С ДНС'ом будут проблемы, 2 записи, кеширование, ttl

Будут же две A-записи, round robin...

generator ★★★ ()
Ответ на: комментарий от generator

Будут же две A-записи, round robin...

Ну, половина запросов пройдёт, половина - нет. Многие броузеры, конечно, умеют все А-записи пробовать, но, думаю, не все

blind_oracle ★★★★★ ()
Ответ на: комментарий от generator

Будут же две A-записи, round robin...

Проходили уже, часть клиентов будет в ауте. Вот если за каждым из ip с А записи были бы вот такие контуры.

А если как-то так сделать, что думаешь?

Ты про конфиг nginx? А что за php приложение вообще?

kukara4 ()
Ответ на: комментарий от blind_oracle

Нее, посмотри выше, я ссылку кинул. Два адреса настроены через keepalived мастерами на разных серверах:

Server1: master-IP1 slave-IP2
Server2: master-IP2 slave-IP1
В случае отказа одного сервера, его ip перекинется на второй сервер, который будет обслуживать оба адреса до поднятия второго.

generator ★★★ ()
Ответ на: комментарий от generator

Ну тогда и смысл в двух айпи какой? Одного достаточно, если он будет с сервера на сервер бегать.

blind_oracle ★★★★★ ()
Ответ на: комментарий от vxzvxz

Вот жеж опечатался я. Я про это и говорил. Не знаю, откуда в буфере ссылка на php-fpm взялась О_о

generator ★★★ ()
Ответ на: комментарий от generator

а в качестве backend-ов что будет?

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

vxzvxz ★★★ ()
Ответ на: комментарий от generator

Так, аффтар, ты определись что тебе то надо в итоге. Вроде про отказоустойчивость разговариваем, не? Концепция изменилась?

blind_oracle ★★★★★ ()
Ответ на: комментарий от vxzvxz

а в качестве backend-ов что будет?

php-fpm

Ноды мультикастом общаются.

generator ★★★ ()
Ответ на: комментарий от blind_oracle

Да, нужно HA, но почему бы и LB не сделать бонусом? Вот kukara4 говорит, что так не делают на двух черверах, я пытаюсь понять, почему.

generator ★★★ ()
Ответ на: комментарий от generator

Чтобы было LB нужно уже думать как ты будешь базы данных в режиме master-master делать. Для этого можно заюзать галеру (http://galeracluster.com/), с точки зрения клиентов она вроде обычный мускуль, но как она по скорости я хз.

Ну и остальные данные как реплицировать тоже надо продумать (сессии в memcached какой-нибудь, файлы по rsync или glusterfs).

Да, и на двух нодах не стоит этого делать, в кластере хорошо когда есть кворум, вот штук 5 серверов самое то. Или 3.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Ладно, уговорил :) Про HA думать не буду. Тогда единственное, что нужно сделать - синхронизовать статику и как-то настроить mysql на автопереключение на slave, в случае отказа мастера.

generator ★★★ ()
Ответ на: комментарий от generator

и как-то настроить mysql на автопереключение на slave, в случае отказа мастера.

Pacemaker вроде это всё умеет из коробки, там есть ресурсы для этого, достаточно только конфиг кластера нарисовать.

синхронизовать статику

Просто ФС синхронизируй по DRBD как я раньше писал - самое простое. Ну или глустерфс какой, но я думаю там много подводных каменей.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

синхронизовать статику и как-то настроить mysql на автопереключение на slave

Не-не-не. Делай все стенделоном, мускул локальный, никак гластеров и синхронизаций файлов.

Все что у тебя будет это drbd + heartbeat/pacemaker. Данный сайта, мускула все на разделе drbd. Ломается первый сервер, ip и все твои данные поднимаются на втором.

Вот зачем ты хочешь master-slave из mysql? Ну рухнул у тебя первый сервер, так тебе нужно будет руками скорее переключать его на слейв, а потом еще синхронизироваться в обратную сторону. Файловая синхронизация тоже вещь не простая. А так у тебя 1 сервер упал - второй подхватил и все автоматически.

kukara4 ()
Последнее исправление: kukara4 (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

базы данных в режиме master-master делать

Если там не самописный движок, где можно решить проблему индексов и проверку на целостность транзакций, то это его ж погубит

kukara4 ()
Ответ на: комментарий от kukara4

Вот зачем ты хочешь master-slave из mysql?

Интересно.. Честно говоря, даже не задумывался, что можно как-то по другому. А как второй сервер поднимется? Из бинарных логов транзакции накатывать начнёт?

generator ★★★ ()
Ответ на: комментарий от generator

Нет, drbd это блочная репликация. Раздел drbd монтируется на мастер ноде, там хранишь сайт, mysql. В это время все изменения на мастере синхронизируются со слейв нодой. В случае падения мастера на слейве поднимается раздел drbd со всей инфой, которая была до падения на мастере. Как-то так.

В таком варианте у тебя будет секунд 5-30 простоя, в зависимости от нагрузки и количества данных. Зато службы запустяться и разницы с мастером не будет.

kukara4 ()
Ответ на: комментарий от generator

проще говоря drbd это как raid-1 только по сети, причем смонтирован он на активной ноде, падает активная нода, drbd перемотируется на запасную, а за перезапуск сервисов nginx, mysql отвечает heartbeat, правда я на drbd держу виртуалки, которые и перезапускаются heartbeat-ом.

vxzvxz ★★★ ()
Ответ на: комментарий от generator

Из бинарных логов транзакции накатывать начнёт?

Почти, из логов InnoDB внутренних, куда они попадают перед тем как примениться к таблицам. Получается то же самое, как если бы ты просто сервер во время работы резетнул.

blind_oracle ★★★★★ ()
Ответ на: комментарий от kukara4

В галере все эти вопросы решены, там синхронная репликация.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Но в чем смысл городить огороды с репликацией базы если ее можно сделать standalone и тупо отдать drbd/heartbeat, непонимаю. Ну разве что с нее бекапы делать.

kukara4 ()

оба php-fpm в апстримы обоих nginx, mysql можно сделать слейвом с одной стороны и мастером с другой, и наоборот, и костылями через скрипты keepelived переключать

loqutus ()
Ответ на: комментарий от kukara4

Смысл только если делать балансировку нагрузки, если чистый HA - то никакого.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Вот и я так думаю. Но товарищ loqutus считает иначе. Печально, в темах про кластеры отписуются 3-5 человек, во всех одни и те же. Мне казалось тут очень много спецов.

kukara4 ()
Ответ на: комментарий от kukara4

Мне казалось тут очень много спецов.

Зато сколько подписчиков и добавлений в избранное :)

Black_Roland ★★★★ ()
Ответ на: комментарий от kukara4

Ну, не знаю, я такие схемы (мускуль на дрбд) реализовывал ещё лет 6-7 назад и даже тогда оно работало очень неплохо, а уж сейчас после развития этих продуктов должно быть вообще отлично. Так что вперёд пробовать.

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