Load balancer что это

Область применения: Windows Server (Semi-Annual Channel), Windows Server 2016 Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

В этом разделе представлен обзор балансировки сетевой нагрузки () NLB в Windows Server 2016. In this topic, we provide you with an overview of the Network Load Balancing (NLB) feature in Windows Server 2016. С помощью NLB можно управлять двумя или более серверами как одним виртуальным кластером. You can use NLB to manage two or more servers as a single virtual cluster. Балансировка сетевой нагрузки повышает доступность и масштабируемость приложений Интернет-сервера, например, используемых в Интернете, FTP, брандмауэре, прокси-сервере, виртуальной частной сети (VPN-)и других задачах,-важных серверах. NLB enhances the availability and scalability of Internet server applications such as those used on web, FTP, firewall, proxy, virtual private network (VPN), and other mission-critical servers.

Windows Server 2016 включает новое программное обеспечение, основанное на Azure Load Balancer (SLB) в качестве компонента программно-определяемой сети (SDN) Infrastructure. Windows Server 2016 includes a new Azure-inspired Software Load Balancer (SLB) as a component of the Software Defined Networking (SDN) infrastructure. Используйте SLB вместо балансировки сетевой нагрузки, если вы используете SDN, используют рабочие нагрузки, не относящиеся к Windows, требуется преобразование исходящего сетевого адреса ()NAT, или требуется уровень 3 () или балансировка нагрузки на основе TCP. Use SLB instead of NLB if you are using SDN, are using non-Windows workloads, need outbound network address translation (NAT), or need Layer 3 (L3) or non-TCP based load balancing. Вы можете продолжать использовать балансировку сетевой нагрузки с Windows Server 2016 для развертываний без SDN. You can continue to use NLB with Windows Server 2016 for non-SDN deployments. Дополнительные сведения о SLB см. в разделе Программная балансировка нагрузки (SLB) для Sdn. For more information about SLB, see Software Load Balancing (SLB) for SDN.

Функция балансировки сетевой нагрузки (NLB) распределяет трафик между несколькими серверами с помощью протокола TCP/IP Network. The Network Load Balancing (NLB) feature distributes traffic across several servers by using the TCP/IP networking protocol. Объединяя два или более компьютеров, на которых запущены приложения, в один виртуальный кластер, NLB обеспечивает надежность и производительность веб-серверов и других-важных серверов. By combining two or more computers that are running applications into a single virtual cluster, NLB provides reliability and performance for web servers and other mission-critical servers.

Серверы в NLB-кластере называются узлами, и на каждом узле выполняется отдельная копия серверных приложений. The servers in an NLB cluster are called hosts, and each host runs a separate copy of the server applications. Балансировка сетевой нагрузки позволяет распределять входящие клиентские запросы между узлами в кластере. NLB distributes incoming client requests across the hosts in the cluster. При этом можно настроить нагрузку для каждого узла. You can configure the load that is to be handled by each host. Если нужно обработать дополнительную нагрузку, узлы можно добавлять к кластеру динамически. You can also add hosts dynamically to the cluster to handle increased load. Кроме того, технология балансировки сетевой нагрузки может направлять весь трафик на один предназначенный для этого узел, называемый узлом по умолчанию. NLB can also direct all traffic to a designated single host, which is called the default host.

Балансировка сетевой нагрузки позволяет обращаться ко всем компьютерам в кластере по одному и тому же набору IP-адресов и поддерживает набор уникальных IP-адресов, выделенных для каждого узла. NLB allows all of the computers in the cluster to be addressed by the same set of IP addresses, and it maintains a set of unique, dedicated IP addresses for each host. Для приложений с балансировкой нагрузки-при сбое или переходе узла в режим «вне сети» нагрузка автоматически перераспределяется между компьютерами, которые еще работают. For load-balanced applications, when a host fails or goes offline, the load is automatically redistributed among the computers that are still operating. Когда компьютер будет готов к работе, он может снова присоединиться к кластеру в рабочем режиме и взять на себя часть нагрузки, что позволит снизить объем данных, приходящийся на другие компьютеры кластера. When it is ready, the offline computer can transparently rejoin the cluster and regain its share of the workload, which allows the other computers in the cluster to handle less traffic.

Практическое применение Practical applications

Балансировка сетевой нагрузки полезна для обеспечения того, что приложения без отслеживания состояния, такие как веб-серверы, работающие службы IIS (IIS), доступны с минимальным временем простоя и что они масштабируются (путем добавления дополнительных серверов при увеличении нагрузки). NLB is useful for ensuring that stateless applications, such as web servers running Internet Information Services (IIS), are available with minimal downtime, and that they are scalable (by adding additional servers as the load increases). В следующих разделах описывается применение NLB для поддержки высокой доступности, масштабируемости и управляемости кластерных серверов, выполняющих указанные приложения. The following sections describe how NLB supports high availability, scalability, and manageability of the clustered servers that run these applications.

Высокая доступность High availability

Система высокой доступности обеспечивает обслуживание на приемлемом уровне с минимальной потерей машинного времени. A high availability system reliably provides an acceptable level of service with minimal downtime. Для обеспечения высокого уровня доступности NLB включает в себя встроенные-функции, которые могут автоматически выполнять следующие действия: To provide high availability, NLB includes built-in features that can automatically:

Выявление в кластере самопроизвольно прекратившего работу или отключившегося от сети узла с последующим его восстановлением. Detect a cluster host that fails or goes offline, and then recover.

Балансировка нагрузки сети при добавлении и удалении узлов. Balance the network load when hosts are added or removed.

Восстановление и перераспределение рабочей нагрузки в течение 10 секунд. Recover and redistribute the workload within ten seconds.

Масштабируемость Scalability

