Всем доброго времени суток!
Прошу совета по следующей проблеме:
Требуется организовать серверную структуру с высокой доступностью веб-приложения.
Как я себе это вижу:
1. Размещаем 2 разных сервера в 2-х ЦОДах.
2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в случае падения одного сервера все запросы обрабатывал второй сервер. (в инете нашел статью с wackamole и apache+mod_backhand, но она уже старая)
3. На серверах находятся базы MySQL - решить проблему синхронизации планирую через MySQL репликацию Master-Master.По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в качестве балансировщика, но что будет, если ДНС запрос закешировался и пакеты будут идти на сдохший сервер?
> Всем доброго времени суток!
> Прошу совета по следующей проблеме:
> Требуется организовать серверную структуру с высокой доступностью веб-приложения.Судя по вопросам, вы еще мало гуглили. Эти вопросы мал-мальски разжеваны.
> Как я себе это вижу:
> 1. Размещаем 2 разных сервера в 2-х ЦОДах.
> 2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в
> случае падения одного сервера все запросы обрабатывал второй сервер.неа, не взлетит.
> 3. На серверах находятся базы MySQL - решить проблему синхронизации планирую через
> MySQL репликацию Master-Master.
> По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в
> качестве балансировщика,какую проблему вы считаете второй?
> но что будет, если ДНС запрос закешировался и пакеты
> будут идти на сдохший сервер?надо ставить маленький TTL.
>> Всем доброго времени суток!
>> Прошу совета по следующей проблеме:
>> Требуется организовать серверную структуру с высокой доступностью веб-приложения.
> Судя по вопросам, вы еще мало гуглили. Эти вопросы мал-мальски разжеваны.Не нашел ничего свежего по данной теме. Может подскажите?
>> По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в
>> качестве балансировщика,
> какую проблему вы считаете второй?
>> но что будет, если ДНС запрос закешировался и пакеты
>> будут идти на сдохший сервер?
> надо ставить маленький TTL.Маленький ТТЛ поставлю, но тогда придется размещать зоны ДНС на этих серверах, и их перезаписывать.
Вот если бы как-то иначе решить данную проблему...
> Маленький ТТЛ поставлю, но тогда придется размещать зоны ДНС на этих серверах,
не понимаю вашу логику. Вовсе не придется. Мастер (источник обновлений) зоны надо разместить там, где будет осуществляться контроль за доступностью веб-серверов.
Где будут слейвы - вообще фиолетово, главное чтобы они нотификейшны от мастера получали и обрабатывали.
>> Маленький ТТЛ поставлю, но тогда придется размещать зоны ДНС на этих серверах,
> не понимаю вашу логику.Ж) ...может, он про TTL IP пакетов?
>[оверквотинг удален]
> Как я себе это вижу:
> 1. Размещаем 2 разных сервера в 2-х ЦОДах.
> 2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в
> случае падения одного сервера все запросы обрабатывал второй сервер. (в инете
> нашел статью с wackamole и apache+mod_backhand, но она уже старая)
> 3. На серверах находятся базы MySQL - решить проблему синхронизации планирую через
> MySQL репликацию Master-Master.
> По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в
> качестве балансировщика, но что будет, если ДНС запрос закешировался и пакеты
> будут идти на сдохший сервер?Failover ip спасет отца русской демократии
почему бы два сервера не держать в одном ДЦ и еще IP будет из одной сетки ?тогда можено heartbeat
можно так же сделать
1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри на IP-nginx
> почему бы два сервера не держать в одном ДЦ и еще IP
> будет из одной сетки ?
> тогда можено heartbeat
> можно так же сделать
> 1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри
> на IP-nginxложится сеть в ДЦ и превед, только не надо говорить, что это маловероятно :D
Вот статью нашел http://www.opennet.me/docs/RUS/webcluster/ - то что надо. Но оно уже устарело и отзывы об апаче не очень в данной ситуации.
>> почему бы два сервера не держать в одном ДЦ и еще IP
>> будет из одной сетки ?
>> тогда можено heartbeat
>> можно так же сделать
>> 1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри
>> на IP-nginx
> ложится сеть в ДЦ и превед, только не надо говорить, что это
> маловероятно :Dну тоже вероятность есть.. так же как и вероятность того, что ляжет сеть и там и там или ДЦ ляжет и там и там
>[оверквотинг удален]
>>> будет из одной сетки ?
>>> тогда можено heartbeat
>>> можно так же сделать
>>> 1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри
>>> на IP-nginx
>> ложится сеть в ДЦ и превед, только не надо говорить, что это
>> маловероятно :D
> ну тоже вероятность есть.. так же как и вероятность того, что ляжет
> сеть и там и там или ДЦ ляжет и там и
> там100% дают сами знаете где :D
Даже хваленный Rackspace со своими 100% uptime садился пару раз в лужу ;)
> 1. Размещаем 2 разных сервера в 2-х ЦОДах.
> 2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы вЭто называется multihoming, одним адресом не обойдёшься, очень желателен Provider-Independent (PI) адресный блок. Сейчас не решается никак - адреса IPv4 тупо кончились.
Сделай просто - в обоих ЦОД по DNS серверу, каждый ресолвит домен в местный адрес, постоянно увеличивая версию зоны. Клиенты сами будут делать round robin, балансировка лишняя.
> По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в
> качестве балансировщика, но что будет, если ДНС запрос закешировался и пакеты
> будут идти на сдохший сервер?Клиент отвалится по таймауту, перезапросит. С multihoming процесс может быть ещё дольше.
> Сделай просто - в обоих ЦОД по DNS серверу, каждый ресолвит домен
> в местный адрес, постоянно увеличивая версию зоны. Клиенты сами будут делать
> round robin, балансировка лишняя.вот тут несовсем понял...
Например у меня есть домен domain.ru , на котором надо сделать отказоустойчивость для сайта test.domain.ru .В настройках домена я указываю NS-сервера своих двух серверов Сервер_1 (1.1.1.1) и Сервер_2 (2.2.2.2) .
Далее на этих серверах подымаю Bind9 и настраиваю зону:
test.domain.ru 1.1.1.1 TTL=1sМежду этими серверами настраиваю (???что-то???, пока в голову идет HearthBeat), и если второй сервер не видит первого сервера, то на втором сервере ДНС меняется на:
test.domain.ru 2.2.2.2 TTL=1sТак получается?
> В настройках домена я указываю NS-сервера своих двух серверов Сервер_1 (1.1.1.1) и
> Сервер_2 (2.2.2.2) .
> Далее на этих серверах подымаю Bind9 и настраиваю зону:
> test.domain.ru 1.1.1.1 TTL=1s
> Между этими серверами настраиваю (???что-то???, пока в голову идет HearthBeat), и если
> второй сервер не видит первого сервера, то на втором сервере ДНС
> меняется на:
> test.domain.ru 2.2.2.2 TTL=1sПочти так. Лепишь разновидность split horizon:
Зоны на NS1 и NS2 - разные. У одного все адреса в подсети, скажем 1.1.1.0, у другого в подсети 2.2.2.0. Пускай serial number в SOA у каждого = unix epoch в момент запроса, то есть это не обычный bind9. TTL = 1с.
Если сеть 1.1.1.0 обломалась, то resolver клиента просто не будет получать 1.1.1.1 для test.domain.ru. Будет там таймаут или network unreachable, зависит от провайдера 1.1.1.0.
NS1 и NS2 даже не нужно знать друг о друге.
> Почти так. Лепишь разновидность split horizon:
> Зоны на NS1 и NS2 - разные. У одного все адреса в
> подсети, скажем 1.1.1.0, у другого в подсети 2.2.2.0. Пускай serial number
> в SOA у каждого = unix epoch в момент запроса, то
> есть это не обычный bind9. TTL = 1с.а зачем заморочки с растущим serial ?
пусть будут просто два независимых DNS-сервера, каждый со своим значением адреса, и каждый с маленьким значением TTL.
клиент попадет на DNS случайным образом, получит запись, она закешируется на короткий промежуток времени, после чего будет повторный запрос и снова на случайный DNS-сервер.
Где тут важная роль растущего serial ? мое имхо говорит мне, что клиенту на это значение глубоко пофиг.
Разве не так?//клиент - ресольвер, кеширующий DNS и т п.
> Где тут важная роль растущего serial ? мое имхо говорит мне, что
> клиенту на это значение глубоко пофиг.
> Разве не так?
> //клиент - ресольвер, кеширующий DNS и т п.По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно расслабиться - сервер сказал, что зона не менялась.
Клиент зону может и скачал, но ничего делать не обязан.
>> Где тут важная роль растущего serial ? мое имхо говорит мне, что
>> клиенту на это значение глубоко пофиг.
>> Разве не так?
>> //клиент - ресольвер, кеширующий DNS и т п.
> По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно
> расслабиться - сервер сказал, что зона не менялась.Описанное вами будет происходить только при истечении TTL негативного ответа, да и то, является штукой не обязательной, кто как реализовал - это еще надо посмотреть.
Собственно это кеширование негативного ответа не является предметом дискуссии, а при кешировании положительного ответа, насколько я осведомлен, эта процедура (проверка serial зоны по истечению TTL записи) - не стандартизирована и не применяется.
Всё это также подтверждается парой запусков dig. Для негативных ответов (для отсутствующих записей по запросу) dig показывает, что сервер отправляет SOA (для поддерживающих фичу клиентов), для положительных ответов SOA не отправляется.
Если вы уверены, что указанное вами явление
> По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно
> расслабиться - сервер сказал, что зона не менялась.происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще приведите доказательство (с указанием наименований и версий софта), что это где-то происходит именно так, как указано вами.
А пока я считаю, что клиенту пофиг на serial в положительных ответах.
>>> Где тут важная роль растущего serial ? мое имхо говорит мне, что
>>> клиенту на это значение глубоко пофиг.[...]
>> По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно
>> расслабиться - сервер сказал, что зона не менялась.[...]
> происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще
> приведите доказательство (с указанием наименований и версий софта), что это где-то
> происходит именно так, как указано вами.
> А пока я считаю, что клиенту пофиг на serial в положительных ответах.Внимательно прочитай раздел 4.3.5. RFC1034. Более поздние навороты над ним же - #3.11 RFC1996, #8.2. RFC4033 и проч. немного запутывают картинку подписями и уведомлениями, оставляя исходную идею без изменений.
Попробуй написать распределённый кэш чего угодно, догадаешься до такого алгоритма сам.
>[оверквотинг удален]
>>> расслабиться - сервер сказал, что зона не менялась.
> [...]
>> происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще
>> приведите доказательство (с указанием наименований и версий софта), что это где-то
>> происходит именно так, как указано вами.
>> А пока я считаю, что клиенту пофиг на serial в положительных ответах.
> Внимательно прочитай раздел 4.3.5. RFC1034. Более поздние навороты над ним же -
> #3.11 RFC1996, #8.2. RFC4033 и проч. немного запутывают картинку подписями и
> уведомлениями, оставляя исходную идею без изменений.
> Попробуй написать распределённый кэш чего угодно, догадаешься до такого алгоритма сам.Всё что написано в 4.3.5 относится к слейв-серверам, поддерживающим зону. К клиентам и клиентским кэшам, обращающимся за данными зоны, это никакого отношения не имеет.
Такое поведение, что запись в _кеше_ считается валидной, если serial не изменился, специфицировано только для negative cache, да и то optional - не обязательное.
Для positive cache такой спецификации я не вижу вообще, т.е. такое поведение недопустимо, исходя из RFC1034.
>> Где тут важная роль растущего serial ? мое имхо говорит мне, что
>> клиенту на это значение глубоко пофиг.
>> Разве не так?
>> //клиент - ресольвер, кеширующий DNS и т п.
> По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно
> расслабиться - сервер сказал, что зона не менялась.
> Клиент зону может и скачал, но ничего делать не обязан.Может ошибаюсь, но где-то читал, что ie вообще пофиг на ttl и он будет долбиться в старый адрес часов 12. У него свой кеш и свой ttl)
с ДНС вроде понятно.
Теперь встала проблема о синхронизации файлов.
Как организовать синхронизацию файлов?
чтобы файлы синхронизовались и с основного и с вспомогательного сервера.
Что-то типа Мастер-Мастер...
> с ДНС вроде понятно.
> Теперь встала проблема о синхронизации файлов.
> Как организовать синхронизацию файлов?
> чтобы файлы синхронизовались и с основного и с вспомогательного сервера.
> Что-то типа Мастер-Мастер...csync2