Щойно вивчав еластичні балансири навантаження. Наскільки я розумію, вони просто роблять кругообіг, рівномірно розподіляючи з'єднання із серверами за ними. Отже, що станеться, якщо за ELB у вас різні екземпляри? Чи надсилає вона більше підключень до більшого екземпляра чи продовжує рівномірно розподіляти з'єднання, це означає, що ви дійсно не повинні використовувати інстанції різного розміру.
Відповіді:
Наскільки я розумію, вони просто роблять кругообіг, рівномірно розподіляючи з'єднання із серверами за ними.
Начебто, але не зовсім я думаю - на жаль, документація щодо маршрутизації Amazon ELB не вистачає і не існує, тому для складання висновку потрібно зібрати деякі фрагменти. Ось єдиний фрагмент із Посібника для розробників Elastic Load Balancing, про який я знаю, див. Розділ Sticky Sessions ( Огляд еластичного балансування навантаження) :
За замовчуванням балансир навантажень спрямовує кожен запит незалежно до екземпляра програми з найменшим навантаженням . Однак ви можете використовувати функцію липкого сеансу (також відому як спорідненість сеансу), яка дозволяє балансиру навантаження зв’язувати сеанс користувача з конкретним екземпляром програми. Це гарантує, що всі запити, що надходять від користувача під час сеансу, будуть надіслані одному екземпляру програми. [акцент мій]
Тепер що саме означає найменше навантаження ? Знову ж таки, єдине мені відоме пояснення - дещо розпливчаста відповідь команди AWS з 2009 року на стратегію ELB :
ELB вільно відслідковує, скільки запитів (або підключень у випадку TCP) є невирішеними у кожному випадку. Він не контролює використання ресурсів (таких як процесор чи пам'ять) у кожному екземплярі. Наразі ELB буде кругоспроможним серед тих випадків, на які, як він вважає, має найменше невирішених запитів. [акцент мій]
Це має багато сенсу щодо їх системної архітектури та розглянутих випадків використання, але, очевидно, не забезпечує прозорість та / або контроль маршрутизації, які ви можете хотіти або потребувати для розширених сценаріїв HA.
Зауважте, що, залежно від інтерпретації, цьому може чи не суперечити нещодавня відповідь команди AWS на Еластичне балансування навантаження - Політика розподілу завантажень :
Раунд-робін дійсно вступає в гру, але клієнтські сесії не завжди вшановують кеші TTL або DNS, тому ви можете отримати перекошені результати і нерівномірний розподіл запитів. ELB не приймає до уваги те, що отримані інстанції трафіку / запитів прийнято у рішеннях про маршрутизацію трафіку. [акцент мій]
Звичайно, вищезазначене доповнюється належним чином задокументованим, прозорим та контрольованим контролем здоров’я , що дає певні важелі для (можливо, тимчасово) вилучення екземплярів з включення в маршрутизацію в першу чергу, як узагальнено у вищезгаданій відповіді команди AWS на ELB Стратегія також:
Балансир навантаження стежить за станом здоров’я ваших випадків, зареєстрованих вашим балансиром навантаження. Коли балансир навантаження виявить проблему з екземпляром, він припиняє розподіляти трафік до неї. Коли екземпляр знову здоровий, балансир навантаження перезавантажує розподіл трафіку до нього. Цей процес дозволяє вашій програмі автоматично реагувати на помилкові екземпляри, без того, щоб ви не були задіяні, крім налаштування перевірки здоров'я.
Хоча, звичайно, незвично, я не бачу, чому ELB також не повинен працювати з пулом різних типів екземплярів Amazon EC2 - я сам не пробував цього, хоча б рекомендував і те, і моніторинг вашого балансира завантаження за допомогою CloudWatch , а також моніторинг ваші окремі екземпляри EC2 і співвіднести результати, щоб згодом отримати відповідне розуміння та впевненість у подібних налаштуваннях.
На основі заяв, складених до цього часу, алгоритм розподілу надзвичайно простий.
Передній кінець ELB, як правило, більше, ніж один екземпляр ELB, а розподіл - круглооб'ємний.
Назад (для ваших примірників) альго стверджує, що:
ELB вільно відслідковує, скільки запитів (або підключень у випадку TCP) є невирішеними у кожному випадку. Він не контролює використання ресурсів (таких як процесор чи пам'ять) у кожному екземплярі. Наразі ELB буде кругоспроможним серед тих випадків, на які, як він вважає, має найменше невирішених запитів.
Це може зробити висновок, що якщо більший екземпляр має менше невирішених запитів, то більше трафіку буде спрямовано на них. Неможливо цього гарантувати.