Governança de recursos

Ao executar vários serviços no mesmo nó ou cluster, é possível que um serviço consuma mais recursos, privando outros serviços no processo. Esse problema é conhecido como o problema do “vizinho barulhento”. O Azure Service Fabric habilita o desenvolvedor a controlar esse comportamento especificando solicitações e limites por serviço para limitar o uso de recursos.

Antes de continuar lendo este artigo, recomendamos que você se familiarize com o Modelo de aplicativo do Service Fabric e o Modelo de hospedagem do Service Fabric.

Métricas de governança de recursos

Há suporte para a governança de recursos no Service Fabric de acordo com o pacote de serviço. Os recursos que são atribuídos ao pacote de serviço podem ser subdivididos entre pacotes de códigos. O Service Fabric dá suporte à governança de CPU e memória por pacote de serviço, com duas métricas internas:

• CPU (nome da métrica servicefabric:/_CpuCores): um núcleo lógico que está disponível no computador host. Todos os núcleos em todos os nós têm o mesmo peso.

• Memória (nome da métrica servicefabric:/_MemoryInMB): a memória é expressa em megabytes e é mapeada para a memória física disponível no computador.

Para essas duas métricas, o CRM (Gerenciador de Recursos de Cluster) controla a capacidade total do cluster, a carga em cada nó do cluster e os recursos restantes no cluster. Essas duas métricas são equivalentes a qualquer outro usuário ou métrica personalizada.

Todos os recursos existentes podem ser usados com elas:

• O cluster pode ser equilibrado de acordo com essas duas métricas (comportamento padrão).
• O cluster pode ser desfragmentado de acordo com essas duas métricas.
• Ao descrever um cluster, a capacidade armazenada em buffer pode ser definida para essas duas métricas.

Mecanismo de governança de recursos

A partir da versão 7.2, o runtime do Service Fabric dá suporte à especificação de solicitações e limites para recursos de CPU e memória.

• Solicitações: os valores de solicitação de CPU e memória representam as cargas usadas pelo CRM (Gerenciador de Recursos de Cluster) para as servicefabric:/_CpuCores e servicefabric:/_MemoryInMB métricas. Em outras palavras, o CRM considera o consumo de recursos de um serviço igual aos seus valores de solicitação e usa esses valores ao tomar decisões de posicionamento.

• Limites: os valores de limite de CPU e memória representam os limites de recursos reais aplicados quando um processo ou um contêiner é ativado em um nó.

O Service Fabric permite as especificações RequestsOnly, LimitsOnly e RequestsAndLimits para CPU e memória.

• Quando a especificação RequestsOnly é usada, o Service Fabric também usa os valores de solicitação como limites.
• Quando a especificação LimitsOnly é usada, o Service Fabric considera os valores da solicitação como 0.
• Quando a especificação RequestsAndLimits é usada, os valores de limite devem ser maiores ou iguais aos valores de solicitação.

Para entender melhor o mecanismo de governança de recursos, vamos conferir um cenário de posicionamento de exemplo com uma especificação RequestsOnly para o recurso de CPU (o mecanismo de governança da memória é equivalente). Considere um nó com dois núcleos de CPU e dois pacotes de serviço que serão colocados nele. O primeiro pacote de serviço a ser colocado, é composto por somente um pacote de código de contêiner e especifica apenas uma solicitação de um núcleo de CPU. O segundo pacote de serviço a ser colocado, é composto por somente um pacote de código baseado em processo e também especifica apenas uma solicitação de um núcleo de CPU. Como os dois pacotes de serviço têm uma especificação RequestsOnly, seus valores de limite são definidos para seus valores de solicitação.

1. Primeiro, o pacote de serviço baseado em contêiner solicitando um núcleo de CPU é colocado no nó. O runtime ativa o contêiner e define o limite de CPU para um núcleo. O contêiner não poderá usar mais de um núcleo.

2. Em seguida, o pacote de serviço baseado em processo solicitando um núcleo de CPU é colocado no nó. O runtime ativa o processo do serviço e define o seu limite de CPU para um núcleo.

Neste ponto, a soma das solicitações é igual à capacidade do nó. O CRM não coloca mais nenhum contêiner ou processos de serviço com solicitações de CPU neste nó. No nó, um processo e um contêiner estão sendo executados com um núcleo cada e não serão disputados entre si para a CPU.

Agora, vamos revisitar nosso exemplo com uma especificação RequestsAndLimits. Desta vez, o pacote de serviço baseado em contêiner especifica uma solicitação de um núcleo de CPU e um limite de dois núcleos de CPU. O pacote de serviço baseado em processo especifica uma solicitação e um limite de um núcleo de CPU.

1. Primeiro, o pacote de serviço baseado em contêiner é colocado no nó. O runtime ativa o contêiner e define o limite de CPU para dois núcleos. O contêiner não poderá usar mais de dois núcleos.
2. Em seguida, o pacote de serviço baseado em processo é colocado no nó. O runtime ativa o processo do serviço e define o seu limite de CPU para um núcleo.

Neste ponto, a soma de solicitações de CPU de pacotes de serviço que são colocados no nó é igual à capacidade de CPU do nó. O CRM não coloca mais nenhum contêiner ou processos de serviço com solicitações de CPU neste nó. No entanto, no nó, a soma dos limites (dois núcleos para o contêiner + um núcleo para o processo) excede a capacidade de dois núcleos. Se o contêiner e o processo dispararem ao mesmo tempo, haverá a possibilidade de contenção para o recurso de CPU. Essa contenção será gerenciada pelo sistema operacional subjacente da plataforma. Para este exemplo, o contêiner poderia disparar até dois núcleos de CPU, resultando na solicitação do processo de um núcleo de CPU não ser garantido.

Existem algumas situações nas quais podem haver contenção para a CPU. Nessas situações, o processo e contêiner do nosso exemplo poderá ter o problema do vizinho barulhento:

• Combinação de serviços e contêineres controlados e não controlados: se um usuário criar um serviço sem nenhuma governança de recursos especificada, o runtime considerará que ele não está consumindo nenhum recurso e poderá colocá-lo no nó de nosso exemplo. Nesse caso, esse novo processo efetivamente consume alguns recursos da CPU à custa dos serviços que já estão sendo executados no nó. Existem duas soluções para esse problema. Não misturar serviços controlados e não controlado no mesmo cluster ou usar restrições de posicionamento para que esses dois tipos de serviços não terminem no mesmo conjunto de nós.

• Quando outro processo for iniciado no nó, fora do Service Fabric (por exemplo, um serviço do SO): nessa situação, o processo fora do Service Fabric também competirá pela CPU com os serviços existentes. A solução para esse problema é configurar as capacidades de nó corretamente para a conta para a sobrecarga do sistema operacional, conforme mostrado na próxima seção.

• Quando as solicitações não são iguais aos limites: conforme descrito no exemplo de RequestsAndLimits anterior, as solicitações não levam à reserva de recursos em um nó. Quando um serviço com limites maiores do que as solicitações é colocado em um nó, ele pode consumir recursos (se disponíveis) até os seus limites. Nesses casos, outros serviços no nó podem não ser capazes de consumir recursos até seus valores de solicitação.

Configuração de cluster para habilitar a governança de recursos

Quando o nó for iniciado e ingressado no cluster, o Service Fabric detectará a quantidade de memória e o número de núcleos disponíveis e então definirá as capacidades de nó para esses dois recursos.

Para deixar algum espaço do buffer para o sistema operacional e para outros processos que possam estar em execução no nó, o Service Fabric usará somente 80% dos recursos disponíveis no nó. Esse percentual é configurável e pode ser alterado no manifesto do cluster.

Este é um exemplo de como instruir o Service Fabric a usar 50% da CPU disponível e 70% da memória disponível:

<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>

Para a maioria dos clientes e cenários, a detecção automática de capacidades de nó para CPU e memória é a configuração recomendada (a detecção automática é ativada por padrão). No entanto, se precisar de configuração manual completa de capacidades do nó, você poderá configurá-las por tipo de nó usando o mecanismo para descrever os nós no cluster. Este é um exemplo de como configurar o tipo de nó com dois núcleos e 2 GB de memória:

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

Quando a detecção automática de recursos disponíveis está habilitada e as capacidades de nó são definidas manualmente no manifesto do cluster, o Service Fabric verifica se o nó tem recursos suficientes para dar suporte à capacidade definida pelo usuário:

• Se as capacidades de nó definidas no manifesto forem menores ou iguais aos recursos disponíveis no nó, o Service Fabric usará as capacidades especificadas no manifesto.

• Se as capacidades do nó definidas no manifesto forem maiores que os recursos disponíveis, o Service Fabric usará os recursos disponíveis como as capacidades do nó.

A detecção automática de recursos disponíveis poderá ser desativada se não for necessária. Para desativá-la, altere a seguinte configuração:

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

Para obter o desempenho ideal, a seguinte configuração também deve ser ativada no manifesto do cluster:

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

Especificar a governança de recurso

As solicitações e os limites da governança de recursos são especificados no manifesto do aplicativo (seção ServiceManifestImport). Veja alguns exemplos:

Exemplo 1: especificação de 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>

Neste exemplo, o atributo CpuCores é usado para especificar uma solicitação de 1 núcleo de CPU para o ServicePackageA. Como o limite de CPU (atributo CpuCoresLimit) não é especificado, o Service Fabric também usa o valor de solicitação especificado de 1 núcleo como o limite de CPU para o pacote de serviço.

O ServicePackageA só será colocada em um nó no qual a capacidade de CPU restante depois de subtrair a soma das solicitações de CPU de todos os pacotes de serviço colocados nesse nó for maior ou igual a 1 núcleo. No nó, o pacote de serviço será limitado a um núcleo. O pacote de serviço contém dois pacotes de códigos (CodeA1 e CodeA2) e eles especificam o atributo CpuShares. A proporção de CpuShares 512:256 é usada para calcular os limites de CPU para os pacotes de código individuais. Portanto, o CodeA1 será limitado a dois terços de um núcleo e o CodeA2 será limitado a um terço de um núcleo. Se os CpuShares não forem especificados para todos os pacotes de códigos, o Service Fabric dividirá os limites de CPU igualmente entre eles.

Embora os CpuShares especificados para pacotes de códigos representem a proporção relativa deles do limite de CPU geral do pacote de serviço, os valores de memória para pacotes de código são especificados em termos absolutos. Neste exemplo, o atributo MemoryInMB é usado para especificar solicitações de memória de 1024 MB para CodeA1 e CodeA2. Como o limite de memória (atributo MemoryInMBLimit) não é especificado, o Service Fabric também usa os valores de solicitação especificados como os limites para os pacotes de código. A solicitação de memória (e o limite) para o pacote de serviço é calculada como a soma dos valores de solicitação de memória (e limite) de seus pacotes de códigos constituintes. Portanto, para o ServicePackageA, a solicitação e o limite de memória são calculados como 2048 MB.

O ServicePackageA só será colocada em um nó no qual a capacidade de memória restante depois de subtrair a soma das solicitações de CPU de todos os pacotes de serviço colocados nesse nó for maior ou igual a 2048 MB. No nó, ambos os pacotes de código serão limitados a 1024 MB de memória cada. Os pacotes de códigos (contêineres ou processos) não poderão alocar mais memória do que esse limite. A tentativa de fazer isso resultará em exceção de memória insuficiente.

Exemplo 2: especificação 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>

Este exemplo usa atributos CpuCoresLimit e MemoryInMBLimit, que estão disponíveis somente nas versões 7.2 e posteriores do SF. O atributo CpuCoresLimit é usado para especificar um limite de CPU de 1 núcleo para o ServicePackageA. Como a solicitação de CPU (atributo CpuCores) não é especificada, ela é considerada como 0. O atributo MemoryInMBLimit é usado para especificar os limites de memória de 1024 MB para CodeA1 e CodeA2 e, como as solicitações (atributo MemoryInMB) não são especificadas, elas são consideradas como 0. A solicitação e o limite de memória de ServicePackageA portanto, são calculados como 0 e 2048, respectivamente. Como as solicitações de CPU e memória para o ServicePackageA são 0, ela não apresenta nenhuma carga para o CRM considerar para posicionamento, para as métricas servicefabric:/_CpuCores e servicefabric:/_MemoryInMB. Portanto, de uma perspectiva de governança de recursos, o ServicePackageA pode ser colocado em qualquer nó, independentemente da capacidade restante. Semelhante ao 1º exemplo, no nó, o CodeA1 será limitado a dois terços de um núcleo e 1024 MB de memória e o CodeA2 será limitado a um terço de um núcleo e 1024 MB de memória.

Exemplo 3: especificação 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>

Com base nos dois primeiros exemplos, este exemplo demonstra a especificação de solicitações e limites para CPU e memória. O ServicePackageA tem solicitações de CPU e memória de 1 núcleo e 3072 (1024 + 2048) MB, respectivamente. Ele só pode ser colocado em um nó que tenha pelo menos 1 núcleo (e 3072 MB) de capacidade restante após subtrair a soma de todas as solicitações de CPU (e memória) de todos os pacotes de serviço que são colocados no nó da capacidade total de CPU (e memória) do nó. No nó, o CodeA1 será limitado a dois terços de 2 núcleos e 3072 MB de memória, enquanto o CodeA2 será limitado a um terço de 2 núcleos e 4096 MB de memória.

Usando parâmetros de aplicativo

Ao especificar as configurações da governança dos recursos, é possível usar os parâmetros do aplicativo para gerenciar várias configurações de aplicativo. O exemplo a seguir mostra o uso de parâmetros do aplicativo:

<?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>

Neste exemplo, os valores de parâmetro padrão são definidos para o ambiente de produção, onde cada pacote de serviço obteria 4 núcleos e 2 GB de memória. É possível alterar os valores padrão com arquivos de parâmetro do aplicativo. Neste exemplo, um arquivo de parâmetro pode ser usado para testar o aplicativo localmente, onde receberia menos recursos do que em produção:

<!-- 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>

Impor os limites de recursos para serviços de usuário

Embora aplicar a governança de recursos aos seus serviços do Service Fabric garanta que esses serviços governados por recursos não possam exceder sua cota de recursos, muitos usuários ainda precisam executar alguns dos serviços do Service Fabric no modo não governado. Ao usar serviços não governados do Service Fabric, é possível se deparar com situações em que serviços não governados "sem controle" consomem todos os recursos disponíveis em nós do Service Fabric, que podem gerar problemas sérios, como:

• A privação de recursos de outros serviços em execução nos nós (incluindo serviços de sistema do Service Fabric)
• Nós terminando em um estado não íntegro
• APIs de gerenciamento de cluster do Service Fabric sem resposta

Para impedir que essas situações ocorram, o Service Fabric permite impor os limites de recursos para todos os serviços de usuário do Service Fabric em execução no nó (governados e não governados) para garantir que os serviços de usuário nunca usem mais do que a quantidade especificada de recursos. Isso acontece ao definir o valor para a configuração EnforceUserServiceMetricCapacities na seção PlacementAndLoadBalancing do ClusterManifest como true. Esta configuração está desativada por padrão.

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

Comentários adicionais:

• A imposição de limite de recursos se aplica somente às métricas de recurso servicefabric:/_CpuCores e servicefabric:/_MemoryInMB
• A imposição de limite de recursos só funciona se as capacidades de nó para as métricas de recurso estiverem disponíveis para o Service Fabric, seja por meio do mecanismo de detecção automática ou por meio de usuários especificando manualmente as capacidades do nó (conforme explicado na seção Configuração do cluster para habilitar a governança de recursos). Se as capacidades do nó não estiverem configuradas, o recurso de imposição de limite de recursos não poderá ser usado, pois o Service Fabric não saberá a quantidade de recursos reservados para os serviços do usuário. O Service Fabric emitirá um aviso de integridade se "EnforceUserServiceMetricCapacities" for true, mas as capacidades do nó não estiverem configuradas.

Outros recursos para contêineres

Além da CPU e da memória, é possível especificar outros limites de recursos para contêineres. Esses limites são especificados no nível do pacote de códigos e aplicados quando o contêiner é iniciado. Ao contrário da CPU e da memória, o Gerenciador de Recursos de Cluster não reconhece esses recursos e não faz verificações de capacidade nem balanceamento de carga para eles.

• MemorySwapInMB: a quantidade total de memória de troca que pode ser usada, em MB. Deve ser um número inteiro positivo.
• MemoryReservationInMB: o limite dinâmico (em MB) para governança de memória que é imposto apenas quando a contenção de memória é detectada no nó. Deve ser um número inteiro positivo.
• CpuPercent: percentual utilizável de CPUs disponíveis (somente Windows). Deve ser um número inteiro positivo. Não pode ser usado com CpuShares, CpuCores ou CpuCoresLimit.
• CpuShares: peso relativo da CPU. Deve ser um número inteiro positivo. Não pode ser usado com CpuPercent, CpuCores ou CpuCoresLimit.
• MaximumIOps: taxa de E/S máxima (leitura e gravação) em termos da IOps que pode ser usada. Deve ser um número inteiro positivo.
• MaximumIOBandwidth: a E/S máxima (bytes por segundo) que pode ser usada (leitura e gravação). Deve ser um número inteiro positivo.
• BlockIOWeight: peso de E/S do bloco, em relação a outros pacotes de código. Precisa ser um inteiro positivo entre 10 e 1.000.
• DiskQuotaInMB: cota de disco para contêineres. Deve ser um número inteiro positivo.
• KernelMemoryInMB: limites de memória do Kernel em bytes. Deve ser um número inteiro positivo. Observe que isso é específico do Linux, o Docker no Windows apresentará um erro se isso estiver definido.
• ShmSizeInMB: tamanho de /dev/shm em bytes. Se omitido, o sistema usará 64MB. Deve ser um número inteiro positivo. Observe que isso é específico do Linux, no entanto, o Docker apenas ignorará (e não excluirá erros), se especificado.

Esses recursos podem ser combinados com a CPU e a memória. Este é um exemplo de como especificar recursos adicionais para contêineres:

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

Próximas etapas

• Para saber mais sobre o Gerenciador de Recursos de Cluster, leia Introdução ao Gerenciador de Recursos de Cluster do Service Fabric.
• Para saber mais sobre o modelo de aplicativo, pacotes de serviço e pacotes de códigos e como as réplicas são mapeadas para eles, leia Modelar um aplicativo no Service Fabric.