Масштабируемость показывает, насколько можно расширить возможности компьютера, службы или приложения в соответствии с повышением требований к его производительности. Scalability is the measure of how well a computer, service, or application can grow to meet increasing performance demands. Применительно к кластерам NLB масштабируемость — это возможность добавления одной или нескольких систем к существующему кластеру, когда общая нагрузка кластера превышает его текущую производительность. For NLB clusters, scalability is the ability to incrementally add one or more systems to an existing cluster when the overall load of the cluster exceeds its capabilities. Поддержка масштабируемости реализуется в NLB следующим образом: To support scalability, you can do the following with NLB:

Балансировка запросов на загрузку в кластере балансировки сетевой нагрузки для отдельных служб TCP/IP. Balance load requests across the NLB cluster for individual TCP/IP services.

Поддержка до 32 компьютеров в одном кластере. Support up to 32 computers in a single cluster.

Распределите нагрузку на несколько запросов на загрузку сервера (из одного клиента или с нескольких клиентов) на нескольких узлах в кластере. Balance multiple server load requests (from the same client or from several clients) across multiple hosts in the cluster.

Добавление узлов в NLB-кластер по мере увеличения нагрузки, не приводящее к сбоям в работе кластера. Add hosts to the NLB cluster as the load increases, without causing the cluster to fail.

Вывод узлов из состава кластера по мере уменьшения нагрузки. Remove hosts from the cluster when the load decreases.

Высокая производительность и уменьшение объема служебных данных за счет реализации полнофункционального конвейерного режима. Enable high performance and low overhead through a fully pipelined implementation. Данный режим позволяет отправлять запросы NLB-кластеру, не ожидая ответа на предыдущий запрос. Pipelining allows requests to be sent to the NLB cluster without waiting for a response to a previous request.

Управляемость Manageability

Поддержка управляемости реализуется в NLB следующим образом: To support manageability, you can do the following with NLB:

Управление и настройка нескольких кластеров балансировки сетевой нагрузки и узлов кластера с одного компьютера с помощью диспетчера NLB или командлетов балансировки сетевой нагрузки (NLB) в Windows PowerShell. Manage and configure multiple NLB clusters and the cluster hosts from a single computer by using NLB Manager or the Network Load Balancing (NLB) Cmdlets in Windows PowerShell.

Используя правила управления портами, можно задавать режим балансировки для отдельного IP-порта или группы портов. Specify the load balancing behavior for a single IP port or group of ports by using port management rules.

Для портов каждого веб-сайта могут определяться различные правила. Define different port rules for each website. Если для нескольких приложений или веб-сайтов используется один и тот же набор балансировки нагрузки серверов-, правила портов основываются на целевом виртуальном IP-адресе (использовании виртуальных кластеров). If you use the same set of load-balanced servers for multiple applications or websites, port rules are based on the destination virtual IP address (using virtual clusters).

Направлять все клиентские запросы на один узел, используя необязательные правила одного-узла. Direct all client requests to a single host by using optional, single-host rules. NLB будет направлять клиентские запросы на определенный узел, где выполняются заданные приложения. NLB routes client requests to a particular host that is running specific applications.

Имеется возможность блокировки доступа по сети к определенным IP-портам. Block undesired network access to certain IP ports.

Включите протокол управления группами Интернета (поддержку IGMP) на узлах кластера для управления переполнением портов коммутатора (, где входящие сетевые пакеты отправляются на все порты на коммутаторе) при работе в режиме многоадресной рассылки. Enable Internet Group Management Protocol (IGMP) support on the cluster hosts to control switch port flooding (where incoming network packets are sent to all ports on the switch) when operating in multicast mode.

Запуск, остановка и управление действиями NLB могут производиться удаленно с использованием команд или сценариев Windows PowerShell. Start, stop, and control NLB actions remotely by using Windows PowerShell commands or scripts.

События NLB можно просматривать в журнале событий Windows. View the Windows Event Log to check NLB events. В журнал событий записываются все действия NLB и изменения кластера. NLB logs all actions and cluster changes in the event log.

Важные функции Important functionality

NLB устанавливается как стандартный компонент сетевого драйвера Windows Server. NLB is installed as a standard Windows Server networking driver component. Его операции прозрачны для сетевого стека TCP/IP. Its operations are transparent to the TCP/IP networking stack. На следующем рисунке показана связь между балансировкой сетевой нагрузки и другими компонентами программного обеспечения в типичной конфигурации. The following figure shows the relationship between NLB and other software components in a typical configuration.

Ниже приведены основные возможности балансировки сетевой нагрузки. Following are the primary features of NLB.

Не требует для запуска изменений аппаратной части. Requires no hardware changes to run.

Читайте также:  Изделия из мусора своими руками

Предоставляет средства балансировки сетевой нагрузки для управления несколькими кластерами и всеми узлами кластеров, а также их настройки с одного удаленного или локального компьютера. Provides Network Load Balancing Tools to configure and manage multiple clusters and all of the hosts from a single remote or local computer.

Позволяет клиентам получать доступ к кластеру с помощью одного логического имени Интернета и виртуального IP-адреса, который называется IP-адресом кластера (он содержит отдельные имена для каждого компьютера). Enables clients to access the cluster by using a single, logical Internet name and virtual IP address, which is known as the cluster IP address (it retains individual names for each computer). Балансировка сетевой нагрузки поддерживает несколько виртуальных IP-адресов для многосетевых серверов. NLB allows multiple virtual IP addresses for multihomed servers.

При развертывании виртуальных машин в качестве виртуальных кластеров балансировка сетевой нагрузки не требует, чтобы серверы были подключены к нескольким виртуальным IP-адресам. When you deploy VMs as virtual clusters, NLB does not require servers to be multihomed to have multiple virtual IP addresses.

