Directives de dimensionnement du dispositif VMware Cloud Director

Présentation

Pour s'assurer que le cluster peut prendre en charge un basculement automatisé en cas d'échec d'une cellule principale, le déploiement minimal de VMware Cloud Director doit être composé d'une cellule principale et de deux cellules en veille. L'environnement reste disponible en cas d'échec lorsque l'une des cellules se déconnecte pour une raison quelconque. Si un échec de la cellule en veille se produit, le cluster fonctionne dans un état entièrement fonctionnel avec une certaine dégradation des performances jusqu'à ce que vous redéployiez la cellule en échec. Reportez-vous à la section Déploiements du dispositif et configuration de la haute disponibilité de la base de données.

Le dispositif VMware Cloud Director a quatre tailles que vous pouvez sélectionner lors du déploiement : Petit, Moyen, Grand et Très grand (VVD). La taille de dispositif Petit convient à une évaluation de laboratoire et ce document ne fournit pas de conseils sur la configuration de cette taille. Le tableau des options de taille fournit des spécifications sur les options restantes et les cas d'utilisation les plus adaptés à un environnement de production. La configuration Très grand correspond au profil d'échelle VMware Validated Designs (VVD) for Cloud Providers.

Pour créer des tailles personnalisées plus grandes, les administrateurs système peuvent ajuster la taille des cellules déployées.

La configuration la plus petite recommandée pour les déploiements de production est un déploiement à trois nœuds des dispositifs virtuels de taille moyenne.

Important : VMware ne prend pas en charge les déploiements de dispositif VMware Cloud Director sans haute disponibilité de base de données.

Options de dimensionnement du dispositif VMware Cloud Director

Vous pouvez utiliser le guide de décision suivant pour estimer la taille du dispositif pour votre environnement.

	Medium	Large	Très grand (VVD)
Cas d'utilisation recommandés	Environnements de laboratoire ou de petite production	Environnement de production	Production avec intégrations d'API et surveillance
Déploiement vRealize Operations Management Pack dans l'environnement VMware Cloud Director	Non	Non	Oui
Activation des mesures de machine virtuelle Cassandra dans VMware Cloud Director	Non	Non	Oui
Nombre approximatif d'utilisateurs ou de clients simultanés accédant à l'API sur une période de pointe de 30 minutes.	< 50	< 100	< 100
Machines virtuelles gérées	5 000	5 000	15 000

Définitions de configuration


	Medium	Large	Très grand (VVD)
Configuration du cluster HA	1 cellule principale + 2 cellules en veille	1 cellule principale + 2 cellules en veille + 1 cellule d'application	1 cellule principale + 2 cellules d'application en veille + 2 cellules d'application
vCPU de cellule principale ou en veille	8	16	24
vCPU de cellule d'application	S/O	8	8
RAM de cellule principale ou en veille	16 Go	24 Go	32 Go
RAM de cellule d'application	S/O	8	8
Rapport vCPU/cœur physique	1:1	1:1	1:1
Espace disque minimal pour chaque dispositif dans le cluster	112 Go	112 Go	112 Go

Comment détecter si votre système est sous-dimensionné

Dans une cellule VMware Cloud Director, l'utilisation du CPU ou de la mémoire augmente et atteint un niveau élevé, c'est-à-dire un niveau proche de la capacité. La cellule VMware Cloud Director peut également perdre la connexion à la base de données.

Comment détecter si le nombre de cellules de votre système est insuffisant

Dans les fichiers vcloud-container-debug.log et cell-runtime.log de l'une des cellules VMware Cloud Director, vous voyez des entrées semblables à org.apache.tomcat.jdbc.pool.PoolExhaustedException: [pool-jetty-XXXXX] Timeout: Pool empty. Unable to fetch a connection in 20 seconds, none available. La cellule VMware Cloud Director peut également perdre la connexion à la base de données.

Note :

