Балансировка нагрузки сети: описание технологии

Кластерная разработка балансировки нагрузки сети (Network Load Balancing), включенная в операционные системы Microsoft® Windows® 2000 Advanced Server и Datacenter Server, увеличивает масштабируемость и отказоустойчивость критически принципиальных служб, работающих по протоколам TCP/IP, таких как веб-сервер, службы терминалов, службы виртуальных личных сетей и потокового мультимедийного вещания. Служба балансировки нагрузки, являющаяся компонентом ОС Windows 2000, работает на всех узлах кластера и не требует для работы специального оборудования. Для обеспечения масштабируемости производительности служба БНС (Балансировка нагрузки сети, Network Load Balancing) распределяет поток данных, передаваемых по протоколу IP, между несколькими узлами кластера. Кроме этого, служба обеспечивает высшую отказоустойчивость, автоматом обнаруживая сбои узлов и перераспределяя поток данных посреди оставшихся. Служба БНС включает функции удаленного управления и позволяет производить чередующиеся обновления для ОС Windows NT® 4.0 и более поздних версий.

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

Архитектура службы балансировки нагрузки сети

Для заслуги наибольшей пропускной возможности и отказоустойчивости служба БНС употребляет вполне распределенную программную архитектуру. На всех узлах кластера параллельно производятся однообразные драйверы службы БНС. Эти драйверы объединяют все узлы в единую сеть для обработки входящего потока данных, поступающих на основной Айпишник кластера (и на дополнительные IP-адреса многосетевых узлов). Для каждого отдельного узла драйвер делает функции фильтра меж драйвером сетевого адаптера и стеком протоколов TCP/IP, позволяя распределять поток данных, получаемых узлом. Таким макаром, поступающие запросы делятся и распределяются меж узлами кластера.

Балансировка нагрузки сети: описание технологии

Набросок 1 – Узел кластера. Ядро Windows 2000

Служба БНС работает как сетевой драйвер, расположенный в сетевой модели ниже высокоуровневых протоколов приложений, таких как HTTP и FTP.

Такая архитектура позволяет достигнуть наибольшей пропускной возможности за счет использования широковещательной сабсети для доставки поступающих данных на все узлы кластера, которая позволяет обойтись без маршрутизации входящих пакетов. Так как фильтрация ненадобных пакетов работает резвее, чем маршрутизация (при которой нужно получить, проверить, перезаписать и повторно выслать каждый пакет), при использовании службы БНС достигается более высочайшая пропускная способность сети по сравнению с решениями на основе диспетчеризации. При росте скорости работы сервера и сети пропорционально вырастает и производительность; таким макаром устраняется зависимость от производительности аппаратных решений для рассредотачивания нагрузки на основе маршрутизации. К примеру, в гигабитных сетях служба БНС показывает пропускную способность до 250 Мб/с.

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

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

На сто процентов конвейерный механизм службы БНС при поступлении пакетов сразу передает их в стек протоколов TCP/IP и получает пакеты от драйвера сетевого адаптера. Это понижает общее время обработки потока данных и задержку, так как стек TCP/IP может обрабатывать пакет сразу с получением драйвером NDIS последующего пакета. Не считая того, требуется меньше ресурсов для координации операций стека TCP/IP и драйвера, а также, в большинстве случаев, в памяти не создаются дополнительные копии пакетов данных. При отправке пакетов служба БНС также обеспечивает завышенную пропускную способность, маленькое время задержки и отсутствие затратных издержек производительности за счет роста числа пакетов TCP/IP, которые могут быть высланы за один вызов NDIS. Для заслуги настолько высочайшей производительности служба БНС употребляет пул буферов и дескрипторов пакетов, применяемый для конвейерных операций со стеком TCP/IP и драйвером NDIS.

Рассредотачивание потока данных кластера

Для рассредотачивания входящего потока данных меж всеми узлами кластера служба БНС употребляет широковещательные либо многоадресные пакеты протокола второго уровня. В используемом по умолчанию одноадресном режиме служба БНС переназначает аппаратный (MAC) адресок сетевого адаптера, для которого она включена (именуемого адаптером кластера), и всем узлам в кластере назначается один MAC-адрес. Таким макаром, поступающие пакеты принимаются всеми узлами кластера и передаются службе БНС для фильтрации. Для обеспечения уникальности MAC-адрес формируется на основании основного Айпишники кластера, обозначенного на странице параметров службы БНС. Для основного Айпишники 1.2.33.44 будет употребляться MAC-адрес одноадресного режима 02-BF-11-2-33-44. Служба БНС автоматом изменяет МАС-адрес адаптера кластера методом внесения конфигурации в реестр и последующей перезагрузки драйвера адаптера; при всем этом не требуется перезапуск операционной системы.

