Розподілення навантаження (Load balancing)

Всім привіт.

Задача:

Є 4 сервери, є Apache з модом mod_jk, і є Tomcat з апплікейшном, потрібно максимально ефективно розподілити навантаження по цим серверам, хто займався даною темою підскажіть, будь ласка, які конфігурації будуть найбільш ефективними:

1) Сервер1: Apache;

Сервер2: Tomcat;

Сервер3: Tomcat;

Сервер4: Tomcat;

2) Сервер1: Apache, Tomcat;

Сервер2: Tomcat;

Сервер3: Tomcat;

Сервер4: Tomcat;

3) Сервер1: Apache, Tomcat;

Сервер2: Tomcat, Tomcat;

Сервер3: Tomcat, Tomcat;

Сервер4: Tomcat, Tomcat;

ЧИ якісь інші?

Усі сервлет контейнери працюють з однією базою (кластер). Серверна ОС ролі не грає.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Якщо передбачається зміна заліза та операційної системи, то на даному етапі тестується виключно продуктивність кластеру. Орієнтовна кількість оброблених запитів за одиницю часу. В такому випадку я би до тестування наступних конфігурацій саме в такому порядку:
1. Apache
2. Tomcat
3. Tomcat
4. Tomcat
Для Java налаштування поставте 1.0 — 1.5 GB RAM (XMX, XMS options).
Зніміть графіки навантаження на процесор та споживання пам"яті.

Піднімайте навантаження на тестову систему до завантаження Tomcat ~90% Спостерігайте за Apache & network traffic from apache. Якщо багато статичного контенту, то слабким мысцем буде апач. Якщо ж апач недогружений, то на ту ж саму машину ставимо додатковий томкат. Знову тестуємо. Якщо ж слабким місцем виявився апач (коли багато статики), це менш імовірне, але можливе, то тоді треба гратись з балансуванням навантаження перед апачем. Інакше це не потрібне для ранніх етапів тестування.

я б взяв варіант
1) Tomkat+Apache + nginx

2) 3) 4) Tomcat

Дякую, але теорія мене не цікавить, оскільки я її прочитав щодо цієї теми.
Цікавлять реальні робочі конфігурації тому, що у мене не має даного досвіду і я хотів зекономинити власний час.
На даний момент тестування проводиться на 2-х ядерних процах по 1.8 МГц ядро, з 3Гб РАМ, він ХР, це робочі станції, тестуємо на них. Пізніше змінемо залізо і ймовірно поставим юнікс системи.
Для себе зробив висновок, що треба ставити експеременти і все, інакше — ніяк.

Дякую за увагу.

Задача з розряду теоретичних. Можна довго сперечатись, але я би радив просто задуматись над наступним:
1. Які очікування від кластеризації? Виграш у стабільності (надійності, безвідмовності), чи виграш у продуктивності. Що з цих двох критеріїв є пріоритетнішим?
а) Якщо стабільність, то особливу увагу треба приділяти балансуванню навантаження. Я би радив тоді, залежно від бюджету, або hardware load balancer, або спочатку примітивний балансер (наприклад: pound), який просто перекидає навантаження на резервну схему в разі відмови першого пристрою. Після цього — вже під«єднувати апач, який розкидає на томкати.
б) Якщо про стабільність не йдеться, то вибір мав би бути між першою та другою схемами залежно від навантаження на апач. Якщо воно не «їсть» процесора, то на тій же ж машині можна експлуатувати томкат.
2. Яке "залізо використовуватиметься? Тип процесора та кількість, об"єм пам"яті. Тип операційної системи. Чи використовується віртуалізація?
Є схеми, коли на кожній машині розташовують по 2 віртуальних і таким чином кількість елементів у кластері подвоюється, крім того існує як мінімум 2 гілки: паралельні, або основна та резервна. Особисто моя суб"єктивна думка: рішення з 2 віртуальними повноцінними ОС (на яких встановлено tomcat) краще за 2 tomcat’и, встановлені на одній ОС.

3. Раджу пробувати то не теоретично, а підкріпляти тестами. Все одно теоретичні поради не дадуть вам остаточного рішення саме для ваших потреб.

Green Threads после java 1.1 не применяются, так что все должно отлично паралелиться.

да, там не всё так просто, если даже слегка погуглить видно как люди жалуются.

Java мапит threads 1: 1 в threads операционной системы. Если операционная система сможет раскидать по ядрам — тогда теоретически всё заработает автоматом. Ещё GC можно захотеть на отдельном ядре запускать.

2Igor,

А что, джавовские потоки не распределяются между ядрами?

если многоядерные серверы — то два томката на одном сервере может быть оправдано. без нагрузочного тестирования ничего определенного сказать нельзя.
видите ли, очень много вариаций в таких задачах, от того сколько длится средний запрос, до того сколько CPU и IO он потребляет. Потом вы поменяете алгоритм балансировки и можно всё начать сначала.
ваши тесты могут показать довольно странные результаты, но этого не стоит бояться — надо пробовать и выбирать лучшее.

А стараться надо что бы решение было просто, максимально просто.

Кстати поместить стат. контент на апач или другой хттп сервер — это действительно один из путей оптимизации.

Я бы выбирал между 1 и 2, так как не вижу никакого смысла держать на сервере два томката с одной апликухой. Ну, а между 1 и 2 нужно выбирать в зависимости сколько проца и памяти у вас отжирает апач, если много — то 1, если не очень много — 2.

П.С. — рассуждения чисто теоретические, никогда такими задачами не занимался...

Я то поексперементую, але хотілося б взнати про існуючі робочі конфігурації і чому були обрані саме вони.

Не зрозумів яке відношення ваше питання має до проблеми, відповідь — ні.

если есть возможность, по-эксперементируйте с этими конфигурациями. статический контент весь на апаче?

Подписаться на комментарии