Dokumen ini memberikan arsitektur referensi untuk aplikasi perusahaan yang memiliki ketersediaan tinggi yang dihosting di virtual machine (VM) Compute Engine dengan konektivitas latensi rendah ke database Exadata Oracle Cloud Infrastructure (OCI) yang berjalan di Google Cloud. Audiens yang dituju untuk dokumen ini adalah arsitek cloud dan administrator database Oracle. Dokumen ini mengasumsikan bahwa Anda sudah memahami Compute Engine dan Layanan Database Oracle Exadata.
Jika menggunakan Oracle Exadata atau Oracle Real Application Clusters (Oracle RAC) untuk menjalankan database Oracle di lokal, Anda dapat memigrasikan aplikasi ke Google Cloud secara efisien dan menjalankan database di Oracle Database@Google Cloud. Oracle Database@Google Cloud adalah penawaran Google Cloud Marketplace yang memungkinkan Anda menjalankan Oracle Exadata Database Service dan Oracle Autonomous Database langsung di dalam Google Cloud.
Jika Anda tidak memerlukan kemampuan Oracle RAC atau jika Anda memerlukan versi Database Oracle selain 19c dan 23ai, Anda dapat menjalankan database Oracle yang dikelola sendiri di VM Compute Engine. Untuk informasi selengkapnya, lihat Aplikasi perusahaan dengan Oracle Database di Compute Engine.
Arsitektur
Diagram berikut menunjukkan tampilan tingkat tinggi arsitektur:
Pada diagram sebelumnya, load balancer eksternal menerima permintaan dari pengguna aplikasi yang ditampilkan kepada publik dan mendistribusikan permintaan ke server web frontend. Server web meneruskan permintaan pengguna melalui load balancer internal ke server aplikasi. Server aplikasi membaca data dari dan menulis ke database di Oracle Database@Google Cloud. Administrator dan layanan OCI dapat terhubung dan berinteraksi dengan database Oracle.
Diagram berikut menunjukkan tampilan mendetail tentang arsitektur:
Dalam arsitektur ini, tingkat web dan tingkat aplikasi berjalan dalam mode aktif-aktif di VM Compute Engine yang didistribusikan di dua zona dalam region Google Cloud. Aplikasi ini menggunakan database Oracle Exadata di region Google Cloud yang sama.
Semua komponen dalam arsitektur berada dalam satu region Google Cloud. Arsitektur ini selaras dengan arketipe deployment regional. Anda dapat menyesuaikan arsitektur ini untuk membuat topologi yang tahan terhadap pemadaman layanan regional menggunakan arketipe deployment multi-regional. Untuk mengetahui informasi selengkapnya, lihat Deployment multi-regional di Compute Engine dan juga panduan di bagian Keandalan nanti dalam dokumen ini.
Arsitektur yang ditampilkan dalam diagram sebelumnya mencakup komponen berikut:
Komponen | Tujuan |
---|---|
Load Balancer Aplikasi eksternal regional | Load Balancer Aplikasi eksternal regional menerima permintaan pengguna dan mendistribusikannya ke VM tingkat web. |
Kebijakan keamanan Google Cloud Armor | Kebijakan keamanan Google Cloud Armor membantu melindungi stack aplikasi Anda dari ancaman seperti serangan distributed denial-of-service (DDoS) dan pembuatan skrip lintas situs (XSS). |
Grup instance terkelola (MIG) regional untuk tingkat web | Tingkat web aplikasi di-deploy di VM Compute Engine yang merupakan bagian dari MIG regional. MIG ini adalah backend untuk Load Balancer Aplikasi eksternal. MIG berisi VM Compute Engine di dua zona. Setiap VM ini menghosting instance independen dari tingkat web aplikasi. |
Load Balancer Aplikasi internal regional | Load Balancer Aplikasi internal regional mendistribusikan traffic dari VM tingkat web ke VM tingkat aplikasi. |
MIG regional untuk tingkat aplikasi | Tingkat aplikasi, seperti cluster Oracle WebLogic Server, di-deploy di VM Compute Engine yang merupakan bagian dari MIG regional. MIG ini adalah backend untuk Load Balancer Aplikasi internal. MIG berisi VM Compute Engine di dua zona. Setiap VM menghosting instance server aplikasi yang independen. |
Jaringan Virtual Private Cloud (VPC) dan subnet | Semua resource Google Cloud dalam arsitektur menggunakan satu jaringan VPC. Bergantung pada persyaratan, Anda dapat memilih untuk membuat arsitektur yang menggunakan beberapa jaringan. Untuk informasi selengkapnya, lihat Menentukan apakah akan membuat beberapa jaringan VPC. |
Oracle Database@Google Cloud |
Server aplikasi membaca data dari dan menulis ke database Oracle di Oracle Exadata Database Service. Anda menyediakan Layanan Database Exadata Oracle menggunakan Oracle Database@Google Cloud, penawaran Cloud Marketplace yang memungkinkan Anda menjalankan database Oracle di hardware yang dikelola Oracle dalam pusat data Google Cloud. Anda menggunakan antarmuka Google Cloud seperti konsol Google Cloud, Google Cloud CLI, dan API untuk membuat instance Exadata Infrastructure. Oracle menyiapkan dan mengelola infrastruktur komputasi, penyimpanan, dan jaringan yang diperlukan di pusat data dalam region Google Cloud pada hardware yang didedikasikan untuk project Anda. |
Instance Exadata Infrastructure | Setiap instance Infrastruktur Exadata berisi dua server database fisik atau lebih dan tiga server penyimpanan atau lebih. Server ini, yang tidak ditampilkan dalam diagram, saling terhubung menggunakan fabric jaringan latensi rendah. Saat membuat instance Infrastruktur Exadata, Anda menentukan jumlah server database dan server penyimpanan yang harus disediakan. |
Cluster VM Exadata |
Dalam instance Infrastruktur Exadata, Anda membuat satu atau beberapa Cluster VM Exadata. Misalnya, Anda dapat memilih untuk membuat dan menggunakan Cluster VM Exadata terpisah untuk menghosting database yang diperlukan untuk setiap unit bisnis Anda. Setiap Cluster VM Exadata berisi satu atau beberapa VM Oracle Linux yang menghosting instance Oracle Database. Saat membuat Cluster VM Exadata, Anda menentukan hal berikut:
VM dalam Cluster VM Exadata bukan VM Compute Engine. |
Instance Database Oracle | Anda membuat dan mengelola database Oracle melalui konsol OCI dan antarmuka OCI lainnya. Software Database Oracle berjalan di VM dalam Cluster VM Exadata. Saat membuat Cluster VM Exadata, Anda menentukan versi Oracle Grid Infrastructure. Anda juga dapat memilih jenis lisensi: bring your own license (BYOL) atau memilih model yang menyertakan lisensi. |
VCN OCI dan subnet | Saat Anda membuat Cluster VM Exadata, jaringan virtual cloud (VCN) OCI akan dibuat secara otomatis. VCN memiliki subnet klien dan subnet cadangan dengan rentang alamat IP yang Anda tentukan. Subnet klien digunakan untuk konektivitas dari jaringan VPC Anda ke database Oracle. Subnet cadangan digunakan untuk mengirim cadangan database ke OCI Object Storage. |
Cloud Router, Partner Interconnect, dan OCI DRG | Traffic antara jaringan VPC dan VCN dirutekan oleh Cloud Router yang dilampirkan ke VPC dan melalui gateway perutean dinamis (DRG) yang dilampirkan ke VCN. Traffic mengalir melalui koneksi latensi rendah yang disiapkan Google menggunakan Partner Interconnect. |
Zona Cloud DNS pribadi | Saat Anda membuat Cluster VM Exadata, zona pribadi Cloud DNS akan dibuat secara otomatis. Saat server aplikasi Anda mengirim permintaan baca dan tulis ke database Oracle, Cloud DNS me-resolve nama host database ke alamat IP yang sesuai. |
OCI Object Storage dan OCI Service Gateway | Secara default, cadangan database Oracle Exadata disimpan di OCI Object Storage. Pencadangan database dirutekan ke OCI Object Storage melalui Service Gateway. |
Gateway Cloud NAT publik | Arsitektur ini mencakup gateway Cloud NAT publik untuk mengaktifkan koneksi keluar yang aman dari VM Compute Engine, yang hanya memiliki alamat IP internal. |
Cloud Interconnect dan Cloud VPN | Untuk menghubungkan jaringan lokal ke jaringan VPC di Google Cloud, Anda dapat menggunakan Cloud Interconnect atau Cloud VPN. Untuk mengetahui informasi tentang keunggulan relatif setiap pendekatan, lihat Memilih produk Network Connectivity. |
Cloud Monitoring | Anda dapat menggunakan Cloud Monitoring untuk mengamati perilaku, kondisi, dan performa aplikasi serta resource Google Cloud, termasuk resource Oracle Exadata. Anda juga dapat memantau resource di resource Oracle Exadata menggunakan layanan OCI Monitoring. |
Produk yang digunakan
Arsitektur referensi ini menggunakan produk Google Cloud berikut:
- Compute Engine: Layanan komputasi yang aman dan dapat disesuaikan yang memungkinkan Anda membuat dan menjalankan VM di infrastruktur Google.
- Cloud Load Balancing: Portofolio load balancer global dan regional yang skalabel, berperforma tinggi, dan andal.
- Virtual Private Cloud (VPC): Sistem virtual yang menyediakan fungsi jaringan global dan skalabel untuk beban kerja Google Cloud Anda. VPC mencakup Peering Jaringan VPC, Private Service Connect, akses layanan pribadi, dan VPC Bersama.
- Google Cloud Armor: Layanan keamanan jaringan yang menawarkan aturan firewall aplikasi web (WAF) dan membantu melindungi dari serangan DDoS dan aplikasi.
- Cloud NAT: Layanan yang menyediakan penafsiran alamat jaringan berperforma tinggi yang dikelola Google Cloud.
- Cloud Monitoring: Layanan yang memberikan visibilitas terkait performa, ketersediaan, dan kondisi aplikasi serta infrastruktur Anda.
- Cloud Interconnect: Layanan yang memperluas jaringan eksternal Anda ke jaringan Google melalui koneksi latensi rendah yang sangat tersedia.
- Partner Interconnect: Layanan yang menyediakan konektivitas antara jaringan lokal dan jaringan Virtual Private Cloud Anda serta jaringan lainnya melalui penyedia layanan yang didukung.
- Cloud VPN: Layanan yang memperluas jaringan peer Anda dengan aman ke jaringan Google melalui tunnel VPN IPsec.
Arsitektur referensi ini menggunakan produk OCI berikut:
- Layanan Database Exadata di Infrastruktur Khusus: Layanan yang memungkinkan Anda menjalankan instance Database Oracle di hardware Exadata yang khusus untuk Anda.
- Penyimpanan Objek: Layanan untuk menyimpan data terstruktur dan tidak terstruktur dalam jumlah besar sebagai objek.
- VCN dan subnet: VCN adalah jaringan virtual dan pribadi untuk resource di region OCI. Subnet adalah rentang alamat IP yang berdekatan dengan VCN.
- Dynamic Routing Gateway: Router virtual untuk traffic antara VCN dan jaringan eksternal.
- Service Gateway: Gateway untuk memungkinkan resource di VCN mengakses layanan Oracle tertentu secara pribadi.
Pertimbangan desain
Bagian ini menjelaskan faktor desain, praktik terbaik, dan rekomendasi desain yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mengembangkan topologi yang memenuhi persyaratan spesifik Anda untuk keamanan, keandalan, efisiensi operasional, biaya, dan performa.
Panduan di bagian ini tidak lengkap. Bergantung pada persyaratan khusus aplikasi Anda serta produk dan fitur Google Cloud dan pihak ketiga yang Anda gunakan, mungkin ada faktor desain dan kompromi tambahan yang harus Anda pertimbangkan.
Desain sistem
Bagian ini memberikan panduan untuk membantu Anda memilih region Google Cloud untuk deployment dan memilih layanan Google Cloud yang sesuai.
Pemilihan region
Saat memilih region Google Cloud untuk deployment, pertimbangkan faktor dan persyaratan berikut:
- Ketersediaan layanan Google Cloud di setiap region. Untuk mengetahui informasi selengkapnya, lihat Produk yang tersedia berdasarkan lokasi.
- Ketersediaan jenis mesin Compute Engine di setiap region. Untuk mengetahui informasi selengkapnya, lihat Region dan zona.
- Ketersediaan Oracle Database@Google Cloud di setiap region. Untuk informasi selengkapnya, lihat Konfigurasi yang tersedia.
- Persyaratan latensi pengguna akhir.
- Biaya resource Google Cloud.
- Persyaratan peraturan.
Beberapa faktor dan persyaratan ini mungkin melibatkan konsekuensi negatif. Misalnya, wilayah yang paling hemat biaya mungkin tidak memiliki jejak karbon terendah. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk pemilihan region Compute Engine.
Infrastruktur komputasi
Arsitektur referensi dalam dokumen ini menggunakan VM Compute Engine untuk menghosting tingkat web dan tingkat aplikasi. Bergantung pada persyaratan aplikasi, Anda dapat memilih layanan komputasi Google Cloud lainnya berikut:
- Container: Anda dapat menjalankan aplikasi dalam container di cluster Google Kubernetes Engine (GKE). GKE adalah mesin orkestrasi container yang mengotomatiskan deployment, penskalaan, dan pengelolaan aplikasi dalam container.
- Serverless: Jika Anda lebih memilih untuk memfokuskan upaya IT pada data dan aplikasi, bukan pada penyiapan dan pengoperasian resource infrastruktur, Anda dapat menggunakan layanan serverless seperti Cloud Run dan Cloud Run functions.
Keputusan untuk menggunakan VM, penampung, atau layanan serverless melibatkan kompromi antara fleksibilitas konfigurasi dan upaya pengelolaan. VM dan penampung memberikan lebih banyak fleksibilitas dan kontrol konfigurasi, tetapi Anda bertanggung jawab untuk mengelola resource. Dalam arsitektur serverless, Anda men-deploy beban kerja ke platform yang telah dikonfigurasi sebelumnya dan memerlukan upaya pengelolaan minimal. Panduan desain untuk layanan tersebut berada di luar cakupan dokumen ini. Untuk mengetahui informasi selengkapnya tentang opsi layanan, lihat Menghosting Aplikasi di Google Cloud.
Opsi penyimpanan
Untuk menyediakan penyimpanan persisten bagi VM Compute Engine di tingkat web dan tingkat aplikasi, pilih jenis Persistent Disk atau Hyperdisk Google Cloud yang sesuai berdasarkan persyaratan aplikasi Anda untuk kapasitas, penskalaan, ketersediaan, dan performa. Untuk mengetahui informasi selengkapnya, lihat Opsi penyimpanan.
Jika Anda memerlukan penyimpanan berbiaya rendah yang redundan di seluruh zona dalam suatu region, gunakan bucket regional Cloud Storage.
Untuk menyimpan data yang dibagikan di beberapa VM dalam satu region, seperti file konfigurasi untuk semua VM di tingkat web, Anda dapat menggunakan instance Filestore Regional. Data yang Anda simpan di instance Filestore Regional direplikasi secara sinkron di tiga zona dalam region tersebut. Replikasi ini membantu memastikan ketersediaan tinggi dan ketahanan terhadap pemadaman layanan zona untuk data yang Anda simpan di Filestore. Anda dapat menyimpan file konfigurasi bersama, alat dan utilitas umum, serta log terpusat di instance Filestore, dan memasang instance di beberapa VM.
Saat Anda mendesain penyimpanan untuk workload, pertimbangkan karakteristik fungsional workload, persyaratan ketahanan, ekspektasi performa, dan sasaran biaya. Untuk informasi selengkapnya, lihat Mendesain strategi penyimpanan yang optimal untuk workload cloud Anda.
Desain jaringan
Saat membuat infrastruktur untuk stack aplikasi multi-lapis, Anda harus memilih desain jaringan yang memenuhi persyaratan bisnis dan teknis Anda. Arsitektur yang ditampilkan dalam dokumen ini menggunakan topologi jaringan sederhana dengan satu jaringan VPC. Bergantung pada persyaratan, Anda dapat memilih untuk menggunakan beberapa jaringan. Untuk informasi selengkapnya, lihat dokumentasi berikut:
- Menentukan apakah akan membuat beberapa jaringan VPC atau tidak
- Menentukan desain jaringan untuk zona landing Google Cloud Anda
Saat Anda menetapkan rentang alamat IP untuk klien dan subnet cadangan yang akan digunakan untuk Cluster VM Exadata, pertimbangkan persyaratan ukuran subnet minimum. Untuk mengetahui informasi selengkapnya, lihat Merencanakan Ruang Alamat IP di Oracle Database@Google Cloud.
Migrasi database
Saat Anda berencana memigrasikan database lokal ke Oracle Database@Google Cloud, nilai lingkungan database Anda saat ini dan dapatkan rekomendasi konfigurasi dan ukuran dengan menggunakan alat Database Migration Assessment (DMA).
Untuk memigrasikan data di infrastruktur lokal ke deployment database Oracle di Google Cloud, Anda dapat menggunakan alat Oracle standar seperti Oracle GoldenGate.
Sebelum menggunakan database yang dimigrasikan di lingkungan produksi, verifikasi konektivitas dari aplikasi Anda ke database.
Keamanan
Bagian ini menjelaskan faktor-faktor yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk mendesain topologi di Google Cloud yang memenuhi persyaratan keamanan dan kepatuhan workload Anda.
Perlindungan terhadap ancaman eksternal
Untuk melindungi aplikasi Anda dari ancaman eksternal seperti serangan DDoS dan XSS, tentukan kebijakan keamanan Google Cloud Armor yang sesuai berdasarkan persyaratan Anda. Setiap kebijakan adalah serangkaian aturan yang menentukan kondisi yang akan dievaluasi dan tindakan yang akan diambil saat kondisi terpenuhi. Misalnya, aturan dapat menentukan bahwa jika alamat IP sumber traffic masuk cocok dengan alamat IP atau rentang CIDR tertentu, traffic harus ditolak. Anda juga dapat menerapkan aturan WAF yang telah dikonfigurasi sebelumnya. Untuk mengetahui informasi selengkapnya, lihat Ringkasan kebijakan keamanan.
Akses eksternal untuk VM
Dalam arsitektur referensi yang dijelaskan dalam dokumen ini, VM yang menghosting tingkat web dan tingkat aplikasi tidak memerlukan akses masuk langsung dari internet. Jangan menetapkan alamat IP eksternal ke VM tersebut. Resource Google Cloud yang hanya memiliki alamat IP internal pribadi masih dapat mengakses API dan layanan Google tertentu menggunakan Private Service Connect atau Akses Google Pribadi. Untuk informasi selengkapnya, lihat Opsi akses pribadi untuk layanan.
Untuk mengaktifkan koneksi keluar yang aman dari resource Google Cloud yang hanya memiliki alamat IP pribadi, seperti VM Compute Engine dalam arsitektur referensi ini, Anda dapat menggunakan Cloud NAT seperti yang ditunjukkan dalam diagram arsitektur sebelumnya, atau menggunakan Secure Web Proxy.
Untuk subnet yang digunakan oleh VM Exadata, Oracle merekomendasikan agar Anda menetapkan rentang alamat IP pribadi.
Keamanan image VM
Gambar yang disetujui adalah gambar dengan software yang memenuhi kebijakan atau persyaratan keamanan Anda. Untuk memastikan bahwa VM Anda di tingkat web dan tingkat aplikasi hanya menggunakan image yang disetujui, Anda dapat menentukan kebijakan organisasi yang membatasi penggunaan image dalam project image publik tertentu. Untuk informasi selengkapnya, lihat Menyiapkan kebijakan image tepercaya.
Hak istimewa akun layanan
Di project Google Cloud tempat Compute Engine API diaktifkan, akun layanan default akan dibuat secara otomatis. Untuk organisasi Google Cloud yang dibuat sebelum 3 Mei 2024, akun layanan default ini diberi peran IAM Editor (roles/editor
), kecuali jika perilaku ini dinonaktifkan.
Secara default, akun layanan default dilampirkan ke semua VM Compute Engine yang Anda buat menggunakan gcloud CLI atau Konsol Google Cloud. Peran Editor mencakup berbagai izin, sehingga melampirkan akun layanan default ke VM akan menimbulkan risiko keamanan. Untuk menghindari risiko ini, Anda dapat membuat dan menggunakan akun layanan khusus untuk setiap tingkat stack aplikasi. Untuk menentukan resource yang dapat diakses akun layanan, gunakan kebijakan terperinci. Untuk mengetahui informasi selengkapnya, lihat Membatasi hak istimewa akun layanan.
Keamanan jaringan
Untuk mengontrol traffic jaringan di antara resource di tingkat web dan tingkat aplikasi arsitektur, Anda harus mengonfigurasi kebijakan Cloud Next Generation Firewall (NGFW) yang sesuai.
Keamanan dan kepatuhan database
Layanan Database Exadata mencakup Oracle Data Safe, yang membantu Anda mengelola persyaratan keamanan dan kepatuhan untuk database Oracle. Anda dapat menggunakan Oracle Data Safe untuk mengevaluasi kontrol keamanan, memantau aktivitas pengguna, dan menyamarkan data sensitif. Untuk mengetahui informasi selengkapnya, lihat Mengelola Keamanan Database dengan Oracle Data Safe.
Pertimbangan keamanan lainnya
Saat membuat arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi keamanan tingkat platform yang diberikan dalam Blueprint fondasi perusahaan.
Keandalan
Bagian ini menjelaskan faktor desain yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk membuat dan mengoperasikan infrastruktur yang andal untuk deployment di Google Cloud.
Ketahanan terhadap kegagalan VM
Dalam arsitektur yang ditampilkan dalam dokumen ini, jika VM Compute Engine di tingkat web atau tingkat aplikasi mengalami error, MIG yang relevan akan membuat ulang VM secara otomatis. Load balancer meneruskan permintaan hanya ke instance server web dan instance server aplikasi yang saat ini tersedia.
Autohealing VM
Terkadang, VM yang menghosting tingkat web dan tingkat aplikasi Anda mungkin berjalan dan tersedia, tetapi mungkin ada masalah dengan aplikasi itu sendiri. Aplikasi mungkin berhenti berfungsi, error, atau tidak memiliki cukup memori. Dalam skenario ini, VM tidak akan merespons health check load balancer, dan load balancer tidak akan merutekan traffic ke VM yang tidak responsif. Untuk membantu memastikan aplikasi merespons seperti yang diharapkan, Anda dapat mengonfigurasi health check berbasis aplikasi sebagai bagian dari kebijakan autohealing MIG. Jika aplikasi di VM tertentu tidak merespons, MIG akan otomatis melakukan pemulihan (perbaikan) pada VM. Untuk informasi selengkapnya tentang mengonfigurasi perbaikan otomatis, lihat Tentang memperbaiki VM untuk ketersediaan tinggi.
Ketahanan terhadap pemadaman layanan region
Jika terjadi pemadaman layanan region, aplikasi tidak akan tersedia. Untuk mengurangi periode nonaktif yang disebabkan oleh pemadaman wilayah, Anda dapat menerapkan pendekatan berikut:
- Mempertahankan replika pasif (failover) dari tingkat web dan tingkat aplikasi di region Google Cloud lainnya.
- Buat instance Infrastruktur Exadata standby dengan Cluster VM Exadata yang diperlukan di region yang sama dengan replika pasif stack aplikasi. Gunakan Oracle Data Guard untuk replikasi data dan failover otomatis ke database Exadata standby. Jika aplikasi Anda memerlukan toleransi jumlah data yang hilang (RPO) yang lebih rendah, Anda dapat mencadangkan dan memulihkan database menggunakan Oracle Autonomous Recovery Service.
- Jika terjadi gangguan layanan di region utama, gunakan replika atau cadangan database untuk memulihkan database ke produksi dan mengaktifkan aplikasi di region failover.
- Gunakan kebijakan perutean DNS untuk merutekan traffic ke load balancer eksternal di region failover.
Untuk aplikasi penting bagi bisnis yang harus terus tersedia meskipun terjadi penghentian layanan region, pertimbangkan untuk menggunakan arketipe deployment multi-regional. Anda dapat menggunakan Oracle Active Data Guard untuk menyediakan database standby hanya baca di region failover.
Oracle mengelola infrastruktur di Oracle Database@Google Cloud. Untuk informasi tentang tujuan tingkat layanan (SLO) untuk Layanan Database Oracle Exadata di Infrastruktur Khusus, lihat Tujuan Tingkat Layanan untuk Layanan Cloud Publik PaaS dan IaaS Oracle.
Penskalaan otomatis MIG
Arsitektur dalam dokumen ini menggunakan MIG regional untuk tingkat web dan tingkat aplikasi. Kemampuan penskalaan otomatis MIG stateless memastikan bahwa VM Compute Engine yang menghosting tingkat web dan tingkat aplikasi tidak terpengaruh oleh pemadaman layanan zona tunggal. MIG stateful tidak dapat diskalakan secara otomatis.
Untuk mengontrol perilaku penskalaan otomatis MIG, Anda dapat menentukan metrik penggunaan target, seperti penggunaan CPU rata-rata. Anda juga dapat mengonfigurasi penskalaan otomatis berbasis jadwal. Untuk mengetahui informasi selengkapnya, lihat Penskalaan otomatis grup instance.
Penempatan VM
Dalam arsitektur yang dijelaskan dalam dokumen ini, tingkat aplikasi dan tingkat web berjalan di VM Compute Engine yang didistribusikan di beberapa zona. Distribusi ini membantu memastikan bahwa tingkat web dan tingkat aplikasi Anda andal terhadap pemadaman zona tunggal. Untuk meningkatkan keandalan ini lebih lanjut, Anda dapat membuat kebijakan penempatan spread dan menerapkannya ke template MIG. Dengan kebijakan penempatan spread, saat membuat VM, MIG akan menempatkannya dalam setiap zona di server fisik yang berbeda (disebut host), sehingga VM Anda tangguh terhadap kegagalan masing-masing host. Namun, konsekuensi dari pendekatan ini adalah latensi untuk traffic jaringan antar-VM mungkin meningkat. Untuk mengetahui informasi selengkapnya, lihat Ringkasan kebijakan penempatan.
Perencanaan kapasitas VM
Untuk memastikan kapasitas VM Compute Engine tersedia saat diperlukan untuk penskalaan otomatis MIG, Anda dapat membuat reservations. Reservasi memberikan kapasitas yang pasti di zona tertentu untuk jumlah VM yang ditentukan dari jenis mesin yang Anda pilih. Reservasi dapat bersifat khusus untuk satu project, atau dapat dibagikan di beberapa project. Anda akan dikenai biaya untuk resource yang dipesan meskipun resource tersebut tidak disediakan atau digunakan. Untuk mengetahui informasi selengkapnya tentang reservasi, termasuk pertimbangan penagihan, lihat Reservasi resource zona Compute Engine.
Penyimpanan stateful
Praktik terbaik dalam desain aplikasi adalah menghindari kebutuhan akan disk lokal stateful. Namun, jika persyaratannya ada, Anda dapat mengonfigurasi disk agar bersifat stateful untuk memastikan bahwa data dipertahankan saat VM diperbaiki atau dibuat ulang. Namun, sebaiknya Anda tetap membuat boot disk stateless, sehingga Anda dapat mengupdatenya dengan mudah ke image terbaru dengan versi baru dan patch keamanan. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi persistent disk stateful di MIG.
Kapasitas database
Anda dapat menskalakan Infrastruktur Exadata dengan menambahkan server database dan server penyimpanan sesuai kebutuhan. Setelah menambahkan server database atau server penyimpanan yang diperlukan ke Infrastruktur Exadata, agar dapat menggunakan resource CPU atau penyimpanan tambahan, Anda harus menambahkan kapasitas ke cluster VM Exadata terkait. Untuk mengetahui informasi selengkapnya, lihat Menskalakan Komputasi dan Penyimpanan Exadata.
Pencadangan dan pemulihan
Anda dapat menggunakan Layanan Pencadangan dan DR untuk membuat, menyimpan, dan mengelola cadangan VM Compute Engine. Backup and DR Service menyimpan data cadangan dalam format asli yang dapat dibaca aplikasi. Jika diperlukan, Anda dapat memulihkan beban kerja ke produksi dengan langsung menggunakan data dari penyimpanan cadangan jangka panjang tanpa aktivitas persiapan atau pemindahan data yang memakan waktu. Untuk informasi selengkapnya, lihat Backup and DR Service untuk pencadangan instance Compute Engine.
Secara default, cadangan database di Oracle Exadata Database Service di Infrastruktur Dedikasi disimpan di OCI Object Storage. Untuk mencapai RPO yang lebih rendah, Anda dapat mencadangkan dan memulihkan database menggunakan Oracle Autonomous Recovery Service.
Pertimbangan keandalan lainnya
Saat Anda mem-build arsitektur cloud untuk workload, tinjau praktik terbaik dan rekomendasi terkait keandalan yang diberikan dalam dokumentasi berikut:
- Panduan keandalan infrastruktur Google Cloud
- Pola untuk aplikasi yang skalabel dan tangguh
- Mendesain sistem yang tangguh
Pengoptimalan biaya
Bagian ini memberikan panduan untuk mengoptimalkan biaya penyiapan dan pengoperasian topologi Google Cloud yang Anda buat menggunakan arsitektur referensi ini.
Jenis mesin VM
Untuk membantu Anda mengoptimalkan penggunaan VM, Compute Engine memberikan rekomendasi jenis mesin. Gunakan rekomendasi untuk memilih jenis mesin yang cocok dengan persyaratan komputasi VM tingkat web dan tingkat aplikasi Anda. Untuk workload yang memiliki persyaratan resource yang dapat diprediksi, Anda dapat menyesuaikan jenis mesin dengan kebutuhan Anda dan menghemat uang dengan menggunakan jenis mesin kustom.
Model penyediaan VM
Jika aplikasi Anda fault-tolerant, Spot VM dapat membantu mengurangi biaya Compute Engine untuk VM Anda di tingkat web dan tingkat aplikasi. Biaya Spot VM jauh lebih rendah daripada VM reguler. Namun, Compute Engine dapat menghentikan atau menghapus VM Spot secara preemptive untuk mengklaim kembali kapasitas.
Spot VM cocok untuk tugas batch yang dapat menoleransi preemption dan tidak memiliki persyaratan ketersediaan tinggi. Spot VM menawarkan jenis, opsi, dan performa mesin yang sama dengan VM reguler. Namun, jika kapasitas resource di zona terbatas, MIG mungkin tidak dapat diskalakan (yaitu, membuat VM) secara otomatis untuk mencapai ukuran target yang ditentukan hingga kapasitas yang diperlukan tersedia lagi.
Penggunaan resource VM
Kemampuan penskalaan otomatis MIG stateless memungkinkan aplikasi Anda menangani peningkatan traffic ke tingkat web dan tingkat aplikasi dengan baik. Penskalaan otomatis juga membantu Anda mengurangi biaya saat kebutuhan resource rendah. MIG stateful tidak dapat diskalakan secara otomatis.
Biaya database
Saat membuat Cluster VM Exadata, Anda dapat memilih BYOL atau menyediakan database Oracle yang disertakan dalam lisensi.
Biaya jaringan untuk transfer data antara aplikasi Anda dan database Oracle Exadata yang berada dalam region yang sama disertakan dalam harga penawaran Oracle Database@Google Cloud.
Pertimbangan biaya lainnya
Saat Anda mem-build arsitektur untuk workload, pertimbangkan juga praktik terbaik dan rekomendasi umum yang diberikan dalam Framework Arsitektur Google Cloud: Pengoptimalan biaya.
Efisiensi operasional
Bagian ini menjelaskan faktor-faktor yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk mendesain topologi Google Cloud yang dapat Anda operasikan secara efisien.
Pembaruan konfigurasi VM
Untuk memperbarui konfigurasi VM di MIG (seperti jenis mesin atau image disk booting), Anda membuat template instance baru dengan konfigurasi yang diperlukan, lalu menerapkan template baru ke MIG. MIG mengupdate VM menggunakan metode update yang Anda tentukan: otomatis atau selektif. Pilih metode yang sesuai berdasarkan persyaratan Anda terkait ketersediaan dan efisiensi operasional. Untuk mengetahui informasi selengkapnya tentang metode update MIG ini, lihat Menerapkan konfigurasi VM baru di MIG.
Image VM
Untuk template instance MIG, sebaiknya buat dan gunakan image OS kustom yang menyertakan konfigurasi dan software yang diperlukan aplikasi Anda, bukan menggunakan image publik yang disediakan Google. Anda dapat mengelompokkan image kustom ke dalam kelompok image kustom. Kelompok image selalu menunjukkan ke image terbaru dalam kelompok tersebut, sehingga template dan skrip instance dapat menggunakan image tersebut tanpa harus memperbarui referensi ke versi image tertentu. Anda harus mengupdate image kustom secara rutin untuk menyertakan update dan patch keamanan yang disediakan oleh vendor OS.
Template instance deterministik
Jika template instance yang Anda gunakan untuk MIG menyertakan skrip startup (misalnya, untuk menginstal software pihak ketiga), pastikan skrip tersebut secara eksplisit menentukan parameter penginstalan software, seperti versi software. Jika tidak, saat MIG membuat VM, software yang diinstal
di VM mungkin tidak konsisten. Misalnya, jika template instance Anda
menyertakan skrip startup untuk menginstal Apache HTTP Server 2.0 (paket apache2
), pastikan skrip menentukan versi apache2
yang tepat yang harus diinstal, seperti versi 2.4.53
. Untuk mengetahui informasi selengkapnya, lihat
Template instance deterministik.
Administrasi database
Oracle mengelola server database fisik, server penyimpanan, dan hardware jaringan di Oracle Exadata Database Service on Dedicated Infrastructure. Anda dapat mengelola instance Infrastruktur Exadata dan Cluster VM Exadata melalui antarmuka OCI atau Google Cloud. Anda membuat dan mengelola database melalui antarmuka OCI. Halaman konsol Google Cloud untuk Oracle Database@Google Cloud menyertakan link yang dapat Anda gunakan untuk langsung membuka halaman yang relevan di konsol OCI. Agar tidak perlu login lagi ke OCI, Anda dapat mengonfigurasi federasi identitas antara OCI dan Google Cloud.
Pertimbangan operasional lainnya
Saat Anda mem-build arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi umum untuk efisiensi operasional yang dijelaskan dalam Framework Arsitektur Google Cloud: Keunggulan operasional.
Pengoptimalan performa
Bagian ini menjelaskan faktor-faktor yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk mendesain topologi di Google Cloud yang memenuhi persyaratan performa workload Anda.
Performa compute
Compute Engine menawarkan berbagai jenis mesin yang telah ditetapkan dan dapat disesuaikan yang dapat Anda pilih, bergantung pada persyaratan performa workload Anda. Untuk VM yang menghosting tingkat web dan tingkat aplikasi, pilih jenis mesin yang sesuai berdasarkan persyaratan performa Anda untuk tingkat tersebut. Untuk mengetahui informasi selengkapnya, lihat Perbandingan seri mesin.
Performa jaringan
Untuk beban kerja yang memerlukan latensi jaringan antar-VM yang rendah dalam tingkat aplikasi dan web, Anda dapat membuat kebijakan penempatan rapat dan menerapkannya ke template MIG yang digunakan untuk tingkat tersebut. Saat membuat VM, MIG akan menempatkan VM di server fisik yang berdekatan. Meskipun kebijakan penempatan rapat membantu meningkatkan performa jaringan antar-VM, kebijakan penempatan spread dapat membantu meningkatkan ketersediaan VM seperti yang dijelaskan sebelumnya. Untuk mencapai keseimbangan optimal antara performa dan ketersediaan jaringan, saat membuat kebijakan penempatan rapat, Anda dapat menentukan jarak VM yang harus ditempatkan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan kebijakan penempatan.
Compute Engine memiliki batas per VM untuk bandwidth jaringan traffic keluar. Batas ini bergantung pada jenis mesin VM dan apakah traffic dirutekan melalui jaringan VPC yang sama dengan VM sumber. Untuk VM dengan jenis mesin tertentu, guna meningkatkan performa jaringan, Anda bisa mendapatkan bandwidth keluar maksimum yang lebih tinggi dengan mengaktifkan jaringan Tingkat_1. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi performa jaringan Tingkat_1 per VM.
Traffic jaringan antara VM tingkat aplikasi dan jaringan Oracle Exadata diarahkan melalui koneksi Partner Interconnect latensi rendah yang disiapkan Google.
Infrastruktur Exadata menggunakan RDMA over Converged Ethernet (RoCE) untuk jaringan bandwidth tinggi dan latensi rendah di antara server database dan server penyimpanan. Server bertukar data langsung di memori utama tanpa melibatkan prosesor, cache, atau sistem operasi.
Pertimbangan performa lainnya
Saat Anda membuat arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi umum yang diberikan dalam Framework Arsitektur Google Cloud: Optimalisasi performa.
Langkah selanjutnya
- Mempercepat transformasi cloud dengan Google Cloud dan Oracle
- Dokumentasi Oracle
- Dokumentasi Google
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis: Kumar Dhanagopal | Developer Solusi Lintas Produk
Kontributor lainnya:
- Andy Colvin | Database Black Belt Engineer (Oracle on Google Cloud)
- Jeff Welsch | Director, Product Management
- Lee Gates | Group Product Manager
- Marc Fielding | Data Infrastructure Architect
- Mark Schlagenhauf | Technical Writer, Networking
- Michelle Burtoft | Senior Product Manager
- Rajesh Kasanagottu | Engineering Manager
- Roberto Mendez | Staff Network Implementation Engineer
- Sekou Page | Outbound Product Manager
- Souji Madhurapantula | Group Product Manager
- Victor Moreno | Product Manager, Cloud Networking