Bilanciamento del carico nel cluster di Service Fabric

Cluster Resource Manager di Service Fabric supporta le modifiche al carico dinamico, reagisce all'aggiunta o alla rimozione di nodi o servizi. Corregge anche automaticamente le violazioni dei vincoli ed esegue in modo proattivo il ribilanciamento del cluster. Ma con quale frequenza vengono eseguite queste azioni, e che cosa le attiva?

Esistono tre diverse categorie di lavoro eseguite da Cluster Resource Manager:

• Posizionamento: questa fase riguarda l'inserimento di repliche con stato o istanze senza stato mancanti. Il posizionamento include sia i nuovi servizi sia la gestione di repliche con stato o istanze senza stato non riuscite. In questa fase viene gestita l'eliminazione di istanze e repliche.
• Verifiche dei vincoli: in questa fase vengono controllate e corrette le violazioni dei vincoli (regole) di posizionamento all'interno del sistema. Esempi di regole sono elementi come garantire che i nodi non siano oltre la capacità e che vengano soddisfatti i vincoli di posizionamento di un servizio.
• Bilanciamento: questa fase controlla se il ribilanciamento è necessario in base al livello di bilanciamento desiderato configurato per metriche diverse. In tal caso, viene eseguito il tentativo di trovare una disposizione più bilanciata nel cluster.

Configurazione dei timer di Cluster Resource Manager

Il primo set di controlli intorno al bilanciamento è un set di timer. Questi timer controllano la frequenza con cui Cluster Resource Manager esamina il cluster e intraprende le azioni correttive.

Ognuno dei tipi diversi di correzioni che Cluster Resource Manager può apportare è controllato da un timer diverso che ne determina la frequenza. Quando viene attivato ogni timer, l'attività viene pianificata. Per impostazione predefinita, Resource Manager:

• Analizza lo stato e applica gli aggiornamenti, ad esempio la registrazione di un nodo inattivo, ogni decimo di secondo.
• imposta il flag di controllo di posizionamento ogni secondo
• imposta il flag di controllo del vincolo ogni secondo
• imposta il flag di bilanciamento ogni cinque secondi

Di seguito sono riportati alcuni esempi di configurazione che controllano i timer:

ClusterManifest.xml:

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PLBRefreshGap" Value="0.1" />
            <Parameter Name="MinPlacementInterval" Value="1.0" />
            <Parameter Name="MinConstraintCheckInterval" Value="1.0" />
            <Parameter Name="MinLoadBalancingInterval" Value="5.0" />
        </Section>

mediante ClusterConfig.json per le distribuzioni autonome o Template.json per i cluster ospitati in Azure:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PLBRefreshGap",
          "value": "0.10"
      },
      {
          "name": "MinPlacementInterval",
          "value": "1.0"
      },
      {
          "name": "MinConstraintCheckInterval",
          "value": "1.0"
      },
      {
          "name": "MinLoadBalancingInterval",
          "value": "5.0"
      }
    ]
  }
]

Oggi Cluster Resource Manager esegue solo una di queste azioni alla volta, in sequenza. Questo è il motivo per cui si fa riferimento a questi timer come "intervalli minimi" e le azioni che vengono eseguite quando il timer viene spente come "flag di impostazione". Ad esempio, Cluster Resource Manager si occupa delle richieste di creazione di servizi in sospeso prima di bilanciare il carico del cluster. Come si nota dagli intervalli di tempo predefiniti specificati, Cluster Resource Manager analizza di frequente tutte le attività. In genere, ciò significa che il set di modifiche apportate durante ogni passaggio è piccolo. Piccole modifiche frequenti consentono a Cluster Resource Manager di essere reattivi quando si verificano eventi nel cluster. I timer predefiniti eseguono una sorta di divisione in batch, dato che molti degli eventi dello stesso tipo tendono a verificarsi simultaneamente.

Ad esempio, quando i nodi presentano errori possono procedere con interi domini di errore alla volta. Tutti questi errori vengono acquisiti durante il successivo aggiornamento dopo il PLBRefreshGap. Le correzioni vengono determinate durante il posizionamento seguente del controllo del vincolo, e bilanciamento del carico viene eseguito. Per impostazione predefinita, Cluster Resource Manager non esegue l'analisi delle ore di modifiche nel cluster e tenta di risolvere tutte le modifiche contemporaneamente. Questo potrebbe generare burst di varianza.

Cluster Resource Manager necessita di informazioni aggiuntive per determinare se il cluster è sbilanciato. Per gestire questi aspetti sono disponibili due controlli di configurazione: le soglie di bilanciamento e le soglie di attività.

Soglie di bilanciamento del carico

Una soglia di bilanciamento del carico è il controllo principale per attivare il ribilanciamento. La soglia di bilanciamento del carico per una metrica è espressa con un rapporto. Se il volume di carico sul nodo più carico diviso per il volume di carico sul nodo meno carico supera il BalancingThresholddella metrica, il cluster viene considerato sbilanciato. In tal caso, al successivo controllo di Cluster Resource Manager viene attivato il bilanciamento del carico. Il timer MinLoadBalancingInterval definisce la frequenza dei controlli eseguiti da Cluster Resource Manager se è necessario il ribilanciamento. Controllare non comporta che venga eseguita un'operazione.

Le soglie di bilanciamento del carico sono definite sulla base delle singole metriche nell'ambito della definizione del cluster. Per altre informazioni sulle metriche, vedere l'articolo sulle metriche.

ClusterManifest.xml

    <Section Name="MetricBalancingThresholds">
      <Parameter Name="MetricName1" Value="2"/>
      <Parameter Name="MetricName2" Value="3.5"/>
    </Section>

mediante ClusterConfig.json per le distribuzioni autonome o Template.json per i cluster ospitati in Azure:

"fabricSettings": [
  {
    "name": "MetricBalancingThresholds",
    "parameters": [
      {
          "name": "MetricName1",
          "value": "2"
      },
      {
          "name": "MetricName2",
          "value": "3.5"
      }
    ]
  }
]

In questo esempio ogni servizio usa una unità di una metrica. Nell'esempio in alto il carico massimo su un nodo è cinque e il carico minimo è due. Si supponga che la soglia di bilanciamento del carico per questa metrica sia tre. Dato che il rapporto nel cluster è 5/2 = 2,5 e che tale cifra è inferiore al valore tre della soglia di bilanciamento, il cluster è bilanciato. In tal caso, al successivo controllo di Cluster Resource Manager non viene attivato alcun bilanciamento del carico.

Nell'esempio in basso il carico massimo su un nodo è 10, mentre il carico minimo è due. Il rapporto è quindi pari a cinque. Cinque è superiore alla soglia di bilanciamento del carico designata di tre per tale metrica. Di conseguenza, all'attivazione successiva del timer di bilanciamento del carico verrà pianificato un ribilanciamento. In una situazione come questa parte di carico viene in genere distribuita al nodo 3. Poiché Cluster Resource Manager di Service Fabric non usa un approccio greedy, è anche possibile distribuire un carico al nodo 2.

Il raggiungimento della soglia di bilanciamento non è un obiettivo esplicito. Le soglie di bilanciamento sono semplicemente un trigger. Quando viene eseguito il bilanciamento, Cluster Resource Manager determina quali miglioramenti può apportare, se ve ne sono. Il fatto che venga avviata una ricerca di bilanciamento non significa che vengano spostati degli elementi. A volte il cluster non è bilanciato ma è troppo limitato per essere corretto. In alternativa, i miglioramenti richiedono dei movimenti che sono troppo costosi).

soglie di attività

A volte, sebbene i nodi siano relativamente sbilanciati, la quantità totale di carico nel cluster è bassa. La mancanza di carico può essere dovuta a un calo temporaneo o al fatto che il cluster è nuovo ed è stato avviato da poco. In entrambi i casi non è consigliabile perdere tempo con il bilanciamento del carico del cluster perché i risultati non sarebbero soddisfacenti. Se il carico del cluster è stato bilanciato, si perderebbero risorse di rete e di calcolo per spostamenti che non farebbero grandi differenze. Per evitare movimenti non necessari, è disponibile un altro controllo noto come Soglie di attività. Le soglie di attività consentono di specificare un limite inferiore assoluto per l'attività. Se nessun nodo supera tale soglia, il bilanciamento del carico non viene attivato neanche se viene raggiunta la soglia di bilanciamento.

