Governance delle risorse

Quando si eseguono più servizi nello stesso nodo o nello stesso cluster, è possibile che un servizio possa utilizzare più risorse, con la fame di altri servizi nel processo. Questo problema prende il nome di "noisy neighbor effect". Azure Service Fabric consente allo sviluppatore di controllare questo comportamento specificando richieste e limiti per servizio per limitare l'utilizzo delle risorse.

Prima di procedere con questo articolo, è consigliabile acquisire familiarità con il modello di applicazione di Service Fabric e il modello di hosting di Service Fabric.

Metriche di governance delle risorse

In Service Fabric la governance delle risorse è supportata in base al pacchetto servizio. Le risorse assegnate al pacchetto servizio possono essere ulteriormente divise tra pacchetti di codice. Service Fabric supporta la governance della CPU e della memoria per ogni pacchetto di servizio, con due metriche predefinite:

• CPU (nome servicefabric:/_CpuCoresmetrica): core logico disponibile nel computer host. Tutti i core in tutti i nodi hanno lo stesso peso.

• Memoria (nome servicefabric:/_MemoryInMBmetrica): la memoria viene espressa in megabyte ed è mappata alla memoria fisica disponibile nel computer.

Per queste due metriche, Cluster Resource Manager (CRM) tiene traccia della capacità totale del cluster, del carico in ogni nodo del cluster e delle risorse rimanenti nel cluster. Queste due metriche sono equivalenti a qualsiasi altra metrica utente o personalizzata.

Nota

I nomi delle metriche personalizzati non devono essere uno di questi due nomi di metrica perché determineranno un comportamento non definito.

Possono essere usate tutte le funzionalità esistenti:

• Il cluster può essere bilanciato in base a queste due metriche (comportamento predefinito).
• Il cluster può essere deframmentato in base a queste due metriche.
• Quando si descrive un cluster, è possibile impostare il buffer di capacità per queste due metriche.

Nota

La creazione di report di carico dinamico non è supportata per queste metriche; i caricamenti per queste metriche vengono definiti in fase di creazione.

Meccanismi di governance delle risorse

A partire dalla versione 7.2, il runtime di Service Fabric supporta la specifica di richieste e limiti per le risorse di CPU e memoria.

Nota

Le versioni di runtime di Service Fabric precedenti alla 7.2 supportano solo un modello in cui un singolo valore funge sia da richiesta che dal limite per una determinata risorsa (CPU o memoria). Questa operazione è descritta come specifica RequestsOnly in questo documento.

• Richieste: I valori delle richieste di CPU e memoria rappresentano i carichi usati dal cluster Resource Manager (CRM) per le servicefabric:/_CpuCores metriche e servicefabric:/_MemoryInMB . In altre parole, CRM considera l'utilizzo delle risorse di un servizio come uguale ai valori della richiesta e usa questi valori durante le decisioni di posizionamento.

• Limiti: I valori limite cpu e memoria rappresentano i limiti effettivi delle risorse applicati quando un processo o un contenitore viene attivato in un nodo.

Service Fabric consente RequestsOnly, LimitsOnly ed entrambe le specifiche RequestsAndLimits per CPU e memoria.

• Quando viene usata la specifica RequestsOnly, Service Fabric usa anche i valori della richiesta come limiti.
• Quando viene usata la specifica LimitsOnly, Service Fabric considera i valori della richiesta pari a 0.
• Quando viene usata la specifica RequestsAndLimits, i valori limite devono essere maggiori o uguali ai valori della richiesta.

Per comprendere meglio il meccanismo di governance delle risorse, si esamini uno scenario di posizionamento di esempio con una specifica RequestsOnly per la risorsa CPU (il meccanismo per la governance della memoria è equivalente). Si consideri un nodo con due core CPU e due pacchetti di servizio che verranno inseriti su di esso. Il primo pacchetto del servizio da inserire è composto da un solo pacchetto di codice contenitore e specifica solo una richiesta di un core CPU. Il secondo pacchetto di servizio da inserire è costituito da un solo pacchetto di codice basato su processo e specifica anche una richiesta di un core CPU. Poiché entrambi i pacchetti di servizio hanno una specifica RequestsOnly, i relativi valori limite vengono impostati su valori di richiesta.

1. Innanzitutto il pacchetto del servizio basato su contenitore che richiede un core CPU viene inserito nel nodo. Il runtime attiva il contenitore e imposta il limite di CPU su un core. Il contenitore non potrà usare più di un core.

