Общие сведения о группах приложений

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

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

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

Ограничение максимального количества узлов

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

На следующем рисунке показан экземпляр приложения с максимальным числом определенных узлов и без нее:

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

Параметр, который управляет этим поведением, называется MaximumNodes. Этот параметр можно задать во время создания приложения или обновить для экземпляра приложения, который уже запущен.

PowerShell

New-ServiceFabricApplication -ApplicationName fabric:/AppName -ApplicationTypeName AppType1 -ApplicationTypeVersion 1.0.0.0 -MaximumNodes 3
Update-ServiceFabricApplication –ApplicationName fabric:/AppName –MaximumNodes 5

C#

ApplicationDescription ad = new ApplicationDescription();
ad.ApplicationName = new Uri("fabric:/AppName");
ad.ApplicationTypeName = "AppType1";
ad.ApplicationTypeVersion = "1.0.0.0";
ad.MaximumNodes = 3;
await fc.ApplicationManager.CreateApplicationAsync(ad);

ApplicationUpdateDescription adUpdate = new ApplicationUpdateDescription(new Uri("fabric:/AppName"));
adUpdate.MaximumNodes = 5;
await fc.ApplicationManager.UpdateApplicationAsync(adUpdate);

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

Метрики приложений, загрузка и емкость

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

Для каждой метрики приложения можно задать два значения:

• Общая емкость приложения — этот параметр представляет общую емкость приложения для определенной метрики. Диспетчер кластерных ресурсов запрещает создание новых служб в этом экземпляре приложения, что приведет к превышению общего объема нагрузки. К примеру, предположим, что экземпляр приложения имел емкость 10 и нагрузка была равна пяти. Создание службы с общей нагрузкой по умолчанию 10 будет запрещено.
• Максимальная емкость узла — этот параметр задает максимальную общую нагрузку для приложения на одном узле. Если нагрузка превышает эту емкость, менеджер кластерных ресурсов перемещает реплики на другие узлы, чтобы нагрузка уменьшилась.

PowerShell.

New-ServiceFabricApplication -ApplicationName fabric:/AppName -ApplicationTypeName AppType1 -ApplicationTypeVersion 1.0.0.0 -Metrics @("MetricName:Metric1,MaximumNodeCapacity:100,MaximumApplicationCapacity:1000")

C#:

ApplicationDescription ad = new ApplicationDescription();
ad.ApplicationName = new Uri("fabric:/AppName");
ad.ApplicationTypeName = "AppType1";
ad.ApplicationTypeVersion = "1.0.0.0";

var appMetric = new ApplicationMetricDescription();
appMetric.Name = "Metric1";
appMetric.TotalApplicationCapacity = 1000;
appMetric.MaximumNodeCapacity = 100;
ad.Metrics.Add(appMetric);
await fc.ApplicationManager.CreateApplicationAsync(ad);

Резервная емкость

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

Резервирование пространства в кластере для приложения происходит сразу же, даже если:

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

Резервирование ресурсов для экземпляра приложения требует указания двух дополнительных параметров: MinimumNodes и NodeReservationCapacity

• MinimumNodes — определяет минимальное количество узлов, на которых должен работать экземпляр приложения.
• NodeReservationCapacity — этот параметр является метрикой для приложения. Это значение — это объем этой метрики, зарезервированной для приложения на любом узле, где выполняются службы в этом приложении.

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

Рассмотрим пример резервирования емкости:

В левом примере приложения не имеют определенной емкости приложений. Диспетчер кластерных ресурсов балансирует все в соответствии с обычными правилами.

В примере справа предположим, что Приложение1 было создано со следующими параметрами:

• Минимальное количество узлов установлено на два
• Метрика приложения, определенная с помощью
  • NodeReservationCapacity 20

PowerShell

New-ServiceFabricApplication -ApplicationName fabric:/AppName -ApplicationTypeName AppType1 -ApplicationTypeVersion 1.0.0.0 -MinimumNodes 2 -Metrics @("MetricName:Metric1,NodeReservationCapacity:20")

C#