En fonction de la configuration de la connexion à la base de données par défaut, toutes les configurations sont limitées à un maximum de 6 cellules de type principal, en veille et d'application.

Comment personnaliser le dimensionnement du dispositif

Il existe deux façons de personnaliser le dimensionnement du dispositif VMware Cloud Director en une configuration personnalisée après l'exécution du système de déploiement du dispositif de service vpostgres-reconfigure.

Personnalisez le dimensionnement du dispositif à l'aide du service vpostgres-reconfigure.
Personnalisez le dimensionnement du dispositif en mettant manuellement à jour le fichier postgresql.auto.conf.

Pour personnaliser le dimensionnement d'un dispositif VMware Cloud Director à l'aide du service vpostgres-reconfigure, vous pouvez modifier les paramètres matériels de la machine virtuel dans vSphere Client. À chaque démarrage du dispositif, le service vpostgres-reconfigure s'exécute et modifie les paramètres PostgreSQL pour qu'ils correspondent à la dimension de la machine virtuelle.

Note : Le service vpostgres-reconfigure ne modifie pas les personnalisations manuelles postgresql.auto.conf précédentes.

Si vous souhaitez effectuer une personnalisation manuelle, vous pouvez modifier le fichier postgresql.auto.conf. La personnalisation manuelle est prioritaire sur la personnalisation du service vpostgres-reconfigure. Pour personnaliser manuellement le taille du dispositif, suivez cette procédure sur toutes les cellules.

Connectez-vous, directement ou à l'aide d'un client SSH, au système d'exploitation du dispositif principal en tant que racine.
Pour afficher et noter les informations de vCPU, exécutez la commande suivante.
```
grep -c processor /proc/cpuinfo
```
Pour afficher et noter les informations de RAM, exécutez la commande suivante.
La RAM signalée ci-dessous est en Ko et vous devez la convertir en Go en divisant par 1 048 576 (1 024 × 1 024).
```
cat /proc/meminfo | grep MemTotal | cut -dk -f1 | awk '{print int($2/1048576)}'
```
Calculez la valeur de shared_buffers comme valeur plancher d'un quart de la RAM totale moins 4 Go.
shared_buffers = valeur plancher [ 0,25 × (total RAM - 4 Go) ]
Où floor renvoie le plus grand entier inférieur ou égal à la valeur entre crochets.
Calculez la valeur de effective_cache_size comme trois quarts de la RAM totale moins 4 Go.
effective_cache_size = 0,75 * (total RAM - 4 Go)
Calculez la valeur de max_worker_processes devant être le nombre de vCPU.
La valeur par défaut (minimale) est 8.
Remplacez l'utilisateur par postgres.
```
sudo -i -u postgres
```

Mettez à jour le fichier de configuration postgresql.auto.conf en exécutant les commandes suivantes et en remplaçant les valeurs calculées.

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';"

Revenez à l'utilisateur racine en exécutant la commande exit.
Redémarrez le processus vpostgres.
```
systemctl restart vpostgres
```
Remplacez l'utilisateur par postgres à nouveau.
```
sudo -i -u postgres
```
Pour chaque nœud en veille, copiez le fichier postgresql.auto.conf sur le nœud et redémarrez le processus vpostgres.
1. Copiez le fichier postgresql.auto.conf du nœud principal vers le nœud en veille.
```
scp /var/vmware/vpostgres/current/pgdata/postgresql.auto.conf postgres@standby-node-address:/var/vmware/vpostgres/current/pgdata/
```
2. Redémarrez le processus vpostgres.
```
systemctl restart vpostgres
```

Pour supprimer les personnalisations manuelles et continuer à utiliser le service vpostgres-reconfigure, modifiez l'utilisateur en postgres, puis exécutez les commandes suivantes.

psql -c "ALTER SYSTEM reset shared_buffers;"
    psql -c "ALTER SYSTEM reset effective_cache_size;"
    psql -c "ALTER SYSTEM reset max_worker_processes;"