Балансировщик f5 что это
Краткий Best practice построения кластерных решений F5
«Непрерывность обслуживания», «всегда доступный», «согласованный уровень SLA», «единая точка отказа» — мы неоднократно сталкивались с этими условиями, когда необходимо учитывать высокую доступность веб-сайта или приложения.
Главной задачей отказоустойчивой схемы, является исключение простоя приложения. Любой инцидент, связанный с внешним вмешательством или внутренним сбоем в работе, должен оставаться незамеченным для пользователя. Для обеспечения этой «незаметности» и непрерывной работы предназначено устройство публикации и защиты от F5 которое изначально имеет все необходимые механизмы за счет использования избыточной физической и логической инфраструктуры.
За функцию высокой доступности в F5 BIG-IP отвечает служба Device service clustering (DSC), которая дает возможность:
Active/Standby
В этом режиме одна система активна и обрабатывает весь трафик, а вторая находится в режиме ожидания (резервная не обрабатывает трафик). Если в активном устройстве F5 обнаружен сбой, весь трафик будет перемещен на резервную, поскольку резервная система уже имеет всю конфигурацию и зеркалирование сессий, резервная система становится активной.
Active/Active
В этом режиме оба системы могут быть активны одновременно. В полной мере используется имеющееся оборудование. Этот тип настройки в основном используется там, где ограничено аппаратное обеспечение F5, а требования к нагрузке большие. Но в данном случае при выходе из строя одного из серверов, часть сервисов станет недоступным.
В зависимости от особенностей работы приложения, требований к его публикации SLA и нагрузки выбирается схема работы устройств F5 и их количество в каждом ЦОД.
Вывод. Для обеспечения гарантированной отказоустойчивости подкрепленной SLA F5 рекомендует построение отказоустойчивых конфигураций минимум из 2-х устройств. В основном используется 2 варианта которые имеют свои преимущества и недостатки:
Подход 1. Построение кластера в двух или трех ЦОД и распределение трафика между ними при помощи DNS. Плюсом данного варианта является малое количество устройств F5 — по одному устройству в каждом ЦОД. но низкое время переключение между ЦОД которое варьируется от минут до нескольких часов в зависимости от настроек. Такое время переключение обусловлено особенностями работы протокола DNS но позволяет использовать малое количество устройств F5.
Подход 2. Создание кластера в каждому ЦОД минимум из 2-х виртуальных или аппаратных устройств F5. Плюсом данного подхода является мгновенное переключения приложения без обрывов сессии пользователя, но требует установку минимум 2-х устройств F5 в каждом ЦОД.
В зависимости от особенностей работы приложения и требований к его доступности стоит выбирать между подходом 1 или подходом 2 с учетом особенностей одного или второго варианта. В случае, когда F5 публикует и защищает приложения с требуемым уровнем SLA 99.9 (почти 9 часов простоя в год) и выше необходимо использовать эти подходы вместе. При подборе решения F5 и его внедрении также стоит учитывать режим работы active/active или active/passive. Важно отметить, что эти режимы могут быть реализованы как в одном ЦОД (разные устройства F5 для разных приложений) для максимальной утилизации устройств F5, так и между ЦОД чтобы оба ЦОД обрабатывали трафик приложений (active-active DC) или только один (Disaster DC).
F5 Networks: технологии и решения
F5 Networks: технологии и решения
Новейшие технологические решения и разработки от компании F5 Networks для обеспечения высокой доступности, защиты и скорости работы приложений
В любой крупной современной компании, где сетевая инфраструктура работает под большой нагрузкой, а также предъявляются высокие требования к конфиденциальности, целесообразно установить специализированное устройство – балансировщик нагрузки (load balancer).
Направления технологических разработок F5 Networks
Деятельность компании F5
Компания F5 Networks занимает лидирующие позиции в производстве систем для балансирования нагрузки на сеть, которые помимо своей основной функции, предоставляют широкий ассортимент технологий для работы с корпоративными приложениями.
По статистике, около 72% хакерских атак нацелены на идентификацию пользователей и веб-приложения, что говорит о высоком приоритете их защиты. Сложность в фильтрации интернет-трафика создаёт всё более часто используемое шифрование, которое традиционные устройства безопасности не в состоянии эффективно расшифровывать. Всё это значительно повышает риски проникновения вредоносного ПО в сеть предприятия. Балансировщики нагрузки от F5 Networks обеспечивают высокий уровень защищённости корпоративной локальной сети, а также успешно решают задачу по фильтрации трафика. Всё это позволяет безопасно работать с корпоративными веб-приложениями.
Защита от DDoS-атак
DDoS-атаки являются одним из наиболее популярных видов хакерского воздействия на сетевую инфраструктуру предприятий. Главная цель таких противоправных действий – это нарушить доступность услуг или работу предприятия в целом. Чем крупнее компания, тем больший материальный ущерб может нанести DDoS-атака, особенно если бизнес основан на работе в интернете. Решения от F5 Networks надежно защищают сеть вашего предприятия от всех типов DDoS-атак.
Решение для глобальной балансировки нагрузки Global Traffic Manager
Обеспечение глобальной доступности и высокой производительности приложений сегодня является критически важной задачей для любой крупной организации. Неправильное распределение нагрузки между серверами приложений в распределенных центрах обработки данных (ЦОД) оказывает негативное влияние на работу пользователей. Решение Global Traffic Manager (GTM) компании F5 Networks распределяет пользовательские запросы на основе местоположения пользователя, а также производительности и доступности приложений в том или ином ЦОДе для сокращения времени отклика приложений и значительного повышения удобства работы с ними.
GTM проверяет работоспособность всей инфраструктуры, устраняя единые точки отказа и перенаправляя трафик от ЦОДов с плохим уровнем производительности к менее нагруженным.
Для проверки работоспособности современных комплексных приложений зачастую недостаточно обычной проверки доступности сервера. Решение GTM объединяет множество методов для проверки состояния приложения на нескольких уровнях, что позволяет обеспечить наивысшую доступность и значительно повысить уровень надежности.
GTM имеет большое число предварительно настроенных методов для проверки работоспособности широко распространенных приложений, включая SAP, Oracle, Active Directory, LDAP и MySQL. Решение выполняет целенаправленный мониторинг этих приложений для точного определения их работоспособности, сокращения времени простоя, а также улучшения пользовательского опыта работы. Также имеется возможность группировать объекты таким образом, что при сбое одного приложения другие зависящие от него приложения будут помечены как нерабочие.
Кроме того, GTM обеспечивает непревзойденную производительность службы DNS за счет обработки запросов несколькими процессорными ядрами и использования технологии DNS Express, что позволяет обслуживать даже самые высоконагруженные площадки. Использование GTM позволяет сократить время ответа службы DNS со средних 300–400 мс до 15 мс.
Атаки типа «отказ в обслуживании» на DNS-инфраструктуру и подмена ставят под угрозу доступность и безопасность приложений. GTM защищает от и позволяет реализовывать политики, предоставляющие приложениям и данным дополнительный уровень защиты. Высокая производительность DNS Express позволяет выдерживать даже самые высокоуровневые (в максимальной конфигурации платформы F5 способны обрабатывать до 10 млн в секунду).
Введение в современную сетевую балансировку и проксирование
Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.
В этой статье я постараюсь восполнить нехватку постепенного введения в современную сетевую балансировку и проксирование. По правде сказать, это объёмная тема, достойная целой книги. И чтобы статья не получилась безразмерной, я постарался ряд сложных задач подать в виде простого обзора.
Что такое сетевая балансировка и проксирование?
Википедия определяет балансировку нагрузки так:
В вычислительной технике балансировка нагрузки улучшает распределение рабочих нагрузок по нескольким вычислительным ресурсам: компьютерам, компьютерным кластерам, сетевым подключениям, центральным процессорам или дисковым устройствам. Балансировка нагрузки призвана оптимизировать использование ресурсов, максимально увеличить пропускную способность, минимизировать время отклика и избежать перегрузки отдельных ресурсов. Применение вместо одного компонента нескольких компонентов с балансировкой может повысить надёжность и доступность благодаря получившемуся запасу мощностей. Балансировка нагрузки обычно подразумевает использование специального ПО или оборудования вроде многоуровневого коммутатора или DNS-сервера.
Это определение применимо ко всем аспектам обработки данных, а не только к работе с сетью. Операционные системы используют балансировку для диспетчеризации задач среди нескольких физических процессоров. Контейнерные оркестраторы вроде Kubernetes используют балансировку для диспетчеризации задач среди нескольких вычислительных кластеров. А сетевые балансировщики распределяют сетевые задачи среди доступных бэкендов. Эта статья посвящена только сетевой балансировке.
Иллюстрация 1: сетевая балансировка
На иллюстрации 1 показана упрощённая схема сетевой балансировки. Некоторые клиенты запрашивают ресурсы с некоторых бэкендов. Балансировщик находится между клиентами и бэкендами и выполняет несколько важных задач:
Правильное использование балансировки в распределённой системе даёт несколько преимуществ:
Балансировщик или прокси?
Термины балансировщик и прокси часто используют как взаимозаменяемые. В этой статье мы тоже в целом будем считать их аналогами (строго говоря, не все прокси — это балансировщики, но первичная функция подавляющего большинства — именно балансировка). Кто-то может возразить, что если балансировка — это часть встроенной клиентской библиотеки, то балансировщик не прокси. Но я отвечу, что такое разделение излишне усложняет и без того непростую тему. Ниже мы подробно рассмотрим типы топологий балансировщиков, но в этой статье топология встроенного балансировщика будет считаться частным случаем проксирования: приложение проксирует с помощью встроенной библиотеки, предлагающей те же абстракции, что и балансировщик вне процесса приложения.
L4 (подключения/сессии)-балансировка
Современные балансировочные решения по большей части можно разделить на две категории: L4 и 7. Они относятся к уровню 4 и уровню 7 модели OSI. По причинам, которые станут очевидны в ходе обсуждения L7-балансировки, выбор этих терминов я считаю неудачным. Модель OSI очень слабо отражает сложность балансировочных решений, включающих в себя не только традиционные протоколы четвёртого уровня, такие как TCP и UDP, но зачастую и элементы протоколов других уровней OSI. Например, если L4 TCP-балансировщик предлагает ещё и TLS-прерывание, то он теперь L7-балансировщик?
Иллюстрация 2: прерывающий L4 TCP-балансировщик
Иллюстрация 2 отражает традиционный L4 TCP-балансировщик. В данном случае клиент создаёт TCP-подключение к балансировщику, тот прерывает подключение (т. е. отвечает напрямую SYN), выбирает бэкенд и создаёт новое подключение к этому бэкенду (т. е. отправляет данные новому SYN). Подробности схемы сейчас не так важны, мы обсудим их в разделе, посвящённому L4-балансировке.
Ключевая мысль — L4-балансировщик обычно оперирует только на уровне L4 TCP/UDP-подключений/сессий. Следовательно, балансировщик перемещает байты так, чтобы байты из одной сессии приходили на один бэкенд. Такому балансировщику неважны особенности приложений, чьими байтами он манипулирует. Это могут быть байты HTTP, Redis, MongoDB или любого иного протокола приложений.
L7 (приложения)-балансировка
L4-балансировка проста и широко применяется. Какие же её особенности заставляют вкладываться в L7-балансировку на уровне приложений? Рассмотрим в качестве примера конкретный случай L4:
Если бэкенд решает обрабатывать трафик клиента А, то он будет обрабатывать нагрузку примерно в 3000 раз меньше, чем если бы обрабатывал трафик клиента Б! Это большая проблема, из-за которой в первую очередь теряется смысл балансировки. Также обратите внимание, что проблема действительна для любого протокола мультиплексирования, поддерживающего постоянные подключения (keep-alive) (мультиплексирование — это отправка конкурентных запросов приложений через одно L4-соединение, а keep-alive — это сохранение подключения в отсутствие активных запросов). Все современные протоколы одновременно и мультиплексирующие, и поддерживающие постоянные подключения, этого требуют соображения эффективности (в целом создавать подключение дорого, особенно если оно шифруется с помощью TLS), так что рассогласование нагрузки в L4-балансировщике со временем усиливается. Эта проблема решается с помощью L7-балансировщика.
Иллюстрация 3: прерывающий L7 HTTP/2-балансировщик
На иллюстрации 3 показан L7 HTTP/2-балансировщик. В этом случае клиент создаёт одно HTTP/2 TCP- подключение к балансировщику, который затем создаёт два подключения к бэкендам. Когда клиент отправляет в балансировщик два HTTP/2-потока, первый поток уходит в бэкенд 1, а второй — в бэкенд 2. Так что даже мультиплексируемые клиенты с очень разными трафиками по запросам будут эффективно сбалансированы по бэкендам. Поэтому L7-балансировка так важна для современных протоколов (у неё есть ещё куча преимуществ благодаря возможности инспектировать трафик приложений, но об этом мы поговорим ниже).
L7-балансировка и модель OSI
Как уже говорилось выше, проблематично использовать модель OSI для описания свойств балансировки. Причина в том, что L7, как минимум согласно модели OSI, сама по себе охватывает несколько дискретных уровней абстракции балансировки. Например, для HTTP-трафика есть несколько подуровней:
Сложный L7-балансировщик работает со всеми этими подуровнями. Более простой L7-балансировщик может обладать лишь небольшим набором свойств, по которым его относят к L7. Иными словами, свойства L7-балансировщиков варьируются гораздо шире, чем в категории L4. И конечно, здесь мы коснулись лишь HTTP, но Redis, Kafka, MongoDB и другие — всё это примеры L7-протоколов приложений, выигрывающих от использования L7-балансировки.
Свойства балансировщика
Здесь мы кратко рассмотрим основные свойства балансировщиков. Не для всех балансировщиков характерны все упоминаемые свойства.
Определение сервисов
Определение сервисов — это способ определения балансировщиком набора доступных бэкендов. Делать это можно по-разному, например с помощью:
Проверка состояния
Это определение, может ли бэкенд обрабатывать трафик. Проверка состояния бывает:
Балансировка
Да, балансировщики должны ещё балансировать нагрузку! Как будет выбираться бэкенд для обработки конкретного подключения или запроса при наличии рабочих бэкендов? Алгоритмы балансировки — это область активных исследований; они варьируются от таких простых, как случайный выбор и round-robin, до более сложных, учитывающих различия в задержках и нагрузках на бэкенды. Один из самых популярных алгоритмов благодаря производительности и простоте — power of 2.
Sticky-сессии
Для определённых приложений важно, чтобы запросы из одной сессии попадали на один и тот же бэкенд. Это связано с кешированием, временным сложным состоянием и прочими вещами. Есть разные определения термина «сессия», она может включать в себя HTTP-куки, свойства клиентского подключения и прочие атрибуты. Многие L7-балансировщики поддерживают sticky-сессии. Отмечу, что «липкость» сессии по своей сути хрупка (бэкенд, хостящий сессию, может умереть), так что держите ухо востро, проектируя систему, полагающуюся на sticky-сессии.
TLS-прерывание
Тема TLS и его роли в обработке и обеспечении безопасности межсервисного взаимодействия заслуживает отдельной статьи. Многие L7-балансировщики выполняют большой объём TLS-обработки, включая прерывания, проверку и закрепление сертификатов, обслуживание сертификатов с помощью SNI и т. д.
Наблюдаемость
Как я люблю повторять: «Наблюдаемость, наблюдаемость, наблюдаемость». Сети априори ненадёжны, и балансировщик часто отвечает за экспортирование статистики, отслеживание и журналирование: он помогает оператору понять, что происходит, и устранить проблему. У балансировщиков бывают самые разные возможности предоставления результатов наблюдения за системой. Самые продвинутые предоставляют обширные данные, включая числовую статистику, распределённую трассировку и настраиваемое журналирование. Отмечу, что продвинутая наблюдаемость достаётся не бесплатно: балансировщикам приходится выполнять дополнительную работу. Однако выгода от получаемых данных намного перевешивает относительно небольшое снижение производительности.
Безопасность и уменьшение последствий DoS
Балансировщики часто реализуют различные функции безопасности, особенно в краевой топологии развёртывания (см. ниже), включая ограничение скорости, аутентификацию и уменьшение последствий DoS (например, маркирование и идентификацию IP-адресов, tarpitting и пр.).
Конфигурация и уровень управления
Балансировщики нужно конфигурировать. В больших развёртываниях это превращается в важную обязанность. Система, конфигурирующая балансировщики, называется уровнем управления (control plane), её можно реализовать по-разному. За подробностями обращайтесь к статье.
И многое другое
Мы лишь прошлись по поверхности темы функциональности балансировщиков. Мы ещё поговорим об этом в части, посвящённой L7-балансировщикам.
Виды топологий балансировщиков
Теперь перейдём к топологиям распределённых систем, в которых развёртываются балансировщики. Каждая топология применима и к L4, и к L7.
Промежуточный прокси
Иллюстрация 4: топология балансировщика с промежуточным прокси
Топология с промежуточным прокси, показанная на иллюстрации 4, — один из самых известных способов балансировки. К таким балансировщикам относятся аппаратные решения Cisco, Juniper, F5 и др.; облачные программные решения вроде Amazon ALB и NLB, Google Cloud Load Balancer; чисто программные автономные решения вроде HAProxy, NGINX и Envoy. Преимущество схемы с промежуточным прокси заключается в простоте. Пользователи подключаются к балансировщику через DNS и больше ни о чём не беспокоятся. А недостаток схемы в том, что прокси (даже кластеризованный) — это единая точка отказа, а также узкое место при масштабировании. Кроме того, промежуточный прокси часто бывает чёрным ящиком, что затрудняет оперирование. Проблема возникла на клиенте? В физической сети? В самом прокси? В бэкенде? Иногда очень трудно определить.
Оконечный прокси
Иллюстрация 5: топология балансировщика с оконечным прокси
Топология на иллюстрации 5 — вариант топологии с промежуточным прокси, в которой балансировщик доступен через интернет. А в данном случае балансировщик обычно предоставляет дополнительные возможности «API-шлюза» вроде TLS-прерываний, ограничения скорости, аутентификации и продвинутой маршрутизации трафика. Преимущества и недостатки такие же, как у предыдущей топологии. Обычно невозможно избежать использования топологии с оконечным прокси в больших, открытых в интернет распределённых системах. Как правило, клиентам нужен доступ к системе по DNS с использованием различных сетевых библиотек, не контролируемых владельцем сервиса (нецелесообразно использовать прямо на клиентах встроенные клиентские библиотеки или топологии с побочным прокси, описанные в следующих разделах). Кроме того, по соображениям безопасности лучше иметь единый шлюз, через который в систему поступает весь интернет-трафик.
Встроенная клиентская библиотека
Иллюстрация 6: балансировка через встроенную клиентскую библиотеку
Чтобы избежать единой точки отказа или проблем с масштабированием, свойственных топологиям с промежуточным прокси, в более сложных инфраструктурах применяется встраивание балансировщика посредством библиотеки прямо в сервисы, как показано на иллюстрации 6. Библиотеки поддерживают разные функции, самые известные и продвинутые решения — Finagle, Eureka/Ribbon/Hystrix и gRPC (основанный на внутренней системе Google под названием Stubby). Главное преимущество решения на основе библиотеки в том, что функциональность балансировщика полностью распределяется по всем клиентам, а значит, единой точки отказа и трудностей масштабирования нет. Основной недостаток — библиотека должна быть реализована на каждом языке, используемом организацией. Распределённые архитектуры становятся настоящими полиглотами (многоязычными). В такой среде главное препятствие — стоимость реализации крайне сложной сетевой библиотеки на многих языках. Наконец, развёртывание обновления библиотеки в архитектуре большого сервиса превращается в огромную головную боль, и в результате в продакшен обычно работает куча разных версий библиотеки, что повышает операционную когнитивную нагрузку.
Учитывая сказанное, использовать библиотеки целесообразно в компаниях, которые могут ограничить разнообразие языков программирования и превозмочь трудности обновления библиотеки.
Побочный прокси
Иллюстрация 7: балансировка через побочный прокси
Топология с побочным прокси — вариант топологии со встроенной клиентской библиотекой. В последние годы эта топология была популяризирована в качестве service mesh. Идея в том, что можно получить все преимущества варианта со встроенной библиотекой без заморочек с языками программирования, но за счёт небольшого увеличения задержки при переходе к другому процессу. Сегодня самые популярные балансировщики с побочным прокси — это Envoy, NGINX, HAProxy, и Linkerd. Почитать подробнее о подходе можно в моей статье об Envoy, а также в статье об уровне данных service mesh и уровне управления.
Преимущества и недостатки разных топологий
Я считаю, что топология с побочным прокси (service mesh) в межсервисном взаимодействии постепенно сменит все остальные топологии. Схема с оконечным прокси всегда будет нужна до того, как трафик попадёт в service mesh.
Текущие достижения в L4-балансировке
L4-балансировщики всё ещё актуальны?
Мы уже говорили о преимуществах L7-балансировщиков для современных протоколов, а ниже обсудим их возможности подробнее. Означает ли это, что L4-балансировщики больше не актуальны? Нет! Хотя я считаю, что L7-балансировщики полностью заменят L4 в межсервисном взаимодействии, однако L4-балансировщики всё ещё очень актуальны на концах сети, потому что почти все современные большие распределённые архитектуры используют для интернет-трафика двухуровневую архитектуру L4/L7-балансировки. Вот преимущества размещения выделенных L4-балансировщиков перед L7-балансировщиками на концах:
Дальше я опишу несколько разных схем L4-балансировщиков с промежуточным/оконечным прокси. Эти схемы неприменимы для топологий с клиентской библиотекой и побочным прокси.
Прерывающие TCP/UDP-балансировщики
Иллюстрация 8: прерывающий L4-балансировщик
Первый тип L4-балансировщиков, всё ещё используемый. Это тот же балансировщик, что и в ознакомительном разделе об L4-балансировщиках. Здесь два отдельных TCP-подключения: одно между клиентом и балансировщиком, второе между балансировщиком и бэкендом.
Прерывающие L4-балансировщики всё ещё используются по двум причинам:
Балансировщики с TCP/UDP-транзитом
Иллюстрация 9: транзитный L4-балансировщик
Второй тип L4-балансировщика — транзитный — показан на иллюстрации 9. Здесь TCP-подключение балансировщиком не прерывается. Вместо этого после отслеживания подключения и преобразования сетевых адресов (NAT) пакеты для каждого подключения направляются на выбранный бэкенд. Сначала давайте определимся с отслеживанием подключения и NAT:
Для чего использовать балансировщик этого типа вместо прерывающего, описанного выше? Ведь он более сложен. Есть несколько причин:
Прямой возврат с сервера (DSR)
Иллюстрация 10: L4 прямой возврат с сервера (DSR)
На иллюстрации 10 показан балансировщик с прямым возвратом с сервера. Он создаётся на базе транзитного балансировщика. По сути, DSR — это оптимизация, при которой входящие пакеты запросов проходят через балансировщик, а исходящие пакеты ответов обходят его и идут прямо к клиенту. Выгода от использования DSR в том, что при многих видах нагрузок трафик ответов многократно больше трафика запросов (например, это характерно для HTTP-запросов/ответов). Допустим, 10 % трафика — это запросы, а остальные 90 % — ответы, и тогда при использовании DSR будет достаточно балансировщика с производительностью в 1/10 пропускной способности системы. Поскольку балансировщики исторически очень дороги, такая оптимизация сильно снижает стоимость системы и повышает надёжность. DSR-балансировщики — развитие концепции транзитного балансировщика:
Обратите внимание, что в схемах транзитного и DSR-балансировщика на балансировщике и бэкенде могут быть настроены разные способы отслеживания подключений, организации NAT, GRE и пр. Но это уже выходит за рамки статьи.
Устойчивость к сбоям благодаря высокодоступным парам (high availability pairs)
Иллюстрация 11: L4 устойчивость к сбоям благодаря HA-парам и отслеживанию подключений
Пока что мы рассматривали схему L4-балансировщиков без учёта окружения. Транзитному и DSR-балансировщику необходимо какое-то количество данных отслеживания подключений и состояний. А что, если балансировщик умирает? Если он был один, то все подключения, шедшие через него, оборвутся. В зависимости от ситуации это может сильно повлиять на производительность приложения.
Исторически сложилось, что L4-балансировщики представляли собой аппаратные решения разных производителей (Cisco, Juniper, F5 и пр.). Эти устройства очень дороги и обрабатывают большой объём трафика. Чтобы избежать обрыва всех подключений из-за сбоя единственного балансировщика, обычно делают два балансировщика, объединяя их в высокодоступные пары, как показано на иллюстрации 11. Схема типичной HA-пары устроена так:
Эта схема сегодня используется во многих интернет-приложениях с высоким трафиком. Но у неё есть несколько значительных недостатков:
Устойчивость к сбоям и масштабирование с помощью кластеров с распределённым консистентным хешированием
Иллюстрация 12: L4 устойчивость к сбоям и масштабирование с помощью кластеров с распределённым консистентным хешированием
С середины 2000-х в больших интернет-инфраструктурах начали внедрять новые, сильно распараллеленные L4 балансировочные системы, как на иллюстрации 12. Их задачами были:
Такую схему можно описать как устойчивую к сбоям и масштабируемую с помощью кластеризации и распределённого консистентного хеширования. Работает она так:
Давайте посмотрим, как вышеописанная схема избавляет нас от недостатков, свойственных схеме с высокодоступной парой:
Когда заходит речь об этой схеме, то обычно спрашивают: «Почему оконечные роутеры не общаются напрямую с бэкендами через ECMP? Зачем нам вообще нужны балансировщики?» В основном причина в защите от DoS и простоте работы с бэкендами. Без балансировщиков каждый бэкенд вынужден использовать BGP, и к тому же было бы гораздо сложнее проводить развёртывание.
Сегодня все системы L4-балансировки перенимают эту схему (или один из её вариантов). Два самых известных примера — Google Maglev и Amazon Network Load Balancer (NLB). Пока не существует OSS-балансировщика, использующего эту схему, но я знаю, что одна компания планирует выпустить такой в 2018-м. Жду с нетерпением, потому что современный L4-балансировщик — важная часть отсутствующего OSS при работе с сетью.
Текущие достижения в L7-балансировке
Прокси-войны — это практически буквально прокси-войны. Или «войны прокси». Nginx плюс, HAProxy, linkerd, Envoy, все буквально сражаются с этим. И proxy-as-a-service/routing-as-a-service SaaS-вендоры тоже повышают планку. Очень интересные времена!
— @copyconstruct
И действительно, в последние годы мы наблюдали возрождение разработки L7-балансировщиков/прокси. Это очень хорошо согласуется с движением в сторону микросервисных архитектур в распределённых системах. Эффективно управлять сетями, склонными по своей природе к сбоям, становится тем труднее, чем чаще они используются. Более того, расцвет автомасштабирования, контейнерных диспетчеров и прочих инструментов означает, что времена предоставления статичных IP в статичных файлах давно прошли. Системы не только активнее используют сети, они становятся гораздо динамичнее, требуют от балансировщиков больше функций. В этой части мы кратко рассмотрим направления, которым уделяется больше всего внимания при разработке современных L7-балансировщиков.
Поддержка протоколов
Современные L7-балансировщики привносят явную поддержку многочисленных протоколов. Чем больше балансировщик знает о трафике приложения, тем более сложные действия он может с ним выполнять, опираясь на данные наблюдений, продвинутую балансировку и маршрутизацию и т. п. Например, Envoy явно поддерживает парсинг L7-протоколов и маршрутизацию для HTTP/1, HTTP2, gRPC, Redis, MongoDB и DynamoDB. И в будущем наверняка будут добавляться новые протоколы, включая MySQL и Kafka.
Динамическая конфигурация
Как уже говорилось, всё более динамическая природа распределённых систем требует вложений в создание динамических и реактивных систем управления. Один из примеров такой системы — Istio. Подробнее почитать об этом можно здесь.
Продвинутая балансировка
L7-балансировщики сегодня часто имеют встроенные возможности продвинутой балансировки, такие как таймауты, повторные попытки, ограничение скорости, разрыв цепи (circuit breaking), теневое копирование (shadowing), буферизация, маршрутизация в зависимости от содержимого и др.
Наблюдаемость
Развёртываемые сегодня всё более динамические системы становится всё труднее отлаживать. Пожалуй, самая важная функция современных L7-балансировщиков — предоставление надёжных данных наблюдений, характерных для конкретных протоколов. Численная статистика, распределённые трейсы и настраиваемое журналирование сегодня нужны практически любому решению по L7-балансировке.
Расширяемость
Пользователям современных L7-балансировщиков часто нужна возможность легко их расширять и добавлять свою функциональность. Это делается с помощью написания подключаемых фильтров, которые загружаются в балансировщик. Также многие балансировщики поддерживают скрипты, обычно Lua.
Устойчивость к сбоям
Я довольно много написал выше об устойчивости L4-балансировщиков к сбоям. А что насчёт L7-балансировщиков? В целом с ними можно работать как с расширяемыми и не хранящими состояние (stateless). Можно легко горизонтально масштабировать L7-балансировщики с помощью обычного ПО. Более того, обработка и отслеживание состояний, выполняемые L7-балансировщиками, гораздо сложнее, чем это делают L4. Создание высокодоступной пары L7 теоретически возможно, но очень трудоёмко.
В целом в сфере L4 и L7 индустрия переходит от высокодоступных пар к горизонтально масштабируемым системам, объединяемым с помощью консистентного хеширования.
И прочее
L7-балансировщики развиваются ошеломляюще быстро. Например, вот что предлагает Envoy.
Глобальная балансировка и централизованный уровень управления
Иллюстрация 13: глобальная балансировка
В будущем всё больше станут использовать отдельные балансировщики в виде типовых устройств. Я считаю, что все реальные инновации и коммерческие возможности связаны с управлением. На иллюстрации 13 приведён пример системы глобальной балансировки. Здесь происходит несколько важных событий:
Глобальный балансировщик сможет решать всё более сложные задачи, не доступные ни одному отдельному балансировщику. Например:
Чтобы глобальная балансировка стала возможна, балансировщик, используемый в качестве уровня передачи данных, должен обладать сложными возможностями динамического конфигурирования. Подробнее читайте об этом в моих статьях: 1 и 2.
Эволюция от аппаратных до программных решений
Пока что я лишь мельком сравнивал аппаратные и программные решения, в основном в контексте высокодоступной пары L4-балансировщиков. Каковы тенденции в этой сфере?
Я пробовал новый OSI-стек из восьми программных уровней. Думаю, это что-то подобное:
— @infosecdad
Конечно, это юмористическое преувеличение, но в этом сообщении как раз и собраны современные тенденции:
Заключение и будущее балансировки
Я считаю, что мы живём в очень увлекательное для сетевой индустрии время! Переход к OSS и программным решениям в большинстве систем на порядки ускоряет циклы итераций. Более того, по мере роста динамичности распределённых систем благодаря «бессерверным» парадигмам в равной степени будут усложняться и лежащие в их основе сети и балансировочные системы.