ApplicationDescription ad = new ApplicationDescription();
ad.ApplicationName = new Uri("fabric:/AppName");
ad.ApplicationTypeName = "AppType1";
ad.ApplicationTypeVersion = "1.0.0.0";
ad.MinimumNodes = 2;

var appMetric = new ApplicationMetricDescription();
appMetric.Name = "Metric1";
appMetric.NodeReservationCapacity = 20;

ad.Metrics.Add(appMetric);

await fc.ApplicationManager.CreateApplicationAsync(ad);

Service Fabric резервирует емкость на двух узлах для Application1 и не позволяет службам из Application2 использовать такую емкость даже в том случае, если в приложении 1 в то время нет нагрузки. Эта зарезервированная емкость приложения считается потребляемой и учитывает оставшуюся емкость на этом узле и в кластере. Резервирование вычитается из оставшейся емкости кластера немедленно, однако зарезервированное потребление вычитается из емкости определенного узла, только если на нем помещается по крайней мере один объект службы. Это последующее резервирование позволяет гибко и лучше использовать ресурсы, так как ресурсы зарезервированы только на узлах при необходимости.

Получение сведений о загрузке приложения

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

PowerShell.

Get-ServiceFabricApplicationLoadInformation –ApplicationName fabric:/MyApplication1

C#

var v = await fc.QueryManager.GetApplicationLoadInformationAsync("fabric:/MyApplication1");
var metrics = v.ApplicationLoadMetricInformation;
foreach (ApplicationLoadMetricInformation metric in metrics)
{
    Console.WriteLine(metric.ApplicationCapacity);  //total capacity for this metric in this application instance
    Console.WriteLine(metric.ReservationCapacity);  //reserved capacity for this metric in this application instance
    Console.WriteLine(metric.ApplicationLoad);  //current load for this metric in this application instance
}

Запрос ApplicationLoad возвращает основные сведения о емкости приложения, указанной для приложения. Эти сведения включают сведения о минимальных узлах и максимальных узлах, а также число, которое в настоящее время занимает приложение. Она также содержит сведения о каждой метрии загрузки приложения, включая:

• Название метрики: имя метрики.
• Емкость резервирования: емкость кластера, зарезервированная в кластере для этого приложения.
• Загрузка приложения: общая загрузка дочерних реплик этого приложения.
• Емкость приложения: максимально допустимое значение нагрузки приложения.

Удаление ресурсов приложения

После установки параметров емкости приложений для приложения их можно удалить с помощью api обновления приложений или командлетов PowerShell. Рассмотрим пример.

Update-ServiceFabricApplication –Name fabric:/MyApplication1 –RemoveApplicationCapacity

Эта команда удаляет все параметры управления емкостью приложений из экземпляра приложения. Это включает MinimumNodes, MaximumNodes и метрики приложения, если таковые имеются. Действие команды происходит немедленно. После завершения этой команды диспетчер кластерных ресурсов использует поведение по умолчанию для управления приложениями. Параметры емкости приложения можно задать повторно с помощью Update-ServiceFabricApplication/System.Fabric.FabricClient.ApplicationManagementClient.UpdateApplicationAsync().

Ограничения емкости приложений

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

• Все целые параметры должны быть неотрицательных чисел.
• MinimumNodes никогда не должны быть больше, чем MaximumNodes.
• Если определены емкости для метрики загрузки, они должны соответствовать следующим правилам:
  • Емкость резервирования узлов не должна превышать максимальную емкость узла. Например, нельзя ограничить емкость метрики "ЦП" на узле двумя единицами и попытаться зарезервировать три единицы на каждом узле.
  • Если задано значение MaximumNodes, продукт MaximumNodes и максимальная емкость узла не должны превышать общую емкость приложения. Например, предположим, что максимальная емкость узла для метрики загрузки "ЦП" имеет значение восемь. Предположим, что для максимального числа узлов задано значение 10. В этом случае общая емкость приложения должна превышать 80 для этой метрики загрузки.

Ограничения применяются как во время создания приложения, так и обновлений.

Как не использовать емкость приложения

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

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

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