Как защититься от сбоев хостинга?

Проверять с одного сервера (без перепроверки с другого) - опасно. Будет какая-нибудь проблема в сети между сервером 1 и 2, и станет показываться заглушка, хотя у 99% пользователей сайт открывался абсолютно нормально. Поэтому либо использовать 2 собственных сервера в разных ДЦ и странах для мониторинга (если есть такие серверы), либо использовать сторонний мониторинг, который проверяет из нескольких точек мониторинга.

Что касается обновления IP в ДНС, то это зависит лишь от указанного TTL. Если указать 90, то максимум полторы минуты пользователи будут ходить по старому IP.

Спасибо за ценную информацию. Вопрос лишь в том, как обеспечить синхронизацию данных с первого основного на второй сервер? Предположим, что ежедневно в течении дня на сайье публикуется по 10-15 материалов. WordPress

---------- Добавлено 25.06.2017 в 04:15 ----------

Я подумал, может есть какие-то специальные плагины под CMS WordPress, пускай и платные... Никто не слышал?

Настройте репликацию БД, при необходимости ещё и синхронизацию файлов.

К сожалению, массе проксирующих ДНС (у дебилопровайдеров) пофиг на эти установки.

Может легко неделя принудительно стоять.

И зарезервируйте еще и их - вдруг упадет по какой то причине. 😂

Балансировщиков в той схеме 2, есть балансировщик с большим весом и меньшим.

---------- Добавлено 30.06.2017 в 09:47 ----------

Чтоб избежать этой проблемы можно построить DNS кластер, который обеспечит работу сразу с 2-х серверов, часть абонентов будет обслуживаться одним сервером, а часть - другим. В случае недоступности одного из серверов работа будет проходить с другого.

У популярных сайтов в А-записях можно видеть потому сразу 12-15 адресов. Это же, в свою очередь, помогает защититься от атак.

Безусловно, такое бывает.

Но у столь глобальной и фаталистичной формулировки этой проблемы очень почтенный возраст.

Раньше подобных "исключений" было на порядки больше. А сейчас ситуация вполне хорошая и продолжает улучшаться:

1. Меньше потребности в экономии ресурсов.

Никто не держится осознанно за нелепые "принудительные" настройки.

2. Снижается распространённость старого некорректного софта и сопутствующего наследства настроек.

Это постоянный процесс везде, но в сфере ДНС популярность DDOS-атак через резолверы в ряде случаев мотивировала и тех, кто очень хотел ничего не менять.

3. Даже в этой консервативной сфере были не очень известные, но очень полезные технологические новшества.

В частности, EDNS-CLIENT-SUBNET (ECS) расширение появилось только 6 лет назад.

И, например, любимые многими Google DNS всего 3 года как дошли до его совсем полноценной поддержки.

А с ECS кеширование идёт с разделением по подсетям.

Поэтому посетители сайтов со средней посещаемостью - вообще очень редко попадают в какой-либо кеш, кроме собственного.

Т.е. новые посетители перенаправляются даже не с TTL, а с нулевой задержкой.

Проблема же с игнорированием TTL - всё же есть. Это не идеал.

Но на практике речь не о "массе", а об очень незначительной части аудитории (преимущественно, региональной).

Не о неделях задержек, а, в большинстве, о минимумах в 5-20 минут TTL у этой незначительной части аудитории.

Более серьёзные проблемы - у совсем исчезающе малого количества.

Да из него большинство роботы (не ПС) и мобильные.

---------- Добавлено 05.07.2017 в 09:55 ----------

Это действительно простой и рабочий метод, если есть технические возможности у самого сайта. Но исключительно для дополнительной "полировки" стандартного ДНС-способа.

На деле и требуется, чтобы нерабочий адрес совсем не откликался, и браузер достаточно долго ждёт (ХХ секунд) перед новой попыткой.

Первейший вопрос в том, точно ли вам нужно именно это и насколько критичны задержки в синхронизации.

