Балансировка нагрузки (вычисления) - Load balancing (computing)

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

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

Обзор проблемы

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

Характер задач

Эффективность алгоритмов балансировки нагрузки критически зависит от характера задач. Следовательно, чем больше информации о задачах доступно на момент принятия решения, тем больше потенциал для оптимизации.

Размер задач

Прекрасное знание времени выполнения каждой из задач позволяет достичь оптимального распределения нагрузки (см. Алгоритм суммы префиксов ). К сожалению, это на самом деле идеализированный случай. Знать точное время выполнения каждой задачи - крайне редкая ситуация.

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

Зависимости

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

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

Разделение задач

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

Статические и динамические алгоритмы

Статический

Алгоритм балансировки нагрузки является «статическим», когда он не принимает во внимание состояние системы для распределения задач. Таким образом, состояние системы включает такие параметры, как уровень загрузки (а иногда даже перегрузки) определенных процессоров. Вместо этого заранее делаются предположения о системе в целом, например о времени поступления и требованиях к ресурсам для входящих задач. Кроме того, известно количество процессоров, их мощность и скорость передачи данных. Следовательно, статическая балансировка нагрузки направлена ​​на то, чтобы связать известный набор задач с доступными процессорами, чтобы минимизировать определенную функцию производительности. Уловка заключается в самой концепции этой функции производительности.

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

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

Динамический

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

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

Аппаратная архитектура

Гетерогенные машины

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

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

Общая и распределенная память

Параллельные компьютеры часто делятся на две широкие категории: те, в которых все процессоры используют одну общую память, в которой они читают и записывают параллельно ( модель PRAM ), и те, в которых каждый вычислительный блок имеет свою собственную память ( модель распределенной памяти ), и где информация обменивается сообщениями.

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

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

Иерархия

Адаптируясь к структурам оборудования, показанным выше, можно выделить две основные категории алгоритмов балансировки нагрузки. С одной стороны, та, где задачи назначаются «мастером» и выполняются «рабочими», которые информируют мастера о ходе своей работы, а мастер может затем взять на себя назначение или переназначение рабочей нагрузки в случае динамического алгоритм. В литературе это называется архитектурой «мастер-рабочий» . С другой стороны, управление может быть распределено между разными узлами. Затем алгоритм балансировки нагрузки выполняется для каждого из них, и ответственность за назначение задач (а также, при необходимости, переназначение и разделение) разделяется. Последняя категория предполагает алгоритм динамической балансировки нагрузки.

Поскольку дизайн каждого алгоритма балансировки нагрузки уникален, предыдущее различие должно быть оговорено. Таким образом, также возможно иметь промежуточную стратегию, например, с «главными» узлами для каждого субкластера, которые сами подчиняются глобальному «главному». Существуют также многоуровневые организации с чередованием стратегий управления ведущий-ведомый и распределенного управления. Последние стратегии быстро усложняются и встречаются редко. Дизайнеры предпочитают алгоритмы, которыми легче управлять.

Адаптация к более крупным архитектурам (масштабируемость)

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

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

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

Отказоустойчивость

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

Подходы

Статическое распределение с полным знанием задач: сумма префикса

Если задачи независимы друг от друга и если время их выполнения и задачи можно разделить, существует простой и оптимальный алгоритм.

Разделив задачи таким образом, чтобы предоставить каждому процессору одинаковый объем вычислений, все, что остается сделать, - это сгруппировать результаты вместе. Используя алгоритм суммирования префиксов , это деление может быть вычислено за логарифмическое время относительно количества процессоров.

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

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

Распределение статической нагрузки без предварительного знания

Даже если время выполнения заранее не известно, статическое распределение нагрузки всегда возможно.

Планирование с циклическим перебором

В алгоритме циклического перебора первый запрос отправляется первому серверу, затем следующий - второму и так далее до последнего. Затем он запускается снова, присваивая следующий запрос первому серверу и так далее.

Этот алгоритм можно взвесить так, чтобы самые мощные блоки получали наибольшее количество запросов и получали их первыми.

