Знакомство с диспетчером ресурсов кластера Service Fabric

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

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

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

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

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

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

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

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

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

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

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

Проверьте эту страницу для обучаемого видео, чтобы понять, как работает Диспетчер кластерных ресурсов:

Что это не так

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

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

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

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

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

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