2. Successivamente, il pacchetto del servizio basato su processo che richiede un core CPU viene inserito nel nodo. Il runtime attiva il processo del servizio e imposta il limite di CPU su un core.

A questo punto, la somma delle richieste è uguale alla capacità del nodo. CRM non inserisce più contenitori o processi di servizio con richieste di CPU in questo nodo. Nel nodo, un processo e un contenitore vengono eseguiti con un core ciascuno e non si confrontarono tra loro per la CPU.

Si esamini ora l'esempio con una specifica RequestsAndLimits . Questa volta il pacchetto del servizio basato su contenitore specifica una richiesta di un core CPU e un limite di due core CPU. Il pacchetto del servizio basato su processo specifica sia una richiesta che un limite di un core CPU.

1. Innanzitutto il pacchetto del servizio basato su contenitore viene inserito nel nodo. Il runtime attiva il contenitore e imposta il limite di CPU su due core. Il contenitore non sarà in grado di usare più di due core.
2. Successivamente, il pacchetto del servizio basato sul processo viene inserito nel nodo. Il runtime attiva il processo del servizio e imposta il limite di CPU su un core.

A questo punto, la somma delle richieste CPU dei pacchetti di servizio inseriti nel nodo è uguale alla capacità della CPU del nodo. CRM non inserisce più contenitori o processi di servizio con richieste di CPU in questo nodo. Tuttavia, nel nodo la somma dei limiti (due core per il contenitore + un core per il processo) supera la capacità di due core. Se il contenitore e il processo scoppiano contemporaneamente, è possibile contesa per la risorsa CPU. Tale contesa verrà gestita dal sistema operativo sottostante per la piattaforma. Per questo esempio, il contenitore potrebbe scoppiare fino a due core CPU, con conseguente mancata garanzia della richiesta del processo di un core CPU.

Nota

Come illustrato nell'esempio precedente, i valori delle richieste per CPU e memoria non comportano la prenotazione di risorse in un nodo. Questi valori rappresentano l'utilizzo delle risorse che il cluster Resource Manager prende in considerazione durante le decisioni di posizionamento. I valori limite rappresentano i limiti effettivi delle risorse applicati quando un processo o un contenitore viene attivato in un nodo.

Esistono alcune situazioni in cui potrebbe esserci contesa per la CPU. In queste situazioni, il processo e il contenitore dell'esempio potrebbero riscontrare il problema del vicino rumoroso:

• Uso combinato di servizi e contenitori regolamentati e non regolamentati: se un utente crea un servizio senza specificare la governance delle risorse, il runtime ritiene che non consumi risorse e può inserirlo nel nodo dell'esempio precedente. In questo caso, il nuovo processo consuma CPU a spese dei servizi già in esecuzione sul nodo. Esistono due soluzioni a questo problema. Evitare l'uso combinato di servizi regolamentati e non regolamentati nello stesso cluster oppure usare vincoli di selezione host in modo che questi due tipi di servizi non vengano inseriti nello stesso set di nodi.

• Quando un altro processo viene avviato nel nodo, al di fuori di Service Fabric (ad esempio, un servizio del sistema operativo): in questa situazione, anche il processo esterno a Service Fabric si contenderà la CPU con i servizi esistenti. Per risolvere il problema, impostare correttamente le capacità del nodo per tenere conto del sovraccarico del sistema operativo, come descritto nella sezione seguente.

• Quando le richieste non sono uguali ai limiti: come descritto nell'esempio RequestsAndLimits precedente, le richieste non comportano la prenotazione di risorse in un nodo. Quando un servizio con limiti maggiori di richieste viene inserito in un nodo, può utilizzare risorse (se disponibili) fino ai limiti. In questi casi, altri servizi nel nodo potrebbero non essere in grado di utilizzare risorse fino ai valori della richiesta.

Configurazione del cluster per l'abilitazione della governance delle risorse

Quando un nodo viene avviato e aggiunto al cluster, Service Fabric rileva la quantità di memoria disponibile e il numero di core disponibili e quindi imposta le capacità del nodo per le due risorse.

Per lasciare spazio buffer per il sistema operativo e per altri processi che potrebbero essere in esecuzione nel nodo, Service Fabric usa solo l'80% delle risorse disponibili nel nodo. Questa percentuale è configurabile e può essere modificata nel manifesto del cluster.