Средство балансировки сетевой нагрузки может быть привязано к нескольким сетевым адаптерам, что позволяет настроить несколько независимых кластеров на каждом узле. Enables NLB to be bound to multiple network adapters, which enables you to configure multiple independent clusters on each host. Поддержка нескольких сетевых адаптеров — это не то же самое, что виртуальные кластеры, в которых можно настраивать несколько кластеров на одном сетевом адаптере. Support for multiple network adapters differs from virtual clusters in that virtual clusters allow you to configure multiple clusters on a single network adapter.

Не требует модификации серверных приложений, что обеспечивает их работу в любом кластере NLB. Requires no modifications to server applications so that they can run in an NLB cluster.

Возможна настройка автоматического добавления узла в кластер при сбое в работе узла данного кластера с последующим возвращением с сеть. Can be configured to automatically add a host to the cluster if that cluster host fails and is subsequently brought back online. Добавленный узел может приступать к обработке новых клиентских обращений к серверу. The added host can start handling new server requests from clients.

Обеспечивает возможность отключения компьютеров от сети для проведения профилактического обслуживания, не затрагивая операции кластера на других узлах. Enables you to take computers offline for preventive maintenance without disturbing the cluster operations on the other hosts.

Требования к оборудованию Hardware requirements

Ниже приведены требования к оборудованию для запуска кластера балансировки сетевой нагрузки. Following are the hardware requirements to run an NLB cluster.

Все узлы кластера должны располагаться в одной подсети. All hosts in the cluster must reside on the same subnet.

Количество сетевых адаптеров на каждом узле не ограничено, при этом различные узлы могут иметь разное число адаптеров. There is no restriction on the number of network adapters on each host, and different hosts can have a different number of adapters.

Все сетевые адаптеры в одном кластере необходимо использовать либо в одноадресном, либо в многоадресном режиме. Within each cluster, all network adapters must be either multicast or unicast. Балансировка сетевой нагрузки не поддерживает смешанную среду одноадресной и многоадресной рассылки внутри одного кластера. NLB does not support a mixed environment of multicast and unicast within a single cluster.

Если используется одноадресный режим, то сетевой адаптер, используемый для работы-клиента с-ным трафиком кластера, должен поддерживать изменение его контроля доступа к носителю (адрес MAC). If you use the unicast mode, the network adapter that is used to handle client-to-cluster traffic must support changing its media access control (MAC) address.

Требования к программному обеспечению Software requirements

Ниже приведены требования к программному обеспечению для запуска кластера балансировки сетевой нагрузки. Following are the software requirements to run an NLB cluster.

На адаптере, для которого включена балансировка сетевой нагрузки на каждом узле, можно использовать только TCP-/IP. Only TCP/IP can be used on the adapter for which NLB is enabled on each host. Не добавляйте никакие другие протоколы (например,) IPX к этому адаптеру. Do not add any other protocols (for example, IPX) to this adapter.

IP-адреса серверов в составе кластера должны быть статическими. The IP addresses of the servers in the cluster must be static.

NLB не поддерживает протокол динамической конфигурации узла ()DHCP. NLB does not support Dynamic Host Configuration Protocol (DHCP). NLB отключает протокол DHCP на каждом настраиваемом интерфейсе. NLB disables DHCP on each interface that it configures.

Сведения об установке Installation information

Балансировку сетевой нагрузки можно установить с помощью диспетчер сервера или команд Windows PowerShell для балансировки сетевой нагрузки. You can install NLB by using either Server Manager or the Windows PowerShell commands for NLB.

Дополнительно можно установить средства балансировки сетевой нагрузки для управления локальным или удаленным кластером NLB. Optionally you can install the Network Load Balancing Tools to manage a local or remote NLB cluster. К этим средствам относятся диспетчер балансировки сетевой нагрузки и команды Windows PowerShell NLB. The tools include Network Load Balancing Manager and the NLB Windows PowerShell commands.

Установка с диспетчер сервера Installation with Server Manager

В диспетчер сервера можно использовать мастер добавления ролей и компонентов, чтобы добавить функцию балансировки сетевой нагрузки . In Server Manager, you can use the Add Roles and Features Wizard to add the Network Load Balancing feature. После завершения работы мастера устанавливается балансировка сетевой нагрузки и не требуется перезагружать компьютер. When you complete the wizard, NLB is installed, and you do not need to restart the computer.

Установка с помощью Windows PowerShell Installation with Windows PowerShell

Чтобы установить NLB с помощью Windows PowerShell, выполните следующую команду в командной строке Windows PowerShell с повышенными привилегиями на компьютере, где требуется установить NLB. To install NLB by using Windows PowerShell, run the following command at an elevated Windows PowerShell prompt on the computer where you want to install NLB.

После завершения установки перезагрузка компьютера не требуется. After installation is complete, no restart of the computer is required.

Дополнительные сведения см. в разделе Install-WindowsFeature. For more information, see Install-WindowsFeature.

Диспетчер балансировки сетевой нагрузки Network Load Balancing Manager

Чтобы открыть диспетчер балансировки сетевой нагрузки в диспетчере сервера, в меню Сервис выберите пункт Диспетчер балансировки сетевой нагрузки. To open Network Load Balancing Manager in Server Manager, click Tools, and then click Network Load Balancing Manager.

Дополнительные ресурсы Additional resources

В следующей таблице приведены ссылки на дополнительные сведения о функции балансировки сетевой нагрузки. The following table provides links to additional information about the NLB feature.

Вопрос о планировании нагрузки следует решать ещё на ранней стадии развития любого веб-проекта. «Падение» сервера (а оно всегда происходит неожиданно, в самый неподходящий момент) чревато весьма серьёзными последствиями — как моральными, так и материальными. Первоначально проблемы недостаточной производительности сервера в связи ростом нагрузок можно решать путем наращивания мощности сервера, или же оптимизацией используемых алгоритмов, программных кодов и так далее. Но рано или поздно наступает момент, когда и эти меры оказываются недостаточными.

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

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

