Современные балансировщики нагрузки обладают очень высокой пропускной способностью (гигабит). Так что, если вы не работаете с огромным сайтом (например, Google), добавление пропускной способности не является причиной, по которой вам понадобится новая пара балансировщиков нагрузки, тем более что большинство крупных сайтов разгружают большую часть своей пропускной способности на CDN (сети доставки контента), такие как Akamai. Если вы прокачиваете гигабит данных, не поддерживающих CDN, через свой сайт и еще не имеете глобальной стратегии балансировки нагрузки, у вас есть проблемы посерьезнее, чем сходство кеша. :-)
Вместо ограничения пропускной способности сайты, как правило, добавляют дополнительные пары LB для географического распределения серверов в отдельных центрах обработки данных, чтобы пользователи, разбросанные по всему миру, могли общаться с ближайшим к ним сервером.
Для этого последнего сценария компании, занимающиеся балансировкой нагрузки, предлагают решения для геолокации, которые (по крайней мере, до нескольких лет назад, когда я следил за этим материалом) были основаны на пользовательских реализациях DNS, которые смотрели на клиентские IP-адреса и разрешались в пары балансировщика нагрузки. Виртуальный IP-адрес, который является «ближайшим» (по сетевой топологии или производительности) к клиенту. В наши дни CDN, такие как Akamai, также предлагают глобальные услуги балансировки нагрузки (например, http://www.akamai.com/html/technology/products/gtm.html). Хостинг Amazon EC2 также поддерживает такую функцию для размещенных там сайтов (см. http://aws.amazon.com/elasticloadbalancing /).
Поскольку пользователи, как правило, не перемещаются между континентами в течение одного сеанса, вы автоматически получаете сходство (или «прилипание») с географической балансировкой нагрузки, предполагая, что ваши пары расположены в разных центрах обработки данных.
Имейте в виду, что определение географического местоположения очень сложно, так как вам также необходимо определить географическое местоположение ваших данных, чтобы убедиться, что ваша внутренняя сеть между центрами обработки данных не перегружена.
Я подозреваю, что F5 и другие поставщики также предлагают решения для одного центра обработки данных, которые достигают тех же целей, если вы действительно беспокоит единая точка отказа сетевой инфраструктуры (маршрутизаторы и т. д.) внутри вашего центра обработки данных. Но поставщики маршрутизаторов и коммутаторов предлагают решения высокой доступности, которые могут быть более подходящими для решения этой проблемы.
Нет-нет, на вашем месте я бы не беспокоился о нескольких парах балансировщиков нагрузки. Получите одну пару и, если у вас нет много денег и времени на проектирование, сотрудничайте с хостером, который хорошо поддерживает работу сети своего центра обработки данных.
Тем не менее, если сходство кеша настолько важно для вашего приложения, что вы думаете о том, чтобы выложить большие $$$ для нескольких пар балансировщиков нагрузки, возможно, стоит рассмотреть некоторые изменения архитектуры приложения (например, использование внешнего кэширующего кластера). . Такие решения, как memcached (для Linux), предназначены для этого сценария. У Microsoft также есть один, который называется «Velocity.
В любом случае, надеюсь, что это полезная информация — по общему признанию, прошло некоторое время с тех пор, как я был глубоко вовлечен в эту область (я был частью команды, которая разработала продукт для балансировки нагрузки приложений для крупного поставщика программного обеспечения), так что вы можете удвоить - проверьте мои предположения выше с фактами, которые вы можете получить в Интернете от F5 и других поставщиков LB.
person
Justin Grant
schedule
25.09.2009