Di seguito è fornito un esempio di come impostare Service Fabric per usare il 50% della CPU disponibile e il 70% della memoria disponibile:

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

Per la maggior parte dei clienti e degli scenari, il rilevamento automatico delle capacità dei nodi per CPU e memoria è la configurazione consigliata (il rilevamento automatico è attivato per impostazione predefinita). Tuttavia, se è necessaria la configurazione manuale completa delle capacità dei nodi, è possibile configurarle per ogni tipo di nodo usando il meccanismo per descrivere i nodi nel cluster. Ecco un esempio di come configurare il tipo di nodo con quattro core e 2 GB di memoria:

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

Se è abilitato il rilevamento automatico delle risorse disponibili e le capacità del nodo sono definite manualmente nel manifesto del cluster, Service Fabric controlla che il nodo abbia risorse sufficienti per soddisfare la capacità definita dall'utente:

• Se le capacità del nodo definite nel manifesto sono inferiori o uguali alle risorse disponibili nel nodo, Service Fabric usa le capacità specificate nel manifesto.

• Se le capacità del nodo definite nel manifesto sono superiori alle risorse disponibili, Service Fabric usa le risorse disponibili come capacità del nodo.

Se non è necessario, è possibile disattivare il rilevamento automatico delle risorse disponibili. Per disattivarlo, modificare l'impostazione seguente:

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

Per ottenere prestazioni ottimali, nel manifesto del cluster è necessario attivare anche l'impostazione seguente:

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

Importante

A partire dalla versione 7.0 di Service Fabric, è stata aggiornata la regola per il modo in cui le capacità delle risorse del nodo vengono calcolate nei casi in cui l'utente fornisce manualmente i valori per le capacità delle risorse del nodo. Si consideri lo scenario seguente:

• Nel nodo sono presenti un totale di 10 core CPU
• SF è configurato per l'uso dell'80% delle risorse totali per i servizi utente (impostazione predefinita), che lascia un buffer del 20% per gli altri servizi in esecuzione nel nodo (inclusi i servizi di sistema di Service Fabric)
• L'utente decide di eseguire manualmente l'override della capacità delle risorse del nodo per la metrica dei core CPU e impostarla su 5 core

È stata modificata la regola sulla modalità di calcolo della capacità disponibile per i servizi utente di Service Fabric nel modo seguente:

• Prima di Service Fabric 7.0, la capacità disponibile per i servizi utente verrebbe calcolata a 5 core (il buffer di capacità del 20% viene ignorato)
• A partire da Service Fabric 7.0, la capacità disponibile per i servizi utente verrebbe calcolata a 4 core (il buffer della capacità del 20% non viene ignorato)

Specificare la governance delle risorse

Le richieste e i limiti di governance delle risorse vengono specificati nel manifesto dell'applicazione (sezione ServiceManifestImport). Di seguito vengono forniti alcuni esempi:

Esempio 1: Specifica 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>

In questo esempio, l'attributo CpuCores viene usato per specificare una richiesta di 1 core CPU per ServicePackageA. Poiché il limite della CPU (CpuCoresLimit attributo) non è specificato, Service Fabric usa anche il valore della richiesta specificato pari a 1 core come limite di CPU per il pacchetto del servizio.

ServicePackageA verrà inserito in un nodo in cui la capacità CPU rimanente viene sottratta dopo aver sottratto la somma delle richieste CPU di tutti i pacchetti di servizio inseriti in tale nodo è maggiore o uguale a 1 core. Nel nodo il pacchetto del servizio sarà limitato a un core. Il pacchetto del servizio contiene due pacchetti di codice (CodeA1 e CodeA2) e entrambi specificano l'attributo CpuShares . La proporzione di CpuShares 512:256 viene usata per calcolare i limiti della CPU per i singoli pacchetti di codice. Di conseguenza, CodeA1 sarà limitato a due terzi di un core e CodeA2 sarà limitato a un terzo di un core. Se CpuShares non viene specificato per tutti i pacchetti di codice, Service Fabric divide il limite di CPU equamente tra di essi.

Mentre CpuShares specificato per i pacchetti di codice rappresentano la percentuale relativa del limite complessivo della CPU del pacchetto del servizio, i valori di memoria per i pacchetti di codice vengono specificati in termini assoluti. In questo esempio, l'attributo MemoryInMB viene usato per specificare le richieste di memoria di 1024 MB per CodeA1 e CodeA2. Poiché il limite di memoria (MemoryInMBLimit attributo) non è specificato, Service Fabric usa anche i valori di richiesta specificati come limiti per i pacchetti di codice. La richiesta di memoria (e il limite) per il pacchetto del servizio viene calcolata come somma dei valori di richiesta di memoria (e limite) dei pacchetti di codice costitutivi. Pertanto, per ServicePackageA, la richiesta di memoria e il limite vengono calcolati come 2048 MB.

ServicePackageA verrà posizionato solo in un nodo in cui la capacità di memoria rimanente viene sottratta dopo aver sottratto la somma delle richieste di memoria di tutti i pacchetti di servizio inseriti in tale nodo è maggiore o uguale a 2048 MB. Nel nodo, entrambi i pacchetti di codice saranno limitati a 1024 MB di memoria ciascuno. I pacchetti di codice (contenitori o processi) non saranno in grado di allocare più memoria di questo limite e il tentativo di eseguire questa operazione comporterà eccezioni di memoria insufficiente.

Esempio 2: Specifica 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>

In questo esempio vengono CpuCoresLimit usati gli attributi e MemoryInMBLimit , disponibili solo nelle versioni SF 7.2 e successive. L'attributo CpuCoresLimit viene usato per specificare un limite di CPU di 1 core per ServicePackageA. Poiché la richiesta cpu (CpuCores attributo) non è specificata, viene considerata 0. MemoryInMBLimit l'attributo viene usato per specificare i limiti di memoria di 1024 MB per CodeA1 e CodeA2 e poiché le richieste (MemoryInMB attributo) non vengono specificate, vengono considerate 0. La richiesta di memoria e il limite per ServicePackageA vengono calcolati rispettivamente come 0 e 2048. Poiché sia le richieste di CPU che di memoria per ServicePackageA sono 0, non presenta alcun carico che CRM consideri per il posizionamento, per le servicefabric:/_CpuCores metriche e servicefabric:/_MemoryInMB . Pertanto, dal punto di vista della governance delle risorse, ServicePackageA può essere inserito in qualsiasi nodo indipendentemente dalla capacità rimanente. Analogamente all'esempio 1, nel nodo CodeA1 sarà limitato a due terzi di un core e 1024 MB di memoria e CodeA2 sarà limitato a un terzo di un core e 1024 MB di memoria.

Esempio 3: Specifica 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>

Basandosi sui primi due esempi, questo esempio illustra la specifica di richieste e limiti per CPU e memoria. ServicePackageA ha richieste di CPU e memoria di 1 core e 3072 (1024 + 2048) MB rispettivamente. Può essere posizionato solo in un nodo con almeno 1 core (e 3072 MB) di capacità lasciata dopo aver sottratto la somma di tutte le richieste di CPU (e memoria) di tutti i pacchetti di servizio inseriti nel nodo dalla capacità totale della CPU (e della memoria) del nodo. Nel nodo CodeA1 sarà limitato a due terzi di 2 core e 3072 MB di memoria, mentre CodeA2 sarà limitato a un terzo di 2 core e 4096 MB di memoria.

Uso dei parametri di applicazione

Quando si specificano le impostazioni di governance delle risorse, è possibile usare i parametri dell'applicazione per gestire più configurazioni di app. L'esempio seguente illustra l'uso dei parametri di applicazione:

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

In questo esempio sono impostati valori di parametro predefiniti per l'ambiente di produzione, dove ogni pacchetto del servizio ottiene 4 core e 2 GB di memoria. È possibile modificare i valori predefiniti con i file di parametri di applicazione. Nell'esempio seguente un solo file di parametri può essere usato per il test dell'applicazione in locale, dove ottiene una minore quantità di risorse rispetto all'ambiente di produzione:

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

È possibile usare i parametri di applicazione per definire la governance delle risorse a partire dalla versione 6.1 di Service Fabric.

Se per definire la governance delle risorse si usano parametri di applicazione, non è possibile eseguire il downgrade di Service Fabric a una versione precedente la 6.1.

Applicazione dei limiti delle risorse per i servizi utente

Applicando la governance delle risorse ai servizi di Service Fabric si garantisce che tali servizi regolamentati dalle risorse non possano superare la quota di risorse, molti utenti devono comunque eseguire alcuni dei servizi di Service Fabric in modalità non governativa. Quando si usano servizi di Service Fabric non gestiti, è possibile verificarsi in situazioni in cui i servizi non gestiti "in esecuzione" utilizzano tutte le risorse disponibili nei nodi di Service Fabric, che possono causare problemi gravi come:

• Fame di risorse di altri servizi in esecuzione nei nodi (inclusi i servizi di sistema di Service Fabric)
• Nodi che terminano in uno stato non integro
• API di gestione del cluster di Service Fabric che non rispondono

Per evitare che si verifichino queste situazioni, Service Fabric consente di applicare i limiti delle risorse per tutti i servizi utente di Service Fabric in esecuzione nel nodo (regolati e non gestiti) per garantire che i servizi utente non usino mai più della quantità di risorse specificata. A tale scopo, impostare il valore per la configurazione EnforceUserServiceMetricCapacities nella sezione PlacementAndLoadBalancing di ClusterManifest su true. Questa impostazione è disattivata per impostazione predefinita.

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

Osservazioni aggiuntive:

• L'applicazione del limite di risorse si applica solo alle metriche delle servicefabric:/_CpuCores risorse e servicefabric:/_MemoryInMB
• L'imposizione del limite delle risorse funziona solo se le capacità dei nodi per le metriche delle risorse sono disponibili per Service Fabric, tramite meccanismo di rilevamento automatico o tramite utenti che specificano manualmente le capacità del nodo (come illustrato nella sezione Configurazione del cluster per abilitare la governance delle risorse ). Se le capacità dei nodi non sono configurate, non è possibile usare la funzionalità di imposizione del limite di risorse perché Service Fabric non è in grado di conoscere la quantità di risorse da riservare per i servizi utente. Service Fabric genera un avviso di integrità se "EnforceUserServiceMetricCapacities" è true, ma le capacità del nodo non sono configurate.

Altre risorse per i contenitori

Oltre alla CPU e alla memoria, è possibile specificare altri limiti di risorse per i contenitori. Questi limiti sono specificati a livello di pacchetto di codice e vengono applicati quando il contenitore viene avviato. A differenza di CPU e memoria, Cluster Resource Manager non riconosce queste risorse e non esegue verifiche della capacità o il bilanciamento del carico.

• MemorySwapInMB: quantità totale di memoria di scambio che può essere usata, in MB. Deve essere un intero positivo.
• MemoryReservationInMB: limite flessibile (in MB) per la governance della memoria applicata solo quando viene rilevata contesa di memoria nel nodo. Deve essere un intero positivo.
• CpuPercent: percentuale utilizzabile di CPU disponibili (solo Windows). Deve essere un intero positivo. Non può essere usato con CpuShares, CpuCores o CpuCoresLimit.
• CpuShares: peso relativo della CPU. Deve essere un intero positivo. Non può essere usato con CpuPercent, CpuCore o CpuCoresLimit.
• MaximumIOps: velocità massima di I/O (lettura e scrittura) in termini di operazioni di I/O che possono essere usate. Deve essere un intero positivo.
• MaximumIOBandwidth: numero massimo di operazioni di I/O (byte al secondo) che possono essere usate (lettura e scrittura). Deve essere un intero positivo.
• BlockIOWeight: blocca il peso di I/O rispetto ad altri pacchetti di codice. Deve essere un intero positivo compreso tra 10 e 1000.
• DiskQuotaInMB: quota del disco per i contenitori. Deve essere un intero positivo.
• KernelMemoryInMB: limiti di memoria del kernel in byte. Deve essere un intero positivo. Si noti che questo è specifico di Linux e Docker in Windows genererà un errore se è impostato.
• ShmSizeInMB: dimensioni di /dev/shm in byte. Se il valore viene omesso, il sistema usa 64 MB. Deve essere un intero positivo. Si noti che è specifico di Linux, tuttavia, Docker ignorerà solo (e non genera errori) se specificato.

Queste risorse possono essere usate in combinazione con CPU e memoria. Di seguito è riportato un esempio di come specificare risorse aggiuntive per i contenitori:

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

Passaggi successivi

• Per altre informazioni su Cluster Resource Manager, vedere Introduzione a Cluster Resource Manager di Service Fabric.
• Per altre informazioni sul modello dell'applicazione, i pacchetti servizio e i pacchetti di codice, nonché sul mapping delle repliche a tali elementi, vedere Modellare un'applicazione in Service Fabric.