Варіанти навантаження-балансира [закрито]

Я розглядаю ряд можливих варіантів збалансування навантаження.

Поки що я обмежений такими варіантами:

• Балансовий навантажувач DNS-сервера, балансуючи до кластеру серверів tomcat, з теракотою для реплікації сеансу. Плюси - не потрібно купувати новий комплект. Мінуси - фунт DNS може продовжувати направляти на зламаний сервер.

• Апаратний балансир завантаження, прямий на кластер серверів tomcat. Плюси - може бути другий ящик для відкази фунтів. Мінуси - витрати.

• Балансир завантаження сервера Apache. Плюси - опитування lb апаше на зламані сервери. Мінуси - сервер apache - це єдиний момент відмови, плюс необхідність придбати інший сервер.

Чи є інші варіанти, які я повинен розглянути?

Спасибі.

Оновлення: Дякую за всі відповіді до цього часу + 1 у всіх напрямках. Ще не прийнявши відповіді, щоб продовжувати надходити більше ідей.

я б не хотів би на основі dns-фунтів - саме з тієї причини, яку ви перераховуєте.

nginx або лак може бути вашим іншим параметром фунт / відмову, який сидить перед appservs і виступає як зворотний проксі. вони вимагають більшого догляду, ніж коробка обладнання, але заощадять вам досить багато грошей. не забудьте поставити цих балансирів і в якийсь кластер [активний пасив із серцебиттям зробить трюк].

Якщо ви дивитесь на прилади для балансування навантаження, ви дійсно не можете помилитися з F5 Big-IP

редагувати: Причина, по якій я кажу, просто переходьте з Big-IP, це те, що це приємний пристрій для адміністраторів серверів, які не мають великого досвіду роботи з мережевими пристроями. Він має приємний веб-інтерфейс з майже необмеженими параметрами конфігурації та звітності. Вони є найнадійнішими і найменш дорогими з усіх варіантів балансування навантаження на "підприємство".

Ось посилання на дослідження варіантів доставки додатків у 2007 році: результати Gartner

Я пропоную використовувати HAProxy . Це надзвичайно швидко. Ви також можете уникнути єдиної точки відмови, використовуючи два балансири з CARP (* BSD) або UCARP / LVS (Linux)

Ми вже багато років використовуємо Coyote Point Equalizer (апаратні балансири навантаження) і дуже раді їм. Вони можуть мати не всі функції F5, але вони все ще мають багато функцій, і коштують вони набагато дешевше. Продуктивність та надійність були чудовими.