Уровни балансировки

Процедура балансировки осуществляется при помощи целого комплекса алгоритмов и методов, соответствующим следующим уровням модели OSI:

Рассмотрим эти уровни более подробно.

Балансировка на сетевом уровне

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

  • DNS-балансировка. На одно доменное имя выделяется несколько IP-адресов. Сервер, на который будет направлен клиентский запрос, обычно определяется с помощью алгоритма Round Robin (о методах и алгоритмах балансировки будет подробно рассказано ниже).
  • Построение NLB-кластера. При использовании этого способа серверы объединяются в кластер, состоящий из входных и вычислительных узлов. Распределение нагрузки осуществляется при помощи специального алгоритма. Используется в решениях от компании Microsoft.
  • Балансировка по IP с использованием дополнительного маршрутизатора.
  • Балансировка по территориальному признаку осуществляется путём размещения одинаковых сервисов с одинаковыми адресами в территориально различных регионах Интернета (так работает технология Anyсast DNS, о которой мы уже писали). Балансировка по территориальному признаку также используется во многих CDN (см. интересный пример реализации).

Балансировка на транспортном уровне

Этот вид балансировки является самым простым: клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который и будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами (об этом ещё пойдёт речь ниже): путём простого кругового перебора, путём выбора наименее загруженного сервера из пула и т.п.

Иногда балансировку на транспортном уровне сложно отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого фильтра pf в BSD-системах: так, например, формально тут идет речь про балансировку трафика на конкретном порту TCP (пример для сетевого фильтра pf в BSD-системах):

Речь в нём идет о балансировке трафика на конкретном порту TCP.

Рассмотрим теперь другой пример:

В этом правиле речь о балансировке исходящего трафика на сетевом уровне. В нём не указано ни конкретного порта, ни конкретного протокола.

Различие между уровнями балансировки можно объяснить следующим образом. К сетевому уровню относятся решения, которые не терминируют на себе пользовательские сессии. Они просто перенаправляют трафик и не работают в проксирующем режиме.
На сетевом уровне балансировщик просто решает, на какой сервер передавать пакеты. Сессию с клиентом осуществляет сервер.

На транспортном уровене общение с клиентом замыкается на балансировщике, который работает как прокси. Он взаимодействует с серверами от своего имени, передавая информацию о клиенте в дополнительных данных и заголовках. Таким образом работает, например, популярный программный балансировщик HAProxy.

Балансировка на прикладном уровне

При балансировке на прикладном уровне балансировщик работает в режиме «умного прокси». Он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Так работает, например, веб-сервер Nginx, распределяя запросы между фронтендом и бэкендом. За балансировку в Nginx отвечает модуль Upstream. Более подробно об особенностях балансировки Nginx на основе различных алгоритмов можно прочитать, например, здесь.

В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы оп серверам баз данных в зависимости от их содержания,: например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой. Подробнее о pgpool и специфике работы с ним можно почитать в этой статье).

Алгоритмы и методы балансировки

Существует много различных алгоритмов и методов балансировки нагрузки. Выбирая конкретный алгоритм, нужно исходить, во-первых, из специфики конкретного проекта, а во-вторых — из целей. которые мы планируем достичь.

В числе целей, для достижения которых используется балансировка, нужно выделить следующие:

  • справедливость: нужно гарантировать, чтобы на обработку каждого запроса выделялись системные ресурсы и не допустить возникновения ситуаций, когда один запрос обрабатывается, а все остальные ждут своей очереди;
  • эффективность: все серверы, которые обрабатывают запросы, должны быть заняты на 100%; желательно не допускать ситуации, когда один из серверов простаивает в ожидании запросов на обработку (сразу же оговоримся, что в реальной практике эта цель достигается далеко не всегда);
  • сокращение времени выполнения запроса: нужно обеспечить минимальное время между началом обработки запроса (или его постановкой в очередь на обработку) и его завершения;
  • сокращение времени отклика: нужно минимизировать время ответа на запрос пользователя.
Читайте также:  Ahd камеры видеонаблюдения что это

Очень желательно также, чтобы алгоритм балансировки обладал следующими свойствами:

  • предсказуемость: нужно чётко понимать, в каких ситуациях и при каких нагрузках алгоритм будет эффективным для решения поставленных задач;
  • равномерная загрузка ресурсов системы;
  • масштабирумость: алгоритм должен сохранять работоспособность при увеличении нагрузки.

Round Robin

Round Robin, или алгоритм кругового обслуживания, представляет собой перебор по круговому циклу: первый запрос передаётся одному серверу, затем следующий запрос передаётся другому и так до достижения последнего сервера, а затем всё начинается сначала.

Самой распространёной имплементацией этого алгоритма является, конечно же, метод балансировки Round Robin DNS. Как известно, любой DNS-сервер хранит пару «имя хоста — IP-адрес» для каждой машины в определённом домене. Этот список может выглядеть, например, так:

С каждым именем из списка можно ассоциировать несколько IP-адресов:

DNS-сервер проходит по всем записям таблицы и отдаёт на каждый новый запрос следующий IP-адрес: например, на первый запрос — xxx.xxx.xxx.2, на второй — ххх.ххх.ххх.3, и так далее. В результате все серверы в кластере получают одинаковое количество запросов.

В числе несомненных плюсов этого алгоритма следует назвать, во-первых, независимость от протокола высокого уровня. Для работы по алгоритму Round Robin используется любой протокол, в котором обращение к серверу идёт по имени.
Балансировка на основе алгоритма Round Robin никак не зависит от нагрузки на сервер: кэширующие DNS-серверы помогут справиться с любым наплывом клиентов.

