Sizing Guidance

Panoramica delle linee guida per il dimensionamento

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

• Compute
• Memory
• Storage

Queste risorse sono necessarie per:

• Controller dei dati
• Istanze gestite SQL

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

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 nell'istanza gestita di SQL.

Requisiti di distribuzione minimi

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. For this configuration, you need at least 16-GB RAM and 4 cores of available capacity on your Kubernetes cluster. È 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.

See the storage-configuration article for details on storage sizing.

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.

metricsdc è un oggetto daemonset, che viene creato in ogni nodo Kubernetes nel cluster. The numbers in the table are per node. 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. Example:

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

See the storage-configuration article for details on storage sizing.

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:

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

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

Cumulative sizing

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.

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

Requirements:

• "SQL1": 1 SQL managed instance with 16-GB RAM, 4 cores
• "SQL2": 1 SQL managed instance with 256-GB RAM, 16 cores

Sizing calculations:

• 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 RAM
    • 20.5 cores
  • For SQL:
    • 12.25-GB RAM
    • 4.25 cores

• La capacità totale necessaria per le istanze di database più il controller dei dati è:

  • Per l'istanza di database
    • 284.75-GB RAM
    • 24.75 cores
  • Per il controller dei dati
    • 16-GB RAM
    • 4 cores
  • In total:
    • 300.75-GB RAM
    • 28.75 cores.

See the storage-configuration article for details on storage sizing.

Other considerations

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.

Your Kubernetes administrator may have set up resource quotas on your namespace/project. Tenere presenti queste quote quando si pianificano le dimensioni dell'istanza di database.