UMGUM.COM 

LNAPM + Mirroring ( Web сервис на базе Nginx, Apache, PHP и MySQL, с элементарным полным резервированием и автозамещением посредством CARP. )

26 марта 2010  (обновлено 27 мая 2017)

Эта публикация отнесена в архив. Она неактуальна.
Ресурс по следующей ссылке является преемником: Web сервис на базе "Nginx", PHP-FPM, "NodeJS", "MySQL", "MongoDB", "Memcached", "mSMTP", "inCron", LXC и "Supervisord".

OS: Linux Debian Lenny/Squeeze.

Задача: обеспечить запуск web-сервиса где процессы и данные владельцев ресурсов будут изолированны друг от друга, исполнение скриптов будет производится от имени владельца файлов выделенного ресурса, доступ между разграниченными ресурсами будет невозможен. Для разгрузки сервера приложений от несвойственных ему операций выдачи статического содержимого соберем схему с "front-end" для выдачи статического содержимого (особенно выгодно при наличии большого количества клиентов с низко-скоростным подключением) и "back-end" сервером для обработки динамического содержимого.

Дополнительная задача, решаемая после исполнения первичной задачи развёртывания web-сервиса - "зеркалирование" физического сервера со всеми web-сервисами и настраивание системы слежения за доступностью web сервисов и автоматического замещения их рабочими. Задачу зеркалирования решаем наиболее "убойными" в своей простоте методами, допускающими выпадение любого из элементов схемы без нарушения её целевого функционала.

Особое условие - никакого изящества в решении, никаких "нано-технологий", все должно быть просто до уровня пошагового освоения и осознания выпускником "ПТУ".

Применим Linux Debian Lenny/Squeeze в качестве операционной системы, Apache2 в качестве "back-end" сервера приложений, FastCGI в качестве средства вызова интерпретаторов, PHP5 в качестве интерпретатора пользовательских скриптов, SUPHP в качестве средства разделения процессов пользователей при запуске скриптов PHP5, Nginx в качестве "front-end" сервера для отдачи статического содержимого, MySQL в качестве СУБД, SFTP как функция от SSH в качестве средства доступа владельцев к своим ресурсам. CARP как средство определения доступности сервисов. Ограничение пользователей в доступных ресурсах файловой системы будет реализовано с помощью встроенных в систему средств UNIX Posix User Permisions.


Примем за данность, что:

подсеть, в которой мы будем экспериментировать - 10.10/16;
IP-адрес доступа нашего первичного сервера - 10.10.2.24/24;
IP-адрес доступа нашего вторичного сервера - 10.10.2.25/24;
общий IP-адрес web-сервисов наших серверов - 10.10.2.26/24;
доменное имя доступа нашего первичного сервера - web1.local;
доменное имя доступа нашего вторичного сервера - web2.local;
доменное имя web сервисов наших серверов - web.local;
доменное имя нашего тестового сайта - u000.local;
доменное имя нашего второго тестового сайта - u001.local.

На начальном этапе конфигурирования служба httpd под управлением Apache2 будет слушать следующий порт:

tcp:10.10.2.25:80

После введения службы прозрачного проксирования под управлением Nginx картина прослушивания изменится до следующей:

tcp:0.0.0.0:80 - Nginx прослушивающий внешний интерфейс;
tcp:127.0.0.1:8080 - Apache2 (это подключение на localhost, открывать доступ к Apache2 на внешних интерфейсах совершенно ни к чему).

После настройки разделения сервисов на открытые и шифрованные прослушиваться будут следующие порты:

tcp:0.0.0.0:80 - Nginx прослушивающий внешний интерфейс для протокола HTTP;
tcp:0.0.0.0:443 - Nginx прослушивающий внешний интерфейс для протокола HTTPS;
tcp:127.0.0.1:8080 - Apache2 в качестве "back-end".

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

При описании параметров сетевых интерфейсов первичного и вторичного сервера помним о том, что их общий IP-адрес, который позже будет задействован для доступа к сервисам как таковым со стороны клиентов, пока не используется и не описывается нигде.

Перед тем, как приступать к инсталляции и конфигурировании каких либо сервисов, необходимо разобраться с установками системных часов, показателями времени и его смещения. Очень мутно ковыряться в журнальных файлах в системе с некорректно выставленным системным временем.

Сразу определимся с тем, что имена пользователей применим стандартизированные, вида: "u1001", "u1002", "u1003" и так далее. В ближайшем будущем опасаться роста количества более десяти тысяч можно не опасаться, так что ограничимся четырьмя разрядами. Имена вроде "vasya" или "firma-top" применять не будем хотя бы потому, чтобы не смазывать взгляд разномастными по длине и виду наименования пользователей. Соответственно, логин для сервисов пользователя можно будет применить единый, по имени пользователя: "u1001", "u1002", "u1003" и так далее. Группы пользователей будем именовать аналогично логинам пользователей, добавляя символ "g": "ug001", "ug002" и так далее.

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