Як балансири навантажень вписуються в центр обробки даних із значно більшою пропускною здатністю, ніж вони впораються?

10

У вас є центр обробки даних, стандартизований на 10GE-з'єднаннях. Скажімо, Nexus 7000s в ядрі, Nexus 5000 з агрегацією, а також деякі розширювачі тканини для краю до серверів (я використовую передачу Cisco як приклади, оскільки це те, що в моїй конкретній лабораторії). Існує кілька балансирів навантаження ACE 4710, які висіли з вашого Nexus 5000, але вони мають лише 1GE інтерфейси. Всі ваші комутаційні з'єднання є 10GE, необхідними для масового руху схід-захід (VM-VM) у сучасних віртуалізованих центрах обробки даних.

Хіба балансові навантаження не стають вузьким місцем у певних умовах руху? Я бачу, як деякий локальний трафік на схід-захід навіть не повинен досягти балансира навантаження, але є й інші ситуації, коли вам потрібно пройти ядро і, можливо, навіть з'єднати центр обробки даних.

В основному, я знаю, що балансири навантажень використовуються в трафіку клієнт-сервер (північ-південь), і такі речі, як HTTP GET, не потребують 10GE, але чи є ситуації, коли ваш балансир навантаження 1GE може перешкоджати інакше все- Шлях трафіку 10GE та спричинить проблеми для таких речей, як vMotion (наприклад)?

load-balancer

— дозорний
джерело

1

ACE 4710 був EOL / EOS з 2010 року. Ви прив'язані до цього балансира навантаження, або ви готові використовувати сучасний балансир навантаження, який може набирати значно більше? (Багато виробників виготовляють їх.) Немає причин штучно розміщувати обмеження на пропускну здатність способом, який ви описуєте. Ну, без причин поза витратами, але якщо ви купили інфраструктуру, яку ви описуєте, у вас, швидше за все, залишиться готівка для налаштування реального балансира навантаження.

— Бретт Лікінс

Це насправді не виробниче середовище, а власне «лабораторний» сценарій, який містить саме ці пристрої. У більш загальному сенсі моє запитання полягає в тому, що, враховуючи навантаження на трафік типового центру обробки даних, як ви забезпечите, щоб балансир навантажень не став вузьким місцем у вашій конструкції? Це відповідає вашому дизайну, як, наприклад, якщо ваш центр обробки даних багатоярусний, на якому ярусі ви завантажуєте балансування тощо. У моєму конкретному прикладі, який я не можу змінити, оскільки це не мій дизайн, чи має сенс їх мати Пристрої ACE одноруко вимикають Nexus 5000, які є набагато потужнішими.

— дозорний

6

Хіба балансові навантаження не стають вузьким місцем у певних умовах руху?

Звичайно, але це не так у добре розробленій мережі.

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

Хоча часто балансир навантаження є шлюзом за замовчуванням для серверів, що знаходяться за ним, я бачив налаштування, де протокол маршрутизації (тобто OSPF або RIP) запускається, щоб дозволити трафіку "схід-захід" обійти балансир навантаження або в менших розміщеннях де використовувались статичні маршрути.

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

— YLearn
джерело

4

Справді. Якщо у вашому шляху vMotion є LB, ви не працювали як інженер.

— Рікі Бім

"... існують способи врівноваження навантаження і через кілька балансирів навантаження", - наприклад, вибір балансира навантаження в мережі з DNS?

— Андрій Ронеа

2

Це дійсно вузьке місце і обмежить вашу пропускну спроможність до "найслабшого ланцюга в ланцюжку", який є вашими LB. Однак можна обійти його. Якщо ви використовуєте щось, відоме як "переключення" або "пряме повернення сервера", ви можете виконувати асинхронні потоки трафіку. Це працює так:

а) клієнт звертається із запитом http до 2.2.2.2

б) LB відповідає на 2.2.2.2 і передає вхідний запит серверу - оскільки LB і сервер знаходяться в одній локальній мережі, це робиться на рівні 2.

в) Сервер приймає це вхідне з'єднання, оскільки IP 2.2.2.2 знаходиться на інседованому інтерфейсі зворотного зв'язку (інакше він випаде пакетом, який не відповідає інтерфейсу).

г) Сервер відповідає безпосередньо клієнту.

Запит - кілька байт. Наданий вміст може бути будь-якого розміру. Вихідний трафік не проходить через LB, тому ви можете обробляти НАДЕЖНІЙ трафік.

Ура,

--tc

— Томас Кеннон
джерело

1

Майте на увазі, що це підходить лише для кластерів L4. Для кластерів L7 це порушить перезапис заголовків, вставлення файлів cookie (збереження), завершення SSL, будь-яке відповідність URL-адрес та будь-які інші більш вдосконалені функції багатьох залишків завантаження.

— YLearn