Использование алгоритма Round Robin не требует связи между серверами, поэтому он может использоваться как для локальной, так и для глобальной балансировки,.
Наконец, решения на базе алгоритма Round Robin отличаются низкой стоимостью: чтобы они начали работать, достаточно просто добавить несколько записей в DNS.

Алгоритм Round Robin имеет и целый ряд существенных недостатков недостатков. Чтобы распределение нагрузки по этому алгоритму отвечало упомянутым выше критериями справедливости и эффективности, нужно, чтобы у каждого сервера был в наличии одинаковый набор ресурсов. При выполнении всех операций также должно быть задействовано одинаковое количество ресурсов. В реальной практике эти условия в большинстве случаев оказываются невыполнимыми.

Также при балансировке по алгоритму Round Robin совершенно не учитывается загруженность того или иного сервера в составе кластера. Представим себе следующую гипотетическую ситуацию: один из узлов загружен на 100%, в то время как другие — всего на 10 — 15%. Алгоритм Round Robin возможности возникновения такой ситуации не учитывает в принципе, поэтому перегруженный узел все равно будет получать запросы. Ни о какой справедливости, эффективности и предсказуемости в таком случае не может быть и речи.

В силу описанных выше обстоятельств сфера применения алгоритма Round Robin весьма ограничена.

Weighted Round Robin

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

Least Connections

В предыдущем разделе мы перечислили основные недостатки алгоритма Round Robin. Назовём ещё один: в нём совершенно не учитывается количество активных на данный момент подключений.

Рассмотрим практический пример. Имеется два сервера — обозначим их условно как А и Б. К серверу А подключено меньше пользователей, чем к серверу Б. При этом сервер А оказывается более перегруженным. Как это возможно? Ответ достаточно прост: подключения к серверу А поддерживаются в течение более долгого времени по сравнению с подключениями к серверу Б.

Описанную проблему можно решить с помощью алгоритма, известного под названием least connections (сокращённо — leastconn). Он учитывает количество подключений, поддерживаемых серверами в текущий момент времени. Каждый следующий вопрос передаётся серверу с наименьшим количеством активных подключений.

Существует усовершенствованный вариант этого алгоритма, предназначенный в первую очередь для использования в кластерах, состоящих из серверов с разными техническими характеристиками и разной производительностью. Он называется Weighted Least Connections и учитывает при распределении нагрузки не только количество активных подключений, но и весовой коэффициент серверов.

В числе других усовершенствованных вариантов алгоритма Least Connections следует прежде всего выделить Locality-Based Least Connection Scheduling и Locality-Based Least Connection Scheduling with Replication Scheduling.

Первый метод был создан специально для кэширующих прокси-серверов. Его суть заключается в следующем: наибольшее количество запросов передаётся серверам с наименьшим количеством активных подключений. За каждым из клиентских серверов закрепляется группа клиентских IP. Запросы с этих IP направляются на «родной» сервер, если он не загружен полностью. В противном случае запрос будет перенаправлен на другой сервер (он должен быть загружен менее чем наполовину).

В алгоритме Locality-Based Least Connection Scheduling with Replication Scheduling каждый IP-адрес или группа IP-адресов закрепляется не за отдельным сервером, а за целой группой серверов. Запрос передаётся наименее загруженному серверу из группы. Если же все серверы из «родной» группы перегружены, то будет зарезервирован новый сервер. Этот новый сервер будет добавлен к группе, обслуживающей IP, с которого был отправлен запрос. В свою очередь наиболее загруженный сервер из этой группы будет удалён — это позволяет избежать избыточной репликации.

Destination Hash Scheduling и Source Hash Scheduling

Алгоритм Destination Hash Scheduling был создан для работы с кластером кэширующих прокси-серверов, но он часто используется и в других случаях. В этом алгоритме сервер, обрабатывающий запрос, выбирается из статической таблицы по IP-адресу получателя.

Алгоритм Source Hash Scheduling основывается на тех же самых принципах, что и предыдущий, только сервер, который будет обрабатывать запрос, выбирается из таблицы по IP-адресу отправителя.

Sticky Sessions

Sticky Sessions — алгоритм распределения входящих запросов, при котором соединения передаются на один и тот же сервер группы. Он используется, например, в веб-сервере Nginx. Сессии пользователя могут быть закреплены за конкретным сервером с помощью метода IP hash (подробную информацию о нём см. в официальной документации). С помощью этого метода запросы распределяются по серверам на основе IP-aдреса клиента. Как указано в документации (см. ссылку выше), «метод гарантирует, что запросы одного и того же клиента будет передаваться на один и тот же сервер». Если закреплённый за конкретным адресом сервер недоступен, запрос будет перенаправлен на другой сервер. Пример фрагмента конфигурационного файла:

Начиная с версии 1.2.2 в Nginx для каждого сервера можно указывать вес.

Применение этого метода сопряжено с некоторыми проблемами. Проблемы с привязкой сессий могут возникнуть, если клиент использует динамический IP. В ситуации, когда большое количество запросов проходит через один прокси-сервер, балансировку вряд ли можно назвать эффективной и справедливой. Описанные проблемы, однако, можно решить, используя cookies. В коммерческой версии Nginx имеется специальный модуль sticky, который как раз использует cookies для балансировки. Есть у него и бесплатные аналоги — например, nginx-sticky-module.
Можно использовать метод sticky-sessions и в HAProxy — подробнее об этом можно прочитать, например, здесь.

Заключение

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

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

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

Решения для балансировки сетевой нагрузки только на первый взгляд выглядят одинаково. На самом деле в процессе участвует множество технологий и алгоритмов, поэтому найти два одинаковых продукта невозможно. Неочевидными особенностями может быть поддержка определенных протоколов (например, только HTTP или любые), есть и множество других параметров.

