Балансировка нагрузки в Amazon EC2? - PullRequest
46 голосов
/ 04 ноября 2008

Мы боролись с HAProxy уже несколько дней в Amazon EC2; опыт пока был замечательным, но мы застряли на том, чтобы выжать из программного балансировщика нагрузки больше производительности. Мы не совсем сетевики Linux (мы, как правило, являемся магазином .NET), но мы до сих пор придерживались своих собственных правил, пытаясь установить надлежащие ограничения, проверяя сообщения ядра и tcpdumps на предмет любых нарушений. Тем не менее, пока мы достигли плато около 1700 запросов в секунду, и к этому моменту время ожидания клиента значительно (мы использовали и настраивали httperf для этой цели). Мы с коллегой слушали самый последний подкаст Stack Overflow, в котором основатели Reddit отмечают, что весь их сайт работает на одном узле HAProxy и что до сих пор он не стал узким местом. Ack! Либо как-то не видно столько одновременных запросов, мы делаем что-то ужасно неправильное, либо общая природа EC2 ограничивает сетевой стек экземпляра Ec2 (мы используем большой тип экземпляра). Учитывая тот факт, что Джоэл и основатели Reddit согласны с тем, что сеть, скорее всего, будет ограничивающим фактором, возможно ли, что это ограничение мы видим?

Любые мысли с благодарностью!

Редактировать Похоже, что на самом деле проблема была не с узлом балансировки нагрузки! В данном случае виновником были узлы, на которых выполнялся httperf. Поскольку httperf создает и разбирает сокет для каждого запроса, он тратит значительное количество процессорного времени в ядре. Когда мы увеличили частоту запросов, TCP FIN TTL (по умолчанию равный 60 с) слишком долго хранил сокеты, а значение по умолчанию для ip_local_port_range было слишком низким для этого сценария использования. По сути, после нескольких минут, когда клиентский узел (httperf) постоянно создает и уничтожает новые сокеты, количество неиспользуемых портов заканчивается, и последующие «запросы» ошибаются на этом этапе, что приводит к низким числам запросов / сек и большому количеству ошибок.

Мы также рассмотрели nginx, но мы работали с RighScale, и у них есть скрипты для HAProxy. О, и у нас слишком сжатые сроки [конечно], чтобы отключать компоненты, если это не окажется абсолютно необходимым. К счастью, нахождение в AWS позволяет нам протестировать другую настройку, используя nginx параллельно (если это гарантировано), и сделать переключение на ночь позже.

Эта страница довольно хорошо описывает каждую из переменных sysctl (в этом случае были настроены ip_local_port_range и tcp_fin_timeout).

Ответы [ 5 ]

20 голосов
/ 18 мая 2009

Не отвечая на вопрос напрямую, но EC2 теперь поддерживает балансировку нагрузки с помощью Elastic Load Balancing вместо использования собственного балансировщика нагрузки в экземпляре EC2.

РЕДАКТИРОВАТЬ: Сервис Amazon Route 53 DNS теперь позволяет указать домен верхнего уровня на ELB с записью "псевдонима". Поскольку Amazon знает текущий IP-адрес ELB, он может вернуть запись A для этого текущего IP-адреса, вместо того чтобы использовать запись CNAME, при этом время от времени он может свободно изменять IP-адрес.

9 голосов
/ 04 ноября 2008

Не совсем ответ на ваш вопрос, но nginx и фунт имеют хорошую репутацию в качестве балансировщиков нагрузки. Wordpress просто переключился на nginx с хорошими результатами.

Но, более конкретно, для устранения вашей проблемы. Если вы не видите 100% использования процессора (включая ожидание ввода / вывода), то вы привязаны к сети, да. EC2 внутренне использует гигабитную сеть, попробуйте использовать экземпляр XL, чтобы у вас было базовое оборудование, и вам не нужно использовать этот гигабитный сетевой порт совместно

3 голосов
/ 03 октября 2010

Да, вы могли бы использовать балансировщик нагрузки за пределами площадки .. и на голом металле LVS - отличный выбор, но ваша задержка будет ужасной! Ходят слухи, что Amazon собирается исправить проблему с CNAME. Однако маловероятно, что они добавят https, undepth или пользовательские проверки работоспособности, агентов обратной связи, сопоставление URL-адресов, вставку файлов cookie (и некоторые люди с хорошей архитектурой тоже скажут, что это правильно). Однако именно поэтому Scalr, RightScale и другие используют HAProxy, как правило, два из их за круглой записью DNS робина. Здесь, на Loadbalancer.org, мы как раз собираемся запустить нашу собственную систему балансировки нагрузки EC2: http://blog.loadbalancer.org/ec2-load-balancer-appliance-rocks-and-its-free-for-now-anyway/ Мы планируем использовать сценарии SSH для интеграции с автоматическим масштабированием таким же образом, как и правая шкала, любые комментарии приветствуются в блоге. Спасибо

1 голос
/ 05 ноября 2008

Я бы посмотрел на переключение на балансировщик нагрузки за пределами площадки, а не в облако, и запустил бы что-то вроде IPVS поверх него. [Причина, по которой это происходит вне облака Amazon, связана с ядром]. Если Amazon не ограничивает исходные IP-адреса пакетов, выходящих из, вы можете использовать однонаправленный механизм балансировки нагрузки. Мы делаем что-то вроде этого и получаем около 800 000 одновременных запросов [хотя мы не имеем дело с задержкой]. Я также сказал бы, что используйте «ab2» (apache bench), так как он немного более удобен для пользователя и проще в использовании по моему скромному мнению.

0 голосов
/ 18 ноября 2014

Даже если ваша проблема решена. KEMP Technologies теперь имеет полностью продвинутый балансировщик нагрузки для AWS Могу избавить вас от хлопот.

...