Когда мощности сервера уже не хватает, встает вопрос, каким путем идти дальше. Апгрейд часто не дает пропорционального прироста и к тому же не обеспечивает требуемой отказоустойчивости. Поэтому самым верным шагом будет установка второго сервера, который возьмет на себя часть нагрузки. Остается выбрать приложение, которое будет обеспечивать балансировку.
Решения для балансировки сетевой нагрузки только на первый взгляд выглядят одинаково. На самом деле в процессе участвует множество технологий и алгоритмов, поэтому найти два одинаковых продукта невозможно. Неочевидными особенностями может быть поддержка определенных протоколов (например, только 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. В принципе, сложным его назвать нельзя, особенно учитывая, что на сайте проекта доступно более десятка готовых примеров, часто нужно лишь выбрать наиболее подходящий и отредактировать под себя.
Работает на нескольких архитектурах 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.
Первоначальная цель проекта 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.
Технологии балансирования нагрузки между вычислительными ресурсами получили актуальность по мере распространения web-сайтов и других интернет-ресурсов (в том числе социальных сетей), а также приложений и данных, распределенных между удаленными площадками. В настоящее время огромное количество людей ежедневно пользуются интернет-сервисами, при доступе к которым задействуются балансировщики нагрузки. Причем в большинстве своем пользователи даже не догадываются об их существовании. В то же время если бы они отсутствовали, предоставление сервисов было бы весьма проблематичным. Так что же такое балансировщики нагрузки? Давайте разбираться.
Изначально балансировщики позиционировались как специализированные устройства, предназначенные для замены/развития существующего в то время решения задачи балансирования web-сервисов при помощи технологии DNS (Domain Name Service) по методу Round-Robin. Без использования балансировщиков DNS-сервис разрешал имя хоста только в один IP-адрес, а в случае их применения - в один из нескольких IP-адресов из заданного списка. При повышении требований к производительности вычислительного комплекса администратор мог просто установить в системе дополнительный сервер и добавить его IP-адрес в список балансирования.
Метод балансирования нагрузки по DNS между несколькими серверами содержал в себе несколько проблемных моментов. Первая проблема заключалась в том, что при использовании такой системы балансирования сложно было добиться равномерного распределения клиентских запросов между отдельными серверами. Чаще всего распределение было непрогнозируемым, т.к. балансировщик не мог получать информацию о текущей загрузке каждого сервера. Это заставляло компании приобретать более производительное серверное оборудование, чем было реально необходимо, что приводило к увеличению капитальных затрат.
В число задач балансировщиков нагрузки входило и входит по сей день обеспечение масштабируемости вычислительных комплексов, отказоустойчивости сервисов , управление серверными подключениями и защита серверного оборудования от атак злоумышленников
Вторая проблема состояла в том, что доступность приложений, TCP/UDP-портов или самих серверов никак не отслеживалась. Если сервер балансирования выходил из строя, DNS-сервер все равно продолжал направлять на него запросы клиентов. В итоге пользователи получали сообщение «сервер не доступен». Если вышедший из строя сервер (или несколько машин) выводился администратором из списка балансирования вручную, клиенты все равно продолжали пытаться осуществлять доступ к нему по его IP-адресу. В настоящее время эта проблема частично решается уменьшением значения параметра TTL в DNS-ответе. Но в случае если на DNS-сервере или рабочей станции клиента установлено игнорирование значений параметра TTL или соответствующая DNS-запись настроена статически, проблема потери доступа остается актуальной. И методы ее решения на сегодня отсутствуют.
Первым коммерческим продуктом, обеспечивающим балансирование нагрузки между IP-серверами, стало устройство Cisco LocalDirector, разработанное в июле 1996 года. Первые балансировщики (в том числе Cisco LocalDirector) были призваны не только снять проблемы балансирования нагрузки по DNS, по большому счету, они предназначались для управления мультисерверной инфраструктурой, в том числе для ее корректного масштабирования.
В настоящее время масштабируемость вычислительных комплексов обычно реализуется двумя способами: наращиванием ресурсов отдельного сервера (суперкомпьютер) или использованием нескольких низкопроизводительных серверов, обслуживающих одну и ту же задачу. Второй вариант менее затратен, поэтому более предпочтителен. Он реализуется как раз при помощи балансировщиков, поддерживающих технологию кластеризации.
Балансировщики нагрузки позволяют распределять между серверами текущий трафик приложений, а также контролировать и изменять его характеристики в соответствии с заданными правилами.
Современные балансировщики нагрузки позволяют производить контроль, распределение и изменение трафика приложений, основываясь на значениях заголовков L2-L7 сетевой модели OSI. По сути балансировщики нагрузки распознают приложения и обеспечивают их «доставку» пользователям, поэтому последнее время их стали называть контроллерами доставки приложений (Application Delivery Controller).
Системы балансирования нагрузки делятся на два типа: глобальный и локальный. Локальное балансирование нагрузки предназначено для распределения клиентских запросов между группой серверов, расположенных в пределах одной площадки. В данном случае балансировщики выступают в качестве промежуточного звена между клиентами и серверами в течение всего времени их взаимодействия. При локальном балансировании распределение клиентских запросов между серверами выполняется на основании значений заголовков L3-L7 устанавливаемого подключения.
Глобальное балансирование предназначено для распределения клиентских запросов между площадками. В данном случае системы не участвуют в передаче клиент-серверного трафика, а только перенаправляют клиентов на ту или иную площадку. При глобальном балансировании нагрузки распределение клиентских запросов между площадками выполняется при помощи механизмов DNS, HTTP redirect и т.п.
В обоих вариантах балансировщики отслеживают доступность серверного оборудования, что делает схему отказоустойчивой. Функционал локального и глобального балансирования может быть сосредоточен на одном оборудовании (Radware, Brocade, F5) или выноситься на независимые платформы (Cisco).
В настоящее время мы чаще всего сталкиваемся с задачами, требующими локального балансирования. Данный тип используется в ЦОД практически всех крупных компаний (банковский и операторский сегменты, контент-провайдеры). Локальное балансирование нагрузки чаще всего используется для следующих типов приложений:
СИСТЕМЫ БАЛАНСИРОВАНИЯ НАГРУЗКИ ДЕЛЯТСЯ НА ДВА ТИПА: ГЛОБАЛЬНЫЙ И ЛОКАЛЬНЫЙ
Глобальное балансирование нагрузки используется преимущественно контент-провайдерами для осуществления сервисов по резервированию между географически распределенными площадками. Данный тип системы чаще всего реализуется на основе технологий DNS и HTTP redirect. Недостатком глобального балансирования нагрузки является достаточно длительное время восстановления сервисов (от пары до десятков секунд) в случае выхода из строя отрезка сети или целой площадки. К тому же возможны ситуации, когда клиентские системы игнорируют значение DNS TTL, что приводит к простою доступа к сервисам вплоть до 24 часов.
Основная цель использования такого типа балансирования - оптимизация потоков данных между клиентами и серверами (доступ клиентов к ближайшему ЦОД). Также он позволяет обеспечить надежный доступ к публичным ресурсам компании в интернете через IP-адреса двух независимых операторов связи (PA-блоки). Таким образом, балансировщики нагрузки отслеживают доступность сервиса через IP-адреса обоих операторов связи, на этом основании принимается решение о направлении клиентов к тому или иному IP-адресу.
Балансировщики нагрузки обладают дополнительными функциональными возможностями. К наиболее востребованным относятся SSL-offloading, сжатие передаваемых данных HTTP и мультиплексирование TCP-соединений.
дает возможность минимизировать нагрузку на серверное оборудования ЦОД за счет переноса SSL-шифрования/дешифрования на балансировщики со встроенными аппаратными ускорителями. Этот функционал обычно используется в вычислительных комплексах, где требуется организовать безопасный доступ к сервисам для удаленных клиентов.Сжатие передаваемых данных HTTP позволяет минимизировать объем передаваемого HTTP-трафика между серверами ЦОД и рабочими станциями удаленных пользователей, тем самым ускоряя работу прикладных систем. Наиболее распространенными протоколами сжатия являются gzip и deflate. Функция сжатия передаваемых данных HTTP поддерживается любым современным браузером. Схожую задачу решают специализированные устройства - аппаратные или программные оптимизаторы трафика. В отличие от балансировщиков их необходимо устанавливать как на стороне клиента, так и на стороне сервера. С другой стороны, в оптимизаторах трафика используется другой принцип работы (на базе кэширования), и есть возможность оптимизировать работу большого числа протоколов, а не только HTTP.
Мультиплексирование TCP-соединений дает возможность минимизировать нагрузку на серверное оборудования ЦОД за счет установки всего одного соединения между балансировщиком и сервером. Таким образом, все клиентские запросы при попадании в балансировщик передаются на сервер в рамках всего одного соединения с использованием множества транзакций внутри него.
Функционал изменения заголовков L3-L7 и защиты от DoS/SYN-атак используется преимущественно в сегменте контент-провайдеров в корпоративном сегменте. Изменение заголовков L3-L7 позволяет заказчикам более гибко обрабатывать трафик приложений, контролируя доступ клиентов к сервисам. Защита от DoS-атак в соответствии с предустановленными сигнатурами предотвращает передачу вредоносного трафика серверному оборудованию. Защита от SYN-атак предупреждает перегрузку серверного оборудования «зависшими» подключениями за счет их принудительного разрыва (если нет подтверждения соединения с клиентской стороны).
Функционал перенаправления клиентских запросов на Cache-серверы применяется преимущественно в сегменте операторов связи. Он позволяет уменьшить трафик, передаваемый в сети сторонних операторов связи (соответственно уменьшается плата за peering), за счет перенаправления запросов пользователей на локальные Caсhe-серверы.
После того как мы обсудили теоретические аспекты внедрения балансировщиков нагрузки, предлагаю рассмотреть несколько реальных кейсов. Мы имеем опыт работы с разными моделями балансировщиков нагрузки: Cisco CSS/CSM, Cisco ACE, Brocade ADX, Radware Alteon (ранее Nortel), Radware OnDemand. Я хотел бы привести наиболее интересные примеры внедрения систем балансирования нагрузки на основе решений Cisco и Brocade.
Балансирование нагрузки между WEB-серверами с SSL-offloading
У одного из наших заказчиков - «ВымпелКом» («Украинские радиосистемы») - существовал ряд предпосылок для внедрения балансировщиков нагрузки. В компании было два независимых web-сервера, обеспечивавших работу абонентских сервисных приложений, при этом переключение нагрузки между web-серверами в случае выхода из строя одного из них производилось вручную. На активный web-сервер приходилась большая нагрузка (в том числе от SSL-шифрования/дешифрования).
Мы предложили решение на базе балансировщиков Cisco CSS11500. В результате их внедрение позволило включить оба web-сервера в активную обработку данных, тем самым увеличив производительность системы. SSL-шифрование и дешифрование перенесены с web-серверов на балансировщики нагрузки, благодаря чему высвободились дополнительные ресурсы web-серверов. Балансировщики нагрузки внедрены в существующую систему практически без изменения конфигурации сети (за исключением изменения правил NAT на граничном оборудовании для доступа в интернет).
Балансирование нагрузки между серверами системы Siebel CRM
Другой проект мы выполнили в «М.Видео». Там основными причинами внедрения балансировщиков нагрузки были наличие нескольких web-серверов и серверов приложений и необходимость надежного двухуровневого взаимодействия: «клиенты-web-серверы» и «web-серверы-серверы приложений». Компании требовался контроль доступности серверного оборудования по отдельным URL.
В проекте также использовались балансировщики Cisco CSS11500. Все web-серверы и серверы приложений были включены в активный процесс обработки данных, балансирование выполнялось на двух уровнях, а проверка доступности серверного оборудования - на основании контрольных URL.
Балансирование нагрузки между web-серверами социальной сети
Крупный контент-провайдер (социальная сеть) имел ряд важных предпосылок для внедрения балансировщиков нагрузки. Среди них наличие нескольких web-серверов, обрабатывающих огромные потоки данных (большое количество соединений и передаваемых данных), необходимость балансирования нагрузки на седьмом уровне модели OSI с изменением HTTP-заголовков и глобального балансирования нагрузки по весам между несколькими VIP локального балансирования. Помимо этого, компании требовалось контролировать доступность серверного оборудования по отдельным URL и ограничивать количество подключений к каждому из web-серверов.
Решение на базе балансировщиков Brocade ADX10000 позволило компании успешно решить вышеперечисленные задачи. Благодаря внедрению балансировщиков все web-серверы и серверы приложений были включены в активную обработку данных, проверка доступности серверного оборудования стала выполняться на основании контрольных URL. Балансировщики были включены в сеть в режиме One-Arm (запросы клиентов и ответы серверов поступали на одни и те же интерфейсы), что позволило не менять настройки серверного и сетевого оборудования.
Системы балансирования нагрузки становятся все более популярными, поскольку они позволяют обеспечить непрерывность бизнеса заказчиков. С каждым годом балансировщики все чаще применяются при развертывании различных прикладных систем, становясь по сути их частью. Это уже не просто балансировщики нагрузки, а контроллеры доставки приложений (Application Delivery Controller), причем их функционал все время расширяется. В будущем большинство крупных прикладных систем будет использовать балансировщики нагрузки в своей инфраструктуре.
балансировка нагрузки спаренных двигателей - — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN twin engine load balancing … Справочник технического переводчика
Балансировка колеса - У этого термина существуют и другие значения, см. Балансировка. Балансировка колёс процесс уменьшения до приемлемого уровня дисбаланса колеса, диска, ступицы, крепления колеса и элементов подвески. Содержание 1 Необходимость б … Википедия
Балансировка - Список значений слова или словосочетания со ссылками на соответствующие статьи. Если вы попали сюда из … Википедия
ГОСТ 19534-74: Балансировка вращающихся тел. Термины - Терминология ГОСТ 19534 74: Балансировка вращающихся тел. Термины оригинал документа: 2. n опорный ротор D. n Lagerrotor Е. n support rotor Single support rotor F. Rotor a n support Ротор, имеющий n опор Определения термина из разных документов:… … Словарь-справочник терминов нормативно-технической документации
Brocade Communications Systems - Brocade, Inc. Тип Публичная компания Листинг на бирже NASDAQ: BRCD Год основания … Википедия
Kerio winroute firewall - Тип межсетевой экран Разработчик Kerio Technologies ОС Windows Версия 6.7 (1 августа 2009) Лицензия … Википедия
Kerio Control - Тип межсетевой экран Разработчик Kerio Technologies Операционная система Windows Последняя версия 7.4.0 (30 октября 2012) Лицензия проприетарная Сайт … Википедия
Нагрузочное тестирование - (англ. Load Testing) определение или сбор показателей производительности и времени отклика программно технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе … Википедия
Тестирование производительности - В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Облачные вычисления - (англ. cloud computing), в информатике это модель обеспечения повсеместного и удобного сетевого доступа по требованию к общему пулу (англ. pool) конфигурируемых вычислительных ресурсов (например, сетям передачи данных,… … Википедия
В терминологии компьютерных сетей балансировка (выравнивание) нагрузки – распределение процесса выполнения заданий между несколькими серверами сети с целью оптимизации использования ресурсов и сокращения времени вычисления.
Типы серверов, которые должны быть сбалансированы:
серверные кластеры;
межсетевые экраны;
серверы инспектирования содержания (такие как AntiVirus- или AntiSpam- серверы).
Обычно системы балансировки загрузки серверов используют возможности уровня L4 (UDP/TCP). При этом контролируется доступность сервера по IP-адресу и номеру порта и принимается решение: какому из доступных серверов следует переслать запрос. Наиболее часто для выбора сервера используется карусельный алгоритм (round-robin). В этом варианте предполагается, что все запросы создают одинаковую загрузку и длительность исполнения. В более продвинутых вариантах алгоритма используется уровень занятости сервера и число активных соединений.
Раньше возможности балансировки нагрузки встраивались в саму прикладную программу или операционную систему. Современные системы балансировки нагрузки должны удовлетворять следующим требованиям:
обеспечивать управление трафиком, чтобы гарантировать доступность приложения и распределение нагрузки в условиях фермы серверов (группа серверов, соединенных сетью передачи данных и работающих как единое целое);
ускорять выполнение приложений в несколько раз;
гарантировать защиту приложений, сохранность данных и обеспечение мониторинга трафика.
Здесь важно учитывать, что доступность IP-адреса и порта еще не гарантирует доступа к приложению.
В последнее время для решения задачи балансировки нагрузки все чаще используется прикладной уровень. При этом в процессе принятия решения учитывается тип клиента, запрашиваемый URL, информация из cookie, возможности конкретного сервера и тип прикладной программы, что позволяет оптимизировать использование ресурсов системы.
Довольно существенные преимущества может предоставить система GSLB (Global Server Load Balancing), которая способна решать задачу балансировки для произвольно расположенных ферм серверов с учетом их удаленности от клиента. Эта система может поддерживать несколько разных алгоритмов распределения нагрузки и обеспечивать оптимальное обслуживание клиентов, разбросанных по всему миру. Для администраторов система дает возможность формирования гибкой политики управления ресурсами.
Одним из способов ускорения обслуживания является кэширование. В случае хорошо сконфигурированного кэша доля запросов, удовлетворяемых кэшем, может достигать 40%. При этом ускорение обслуживания может быть улучшено в 30 раз.
Еще одним методом ускорения обслуживания может служить архивация данных, так как в этом варианте понижается уровень перегрузки каналов сети.
Управление балансировкой нагрузки можно совместить с функцией прикладного межсетевого экрана (70% успешных вторжений использует уязвимости приложений) и с использованием SSL по VPN-туннелю. SSL – Secure Sockets Layer – криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером.
Для достижения максимальной пропускной способности и отказоустойчивости межсетевые экраны позволяют распределить или сбалансировать нагрузку, используя все имеющиеся каналы Интернета (серверов) одновременно. Например, можно избежать такой ситуации, когда передаваемые по сети пакеты идут через одного провайдера, в то время как выход в Интернет через другого провайдера простаивает без дела. Или распределить сервисы и направить трафик через все имеющиеся Интернет-каналы. Возможна настройка балансировки нагрузки, если соединения с провайдерами осуществляются с разными типами подключения (Static IP, PPPoE, PPTP/L2TP), а также – для балансировки трафика, проходящего через VPN-туннели, установленные на разных физических интерфейсах.
Рис. 4.12. Балансировка нагрузки по нескольким маршрутам
В межсетевых экранах D-Link серии NetDefend предусмотрена функция, предназначенная для балансировки сетевой нагрузки по разным маршрутам – Route Load Balancing (RLB ) , возможности которой обеспечивают:
балансировку трафика между интерфейсами на основе политик;
балансировку нагрузки трафика при одновременном множественном доступе в Интернет, пользуясь услугами двух и более провайдеров;
балансировку трафика, проходящего через VPN-туннели, установленные на разных физических интерфейсах.
Функция балансировки нагрузки в межсетевых экранах NetDefend активируется на основе таблицы маршрутизации путем создания объекта RLB Instance , в котором определены два параметра: таблица маршрутизации и RLB-алгоритм. С таблицей маршрутизации может быть связан только один объект Instance.
Рис. 4.13. Выбор алгоритма распределения нагрузки в межсетевых экранах NetDefend
Есть возможность выбрать один из алгоритмов распределения нагрузки между Интернет-интерфейсами:
Алгоритм Round Robin распределяет нагрузку между интерфейсами WAN1 и WAN2 последовательно (поочередно). Каждый раз, когда возникает новая исходящая сессия с интерфейса LAN, выбирается интерфейс WAN1 или WAN2 для отправки пакетов. В дальнейшем, пакеты данной сессии будут использовать ранее определенный WAN-интерфейс. TCP-сессия открывается и закрывается на одном и том же WAN-интерфейсе.
Алгоритм Destination позволит избежать проблем с некоторыми протоколами при использовании балансировки, например FTP. Данный алгоритм работает аналогично алгоритму Round Robin, за исключением того, что все данные к удаленному хосту идут через тот интерфейс, через который соединение было установлено.
Значение Spillover определяет предельное значение нагрузки для основного WAN-порта (Routing → Route Load Balancing > Algoritm Setings ) . При достижении этой нагрузки за указанный период начнет использоваться второй WAN-порт (для новых сессий). Как только загрузка основного канала упадет, новые сессии будут открываться на нем.
Round Robin
Метрика каждого маршрута по умолчанию равна нулю. При использовании взаимосвязанных алгоритмов Round Robin и Destination можно устанавливать разные значения метрик, позволяющие создать приоритет выбора маршрутов. Маршруты с минимальным значением метрики будут выбираться чаще, чем маршруты с более высоким значением.
Если в сценарии с двумя Интернет-провайдерами (часто встречается выражение "ISP-провайдер", т.е. Internet Service Provider) требуется, чтобы большая часть трафика проходила через одно из ISP-подключений, то следует активировать RLB и назначить меньшее значение метрики для маршрута основного ISP-подключения (например, 90) относительно второго (например, 100).
Если задача заключается в равномерной балансировке трафика между двумя Интернет-провайдерами, то значение метрик для обоих маршрутов следует назначать одинаковое.
Использование метрик маршрута с алгоритмом Spillover
При использовании алгоритма Spillover для каждого маршрута обязательно должна быть определена метрика. В этом случае система NetDefendOS всегда выбирает маршрут с самым низким значением метрики. Алгоритм не предназначен для работы с одинаковыми метрическими значениями маршрутов, поэтому администратору следует устанавливать различные значения метрик для всех маршрутов, к которым применяется алгоритм Spillover .
Значение метрики определяет порядок, в соответствии с которым трафик перенаправляется на другой маршрут после того, как для выбранного маршрута превышено допустимое значение передаваемого трафика.
Можно создать несколько альтернативных маршрутов с различными метрическими значениями, для каждого из которых определена пороговая величина настроек алгоритма – Spillover Setting – для каждого интерфейса. Сначала выбирается маршрут с минимальной метрикой; после того как превышен допустимый порог настроек алгоритма, будет выбран следующий маршрут.
Если на всех альтернативных маршрутах достигнуты пороговые значения Spillover Setting, то маршрут не меняется.
ВНИМАНИЕ : значение метрики на интерфейсах (маршрутах), которые используются в балансировке, должно быть установлено выше, чем для остальных интерфейсов (маршрутов). Чем ниже значение метрики на интерфейсе (маршруте), тем чаще этот интерфейс (маршрут) будет использован для установки соединения, относительно интерфейса (маршрута) с большим значением метрики. Доля использования интерфейсов (маршрутов) будет пропорциональна разнице между значениями метрик на этих интерфейсах (маршрутах).
Балансировка нагрузки сети и НА-кластеризация (резервирование устройств) межсетевых экранов NetDefend
Высокий уровень сетевой отказоустойчивости достигается за счет использования двух межсетевых экранов NetDefend: основного устройства (master) и резервного устройства (slave). Основной и резервный межсетевые экраны взаимосвязаны и составляют логический HA-кластер.
Межсетевые экраны NetDefend не поддерживают балансировку нагрузки в НА-кластеризации устройств, т.е. распределение нагрузки между ними не обеспечиваетс , так как одно устройство всегда является активным (active), в то время как другое находится в режиме ожидания (passive).
Рис.
4.14.
НА-кластеризация
межсетевых экранов NetDefend
Что есть балансировка нагрузки? Фактически, это распределение входящих сетевых подключений между несколькими вычислительными узлами. При этом, использование для этих целей аппаратных или программных решений, а так же применяемый алгоритм распределения сути, совершенно не меняет. Но, благодаря распределению нагрузки можно решить две достаточно серьезные проблемы.
Во-первых, это распределение нагрузки между вычислительными узлами в ситуации, когда ресурсов одного сервера не достаточно и вертикальное наращивание его мощности уже не возможно. В таком случае, необходимо добавление еще одной вычислительной единицы и применение одного из видов балансировки.
Во-вторых — обеспечение доступности. Как известно, отказоустойчивость любой системы, будь то аппаратное решение или программное достигается путем дублирования основных компонентов. К сожалению, не существует абсолютно надежных жестких дисков, RAID-контроллеров и прочего оборудования, а современный уровень программирования не гарантирует отсутствие сбоев в ПО. По этой причине, при построении отказоустойчивых сервисов, дублируется все, сетевые контроллеры, коммутаторы и в конце концов сами вычислительные узлы. Например, нагрузка создаваемая на один сервер может быть не большой, но при этом хочется, что бы выход одного или нескольких узлов не привел к простою сервиса. В этом случае решением снова может стать балансировщик нагрузки.
По сути, все существующие виды балансировки можно разделить на три глобальные группы отличающиеся между собой «глубиной» анализа входящих запросов и степенью проверки доступности серверов.
В эту группу входят способы балансировки которые ни каким образом не анализируют входящий трафик и не проверяют доступность вычислительных узлов находящихся за ними. Самый яркий представитель данной группы, это распределение запросов с помощью DNS о котором ниже.
Пожалуй, самый распространенный метод. Основан на том, что спецификация DNS позволяет создавать несколько одинаковых А-записей с отличными IP-адресами. Например, можно завести две записи для узла srv-01.company.com с различными IP-адресами принадлежащих, разным серверам. Дополнительно, должна быть включена специальная опция (Round robin) на DNS-сервере. В результате, при каждом новом запросе записи srv-01.company.com будут отдаваться разные IP-адреса, что приведет к равномерному распределению подключений между узлами.
Но, при всей легкости и дешевизне данного решения, имеется ряд ограничений. Во первых, нет никаких методов проверки доступности узлов. То есть, сервер может выйти из строя, но DNS все равно будет отдавать его IP-адрес клиентам. Во вторых, не учитывается число текущих сессий на том или ином узле. Может получиться ситуация, когда на одном из серверов, открытых сессий значительно больше чем на остальных, при этом подключения все равно будут распределяться равномерно. Ну и в-третьих, DNS не учитывает к какому серверу был подключен пользователь в прошлый раз. Возможно, что при каждом новом подключении, например, к терминалу или к веб-серверу, будет открываться новая сессия на другом узле, что может быть не желательно.
Отдельно, в этом пункте хочется выделить сервисы типа Amazon Route 53 . Это облачный DNS-хостинг позволяющий кроме стандартных функций, указывать «вес» одинаковых А-записей, что позволяет распределять входящие запросы более гибко. Кроме этого, возможна интеграция с облачным балансировщиком нагрузки Elastic Load Balancing доступным в Amazon Web Services, что позволяет добиться еще более тонкой балансировки.
Суть метода в разделении всех пользователей на несколько групп и подключение их к различным серверам. Например, в организации работает два терминальных сервера одинаковой производительности.Половине пользователей на рабочем столе создается ярлык для подключения к первому серверу, а оставшимся ко второму. Дополнительно, на случай отказа текущего узла создается ярлык для подключения к другому серверу который будет являться резервным. Пожалуй, подобный метод применим лишь в небольших организациях, причем целью такого распределения является именно отказоустойчивость, а не балансировка. При этом нет необходимости в дополнительном оборудовании и программном обеспечении, но придется немного поработать ручками.
Это самый универсальный и распространенный механизм. Одинаково применим для TCP и UDP протоколов, а соответственно им можно распределять трафик практически любого сервиса. На этом уровне во входящих пакетах проверяется лишь IP-адрес и номер порта назначения. В случае совпадения с одним из правил, трафик будет попросту перенаправлен на указанные сервера, с помощью механизма sNAT в установленном порядке. Содержимое пакетов не проверяется. Так же нет никаких особых техник проверки доступности вычислительных узлов. Выполняется простая проверка доступности адреса и порта. В случае если порт открыт, сервер считается доступным и к нему продолжают отправляться запросы.
По такому механизму работает большинство популярных программных и аппаратных балансировщиков, в том числе Network Load Balancing (NLB) используемый в Windows Server. Так же, к этой категории можно отнести популярные нынче облачные сервисы типа Elastic Load Balancing от Amazon, упомянутый выше.
Динамично развивающийся вид распределения нагрузки на уровне приложений. Такие балансировщики еще называют контроллерами доставки приложений. Ориентированы на работу с высокоуровневыми протоколами. В основном HTTP\HTTPS. Здесь, как и в случае с предыдущим видом описываются правила. При установке соединения на некотором порту, пакеты перенаправляются на указанные адреса и порты вычислительных узлов. Но, при выборе конкретного сервера для ретрансляции на него трафика, учитывается тип клиента, URL, содержимое cookie, запрашиваемый контент и некоторые другие параметры. Кроме этого, проверка доступности сервиса на вычислительных узлах, проверяется значительно интеллектуальнее. Например, может запрашиваться некоторый URL и проверяться его содержимое.
Еще одной отличительной чертой этого типа от L4 является то, что сервера в кластере могут быть не идентичными. Например, одни узлы могут поставлять статические данные типа фото и видео а другие серверы доставляют контент с помощью скриптов, HTML и CSS. В таком случае, могут быть созданы правила для каждого типа контента с особыми алгоритмами перенаправления трафика на различные группы серверов. В этой категории, так же существует еще один класс профильных балансировщиков, типа Citrix NetScaler . Это решение специализируется на распределении нагрузки и повышении производительности продуктов Citrix (XenApp, XenDesktop), а так же веб-приложений. Кроме продвинутой балансировки он умеет выполнять компрессию контента, мощное кэширование, обеспечивает шифрование, а так же анализ трафика и его фильтрацию. Это лишь небольшая часть его возможностей, которые заслуживают отдельной статьи.
