Governance delle risorse

Quando si eseguono più servizi sullo stesso nodo o cluster, è possibile che uno di essi consumi molte risorse a scapito degli altri servizi del 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 di CPU e memoria per pacchetto servizio con due metriche predefinite:

• CPU (nome della metrica servicefabric:/_CpuCores): core logico disponibile sul computer host. Tutti i core in tutti i nodi hanno lo stesso peso.

• Memoria (nome della metrica servicefabric:/_MemoryInMB): la memoria viene espressa in megabyte ed esegue il mapping alla memoria fisica disponibile nel computer.

Per queste due metriche, Cluster Resource Manager (CRM) rileva la capacità totale del cluster, il carico presente su ciascun nodo e le restanti risorse del 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é comportano 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 sul carico dinamico non è supportata per queste metriche; i relativi carichi vengono definiti al momento della 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 da Cluster Resource Manager (CRM) per le metriche servicefabric:/_CpuCores 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 quando si prende 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 esaminerà 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 è costituito 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. Prima di tutto il pacchetto del servizio basato su contenitori che richiede un core CPU viene inserito nel nodo. Il runtime attiva il contenitore e imposta il limite della 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 contenderanno l'uno con l'altro per la CPU.

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

1. Prima di tutto, il pacchetto del servizio basato su contenitori viene inserito nel nodo . Il runtime attiva il contenitore e imposta il limite di CPU su due core. Il contenitore non potrà usare più di due core.
2. Successivamente, il pacchetto del servizio basato su 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 posizionati 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 esplodono contemporaneamente, è possibile contesa per la risorsa CPU. Tale contesa verrà gestita dal sistema operativo sottostante per la piattaforma. Per questo esempio, il contenitore potrebbe eseguire un burst 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 della richiesta per CPU e memoria non comportano la prenotazione di risorse in un nodo. Questi valori rappresentano l'utilizzo delle risorse che 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, nel processo e nel contenitore dell'esempio potrebbe presentarsi il problema del noisy neighbor:

• 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. Di seguito sono riportate due soluzioni per il 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 in precedenza nell'esempio RequestsAndLimits, le richieste non comportano la prenotazione di risorse in un nodo. Quando un servizio con limiti superiori alle 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 nel buffer per il sistema operativo e per altri processi che potrebbero essere eseguiti 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 una configurazione manuale completa delle capacità dei nodi, è possibile configurarle per ogni tipo di nodo usando il meccanismo per descrivere i nodi nel cluster. Di seguito è riportato 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 da Service Fabric versione 7.0, è 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. Prendi in considerazione lo scenario seguente:

• Nel nodo sono presenti un totale di 10 core CPU
• SF è configurato per l'utilizzo 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 su 5 core (il buffer della capacità del 20% viene ignorato)
• A partire da Service Fabric 7.0, la capacità disponibile per i servizi utente verrebbe calcolata su 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 di CPU ( attributoCpuCoresLimit) non viene 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 solo in un nodo in cui la capacità CPU rimanente dopo aver sottratto la somma delle richieste CPU di tutti i pacchetti di servizio posizionati nel nodo è maggiore o uguale a 1 core. Nel nodo il pacchetto del servizio sarà limitato a un core. Il pacchetto servizio contiene due pacchetti di codice, CodeA1 e CodeA2, che specificano entrambi l’attributo CpuShares. La proporzione di CpuShares 512:256 viene usata per calcolare i limiti di CPU per i singoli pacchetti di codice. Pertanto, 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 CPU parti uguali tra di essi.

Mentre CpuShares specificato per i pacchetti di codice rappresentano la percentuale relativa del limite complessivo della CPU del pacchetto di 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 (attributoMemoryInMBLimit) non viene 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à inserito solo in un nodo in cui la capacità di memoria rimanente 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 pacchetti) non saranno in grado di allocare una quantità di memoria superiore a questo limite. Un'operazione di questo tipo genererà quindi eccezioni di memoria esaurita.

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>

Questo esempio usa gli attributi CpuCoresLimit 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. L’attributo MemoryInMBLimit viene usato per specificare limiti di memoria di 1024 MB per CodeA1 e CodeA2 e poiché le richieste (attributo MemoryInMB) non vengono specificate, vengono considerate 0. La richiesta di memoria e il limite per ServicePackageA vengono quindi calcolati rispettivamente come 0 e 2048. Poiché le richieste di CPU e memoria per ServicePackageA sono 0, non presenta alcun carico per CRM da considerare per il posizionamento, per le metriche servicefabric:/_CpuCores 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 (rispettivamente 1024 + 2048). Può essere inserito 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 posizionati 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 della governance delle risorse, è possibile usare parametri di 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

L'applicazione della governance delle risorse ai servizi di Service Fabric 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 non gestiti utilizzano tutte le risorse disponibili nei nodi di Service Fabric, che possono causare problemi gravi, ad esempio:

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

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à specificata di risorse. 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'imposizione del limite di risorse si applica solo alle metriche delle risorse servicefabric:/_CpuCores 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à del nodo non sono configurate, non è possibile usare la funzionalità di imposizione dei limiti delle 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 i limiti di altre 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 è possibile usare, espressa in MB. Deve essere un intero positivo.
• MemoryReservationInMB: limite flessibile (in MB) per la governance della memoria che viene applicato solo quando si verificano problemi di contesa della memoria sul 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, CpuCore 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 al secondo che possono essere usate. Deve essere un intero positivo.
• MaximumIOBandwidth: valore massimo di I/O (byte al secondo) che può essere usato (lettura e scrittura). Deve essere un intero positivo.
• BlockIOWeight: peso di I/O del blocco rispetto ad altri pacchetto di codice. Deve essere un intero positivo compreso tra 10 e 1000.
• DiskQuotaInMB: quota disco per i contenitori. Deve essere un intero positivo.
• KernelMemoryInMB: limiti di memoria del kernel in byte. Deve essere un intero positivo. Questo valore è specifico di Linux e se impostato in Docker in Windows causa un errore.
• ShmSizeInMB: dimensioni di /dev/shm in byte. Se il valore viene omesso, il sistema usa 64 MB. Deve essere un intero positivo. Questo valore è specifico di Linux; tuttavia, se specificato, Docker ignorerà (e non genererà errori).

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.