x
© 1995-2021 Компания «Инфосистемы Джет»
Проектировщики. Балансировщики нагрузки: практические аспекты внедрения
Сетевые решения

Технологии балансирования нагрузки между вычислительными ресурсами получили актуальность по мере распространения web-сайтов и других интернет-ресурсов (в том числе социальных сетей), а также приложений и данных, распределенных между удаленными площадками.

Сетевые решения

Проектировщики. Балансировщики нагрузки: практические аспекты внедрения

17.09.2012

Посетителей: 440

Просмотров: 408

Время просмотра: 6.8 мин.

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

 

В настоящее время мы чаще всего сталкиваемся с задачами, требующими локального балансирования. Данный тип используется в ЦОД практически всех крупных компаний (банковский и операторский сегменты, контент-провайдеры). Локальное балансирование нагрузки чаще всего используется для следующих типов приложений:

 

  • почтовые системы;
  • web-системы (отдельные web-серверы и Frontend-сегменты сложных прикладных систем);
  • системы DNS;
  • системы контроля доступа (Firewall).

 

СИСТЕМЫ БАЛАНСИРОВАНИЯ НАГРУЗКИ ДЕЛЯТСЯ НА ДВА ТИПА: ГЛОБАЛЬНЫЙ И ЛОКАЛЬНЫЙ

 

Глобальное балансирование нагрузки используется преимущественно контент-провайдерами для осуществления сервисов по резервированию между географически распределенными площадками. Данный тип системы чаще всего реализуется на основе технологий DNS и HTTP redirect. Недостатком глобального балансирования нагрузки является достаточно длительное время восстановления сервисов (от пары до десятков секунд) в случае выхода из строя отрезка сети или целой площадки. К тому же возможны ситуации, когда клиентские системы игнорируют значение DNS TTL, что приводит к простою доступа к сервисам вплоть до 24 часов.

 

Основная цель использования такого типа балансирования – оптимизация потоков данных между клиентами и серверами (доступ клиентов к ближайшему ЦОД). Также он позволяет обеспечить надежный доступ к публичным ресурсам компании в интернете через IP-адреса двух независимых операторов связи (PA-блоки). Таким образом, балансировщики нагрузки отслеживают доступность сервиса через IP-адреса обоих операторов связи, на этом основании принимается решение о направлении клиентов к тому или иному IP-адресу.

 

Дополнительные возможности

 

Балансировщики нагрузки обладают дополнительными функциональными возможностями. К наиболее востребованным относятся SSL-offloading, сжатие передаваемых данных HTTP и мультиплексирование TCP-соединений.

 

SSL-offloading дает возможность минимизировать нагрузку на серверное оборудования ЦОД за счет переноса 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), причем их функционал все время расширяется. В будущем большинство крупных прикладных систем будет использовать балансировщики нагрузки в своей инфраструктуре.

Уведомления об обновлении рубрик – в вашей почте

Виртуализация – свобода выбора, гибкость и мощные средства управления

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

BI в формате Oracle

Компания Oracle представлена на рынке систем бизнес-анализа достаточно давно. Первоначально основой BI-платформы, предлагаемой вендором, служил Oracle Discoverer, однако после приобретения компании Siebel за основу был взят продукт Siebel Analytics.

Принцип службы поддержки - преемственность опыта

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

Эволюция ИТ-аутсорсинга

Слово «аутсорсинг» стал привычным уже не только для специалистов, но и для обывателей. Но смысл, который тот или иной человек вкладывает в этот термин, подчас оказывается разным.

Результаты тестирования Oracle Exadata Database Machine

С аппаратной точки зрения Exadata представляет собой сбалансированное под задачи Oracle Database стандартное Oracle/Sun Hardware решение на основе платформы Intel x86. Но «волшебством» Exadata является специальное ПО, функционирующее на серверах хранения – Exadata Software.

В России проведено первое сравнение вендоров Wi-Fi 6. Что выяснили специалисты тестовой лаборатории «Инфосистемы Джет»?

В чем преимущества Wi-Fi 6? Особенности решений от Huawei, Cisco, Aruba и Ruijie? Результаты тестирования технологии в нашей лаборатории?

Важно найти баланс между внутренней и внешней экспертизой

Сергей Сергеев, ИТ-директор Группы компаний «М.Видео-Эльдорадо», использующей ИТ-аутсорсинг для поддержки операционной деятельности, в интервью нашему изданию рассказал о преимуществах работы с подрядчиками, тенденциях развития ИТ в российском ритейле, а также об опыте использования ML‑технологий.

Хранить или не хранить: больше не вопрос …

Все в нашей жизни меняется: меняется рынок, меняются сами банки, меняются требования, которые банки выставляют к своим информационным системам, меняются и сами информационные системы.

Думы об аутсорсинге

Начать эту статью мне хотелось бы перифразом Владимира Маяковского: если ИТ-аутсорсинг выбирают, значит это кому-нибудь нужно. Возникают вопросы - кому именно и в каких ситуациях?

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на рубрику






      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня