- PVSM.RU - https://www.pvsm.ru -
Часто случается, что после запуска какого-нибудь амбициозного интернет проекта и удачного его пиара в СМИ компания ожидает большой приток посетителей. К сожалению, наш мир не идеален и так случается, что сайт не справляется с таким потоком посетителей, называемым в наших кругах «хабраэффектом», и начинает тормозить. Соответственно компания теряет и деньги и репутацию. В таких случаях программисты обычно сваливают вину на админов, а админы на программистов. Получается замкнутый круг.
Что же делать, если ваше приложение стало тормозить? Одним из способов является перевод его в <a rel="nofollow" href="http://habrahabr.ru/company/jelastic/blog/136996/">кластерную архитектуру. К сожалению, есть не так много инструкций и статей, которые подскажут, как это сделать. Поэтому мы решили опубликовать небольшой пример того, как можно создать отказоустойчивый кластер на базе GlassFish [1]. Этот процесс и многое другое автоматизировано в Jelastic [2], но если Вы по каким-либо причинам не можете перейти на облачный
Давайте начнем по порядку:
Для создания отказоустойчивого кластера нам понадобятся: две машины n1 и n2 для серверов GlassFish (на одну из них будет установлен DAS и 2 сервера GF); машина lb1 для балансировки нагрузки; машина db1 для СУБД. Убедитесь, что все машины «видят» друг — друга (ping).
Все ПО будет работать под управлением Linux. Будем использовать заранее подготовленный образ виртуальной машины с CentOS. GlassFish использует для управления удаленными нодами SSH, поэтому нам потребуется установленный SSH-сервер на каждой из машин кластера. Также для возможности работы по SSH нам потребуется отдельная учетная запись в каждой ОС. Предлагаю назвать ее единообразно для всех машин: glassfish.
# adduser glassfish
# passwd glassfish
GlassFish использует нестандартные порты и для того, чтобы с ним можно было работать с помощью админ консоли в браузере, нужно либо прописать соответствующие правила в firewall, либо вообще его отключить. Предлагаю сделать последнее:
# service iptables save
# service iptables stop
# chkconfig iptables off
Ну и, конечно же, без JVM нам не обойтись.
Предупреждаю сразу, что придется прилично повозиться, так как требуется большое количество настроек.
Конфигурацию кластера будем проводить преимущественно из командной строки с помощью утилиты из поставки GlassFish asadmin
wget download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip
./asadmin start-domain domain1
Failed to rendezvous with DAS on n1:4848. Please check if this server is running, that the host and port are correct, and that this server is configured to allow remote access.
./asadmin enable-secure-admin
./asadmin create-cluster c1
../asadmin create-local-instance --cluster c1 i1
./asadmin create-local-instance --cluster c1 i2
./asadmin start-cluster c1
/asadmin –host n1 –port 4848 create-local-instance –cluster c1 i3
./asadmin –host n1 –port 4848 create-local-instance –cluster c1 i4
Сейчас фактически все готово для того, чтобы задеплоить приложение в кластер, но для нас этого мало, т.к. не обеспечена балансировка нагрузки и HA.
Нам необходимо установить и настроить балансировщик нагрузки для того, чтобы пользователям было удобно работать с приложением:
Вообще GlassFish «содержит» плагин балансировки для «популярных» http-серверов. Слова «содержит» и «популярных» не зря взяты в кавычки, т.к. данный плагин не содержится в Open Source версии GF, к тому же поддерживаются Oracle iPlanet Web Server,Oracle HTTP Server, Apache HTTP Server, Microsoft IIS. Все мы знаем, что Apache был когда-то хорош, но сейчас есть более эффективные решения.
Среди кандидатов: NGINX, HAProxy, lighthttpd.
Поддержим отечественного производителя и выберем NGINX [4], который к тому же все больше и больше захватывает рынок.
#yum install nginx
#nano /etc/nginx/nginx.conf
upstream backend {
ip_hash;
server 192.168.0.1:28080 max_fails=5 fail_timeout=15s;
server 192.168.0.1:28081 max_fails=5 fail_timeout=5s;
server 192.168.0.2:28082 max_fails=5 fail_timeout=5s;
server 192.168.0.2:28083 max_fails=5 fail_timeout=5s;
}
127.0.0.1 localhost
127.0.1.1 n1.cluster.com
127.0.0.1 n1.cluster.com
192.168.0.2 n2.cluster.com
127.0.0.1 localhost
127.0.1.1 n2.cluster.com
127.0.0.1 n2.cluster.com
192.168.0.1 n1.cluster.com
./asadmin validate-multicast
В данном примере будем использовать PostgreSQL [5].
Устанавливаем СУБД и создаем нового пользователя и базу данных.
# yum install postgresql-8.4
# service postgresql initdb
# service postgresql start
В PostgreSQL по умолчанию разрешены только локальные подключения. Для того, чтобы это исправить необходимо поправить конфигурационный файл /var/lib/pgsql/data/pg_hba.conf, в котором нужно указать разрешенные подсети: host all all 192.168.0.0/24 md5
Ну вот и все! Теперь наконец-то можно деплоить приложение (для примера мы используем jforum).
У меня, честно говоря, после всех этих настроек чуть не «вскипел мозг». Нам пришлось хорошенько «попотеть», чтобы автоматизировать весь описанный выше процесс в Jelastic и превратить его в несколько щелчков мышью.
Можете попробовать, что из этого вышло, на jelastic.com [2] и поделиться мнением в комментариях к посту.
Автор:
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/java/2360
Ссылки в тексте:
[1] GlassFish: http://glassfish.java.net/
[2] Jelastic: http://jelastic.com
[3] хостинг: https://www.reg.ru/?rlink=reflink-717
[4] NGINX: http://nginx.org/
[5] PostgreSQL: http://www.postgresql.org/
Нажмите здесь для печати.