In base alle proprie esigenze, è possibile avere configurazioni diverse del gruppo di server basato sull'appliance VMware Cloud Director e dimensioni diverse delle istanze della virtual appliance VMware Cloud Director.

Panoramica

Per assicurarsi che il cluster possa supportare un failover automatico in caso di errore della cella primaria, la distribuzione minima di VMware Cloud Director deve essere costituita da una cella primaria e da due celle di standby. L'ambiente rimane disponibile in qualsiasi scenario di errore in cui una delle celle passa offline per un motivo qualsiasi. Se si verifica un errore della cella di standby, finché non si ridistribuisce la cella in cui si è verificato l'errore, il cluster è completamente funzionante con qualche peggioramento delle prestazioni. Vedere Distribuzioni dell'appliance e configurazione della disponibilità elevata del database.

L'appliance VMware Cloud Director ha quattro dimensioni che è possibile selezionare durante la distribuzione: Piccola, Media, Grande e Molto grande (VVD). La dimensione dell'appliance Piccola è adatta per la valutazione di laboratorio e questo documento non fornisce istruzioni sulla configurazione di questo tipo di appliance. La tabella delle opzioni di dimensionamento fornisce le specifiche per le opzioni rimanenti e i casi d'uso più adatti per un ambiente di produzione. La configurazione Molto grande corrisponde al profilo di scalabilità VMware Validated Designs (VVD) for Cloud Providers.

Per creare dimensioni personalizzate più grandi, gli amministratori di sistema possono modificare le dimensioni delle celle distribuite.

La configurazione minima consigliata per le distribuzioni di produzione è una distribuzione di tre nodi di appliance virtuali di dimensioni medie.

Importante: VMware non fornisce il supporto per le distribuzioni dell'appliance VMware Cloud Director senza database HA.

Opzioni di dimensionamento dell'appliance VMware Cloud Director

È possibile utilizzare le linee guida seguenti per stimare le dimensioni dell'appliance per il proprio ambiente.

Media Grande Molto grande (VVD)
Casi d'uso consigliati Ambienti di produzione piccoli o di laboratorio Ambiente di produzione Produzione con integrazioni API e monitoraggio
Distribuzione di vRealize Operations Management Pack nell'ambiente di VMware Cloud Director No No
Abilitazione delle metriche delle macchine virtuali Cassandra in VMware Cloud Director No No
Numero approssimato di utenti o client che accedono all'API contemporaneamente per un periodo di picco di 30 minuti. < 50 < 100 < 100
Macchine virtuali gestite 5000 5000 15000

Definizioni di configurazione

Media Grande Molto grande (VVD)
Configurazione cluster HA 1 cella primaria + 2 celle di standby 1 cella primaria + 2 celle di standby + 1 cella dell'applicazione 1 cella primaria + 2 celle di standby + 2 celle dell'applicazione
vCPU della cella primaria o di standby 8 16 24
vCPU della cella dell'applicazione N/D 8 8
RAM della cella primaria o di standby 16 GB 24 GB 32 GB
RAM della cella dell'applicazione N/D 8 8
Rapporto tra vCPU e core fisici 1:1 1:1 1:1
Spazio su disco minimo per ogni appliance nel cluster 112 GB 112 GB 112 GB

Come stabilire se le dimensioni del sistema sono insufficienti

In una cella VMware Cloud Director, l'uso della CPU o della memoria aumenta fino a raggiungere un livello elevato, ovvero quasi vicino alla capacità massima. La cella di VMware Cloud Director potrebbe inoltre perdere la connessione al database.

Come stabilire se il numero di celle del sistema è insufficiente

Nei file vcloud-container-debug.log e cell-runtime.log di tutte le celle di VMware Cloud Director sono presenti voci simili a rg.apache.apache.tomcat.jdbc.pool.PoolExcatetedException: [pool-jetty-XXXXX] Timeout: Pool empty. Unable to fetch a connection in 20 seconds, none available. La cella di VMware Cloud Director potrebbe inoltre perdere la connessione al database.
Nota:

In base alla configurazione della connessione del database predefinita, tutte le configurazioni sono limitate a un massimo di 6 celle di tipo primario, standby e applicazione.

Come personalizzare il dimensionamento dell'appliance

