No Image

Распределение нагрузки между серверами

СОДЕРЖАНИЕ
534 просмотров
10 марта 2020

В терминологии компьютерных сетей балансировка нагрузки или выравнивание нагрузки (англ. load balancing ) — метод распределения заданий между несколькими сетевыми устройствами (например, серверами) с целью оптимизации использования ресурсов, сокращения времени обслуживания запросов, горизонтального масштабирования кластера (динамическое добавление/удаление устройств), а также обеспечения отказоустойчивости (резервирования).

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

Балансировка нагрузки отличается от физического соединения тем, что балансировка нагрузки делит трафик между сетевыми интерфейсами на сетевой сокет (модель OSI уровень 4) основе, в то время как соединение канала предполагает разделение трафика между физическими интерфейсами на более низком уровне, либо в пакет (модель OSI уровень 3) или по каналу связи (модель OSI уровень 2); Основы с, как протокол соединения кратчайшего пути

Примеры устройств, к которым применима балансировка:

Балансировка нагрузки может быть использована для расширения возможностей фермы серверов, состоящей более чем из одного сервера. Она также может позволить продолжать работу даже в условиях, когда несколько исполнительных устройств (серверов) вышли из строя. Благодаря этому растёт отказоустойчивость, и появляется возможность динамически регулировать используемые вычислительные ресурсы за счёт добавления/удаления исполнительных устройств в кластере.

Содержание

Интернет-услуги [ править | править код ]

Один из наиболее часто используемых приложений балансировки нагрузки является создание единого интернет-сервиса с несколькими серверами, иногда известные как фермы серверов. Обычно с балансировкой нагрузки системы относятся популярные веб-сайты, большие Интернет-магазины, сайты использующие протокол передачи файлов (FTP), системы доменных имен (DNS), и базы данных.

Для интернета, балансировщик нагрузки — это обычно программа, которая прослушивает порт, где внешние клиенты подключаются к службам. Балансировщик нагрузки перенаправляет запросы на один из «серверов» сервера, который обычно отвечает балансировщику нагрузки. Это позволяет подсистеме балансировки нагрузки, отвечать клиенту не зная о внутреннем разделении функций. Это также позволяет клиентам связавшись с фоновыми серверами напрямую, которые могут иметь преимущества в плане безопасности и скрывает структуру внутренней сети и предотвращения атак на ядро, сетевой стек или несвязанные сервисы, работающие на других портах.

Некоторые балансировщики нагрузки обеспечивают механизм для того, чтобы делать что-то особенное в том случае, если все серверная часть сервера недоступна. Это может включать в себя переадресацию на резервную систему балансировки, или отображения сообщения о неисправности.

Важно также, что подсистема балансировки нагрузки не должна стать единой точкой отказа. Обычно балансировщики нагрузки реализуются в высокой доступности, которые могут также реплицировать сессии сохраняемости данных, если это требуется для конкретного применения. [1]

Циклический перебор DNS [ править | править код ]

Альтернативный метод балансировки нагрузки, которая не обязательно требует специального программного или аппаратного обеспечения узла, называется раунд Робин с DNS. В этой технике, несколько IP-адресов, связанных с одним доменным именем; клиенты должны выбрать сервер для подключения. В отличие от использования выделенной подсистемы балансировки нагрузки, эта методика предоставляет клиентам существование несколько серверов. Техника имеет свои преимущества и недостатки, в зависимости от степени контроля над DNS-серверами и степени детализации требуемой нагрузки.

Другой, более эффективный метод для балансировки нагрузки с помощью DNS можно делегировать www.example.org в качестве суб-домена, для которого зона обслуживается каждый же серверах, обслуживающих веб-сайт. Эта техника работает особенно хорошо, где отдельные серверы разбросаны географически в Интернете. Например:

Тем не менее, файл зоны для www.example.org на каждом сервере отличается таким образом, что каждый сервер решает как использовать IP-адрес в качестве A-записи. На сервере одного файла зоны для отчетов www.example.org:

На сервере два тот же файл зоны содержит:

Таким образом, когда первый сервер не работает, его DNS не отвечает, и веб-служба не получает какого-либо движения. Если линия на одном сервере перегружена, ненадежная служба DNS обеспечивает меньше http-трафика который достигнет этого сервера. Кроме того, самый быстрый ответ DNS разрешителю почти всегда от сети ближайшего сервера, обеспечение гео-чувствительный балансировки нагрузки [ нужная цитация ] . Короткий TTL на a-запись позволяет обеспечить трафик быстро отвлекаются, когда рухнет сервер. Необходимо учитывать возможность того, что эта методика может привести к возможности индивидуальных клиентов переключаться между отдельными серверами в середине сессии.

Алгоритмы планирования [ править | править код ]

Множество алгоритмов планирования используются балансировщиками нагрузки, чтобы определить, какому серверу послать запрос. Простые алгоритмы включают в себя случайный выбор или круговой системе. Более сложные подсистемы балансировки нагрузки могут принимать во внимание дополнительные факторы, такие как сервера сообщили нагрузки, меньшее Время отклика, вверх/вниз статус (определяется путём мониторинга опрос какой-то), количество активных соединений, географическое положение, возможности, или сколько трафика он недавно был назначен.

Настойчивость [ править | править код ]

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

В идеале кластер серверов за балансировщиком нагрузки должны быть в курсе сессий, так, что если клиент подключается к любому серверу в любой момент история общения пользователя с конкретным сервером не имеет значения. Обычно это достигается с помощью общей базы данных или в памяти сессии базы данных, например memcached.

Одно основное решение проблемы данных сессии должны отправлять все запросы в сессии пользователя последовательно в тот же сервер. Это называется настойчивость(persistence) или липкость(stickiness). Существенным недостатком этой технологии является отсутствие автоматической отработки отказа: если сервер выходит из строя, его сессионные информация становится недоступной, из всех сеансов теряется. Та же проблема обычно актуальна для центральной базы данных сервера; даже если веб-сервера являются «лицами без гражданства»(stateless) и не «липкий»(sticky), центральной базе данных (см. ниже).

Отнесение к определенному серверу могут основываться на имени пользователя, клиентского IP-адреса, или могут быть случайными. Из-за изменения клиента воспринимаются адрес, вытекающих из протокола DHCP, трансляцию сетевых адресов и веб-прокси, этот метод может быть ненадежным. Случайные задания должны запоминаться балансировщиком нагрузки, который создает нагрузку на хранилище. Если балансировщик нагрузки заменяется или выходит из строя, эта информация может быть потеряна, и задания, возможно, должны быть удалены после заданного промежутка времени или в периоды высокой нагрузки, чтобы избежать превышения пространства, доступного для таблицы присвоений. Метод случайного присвоение также требует, чтобы клиенты поддерживают некоторые настройки, который может быть проблемой, например, когда Web-браузер отключил хранения файлов cookie. Сложные подсистемы балансировки нагрузки используют несколько методов сохранения, позволяющие избежать некоторых недостатков какого-либо одного метода.

Другим решением является хранить сессионные данные в БД. Вообще это плохо для производительности, так как это увеличивает нагрузку на базу данных: базу данных лучше использовать для хранения информации менее изменяющуюся, чем сессионные данные. Чтобы предотвратить стать единой точкой отказа базу данных, и для повышения масштабируемости, базы данных часто реплицируются между несколькими компьютерами, и балансировки нагрузки используется для распространения индекса нагрузки между этими репликами. Технология Microsoft ASP.net State Server является примером сеанса базы данных. Все серверы в веб-ферме хранят данные сессии на Главном State Server сервер и любой сервер в ферме может извлечь данные.

Очень распространены случаи когда клиентом является веб-браузер, простой, то эффективный подход-хранить сессионные данные в самом браузере. Одним из способов достижения этого является использование cookie браузера, временные зашифрованные метки. Другой способ — перезапись URL. Хранение данных сессии на клиенте, как правило, предпочтительное решение: тогда балансировщик нагрузки волен выбирать любой сервера для обработки запроса. Однако, этот метод обработки данных состояния плохо подходит для некоторых сложных сценариев бизнес-логики, где состояние сеанса является большой полезной нагрузкой и перечитывать его с каждым запросом на сервер не представляется возможным. Перезапись URL-адресов имеет серьезные проблемы безопасности, потому что конечный пользователь может легко изменять представленные URL и таким образом изменить потоки сессии.

