Балансировка нагрузки в Amazon EC2?

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

Любые мысли очень ценятся!

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

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

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

Ответ 1

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

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

Ответ 2

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

EDIT: Amazon Route 53 Служба DNS теперь предлагает способ указать домен верхнего уровня в ELB с записью "alias". Поскольку Amazon знает текущий IP-адрес ELB, он может вернуть запись A для этого текущего IP-адреса, вместо того, чтобы использовать запись CNAME, хотя время от времени можно изменять IP-адрес.

Ответ 3

Да, вы можете использовать балансировщик нагрузки за пределами площадки.. и на голом металле LVS - отличный выбор, но ваша латентность будет ужасной! Ходят слухи, что Amazon собирается исправить проблему CNAME. Однако вряд ли они добавят https, indepth или пользовательские проверки работоспособности, агенты обратной связи, сопоставление 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-скрипты для межсетевого обмена с автомасштабированием, так же как и правкале, любые комментарии, оцененные в блоге. Благодаря

Ответ 4

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

Ответ 5

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