Размышления о кластеризации: Часть 2 - Раздача Статики
Долго думал как продолжить цикл статей о кластерах. В предыдущей статье <a href="http://www.tech-notes.net/notes-about-clusters/" title="Размышления о кластеризации. Часть 1" target="_blank">Размышления о кластеризации. Часть 1</a> я рассмотрел вариант разнесения базы данных и вэб сервера на разные ноды/головы. Во второй статье я хотел рассмотреть вариант добавления дополнительных вэб серверов, потом понял что в блоге нету заметки о всех, известных мне, вариантах балансировки нагрузки. Потом подумал о том, что можно было бы описать добавление в кластер сервера баз данных, потом понял что в блоге нету заметки о репликации mysql.
Что осталось еще? Так называемые application или storage сервера. Вот-вот 🙂 Для рассмотрения введения дополнительного звена заметок хватает.
Исходя из предыдущей статьи, имеющийся в наличии, web сервер отвечает за следующие задачи:
- Отдача динамически генерируемого контента;
- Раздача статических объектов, таких как картинки, css/стили, js/скрипты, шрифты и прочие файлы.
- Опциональной задачей вэб сервера может являться кэширование данных с помощью memcached, APC или eAccelerator.
- Каждый уважающий себя серверный админ стремится установить Varnish, поэтому он так же может крутиться на оставшемся вэб сервере.
Как Вы могли заметить, основная задача этого сервера в пункте №1. В случае увеличения нагрузки на существующий кластер из двух серверов, не стоит торопиться создавать еще один web сервер. Есть смысл (здравый) освободить имеющийся сервер от выполнения второстепенных задач. И опять же раздача статики не является трудоемкой задачей, поэтому для нее можно брать самый слабый, из доступных у Вашего хостера, сервер.
Общая картина работы будет следующей:
Для того, что бы раздавать статику, можно собрать NginX из исходников, отключив полностью все модули. Оставить можно только gzip модуль. Строка конфигурирования будет выглядеть следующим образом:
./configure -prefix=/etc/nginx -user=nginx -group=nginx -with-http_gzip_static_module
После того, как NginX установлен, нужно каким-то образом разместить статический контент на новом сервере. Для этого есть три варианта:
- Синхронизация контента с Web сервера на App сервер (lsync, rsync). Не предпочтительный метод, поскольку в этом случае у Вас увеличится в два раза объем хранимых файлов, хоть и на двух серверах.
- Установить NFS сервер на Web сервере и замонтировать папку сайта на App сервер.
- Перенести весь контент на App сервер,установить на нем NFS сервер и замонтировать папку всего сайта на Web сервер.
Рекомендую выбирать из двух последних вариантов. Все зависит от объема файлов.
Если доступное дисковое пространство на App сервере позволяет вместить все файлы вашего сайта, тогда лучше следовать третьему варианту. Это предпочтительный подход, если учесть необходимость дальнейшего увеличения серверов в кластере.
Опять же опционально, можно скопировать весь контент сайта на App сервер и замонтировать всю папку на Web сервер с помощью NFS.
Общая схема немного преобразилась. В нее были добавлены новые элементы. Разноцветные стрелочки показывают разные типы запросов.
Теперь осталось разграничить запросы к двум серверам. Нужен ли балансировщик нагрузки?, - спросите Вы. Нет, не нужен., - отвечу я Вам. Для того, что бы запросы статики отправлялись на App сервер, достаточно одного правила rewrite в .htaccess файле на Web сервере.
Я буду рассматривать вариант, когда на Web сервере установлен Apache. Для NginX эти правила можно конвертировать.
Для начала можно создать DNS А запись, обозвав ее static.yourwebsite.com и указать ей IP адрес APP сервера.
Дальше добавьте вот такие правила модуля rewrite в .htaccess файл в корневой папке сайта:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.yourwebsite.com$ [NC]
RewriteRule .*.(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|woff|другие_типы_файлов)$ http://static.yourwebsite.com/$1 [R=301,L]
другие_типы_файлов замените недостающими расширениями файлов, саму фразу из правила нужно удалить.
Вообще подход кривой, но он не будет создавать лишней нагрузки на Web сервер. Конечно же желательно переписать все адреса статистических объектов в базе данных Вашего сайта. В случае с CMS Magento, можно просто поменять адрес сервера со статическим контентом в панели администратора.
Кэшировать статику нету смысла, поэтому не нужно настраивать Varnish на App сервере для обработки статического контента. Отдельный вариант я рассмотрю со временем.
На app сервер так же можно установить Memcached. В файле настроек (/etc/memcached.conf) нужно сменить ip адрес сокета с 127.0.0.1 на доступный для сетевого соединения ip адрес (в схемах 10.10.10.30) и разрешить входящие соединения на порту 11211 для серверной подсети:
iptables -I INPUT -p tcp -s 10.10.10.0/24 -dport 11211 -j ACCEPT
Не забудьте перенастроить ваш сайт на работу с memcached на app сервере.
На этом пожалуй все. Теперь сайт вертится на трех серверах, каждый из которых отвечает за вверенные ему задачи.
Следующая статья:
Размышления о кластеризации: Часть 3 — Varnish кэш
