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

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

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

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

Содержание

  • 1 Обзор проблемы
    • 1.1 Характер задач
      • 1.1.1 Размер задачи
      • 1.1.2 Зависимости
      • 1.1.3 Разделение задач
    • 1.2 Статические и динамические алгоритмы
      • 1.2.1 Статистика ic
      • 1.2.2 Динамический
    • 1.3 Архитектура оборудования
      • 1.3.1 Гетерогенные машины
      • 1.3.2 Общая и распределенная память
      • 1.3.3 Иерархия
      • 1.3.4 Адаптация к более крупным архитектурам ( масштабируемость)
    • 1.4 Отказоустойчивость
  • 2 подхода
    • 2.1 Статическое распределение с полным знанием задач: сумма префиксов
    • 2.2 Статическое распределение нагрузки без предварительного знания
      • 2.2.1 Round-Robin
      • 2.2.2 Рандомизированный статический
      • 2.2.3 Другое
    • 2.3 Схема мастер-работник
    • 2.4 Неиерархическая архитектура, без знания системы: кража работы
      • 2.4.1 Принцип
      • 2.4.2 Эффективность
  • 3 Приложение
    • 3.1 Интернет-службы
      • 3.1.1 Циклический перебор DNS
      • 3.1.2 Делегирование DNS
      • 3.1.3 Случайная балансировка нагрузки на стороне клиента
      • 3.1.4 Балансировщики нагрузки на стороне сервера
        • 3.1.4.1 Алгоритмы планирования
        • 3.1.4.2 Постоянство
        • 3.1.4.3 Функции балансировщика нагрузки
    • 3.2 Использование в телекоммуникациях
      • 3.2.1 Мостовое соединение по кратчайшему пути
      • 3.2. 2 Маршрутизация 1
    • 3.3 Использование в сетях центров обработки данных
    • 3.4 Связь с отработкой отказа
  • 4 См. Также
  • 5 Ссылки
  • 6 Внешние ссылки

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

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

Природа задач

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

Размер задач

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

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

Зависимости

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

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

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

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

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

Статические

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархия

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

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

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

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

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

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

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

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

Подходы

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

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

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

.

Алгоритм балансировки нагрузки в зависимости от делимости задач

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

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

Статическое распределение нагрузки без предварительной информации

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

Round-Robin

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

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

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

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

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

Другое

Конечно, есть и другие методы назначения:

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

Схема главный-рабочий

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

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

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

мастер-работник и как узкое место

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

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

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

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

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

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

Принцип

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

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

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

Приложение

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

Интернет-службы

