LINUX.ORG.RU

Отказоустойчивость веб-серверов.

 , , ,


0

2

Привет всем , имея 2 сервера с nginx за разными ip адресами необходимо настроить отказоустойчивость на случай выхода из строя одного из серверов , я предпологаю сделать это на уровне домена , но не представляю как он будет проверять сервер на доступность в случае отказа прежде чем выдать результат пользователю .

Подскажите пожалуйста как это лучше всего организовать ?

Гугли «Round robin DNS». У домена две одноимённые записи типа A, в первой IP первого сервера, во второй — второго. DNS сервер возвращает оба адреса меняя их порядок. Клиенты сначала пытаются подключиться к первому IP, если не получается то пытаются подключиться ко второму (кажется это поведение не стандартизировано). Это наверное самый простой вариант достижения отказоустойчивости

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

кажется это поведение не стандартизировано

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

Алсо два первых совета в теме, хотя и правильные, это может быть не совсем то, что нужно автору.

goingUp ★★★★★ ()
Последнее исправление: goingUp (всего исправлений: 1)

Ну какая ещё отказоустойчивость на уровне DNS, ну о чём вы.
Только кластеризация и плавающие адреса спасут отца русской демократии.
В нормальном состоянии каждый адрес висит на своей ноде, в случае отказа одной ноды адрес переплывает на оставшуюся рабочую ноду.

Совет про балансировщик норм, но если он является SPoF(единая точка отказа) то в случае его выхода из строя весь сервис падает, даже если у тебя при этом обе ноды живы.

zolden ★★★★★ ()
Ответ на: комментарий от goingUp

Когда я в последний раз интересовался оно работало во всех актуальных браузерах. Оно было давно, но не настолько давно чтобы IE7 считался актуальным

MrClon ★★★★★ ()
Ответ на: комментарий от zolden

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

И это будет работать только в контексте одного свитча/ДЦ?

deep-purple ★★★★★ ()
Ответ на: комментарий от The_Ketchup

Если он так запросто плавает, то тут видимо всего замешана динамическая маршрутизация и собственная AS.
Если всё так по-взрослому то наверное стоит смотреть в сторону Anycast и BGP и не париться кластеризацией.

zolden ★★★★★ ()
Ответ на: комментарий от deep-purple

У нас, например, темная оптика никак не касается самого цода, подключается напрямую в наше оборудование, проблемы сети самого цода нас никак не касаются.

Вот смысл?

Смысл как раз защититься либо от полной потери цода, либо от потери аплинков в одном цоде. В случае проблем сервис будет прекрасно доступен через второй цод.

user_undefined ()
Ответ на: комментарий от user_undefined

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

т.е. не в каждом цоде можно договориться так удобно

в боле-менее крупных цодах найти того, кто продаст темную оптику совсем не проблема, были бы деньги.

и еще, а что толку в нецодовской своей личной сиське?

не, ну если один сервак, да к тому же еще и арендованый, то толку нет. А если арендуются десятки стоек, то и никакого цодовского оборудования нет, все свое, включая циски.

оно ж электричество то цодовское так и так юзать будет

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

user_undefined ()
Ответ на: комментарий от MrClon

С RR DNS есть вопросы, как ты будешь синхронизировать куки.

Кроме того, если один из серверов умрет, то его IP от этого не перестанет отдаваться пользователям, что приведет к тому, что половина запросов будет уходить в никуда -> увеличивается время отклика -> пользователи недовольны.

CaveRat ()
Ответ на: комментарий от zolden

Совет про балансировщик норм, но если он является SPoF(единая точка отказа) то в случае его выхода из строя весь сервис падает, даже если у тебя при этом обе ноды живы.

Во-первых, никто не запрещает сделать HA LB :) Кроме того, если использовать железный балансер (хотя это явно не случай ТС-а) - можешь посмотреть MTBF и посчитать вероятность отказа в заданный период.