Если узлы кластера подключены к коммутатору, а не к концентратору, внедрение общего MAC-адреса может вызвать конфликт, так как коммутаторы второго уровня способны работать только с уникальными MAC-адресами источников на всех портах. Для устранения данной задачи служба БНС видоизменит MAC-адрес источника в исходящих пакетах; MAC-адрес кластера 02-BF-11-2-33-44 преобразуется в адрес вида 02-h-11-2-33-44, где h — ценность узла снутри кластера (задается в окне параметров службы БНС). Таким макаром, коммутатору не передается фактический MAC-адрес кластера, и в результате поступающие в кластер пакеты данных доставляются на все порты коммутатора. Если узлы кластера подключены заместо коммутатора конкретно к концентратору, в одноадресном режиме службы БНС маскировку начального MAC-адреса можно отключить, чтоб заблокировать лавинную маршрутизацию исходящих пакетов в коммутаторе. Отключение маскировки делается методом присвоения в реестре параметру MaskSourceMAC службы БНС значения 0. Внедрение коммутатора исходящих данных по протоколу третьего уровня позволяет также избежать лавинной маршрутизации.

У одноадресного режима работы службы БНС имеется побочный эффект блокирования конкретной связи меж сетевыми адаптерами узлов кластера. Так как исходящие пакеты, отправляемые другому узлу кластера, посылаются на MAC-адрес, совпадающий с адресом отправителя, эти пакеты ворачиваются отправителю сетевым стеком и никогда не попадут в сеть. Это ограничение можно обойти, установив в каждый сервер кластера 2-ой сетевой адаптер. В таком случае служба БНС обрабатывает данные только от сетевого адаптера сабсети, от которого поступают клиентские запросы, а второй адаптер, обычно, подключается к отдельной сабсети, созданной для связи с другими узлами и серверами файлов и баз данных. Для ритмических сообщений и удаленного управления употребляется только сетевой адаптер кластера.

Необходимо подчеркнуть, что ограничения одноадресного режима службы БНС не влияют на подключения узлов кластера к узлам, не включенным в кластер. Поток данных из сети, поступающий на выделенный IP-адрес (на адаптер кластера), получают все узлы кластера, так как они употребляют однообразный MAC-адрес. Так как служба БНС никогда не передает распределенные данные на выделенный Айпишник кластера, они доставляются конкретно стеку протоколов TCP/IP узла-адресата. На других узлах служба БНС обрабатывает эти пакеты как уже распределенный поток данных (так как Айпишник получателя не совпадает с выделенными Айпишниками других узлов): они могут быть переданы стеку TCP/IP, который их отклонит. Передача лишнего объема данных на выделенные IP-адреса при работе в одноадресном режиме может привести к падению производительности, так как стек TCP/IP вынужден отклонять огромное количество «чужих» пакетов.

Потому в службе БНС имеется 2-ой режим, обеспечивающий рассредотачивание входящего потока данных всем узлам кластера. При использовании многоадресного режима заместо конфигурации МАС-адреса адаптера кластера ему присваивается широковещательный адресок второго уровня. Основному Айпишнику кластера 1.2.33.44 будет при всем этом соответствовать широковещательный MAC-адрес03-BF-11-2-33-44. Так как у каждого узла сохраняется уникальный МАС-адрес, в этом режиме нет необходимости устанавливать 2-ой сетевой адаптер для связи меж узлами кластера. В нем также отсутствует падение производительности при использовании выделенных Айпишников.

Для одновременной доставки входящего потока данных всем узлам кластера в однонаправленном режиме работы службы БНС употребляется лавинная маршрутизация (доставка пакетов во все порты коммутатора, не считая начального). При использовании многоадресного режима коммутаторы также во многих случаях посылают пакеты во все порты для доставки широковещательных данных. Тем не менее, в многоадресном режиме сисадмин имеет возможность ограничить лавинную маршрутизацию, настроив в коммутаторе виртуальную сеть для портов, относящихся к узлам кластера. Это может быть изготовлено методом ручной опции коммутатора либо с помощью протоколов IGMP (Internet Group Management Protocol, межсетевой протокол управления группами) и GARP. Текущая версия службы БНС не имеет автоматической поддержки протоколов IGMP и GMRP.

Она поддерживает протокол ARP (Address Resolution Protocol, протокол разрешения адресов), нужный для разрешения основного Айпишника и других виртуальных Айпишников в широковещательный MAC-адрес кластера. (Выделенный IP-адреспо-прежнему разрешается в МАС-адрес адаптера кластера.) Опыт указывает, что маршрутизаторы Cisco не принимают сигнал ARP от кластера, разрешающего однонаправленные Айпишника в широковещательные MAC-адреса. Эту делему можно обойти, добавив в маршрутизатор статическую запись ARP для каждого виртуального Айпишника. Широковещательный МАС-адрес можно поглядеть в окне параметров службы БНС либо с помощью программки удаленного управления Wlbs.exe. В используемом по умолчанию однонаправленном режиме данная неувязка отсутствует, так как MAC-адрес кластера совпадает с однонаправленным MAC-адресом.

