Что такое балансировщик в it
Балансировка нагрузки
Время чтения : 7 минут
Что такое балансировка нагрузки?
Балансировка нагрузки (БН) — это метод, который гарантирует, что сервер организации не будет перегружен трафиком. Под этим определением понимается эффективное распределение входящего сетевого трафика между группой внутренних серверов, также известной как ферма серверов или пул серверов.
Операция выполняется физическим или виртуальным устройством, определяющим, какой сервер в пуле удовлетворит клиентский запрос наилучшим образом. При этом интенсивный сетевой трафик не перегружает систему. Кроме того, метод обеспечивает аварийное переключение между устройствами. Поэтому если один из серверов выходит из строя, балансировщик немедленно перенаправляет рабочие нагрузки на резервный сервер, тем самым снижая негативное воздействие на конечных пользователей.
Для чего нужен балансировщик нагрузки?
Балансировщик нагрузки (Load Balancer) — сервис, помогающий серверам эффективно перемещать данные, оптимизирующий использование ресурсов доставки приложений и предотвращающий перегрузки. Он управляет потоком информации между локальным или облачным хранилищем и конечным устройством — ПК, ноутбук, планшет или смартфон. Этот сервис проводит непрерывные проверки работоспособности серверов, чтобы убедиться в их работоспособности. При необходимости подсистема балансировки удаляет неисправные серверы из пула. Входящие в состав балансировщика контроллеры доставки приложений (ADC) предлагают множество дополнительных функций — шифрование, аутентификацию и межсетевой экран веб-приложений, создавая тем самым единую точку контроля для защиты, управления и мониторинга веб-сервисов.
К таким дополнительным возможностям относятся:
Балансировщики могут быть как отдельными физическими аппаратными устройствами, так и поставляться в виде программы. Аппаратные устройства работают на основе программного обеспечения, оптимизированного под специализированные процессоры. По мере увеличения трафика, поставщик просто добавляет дополнительные устройства балансировки нагрузки для обработки необходимого объема.
Преимущества такого подхода:
Программные балансировщики обычно работают на менее дорогом стандартном оборудовании или в облаке и имеют ряд собственных преимуществ:
Уровни балансировки
Прежде всего, давайте разберемся с моделью взаимодействия открытых систем OSI (Open System Interconnection). Разработанная еще в 1984 году, она описывает способ передачи информации между приложениями (программами), работающими на сетевых устройствах, компьютерах, маршрутизаторах (открытых системах). На изображении ниже показаны семь уровней взаимодействия этой модели:
Балансировка нагрузки происходит непосредственно на уровнях 4 и 7.
На уровне 4 балансировщик нагрузки отслеживает сетевую информацию о портах приложений и протоколах (TCP / UDP). Он доставляет трафик, комбинируя эти ограниченные данные с алгоритмом балансировки нагрузки, таким как циклический перебор, вычисляя лучший целевой сервер, на основе наименьшего количества подключений или времени ответа. Одним из наиболее известных балансировщиков нагрузки уровня 4 является Microsoft Network Load Balancer или NLB, это программное обеспечение для балансировки нагрузки ядра сети, доступное пользователям критически важных приложений Microsoft.
На уровне 7 балансировщик уже осведомлен о приложении и может использовать эту дополнительную информацию для принятия более сложных и обоснованных решений по балансировке нагрузки. С помощью протокола HTTP, он может однозначно идентифицировать клиентские сеансы, на основе файлов cookie и использовать эту информацию для доставки всех запросов клиента на один и тот же сервер. Благодаря своему логическому положению в сети, балансировщик нагрузки уровня 7 проверяет весь трафик уровней 4 и 7, проходящий к веб-сайтам и серверам приложений. Вся эта деятельность записывается в журналы, чтобы облегчить мониторинг и отслеживание сетевой информации.
Алгоритмы и методы балансировки
Существуют определенные алгоритмы балансировки нагрузки, определяющие оптимальные серверы для входящих клиентских запросов. Рассмотрим стандартные решения:
Преимущества облачного балансировщика
Все больше предприятий стремятся развертывать свои приложения в облаках. Это стало необходимостью поскольку, программы стали более сложными, потребности пользователей выросли, а объем трафика увеличился. Как и другие формы балансировки, балансировка нагрузки в облаке позволяет максимально повысить производительность и надежность приложений. Простота и скорость масштабирования в облаке означает, что компании могут справляться с пиками трафика без снижения производительности.
Аппаратные балансировщики при увеличении объема трафика, зачастую просто не справляются и поставщику приходится добавлять в пул дополнительные устройства. Это не продуктивно и поэтому на смену традиционным БН приходят облачные.
Отслеживание нагрузки здесь происходит с помощью «слушателей», использующих настроенные протоколы сети и порты для проверки клиентских запросов. ELB может обрабатывать миллионы параллельных подключений и обеспечивает высокую доступность серверов.
Резюме
В современном цифровом высоконагруженном мире без использования метода балансировки нагрузки обойтись практически невозможно. Грамотное распределение нагрузок обеспечивает ИТ-отделам масштабируемость и доступность услуг. Готовые инструменты управления трафиком помогают бизнесу более эффективно направлять запросы к нужным ресурсам, для каждого конечного пользователя, а реализованный принцип отказоустойчивости обеспечит бесперебойную работу вашей системы.
Отказоустойчивый балансировщик нагрузки: как работает и где протестировать бесплатно
Задачи по балансировке нагрузки, пожалуй, были актуальны всегда. И со временем их актуальность только растет. Активно развиваются микросервисные архитектуры и высоконагруженные проекты. Большую популярность в последнее время получили проекты с горизонтальным масштабированием, требующие балансировки трафика.
На бесплатном вебинаре 1 июля в 16:00 эксперты Selectel расскажут, как построить отказоустойчивую инфраструктуру, не вкладывая в это лишних сил и денег.
Что вы узнаете на вебинаре
→ как сделать первый шаг к отказоустойчивой инфраструктуре с помощью нового балансировщика нагрузки от Selectel;
→ как организовать публикацию приложения в интернете и балансировку нагрузки без единой точки отказа;
→ как бесплатно протестировать «Отказоустойчивый балансировщик нагрузки».
Программа
1. Отказоустойчивость современных приложений: типовая архитектура
публичного сервиса; примеры точек отказа; возникающие проблемы и задачи.
2. Балансировка нагрузки: базовые понятия; существующие решения для балансировки; устранение основных точек отказа.
3. Отказоустойчивый балансировщик: общая схема работы; возможности балансировщика.
Кому будет особо интересно
Вебинар будет полезен, если вы:
→ хотите построить отказоустойчивый сервис, зарезервированный в нескольких регионах;
→ хотите распределить нагрузку между выделенными серверами;
→ создаете и масштабируете гибридную инфраструктуру.
Кто эксперты
Станислав Валуев, менеджер продуктов ускоренной разработки
Юрий Логунов, старший системный администратор
Подключиться к бесплатному вебинару можно онлайн — 1 июля в 16:00. Регистрация по ссылке.
Также подробнее о балансировщике мы рассказали в блоге.
Краткий oбзор систем балансировки и отказоустойчивости веб сервисов
Рынок аппаратных систем балансировки нагрузок и отказоустойчивости для многих видов протоколов и служб включает в себя продукты таких фирм как Cisco, Radware, F5 и других… Но здесь о них речь не пойдет.
Хотелось бы собрать в одну страницу небольшой список популярных систем отказоустойчивости, балансировки нагрузок и кластеризации на основе проектов открытого кода, используемых в инфраструктуре крупных веб сайтов, коммерческих компаниях, провайдерах хостинга и не только. В таком “списке” трудно приравнивать один тип решения к другому — практически все нижеприведенные отличаются друг от друга назначением и свойствами, но всё-же все они могут быть отнесены к роду решений для поддержания высоко нагруженных сервисов с возможностями масштабирования “на лету” и успешно конкурирующими с промышленными продуктами.
LVS — Балансировщик нагрузки и кластеризация
Linux Virtual Server позволяет создать кластер из физических (или виртуальных) серверов, распределяющий нагрузку между машинами в зависимости от их состояния, приоритета и других параметров настройки. Поддерживаемые протоколы: TCP, UDP. LVS является по сути коммутатором протоколов 4го уровня. Компоненты проверки аппликативного состояния соединений на более высоком уровне протоколов (к примеру по cookies в HTTP) не доработаны.
Все процессы связи кластера с реальными серверами прозрачны для конечного пользователя — он (или она) увидит только внешний IP адрес кластера. Физические сервера могут находится как в одном сегменте сети с самим сервером LVS (т.н. Директором), так и быть удалены даже географически и связываться разными методами: туннелирование трафика внутри IP пакетов, прямая маршрутизация и NAT. В методе прямой маршрутизации, физические сервера возвращают пакеты напрямую к конечному пользователю дабы не загружать трафиком канал связи кластера и сам Директор сервер, маскируя при этом source адрес возвращенных пакетов под главный адрес кластера (с целью сохранения целостности соединения и TCP сессий). Сам сервер Директора может иметь резервных “рабов” (slave) на случай падения, один из которых заберет на себя все активные соединения. Сервера предоставляющие сам контент не обязательно должны работать на Линуксе, есть возможность работы с *BSD, Windows и Solaris. Разработки проекта LVS используются в других проектах кластеризации, к примеру демон keepalived, Linux-HA, Ultra Monkey, Piranha (Red Hat Cluster Suite).
Нужно отметить что в этом примере изображен метод прямой маршрутизации. «Фронт» сервера обращаются к Динамическим так-же через LVS, для балансировки.
Проект стабилен, довольно прост в установке и настройке, присутствует в большинстве репозиториев крупных сборок Линуксa и хорошо документирован. Код ядра проекта (IPVS) внесен в официальное ядро Линуса в версиях 2.4 и 2.6. Имеет место быть порт на FreeBSD, но сий слабо развит и поддерживает только методы туннелирования и прямой маршрутизации.
Из крупных игроков использующих LVS можно отметить: linux.com, Siemens (siemens.com), Wikimedia, Drupal (drupal.org), SourceForge (sourceforge.net), Zope (www.zope.org), Real Networks (www.real.com), Tiscali Group, ibiblio.org, University of Nottingham и многие другие.
HAProxy — Высокопроизводительный прокси и балансировка
HAProxy является прокси сервером аппликативного (7го) уровня для протоколов HTTP и TCP. Отличительная способность — умение проверять и встраивать в сессию “печеньку” для браузера пользователя, которая впоследствии будет использована для постоянства при направлении соединения на один из фронт или бэкэнд серверов с целью поддержания активных сессий с веб аппликациями. Умеет решать на какую группу серверов будет направлен пользователь в зависимости от любого из параметров HTTP запроса. Способен работать с WebSockets (в виде TCP соединений).
На Линуксе, может быть настроен как “прозрачный” прокси (передавая запросы на обслуживающие сервера оставляя source адреса пакетов полученных от пользователей без изменения на свой главный IP адрес как при стандартном или обратном проксировании). Проверка пакетов на 7ом уровне позволяет фильтровать несанкционированный трафик и протоколы. Многослойная архитектура, планировщик на уровне ядра, оптимизированные протоколы и алгоритмы балансировки позволяют достичь пропускных способностей в несколько терабайт трафика за день. Отказоустойчивость одного прокси сервера обеспечивается через использование демона keepalived проверяющего работоспособность самого прокси и синхронизируясь с резервным сервером (протокол VRRP), обеспечивая дублирование в случае падения первого. Так-же возможна параллельная работа обоих для балансировки, но в такой конфигурации требуется внешний балансер или разброс по roud-robin DNS.
Проект не столь популярен как LVS, но и не слишком от этого страдает. Гордятся стабильностью и безопасностью кода. Установка и настройка тривиальны, в репозиториях не присутствует но есть собранные, стандартные бинарники залинкованные на Glibc 2.2, и естественно сорсы. Официально работает на Линуксе 2.4/2.6, Solaris 8-10, FreeBSD, OpenBSD. Данные о использующих проект не афишируются, замечен у некоторых провайдеров аппликаций и сервисов в сети, так же укомплектован в продуктах: redWall Firewall, ALOHA Load Balancer, Loadbalancer.org.
Varnish — Kеширующий прокси и акселерация http
Varnish недавно попал в ленты новостей IT как проект автор которого (Пол-Хеннинг Камп) объявил о том что “вы делаете это не правильно”. Он имел ввиду реализацию и продуктивность алгоритма btree, доказав свою гипотезу тем что оптимизировал производительность алгоритма бинарных деревьев B-heap в Varnish до десяти раз. Проект и до этого позиционировал себя как полностью модернизированный, построенный с нуля в 2006-ом году и эффективно использующий современные технологии операционных систем в общем, и Виртуальной Памяти в частности. Varnish классифицируется как “обратный” (reverse), кеширующий прокси и акселератор HTTP.
Из отличительных способностей можно отметить возможность настройки кеширования страниц по частям, к примеру собирая только динамические объекты с обслуживающих серверов. Присутствует встроенный механизм проверки работоспособности бэкендов с гибкой настройкой — замер потраченного на ответ времени, настраиваемый предел кол-ва неудавшихся проверок и т.д. Язык конфигурации — динамический, с возможностью писать встраиваемый код на С. Как пример, на сайте проекта дается код для использования GeoIP и еще один для отправления логов в Syslog. Так-же, можно вносить изменения в конфигурацию “на лету” — подключаясь к процессу сервера через контрольный канал. Встроенная возможность переписки и перенаправления URLов (rewrite). Сам сервис Varnish не имеет механизма отказоустойчивости или дублирования на случай падения, предположительно можно добиться этого в связке с другим решением балансировки. Масштабируемость возможна через установку за фронтальной машиной Varnish бэкендов с Varnish установленным в конфигурации ‘Director’ и серверами контента уже за ним.
Проект ярко освещает свою популярность и современный дизайн (“опуская” при этом Squid при любом удобном случае), но всё-же да, есть чем гордится — в одном из примеров две машины Varnish заменили 12 машин Squid’а. Установка стандартная для *NIX, присутствует в некоторых репозиториях и так-же имеет SourceForge страницу с бинарными пакетами под многие сборки. Правильная настройка, из-за подхода столь отличного от классического, достигается через долгие интимные отношения. Официально рекомендуется установка на современных версиях 64х битных Линуксов, FreeBSD или Solaris. Из крупных сайтов признавшихся в использовании: Slashdot, The Pirate Bay, Funny or Die, Wikia. Из неподтвержденных но замеченных: Twitter, Facebook, Photobucket, weather.com, answers.com, Hulu, break.com.
Pound — Прокси и балансировка http и https
Pound это обратный прокси и балансировщик нагрузки для протоколов HTTP и HTTPS. Отличительные способности включают в себя возможность фронтальной обработки SSL и распределения на обслуживающие сервера в виде HTTP, дезинфекция HTTP и HTTPS на предмет неправильно сформированных запросов, балансировка по состоянию сессии и другим параметрам (URL, идентификации (Basic HTTP), кукам (cookies), HTTP headers). Полная поддержка WebDAV.
Pound имеет встроенный механизм балансировки и проверки работоспособности обслуживающих серверов. Разработчики отмечают что дизайн изначально был спланирован из принципа не вмешиваться в проходящий трафик, исходя из этого не используют методы встраивания “печенек” и т.п. в сессии, довольно таки на прямую намекая на противоположность методам HAProxy. Несмотря на это замечание, может встраивать в хедэры “X-Forwarded-for” для передачи на бэкенд сервера IP адрес пользователя с целью записи в логи и т.п. Изначально проект разрабатывался как фтонтэнд для нескольких серверов Zope (ZEO). Считается легковесным и безопасным так как практически не обращается к диску (кроме чтения сертификатов SSL во время загрузки), может бежать в chroot’е. Встроенных механизмов отказоустойчивости не имеет.
Проект скромен, манией величия не страдает. Установка и настройка не представляют больших сложностей. Существуют неофициальные пакеты под крупные сборки Линукса, на сайте распространяется только в виде сорсов. Официально тестирован на Линуксе, OpenBSD и Solaris. О использующих проект данных не много, но часто упоминается как решение для балансировки HTTPS в связке с другими решениями.
NGINX — Высокопроизводительный веб сервер и балансировка
О nginx распространятся особенно не буду. Проект отечественный и широко известен общественности, но, полагающиеся почести отдать в контексте такого обзора обязан — как минимум упомянуть.
Еще о NGINX могу отметить что он используется на фронтальных машинах для обработки статических запросов и балансировки запросов к динамическим объектам в фирме где работает сам автор сих слов (подобно примеру на рис. №1 о LVS).
Адаптивная балансировка нагрузки или как повысить надёжность микросервиса
Привет, меня зовут Геннадий, я работаю в Ozon, занимаюсь разработкой backend-сервисов.
Избыточностью компонентов, кластеризацией или балансировкой уже никого не удивишь в наши дни. Это очень важные и нужные механизмы. Но так ли они хороши? На сколько они защищают нас от возможных отказов?
В Ozon все перечисленное используется, но мы сталкивается с проблемами, которые выходят за рамки возможностей стандартных решений и нужны иные подходы и инструменты. Я уверен, что и у вас есть кластеризация и она также не спасает на все сто.
В статье я хочу затронуть некоторые из этих вопросов и показать, как мы повышаем надежность сервисов с помощью адаптивной балансировки.
Изначально решалась проблема клиентской балансировки запросов к PostgreSQL и Redis, но описываемое ниже решение этим не ограничивается – можно применить и для других случаев.
Алгоритм достаточно простой, не привязан к какой-то технологии или языку программирования и может быть адаптирован под разные платформы.
Но обо всем по порядку.
Начнём с проблематики.
Узкие места масштабирования
Есть некий сервис, который должен отвечать на запросы. Он выглядит вот так:
Данные извлекаются, к примеру, из PostgreSQL и передаются потребителям.
В данной схеме узких мест несколько. Если не вдаваться в окружение (сетевую инфраструктуру, вычислительные узлы и т.д.), то их два. Сам сервис и хранилище.
Сервис можно масштабировать горизонтально и тем самым добиться высокой доступности и отказоустойчивости (примем это за истину). Плюс, мы же не в вакууме живем – под рукой обычно есть средства балансировки трафика. А какой-нибудь Kubernetes ещё и отслеживает состояние нашего сервиса (или сам балансировщик – с помощью проб).
Получаем такую картину:
Хранилище тоже можно масштабировать горизонтально. Например, сделать несколько реплик и организовать кластер, как в случае с PostgreSQL или тем же Redis.
Если бы мы жили в идеальном мире, то на этом можно было завершить статью — проблема решена и бизнес может спать спокойно.
Но в реальном мире остаётся ещё куча других проблем, которые не решаются только лишь кластеризацией.
Больше кластеров
Есть человеческий фактор. Кто-то случайно удалил логин, поменял пароль, удалил таблицу — такое редко, но бывает. В этой ситуации сервис будет полностью недоступен, хотя кластер продолжит работать.
Или, например, в системах, где «много» данных, кто-то запустил долгий запрос и это повлияло на всё остальное. В микросервисах с eventual consistency не так редки случаи запуска различных синхронизаций (пересчётов), индексаций, которые также грузят систему.
Долгие ответы, недоступность по таймауту. Кластер этого не заметит.
Как долго вы будете искать причину? Сколько времени займет исправление? Клиент не ждет, бизнес теряет деньги.
И тут мы приходим к выводу: нам нужны независимые системы, чтобы отказ одной, не влиял на другую!
Хорошо, давайте сделаем два кластера.
В подробности сходимости вдаваться не будем, решений очень много: репликация на уровне железа (СХД), репликация на уровне софта или, к примеру, клиент, мутирующий данные, может писать сразу в несколько мест.
Получили подходящую по согласованности систему из двух «независимых» источников.
И тут нужно решить откуда читать – копий-то две (а то и больше).
Есть несколько вариантов:
1) читаем из первой и, в случае недоступности, обращаемся ко второй;
2) балансируем запросы между системами и, в случае недоступности одной, делаем обращение к другой;
3) ходим сразу в оба кластера, берём первый (или лучший) полученный результат, второй отбрасываем.
Допустим, мы выбрали какую-то из схем доступа. Решили ли мы проблемы? Какие-то да. Если «сломается» одна система, то мы будем получать данные от другой.
Но часть проблем осталась.
В первом и втором варианте остаются все те же долгие ответы и таймауты. Если система быстро «падает», то хорошо – мы без потерь можем переключиться на другую и получить ответ от неё (на самом деле это тоже плохо, но об этом чуть позже). А вот если первый узел отвечает долго, то общее время ответа может быть неприемлемым.
Во втором варианте проблема будет сглажена балансировкой. Если запросы балансируются 1-к-1, то мы теряем всего 50% трафика. Стало лучше, но устраивает ли нас это?
Третий вариант (одновременные запросы к обоим узлам) – очень хороший и мы долгое время его использовали. Он даёт очень достойный с точки зрения отклика результат. Даже на предельной нагрузке ответы были константами, без деградации; узлы компенсировали «тормоза» друг друга. Плюс, решаются проблемы с прогреванием и мониторингом способности держать нагрузку. Если используются ответы только от одного узла, значит, скорее всего второй не справляется.
Но есть проблема: так потребляется больше ресурсов. Одно дело вы обращается к одной базе данных, другое дело сразу два I/O-запроса.
Приведу пример. На проде работает релиз, за данными он ходит одновременно в PostgreSQL и Redis. Начинаем выкатывать новый релиз, канарейкой. Переключаем трафик: 5%, 10%, 15% и т. д. Видим, что новый релиз генерирует исключения о нехватке соединений к БД: «FATAL: connection limit exceeded for non-superusers». Ничего страшно, Redis же отвечает!
Переключаем трафик дальше. И в какой-то момент, условно на 80% трафика – поды начинают перезагружаться.
Что случилось? Проблема в исключениях (Exceptions).
Я думаю, не секрет, что обработка исключения в тысячи раз «медленнее», чем обработка кода возврата. И чем дальше по стеку происходит «захват», тем затратнее такая обработка. Это всё stack trace.
Во всех вариантах балансировки (и без балансировки) исключения могут сыграть роковую роль. Сервис тратит на это много вычислительных ресурсов и сам деградирует, в конечном итоге. В контейнерной среде это выглядит как повышенная утилизация CPU, throttling, «подвисание» контейнера и его последующий перезапуск. А пока происходит перезапуск, запросы будут перенаправлены на другие узлы, где произойдет то же самое. Сервис будет полностью недоступен.
Из описанного выше случая с нехваткой соединений, контейнеру «хватило» всего 200 Exceptions в секунду, чтобы произошёл лавинообразный отказ всего приложения.
Чтобы решить эту проблему, можно перестать кидать исключения и перейти на soft-exception – коды возврата. Оставить исключения только для исключительных случаев.
Хорошо, в своём коде и библиотеках мы можем поменять подход. А как быть со сторонними? Они то продолжают использовать исключения. Будем переписывать библиотеку, скажем, NpgSql, которая по-другому не умеет сообщать о проблемах?
Подведём промежуточные итоги. У нас есть следующие проблемы:
И есть требования к отказоустойчивости и высокой доступности.
Нам нужен какой-то балансировщик, который бы мог распределять запросы между узлами, в соответствии с временем ответа, учитывая таймауты, и при этом как-то отключать «плохие» узлы. А когда система вернётся к штатному функционированию, автоматически перераспределить нагрузку.
Сделаем такой балансировщик.
Балансировщик
Распределять запросы в соответствии с response time узла – не сложно. Мы должны считать время ответа каждого и распределять запросы в соответствии с этим показателем.
Как считать время? Можно вычислять среднее время всех ответов, начиная со старта приложения. Ок, но с таким подсчётом текущие «проблемы» очень нескоро повлияют на балансировку.
Можно считать средний показатель за период – скользящую. Например, среднее время ответа за 100 последних запросов. Уже лучше.
У простой скользящей есть две проблемы. Первая – все значения имеют равный вес, а это значит, что старые значения будут одинаково влиять на результат наряду с новыми (хотя старые уже не вызывают интереса, как правило).
Здесь видно, что десятый запрос с response time в 20ms будет влиять на все последующие десять запросов.
Вторая проблема – значения, которые «приходят» в скользящую, влияют на неё 2 раза (когда входят и когда выходят).
Решить эти проблемы позволяют взвешенные скользящие – они сглаживают этот эффект.
Например, экспоненциальная скользящая средняя. Вот её формула:
F – фактор сглаживания; это значение можно подобрать, обычно используется «стандартное»: 2/(n+1), где n – период скользящей;
EMA(i-1) – значение EMA за предыдущий период.
Если простым языком, то предыдущее значение RT (за период) уменьшается на некоторый коэффициент и к нему прибавляется текущее значение с большим весом. Получаем, что текущие значения имеют более высокий приоритет, а старые и те, что выходят из «окна» – влияют в меньшей степени.
Вот так выглядит предыдущий всплеск. Он в большей степени влияет на среднюю при появлении и постепенно уменьшает своё влияние на более новые значения.
А вот как выглядит значение средней с периодом 30, если, скажем, сервис начал постоянно отвечать «плохо»:
Средний ответ был 2ms, а потом резко упал до 10ms и остановился на этом уровне. Как видим, «поведение» обычной скользящей средней (SMA) линейное и грубое. Хотя при этом стало быстрее соответствовать реальной картине. EMA наоборот, более сглаженное, но немного отстаёт. Чтобы для EMA получить отклик лучше, необходимо «поиграться» с периодом или фактором сглаживания.
Есть другие взвешенные: AMA, Double EMA, Triple EMA, Fractal AMA. Суть балансировки не меняется, в статье их рассматривать не будем.
Отлично, мы научились считать среднее и теперь можем балансировать трафик между узлами.
Давайте разбираться с таймаутами и устойчивыми исключениями (permanent exceptions). Их можно обрабатывать отдельно. Но тогда механизм балансировки станет сложнее – необходимо будет отслеживает ошибки за период и принимать решение об ограничении трафика уже на основе двух показателей. Сложно, не подходит.
А что, если учитывать их как response time? Здесь также есть несколько подходов.
Можно назначить разным показателям разные значения RT. К примеру, договориться что timeout – это 100ms, ошибка – 200ms и т. д. Но в этом случае долгие ответы будут мало отличимыми от этих обособленных.
Или можно задать им коэффициенты от нормального отклика – чтобы в случае замедления ответов нормального узла, мы не получили распределение трафика близкого 1-к-1. Тогда опять придётся отдельно считать среднюю RT для нормальных ответов и вводить ещё какой-то общий счетчик.
А что, если ввести коэффициенты от среднего response time? То есть применить геометрическую прогрессию. Timeout к примеру, будет с коэффициентом 1.5, ошибки – 2 и т. д.
Тогда единичные ошибки будут умножать нормальное время на этот коэффициент и не сильно влиять на среднюю, а постоянные ошибки будут увеличивать это значение и вносить «существенный» вклад в общую картину. То, что нужно!
Есть еще некоторые нюансы, которые мы должны учесть, но хватит теории – пора писать алгоритм.
Адаптивный балансировщик: алгоритм
Алгоритм представлен на некотором псевдоязыке.
Вводить соглашения не будем. Уверен, у вас не возникнет трудностей понять, что происходит. К тому же я старался вставлять полезные комментарии и пояснения, что также должно облегчить понимание.
Использовать его нужно следующим образом:
То есть для запроса вы должны спросить у балансировщика, «кто следующий», и после запроса обновить информацию о нём. Для второго ответа, если он случился, также обновляем статистику.
Что ещё забыли? Конечно, про синхронизацию потоков. Этот вопрос нельзя обойти стороной, поскольку он очень важен в реальном мире.
Структуры балансировки (счётчики, веса) сосредоточены в одном месте, и в высоконагруженном приложении в любом случае произойдёт конкурентный доступ.
Я использую синхронизацию, когда обновляю счётчик запросов (функция GetNext, инструкция RequestTotal++). Конкретно, в С# используется конструкция синхронизации пользовательского режима – Interlocked.
Нужно ли использовать синхронизацию при обновлении счётчиков средних ответов (firstNodeResponseTime и secondNodeResponseTime)? Мой ответ – нет. И вот почему.
Как правило, на протяжении некоторого продолжительного времени, сервис отвечает с константной задержкой или не отвечает вовсе. То есть ведёт себя ожидаемо, стабильно.
Даже если случайные всплески в порыве конкуренции перезатрут «хорошие» (или «плохие») данные, вряд ли это существенно повлияет на общую картину. Поэтому здесь их можно не использовать.
А вот для обновления весов (nodeRatio) синхронизация нужна. Мы должны обеспечить балансировку 1-к-X, поэтому структура должна быть целостной. Значит, за это должен отвечать один поток. Используем Interlocked.
А есть ли смысл обновлять веса для каждого запроса? В highload-системах можно этой точностью пренебречь. Одного раза на каждые 50 запросов будет вполне достаточно.
На этом обсуждение самого алгоритма можно завершить. На мой взгляд все ключевые вопросы мы разобрали.
Практика
Первым делом запускаем нагрузочные тесты.
У нас есть приложение, которое ходит за данными в PostgreSQL и Redis. Даём на него нагрузку и через какое-то время производим отключение одного из хранилищ.
На графике стрелкой 1 отмечен момент отключения базы данных (переименовываем таблицу, из которой читает сервис). Отключение было примерно в 16:44 (балансировщик отдает метрики, но с небольшим отставанием, чтобы уменьшить накладные расходы). Видно, что примерно за две минуты база данных была полностью отсечена от запросов, на неё падали эти 0.5% трафика с fallback на Redis. Cтрелка 2 – обратно вернул таблицу на место.
Давайте посмотрим, как это повлияло на характеристики сервиса.
Error rate остался на прежнем уровне и немного увеличился response time – поскольку всё-таки часть трафика попала на отказавший postgres, и только потом происходил fallback на Redis. PostgreSQL очень быстро кидал exception (таблицы же нет, чего ждать), поэтому response time не сильно увеличился. Но, что самое главное, приложение «выжило» и не упало!
И обратная картина. Убиваем Redis (командой DEBUG SEGFAULT).
К сожалению, данных балансировки по этому тесту нет. Но есть данные по работе приложения.
На скрине плохо видно, но error rate увеличился до 2.51% (в нормальном режиме работы – 0.009%). Подрос response time в 90 и 99 квантилях. Но в целом, катастрофы не случилось.
Это были стресс-тесты.
Там вот так убивать базу или Redis страшно (хотя очень бы хотелось).
Но есть момент выкатки релиза, когда не хватает соединений к PostgreSQL и постоянно возникает exception.
Вот этот «холмик» – как раз и есть момент отсечения PostgreSQL.
Нехватка соединений в целом никак не повлияла на сервис, лишь немного деградировал ответ в 99 квантиле. На графике это период с 11:30 до 12:30.
А вот несколькими неделями ранее, до релиза балансировки – был бы полный отказ приложения.
Не серебряная, но пуля
Мы написали адаптивный балансировщик, который приспосабливается к изменяющимся условиям, умеет отсекать нагрузку и автоматически восстанавливаться. При этом весьма простой и с небольшими накладными расходами.
Понятно, что это не серебряная пуля, и всех проблем мы не решили. Но в какой-то степени мы добились улучшения показателей высокой доступности и отказоустойчивости сервиса.
На этом у меня всё.
Буду рад комментариям, замечаниям, пожеланиям!