Одним из наиболее часто используемых приложений балансировки нагрузки является предоставление единой Интернет-службы с нескольких серверов, иногда называемых ферма серверов. Обычно системы с балансировкой нагрузки включают популярные веб-сайты, большие сети Internet Relay Chat, узлы с высокой пропускной способностью протокол передачи файлов, протокол передачи сетевых новостей (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-запись. На сервере 1 файл зоны для www.example.org сообщает:

@ в 192.0.2.1

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

@ в 203.0.113.2

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

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

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

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

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

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

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

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

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

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

Постоянство

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

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

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

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

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

В очень распространенном случае, когда клиентом является веб-браузер, простой, но эффективный подход состоит в том, чтобы хранить данные сеанса в самом браузере. Один из способов добиться этого - использовать файл 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)
Нагрузка балансировщики могут предоставлять такие функции, как SYN cookie и отложенное связывание (внутренние серверы не видят клиента, пока он не завершит свое TCP-рукопожатие) для смягчения атак SYN flood и в целом разгрузить работу с серверов на более эффективную платформу.
HTTP-сжатие
HTTP-сжатие сокращает объем данных, передаваемых для объектов HTTP, за счет использования сжатия gzip, доступного во всех современных веб-браузерах. Чем больше отклик и чем дальше находится клиент, тем больше эта функция может сократить время отклика. Компромисс заключается в том, что эта функция создает дополнительную нагрузку на ЦП для балансировщика нагрузки и вместо этого может выполняться веб-серверами.
Разгрузка TCP
Различные поставщики используют разные термины для этого, но идея заключается в том, что обычно каждый HTTP-запрос от каждого клиента представляет собой отдельное TCP-соединение. Эта функция использует HTTP / 1.1 для объединения нескольких HTTP-запросов от нескольких клиентов в один TCP-сокет к внутренним серверам.
Буферизация TCP
Балансировщик нагрузки может буферизовать ответы от сервера и подавать данные из ложки медленным клиентам, позволяя веб-серверу освобождать поток для других задач быстрее, чем если бы он отправлял весь запрос клиенту напрямую.
Прямой возврат сервера
Вариант для асимметричного распределения нагрузки, при котором запрос и ответ имеют разные сетевые пути.
Проверка работоспособности
Балансировщик опрашивает серверы на предмет работоспособности уровня приложения и удаляет отказавшие серверы из пула.
HTTP-кеширование
Балансировщик хранит статический контент, поэтому некоторые запросы могут обрабатываться без обращения к серверам.
Фильтрация контента
Некоторые балансировщики могут произвольно изменять проходящий трафик.
Безопасность HTTP
Некоторые балансировщики могут скрывать страницы ошибок HTTP, удалять идентификатор сервера заголовки entification из ответов HTTP и шифрование файлов cookie, чтобы конечные пользователи не могли ими манипулировать.
Очередь с приоритетом
Также известна как формирование скорости, возможность назначать разный приоритет разному трафику.
Коммутация с учетом содержимого
Большинство балансировщиков нагрузки могут отправлять запросы на разные серверы в зависимости от запрашиваемого URL-адреса, при условии, что запрос не зашифрован (HTTP) или если он зашифрован (через HTTPS), что HTTPS запрос завершается (расшифровывается) на балансировщике нагрузки.
Аутентификация клиента
Аутентифицирует пользователей с использованием различных источников аутентификации, прежде чем разрешить им доступ к веб-сайту.
Программное управление трафиком
По крайней мере, один балансировщик позволяет использовать язык сценариев, чтобы разрешить настраиваемые методы балансировки, произвольные манипуляции с трафиком и т. Д.
Межсетевой экран
Межсетевые экраны могут предотвращать прямые подключения к внутренним серверам по соображениям сетевой безопасности.
Система предотвращения вторжений
Intrusio n системы предотвращения предлагают безопасность на уровне приложений в дополнение к сетевому / транспортному уровню, предлагаемому защитой межсетевого экрана.

Использование в телекоммуникациях

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

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

Мост по кратчайшему пути

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

Маршрутизация 1

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

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

Использование в сетях центров обработки данных

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

Связь с отработкой отказа

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

См. Также

