Высокая доступность веб-сайта — совместная работа и разработчика сайта. Основная цель обеспечения высокой доступности — минимизация запланированных и незапланированных простоев.
Высокая доступность — это больше, чем просто размещение вашего проекта в надежном облаке. По-настоящему высокодоступный сайт должен работать в нескольких регионах облака и его пользователи не должны замечать каких-то изменений даже если один из регионов облака станет недоступным. Разработчик веб-сайта должен обеспечить работоспособность сайта даже в случае чрезвычайной ситуации. Системы высокой доступности дублируются: при сбое у провайдера сайт будет доступен. При сбое репликации пользователя сайт также должен быть доступен. Если необходимо провести работы на сервере разработчику или перезагрузить его — пользователи не должны замечать этого.
В этом цикле статей мы рассмотрим способы организации высокой доступности различных подсистем вашего сайта. Многие задачи имеют различные решения. Автор не утверждает, что здесь представлено лучшее решение, но оно вполне работоспособно и проверено на практике. Однако поле для экспериментов по увеличению доступности огромно.
Сегодня мы рассмотрим синхронизацию статического сайта между регионами облака: изменения в файлах на одном из серверов должны появляться и на другом. Также мы рассмотрим простейший способ перенаправить пользователей вашего сайта на альтернативный сервер с помощью нескольких А-записей DNS, применимый для этого случая.
Lsyncd
Lsyncd (Live Syncing Daemon) – приложение для своевременного интерактивного зеркалирования данных серверов для использования в кластерах высокой доступности. Особенно хорошо lsyncd подходит для систем с небольшим трафиком синхронизации. Приложение собирает информацию об изменениях данных через подсистему ядра Linux inotify в течение определенного в конфигурации периода и запускает процессы зеркалирования изменений (через rsync по умолчанию, но есть и другие варианты). По-умолчанию lsyncd запускается как демон в фоне и протоколирует свои действия с помощью syslog. Для целей тестирования можно запустить приложение без демонизации, чтобы видеть происходящие действия в терминале для отладки.
Lsyncd не использует отдельную файловую систему или блочное устройство и не влияет сильно на производительность локальной файловой системы.
Использование опции Rsync + SSH позволяет передавать файлы сразу в целевую директорию вместо передачи места размещения на удаленный сервер.
Установка и настройка георепликации файлов веб-сервера
Получение доступа к разным регионам InfoboxCloud
Закажите 2 подписки на InfoboxCloud в Москве и Амстердаме для создания геораспределенного решения.
Для того, чтобы подписки были привязаны к единому аккаунту пользователя действовать нужно так:
1. Зайдите на http://infoboxcloud.ru и закажите облачную инфраструктуру в любом регионе (например в Амстердаме). Далее войдите в панель управления и закажите облако в другом регионе (например в Москве), как показано ниже.
После заказа выйдите из панели управления и войдите вновь. Теперь вы можете выбирать регион, в котором происходит работа, в правом верхнем углу панели управления:
Создайте 2 сервера: один в Москве, другой в Амстердаме.
В качестве операционной системы выберите CentOS 7. В статье рассматривается именно она, но можно использовать и другую операционную систему Linux при необходимости. При этом настройки могут отличаться. Вы можете использовать любой тип виртуализации на выбор. Разница для конкретного сценария в том, что если вы не поставите галочку «разрешить управление ядром ОС» — сможете использовать автомасштабирование по памяти для серверов, что позволит использовать ресурсы эффективнее. А если поставите — сможете настроить подсистему ядра inotify, что будет полезно при высоких нагрузках (пример настройки), но не имеет смысла для обычного небольшого сайта. Обязательно при создании каждого из серверов добавьте по одному публичному ip–адресу, чтобы к серверам был доступ из внешней сети:
После создания серверов данные для доступа придут к вам на email.
Настройка DNS
Для основного домена, сайт на котором должен быть высокодоступен, создайте две А-записи DNS, указывающие на сервер в Москве и сервер в Амстердаме. В нашем случае сайт будет failover.trukhin.com.
Создайте служебные поддомены, A–запись которых должна указывать на свой сервер. Например failovermsk.trukhin.com указывает на сервер в Москве, а failoverams.trukhin.com указывает на сервер в Амстердаме. Отдельные поддомены для каждого из серверов нужны, чтобы, в случае если сервер выйдет из строя, с резервного сервера развернуть еще реплику и перенаправить поддомен на нее.
Настройка серверов
Указанные ниже действия нужно провести на обоих серверах.
Подключитесь по SSH к обоим серверам. Установите Apache на каждом из серверов, запустите его и добавьте в автозагрузку:
yum -y update && yum install -y httpd && systemctl start httpd.service && systemctl enable httpd.service
Создайте файл index.html в директории /var/www/html каждого из серверов и убедитесь, что страница корректно открывается в браузере с каждого из серверов.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>
Hi
</title>
</head>
<body>
Hello, World!
</body>
</html>
Для работы lsyncd нужно, чтобы был предоставлен доступ к каждому из серверов по ключу друг для друга.
Сгенерируйте ключ SSH (на вопросы можно просто нажать Enter):
ssh-keygen
С сервера в Москве добавьте ключ на сервер в Амстердаме:
ssh-copy-id root@failoverams.trukhin.com
С сервера в Амстердаме добавьте ключ на сервер в Москве:
ssh-copy-id root@failovermsk.trukhin.com
Теперь подключитесь с сервера в Москве (root@failovermsk.trukhin.com) к серверу в Амстердаме (root@failoverams.trukhin.com) и наоборот. Пароль запрашиваться не должен. На вопросы при подключении ответьте yes.
Устанавливаем и настраиваем lsyncd
Указанные ниже действия нужно провести на обоих серверах.
Для установки lsyncd в CentOS 7 добавьте репозиторий EPEL командой:
rpm -ivh http://mirror.yandex.ru/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
Теперь установите lsyncd:
yum install lsyncd
Создайте директорию для хранения логов и временных файлов lsyncd:
mkdir -p /var/log/lsyncd && mkdir -p /var/www/temp
Создайте файл конфигурации lsyncd по адресу: /etc/lsyncd.conf
settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd.status",
nodaemon = false
}
sync {
default.rsyncssh,
source="/var/www/html",
host="failovermsk.trukhin.com",
targetdir="/var/www/html",
rsync = {
archive=true,
compress=true,
temp_dir="/var/www/temp",
update=true,
links=true,
times=true,
protect_args=true
},
delay=3,
ssh = {
port = 22
}
}
Значение host: failovermsk.trukhin.com замените на поддомен, направленный только на сервер в другом регионе. В source указывается папка на текущем сервере. В targetdir указывается папка на удаленном сервере. Параметр delay – период, через который будет выполняться синхронизация изменений на сервере. Данное значение подобрано экспериментальным путем, значение по умолчанию — 10. Полностью все параметры lsyncd можно найти в официальной документации.
Для отладки установите параметр nodaemon=true и сохраните изменения. Создайте файл на одном из серверов:
touch /var/www/test
Запустите lsyncd вручную для проверки, что все корректно синхронизируется.
lsyncd /etc/lsyncd.conf
Если все прошло хорошо — на сервере в другом регионе в папке /var/www/html вы увидите созданный тестовый файл.
Теперь верните значение nodaemon=false в /etc/lsyncd.conf. Добавьте lsyncd в автозагрузку и запустите сервис:
systemctl start lsyncd.service
systemctl enable lsyncd.service
Убедитесь, что данные реплицируются и после перезагрузки.
Репликация в 2 стороны
Чтобы работала репликация и в обратную сторону — на сервере в другом регионе проведите такие же настройки, но в файле конфигурации lsyncd укажите адрес первого сервера. Проверьте, что данные реплицируются и в обратном направлении. В конфигурации lsyncd уже указана временная директория temp_dir, использование которой необходимо для двусторонней синхронизации.
Реплицировать в 2 стороны необходимо не всегда, так как в mysql не рекомендуется использовать master-master репликацию и в случае выхода первого сервера из строя при использовании такой базы данных придется настроить репликацию из второго рабочего сервера на третий. Это делается просто, если мы заранее подготовим шаблон резервного сервера для облака, о чем будет рассказано в последующих статьях. Сегодня мы работаем только с файлами и для статического сайта двусторонняя репликация вполне применима.
Проверяем доступность сайта
Давайте зайдем на наш сайт:
Оба сервера доступны.
Далее выключим сервер в Москве.
Наш сайт доступен:
Включим сервер в Москве и выключим в Амстердаме:
Наш сайт доступен:
Почему это работает?
Современные браузеры при наличии нескольких А-записей сначала пытаются зайти на один ip–адрес, а если он не доступен — на другой. Таким образом если хотя бы один сервер доступен — сайт будет работать.
Данный подход в более сложном виде давно используется большими сайтами и резервных серверов для них сделано много. Например у Google их 11:
Заключение
В данной статье мы рассмотрели как настроить георепликацию для статического сайта без базы данных. В последующих статьях мы рассмотрим, как реплицировать базу данных и обеспечивать высокую доступность для более сложных сайтов.
Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней. Если вы не можете оставлять комментарии на Хабре — напишите их в Сообществе InfoboxCloud.
Успешной работы!
Автор: infobox
