- PVSM.RU - https://www.pvsm.ru -
Итак, у нас есть коммерческий online-сервис, а наши клиенты — это компании, которые используют наш сервис 24x7. Наша задача, чтобы клиенты были счастливы и наши внутренние проблемы, связанные с отказом оборудования и ПО оставались для клиента максимально незамеченными. Клиенту вовсе не надо знать о том, что у нас сгорел RAID-контроллер, а системный администратор живет в Таиланде и не привык рано вставать.
Во первых, под online-сервисом будем понимать нечто более широкое, чем «информационный» WEB-сайт. Например, описываемое в данной статье решение было реализовано для проекта СМС-рассылок, где клиентом может быть банк, отправляющий СМС-оповещение с паролем платежа используя XML-API нашего сервиса.
Сервис включает в себя online-биллинг, данные в БД постоянно обновляются и должны оставаться сохранными в любых случаях. Доступность 24x7 очень важна.
В этой статье я не буду подробно расписывать все «за» и «против» таких решений как «хороший» RAID с массивом «качественных» HDD, сервер холодной замены, кластер и т.д. — это займет слишком много времени.
Остановлюсь лишь на паре моментов:
Ваш покорный слуга не претендует на «открытие Америки» в поднимаемой теме. Решение которое мы реализовали для своего проекта СМС-рассылок основано на нескольких известных идеях.
Однако с учетом многолетнего опыта работы, в том числе и в крупных IT-компаниях — лидерах Российского рынка мобильных услуг могу констатировать, что такое (или аналогичное) элегантное и эффективное решение, гармонично сочетающее различные идеи — большущая редкость. Зачастую все пускается просто на самотек (авось сервер купили дорогой — не сломается, а через год купим новый). В лучшем случае организуются сервера «теплой» замены (с ручным заводом).
Т.о. для каждого из серверов у нас могут быть два режима работы: master и slave.
В открытом доступе всегда находится только master. Slave в это время занимается только синхронизацией БД.
Все решение построено на скриптах, написанных на bash. Скрипты на обоих серверах абсолютно одинаковые.
Нам потребуется 3-е звено (кроме наших двух серверов): DNS-хостинг от какого либо внушающего доверие поставщика.
Мы в своем проекте использовали DNS-хостинг Яндекс.
DNS-хостинг используется для двух вещей:
Яндекс предоставляет своим пользователям замечательную вещь — API для работы с DNS-записями. Использую этот API наши сервера могут читать и писать DNS-записи.
По cron'у, раз в 5 минут производятся следующие действия:
Процедура выполняется на master-сервере, когда он «понимает», что он больше не master. Это может произойти после того, как случилась авария и SLAVE поняв, что master-сервер недоступен сам становится master'ом. После того как авария устранена (дали электричество в дата-центре) поднимается «старый» master — наша задача, чтобы два сервера не работали в боевом master-режиме одновременно т.к. это может привести к рассинхронизации данных — для этого как только случается авария slave записывает в DNS свой собственный IP-адрес, что с одной стороны перенаправляет клиентов на новый IP, а с другой — является флагом для «старого» мастера, что он больше не мастер.
По cron'у, раз в 5 минут производятся следующее действие:
Как уже было сказано, данная процедура запускается на slave-сервере, когда он «понимает», что не получил через общее DNS-хранилище очередную временную метку от master'a.
В этом случае нужно:
Ну, во первых, мы верим в то, что Яндекс здорово заботится о стабильности своих сервисов, не жалеет на это денег (как мы) и сил. И как показывает практика, на самом деле — недоступность DNS-серверов Яндекс это большая редкость
И, во вторых, если DNS и недоступен какое то время то просто не надо делать ничего — пусть master продолжает работать в режиме master. Вероятность того, что авария Яндекс наложится на вашу аварию крайне низка.
Во первых, на Яндекс можно настроить время обновления кешей — установите их на минимальные значения.
Во вторых, можно оповестить технически подкованных клиентов о вашем резервном IP, чтобы они обращались к вашему сервису напрямую по IP в случае недоступности по доменному имени.
В случае когда оба сервера «живы» пользователи будут автоматически проксироваться на мастер.
Естественно, кроме упомянутых слабых мест можно найти и еще.
Но тем не мене данная реализация уже зарекомендовала себя с самой лучшей стороны, не единожды избавив техников из 2кенгу от авральных работ по экстренному подъему сервиса.
Затраты: 2 сервера (можно арендованных) — на ваш вкус + единоразовые работы по настройке скриптов.
Время неработоспособности сервиса в случае аварии: 10 минут на диагностику + 10 минут на переключение, итого 20 минут — в любое время дня и ночи — а вы, спокойно просыпаетесь утром, выпиваете чашечку кофе и узнаете обо всем разбирая письма.
Автор: Egorcheg
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/28041
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/170687/
Нажмите здесь для печати.