| Обеспечение отказоустойчивости веб-сайта с использованием сервера горячего резерва [сообщение #1176] |
Птн, 24 Июнь 2011 22:09 |
Roman
Сообщений: 4
Зарегистрирован: Июнь 2011
|
Junior Member |
|
|
Предпосылки
Эта статья содержит пример обеспечения отказоустойчивости сайта с помощью DNS и сервера горячего резерва.
Для того чтобы избежать публикации деталей, которые могут применяться на оборудовании, принадлежащем другим организациям, доменное имя, используемое в примере, будет example.com, и используемые IP-адреса, будут из приватного диапазона. Эта практика соответствует рекомендациям IETF, как это написано в различных RFC.
Сценарий использования
example.com хочет гарантировать, что сайт будет доступен даже, если их основной дата-центр станет недоступным. Копия сайта размещена в альтернативном дата-центре. Альтернативный сервер должен использоваться только, если главный сервер недоступен. Сайт публикуется как example.com и www.example.com.
Типовая настройка отказоустойчивости веб-сервера (сайта)
1. Создайте две А-записи для example.com: одну на IP-адрес главного сервера, другую на IP-адрес сервера горячего резерва. Установите TTL у обоих записей на значение между 600 и 60 секундами. Пометьте обе как "failback on recovery". Пометьте сервер резерва, как сервер горячего резерва.
2. Создайте одну запись алиаса для www.example.com с указанием на example.com с соответствующим TTL. Алиас www.example.com будет автоматически следовать за example.com.
3. Создайте тестовый монитор HTTP для каждой из двух А-записей. Тест будет проходить автоматически с интервалом равным 20% от основного TTL. Тестовый интервал ограничен диапазоном от 900 до 60 секунд.
4. Включите оповещения для каждого тестового монитора.
5. Создайте административные записи для каждого сервера: main.example.com, указывающую на главный сервер, и fail.example.com, указывающую на сервер горячего резерва. Эти записи используются администратором для прямого доступа к правильному серверу. Эти записи не должны мониториться.
Системные операции
Система мониторинга отслеживает доступность сервисов на всех серверах, как на основном, так и на резервном. Мониторинг доступности осуществляется одновременно с нескольких точек.
А-запись помечается как недоступная, если ни один из запросов системы мониторинга не получил правильный отклик. Если хотя бы один из запросов получил отклик, то А-запись считается доступной к использованию. Если А-запись адреса продуктивного сервера помечается как недоступная, то ее замещает запись с резервного сервера. Администратор сайта оповещается об этом.
Система мониторинга продолжает тестировать все помеченные к наблюдению А-записи example.com. Когда главный сервер снова становится доступным, А-записи восстанавливаются в начальное состояние.
Дополнительная информация
Если ни один из серверов example.com недоступен, А-запись направляется на hold.dxmx.org. Этот сервер поддерживается Edgedirector. Он оповещает, что example.com в настоящее время не доступен и предлагает посетителю попробовать еще раз через несколько минут.
Только А-запись может быть настроена для мониторинга. Все А-записи с одинаковым именем это часть одной группы. Все остальные записи определяют А-записи по имени и будут следовать им автоматически.
У продуктивного сервера может быть много A-записей. DNS будет возвращать только рабочие А-записи. Кроме того, может существовать множество А-записей на резервные сервера. Однако, пока доступны продуктивные сервера, ни одна резервная А-запись не будет возвращена.
Значение TTL влияет на то, как быстро сайт может быть переключен между серверами и снова стать доступным, в случае "падения" продуктивного сервера. Рекомендованное значение 300 секунд. Значения больше 600 секунд не рекомендованы из-за медленного переключения на резервный сервер.
Администраторы сайтов могут принять решение об использовании балансировки нагрузки и отказоустойчивости серверов совместно. Это позволит лучше использовать ресурсы.
Необязательно, чтобы главный и резервный сайты были идентичны по контенту и функциональности. Например, главный сайт может находиться на выделенном сервере в дата-центе, в то время как резервный может размещаться на массовом хостинге.
А-запись может быть удалена из системы мониторинга вручную с использованием панели управления. Это позволит отключить действующий сайт для технического обслуживания, в то время как резервный сервер примет на себя посетителей.
Облачная конфигурация
В случае если резервное копирование (бэкап) сайта делается вручную на облачные сервисы, то для настройки сервера горячего резерва требуется внести изменения в конфигурации.
Назначьте основной сервер и резервную копию на "облаке" как отказоустойчивые, и резервный сервер как сервер горячего резерва.
Когда главный сервер будет недоступен, автоматически будет задействован резервный сервер, поскольку сайт на облачном сервисе будет еще не доступен. Как только администратор задействует сайт на "облаке", резервный сервер будет отключен в пользу облачного сервиса.
Когда основной сервер снова станет доступным, его А-запись будет восстановлена в DNS. Как только заработает основной сервер, администратор удалит А-запись, ссылающуюся на облачный сервис.
В этот момент будет задействован только главный сервер.
Оригинал статьи и ссылка на иностранный первоисточник в нашем блоге:
Отказоустойчивость веб-сайта с использованием сервера горячего резерва
[Обновления: Сбт, 19 Ноябрь 2011 08:41] Известить модератора |
|
|
|
Форум компании ITRM
Поиск
F.A.Q.
Регистрация
Вход
Начало
