Введение в группы приложений

  • Статья

Диспетчер кластерных ресурсов 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, а текущая нагрузка составляет 5. Создание службы, для которой указана стандартная нагрузка 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, можно гарантировать резервирование минимальной нагрузки для приложения в кластере. Если оставшаяся емкость в кластере меньше, чем общая требуемая резервируемая емкость, то при создании приложения происходит сбой.

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

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

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

Допустим, в примере справа приложение Application1 было создано со следующими параметрами:

  • MinimumNodes имеет значение 2;
  • для приложения определена метрика со следующими значениями:
    • 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 использовать эту емкость, даже если в это время службы в Application1 не потребляют ресурсы. Зарезервированная для приложения емкость считается потребляемой и будет учитываться при определении остатка доступной емкости на этом узле или в кластере. Зарезервированная емкость мгновенно вычитается из оставшейся емкости кластера, однако из емкости определенного узла она вычитается только в том случае, если в нем размещается по крайней мере один объект службы. Этот второй этап резервирования позволяет более гибко и более эффективно использовать ресурсы, поскольку на конкретных узлах резервирование происходит только по мере необходимости.

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

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

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 возвращает основные сведения о параметрах емкости, указанных для приложения. Сюда входят данные о минимальном и максимальном числе узлов, а также о том, сколько узлов приложение занимает в настоящее время. Также вы получите информацию по каждой метрике нагрузки для приложения, в том числе перечисленные ниже сведения.

  • Metric Name: имя метрики.
  • Reservation Capacity: емкость, зарезервированная в кластере для этого приложения.
  • Application Load: общая нагрузка, создаваемая дочерними репликами этого приложения.
  • Application Capacity: максимально допустимое значение нагрузки приложения.

Удаление емкости приложения

Когда для приложения будут установлены параметры емкости приложения, их можно будет удалить с помощью API-интерфейсов обновления приложения или командлетов PowerShell. Пример:

Update-ServiceFabricApplication –Name fabric:/MyApplication1 –RemoveApplicationCapacity

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

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

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

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

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

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

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

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