In diesem Dokument wird beschrieben, wie Sie sich auf die Ausführung von AlloyDB Omni in einer beliebigen Linux-Umgebung vorbereiten, die Container-Runtimes unterstützt.
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 wie die Anforderungen des Quelldatenbanksystems.
Beginnen Sie mit einer Bereitstellung mit passenden CPU-, RAM- und Festplattenressourcen und verwenden Sie die Konfiguration des Quellsystems als AlloyDB Omni-Basiskonfiguration. Möglicherweise können Sie Ihren 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 werden. Berücksichtigen Sie sowohl aktuelle Daten als auch das prognostizierte Wachstum im Zeitverlauf.
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 Reaktionszeiten für verschiedene Arten von Anfragen und Vorgängen.
Achten Sie darauf, dass Ihre Hardware die Größenanforderungen erfüllt.
CPU: AlloyDB Omni profitiert von Systemen mit mehreren CPU-Kernen und lässt sich je nach Arbeitslast linear skalieren. Open-Source-PostgreSQL profitiert jedoch in der Regel nicht von mehr als 16 vCPUs. Beachten Sie Folgendes:
- Die Anzahl der Kerne basierend auf der Parallelität der Arbeitslast und den Rechenanforderungen.
- Alle Vorteile, die sich aus einer Änderung der CPU-Generation oder ‑Plattform ergeben.
Arbeitsspeicher: Weisen Sie AlloyDB Omni ausreichend RAM für die freigegebenen Puffer zum Zwischenspeichern von Daten und Arbeitsspeicher für die Verarbeitung von Abfragen 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 Leistung oder SAN-Speicher für Skalierbarkeit und gemeinsame Datennutzung aus.
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, sollten Sie die Leistungsmerkmale Ihres Speichertyps berücksichtigen, um festzustellen, 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
| Betriebssystem/Plattform | Mindesthardware | Empfohlene Hardware |
|---|---|---|
| Linux |
|
|
| macOS |
|
|
- Wir empfehlen, ein dediziertes Solid-State-Laufwerk (SSD) 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 | Empfohlene Software |
|---|---|---|
| Linux1 |
|
|
| macOS |
|
|
- AlloyDB Omni geht davon aus, dass SELinux, sofern vorhanden, auf dem Host so konfiguriert ist, dass der Container ausgeführt werden kann, einschließlich des Zugriffs auf das Dateisystem (oder SELinux auf „permissive“ gesetzt ist).
Unterstützte Speichertypen
AlloyDB Omni unterstützt Dateisysteme auf Block-Storage-Volumes in Datenbankinstanzen. Bei kleineren Entwicklungs- oder Testsystemen verwenden Sie das lokale Dateisystem des Hosts, auf dem der Container ausgeführt wird. Verwenden Sie für Enterprise-Arbeitslasten Speicher, der für AlloyDB Omni-Instanzen reserviert ist. Konfigurieren Sie Ihre Speichergeräte je nach den Anforderungen Ihrer Datenbankarbeitslast entweder in einer Singleton-Konfiguration mit einem Laufwerkgerät für jeden Container oder in einer konsolidierten Konfiguration, in der mehrere Container Daten vom selben Laufwerkgerät lesen und darauf schreiben.
Lokaler NVMe- oder SAN-Speicher
Sowohl lokaler NVMe-Speicher (Non-Volatile Memory Express) als auch SAN-Speicher (Storage Area Network) bieten unterschiedliche Vorteile. Die Wahl der richtigen Lösung hängt von Ihren spezifischen Arbeitslastanforderungen, Ihrem Budget und Ihren zukünftigen Skalierbarkeitsanforderungen ab.
Berücksichtigen Sie Folgendes, um die beste Speicheroption zu ermitteln:
- Wenn Sie absolute Leistung priorisieren möchten, wählen Sie lokale NVMe aus.
- Wenn Sie 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 leistungsstarkes Protokoll, das für Solid-State-Laufwerke (SSDs) entwickelt wurde. Für Anwendungen, die einen schnellen Datenzugriff benötigen, bietet der lokale NVMe-Speicher die folgenden Vorteile:
- NVMe-SSDs werden direkt an den PCIe-Bus (Peripheral Component Interconnect Express) angeschlossen, um schnelle Lese- und Schreibgeschwindigkeiten zu ermöglichen.
- Lokaler NVMe-Speicher bietet die niedrigste Latenz.
- Lokaler NVMe-Speicher bietet den höchsten Durchsatz.
Um den lokalen NVMe-Speicher zu skalieren, müssen einzelnen Servern weitere Laufwerke hinzugefügt werden. Wenn Sie einzelnen Servern jedoch weitere Laufwerke hinzufügen, führt dies zu fragmentierten Speicherpools und potenziellen Verwaltungskomplexitäten. Lokaler NVMe-Speicher ist nicht für die gemeinsame Nutzung von Daten zwischen mehreren Servern konzipiert. Da der lokale NVMe-Speicher lokal ist, müssen Serveradministratoren sich mit Hardware oder Software vor Festplattenausfällen schützen, indem sie ein Redundant Array of Inexpensive Disks (RAID) verwenden. Andernfalls führt der Ausfall eines einzelnen NVMe-Geräts zu Datenverlust.
SAN-Speicher
Ein SAN ist ein dediziertes Speichernetzwerk, das mehrere Server mit einem gemeinsamen Pool von Speichergeräten verbindet, häufig SSDs oder zentralisierter NVMe-Speicher. SAN ist zwar nicht so schnell wie lokale NVMe, aber moderne SANs, insbesondere solche, die NVMe over Fabrics verwenden, bieten für die meisten Unternehmensarbeitslasten immer noch eine hervorragende Leistung.
SANs sind hochgradig skalierbar. Wenn Sie mehr Speicherkapazität oder Leistung benötigen, können Sie neue Speicher-Arrays hinzufügen oder vorhandene aktualisieren. 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 eine hohe Verfügbarkeit erfordern, können mehrere Server auf die im SAN gespeicherten Daten zugreifen und diese gemeinsam nutzen. Bei einem Serverausfall können Sie SAN-Speicher auf einem anderen Server im Rechenzentrum bereitstellen, was eine schnellere Wiederherstellung ermöglicht.