Чи можна використовувати кілька балансирів навантаження для перенаправлення трафіку на мої сервери додатків?

Я новачок завантажую балансування, і мені цікаво, чи можна використовувати кілька балансирів навантаження для перенаправлення трафіку на мої сервери додатків. Я не дуже розумію, як це можна зробити. Чи не повинно доменне ім’я відповідати одному до одного з IP-адресою певного сервера (у цьому випадку IP одного балансира завантаження)? Якщо кожен сервер балансування навантаження має різну IP-адресу, то як запит можуть бути отримані обома балансирами навантаження (або 10 балансирами навантаження, або 50, або 100)?

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

Є й інші способи досягти цього.
1) Активні / пасивні балансири навантаження
В основному один балансир навантаження обробляє весь трафік за одну IP-адресу.
Якщо цей балансир опуститься, пасивний вузол заскакує і переймає IP.
Майте на увазі, що балансири навантажень в значній мірі лише перенаправляють трафік, тому для невеликих та середніх сайтів це може бути добре.

2) Активні / активні балансири навантажень
Один і той же IP-трафік налаштований на обох (або багатьох інших) балансирах навантаження.
Вхідний трафік надсилається всім балансирам навантажень, але алгоритм вибирає, який балансир повинен відповідати, а всі інші відкидають цей трафік.
Простий спосіб подумати про це, у вас є два балансири навантаження:
Коли запитуючий IP закінчується парним числом, тоді завантажує балансир відповіді, інакше завантажує балансир B.

Звичайно, ваша інфраструктура повинна підтримувати це, і є надмірні витрати через надходження трафіку, але його відкидають.
Більше інформації, наприклад тут: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

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

Існує велика кількість цих протоколів, які я бачив більшість із звичайними балансирами навантаження - це VRRP та NLB (а також безліч непрозорих протоколів чорного кольору в пристроях). Окрім розширення маршрутизаторів та брандмауерів, можна також зустріти, наприклад, CARP , HRSP , GLSP .

Ця стратегія має низку переваг у порівнянні з навантаженням DNS, що є більш простою стратегією (і про яку ми вирішуємо в іншій відповіді).

Балансування навантаження DNS обтяжується, наприклад:

• повільний оборот механізмів кешування dns
• алгоритми з обмеженим балансуванням навантаження (як правило, просто круговий)
• аутсорсинг рішення щодо балансування навантаження клієнту (через кешування запису dns)
• Повільне зливання службових черг, коли сервер (тобто балансир навантаження) виводиться з обертання (на основі запису TTL, записаного в dns, як обробляють провайдери та клієнти )
• Повільне відмовлення від несправності навантажувача

Використання віртуального протоколу ip для HA, наприклад, може мати вибір:

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

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

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

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

Давайте знайдемо додаток з подібним характером навантаження, наприклад, магазин журналів і додаток пошуку. Я знайшов одного .

Що вони хочуть:

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

Що вони спробували та дізналися про ELB:

1. Не працює, як очікувалося
2. Проблеми із затримкою через збільшення навантаження
3. Недостатньо спостереження
4. Занадто багато обмежень (кількість відкритих портів та протоколів)

Чому вони вибрали маршрут Route53:

1. "Круглий робін є досить базовим балансуванням навантаження, але він добре працює для нас з точки зору ефективності"
2. "Ми використовуємо переваги перевірок здоров'я на маршруті 53".
3. "Якщо з колектором виникла проблема, маршрут 53 автоматично виводить її з сервісу; наші клієнти не побачать жодного впливу".
4. Не потрібно попереднього розминки на маршруті 53

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

Цей конкретний приклад показує, що в деяких сценаріях (збирач журналів, сервіс рекламних оголошень або подібний) балансир навантаження є зайвим, і "рішення здоров'я DNS для перевірки здоров'я круглої лінії" робить свою роботу дуже добре.

Давайте подивимося, що AWS кажуть про перехід на DNS:

За допомогою DNS Failover Route 53 може виявити відключення вашого веб-сайту та перенаправити кінцевих користувачів на чергування або резервне копіювання вказаних вами місць. Маршрут 53 DNS Failover покладається на перевірки здоров’я - регулярно надсилаючи Інтернет-запити до ваших додатків кінцевими точками з різних місць по всьому світу, щоб визначити, чи є кожна кінцева точка вашої програми вгору чи вниз.

Ця техніка також робить ELB (не потрібен, лише на замітку) більш надійним, знову ж таки, він заснований на RR + Health Check:

Маршрут 53 DNS Failover обробляє всі ці сценарії відмов шляхом інтеграції з ELB за кадром. Після ввімкнення Маршрут 53 автоматично налаштовує та керує перевірками стану здоров'я для окремих вузлів ELB.

Давайте тепер подивимося, як це працює за сценою. Очевидне питання - як поводитися з кешуванням DNS:

Однак кешування DNS все ще може бути проблемою тут (див. Наш попередній пост, де висвітлюється проблема "довгого хвоста"), якщо TTL не дотримується всіма шарами між вашим клієнтом та маршрутом 53. Потім ви можете застосувати техніку "перебір кешу": відправити запит на унікальний домен

("http://<unique-id>.<your-domain>") 

і визначити ресурс підстановки

Record "*.<your-domain>" to match it.

Algolia представила "стратегію повторного використання клієнта", яка працює досить добре, якщо ваш клієнт (JS у вашому випадку) може впоратися з цим:

Ми закінчили реалізацію основної стратегії спроб у наших клієнтах API. Кожен клієнт API був розроблений для доступу до трьох різних машин. Три різні записи DNS представляли кожного користувача: USERIDID-1.algolia.io, USERID-2.algolia.io таUSERID-3.algolia.io. Наша перша реалізація полягала у тому, щоб випадковим чином вибрати один із записів, а потім повторити спробу з іншим у разі відмови.