CaveRat ()
Ответ на: комментарий от CaveRat

С RR DNS есть вопросы, как ты будешь синхронизировать куки.

Справедливо для любого варианта резервирования или распределения нагрузки без SPoF. Будут какие-то данные которые надо синхронизировать между нодами. Сессионные данные тут меньшая из проблем.

Конкретно куки синхронизировать не надо, куки на клиенте. Привязку session id к пользователю можно хранить в самих куках (грубо говоря session_id=$username+sha($username+$secret+$date))

Кроме того, если один из серверов умрет, то его IP от этого не перестанет отдаваться пользователям, что приведет к тому, что половина запросов будет уходить в никуда -> увеличивается время отклика -> пользователи недовольны.

Я и не говорил что решение идеально. Это лучше чем SPoF умер, все запросы отправились в ад, пользователи негодуют. Схему можно улучшить используя A записи с низким TTL и свой DNS сервер отслеживающий состояние фронтэндов и выкидывающий лежащие из ротации. Но слишком сильно уменьшать TTL доменных записей не стоит, да и всегда найдутся DNS сервера которые закешируют на сутки запись с TTL в 10 минут, так что RR всё-равно нужен

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

Справедливо для любого варианта резервирования или распределения нагрузки без SPoF. Будут какие-то данные которые надо синхронизировать между нодами. Сессионные данные тут меньшая из проблем.

Согласен, только почему SPoF-то? Балансировщики умеют делать отказоустойчивость!

Я и не говорил что решение идеально. Это лучше чем SPoF умер, все запросы отправились в ад, пользователи негодуют. Схему можно улучшить используя A записи с низким TTL и свой DNS сервер отслеживающий состояние фронтэндов и выкидывающий лежащие из ротации. Но слишком сильно уменьшать TTL доменных записей не стоит, да и всегда найдутся DNS сервера которые закешируют на сутки запись с TTL в 10 минут, так что RR всё-равно нужен

Это все, извините, костыли.

CaveRat ()
Ответ на: комментарий от CaveRat

Согласен, только почему SPoF-то? Балансировщики умеют делать отказоустойчивость!

Если балансировщик один то он SPoF, если их более одного то между ними нужно как-то балансировать трафик. Например с помощью DNS RR. Есть конечно и другие варианты (anycast routing например), но они более требовательны к сетапу. Для DNS RR достаточно двух серверов (или VPS, или шаред-хостингов :) и примерно любого DNS хостинга, и можно улучшать по мере необходимости.

И у меня сложилось впечатление что у ТСа сейчас нет ресурсов (материальных, человеческих) что бы мутить что то сильно сложнее простейшей версии DNS RR. Разве-что его провайдер предоставляет собственную баллансировку-как-сервис

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

Если балансировщик один то он SPoF, если их более одного то между ними нужно как-то балансировать трафик. Например с помощью DNS RR. Есть конечно и другие варианты (anycast routing например), но они более требовательны к сетапу.

Между балансировщиками не обязательно делать балансировку, хватит отказоустойчивости, которой можно добиться тем же VRRP, который поддерживают, по моему, вообще все. А у больших балансировщиков есть свои внутренние механизмы кластеризации.

И у меня сложилось впечатление что у ТСа сейчас нет ресурсов (материальных, человеческих) что бы мутить что то сильно сложнее простейшей версии DNS RR. Разве-что его провайдер предоставляет собственную баллансировку-как-сервис

Ну да. LBaaS сейчас многие делают.

CaveRat ()
Ответ на: комментарий от CaveRat

можно добиться тем же VRRP

Сервера должны быть в одной сети, и на сколько я понимаю нужна какая-то дополнительная поддержка со стороны сети. Как минимум IP не должен быть прибит к порту свича. ТС не сообщил почти никаких подробностей, так что мы даже не можем быть уверены что сервера в одном ДЦ.

Да и вообще ТС пропал куда то

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

