Gestão de recursos

Quando você está executando vários serviços no mesmo nó ou cluster, é possível que um serviço consuma mais recursos, deixando de lado outros serviços no processo. Este problema é referido como o problema do "vizinho barulhento". O Azure Service Fabric permite que o desenvolvedor controle esse comportamento especificando solicitações e limites por serviço para limitar o uso de recursos.

Antes de prosseguir com 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

A governança de recursos é suportada no Service Fabric de acordo com o pacote de serviços. Os recursos atribuídos ao pacote de serviço podem ser divididos entre pacotes de código. O Service Fabric suporta governança de CPU e memória por pacote de serviço, com duas métricas integradas:

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

• Memória (nome servicefabric:/_MemoryInMBda métrica): A memória é expressa em megabytes e é mapeada para a memória física disponível na máquina.

Para essas duas métricas, o CRM (Gerenciador de Recursos de Cluster) rastreia 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 eles:

• O cluster pode ser balanceado 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 em buffer pode ser definida para essas duas métricas.

Mecanismo de governação dos recursos

A partir da versão 7.2, o tempo de execução do Service Fabric suporta a 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 métricas e servicefabric:/_MemoryInMB . 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, a malha de serviço também usa os valores de solicitação como limites.
• Quando a especificação LimitsOnly é usada, a malha de serviço considera os valores de solicitação como 0.
• Quando a especificação RequestsAndLimits é usada, os valores limite devem ser maiores ou iguais aos valores da solicitação.

Para entender melhor o mecanismo de governança de recursos, vamos examinar um exemplo de cenário de posicionamento com uma especificação RequestsOnly para o recurso da CPU (o mecanismo de governança de 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 apenas 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 apenas um pacote de código baseado em processo e também especifica apenas uma solicitação de um núcleo de CPU. Como ambos os pacotes de serviço têm uma especificação RequestsOnly, seus valores limite são definidos para seus valores de solicitação.

1. Primeiro, o pacote de serviço baseado em contêiner que solicita um núcleo de CPU é colocado no nó. O tempo de execução ativa o contêiner e define o limite da 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 que solicita um núcleo de CPU é colocado no nó. O tempo de execução ativa o processo de serviço e define seu limite de CPU para um núcleo.

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

Vamos agora 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 tempo de execução ativa o contêiner e define o limite da 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 tempo de execução ativa o processo de serviço e define seu limite de CPU para um núcleo.

Neste ponto, a soma das solicitações de CPU de pacotes de serviço que são colocados no nó é igual à capacidade da CPU do nó. O CRM não colocará mais contêineres ou processos de serviço com solicitações de CPU nesse 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 estourarem ao mesmo tempo, há possibilidade de disputa para o recurso da CPU. Tal disputa será gerenciada pelo sistema operacional subjacente à plataforma. Neste exemplo, o contêiner pode explodir até dois núcleos de CPU, resultando na solicitação do processo de um núcleo de CPU não sendo garantida.

Existem algumas situações em que pode haver disputa pela CPU. Nessas situações, o processo e o contêiner do nosso exemplo podem enfrentar o problema do vizinho barulhento:

• Misturando serviços e contêineres governados e não controlados: se um usuário criar um serviço sem nenhuma governança de recursos especificada, o tempo de execução o verá como não consumindo recursos e poderá colocá-lo no nó em nosso exemplo. Nesse caso, esse novo processo efetivamente consome alguma CPU às custas dos serviços que já estão em execução no nó. Existem duas soluções para este problema. Não misture serviços governados e não governados no mesmo cluster ou use restrições de posicionamento para que esses dois tipos de serviços não acabem no mesmo conjunto de nós.

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

• Quando as solicitações não são iguais a limites: conforme descrito no exemplo RequestsAndLimits anteriormente, as solicitações não levam à reserva de recursos em um nó. Quando um serviço com limites maiores do que solicitações é colocado em um nó, ele pode consumir recursos (se disponíveis) até 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 um nó é iniciado e ingressa no cluster, o Service Fabric deteta a quantidade disponível de memória e o número disponível de núcleos e, em seguida, define as capacidades do nó para esses dois recursos.

Para deixar espaço no buffer para o sistema operacional e para outros processos que possam estar sendo executados no nó, o Service Fabric usa apenas 80% dos recursos disponíveis no nó. Essa porcentagem é configurável e pode ser alterada no manifesto do cluster.

Aqui está 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 deteção automática de capacidades de nó para CPU e memória é a configuração recomendada (a deteção automática é ativada por padrão). No entanto, se você precisar de configuração manual completa de capacidades de nó, poderá configurá-las por tipo de nó usando o mecanismo para descrever nós no cluster. Aqui está um exemplo de como configurar o tipo de nó com quatro 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 deteção automática de recursos disponíveis está habilitada e as capacidades do nó são definidas manualmente no manifesto do cluster, o Service Fabric verifica se o nó tem recursos suficientes para suportar a 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 de nó definidas no manifesto forem maiores do que os recursos disponíveis, o Service Fabric usará os recursos disponíveis como capacidades de nó.

A deteção automática dos recursos disponíveis pode ser desativada se não for necessária. Para desativá-lo, altere a seguinte configuração:

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

Para um 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 governança de recursos

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

Exemplo 1: Especificação 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 CpuCores atributo é usado para especificar uma solicitação de 1 núcleo de CPU para ServicePackageA. Como o limite de CPU (CpuCoresLimit atributo) 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.

ServicePackageA só será colocado em um nó onde a capacidade restante da CPU 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ódigo (CodeA1 e CodeA2) e ambos especificam o CpuShares atributo. A proporção de CpuShares 512:256 é usada para calcular os limites de CPU para os pacotes de código individuais. Assim, 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 CpuShares não forem especificados para todos os pacotes de código, o Service Fabric dividirá o limite de CPU igualmente entre eles.

Enquanto CpuShares especificados para pacotes de código representam sua proporção relativa do limite geral de CPU do pacote de serviço, os valores de memória para pacotes de código são especificados em termos absolutos. Neste exemplo, o MemoryInMB atributo é usado para especificar solicitações de memória de 1024 MB para CodeA1 e CodeA2. Como o limite de memória (MemoryInMBLimit atributo ) não é especificado, o Service Fabric também usa os valores de solicitação especificados como limites para os pacotes de código. A solicitação de memória (e 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ódigo constituintes. Assim, para ServicePackageA, a solicitação de memória e o limite são calculados como 2048 MB.

ServicePackageA só será colocado em um nó onde a capacidade de memória restante após subtrair a soma das solicitações de memória 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ódigo (contêineres ou processos) não poderão alocar mais memória do que esse limite, e tentar fazer isso resultará em exceções de falta de memória.

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

Ao especificar configurações de governança de recursos, é possível usar parâmetros de aplicativo para gerenciar várias configurações de aplicativo. O exemplo a seguir mostra o uso de parâmetros de 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âmetros 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âmetros do aplicativo. Neste exemplo, um arquivo de parâmetro pode ser usado para testar o aplicativo localmente, onde ele obteria menos recursos do que na 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>

Impondo os limites de recursos para serviços do usuário

Embora a aplicação de governança de recursos aos seus serviços do Service Fabric garanta que esses serviços controlados por recursos não possam exceder sua cota de recursos, muitos usuários ainda precisam executar alguns de seus 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 "fugitivos" consomem todos os recursos disponíveis nos nós do Service Fabric, o que pode levar a problemas sérios como:

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

Para evitar que essas situações ocorram, o Service Fabric permite que você imponha 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 do usuário nunca usarão mais do que a quantidade especificada de recursos. Isso é conseguido definindo o valor para a configuração EnforceUserServiceMetricCapacities na seção PlacementAndLoadBalancing do ClusterManifest como true. Essa configuração está desativada por padrão.

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

Observações complementares:

• A imposição do limite de recursos aplica-se apenas às métricas e servicefabric:/_CpuCores servicefabric:/_MemoryInMB de recursos
• A imposição de limite de recursos só funciona se as capacidades do nó para as métricas de recursos estiverem disponíveis para o Service Fabric, seja por meio do mecanismo de deteçã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 poderá saber quantos recursos reservar para os serviços do usuário. O Service Fabric emitirá um aviso de integridade se "EnforceUserServiceMetricCapacities" for verdadeiro, mas as capacidades do nó não estiverem configuradas.

Outros recursos para contentores

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ódigo e são aplicados quando o contêiner é iniciado. Ao contrário da CPU e da memória, o Gerenciador de Recursos de Cluster não está ciente desses recursos e não fará nenhuma verificação de capacidade ou balanceamento de carga para eles.

• MemorySwapInMB: A quantidade total de memória de permuta que pode ser usada, em MB. Deve ser um número inteiro positivo.
• MemoryReservationInMB: O limite flexível (em MB) para governança de memória que é imposto somente quando a contenção de memória é detetada no nó. Deve ser um número inteiro positivo.
• CpuPercent: Percentagem utilizável de CPUs disponíveis (apenas 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 máxima de IO (leitura e gravação) em termos de IOps que podem ser usadas. Deve ser um número inteiro positivo.
• MaximumIOBandwidth: O máximo de E/S (bytes por segundo) que pode ser usado (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. Deve ser um número inteiro positivo entre 10 e 1000.
• 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 e o Docker no Windows errará se isso estiver definido.
• ShmSizeInMB: Tamanho de /dev/shm em bytes. Se omitido, o sistema usa 64MB. Deve ser um número inteiro positivo. Observe que isso é específico do Linux, no entanto, o Docker só ignorará (e não eliminará erros) se especificado.

Esses recursos podem ser combinados com CPU e memória. Aqui está 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óximos passos

• Para saber mais sobre o Gerenciador de Recursos de Cluster, leia Apresentando o gerenciador de recursos de cluster do Service Fabric.
• Para saber mais sobre o modelo de aplicativo, os pacotes de serviço e os pacotes de código - e como as réplicas são mapeadas para eles - leia Modelar um aplicativo no Service Fabric.