1. Сайт стандартного типа и размера; данные приемлемы с многодневной давностью; и при проблемах достаточен доступ только на чтение?

Делать не нужно вообще ничего.

Вам уже подсказали вариант с AlwaysOnline.

Из основных минусов:

- "снимок" может оказаться недельной давности;

- будет содержать далеко не всё (если сайт больше стандартной визитки);

- рассказывает посетителям о проблемах сайта, когда полезнее промолчать;

- может не сработать при некоторых ошибках (например, при проблемах БД).

Сходный модуль WSR сочетает "архивный снимок" с всегда свежим дополняющим "рабочим кешем" и интегрирован с гибко настраиваемым мониторингом, который принимает решения при подтверждении из 3 разных ДЦ.

2. Нужен работающий функционал и\или повышенная, но всё же не очень критичная актуальность данных уровня 6-24ч?

Берёте уже описанные здесь методы по самостоятельному построению ДНС-отказоустойчивости и мониторинга.

Добавляете простой, неэффективный, но более чем достаточный баш-скрипт:

- rsync для файлов, не забыв исключить кеши WP;

- бэкап+рестор для БД.

Можно аккуратнее, но это сложнее, а при таких объёмах полная обработка БД не проблема. С удалённым доступом к БД всё реализуется со стороны одного из серверов и правда очень лаконично. Ну разве что, кроме контроля успешности.

Либо с несколько более интересной надёжностью и трудоёмкостью:

- Настраиваете ресторы по расписанию в бэкап-модуле WSR.

- А в CDN указываете резервный сервер, и, вместо использования "снимка", запросы будут перекидываться на него.

А если и он умрёт, то тогда уже "снимок".

3. Актуальность критична на уровне секунд\минут?

Тут уж точно репликация БД, что достаточно просто для такого случая.

Для файлов аналогичным уровнем была бы, например, GlusterFS.

Но в отличие от БД столь частые и действительно нужные изменения на уровне файлов бывают редко у большинства проектов.

И, скорее всего, реальным требованием будет вполне соответствовать куда более простое решение - тот же rsync, только с небольшими поправками в характере применения.

- Сравнительно редкая общая синхронизация.

- Очень частый или событийный запуск для папок с часто меняющимися файлами (вероятно, только картинки).

А в остальном тоже самое.

Именно в таком виде - мало. Могут быть временные проблемы с доступностью запасного сервера (например, канала) - и в этот момент он будет пытаться переключить основной сервер на себя.

У меня резервный сервер проверяет каждую секунду основные, при N неудачных проверках - делает проверку через промежуточные хостинги (3 хостинга) - если минимум 2 из них ответили и "сказали", что основной сервер недоступен - идет переключение на запасной.

Подскажите NS хостинг с минимальным TTL и возможностью через API редактировать A запись.

В данный момент я остановился на cloudflare TTL 120, есть API и готовые библиотеки на php. Решение для себя вижу такое. Брать два хостинга в разных ДЦ, условно 1-сервер(хостинг) основной, 2-сервер резервный(можно тариф по дешевле) мониторинг по крону на 1-сервере по четным минутам на 2-сервере по нечетным. Если сайт не доступен, то через API смотрим на каком он сервере в данный момент висит и перекидываем на другой. Соответственно если не доступен 1-сервер, то 2-сервер это увидит и переключит на себя, и наоборот. Кроме того на основном сервере по крону раз в N часов проверяем на каком сервере работает сайт и если не на основном, то возвращаем его на основной сервер (последний пункт не актуален если нет разделения на основной и резервный сервер).

Я в свое время делал так:

Покупал 2-3 виртуалки в разных дц, днс вешал тут https://www.cloudns.net/

у них есть смена записи по PHP скрипту или wget-ом, так вот между этими серверами настраивал репликацию, а крон отстукивал скрипт и в случае чего менял А запись, все происходило автоматом, время недоступности измерялось в нескольких минутах