2 сервера, один домен

[hotmax2]

Честно, поиск еще не юзал. Может кто знает как организовать?
Цель - отказоустойчивость работы сайта. ( к примеру на основном серваке отвалился интернет или питание )
Средства - есть 2 физических сервера, на разных ( белых ) IP адресах.
Нужно: Разместить сайт на серверах ( полное зеркало ), но трафик должен идти только с основного сервера, а второй нужен на случай падения первого.
Есть может у кого готовые решения?

ЗЫ..  и как настроить синхронизацию базы данных MySQL на 2х серверах ( про папки тут все ясно )...

[shushpanchik]

По-моему проще сделать базу данных на отдельном серваке. А 2 веб-сервера пусть обращаются к одной базе.

[hotmax2]

База отдельная это уже 3й сервак...  Задача организовать на 2х

[shushpanchik]

Я понимаю что это третий сервант. Я предлдожил идею к вопросу о синхронизации баз. В таком варианте ее просто не нужно будет делать. Поднимите на виртуалке сервер с базой. Думаю религия должна позволить.

Или же поднимите 2 веб-сервера в виртуалках на одном физическом компе, а на втором - базу.

ИМХО как вариант.

Кстати я тоже подобным вариантом интересовался. У меня парк физических машин побольше, могу позволить потратить чуток больше ресурсов. Но вычитал что если у регистратора имен в DNS прописать

Код: [Выделить]

example.com A IP1
example.com A IP2
www.example.com CNAME example.com
то это особо не поможет. Половина запросов идет на один IP, половина на другой и соответственно если один IP рухнет - то половина запросов будет просто отваливаться с ошибкой. Потому что информация в DNS перебирается последовательно.

[Karl500]

Судя по первому посту, Вам, на мой взгляд, не синхронизация БД MySQL нужна, а репликация. Т.е. основная БД - мастер, резервная - slave.

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

[hotmax2]

Вот именно...  DNS тут не помошник.. 
Держать на виртуалках 2 web сервера? Для чего? Если физически сеть отвалится от сервера (электрик негодяй рубильник вырубит )
Задача иметь в доступности сайт, при условии что один из серверов отвалится физически.
Синхронизация баз данных на 2х серверах, задача выполнимая.
А вот перенаправление на резервный сервер - вот задача.

[victor00000]

Вот именно...  DNS тут не помошник.. 

пример Bind9 - Настройка DNS домен и ип адресс --> http://paste.ubuntu.com/8902137/

[hotmax2]

По моему мнению, это должно выглядеть так:
Два сервера в инете, первый выполняет роль мастера,
А второй периодически пингует первый на доступность..  в случае отказа первого, второй "кричит" я вместо первого времено. В Cisco такая технология есть, если вываливается один маршутизатор, то второй подхватывает пакеты первого. ( PS не помню точно как это называется)

[fisher74]

В cisco знаю и пользую только технологию резервирования шлюза (HSRP). Только они там не пингуются, а обмениваются пакетами согласно протоколу (приоритетность, доступность, актуальность и т.п.). Хотя возможно есть и описанный Вами механизм, но я пока с этим не сталкивался - не было необходимости.

Самая большая проблема для ТС- как быть с БД? вроде бы как репликация с мастера на слейв самое то. Для резервирования-то оно самое, но (всегда оно здесь)... Ведь если основной упал/пропал/отвалился, то в ход вступает второй сервер и БД изменяется уже в нём. О! Можно же сделать двустороннюю репликацию. Вроде бы всё, проблема решена. И снова рядом НО. Но надо быть готовым, что работа с БД работающей в двусторонней репликацией несколько отличается от стандартного режима. Ведь изменения на 2-ом сервер БД никак не должны перехлеснуться с изменениями на 1-ом. То есть для веб-дизайнера (в данном случае) нужно решать проблему возникновения коллизий....
Ну и ещё много-много подводных камней.
Просто как бы подумайте, что даже в Linux окружении подобные системы (в общем-то это кластер получается) стоят деньги... и весьма не слабенькие.

[shushpanchik]

Самая большая проблема для ТС- как быть с БД? вроде бы как репликация с мастера на слейв самое то. Для резервирования-то оно самое, но (всегда оно здесь)... Ведь если основной упал/пропал/отвалился, то в ход вступает второй сервер и БД изменяется уже в нём. О! Можно же сделать двустороннюю репликацию. Вроде бы всё, проблема решена. И снова рядом НО. Но надо быть готовым, что работа с БД работающей в двусторонней репликацией несколько отличается от стандартного режима. Ведь изменения на 2-ом сервер БД никак не должны перехлеснуться с изменениями на 1-ом. То есть для веб-дизайнера (в данном случае) нужно решать проблему возникновения коллизий....
Ну и ещё много-много подводных камней.

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

[hotmax2]

С базой вопрос более менее понятен...  Да и это не самая большая проблема..  Пусть будет 3й сервак, пусть у хостера, но как быть с перенаправлением web серверов?

[fisher74]

Присоздании такой системы надо знать ещё и физическую структуру. Может у Вас все железки в одном сетевом сегменте живут с подконтрольным роутером или коммутатором, тогда вопрос решается одним способом. Если в разных концах света - другим. Да и преследуемые цели резервирования: сами сервера или каналы до них.
У меня пока веет мысля собрать их в один сегмент средствами VPN и в её пределах рулить. Но в таком случае точка входа остаётся одна.

Вообще, горячее резервирование - самая дорогая штука. Нужно серьёзно взвесить стоит ли овчина выделки или нет.

[Freezeman]

ЗЫ..  и как настроить синхронизацию базы данных MySQL на 2х серверах ( про папки тут все ясно )...

Это называется репликация.

Средства - есть 2 физических сервера, на разных ( белых ) IP адресах.
Нужно: Разместить сайт на серверах ( полное зеркало ), но трафик должен идти только с основного сервера, а второй нужен на случай падения первого.
Есть может у кого готовые решения?

Циклический DNS

[hotmax2]

Хотя Round robin DNS (RR DNS) легко реализовать, всё же этот алгоритм имеет несколько проблематичных недостатков, связанных с кэшированием записи в иерархии RR DNS самого себя, а также с кэшированием на стороне клиента, выданного адреса и его повторного использования, сочетание которых трудно управляемо. RR DNS не опирается на доступность услуг. К примеру, если сервис на одном из адресов недоступен, RR DNS будет продолжать раздавать этот адрес и клиенты будут по-прежнему пытаться соединиться с неработающим сервером.

[unimix]

hotmax2, ну так зависит от того, что ты хочешь: или 2 IP за каждым из них свой сервер; или 1 IP, но за ним 2 сервера; или 2 IP за которыми 1 балансировщик и за ним 2 сервера. Последние 2 варианта это почти одно и то же.