Gestão de recursos

Quando está a executar vários serviços no mesmo nó ou cluster, é possível que um serviço possa consumir mais recursos, esfomeando outros serviços no processo. Este problema é referido como o problema do "vizinho barulhento". O Azure Service Fabric permite ao programador controlar este comportamento ao especificar pedidos e limites por serviço para limitar a utilização de recursos.

Antes de continuar com este artigo, recomendamos que se familiarize com o modelo de aplicação do Service Fabric e o modelo de alojamento do Service Fabric.

Métricas de governação de recursos

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

• CPU (nome servicefabric:/_CpuCoresda métrica): um núcleo lógico que está disponível no computador anfitrião. Todos os núcleos em todos os nós são ponderados da mesma forma.

• Memória (nome servicefabric:/_MemoryInMBda métrica): a memória é expressa em megabytes e mapeia para a memória física que está disponível no computador.

Para estas duas métricas, o Cluster Resource Manager (CRM) monitoriza a capacidade total do cluster, a carga em cada nó no cluster e os restantes recursos no cluster. Estas duas métricas são equivalentes a qualquer outro utilizador ou métrica personalizada.

Nota

Os nomes de métricas personalizados não devem ser um destes dois nomes de métricas, uma vez que levará a um comportamento indefinido.

Todas as funcionalidades existentes podem ser utilizadas com as mesmas:

• O cluster pode ser equilibrado de acordo com estas duas métricas (comportamento predefinido).
• O cluster pode ser desfragmentado de acordo com estas duas métricas.
• Ao descrever um cluster, a capacidade em memória intermédia pode ser definida para estas duas métricas.

Nota

O relatório de carga dinâmico não é suportado para estas métricas; as cargas para estas métricas são definidas no momento da criação.

Mecanismo de governação de recursos

A partir da versão 7.2, o runtime do Service Fabric suporta a especificação de pedidos e limites para recursos de CPU e memória.

Nota

As versões de runtime do Service Fabric com mais de 7.2 suportam apenas um modelo em que um único valor serve tanto como o pedido como o limite para um determinado recurso (CPU ou memória). Isto é descrito como a especificação RequestsOnly neste documento.

• Pedidos: Os valores da CPU e do pedido de memória representam as cargas utilizadas pelo Cluster Resource Manager (CRM) para as servicefabric:/_CpuCores métricas eservicefabric:/_MemoryInMB. Por outras palavras, a CRM considera que o consumo de recursos de um serviço é igual aos respetivos valores de pedido e utiliza estes valores ao tomar decisões de colocação.

• Limites: Os valores de limite de CPU e Memória representam os limites de recursos reais aplicados quando um processo ou um contentor é ativado num nó.

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

• Quando a especificação RequestsOnly é utilizada, o service fabric também utiliza os valores do pedido como limites.
• Quando a especificação LimitsOnly é utilizada, o service fabric considera que os valores do pedido são 0.
• Quando a especificação RequestsAndLimits é utilizada, os valores de limite têm de ser maiores ou iguais aos valores do pedido.

Para compreender melhor o mecanismo de governação de recursos, vejamos um cenário de colocação de exemplo com uma especificação RequestsOnly para o recurso da CPU (o mecanismo para a governação da memória é equivalente). Considere um nó com dois núcleos de CPU e dois pacotes de serviço que serão colocados no mesmo. O primeiro pacote de serviço a ser colocado é composto por apenas um pacote de código de contentor e especifica apenas um pedido 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 processos e também especifica apenas um pedido de um núcleo de CPU. Uma vez que ambos os pacotes de serviço têm uma especificação RequestsOnly, os respetivos valores de limite são definidos para os respetivos valores de pedido.

1. Primeiro, o pacote de serviço baseado em contentor que pede um núcleo de CPU é colocado no nó. O runtime ativa o contentor e define o limite da CPU para um núcleo. O contentor não poderá utilizar mais do que um núcleo.

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

Neste momento, a soma dos pedidos é igual à capacidade do nó. A CRM não colocará mais contentores ou processos de serviço com pedidos de CPU neste nó. No nó, um processo e um contentor estão em execução com um núcleo cada um e não serão suportados entre si para a CPU.

Vamos agora rever o nosso exemplo com uma especificação RequestsAndLimits . Desta vez, o pacote de serviço baseado em contentor especifica um pedido de um núcleo de CPU e um limite de dois núcleos de CPU. O pacote de serviço baseado no processo especifica um pedido e um limite de um núcleo de CPU.

1. Primeiro, o pacote de serviço baseado em contentor é colocado no nó. O runtime ativa o contentor e define o limite da CPU para dois núcleos. O contentor não poderá utilizar mais do que dois núcleos.
2. Em seguida, o pacote de serviço baseado no processo é colocado no nó. O runtime ativa o processo de serviço e define o respetivo limite de CPU para um núcleo.

Neste momento, a soma dos pedidos de CPU dos pacotes de serviço que são colocados no nó é igual à capacidade da CPU do nó. A CRM não colocará mais contentores ou processos de serviço com pedidos de CPU neste nó. No entanto, no nó, a soma dos limites (dois núcleos para o contentor + um núcleo para o processo) excede a capacidade de dois núcleos. Se o contentor e o processo rebentarem ao mesmo tempo, existe a possibilidade de contenção para o recurso da CPU. Essa contenção será gerida pelo SO subjacente para a plataforma. Para este exemplo, o contentor pode explodir até dois núcleos de CPU, o que resulta na não garantia do pedido do processo de um núcleo da CPU.

Nota

Conforme ilustrado no exemplo anterior, os valores de pedido para CPU e memória não levam à reserva de recursos num nó. Estes valores representam o consumo de recursos que o Cluster Resource Manager considera ao tomar decisões de colocação. Os valores de limite representam os limites de recursos reais aplicados quando um processo ou um contentor é ativado num nó.

Existem algumas situações em que pode haver contenção para a CPU. Nestas situações, o processo e o contentor do nosso exemplo podem ter o problema de vizinho ruidoso:

• Mixing governed and non-governed services and containers: If a user creates a service without any resource governance specified, the runtime see it as consuming no resources, and can place it on the node in our example. Neste caso, este novo processo consome efetivamente alguma CPU em detrimento dos serviços que já estão em execução no nó. Existem duas soluções para este problema. Não misture serviços regidos e não regidos no mesmo cluster ou utilize restrições de colocação para que estes 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 de SO): Nesta situação, o processo fora do Service Fabric também defende a CPU com serviços existentes. A solução para este problema é configurar corretamente as capacidades dos nós para ter em conta a sobrecarga do SO, conforme mostrado na secção seguinte.

• Quando os pedidos não são iguais a limites: conforme descrito no exemplo RequestsAndLimits anteriormente, os pedidos não levam à reserva de recursos num nó. Quando um serviço com limites superiores aos pedidos é colocado num nó, pode consumir recursos (se disponível) até aos limites. Nesses casos, outros serviços no nó poderão não conseguir consumir recursos até aos respetivos valores de pedido.

Configuração do cluster para ativar a governação de recursos

Quando um nó inicia e associa o 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 na memória intermédia para o sistema operativo e para outros processos que possam estar em execução no nó, o Service Fabric utiliza apenas 80% dos recursos disponíveis no nó. Esta percentagem é configurável e pode ser alterada no manifesto do cluster.

Eis um exemplo de como instruir o Service Fabric a utilizar 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ós para CPU e memória é a configuração recomendada (a deteção automática está ativada por predefinição). No entanto, se precisar de uma configuração manual completa das capacidades dos nós, pode configurá-las por tipo de nó com o mecanismo para descrever os nós no cluster. Eis 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á ativada e as capacidades dos nós são definidas manualmente no manifesto do cluster, o Service Fabric verifica se o nó tem recursos suficientes para suportar a capacidade que o utilizador definiu:

• Se as capacidades dos nós definidas no manifesto forem inferiores ou iguais aos recursos disponíveis no nó, o Service Fabric utiliza as capacidades especificadas no manifesto.

• Se as capacidades dos nós definidas no manifesto forem superiores aos recursos disponíveis, o Service Fabric utiliza os recursos disponíveis como capacidades de nó.

A deteção automática de recursos disponíveis pode ser desativada se não for necessária. Para a desativar, altere a seguinte definição:

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

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

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

Importante

A partir da versão 7.0 do Service Fabric, atualizámos a regra de como as capacidades dos recursos de nós são calculadas nos casos em que o utilizador fornece manualmente os valores para capacidades de recursos de nós. Vamos considerar o seguinte cenário:

• Existe um total de 10 núcleos de CPU no nó
• O SF está configurado para utilizar 80% do total de recursos para os serviços de utilizador (predefinição), o que deixa uma memória intermédia de 20% para os outros serviços em execução no nó (incl. Serviços de sistema do Service Fabric)
• O utilizador decide substituir manualmente a capacidade do recurso do nó para a métrica dos núcleos da CPU e define-a como 5 núcleos

Alterámos a regra sobre a forma como a capacidade disponível para os serviços de utilizador do Service Fabric é calculada da seguinte forma:

• Antes do Service Fabric 7.0, a capacidade disponível para serviços de utilizador seria calculada para 5 núcleos (a memória intermédia de capacidade de 20% é ignorada)
• A partir do Service Fabric 7.0, a capacidade disponível para serviços de utilizador seria calculada para 4 núcleos (a memória intermédia de capacidade de 20% não é ignorada)

Especificar governação de recursos

Os pedidos e limites de governação de recursos são especificados no manifesto da aplicação (secção ServiceManifestImport). Vejamos alguns exemplos:

Exemplo 1: RequestsOnly specification

<?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 é utilizado para especificar um pedido de 1 núcleo de CPU para ServicePackageA. Uma vez que o limite da CPU (CpuCoresLimit atributo) não é especificado, o Service Fabric também utiliza o valor de pedido especificado de 1 núcleo como o limite da CPU para o pacote de serviço.

O ServicePackageA só será colocado num nó onde a capacidade restante da CPU após subtrair a soma dos pedidos de CPU de todos os pacotes de serviço colocados nesse nó seja 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 é utilizada para calcular os limites da CPU para os pacotes de código individuais. Assim, o CodeA1 será limitado a dois terços de um núcleo e 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 divide igualmente o limite da CPU entre eles.

Embora cpuShares especificado para pacotes de código representem a sua proporção relativa do limite geral da 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 é utilizado para especificar pedidos de memória de 1024 MB para CodeA1 e CodeA2. Uma vez que o limite de memória (MemoryInMBLimit atributo) não é especificado, o Service Fabric também utiliza os valores de pedido especificados como limites para os pacotes de código. O pedido de memória (e limite) para o pacote de serviço é calculado como a soma dos valores de pedido de memória (e limite) dos respetivos pacotes de código constituintes. Assim, para o ServicePackageA, o pedido de memória e o limite são calculados como 2048 MB.

O ServicePackageA só será colocado num nó onde a capacidade de memória restante após subtrair a soma dos pedidos de memória de todos os pacotes de serviço colocados nesse nó seja superior 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 (contentores ou processos) não poderão alocar mais memória do que este limite e tentar fazê-lo resultará em exceções fora da 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 utiliza CpuCoresLimit e MemoryInMBLimit atributos, que só estão disponíveis nas versões SF 7.2 e posterior. O atributo CpuCoresLimit é utilizado para especificar um limite de CPU de 1 núcleo para ServicePackageA. Uma vez que o pedido da CPU (CpuCores atributo) não é especificado, considera-se que é 0. MemoryInMBLimit o atributo é utilizado para especificar limites de memória de 1024 MB para CodeA1 e CodeA2 e, uma vez que os pedidos (MemoryInMB atributo) não são especificados, são considerados 0. Assim, o pedido de memória e o limite do ServicePackageA são calculados como 0 e 2048, respetivamente. Uma vez que os pedidos de CPU e de memória para ServicePackageA são 0, não apresenta nenhuma carga para a CRM considerar para colocação, para as servicefabric:/_CpuCores métricas e servicefabric:/_MemoryInMB . Por conseguinte, do ponto de vista da governação de recursos, o ServicePackageA pode ser colocado em qualquer nó , independentemente da capacidade restante. Semelhante ao exemplo 1, no nó, CodeA1 estará limitado a dois terços de um núcleo e 1024 MB de memória e 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 pedidos e limites para CPU e memória. O ServicePackageA tem pedidos de CPU e memória de 1 núcleo e 3072 (1024 + 2048) MB, respetivamente. Só pode ser colocado num nó que tenha, pelo menos, 1 núcleo (e 3072 MB) de capacidade restante após subtrair a soma de todos os pedidos de CPU (e memória) de todos os pacotes de serviço que são colocados no nó a partir da capacidade total da CPU (e memória) do nó. No nó, CodeA1 estará limitado a dois terços de 2 núcleos e 3072 MB de memória, enquanto CodeA2 será limitado a um terço de 2 núcleos e 4096 MB de memória.

Utilizar parâmetros de aplicação

Ao especificar as definições de governação de recursos, é possível utilizar parâmetros de aplicação para gerir várias configurações de aplicações. O exemplo seguinte mostra a utilização dos parâmetros da aplicação:

<?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 predefinidos 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 predefinidos com ficheiros de parâmetros da aplicação. Neste exemplo, um ficheiro de parâmetros pode ser utilizado para testar a aplicação localmente, onde 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>

Importante

A especificação da governação de recursos com parâmetros de aplicação está disponível a partir da versão 6.1 do Service Fabric.

Quando os parâmetros da aplicação são utilizados para especificar a governação de recursos, o Service Fabric não pode ser reduzido para uma versão anterior à versão 6.1.

Impor os limites de recursos para serviços de utilizador

