Вопрос

Мы несколько дней сражались с 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).

Это было полезно?

Решение

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

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

Другие советы

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

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

Да, вы можете использовать балансировщик нагрузки за пределами площадки ... и 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 для интеграции с автоматическим масштабированием таким же образом, как и правая шкала, любые комментарии приветствуются в блоге. Благодаря

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top