# Основы балансировки нагрузки > Основы балансировки нагрузки на уровне пакетов, сети, серверов, L4 и L7 --- Индекс LLMS: [llms.txt](/ru/llms.txt) --- Этот документ знакомит с HAProxy тех, кто ещё не знает продукт, а также тех, кто знаком с его старыми версиями и хочет открыть его заново. Главная цель — предоставить все сведения, необходимые для решения, подходит ли HAProxy пользователю. Опытные пользователи могут найти здесь решения ранее возникших задач, о которых они не знали из-за незнакомства с новой функцией. Также приведены сведения для расчёта ресурсов, описан жизненный цикл продукта и даны сравнения с продуктами, чьи возможности частично пересекаются с HAProxy. Этот документ не содержит помощи или советов по настройке, но объясняет, где искать соответствующую документацию. Руководство представлено плоской последовательностью тематических страниц в боковой панели HAProxy. Балансировка нагрузки объединяет несколько компонентов, чтобы получить общую производительность выше производительности каждого из них, без вмешательства конечного пользователя и с возможностью масштабирования. В результате за время, необходимое одному компоненту для выполнения одной операции, одновременно выполняется больше операций. Однако отдельная операция по-прежнему выполняется только на одном компоненте и не ускоряется по сравнению с работой без балансировки. Чтобы задействовать все компоненты и полностью использовать преимущества балансировки, всегда нужно как минимум столько же операций, сколько компонентов, а также эффективный механизм распределения нагрузки. Наглядный пример — число полос на автомагистрали: оно позволяет пропустить больше автомобилей за одно и то же время без увеличения скорости каждого автомобиля. Примеры балансировки нагрузки: - Планирование процессов в многопроцессорных системах. - Балансировка нагрузки каналов связи (например, EtherChannel, Bonding). - Балансировка по IP-адресам (например, ECMP, циклический выбор DNS). - Балансировка нагрузки серверов (с помощью балансировщиков нагрузки). Механизм или компонент, выполняющий распределение нагрузки, называется балансировщиком нагрузки. В веб-средах такие компоненты называют «сетевыми балансировщиками нагрузки», а чаще просто «балансировщиками нагрузки», поскольку это наиболее известная область их применения. Балансировщик нагрузки может действовать: - На уровне канала: балансировка нагрузки каналов связи выбирает сетевой канал, по которому отправить пакет. - На уровне сети: сетевая балансировка нагрузки выбирает маршрут для последовательности пакетов. - На уровне сервера: балансировка нагрузки серверов определяет сервер, который обработает соединение или запрос. Существуют две разные технологии, решающие разные, хотя частично пересекающиеся задачи. В обоих случаях важно помнить: балансировка отклоняет трафик от его естественного пути, поэтому всегда требуется некоторая осторожность, чтобы сохранять необходимую согласованность всех решений о маршрутизации. Первая технология работает на уровне пакетов и обрабатывает их более или менее независимо. Между входными и выходными пакетами существует соответствие 1-к-1, поэтому трафик по обе стороны балансировщика можно отслеживать обычным анализатором сетевого трафика. Эта технология может быть очень дешёвой и чрезвычайно быстрой. Обычно она реализуется аппаратно, на ASIC, и позволяет достичь скорости линии — например, в коммутаторах с ECMP. Чаще всего она не хранит состояние, но может учитывать сеанс, к которому относится пакет; такой вариант называют layer4-LB или L4. Если пакеты не изменяются, возможна поддержка DSR — прямого ответа сервера без повторного прохождения через балансировщик. Однако содержимое практически не анализируется. Эта технология отлично подходит для балансировки на уровне сети, хотя иногда применяется и для простейшей высокоскоростной балансировки нагрузки серверов. Вторая технология работает с содержимым сеансов. Для этого входной поток необходимо собрать и обработать целиком. Содержимое можно изменить, а выходной поток разбивается на новые пакеты. Поэтому такую обработку обычно выполняют прокси, часто называемые балансировщиками нагрузки уровня 7 или L7. Это подразумевает два отдельных соединения по обе стороны балансировщика и отсутствие связи между размерами и числом входных и выходных пакетов. Клиенты и серверы не обязаны использовать один и тот же протокол: например, возможны IPv4 и IPv6 или незашифрованный трафик и SSL. Операции всегда сохраняют состояние, а обратный трафик обязательно проходит через балансировщик. Дополнительная обработка требует ресурсов, поэтому достичь скорости линии удаётся не всегда, особенно на маленьких пакетах. Зато технология даёт широкие возможности и обычно реализуется целиком программно, даже во встроенных аппаратных устройствах. Она отлично подходит для балансировки нагрузки серверов. Балансировщики, работающие с пакетами, обычно развёртываются в режиме сквозной пересылки: их устанавливают на обычном пути трафика, который они перенаправляют согласно конфигурации. Обратный трафик не обязательно проходит через балансировщик. Для направления трафика нужному адресату может изменяться сетевой адрес назначения. В таком случае обратный трафик обязательно должен проходить через балансировщик. Если маршруты этого не позволяют, балансировщик может также заменить исходный адрес пакетов своим, принудительно направляя обратный трафик через себя. Балансировщики на основе прокси развёртываются как серверы с собственными IP-адресами и портами, без изменения архитектуры. Иногда приходится адаптировать приложения, чтобы клиенты направлялись на IP-адрес балансировщика, а не прямо к серверу. Некоторым балансировщикам для этого нужно изменять ответы серверов — например, поле заголовка HTTP Location, используемое при перенаправлениях. Некоторые балансировщики на основе прокси умеют перехватывать трафик для чужого адреса и подставлять адрес клиента при соединении с сервером. Это позволяет развёртывать их как обычный маршрутизатор или межсетевой экран, в режиме сквозной пересылки, очень похожем на режим пакетных балансировщиков. Это особенно ценится в продуктах, сочетающих режим обработки пакетов и режим прокси. Очевидно, что DSR в таком случае по-прежнему невозможен, а обратный трафик необходимо направлять через балансировщик. Хорошо масштабируемая многоуровневая схема может начинаться с пограничного маршрутизатора, принимающего трафик из нескольких сбалансированных каналов и распределяющего его с помощью ECMP на первый уровень из нескольких пакетных балансировщиков с состоянием (L4). Эти балансировщики L4 передают трафик ещё большему числу балансировщиков на основе прокси (L7), которые разбирают содержимое и выбирают конечный сервер-получатель. Увеличение числа компонентов и возможных путей трафика повышает риск отказа. В очень больших средах нормально, когда несколько неисправных компонентов постоянно находятся на ремонте или замене. Балансировка без учёта работоспособности всего стека значительно снижает доступность. Поэтому любой разумно устроенный балансировщик проверяет, что компоненты, которым он собирается отправлять трафик, работают и доступны, и прекращает направлять трафик неисправным. Для этого применяют разные методы. Самый распространённый метод — периодические пробы, подтверждающие работоспособность компонента. Их называют «проверками работоспособности». Они должны соответствовать типам отказов, которые требуется выявить. Например, проверка ping не обнаружит, что веб-сервер аварийно завершился и больше не прослушивает порт. Соединение с портом выявит такую проблему, а более сложный запрос может также подтвердить работоспособность сервера и доступность используемой им базы данных. Проверки часто повторяют несколько раз, чтобы исключить случайные ошибки измерения. Интервал между ними должен быть достаточно мал, чтобы неисправный компонент не использовался слишком долго после возникновения ошибки. Другие методы анализируют выборку рабочего трафика, отправляемого адресату, проверяют правильность его обработки и исключают компоненты с некорректными ответами. Однако при этом приходится жертвовать частью рабочего трафика, что не всегда допустимо. Сочетание обоих механизмов объединяет их преимущества: для выявления отказа применяются оба, а для определения восстановления — только проверки работоспособности. Ещё один метод основан на централизованных сообщениях: центральный агент мониторинга периодически сообщает всем балансировщикам состояние всех компонентов. Это даёт каждому компоненту общее представление об инфраструктуре, хотя иногда с меньшей точностью или оперативностью. Такой подход лучше всего подходит для сред с большим числом балансировщиков и серверов. Балансировщики уровня 7 сталкиваются и с другой задачей — привязкой сеансов, также называемой сохранением привязки. Обычно несколько последовательных запросов или соединений от одного источника, например конечного пользователя, нужно направлять одному адресату. Самый известный пример — корзина интернет-магазина. Если каждый щелчок создаёт новое соединение, пользователя всегда необходимо отправлять на сервер, где хранится его корзина. Анализ содержимого позволяет легче выделить в запросе элементы для определения нужного сервера, но этого не всегда достаточно. Например, если ключом выбора сервера служит исходный адрес, можно применить алгоритм хеширования: один IP-адрес всегда направляется на один сервер на основе деления адреса на число доступных серверов. Но при отказе сервера результат изменится, и все пользователи внезапно попадут на другие серверы, потеряв свои корзины. Решение — запоминать выбранного адресата и при каждом появлении того же посетителя направлять его на тот же сервер независимо от числа доступных серверов. Сведения можно хранить в памяти балансировщика; если он не единственный, их может потребоваться реплицировать другим балансировщикам. Либо их можно разными способами хранить у клиента, если он способен передавать их с каждым запросом: посредством вставки cookie, перенаправления на поддомен и т. п. Дополнительное преимущество такого механизма — отсутствие зависимости от нестабильных или неравномерно распределённых сведений, например исходного IP-адреса. Именно это является главным доводом в пользу балансировщика уровня 7 вместо уровня 4. Чтобы извлечь cookie, поле заголовка host, URL или другие сведения, балансировщику может потребоваться расшифровать трафик SSL/TLS и, возможно, снова зашифровать его перед передачей серверу. Высокая стоимость этой операции объясняет, почему в некоторых инфраструктурах с большим объёмом трафика бывает много балансировщиков. Поскольку балансировщик уровня 7 выполняет множество сложных операций с трафиком — расшифровывает, разбирает, изменяет, сопоставляет cookie, выбирает сервер и т. п., — он действительно может вызывать проблемы. Но очень часто его обвиняют и в тех проблемах, которые он лишь выявил. Нередко обнаруживается нестабильность серверов, которые периодически отключаются и возвращаются в работу; жёстко заданные ссылки на веб-страницах, заставляющие клиентов обращаться прямо к определённому серверу в обход балансировщика; либо очень медленные ответы под высокой нагрузкой, вызывающие тайм-ауты. Поэтому ведение журнала — исключительно важная часть балансировки уровня 7. После сообщения о проблеме необходимо выяснить, принял ли балансировщик неверное решение и, если да, почему, чтобы исключить повторение. --- Обратные ссылки: - [HAProxy](/ru/docs/haproxy/) - [Ресурсы](/ru/docs/haproxy/resources/)