» ha cluster

приветствую!
есть задача построить отказоустойчивый веб сервер.
на сегодня пока что имеем сайты (файловая структура) + БД MySql
на чем все это лучше (и как) это реализовать?
как синхронизировать файловую структуру? drbd?
с Mysql понятно, можно сделать репликацию, но опять же таки вопрос, если упал один mysql как сайт поймет что нужно слать запрос на резервный?
подскажите пожалуйста по теме, может есть кого либо наработки в эту сторону?

artemka1988
Для MySQL либо master-master и аккуратно с этим работать на уровне приложения, либо мы используем Pacemaker с PRM.

С файликами можно использовать DRBD.

На самом я делал 2 года назад инсталяцию, которая до сих пор работает без нареканий между ДЦ. Там и файлы сайта и MySQL реплицируются за счёт master-slave DRBD схемы управляемой pacemaker'ом.

Опять же вопрос — у Вас это в рамках одного ДЦ или нет. На виртуалках или нет. Есть ли PI IP адреса или нет.

это нужно стоить в рамках разных ДЦ и пока на сегодня только два физических сервера.
как вариант можно арендовать еще 1 или 2 шт если нужно будет
на счет ип, тоже не понятно. на каждом сервере будут ип и разных пулов, ну и соответсвенно выдавать адреса будут разные провайдеры. как тут быть?

artemka1988
Не комильфо, но ровно в таких условиях я один раз это проделал и считаю, что схема работоспособна — та что на основе DRBD. Правда для того что бы это нормально работало в рамках всего двух нод и не было "левых" переездов пришлось дописать "мозги" в виде своего RA для pacemaker'а.

ну с этим немного понятно. хоть я не понял что такое RA и pacemaker
я только в первый рас собираюсь реализовать)
ну а как быть с heartbeat? для него нужны как я понял минимум две машины не зависящие друг от друга?
и с Mysql до конца не понял. если один падает, как узнает приложение, что нужно обращаться к другому?

artemka1988

Цитата:

ну с этим немного понятно. хоть я не понял что такое RA и pacemaker

pacemaker - это утилита а-ля fail-safe-ip, что предлагает тот же Hetzner. Есть два физ. сервера в одном дц, с одной адресацией - и у них есть два IP адреса, каждый принимает запросы. При выпадении одного из серверов - второй, живой, перехватывает адрес первого, до его восстановления, таким образом переключение IP будет почти прозрачно и не требуется мониторинга, при наличии heartbeat - он и выполняет задачу перевешивания IP.


Цитата:

с Mysql до конца не понял. если один падает, как узнает приложение, что нужно обращаться к другому?

Если приложение требует именно Mysql, для него нет такого простого решения. Взгляните на Green SQL, интересный вариант. Разруливать можно также через iptables, но будет небольшой оверхэд.
Если есть выбор - для Postgres имеется очень хорошая штука - PG bouncer.

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

ssmk
Цитата:

pacemaker - это утилита а-ля fail-safe-ip

Ну не фига себе Вы его опустили... Он гораздо более функциональный, чем простые ucarp,vrrpd или keepalived.
heartbeat мне не очень нравится и вообще его применяют в связке с RedHat'ным CMAN, а я всем этим не пользуюсь. Но в любом случае у pacemaker'а частично теже RA что и у heartbeat'а.

Цитата:

C DRBD связываться между двумя ДЦ - имхо, мазохизм

действительно очень распространённое мнение, тем не менее, работало даже через OpenVPN (UDP канал) весьма стабильно. (drbd protocol C)
Цитата:

Если приложение требует именно Mysql, для него нет такого простого решения.

Решения есть всегда. Первоё что взбрело в голову это использовать Consul и обращаться к базе по доменному имени. Но это далеко не единственное решение.



artemka1988
RA = Resource Agent. Скрипт/программа реализующий логику обработки всевозможных ситуаций, на которые умеет реагировать pacemaker.

