Назад | Перейти на главную страницу

балансировка нагрузки, высокая доступность для настройки веб-приложений

Мы создали специальную социальную сеть, и теперь нам нужно настроить правильную настройку сервера для серверов веб-приложений.

У нас есть для физического сервера webapp 5 доступны (2xE5645 CPU, 24 GB Ram, RAID, 4x Gbit NIC), один из пяти серверов, необходимых для предоставления API нашим мобильным посетителям (iOS, Android). Нашему веб-приложению нужны PHP, APC, Memcached и MySQL.

Также у нас есть еще 4 физических сервера (2xE5620, 12 ГБ RAM, RAID, 4x Gbit NIC):

Для начала мы хотим иметь только сервер веб-приложений в LB / HA, потому что на данный момент у нас нет других доступных серверов.

И, наконец, недорогой сервер (X3430, 4 ГБ ОЗУ, RAID, сетевая карта 2 Гбит), который используется для мониторинга всего оборудования.

У нас есть два управляемых коммутатора HP Procurve 2900 на 48 портов Гбит.
Все перечисленное оборудование остается в нашей стойке в сетевом центре. Мы используем RHEL 6 на всех серверах.

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

Мое направление - установить прокси-сервер HA и веб-сервер Apache на двух ящиках, иметь на двух ящиках сервер MySQL DB, а на одном - Apache и MySQL для API / Webservice. Использовать один из коммутаторов для частной сети, где все серверы будут подключены и использоваться для внутренней связи (MySQL, передача файлов после загрузки).

Полезно ли подключать к коммутатору несколько портов NIC на каждом сервере?

HA Proxy - лучший вариант для нашего случая? Или было бы лучше использовать nginx на 2 или 3 блоках и использовать его для балансировки нагрузки и обслуживания PHP и иметь LVS или что-то подобное для части HA?

Я открыт для всех решений, и сервер 5 + 1 можно использовать гибко.

Спасибо за любую помощь.

ОБНОВИТЬ: После дополнительных исследований я думаю, что будет сложно найти решение, позволяющее обеспечить высокую доступность для всех серверов. Моя настоящая идея для установки:

nginx в качестве прокси для балансировки нагрузки (я буду использовать один из блоков средней спецификации)
3 Веб-сервер Apache в частной сети
2 MySQL Server Master / Slave в частной сети

В приведенном выше решении веб-сервер Apache также будет размещать сайт SSL для выплаты, я не уверен, может ли nginx обрабатывать сертификат SSL для этих разных внутренних серверов.

ОБНОВЛЕНИЕ 2: У меня есть дополнительные исследования, Redhat предлагает надстройку для балансировки нагрузки на основе LVS. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtual_Server_Administration/ch-lvs-overview-VSA.html Этот аддон выглядит хорошо, НО я все еще не знаю, какой вариант правильный? Лучше пойти с nginx впереди или с LVS или чем-то другим? Кто-то сказал мне, что я могу использовать существующий коммутатор HP Procurve 2900 для простого распределения нагрузки ...

LVS разработан для балансировки нагрузки уровня 4. nginx или ha прокси используются только для балансировки нагрузки уровня 7 (я имею в виду веб-трафик). Таким образом, я хотел бы предложить вам использовать прокси-сервер nginx или HA в качестве балансировщика нагрузки, если веб-трафик является вашей самой большой рабочей нагрузкой. Если максимальное количество одновременных подключений является вашим узким местом, я рекомендую вам использовать прокси-сервер HA в качестве балансировщика нагрузки, поскольку прокси-сервер HA имеет лучшую производительность (см.http://affectioncode.wordpress.com/2008/06/11/comparing-nginx-and-haproxy-for-web-applications/).

HA для веб-приложения СЛЕДУЕТ разрабатывать с самого начала. Хотел бы я когда-нибудь увидеть это :)

А если серьезно: вы просите активную / активную настройку. Наиболее важные вопросы при выборе такой архитектуры - это то, как данные приложения должны или не должны, могут или не могут быть синхронизированы между серверами приложений. Кроме того, НАСКОЛЬКО синхронным это должно быть, есть ли код, который ожидает, что изменение будет глобально распределено перед возвратом, есть ли в приложении области, которые могут справиться с задержкой состояния на пару секунд, но не более (не забывайте, что репликация mysql - это второго типа!)? Эти потребности и возможности будут определять вашу настройку. Аппаратное масштабирование появится позже. А active / active всегда сложно привить к чему-то, что не было разработано с учетом этого.