форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Сеть. проблемы, диагностика)
Изначальное сообщение		[ Отслеживать ]

"Организация высокодоступного ВЕБ-сервера"	+/–
Сообщение от dimawar (ok) on 05-Фев-13, 08:02
Всем доброго времени суток! Прошу совета по следующей проблеме: Требуется организовать серверную структуру с высокой доступностью веб-приложения. Как я себе это вижу: 1. Размещаем 2 разных сервера в 2-х ЦОДах. 2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в случае падения одного сервера все запросы обрабатывал второй сервер. (в инете нашел статью с wackamole и apache+mod_backhand, но она уже старая) 3. На серверах находятся базы MySQL - решить проблему синхронизации планирую через MySQL репликацию Master-Master. По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в качестве балансировщика, но что будет, если ДНС запрос закешировался и пакеты будут идти на сдохший сервер?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Организация высокодоступного ВЕБ-сервера"	+/–
Сообщение от PavelR (ok) on 05-Фев-13, 09:27
> Всем доброго времени суток! > Прошу совета по следующей проблеме: > Требуется организовать серверную структуру с высокой доступностью веб-приложения. Судя по вопросам, вы еще мало гуглили. Эти вопросы мал-мальски разжеваны. > Как я себе это вижу: > 1. Размещаем 2 разных сервера в 2-х ЦОДах. > 2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в > случае падения одного сервера все запросы обрабатывал второй сервер. неа, не взлетит. > 3. На серверах находятся базы MySQL - решить проблему синхронизации планирую через > MySQL репликацию Master-Master. > По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в > качестве балансировщика, какую проблему вы считаете второй? > но что будет, если ДНС запрос закешировался и пакеты > будут идти на сдохший сервер? надо ставить маленький TTL.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от dimawar (ok) on 05-Фев-13, 10:35
	>> Всем доброго времени суток! >> Прошу совета по следующей проблеме: >> Требуется организовать серверную структуру с высокой доступностью веб-приложения. > Судя по вопросам, вы еще мало гуглили. Эти вопросы мал-мальски разжеваны. Не нашел ничего свежего по данной теме. Может подскажите? >> По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в >> качестве балансировщика, > какую проблему вы считаете второй? >> но что будет, если ДНС запрос закешировался и пакеты >> будут идти на сдохший сервер? > надо ставить маленький TTL. Маленький ТТЛ поставлю, но тогда придется размещать зоны ДНС на этих серверах, и их перезаписывать. Вот если бы как-то иначе решить данную проблему...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от PavelR (ok) on 05-Фев-13, 20:37
	> Маленький ТТЛ поставлю, но тогда придется размещать зоны ДНС на этих серверах, не понимаю вашу логику. Вовсе не придется. Мастер (источник обновлений) зоны надо разместить там, где будет осуществляться контроль за доступностью веб-серверов. Где будут слейвы - вообще фиолетово, главное чтобы они нотификейшны от мастера получали и обрабатывали.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	9. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от Andrey Mitrofanov on 05-Фев-13, 21:19
	>> Маленький ТТЛ поставлю, но тогда придется размещать зоны ДНС на этих серверах, > не понимаю вашу логику. Ж) ...может, он про TTL IP пакетов?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

