Чтобы сайт не падал: экономный метод

Сайты падают. Я работаю в хостинге 7 лет и последние 5 лет (кроме всего прочего) предоставляю услуги по географически-распределённым кластерам, чтобы при аварии в одном из дата-центров сайт продолжил работу в другом. На выходе такое решение стоит минимум от 4 тысяч рублей в месяц за 1 виртуальный сервер. Небольшому интернет-магазину это может оказаться дорого для «страховки», которая потребуется 1-3 раза в год, а если повезет — не потребуется совсем. Соответственно, многим нужен вариант дешевле, подходящий для малого и среднего бизнеса. Сейчас расскажу, как это решить очень и очень просто.
В прошлый раз я рассказал о принципах организации бюджетного отказоустойчивого кластера. Полноценный кластер требует как минимум удвоения количества оборудования, чтобы при сбое иметь возможность продолжить работу. В этом посте я расскажу о том, как обойтись без дублирования системы и при этом сохранить клиентов при отказе основного сервера.

Итак, когда падает сайт интернет-магазина или, например, кафе, проблем две:

1. Клиенты не могут достучаться до сайта и вы теряете заказы. Как правило, падения редко длятся больше дня, поэтому обычно просто вычитайте день работы из прибыли.
2. Что хуже – сайты могут выпасть из выдачи поисковых систем, поскольку поисковые роботы видят вместо сайта какую-нибудь 503-ю или 404-ю ошибки или не видят вообще ничего.

Если первое обычно в малом бизнесе достаточно легко перетерпеть (ну, 9-15 тысяч оборота при марже 30% — это 3-5 тысяч рублей, в целом – не страшно), то просадка в поисковых системах обходится заметно дороже. Лицо сеошника на второй час падения будет выглядеть страшно. Ущерб (если не повезло) – примерно ваш месячный бюджет на продвижение. Ради этого уже стоит «подстелить соломки» на случай падения.

Мы пообщались с Milfgard об отказоустойчивых решениях, и он рассказал, как они уже много лет решают эту проблему в Мосигре. На время перебоев в работе сайта клиенты просто переключаются на статическую html-заглушку с основной информацией.

Это страница, где показывается общая информация о компании, телефон для связи и возможно еще несколько страниц, в продвижение которых вкладываются деньги. Для такой заглушки достаточно от 1 до 20 страниц (условно это главная страница и еще несколько страниц с топовыми товарами). Если больше, уже имеет смысл думать про кластер. Такая система «заглушки» делается и поддерживается заметно проще полноценного кластера.

Суть метода

1. С сайта забираются основные страницы (главная + несколько любых на ваш выбор). Из них создаётся из них создается статический сайт-заглушка. При нажатии на любую ссылку, ведующую на не вошедшие в такую страховку страницы показывается сообщение вроде: «Сайт временно недоступен, позвоните по телефону 123, мы примем заказ». Эта заглушка размещается на сервере, независимом от хостинга, где работает основной сайт.
2. Для поддержания актуальности (цены, изменения в дизайне и т. п.) такой сайт-заглушка обновляется раз в неделю.
3. Домен делегируется на надежный DNS-сервис (в моём случае – Яндекса, т.к. он сам по себе отказоустойчивый), которым можно управлять через API.
4. Резервный сервер занимается мониторингом основного и при сбое меняет IP-адрес на адрес резервного сервера. Проверка осуществляется раз в минуту, и если 3 раза подряд робот наткнулся на ошибку происходит переключение A-записи домена на резервный сервер. При восстановлении работы основного сайта запись меняется обратно.
5. При переключениях записи туда-обратно владельцу или администратору отправляется смс-уведомление.

Другими словами: мы берём и копируем основные страницы любого сайта, делаем статическую заглушку и следим за тем, чтобы при падении основного сайта клиенты переключились на нашу статическую версию. Потом переключаем обратно после восстановления работы основного сайта.
Процесс переключения занимает около 1,5 минут, то есть это время (TTL) плюс-минус пару минут сайт всё-таки полежит. Когда мы только начинали тестировать, задержка составляла около 12-17 минут, сейчас всё куда быстрее: нашлись варианты.

Преимущества перед кластером

1. Очень просто в реализации, делается по одной кнопке.
2. Несравнимо дешевле.
3. Часто этого достаточно для сохранения покупателя пришедшего по рекламе — подробности оператор расскажет по телефону, ну и вообще клиент увидит что сайт живой, работает вместо непонятной ошибки.
4. Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
5. Спасает от перегрузок, ошибок в ПО сайта/базы, взломов, атаки и т.п. — при любом неблагоприятном сценарии можно переключить домен на статический сайт и он честно всё отработает. Сломать сайт из одних статических html-ек с картинками сложно и нагрузку он выдержит заметно больше чем основной сайт с кучей функций и большой базой.
6. Может работать с любым хостингом, лишь бы тот поддерживал работу с внешними DNS-серверами (подавляющее большинство поддерживают).
7. Клиенту вовсе необязательно переносить свой сайт на наш хостинг – достаточно заказать услугу вот такой заглушки, и у себя на сайте можно ничего не трогать.

Ещё раз: такая заглушка не требует никаких изменений со стороны сайта, хостинга и т. п. — сайт будет работать как работал, а на случай проблем будет подготовлена «соломка», куда мягко падать.

Недостатки

1. Это заглушка — пользователь не сможет произвести поиск по сайту, зарегистрировать, войти в личный кабинет и т.п. Только посмотреть основную информацию и (условно прайс и номер телефона чтобы связаться с оператором).
2. При переключении есть задержка на обновление DNS-кеша, около 1.5 минут.
3. Есть дополнительная сложность – нужно чтобы владелец сайта делегировал домен на DNS-серверы Яндекса. Это не сложно, но требуется опыт — такую процедуру не сможет выполнить обычная серетарша.

Практическая реализация

1. Домен клиента делегируется на DNS-серверы Яндекс — они бесплатные и надежные, есть простое API для управления. TTL ставится минимальный — 90 секунд.
2. На отдельном сервере размещается служба мониторинга и хостинг статических сайтов. Мониторинг раз в минуту обращается к основному серверу, скачивает главную страницу и ищет там ключевую фразу, которая говорит о том что сайт работает. Обычно это код яндекс-метрики или гугль-аналитики, но можно вставить и что-то специальное что будет точно выдаваться запросом из базы внутри основного текста страницы. При трёх сбоях подряд — клиенту отправляется смс-уведомление о сбое и переключении сайта на запасную площадку.
3. При этом мониторинг меняет IP-адрес домена на адрес резервной площадки и продолжает проверки основного сайта на предмет доступности. Как только основной сайт приходит в норму — клиенту отправляется уведомление о переключении сайта на основную площадку и возвращается основной IP-адрес сервера.
4. При необходимости для клиента можно организовать ftp-доступ к файлам своего сайта или API для загрузки архива чтобы обновлять заглушку в автоматическом режиме (это у меня пока не реализовано на потоке).

Посмотреть

Посмотреть как это работает можно на примере тестовых сайтов:

splasher-test-00.inf1f2.ru — выдает ошибку с нулевой по 14-ю минуту каждого часа
splasher-test-15.inf1f2.ru — выдает ошибку с 15-й по 29-ю минуту каждого часа
splasher-test-30.inf1f2.ru — выдает ошибку с 30-й по 44-ю минуту каждого часа
splasher-test-45.inf1f2.ru — выдает ошибку с 45-й по 59-ю минуту каждого часа

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.