Требования к балансировке нагрузки веб-серверов .NET 3.5

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

Как вы пришли к числу 10? Почему вы не увеличиваете масштаб до 2 или 3 и не добавляете больше по мере необходимости?

Почему вы вообще собираетесь балансировать нагрузку? Например, вы собираетесь использовать высокую нагрузку, высокую доступность или и то, и другое? Есть ли немедленная необходимость или это прогнозная необходимость?

Если вы сейчас находитесь под нагрузкой и пытаетесь масштабироваться, чтобы решить эту проблему, я задам один большой вопрос: вы действительно определили узкое место. Вы упомянули, что используете .NET и SQL для состояния сеанса, поэтому я предполагаю, что вы также работаете с приложением с поддержкой SQL. Вы также балансируете сервер SQL? Может ли сервер SQL обрабатывать в 10 раз больше соединений, чем у вас сейчас?

Если вы стремитесь к доступности, учли ли вы все другие точки отказа? Есть ли у вашего балансировщика нагрузки избыточность? Есть ли у вас резервирование на сервере (ах) баз данных? Есть ли у вас резервирование на вашем восходящем интернет-канале (учитывайте все моменты: один кабель, один коммутатор и т. Д.)? С точки зрения доступности, вы в безопасности настолько, насколько ваше самое слабое звено. Не имеет значения, есть ли у вас 10 или даже 100 интерфейсных веб-серверов, если у вас есть только один сервер базы данных, и он выходит из строя.

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

• Если вы используете SSL, есть два типичных режима, в которых обычно работают балансировщики нагрузки, которые влияют на работу SSL:

  • Уровень 4: это уровень TCP. SSL обрабатывается каждым сервером, поэтому сертификат SSL должен быть установлен на каждом сервере.
  • Уровень 7: это уровень приложения, также называемый обратным прокси. Балансировщик нагрузки обрабатывает сеанс HTTP и устанавливает второе соединение с сервером приложений. В этом режиме сертификат SSL устанавливается только на балансировщике, а соединение с серверами приложений обычно осуществляется по протоколу HTTP. Это иногда называют «разгрузкой SSL» и обычно полезно, если ваш балансировщик нагрузки мощный, и вы не хотите, чтобы ваш сервер приложений обрабатывал накладные расходы на шифрование SSL (например, ваше приложение интенсивно использует процессор).

• Убедитесь, что ваш балансировщик настроен на вывод серверов из строя, когда они выходят из строя, и протестируйте эту функциональность. Вы должны иметь возможность отключать серверы, не влияя на остальные серверы. Обратите внимание: PING против HTTP против проверки времени ответа. (Проверка связи не означает, что HTTP отвечает)

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

• Запустите промежуточную среду. Это может быть не 10 серверов, но должно быть достаточно для репликации производственной системы для тестирования развертывания.

• Иметь сценарий автоматического развертывания и очень строго относиться к управлению исходными кодами и конфигурацией. В идеале это означает, что ВСЕ (включая файлы конфигурации) находится в системе управления версиями, и у вас есть автоматизированные сборки для создания всего, вплоть до вашего установщика / скрипта.

• Получите инструмент, который отслеживает как ваш внешний сайт, так и все внутренние серверы. Если сервер умирает, с точки зрения внешнего мира ничего не меняется, но вы все равно хотите узнать и исправить сервер. Если у вас возникнут проблемы с производительностью или доступностью, вы не захотите обнаружить, что 3 сервера не работают в течение месяца, а остальные борются с дополнительной нагрузкой.