Aplikasi perusahaan dengan Database Oracle di Compute Engine

Last reviewed 2024-09-02 UTC

Dokumen ini memberikan arsitektur referensi untuk membantu Anda mem-build infrastruktur guna menghosting aplikasi perusahaan yang memiliki ketersediaan tinggi dan menggunakan database Oracle, dengan seluruh stack yang di-deploy di VM Compute Engine. Anda dapat menggunakan arsitektur referensi ini untuk menghosting ulang (lift and shift) aplikasi on-premise yang menggunakan database Oracle ke Google Cloud secara efisien. Dokumen ini juga mencakup panduan untuk membantu Anda membuat topologi Database Oracle di Google Cloud yang memenuhi persyaratan arsitektur ketersediaan maksimum (MAA) Oracle. Audiens yang dituju untuk dokumen ini adalah arsitek cloud dan administrator database Oracle. Dokumen ini mengasumsikan bahwa Anda sudah memahami Compute Engine dan Oracle Database.

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. Untuk mengetahui informasi selengkapnya, lihat Aplikasi perusahaan di VM Compute Engine dengan Oracle Exadata di Google Cloud.

Arsitektur

Diagram berikut menunjukkan infrastruktur untuk aplikasi perusahaan multi-tingkat yang menggunakan Oracle Database. Tingkat web, tingkat aplikasi, dan instance Oracle Database dihosting di VM Compute Engine. Tingkat web dan tingkat aplikasi berjalan dalam mode aktif-aktif di VM yang didistribusikan di dua zona dalam region Google Cloud. Instance database utama dan standby di-deploy di zona terpisah. Arsitektur ini selaras dengan arketipe deployment regional, yang membantu memastikan bahwa topologi Google Cloud Anda tangguh terhadap penghentian layanan satu zona1.

Aplikasi perusahaan multi-level menggunakan Database Oracle di VM Compute Engine.

Arsitektur yang ditampilkan dalam diagram sebelumnya mencakup komponen berikut:

Komponen Tujuan
Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi eksternal regional menerima dan mendistribusikan permintaan pengguna 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.
Instance Database Oracle yang di-deploy di VM Compute Engine Aplikasi dalam arsitektur ini menggunakan pasangan utama-standby instance Database Oracle yang di-deploy di VM Compute Engine di zona terpisah. Anda membawa lisensi sendiri (BYOL) untuk instance Database Oracle ini, dan Anda mengelola VM dan instance database.
Penyimpanan Gabungan Hyperdisk VM di setiap zona (di semua tingkat dalam stack aplikasi) menggunakan volume Hyperdisk Balanced dari Hyperdisk Storage Pool. Dengan membuat dan mengelola semua disk dalam satu storage pool, Anda akan meningkatkan penggunaan kapasitas dan mengurangi kompleksitas operasional sekaligus mempertahankan kapasitas dan performa penyimpanan yang diperlukan VM.
Pengamat Oracle Data Guard FSFO Pengamat Oracle Data Guard Fast-Start Failover (FSFO) adalah program ringan yang memulai failover otomatis ke instance Oracle Database standby saat instance utama tidak tersedia. Observer berjalan di VM Compute Engine di zona yang berbeda dengan zona tempat instance database utama dan standby di-deploy.
Bucket Cloud Storage Untuk menyimpan cadangan instance Database Oracle, arsitektur ini menggunakan bucket Cloud Storage. Untuk memfasilitasi pemulihan database selama pemadaman region, Anda dapat menyimpan cadangan secara redundan secara geografis di bucket dual-region atau multi-region.
Jaringan Virtual Private Cloud (VPC) dan subnet Semua resource Google Cloud dalam arsitektur menggunakan satu jaringan dan subnet VPC. Bergantung pada persyaratan Anda, Anda dapat memilih untuk membuat arsitektur yang menggunakan beberapa jaringan VPC atau beberapa subnet. Untuk informasi selengkapnya, lihat Menentukan apakah akan membuat beberapa jaringan VPC atau tidak.
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 informasi tentang keunggulan relatif setiap pendekatan, lihat Memilih produk Network Connectivity.
Cloud Monitoring dan Cloud Logging Cloud Monitoring membantu Anda mengamati perilaku, kondisi, dan performa aplikasi serta resource Google Cloud. Ops Agent mengumpulkan metrik dan log dari VM Compute Engine, termasuk VM yang menghosting instance Oracle Database. Agen mengirimkan log ke Cloud Logging dan mengirimkan metrik ke Cloud 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.
  • Google Cloud Hyperdisk: Layanan penyimpanan jaringan yang dapat Anda gunakan untuk menyediakan dan menskalakan volume block storage secara dinamis dengan performa yang dapat dikonfigurasi dan dapat diprediksi.
  • Cloud Load Balancing: Portofolio load balancer global dan regional yang skalabel, berperforma tinggi, dan andal.
  • Cloud Storage: Penyimpanan objek berbiaya rendah tanpa batas untuk berbagai jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di seluruh lokasi untuk redundansi.
  • 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 Logging: Sistem pengelolaan log real-time dengan penyimpanan, penelusuran, analisis, dan pemberitahuan.
  • Cloud Interconnect: Layanan yang memperluas jaringan eksternal Anda ke jaringan Google melalui koneksi latensi rendah yang sangat tersedia.
  • Cloud VPN: Layanan yang memperluas jaringan peer Anda dengan aman ke jaringan Google melalui tunnel VPN IPsec.

Arsitektur referensi ini menggunakan produk Oracle berikut:

  • Oracle Database: Sistem manajemen database relasional (RDBMS) yang memperluas model relasional ke model relasional objek.
  • Oracle Data Guard: Kumpulan layanan untuk membuat, memelihara, mengelola, dan memantau satu atau beberapa database standby.

Anda bertanggung jawab untuk mendapatkan lisensi untuk produk Oracle yang Anda deploy di Google Cloud, dan Anda bertanggung jawab untuk mematuhi persyaratan dan ketentuan lisensi Oracle.

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 khusus 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.

Pilihan wilayah

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.
  • 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 semua 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 suka memfokuskan upaya IT pada data dan aplikasi, bukan menyiapkan dan mengoperasikan resource infrastruktur, Anda dapat menggunakan layanan serverless seperti Cloud Run.

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 Opsi Hosting Aplikasi.

Opsi penyimpanan

Arsitektur yang ditampilkan dalam dokumen ini menggunakan Hyperdisk Storage Pool di setiap zona, dengan volume Hyperdisk Balanced untuk VM di semua tingkat. Volume Hyperdisk memberikan performa, fleksibilitas, dan efisiensi yang lebih baik daripada Persistent Disk. Untuk mengetahui informasi tentang jenis dan fitur Hyperdisk, lihat Tentang Hyperdisk.

Untuk menyimpan data yang dibagikan di beberapa VM dalam satu region, seperti file konfigurasi untuk semua VM di tingkat web, Anda dapat menggunakan instance regional Filestore. Data yang Anda simpan di instance regional Filestore direplikasi secara sinkron di tiga zona dalam region tersebut. Replikasi ini memastikan ketersediaan tinggi dan ketahanan terhadap pemadaman layanan zona. 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 dan subnet VPC. Bergantung pada persyaratan, Anda dapat memilih untuk menggunakan beberapa jaringan VPC atau beberapa subnet. Untuk informasi selengkapnya, lihat dokumentasi berikut:

Keamanan, privasi, dan kepatuhan:

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 membantu 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 firewall aplikasi web (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 lapisan web, lapisan aplikasi, dan instance Oracle Database 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 Secure Web Proxy atau Cloud NAT.

Keamanan image VM

Gambar yang disetujui adalah gambar dengan software yang memenuhi kebijakan atau persyaratan keamanan Anda. Untuk memastikan bahwa VM 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 yang Anda buat menggunakan Google Cloud CLI atau Konsol Google Cloud. Peran Editor menyertakan 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.

Enkripsi disk

Secara default, data yang disimpan di volume Hyperdisk dienkripsi menggunakan kunci milik dan dikelola Google. Sebagai lapisan perlindungan tambahan, Anda dapat memilih untuk mengenkripsi kunci enkripsi data milik Google menggunakan kunci yang Anda miliki dan kelola di Cloud Key Management Service (Cloud KMS). Untuk mengetahui informasi selengkapnya, lihat Tentang enkripsi disk.

Keamanan jaringan

Untuk mengontrol traffic jaringan di antara resource dalam arsitektur, Anda harus mengonfigurasi kebijakan Cloud Next Generation Firewall (NGFW) yang sesuai.

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 salah satu tingkat gagal, aplikasi dapat terus memproses permintaan.

  • Jika VM di tingkat web atau tingkat aplikasi mengalami error, MIG yang relevan akan otomatis membuat ulang VM. Load balancer hanya meneruskan permintaan ke instance server web dan instance server aplikasi yang saat ini tersedia.
  • Jika VM yang menghosting instance Database Oracle utama gagal, pengamat FSFO Oracle Data Guard akan memulai failover otomatis ke instance Database Oracle standby.

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 cara mengonfigurasi perbaikan otomatis, lihat Tentang memperbaiki VM untuk ketersediaan tinggi.

Ketahanan terhadap pemadaman layanan zona

Jika terjadi pemadaman layanan zona, aplikasi tetap tersedia.

  • Tingkat web dan tingkat aplikasi tersedia (dan responsif) karena VM berada di MIG regional. MIG regional memastikan bahwa VM baru dibuat secara otomatis di zona lain untuk mempertahankan jumlah minimum VM yang dikonfigurasi. Load balancer meneruskan permintaan ke VM server web dan VM server aplikasi yang tersedia.
  • Jika pemadaman layanan memengaruhi zona yang memiliki instance Oracle Database utama, observer FSFO Oracle Data Guard akan memulai failover otomatis ke instance Oracle Database standby. Pengamat FSFO berjalan di VM di zona yang berbeda dengan zona yang memiliki instance database utama dan standby.
  • Untuk memastikan ketersediaan data yang tinggi di volume Hyperdisk selama penghentian layanan satu zona, Anda dapat menggunakan Hyperdisk Balanced High Availability. Saat data ditulis ke volume, data direplikasi secara sinkron antara dua zona dalam region yang sama.

Ketahanan terhadap pemadaman layanan region

Jika kedua zona dalam arsitektur mengalami pemadaman layanan atau jika pemadaman layanan region terjadi, aplikasi tidak akan tersedia. Untuk mengurangi periode nonaktif yang disebabkan oleh penghentian layanan multi-zona atau region, Anda dapat menerapkan pendekatan berikut:

  • Mempertahankan replika pasif (failover) stack infrastruktur di region Google Cloud lain.

  • Gunakan bucket Cloud Storage multi-region atau dual-region untuk menyimpan cadangan Database Oracle. Cadangan direplikasi secara asinkron di setidaknya dua lokasi geografis. Dengan pencadangan database replika, arsitektur Anda akan dipetakan ke tingkat Silver Maximum Availability Architecture (MAA) Oracle.

    Untuk mencapai replikasi yang lebih cepat untuk pencadangan yang disimpan di bucket dual-region, Anda dapat menggunakan replikasi turbo. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan dan ketahanan data.

  • Jika terjadi gangguan layanan di region utama, gunakan cadangan database untuk memulihkan database dan mengaktifkan aplikasi di region failover. Gunakan kebijakan perutean DNS untuk merutekan traffic ke load balancer di region failover.

Untuk aplikasi penting bagi bisnis yang harus terus tersedia meskipun terjadi penghentian layanan region, pertimbangkan untuk menggunakan arketipe deployment multi-regional. Untuk tingkat database, Anda dapat menggunakan FSFO Oracle Active Data Guard untuk mengalami failover secara otomatis ke instance Database Oracle standby di region failover. Pendekatan ini dipetakan ke tingkat MAA Gold Oracle.

Penskalaan otomatis MIG

Saat Anda menjalankan aplikasi di VM dalam MIG regional, aplikasi akan tetap tersedia selama pemadaman zona terisolasi. Kemampuan penskalaan otomatis MIG stateless memungkinkan Anda mempertahankan ketersediaan dan performa aplikasi pada tingkat yang dapat diprediksi. 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 memastikan bahwa aplikasi Anda tahan terhadap penghentian layanan satu zona. Untuk meningkatkan keandalan ini lebih lanjut, Anda dapat membuat kebijakan penempatan spread dan menerapkannya ke template MIG. Dengan kebijakan penempatan tersebar, saat membuat VM, MIG akan menempatkannya dalam setiap zona di server fisik yang berbeda (disebut host), sehingga VM Anda tahan terhadap kegagalan setiap host. Namun, konsekuensi dari pendekatan ini adalah latensi untuk traffic jaringan antar-VM mungkin meningkat. Untuk 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.

Ketersediaan block storage

Arsitektur dalam dokumen ini menggunakan Kumpulan Penyimpanan Hyperdisk di setiap zona untuk menyediakan block storage bagi VM Compute Engine. Anda membuat kumpulan kapasitas penyimpanan blok untuk zona. Kemudian, Anda membuat volume Hyperdisk di kumpulan penyimpanan dan memasang volume ke VM di zona. Tampungan penyimpanan mencoba menambahkan kapasitas secara otomatis untuk memastikan bahwa rasio penggunaan tidak melebihi 80% dari kapasitas yang disediakan oleh kumpulan. Pendekatan ini memastikan bahwa ruang penyimpanan blok tersedia saat diperlukan. Untuk informasi selengkapnya, lihat Cara kerja Penyimpanan Gabungan Hyperdisk.

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.

Pencadangan dan pemulihan

Arsitektur dalam dokumen ini menggunakan Cloud Storage untuk menyimpan cadangan database. Jika Anda memilih jenis lokasi dual-region atau multi-region untuk bucket Cloud Storage, cadangan akan direplikasi secara asinkron di setidaknya dua lokasi geografis. Jika terjadi pemadaman layanan regional, Anda dapat menggunakan cadangan untuk memulihkan database di region lain. Dengan bucket dual-region, Anda dapat mencapai replikasi yang lebih cepat dengan mengaktifkan opsi replikasi turbo. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan dan ketahanan data.

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 dokumentasi berikut:

Pertimbangan keandalan lainnya

Saat Anda mem-build arsitektur cloud untuk workload, tinjau praktik terbaik dan rekomendasi terkait keandalan yang diberikan dalam dokumentasi berikut:

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 resource VM, Compute Engine memberikan rekomendasi jenis mesin. Gunakan rekomendasi untuk memilih jenis mesin yang sesuai dengan persyaratan komputasi workload 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 dengan Spot VM mungkin tidak dapat diskalakan (yaitu, membuat VM) secara otomatis untuk mencapai ukuran target yang ditentukan hingga kapasitas yang diperlukan tersedia lagi. Jangan gunakan VM Spot untuk VM yang menghosting instance Database Oracle.

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.

Pemberian lisensi Oracle Database

Anda bertanggung jawab untuk mendapatkan lisensi untuk produk Oracle yang Anda deploy di Compute Engine, dan Anda bertanggung jawab untuk mematuhi persyaratan dan ketentuan lisensi Oracle. Saat Anda menghitung biaya pemberian lisensi Oracle Database, pertimbangkan jumlah lisensi Oracle Processor yang diperlukan berdasarkan jenis mesin yang Anda pilih untuk VM Compute Engine yang menghosting instance Oracle Database. Untuk mengetahui informasi selengkapnya, lihat Melisensikan Software Oracle di Lingkungan Cloud Computing.

Pemanfaatan resource block storage

Arsitektur dalam dokumen ini menggunakan Kumpulan Penyimpanan Hyperdisk di setiap zona untuk menyediakan block storage bagi VM Compute Engine. Anda dapat meningkatkan penggunaan kapasitas penyimpanan blok secara keseluruhan dan mengurangi biaya dengan menggunakan Pusat penyimpanan kapasitas lanjutan, yang menggunakan penyediaan virtual dan teknologi pengurangan data untuk meningkatkan efisiensi penyimpanan.

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 keamanan dan patch 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.

Pengelolaan block storage

Arsitektur dalam dokumen ini menggunakan Kumpulan Penyimpanan Hyperdisk di setiap zona untuk menyediakan block storage bagi VM Compute Engine. Penyimpanan Gabungan Hyperdisk membantu menyederhanakan pengelolaan penyimpanan. Daripada mengalokasikan dan mengelola kapasitas satu per satu untuk banyak disk, Anda menentukan kumpulan kapasitas yang dapat dibagikan di beberapa beban kerja dalam zona. Kemudian, Anda membuat volume Hyperdisk di kumpulan penyimpanan dan melampirkan volume ke VM di zona. Berbagai kumpulan penyimpanan akan mencoba menambahkan kapasitas secara otomatis untuk memastikan bahwa rasio penggunaan tidak melebihi 80% dari kapasitas yang disediakan kumpulan.

Konektivitas server aplikasi ke database

Untuk koneksi dari aplikasi ke Database Oracle, sebaiknya Anda menggunakan nama DNS internal zona VM database, bukan alamat IP-nya. Google Cloud akan otomatis me-resolve nama DNS ke alamat IP internal utama VM. Keuntungan tambahan dengan pendekatan ini adalah Anda tidak perlu mencadangkan dan menetapkan alamat IP internal statis untuk VM database.

Dukungan dan administrasi Oracle Database

Saat Anda menjalankan instance Oracle Database yang dikelola sendiri di VM Compute Engine, ada masalah operasional yang serupa seperti saat Anda menjalankan Oracle Database di infrastruktur lokal. Namun, dengan VM Compute Engine, Anda tidak lagi perlu mengelola infrastruktur komputasi, jaringan, dan penyimpanan yang mendasarinya.

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 mendapatkan daftar jenis mesin yang tersedia yang mendukung volume Hyperdisk dan memenuhi performa serta persyaratan lainnya, gunakan tabel Perbandingan seri mesin.
  • Untuk VM yang menghosting instance Oracle Database, sebaiknya Anda menggunakan jenis mesin dalam seri mesin C4 dari kelompok mesin untuk tujuan umum. Jenis mesin C4 memberikan performa tinggi secara konsisten untuk beban kerja database.

Performa jaringan

Untuk beban kerja yang memerlukan latensi jaringan antar-VM yang rendah, Anda dapat membuat kebijakan penempatan rapat dan menerapkannya ke template MIG yang digunakan untuk tingkat aplikasi. Saat membuat VM, MIG menempatkan VM di server fisik yang berdekatan satu sama lain. 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 yang optimal antara performa dan ketersediaan jaringan, saat membuat kebijakan penempatan rapat, Anda dapat menentukan jarak penempatan VM. 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.

Performa penyimpanan Hyperdisk

Arsitektur yang dijelaskan dalam dokumen ini menggunakan volume Hyperdisk untuk VM di semua tingkat. Dengan Hyperdisk, Anda dapat menskalakan performa dan kapasitas secara dinamis. Anda dapat menyesuaikan IOPS, throughput, dan ukuran setiap volume yang disediakan agar sesuai dengan performa penyimpanan dan kebutuhan kapasitas workload Anda. Performa volume Hyperdisk bergantung pada jenis Hyperdisk dan jenis mesin VM tempat volume terpasang. Untuk informasi selengkapnya tentang penyetelan dan batas performa Hyperdisk, lihat dokumentasi berikut:

Pertimbangan performa lainnya

Saat Anda mem-build arsitektur untuk workload, pertimbangkan praktik terbaik dan rekomendasi umum yang diberikan dalam Framework Arsitektur Google Cloud: Optimalisasi performa.

Langkah selanjutnya

Kontributor

Penulis: Kumar Dhanagopal | Developer Solusi Lintas Produk

Kontributor lainnya:

  1. Region Meksiko, Montreal, dan Osaka memiliki tiga zona dalam satu atau dua pusat data fisik. Region ini sedang dalam proses perluasan ke minimal tiga pusat data fisik. Untuk mengetahui informasi selengkapnya, lihat Lokasi Cloud dan SLA Google Cloud Platform. Untuk membantu meningkatkan keandalan workload Anda, pertimbangkan deployment multi-regional.  ↩