Linee guida per il ridimensionamento

  • Articolo

Panoramica delle linee guida per il ridimensionamento

Quando si pianifica la distribuzione dei servizi dati di Azure Arc, pianificare la quantità corretta di:

  • Calcolo
  • Memoria
  • Storage

Queste risorse sono necessarie per:

  • Titolare del trattamento dei dati
  • Istanze gestite SQL
  • Server PostgreSQL

Poiché i servizi dati abilitati per Azure Arc vengono distribuiti in Kubernetes, è possibile aggiungere più capacità al cluster Kubernetes nel tempo tramite nodi di calcolo o archiviazione. Questa guida illustra i requisiti minimi e consiglia le dimensioni per alcuni requisiti comuni.

Requisiti generali di dimensionamento

Nota

Se non si ha familiarità con i concetti di questo articolo, è possibile leggere altre informazioni sulla governance delle risorse Kubernetes e sulla notazione delle dimensioni di Kubernetes.

I numeri di core devono essere un valore intero maggiore o uguale a uno.

Quando si esegue la distribuzione con l'interfaccia della riga di comando di Azure (az), usare una potenza di due numeri per impostare i valori di memoria. In particolare, usare i suffissi:

  • Ki
  • Mi
  • Gi

I valori limite devono essere sempre maggiori del valore della richiesta, se specificato.

I valori limite per i core sono la metrica fatturabile nei server Istanza gestita di SQL e PostgreSQL.

Requisiti minimi di distribuzione

Una distribuzione minima dei servizi dati abilitati per Azure Arc può essere considerata come il controller dati di Azure Arc più un'istanza gestita di SQL più un server PostgreSQL. Per questa configurazione sono necessari almeno 16 GB di RAM e 4 core di capacità disponibile nel cluster Kubernetes. È necessario assicurarsi di avere una dimensione minima del nodo Kubernetes di 8 GB di RAM e 4 core e una somma totale di 16 GB di RAM disponibile in tutti i nodi Kubernetes. Ad esempio, è possibile avere un nodo a 32 GB di RAM e 4 core oppure avere 2 nodi con 16 GB di RAM e 4 core ciascuno.

Per informazioni dettagliate sul dimensionamento dell'archiviazione, vedere l'articolo relativo alla configurazione dell'archiviazione.

Dettagli sul ridimensionamento del titolare del trattamento dei dati

Il controller di dati è una raccolta di pod distribuiti nel cluster Kubernetes per fornire un'API, il servizio controller, il programma di avvio automatico e i database e i dashboard di monitoraggio. Questa tabella descrive i valori predefiniti per le richieste e i limiti di memoria e CPU.

Nome pod Richiesta CPU Richiesta di memoria Limite CPU Limite memoria
bootstrapper 100m 100Mi 200m 200Mi
control 400m 2Gi 1800m 2Gi
controldb 200m 4Gi 800m 6Gi
logsdb 200m 1600Mi 2 1600Mi
logsui 100m 500Mi 2 2Gi
metricsdb 200m 800Mi 400m 2Gi
metricsdc 100m 200Mi 200m 300Mi
metricsui 20m 200Mi 500m 200Mi

metricsdc è un daemonsetoggetto , che viene creato in ognuno dei nodi Kubernetes nel cluster. I numeri nella tabella sono per nodo. Se si imposta allowNodeMetricsCollection = false nel file del profilo di distribuzione prima di creare il controller di dati, questo daemonset non viene creato.

È possibile eseguire l'override delle impostazioni predefinite per i controldb pod e nel file YAML del controller di dati. Esempio:

  resources:
    controller:
      limits:
        cpu: "1000m"
        memory: "3Gi"
      requests:
        cpu: "800m"
        memory: "2Gi"
    controllerDb:
      limits:
        cpu: "800m"
        memory: "8Gi"
      requests:
        cpu: "200m"
        memory: "4Gi"

Per informazioni dettagliate sul dimensionamento dell'archiviazione, vedere l'articolo relativo alla configurazione dell'archiviazione.

Dettagli sul ridimensionamento dell'istanza gestita di SQL

Ogni istanza gestita di SQL deve avere le richieste e i limiti minimi di risorse seguenti:

Livello di servizio Utilizzo generico Business Critical
Richiesta CPU Minimo: 1
Massimo: 24
Valore predefinito: 2		 Minimo: 3
Massimo: illimitato
Impostazione predefinita: 4
Limite CPU Minimo: 1
Massimo: 24
Valore predefinito: 2		 Minimo: 3
Massimo: illimitato
Impostazione predefinita: 4
Richiesta di memoria Minimo: 2Gi
Massimo: 128Gi
Impostazione predefinita: 4Gi		 Minimo: 2Gi
Massimo: illimitato
Impostazione predefinita: 4Gi
Limite memoria Minimo: 2Gi
Massimo: 128Gi
Impostazione predefinita: 4Gi		 Minimo: 2Gi
Massimo: illimitato
Impostazione predefinita: 4Gi

Ogni pod dell'istanza gestita di SQL creato ha tre contenitori:

Nome contenitore Richiesta CPU Memoria richiesta Limite CPU Limite memoria Note
fluentbit 100m 100Mi Non specificato Non specificato Le fluentbit richieste di risorse del contenitore si aggiungono alle richieste specificate per l'istanza gestita di SQL.
arc-sqlmi Utente specificato o non specificato. Utente specificato o non specificato. Utente specificato o non specificato. Utente specificato o non specificato.
collectd Non specificato Non specificato Non specificato Non specificato

Le dimensioni predefinite del volume per tutti i volumi permanenti sono 5Gi.

