В вычислительной технике балансировка нагрузки — это процесс распределения набора задач по набору ресурсов (вычислительных единиц) с целью повышения эффективности их общей обработки. Балансировка нагрузки может оптимизировать время отклика и избежать неравномерной перегрузки некоторых вычислительных узлов, в то время как другие вычислительные узлы остаются бездействующими.
Балансировка нагрузки является предметом исследований в области параллельных компьютеров . Существуют два основных подхода: статические алгоритмы, которые не учитывают состояние различных машин, и динамические алгоритмы, которые обычно более общие и более эффективные, но требуют обмена информацией между различными вычислительными блоками, что сопряжено с риском потери эффективности.
Алгоритм балансировки нагрузки всегда пытается решить конкретную проблему. Среди прочего, необходимо учитывать характер задач, сложность алгоритма , аппаратную архитектуру, на которой будут работать алгоритмы, а также требуемую устойчивость к ошибкам . Поэтому необходимо найти компромисс, чтобы наилучшим образом удовлетворить требования, предъявляемые к конкретному приложению.
Эффективность алгоритмов балансировки нагрузки критически зависит от характера задач. Поэтому чем больше информации о задачах доступно на момент принятия решения, тем больше потенциал для оптимизации.
Идеальное знание времени выполнения каждой из задач позволяет достичь оптимального распределения нагрузки (см. алгоритм префиксной суммы ). [1] К сожалению, это на самом деле идеализированный случай. Знание точного времени выполнения каждой задачи — крайне редкая ситуация.
По этой причине существует несколько методов, позволяющих получить представление о различном времени выполнения. Прежде всего, в удачном сценарии, когда задачи имеют относительно однородный размер, можно считать, что каждая из них потребует приблизительно среднего времени выполнения. Если же, с другой стороны, время выполнения очень нерегулярно, необходимо использовать более сложные методы. Один из методов заключается в добавлении некоторых метаданных к каждой задаче. В зависимости от предыдущего времени выполнения для аналогичных метаданных можно сделать выводы для будущей задачи на основе статистики. [2]
В некоторых случаях задачи зависят друг от друга. Эти взаимозависимости можно проиллюстрировать направленным ациклическим графом . Интуитивно понятно, что некоторые задачи не могут начаться, пока другие не будут завершены.
Предполагая, что требуемое время для каждой из задач известно заранее, оптимальный порядок выполнения должен приводить к минимизации общего времени выполнения. Хотя это NP-трудная задача и, следовательно, ее может быть трудно решить точно. Существуют алгоритмы, такие как job scheduler , которые вычисляют оптимальное распределение задач с использованием метаэвристических методов.
Еще одной особенностью задач, критически важной для разработки алгоритма балансировки нагрузки, является их способность разбиваться на подзадачи во время выполнения. Алгоритм "Tree-Shaped Computation", представленный ниже, в значительной степени использует эту специфику.
Алгоритм балансировки нагрузки является «статичным», когда он не учитывает состояние системы для распределения задач. Таким образом, состояние системы включает такие меры, как уровень нагрузки (а иногда даже перегрузки) определенных процессоров. Вместо этого заранее делаются предположения о всей системе, такие как время прибытия и требования к ресурсам входящих задач. Кроме того, известны количество процессоров, их соответствующая мощность и скорости связи. Поэтому статическая балансировка нагрузки направлена на то, чтобы связать известный набор задач с доступными процессорами, чтобы минимизировать определенную функцию производительности. Хитрость заключается в концепции этой функции производительности.
Статические методы балансировки нагрузки обычно централизуются вокруг маршрутизатора или Мастера , который распределяет нагрузки и оптимизирует функцию производительности. Эта минимизация может учитывать информацию, связанную с распределяемыми задачами, и выводить ожидаемое время выполнения.
Преимущество статических алгоритмов в том, что они просты в настройке и чрезвычайно эффективны в случае достаточно регулярных задач (например, обработка HTTP- запросов с веб-сайта). Однако все еще существует некоторая статистическая дисперсия в назначении задач, которая может привести к перегрузке некоторых вычислительных блоков.
В отличие от статических алгоритмов распределения нагрузки, динамические алгоритмы учитывают текущую нагрузку каждого из вычислительных блоков (также называемых узлами) в системе. При таком подходе задачи могут динамически перемещаться с перегруженного узла на недогруженный узел для получения более быстрой обработки. Хотя эти алгоритмы гораздо сложнее в проектировании, они могут давать отличные результаты, в частности, когда время выполнения сильно различается от одной задачи к другой.
Архитектура динамической балансировки нагрузки может быть более модульной, поскольку не обязательно иметь определенный узел, выделенный для распределения работы. Когда задачи уникально назначаются процессору в соответствии с их состоянием в определенный момент, это уникальное назначение. Если, с другой стороны, задачи могут быть постоянно перераспределены в соответствии с состоянием системы и ее развитием, это называется динамическим назначением. [3] Очевидно, что алгоритм балансировки нагрузки, требующий слишком большого количества коммуникаций для достижения своих решений, рискует замедлить решение общей проблемы.
Параллельные вычислительные инфраструктуры часто состоят из блоков различной вычислительной мощности , что следует учитывать при распределении нагрузки.
Например, устройства с меньшей мощностью могут получать запросы, требующие меньшего объема вычислений, или, в случае однородных или неизвестных размеров запросов, получать меньше запросов, чем устройства с большей мощностью.
Параллельные компьютеры часто делятся на две большие категории: те, в которых все процессоры используют одну общую память, в которой они читают и пишут параллельно ( модель PRAM ), и те, в которых каждое вычислительное устройство имеет свою собственную память ( модель распределенной памяти ) и где обмен информацией осуществляется посредством сообщений.
Для компьютеров с общей памятью управление конфликтами записи значительно замедляет скорость индивидуального выполнения каждого вычислительного блока. Однако они могут прекрасно работать параллельно. И наоборот, в случае обмена сообщениями каждый из процессоров может работать на полной скорости. С другой стороны, когда дело доходит до коллективного обмена сообщениями, все процессоры вынуждены ждать, пока самые медленные процессоры начнут фазу коммуникации.
В действительности, лишь немногие системы попадают в одну из категорий. Как правило, каждый процессор имеет внутреннюю память для хранения данных, необходимых для следующих вычислений, и организован в последовательные кластеры . Часто эти элементы обработки затем координируются через распределенную память и передачу сообщений . Поэтому алгоритм балансировки нагрузки должен быть уникально адаптирован к параллельной архитектуре. В противном случае существует риск того, что эффективность параллельного решения задач будет значительно снижена.
Адаптируясь к рассмотренным выше аппаратным структурам, можно выделить две основные категории алгоритмов балансировки нагрузки. С одной стороны, та, в которой задачи назначаются «мастером» и выполняются «работниками», которые информируют мастера о ходе своей работы, а мастер затем может взять на себя ответственность за назначение или переназначение рабочей нагрузки в случае динамического алгоритма. В литературе это называется архитектурой «мастер-работник» . С другой стороны, управление может быть распределено между различными узлами. Затем алгоритм балансировки нагрузки выполняется на каждом из них, и ответственность за назначение задач (а также переназначение и разделение по мере необходимости) распределяется. Последняя категория предполагает динамический алгоритм балансировки нагрузки.
Поскольку конструкция каждого алгоритма балансировки нагрузки уникальна, предыдущее различие должно быть уточнено. Таким образом, также возможно иметь промежуточную стратегию, например, с «главными» узлами для каждого подкластера, которые сами подчиняются глобальному «главному». Существуют также многоуровневые организации с чередованием стратегий «главный-подчиненный» и распределенного управления. Последние стратегии быстро становятся сложными и встречаются редко. Разработчики предпочитают алгоритмы, которые легче контролировать.
В контексте алгоритмов, которые работают в течение очень длительного периода (серверы, облако...), архитектура компьютера со временем развивается. Однако предпочтительнее не разрабатывать каждый раз новый алгоритм.
Поэтому чрезвычайно важным параметром алгоритма балансировки нагрузки является его способность адаптироваться к масштабируемой аппаратной архитектуре. Это называется масштабируемостью алгоритма . Алгоритм называется масштабируемым для входного параметра, когда его производительность остается относительно независимой от размера этого параметра.
Когда алгоритм способен адаптироваться к разному количеству вычислительных блоков, но количество вычислительных блоков должно быть зафиксировано перед выполнением, он называется формовочным. Если же, с другой стороны, алгоритм способен работать с изменяющимся количеством процессоров во время выполнения, говорят, что алгоритм является пластичным. Большинство алгоритмов балансировки нагрузки по крайней мере являются формовочными. [4]
Особенно в крупномасштабных вычислительных кластерах недопустимо выполнять параллельный алгоритм, который не может выдержать отказ одного компонента. Поэтому разрабатываются отказоустойчивые алгоритмы, которые могут обнаруживать сбои процессоров и восстанавливать вычисления. [5]
Если задачи независимы друг от друга и если время их выполнения и сами задачи можно разделить, то существует простой и оптимальный алгоритм.
Разделив задачи таким образом, чтобы дать каждому процессору одинаковое количество вычислений, все, что остается сделать, это сгруппировать результаты вместе. Используя алгоритм префиксной суммы , это деление можно вычислить за логарифмическое время относительно количества процессоров. [ необходима цитата ]
Однако если задачи не могут быть разделены (т. е. они атомарны ), то, хотя оптимизация назначения задач является сложной проблемой, все равно можно приблизиться к относительно справедливому распределению задач, при условии, что размер каждой из них намного меньше общего объема вычислений, выполняемых каждым из узлов. [1]
В большинстве случаев время выполнения задачи неизвестно, и доступны только грубые приближения. Этот алгоритм, хотя и особенно эффективен, не подходит для таких сценариев.
Даже если время выполнения заранее неизвестно, статическое распределение нагрузки всегда возможно.
В алгоритме round-robin первый запрос отправляется на первый сервер, затем следующий — на второй и так далее до последнего. Затем он запускается снова, назначая следующий запрос первому серверу и так далее.
Этот алгоритм можно взвесить таким образом, чтобы самые мощные блоки получали наибольшее количество запросов и получали их первыми.
Рандомизированная статическая балансировка нагрузки — это просто случайный процесс назначения задач разным серверам. Этот метод работает довольно хорошо. Если же, с другой стороны, количество задач известно заранее, еще эффективнее заранее рассчитать случайную перестановку. Это позволяет избежать затрат на связь для каждого назначения. Больше нет необходимости в мастере распределения, поскольку каждый процессор знает, какая задача ему назначена. Даже если количество задач неизвестно, все равно можно избежать связи с помощью псевдослучайной генерации назначений, известной всем процессорам.
Производительность этой стратегии (измеряемая общим временем выполнения заданного фиксированного набора задач) уменьшается с увеличением максимального размера задач.
Конечно, существуют и другие методы назначения:
Схемы Master-Worker являются одними из самых простых алгоритмов динамической балансировки нагрузки. Мастер распределяет нагрузку между всеми работниками (иногда их также называют «ведомыми»). Изначально все работники простаивают и сообщают об этом мастеру. Мастер отвечает на запросы работников и распределяет между ними задачи. Когда у него больше нет задач, он сообщает об этом работникам, чтобы они перестали запрашивать задачи.
Преимущество этой системы в том, что она распределяет нагрузку очень справедливо. Фактически, если не принимать во внимание время, необходимое для выполнения задания, время выполнения будет сопоставимо с префиксной суммой, показанной выше.
Проблема этого алгоритма в том, что он с трудом адаптируется к большому количеству процессоров из-за большого количества необходимых коммуникаций. Этот недостаток масштабируемости быстро делает его неработоспособным на очень больших серверах или очень больших параллельных компьютерах. Мастер выступает в качестве узкого места .
Однако качество алгоритма можно значительно улучшить, заменив мастер списком задач, который может использоваться разными процессорами. Хотя этот алгоритм немного сложнее реализовать, он обещает гораздо лучшую масштабируемость, хотя все еще недостаточную для очень больших вычислительных центров.
Еще одним методом преодоления проблем масштабируемости, когда неизвестно время, необходимое для выполнения задачи, является кража работы .
Подход заключается в назначении каждому процессору определенного количества задач случайным или предопределенным образом, а затем в разрешении неактивным процессорам «воровать» работу у активных или перегруженных процессоров. Существует несколько реализаций этой концепции, определяемых моделью разделения задач и правилами, определяющими обмен между процессорами. Хотя этот метод может быть особенно эффективным, его трудно реализовать, поскольку необходимо гарантировать, что коммуникация не станет основным занятием процессоров вместо решения проблемы.
В случае атомарных задач можно выделить две основные стратегии: те, где процессоры с низкой нагрузкой предлагают свою вычислительную мощность процессорам с самой высокой нагрузкой, и те, где наиболее загруженные блоки желают облегчить возложенную на них нагрузку. Было показано [8] , что когда сеть сильно загружена, то менее загруженным блокам эффективнее предлагать свою доступность, а когда сеть слабо загружена, то именно перегруженным процессорам требуется поддержка от самых неактивных. Это практическое правило ограничивает количество обмениваемых сообщений.
В случае, когда мы начинаем с одной большой задачи, которая не может быть разделена за пределы атомарного уровня, существует очень эффективный алгоритм «древовидного вычисления» [9] , где родительская задача распределяется по рабочему дереву.
Изначально у многих процессоров есть пустая задача, за исключением одного, который работает над ней последовательно. Неактивные процессоры отправляют запросы случайным образом другим процессорам (не обязательно активным). Если последний может подразделить задачу, над которой он работает, он делает это, отправляя часть своей работы узлу, делающему запрос. В противном случае он возвращает пустую задачу. Это вызывает древовидную структуру . Затем необходимо отправить сигнал завершения родительскому процессору, когда подзадача будет завершена, чтобы он, в свою очередь, отправил сообщение своему родителю, пока не достигнет корня дерева. Когда первый процессор, т. е. корень, завершит работу, может быть передано глобальное сообщение о завершении. В конце необходимо собрать результаты, поднявшись обратно вверх по дереву.
Эффективность такого алгоритма близка к префиксной сумме, когда время нарезки и коммуникации не слишком велико по сравнению с работой, которую нужно выполнить. Чтобы избежать слишком высоких затрат на коммуникацию, можно представить список работ в общей памяти . Поэтому запрос — это просто чтение из определенной позиции в этой общей памяти по запросу главного процессора.
Помимо эффективного решения задач посредством параллельных вычислений, алгоритмы балансировки нагрузки широко используются в управлении HTTP- запросами, где сайт с большой аудиторией должен иметь возможность обрабатывать большое количество запросов в секунду.
Одним из наиболее часто используемых приложений балансировки нагрузки является предоставление единой интернет-услуги с нескольких серверов , иногда называемых фермой серверов . Обычно системы с балансировкой нагрузки включают популярные веб-сайты , крупные сети Internet Relay Chat , сайты с высокой пропускной способностью File Transfer Protocol (FTP), серверы Network News Transfer Protocol (NNTP), серверы Domain Name System (DNS) и базы данных.
Круговой DNS — это альтернативный метод балансировки нагрузки, не требующий выделенного программного или аппаратного узла. В этом методе несколько IP-адресов связываются с одним доменным именем ; клиентам назначается IP-адрес по кругу. IP-адрес назначается клиентам с коротким сроком действия, поэтому клиент с большей вероятностью будет использовать другой IP-адрес при следующем доступе к запрашиваемой интернет-услуге.
Другой более эффективный метод балансировки нагрузки с использованием DNS — делегировать www.example.org как поддомен, зона которого обслуживается каждым из тех же серверов, которые обслуживают веб-сайт. Этот метод работает особенно хорошо, когда отдельные серверы географически разбросаны по Интернету. Например:
Однако файл зоны для www.example.org на каждом сервере отличается, поэтому каждый сервер разрешает свой собственный IP-адрес как A-запись. [10] На первом сервере файл зоны для www.example.org сообщает:
На сервере два тот же файл зоны содержит:
Таким образом, когда сервер выходит из строя, его DNS не будет отвечать, и веб-служба не получит никакого трафика. Если линия к одному серверу перегружена, ненадежность DNS гарантирует, что меньше HTTP-трафика достигнет этого сервера. Кроме того, самый быстрый ответ DNS на резольвер почти всегда исходит от ближайшего сервера сети, что обеспечивает геозависимую балансировку нагрузки [ требуется цитата ] . Короткий TTL в A-записи помогает обеспечить быстрое перенаправление трафика, когда сервер выходит из строя. Необходимо учитывать возможность того, что этот метод может привести к тому, что отдельные клиенты будут переключаться между отдельными серверами в середине сеанса.
Другой подход к балансировке нагрузки заключается в предоставлении клиенту списка IP-адресов сервера, а затем в том, чтобы клиент случайным образом выбирал IP-адрес из списка при каждом подключении. [11] [12] По сути, это основано на том, что все клиенты генерируют схожие нагрузки, и на законе больших чисел [12] для достижения достаточно ровного распределения нагрузки по серверам. Утверждается, что случайная балансировка нагрузки на стороне клиента имеет тенденцию обеспечивать лучшее распределение нагрузки, чем циклический DNS; это объясняется проблемами кэширования с циклическим DNS, которые в случае больших серверов кэширования DNS имеют тенденцию искажать распределение для циклического DNS, в то время как случайный выбор на стороне клиента остается неизменным независимо от кэширования DNS. [12]
При таком подходе способ доставки списка IP-адресов клиенту может варьироваться и может быть реализован как список DNS (доставляемый всем клиентам без какого-либо циклического перебора) или путем жесткого кодирования его в списке. Если используется «умный клиент», который обнаруживает, что случайно выбранный сервер не работает, и подключается снова случайным образом, он также обеспечивает отказоустойчивость .
Для интернет-сервисов серверный балансировщик нагрузки обычно представляет собой программное обеспечение, которое прослушивает порт , к которому подключаются внешние клиенты для доступа к сервисам. Балансировщик нагрузки пересылает запросы на один из «бэкэнд»-серверов, который обычно отвечает балансировщику нагрузки. Это позволяет балансировщику нагрузки отвечать клиенту, не давая клиенту знать о внутреннем разделении функций. Он также не позволяет клиентам напрямую связываться с бэкэнд-серверами, что может иметь преимущества в плане безопасности, скрывая структуру внутренней сети и предотвращая атаки на сетевой стек ядра или несвязанные сервисы, работающие на других портах.
Некоторые балансировщики нагрузки предоставляют механизм для выполнения чего-то особенного в случае, если все внутренние серверы недоступны. Это может включать переадресацию на резервный балансировщик нагрузки или отображение сообщения об отключении.
Также важно, чтобы сам балансировщик нагрузки не стал единой точкой отказа . Обычно балансировщики нагрузки реализуются в парах высокой доступности , которые также могут реплицировать данные сохранения сеанса, если это требуется конкретным приложением. [13] Некоторые приложения программируются с иммунитетом к этой проблеме, смещая точку балансировки нагрузки по дифференциальным платформам совместного использования за пределы определенной сети. Последовательные алгоритмы, сопряженные с этими функциями, определяются гибкими параметрами, уникальными для конкретной базы данных. [14]
Многочисленные алгоритмы планирования , также называемые методами балансировки нагрузки, используются балансировщиками нагрузки для определения того, на какой внутренний сервер направить запрос. Простые алгоритмы включают случайный выбор, циклический перебор или наименьшее количество подключений. [15] Более сложные балансировщики нагрузки могут учитывать дополнительные факторы, такие как сообщаемая нагрузка сервера, наименьшее время отклика, статус «включен/выключен» (определяемый каким-либо опросом мониторинга), количество активных подключений, географическое положение, возможности или объем трафика, который был недавно назначен.
Важным вопросом при работе службы с балансировкой нагрузки является то, как обрабатывать информацию, которая должна храниться между несколькими запросами в сеансе пользователя. Если эта информация хранится локально на одном внутреннем сервере, то последующие запросы, идущие на другие внутренние серверы, не смогут ее найти. Это может быть кэшированная информация, которую можно пересчитать, и в этом случае балансировка нагрузки запроса на другой внутренний сервер просто приводит к проблеме производительности. [15]
В идеале кластер серверов за балансировщиком нагрузки не должен быть осведомлен о сеансах, так что если клиент подключается к любому бэкэнд-серверу в любое время, пользовательский опыт не изменяется. Обычно это достигается с помощью общей базы данных или базы данных сеансов в памяти, такой как Memcached .
Одним из основных решений проблемы данных сеанса является последовательная отправка всех запросов в сеансе пользователя на один и тот же внутренний сервер. Это известно как «персистентность» или «липкость». Существенным недостатком этой методики является отсутствие автоматического переключения на другой ресурс: если внутренний сервер выходит из строя, его информация о сеансе становится недоступной, и все сеансы, зависящие от него, теряются. Та же проблема обычно актуальна для серверов центральной базы данных; даже если веб-серверы «не имеют состояния» и не «липкие», центральная база данных является таковой (см. ниже).
Назначение на определенный сервер может быть основано на имени пользователя, IP-адресе клиента или случайно. Из-за изменений в воспринимаемом адресе клиента в результате DHCP , трансляции сетевых адресов и веб-прокси этот метод может быть ненадежным. Случайные назначения должны запоминаться балансировщиком нагрузки, что создает нагрузку на хранилище. Если балансировщик нагрузки заменен или выходит из строя, эта информация может быть утеряна, и назначения, возможно, придется удалить после периода ожидания или в периоды высокой нагрузки, чтобы избежать превышения пространства, доступного для таблицы назначений. Метод случайного назначения также требует, чтобы клиенты поддерживали некоторое состояние, что может быть проблемой, например, когда веб-браузер отключил хранение файлов cookie. Сложные балансировщики нагрузки используют несколько методов сохранения, чтобы избежать некоторых недостатков любого одного метода.
Другое решение — хранить данные сеанса в базе данных . Это, как правило, плохо для производительности, поскольку увеличивает нагрузку на базу данных: базу данных лучше всего использовать для хранения информации, менее временной, чем данные сеанса. Чтобы предотвратить превращение базы данных в единую точку отказа и улучшить масштабируемость , база данных часто реплицируется на несколько машин, а балансировка нагрузки используется для распределения нагрузки запросов между этими репликами. Технология Microsoft ASP.net State Server является примером базы данных сеансов. Все серверы в веб-ферме хранят данные своих сеансов на State Server, и любой сервер в ферме может извлекать данные.
В очень распространенном случае, когда клиентом является веб-браузер, простой, но эффективный подход заключается в хранении данных сеанса в самом браузере. Одним из способов достижения этого является использование cookie-файла браузера , соответствующим образом промаркированного по времени и зашифрованного. Другим способом является перезапись URL-адресов . Хранение данных сеанса на клиенте, как правило, является предпочтительным решением: тогда балансировщик нагрузки может свободно выбрать любой внутренний сервер для обработки запроса. Однако этот метод обработки данных состояния плохо подходит для некоторых сложных сценариев бизнес-логики, где полезная нагрузка состояния сеанса велика и пересчет ее при каждом запросе на сервере невозможен. Перезапись URL-адресов имеет серьезные проблемы безопасности, поскольку конечный пользователь может легко изменить отправленный URL-адрес и, таким образом, изменить потоки сеанса.
Еще одно решение для хранения постоянных данных — связать имя с каждым блоком данных и использовать распределенную хеш-таблицу для псевдослучайного назначения этого имени одному из доступных серверов, а затем сохранить этот блок данных на назначенном сервере.
Аппаратные и программные балансировщики нагрузки могут иметь ряд специальных функций. Основная функция балансировщика нагрузки — возможность распределять входящие запросы по нескольким внутренним серверам в кластере в соответствии с алгоритмом планирования. Большинство из следующих функций зависят от поставщика:
Балансировка нагрузки может быть полезна в приложениях с избыточными коммуникационными каналами. Например, у компании может быть несколько подключений к Интернету, гарантирующих сетевой доступ в случае отказа одного из соединений. Схема отказоустойчивости будет означать, что один канал предназначен для обычного использования, а второй канал используется только в случае отказа основного канала.
Используя балансировку нагрузки, оба канала могут использоваться все время. Устройство или программа отслеживает доступность всех каналов и выбирает путь для отправки пакетов. Использование нескольких каналов одновременно увеличивает доступную пропускную способность.
TRILL (прозрачное соединение множества ссылок) облегчает Ethernet для получения произвольной топологии и позволяет разделять нагрузку попарно на поток с помощью алгоритма Дейкстры без настройки и вмешательства пользователя. Катализатором TRILL стало событие в медицинском центре Beth Israel Deaconess , которое началось 13 ноября 2002 года. [16] [17] Концепция Rbridges [18] [sic] была впервые предложена Институту инженеров по электротехнике и электронике в 2004 году, [19] который в 2005 году [20] отклонил то, что стало известно как TRILL, и в период с 2006 по 2012 год [21] разработал несовместимую вариацию, известную как Shortest Path Bridging .
IEEE одобрил стандарт IEEE 802.1aq в мае 2012 года [22] , также известный как Shortest Path Bridging (SPB). SPB позволяет всем соединениям быть активными через несколько равноценных путей, обеспечивает более быстрое время сходимости для сокращения простоев и упрощает использование балансировки нагрузки в топологиях ячеистых сетей (частично подключенных и/или полностью подключенных), позволяя трафику распределять нагрузку по всем путям сети. [23] [24] SPB разработан для того, чтобы фактически исключить человеческие ошибки во время настройки и сохранить природу plug-and-play, которая установила Ethernet как фактический протокол на уровне 2. [25]
Многие телекоммуникационные компании имеют несколько маршрутов через свои сети или к внешним сетям. Они используют сложную балансировку нагрузки для переключения трафика с одного пути на другой, чтобы избежать перегрузки сети на каком-либо конкретном канале, а иногда и для минимизации стоимости транзита через внешние сети или повышения надежности сети .
Другой способ использования балансировки нагрузки — мониторинг сети . Балансировщики нагрузки могут использоваться для разделения огромных потоков данных на несколько подпотоков и использования нескольких сетевых анализаторов, каждый из которых считывает часть исходных данных. Это очень полезно для мониторинга быстрых сетей, таких как 10GbE или STM64, где сложная обработка данных может быть невозможна на скорости передачи данных . [26]
Балансировка нагрузки широко используется в сетях центров обработки данных для распределения трафика по многим существующим путям между любыми двумя серверами. [27] Она позволяет более эффективно использовать пропускную способность сети и снижает затраты на предоставление. В целом, балансировку нагрузки в сетях центров обработки данных можно классифицировать как статическую или динамическую.
Статическая балансировка нагрузки распределяет трафик, вычисляя хэш исходных и конечных адресов и номеров портов потоков трафика и используя его для определения того, как потоки назначаются одному из существующих путей. Динамическая балансировка нагрузки назначает потоки трафика путям, отслеживая использование полосы пропускания на разных путях. Динамические назначения также могут быть проактивными или реактивными. В первом случае назначение фиксируется после выполнения, тогда как во втором случае сетевая логика продолжает отслеживать доступные пути и переключает потоки по ним по мере изменения использования сети (с поступлением новых потоков или завершением существующих). Был предоставлен всесторонний обзор балансировки нагрузки в сетях центров обработки данных. [27]
Балансировка нагрузки часто используется для реализации отказоустойчивости — продолжения обслуживания после отказа одного или нескольких его компонентов. Компоненты постоянно контролируются (например, веб-серверы могут контролироваться путем извлечения известных страниц), и когда один из них перестает отвечать, балансировщик нагрузки информируется об этом и больше не отправляет ему трафик. Когда компонент снова подключается к сети, балансировщик нагрузки начинает перенаправлять трафик на него. Чтобы это работало, должен быть по крайней мере один компонент, превышающий емкость сервиса ( избыточность N+1 ). Это может быть намного менее затратным и более гибким, чем подходы к отказоустойчивости, когда каждый активный компонент сопряжен с одним резервным компонентом, который берет на себя управление в случае отказа ( двойная модульная избыточность ). Некоторые системы RAID также могут использовать горячее резервирование для аналогичного эффекта. [28]
Path Bridging заменит Spanning Tree в структуре Ethernet.