Рандомизированный статический

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

Производительность этой стратегии (измеряемая в общем времени выполнения для данного фиксированного набора задач) снижается с увеличением максимального размера задач.

Другие

Конечно, есть и другие способы присвоения:

• Меньше работы: назначайте серверам больше задач, выполняя меньше (метод также может быть взвешенным).
• Хеш: распределяет запросы в соответствии с хеш-таблицей .
• Сила двух вариантов: выберите два сервера наугад и выберите лучший из двух вариантов.

Схема мастер-рабочий

Схемы Master-Worker относятся к числу простейших алгоритмов динамической балансировки нагрузки. Мастер распределяет рабочую нагрузку между всеми работниками (также иногда называемыми «подчиненными»). Изначально все рабочие простаивают и сообщают об этом мастеру. Мастер отвечает на запросы работников и раздает им задания. Когда у него больше нет задач, он информирует рабочих, чтобы они перестали просить о задачах.

Преимущество этой системы в том, что она распределяет нагрузку очень справедливо. Фактически, если не принимать во внимание время, необходимое для назначения, время выполнения будет сопоставимо с суммой префиксов, показанной выше.

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

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

Неиерархическая архитектура, без знания системы: кража работы

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

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

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

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

Принцип

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

Эффективность

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

Случаи применения

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

Интернет-сервисы

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

Циклический DNS

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

Делегирование DNS

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

one.example.org A 192.0.2.1
two.example.org A 203.0.113.2
www.example.org NS one.example.org
www.example.org NS two.example.org

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

@ in a 192.0.2.1

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

@ in a 203.0.113.2

Таким образом, когда сервер не работает, его DNS не отвечает, и веб-служба не получает никакого трафика. Если линия к одному серверу перегружена, ненадежность DNS гарантирует, что меньше HTTP-трафика достигает этого сервера. Более того, самый быстрый ответ DNS на преобразователь почти всегда - это ответ от ближайшего к сети сервера, что обеспечивает географическую балансировку нагрузки. Короткий TTL на A-записи помогает обеспечить быстрое перенаправление трафика, когда сервер выходит из строя. Следует учитывать возможность того, что этот метод может вызвать переключение отдельных клиентов между отдельными серверами в середине сеанса.

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

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

При таком подходе метод доставки списка IP-адресов клиенту может варьироваться и может быть реализован как список DNS (доставляемый всем клиентам без циклического перебора) или посредством жесткого кодирования его в список. Если используется «умный клиент», который обнаруживает, что случайно выбранный сервер не работает и снова случайным образом подключается, он также обеспечивает отказоустойчивость .

Балансировщики нагрузки на стороне сервера

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

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

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

Алгоритмы планирования

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

Упорство

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

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

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

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

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

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

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

Возможности балансировщика нагрузки

Аппаратные и программные балансировщики нагрузки могут иметь множество специальных функций. Фундаментальная особенность балансировщика нагрузки - это возможность распределять входящие запросы по нескольким внутренним серверам в кластере в соответствии с алгоритмом планирования. Большинство из следующих функций зависят от производителя:

Асимметричная нагрузка

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

Приоритетная активация

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

Разгрузка и ускорение TLS

Ускорение TLS (или его предшественника SSL) - это метод разгрузки вычислений криптографического протокола на специализированное оборудование. В зависимости от рабочей нагрузки обработка требований к шифрованию и аутентификации запроса TLS может стать основной частью нагрузки на ЦП веб-сервера; по мере увеличения спроса пользователи будут видеть более медленное время отклика, поскольку накладные расходы TLS распределяются между веб-серверами. Чтобы устранить эту потребность на веб-серверах, балансировщик может разрывать соединения TLS, передавая запросы HTTPS в виде запросов HTTP на веб-серверы. Если сам балансировщик не перегружен, это не приведет к заметному снижению производительности, воспринимаемой конечными пользователями. Обратной стороной этого подхода является то, что вся обработка TLS сосредоточена на одном устройстве (балансировщике), которое может стать новым узким местом. Некоторые устройства балансировки нагрузки включают специализированное оборудование для обработки TLS. Вместо обновления балансировщика нагрузки, который представляет собой довольно дорогое выделенное оборудование, может быть дешевле отказаться от разгрузки TLS и добавить несколько веб-серверов. Кроме того, некоторые поставщики серверов, такие как Oracle / Sun, теперь включают оборудование для криптографического ускорения в свои процессоры, такие как T2000. F5 Networks включает в себя выделенную аппаратную карту ускорения TLS в своем локальном диспетчере трафика (LTM), которая используется для шифрования и дешифрования трафика TLS. Одно очевидное преимущество разгрузки TLS в балансировщике заключается в том, что он позволяет ему выполнять балансировку или переключение контента на основе данных в запросе HTTPS.

