Для этого я специально имею в виду запуск веб-сайтов в Windows, но это не относится к IIS. Иногда мы также запускаем Tomcat. Очевидно, что здесь есть много вариантов аппаратного и программного обеспечения, и есть много моментов, которые следует учитывать в мире Windows, например, липкие сеансы и состояния, которые иногда присущи веб-приложению.
Так что я ищу любой хороший опыт использования эффективных стратегий балансировки нагрузки, будь то аппаратное или программное обеспечение, и причины для оправдания связанных с этим бизнес-затрат.
Спасибо
Обновить:
В ответ на некоторые более глубокие вопросы от Пола я лично хотел бы найти балансировку нагрузки с наименьшей нагрузкой и определенно с аварийным переключением сеанса. Теперь с подобными вещами можно справиться с помощью чего-то вроде Memcached или чего-то подобного. Завершение SSL очень сильно зависит от того, идете ли вы по аппаратному или программному пути, но тогда я также могу ответить на свой вопрос.
Объемы могут быть любыми: от стартапа с планом до, как мы надеемся, экспоненциального роста без представления пользователям печально известного Fail Whale ...
В вопросе конкретно задается вопрос, какие стратегии балансировки нагрузки были эффективными для вас в прошлом для запуска веб-сайтов в Windows. Если предлагаемая вами стратегия - это аппаратная балансировка нагрузки, при которой завершение SSL-соединения происходит, например, в балансировщике нагрузки, и вы поясняете, почему это оказалось для вас хорошей стратегией, то это поможет ответить на мой вопрос. Прямо сейчас у меня просто недостаточно опыта работы с различными методами и альтернативами, отсюда и мой вопрос.
Как и упомянутые скеваны, балансировку нагрузки, безусловно, можно выполнить с помощью Windows NLB. Я предполагаю, что большинство интернет-магазинов Windows начинают именно так. А некоторые продолжают использовать его бесконечно.
Распространенное заблуждение, что NLB работает плохо, на самом деле неплохо с точки зрения производительности. NLB очень хорош для некоторых вещей, таких как приложения, которые относительно стабильны и не находятся в активной разработке. Если NLB начинает вас подводить, это проверка состояния, NLB в основном полностью игнорирует уровень приложения, поэтому в какой-то момент, когда один из ваших JVM или рабочих процессов IIS взорвется, NLB будет продолжать видеть, что сломанный сервер прослушивает , и продолжать успешно перенаправлять запросы к неработающему приложению на работающем сервере, это явно плохо.
Именно здесь начинают проявлять себя специализированные балансировщики веб-нагрузки. Практически все они поддерживают различные методы балансировки, от циклического перебора до минимального количества соединений и взвешенных версий обоих.
Возможность указать страницу проверки работоспособности для каждого приложения на каждом сервере обеспечивает новый уровень уверенности и позволяет балансировщикам нагрузки принимать более обоснованные решения. В зависимости от вашего приложения страница проверки работоспособности обычно должна быть специально создана. Мне нравится страница проверки работоспособности, чтобы быстро опросить сервер db, чтобы убедиться, что соединение db работает. Этот вызов должен быть очень дешевым, наш мастер БД предоставляет его, я думаю, что это «Выбрать 1», но я могу ошибаться. Если вызов завершается успешно, на тестовой странице отображается идентификатор сервера (мы также используем эту страницу, чтобы увидеть, на каком сервере мы застряли на фермах с активным закреплением). В любом случае, балансировщик нагрузки выполнит это несколько раз в минуту, а затем проанализирует файл ответов, если он не завершится неудачно, он останется в ротации. Если эта страница не работает по какой-либо причине, сервер удаляется из ротации. Это также удобно в ситуациях, когда люди, администрирующие веб-серверы, не имеют опыта / доступа к балансировщику нагрузки. Просто переименовав файл проверки работоспособности, они могут легко вывести сервер из ротации для развертывания или устранения неполадок. Большинство балансировщиков нагрузки также можно настроить с жалким сервером. Если проверка работоспособности не выполняется на всех узлах фермы, пользователи отправляются на другой сервер, содержащий (статическую) страницу обслуживания.
Завершение SSL на балансировщике нагрузки также может быть удобно. Некоторые балансировщики нагрузки не используют HTTPS для проверки работоспособности, поэтому в некоторых ситуациях разгрузка вашего SSL - это единственный способ воспользоваться всеми перечисленными выше классными функциями проверки работоспособности. Разгрузка вашего SSL также, очевидно, освобождает циклы ЦП веб-сервера для обслуживания сети, а не для шифрования / дешифрования, но для меня большие преимущества связаны с устранением неполадок и управлением SSL. В зависимости от вашей платформы и инструментов управлять сертификатом SSL на большой ферме серверов непросто (msdeploy не поддерживал его до последней версии). Установка сертификата на 2 балансировщика нагрузки обычно быстрее / проще, чем на 10+ серверах. Это также очень полезно при устранении неполадок, время от времени вы получаете эту супер причудливую проблему, когда вам нужно копаться на уровне пакетов и отслеживать то, что отправляется на веб-сервер. С выгруженным SSL весь этот трафик представлен в виде простого текста, и его намного легче анализировать. Примечание: это также означает, что сегмент сети между вашими балансировщиками нагрузки и вашими серверами должен быть безопасным.
Что касается аварийного переключения, я придерживаюсь мнения, что приложения должны разрабатываться так, чтобы не требовать «липких» сеансов, если только для этого нет очень веской причины. В мире .NET это обычно так же просто, как настроить приложение для отправки своего состояния сеанса на сервер sql на всех узлах и убедиться, что все объекты сеанса сериализуемы (вы получите большую большую ошибку при первом включении если нет). Когда вы работаете в этой конфигурации, вы можете работать на веб-серверах в любое время, не затрагивая пользователей, просто удалив сервер из ротации, внося изменения и возвращая его в ротацию. Поскольку все данные сеанса централизованно хранятся в SQL, не имеет значения, какой узел отвечает на запрос.
Что касается программного и аппаратного обеспечения и оправдания затрат, это немного сложнее. Если у вас есть бюджетный аппаратный балансир, то это неплохо. Очевидно, что аппаратное обеспечение выполняется быстрее, и, что более важно, поддержка, которую вы получаете от поставщиков оборудования, как правило, намного лучше. В наши дни программные балансировщики получают все больше и больше функций.
По большей части мой опыт работы с линиями F5-BigIP, Cisco Arrowpoint / CSS и Cisco ACS. Недавно я начал изучать маршрутизацию запросов приложений IIS7 (ARR) для моего консультационного клиента с ограниченным бюджетом. Если у вас есть запасное оборудование и лицензии на Windows, это ничего вам не стоит и выглядит достаточно полнофункциональным. Мне интересно посмотреть, как это сложится. Вы можете найти больше информации о ARR здесь.
Дайте мне знать, если вам нужна более конкретная информация
Я большой поклонник службы балансировки нагрузки Windows (WLBS). Я понимаю, что некоторые могут сказать, что это не задача обслуживания большого сайта, но каким-то образом Microsoft может заставить его работать для Microsoft.com, поэтому я склонен не соглашаться с этими утверждениями.
Думаю, вам придется еще немного дать определение «эффективному».
Какую балансировку нагрузки вы хотите сделать? Круговая, наименее загруженная, географическая балансировка нагрузки?
Насколько глубоко вы хотите углубиться в проверку пакетов (уровень 2/3 или уровень 7)?
Вам требуется переключение сеанса при отказе?
О каких объемах вы говорите?
Где вы хотите завершить SSL-завершение?
Возможны различные варианты - от простой балансировки нагрузки Windows до глобально распределенных избыточных массивов аппаратных балансировщиков нагрузки с ускорителями SSL. На «самый эффективный» нет лучшего ответа.
Мы предпочитаем аппаратный балансировщик нагрузки с резервным оборудованием. Мы также используем наш балансировщик нагрузки в качестве точки завершения SSL. Он не обрабатывает отработку отказа сеанса. Для этого он полагается на веб-сервер. Например, мы используем серверы Weblogic, настроенные для обработки аварийного переключения сеанса.
HAProxy. Супер надежный, безопасный и работает с большим количеством больших систем. на веб-странице содержится много информации о балансировке нагрузки в целом, и есть несколько компаний, которые предоставят вам системы под ключ, например Loadbalancer.org
Если вы дешевы и задача небольшая, есть небольшой, но эффективный балансировщик нагрузки Java под названием Distributor (Sourceforce - Distributor.shourceforce.com). Я администратор и разработчик - его легко настроить и запустить, он выполняет мониторинг внутреннего сервера. а также аварийное переключение, а также возобновление работы после восстановления сервера.
Попробуйте и скажите, что вы думаете!
Конечно, это не аппаратный баланс нагрузки, если у вас миллионы обращений в час, это не для вас !!!!
Павел