Как распределители нагрузки вписываются в центр обработки данных с гораздо более высокой пропускной способностью, чем они могут обрабатывать?

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

Разве балансировщики нагрузки не становятся узким местом в определенных условиях движения? Я могу видеть, как некоторому локальному трафику восток-запад даже не нужно достигать балансировщика нагрузки, но есть другие ситуации, когда вам нужно пересечь ядро ​​и, возможно, даже соединить центр обработки данных.

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

Разве балансировщики нагрузки не становятся узким местом в определенных условиях движения?

Конечно, но это обычно не так в хорошо спроектированной сети.

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

Хотя часто балансировщик нагрузки является шлюзом по умолчанию для серверов, стоящих за ним, я видел установки, где используется протокол маршрутизации (т.е. OSPF или RIP), позволяющий трафику «восток-запад» обходить балансировщик нагрузки, или в небольших развертываниях. где использовались статические маршруты.

Если балансировщики нагрузки будут узким местом даже при хорошем дизайне (т. Е. Объем трафика настолько высок), то есть также способы балансировки нагрузки между несколькими балансировщиками нагрузки.

Это действительно узкое место и ограничит вашу пропускную способность "самым слабым звеном в цепочке", которым являются ваши LB. Тем не менее, вы можете обойти это. Если вы используете что-то, известное как «switchback» или «direct server return», вы можете выполнять асинхронные потоки трафика. Вот как это работает:

а) клиент делает http запрос к 2.2.2.2

b) LB отвечает по 2.2.2.2 и передает входящий запрос на сервер - поскольку LB и сервер находятся в одной локальной сети, это делается на уровне 2.

c) Сервер принимает это входящее соединение, так как IP 2.2.2.2 находится на псевдонимном интерфейсе обратной связи (в противном случае он отбросит пакет, который не соответствует интерфейсу).

г) Сервер отвечает непосредственно клиенту.

Запрос составляет несколько байтов. Контент может быть любого размера. Исходящий трафик не проходит через LB, поэтому вы можете обрабатывать ПУТЬ больше трафика.

Ура,

--tc