Распределенная защита от атак типа отказ в обслуживании (DDoS)

Балансировщики нагрузки могут предоставлять такие функции, как файлы cookie SYN и отложенное связывание (внутренние серверы не видят клиента, пока он не завершит свое TCP-рукопожатие), чтобы смягчить атаки SYN-флуда и, как правило, перенести работу с серверов на более эффективную платформу.

HTTP-сжатие

Сжатие HTTP уменьшает объем данных, передаваемых для объектов HTTP, за счет использования сжатия gzip, доступного во всех современных веб-браузерах. Чем больше отклик и чем дальше находится клиент, тем больше эта функция может сократить время отклика. Компромисс заключается в том, что эта функция увеличивает нагрузку на ЦП для балансировщика нагрузки и может выполняться веб-серверами.

Разгрузка TCP

Разные поставщики используют разные термины для этого, но идея состоит в том, что обычно каждый HTTP-запрос от каждого клиента представляет собой отдельное TCP-соединение. Эта функция использует HTTP / 1.1 для объединения нескольких HTTP-запросов от нескольких клиентов в один TCP-сокет к внутренним серверам.

Буферизация TCP

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

Прямой возврат сервера

Вариант асимметричного распределения нагрузки, когда запрос и ответ имеют разные сетевые пути.

Проверка здоровья

Балансировщик опрашивает серверы на предмет работоспособности уровня приложений и удаляет отказавшие серверы из пула.

HTTP-кеширование

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

Фильтрация контента

Некоторые балансировщики могут произвольно изменять проходящий трафик.

Безопасность HTTP

Некоторые балансировщики могут скрывать страницы ошибок HTTP, удалять заголовки идентификации сервера из ответов HTTP и шифровать файлы cookie, чтобы конечные пользователи не могли ими манипулировать.

Приоритетная очередь

Также известное как формирование скорости , способность назначать разный приоритет разному трафику.

Переключение с учетом содержимого

Большинство балансировщиков нагрузки могут отправлять запросы на разные серверы в зависимости от запрашиваемого URL-адреса, при условии, что запрос не зашифрован (HTTP) или, если он зашифрован (через HTTPS), запрос HTTPS завершается (расшифровывается) в балансировщике нагрузки.

Проверка подлинности клиента

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

Программное управление трафиком

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

Межсетевой экран

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

Система предотвращения вторжений

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

Телекоммуникации

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

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

Преодоление кратчайшего пути

IEEE утвердил стандарт IEEE 802.1aq в мае 2012 года, также известный как мост по кратчайшему пути (SPB). SPB позволяет всем каналам быть активными через несколько путей с одинаковой стоимостью, обеспечивает более быстрое время конвергенции для сокращения времени простоя и упрощает использование балансировки нагрузки в топологиях ячеистой сети (частично подключенных и / или полностью подключенных), позволяя трафику распределять нагрузку по всем пути сети. SPB разработан для того, чтобы практически исключить человеческую ошибку во время настройки и сохраняет принцип plug-and-play, который установил Ethernet как фактический протокол на уровне 2.

Маршрут 1

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

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

Сети центров обработки данных

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

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

Отказоустойчивость

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

Смотрите также

использованная литература

внешние ссылки

• Маршрутизация сервера для балансировки нагрузки с полным автоматическим восстановлением после сбоя