Сайты падают. Я работаю в хостинге 7 лет и последние 5 лет (кроме всего прочего) предоставляю услуги по географически-распределённым кластерам, чтобы при аварии в одном из дата-центров сайт продолжил работу в другом. На выходе такое решение стоит минимум от 4 тысяч рублей в месяц за 1 виртуальный сервер. Небольшому интернет-магазину это может оказаться дорого для «страховки», которая потребуется 1-3 раза в год, а если повезет — не потребуется совсем. Соответственно, многим нужен вариант дешевле, подходящий для малого и среднего бизнеса. Сейчас расскажу, как это решить очень и очень просто.
Важное вступление
В прошлый раз я рассказал о принципах организации бюджетного отказоустойчивого кластера. Полноценный кластер требует как минимум удвоения количества оборудования, чтобы при сбое иметь возможность продолжить работу. В этом посте я расскажу о том, как обойтись без дублирования системы и при этом сохранить клиентов при отказе основного сервера.
Итак, когда падает сайт интернет-магазина или, например, кафе, проблем две:
- Клиенты не могут достучаться до сайта и вы теряете заказы. Как правило, падения редко длятся больше дня, поэтому обычно просто вычитайте день работы из прибыли.
- Что хуже – сайты могут выпасть из выдачи поисковых систем, поскольку поисковые роботы видят вместо сайта какую-нибудь 503-ю или 404-ю ошибки или не видят вообще ничего.
Если первое обычно в малом бизнесе достаточно легко перетерпеть (ну, 9-15 тысяч оборота при марже 30% — это 3-5 тысяч рублей, в целом – не страшно), то просадка в поисковых системах обходится заметно дороже. Лицо сеошника на второй час падения будет выглядеть страшно. Ущерб (если не повезло) – примерно ваш месячный бюджет на продвижение. Ради этого уже стоит «подстелить соломки» на случай падения.
Мы пообщались с Milfgard об отказоустойчивых решениях, и он рассказал, как они уже много лет решают эту проблему в Мосигре. На время перебоев в работе сайта клиенты просто переключаются на статическую html-заглушку с основной информацией.
Это страница, где показывается общая информация о компании, телефон для связи и возможно еще несколько страниц, в продвижение которых вкладываются деньги. Для такой заглушки достаточно от 1 до 20 страниц (условно это главная страница и еще несколько страниц с топовыми товарами). Если больше, уже имеет смысл думать про кластер. Такая система «заглушки» делается и поддерживается заметно проще полноценного кластера.
Суть метода
- С сайта забираются основные страницы (главная + несколько любых на ваш выбор). Из них автоматически создаётся статический сайт-заглушка. При нажатии на любую ссылку (ведущую на страницы не вошедшие в такую заглушку) показывается сообщение вроде: «Сайт временно недоступен, позвоните по телефону 123, мы примем заказ». Эта заглушка размещается на сервере, независимом от хостинга, где работает основной сайт.
- Для поддержания актуальности (цены, изменения в дизайне и т. п.) такой сайт-заглушка автоматически обновляется раз в неделю.
- Домен делегируется на надежный DNS-сервис (в моём случае – Яндекса, т.к. он сам по себе отказоустойчивый), которым можно управлять через API.
- Резервный сервер занимается мониторингом основного и при сбое меняет IP-адрес на адрес резервного сервера. Проверка осуществляется раз в минуту, и если 3 раза подряд робот наткнулся на ошибку происходит переключение A-записи домена на резервный сервер. При восстановлении работы основного сайта запись меняется обратно.
- При переключениях записи туда-обратно владельцу или администратору отправляется смс-уведомление.
Другими словами: мы берём и копируем основные страницы любого сайта, делаем статическую заглушку и следим за тем, чтобы при падении основного сайта клиенты переключились на нашу статическую версию. Потом переключаем обратно после восстановления работы основного сайта.
Процесс переключения занимает около 1,5 минут, то есть это время (TTL) плюс-минус пару минут сайт всё-таки полежит. Когда мы только начинали тестировать, задержка составляла около 12-17 минут, сейчас всё куда быстрее: нашлись варианты.
Преимущества перед кластером
- Очень просто в реализации, делается по одной кнопке.
- Несравнимо дешевле.
- Часто этого достаточно для сохранения покупателя пришедшего по рекламе — подробности оператор расскажет по телефону, ну и вообще клиент увидит что сайт живой, работает вместо непонятной ошибки.
- Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
- Спасает от перегрузок, ошибок в ПО сайта/базы, взломов, атаки и т.п. — при любом неблагоприятном сценарии можно переключить домен на статический сайт и он честно всё отработает. Сломать сайт из одних статических html-ек с картинками сложно и нагрузку он выдержит заметно больше чем основной сайт с кучей функций и большой базой.
- Может работать с любым хостингом, лишь бы тот поддерживал работу с внешними DNS-серверами (подавляющее большинство поддерживают).
- Клиенту вовсе необязательно переносить свой сайт на наш хостинг – достаточно заказать услугу вот такой заглушки, и у себя на сайте можно ничего не трогать.
Ещё раз: такая заглушка не требует никаких изменений со стороны сайта, хостинга и т. п. — сайт будет работать как работал, а на случай проблем будет подготовлена «соломка», куда мягко падать.
Недостатки
- Это заглушка — пользователь не сможет произвести поиск по сайту, зарегистрировать, войти в личный кабинет и т.п. Только посмотреть основную информацию и (условно прайс и номер телефона чтобы связаться с оператором).
- При переключении есть задержка на обновление DNS-кеша, около 1.5 минут.
- Есть дополнительная сложность – нужно чтобы владелец сайта делегировал домен на DNS-серверы Яндекса. Это не сложно, но требуется опыт — такую процедуру не сможет выполнить обычная секретарша.
Практическая реализация
- Домен клиента делегируется на DNS-серверы Яндекс — они бесплатные и надежные, есть простое API для управления. TTL ставится минимальный — 90 секунд.
- На отдельном сервере размещается служба мониторинга и хостинг статических сайтов. Мониторинг раз в минуту обращается к основному серверу, скачивает главную страницу и ищет там ключевую фразу, которая говорит о том что сайт работает. Обычно это код яндекс-метрики или гугль-аналитики, но можно вставить и что-то специальное что будет точно выдаваться запросом из базы внутри основного текста страницы. При трёх сбоях подряд — клиенту отправляется смс-уведомление о сбое и переключении сайта на запасную площадку.
- При этом мониторинг меняет IP-адрес домена на адрес резервной площадки и продолжает проверки основного сайта на предмет доступности. Как только основной сайт приходит в норму — клиенту отправляется уведомление о переключении сайта на основную площадку и возвращается основной IP-адрес сервера.
- При необходимости для клиента можно организовать 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-ю минуту каждого часа
Комментарии (43)
zenn
15.06.2015 11:14+5Знаете, есть еще более дешевое решение — стоит оно аж целых 0 рублей, называется cloudflare(есть и альтернативные CDN) с включенной функцией Always online
aml
15.06.2015 12:03А если к нему прикрутить runbook.io (стоит в целых 10 раз дороже, правда), то можно полноценный фейловер сделать.
rekby Автор
15.06.2015 12:05Да, про cloudflare знаю.
Кроме стоимости 0 рублей есть и другие отличия:
- Cloudflare определяет падение сайта по http-коду 500 или невозможности подключения к серверу, т.е. если навернется база данных и на сайте будет каша — cloudflare может посчитать это нормой и если не повезет — даже закешировать её для always online.
- Нельзя задать какие именно страницы будут попадать в кеш — это cloudflare определяет сам, это могут оказаться не те страницы которые важны с точки зрения бизнеса, а просто самые посещаемые (например страница справки, а не того товара который начал рекламироваться вчера).
- Нельзя сделать свою заглушку на несуществующие страницы — будет показываться ошибка cloudflare, которая говорит что сайт упал. При этом методе — будет показываться условно главная страницы и телефон оператора (заглушку можно сделать и отличающуюся от сайта — это уже по желанию).
- При использовании использовании CDN все запросы проксируются через него, у Cloudflare нет серверов в России — скорость открытия страниц вырастает на скакание трафика до заграницы и обратно дважды если хостинг в России (от клиента до CDN и от CDN до хостинга).
Я не говорю о том что cloudflare плохой — просто этот инструмент подходит не для всех задач.zenn
15.06.2015 13:59Да, по поводу алгоритма определения кешированных страниц и принципу кеширования есть ряд вопросов к cloudflare, однако такая «реализация», если ее так можно назвать существенно проще вашей (и да, если вы рекламируете определенную посадочную страничку, на которую много переходов — с большой долей вероятности cloudflare все же ее закеширует).
По поводу TTB для России через cloudflare — я бы не сказал, что существенно возрастает пинг (у меня к примеру, direct — 45-46 / cloudflare — 74-76), наоборот, если ваш сайт посещают НЕ ТОЛЬКО жители России а и жители из других регионов то это им даст существенное преимущество(да, я понимаю что это редко оправдано для интернет-коммерции).
Eklykti
15.06.2015 19:02Это, наверное, какой-то очень хороший движок у сайта, который при ошибке базы данных всё равно отдаёт 200 OK и ту кашу, которая в результате получилась. Вот только в таком хорошем движке и код яндекс-метрики и гуглоаналитики тоже будет на месте, ибо в таких хороших движках они обычно захардкожены в шаблонах.
rekby Автор
15.06.2015 19:21+1Специально проверил только что — например так делает joomla 1.5:
«Database Error: Unable to connect to the database:Could not connect to MySQL», код шаблона не выводит.
И битрикс:
DB query error.
Please try later.
Оба выдают код 200, оба выводят текст ошибки о базе и оба НЕ выводят шаблон. Проверил только эти две cms, других под руками нет но и эти две покрывают сразу заметный процент сайтов.
Для остальных код проверки можно вставить в текст, выдергиваемый из базы — это не проблема и тоже никакой поддержки со стороны сайта не требует, там хоть ключевое слово, хоть невидимый html-тег/комментарий.symbix
16.06.2015 04:14Может, там все-таки какой-то отладочный режим включен? Джумла — ладно, с ней все ясно, но битрикс за большие деньги продают, так совсем нельзя.
rekby Автор
16.06.2015 06:09Нет, никаких спец. режимов — просто установил свежий битрикс на пустой сайт в пустую базу и поставил в настройках неправильный пароль подключения.
В отладочном режиме битрикс выдает более подробную информацию.symbix
16.06.2015 06:56Мда, в гугле по запросу «DB query error. Please try later. -ошибка -битрикс -форум» (отфильтровал вопросы на форумах) все понятно. Serious business.
Ну, можно воткнуть адов костыль — включить в php.ini/.htaccess output_buffering и auto_append_file, в котором проверять наличие подстроки в буфере и если что — отдавать 500-ю. Но это жесть.
igordata
15.06.2015 11:48Может я чего-то не понимаю, но я всегда считал, что смена записей в DNS туда и обратно может для конечного посетителя занять больше времени, чем ремонт сайта.
rekby Автор
15.06.2015 11:51Это зависит от TTL. Обычно у А-записей он 1 час (иногда больше) — тогда да, чинить бывает быстрее. В данном случае TTL устанавливается на 90 секунд, т.е. уже быстрее переключать.
aml
15.06.2015 12:05+3А ещё есть кеширующие DNS, которым стандарт не писан. Они могут сутками отдавать старые записи. И их количество статистически весьма заметное.
rekby Автор
15.06.2015 12:15Да, есть и такие, но по опыту переносов я бы не сказал что их сильно много — через сутки на старом IP я замечал только роботов, скачивающих картинки, в основном Bing. Подавляющая часть запросов переезжают примерно за TTL.
Для того чтобы сохранить остальных есть кластер, где при переезде между ДЦ IP-адреса сохраняются, а маршруты меняются через BGP, о нём я писал в предыдущем посте.
Этот вариант для тех у кого нет кластера или кому размещаться в кластере по каким-то причинам не хочется/не можется.
msfs11
16.06.2015 12:37У нас были клиенты из Владивостока, через несколько суток после эпичного сбоя DNS на r01 получали неправильный контент.
maximw
15.06.2015 12:16+2По закону подлости падения случаются на выходных или когда ты где-нибудь в отпуске далеко от интернета. Т.е. кроме времени ремонта, надо учитывать и время от возникноваения проблемы до начала ремонта.
shornikov
15.06.2015 12:28Если у резервного сервера хватает возможностей на «занимается мониторингом основного и при сбое меняет IP-адрес на адрес резервного сервера» — то почему-бы там не держать полную версию сайта? В табличке заказов автоинкремент побольше поставить чтобы заказы не пересекались и готово.
rekby Автор
15.06.2015 12:38Развернуто могу отвечать долго, ограничусь двумя пунктами
Потому что это:
1. Заметно сложнее в настройке, а репликация например в MySQL еще и работает плохо — её надо периодически чинить.
2. Нужен полный резерв мощностей на запасной площадке чтобы при сбое принять на себя всю нагрузку.
Ну и перечитайте еще раз раздел поста: «Преимущества перед кластером».
ntfs1984
15.06.2015 13:251.
Репликация MySQL работает плохо, но ничего не мешает ее заменить простой периодической синхронизацией на уровне SQL-дампов. Единственное что может помешать как репликации, так и дампово-костыльной синхронизации — это большой размер базы данных.
Но мы ведь умные, код магазина писали сами, без индусов, и статическая база данных (где можно хранить архивные заказы, разную дополнительную информацию) лежит в одном месте, а динамическая — в другом, занимая при этом мегабайт 200 от силы?
А их уже не составит труда передавать раз в пять минут на второй сервер.
2.
Здесь уже нужно знать подробнее с чем имеем дело. Раньше я тоже думал, что для большой нагрузки нужны большие мощности. Пока не столкнулся вплотную с Raspberry Pi. Теперь могу с уверенностью сказать: Ваш интернет-магазин работает на Quad Core 2.13*4 \ 16 Гб RAM? Оптимизируете, и он будет работать на Celeron 1037U \ 4 Гб RAM.
TimsTims
15.06.2015 12:35-2Вы пишете:
Не требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Хотя до этого писали:
Для поддержания актуальности (цены, изменения в дизайне и т. п.) такой сайт-заглушка автоматически обновляется раз в неделю.
Лукавите, всё же нужно допиливать периодическую автогенерацию html. А так недалеко и до полноценной html-копии сайта дойти.rekby Автор
15.06.2015 12:42+1А где тут лукавство?
Я же и пишу чтоНе требует никакой поддержки со стороны основного сайта, работает с любыми движками и технологиями.
Конечно для поддержания актуальности на резервный сервер должен эту актуальность поддерживать, но это не предъявляет никаких требований к основному сайту — он может быть написан как угодно, на чем угодно и ничего про запасной вариант не знать, он не занимается специальным генерированием кода заглушки.
Заглушка генерируется резервным сервером путем запроса страниц с основного сайта, в самом простом виде это может быть например wget …
achekalin
15.06.2015 13:03> Клиенты не могут достучаться до сайта и вы теряете заказы
Если магазину заплатить 3-4 тысячи дорого, то и клиентов у него единицы, и шанс, что во время падения такой редкий клиент зайдет — не сильно большой. Если же поток такой, что прям час простоя — это очень «дорого» для магазина, то на постраховку денежка как-то, да найдется.
Да, у Cloudflare есть такая фича, что, если ваш сервер не отвечает, Cloudflare отдает его страницы из своего кеша с припиской «это кешированная версия». По идее, можно как-то внутри кода страницы такие моменты отловить, и либо прятать форму заказа, либо просить звонить в магазин по телефону — как вариант.
r00tGER
15.06.2015 13:29Надуманная проблема для ниши «4Круб. дорого».
При «нормальном» хостинге, владелец подобного сайта вообще не задумается об аптаймах.ntfs1984
15.06.2015 13:33+1Даже нормальные хостинги зависимы от ISP, и это проблема еще хуже чем внезапный пожар.
r00tGER
15.06.2015 13:45Мы говорим о ситуации, когда простой сайта обойдется в ~0 рублей (как сказали выше, вероятность упущенной покупки минимальна). Соответственно страховать подобные риски нет смысла.
Disasm
Уточните, пожалуйста, о каких системах идёт речь, а то за гуглом я что-то не замечал такого. Через гугл можно даже удалённые статьи с хабра читать, не говоря уж о лежащих сайтах.
rekby Автор
Читать из сайт кеша безусловно можно, но мнению сеошников понижается позиция сайта в выдаче (как есть на самом деле знают только поисковики).
Disasm
Тогда предлагаю добавить третий пункт:
3. Что ещё хуже — могут отобрать доменное имя
Просто так. Основываясь ни на чём.
rekby Автор
Давайте лучше спросим представителей яндекса/гугля если они тут есть и могут поделиться этой информацией — зависит ли позиция сайта в выдаче от того есть ли сбои при обращении к нему роботов.
yjurfdw
Если страница выдает 404 или другой ошибочный код несколько раз — она точно будет исключена из выдачи.
А может даже с первого, это на усмотрение поисковой машины.
Alexufo
Потому что это написано в документации того же Яндекса)
gonzazoid
ну 404 по каждому чиху отдавать — это ССЗБ.
А вообще все что описано в статье делается через 302, его поисковики нормально обрабатывают, и не нужны танцы с dns.
rekby Автор
Простите — а если сервер у хостера упал — кто вам будет 302 выдавать?
gonzazoid
а 404 кто отдает?
а если без ерничаний — если упал фронт, то никто. Если бэк или база — то собственно фронт и должен это отдавать.
rekby Автор
1. А 404 тут причем?
Хостинг упал, сайт лежит — наружу может отдаваться 404 (хостер не прочитал конфиг, аккаунт хостинга выключен за неоплату или нарушение), 500 (ошибка на сервере хостинга или в сайте), 200 (сайт работает или ошибка внутри сайта), может отдаваться еще какой-то код. Речь идет о том, что если не отдается нормальный контент — сайт может выпасть или понизиться в выдаче.
2. Настраивать свои 302-е редиректы при ошибках можно если у вас свой сервер/VDS и есть способ определять что бэкенд лежит чтобы отдать 302-й редирект. Врядли у владельцу сайта получится договориться о такой настройке с провайдером виртуального хостинга (которого кстати достаточно для большинства интернет-магазинов).
Смена A-записи решает эти задачи и работает в том числе с дешевым виртуальным хостингом, от которого тоже практически ничего не требуется — главное чтобы небыло требования работать только со своими dns-серверами. Но такого обычно нет.
rekby Автор
— в смысле только с dns-серверами хостера.
gonzazoid
>с провайдером виртуального хостинга
давайте завершим разговор — vps стоит от 400 рублей в месяц.
rekby Автор
К VPS должен прилагаться администратор, который умеет с VPS работать, а он стоит уже заметно больше 400 рублей в месяц.
кроме того VPS тоже может упасть как сам по себе так и вместе с физическим сервером хостера, тогда 302-ю снова отдавать никто не может.
gonzazoid
если vps падает сам по себе, то я за два часа поменяю вместе с dns записями еще и хостера. А по поводу навыков — большой разницы между администрированием vps и виртуального хостинга я не вижу. По мне так vps попроще будет. Или виртуальный хостинг сам работает, без админа?
Это раз. Если падает vps(на и виртуальный хостинг тоже) то проблемой занимаетесь не вы лично или ваш эникейщик, а техподдержка хостера, которая, если хостер нормальный — 24/7/365. У меня лично за три года работы — два инцидента, один на пол дня, но там не хостер а магистраль, второй — чисто хостера косяк, поправили за полтора часа.
rekby Автор
Разница между VPS (даже с панелью) и виртуальным хостингом огромна в момент когда внутри VPS что-то наворачивается (например тупо место закончилось из-за того что кеш движка не чистился и всё встало). С VPS клиент предоставлен сам себе и сам должен понять что внутри его сервера случилось и как это чинить, для этого нужен человек который знает как работать с сервером. Если такого человека нет — его надо искать, а это небыстро.
А виртуальный хостинг — да, спокойно работает без админа (со стороны владельца сайта) по многу лет, т.к. ломаться там особо нечему + если всё же сломалось всегда можно просто восстановиться из резервной копии по кнопке из личного кабинета.
gonzazoid
ok. тогда я тем более не понимаю. Виртуальный хостинг работает сам по себе, ломаться там нечему. Если упало — это поднимает хостер. Так получается, смысл статьи — что делать если хостер не чешется, а менять его не хочется?
rekby Автор
Смысл статьи: что сделать, чтобы не терять заказы/позиции в поиске пока хостер или администратор поднимают основной ресурс.