Embora a aplicação da governação de recursos aos seus serviços do Service Fabric garanta que esses serviços regidos por recursos não podem exceder a quota de recursos, muitos utilizadores ainda precisam de executar alguns dos seus serviços do Service Fabric no modo desgovernado. Ao utilizar serviços não governamentais do Service Fabric, é possível deparar-se com situações em que os serviços não governamentais "em fuga" consomem todos os recursos disponíveis nos nós do Service Fabric, o que pode levar a problemas graves como:

• Falta de recursos de outros serviços em execução nos nós (incluindo serviços de sistema do Service Fabric)
• Nós que acabam em mau estado de funcionamento
• APIs de gestão de clusters do Service Fabric sem resposta

Para evitar que estas situações ocorram, o Service Fabric permite-lhe impor os limites de recursos para todos os serviços de utilizador do Service Fabric em execução no nó (regidos e não governados) para garantir que os serviços de utilizador nunca utilizarão mais do que a quantidade especificada de recursos. Isto é conseguido ao definir o valor para a configuração EnforceUserServiceMetricCapacities na secção PlacementAndLoadBalancing do ClusterManifest como verdadeiro. Esta definição está desativada por predefinição.

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

Observações adicionais:

• A imposição do limite de recursos aplica-se apenas às servicefabric:/_CpuCores métricas de recursos e servicefabric:/_MemoryInMB
• A imposição do limite de recursos só funciona se as capacidades dos nós das métricas de recursos estiverem disponíveis para o Service Fabric, seja através do mecanismo de deteção automática ou através de utilizadores que especifiquem manualmente as capacidades dos nós (conforme explicado na secção Configuração do Cluster para ativar a governação de recursos ). Se as capacidades dos nós não estiverem configuradas, não é possível utilizar a capacidade de imposição do limite de recursos, uma vez que o Service Fabric não sabe quantos recursos reservar para os serviços de utilizador. O Service Fabric emitirá um aviso de estado de funcionamento se "EnforceUserServiceMetricCapacities" for verdadeiro, mas as capacidades dos nós não estiverem configuradas.

Outros recursos para contentores

Além da CPU e da memória, é possível especificar outros limites de recursos para contentores. Estes limites são especificados ao nível do pacote de código e são aplicados quando o contentor é iniciado. Ao contrário da CPU e da memória, o Cluster Resource Manager não tem conhecimento destes recursos e não faz quaisquer verificações de capacidade ou balanceamento de carga para os mesmos.

• MemorySwapInMB: a quantidade total de memória de troca que pode ser utilizada, em MB. Tem de ser um número inteiro positivo.
• MemoryReservationInMB: o limite suave (em MB) para a governação da memória que é imposto apenas quando a contenção da memória é detetada no nó. Tem de ser um número inteiro positivo.
• CpuPercent: percentagem utilizável de CPUs disponíveis (apenas windows). Tem de ser um número inteiro positivo. Não é possível utilizar com CpuShares, CpuCores ou CpuCoresLimit.
• CpuShares: peso relativo da CPU. Tem de ser um número inteiro positivo. Não é possível utilizar com CpuPercent, CpuCores ou CpuCoresLimit.
• MaximumIOps: taxa máxima de E/S (leitura e escrita) em termos de IOps que podem ser utilizados. Tem de ser um número inteiro positivo.
• MaximumIOBandwidth: a E/S máxima (bytes por segundo) que pode ser utilizada (leitura e escrita). Tem de ser um número inteiro positivo.
• BlockIOWeight: bloquear o peso de E/S em relação a outros pacotes de código. Tem de ser um número inteiro positivo entre 10 e 1000.
• DiskQuotaInMB: quota de disco para contentores. Tem de ser um número inteiro positivo.
• KernelMemoryInMB: limites de memória de kernel em bytes. Tem de ser um número inteiro positivo. Tenha em atenção que é específico do Linux e o Docker no Windows irá efetuar um erro se estiver definido.
• ShmSizeInMB: tamanho de /dev/shm em bytes. Se omitido, o sistema utiliza 64 MB. Tem de ser um número inteiro positivo. Tenha em atenção que este é específico do Linux, no entanto, o Docker só irá ignorar (e não eliminar erros) se for especificado.

Estes recursos podem ser combinados com a CPU e a memória. Eis um exemplo de como especificar recursos adicionais para contentores:

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

Passos seguintes

• Para saber mais sobre o Cluster Resource Manager, leia Introdução ao gestor de recursos do cluster do Service Fabric.
• Para saber mais sobre o modelo de aplicação, os pacotes de serviços e os pacotes de código e como as réplicas são mapeados para eles, leia Modelar uma aplicação no Service Fabric.