Кроме того, системы балансировки нагрузки могут перенаправлять трафик клиентов на избранный сервер несколькими способами. Самые популярные: трансляция сетевых адресов (Network Address Translation) и отсылка через шлюз TCP (TCP gateway). В первом случае балансировщик на лету подменяет в пакете IP-адреса, чем скрывает IP сервера от клиента и наоборот. Если же IP клиента нужно конечному приложению для статистики или любых других операций, его обычно сохраняют в HTTP-заголовке X-Forwarded-for. При использовании другого протокола следует убедиться, что подобная возможность реализована. В случае TCP gateway балансировщик умеет управлять трафиком на L4 (транспортном) уровне и даже на уровне приложения (L7). Для этого он устанавливает соединение и смотрит внутрь пакета. Обычно клиент и приложение обмениваются информацией через балансировщик. Но в последнее время становится все более популярной конфигурация сервера с прямым возвратом (Direct Server Return, DSR) когда ответ от сервера идет к клиенту напрямую, а не через устройство балансировки. Использование DSR уменьшает нагрузку на балансировщик, но не позволяет использовать куки и расшифровывать SSL. Данный способ на порядок быстрее, чем использование NAT-балансировки, и позволяет сервисам видеть реальные IP-адреса клиентов.

Также в системах можно встретить разные методы балансировки. Разберемся с назначением некоторых из них. В настройках продуктов они могут иметь отличные названия или свои особенности в реализации, но часто их суть одна.
Самый простой — Round Robin DNS, это специальный DNS-сервер, содержащий несколько А-записей и их вес (опционально) и выдающий при запросе клиентов различные IP-адреса. Минусы очевидны. Он абсолютно не владеет информацией о текущей загрузке и состоянии бэкендов, не учитывает предыдущие подключения клиентов (немного сглаживает ситуацию DNS-кеш).

Есть аналогичный по названию алгоритм, но реализованный средствами самого балансировщика — Round Robin. Все клиенты равномерно распределяются по бэкендам, и обычно какие-либо другие параметры не учитываются. Алгоритм распределения по весу (Round Robin Weighted) учитывает значение параметра Weight, указанного для каждого сервера. Проставив больший вес для более мощного сервера, мы сможем направить к нему больше клиентов. Несколько иначе действует распределение по приоритету. В этом алгоритме работает только сервер с большим приоритетом, остальные подключаются, как правило, только в случае его отказа. Этот вариант позволяет строить кластер с одним активным узлом, например когда второй сервер выполняет другую роль и только подстраховывает первый. Еще один вариант — Least Connection (Least Session) — соединение принимает сервер, обслуживающий наименьшее количество соединений (сессий), но соединения могут быть разные (пользователь активен или пассивен) и, соответственно, давать разную нагрузку на сервер. А вот алгоритм Least Bandwidth учитывает действительную загрузку сети.

Hash sticky client — клиент привязывается к одному серверу, для этого в специальную таблицу помещается хеш-строка, указывающая на его IP. Возможны варианты. Клиент всегда идет к одному серверу, а в случае его выхода подключение невозможно. Или, когда не отвечает «родной», он соединяется с другими системами.

Доступность бэкендов определяется двумя: активный (keepalives, балансировщик сам опрашивает серверы) и пассивный (In-Band, контролируются текущие соединения, ответы сервиса).

Проект номер один в списке — BalanceNG, является развитием Open Source решения Balance, но распространятся уже под двойной лицензией (коммерческой и бесплатной Free Basic License). В бесплатной версии можно подключать один виртуальный сервер и два узла, чего с учетом возможностей достаточно, чтобы без проблем справиться со средней, а иногда и большой нагрузкой. Представляет собой решение для балансировки IP-нагрузки, поддерживающее IPv6, предлагает несколько методов управления выбора бэкенда (Round Robin, Random, Weighted Random, Least Session, Least Bandwidth, Hash, Agent и Randomized Agent).

Читайте также:  Как выбрать электронную книгу для пожилого человека

В продукте использован оригинальный движок, работающий на Layer 2 (Ethernet), балансировка ведется на основе IP-адреса клиента, без привязки к портам работать может с любым сервисом. Поддерживает DNS GSLB (Global Server Load-Balancing) и конфигурацию сервера с прямым возвратом Direct Server Return (DSR), когда ответ от сервера идет к клиенту напрямую, а не через устройство балансировки. Содержит настраиваемый агент проверки UDP, поддерживает VRRP для установки высокодоступных конфигураций на многих узлах. Встроенные механизмы позволяют произвести захват и сохранение пакетов при помощи pcap для дальнейшего исследования. Предусмотрено несколько вариантов проверки работоспособности конечных систем: агент, ping, TCP Open, скрипт и другие инструменты вроде wget.

Возможно резервирование балансировщика с репликацией NAT-состояний между основным и резервным узлами, клиент при переподключении подсоединяется к тому же серверу. Для сохранения сессии используется IP-адрес клиента и порт назначения. Поддерживается Linux bonding. Все таблицы хранятся в ОЗУ, но требования невелики, для 4 миллионов сессий достаточно 512 Мб памяти.
Может работать в Linux (с использованием сокета API PF_PACKET) и SPARC/Intel Solaris (Streams/DLPI API). Для установки предлагаются rpm (Red Hat RHEL 6 / CentOS) и deb (Debian/Ubuntu) пакеты и тарбал для остальных дистрибутивов. Также доступен готовый образ для виртуальной машины (на базе Ubuntu 8.04), что позволяет быстро развернуть нужную функциональность. Во время закачки будут показаны все пароли для входа. Агент (bngagent) поставляется с открытым исходным кодом и поддерживает Linux, Solaris, OS X, HP-UX и другие.
Какой-либо интерфейс для настройки не предусмотрен, все установки производятся при помощи конфигурационного файла /etc/bng.conf. В принципе, сложным его назвать нельзя, особенно учитывая, что на сайте проекта доступно более десятка готовых примеров, часто нужно лишь выбрать наиболее подходящий и отредактировать под себя.

