Größenrichtlinien für die VMware Cloud Director-Appliance

Übersicht

Um sicherzustellen, dass der Cluster ein automatisiertes Failover unterstützen kann, wenn ein Fehler in einer primären Zelle auftritt, muss die minimale VMware Cloud Director-Bereitstellung aus einer primären und zwei Standby-Zellen bestehen. Die Umgebung bleibt in jedem Fehlerszenario verfügbar, bei dem eine der Zellen aus irgendeinem Grund offline geschaltet wird. Wenn ein Standby-Fehler auftritt, erfolgt der Betrieb des Cluster bis zur erneuten Bereitstellung der ausgefallenen Zelle in einem voll funktionsfähigen Zustand mit einigen Leistungsbeeinträchtigungen. Weitere Informationen finden Sie im Appliance-Bereitstellungen und Datenbank-Hochverfügbarkeitskonfiguration.

Die VMware Cloud Director-Appliance weist vier Größen auf, die Sie während der Bereitstellung auswählen können: Klein, Mittel, Groß und Extragroß (VVD). Die Appliance-Größe „Klein“ ist für Lab-Testzwecke geeignet, und in diesem Dokument wird die Appliance-Konfiguration „Klein“ nicht näher erläutert. Die Tabelle mit den Größenoptionen enthält die Spezifikationen für die verbleibenden Optionen und die am besten geeigneten Anwendungsfälle für eine Produktionsumgebung. Die Konfiguration „Extragroß“ stimmt mit dem Skalierungsprofil unter VMware Validated Designs (VVD) for Cloud Providers überein.

Um größere benutzerdefinierte Größen zu erstellen, können Systemadministratoren die Größe der bereitgestellten Zellen anpassen.

Die kleinste empfohlene Konfiguration für Produktionsbereitstellungen ist eine Drei-Knoten-Bereitstellung mit virtuellen Appliances mittlerer Größe.

Wichtig: VMware bietet keine Unterstützung für VMware Cloud Director-Appliance-Bereitstellungen ohne Datenbank-HA.

Größenoptionen für die VMware Cloud Director-Appliance

Sie können den folgenden Entscheidungsleitfaden verwenden, um eine Schätzung der Appliance-Größe für Ihre Umgebung vorzunehmen.

	Mittel	Groß	Extragroß (VVD)
Empfohlene Anwendungsfälle	Lab- oder kleine Produktionsumgebungen	Produktionsumgebung	Produktion mit API-Integrationen und Überwachung
vRealize Operations Management Pack-Bereitstellung in der VMware Cloud Director-Umgebung	Nein	Nein	Ja
Aktivierung von Cassandra-VM-Metriken in VMware Cloud Director	Nein	Nein	Ja
Ungefähre Anzahl gleichzeitiger Benutzer oder Clients, die über einen Zeitraum von 30 Minuten maximal auf die API zugreifen.	< 50	< 100	< 100
Verwaltete VMs	5.000	5.000	15000

Konfigurationsdefinitionen


	Mittel	Groß	Extragroß (VVD)
HA-Clusterkonfiguration	1 primäre Zelle + 2 Standby-Zellen	1 primäre Zelle + 2 Standby-Zellen + 1 Anwendungszelle	1 primäre Zelle + 2 Standby-Zellen + 2 Anwendungszellen
vCPUs der primären oder Standby-Zelle	8	16	24
vCPUs der Anwendungszelle	Nicht verfügbar	8	8
RAM der primären oder Standby-Zelle	16 GB	24 GB	32 GB
RAM der Anwendungszelle	Nicht verfügbar	8	8
Verhältnis von vCPU zu physischem Kern	1:1	1:1	1:1
Erforderlicher Festplattenspeicher für jede Appliance im Cluster	112 GB	112 GB	112 GB

So erkennen Sie, ob Ihr System unterdimensioniert ist

In einer VMware Cloud Director-Zelle wächst der CPU- oder Arbeitsspeicherverbrauch an und bleibt dauerhaft auf einem hohen Niveau, d. h. einem Niveau nahe der Kapazitätsgrenze. Die VMware Cloud Director-Zelle verliert möglicherweise auch die Verbindung zur Datenbank.

So erkennen Sie, ob die Anzahl der Zellen in Ihrem System nicht ausreicht

In den Dateien vcloud-container-debug.log und cell-runtime.log einer beliebigen der VMware Cloud Director-Zellen sehen Sie Einträge ähnlich dem folgenden: org.apache.tomcat.jdbc.pool.PoolExhaustedException: [pool-jetty-XXXXX] Zeitüberschreitung: Pool leer. Abrufen einer Verbindung nicht möglich in 20 Sekunden, keine verfügbar. Die VMware Cloud Director-Zelle verliert möglicherweise auch die Verbindung zur Datenbank.

Hinweis:

Basierend auf der standardmäßigen Datenbankverbindungskonfiguration sind alle Konfigurationen auf maximal 6 Zellen des primären, Standby- und Anwendungstyps beschränkt.

So passen Sie die Größe der Appliance an

Es gibt zwei Möglichkeiten, die Größe der VMware Cloud Director-Appliance nach der Ausführung des Bereitstellers der vpostgres-reconfigure-Dienst-Appliance an eine benutzerdefinierte Konfiguration anzupassen.

Passen Sie die Größe der Appliance mithilfe des vpostgres-reconfigure-Diensts an.
Passen Sie die Größe der Appliance an, indem Sie die Datei postgresql.auto.conf manuell aktualisieren.

Um die Größe einer VMware Cloud Director-Appliance mithilfe des vpostgres-reconfigure-Diensts anzupassen, können Sie die VM-Hardwareeinstellungen im vSphere Client bearbeiten. Bei jedem Start der Appliance wird der vpostgres-reconfigure-Dienst ausgeführt, der die PostgreSQL-Einstellungen entsprechend der VM-Größe ändert.

Hinweis: Der vpostgres-reconfigure-Dienst ändert keine früheren manuellen Anpassungen an der Datei postgresql.auto.conf.

Wenn Sie eine manuelle Anpassung vornehmen möchten, können Sie die Datei postgresql.auto.conf bearbeiten. Die manuelle Anpassung hat Vorrang vor der Anpassung des vpostgres-reconfigure-Diensts. Führen Sie dieses Verfahren in allen Zellen aus, um die Größe der Appliance manuell anzupassen.

Melden Sie sich direkt oder mithilfe eines SSH-Clients beim Betriebssystem der primären Appliance als root an.
Um die vCPU-Informationen anzuzeigen und zu notieren, führen Sie den folgenden Befehl aus.
```
grep -c processor /proc/cpuinfo
```
Um die RAM-Informationen anzuzeigen und zu notieren, führen Sie den folgenden Befehl aus.
Der unten genannten RAM ist in KB angegeben. Sie müssen ihn in GB konvertieren, indem Sie ihn durch 1048576 (1024*1024) teilen.
```
cat /proc/meminfo | grep MemTotal | cut -dk -f1 | awk '{print int($2/1048576)}'
```
Berechnen Sie den Wert für shared_buffers als größte Ganzzahl eines Viertels des gesamten RAM minus 4 GB.
shared_buffers = größte Ganzzahl [0,25 * (Gesamt-RAM - 4 GB)]
Dabei gibt floor die größte Ganzzahl zurück, die kleiner oder gleich dem Wert in den eckigen Klammern ist.
Berechnen Sie den Wert für effective_cache_size so, dass er drei Viertel des gesamten RAM minus 4 GB beträgt.
effective_cache_size = 0,75 * (gesamter RAM - 4 GB)
Berechnen Sie den Wert für max_worker_processes so, dass er gleich der Anzahl der vCPUs ist.
Der Standard- und Mindestwert lauten 8.
Ändern Sie den Benutzer in postgres.
```
sudo -i -u postgres
```

Aktualisieren Sie die Konfigurationsdatei postgresql.auto.conf, indem Sie die folgenden Befehle ausführen und die berechneten Werte einsetzen.

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

Kehren Sie zum root-Benutzer zurück, indem Sie den Befehl exit ausführen.
Starten Sie den Prozess vpostgres neu.
```
systemctl restart vpostgres
```
Ändern Sie den Benutzer erneut in postgres.
```
sudo -i -u postgres
```
Kopieren Sie für jeden Standby-Knoten die Datei postgresql.auto.conf auf den Knoten und starten Sie den vpostgres-Prozess neu.
1. Kopieren Sie postgresql.auto.conf vom primären Knoten auf den Standby-Knoten.
```
scp /var/vmware/vpostgres/current/pgdata/postgresql.auto.conf postgres@standby-node-address:/var/vmware/vpostgres/current/pgdata/
```
2. Starten Sie den Prozess vpostgres neu.
```
systemctl restart vpostgres
```

Um alle manuellen Anpassungen zu entfernen und weiterhin den vpostgres-reconfigure-Dienst zu verwenden, ändern Sie den Benutzer in postgres und führen Sie die folgenden Befehle aus.

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