Служба БНС не управляет никакими входящими пакетами данных, не считая данных по протоколам TCP, UDP и GRE (часть потока данных PPTP) для обозначенных портов. Она не фильтрует данные по протоколам IGMP, ARP (за исключением обозначенных выше), ICMP либо другим IP-протоколам. Все данные по этим протоколам передаются стеку TCP/IP в неизменном виде на всех узлах кластера. В результате для неких TCP/IP-программ «точка-точка» (к примеру, ping) при использовании Айпишники кластера могут генерироваться дублирующиеся отклики. Благодаря надежности протокола TCP/IP и его возможности обрабатывать дублированные датаграммы, другие протоколы продолжают верно работать в кластере. Чтоб избежать данной препядствия, для таких программ можно использовать выделенный Айпишник.

Метод балансировки нагрузки

Для рассредотачивания подключаемых клиентов меж узлами кластера служба БНС употребляет стопроцентно распределенный метод фильтрации. Этот метод был избран для предоставления узлам кластера способности стремительно и независимо друг от друга принимать решения о распределении нагрузки для каждого входящего пакета. Метод был оптимизирован для обеспечения статистически равномерного рассредотачивания нагрузки по большому количеству клиентских узлов, выполняющих неизменные, относительно маленькие запросы (таковой тип нагрузки типичен, к примеру, для веб-серверов). Когда количество клиентов невелико и/или объем запросов клиентов изменяется в широких границах, метод рассредотачивания нагрузки службы БНС наименее эффективен. Тем не менее, простота и скорость работы этого метода позволяют обеспечивать очень высшую производительность, высшую пропускную способность и низкое время отклика для разных типов приложений клиент/сервер.

Служба БНС распределяет поступающие клиентские запросы, направляя определенный процент новых запросов каждому узлу кластера. Процент распределяемой загрузки задается в окне «Свойства балансировки нагрузки сети» для каждого спектра номеров портов, нагрузку которых нужно распределять. Метод не способен приспособиться к изменениям нагрузки каждого узла кластера (в отличие от нагрузки ЦП и использования памяти). Но сравнение изменяется при изменении количества узлов кластера, в соответствии с которым изменяются проценты рассредотачивания нагрузки.

При анализе поступающего пакета все узлы сразу делают статическое сравнение для резвого выбора узла, который будет обрабатывать пакет. Для сравнения употребляется функция случайного выбора, рассчитывающая ценность узла на основании IP-адреса клиента, номера порта и других данных о состоянии, поддерживаемых для оптимизации рассредотачивания нагрузки. Избранный узел передает пакет из сетевого стека в стек TCP/IP, а другие узлы отклоняют этот пакет. Схема сравнения изменяется только при конфигурациях состава узлов кластера; в результате композиция определенного Айпишники клиента и номера порта всегда сопоставлена одному узлу кластера. Но узел кластера, которому сопоставлен IP-адрес и порт клиента, нельзя найти заблаговременно, потому что функция случайного выбора учитывает текущее и прошлое членство в кластере для минимизации конфигураций схемы сравнения.

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

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

Вследствие стохастического нрава набора клиентов могут наблюдаться малозначительные временные конфигурации равномерности рассредотачивания нагрузки. Необходимо подчеркнуть, что достижение полностью равномерного рассредотачивания нагрузки меж всеми узлами кластера потребовало бы значимого роста производительности (пропускной возможности и времени отклика), которые расходовались бы на измерение и реакцию на колебания нагрузки. Цена ресурсов, которые дополнительно потребовались для этого, следует сравнить с потенциальными преимуществами очень рационального использования ресурсов узлов кластера (в основном ресурсов ЦП и оперативной памяти). В любом случае нужно обеспечить избыточность ресурсов кластера для обеспечения обработки нагрузки в случае сбоя 1-го из узлов. В службе БНС употребляется обычный, но в тоже время действенный метод рассредотачивания нагрузки, обеспечивающий очень вероятную производительность и отказоустойчивость.

Характеристики привязки клиентов службы БНС реализованы за счет конфигурации входных данных метода статического сравнения. При выборе привязки клиентов в окне «Свойства балансировки нагрузки сети» номера портов клиентов не используются для сравнения. Потому все запросы от одного клиента всегда направляются на один узел кластера. Стоит отметить, что для этого ограничения значение времени ожидания не указывается (как это обычно бывает в решениях с диспетчеризацией), и это сравнение будет действовать вплоть до изменения состава кластера. При выборе режима привязки 1-го клиента метод сравнения употребляет полный Айпишник клиента. Но при выборе режима привязки адресов класса C алгоритм употребляет только часть адреса клиента, относящуюся к классу С (1-ые 24 разряда). Таким макаром, все клиенты из одного адресного места класса С сопоставлены одному узлу кластера.

