Доброго времени суток.
Стыдно задавать такие вопросы, но не хочется изобретать велосипед.
Суть.
Есть сервер, на котором крутится веб с парой десятков сайтов. Сервер этот VPS, находится у хостера. Сегодня утром возникла ситуация, когда у хостера были проблемы с провайдером. Соответственно, все наши сайты были недоступны.
Работоспособность сайтов крайне критична.
Каким образом можно обеспечить доступность сайтов?
Если организовывать резервный сервер у другого хостера, то как должно происходить взаимодействие (как происходит переключение, контроль доступности и т.д.)?
1 вариант. Поднимаете сайты у другого хостера, базы данных синхронизируете через репликацию, в днс указываете адреса обоих серверов. Получите два параллельных сервера, в случае отказа одного - второй продолжит работу... Репликация в режиме master-master, следует контролировать состояние на обоих серверах.
2 вариант. На втором хостере поднимаете сайты, базы также в реплику. В днс указываете адрес только первого сервера, мониторите его доступность, при отказе - меняете днс. Днс ttl надо держать небольшим - от этого зависит время обновления записей. Ну и требуется мониторинг доступности.
Я бы выбрал первый вариант - он проще в обслуживании.
> в днс указываете адреса обоих серверов
> в случае отказа одного - второй продолжит работу...
Второй работу-то продолжит, вот только половина клиентов будет ходить в упавший сервер.
> Репликация в режиме master-master
Базар-то фильтруйте. Человек вообще не сталкивался с репликацией, судя по всему, а вы ему мастер-мастер предлагаете =)
и что теперь? Не предлагать? По крайней мере человек будет знать, в какую сторону смотреть
И насчет днс - вы не правы. Если хост резолвится в несколько адресов и часть адресов недоступна - то броузер будет перебирать адреса дальше, пока не соединится. Проверено на опыте, так не только броузеры себя ведут. Я в свое время так PPTP VPN сервера резервировал.
Руслан Федосеев: не будет он перебирать адреса.
Некоторые (подчеркиваю, некоторые - и это не chrome самый популярный) перебирают адреса только при условии connection failed, что выливается в тормоза по 60 секунд на страницу в случае blackhole. А в случае наличия коннекта и ошибки на стороне сервера - ни один браузер перебирать не будет.
> По крайней мере человек будет знать, в какую сторону смотреть
Ну да, шикарная сторона, высказанная человек с незнанием самых основ в работе Сети.
уговорили, откуда мне сирому основы работы Сети то знать... я тут так, провайдером работаю...
Итак, вернемся к вопросу. "Сегодня утром возникла ситуация, когда у хостера были проблемы с провайдером". Что в данном случае будет? Праавильно, connection failed. Описанный вами вариант размещается весь целиком у этого самого хостера. Если нет - то я с интересом послушаю, как вы поверх интернета файловую систему разворачивать будете... С негарантированными задержками и транспортом. Ну или просто репликацию ФС. Как развернете и заработает - можете посылать свое резюме в IBM,Google и т.п. Оторвут с обоими руками...
Руслан Федосеев: ну а почему бы и нет если проект серьезный это более менее правильный подход + балансировка нагрузки и в любом случае сайт останется доступен.
Может я и не прав, я не администратор но просто думаю вариант такой правильнее. :)
не совсем. Мы получаем одну точку отказа. Что будет, если откажет вот этот третий сервер? Правильно, вся связка перестанет работать. В моем 1-м варианте оба сервера равноправны. И сайт будет недоступен только в случае отказа одновременно обоих хостеров.
Если уж мы ставим балансировщик - его тоже надо резервировать ;) И мы все равно приходим к моему варианту, усложненному тем, что кроме рабочих серверов мы зарезервировали еще и балансировщики...
Тогда уж стоит идти в сторону облаков...
Люди, решающие подобные проблемы, получают от 80к в месяц (сильно от).
А так - galera, gluster, система деплоя, чтобы конфиги одинаковые были, какой-нибудь балансер поумнее, чем "сервер упал - треть клиентов идет лесом" (тот же failover IP у hetzner/linode/ovh).
А, да, вся эта байда не имеет смысла при количестве нод меньше трех - split-brain будет.
fiercebrute: failover ip - само собой, в пределах хостера (ну или со своими BGP-анонсами).
А так можно и с dns извратиться, но не тупым RR, а несколькими NS для каждого домена, которые сами на себя отдают А-записи.
;) Между тем описанное мной решение реализуется буквально за несколько часов и спокойно работает. Нет, если речь идет о сайтах уровня lj.ru или vk.com - то да, там все ваши страшные слова нужны. А если речь идет просто о сайте небольшой компании, которая не хочет зависеть от одного хостера - то тут специалист "сильно от 80к" просто не нужен
Руслан Федосеев: "то да, там все ваши страшные слова нужны" там как раз эти страшные слова не работают, а вот для мелких сайтов - самое то.
И да, поднимается тоже за несколько часов.
Руслан Федосеев: блеа, ЛЮБОЙ вариант проще, чем мастер-мастер репликация под софтом, который писали без рассчета на мастер-мастер, уж поверьте =)
Ну и ваш вариант с dns не работает для протоколов http(s). Если у провайдера упадет BGP - то blackhole, тормоза по 60 секунд (ну а половина клиентов просто не попадет на сайт). Если упадет один из серверов, но будет отвечать по 80му порту - то половина клиентов будет попадать на него и видеть ошибку.
У меня биллинг написан был нами без учета мастер-мастер репликации. В один прекрасный момент я взял, и поднял мастер-мастер репликацию. И биллинг туда перевел. И десяток популярных движков для сайтов на этом кластере сидели.... Так что не рассказывайте.
Если уж так не нравится репликация - поднимите сервер базы данных отдельно. Только как вы его защищать от падения будете....
Средний
Простой
