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.
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.
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.
Linux-Kernel-Version 6.1 oder höher oder eine beliebige Linux-Kernel-Version vor 5.3, die die Direktiven MADV_COLLAPSE und MADV_POPULATE_WRITE unterstützt
Cgroupsv2 aktiviert
Docker Engine 25.0.0+ oder Podman 5.0.0+
macOS
Docker Desktop 4.20 und höher
Docker Desktop 4.30 und höher
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eAlloyDB Omni's performance, reliability, and cost-effectiveness are directly impacted by its size and capacity, so when migrating an existing database, start with CPU, RAM, and disk resources similar to the source database, with the potential to reduce consumption after testing.\u003c/p\u003e\n"],["\u003cp\u003eProperly sizing an AlloyDB Omni environment involves defining the workload, including data volume, transaction rate, concurrency, and performance requirements, then ensuring the hardware supports these needs.\u003c/p\u003e\n"],["\u003cp\u003eFor running AlloyDB Omni, the minimum hardware requirements for both Linux and macOS are an x86-64 or ARM CPU with AVX2 support (or Intel/M-chip for macOS), 2GB of RAM, and 10GB of disk space, with 8GB of RAM per vCPU and 20GB+ of disk space recommended.\u003c/p\u003e\n"],["\u003cp\u003eAlloyDB Omni supports file systems on block storage volumes, with local file systems suitable for development and trial systems, while enterprise workloads should use storage reserved specifically for AlloyDB Omni instances.\u003c/p\u003e\n"],["\u003cp\u003eLocal NVMe storage is best for prioritizing absolute performance with fast data access and low latency, while SAN storage is preferred for large-scale, shared storage needs and high availability.\u003c/p\u003e\n"]]],[],null,["# Plan your AlloyDB Omni installation on a VM\n\nSelect a documentation version: 15.7.1keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/plan-installation)\n- [16.8.0](/alloydb/omni/16.8.0/docs/plan-installation)\n- [16.3.0](/alloydb/omni/16.3.0/docs/plan-installation)\n- [15.12.0](/alloydb/omni/15.12.0/docs/plan-installation)\n- [15.7.1](/alloydb/omni/15.7.1/docs/plan-installation)\n- [15.7.0](/alloydb/omni/15.7.0/docs/plan-installation)\n\n\u003cbr /\u003e\n\nThis document describes how to prepare for running AlloyDB Omni in any Linux environment that supports container runtimes.\n\n\u003cbr /\u003e\n\nFor an overview of AlloyDB Omni, see\n[AlloyDB Omni overview](/alloydb/omni/15.7.1/docs/overview).\n\nSize and capacity\n-----------------\n\nSize and capacity directly affects the performance, reliability, and\ncost-effectiveness of your AlloyDB Omni instance. When you\nmigrate an existing database, the CPU and memory resources required are similar\nto the requirements of the source database system.\n\nPlan to start with a deployment using matching CPU, RAM and disk resources,\nand use the source system configuration as the AlloyDB Omni\nbaseline configuration. You might be able to reduce your resource\nconsumption after you perform sufficient testing of your\nAlloyDB Omni instance.\n\nSizing a AlloyDB Omni environment includes the following steps:\n\n1. Define your workload.\n\n - Data volume: Estimate the total amount of data you'll store in\n AlloyDB Omni. Consider both current data and projected\n growth over time.\n\n - Transaction rate: Determine the expected number of transactions per\n second (TPS), including reads, writes, updates, and deletes.\n\n - Concurrency: Estimate the number of concurrent users or connections\n accessing the database.\n\n - Performance requirements: Define your acceptable response times for\n different types of queries and operations.\n\n2. Ensure that your hardware supports sizing requirements.\n\n - CPU: AlloyDB Omni benefits from systems with multiple\n CPU cores, and AlloyDB Omni scales linearly, depending on the\n workload. However, open source PostgreSQL\n generally doesn't benefit from greater than 16 vCPUs. Take the\n following into consideration:\n\n - The number of cores based on workload concurrency and computation needs.\n - Any gains that might be present due to a change in CPU generation or platform.\n - Memory: Allocate sufficient RAM for AlloyDB Omni's shared\n buffers for caching data and working memory for query processing. The\n exact requirement depends on the workload. Start with 8 GB of RAM per\n vCPU.\n\n - Storage\n\n - Type: Based on your needs, choose between local NVMe storage for\n performance or SAN storage for scalability and data sharing.\n\n - Capacity: Ensure enough storage for your data volume, indexes,\n Write-Ahead Log (WAL), backups, and future growth.\n\n - IOPS: Estimate the required input/output operations per second\n (IOPS) based on your workload's read and write patterns. When\n running AlloyDB Omni in a public cloud, consider\n the performance characteristics of your storage type to\n understand if you need to increase storage capacity to meet a\n specific IOPS target.\n\nPrerequisites for running AlloyDB Omni\n--------------------------------------\n\nBefore you run AlloyDB Omni, make sure that you meet the\nfollowing hardware and software requirements.\n\n### Hardware requirements\n\n1. We recommend that you use a dedicated solid-state drive (SSD) storage device for storing your data. If you use a physical device for this purpose, we recommend that you attach it directly to the host machine.\n\n| **Tip:** To install AlloyDB Omni on a cloud platform, we recommend that you use instances that maintain the ratio of 8GB of RAM per vCPU.\n| **Note:** AlloyDB Omni is compiled to run directly on Linux systems. Running AlloyDB Omni in a Docker container on macOS utilizes Docker's compatibility layer, which results in reduced performance compared to running directly on Linux.\n\n### Software requirements\n\n1. AlloyDB Omni assumes that SELinux, when present, is configured on the host to permit the container to run, including access to the file system (or SELinux is set to permissive).\n\nSupported storage types\n-----------------------\n\nAlloyDB Omni supports file systems on block storage volumes\nin database instances. For smaller development or trial systems, use the local\nfile system of the host where the container is running. For enterprise\nworkloads, use storage that is reserved for AlloyDB Omni\ninstances. Depending on the demands set by your database workload, configure\nyour storage devices either in a singleton configuration with one disk device\nfor each container, or in a consolidated configuration where multiple containers\nread and write from the same disk device.\n\n### Local NVMe or SAN storage\n\nBoth local Non-Volatile Memory Express (NVMe) storage and Storage Area Network\n(SAN) storage offer distinct advantages. Choosing the right solution depends on\nyour specific workload requirements, budget, and future scalability needs.\n\nTo determine the best storage option, consider the following:\n\n- To prioritize absolute performance, choose local NVMe.\n- If you need large-scale, shared storage, choose SAN.\n- If you need to balance performance and sharing, consider SAN with NVMe over Fabrics for faster access.\n\n### Local NVMe storage\n\nNVMe is a high-performance protocol designed for solid-state drives (SSDs). For\napplications that need fast data access, local NVMe storage offers the following\nbenefits:\n\n- NVMe SSDs connect directly to the Peripheral Component Interconnect express (PCIe) bus to deliver fast read and write speeds.\n- Local NVMe storage provides the lowest latency.\n- Local NVMe storage provides the highest throughput.\n\nScaling local NVMe storage requires adding more drives to individual servers.\nHowever, adding more drives to individual servers leads to fragmented storage\npools and potential management complexities. Local NVMe storage isn't designed\nfor data sharing between multiple servers. Since local NVMe storage is local,\nserver administrators must protect against disk failures using hardware or\nsoftware\n[Redundant Array of Inexpensive Disks (RAID)](https://en.wikipedia.org/wiki/Standard_RAID_levels).\nOtherwise, the failure of a single NVMe device will result in data loss.\n\n### SAN storage\n\nSAN is a dedicated storage network that connects multiple servers to a shared\npool of storage devices, often SSDs or centralized NVMe storage. While SAN isn't\nas fast as local NVMe, modern SANs, especially those using NVMe over Fabrics,\nstill deliver excellent performance for most enterprise workloads.\n\n- SANs are highly scalable. To add more storage capacity or\n performance, add new storage arrays or upgrading existing ones. SANs provide\n redundancy at the storage layer, providing protection against storage media\n failures.\n\n- SANs excel at data sharing. For enterprise environments that require high\n availability, multiple servers can access and share data stored on the SAN.\n In the event of a server failure, you can present SAN storage to another\n server in the data center, allowing for faster recovery.\n\nWhat's next\n-----------\n\n- [Install AlloyDB Omni](/alloydb/omni/15.7.1/docs/quickstart)"]]