Ссылки

  1. ^Сандерс, Питер; Мельхорн, Курт; Дицфельбингер, Мартин; Дементьев, Роман (11 сентября 2019). Последовательные и параллельные алгоритмы и структуры данных: основной набор инструментов. ISBN 978-3-030-25208-3.
  2. ^Лю, Ци; Цай, Вэйдун; Джин, Дандан; Шен, Цзянь; Фу, Чжанцзе; Лю, Сяодун; Линге, Найджел (30 августа 2016 г.). «Точность оценки времени выполнения задач времени выполнения в неоднородной распределенной среде». Датчики. 16 (9): 1386. doi : 10.3390 / s16091386. PMID 27589753. S2CID 391429.
  3. ^Алакил, Али (ноябрь 2009 г.). «Руководство по динамической балансировке нагрузки в распределенных компьютерных системах». Международный журнал компьютерных наук и сетевой безопасности (IJCSNS). 10.
  4. ^Асгар, Саджад; Обанель, Эрик; Бремнер, Дэвид (октябрь 2013 г.). "Параллельный решатель SAT на основе динамического планирования заданий". 2013 42-я Международная конференция по параллельной обработке: 110–119. DOI : 10.1109 / ICPP.2013.20. ISBN 978-0-7695-5117-3. S2CID 15124201.
  5. ^Punetha Sarmila, G.; Gnanambigai, N.; Динадаялан, П. (2015). «Обзор отказоустойчивых алгоритмов балансировки нагрузки в облачных вычислениях». 2-я Международная конференция по электронике и системам связи (ICECS): 1715–1720. DOI : 10.1109 / ECS.2015.7124879. ISBN 978-1-4799-7225-8. S2CID 30175022.
  6. ^Сандерс, Питер; Мельхорн, Курт; Дицфельбингер, Мартин; Дементьев, Роман (11 сентября 2019). Последовательные и параллельные алгоритмы и структуры данных: основной набор инструментов. ISBN 978-3-030-25208-3.
  7. ^«NGINX и« Сила двух вариантов »алгоритм балансировки нагрузки». nginx.com. 2018-11-12. Архивировано из оригинального 12.12.2019.
  8. ^"Test Driving" Сила двух случайных вариантов "Load Balancing". haproxy.com. 2019-02-15. Архивировано из оригинала 15.02.2019.
  9. ^Eager, Derek L; Лазовская, Эдвард Д.; Захоржан, Джон (1 марта 1986 г.). «Сравнение инициируемого получателем и отправителя адаптивного распределения нагрузки». Оценка эффективности. 6 (1): 53–68. DOI : 10.1016 / 0166-5316 (86) 90008-8. ISSN 0166-5316.
  10. ^Сандерс, Питер (1998). «Древовидные вычисления как модель для параллельных приложений». doi : 10.5445 / ir / 1000074497. Для журнала Cite требуется | journal =()
  11. ^Запись адреса IPv4 (A)
  12. ^Шаблон: балансировка нагрузки на стороне клиента
  13. ^ Архитектура на стороне сервера MMOG. Серверы переднего плана и случайная балансировка нагрузки на стороне клиента
  14. ^«Высокая доступность». Linuxvirtualserver.org. Дата обращения 20 ноября 2013.
  15. ^Ранджан, Р. (2010). «Обеспечение однорангового облака: обнаружение сервисов и балансировка нагрузки». Облачные вычисления.
  16. ^ «Балансировка нагрузки 101: гайки и болты». F5 Сети. 05.12.2017. Архивировано из оригинала 05.12.2017. Проверено 23.03.2018.
  17. ^Шуан Ю (8 мая 2012 г.). " IEEE УТВЕРЖДАЕТ НОВЫЙ СТАНДАРТ IEEE 802.1aq ™ «Мост по кратчайшему пути». IEEE. Получено 2 июня 2012 г.
  18. ^Питер Эшвуд-Смит (24 февраля 2011 г.). «Кратчайший мост для моста IEEE 802.1aq.>(PDF). Huawei. Архивировано из оригинала (PDF) 15 мая 2013 года. Дата обращения 11 мая 2012 года.
  19. ^Джим Даффи (11 мая 2012 года). «Крупнейшая система здравоохранения Иллинойса искоренена Cisco построить частное облако стоимостью 40 миллионов долларов ". Советник для ПК. Проверено 11 мая 2012 г. Мост кратчайшего пути заменит связующее дерево в структуре Ethernet.
  20. ^«IEEE утверждает новый стандарт моста кратчайшего пути IEEE 802.1aq». Технология Power Up. 7 мая 2012 г. Дата обращения 11 мая 2012 г.
  21. ^Mohammad Noormohammadpour, Cauligi S. Raghavendra Минимизация времени завершения потока с помощью адаптивной маршрутизации по глобальным сетям между центрами обработки данных Плакатные сессии IEEE INFOCOM 2018, DOI: 10.13140 / RG.2.2.36009.90720 6 января 2019
  22. ^ М. Ноормохаммадпур, К. С. Рагхавендра, «Управление трафиком центра обработки данных: понимание методов и компромиссов», IEEE Communications Surveys Tutorials, vol. ПП, нет. 99, стр. 1-1.
  23. ^Отказоустойчивость и балансировка нагрузки IBM 6 января 2019

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

На Wikimedia Commons есть носители, относящиеся к Балансировка нагрузки (вычисления).
Последняя правка сделана 2021-05-28 04:57:50
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте