Управление ресурсами

При запуске нескольких служб на одном узле или кластере возможно, что одна служба может использовать больше ресурсов, лишая другие службы ресурсов в процессе. Эта проблема известна как «шумный сосед». Azure Service Fabric позволяет разработчику управлять этим поведением, указывая запросы и ограничения для каждой службы, чтобы ограничить использование ресурсов.

Прежде чем продолжить работу с этой статьей, рекомендуется ознакомиться с моделью приложения Service Fabric и моделью размещения Service Fabric.

Метрики управления ресурсами

Управление ресурсами поддерживается в Service Fabric в соответствии с пакетом службы. Ресурсы, назначенные пакету службы, можно дополнительно разделить между пакетами кода. Service Fabric поддерживает управление ЦП и памятью для каждого пакета службы с двумя встроенными метриками:

• ЦП (название метрики servicefabric:/_CpuCores): логическое ядро, доступное на хост-машине. Все ядра во всех узлах имеют одинаковый вес.

• Память (название servicefabric:/_MemoryInMBметрики): память выражается в мегабайтах и соответствует физической памяти, доступной на устройстве.

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

Все существующие функции можно использовать с ними:

• Кластер можно сбалансировать в соответствии с этими двумя метриками (поведением по умолчанию).
• Кластер можно дефрагментировать в соответствии с этими двумя метриками.
• При описании кластера буферизованная емкость может быть задана для этих двух метрик.

Механизм управления ресурсами

Начиная с версии 7.2 среда выполнения Service Fabric поддерживает спецификацию запросов и ограничений ресурсов ЦП и памяти.

• Запросы: Значения запросов ЦП и памяти представляют нагрузки, используемые диспетчером ресурсов кластера (CRM) для servicefabric:/_CpuCores метрик и servicefabric:/_MemoryInMB метрик. Другими словами, CRM считает потребление ресурсов службы равными своим значениям запроса и использует эти значения при принятии решений о размещении.

• Ограничения: Значения ограничения ЦП и памяти представляют фактические ограничения ресурсов, применяемые при активации процесса или контейнера на узле.

Service Fabric позволяет RequestsOnly, LimitsOnly и спецификации RequestsAndLimits для ЦП и памяти.

• При использовании спецификации RequestOnly service fabric также использует значения запроса в качестве ограничений.
• Если используется спецификация LimitsOnly, service fabric считает значения запроса 0.
• Если используется спецификация RequestAndLimits, предельные значения должны быть больше или равно значениям запроса.

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

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

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

На этом этапе сумма запросов равна емкости узла. CRM больше не будет размещать контейнеры или процессы службы с запросами ЦП на этом узле. На узле процесс и контейнер выполняются, используя по одному ядру каждый, и не будут конкурировать за ресурсы ЦП.

Давайте рассмотрим наш пример с спецификацией RequestsAndLimits . На этот раз пакет службы на основе контейнера задает запрос одного ядра ЦП и ограничение двух ядер ЦП. Пакет службы на основе процесса указывает как запрос, так и ограничение одного ядра ЦП.

1. Сначала пакет службы на основе контейнера помещается на узел. Среда выполнения активирует контейнер и задает ограничение ЦП на два ядра. Контейнер не сможет использовать более двух ядер.
2. Затем пакет службы, основанный на процессе, размещается на узле. Среда выполнения активирует процесс службы и задает ограничение ЦП на одно ядро.

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

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

• Сочетание управляемых и неуправляемых служб и контейнеров: если пользователь создает службу без указания управления ресурсами, среда выполнения рассматривает ее как не потребляющую ресурсы и может разместить ее на узле в нашем примере. В этом случае новый процесс эффективно потребляет некоторые ЦП за счет служб, которые уже работают на узле. Эту проблему можно устранить двумя способами. Либо не смешивайте управляемые и неуправляемые службы в одном кластере, либо используйте ограничения размещения, чтобы эти два типа служб не оказались в одном наборе узлов.

• При запуске другого процесса на узле за пределами Service Fabric (например, службы ОС): в этой ситуации процесс за пределами Service Fabric также борется за ЦП с существующими службами. Решение этой проблемы заключается в том, чтобы правильно настроить емкости узлов для учета затрат на ОС, как показано в следующем разделе.

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

Настройка кластера для включения управления ресурсами

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

Чтобы оставить буферное пространство для операционной системы и для других процессов, которые могут выполняться на узле, Service Fabric использует только 80% доступных ресурсов на узле. Этот процент настраивается и может быть изменен в манифесте кластера.

Ниже приведен пример того, как указать Service Fabric использовать 50% доступных ЦП и 70% доступной памяти:

<Section Name="PlacementAndLoadBalancing">
    <!-- 0.0 means 0%, and 1.0 means 100%-->
    <Parameter Name="CpuPercentageNodeCapacity" Value="0.5" />
    <Parameter Name="MemoryPercentageNodeCapacity" Value="0.7" />
</Section>

Для большинства клиентов и сценариев автоматическое обнаружение емкостей узлов для ЦП и памяти является рекомендуемой конфигурацией (автоматическое обнаружение включается по умолчанию). Однако если вам потребуется полная настройка емкостей узлов вручную, их можно настроить для каждого типа узла с помощью механизма описания узлов в кластере. Ниже приведен пример настройки типа узла с четырьмя ядрами и 2 ГБ памяти:

    <NodeType Name="MyNodeType">
      <Capacities>
        <Capacity Name="servicefabric:/_CpuCores" Value="4"/>
        <Capacity Name="servicefabric:/_MemoryInMB" Value="2048"/>
      </Capacities>
    </NodeType>

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

• Если емкости узлов, определенные в манифесте, меньше или равны доступным ресурсам на узле, Service Fabric использует емкости, указанные в манифесте.

• Если емкости узлов, определенные в манифесте, больше доступных ресурсов, Service Fabric использует доступные ресурсы в качестве емкостей узлов.

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

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="AutoDetectAvailableResources" Value="false" />
</Section>

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

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="PreventTransientOvercommit" Value="true" />
    <Parameter Name="AllowConstraintCheckFixesDuringApplicationUpgrade" Value="true" />
</Section>

Указание системы управления ресурсами

Запросы и ограничения управления ресурсами указаны в манифесте приложения (раздел ServiceManifestImport). Рассмотрим несколько примеров:

Пример 1. Спецификация RequestsOnly

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="1"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="1024" />
    </Policies>
  </ServiceManifestImport>

В этом примере CpuCores атрибут используется для указания запроса 1 ядра ЦП для ServicePackageA. Так как ограничение ЦП (CpuCoresLimit атрибут) не указано, Service Fabric также использует указанное значение запроса 1 ядра в качестве ограничения ЦП для пакета службы.

ServicePackageA будет помещена только на узел, где оставшаяся емкость ЦП после вычитания суммы запросов ЦП всех пакетов служб, размещенных на этом узле , больше или равно 1 ядру. На узле пакет службы будет ограничен одним ядром. Пакет службы содержит два пакета кода (CodeA1 и CodeA2), а также укажите CpuShares атрибут. Доля CpuShares 512:256 используется для вычисления ограничений ЦП для отдельных пакетов кода. Таким образом, CodeA1 будет ограничен двумя третями ядра, и CodeA2 будет ограничен одной третью ядра. Если cpuShares не заданы для всех пакетов кода, Service Fabric распределяет ограничение ЦП одинаково между ними.

Хотя CpuShares, указанные для пакетов кода, представляют их относительную долю от общего ограничения ЦПУ пакета службы, значения памяти для пакетов кода указываются в абсолютных значениях. В этом примере MemoryInMB атрибут используется для указания запросов памяти 1024 МБ для CodeA1 и CodeA2. Так как ограничение памяти (MemoryInMBLimit атрибут) не указано, Service Fabric также использует указанные значения запроса в качестве ограничений для пакетов кода. Запрос памяти и его ограничение для пакета службы вычисляются как сумма значений запроса памяти и ограничения его составляющих пакетов кода. Таким образом, для ServicePackageA запрос памяти и ограничение вычисляется как 2048 МБ.

ServicePackageA будет помещена только на узел, где оставшаяся емкость памяти после вычитания суммы запросов памяти всех пакетов служб, размещенных на этом узле , больше или равно 2048 МБ. На узле оба пакета кода будут ограничены 1024 МБ памяти. Пакеты кода (контейнеры или процессы) не смогут выделить больше памяти, чем это ограничение, и попытка сделать это вызовет исключение OutOfMemory.

Пример 2. Спецификация LimitsOnly

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCoresLimit="1"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMBLimit="1024" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMBLimit="1024" />
    </Policies>
  </ServiceManifestImport>

В этом примере используются CpuCoresLimit и MemoryInMBLimit атрибуты, которые доступны только в SF версии 7.2 и более поздних версиях. Атрибут CpuCoresLimit используется для указания ограничения ЦП 1 ядра для ServicePackageA. Так как запрос ЦП (CpuCores атрибут) не указан, считается 0. MemoryInMBLimit атрибут используется для указания ограничений памяти в 1024 МБ для CodeA1 и CodeA2 и так как запросы (MemoryInMB атрибут) не указаны, они считаются 0. Таким образом, запрос памяти и ограничение для ServicePackageA вычисляются как 0 и 2048 соответственно. Так как запросы ЦП и памяти для ServicePackageA имеют значение 0, они не создают нагрузку для CRM для учета размещения, для servicefabric:/_CpuCores и servicefabric:/_MemoryInMB метрик. Таким образом, с точки зрения управления ресурсами ServicePackageA можно поместить на любой узел независимо от оставшейся емкости. Как и в примере 1, на узле CodeA1 будет ограничен двумя третью ядра и 1024 МБ памяти, а CodeA2 будет ограничена одной третью ядра и 1024 МБ памяти.

Пример 3. Спецификация RequestsAndLimits

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="1" CpuCoresLimit="2"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" MemoryInMBLimit="3072" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="2048" MemoryInMBLimit="4096" />
    </Policies>
  </ServiceManifestImport>

На основе первых двух примеров этот пример демонстрирует указание как запросов, так и ограничений ЦП и памяти. ServicePackageA запрашивает 1 ядро ЦП и 3072 МБ памяти (1024 + 2048) соответственно. Он может быть размещен только на узле, который имеет не менее 1 ядра (и 3072 МБ) емкости, оставшегося после вычитания суммы всех запросов ЦП (и памяти) всех пакетов служб, размещенных на узле, из общей емкости ЦП (и памяти) узла. На узле CodeA1 будет ограничен двумя третими ядрами и 3072 МБ памяти, а CodeA2 будет ограничен одной третью из 2 ядер и 4096 МБ памяти.

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

При указании параметров управления ресурсами можно использовать параметры приложения для управления несколькими конфигурациями приложений. В следующем примере показано использование параметров приложения:

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>

  <Parameters>
    <Parameter Name="CpuCores" DefaultValue="4" />
    <Parameter Name="CpuSharesA" DefaultValue="512" />
    <Parameter Name="CpuSharesB" DefaultValue="512" />
    <Parameter Name="MemoryA" DefaultValue="2048" />
    <Parameter Name="MemoryB" DefaultValue="2048" />
  </Parameters>

  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="[CpuSharesA]" MemoryInMB="[MemoryA]" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="[CpuSharesB]" MemoryInMB="[MemoryB]" />
    </Policies>
  </ServiceManifestImport>

В этом примере значения параметров по умолчанию задаются для рабочей среды, где каждый пакет службы получит 4 ядра и 2 ГБ памяти. Можно изменить значения по умолчанию с файлами параметров приложения. В этом примере можно использовать один файл параметров для локального тестирования приложения, где он получит меньше ресурсов, чем в рабочей среде:

<!-- ApplicationParameters\Local.xml -->

<Application Name="fabric:/TestApplication1" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="CpuCores" DefaultValue="2" />
    <Parameter Name="CpuSharesA" DefaultValue="512" />
    <Parameter Name="CpuSharesB" DefaultValue="512" />
    <Parameter Name="MemoryA" DefaultValue="1024" />
    <Parameter Name="MemoryB" DefaultValue="1024" />
  </Parameters>