При сравнении клиентов узлам служба БНС не может конкретно выслеживать границы сеансов (таких, как сеансы по протоколу SSL), так как решения о распределении нагрузки принимаются при установлении подключений TCP до поступления пакетов, содержащих данные сетевых приложений. Не считая того, служба не способна выслеживать границы потоков по протоколу UDP, так как границы логических сеансов определяются приложениями. Заместо этого характеристики привязки службы БНС употребляются для поддержания сеансов клиентов. При нарушении либо выключении узла от кластера все подключения клиентов к нему разрываются. После определения нового состава кластера с помощью процедуры схождения (см. ниже) клиенты, которые были сопоставленные выбывшему узлу, сопоставляются одному из оставшихся узлов. При всем этом сбой не влияет на сеансы всех других клиентов, которых кластер продолжает бесперебойно обслуживать. Таким макаром, метод рассредотачивания нагрузки минимизирует перерывы в обслуживании клиентов при нарушении.

При включении в кластер нового узла инициируется процедура схождения для учета нового члена кластера. После окончания схождения новенькому узлу сопоставляется минимум клиентов. Служба БНС выслеживает TCP-подключения к каждому узлу, и после окончания текущих подключений последующие подключения затрагиваемых клиентов будут обрабатываться новым узлом. Обработка UDP-потоков новым узлом начинается немедля. Это может привести к разрыву неких клиентских сеансов, включающих несколько подключений либо UDP-потоков. Как следует, узлы нужно добавлять в кластер в моменты, когда это приведет к разрыву малого количества сеансов. Чтоб на сто процентов убрать эту делему, состояние сеансов должно управляться серверными приложениями, чтоб иметь возможность вернуть либо возобновить сеанс с любого узла кластера. К примеру, состояние сеанса может передаваться серверу внутренней базы данных либо сохраняться на стороне клиента в файлах cookie. Состояние SSL-сеансов восстанавливается автоматом методом повторной аутентификации клиента.

GRE-поток снутри протокола PPTP — это особенный случай сеанса, на который не влияет добавление нового узла в кластер. Так как GRE-поток ограничен в пределах продолжительности управляющего TCP-сеанса, служба БНС выслеживает этот поток вместе с управляющим сеансом. Таким макаром, предотвращается разрыв туннельного подключения PPTP при добавлении нового узла.

Схождение

Узлы кластера, работающего под управлением службы БНС, временами обмениваются многоадресными либо широковещательными ритмическими сообщениями. Это позволяет держать под контролем состояние кластера. При изменении состояния кластера (нарушении, выключении либо включении нового узла) служба БНС инициирует процесс, именуемый схождением, при котором узлы обмениваются ритмическими сообщениями для определения нового узла, текущего состояния кластера и выбора узла с наиболее высочайшим ценностью в качестве нового основного узла. При достижении узлами соглашения о текущем состоянии кластера конфигурации членства в кластере после схождения заносятся в журнал событий Windows 2000.

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

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

В одноадресном режиме ритмические сообщения рассылаются каждым узлом широковещательно, а в многоадресном режиме — многоадресно. Каждое ритмическое сообщение занимает один кадр Ethernet и помечено главным Айпишником кластера, чтоб обеспечить возможность работы нескольких кластеров снутри одной сабсети. Ритмическим сообщениям назначается или настраиваемое значение, или шестнадцатеричное значение 886F. По умолчанию период отправки ритмических сообщений равен одной секунде. Это значение можно поменять с помощью параметра реестра AliveMsgPeriod. При выполнении процедуры схождения для ускорения процесса период отправки сообщения понижается в два раза. Даже в больших кластерах полоса пропускания, занимаемая ритмическими сообщениями, очень невелика (к примеру, 24 КБ/с в 16-узловом кластере).

При работе службы БНС подразумевается, что узел кластера работает верно до тех пор, пока он участвует в обмене ритмическими сообщениями меж узлами кластера. Если другие узлы не получают от одного из серверов ритмические сообщения в течение нескольких периодов обмена сообщениями, запускается процедура схождения. Количество пропущенных сообщений, после которого начинается схождение, по умолчанию равно 5, но его можно поменять с помощью параметра реестра AliveMsgTolerance.

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

Удаленное управление

Механизм удаленного управления службой БНС употребляет протокол UDP по порту 2504. Его датаграммы отправляются на основной IP-адрес кластера. Так как датаграммы обрабатываются драйверами службы балансировки нагрузки на каждом узле кластера, они должны направляться в подсеть кластера (а не в подсеть, к которой подключен кластер). Команды удаленного управления, отдаваемые в пределах кластера, передаются в локальную сабсеть кластера в виде

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.