dig A test.vsem
; <<>> DiG 9.3.4-P1 <<>> A test.vsem
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27554
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;test.vsem. IN A
;; ANSWER SECTION:
test.vsem. 3600 IN A 192.168.10.222
test.vsem. 3600 IN A 192.168.10.223
Запасной сервер для сайта
Здравствуйте! У меня возник следующий вопрос, но не понимаю с какой стороны подойти к решению! Хочется обеспечить бесперебойную работу сайта, с этой целью хочу разместить его на нескольких площадках. Только вот как теперь организовать такой механизм, чтобы, когда один сервере упадет, посетитель автоматически попадал на другой сервер?
То есть чтобы одному доменному имени соответствовало несколько разных ip, которые бы переключались когда нужно.
Я так понимаю, прописывание ip "запасного" сервера как альтернативный dns - это не то.
То есть чтобы одному доменному имени соответствовало несколько разных ip, которые бы переключались когда нужно.
Я так понимаю, прописывание ip "запасного" сервера как альтернативный dns - это не то.
В такой формулировке стандартным софтом такого сделать не получиться. В каждый момент времени в прелелах одного DNS сервера может быть только один IP для доменного имени.
Я не говорю уже о проблемах синхронизации этих серверов....
Я не говорю уже о проблемах синхронизации этих серверов....
Ну вопрос синхронизации меня сейчас не беспокоит.
Если знаете, можете посоветовать вариант решения попроще? Может конечно и формулировку я не очень корректную дал, но ведь делают так?
Если знаете, можете посоветовать вариант решения попроще? Может конечно и формулировку я не очень корректную дал, но ведь делают так?
Цитата: alekciy
В каждый момент времени в прелелах одного DNS сервера может быть только один IP для доменного имени.
да что вы говорите?
Dipish
в любом случае - у вас должна быть единая точка входа, которая будет по некоторым критериям разбрасывать запросы на бэкенды. например - можете использовать mod_proxy_balancer модуль для Apache 2.2 или nginx.
вот пример настройки для mod_proxy_balancer
http://www.howtoforge.com/load_balancing_apache_mod_proxy_balancer
вот описание модуля upstream для nginx
http://sysoev.ru/nginx/docs/http/ngx_http_upstream.html
что касается синхронизации контента - то тут вариантов море. например - rsync или даже сvs/svn по cron.
для БД - можно использовать репликацию. только ньюансик - вменяемой мультимастер репликации на популярных СУБД нету, посему - вам придется использовать один сервер на запись, а чтение делать на слейвах и реализовывать эту балансировку - программно. естественно я имею ввиду балансировку чтение/записть. средств для балансировки чтения между базами - вагон.
вот как то так... извините за сумбур - завтра, если что, распишу по-подробнее.
squirL большое спасибо за столь подробный ответ! Со средствами синхронизации я уже познакомился, а вот про прокси почитаю! Как раз о нем слышал, но совершенно не понимал что это за прокси такой.
Но только эта самая "точка входа" ведь такой же не застрахованный от падений сервер. И если прокси посыпится, мы вообще никуда не попадем, даже если обе площадки с сайтом работают. Но надо в иной раз смириться с фактом, что чудес не бывает =)
А как вы сами считаете, что можно сказать о таком способе организации по сравнению, скажем, с простой покупкой кластерного хостинга? По описанию кластерный хостинг весьма заманчив, но у конторы может быть какая-нибудь глобальная проблема, и тогда будет утерян функционал всех кластеров. Вот из таких соображений (замечу свою скудную осведомленность в данном вопросе) я глянул в сторону покупки двух площадок у разных хостеров... хочется верить что вероятность аварии у двух хостеров одновременно меньше вероятности аварии у одного хостера! %) Буду очень благодарен если поделитесь объяснениями и, если есть, опытом!
Еще раз спасибо за статью о прокси, как раз с этим хотел ознакомиться!
Но только эта самая "точка входа" ведь такой же не застрахованный от падений сервер. И если прокси посыпится, мы вообще никуда не попадем, даже если обе площадки с сайтом работают. Но надо в иной раз смириться с фактом, что чудес не бывает =)
А как вы сами считаете, что можно сказать о таком способе организации по сравнению, скажем, с простой покупкой кластерного хостинга? По описанию кластерный хостинг весьма заманчив, но у конторы может быть какая-нибудь глобальная проблема, и тогда будет утерян функционал всех кластеров. Вот из таких соображений (замечу свою скудную осведомленность в данном вопросе) я глянул в сторону покупки двух площадок у разных хостеров... хочется верить что вероятность аварии у двух хостеров одновременно меньше вероятности аварии у одного хостера! %) Буду очень благодарен если поделитесь объяснениями и, если есть, опытом!
Еще раз спасибо за статью о прокси, как раз с этим хотел ознакомиться!
Цитата: Dipish
[
Но только эта самая "точка входа" ведь такой же не застрахованный от падений сервер. И если прокси посыпится, мы вообще никуда не попадем, даже если обе площадки с сайтом работают. Но надо в иной раз смириться с фактом, что чудес не бывает =)
Но только эта самая "точка входа" ведь такой же не застрахованный от падений сервер. И если прокси посыпится, мы вообще никуда не попадем, даже если обе площадки с сайтом работают. Но надо в иной раз смириться с фактом, что чудес не бывает =)
тут есть такие штуки, как carp, например :) вот неплохая обзорная статейка:
http://www.citforum.ru/internet/webservers/web_cluster/
Цитата: squirL
да что вы говорите?
Угу. Говорю что знаю. Может и ошибаясь, тогда вдвойне интереснее.
Если возможно, то пример конфига BIND-а отдающего при DNS запросе список адресов на клиент.
Мне смутно помниться приходилось видеть конфиги при которых DNS отдает данные в зависимости от IP вопрошающего, но DNS отдающий через раз разные IP... что-то в стандартном конфиге я такого не припомню.
И такая схема подразумевает не использование центральной точки входа.
Код:
проверяем как ресолвятся две A записи
Код:
ping test.vsem
PING test.vsem (192.168.10.223): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
[squirl@gate ~]$ ping test.vsem
PING test.vsem (192.168.10.222): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
[squirl@gate ~]$ ping test.vsem
PING test.vsem (192.168.10.223): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
[squirl@gate ~]$ ping test.vsem
PING test.vsem (192.168.10.222): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
PING test.vsem (192.168.10.223): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
[squirl@gate ~]$ ping test.vsem
PING test.vsem (192.168.10.222): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
[squirl@gate ~]$ ping test.vsem
PING test.vsem (192.168.10.223): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
[squirl@gate ~]$ ping test.vsem
PING test.vsem (192.168.10.222): 56 data bytes
^C
--- test.vsem ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
что
Спасибо за ссылки, много нового узнал! Буду переваривать =)