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

Question

Если вы действительно переходите от односерверной среды к кластеру с балансировкой нагрузки из 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 сервера не работают уже месяц, а остальные борются с дополнительной нагрузкой.

Answer 1

Если вы действительно переходите от односерверной среды к кластеру с балансировкой нагрузки из 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 сервера не работают уже месяц, а остальные борются с дополнительной нагрузкой.

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

решение1

Связанный контент