Ukuran dan kapasitas secara langsung memengaruhi performa, keandalan, dan efektivitas biaya instance AlloyDB Omni Anda. Saat Anda
memigrasikan database yang ada, resource CPU dan memori yang diperlukan serupa
dengan persyaratan sistem database sumber.
Rencanakan untuk memulai dengan deployment menggunakan CPU, RAM, dan resource disk yang cocok, serta gunakan konfigurasi sistem sumber sebagai konfigurasi dasar AlloyDB Omni. Anda mungkin dapat mengurangi konsumsi resource setelah melakukan pengujian yang memadai pada instance AlloyDB Omni.
Penentuan ukuran lingkungan AlloyDB Omni mencakup langkah-langkah berikut:
Tentukan beban kerja Anda.
Volume data: Perkirakan jumlah total data yang akan Anda simpan di
AlloyDB Omni. Pertimbangkan data saat ini dan pertumbuhan yang diproyeksikan dari waktu ke waktu.
Kecepatan transaksi: Tentukan perkiraan jumlah transaksi per detik (TPS), termasuk pembacaan, penulisan, pembaruan, dan penghapusan.
Serentak: Perkirakan jumlah pengguna atau koneksi serentak yang mengakses database.
Persyaratan performa: Tentukan waktu respons yang dapat diterima untuk berbagai jenis kueri dan operasi.
Pastikan hardware Anda mendukung persyaratan ukuran.
CPU: AlloyDB Omni diuntungkan dari sistem dengan beberapa core CPU, dan AlloyDB Omni menskalakan secara linear, bergantung pada beban kerja. Namun, PostgreSQL open source
umumnya tidak mendapatkan manfaat dari lebih dari 16 vCPU. Pertimbangkan
hal berikut:
Jumlah core berdasarkan konkurensi dan kebutuhan komputasi workload.
Peningkatan performa yang mungkin terjadi karena perubahan generasi atau platform CPU.
Memori: Alokasikan RAM yang cukup untuk buffer bersama AlloyDB Omni untuk menyimpan data dalam cache dan memori kerja untuk pemrosesan kueri. Persyaratan
yang tepat bergantung pada workload. Mulai dengan RAM 8 GB per vCPU.
Penyimpanan
Jenis: Berdasarkan kebutuhan Anda, pilih antara penyimpanan NVMe lokal untuk performa atau penyimpanan SAN untuk skalabilitas dan berbagi data.
Kapasitas: Pastikan penyimpanan yang cukup untuk volume data, indeks, Write-Ahead Log (WAL), cadangan, dan pertumbuhan di masa mendatang.
IOPS: Perkirakan operasi input/output per detik (IOPS) yang diperlukan berdasarkan pola baca dan tulis beban kerja Anda. Saat menjalankan AlloyDB Omni di cloud publik, pertimbangkan karakteristik performa jenis penyimpanan Anda untuk memahami apakah Anda perlu meningkatkan kapasitas penyimpanan untuk memenuhi target IOPS tertentu.
Prasyarat untuk menjalankan AlloyDB Omni
Sebelum menjalankan AlloyDB Omni, pastikan Anda memenuhi persyaratan hardware dan software berikut.
Sebaiknya gunakan perangkat penyimpanan solid-state drive (SSD) khusus untuk menyimpan data Anda. Jika Anda menggunakan perangkat fisik untuk tujuan ini, sebaiknya hubungkan langsung ke mesin host.
Kernel Linux versi 6.1+, atau versi kernel Linux apa pun yang lebih lama dari 5.3 yang memiliki dukungan untuk direktif MADV_COLLAPSE dan MADV_POPULATE_WRITE
Cgroupsv2 diaktifkan
Docker Engine 25.0.0+ atau Podman 5.0.0+
macOS
Docker Desktop 4.20+
Docker Desktop 4.30+
AlloyDB Omni mengasumsikan bahwa SELinux, jika ada, dikonfigurasi di host untuk mengizinkan container berjalan, termasuk akses ke sistem file (atau SELinux disetel ke permisif).
Jenis penyimpanan yang didukung
AlloyDB Omni mendukung sistem file pada volume penyimpanan blok
di instance database. Untuk sistem pengembangan atau uji coba yang lebih kecil, gunakan sistem file lokal host tempat container berjalan. Untuk beban kerja perusahaan, gunakan penyimpanan yang dicadangkan untuk instance AlloyDB Omni. Bergantung pada permintaan yang ditetapkan oleh beban kerja database Anda, konfigurasikan perangkat penyimpanan Anda dalam konfigurasi singleton dengan satu perangkat disk untuk setiap penampung, atau dalam konfigurasi gabungan tempat beberapa penampung membaca dan menulis dari perangkat disk yang sama.
Penyimpanan NVMe atau SAN lokal
Penyimpanan Non-Volatile Memory Express (NVMe) lokal dan penyimpanan Jaringan Area Penyimpanan (SAN) menawarkan keunggulan yang berbeda. Memilih solusi yang tepat bergantung pada
persyaratan workload, anggaran, dan kebutuhan skalabilitas di masa mendatang.
Untuk menentukan opsi penyimpanan terbaik, pertimbangkan hal berikut:
Untuk memprioritaskan performa absolut, pilih NVMe lokal.
Jika Anda memerlukan penyimpanan bersama berskala besar, pilih SAN.
Jika Anda perlu menyeimbangkan performa dan berbagi, pertimbangkan SAN dengan NVMe over Fabrics untuk akses yang lebih cepat.
Penyimpanan NVMe lokal
NVMe adalah protokol berperforma tinggi yang dirancang untuk solid-state drive (SSD). Untuk aplikasi yang memerlukan akses data cepat, penyimpanan NVMe lokal menawarkan manfaat berikut:
SSD NVMe terhubung langsung ke bus Peripheral Component Interconnect Express (PCIe) untuk memberikan kecepatan baca dan tulis yang cepat.
Penyimpanan NVMe lokal memberikan latensi terendah.
Penyimpanan NVMe lokal memberikan throughput tertinggi.
Menskalakan penyimpanan NVMe lokal memerlukan penambahan lebih banyak drive ke setiap server.
Namun, menambahkan lebih banyak drive ke server individual akan menyebabkan kumpulan penyimpanan yang terfragmentasi dan potensi kompleksitas pengelolaan. Penyimpanan NVMe lokal tidak dirancang untuk berbagi data di antara beberapa server. Karena penyimpanan NVMe lokal bersifat lokal, administrator server harus melindungi dari kegagalan disk menggunakan hardware atau software Redundant Array of Inexpensive Disks (RAID).
Jika tidak, kegagalan satu perangkat NVMe akan menyebabkan hilangnya data.
Penyimpanan SAN
SAN adalah jaringan penyimpanan khusus yang menghubungkan beberapa server ke kumpulan perangkat penyimpanan bersama, sering kali SSD atau penyimpanan NVMe terpusat. Meskipun SAN tidak secepat NVMe lokal, SAN modern, terutama yang menggunakan NVMe over Fabrics, tetap memberikan performa yang sangat baik untuk sebagian besar beban kerja perusahaan.
SAN sangat skalabel. Untuk menambahkan kapasitas atau performa penyimpanan, tambahkan array penyimpanan baru atau upgrade array penyimpanan yang ada. SAN menyediakan redundansi di lapisan penyimpanan, sehingga memberikan perlindungan terhadap kegagalan media penyimpanan.
SAN unggul dalam berbagi data. Untuk lingkungan perusahaan yang memerlukan ketersediaan
tinggi, beberapa server dapat mengakses dan membagikan data yang disimpan di SAN.
Jika terjadi kegagalan server, Anda dapat menyajikan penyimpanan SAN ke server lain di pusat data, sehingga memungkinkan pemulihan yang lebih cepat.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[[["\u003cp\u003eAlloyDB Omni's performance, reliability, and cost-effectiveness are directly impacted by its size and capacity, so matching the CPU, RAM, and disk resources of your existing database when migrating is recommended as a baseline.\u003c/p\u003e\n"],["\u003cp\u003eWhen sizing an AlloyDB Omni environment, you must define your workload by estimating data volume, transaction rates, concurrency, and performance requirements, and you must also ensure that your hardware meets these sizing requirements.\u003c/p\u003e\n"],["\u003cp\u003eThe minimum hardware requirements for AlloyDB Omni include an x86-64 or ARM CPU with AVX2 support, 2GB of RAM, and 10GB of disk space for Linux or macOS, while the recommended hardware is 8GB of RAM per vCPU and 20GB+ of disk space.\u003c/p\u003e\n"],["\u003cp\u003eFor software, Linux requires one of several specified OS versions, a Linux kernel version 4.18+ (or 6.1+ for recommended), Cgroups v1 or v2 enabled (v2 recommended), and Docker Engine 20.10+ or Podman 4.2.0+, while macOS requires Docker Desktop 4.20+ (4.30+ recommended).\u003c/p\u003e\n"],["\u003cp\u003eFor storage, local NVMe is recommended for absolute performance with direct connection to the PCIe bus, while SAN storage is ideal for large-scale shared storage and offers redundancy and high availability for enterprise environments.\u003c/p\u003e\n"]]],[],null,["# Plan your AlloyDB Omni installation on a VM\n\nSelect a documentation version: Current (16.8.0)keyboard_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/current/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/current/docs/quickstart)"]]
