Опыт использования программной балансировки нагрузки или аппаратного балансировщика нагрузки?

Question

Приложение ASP.NET, за которое я в настоящее время отвечаю на своей повседневной работе, достигло предела с точки зрения возможности масштабирования внутри одного сервера. Очевидно, мы работаем над тем, чтобы вывести сессию из процесса и провести тестирование, и, надеюсь, приблизим дату. Я хотел бы опираться на опыт людей, использующих встроенную балансировку нагрузки в Windows, по сравнению с решением для таких устройств, как Baracudda, Coyote Point, F5 и т. Д. Вы начали с одного и перешли на другой и почему?

мысли и советы оценены заранее ...

Answer 1

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

С точки зрения решений, с которыми я столкнулся:

Встроенная балансировка нагрузки в окнах хорошо работает в большинстве случаев, хотя вы должны убедиться, что ваши приложения могут правильно обрабатывать сеансы, если они не привязаны. и т.д.

Я использовал продукты F5, главным образом, в качестве решения для кэширования, однако они были слишком сложными для нас. В настоящее время мы удаляем их, поскольку разработчики не использовали их правильно, поскольку они были слишком сложными. (Обратите внимание, что это были довольно старые продукты F5.)

В настоящее время мы тестируем аппаратные балансировщики нагрузки от Foundry, и, вероятно, мы пойдем с ними, поскольку они хорошо вписываются в нашу сетевую архитектуру. (Что довольно сложно.).

Так что я бы сказал, если вы хотите простое решение, используйте балансировку нагрузки в Windows (если ваши приложения будут работать правильно.).

Если не использовать что-то более сложное.

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

Answer 2

настроить кластер apache mod_proxy. http://www.howtoforge.com/high_availability_loadbalanced_apache_cluster

легче, чем вы думаете, и на долю цены

Answer 3

некоторые мысли

• WLBS часто "достаточно хорош", чтобы начать работу с NLB. Однако, как любой великий инженер - вам нужно «измерить, чтобы знать»
• это не только увеличение масштабов, но и мягкое или жесткое резервирование. Мы часто выполняем NLB между виртуальными машинами, просто чтобы обеспечить мягкое резервирование.
• NLB в равной степени применяется как к базовым, так и к внешним сетям
• переход на аппаратное ускорение дает вам новый уровень затрат на эксплуатацию. Новая учебная специализированная поддержка, эскалация и т. Д.
• ищите аппаратное ускорение, чтобы дать вам намного больше, чем NLB, например Защита от DDoS, SSL, сжатие, кэширование, переключение контента, агрегация соединений, буферизация.
• Расскажите обо всех преимуществах аппаратного ускорения Devs & Ops SE: отличный дизайн может объединить грань между сетевыми операциями и разработкой приложений.
• аппаратная буферизация сама по себе сделала ASP.NET примерно на 30% быстрее, просто сократив время GC.
• переключение контента может позволить вам прозрачно объединять или переносить разрозненные системы. Используя эту технику, мы объединили платформы MSDN и MSDN2 в единое пространство URL.
• липкость сеанса - это палка о двух концах - используйте осторожно - опять же, не замените хорошую технику - измерьте и проверьте

Мы используем как WLBS, так и NLB в нашей сети - стоимость часто ведет к разговору. Относитесь к обоим инструментам в наборе инструментов, изучайте их нюансы, модели стоимости и т. Д.

Answer 4

F5 поставляется с чипом ускорения SSL. Шифрование и дешифрование SSL (оно сильно загружает процессор) с помощью серверов приложений замедляет обработку реальных запросов. Обычно трафик SSL завершается на F5, а нормальный http-трафик отправляется на серверы приложений. Это называется SSL Offloading на балансировщике нагрузки. Sinces F5 выполняет шифрование и дешифрование SSL с использованием микросхемы (аппаратное обеспечение), что в 30-40 раз быстрее, чем обычное время шифрования и дешифрования.