• Главная
  • Карта сайта
Не найдено

Огляд систем балансування мережного навантаження для * nix

  1. З чого вибирати?
  2. BalanceNG
  3. HAProxy
  4. Pound - проксі і балансування HTTP і HTTPS
  5. Crossroads
  6. ZEN Load balancer
  7. Висновок

Коли потужності сервера вже не вистачає, постає питання яким шляхом йти далі. Вертикальне масштабування завжди має певний межа і часто не дає пропорційного приросту, і до того ж не забезпечує необхідної відмовостійкості. Тому найбільш вірним кроком буде установка другого сервера, який візьме на себе частину навантаження. Залишається вибрати додаток яке буде забезпечувати балансування.

З чого вибирати?

Рішення для балансування мережного навантаження, тільки на перший погляд виглядають однаково. Насправді в процесі беруть участь безліч технологій і алгоритмів, тому знайти два однакових можна навіть і не пробувати. Крім очевидного - підтримка певних протоколів (наприклад, тільки HTTP або будь-які), є і безліч інших параметрів.
Так системи балансування навантаження можуть перенаправляти трафік клієнтів на обраний сервер декількома способами. Найпопулярніші: трансляція мережевих адрес (Network Address Translation) і шлюз TCP (TCP gateway). У першому випадку балансувальник на льоту підміняє в пакеті IP адреси, ніж приховує IP сервера від клієнта і навпаки. Якщо ж IP-клієнта потрібно кінцевому додатком для статистики або будь-яких інших операцій, його зазвичай зберігають в HTTP заголовку X-Forwarded-for. При використанні іншого протоколу слід переконатися що подібна можливість реалізована. У разі TCP gateway балансувальник вміє управляти трафіком на L4 (транспортом) рівні і навіть на рівні додатку (L7). Для цього він встановлює з'єднання і дивиться всередину пакета. Зазвичай клієнт і додаток обмінюються інформацією через балансувальник. Але останнім часом стає все більш популярною конфігурація сервера з прямим поверненням (Direct Server Return, DSR) коли відповідь від сервера йде до клієнта безпосередньо, а не через пристрій балансування. Використання DSR зменшує навантаження на балансувальник, але не дозволяє використовувати куки, і розшифровувати SSL. Даний спосіб на порядок швидше ніж використання NAT балансування і дозволяє сервісів бачити реальні IP адреси клієнтів.
Також в системах можна зустріти різні методи балансування. Розберемося з призначень деяких з них. В налаштуваннях продуктів вони можуть мати відмінні назви або свої особливості в реалізації, але часто їх суть одна.
Найпростіший Round Robin DNS - це спеціальний DNS сервер містить кілька «А» записів і опціонально їх вага, і видає при запиті клієнтів різні IP адреси. Мінуси очевидні. Він абсолютно не володіє інформацією про поточне завантаження і стан бекенда, не враховує попередні підключення клієнтів (трохи згладжує ситуацію DNS кеш).
Є аналогічний за назвою алгоритм але реалізований засобами самого балансувальника - Round Robin. Всі клієнти рівномірно розподіляються по бекенда, і зазвичай будь-які інші параметри не враховуються. Алгоритм розподілу по вазі (Round Robin Weighted) враховує значення параметра Weight зазначеного для кожного сервера. Проставивши більшу вагу для більш потужного сервера ми зможемо направити до нього більше клієнтів. Дещо по-іншому працює розподіл за пріоритетом. У цьому алгоритмі працює тільки сервер з великим пріоритетом, інші підключаються, як правило, тільки в разі його відмови. Цей варіант дозволяє будувати кластер з одним активним вузлом (активний - пасивний), наприклад коли другий сервер виконує іншу роль і тільки підстраховує перший. Least Connection (Least Session) - з'єднання приймає сервер обслуговуючий найменшу кількість з'єднань (сесій), але з'єднання можуть бути різні (користувач активний або пасивний) і відповідно давати різне навантаження на сервер. А ось алгоритм Least Bandwidth враховує дійсну завантаження на мережу.
Hash: sticky client - клієнт прив'язується до одного сервера, для цього в спеціальну таблицю поміщається хеш-рядок вказує на його IP. Можливі варіанти. Клієнт завжди йде до одного сервера, а в разі його виходу підключення неможливо. Або коли не відповідає «рідний» він з'єднується з іншими системами.
Доступність бекенда визначається двома: активний (keepalives, балансувальник сам опитує сервера) і пасивний (In-Band, контролюються поточні з'єднання, відповіді сервісу).

BalanceNG

Проект номер один в списку - BalanceNG (inlab.de/balanceng), являє подальший розвиток ідей закладених в OpenSource вирішенні [Balance] (inlab.de/balance.html), але яке розповсюджується вже під подвійний ліцензією (комерційної та безкоштовної Free Basic License) . За умовами останньої можна підключати один віртуальний сервер і два вузла, чого з урахуванням можливостей досить щоб без проблем впоратися із середньою, а іноді і великим навантаженням. Являє собою рішення для балансування IP навантаження підтримує IPv6, пропонує кілька методів управління вибору бекенда (Round Robin, Random, Weighted Random, Least Session, Least Bandwidth, Hash, Agent і Randomized Agent).
У продукті використаний оригінальний двигун працює на Layer 2 (Ethernet), балансування ведеться на основі IP-адреси клієнта, без урахування прив'язки до портів т. Е. Це може бути будь-який сервіс. Підтримує DNS GSLB (Global Server Load-Balancing) і конфігурацію сервера з прямим поверненням Direct Server Return (DSR). Містить настроюється агент перевірки UDP, підтримує VRRP для установки високо доступних конфігурацій на багатьох вузлах. Вбудовані механізми дозволяють провести захоплення і збереження пакетів за допомогою pcap для подальшого дослідження. Передбачено кілька варіантів перевірки працездатності кінцевих систем: агент, ping, TCP Open, скрипт і інші інструменти на зразок wget.
Можливо резервування балансувальника з реплікацією NAT станів між основним і резервним вузлів, Клієнт при перепідключенні підключається до того ж сервера. Для збереження сесії використовується IP-адреса клієнта і порт призначення. Підтримується Linux bonding. Всі таблиці зберігаються в ОЗП, але вимоги невеликі, для 4 мільйонів сесій достатньо 512 Мб пам'яті.
Може працювати в Linux (з використанням сокета API PF_PACKET) і SPARC / Intel Solaris (STREAMS / DLPI API). Для установки пропонується rpm (Red Hat RHEL6 / CentOS) і deb (Debian / Ubuntu) пакети і Тарбаев для інших дистрибутивів. Також доступний готовий образ для віртуальної машини (на базі Ubuntu 8.04), що дозволяє швидко розгорнути потрібну функціональність. Під час закачування будуть показані всі паролі для входу. Агент (bngagent) поставляється з відкритим вихідним кодом і підтримує Linux, Solaris, Mac OS-X, HP-UX та інші.
Будь-якої інтерфейс для налаштування не передбачений, все установки виробляються за допомогою конфігураційного файлу /etc/bng.conf. В принципі складним його назвати не можна, особливо враховуючи що на сайті проекту є більше десятка готових прикладів, часто потрібно лише вибрати найбільш підходящий і відредагувати під себе.

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

Конфігураційний файл BalanceNG

HAProxy

[HAProxy] (haproxy.1wt.eu) балансувальник навантаження і проксі-сервер рівня додатків Layer7 для TCP і HTTP. Власне проект починався, як дуже простий HTTP-проксі Webroute, але поступово обріс новими можливостями. Особливістю HAProxy є використання для регулювання з'єднань cookie і контенту, для вбудовує cookie і перевіряє вміст пакету при підключенні. Аналіз пакетів на Layer7 дозволяє фільтрувати несанкціонований трафік і протоколи. Перевіряючи HTTP запит за допомогою регулярних виразів можна задати будь-які правила для вибору сервера, наприклад реалізуючи ACL і геолокацію. У разі необхідності обробки IP клієнта на кінцевому сервер можемо зберегти його в "X-Forwarded-for". Движок стабільний, безпечний оптимізований, в результаті HAProxy здатний одночасно обробляти велику кількість підключень (20 000 в с і більше).
Обробкою всіх підключень займається один процес, за рахунок оптимізації і планувальника забезпечує велику кількість одночасних з'єднань на дуже високих швидкостях. Такі системи не дуже добре масштабуються на багатопроцесорних системах, але не хворіють блокуваннями і обмеженнями пам'яті. Але тут ми не побачимо просунутих функцій на зразок підтримки SSL і Keep-Alive, за твердженням розробників вони ускладнюють і «обтяжують» процес. Відмовостійкість HAProxy сервера забезпечується через використання демона keepalived перевіряючого його працездатність, синхронізація з резервним сервером (протокол VRRP) забезпечує дублювання.
Забезпечується логирование з'єднань і надання різноманітних звітів (статистика виводиться на окремому порту). Орієнтований в першу чергу для веб-сайтів, але використовується і в інших сценаріях, наприклад в якості балансувальника для multi-master серверів MySQL.

Орієнтований в першу чергу для веб-сайтів, але використовується і в інших сценаріях, наприклад в якості балансувальника для multi-master серверів MySQL

Статистика HAProxy

Підтримується фільтрація користувачів і підключення до того ж сервера (для RDP і HTTP), аутентифікація HTTP.
HAProxy як балансіровшіка використовується в декількох компаніях зі списку Fortune 500: Amazon RDS, Github, Stackoverflow, Serverfault, Twitter ...
Можливості розширюються за допомогою аддонов, їх повний список є на сайті. Всі настройки проводяться за допомогою конфігураційного файлу (на сайті є приклади). Крім того відомі два інтерфейси сторонніх розробників: комерційний веб [Snapt] (snapt.net) і вільний [HATop] (feurix.org/projects/hatop).
Працює на декількох архітектур x86, x86_64, Alpha, SPARC, MIPS, PARISC. Офіційно підтримує Linux 2.6.32+ (рекомендується для максимальної продуктивності) і 2.4, Solaris 8-10, FreeBSD, OpenBSD. Установка і настройка тривіальні, хоча пакети в репозиторіях не присутній. Проект пропонує вихідний код під ліцензією GPL v2 і готові бінарники під Linux / x86 Glibc 2.2 і Solaris8 / Sparc.

Веб-інтерфейс Snapt для настройки HAProxy

Pound - проксі і балансування HTTP і HTTPS

Початкова мета проекту [Pound] (apsis.ch/pound) було розподіл навантаження між декількома серверами Zope, в результаті вийшов вузькоспрямований інструмент, який представляє собою зворотний проксі і балансувальник навантаження для HTTP і HTTPS.
Балансування проводиться за станом сесії і іншим параметрам (URL, аутентифікації, cookies, HTTP headers). Повна підтримка WebDAV. На відміну від HAProxy обробляє SSL. Розроблено в IT компанії, що займається безпекою, що також позначилося на можливостях продукту. Особливістю є наявність базових функцій Web Application Firewall, Pound вміє контролювати коректність заголовків HTTP і HTTPS, відкидаючи неправильні. За замовчуванням пропускаються всі запити, але можна створити шаблони URL, і тип запитів (стандартні, розширені, RPC і WebDAV) які будуть перевірятися на відповідність. За результатами вибирається кінцевий сервер або з'єднання блокується. Дизайн спочатку передбачає мінімальне втручання в трафік (наприклад вбудовування cookie), але може прописувати "X-Forwarded-for" для передачі на бекенд сервера IP адреса користувача.
Підтримує IPv6, може перекидати IPv6 клієнтів до серверів IPv4. Інформація про сеанс зберігається і клієнт в подальшому підключається до свого облікового запису.
З специфіки - можлива не тільки відправлення з'єднання до бекенд, а й редирект на інший URL.
Pound не вимагає багато ресурсів, примітно що крім зчитування SSL сертифікатів чорт не звертається до хард. Може бути запущений в chroot і використовувати setuid / setgid. Будь-яких вбудованих механізмів відмовостійкості немає. Перевірка працездатності бекенд проводиться завжди по HTTP.
На процесорі рівня Pentium D дозволяє досягти приблизно 600-800 HTTP і 200-300 HTTPS з'єднань в секунду. Тому коник Pound невеликі проекти з упором на доступність, безпеку і більший контроль над трафіком. Для більшого навантаження самі розробники Pound рекомендують скористатися іншими рішеннями.
Установка і настройка не уявляють великих складнощів, хоча і виробляються за допомогою конфігураційних файлів (документація дуже докладна). Офіційно був протестований на Linux, Solaris і OpenBSD. Проект пропонує тільки початкові тексти, в репозитариях SuSE, Debian і Ubuntu, можна знайти готові пакети, окрім цього на сайті є посилання для RedHat і готового дистрибутива зібраного на базі FreeBSD.

Проект пропонує тільки початкові тексти, в репозитариях SuSE, Debian і Ubuntu, можна знайти готові пакети, окрім цього на сайті є посилання для RedHat і готового дистрибутива зібраного на базі FreeBSD

У файлі конфігурації Pound розібратися легко

Crossroads

Crossroads або [XR] (crossroads.e-tunity.com) забезпечує балансування навантаження до будь-яких TCP сервісів, тому підходить не тільки для HTTP (S), але і для SMTP, SSH, баз даних та інших. У звичайному варіанті він просто гарантує підключення до бекенд, не вникаючи у нутрощі, забезпечуючи в цьому режимі максимальну продуктивність. Один сервер може обслуговувати кілька сайтів з різними бекенда і протоколами. Але є спеціальний режим "HTTP mode" при якому обробляються і при необхідності змінюються заголовки сеансу. Це забезпечує можливість перенаправлення користувача на той же сервер (session stickiness) і збереження IP клієнта в X-Forwarded-For. Сам по собі "HTTP mode" і особливо модифікація пакета впливає на продуктивність (втрати до 30%).
За замовчуванням клієнт перенаправляється на сервер приймає менше підключень, але при необхідності алгоритм легко змінити на Round-Robin, Least-Connections і First-Available або визначатися зовнішньою програмою або скриптом. Клієнтів можна закріплювати за певним сервером (Hash sticky client), жорстко або з можливістю підключення до іншого сервера якщо «свій» не відповідає. При поновленні роботи бекенда, він автоматично включається в роботу. Можливо управління доступом до Crossroads на основі IP адреси ( "allow" і "deny").
У версії 2.х все підключення обслуговує один процес працює в просторі користувача, це позитивно позначилося на швидкості роботи і на управлінні. Може працювати як stand-alone демон або запускатися через inetd. Зручно, що всі налаштування і команди можна віддавати на льоту (за допомогою утиліти xr), зміна параметрів не вимагає перезапуску Crossroads. Наприклад, налаштуємо балансування для двох веб-сайтів і серверів MySQL.

# / Usr / sbin / xr --verbose -S --server http: 0: 80 --host-match www.host1.com --backend 192.168.1.10:80 --backend 192.168.1.20:80 \ --host -match www.host2.com --backend 192.168.2.10:80 --backend 192.168.2.20:80 2> & 1 >> /var/log/xr.log # / usr / sbin / xr --verbose --server tcp : 0: 3306 --backend 192.168.1.1:3306 --backend 192.168.1.2:3306 2> & 1 >> /var/log/xr.log &

Статистика виводиться за допомогою веб-інтерфейсу, порт якого задається разом з ключем -W (-web-interface). Також з його допомогою можна змінити три параметри: максимальна кількість з'єднань для Crossroads і бекенда, вага бекенда.
Для зручності всі їх записують в окремий файл який і вказують при завантаженні або використовують спеціальний конфігураційний файл у форматі xml (/etc/xrctl.xml, в постачанні кілька готових прикладів).
Може бути запущений на будь-який POSIX системі - Linux, Mac OS X, Solaris. Проект пропонує вихідні текст (збірка проблем не викликає), готові пакети доступні в репозитариях основних дистрибутивів.

Проект пропонує вихідні текст (збірка проблем не викликає), готові пакети доступні в репозитариях основних дистрибутивів

У постачання Crossroads кілька готових конфігураційних файлів

ZEN Load balancer

Рішення кілька відрізняється від інших учасників огляду. Розробники справедливо вирішили, що під балансування виділяється окремий сервер, а тому краще відразу надати готовий дистрибутив, щоб спростити розгортання, підвищити продуктивність і безпеку. Основою [ZEN Load balancer] (zenloadbalancer.org) є оптимізована і урізана версія Debian 6. Підтримується балансування на Layer 4 для протоколів TCP, UDP і на Layer 7 для HTTP / HTTPS. Спеціальний режим L4xNAT дозволяє налаштувати балансування на транспортному рівні без урахування номерів портів (фактично без прив'язки до сервісу), в цьому випадку ZEN просто пропускає через себе весь трафік, розподіляючи його по серверам. Якщо у Zen і фішка - режим DATALINK. В цьому випадку Zen виступає в якості шлюзу забезпечуючи рівномірне навантаження на канал і резервування при підключенні до декількох провайдерам (балансування на Layer 3).
Реалізовано кілька алгоритмів вибору бекенда Round Robin, по вазі (Weight), за пріоритетом (Priority) або підключення до певного сервера (Hash sticky client). Можливе повернення користувача в відкриту сесію, він визначається декількома способами (по IP-адресою,-файли, запитуваного URL, по заголовку HTTP). Передбачено збереження IP в X-Forwarded-For.
Технологія FarmGuardian дозволяє визначати доступність сервісів за допомогою спеціального скрипта, і розподіляти по ним підключення. Zen може виконувати роль SSL-проксі, шифруючи потік до клієнта, на ділянці Zen - бекенда дані йдуть в відкритому вигляді. Підтримується VLAN.
З інших особливостей можна назвати просту систему резервування та відновлення конфігурації, робота декількох балансувальник в кластері, система моніторингу і виведення різної статистики в тому числі і у вигляді наочних графіків.
І головне все настройки проводяться за допомогою веб-інтерфейсу (за замовчуванням на HTTPS / 444, логін / пароль - admin / admin). Пропонується дві версії. Безкоштовна тільки в x86 варіанті і без технічної підтримки. Її можливостей цілком вистачає для більшості мереж середнього розміру. Платна версія надається вже в x64 збірці. Розгорнути готову систему дуже просто, на сайті доступна вся необхідна інформація з налагодження (англійською).

Розгорнути готову систему дуже просто, на сайті доступна вся необхідна інформація з налагодження (англійською)

Всі настройки ZEN Load balancer виробляються через веб-інтерфейс

Хмарні сервіси для балансування навантаження

З ростом популярності Сонячно сервісів, все более систем розміщуються на зовнішніх майданчиках утворюючі гібрідні хмари. Більшість розробніків предлагает до Всього Іншого и можлівість балансування НАВАНТАЖЕННЯ, це дуже зручне так як НЕ требует от клієнта установки додатково обладнання и готово до! Застосування почти відразу. Хоча можливий по управлінню такий способ дает як правило менше. Всі основні гравці вже запропонували свої рішення. Наприклад, [Amazon Route 53] (aws.amazon.com/route53/) є частиною Amazon Web Services і надає балансування за допомогою Round Robin DNS. Вартість послуги невелика і складає 1 $ в місяць, плюс 0.50 $ за перший мільйон запитів і 0.25 $ за кожен наступний. Передбачено зручний API для редагування, додавання і видалення записів.
Також потрібна функціональність доступна в спеціалізованих хмарних продуктах - WAF або рішеннях для захисту від DDOS. Наприклад, сервіс [Akamai Global Traffic Management] (akamai.com/html/solutions/gtm.html).

Висновок

Вибирати є з чого. Кожен продукт має свої сильні і слабкі сторони, знаючи які легко визначитися який з них підходить для певної ситуації. Так HAProxy підкуповує продуктивністю, BalanceNG можливістю, простий в налаштуваннях Pound забезпечує розбирання HTTP, а Crossroads гнучкістю. Якщо все ж потрібен веб-інтерфейс то альтернативи ZEN Load balancer немає, ну якщо тільки не хочеться платити за Snapt для HAProxy.

З чого вибирати?
З чого вибирати?
Новости
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью