Резервирование сайта на внешнее облако: Как что и зачем?

Береженого Бог бережет

РубрикаВремя на чтение6 минут

Ingredients

Directions

Резерв сайта на внешнее облако

Любой хостинг, даже крупный, рано или поздно периодически падает. Воспроизвести всю цепочку не составит проблем — а) лежит сайт, б) вы теряете клиентов, в) тебя кошмарит начальство, что аж sql-запросы стынут в жилах. Если уж важность бэкапов все уже в большей мере осознали, то с резервированием работоспособности всего сайта пока получается не очень. Именно поэтому сегодня мы снимаем гриф «Секретно» и разбираемся как нам может помочь некст ген облачных сервисов

Почему облако в качестве резерва?

Быстрое переключение на резервную инфраструктуру поможет держать стабильный аптайм для вашего сайта и/или приложения. Плюсы аренды облачных ресурсов уже всем давно известны и они применимы к нашей конкретной ситуации: быстрое развертывание, высокий SLA, распределение нагрузки (балансер) и самое главное — кастомизация конфигурации под ваши нужды и бюджет (pay-as-you-go):

Кроме того, всё это управляется через удобный веб, либо через VNC-консоль для бородатых админов. Самое главное преимущество такого подхода — надежность, ведь провайдеры облачных услуг обычно располагают свои мощности в надежных дата-центрах уровня Tier III.

Как это сделать?

Итак, чтобы сайт продолжал работу, необходимо сделать резерв на внешний облачный сервис. Какие есть варианты? Вообще их два:

1. Сложный — самостоятельная настройка

Вкратце теория такая — имеется запасной сервер с копией основного (файлы, база данных)и настроенной NS-записью. При падении основного, запускается резервный и все счастливы. В реальности всё гораздо сложнее:

  1. Балансировка бэкэнда. Балансировка нагрузки между бэкэндами (ngnix/apache) в разных облаках/дата-центрах. Обычно для этого используется метод least_conn, который отправляет запрос к бэкенду с наименьшим количеством активных подключений
  2. Балансировка DNS. Чаще всего используется метод Round-robin DNS, который позволяет указывать более одного IP адреса в А записях, таким образом при запросе разные клиенты будут получать разные IP адреса при обращении домену. Коротко: браузер опрашивает 1 IP-адрес, если он не подключается в течение 5-10 секунд, пробует подключиться к другому IP (в это время nginx переключается к своему внутреннему apache и работает с ним)
  3. Репликация базы данных. Автоматическая синхронизация БД в режиме Master-slave (иногда используется Master-Master) позволяет сделать дубликат базы данных. На «Мастере» происходят все изменения данных (добавление, изменение, удаление). Дополнительный (Slave) лишь копируют всю информацию с мастера, но при этом может помогать ему за счет переноса некоторых операций (например, чтения)
  4. Репликация файлов. Можно через утилиту «живой» синхронизации clsync
  5. Репликация PHP-сессий. Для этого часто используется memcachedrep — высокопроизводительное многопоточное хранилище ключей или значений на основе событий, предназначенное для использования в распределенной системе
  6. Организация мониторинга. Подойдет Zabbix

2. Простой — использование VPS в облаке

Многие облачные сервисы предлагают услугу Backup-as-a-Service — резервное копирование для любой инфраструктуры, в том числе и сайта. Как вариант, можно насовсем переехать в облако, ведь в таком случае, если случается проблем с основным дата-центром происходит автоматическая миграция на резервный, географически разнесенный. Плюс такого подхода не только в простоте, но и в пресловутой надежности, ведь провайдеры таких услуг предоставляют базовую и расширенную защиту от DDoS-атак, вплоть до уровня L7

Смена DNS

Возникает вопрос — а как быстро перекинуть запросы посетителей на нужный нам IP? Самый главный совет в ситуации проблем у хостера  — держите домены у регистратора, у них можно быстро сменить DNS (а вам придётся это делать, если сервер/ДЦ ляжет). Например, в Руцентре это можно сделать за пару кликов в личном кабинете:

Многие могут сказать: «Но ведь провайдер обычно кеширует NS-записи?». Да, верно, но в таком случае помогает такой параметр, как TTL (Time to Live) в  этой самой записи. Если он небольшой, то запись обновиться быстро.  Например, сервис Cloudflare позволяет менять это значение

Итог:

Резервное копирование в облако — это отличный шанс быстро и без нервотрёпки пережить лежачий хостинг. Единственная возможная проблема — делать всё вручную довольно сложно и долго.