Condividi tramite

Indicazioni sul dimensionamento

  • Articolo

Panoramica delle linee guida per il dimensionamento

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

  • Calcolo
  • Memoria
  • Storage

Queste risorse sono necessarie per:

  • Controller 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 risorse di archiviazione. Questa guida indica i requisiti minimi e consiglia le dimensioni per alcuni requisiti comuni.

Requisiti generali di dimensionamento

Nota

Se non si ha familiarità con i concetti usati in questo articolo, è possibile approfondirli facendo riferimento alle informazioni sulla governance delle risorse Kubernetes e sulla notazione delle dimensioni in 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 per impostare i valori della memoria. In particolare, usare i suffissi:

  • Ki
  • Mi
  • Gi

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

I valori limite per i core sono la metrica fatturabile nei server PostgreSQL e delle istanze gestite di SQL.

Requisiti di distribuzione minimi

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

Per informazioni dettagliate sul dimensionamento delle risorse di archiviazione, consultare l'articolo relativo alla configurazione delle risorse di archiviazione.

Dettagli sul ridimensionamento del controller dei dati

Il controller dei dati è una raccolta di pod distribuiti nel cluster Kubernetes per fornire un'API, il servizio del controller, il caricatore di bootstrap e i database e i dashboard di monitoraggio. Questa tabella riporta i valori predefiniti per i requisiti e i limiti di memoria e CPU.

Nome pod Richiesta CPU Richiesta 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 oggetto daemonset, che viene creato in ogni nodo Kubernetes nel cluster. I numeri nella tabella sono da intendersi per nodo. Se si imposta allowNodeMetricsCollection = false nel file del profilo di distribuzione prima di creare il controller dei dati, l'oggetto daemonset non viene creato.

È possibile eseguire l'override delle impostazioni predefinite per controldb e i pod di controllo e nel file YAML del controller dei 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 delle risorse di archiviazione, consultare l'articolo relativo alla configurazione delle risorse di archiviazione.

Dettagli sul dimensionamento del servizio Istanza gestita di SQL

Ogni istanza gestita di SQL deve essere conforme ai requisiti e ai 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
Valore predefinito: 4
Limite CPU Minimo: 1
Massimo: 24
Valore predefinito: 2		 Minimo: 3
Massimo: illimitato
Valore predefinito: 4
Richiesta 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 richieste di risorse del contenitore fluentbit 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 persistenti sono 5Gi.

Dettagli sul dimensionamento 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 richieste di risorse del contenitore fluentbit 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 di database. Le dimensioni complessive possono essere difficili da prevedere in quanto il numero di istanze può aumentare e diminuire 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 corrispondono alle dimensioni del controller dei dati, che richiede 4 core e 16 GB di RAM. Aggiungere quindi il totale cumulativo di core e memoria necessari per le istanze di database. Il servizio 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 di database, è necessario aggiungere 250m di core e 250Mi di RAM per i contenitori dell'agente.

Esempi di calcolo del dimensionamento

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 con 12 GB di RAM, 4 core

Calcoli di dimensionamento:

  • 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 usare 12.25 Gi RAM e 4.25 core.

  • Capacità totale richiesta:

    • Per le istanze di 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 di database più il controller dei dati è:

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

Per informazioni dettagliate sul dimensionamento delle risorse di archiviazione, consultare l'articolo relativo alla configurazione delle risorse di archiviazione.

Altre considerazioni

Tenere presente che una determinata richiesta di dimensioni dell'istanza di database relativamente a core o RAM non può superare la capacità disponibile dei nodi Kubernetes nel cluster. Ad esempio, se la dimensione del nodo Kubernetes più grande disponibile nel cluster Kubernetes è pari a 256 GB di RAM e 24 core, non è possibile creare un'istanza di 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
  • Supportare gli aggiornamenti in sequenza dei nodi Kubernetes
  • Facilitare la crescita a lungo termine su richiesta

Nei calcoli del dimensionamento, aggiungere le risorse necessarie per i pod di sistema Kubernetes e per 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à in caso di ripristino di emergenza, pianificare in modo 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 di database in un altro nodo Kubernetes.

Considerare sempre i limiti massimi per le dimensioni dei 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 di database.