Indicazioni sul 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.
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.
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.
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.
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
.
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 |
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.
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 usare16.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 usare256.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 usare12.25 Gi
RAM e4.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
- Per le istanze di database:
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 l'istanza di database
Per informazioni dettagliate sul dimensionamento delle risorse di archiviazione, consultare l'articolo relativo alla configurazione delle risorse di archiviazione.
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.