</Application>

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

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

• Нехватка ресурсов других служб, работающих на узлах (включая системные службы Service Fabric)
• Узлы оказываются в неработоспособном состоянии
• Неответственные API управления кластерами Service Fabric

Чтобы предотвратить возникновение этих ситуаций, Service Fabric позволяет применять ограничения ресурсов для всех пользовательских служб Service Fabric, работающих на узле (управляемых и неуправляемых), чтобы гарантировать, что пользовательские службы никогда не будут использовать больше указанного объема ресурсов. Это достигается путем установки значения параметра конфигурации EnforceUserServiceMetricCapacities в разделе PlacementAndLoadBalancing ClusterManifest в true. Этот параметр отключен по умолчанию.

<SectionName="PlacementAndLoadBalancing">
    <ParameterName="EnforceUserServiceMetricCapacities" Value="false"/>
</Section>

Дополнительные замечания:

• Ограничение ресурсов применяется только к метрикам ресурсов servicefabric:/_CpuCores и servicefabric:/_MemoryInMB.
• Принудительное применение ограничения ресурсов работает только в том случае, если емкости узлов для метрик ресурсов доступны Service Fabric либо с помощью механизма автоматического обнаружения, либо с помощью пользователей, которые вручную указывают емкости узлов (как описано в разделе "Настройка кластера" для включения управления ресурсами ). Если емкости узлов не настроены, возможность использования ограничения ресурсов не может быть применена, так как Service Fabric не может знать, сколько ресурсов зарезервировать для пользовательских служб. Service Fabric выдает предупреждение о работоспособности, если значение "EnforceUserServiceMetricCapacities" имеет значение true, но емкости узлов не настроены.

Другие ресурсы для контейнеров

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

• MemorySwapInMB: общий объем памяти буфера, который можно использовать в МБ. Должно быть положительным целым числом.
• MemoryReservationInMB: мягкое ограничение (в МБ) для управления ресурсами памяти, которое применяется только при обнаружении конфликта памяти на узле. Должно быть положительным целым числом.
• CpuPercent: доступный процент доступных ЦП (только Для Windows). Должно быть положительным целым числом. Нельзя использовать с CpuShares, CpuCores или CpuCoresLimit.
• CpuShares: относительный вес ЦП. Должно быть положительным целым числом. Нельзя использовать с CpuPercent, CpuCores или CpuCoresLimit.
• MaximumIOps: максимальная скорость ввода-вывода (чтение и запись) с точки зрения операций ввода-вывода, которые можно использовать. Должно быть положительным целым числом.
• MaximumIOBandwidth: максимальное количество операций ввода-вывода (байт в секунду), которое можно использовать (чтение и запись). Должно быть положительным целым числом.
• BlockIOWeight: блокировать вес ввода-вывода относительно других пакетов кода. Должно быть положительным целым числом от 10 до 1000.
• DiskQuotaInMB: квота диска для контейнеров. Должно быть положительным целым числом.
• KernelMemoryInMB: ограничения памяти ядра в байтах. Должно быть положительным целым числом. Обратите внимание, что это специфично для Linux, и Docker на Windows вызовет ошибку, если это задано.
• ShmSizeInMB: размер /dev/shm в байтах. Если параметр не указан, система использует 64 МБ. Должно быть положительным целым числом. Обратите внимание, что это специфично для Linux, однако Docker будет игнорировать (и не выдавать ошибку), если указано.

Эти ресурсы можно объединить с ЦП и памятью. Ниже приведен пример указания дополнительных ресурсов для контейнеров:

    <ServiceManifestImport>
        <ServiceManifestRef ServiceManifestName="FrontendServicePackage" ServiceManifestVersion="1.0"/>
        <Policies>
            <ResourceGovernancePolicy CodePackageRef="FrontendService.Code" CpuPercent="5"
            MemorySwapInMB="4084" MemoryReservationInMB="1024" MaximumIOPS="20" />
        </Policies>
    </ServiceManifestImport>

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

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