на сколько я понимаю нужна какая-то дополнительная поддержка со стороны сети. Как минимум IP не должен быть прибит к порту свича.

IP?? К порту свитча? Свитч, как правило, про IP не думает, он думает про MAC, а они у серверов будут разные.

ТС не сообщил почти никаких подробностей, так что мы даже не можем быть уверены что сервера в одном ДЦ

Если они у ТСа в разных ЦОДах, то тут уже надо думать про GSLB, который делается очень по-разному на разных решениях.

CaveRat ()
Ответ на: комментарий от CaveRat

IP?? К порту свитча? Свитч, как правило, про IP не думает, он думает про MAC, а они у серверов будут разные.

За пределами домашних сеток клиентов друг от друга стараются изолировать, так или иначе

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

ТС не сообщил почти никаких подробностей

Да и вообще ТС пропал куда то

Кмк, у него защита на носу. Он еле-еле успел раздел по отказоустойчивости дописать. )

vvn_black ★★★★ ()
Ответ на: комментарий от user_undefined

если все совсем плохо стало - тогда второй цод и включится в работу

Эт смотря в каком цоде фронтальная сиська. Может стать что никакой уже не включится — по факту пашут, а сетки до них нет.

deep-purple ★★★★★ ()
Ответ на: комментарий от MrClon

Это прекрасно, к чему это было? Узлы VRRP находятся в одной сети, они, условно, подключены к одному коммутатору. Просто в какой-то момент времени на vIP отвечает первый узел, в случае его отказа - второй. При чем тут изоляция?

CaveRat ()
Ответ на: комментарий от MrClon

ХЗ, мне так не показалось

Да, посмотрел активность ТСа, скорее не студент, чем обратное. Но проблемы поднимает довольно специфичные.

vvn_black ★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от CaveRat

К тому что в норме сеть не позволит узлу А получать трафик адресованный на IP привязанный к узлу Б. Сеть должна знать что эти два узла и этот vIP принадлежат одному клиенту и vIP может мигрировать между этими узлами. Иначе что помешает хосту другого клиента анонсировать этот vIP и забрать себе твой трафик? т.е. это отдельная услуга от ДЦ, которую он может и не предоставлять

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

В норме коммутатор вообще не знает, что такое IP-адрес. Он оперирует mac-ами. Которые, в случае VRRP, никуда не мигрируют.

Сеть должна знать что эти два узла и этот vIP принадлежат одному клиенту и vIP может мигрировать между этими узлами. Иначе что помешает хосту другого клиента анонсировать этот vIP и забрать себе твой трафик?

arp inspection - это очень круто, ровно до тех пор, пока не приходится это поддерживать. Проще ограничить и контролировать узлы, которые находятся в защищаемом vlan-е, чем такое городить.

CaveRat ()
Ответ на: комментарий от CaveRat

Зачем обязательно arp inspection? Да хотя бы и теми же vlan-ами можно: по одному vlan на клиентский порт, все вланы втыкаются в роутер в который система управления конфигурацией вливает правила какой IP в какой vlan роутить

MrClon ★★★★★ ()
Ответ на: комментарий от deep-purple

Так в том то и фишка, в случае сбоя адреса будут анонсироваться и доступны через другой цод и соответственно другую циску. Тут уже выше писали про динамическую маршрутизацию. Но да, нужна своя AS. Для мелких проектов из двух серверов - явный перебор, но для чего-то боле-менее крупного вполне приемлемо.

user_undefined ()

Че то в дебри уходим :)) итак еще раз у нас есть 2IP адреса (в разных местах) за которыми сидят ->pfsense->nginx (отдельными виртуалками )со статикой по сути они просто прокси без бд и так далее , неужели нету нормального адекватного способа смастерить нормальную отказоустойчивость ? Прошу прощения но я просто в ступоре как бы это правильно реализовать :)

Rebbit ()