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

Диспетчер кластерных ресурсов Service Fabric — это центральная служба, которая работает в кластере. Он управляет требуемым состоянием служб в кластере, в частности потреблением ресурсов и правилами размещения.

Для управления ресурсами в кластере диспетчеру кластерных ресурсов Service Fabric нужна определенная информация:

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

В разное время одна и та же служба может использовать разный объем ресурсов, при этом службы обычно зависят от нескольких типов ресурсов. В разных службах могут учитываться как реальные физические, так и логические ресурсы. Например, службы контролируют такие физические показатели, как потребление памяти и места на диске. Но еще чаще их интересуют логические метрики, например WorkQueueDepth (Длина очереди заданий) или TotalRequests (Общее количество запросов). Логические и физические метрики могут использоваться в одном и том же кластере. Метрики могут совместно использоваться для нескольких служб или относиться к конкретной службе.

Другие вопросы

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

Кластер и службы являются динамическими:

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

Компоненты и поток данных диспетчера кластерных ресурсов

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

Посмотрите на схему ниже.

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

Посмотрите на следующую схему, которая показывает, что происходит далее. Предположим, диспетчер кластерных ресурсов определяет, что необходимы изменения. Он вносит необходимые изменения по согласованию с другими службами (в частности с диспетчером отработки отказов). На соответствующие узлы отправляются необходимые команды (4). Предположим, диспетчер ресурсов заметил, что узел Node5 перегружен, и решил перенести службу B с узла Node5 на узел Node4. После перенастройки (5) кластер выглядит следующим образом:

Следующие шаги

• В Cluster Resource Manager предусмотрено много параметров для описания кластера. Дополнительные сведения об этих параметрах см. в статье с описанием кластера Service Fabric.
• Основная задача диспетчера кластерных ресурсов — перераспределение нагрузки кластера и применение правил размещения. Дополнительные сведения о настройке этих функций см. в разделе Балансировка кластера Service Fabric.