В вычислительной технике балансировка нагрузки — это процесс распределения набора задач по набору ресурсов (вычислительных блоков) с целью повышения эффективности их общей обработки. Балансировка нагрузки позволяет оптимизировать время отклика и избежать неравномерной перегрузки некоторых вычислительных узлов, в то время как другие вычислительные узлы остаются бездействующими.
Балансировка нагрузки является предметом исследований в области параллельных компьютеров . Существуют два основных подхода: статические алгоритмы, которые не учитывают состояние различных машин, и динамические алгоритмы, которые обычно являются более общими и более эффективными, но требуют обмена информацией между различными вычислительными блоками с риском потери. эффективности.
Алгоритм балансировки нагрузки всегда пытается решить конкретную проблему. Помимо прочего, необходимо учитывать характер задач, алгоритмическую сложность , аппаратную архитектуру, на которой будут работать алгоритмы, а также требуемую устойчивость к ошибкам . Поэтому необходимо найти компромисс, чтобы наилучшим образом удовлетворить требования конкретного приложения.
Эффективность алгоритмов балансировки нагрузки критически зависит от характера задач. Следовательно, чем больше информации о задачах доступно на момент принятия решения, тем больше потенциал для оптимизации.
Прекрасное знание времени выполнения каждой из задач позволяет достичь оптимального распределения нагрузки (см. алгоритм суммы префиксов ). [1] К сожалению, на самом деле это идеализированный случай. Знание точного времени выполнения каждой задачи — крайне редкая ситуация.
По этой причине существует несколько методов, позволяющих получить представление о разном времени выполнения. Прежде всего, в благоприятном сценарии, когда задачи относительно однородного размера, можно считать, что каждая из них потребует примерно среднего времени выполнения. С другой стороны, если время выполнения очень нерегулярно, необходимо использовать более сложные методы. Один из методов — добавить метаданные к каждой задаче. В зависимости от предыдущего времени выполнения аналогичных метаданных можно сделать выводы для будущей задачи на основе статистики. [2]
В некоторых случаях задачи зависят друг от друга. Эти взаимозависимости можно проиллюстрировать ориентированным ациклическим графом . Интуитивно понятно, что некоторые задачи не могут начаться, пока не будут завершены другие.
Если предположить, что требуемое время для каждой из задач известно заранее, оптимальный порядок выполнения должен приводить к минимизации общего времени выполнения. Хотя это NP-сложная задача, и поэтому ее сложно решить точно. Существуют алгоритмы, такие как планировщик заданий , которые рассчитывают оптимальное распределение задач с помощью метаэвристических методов.
Еще одной особенностью задач, критической для разработки алгоритма балансировки нагрузки, является их способность разбиваться на подзадачи во время выполнения. Алгоритм «Древовидных вычислений», представленный позже, в значительной степени использует эту особенность.
Алгоритм балансировки нагрузки является «статичным», когда он не учитывает состояние системы при распределении задач. Таким образом, состояние системы включает в себя такие показатели, как уровень загрузки (а иногда и перегрузки) определенных процессоров. Вместо этого заранее делаются предположения об общей системе, например, о времени прибытия и требованиях к ресурсам для входящих задач. Кроме того, известно количество процессоров, их мощность и скорость передачи данных. Таким образом, статическая балансировка нагрузки направлена на то, чтобы связать известный набор задач с доступными процессорами, чтобы минимизировать определенную функцию производительности. Хитрость заключается в концепции этой функции производительности.
Методы статической балансировки нагрузки обычно централизованы вокруг маршрутизатора или Master , который распределяет нагрузку и оптимизирует функцию производительности. Эта минимизация может учитывать информацию, связанную с распределяемыми задачами, и определять ожидаемое время выполнения.
Преимущество статических алгоритмов в том, что они просты в настройке и чрезвычайно эффективны в случае достаточно регулярных задач (например, обработка HTTP-запросов с веб-сайта). Однако по-прежнему существует некоторая статистическая вариативность в распределении задач, что может привести к перегрузке некоторых вычислительных блоков.
В отличие от алгоритмов статического распределения нагрузки, динамические алгоритмы учитывают текущую загрузку каждого из вычислительных блоков (также называемых узлами) в системе. При таком подходе задачи можно динамически перемещать с перегруженного узла на недогруженный узел, чтобы обеспечить более быструю обработку. Хотя эти алгоритмы гораздо сложнее разработать, они могут давать отличные результаты, особенно когда время выполнения сильно варьируется от одной задачи к другой.
Архитектура динамической балансировки нагрузки может быть более модульной , поскольку не обязательно иметь конкретный узел, выделенный для распределения работы. Когда задачи однозначно назначаются процессору в соответствии с их состоянием в данный момент, это уникальное назначение. Если же задачи могут постоянно перераспределяться в зависимости от состояния системы и ее развития, это называется динамическим назначением. [3] Очевидно, что алгоритм балансировки нагрузки, который требует слишком большого количества коммуникаций для принятия решений, рискует замедлить решение общей проблемы.
Параллельные вычислительные инфраструктуры часто состоят из блоков разной вычислительной мощности , что следует учитывать при распределении нагрузки.
Например, устройства с меньшим энергопотреблением могут получать запросы, требующие меньшего объема вычислений, или, в случае однородных или неизвестных размеров запросов, получать меньше запросов, чем более крупные устройства.
Параллельные компьютеры часто делятся на две большие категории: те, в которых все процессоры используют одну общую память, в которой они параллельно читают и записывают ( модель PRAM ), и те, где каждый вычислительный блок имеет свою собственную память ( модель распределенной памяти ), и где информация обменивается сообщениями.
Для компьютеров с общей памятью управление конфликтами записи значительно замедляет скорость индивидуального выполнения каждого вычислительного блока. Однако они могут прекрасно работать параллельно. И наоборот, в случае обмена сообщениями каждый из процессоров может работать на полной скорости. С другой стороны, когда дело доходит до коллективного обмена сообщениями, все процессоры вынуждены ждать, пока самые медленные процессоры начнут фазу связи.
В действительности лишь немногие системы попадают точно в одну из категорий. Как правило, каждый процессор имеет внутреннюю память для хранения данных, необходимых для следующих вычислений, и организован в последовательные кластеры . Часто эти элементы обработки затем координируются посредством распределенной памяти и передачи сообщений . Следовательно, алгоритм балансировки нагрузки должен быть однозначно адаптирован к параллельной архитектуре. В противном случае существует риск того, что эффективность параллельного решения задач будет сильно снижена.
При адаптации к аппаратным структурам, рассмотренным выше, можно выделить две основные категории алгоритмов балансировки нагрузки. С одной стороны, тот, где задачи назначаются «мастером» и выполняются «работниками», которые информируют мастера о ходе своей работы, а затем мастер может взять на себя ответственность за распределение или перераспределение рабочей нагрузки в случае динамический алгоритм. В литературе это называется архитектурой «Мастер-Работник» . С другой стороны, управление может быть распределено между разными узлами. Затем на каждом из них выполняется алгоритм балансировки нагрузки, и ответственность за назначение задач (а также за переназначение и разделение при необходимости) распределяется. Последняя категория предполагает алгоритм динамической балансировки нагрузки.
Поскольку конструкция каждого алгоритма балансировки нагрузки уникальна, предыдущее различие необходимо уточнить. Таким образом, также возможно иметь промежуточную стратегию, например, с «главными» узлами для каждого подкластера, которые сами подчиняются глобальному «главному». Существуют также многоуровневые организации с чередованием стратегий главного-подчиненного и распределенного управления. Последние стратегии быстро становятся сложными и встречаются редко. Дизайнеры предпочитают алгоритмы, которыми легче управлять.
В контексте алгоритмов, которые работают в долгосрочной перспективе (серверы, облако...), компьютерная архитектура со временем развивается. Однако желательно не разрабатывать каждый раз новый алгоритм.
Поэтому чрезвычайно важным параметром алгоритма балансировки нагрузки является его способность адаптироваться к масштабируемой аппаратной архитектуре. Это называется масштабируемостью алгоритма. Алгоритм называется масштабируемым для входного параметра, если его производительность остается относительно независимой от размера этого параметра.
Когда алгоритм способен адаптироваться к различному количеству вычислительных блоков, но количество вычислительных блоков должно быть фиксировано перед выполнением, его называют формируемым. Если, с другой стороны, алгоритм способен работать с меняющимся количеством процессоров во время своего выполнения, алгоритм называется гибким. Большинство алгоритмов балансировки нагрузки, по крайней мере, поддаются формированию. [4]
Особенно в крупномасштабных вычислительных кластерах недопустимо выполнять параллельный алгоритм, который не может выдержать сбой одного-единственного компонента. Поэтому разрабатываются отказоустойчивые алгоритмы, которые могут обнаруживать сбои процессоров и восстанавливать вычисления. [5]
Если задачи независимы друг от друга и если время их выполнения и задачи можно разделить, существует простой и оптимальный алгоритм.
Разделив задачи таким образом, чтобы каждому процессору был предоставлен одинаковый объем вычислений, остается только сгруппировать результаты. Используя алгоритм префиксной суммы , это деление можно вычислить за логарифмическое время относительно количества процессоров. [ нужна цитата ]
Однако если задачи не могут быть разделены (т. е. они атомарны ), хотя оптимизация распределения задач является сложной задачей, все же можно приблизиться к относительно справедливому распределению задач при условии, что размер каждой из них намного меньше. чем общий объем вычислений, выполняемых каждым из узлов. [1]
В большинстве случаев время выполнения задачи неизвестно и доступны лишь грубые приближения. Этот алгоритм, хотя и особенно эффективен, не подходит для таких сценариев.
Даже если время выполнения заранее вообще не известно, статическое распределение нагрузки всегда возможно.
В циклическом алгоритме первый запрос отправляется на первый сервер, затем на второй и так до последнего. Затем он запускается снова, назначая следующий запрос первому серверу и так далее.
Этот алгоритм может быть взвешен таким образом, чтобы самые мощные устройства получали наибольшее количество запросов и получали их первыми.
Случайная статическая балансировка нагрузки — это просто случайное назначение задач различным серверам. Этот метод работает довольно хорошо. Если же количество задач известно заранее, еще эффективнее заранее рассчитать случайную перестановку. Это позволяет избежать затрат на связь для каждого задания. Больше нет необходимости в мастере распределения, поскольку каждый процессор знает, какая задача ему назначена. Даже если количество задач неизвестно, все равно можно избежать связи с известной всем процессорам генерацией псевдослучайных назначений.
Производительность этой стратегии (измеряемая общим временем выполнения заданного фиксированного набора задач) снижается с увеличением максимального размера задач.
Конечно, существуют и другие методы назначения:
Схемы Master-Worker являются одними из самых простых алгоритмов динамической балансировки нагрузки. Мастер распределяет рабочую нагрузку между всеми работниками (также иногда называемыми «подчиненными»). Изначально все рабочие простаивают и сообщают об этом мастеру. Мастер отвечает на запросы работников и раздает им задачи. Когда у него больше нет заданий, он сообщает об этом работникам, чтобы они перестали спрашивать задания.
Преимущество этой системы в том, что она распределяет нагрузку очень справедливо. Фактически, если не принимать во внимание время, необходимое для выполнения задания, время выполнения будет сопоставимо с суммой префиксов, представленной выше.
Проблема этого алгоритма в том, что ему трудно адаптироваться к большому количеству процессоров из-за большого количества необходимых коммуникаций. Отсутствие масштабируемости делает его быстро неработоспособным на очень больших серверах или очень больших параллельных компьютерах. Мастер выступает в роли узкого места .
Однако качество алгоритма можно значительно улучшить, заменив мастер списком задач, который может использоваться разными процессорами. Хотя этот алгоритм немного сложнее реализовать, он обещает гораздо лучшую масштабируемость, хотя и недостаточную для очень крупных вычислительных центров.
Другой метод решения проблем масштабируемости, когда время, необходимое для выполнения задачи, неизвестно, — это «кража работы» .
Этот подход состоит в том, чтобы назначить каждому процессору определенное количество задач случайным или заранее определенным образом, а затем позволить неактивным процессорам «украсть» работу у активных или перегруженных процессоров. Существует несколько реализаций этой концепции, определяемых моделью разделения задач и правилами, определяющими обмен между процессорами. Хотя этот метод может быть особенно эффективным, его сложно реализовать, поскольку необходимо гарантировать, что общение не станет основным занятием процессоров вместо решения проблемы.
В случае атомарных задач можно выделить две основные стратегии: те, в которых процессоры с низкой нагрузкой предлагают свою вычислительную мощность процессорам с самой высокой нагрузкой, и те, которые являются наиболее нагруженными устройствами, желающими облегчить возложенную на них рабочую нагрузку. Показано [8] , что при сильной загруженности сети наименее загруженным блокам эффективнее предлагать свою доступность, а при малой загрузке сети именно перегруженные процессоры требуют поддержки со стороны наиболее неактивных. Это эмпирическое правило ограничивает количество обмениваемых сообщений.
В случае, когда кто-то начинает с одной большой задачи, которую нельзя разделить за пределы атомарного уровня, существует очень эффективный алгоритм «Древовидное вычисление» [9] , где родительская задача распределяется в рабочем дереве.
Изначально у многих процессоров имеется пустая задача, кроме той, которая работает над ней последовательно. Простаивающие процессоры случайным образом отправляют запросы другим процессорам (не обязательно активным). Если последний может разделить задачу, над которой он работает, он делает это, отправляя часть своей работы узлу, делающему запрос. В противном случае возвращается пустая задача. Это создает древовидную структуру . Затем необходимо отправить сигнал завершения родительскому процессору, когда подзадача будет завершена, чтобы он, в свою очередь, отправлял сообщение своему родительскому процессору, пока оно не достигнет корня дерева. Когда первый процессор, т. е. корневой, завершил работу, может быть передано глобальное сообщение о завершении. В конце необходимо собрать результаты, вернувшись вверх по дереву.
Эффективность такого алгоритма близка к сумме префиксов, когда время сокращения работы и связи не слишком велико по сравнению с работой, которую необходимо выполнить. Чтобы избежать слишком высоких затрат на связь, можно представить список заданий в общей памяти . Следовательно, запрос — это просто чтение определенной позиции в этой общей памяти по запросу главного процессора.
Помимо эффективного решения проблем посредством параллельных вычислений, алгоритмы балансировки нагрузки широко используются при управлении HTTP- запросами, когда сайт с большой аудиторией должен иметь возможность обрабатывать большое количество запросов в секунду.
Одним из наиболее часто используемых приложений балансировки нагрузки является предоставление одной интернет-службы с нескольких серверов , иногда называемых фермой серверов . Обычно системы с балансировкой нагрузки включают популярные веб-сайты , крупные сети интернет-чата , сайты протокола передачи файлов (FTP) с высокой пропускной способностью , серверы протокола передачи сетевых новостей (NNTP), серверы системы доменных имен (DNS) и базы данных.
Круговой DNS — это альтернативный метод балансировки нагрузки, не требующий выделенного программного или аппаратного узла. В этом методе несколько IP-адресов связаны с одним доменным именем ; клиентам предоставляется IP-адрес в циклическом порядке. IP-адрес назначается клиентам с коротким сроком действия, поэтому клиент с большей вероятностью будет использовать другой IP-адрес при следующем доступе к запрашиваемой интернет-службе.
Еще один более эффективный метод балансировки нагрузки с использованием DNS — делегировать www.example.org в качестве поддомена, зона которого обслуживается каждым из тех же серверов, которые обслуживают веб-сайт. Этот метод особенно хорошо работает, когда отдельные серверы географически разбросаны в Интернете. Например:
one.example.org А 192.0.2.1two.example.org A 203.0.113.2www.example.org NS one.example.orgwww.example.org NS two.example.org
Однако файл зоны для www.example.org на каждом сервере различен, так что каждый сервер разрешает свой собственный IP-адрес как A-запись. [10] На первом сервере файл зоны для www.example.org сообщает:
@ в 192.0.2.1
На втором сервере тот же файл зоны содержит:
@ в 203.0.113.2
Таким образом, когда сервер не работает, его DNS не отвечает, и веб-служба не получает никакого трафика. Если линия к одному серверу перегружена, ненадежность DNS гарантирует, что на этот сервер будет доходить меньше HTTP-трафика. Более того, самый быстрый ответ DNS резолверу почти всегда приходит от ближайшего к сети сервера, что обеспечивает геозависимую балансировку нагрузки . Короткий срок жизни A-записи помогает обеспечить быстрое перенаправление трафика в случае сбоя сервера. Необходимо учитывать возможность того, что этот метод может привести к тому, что отдельные клиенты будут переключаться между отдельными серверами в середине сеанса.
Другой подход к балансировке нагрузки заключается в доставке клиенту списка IP-адресов серверов, а затем в том, чтобы клиент случайным образом выбирал IP-адрес из списка при каждом подключении. [11] [12] По сути, это основано на том, что все клиенты генерируют одинаковую нагрузку, а также на Законе больших чисел [12] для достижения достаточно равномерного распределения нагрузки между серверами. Утверждалось, что случайная балансировка нагрузки на стороне клиента имеет тенденцию обеспечивать лучшее распределение нагрузки, чем DNS с циклическим перебором; это связано с проблемами кэширования с циклическим DNS, которые в случае крупных серверов кэширования DNS имеют тенденцию искажать распределение для циклического DNS, в то время как случайный выбор на стороне клиента остается неизменным независимо от кэширования DNS. [12]
При таком подходе метод доставки списка IP-адресов клиенту может варьироваться и может быть реализован в виде списка DNS (доставленного всем клиентам без циклического перебора) или посредством жесткого кодирования его в список. Если используется «умный клиент», обнаруживающий, что случайно выбранный сервер не работает, и снова подключающийся случайным образом, это также обеспечивает отказоустойчивость .
Для интернет-сервисов балансировщик нагрузки на стороне сервера обычно представляет собой программу, которая прослушивает порт, к которому внешние клиенты подключаются к службам доступа. Балансировщик нагрузки пересылает запросы на один из «внутренних» серверов, который обычно отвечает балансировщику нагрузки. Это позволяет балансировщику нагрузки отвечать клиенту, при этом клиент даже не узнает о внутреннем разделении функций. Это также не позволяет клиентам напрямую связываться с внутренними серверами, что может иметь преимущества в плане безопасности, поскольку скрывает структуру внутренней сети и предотвращает атаки на сетевой стек ядра или несвязанные службы, работающие на других портах.
Некоторые балансировщики нагрузки предоставляют механизм для выполнения особых действий в случае, если все внутренние серверы недоступны. Это может включать пересылку на резервный балансировщик нагрузки или отображение сообщения о сбое.
Также важно, чтобы сам балансировщик нагрузки не стал единой точкой отказа . Обычно балансировщики нагрузки реализуются парами с высокой доступностью , которые также могут реплицировать данные постоянства сеанса, если этого требует конкретное приложение. [13] Некоторые приложения запрограммированы с учетом этой проблемы путем смещения точки балансировки нагрузки на платформах дифференциального совместного использования за пределами определенной сети. Последовательные алгоритмы, связанные с этими функциями, определяются гибкими параметрами, уникальными для конкретной базы данных. [14]
Многочисленные алгоритмы планирования , также называемые методами балансировки нагрузки, используются балансировщиками нагрузки, чтобы определить, на какой внутренний сервер отправить запрос. Простые алгоритмы включают случайный выбор, циклический алгоритм или метод наименьшего числа соединений. [15] Более сложные балансировщики нагрузки могут принимать во внимание дополнительные факторы, такие как заявленная нагрузка сервера, наименьшее время ответа, статус включения/выключения (определяемый каким-либо опросом мониторинга), количество активных подключений, географическое положение, возможности , или сколько трафика ему недавно было назначено.
Важным вопросом при работе службы с балансировкой нагрузки является то, как обрабатывать информацию, которая должна храниться в нескольких запросах в сеансе пользователя. Если эта информация хранится локально на одном бэкэнд-сервере, то последующие запросы, идущие к другим бэкэнд-серверам, не смогут ее найти. Это может быть кэшированная информация, которая может быть перевычислена, и в этом случае балансировка нагрузки запроса на другой внутренний сервер просто приводит к проблеме с производительностью. [15]
В идеале кластер серверов за балансировщиком нагрузки не должен поддерживать сеансы, чтобы клиент в любой момент подключился к любому серверному серверу, и это не повлияет на работу пользователя. Обычно это достигается с помощью общей базы данных или сеансовой базы данных в памяти, такой как Memcached .
Одним из основных решений проблемы данных сеанса является последовательная отправка всех запросов в сеансе пользователя на один и тот же внутренний сервер. Это известно как «стойкость» или «липкость». Существенным недостатком этого метода является отсутствие автоматического переключения при сбое : если внутренний сервер выходит из строя, его информация о каждом сеансе становится недоступной, и все зависящие от него сеансы теряются. Та же проблема обычно актуальна для центральных серверов баз данных; даже если веб-серверы «без сохранения состояния» и не «привязаны», центральная база данных остается (см. ниже).
Назначение конкретному серверу может быть основано на имени пользователя, IP-адресе клиента или случайно. Из-за изменений в воспринимаемом адресе клиента в результате DHCP , трансляции сетевых адресов и веб-прокси этот метод может быть ненадежным. Балансировщик нагрузки должен запоминать произвольные назначения, что создает нагрузку на хранилище. Если балансировщик нагрузки заменяется или выходит из строя, эта информация может быть потеряна, и назначения, возможно, придется удалить по истечении периода ожидания или в периоды высокой нагрузки, чтобы избежать превышения пространства, доступного для таблицы назначений. Метод случайного назначения также требует, чтобы клиенты сохраняли некоторое состояние, что может стать проблемой, например, когда веб-браузер отключил сохранение файлов cookie. Сложные балансировщики нагрузки используют несколько методов сохранения, чтобы избежать некоторых недостатков любого одного метода.
Другое решение — хранить данные каждого сеанса в базе данных . Обычно это плохо сказывается на производительности, поскольку увеличивает нагрузку на базу данных: базу данных лучше всего использовать для хранения информации, менее временной, чем данные каждого сеанса. Чтобы предотвратить превращение базы данных в единую точку отказа и улучшить масштабируемость , база данных часто реплицируется на несколько компьютеров, а балансировка нагрузки используется для распределения нагрузки запросов между этими репликами. Технология сервера состояний ASP.net компании Microsoft является примером сеансовой базы данных. Все серверы веб-фермы хранят данные своих сеансов на сервере состояний, и любой сервер фермы может получить эти данные.
В очень распространенном случае, когда клиентом является веб-браузер, простым, но эффективным подходом является сохранение данных каждого сеанса в самом браузере. Один из способов добиться этого — использовать файлы cookie браузера с соответствующей отметкой времени и зашифрованными. Другой вариант — перезапись URL-адресов . Хранение данных сеанса на клиенте обычно является предпочтительным решением: тогда балансировщик нагрузки может выбрать любой внутренний сервер для обработки запроса. Однако этот метод обработки данных о состоянии плохо подходит для некоторых сложных сценариев бизнес-логики, где полезная нагрузка состояния сеанса велика и ее повторный расчет при каждом запросе на сервере невозможен. Перезапись URL-адресов имеет серьезные проблемы с безопасностью, поскольку конечный пользователь может легко изменить отправленный URL-адрес и, таким образом, изменить потоки сеанса.
Еще одно решение для хранения постоянных данных — связать имя с каждым блоком данных и использовать распределенную хеш-таблицу для псевдослучайного присвоения этого имени одному из доступных серверов, а затем сохранить этот блок данных на назначенном сервере.
Аппаратные и программные балансировщики нагрузки могут иметь множество специальных функций. Фундаментальной особенностью балансировщика нагрузки является возможность распределять входящие запросы по нескольким серверным серверам в кластере в соответствии с алгоритмом планирования. Большинство из следующих функций зависят от поставщика:
Балансировка нагрузки может быть полезна в приложениях с резервными каналами связи. Например, компания может иметь несколько подключений к Интернету, обеспечивающих доступ к сети в случае сбоя одного из подключений. Механизм аварийного переключения будет означать, что один канал предназначен для нормального использования, а второй канал используется только в случае сбоя основного канала.
Благодаря балансировке нагрузки оба канала могут использоваться постоянно. Устройство или программа отслеживает доступность всех каналов и выбирает путь для отправки пакетов. Использование нескольких каналов одновременно увеличивает доступную пропускную способность.
TRILL (TRansparent Interconnection of Multiple Links) позволяет Ethernet иметь произвольную топологию и обеспечивает попарное разделение нагрузки для каждого потока с помощью алгоритма Дейкстры без настройки и вмешательства пользователя. Катализатором для TRILL стало мероприятие в Медицинском центре Бет Исраэль Диаконесса , которое началось 13 ноября 2002 года . 2004, [19] , который в 2005 году [20] отверг то, что стало известно как TRILL, а в период с 2006 по 2012 год [21] разработал несовместимый вариант, известный как мост по кратчайшему пути .
В мае 2012 года IEEE утвердил стандарт IEEE 802.1aq , [22] также известный как мост по кратчайшему пути (SPB). SPB позволяет всем каналам быть активными по нескольким путям с равной стоимостью, обеспечивает более быстрое время конвергенции для сокращения времени простоя и упрощает использование балансировки нагрузки в топологиях ячеистых сетей (частично подключенных и/или полностью подключенных), позволяя трафику распределять нагрузку по всем каналам. пути сети. [23] [24] SPB разработан таким образом, чтобы практически исключить человеческие ошибки во время настройки и сохранить принцип «включай и работай», благодаря которому Ethernet стал фактическим протоколом на уровне 2. [25]
Многие телекоммуникационные компании имеют несколько маршрутов через свои сети или к внешним сетям. Они используют сложную балансировку нагрузки для переключения трафика с одного пути на другой, чтобы избежать перегрузки сети на каком-либо конкретном канале, а иногда и для минимизации стоимости транзита через внешние сети или повышения надежности сети .
Другой способ использования балансировки нагрузки — мониторинг сети . Балансировщики нагрузки можно использовать для разделения огромных потоков данных на несколько подпотоков и использования нескольких сетевых анализаторов, каждый из которых считывает часть исходных данных. Это очень полезно для мониторинга быстрых сетей, таких как 10GbE или STM64, где сложная обработка данных может быть невозможна на скорости проводной сети . [26]
Балансировка нагрузки широко используется в сетях центров обработки данных для распределения трафика по множеству существующих путей между любыми двумя серверами. [27] Это позволяет более эффективно использовать пропускную способность сети и снижает затраты на обеспечение. В целом балансировку нагрузки в сетях центров обработки данных можно разделить на статическую и динамическую.
Статическая балансировка нагрузки распределяет трафик путем вычисления хэша адресов источника и назначения, а также номеров портов потоков трафика и использования его для определения того, как потоки назначаются одному из существующих путей. Динамическая балансировка нагрузки распределяет потоки трафика по путям, отслеживая использование полосы пропускания на разных путях. Динамические назначения также могут быть проактивными или реактивными. В первом случае назначение фиксируется после выполнения, а во втором сетевая логика продолжает отслеживать доступные пути и перемещать потоки по ним по мере изменения загрузки сети (при поступлении новых потоков или завершении существующих). Стал доступен комплексный обзор балансировки нагрузки в сетях центров обработки данных. [27]
Балансировка нагрузки часто используется для реализации аварийного переключения — продолжения обслуживания после отказа одного или нескольких его компонентов. Компоненты постоянно контролируются (например, веб-серверы могут отслеживаться путем выборки известных страниц), и когда один из них перестает отвечать на запросы, балансировщик нагрузки информируется и больше не отправляет на него трафик. Когда компонент снова подключается к сети, балансировщик нагрузки начинает перенаправлять на него трафик. Чтобы это работало, должен быть хотя бы один компонент, превышающий пропускную способность сервиса ( избыточность N+1 ). Это может быть намного дешевле и более гибко, чем подходы к аварийному переключению, при которых каждый работающий компонент соединен с одним резервным компонентом, который берет на себя управление в случае сбоя ( двойное модульное резервирование ). Некоторые системы RAID также могут использовать «горячий» резерв для аналогичного эффекта. [28]
Соединение по кратчайшему пути заменит связующее дерево в структуре Ethernet.