Я схильний використовувати апаратні LB, оскільки вони часто можуть обробляти максимум великого обсягу трафіку, часто «простіші», тому більш здатні бути загартованішими краще / легше, а іноді можуть також керувати іншими проблемами безпеки, такими як напади SYN-потоку в апаратному забезпеченні. Я використовую ливарне виробництво, але є вибір на вибір (F5, Cisco тощо) - хоча витрачено :(

Cisco GSS (Global Site Selector) - це сервер DNS, який також здійснює перевірку стану здоров'я. Очевидно, це буде більш дорогим варіантом, ніж звичайний DNS-сервер. Веб-сторінка з більш детальною інформацією тут: http://www.cisco.com/en/US/products/hw/contnetw/ps4162/index.html

F5 has similar offerings:  http://www.f5.com/products/ 
Cisco ACE product page: http://www.cisco.com/en/US/products/ps8361/index.html

Як згадував Chopper3, апаратне врівноваження на основі обладнання, ймовірно, забезпечить більшу продуктивність, але ви заплатите за це.

Особливості, які ви можете шукати, це: завантаження SSL, підтримка vlan, контексти, кластеризація, підтримка протоколів маршрутизації та підтримка / взаємодія з різними програмами (тобто HTML-файли cookie та модифікація заголовка).

Ви подивилися на ldirectord ?

Він працює на Linux, може працювати з серцебиттям на тих же машинах, він балансує навантаженням (і, таким чином, вбудовується надмірність) - або, звичайно, на власній коробці перед ними, легко налаштовуватися, легкий і дуже здатний .

Я виявив, що перехрестя було чудовим балансиром навантаження. Ми працювали з нашими виробничими навантаженнями протягом семи місяців, тоді як хлопці мережі вирішили апаратну проблему з балансиром завантаження Cisco.

Я написав програмний балансир навантаження, який не потребує окремої машини.

Суть полягає в тому, що вона насправді не готова до виробництва - але якщо ви хочете протестувати її у вашій тестовій мережі, я буду радий.

Пухнастий кластер тут

Це в основному поверхнево схоже на NLB Microsoft (я думаю) - хоча я не маю їх джерела і не знаю, як саме працює їхнє.

Звичайно, ми не контролюємо автоматично додаток, але ви можете написати щось, що це робить, і змінювати ваги або витягувати вузли відповідно.

EDIT: Ви не сказали, що таке ОС, Fluffy кластер є лише Linux.

keepalived - це ще один балансир завантаження Linux, який підтримує декілька алгоритмів балансування навантаження (очевидно) та VRRP для створення зайвих екземплярів з автоматичним відмовою, коли поле балансира навантаження знижується

Якщо гроші не викликають занепокоєння, знайдіть апаратний балансир завантаження.

Компанія, над якою працюю, використовує Apache для переходу до наших серверів Tomcat, а балансир навантаження знаходиться в тому ж полі, що і деякі Tomcat (tomcats використовують внутрішні порти). Незабаром ми перейдемо до спеціалізованого вікна балансира навантаження. Незабаром ми перейдемо до Nginx, але я вважаю, що конфігурація простіша і вся справа набагато легша, ніж Apache. Залежно від вашої мережевої архітектури, я б також радив вам використовувати внутрішній "плаваючий IP" для балансира навантаження, а також запустити щось на зразок серцебиття, щоб переключити IP в інше поле, якщо потрібно. Це додасть можливості відмовитись, не турбуючись про проблеми поширення DNS.

Я створив рішення з DNSMadeEasy . У них є хороший показ екрану щодо відмови DNS. Вони мають розумні ціни. У нашій системі ми реалізували просту службу, яка "пінговує" різні компоненти нашої системи (база даних, черга JMS, з'єднання S3) і повертає ОК, який DNSMadeEasy може використовувати. Щоразу, коли настає виняток, DNSMadeEasy видалить цей сервер зі списку серверів, які відповідають на це пошук DNS.

Ви дивилися на перлбалу?

www.danga.com/perlbal/

Привіт @toolkit Ви коли-небудь реалізовували NGinX / Varnish у своєму квесті LoadBalancer (LB)? якщо так, то які були ваші результати? (якщо ви не проти поділитися з іншими нами ;-)

Просто підсумувати вищесказане (і згадати ZMQ)

Базове балансування навантаження

• У Apache є проект вищого рівня під назвою Camel - http://camel.apache.org/load-balancer.html (також є mod_proxy, якщо вам зручніше з Apache2 - http://httpd.apache.org/docs/ 2.0 / mod / mod_proxy.html )
• NGinX має HTTPUpstreamModule, який робить основне (але проти.) Балансування навантаження - http://wiki.nginx.org/HttpUpstreamModule
• HAProxy також надзвичайно ефективний - http://haproxy.1wt.eu/
• Якщо у вашому веб-додатку є багато статичних сторінок, які не потребують персоналізованих повідомлень, ви можете спробувати кеш лаку - https://www.varnish-cache.org/trac/wiki/LoadBalancing

Більш розширений

• ZeroMQ може впоратися з феноменальною одночасністю та завантаженням, але не розроблений з урахуванням LB; Його черга повідомлень - яка по суті поширює (вирішує) вхідні запити. Якщо ви відчуваєте пригоди, рекомендую заглянути до цього (2-х годинна крива навчання - висока рентабельність інвестицій! ):
  • http://nichol.as/zeromq-an-introduction
  • http://www.igvita.com/2010/09/03/zeromq-modern-fast-networking-stack/