Один в полі не воїн: як створити відмовостійкий кластер
Часто трапляється, що після запуску якого-небудь амбітного інтернет проекту і вдалого його піару в ЗМІ компанія очікує великий приплив відвідувачів. На жаль, наш світ не ідеальний і так трапляється, що сайт не справляється з таким потоком відвідувачів, званим в наших колах «хабраеффектом», і починає гальмувати. Відповідно компанія втрачає і гроші і репутацію. У таких випадках програмісти зазвичай звалюють провину на адмінів, а адміни на програмістів. Виходить замкнуте коло.
підготовка
Для створення відмов кластеру нам знадобляться: дві машини n1 і n2 для серверів GlassFish (на одну з них буде встановлено DAS і 2 сервера GF); машина lb1 для балансування навантаження; машина db1 для СУБД. Переконайтеся, що всі машини «бачать» одне - одного (ping).
конфігурація кластера
Конфігурацію кластера будемо проводити переважно з командного рядка за допомогою утиліти з поставки GlassFish asadmin
- Викачуємо дистрибутив GlassFish
wget download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip
і розпаковуємо його. - Запускаємо екземпляр адміністративного домену (domain1):
./ Asadmin start-domain domain1
GlassFish за замовчуванням забороняє віддалені початку сеансу домену. І все вузли кластера (Node Agents), крім того вузла, на якому стоїть DAS, не зможуть з ним взаємодіяти.
Типова помилка:
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 - Додаємо нові екземпляри, що знаходяться на машині n2 (команди фізично виполняються на n2):
. / Asadmin -host n1 -port 4848 create-local-instance -cluster c1 i3
./ Asadmin -host n1 -port 4848 create-local-instance -cluster c1 i4 - В адмін консолі знаходимо новостворений екземпляр, міняємо його тип на SSH, міняємо значення поля Node Host на n2. При цьому нам необхідно вказати ім'я користувача і його пароль для доступу по SSH на машину n2. Запускаємо кластер. Бачимо, що всі екземпляри працюють.
Балансування навантаження і HA
Зараз фактично все готово для того, щоб задеплоіть додаток в кластер, але для нас цього мало, тому що не забезпечена балансування навантаження і HA.
Нам необхідно встановити і налаштувати балансувальник навантаження для того, щоб користувачам було зручно працювати з додатком:
- зверталися тільки по одному УРЛу;
- їх запити розподілялися рівномірно по всіх примірників серверів кластера;
- в разі виходу з ладу деякої кількості примірників користувачі змогли б продовжити роботу з додатком в штатному режимі;
- і взагалі не знали про внутрішню «кухню» кластера.
Взагалі GlassFish «містить» плагін балансування для «популярних» http-серверів. Слова «містить» і «популярних» не дарма взяті в лапки, тому що даний плагін не міститься в Open Source версії GF, до того ж підтримуються Oracle iPlanet Web Server, Oracle HTTP Server, Apache HTTP Server, Microsoft IIS. Всі ми знаємо, що Apache був колись гарний, але зараз є більш ефективні рішення.
Серед кандидатів: NGINX, HAProxy, lighthttpd.
Підтримаємо вітчизняного виробника і виберемо NGINX. який до того ж все більше і більше захоплює ринок.
- Встановлюємо NGINX:
#yum install nginx
#nano /etc/nginx/nginx.conf - Налаштовуємо NGINX на балансування запитів round-robbin для 4х серверів однакових ваг c підтримкою закріплених (sticky) сесій (нижче наводиться частина конфіга і запускається сервер).
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;
>
Варто відзначити, що це найпростіший конфиг закріплює сесії користувачів за конкретним сервером за методом ip_hash - Щоб запрацювала HA необхідно, щоб хости n1 і n2 мали загальний батьківський домен. Наприклад, cluster.com. Для цього потрібно модифікувати файли / etc / hosts на обох машинах наступним чином:
n1:
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
n2:
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 - Для перевірки роботи multicast на кожній фізичній машині кластера виконуємо:
./ Asadmin validate-multicast - В адміністративній консолі DAS GlassFish необхідно поміняти згадка n2 на n2.cluster.com
- Для того, щоб GlassFish виробляв реплікацію Http-сесій між екземплярами кластера необхідно, щоб веб-дескриптор додатки містив відповідну інструкцію (тег
) І при Деплой додатки встановити прапор Avalaibility.
Установка і конфігурація БД
В даному прикладі будемо використовувати PostgreSQL.
Встановлюємо СУБД і створюємо нового користувача і базу даних.
# 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
Давайте подивимося, як зростає споживання ресурсів серверами в конфігурації відмов кластеру (з реплікацією сесій) на прикладах серверів, доступних зараз в Jelastic.
Почнемо з GlassFish. Цей сервер має безліч переваг: повна підтримка промислової кластеризації, широкий спектр функцій, безліч модулів, висока надійність, адміністративна панель і т.д. Якщо ми поглянемо на наступну таблицю, то може здатися, що GlassFish досить «ненажерливий», але це повністю виправдано його функціональністю.
Примітка: в усіх таблицях ми вказуємо не тільки споживання пам'яті в MB, але і кількість споживаних клаудлет. Клаудлети - наш спосіб вважати спожиті ресурси. Один клаудлет - це 128 MB RAM і приблизно 200 Mhz CPU core.
Tomcat 6 - найпопулярніший сервер серед наших розробників, завдяки його простоті і стабільності. Оптимальний вибір для більшості веб-додатків. Скільки ресурсів він «їсть» при всіх можливих варіантах конфігурації, ви можете побачити в наступній таблиці:
Tomcat 7 теж має чим похвалитися: він ще більш продуктивний і ефективний, ніж його попередник. Відповідно вимагає трошки великих витрат:
Що стосується Jetty. то цей сервер додатків стає все популярнішим серед розробників (як показує наша статистика). Також він є найбільш «легковажним», переконайтеся самі:
Як вам уже відомо, GlassFish - високонадійний Java EE сервер додатків з повною підтримкою промислової кластеризації і широким спектром функцій.
До недавнього часу Glassfish використовувався в Jelastic Java PaaS просто як окремий сервер, тепер же ми підтримуємо всі функції цього сервера, включаючи високу доступність (HA).
Ми зберегли «рідну» кластерну архітектуру GlassFish, яка заснована на концепції адміністративного домену. Адміністративні домени складаються з кластерів і інстанси, контроль над якими здійснюється за допомогою DAS (Domain Administration Server).
Ви можете управляти центральним репозитарием за допомогою адмін консолі. Це легкий у використанні GUI, який підтримує всі фічі, доступні в Glassfish. DAS управляє Java інстанси домену, а GMS (Group Management Service) відповідає за надання інформації про кластер і його інстанси.
Реплікації сесій в GlassFish
Інстанси в кластерах розбиваються на пари. Якщо один з інстанси впав, користувачі, запити яких оброблялися на ньому, автоматично перекидаються на інший інстанси кластера. «Інстанси-напарник» вже має в наявності всі сесії впав, так що кінцевий користувач ніколи не помітить ніяких змін. У разі падіння обох інстанси запити користувачів перенаправляються на інший кластер. Для перенаправлення запитів Jelastic використовує NGINX балансер (як і у випадку з іншими серверами додатків).
масштабування
Звичайно ж, ми не забули про масштабування. Надається як горизонтальне, так і вертикальне масштабування для випадків збільшення або зменшення навантаження на сервері. Це означає, що може змінюватися і розмір, і кількість кластерів. Jelastic - перша PaaS, яка надає таку досконалу систему масштабування.
Кластерна архітектура GlassFish в Jelastic дуже близька до стандартної, так що ви можете використовувати всі її можливості і навіть трошки більше.