HA система

>Эти сервера определяют какой из двух серверов с apache+mysql живой и направляют на него.

сервера в одном канальном сегменте? если да, то отказоустойчивость а-ля vrrp(vrrp, carp и т.д.) рассматривалась как вариант?

Подход в корне неверный. DNS сервера не должны ничего определять, они просто адреса отдают, а адреса кешируются. В итоге твой сайт будет лежать пока все кеши не очистятся.

Если хочется отказоустойчивости на двух серверах - то используй дисковую репликацию аля DRBD + heartbeat для определения дохлости второго сервера.

Если он падает, то DRBD-девайс монтируется на втором сервере и с него уже отдают контент все службы (SQL/WEB и т.д.)

Примеров в инете вагон как настроить.

Как уже сказали - ДНС тупо отдает адреса. Дальше рекомендую смотреть в сторону CARP на BSD и в сторону pacemaker && clusterip на линухе.

Просто я смотрел реализации heartbeat и мы в итоге упираемся в надежность одного! сервера, который решает кто дохлый кто нет и распределяет, хотелось бы что бы пользователь вводил домен и недумал как из серверов отдается ему но при этом серверов которые отвечают за распределение было бы как минимум два в разных частях мира :)

а в случае heartbeat мы вводим домен который решается в айпи этого heartbeat сервера. А если этот сервер упадет? Тот на котором хартбит

Нет. Решает кворум (т.е. большинство серверов). Или при наличии всего 2 серверов - если сервер, на котором ресурс неактивен, видит, что «коллега» не отвечает - то, соответственно, считает, что остался один и поднимает у себя ресурсы «коллеги». Почему собссно и важна безотказная связь между серверами.

У HB нет выделенного мастера. Есть «ВрИО», который при смерти текущего автоматом передается. Кворум не работает в конфигурации из двух серверов, причем принципиально. Так что тут надо думать над связностью серверов (отдельным прямым линком - лучший вариант). есть еще вещи типа STONITH, но без кворума и в лоб опять же есть опасность ситуации когда серваки при отсутствии связности тупо пристрелят друг друга как на хорошей дуэли.

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

>>Кворум не работает в конфигурации из двух серверов, причем принципиально.

всмысле принципиально? не вводите в заблуждение товарища. третьим голосом может выступать маломощный сервер(на который не будет перекидываться контент) или дисковый раздел(кто повесил persistent reservation, у того и доступ).

али линукс не умеет так?

тс'у курить split-brain и data fencing.

Для решения проблем аля сплит-брейн я обычно юзаю несколько хартбит линков - через сериал порт, езернет на несколько линков и т.п. Все вряд-ли упадут.

Ключевое слово «_ДВА_ сервера»!!! А Вы вводите третий. На трех - сколько угодно. А сколько сервисов крутить и на скольки машинах - это совсем отдельная песня. PaceMaker умеет прибивать сервис к серваку гвоздями. И это не касается линукс-не линукс. Это свойства pacemaker'а.

Все решаемо. Но Надо будет продумать регламенты когда сервера друг друга не видят, но оба живые. Например если на NS можно поднимать демонов, я бы на нем поднял третью ноду. Файлы синхронизировать я бы стал rsync'ом, если они не сильно объемистые и частоменяемые.

Но если мы раскидываем по разным ДЦ, то в чистом виде кластеризация не работает. Я бы вытащил отдельно фронтенд на каком нибудь nginx'е, который будет кешировать, отдавать статику и пробрасывать траф на два бэкэнда. nginx умеет собирать пулы бэкэндов и мониторить состояние серверов, но есть свои моменты - под большой нагрузкой это работает не ахти. Простой мониторинг такого плана навскидку не подскажу. Я бы поднял скрипт в кроне, который бы лазил на бэкэнд и дергал nginx при отвалах. Далее у нас точка входа - точка отказа. Соответственно на данном уровне можно только подготовить инфраструктуру для быстрой миграции nginx на другой сервер. Это оставил бы на ручном управлении, но заскриптовал для максимальной простоты и скорости.

В общем это как скелет того что сделал бы я на трех серверах в разных ДЦ. Простор для дальнейшей фантазии большой.

Высказывались еще веселые решения типа объединения нескольких линков в один интерфейс и мониторить на нем. Но извращаться можно много и по разному.

>>Ключевое слово «_ДВА_ сервера»

ключевое слово «свои NS сервера» из которых можно сделать кворум, например. не обязательно кластер из 3 нод для этого.

Я так и не понял как реализовать структуру когда есть два сервера с приложением (apache+mysql), находятся они в разных датацентрах, и два! сервера для определения какой из них живой, если есть два сервера для опеределения живучести то какой айпи я должен прописывать в днс записи домена по которому ходит клиент?

и еще вопрос, как в таком случае (если сервера в разных ДЦ) реальзовать номальные зеркалирование файликов? Базы то реплицируются нормально, а вот запуск раз в минуту rsync как то не то, тем более в таком случае нужно делать мастер-мастер репликацию и на обоих серверах запускать rsync? Не получится ли коллизий?

Не передергивайте и не приписывайте мне чужих слов. Я говорил что на ДВУХ серверах КВОРУМ не реализуется принципиально. Точка. Сколько их есть у ТС, что из них можно использовать в кластере а что нельзя - вопрос третий.

да я не к тому, я вообщем у всех спросил :)

Стройте round-robin dns. А про зеркалирование - вам не кажется что предлагать наилучшее решение «в общем плане» несколько... Некорректно? Для домашней страницы В. Пупкина можно и вручную синхронизировать, а для хранения картинок photofile даже говорить о «нормальном зеркалировании файликов» как то... Не ахти? Не хотите решать проблему, а слепить из того что есть конфетку, да еще что б разжевали все - не то место.

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

>>Я говорил что на ДВУХ серверах КВОРУМ не реализуется принципиально.

кворум диск же или «виртуалка»

Сколько их есть у ТС, что из них можно использовать в кластере а что нельзя - вопрос третий.

зачем их использовать в кластере? нужно только отдать голос.
о наличии серверов помимо 2х было написано в первом посте.