Конфигурационный файл BalanceNG

Xakep #248. Checkm8

HAProxy — балансировщик нагрузки и прокси-сервер уровня приложений Layer7 для TCP и HTTP. Проект начинался как очень простой HTTP-прокси Webroute, но постепенно оброс новыми возможностями. Особенностью HAProxy является использование для регулирования соединений cookie и контента, он встраивает cookie и проверяет содержимое пакета при подключении. Анализ пакетов на Layer7 позволяет фильтровать несанкционированный трафик и протоколы. Проверяя HTTP-запрос при помощи регулярных выражений, можно задать любые правила для выбора сервера, например реализуя ACL и геолокацию. В случае необходимости обработки IP-клиента на конечном сервере можем сохранить его в X-Forwarded-for. Движок стабилен, безопасен, оптимизирован, в результате HAProxy способен одновременно обрабатывать большое количество подключений (20 тысяч в секунду и более).
Обработкой всех подключений занимается один процесс, за счет оптимизации и планировщика обеспечивающий большое количество одновременных соединений на очень высоких скоростях. Такие системы не слишком хорошо масштабируются на многопроцессорных системах, но не болеют блокировками и ограничениями памяти. Но здесь мы не увидим продвинутых функций вроде поддержки SSL и keep-alive — по утверждению разработчиков, они усложняют и «утяжеляют» процесс. Отказоустойчивость HAProxy-сервера достигается через использование демона keepalived, проверяющего его работоспособность, синхронизация с резервным сервером (протокол VRRP) обеспечивает дублирование.

Предоставляет логирование соединений и разнообразные отчеты (статистика выводится на отдельном порту). Ориентирован в первую очередь на веб-сайты, но используется и в других сценариях, например в качестве балансировщика для multi-master серверов MySQL. Поддерживается фильтрация пользователей и подключение к тому же серверу (для RDP и HTTP), аутентификация HTTP.

Веб-интерфейс Snapt для настройки HAProxy

HAProxy в качестве балансировщика используется в нескольких компаниях из списка Fortune 500: Amazon RDS, GitHub, Stack Overflow, Server Fault, Twitter…
Возможности расширяются при помощи аддонов, их полный список есть на сайте. Все настройки производятся при помощи конфигурационного файла (на сайте есть примеры). Кроме того, известны два интерфейса сторонних разработчиков: коммерческий веб Snapt и свободный HATop.

Работает на нескольких архитектурах x86, x86_64, Alpha, SPARC, MIPS, PARISC. Официально поддерживает Linux 2.6.32+ (рекомендуется для максимальной производительности) и 2.4, Solaris 8–10, FreeBSD, OpenBSD. Установка и настройка тривиальны, хотя пакет в репозиториях не присутствует. Проект предлагает исходный код под лицензией GPL v2 и готовые бинарники под Linux/x86 Glibc 2.2 и Solaris8/Sparc.

Статистика HAProxy

Первоначальная цель проекта Pound — распределение нагрузки между несколькими серверами Zope, в итоге получился узконаправленный инструмент, представляющий собой обратный прокси и балансировщик нагрузки для HTTP и HTTPS.

Балансировка производится по состоянию сессии и другим параметрам (URL, аутентификации, cookies, HTTP headers). Полная поддержка WebDAV. В отличие от HAProxy обрабатывает SSL. Разработан в IT-компании, занимающейся безопасностью, что также сказалось на возможностях продукта. Особенностью является наличие базовых функций Web Application Firewall, Pound умеет контролировать корректность заголовков HTTP и HTTPS, отбрасывая неправильные. По умолчанию пропускаются все запросы, но можно создать шаблоны URL и тип запросов (стандартные, расширенные, RPC и WebDAV), которые будут проверяться на соответствие. По результатам выбирается конечный сервер или соединение блокируется. Дизайн изначально предусматривает минимальное вмешательство в трафик (например, встраивание cookie), но может прописывать X-Forwarded-for для передачи на бэкенд сервера IP-адреса пользователя.

Поддерживает IPv6, может перебрасывать IPv6 клиентов к серверам IPv4. Информация о сеансе сохраняется, и клиент в последующем подключается к своему серверу.

Из специфики — возможна не только отправка соединения к бэкенду, но и редирект на другой URL.

Pound не требует много ресурсов, примечательно, что кроме как за считыванием SSL-сертификатов демон не обращается к харду. Может быть запущен в chroot и использовать setuid/setgid. Каких-либо встроенных механизмов отказоустойчивости нет. Проверка работоспособности бэкендов производится всегда по HTTP.

На процессоре уровня Pentium D позволяет достичь примерно 600–800 HTTP- и 200–300 HTTPS-соединений в секунду. Поэтому конек Pound — небольшие проекты с упором на доступность, безопасность и больший контроль над трафиком. Для более высокой нагрузки сами разработчики Pound рекомендуют воспользоваться другими решениями.

Установка и настройка не представляют больших сложностей, хотя и производятся при помощи конфигурационных файлов (документация очень подробная). Официально был протестирован на Linux, Solaris и OpenBSD. Проект предлагает только исходные тексты, в репозиториях SUSE, Debian и Ubuntu можно найти готовые пакеты, кроме этого, на сайте есть ссылки для Red Hat и готового дистрибутива, собранного на базе FreeBSD.

В конфигурационном файле Pound разобраться легко