Читайте также:  Intel core i5 4460 отзывы

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

Возможности балансировщика нагрузки [ править | править код ]

Аппаратные и программные балансировщики нагрузки могут иметь различные специальные характеристики. Основная черта балансировщика нагрузки — иметь возможность распределять входящие запросы через несколько серверов в кластере по алгоритму планирования. Большинство из перечисленных ниже свойств конкретного поставщика:

  • Асимметричная нагрузка: соотношение может быть назначено вручную вызывать некоторые сервера, чтобы получить большую долю нагрузки, чем другие. Это иногда используется в качестве способа когда одна часть серверов имеет больше возможностей, чем другие, и не всегда работают так, как хотелось.
  • Приоритет активации: когда количество доступных серверов падает ниже определенного числа, или нагрузка становится слишком высокой, часть резервных серверов может быть переведено в оперативный режим.
  • SSL разгрузка и ускорение: в зависимости от загруженности, обработка шифрования и аутентификации для SSL запроса может занимать значительную часть процессорного времени; поскольку запросы увеличивают время отклика для пользователей, так как протокол SSL увеличивает расходы распределяемые между веб-серверами. Снять этот спрос на веб-серверах, балансер может завершать SSL-соединения, передавая запросы https, как и http-запросов к веб-серверам. Если балансер сам по себе не перегружается, это не ухудшит производительность воспринимаемая конечными пользователями. Недостатком этого подхода является то, что вся обработка SSL сосредоточено на одном устройстве (балансировщик), который может стать новым «узким местом». В некоторое оборудование балансировки нагрузки входит специализированное оборудование для обработки SSL. Вместо того, чтобы модернизировать балансировщик нагрузки, который стоит достаточно дорого специализированного оборудования, может быть дешевле отказаться от SSL разгрузки и добавить несколько веб-серверов. Кроме того, некоторые серверные вендоры, такие как Oracle/Sun теперь включают аппаратное ускорение шифрования в свои процессоры такие как на контроллере T2000. F5 сети включает выделенное SSL ускорение аппаратных средств карты в их локальный трафик менеджер (ЛТМ), который используется для шифрования и расшифровки SSL-трафика. Одной из явных выгод для разгрузки SSL в балансировки заключается в том, что он позволяет делать балансировку или коммутацию контента на основе данных в https-запроса.
  • Распределенный отказ в обслуживании (DDoS-атак) атаки защиты: балансировщики нагрузки обеспечивают защиту с помощью Син куки файлов и задержки ответа (фоновые сервера не видят клиента, пока он не подтвердит себя по TCP) для смягчения Син флуд атак и разгружает серверы на более эффективную платформу.
  • Http-сжатие: уменьшает объем передаваемых данных по http, используя сжатие GZIP поддерживается всеми современными браузерами. Чем дольше реакция и чем дальше клиент, тем больше эта функция может уменьшить время отклика. Компромисс в том, что эта функция добавляет дополнительную нагрузку на Балансировщик и снимает её с Веб-сервера.
  • Разгрузка TCP: разные производители используют разные термины для этого, но идея заключается в том, что обычно каждый http-запрос от каждого клиента-это разные TCP-соединения. Данная функция использует протокол HTTP/1.1, чтобы объединить несколько http-запросов от нескольких клиентов в один TCP-сокет с фоновыми серверами.
  • Буферизация TCP: балансировщик нагрузки может держать буфер ответов от сервера и постепенно отвечать для медленных клиентов, позволяя веб-серверу быть свободным для других задач, это быстрее чем отправить весь запрос клиента серверу напрямую.
  • Прямой Серверный Ответ: вариант для асимметричного распределения нагрузки, где запрос и ответ имеют различные сетевые пути.
  • Проверка работоспособности: балансировщик опрашивает серверы на доступность и удаляет из пула недоступные серверы.
  • Кэширование http: балансировщик сохраняет статическое содержимое так, что некоторые запросы могут быть обработаны без обращения к серверам.
  • Фильтрация Контента: некоторые балансировщики могут произвольно изменять пути движения.
  • Безопасности http: некоторые балансировщики могут скрыть ошибки http страниц, удалить сервер идентификации заголовки из http-ответы, и шифровать куки, так что конечные пользователи не могут манипулировать ими.
  • Организация очередей с учетом приоритетов: также известен как формирование скорости трафика, возможность дать разные приоритеты для разных передач.
  • Контентно-зависимые переключения: большинство балансировщиков нагрузки могут отправлять запросы на разные серверы на основе URL-адресов запрашивается, предполагая, что запрос не шифруется (http) или если он зашифрован (через https), что https-запрос расшифровывается в подсистеме балансировки нагрузки.
  • Клиент аутентификация: аутентификация пользователей с различных источников аутентификации, прежде чем разрешить им доступ к сайту.
  • Программный трафик манипуляции: по крайней мере один балансировщик позволяет использовать скриптовый язык, чтобы разрешить пользовательские методы балансировки, произвольные манипуляции с трафиком, и многое другое.
  • Брандмауэр: прямые соединения с сервером имеют большие возможности, для сети. Из соображений безопасности балансировщик используют как Брандмауэр (это набор правил, которые решают, является ли полезным трафик и который проходит до бекенд серверов или нет.
  • Система предотвращения вторжений: предложение безопасности на уровне приложений в дополнение к сетевому/транспортному уровню безопасности брандмауэра.

Использования в телекоммуникационных сетях [ править | править код ]

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

Используя балансировку нагрузки, обе ссылки могут быть заняты все время. Устройство или программа контролирует наличие всех звеньев и выбирает путь для отправки пакетов. Использование нескольких ссылок одновременно увеличивает доступную полосу пропускания.

Кратчайший Путь Преодоления [ править | править код ]

Стандарт IEEE утвердил стандарт IEEE 802.1 р-р стандартный мая 2012 года [2] также известно и задокументировано в большинстве книг в качестве Кратчайшего пути преодоления (КПП). КПП позволяет всем ссылкам, чтобы быть активными через несколько путей равной значимости, обеспечивает более быструю сходимость сокращая время простоя и упрощает использование балансировки нагрузки в сети ячеистой топологии (частично и/или полностью подключеной), позволяя трафику распределять нагрузку для всех путей сети. [3] [4] КПП призвана практически исключить влияние человеческого фактора в процессе настройки и сохраняет природу «plug-and-play» подключи-и-играй, что создаёт Ethernet в качестве де-факто протокола во втором слое. [5]

Маршрутизация [ править | править код ]

Многие телекоммуникационные компании имеют несколько маршрутов через свои сети или к внешним сетям. Они используют сложные нагрузки для смены движения с одного пути на другой, чтобы избежать перегрузки сети на какой-либо конкретной ссылке, а иногда и свести к минимуму стоимость транзитных перевозок через внешние сети или улучшение надежности сети.

Другой способ использования балансировки нагрузки в сети с мониторингом деятельности. Балансировщики нагрузки могут быть использованы для разбиения огромных потоков данных на несколько суб-потоков и использовать несколько сетевых анализаторов, где каждый читает часть исходных данных. Это очень полезно для мониторинга быстрых сетей, таких как порта 10gbe или STM64, где комплекс обработки данных может быть невозможен на скорости проводного соединеия.

Отношение к отказоустойчивости [ править | править код ]

Балансировка нагрузки часто используется для реализации отказоустойчивости—продолжение работы службы после отказа одного или нескольких её компонентов. Компоненты контролируются постоянно (например, веб-серверы могут контролироваться выборкой известных страниц), и когда один перестанет реагировать, балансировщик нагрузки информируется и больше не шлет трафик на этот сервер. Когда компонент возвращается на линию, балансировщик нагрузки начинает маршрутизировать трафик к нему снова. Для того чтобы это работало, должен быть по крайней мере один компонент в количестве, превышающем емкость службы (N+1 резервирование). Это гораздо дешевле и более гибким, чем отказоустойчивого подходы в котором каждый живой компонент работает в паре с единой резервной копии компонента, который берет на себя в случае выхода из строя (двойное модульное резервирование). Некоторые типы RAID систем можно также использовать для горячий резервирования для подобного эффекта.

Ранее я немного касался настройки nginx в качестве web сервера или proxy сервера для web приложения. Сегодня я расскажу, как настроить балансировку нагрузки бэкендов с помощью nginx. В качестве примера возьму простую ситуацию, когда трафик будет распределяться между тремя одинаковыми серверами.

Введение

Ранее я подробно рассказывал о базовой настройке nginx и настройки его в качестве proxy сервера. Так же у меня есть подробная статья по настройке web сервера на базе Centos 7. Сегодня я расскажу о том, как настроить балансировку нагрузки с помощью nginx. Чаще всего это необходимо для балансировки нагрузки между бэкендами и обеспечения отказоустойчивости в работе web сервиса. Существуют различия в возможностях тонкой настройки балансировщика в бесплатной и платной версии nginx plus. Это один из первых моментов, где я столкнулся с тем, что мне стали необходимы функции платной версии, которых не было в бесплатной. Но цена nginx plus велика.

Читайте также:  Via karaoke digital mixer service что это

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

Добавление бэкендов

Для того, чтобы начать балансировать нагрузку, необходимо добавить бэкенды в настройки nginx. Для примера, я возьму отдельный виртуальный хост. Идем в его конфиг и в самое начало добавляем три бэкенда через директиву upstream.

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

Этого минимального набора настроек достаточно, чтобы nginx начал равномерно распределять запросы между двумя серверами. Но в реальной ситуации требуется более детальная настройка балансировщика. Для этого используются следующие параметры:

weight Задает вес сервера, по умолчанию 1. Чем больше вес сервера, тем пропорционально больше запросов он будет принимать от балансировщика.
max_conns Ограничивает максимальное число одновременных активных соединений к проксируемому серверу Значение по умолчанию равно 0 и означает, что ограничения нет.
max_fails Задаёт число неудачных попыток работы с сервером, которые должны произойти в течение времени, заданного параметром fail_timeout, чтобы сервер считался недоступным на период времени, также заданный параметром fail_timeout. Дефолтное значение — 1.
fail_timeout Задаёт время, в течение которого должно произойти заданное число неудачных попыток работы с сервером для того, чтобы сервер считался недоступным и время, в течение которого сервер будет считаться недоступным. По умолчанию параметр равен 10 секундам.
backup Помечает сервер как запасной сервер. На него будут передаваться запросы в случае, если не работают основные серверы.
down Помечает сервер как постоянно недоступный.

Подробнее об этом написано в официальной документации, в описании модуля ngx_http_upstream_module. К примеру, конфиг бэкендов для балансировки может быть таким.

С такими настройками после двух неудачных попыток соединения в течении 10 секунд, бэкенд будет выведен из работы на те же 10 секунд.

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

Соединения к серверам для балансировки нагрузки могут распределяться по различным правилам. Существуют несколько методов распределения запросов. Я перечислю основные:

  • round-robin — используется по умолчанию. Веб сервер равномерно распределяет нагрузку на сервера с учетом их весов. Специально указывать этот метод в конфигурации не надо.
  • least-connected — запрос отправляется к серверу с наименьшим количеством активных подключений. В конфигурации данный параметр распределения запросов устанавливается параметром least_conn.
  • ip-hash — используется хэш функция, основанная на клиентском ip адресе, для определения, куда направить следующий запрос. Используется для привязки клиента к одному и тому же серверу. В предыдущих методах один и тот же клиент может попадать на разные серверы.
  • hash — задаёт метод балансировки, при котором соответствие клиента серверу определяется при помощи хэшированного значения ключа. В качестве ключа может использоваться текст, переменные и их комбинации.
  • random — балансировка нагрузки, при которой запрос передаётся случайно выбранному серверу, с учётом весов.

В платной версии существуют дополнительный более продвинутый метод распределения нагрузки — least_time, при котором запрос передаётся серверу с наименьшими средним временем ответа и числом активных соединений с учётом весов серверов.

Проблемы балансировки нагрузки

Проблем при балансировки нагрузки с помощью nginx может быть масса. В обычном рабочем проекте нельзя просто взять и разделить нагрузку на несколько серверов. Само приложение, его БД должны быть готовы к этому. Первое, с чем вы столкнетесь — как правильно определить, что с сервером проблемы. В бесплатной версии nginx нет никаких инструментов для того, чтобы определить, что ваш бэкенд отвечает правильно.

Допустим, один из серверов перегружен и он отдает неправильные ответы. То есть он жив, отвечает, но ответы нам не подходят. Балансировщик будет считать, что все в порядке, запросы на проблемный сервер будут продолжать идти. Nginx исключит его из списка бэкендов только тогда, когда он полностью перестанет отвечать. Но это лишь малая часть проблем, которые могут приключиться. По моему опыту, чаще всего сервера не отваливаются полностью, а начинают тупить или отдавать, к примеру 502 ошибку. В бесплатной версии nginx будет считать, что все в порядке.

Для того, чтобы анализировать ответ бэкенда и в зависимости от этого ответа, решать, в каком состоянии находится сервер, вам необходим модуль ngx_http_upstream_hc_module. Он доступен только в коммерческой подписке. С помощью этого модуля можно тестировать код ответа, наличие или отсутствие определённых полей заголовка и их значений, а также содержимое тела ответа. Без этих данных качественно настроить работу балансировщика трудно.

Отмечу еще несколько полезных настроек, на которые надо обратить внимание, при настройке балансировки нагрузки с помощью nginx:

  • proxy_connect_timeout — задаёт таймаут для установления соединения с проксированным сервером. При отсутствии ответа за указанное время сервер будет считаться неработающим. Дефолтное значение 60 секунд. Это очень много, если у вас большие нагрузки. За минуту скопится огромное количество висящих соединений, которые мог бы обработать другой бэкенд.
  • proxy_read_timeout — задаёт таймаут при чтении ответа проксированного сервера. Дефолт тоже 60 секунд. Чаще всего имеет смысл уменьшить значение.

Полный конфиг балансировщика nginx

Привожу пример полного конфига виртуального хоста для балансировки нагрузки на примере nginx. Это не пример с рабочего сервера, так что возможны какие-то мелкие ошибки или опечатки. Не тестировал конфиг, так как это не готовое how to, а просто рекомендации и описание. Составил его чтобы было представление, как все это выглядит в единой конфигурации.

За подробностями параметров секции с proxy_pass переходите в отдельную статью на эту тему.

Заключение

Мне не приходилось пробовать в деле никаких других балансировщиков, кроме Nginx. Знаю, что есть haproxy, но попробовать так и не дошли руки. Бесплатная версия nginx очень слабо подходит для полноценной балансировки крупного проекта, либо я просто не понимаю, как его правильно использовать. Реально не хватает тех фич, которые есть в Nginx Plus. До того момента, как не начал использовать балансировщик, не понимал толком, что там такого в платной версии. Теперь прекрасно понимаю 🙂

Готовые примеры балансировки с использованием фич Nginx Plus приведены в этой статье. Так же обращаю внимание на формат логов, который для удобства стоит подправить под использование бэкендов. Этот вопрос я рассмотрел отдельно в статье про мониторинг производительности бэкендов с помощью elk stack.

Буду рад любым комментариям, ссылкам, советам по существу затронутой темы. Я в ней новичок. Ни на что не претендую, поделился своим опытом.

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

Хотя большинство используют nginx в качестве HTTP-сервера, он также имеет встроенные функции балансировки нагрузки. В этой статье мы рассмотрим, как настроить его в вашей системе.

Основы балансировки нагрузки

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

Читайте также:  Фитнес часы для iphone

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

Балансировщики нагрузки обычно классифицируются как аппаратные и программные. Первые, являются специализированным оборудованием и несут специализированные интегральные схемы (ASIC), которые очень эффективно маршрутизируют трафик. С другой стороны, программные балансировщики нагрузки, такие как nginx или HAproxy, выполняют балансировку нагрузки в программном обеспечении.

Кроме того, балансировка нагрузки может выполняться на различных сетевых уровнях. Как следует из названия, балансировщики нагрузки уровня 4 балансируют трафик, проверяя запросы и ответы на транспортном уровне. Кроме того, существуют подсистемы балансировки нагрузки уровня 7, которые проверяют трафик на уровне приложений. Последний немного более мощный, поскольку он имеет высокий уровень видения вещей. Например, балансировщик 7-го уровня, который знает о HTTP, может проверять URL-адреса и отправлять запросы различным наборам серверных частей в зависимости от URL-адреса.

Nginx может выполнять как балансировку нагрузки уровня 4 для TCP и UDP, так и балансировку нагрузки HTTP уровня 7. В следующих нескольких разделах мы рассмотрим, как настроить nginx для этой цели.

В большинстве дистрибутивов Linux файл конфигурации nginx находится в /etc/nginx/nginx.conf . Однако в Debian/Ubuntu этот файл разделен на два разных: /etc/nginx/nginx.conf для основной конфигурации и /etc/nginx/sites-enabled/default для отдельных веб-сайтов, которые вы размещаете. Если вы используете Debian/Ubuntu, вы должны добавить upstream блоки в первый, а блок location во второй.

Балансировка нагрузки веб-приложений

Прежде чем продолжить, вам нужно настроить несколько внутренних серверов, на которых будет работать наше веб-приложение. На этих серверах будет работать HTTP-сервер на каждом из этих серверов. В нашем примере мы предположим, что мы уже настроили их, и эти серверы доступны на 192.168.0.1 , 192.168.0.2 и 192.168.0.3 . Конечно, они не должны быть внутренними IP-адресами — они также могут быть внешними IP-адресами или именами хостов.

Теперь есть две вещи, которые вам нужно настроить в качестве балансировщика нагрузки. Во-первых, в разделе http необходимо указать набор внутренних серверов с блоком upstream . Затем вам необходимо передать эти запросы на серверы. Для этого откройте файл конфигурации и добавьте следующие строки:

Это говорит nginx о необходимости передавать HTTP-запросы для любого URL-адреса на набор внутренних серверов, которые мы назвали backend1 . Если вы хотите передать только определенные URL-адреса, вы можете сделать что-то вроде:

Это будет соответствовать всем URL-адресам, начинающимся с «/shop», и передавать их на серверы бэкэнда. Вы также можете расширить эту концепцию, чтобы передавать разные URL-адреса различным бэкэндам. В этом примере мы добавили еще один бэкэнд для серверов, на которых размещается блог. Затем мы настроили nginx для передачи URL-адресов, начинающихся с «/blog», новому бэкэнду.

Nginx также поддерживает пару прокси для нескольких других протоколов с такими директивами, как FastCGI и uWSGI с директивами fastcgi_pass и uwsgi_pass. Скажем, например, что на каждом внутреннем сервере на порту 9000 работает демон PHP-FPM, и вы хотите передавать запросы к ним через прокси. Вот как будет выглядеть конфигурация:

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

У nginx есть несколько стратегий выбора сервера для отправки запросов. По умолчанию он использует алгоритм циклического перебора для определения сервера, на который должен быть отправлен запрос. Однако доступны и другие стратегии, которые вы можете включить вручную. Стратегия least_conn выбирает сервер, который обрабатывает наименьшее количество соединений. С другой стороны, стратегия ip_hash выбирает серверы на основе результата запуска хэш-функции на IP. Это означает, что запросы с одного и того же IP-адреса попадают на один и тот же сервер.

Чтобы использовать стратегию, отличную от принятой по умолчанию, просто укажите ее имя в upstream блоке:

Существует также универсальная hash директива, которую можно использовать с любым значением HTTP. В этом примере мы распределили запросы на основе URL:

Кроме того, вы можете изменить стратегию по умолчанию, назначив приоритет серверу. По умолчанию все серверы имеют приоритет 1, что означает, что nginx не «предпочитает» один сервер другому, кроме применения правил используемой стратегии. Пример конфигурации с приоритетами выглядит следующим образом:

Как вы можете сказать, мы используем стратегию циклического перебора в этом примере. С приоритетами, которые мы показали в примере выше, каждые 4 из 7 запросов будут отправляться на первый сервер, 2 из них на второй и 1 на третий. (Как мы упоминали ранее, приоритет по умолчанию равен 1, поэтому мы оставили его в приведенном выше примере.)

Расширенные настройки

Когда nginx передает запросы на эти серверы, он также пассивно выполняет проверку работоспособности. Если серверу не удается отправить ответ, он автоматически помечается как таковой, и nginx в течение некоторого времени избегает отправки ему запросов. Значение fail_timeout контролирует время, до которого nginx избегает отправки запросов на сервер. Значение max_fails устанавливает количество запросов, которые должны завершиться неудачей, после чего nginx помечает сервер как таковой.

В приведенном ниже примере мы установили max_fails 3, а fail_timeout 20 секундам для первого сервера:

Кроме того, вы можете пометить определенный сервер, который будет обрабатываться по-разному. Если вы выполняете обслуживание на одном из внутренних серверов, вы можете пометить его как down . Запросы, которые будут обрабатываться этим сервером, теперь отправляются на следующий сервер в группе. Вы также можете пометить определенный сервер в качестве backup сервера. Запросы будут переданы ему, когда все остальные серверы будут недоступны. Пример этих двух директив показан ниже:

Некоторые общие проблемы

В зависимости от типов приложений, которые вы развернули, балансировщик нагрузки может вызвать определенные проблемы. Часто вы получите 404 или другие ошибки из веб-приложения. Обычно это происходит потому, что заголовок «Host» содержит адрес внутреннего сервера вместо его исходного значения. Чтобы исправить это, вы можете вручную установить его в блоке location:

Многие сложные веб-приложения хранят состояние локально, и они могут не работать, если балансировщик нагрузки распределяет запросы сеанса по разным серверам. Чтобы решить эту проблему, балансировщик нагрузки должен отслеживать исходный внутренний сервер, который ответил на первоначальный запрос. Эта концепция известна как «постоянство сеанса». К сожалению, эта функция доступна только в коммерческой версии nginx. Однако, в качестве обходного пути, вы можете попробовать директиву ip_hash , которая будет перенаправлять запросы с одного и того же IP на один и тот же внутренний сервер. IP-адреса обычно меняются не очень часто, поэтому это может работать достаточно хорошо для вашего варианта использования.

Балансировка нагрузки nginx транспортного уровня

Как мы упоминали ранее, nginx также может выполнять балансировку нагрузки на транспортном уровне. Синтаксис немного отличается от того, который мы видели ранее. В частности, как upstream и server разделы содержатся внутри stream блока.

Чтобы использовать эту функцию, вы должны скомпилировать nginx с ключом –with-stream . В Debian и Ubuntu версия nginx в репозиториях уже скомпилирована с этим флагом, поэтому вы можете использовать ее напрямую.

Предположим, у вас есть несколько DNS-серверов, и вы хотите использовать nginx в качестве балансировщика нагрузки. Вам просто нужно поместить это в файл конфигурации:

Здесь мы определили несколько бэкэндов DNS, а затем настроили nginx для прослушивания входящих пакетов UDP через порт 53. Директива proxy_pass отправляет их на бэкэнд-серверы. Также по умолчанию nginx ожидает, что серверная часть может отправить один или несколько ответов. Поскольку будет один ответ на один запрос, мы установили proxy_responses в 1.

Балансировка нагрузки с TCP довольно похожа.

Здесь также применяются стратегии балансировки нагрузки и другие параметры конфигурации, которые мы описали ранее.

Заключение

Nginx предоставляет мощные возможности балансировки нагрузки с широким спектром опций. Если вы хотите узнать больше, обязательно ознакомьтесь с официальной документацией .

Если вам понравился этот пост, пожалуйста, поделитесь им.

Поделиться ссылкой:

Похожее

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Комментировать
534 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock
detector