Существует множество различных систем для балансировки нагрузки и достижения избыточности на производственных серверах (не только на веб-серверах).
Если вы используете один из этих (или других) в производстве, какой? Насколько хорошо это работает для вас? Вы оценили других?
HAProxy - превосходный программный балансировщик нагрузки; легко настраивается, настраивается и чрезвычайно эффективен (он может насыщать сетевой адаптер 10 Гбит).
Основные функции, которые делают HAProxy подходящим для нас:
Единственное, что раздражает HAProxy, это файл конфигурации. Нет никакого удобного способа программного изменения конфигурации сервера, и есть кривая обучения для понимания различных параметров.
Я использовал LVS и обнаружил, что это очень малое обслуживание после установки. На стороннем проекте я попробовал haproxy для сайта, где я просто балансировал 3 веб-сервера. Работал как шарм и был очень прост в настройке - рекомендуется.
Добавить Ultramonkey в список.
Мы только используем DB для избыточности, Oracle Dataguard работает хорошо, но его сложно настроить.
Для наших процессов apache мы используем (d): http://www.f5.com/products/big-ip/ Это похоже на отраслевой стандарт. Думаю, все сводится к тому, сколько вы платите, и что вы балансируете на балансе.
например. Websphere можно сделать:
большой ip → Apache 1 → WebSphere 1
большой ip → Apache 2 → WebSphere 2
или вы можете пересечь его:
большой ip → Apache 1 → WebSphere 1 и 2 (round robin)
большой ip → Apache 2 → WebSphere 2 и 1 (round robin)
Мы использовали последний, и он работал отлично. Следите за сценарием, когда один хост выходит из строя: в большинстве случаев вы потеряете этот запрос, если он просто отключится.
Mark Imbriaco of 37signals создал короткий скринкаст, демонстрирующий, как его компания использует HAproxy для балансировки нагрузки Rails:
Я использовал один из low-end Coyote Point для балансировки нагрузки для небольшого веб-сайта. Я нашел установку интуитивно понятной и стабильной и простой в использовании.
Я считаю, что их продукт - хороший интерфейс веб-интерфейса для BSD relayd, ранее hoststated.
В ретроспективе мне жаль, что я не купил продукт от среднего до высокого, поэтому я мог использовать балансировщик нагрузки в качестве конечной точки SSL и сэкономить деньги на сертификатах.
Мы используем E250si coyotepoint.
Причины, по которым мы выбрали этот конкретный loadbalancer
Одна из вещей, которые нужно добавить, состоит в том, что даже если у loadbalancer есть только четыре физических порта, вы можете включить больше портов, подключив коммутатор к одному из ваших физических портов - и тем самым расширяя
Там не так много сказать об этом loadbalancer. Это было хорошо для нас и работает без перезагрузки и любых проблем в течение 10 месяцев или около того. Всякий раз, когда сервер терпел неудачу, он был немедленно снят с вращения. Не столько я могу жаловаться.
Изначально было несколько вещей, чтобы привыкнуть, и если бы мне пришлось думать о слабых местах, только два приходят на ум:
В общем, E250si сохранил нам всю конфигурацию и поддерживает другой сервер и т.д. Но так как я слышал много хорошего о HAproxy и фунтах, мы, скорее всего, рано или поздно перейдем в этом направлении. Если я поеду на программный маршрут, я буду очень придирчив после того, как компоненты, которые я разместил на сервере, - например, материнская плата, сетевые карты и т.д.
Мы используем keepalived поверх LVS. Простое добавление серверов и поддержка серверов с избыточной нагрузкой.
Я использовал F5 бидипсов на нескольких рабочих местах, в дополнение к обычным аппаратным средствам балансировки нагрузки я особенно люблю irules, которые действительно предлагают отличную гибкость перезаписи
в основном это событие script language
http://devcentral.f5.com/Default.aspx?tabid=75
есть wiki, но вам нужно создать учетную запись для доступа -
HAProxy (loadbalancing) + Pound (SSL termnation) + keepalived (VRRP для резервного резервного балансира)
Круглый DNS-сервер даст вам балансировку нагрузки, но не избыточность. Если один из ваших серверов выходит из строя, он по-прежнему будет поражен своей долей запросов.
Мы используем Apache mod_jk для обработки балансировки нагрузки и избыточности между парами серверов приложений Java. Это работает очень хорошо, и это просто.
У нас также есть сервер Apache с отказоустойчивым отказом, если первичный сбой. В идеале мы использовали бы что-то Linux-HA для достижения горячего перехода на апач, но мы не уверены, можем ли мы оправдать сложность.
Отдел UCLA использует Juniper Acceleration Platform, и они очень довольны этим. Это касается решения SSL-шифрования, и мальчик, основанный на оборудовании SSL, намного быстрее! В настоящее время они перенаправляют больше своих услуг для работы с ним.
Что круто:
Это не дешево, но очень эффективно для компаний с огромным количеством трафика. См. Спецификации для выбора UCLA здесь.
В настоящее время мы используем балансировщик нагрузки Zeuz ZXTM и до сих пор довольны им. Однако наш хостинг-провайдер изначально настроил его на виртуальной машине поверх машины, на которой работают службы брандмауэра. Оказалось, что это была довольно глупая ошибка, поскольку связи стали насыщенными задолго до того, как трафик должен был стать проблемой. После того, как он перешел в собственный выделенный ящик, мы смогли без проблем выполнить пробный трафик 100 Мб/с (на 4 Гбит/с с разрывающейся интернет-трубкой).
Мы используем HAProxy с большим успехом. Я никогда не видел, чтобы это превысило 2% использования ЦП даже во время средней нагрузки.
Круглый Робин с липкими сеансами - это то, что я считаю используемым. У нас должен быть параметр, чтобы информация сеанса ASP/ASP.Net сохранялась, чтобы пользователь придерживался одного сервера, на котором есть сеанс.
У нас была небольшая проблема, связанная с переходом с http на SSL, где наш сайт отправил пользователей, прошедших проверку подлинности, на незащищенную страницу, и пользователи, не прошедшие проверку подлинности, будут отправлены на безопасную страницу входа, которая была бы странной, но она делала в конце концов, был определен смысл, который был разрешен посредством завершения SSL для лучшего решения, кроме как вернуться к одному серверу, который был немедленным решением.
Возможно, наступит время, когда потребуется определить что-то более сложное, чтобы определить, какой сервер является "наименее занятым", и отправить следующий запрос на эту машину, но я не уверен, как ребята инфраструктуры получат эту функциональность балансиров нагрузки.