3. "Организация высокодоступного ВЕБ-сервера"	+/–
Сообщение от ALex_hha (ok) on 05-Фев-13, 10:58
>[оверквотинг удален] > Как я себе это вижу: > 1. Размещаем 2 разных сервера в 2-х ЦОДах. > 2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в > случае падения одного сервера все запросы обрабатывал второй сервер. (в инете > нашел статью с wackamole и apache+mod_backhand, но она уже старая) > 3. На серверах находятся базы MySQL - решить проблему синхронизации планирую через > MySQL репликацию Master-Master. > По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в > качестве балансировщика, но что будет, если ДНС запрос закешировался и пакеты > будут идти на сдохший сервер? Failover ip спасет отца русской демократии
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от Alexey (??) on 05-Фев-13, 12:27
	почему бы два сервера не держать в одном ДЦ и еще IP будет из одной сетки ? тогда можено heartbeat можно так же сделать 1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри на IP-nginx
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от ALex_hha (ok) on 05-Фев-13, 12:29
	> почему бы два сервера не держать в одном ДЦ и еще IP > будет из одной сетки ? > тогда можено heartbeat > можно так же сделать > 1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри > на IP-nginx ложится сеть в ДЦ и превед, только не надо говорить, что это маловероятно :D
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от dimawar (ok) on 05-Фев-13, 12:36
	Вот статью нашел http://www.opennet.me/docs/RUS/webcluster/ - то что надо. Но оно уже устарело и отзывы об апаче не очень в данной ситуации.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	13. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от Alexey (??) on 07-Фев-13, 09:45
	>> почему бы два сервера не держать в одном ДЦ и еще IP >> будет из одной сетки ? >> тогда можено heartbeat >> можно так же сделать >> 1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри >> на IP-nginx > ложится сеть в ДЦ и превед, только не надо говорить, что это > маловероятно :D ну тоже вероятность есть.. так же как и вероятность того, что ляжет сеть и там и там или ДЦ ляжет и там и там
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	14. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от ALex_hha (ok) on 07-Фев-13, 12:54
	>[оверквотинг удален] >>> будет из одной сетки ? >>> тогда можено heartbeat >>> можно так же сделать >>> 1 сервер nginx -> который использует как upstream IP1-server, IP2-server, DNS смотри >>> на IP-nginx >> ложится сеть в ДЦ и превед, только не надо говорить, что это >> маловероятно :D > ну тоже вероятность есть.. так же как и вероятность того, что ляжет > сеть и там и там или ДЦ ляжет и там и > там 100% дают сами знаете где :D Даже хваленный Rackspace со своими 100% uptime садился пару раз в лужу ;)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