Sono disponibili due modi per personalizzare il dimensionamento dell'appliance VMware Cloud Director in una configurazione personalizzata dopo aver eseguito lo strumento di distribuzione dell'appliance del servizio vpostgres-reconfigure.

  • Personalizzare il dimensionamento dell'appliance utilizzando il servizio vpostgres-reconfigure.
  • Personalizzare il dimensionamento dell'appliance aggiornando manualmente il file postgresql.auto.conf.

Per personalizzare un dimensionamento dell'appliance VMware Cloud Director utilizzando il servizio vpostgres-reconfigure, è possibile modificare le impostazioni dell'hardware della macchina virtuale in vSphere Client. Ogni volta che viene avviata l'appliance, il servizio vpostgres-reconfigure viene eseguito e modifica le impostazioni di PostgreSQL in modo che corrispondano alle dimensioni della macchina virtuale.

Nota: Il servizio vpostgres-reconfigure non modifica le personalizzazioni manuali precedenti del file postgresql.auto.conf.

Se si desidera creare una personalizzazione manuale, è possibile modificare il file postgresql.auto.conf. La personalizzazione manuale ha la precedenza sulla personalizzazione del servizio vpostgres-reconfigure. Per personalizzare manualmente il dimensionamento dell'appliance , eseguire questa procedura in tutte le celle.

  1. Accedere direttamente o tramite un client SSH al sistema operativo dell'appliance primaria come root.
  2. Per visualizzare e annotare le informazioni sulla vCPU, eseguire il comando seguente.
    grep -c processor /proc/cpuinfo
  3. Per visualizzare e annotare le informazioni sulla RAM, eseguire il comando seguente.

    La RAM indicata di seguito è in KB ed è necessario convertirla in GB dividendola per 1048576 (1024*1024).

    cat /proc/meminfo | grep MemTotal | cut -dk -f1 | awk '{print int($2/1048576)}'
  4. Calcolare il valore shared_buffers in modo che corrisponda al valore floor di un quarto della RAM totale meno 4 GB.

    shared_buffers = floor [ 0.25 * (total RAM - 4 GB) ]

    Dove floor restituisce il numero intero più grande minore o uguale al valore tra le parentesi quadre.

  5. Calcolare il valore effective_cache_size in modo che corrisponda a tre quarti della RAM totale meno 4 GB.

    effective_cache_size = 0,75 * (RAM totale - 4 GB)

  6. Calcolare il valore max_worker_processes che è il numero di vCPU.

    Il valore predefinito e minimo è 8.

  7. Sostituire l'utente con postgres.
    sudo -i -u postgres
  8. Aggiornare il file di configurazione postgresql.auto.conf eseguendo i comandi seguenti e sostituendo i valori calcolati.
    psql -c "ALTER SYSTEM set shared_buffers = 'shared_buffers value';"
    psql -c "ALTER SYSTEM set effective_cache_size =  'effective_cache_size value';"
    psql -c "ALTER SYSTEM set work_mem = '8MB';"
    psql -c "ALTER SYSTEM set maintenance_work_mem = '1GB';"
    psql -c "ALTER SYSTEM set max_worker_processes= 'max_worker_processes value';"
    
  9. Tornare all'utente root eseguendo il comando exit.
  10. Riavviare il processo vpostgres.
    systemctl restart vpostgres
  11. Impostare di nuovo l'utente su postgres.
    sudo -i -u postgres
  12. Per ogni nodo di standby, copiare il file postgresql.auto.conf nel nodo e riavviare il processo vpostgres.
    1. Copiare il file postgresql.auto.conf dal nodo primario al nodo di standby.
      scp /var/vmware/vpostgres/current/pgdata/postgresql.auto.conf postgres@standby-node-address:/var/vmware/vpostgres/current/pgdata/
    2. Riavviare il processo vpostgres.
      systemctl restart vpostgres
Per rimuovere eventuali personalizzazioni manuali e continuare a utilizzare il servizio vpostgres-reconfigure, modificare l'utente impostandolo su postgres ed eseguire i comandi seguenti.
psql -c "ALTER SYSTEM reset shared_buffers;"
    psql -c "ALTER SYSTEM reset effective_cache_size;"
    psql -c "ALTER SYSTEM reset max_worker_processes;"