Si supponga che abbiamo mantenuto la soglia di bilanciamento su tre per questa metrica. Si supponga anche che sia disponibile una Soglia di attività di 1536. Nel primo caso il cluster è sbilanciato in base alla soglia di bilanciamento, ma nessun nodo raggiunge la soglia di attività, quindi non viene eseguita alcuna azione. Nell'esempio inferiore il nodo 1 supera la soglia di attività. Dato che vengono superate sia la soglia di bilanciamento che la soglia di attività per la metrica, viene pianificato un bilanciamento del carico. Ad esempio, si veda il diagramma seguente:

Proprio come le soglie di bilanciamento del carico, le soglie di attività sono definite sulla base di singoli metriche tramite la definizione del cluster:

ClusterManifest.xml

    <Section Name="MetricActivityThresholds">
      <Parameter Name="Memory" Value="1536"/>
    </Section>

mediante ClusterConfig.json per le distribuzioni autonome o Template.json per i cluster ospitati in Azure:

"fabricSettings": [
  {
    "name": "MetricActivityThresholds",
    "parameters": [
      {
          "name": "Memory",
          "value": "1536"
      }
    ]
  }
]

Le soglie di bilanciamento e attività sono entrambe collegate a una metrica specifica. Il bilanciamento viene attivato solo se entrambe le soglie di bilanciamento e soglia di attività vengono superate per la stessa metrica.

Bilanciamento composto dei servizi

Che il cluster sia bilanciato o no è una decisione a livello di cluster. Tuttavia, la correzione viene eseguita spostando singole repliche e istanze del servizio. Questo approccio ha senso, giusto? Uno stack di memoria in un nodo può ricevere contributi da più repliche o istanze. Per correggere lo sbilanciamento potrebbe essere necessario spostare una delle repliche con stato o delle istanze senza stato che usano la metrica sbilanciata.

In alcuni casi però viene spostato un servizio che non era sbilanciato (ricordare la discussione precedente relativa ai pesi locali e globali). Per quale motivo si dovrebbe spostare un servizio quando tutte le metriche di quel servizio sono state bilanciate? Di seguito viene illustrato un esempio:

• Si supponga che siano presenti quattro servizi, Service 1, Service 2, Service 3 e Service 4.
• Il servizio 1 segnala le metriche metrica 1 e metrica 2.
• Il servizio 2 segnala le metriche metrica 2 e metrica 3.
• Il servizio 3 segnala le metriche metrica 3 e metrica 4.
• Il servizio 4 segnala la metrica metrica 99.

Non ci sono quattro servizi indipendenti, ma tre servizi correlati tra loro e uno autonomo.

A causa di questa catena, è possibile che uno squilibrio nelle metriche 1-4 provochi lo spostamento di repliche o istanze appartenenti ai servizi 1-3. Sappiamo anche che uno squilibrio nelle metriche 1, 2 o 3 non può causare spostamenti nel servizio 4. Non ci sarebbe alcun punto perché lo spostamento delle repliche o delle istanze appartenenti al servizio 4 non può fare assolutamente nulla per influire sul saldo delle metriche 1-3.

Cluster Resource Manager determina automaticamente i servizi correlati. Aggiungere, rimuovere o modificare le metriche per i servizi può influire sulle relative relazioni. Ad esempio, tra due esecuzioni di bilanciamento del servizio 2 potrebbe essere stato aggiornato per rimuovere la metrica 2. In questo modo si interrompe la catena tra Il servizio 1 e il servizio 2. Ora, invece di due gruppi di servizi correlati ce ne sono tre:

Bilanciamento di un cluster per tipo di nodo

Come descritto nelle sezioni precedenti, i controlli principali di attivazione del ribilanciamento sono soglie di attività, soglie di bilanciamento e timer. Cluster Resource Manager di Service Fabric offre un controllo più granulare sull'attivazione del ribilanciamento con la specifica dei parametri per tipo di nodo e consente lo spostamento solo sui tipi di nodo sbilanciati. Il vantaggio principale del bilanciamento per ogni tipo di nodo è consentire un miglioramento delle prestazioni sui tipi di nodo che richiedono regole di bilanciamento più rigorose, senza riduzione delle prestazioni in altri tipi di nodo. La funzionalità contiene due parti principali:

• Il rilevamento dello squilibrio viene eseguito per ogni tipo di nodo. Il calcolo globale precedentemente dello squilibrio viene calcolato per ogni tipo di nodo. Se tutti i tipi di nodo sono bilanciati, CRM non attiverà la fase di bilanciamento. In caso contrario, se almeno un tipo di nodo è sbilanciato, è necessaria una fase di bilanciamento.
• Il bilanciamento sposta le repliche solo su tipi di nodo sbilanciati, altri tipi di nodo non sono interessati dalla fase di bilanciamento.