Crossroads обеспечивает балансировку нагрузки к любым TCP-сервисам, поэтому подходит не только для HTTP(S), но и для SMTP, SSH, баз данных и других. В обычном варианте он просто гарантирует подключение к бэкенду, не вникая во внутренности, и обеспечивает в этом режиме максимальную производительность. Один сервер может обслуживать несколько сайтов с разными бэкендами и протоколами. Но есть специальный режим HTTP mode, при котором обрабатываются и при необходимости меняются заголовки сеанса. Это обеспечивает возможность перенаправления пользователя на тот же сервер (session stickiness) и сохранение IP клиента в X-Forwarded-For. Сам по себе HTTP mode и особенно модификация пакета влияет на производительность (потери до 30%).

По умолчанию клиент перенаправляется на сервер, принимающий меньше подключений, но при необходимости алгоритм легко изменить на Round Robin, Least-Connections и First Available или определяться внешней программой или скриптом. Клиентов можно закреплять за определенным сервером (Hash sticky client), жестко или с возможностью подключения к другому серверу, если «свой» не отвечает. При возобновлении работы бэкенда он автоматически включается в работу. Возможно управление доступом к Crossroads на основе IP-адреса (allow и deny).
В версии 2.х все подключения обслуживает один процесс, работающий в пространстве пользователя, это положительно сказалось на скорости работы и на управлении. Может работать как stand-alone демон или запускаться через inetd. Удобно, что все настройки и команды можно отдавать на лету (при помощи утилиты xr), изменение параметров не требует перезапуска Crossroads. Например, настроим балансировку для двух веб-сайтов и серверов MySQL.

Статистика выводится при помощи веб-интерфейса, порт которого задается вместе с ключом -W (–web-interface). Также с его помощью можно изменить три параметра: максимальное количество соединений для Crossroads и для бэкендов, вес бэкендов.

Для удобства все их записывают в отдельный файл, который и указывают при загрузке, или используют специальный конфигурационный файл в формате XML (/etc/xrctl.xml, в поставке несколько готовых примеров).

Может быть запущен на любой POSIX-системе — Linux, OS X, Solaris. Проект предлагает исходные тексты (сборка проблем не вызывает), готовые пакеты доступны в репозиториях основных дистрибутивов.

В поставке Crossroads несколько готовых конфигурационных файлов

Решение, несколько отличающееся от остальных участников обзора. Разработчики справедливо решили, что под балансировку выделяется отдельный сервер, а поэтому лучше сразу предоставить готовый дистрибутив, чтобы упростить развертывание, повысить производительность и безопасность. Основой Zen Load Balancer является оптимизированная и урезанная версия Debian 6. Поддерживается балансировка на Layer 4 для протоколов TCP, UDP и на Layer 7 для HTTP/HTTPS. Специальный режим L4xNAT позволяет настроить балансировку на транспортном уровне без учета номеров портов (фактически без привязки к сервису), в этом случае Zen просто пропускает через себя весь трафик, распределяя его по серверам. Есть у Zen и фишка — режим DATALINK. В этом случае Zen выступает в качестве шлюза по умолчанию, обеспечивая равномерную нагрузку на канал и резервирование при подключении к нескольким провайдерам (балансировка на Layer 3).

Реализовано несколько алгоритмов выбора бэкенда: Round Robin, по весу (Weight), по приоритету (Priority) или подключение к определенному серверу (Hash sticky client). Возможен возврат пользователя в открытую сессию, он определяется несколькими способами (по IP-адресу, сookie, запрашиваемому URL, по заголовку HTTP). Предусмотрено сохранение IP в X-Forwarded-for.

Технология FarmGuardian позволяет определять доступность сервисов при помощи специального скрипта и распределять по ним подключения. Zen может выполнять функцию SSL-прокси, шифруя поток к клиенту, на участке Zen — бэкенд данные идут в открытом виде. Поддерживается VLAN.

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

И главное — все настройки производятся при помощи веб-интерфейса (по умолчанию на HTTPS/444, логин/пароль — admin/admin). Предлагается две версии. Бесплатная только в x86-варианте и без технической поддержки. Ее возможностей вполне хватает для большинства сетей среднего размера. Платная версия предоставляется уже в x64-сборке. Развернуть готовую систему очень просто, на сайте доступна вся необходимая информация по настройкам (на английском).

Все настройки Zen Load Balancer производятся через веб-интерфейс

Как видим, выбирать есть из чего. Каждый продукт имеет свои сильные и слабые стороны, зная которые легко определиться, какой из них подходит для определенной ситуации. Так, HAProxy подкупает производительностью, BalanceNG — функциональностью, простотой в настройках. Pound отличается возможностью разборки HTTP, а Crossroads — гибкостью. Если все же нужен веб-интерфейс, то альтернативы Zen Load Balancer нет, ну если только не хочется платить за Snapt для HAProxy.

Облачные сервисы для балансировки нагрузки

С ростом популярности облачных сервисов все больше систем размещаются на внешних площадках, образуя гибридные облака. Большинство разработчиков предлагает ко всему прочему и возможность балансировки нагрузки, это очень удобно, так как не требует от клиента установки дополнительного оборудования и готово к применению почти сразу. Хотя возможностей по управлению такой способ дает, как правило, меньше. Все основные игроки уже предложили свои решения. Например, Amazon Route 53, являющийся частью Amazon Web Services и предоставляющий балансировку при помощи Round Robin DNS. Стоимость услуги небольшая и составляет один доллар в месяц, плюс 0,50 доллара за первый миллион запросов и 0,25 за каждый следующий. Предусмотрен удобный API для редактирования, добавления и удаления записей.
Также нужная функциональность доступна в специализированных облачных продуктах — WAF или решениях для защиты от DDoS. Например, сервис Akamai Global Traffic Management Akamai.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock detector