Идея написать статью появилась в связи с тем, что материалов по этой теме фактически нет, да и существующие описывают чуть ли не версию виртуальной машины 1.6 Главным же фактором стало то, что нужно многое учесть для более или менее нормальной работы кластера. В формат статьи не сможет войти вся исчерпывающая информация по 1С-Битрикс кластеру, да и была бы она весьма массивна и трудноусваиваемая. А вот основные кейсы по битрикс машине я все-же постараюсь взять.
Задача:
Поднять отказоустойчивый кластер на основе Битрикс «Веб-кластер» с распределенными серверами по разным датацентрам. Завести несколько сайтов.
В последующих пунктах особо важна последовательность, будьте внимательны!
Заказав два Dedicated Serve c двумя предустановленными дистрибутивами Linux Centos 6.6 final mini (которые все-же немного отличались).
1. Создаем домены для нодов.
Ноды кластера будут общаться через DNS имена, для них мы заводим два домена 3 уровня и прописываем соответствующие А записи каждому домену.
server1.test.ru A 1.1.1.1
server2.test.ru A 2.2.2.2
2. Hostname
Прописываем их в hostname до установки битрикс виртуальной машины, поскльку смена имени хоста в админке «1С-Битрикс виртуальной машины» не ведет к перегенерации всего мастер-нод, также в ней нет функции удаления мастер ноды. В противном случае вам придется править все конфиги и генерить все ключи заново ручками.
Вписываем на каждом сервере его доменное имя.
sudo vi /etc/sysconfig/network
/etc/init.d/network restart
Проверяем:
hostname
Она должна выдавать ваш домен на каждом сервере естественно свой.
На всякий случай указываю сразу все DNS имена в hosts файле.
vi /etc/hosts
Вписываем
1.1.1.1 server1.test.ru
2.2.2.2 server2.test.ru
Данную запись дублирую на втором сервере, она потом сама бы добавилась при создание slave-node, но если честно, переустанавливая машину уже в 5 раз, желания проверять, что именно работало не так, уже не было, так что исключаю любую возможность, да и проблемы с недоступностью доменов у меня по дороге все-же встречались, хотя скорее всего по моей вине.
Обратите внимание, что при создание master-node Вы не сможете откатить изменения, и при неправильно введенном имени, вам придется переустанавливать машину.
Обновление ОС
Видно что дистрибутивы разные, так что обновляем все дистрибутивы с одного зеркала. Сокращаю манипуляции до самой команды обновления.
Конечно все это можно пропустить и работать будет и так, но учитывая патологическое желание 1С-Битрикс виртуальной машины повесить кластер на любом доступном месте, стараюсь избегать разницы в версионности пакетов. Будем считать что я параноик.
yum update
Кстати, разница была в 200 мегабайт. (скриншот сделан на vps любезно предоставленных компанией vps-server.ru, на реальных машинах разница была)
Теперь у меня есть две чистые идентичные машины в разных датацентрах.
Но это еще не все.
3. Установка 1С-Битрикс окружения 5.2.1
Официальный вариант установки сразу пришлось немного кастомизировать.
Как я и писал в свое время в службу поддержки, такая команда сработает отнюдь не везде, так и в моем случае один из серверов попросту не имел wget.
yum install wget
Далее стандартно
wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh
chmod 777 bitrix-env.sh
./bitrix-env.sh
Обновлять саму виртуальную машину не имеет смысла, она обновляется при установке, до последней версии.
4. Порты
Также на одной из машин были закрыты все порты, по сему рекомендую сразу открывать их.
Да, в конфигах которые я встречал далее везде есть проверка, но учитывая качество сборки битрикс виртуально машины я бы не полагался на них. Так что открываем порты принудительно на всех машинах вне зависимости от того открыты они или нет.
iptables -I INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -I INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
iptables -I INPUT -p tcp --dport 5222 -m state --state NEW -j ACCEPT
iptables -I INPUT -p tcp --dport 5223 -m state --state NEW -j ACCEPT
iptables -I INPUT -p tcp --dport 8090 -m state --state NEW -j ACCEPT
iptables -I INPUT -p tcp --dport 8891 -m state --state NEW -j ACCEPT
Сохраняем и перезапускаем.
service iptables save
/etc/init.d/iptables restart
Проверить можно просто
telnet host port
5. Дополнительное ПО
Для моего проекта потребуется еще curl, так что я дооустанавливаю его на обоих машинах.
Также устанавливаю программное обеспечение, которым обычно пользуюсь.
yum install htop iotop atop mc w3m multitail vim mytop
6.Перезагрузка:
Для дальнейшей работы нам потребуется перезапустить ssh, но поскольку у нас на сервере сейчас активных посетителей нет, а установили мы уже достаточно много ПО, я перезагружаю все железо, дабы проверить лишний раз валидность рестарта машины.
shutdown -r now
Дожидаюсь перезагрузки и убеждаюсь лишний раз, что пока все идет как по маслу.
Теперь консоль встречает нас приветствием 1С-Битрикс машины и требует ввести пароль Bitrix пользователя.
От данного юезра и группы bitrix:bitrix будут работать все сайты на сервере, также его удобно давать контент-менеджерам в замен ftp, поскольку сайт расположен внутри /home
у контент-менеджеров не будет возможности убить ОС. Фактически пароль к этому юзеру можно всегда скинуть, НО нельзя оставлять пустым или легким! Также не забывайте о безопасности. Злоумышленник, получивший доступ к одному из сайтов, получает автоматически доступ к остальным!
Также не совсем понятна логика, ведь если говорить о валидности разделения прав, то проще это сделать на FastCGI, и в этом случае есть пара приятных плюшек. Если же говорить о реальной серьезности работы, то лучше использовать PHP-FPM, но уж никак не стандартный apache-php. В любом случае имеем что имеем.
7. Создаем ноды
В консоли:
1. Manage Hosts in the pool
1. Add new host in the pool
Enter IP address or DNS name for new server: 1.1.1.1
Теперь у нас есть master-nod (на нем будет расположен балансировщик его мы не можем передвинуть)
Добавляем второй сервер
1. Manage Hosts in the pool
1. Add new host in the pool
Enter IP address or DNS name for new server: 2.2.2.2
8. Manage web nodes in the pool
8. Создаем сайты
Сейчас мы создаем сайт.
НЕ ИСПОЛЬЗУЙТЕ default — /home/bitrix/www, использовать данный домен можно ТОЛЬКО в ДЕМО режиме, поскольку у него очень большие проблемы с мусорными запросами фактически в default валятся все неразобранные запросы, включая все зеркала и т. д., реальный сайт ставить в него крайне не рекомендуется! Или же очень осторожно прописать в.htacces все виды редиректов и даже в этом случае, я бы не рекомендовал вам ставить сайт в это место. Фактически оно создано для простоты установки, но никак не для безопасности и не для seo. ВСЕ сайты должны располагаться в папке ext_www
Все делаем с консоли.
6. Manage sites in the pool
1.Create site
Enter site name (ex. example.org) or 0 for exit: site1.ru
Enter site type (link|kernel|ext_kernel): kernel
Enter site encoding (UTF-8|windows-1251): UTF-8
Do you want to specify them? (N|y) N
Press ENTER for exit: Enter0. Previous screen or exit
И так, у нас сейчас появились папки для сайтов и все конфиги необходимые для работы сервера.
Установить сайт каждый в свою директорию достаточно просто, все что для этого нужно — прописать в host файле у себя на компьютере соответствующий домен и его IP, не забудьте указать зеркало с www во избежания проблем на сайте.
По умолчанию установщик не будет спрашивать паролей к БД поскольку они прописаны в dbcon.php, находящегося в каждой папке каждого сайта, при генерации!
Если же у вас все же возникли вопросы, то есть два варианта:
Посмотрите в dbcon в папке /var/www/ext_site.ru/bitrix/... и т. д.
Создайте свой, используя пароль root для генерации учетной записи. User: root Pass: ПУСТО
Для простоты я развернул демо сайты. На всех доменах.
3. при создании бд для сайта через консольную админку и указать кастом, но в этом случае вы попадете на две вещи </ br>
а) этот кастом будет с префиксом db, а имя бд юзера и самой бд будет отличаться от введенных вами, смотрите внимательно конечный вывод. Так же при введение бд типа site_1 site_2 возможны коллизии поскольку бд будет называться dbsite. В общем это самый не рекомендованный способ создания бд.</ br>
Учтите, что заявления 1c-Битрикс «теперь любая редакция будет иметь разрешения на 2 машины в кластере» — наглое вранье, ничего не поменялось. Кластер доступен только в старшей редакции, подробней на сайте битрикс.
9. Добавляем роли
Добавляем роль apache
1. Manage Hosts in the pool
1. Add new host in the pool
0. Previous screen or exit
Добавляем роль mysql
3. Configure MySQL servers
2. Create slave MySQL server
0. Previous screen or exit
Каждое действие занимает некоторое время. Во время создания роли apache так же копируется весь контент на новый сервер,
отследить что сейчас происходит достаточно легко:
iotop -oka
Также можно делать через веб панель. На сайте будет более графически отображаться, но толку не добавит особо, ошибки всеравно появляются, и каждый раз разные.
Как синхронизация прошла, у нас есть готовый кластер и мы, потирая руки, думаем что все уже хорошо, мало того, положив пару файлов на одном сервере, вы увидите что они в течение 5 минут появляются на новом. Все вроде бы хорошо и мы переходим к тестированию производительности. И тут-то начинается самое веселое.
Заходя в панель производительности, вы запускаете тест и получаете свои 0.5 попугайчика и 50 запросов в бд в секунду против только что доступных 80 и 34000 соответственно. Что мягко говоря озадачивает, сайт еле ползает.
Оставить комментарий