Impatto del bilanciamento per tipo di nodo in un cluster

Durante il bilanciamento di un cluster per tipo di nodo, Cluster Resource Manager di Service Fabric calcola lo stato di squilibrio per ogni tipo di nodo. Se almeno un tipo di nodo è sbilanciato, verrà attivata la fase di bilanciamento. La fase di bilanciamento non sposta le repliche sui tipi di nodo sbilanciate, quando il bilanciamento viene sospeso temporaneamente su questi tipi di nodo (ad esempio, l'intervallo di bilanciamento minimo non è passato dopo una fase di bilanciamento precedente). Il rilevamento di uno stato sbilanciato usa meccanismi comuni già disponibili per il bilanciamento del cluster classico, ma migliora la granularità e la flessibilità della configurazione. I meccanismi usati per il bilanciamento per ogni tipo di nodo per rilevare lo squilibrio sono disponibili nell'elenco seguente:

• Le soglie di bilanciamento delle metriche per tipo di nodo sono valori con un ruolo simile a quello della soglia di bilanciamento definita a livello globale usata nel bilanciamento classico. Il rapporto tra carico minimo e massimo delle metriche viene calcolato per ogni tipo di nodo. Se tale rapporto di un tipo di nodo è superiore alla soglia di bilanciamento definita del tipo di nodo, il tipo di nodo viene contrassegnato come sbilanciato. Per altre informazioni sulla configurazione delle soglie di attività delle metriche per ogni tipo di nodo, vedere la sezione Relativa alle soglie di bilanciamento per ogni tipo di nodo.
• Le soglie di attività delle metriche per tipo di nodo sono valori che hanno un ruolo simile alla soglia di attività definita a livello globale usata nel bilanciamento classico. Il carico massimo delle metriche viene calcolato per ogni tipo di nodo. Se il carico massimo di un tipo di nodo è superiore alla soglia di attività definita per tale tipo di nodo, il tipo di nodo viene contrassegnato come sbilanciato. Per altre informazioni sulla configurazione delle soglie di attività delle metriche per ogni tipo di nodo, vedere la sezione activity-thresholds-per-node-type.
• L'intervallo di bilanciamento minimo per tipo di nodo ha un ruolo simile all'intervallo di bilanciamento minimo definito a livello globale. Per ogni tipo di nodo, Cluster Resource Manager mantiene il timestamp dell'ultimo bilanciamento. Non è stato possibile eseguire due fasi di bilanciamento consecutive in un tipo di nodo entro l'intervallo di bilanciamento minimo definito. Per altre informazioni sulla configurazione dell'intervallo di bilanciamento minimo per tipo di nodo, vedere la sezione intervallo di bilanciamento minimo per ogni tipo di nodo.

Descrivere il bilanciamento per tipo di nodo

Per abilitare il bilanciamento per ogni tipo di nodo, è necessario abilitare il parametro SeparateBalancingStrategyPerNodeType in un manifesto del cluster. Inoltre, è necessario abilitare anche la funzionalità di sottoclustering. Esempio di sezione PlacementAndLoadBalancing del manifesto del cluster per abilitare la funzionalità:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="SeparateBalancingStrategyPerNodeType" Value="true" />
    <Parameter Name="SubclusteringEnabled" Value="true" />
    <Parameter Name="SubclusteringReportingPolicy" Value="1" />
</Section>

ClusterConfig.json per distribuzioni autonome o Template.json per i cluster ospitati in Azure:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "SeparateBalancingStrategyPerNodeType",
          "value": "true"
      },
      {
          "name": "SubclusteringEnabled",
          "value": "true"
      },
      {
          "name": "SubclusteringReportingPolicy",
          "value": "1"
      },
    ]
  }
]

Come descritto nella sezione precedente, è possibile specificare soglie e intervalli per ogni tipo di nodo. Per altre informazioni sull'aggiornamento di un parametro specifico, vedere le sezioni seguenti:

• Soglie di bilanciamento delle metriche per tipo di nodo
• Soglie di attività delle metriche per tipo di nodo
• Intervallo di bilanciamento minimo per tipo di nodo