Dettagli sul ridimensionamento del server PostgreSQL

Ogni nodo del server PostgreSQL deve avere le richieste di risorse minime seguenti:

  • Memoria: 256Mi
  • Core: 1

Ogni pod del server PostgreSQL creato ha tre contenitori:

Nome contenitore Richiesta CPU Memoria richiesta Limite CPU Limite memoria Note
fluentbit 100m 100Mi Non specificato Non specificato Le fluentbit richieste di risorse del contenitore si aggiungono alle richieste specificate per il server PostgreSQL.
postgres Utente specificato o non specificato. Utente specificato o 256Mi (impostazione predefinita). Utente specificato o non specificato. Utente specificato o non specificato.
arc-postgresql-agent Non specificato Non specificato Non specificato Non specificato

Dimensionamento cumulativo

Le dimensioni complessive di un ambiente necessario per i servizi dati abilitati per Azure Arc sono principalmente una funzione del numero e delle dimensioni delle istanze del database. Le dimensioni complessive possono essere difficili da prevedere in anticipo sapendo che il numero di istanze può aumentare e ridurre e la quantità di risorse necessarie per ogni istanza di database può cambiare.

Le dimensioni di base per un determinato ambiente di servizi dati abilitati per Azure Arc sono le dimensioni del controller dati, che richiede 4 core e 16 GB di RAM. Aggiungere quindi il totale cumulativo di core e memoria necessari per le istanze del database. Istanza gestita di SQL richiede un pod per ogni istanza. Il server PostgreSQL crea un pod per ogni server.

Oltre ai core e alla memoria richiesti per ogni istanza del database, è necessario aggiungere 250m core e 250Mi RAM per i contenitori dell'agente.

Calcolo del ridimensionamento di esempio

Requisiti:

  • "SQL1": 1 istanza gestita di SQL con 16 GB di RAM, 4 core
  • "SQL2": 1 istanza gestita di SQL con 256 GB di RAM, 16 core
  • "Postgres1": 1 server PostgreSQL a 12 GB di RAM, 4 core

Calcoli di ridimensionamento:

  • Le dimensioni di "SQL1" sono: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Per gli agenti per pod usare 16.25 Gi RAM e 4.25 core.

  • Le dimensioni di "SQL2" sono: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). Per gli agenti per pod usare 256.25 Gi RAM e 16,25 core.

  • Le dimensioni totali di SQL 1 e SQL 2 sono:

    • (16.25 GB + 256.25 Gi) = 272.5-GB RAM
    • (4.25 cores + 16.25 cores) = 20.5 cores

  • Le dimensioni di "Postgres1" sono: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Per gli agenti per pod usano 12.25 Gi RAM e 4.25 core.

  • Capacità totale richiesta:

    • Per le istanze del database:
      • 272,5 GB di RAM
      • 20.5 core
    • Per SQL:
      • 12,25 GB di RAM
      • 4.25 core
    • Per il server PostgreSQL
      • 284,75 GB di RAM
      • 24,75 core

  • La capacità totale necessaria per le istanze del database più il titolare del trattamento dei dati è:

    • Per l'istanza del database
      • 284,75 GB di RAM
      • 24,75 core
    • Per il titolare del trattamento dei dati
      • 16 GB di RAM
      • 4 core
    • Totale:
      • 300,75 GB di RAM
      • 28,75 core.

Per informazioni dettagliate sul dimensionamento dell'archiviazione, vedere l'articolo relativo alla configurazione dell'archiviazione.

Altre considerazioni

Tenere presente che una determinata richiesta di dimensioni dell'istanza del database per core o RAM non può superare la capacità disponibile dei nodi Kubernetes nel cluster. Ad esempio, se il nodo Kubernetes più grande disponibile nel cluster Kubernetes è di 256 GB di RAM e 24 core, non è possibile creare un'istanza del database con una richiesta di 512 GB di RAM e 48 core.

Mantenere almeno il 25% della capacità disponibile nei nodi Kubernetes. Questa capacità consente a Kubernetes di:

  • Pianificare in modo efficiente i pod da creare
  • Abilitare il ridimensionamento elastico
  • Supporta gli aggiornamenti in sequenza dei nodi Kubernetes
  • Facilita la crescita a lungo termine su richiesta

Nei calcoli di ridimensionamento aggiungere i requisiti delle risorse dei pod di sistema Kubernetes e di tutti gli altri carichi di lavoro, che possono condividere la capacità con i servizi dati abilitati per Azure Arc nello stesso cluster Kubernetes.

Per mantenere la disponibilità elevata durante la manutenzione pianificata e la continuità di emergenza, pianificare che almeno uno dei nodi Kubernetes nel cluster non sia disponibile in un determinato momento. Kubernetes tenta di riprogrammare i pod in esecuzione in un determinato nodo che è stato arrestato per la manutenzione o a causa di un errore. Se non è disponibile capacità nei nodi rimanenti, tali pod non verranno riprogrammati per la creazione fino a quando non sarà disponibile di nuovo la capacità. Prestare particolare attenzione alle istanze di database di grandi dimensioni. Ad esempio, se è presente un solo nodo Kubernetes sufficientemente grande per soddisfare i requisiti delle risorse di un'istanza di database di grandi dimensioni e tale nodo ha esito negativo, Kubernetes non pianifica il pod dell'istanza del database in un altro nodo Kubernetes.

Tenere presenti i limiti massimi per le dimensioni del cluster Kubernetes.

L'amministratore di Kubernetes potrebbe aver configurato le quote di risorse nello spazio dei nomi o nel progetto. Tenere presenti queste quote quando si pianificano le dimensioni dell'istanza del database.