Общие сведения о диспетчере кластерных ресурсов Service Fabric

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

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

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

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

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

Знакомство с оркестраторами

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

Оркестраторы (а не люди) принимают меры при сбое компьютера или остановке рабочей нагрузки по непредвиденной причине. Большинство оркестраторов способны на большее, чем просто устранение сбоев. Они могут также управлять новыми развертываниями, применять обновления и контролировать потребление ресурсов, а также управлять ими. Все оркестраторы, по сути, занимаются поддержанием требуемого состояния в определенной среде. Для этого вам нужно сообщить оркестратору свои пожелания и дать ему выполнить необходимые действия. Aurora на платформе Mesos, Docker Datacenter и Docker Swarm, Kubernetes и Service Fabric — это все примеры оркестраторов. Разработка этих оркестраторов активно продолжается, чтобы учесть потребности реальных рабочих нагрузок в рабочих средах.

Оркестрация как служба

Диспетчер кластерных ресурсов — это системный компонент, который осуществляет оркестрацию в Service Fabric. Задачи диспетчера кластерных ресурсов делятся на три части:

1. Применение правил.
2. Оптимизация среды.
3. Помощь с другими процессами.

См. эту страницу, чтобы узнать, как работает Диспетчер кластерных ресурсов:

Чем это не является

В традиционных N-уровневых приложениях всегда использовалась подсистема балансировки нагрузки. Обычно это была подсистема балансировки сетевой нагрузки или нагрузки приложений, в зависимости от ее расположения в стеке сетевых протоколов. Одни балансировщики (например, BigIP от F5) работают на аппаратном уровне, а другие (например, балансировщик сетевой нагрузки от Майкрософт) — на программном. В других средах в этой роли может выступать, например, HAProxy, nginx, Istio или Envoy. В этих архитектурах балансировка нагрузки заключается в (приблизительно) равномерном распределении заданий между рабочими нагрузками без отслеживания состояний. Используются самые разные стратегии балансировки нагрузки. Некоторые подсистемы балансировки распределяют разные вызовы между разными серверами. Другие поддерживают закрепление сеансов. Более сложные подсистемы балансировки используют инструменты оценки нагрузки или информирования, чтобы маршрутизировать вызовы, исходя из прогнозируемых затрат на их обработку и текущей загрузки компьютеров.

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

И хотя некоторые из этих стратегий довольно интересны, диспетчер кластерных ресурсов Service Fabric совсем не похож на подсистему балансировки нагрузки или кэш. Azure Load Balancer балансирует нагрузку внешних интерфейсов, распределяя трафик между ними. Диспетчер кластерных ресурсов Service Fabric использует другую стратегию. Платформа Service Fabric перемещает службы туда, где они будут наиболее полезны, и ожидает соответствующих перемещений трафика или нагрузки. Например, она может переместить службы на те узлы, у которых ниже температура, предполагая, что размещенные там службы работают не очень активно. Возможно даже, что размещенные там службы уже удалены или перемещены в другое место. Кроме того, диспетчер кластерных ресурсов может убрать службу с определенного компьютера, например, перед его обновлением или в случае превышения нагрузки из-за всплеска активности размещенных на нем служб. Кроме того, возможно повышение потребности службы в ресурсах. В итоге на этом компьютере будет недостаточно ресурсов для продолжения ее выполнения.

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

Дальнейшие действия

• Сведения об архитектуре диспетчера кластерных ресурсов и потоке информации в нем см. в этой статье
• В Cluster Resource Manager предусмотрено много параметров для описания кластера. Дополнительные сведения о метриках см. в статье, в которой описывается кластер Service Fabric.
• Дополнительные сведения о настройке служб см. в разделе Настройка параметров Cluster Resource Manager для служб Service Fabric.
• Метрики показывают, как диспетчер кластерных ресурсов Service Fabric управляет потреблением и емкостью в кластере. Чтобы узнать больше о метриках и их настройке, ознакомьтесь с этой статьей.
• Диспетчер кластерных ресурсов работает с функциями управления Service Fabric. Подробные сведения об этой интеграции см. в этой статье.
• Чтобы узнать, как диспетчер кластерных ресурсов управляет нагрузкой кластера и балансирует ее, ознакомьтесь со статьей о балансировке нагрузки