Soglie di bilanciamento per tipo di nodo

È possibile definire la soglia di bilanciamento delle metriche per ogni tipo di nodo per aumentare la granularità dalla configurazione di bilanciamento. Le soglie di bilanciamento hanno un tipo a virgola mobile, poiché rappresentano la soglia per il rapporto tra valore di carico massimo e minimo all'interno di un determinato tipo di nodo. Le soglie di bilanciamento sono definite nella sezione PlacementAndLoadBalancingOverrides per ogni tipo di nodo:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricBalancingThresholdsPerNodeType>
                <BalancingThreshold Name="Metric1" Value="2.5">
                <BalancingThreshold Name="Metric2" Value="4">
                <BalancingThreshold Name="Metric3" Value="3.25">
            </MetricBalancingThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Se la soglia di bilanciamento per una metrica non è definita per un tipo di nodo, la soglia eredita il valore della soglia di bilanciamento delle metriche definita a livello globale nella sezione PlacementAndLoadBalancing . In caso contrario, se la soglia di bilanciamento per una metrica non è definita né per un tipo di nodo né a livello globale in una sezione PlacementAndLoadBalancing , la soglia avrà il valore predefinito uno.

Soglie di attività per tipo di nodo

È possibile definire la soglia di attività delle metriche per ogni tipo di nodo per aumentare la granularità della configurazione del bilanciamento del carico. Le soglie di attività hanno un tipo integer, poiché rappresentano la soglia per il valore di carico massimo all'interno di un determinato tipo di nodo. Le soglie di attività vengono definite nella sezione PlacementAndLoadBalancingOverrides per ogni tipo di nodo:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MetricActivityThresholdsPerNodeType>
                <ActivityThreshold Name="Metric1" Value="500">
                <ActivityThreshold Name="Metric2" Value="40">
                <ActivityThreshold Name="Metric3" Value="1000">
            </MetricActivityThresholdsPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Se la soglia di attività per una metrica non è definita per un tipo di nodo, threshold eredita il valore dalla soglia di attività della metrica definita a livello globale nella sezione PlacementAndLoadBalancing . In caso contrario, se la soglia di attività per una metrica non è definita né per un tipo di nodo né a livello globale in una sezione PlacementAndLoadBalancing, la soglia avrà il valore predefinito zero.

Intervallo di bilanciamento minimo per tipo di nodo

È possibile definire un intervallo di bilanciamento minimo per ogni tipo di nodo per aumentare la granularità della configurazione di bilanciamento. L'intervallo di bilanciamento minimo ha un tipo integer, poiché rappresenta la quantità minima di tempo che deve trascorrere prima di due round di bilanciamento consecutivi su uno stesso tipo di nodo. L'intervallo di bilanciamento minimo è definito nella sezione PlacementAndLoadBalancingOverrides per ogni tipo di nodo:

<NodeTypes>
    <NodeType Name="NodeType1">
        <PlacementAndLoadBalancingOverrides>
            <MinLoadBalancingIntervalPerNodeType>100</MinLoadBalancingIntervalPerNodeType>
        </PlacementAndLoadBalancingOverrides>
    </NodeType>
</NodeTypes>

Se l'intervallo di bilanciamento minimo non è definito per un tipo di nodo, l'intervallo eredita il valore dall'intervallo di bilanciamento minimo definito a livello globale nella sezione PlacementAndLoadBalancing . In caso contrario, se l'intervallo minimo non è definito né per un tipo di nodo né a livello globale in una sezione PlacementAndLoadBalancing , l'intervallo minimo avrà un valore predefinito pari a zero , che indica che non è necessaria la sospensione tra round di bilanciamento consecutivi.

Esempi

Esempio 1

Si consideri ora un caso in cui un cluster contiene due tipi di nodo, il tipo di nodo A e il tipo di nodo B. Tutti i servizi segnalano una stessa metrica e sono suddivisi tra questi tipi di nodo, quindi le statistiche di caricamento sono diverse per loro. Nell'esempio il tipo di nodo A ha un carico massimo di 300 e minimo 100 e il tipo di nodo B ha un carico massimo di 700 e carico minimo di 500:

Il cliente ha rilevato che i carichi di lavoro di due tipi di nodo hanno esigenze di bilanciamento diverse e hanno deciso di impostare soglie di bilanciamento e attività diverse per ogni tipo di nodo. La soglia di bilanciamento del tipo di nodo A è 2,5 e la soglia di attività è 50. Per il tipo di nodo B, il cliente imposta la soglia di bilanciamento su 1,2 e la soglia di attività su 400.

Durante il rilevamento dello squilibrio per il cluster in questo esempio, entrambi i tipi di nodo violano la soglia di attività. Il carico massimo del tipo di nodo A pari a 300 è superiore alla soglia di attività definita pari a 50. Il carico massimo del tipo di nodo B di 700 è superiore alla soglia di attività definita pari a 400. Il tipo di nodo A viola i criteri di soglia di bilanciamento, poiché il rapporto corrente del carico massimo e minimo è 3 e la soglia di bilanciamento è 2,5. Opposto, il tipo di nodo B non viola i criteri di soglia di bilanciamento, poiché il rapporto corrente del carico massimo e minimo per questo tipo di nodo è 1,2, ma la soglia di bilanciamento è 1,4. Il bilanciamento è necessario solo per le repliche nel tipo di nodo A e l'unico set di repliche idonee per gli spostamenti durante la fase di bilanciamento sono repliche inserite nel tipo di nodo A.

Esempio 2

Si consideri ora un caso in cui un cluster contiene tre tipi di nodo, tipo di nodo A, B e C. Tutti i servizi segnalano una stessa metrica e sono suddivisi tra questi tipi di nodo, quindi le statistiche di caricamento sono diverse per loro. Nell'esempio, il tipo di nodo A ha un carico massimo di 600 e minimo 100, il tipo di nodo B ha un carico massimo di 900 e il carico minimo di 100 e il tipo di nodo C ha un carico massimo di 600 e carico minimo di 300:

Il cliente ha rilevato che i carichi di lavoro di questi tipi di nodo hanno esigenze di bilanciamento diverse e hanno deciso di impostare soglie di bilanciamento e attività diverse per ogni tipo di nodo. La soglia di bilanciamento del tipo di nodo A è 5 e la soglia di attività è 700. Per il tipo di nodo B, il cliente imposta la soglia di bilanciamento su 10 e la soglia di attività su 200. Per il tipo di nodo C, il cliente imposta la soglia di bilanciamento su 2 e la soglia di attività su 300.

Il carico massimo del tipo di nodo A pari a 600 è inferiore alla soglia di attività definita pari a 700, pertanto il tipo di nodo A non verrà bilanciato. Il carico massimo del tipo di nodo B di 900 è superiore alla soglia di attività definita pari a 200. Il tipo di nodo B viola i criteri di soglia delle attività. Il carico massimo del tipo di nodo C di 600 è superiore alla soglia di attività definita pari a 300. Il tipo di nodo C viola i criteri di soglia delle attività. Il tipo di nodo B non viola i criteri di soglia di bilanciamento, poiché il rapporto corrente del carico massimo e minimo per questo tipo di nodo è 9, ma la soglia di bilanciamento è 10. Il tipo di nodo C viola i criteri di soglia di bilanciamento, poiché il rapporto corrente del carico massimo e minimo è 2 e la soglia di bilanciamento è 2. Il bilanciamento è necessario solo per le repliche nel tipo di nodo C e l'unico set di repliche idonee per gli spostamenti durante la fase di bilanciamento sono repliche inserite nel tipo di nodo C.

Passaggi successivi

• Le metriche determinano il modo in cui Cluster Resource Manger di Service Fabric gestisce il consumo e la capacità del cluster. Per altre informazioni sulle metriche e su come configurarle, vedere l'articolo sulle metriche
• Il costo dello spostamento è un modo per segnalare a Cluster Resource Manager che alcuni servizi sono più costosi da spostare rispetto ad altri. Per altre informazioni sui costi di spostamento, vedere l'articolo sui costi di spostamento
• Cluster Resource Manager dispone di diverse limitazioni da configurare per rallentare la varianza del cluster. In genere non sono necessari, ma se sono necessari, è possibile ottenere informazioni su di essi l'articolo sulla limitazione avanzata
• Cluster Resource Manager può riconoscere e gestire il sottoclustering. Il sottoclustering può verificarsi quando si usano vincoli di posizionamento e bilanciamento. Per informazioni su come il sottoclustering può influire sul bilanciamento e su come gestirlo, vedere l'articolo relativo al sottoclustering