Балансировка нагрузки

В вычислениях, балансировка нагрузки усовершенствует распределение нагрузки между несколькими вычислительными ресурсами, например компьютеры, в компьютерном кластере, сетевые соединения, центральные процессоры или диски. Балансировка нагрузки направлена ​​на улучшение использования ресурсов, увеличение пропускной способности, уменьшение времени отклика, нейтрализации перегрузки любого отдельного ресурса, горизонтального масштабирования кластера(динамическое добавление/удаление устройств), а также предоставления отказоустойчивости(резервирования). Применение нескольких компонентов с балансировкой нагрузки вместо одного компонента повышает надежность и доступность вследствии избыточности. Балансировка нагрузки как правило состоит из специализированного программного обеспечения или аппаратного обеспечения, например многоуровневый коммутатор или процесс сервера доменных имен.

Примеры устройств, к которым применима балансировка:

1) Серверные кластеры;

2) Прокси-серверы;

3) Межсетевые экраны;

4) Коммутаторы;

5) Серверы инспектирования содержимого;

6) Серверы DNS;

7) Сетевые адаптеры;

Балансировка нагрузки применяется для увеличения возможностей кластера серверов. Она также позволяет продолжать работу даже в условиях, при нескольких вышедших из строя исполнительных устройств. Поэтому растёт отказоустойчивость, и предоставляется возможность динамически регулировать используемые вычислительные ресурсы за счёт добавления/удаления исполнительных устройств в кластере.

Балансировщики оборудования и программного обеспечения имеют большое количество специальных функций. Главная особенность балансировки нагрузки это распределение входящих запросов по нескольким серверам согласно алгоритму планирования. Многие из следующих функций уникальны для балансировщика:

1. Асимметричная нагрузка: отношение может быть назначено вручную для того, чтобы заставить некоторые серверы получать большую часть рабочей нагрузки, чем другие. Иногда это используется как грубый способ учесть, что некоторые серверы имеют большую ёмкость, чем другие.

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

3. Защита от атак с распределенным отказом в обслуживании (DDoS)

4. HTTP-сжатие: снижает количество передаваемых данных для объектов HTTP, используя сжатие gzip.

5. Direct Server Return: опция для асимметричного распределения нагрузки, где запрос и ответ передаются по разные сетевым путям.

6. Проверка работоспособности.

7. HTTP-кэширование: балансировщик хранит статический контент, поэтому некоторые запросы могут обрабатываться без обращения к серверам.

8. Фильтрация контента: некоторые балансировщики обладают возможностью произвольно изменять трафик на пути.

9. Приоритетная очередность

10. Переключение с учетом содержания

11. Аутентификация клиента.

12. Программная обработка трафика

13. Брандмауэр.

14. Система предотвращения вторжений

Балансировка нагрузки в большинстве случаев используется для реализации отказоустойчивости. Постоянно контролируются компоненты и при изменение статуса на неактивный, балансировщик нагрузки получает об этом информацию и больше не отправляет ему трафик. При возвращение компонента в сеть, балансировщик нагрузки снова направляет трафик на него. Для того чтобы это работало, необходим хотя бы один компонент, превышающий емкость службы (избыточность N + 1). Это приводит к меньшим затратам и более гибким, чем подходы к отказоустойчивости, когда каждый отдельный компонент в реальном времени соединен с одним резервным компонентом.

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

Одним из решением является хранить сессионные данные в базе данных. Это плохо для производительности потому, что это увеличивает нагрузку на базу данных: базу данных лучше использовать для хранения более статичной информации, чем сессионные данные. Еще одно решение для хранения постоянных данных это связать имя с каждым блоком данных и применять распределенную хэш-таблицу, чтобы псевдо-случайным образом присвоить имя одному из доступных серверов, а потом хранить, этот блок данных в назначенном сервере.