Eine Übersicht über AlloyDB Omni finden Sie unter AlloyDB Omni – Übersicht.
Größe und Kapazität
Größe und Kapazität wirken sich direkt auf die Leistung, Zuverlässigkeit und Kosteneffizienz Ihrer AlloyDB Omni-Instanz aus. Wenn Sie eine vorhandene Datenbank migrieren, sind die erforderlichen CPU- und Arbeitsspeicherressourcen ähnlich den Anforderungen des Quelldatenbanksystems.
Planen Sie, mit einer Bereitstellung mit passenden CPU-, RAM- und Festplattenressourcen zu beginnen, und verwenden Sie die Konfiguration des Quellsystems als AlloyDB Omni-Basiskonfiguration. Möglicherweise können Sie den Ressourcenverbrauch reduzieren, nachdem Sie Ihre AlloyDB Omni-Instanz ausreichend getestet haben.
Die Dimensionierung einer AlloyDB Omni-Umgebung umfasst die folgenden Schritte:
Definieren Sie Ihre Arbeitslast.
Datenvolumen: Schätzen Sie die Gesamtmenge der Daten, die Sie in AlloyDB Omni speichern. Berücksichtigen Sie sowohl aktuelle Daten als auch das prognostizierte Wachstum im Laufe der Zeit.
Transaktionsrate: Bestimmen Sie die erwartete Anzahl von Transaktionen pro Sekunde (TPS), einschließlich Lese-, Schreib-, Aktualisierungs- und Löschvorgängen.
Gleichzeitigkeit: Schätzen Sie die Anzahl der gleichzeitigen Nutzer oder Verbindungen, die auf die Datenbank zugreifen.
Leistungsanforderungen: Definieren Sie die akzeptablen Antwortzeiten für verschiedene Arten von Abfragen und Vorgängen.
Prüfen Sie, ob Ihre Hardware die Anforderungen an die Dimensionierung erfüllt.
CPU: AlloyDB Omni profitiert von Systemen mit mehreren CPU-Kernen und wird je nach Arbeitslast linear skaliert. Open-Source-PostgreSQL profitiert jedoch im Allgemeinen nicht von mehr als 16 vCPUs. Berücksichtigen Sie Folgendes:
- Die Anzahl der Kerne basierend auf der Nebenläufigkeit der Arbeitslast und den Rechenanforderungen.
- Alle Vorteile, die sich aus einer Änderung der CPU-Generation oder -Plattform ergeben können.
Arbeitsspeicher: Weisen Sie ausreichend RAM für die freigegebenen Puffer von AlloyDB Omni zum Zwischenspeichern von Daten und Arbeitsspeicher für die Abfrageverarbeitung zu. Die genauen Anforderungen hängen von der Arbeitslast ab. Beginnen Sie mit 8 GB RAM pro vCPU.
Speicher
Typ: Wählen Sie je nach Bedarf zwischen lokalem NVMe-Speicher für die Leistung oder SAN-Speicher für Skalierbarkeit und Datenfreigabe.
Kapazität: Sorgen Sie für ausreichend Speicherplatz für Ihr Datenvolumen, Ihre Indexe, das Write-Ahead-Log (WAL), Sicherungen und zukünftiges Wachstum.
IOPS: Schätzen Sie die erforderlichen Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) basierend auf den Lese- und Schreibmustern Ihrer Arbeitslast. Wenn Sie AlloyDB Omni in einer öffentlichen Cloud ausführen, berücksichtigen Sie die Leistungsmerkmale Ihres Speichertyps, um zu ermitteln, ob Sie die Speicherkapazität erhöhen müssen, um ein bestimmtes IOPS-Ziel zu erreichen.
Voraussetzungen für die Ausführung von AlloyDB Omni
Bevor Sie AlloyDB Omni ausführen, müssen Sie die folgenden Hardware- und Softwareanforderungen erfüllen.
Hardwareanforderungen
Die Systemanforderungen für den AlloyDB Omni-Bereitstellungsstack umfassen einen Knoten, der für die Ausführung verschiedener Komponenten vorkonfiguriert ist. Der AlloyDB Omni-Knoten muss ein angehängtes Datenlaufwerk mit einem ext4/xfs-Dateisystem haben, dessen Größe anhand der Datengröße geschätzt wird. Die Leistungsmerkmale des Speichers wirken sich auf die Leistung von AlloyDB Omni aus.
| Knoten | Mindesthardware | Empfohlene Hardware |
|---|---|---|
| AlloyDB Omni |
|
|
- Wir empfehlen, ein dediziertes SSD-Speichergerät (Solid State Drive) zum Speichern Ihrer Daten zu verwenden. Wenn Sie ein physisches Gerät für diesen Zweck verwenden, empfehlen wir, es direkt an den Hostcomputer anzuschließen.
Softwareanforderungen
| Betriebssystem/Plattform | Mindestsoftware |
|---|---|
| Linux1 |
|
-
Bei AlloyDB Omni wird davon ausgegangen, dass das
policycoreutils-python-utilsPaket installiert ist, bevor das AlloyDB Omni-RPM-Paket installiert wird. So kann AlloyDB Omni die SELinux-Richtlinie konfigurieren, mit der der AlloyDB Omni-Datenbankdienst ausgeführt werden kann.
Unterstützte Speichertypen
AlloyDB Omni unterstützt Dateisysteme auf Blockspeichervolumes in Datenbankinstanzen. Verwenden Sie für kleinere Entwicklungs- oder Testsysteme das lokale Dateisystem des Hosts, auf dem der Container ausgeführt wird. Verwenden Sie für Arbeitslasten im Unternehmen Speicher, der für AlloyDB Omni-Instanzen reserviert ist. Konfigurieren Sie Ihre Speichergeräte je nach den Anforderungen Ihrer Datenbankarbeitslast entweder in einer Einzelkonfiguration mit einem Laufwerk für jeden Container oder in einer konsolidierten Konfiguration, in der mehrere Container Daten auf demselben Laufwerk lesen und schreiben.
Lokaler NVMe- oder SAN-Speicher
Sowohl der lokale NVMe-Speicher (Non-Volatile Memory Express) als auch der SAN-Speicher (Storage Area Network) bieten deutliche Vorteile. Die Wahl der richtigen Lösung hängt von den spezifischen Anforderungen an die Arbeitslast, dem Budget und den zukünftigen Skalierbarkeitsanforderungen ab.
Berücksichtigen Sie Folgendes, um die beste Speicheroption zu ermitteln:
- Wenn Sie absolute Leistung priorisieren möchten, wählen Sie lokalen NVMe-Speicher aus.
- Wenn Sie einen freigegebenen Speicher im großen Maßstab benötigen, wählen Sie SAN aus.
- Wenn Sie Leistung und Freigabe in Einklang bringen müssen, sollten Sie SAN mit NVMe over Fabrics für einen schnelleren Zugriff in Betracht ziehen.
Lokaler NVMe-Speicher
NVMe ist ein Hochleistungsprotokoll, das für SSDs (Solid State Drives) entwickelt wurde. Für Anwendungen, die einen schnellen Datenzugriff erfordern, bietet der lokale NVMe-Speicher die folgenden Vorteile:
- NVMe-SSDs werden direkt mit dem PCIe-Bus (Peripheral Component Interconnect Express) verbunden, um schnelle Lese- und Schreibgeschwindigkeiten zu erzielen.
- Der lokale NVMe-Speicher bietet die niedrigste Latenz.
- Der lokale NVMe-Speicher bietet den höchsten Durchsatz.
Für die Skalierung des lokalen NVMe-Speichers müssen einzelnen Servern weitere Laufwerke hinzugefügt werden. Das Hinzufügen weiterer Laufwerke zu einzelnen Servern führt jedoch zu fragmentierten Speicherpools und potenziellen Verwaltungskomplexitäten. Der lokale NVMe-Speicher ist nicht für die Datenfreigabe zwischen mehreren Servern konzipiert. Da der lokale NVMe-Speicher lokal ist, müssen Serveradministratoren sich mit Hardware- oder Software RAID (Redundant Array of Inexpensive Disks)vor Festplattenausfällen schützen. Andernfalls führt der Ausfall eines einzelnen NVMe-Geräts zu Datenverlust.
SAN-Speicher
SAN ist ein dediziertes Speichernetzwerk, das mehrere Server mit einem freigegebenen Pool von Speichergeräten verbindet, häufig SSDs oder zentralisierter NVMe-Speicher. SAN ist zwar nicht so schnell wie lokaler NVMe-Speicher, aber moderne SANs, insbesondere solche, die NVMe over Fabrics verwenden, bieten dennoch eine hervorragende Leistung für die meisten Arbeitslasten im Unternehmen.
SANs sind hochgradig skalierbar. Um mehr Speicherkapazität oder Leistung hinzuzufügen, fügen Sie neue Speicherarrays hinzu oder führen Sie ein Upgrade der vorhandenen durch. SANs bieten Redundanz auf der Speicherebene und schützen so vor Ausfällen von Speichermedien.
SANs eignen sich hervorragend für die Datenfreigabe. In Unternehmensumgebungen, die Hochverfügbarkeit erfordern, können mehrere Server auf Daten zugreifen und diese freigeben, die im SAN gespeichert sind. Bei einem Serverausfall können Sie SAN-Speicher auf einem anderen Server im Rechenzentrum bereitstellen, um die Wiederherstellung zu beschleunigen.