8. "Организация высокодоступного ВЕБ-сервера"	+/–
Сообщение от ACCA (ok) on 05-Фев-13, 21:02
> 1. Размещаем 2 разных сервера в 2-х ЦОДах. > 2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в Это называется multihoming, одним адресом не обойдёшься, очень желателен Provider-Independent (PI) адресный блок. Сейчас не решается никак - адреса IPv4 тупо кончились. Сделай просто - в обоих ЦОД по DNS серверу, каждый ресолвит домен в местный адрес, постоянно увеличивая версию зоны. Клиенты сами будут делать round robin, балансировка лишняя. > По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в > качестве балансировщика, но что будет, если ДНС запрос закешировался и пакеты > будут идти на сдохший сервер? Клиент отвалится по таймауту, перезапросит. С multihoming процесс может быть ещё дольше.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от dimawar (ok) on 06-Фев-13, 04:49
	> Сделай просто - в обоих ЦОД по 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 Так получается?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от ACCA (ok) on 07-Фев-13, 01:22
	> В настройках домена я указываю 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 даже не нужно знать друг о друге.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от PavelR (ok) on 07-Фев-13, 09:00
	> Почти так. Лепишь разновидность 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 и т п.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от ACCA (ok) on 08-Фев-13, 17:17
	> Где тут важная роль растущего serial ? мое имхо говорит мне, что > клиенту на это значение глубоко пофиг. > Разве не так? > //клиент - ресольвер, кеширующий DNS и т п. По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно расслабиться - сервер сказал, что зона не менялась. Клиент зону может и скачал, но ничего делать не обязан.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	16. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от PavelR (ok) on 08-Фев-13, 22:18
	>> Где тут важная роль растущего serial ? мое имхо говорит мне, что >> клиенту на это значение глубоко пофиг. >> Разве не так? >> //клиент - ресольвер, кеширующий DNS и т п. > По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно > расслабиться - сервер сказал, что зона не менялась. Описанное вами будет происходить только при истечении TTL негативного ответа, да и то, является штукой не обязательной, кто как реализовал - это еще надо посмотреть. Собственно это кеширование негативного ответа не является предметом дискуссии, а при кешировании положительного ответа, насколько я осведомлен, эта процедура (проверка serial зоны по истечению TTL записи) - не стандартизирована и не применяется. Всё это также подтверждается парой запусков dig. Для негативных ответов (для отсутствующих записей по запросу) dig показывает, что сервер отправляет SOA (для поддерживающих фичу клиентов), для положительных ответов SOA не отправляется. Если вы уверены, что указанное вами явление > По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно > расслабиться - сервер сказал, что зона не менялась. происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще приведите доказательство (с указанием наименований и версий софта), что это где-то происходит именно так, как указано вами. А пока я считаю, что клиенту пофиг на serial в положительных ответах.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от ACCA (ok) on 16-Фев-13, 00:11
	>>> Где тут важная роль растущего serial ? мое имхо говорит мне, что >>> клиенту на это значение глубоко пофиг. [...] >> По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно >> расслабиться - сервер сказал, что зона не менялась. [...] > происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще > приведите доказательство (с указанием наименований и версий софта), что это где-то > происходит именно так, как указано вами. > А пока я считаю, что клиенту пофиг на serial в положительных ответах. Внимательно прочитай раздел 4.3.5. RFC1034. Более поздние навороты над ним же - #3.11 RFC1996, #8.2. RFC4033 и проч. немного запутывают картинку подписями и уведомлениями, оставляя исходную идею без изменений. Попробуй написать распределённый кэш чего угодно, догадаешься до такого алгоритма сам.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от PavelR (??) on 16-Фев-13, 10:08
	>[оверквотинг удален] >>> расслабиться - сервер сказал, что зона не менялась. > [...] >> происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще >> приведите доказательство (с указанием наименований и версий софта), что это где-то >> происходит именно так, как указано вами. >> А пока я считаю, что клиенту пофиг на serial в положительных ответах. > Внимательно прочитай раздел 4.3.5. RFC1034. Более поздние навороты над ним же - > #3.11 RFC1996, #8.2. RFC4033 и проч. немного запутывают картинку подписями и > уведомлениями, оставляя исходную идею без изменений. > Попробуй написать распределённый кэш чего угодно, догадаешься до такого алгоритма сам. Всё что написано в 4.3.5 относится к слейв-серверам, поддерживающим зону. К клиентам и клиентским кэшам, обращающимся за данными зоны, это никакого отношения не имеет. Такое поведение, что запись в _кеше_ считается валидной, если serial не изменился, специфицировано только для negative cache, да и то optional - не обязательное. Для positive cache такой спецификации я не вижу вообще, т.е. такое поведение недопустимо, исходя из RFC1034.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от bill (ok) on 01-Мрт-13, 19:17
	>> Где тут важная роль растущего serial ? мое имхо говорит мне, что >> клиенту на это значение глубоко пофиг. >> Разве не так? >> //клиент - ресольвер, кеширующий DNS и т п. > По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно > расслабиться - сервер сказал, что зона не менялась. > Клиент зону может и скачал, но ничего делать не обязан. Может ошибаюсь, но где-то читал, что ie вообще пофиг на ttl и он будет долбиться в старый адрес часов 12. У него свой кеш и свой ttl)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "Организация высокодоступного ВЕБ-сервера"	+/–
Сообщение от dimawar (ok) on 28-Фев-13, 07:22
с ДНС вроде понятно. Теперь встала проблема о синхронизации файлов. Как организовать синхронизацию файлов? чтобы файлы синхронизовались и с основного и с вспомогательного сервера. Что-то типа Мастер-Мастер...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Организация высокодоступного ВЕБ-сервера"	+/–
	Сообщение от stre10k (ok) on 06-Мрт-13, 09:54
	> с ДНС вроде понятно. > Теперь встала проблема о синхронизации файлов. > Как организовать синхронизацию файлов? > чтобы файлы синхронизовались и с основного и с вспомогательного сервера. > Что-то типа Мастер-Мастер... csync2
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема