Настройка отказоустойчивого веб сервера на базе nginx и apache.

Дата: 23.06.2015 Автор Admin

Рассмотрим настройку отказоустойчивых веб серверов.
В данном примере мы будем использовать для балансировки нагрузки, а связку + apache будем использовать как .

Теперь рассмотрим данную реализацию подробнее. Мы можем использовать две схемы отказоустойчивости, это схема 1:

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

Если вас интересует полная отказоустойчивость, то вам подойдет вторая схема:

В данной схеме задублирован каждый узел.

В рамках этой статьи мы рассмотрим реализацию схемы №1, как реализовать схему 2 я расскажу в конце статьи.

Теперь рассмотрим подробнее схему 1.

Нам понадобится:

1) Настроить DNS записи типа A на адрес балансировщика Nginx

2) Настроить балансировку нагрузки на сервере nginx

3) Настроить веб сервера на связке Nginx + Apache, где Nginx отдает статический контент, а Apache динамический

4) Настроить репликацию Mysql (тип Master-Master)

5) Настроить распределенную файловую систему GlusterFS для хранения сайтов

Перейдем к пункту 2, настроим балансировщик на базе Nginx.

Обновляем все пакеты:

Удалим кэш пакетов и ненужные пакеты:

Устанавливаем веб сервер Nginx.

Удаляем дефолтные конфиги.

Создаем конфиг для нового сайта.

Приводим данный конфиг к виду:

В данном конфиге:

В секции upstream http описываются метод балансировки и адреса веб серверов на которые распределяется нагрузка

Параметр max_fails указывает максимальное число неудачных соединений с сервером

Параметр fail_timeout указывает максимальное время ожидания при обрыве связи с сервером

В секции server описывается адрес сайта и порт на котором работает сайт

В секции location указываются параметры проксирования, параметр proxy_pass указывает какую директиву из конфига использовать.

Если вы настраиваете хост https , то конфиг будет выглядеть так:





В таком случае ssl сессии будет поднимать балансировщик, а не конечный веб сервер.

Сохраняем конфиг и включаем сайт (в примере используется конфиг без ssl).

Перезапускаем Nginx.

На этом настройка балансировщика завершена.

Перейдем к настройке вебсервера номер 1.

Обновляем все пакеты:

Удалим кэш пакетов и ненужные пакеты:

Установим часовой пояс.

Установим NTP.

Устанавливаем веб сервер .

Устанавливаем PHP.

Устанавливаем Mysql сервер.

Настраиваем безопасность Mysql.

Устанавливаем значения firewall.

Т.к. Apache будет нашим backend, настроим его на работу на localhost.

Открываем файл /etc/apache2/ports.conf

И редактируем директиву Listen, должно получиться так:

Включаем необходимые для работы модули Apache2.

Для корректного отображения ip адресов в логах установим модуль rpaf.

Так же вы можете отключить лишние модули, например вот так отключается модуль status.

Удаляем дефолтные сайты.

Перезапускаем Apache2.

Теперь установим Nginx, он будет frontend.

Удаляем дефолтные конфиги.

Повторяем данные операции на втором веб сервере.

Теперь перейдем к настройке распределенной файловой системе GlusterFS.

Данная фс нужна для хранения и репликации файлов сайтов между веб серверами.

На каждом из веб серверов создадим правила Firewall.

На каждом из веб серверов открываем файл /etc/hosts и прописываем полные адреса веб серверов.

Должно получиться примерно так:

Обратите внимание, что имя сервера на котором идет настройка указывается на 127.0.0.1, dns имя второго веб сервера указывается на его внешний ip.

Устанавливаем Gluster FS (выполняем это действие на каждом из серверов).

Теперь переходим на первый веб сервер и выполняем команду.

Где webserver2.test.com, dns имя второго веб сервера.

Проверяем объединились ли сервера в кластер.

Как видите сервера в кластере.

Теперь создадим кластерное хранилище с именем volume1,

В данной команде:

volume1 — название хранилища

replica 2 — количество серверов реплик

webserver1.test.com:/gluster-storage -В данном случае webserver1.test.com имя сервера gluster, а /gluster-storage путь к папке в которой будут храниться изменения в фс Gluster

Вывод команды должне быть таким:

Теперь включаем созданное хранилище.

Вывод команды должен быть таким:

Теперь установим клиентскую часть, для подключения созданной фс.

Выполните данные действия на каждом веб сервере:

Устанавливаем необходимые компоненты.

Создаем директорию для монтирования (Выполняем на каждом веб сервере).

Редактируем файл /etc/fstab и добавляем в него строку с параметрами подключения (Выполняем на каждом веб сервере):

В данной строке указываются следующие параметры:

webserver1:/volume1 — Адрес сервера к которому идет подключение (желательно указывать серверу самого себя) и название хранилища.

/storage-pool — папка, куда будет смонтирована фс.

backupvolfile-server — адрес резервного сервера.
Монтируем общее хранилище(Выполняем на каждом веб сервере).

Теперь на каждом веб сервере настроим список ip, которым можно подключать хранилище.

Сделать это можно командой:

Где вместо gluster_client1_ip,gluster_client2_ip вводятся ip адреса веб серверов.
Теперь создадим папку с сайтами.

Далее откроем доступ к папке с сайтами, для этого редактируем файл /etc/apache2/apache2.conf и вносим в него следующие строки (Делаем это на каждом веб сервере):

Создадим конфиг для нового сайта. (Делаем на каждом веб сервере)

Открываем конфиг в вводим следующее:

В данном примере:

Сайт работает на 80-м порту

Сайт доступен по DNS адресам newsite.test.com

Сайт расположен в директории – /storage-pool/hosting/newsite

 




Создаем каталог с новым сайтом.

Включаем сайт (Делаем на каждом веб сервере):

Перезагрузим конфиги apache2 (Делаем на каждом веб сервере).

Создадим конфиг сайта newsite для Nginx (Делаем на каждом веб сервере).

Открываем конфиг в вводим следующее:

 

В данном конфиге:

Директива listen ip_adress:80 указывает на каком порту и ip работает сайт

Директива root указывает корневую директорию сайта

Директива server_name указывает dns имя сайта

Директива:

Указывает тип статических файлов.

Директива expires указывает сколько дней хранить статический контент.

Директива:

Запрещает Nginx отдавать файлы начинающиеся с .ht

Директива:

Указывает что Nginx работает как обратный прокси и передает запросы на localhost.

 

Включаем сайт командой. (Делаем на каждом веб сервере).

Перезапускаем Nginx. (Делаем на каждом веб сервере).

Теперь в качестве примера установим CMS WordPress.

Скачиваем последнюю версию WordPress.

Разархивируем архив с CMS.

Копируем сайт.

Теперь перейдем к настройке Mysql репликации.

Переходим на первый веб сервер и открываем файл /etc/mysql/my.cnf.

Изменяем в конфиге следующие строки:

В данном конфиге:

server-id – номер id mysql сервера

log_bin – путь к бинарному логу, в него пишутся изменения

binlog_do_db – название БД, которую мы будем реплицировать

# bind-address – строка закоментирована, т.к. сервер должен работать не только на localhost

Перезапускаем mysql сервер.

Перейдем к настройке репликации.

Подключаемся к Mysql.

Создадим пользователя replicator.

Создаем базу данных, которую мы будем реплицировать.

Назначим права пользователю.

Проверить статус репликации можно командой:

Запоминаем параметры File (mysql-bin.000001) и Position (107). Эти параметры нам понадобятся на втором веб сервере.

Отключаемся от консоли mysql.

Переходим на второй веб сервер и правим конфиг файл /etc/mysql/my.cnf

Конфиг файл второго сервера будет отличаться только id.

Перезапускаем mysql на втором сервере.

Повторяем операции по созданию пользователя.

Создаем базу данных, которую мы будем реплицировать.

Назначим права пользователю.

Запускаем процесс репликации.

Параметры MASTER_LOG_FILE и MASTER_LOG_POS берем с первого сервера (вывод команды show master status;).

Теперь посмотрим статус репликации:

 




Запоминаем название файла и параметр позиции, эти данные понадобятся нам при включении репликации на первом сервере.

Теперь вернемся на первый сервер и включим репликацию на нем:

Меняем параметры MASTER_LOG_FILE и MASTER_LOG_POS полученные ранее из команды SHOW MASTER STATUS;

Теперь репликация работает на двух серверах.

Откроем консоль mysql и выполним команды:

Данными командами мы создали пользователя mysql для подключения из CMS WordPress к базе данных example_DB.

Теперь настроим CSM WordPress для работы с базой данных.

Копируем конфиг WordPress.

Открываем файл wp-config.php и редактируем следующие поля:

Теперь настроим права на папку с сайтами.

Теперь CSM wordpress сможет работать с базой данных.

На этом настройка схемы №1 окончена. При падении одного из веб серверов сайт http://newsite.test.com будет оставаться доступным.

Для реализации схемы №2 вам нужно добавить еще один балансировщик Nginx и создать в DNS две A записи вашего сайта, каждая из которых должна указывать на ip адрес одного из балансировщиков.

На этом реализация отказоустойчивого веб сервера завершена) Удачной настройки)


Комментарии

Александр

Добрый день!
После настройки получаю 403 forbidden.

Аноним

Открываем конфиг в вводим следующее:

ServerName newsite.test.com
DocumentRoot /storage-pool/hosting/newsite
CustomLog /var/log/apache2/newsite.access.log combined
ErrorLog /var/log/apache2/newsite.error.log

Исправьте, на , иначе apache скажет что порт занят(nginx крутится на 80).

    Admin

    В конфиге apache ports должно быть указано что он работает на localhost, тогда проблем с занятым 80-м портом не будет.

Alexander

Спасибо за хорошую статью. Мне очень помогла.

Alexxx

DNS сам понимает что один из фронтов не работает и не будет слать на него трафик?

    Admin

    Сам по себе DNS не понимает, вы можете установить низкий ttl, тогда при следующем запросе клиент попадет на работающий балансировщик.

Добавить комментарий

Ваш e-mail не будет опубликован.