Хотя в любом случае, всего 2 узла и через интернет, тяжело настроить для нормальной надёжной работы.

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

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

artemka1988
Кол-во серверов зависит от выбранного решения. Если это будут решения базирующиеся на соблюдении консенсуса (тот же corosync+pacemaker использующие PAXOS), то для нормальной не костыльной работы нужно хотя бы 2узла+арбитратор(арбитратор это узёл принимающий участие в голосовании, но не выполняющий функциональных ролей). Но как я уже говорил, можно накостылять что бы и на 2-х нодах оно работало без splitbrain'а.

IP в Вашем случае ни как не подхватится. Как вариант я Вам предложил ходить в базу по доменному имени и для его актуального состояния использовать тот же Consul.

p.s. Вам надо почитать кучу всякой хрени в интернете что бы расширить кругозор с целью узнавания вообще о существующих решениях и практиках в области кластеризации. В противном случае Вы и не знаете из чего выбирать и чем можно жертвовать. А ещё есть CAP теореама и многое другое. При репликации баз ещё важны сетевые задержки, в частности RTT.

На всё это накладывается вопрос из каких точек будет одновременно доступно Ваше приложение:
- из одной (мастер)
- из всех (мульти-мастер)
- из всех (мастер+остальные проксируют на мастера)

И таких вопросов много. Решить что и как делать за Вас мы не можем. Почитайте немного какие существуют варианты, пускай даже не о всех узнаете, но остановитесь для себя на одном приемлемом и изучите его. Тогда мы сможем объяснить его плюсы или минусы и мб помочь с настройкой.
Howto можно найти под разные решения, но все они не идеальны. Большинство схем всё же рассчитывают на "интеллект" со стороны приложения, реализовать всё прозрачно невозможно или очень дорого.

читать то читаю, только возникают вопросы по ходу...
https://help.ubuntu.com/community/HighlyAvailableLAMP
http://habrahabr.ru/company/acronis/blog/198934/
здесь я смотрю что все делают в пределах одной сети.
самое не понятное было, как будет работать смена ip в разных ДЦ
вот на счет *интеллекта* приложения, то там его нет(

artemka1988
Ubuntu'оиды как раз в статье описывают всё на DRBD, хоть я бы использовал 2 DRBD девайса, а не один, дабы полностью разнести файлы БД и приложения, хотя в одном тоже есть смысл. Как всегда палка о двух концах.

А на хабре так и вообще не слова про MySQL. А у Вас именно это будет основной головной болью.

Вместо плавающих адресов разрулите всё на уровне DNS. Приложение будет доступно по round-robin A записям. В базу будет ходить, либо по флагу какому-нить (самописному), либо по DNS имени promote'ящемуся Consul'ом.

Данные синхронить будете либо независимо от MySQL (drbd, ceph и т.п.), либо встроенной репликацией.
Я когда делал настройку MySQL+Pacemaker+DRBD по официальному Oracle'ёвому мануалу. Вот описание, пошаговая инструкция там внизу по ссылке, надо будет зарегаться что бы скачать PDF'ку.
Если делать на уровне репликации MySQL, то в самом начале топика я давал Вам ссылку на PRM.

тут я немного понял. но теперь еще вопрос.
как будет работать nginx? тоже по dns имени? (имею в виду аля heartbeat)

artemka1988
Для приложения у вас не будет ни какого heartbeat'а, оно просто будет работать с двух мест, две точные копии (если нужно заливать файлы пользователей на диск, то использовать DRBD), php сессии или другое хранить в MySQL'е, или научиться работать с каким-нить распределённым key-value хранилищем.

На обе морды пользователи будут попадать через DNS записи (две A записи). Современные браузеры нормально ведут себя если по одному из адресов совсем нету ответа.

вот теперь еще понятней! спасибо!
вместо mysql я так понимаю лучше будет mariadb?

artemka1988
Хз, ни когда её не использовал, я использую percona.