Bagikan melalui

Arsitektur untuk database Oracle di Azure Virtual Machines

Berlaku untuk: ✔️ mesin virtual Linux

Artikel ini mencakup informasi tentang penyebaran database Oracle yang sangat tersedia di Azure. Selain itu, panduan ini menjelaskan pertimbangan pemulihan dari bencana secara mendetail. Arsitektur ini telah dibuat berdasarkan implementasi pelanggan. Panduan ini hanya berlaku untuk Oracle Database Enterprise Edition.

Jika Anda tertarik untuk mempelajari selengkapnya tentang memaksimalkan performa database Oracle Anda, lihat Mendesain dan menerapkan database Oracle di Azure.

Prasyarat

  • Pemahaman tentang berbagai konsep Azure seperti zona ketersediaan
  • Oracle Database Enterprise Edition 12c atau yang lebih baru
  • Kesadaran tentang implikasi lisensi saat menggunakan solusi dalam artikel ini
  • Persyaratan RPO dan RTO yang Telah Ditentukan

Ketersediaan tinggi untuk database Oracle

Pencapaian ketersediaan tinggi di cloud adalah bagian penting dalam perencanaan dan desain setiap organisasi. Azure menawarkan zona ketersediaan dan set ketersediaan untuk digunakan di wilayah di mana zona ketersediaan tidak tersedia. Untuk informasi selengkapnya tentang cara mendesain untuk cloud, lihat Opsi ketersediaan untuk Azure Virtual Machines.

Selain alat dan penawaran cloud-native, Oracle menyediakan solusi untuk ketersediaan tinggi yang dapat disiapkan di Azure:

Panduan ini mencakup arsitektur referensi untuk masing-masing solusi ini.

Saat Anda memigrasikan atau membuat aplikasi untuk cloud, sebaiknya gunakan pola asli-cloud seperti pola ulang dan pola pemutus rangkaian. Untuk pola lain yang dapat membantu membuat aplikasi Anda lebih tangguh, lihat Panduan Pola Desain Cloud.

Oracle RAC di awan

Oracle Real Application Cluster (RAC) adalah solusi dari Oracle untuk membantu pelanggan mencapai throughput tinggi dengan memiliki banyak instans yang mengakses satu penyimpanan database. Pola ini adalah arsitektur berbagi bersama. Meskipun Oracle RAC dapat digunakan untuk ketersediaan tinggi lokal, Oracle RAC saja tidak dapat digunakan untuk ketersediaan tinggi di cloud. Oracle RAC hanya melindungi dari kegagalan tingkat instans dan bukan terhadap kegagalan tingkat rak atau tingkat pusat data. Untuk alasan ini, Oracle merekomendasikan penggunaan Oracle Data Guard dengan database Anda, baik instans tunggal atau RAC, untuk ketersediaan tinggi.

Pelanggan umumnya memerlukan SLA tinggi untuk menjalankan aplikasi misi penting. Oracle saat ini tidak mensertifikasi atau mendukung Oracle RAC di Azure. Namun, Azure menawarkan fitur seperti zona ketersediaan dan jendela pemeliharaan terencana untuk membantu melindungi dari kegagalan tingkat instans. Selain penawaran ini, Anda dapat menggunakan Oracle Data Guard, Oracle GoldenGate, dan Oracle Sharding untuk performa dan ketahanan tinggi. Teknologi ini dapat membantu melindungi basis data Anda dari kegagalan tingkat rak, tingkat pusat data, dan kegagalan geo-politik.

Saat Anda menjalankan Oracle Database di beberapa zona ketersediaan dengan Oracle Data Guard atau GoldenGate, Anda bisa mendapatkan SLA waktu aktif 99,99%. Di wilayah Azure di mana zona ketersediaan belum tersedia, Anda dapat menggunakan set ketersediaan dan mencapai SLA waktu aktif sebesar 99,95%.

Catatan

Anda dapat memiliki target waktu aktif yang jauh lebih tinggi daripada SLA waktu aktif yang disediakan oleh Microsoft.

Pemulihan bencana untuk database Oracle

Saat menghosting aplikasi dengan tingkat kepentingan dan kritikal tinggi di cloud, penting untuk merancang ketersediaan tinggi dan pemulihan bencana.

Untuk Oracle Database Enterprise Edition, Oracle Data Guard adalah fitur yang berguna untuk pemulihan dari bencana. Anda dapat menyiapkan instans database siaga di wilayah Azure yang dipasangkan dan menyiapkan failover Data Guard untuk pemulihan bencana. Untuk memastikan tidak ada kehilangan data, kami menyarankan untuk menyebarkan instans Oracle Data Guard Far Sync, serta menggunakan Active Data Guard.

Untuk replikasi data jarak jauh, disarankan untuk memanfaatkan Far Sync. Far Sync adalah Fitur Oracle Active Data Guard.

Catatan

Jika Anda mengaktifkan Far Sync, lisensi Active Data Guard diperlukan. Hubungi perwakilan Oracle Anda untuk membahas implikasi lisensi.

Oracle Far Sync membahas jarak jauh antara database utama dan database sekunder dengan memperkenalkan server perantara yang dikenal sebagai Instans Sinkronisasi Jauh. Server ini menerima pengulangan data dari database utama lalu meneruskannya ke database siaga. Dengan demikian instans Far Sync ditempatkan lebih dekat ke primer untuk mengurangi waktu komunikasi. Server Far Sync kemudian mentransfer data pengulangan secara asinkron ke database sekunder.

Catatan

Saat Anda menggunakan database Oracle Standard Edition, ada solusi ISV yang memungkinkan Anda menyiapkan ketersediaan tinggi dan pemulihan bencana, seperti DBVisit Standby atau Tessell.

Arsitektur referensi

Oracle Data Guard

Oracle Data Guard menjamin ketersediaan tinggi, perlindungan data, dan pemulihan dari bencana untuk data perusahaan. Data Guard mempertahankan database siaga sebagai salinan konsisten transaksional dari database utama. Bergantung pada jarak antara database utama dan sekunder serta toleransi aplikasi untuk latensi, Anda dapat menyiapkan replikasi sinkron atau asinkron.

Oracle Data Guard dengan Failover Cepat Mulai

Data Guard dapat disebarkan menggunakan Fast Start Failover (FSFO). Fast-Start-Failover adalah fitur yang disediakan dalam Konfigurasi Broker Data Guard. Fitur ini memungkinkan Anda untuk melakukan failover secara otomatis jika terjadi kegagalan. Waktu default yang digunakan pelanggan adalah 30 detik, tetapi dapat disesuaikan berdasarkan kebutuhan Anda. Yang disebut OperationTimeout merupakan bagian dari properti Data Guard yang Anda tentukan selama penyebaran Anda.

Bagaimana Cara kerja Data Guard dengan properti ini

Tugas Data Guards adalah memantau terus kesehatan dan status Database utama dan sekunder. Segera setelah Anda mengaktifkan Fast-Start-Failover (FSFO), proses pengamat dimulai dan meninjau status kesehatan secara teratur untuk memastikan ketersediaan tinggi setiap saat.

Sekarang, jika Database utama menjadi tidak tersedia, pengamat dan Broker Data Guard mendeteksi gangguan ini. Dengan demikian, parameter OperationTimeout 30 detik menentukan berapa lama Broker harus menunggu respons dari database utama sebelum mengambil tindakan lebih lanjut.

Yang kemudian menghasilkan jika primer tidak merespons dalam jendela 30 detik ini, Pengamat mengasumsikan primer tidak dapat diakses dan memulai proses failover.

Broker segera mempromosikan database siaga ke status utama, menukar peran dan memastikan bahwa aplikasi dapat dengan cepat dilanjutkan dari mode siaga.

Selama waktu ini, Broker juga memastikan bahwa transaksi sudah diperbarui secara siaga. Dengan mode yang Anda konfigurasi, yang dapat berupa Ketersediaan Maksimum atau Perlindungan Maksimum, replikasi sinkron akan memberikan kehilangan data minimal hingga nol. Database Oracle ditempatkan di beberapa zona ketersediaan untuk ketersediaan tinggi. Setiap zona terbuat dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen. Untuk memastikan ketahanan, terdapat minimal tiga zona terpisah di semua wilayah yang diaktifkan. Pemisahan fisik zona ketersediaan dalam suatu wilayah membantu melindungi aplikasi dan data dari kegagalan pusat data. Selain itu, dua pengamat FSFO disiapkan di dua zona ketersediaan untuk memulai failover ke database sekunder jika terjadi kegagalan. Setelah failover terjadi dan database utama Anda sebelumnya tersedia lagi, itu dapat dipulihkan. Broker Data Guard memfasilitasi proses ini.

Pada akhirnya, jika database utama tidak tersedia karena pemadaman yang direncanakan atau tidak direncanakan, Data Guard beralih atau melakukan failover ke database siaga Anda.

Fitur ini dapat memberikan ketahanan tambahan dengan menyiapkan pengamat pada komputer virtual terpisah. Maka, Anda menempatkan pemantau pada VM ringan. Pendekatan ini memungkinkan ketersediaan dan ketahanan tinggi.

Dengan Oracle Database versi 12.2 ke atas, dimungkinkan juga untuk mengonfigurasi beberapa pengamat dengan satu konfigurasi broker Oracle Data Guard. Ini memberikan ketersediaan tambahan jika salah satu pengamat dan database sekunder mengalami pemadaman. Untuk informasi selengkapnya tentang Broker Data Guard dan keuntungannya, lihat Konsep Broker Oracle Data Guard.

Diagram berikut menunjukkan penginstalan Oracle Data Guard tanpa Sinkronisasi Jauh dengan waktu pemulihan kurang dari 5 menit.

Diagram yang memperlihatkan Arsitektur Oracle Data Guard.

Database Oracle ditempatkan di beberapa zona ketersediaan untuk ketersediaan tinggi. Setiap zona terbuat dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen. Untuk memastikan ketahanan, terdapat minimal tiga zona terpisah di semua wilayah yang diaktifkan. Pemisahan fisik zona ketersediaan dalam suatu wilayah membantu melindungi aplikasi dan data dari kegagalan pusat data. Selain itu, dua pengamat FSFO disiapkan di dua zona ketersediaan untuk memulai failover ke database sekunder jika terjadi kegagalan.

Catatan

Ketika Anda merencanakan penyebaran Data Guard simetris, harap dicatat bahwa Anda akan memerlukan satu pengamat lagi di zona ketersediaan tiga.

Selain itu, kami sangat menyarankan untuk menyebarkan Oracle Enterprise Manager untuk terus memiliki gambaran umum lapisan database. Azure Monitor dianjurkan untuk diimplementasikan dengan metrik berikut: Pantau disk:

  • Persentase IOPS Disk OS yang Terpakai
  • Persentase IOPS Terpakai pada Disk Data
  • Byte Dibaca per Detik/Disk Data
  • Penulisan Data Disk Byte/Detik
  • Kedalaman Antrean Disk
  • Bandwidth Disk dalam % per lun

Selain hal di atas, kami juga sangat menyarankan untuk mengaktifkan VM Insights.

Komputer Virtual dipilih berdasarkan penilaian AWR Anda. Harap tinjau Perencanaan Kapasitas Oracle untuk informasi lebih lanjut. Sebaiknya gunakan vCPU inti yang dibatasi untuk menghemat biaya lisensi dan memaksimalkan performa.

Pilihan jenis disk tergantung pada output penilaian AWR Anda.

Seperti disebutkan di atas, Far Sync adalah sebuah kemampuan yang umumnya digunakan dalam skenario di mana Anda mereplikasi antar wilayah untuk mengatasi jarak yang jauh. Mengacu pada skenario ini, Oracle Active Data Guard Far Sync menyediakan kemampuan perlindungan kehilangan data nol untuk Oracle Database. Instans Oracle Far Sync perlu diinstal pada VM terpisah.

SSD premium v2 tidak didukung untuk file yang mengacu pada sistem operasi. Untuk informasi lebih lanjut, silakan kunjungi Menyebarkan Premium SSD v2.

Azure Premium Files digunakan sebagai tujuan Pencadangan. Solusi ini adalah yang paling berkinerja. Anda juga dapat menggunakan Azure Blob Storage sebagai tujuan Backup. Selalu pastikan untuk menguji opsi mana yang paling sesuai untuk Anda. Kunjungi juga Strategi Pencadangan Oracle Database.

Oracle Data Guard Far Sync

Seperti disebutkan di atas, Far Sync adalah sebuah kemampuan yang umumnya digunakan dalam skenario di mana Anda mereplikasi antar wilayah untuk mengatasi jarak yang jauh. Mengacu pada skenario ini, Oracle Far Sync menyediakan kemampuan perlindungan kehilangan data nol untuk Oracle Database. Instans Oracle Far Sync perlu diinstal pada VM terpisah.

Untuk perlindungan kehilangan data nol, harus ada komunikasi sinkron antara database utama Anda dan instans Far Sync. Instans Far Sync menerima pengulangan dari primer secara sinkron dan meneruskannya langsung ke semua database siaga secara asinkron. Penyiapan ini juga mengurangi overhead di database utama, karena hanya perlu mengirim pengulangan ke instans Far Sync, bukan semua database siaga. Jika instans Far Sync gagal, Active Data Guard secara otomatis menggunakan transportasi asinkron ke database sekunder dari database utama untuk mempertahankan perlindungan kehilangan data hampir nol. Untuk ketahanan yang lebih baik, pelanggan mungkin menyebarkan beberapa instans Far Sync untuk setiap instans database, termasuk database primer dan sekunder.

Diagram berikut adalah arsitektur yang menggunakan Oracle Active Data Guard FSFO dan Far Sync untuk mencapai ketersediaan tinggi dan pemulihan bencana:

Diagram yang memperlihatkan Oracle Database menggunakan Far Sync dalam konfigurasi Active Data Guard di seluruh wilayah.

Catatan

Ketika Anda merencanakan penyebaran Far Sync simetris, harap dicatat bahwa Anda akan memerlukan satu lagi instans Far Sync di wilayah kedua.

Oracle GoldenGate

GoldenGate memungkinkan pertukaran dan manipulasi data pada tingkat transaksi di antara beberapa platform heterogen di seluruh perusahaan. Ini memindahkan transaksi yang diterapkan dengan integritas transaksi dan overhead minimum pada infrastruktur Anda yang ada. Arsitektur modularnya memberi Anda fleksibilitas untuk mengekstrak dan mereplikasi rekaman data yang dipilih, perubahan transaksional, dan perubahan pada bahasa definisi data (DDL) di berbagai topologi.

Oracle GoldenGate memungkinkan Anda mengonfigurasi database untuk ketersediaan tinggi dengan menyediakan replikasi dua arah. Pendekatan ini memungkinkan Anda menyiapkan konfigurasi multi-master atau active-active yang memerlukan kesadaran pada tingkat aplikasi. Diagram berikut adalah sebuah arsitektur yang direkomendasikan untuk konfigurasi aktif-aktif Oracle GoldenGate di Azure. Dalam arsitektur berikut, database Oracle telah dikonfigurasi menggunakan mesin virtual yang dioptimalkan memori dengan hyperthreaded dengan vCPU inti yang dibatasi untuk menghemat biaya lisensi dan memaksimalkan kinerja. Arsitektur ini menggunakan beberapa disk premium atau ultra (disk terkelola) untuk performa dan ketersediaan.

Diagram yang memperlihatkan Oracle Database menggunakan zona ketersediaan dengan Data Guard Broker - FSFO.

Catatan

Arsitektur serupa dapat disiapkan menggunakan set ketersediaan di wilayah tempat zona ketersediaan belum tersedia.

Oracle GoldenGate memiliki proses seperti Ekstrak, Pompa, dan Replikasi yang membantu Anda mereplikasi data Anda secara asinkron dari satu server database Oracle ke server database Oracle lainnya. Proses ini memungkinkan Anda mengonfigurasi replikasi dua arah untuk memastikan ketersediaan database Anda yang tinggi jika ada pemadaman di tingkat zona ketersediaan.

Dalam diagram sebelumnya, proses Ekstrak berjalan pada server yang sama dengan database Oracle Anda. Proses Pompa Data dan Replicat berjalan pada server terpisah di zona ketersediaan yang sama. Proses Replikasi (Replicat) digunakan untuk menerima data dari database di zona ketersediaan lain dan menerapkan data ke database Oracle di zona ketersediaannya. Demikian pula, proses Pompa Data mengirimkan data yang diekstrak proses Ekstrak ke proses Replicat di zona ketersediaan lainnya.

Meskipun diagram arsitektur sebelumnya menunjukkan proses Pompa Data dan Replicat yang dikonfigurasi di server terpisah, Anda mungkin menyiapkan semua proses Oracle GoldenGate di server yang sama, berdasarkan kapasitas dan penggunaan server Anda. Selalu lihat laporan AWR Anda dan metrik di Azure untuk memahami pola penggunaan server Anda.

Saat menyiapkan replikasi dua arah Oracle GoldenGate di zona ketersediaan yang berbeda atau wilayah yang berbeda, Anda perlu memastikan bahwa latensi antara komponen yang berbeda dapat diterima untuk aplikasi Anda. Latensi antara zona ketersediaan dan wilayah dapat bervariasi. Latensi tergantung pada beberapa faktor. Kami menyarankan agar Anda menyiapkan pengujian performa antara tingkat aplikasi dan tingkat database Anda di zona atau wilayah ketersediaan yang berbeda. Pengujian dapat mengonfirmasi bahwa konfigurasi memenuhi persyaratan performa aplikasi Anda.

Tingkat aplikasi dapat disiapkan dalam subnet-nya sendiri dan tingkat database dapat dipisahkan menjadi subnet-nya sendiri. Jika memungkinkan, pertimbangkan untuk menggunakan Azure Application Gateway untuk lalu lintas keseimbangan beban antara server aplikasi Anda. Application Gateway adalah penyeimbang beban lalu lintas web yang kuat. Ini menyediakan afinitas sesi berbasis cookie yang menyimpan sesi pengguna di server yang sama, meminimalkan konflik pada database. Alternatif untuk Application Gateway adalah Azure Load Balancer dan Azure Traffic Manager.

Oracle Sharding

Sharding adalah pola lapisan data yang diperkenalkan di Oracle 12.2. Ini memungkinkan Anda mempartisi secara horizontal dan menskalakan data Anda di seluruh database independen. Ini adalah arsitektur tanpa berbagi di mana setiap database dihosting pada mesin virtual yang didedikasikan. Pola ini memungkinkan throughput baca dan tulis yang tinggi selain ketahanan dan peningkatan ketersediaan.

Pola ini menghilangkan titik-titik kegagalan tunggal, memberikan isolasi kesalahan, dan memungkinkan pembaruan bergulir tanpa waktu henti. Saat terjadi downtime pada satu shard atau kegagalan pada tingkat pusat data, hal ini tidak memengaruhi performa atau ketersediaan shard lain di pusat data lain.

Sharding cocok untuk aplikasi OLTP dengan throughput tinggi yang tidak dapat menanggung waktu henti sama sekali. Semua baris dengan kunci sharding yang sama selalu dijamin berada di shard yang sama. Fakta ini meningkatkan performa, memberikan konsistensi tinggi. Aplikasi yang menggunakan sharding harus memiliki model data dan strategi distribusi data yang terdefinisi dengan baik, seperti hash, rentang, daftar, atau komposit yang konsisten. Strategi ini terutama mengakses data menggunakan kunci sharding, misalnya, customerId atau accountNum. Sharding juga memungkinkan Anda untuk menyimpan set data tertentu yang lebih dekat dengan pelanggan akhir, sehingga membantu memenuhi persyaratan performa dan kepatuhan Anda.

Kami menyarankan agar Anda mereplikasi pecahan Anda untuk ketersediaan tinggi dan pemulihan bencana. Penyiapan ini dapat dilakukan menggunakan teknologi Oracle seperti Oracle Data Guard atau Oracle GoldenGate. Unit replikasi bisa berupa pecahan, bagian dari pecahan, atau grup pecahan. Pemadaman atau perlambatan satu atau beberapa pecahan tidak memengaruhi ketersediaan database yang dipecah.

Untuk ketersediaan tinggi, pecahan siaga dapat ditempatkan di zona ketersediaan yang sama tempat pecahan utama ditempatkan. Untuk pemulihan dari bencana, pecahan siaga dapat ditemukan di wilayah lain. Anda mungkin juga menyebarkan pecahan di beberapa wilayah untuk melayani lalu lintas di wilayah tersebut. Untuk mempelajari selengkapnya tentang mengonfigurasi ketersediaan tinggi dan replikasi database terpecah Anda, lihat Shard-Level High Availability.

Oracle Sharding terutama terdiri dari komponen-komponen berikut. Untuk informasi selengkapnya, lihat Gambaran Umum Sharding Oracle:

  • Katalog Shard. Database Oracle tujuan khusus yang merupakan penyimpanan persisten untuk semua data konfigurasi database Shard. Semua perubahan konfigurasi seperti penambahan atau penghapusan pecahan, pemetaan data, dan DDL dalam database pecahan diinisiasi di katalog pecahan. Katalog shard juga berisi salinan induk dari semua tabel duplikat dalam SDB.

    Katalog pecahan menggunakan tampilan berwujud untuk secara otomatis mereplikasi perubahan pada tabel duplikat di semua pecahan. Database katalog shard juga bertindak sebagai koordinator kueri yang digunakan untuk memproses kueri multi-shard dan kueri yang tidak menyertakan kunci sharding.

    Kami merekomendasikan menggunakan Oracle Data Guard dengan zona ketersediaan atau set ketersediaan untuk mencapai ketersediaan tinggi bagi katalog shard sebagai praktik terbaik. Ketersediaan katalog pecahan tidak berpengaruh pada ketersediaan database pecahan. Waktu henti dalam katalog pecahan hanya memengaruhi operasi pemeliharaan dan kueri multi-pecahan selama periode singkat saat failover Data Guard selesai. SDB terus merutekan dan menjalankan transaksi online. Pemadaman katalog tidak memengaruhinya.

  • Direktur Shard. Layanan ringan yang perlu disebarkan di setiap wilayah/zona ketersediaan tempat pecahan Anda berada. Direktur Pecahan adalah Pengelola Layanan Global yang digunakan dalam konteks Oracle Sharding. Untuk ketersediaan tinggi, kami sarankan Anda menyebarkan setidaknya satu direktur shard di setiap zona ketersediaan tempat pecahan Anda berada.

    Pada awalnya, saat menyambungkan ke database, direktur shard menyiapkan informasi perutean dan menyimpan informasi tersebut untuk permintaan berikutnya, yang tidak langsung melalui direktur shard. Setelah sesi dibuat dengan "shard", semua kueri SQL dan DML didukung dan dijalankan dalam lingkup "shard" yang ditentukan. Pengarahan ini cepat dan digunakan untuk semua beban kerja OLTP yang melakukan transaksi di dalam pecahan. Kami menyarankan agar Anda menggunakan perutean langsung untuk semua beban kerja OLTP yang memerlukan performa dan ketersediaan tertinggi. Cache perutean secara otomatis diperbarui saat shard menjadi tidak tersedia atau terjadi perubahan pada topologi sharding.

    Untuk perutean performa tinggi dan bergantung pada data, Oracle merekomendasikan untuk menggunakan kumpulan koneksi saat mengakses data dalam database pecahan. Kumpulan koneksi Oracle, pustaka khusus bahasa, dan driver mendukung Oracle Sharding. Untuk informasi selengkapnya, lihat Gambaran Umum Sharding Oracle.

  • Layanan global. Layanan global mirip dengan layanan database reguler. Selain semua properti layanan database, layanan global memiliki properti untuk database pecahan. Properti ini termasuk afinitas wilayah antara klien dan shard serta toleransi terhadap jeda replikasi. Hanya satu layanan global yang perlu dibuat untuk membaca/menulis data ke dan dari database pecahan. Saat menggunakan Active Data Guard dan menyiapkan replika baca-saja dari shard, Anda dapat membuat layanan global lain untuk menangani beban kerja baca-saja. Klien dapat menggunakan layanan global ini untuk menyambungkan ke database.

  • Pengelompokan basis data. Database shard adalah database Oracle Anda. Setiap database direplikasi menggunakan Oracle Data Guard dalam konfigurasi Broker dengan FSFO diaktifkan. Anda tidak perlu menyiapkan failover dan replikasi Data Guard di setiap shard. Aspek ini secara otomatis dikonfigurasi dan disebarkan saat database bersama dibuat. Jika pecahan tertentu gagal, Oracle Sharing mengalihkan koneksi database dari utama ke cadangan.

Anda dapat menyebarkan dan mengelola database pecahan Oracle dengan dua antarmuka: Oracle Enterprise Manager Cloud Control GUI dan GDSCTL utilitas baris perintah. Anda juga dapat memantau pecahan yang berbeda untuk mengetahui ketersediaan dan performa menggunakan Cloud Control. Perintah GDSCTL DEPLOY otomatis membuat pecahan dan pendengarnya masing-masing. Selain itu, perintah ini otomatis menyebarkan konfigurasi replikasi yang digunakan untuk ketersediaan tinggi pada tingkat pecahan yang ditentukan oleh administrator.

Ada berbagai cara untuk memecah database:

  • Sharding yang dikelola sistem: Mendistribusikan secara otomatis di seluruh pecahan dengan partisi
  • Sharding yang ditentukan pengguna: Memungkinkan Anda menentukan pemetaan data ke shard, yang berfungsi dengan baik ketika ada persyaratan peraturan atau pelokalan data
  • Sharding komposit: Kombinasi sharding yang dikelola sistem dan ditentukan pengguna untuk shardspace yang berbeda
  • Subpartisi tabel: Mirip dengan tabel reguler yang dipartisi

Untuk informasi selengkapnya, lihat Metode Pemecahan Data.

Database yang dipecah terlihat seperti database tunggal untuk aplikasi dan pengembang. Saat Anda bermigrasi ke database yang terpecah, rencanakan dengan cermat untuk memahami tabel mana yang diduplikasi dibandingkan dengan yang terpecah.

Tabel duplikasi disimpan di semua pecahan, sedangkan tabel pecahan didistribusikan di berbagai pecahan. Sebaiknya Anda menduplikasi tabel kecil dan tabel dimensi serta mendistribusikan atau memecah tabel fakta. Data dapat dimuat ke database pecahan menggunakan katalog pecahan sebagai koordinator pusat atau dengan menjalankan Data Pump di setiap pecahan. Untuk informasi selengkapnya, lihat Memigrasikan Data ke Database Terfragmentasi.

Oracle Sharding dengan Data Guard

Oracle Data Guard dapat digunakan untuk pemecahan dengan metode pemecahan yang dikelola sistem, yang ditentukan pengguna, dan komposit.

Diagram berikut adalah arsitektur referensi untuk Oracle Sharding dengan Oracle Data Guard yang digunakan untuk ketersediaan tinggi setiap shard. Diagram arsitektur menunjukkan metode pembagian komposit. Diagram arsitektur kemungkinan berbeda untuk aplikasi dengan persyaratan yang berbeda untuk lokalitas data, penyeimbangan beban, ketersediaan tinggi, dan pemulihan bencana. Aplikasi mungkin menggunakan metode yang berbeda untuk sharding. Oracle Sharding memungkinkan Anda untuk memenuhi persyaratan ini dan menskalakan secara horizontal dan efisien dengan menyediakan opsi ini. Arsitektur serupa bahkan dapat digunakan menggunakan Oracle GoldenGate.

Diagram yang memperlihatkan Oracle Database Sharding menggunakan zona ketersediaan dengan Data Guard Broker - FSFO.

Sharding yang dikelola sistem adalah yang paling mudah untuk dikonfigurasi dan dikelola. Sharding yang ditentukan pengguna atau sharding komposit sangat cocok untuk skenario di mana data dan aplikasi Anda didistribusikan secara geografis atau dalam skenario di mana Anda harus memiliki kontrol atas replikasi setiap shard.

Pada arsitektur sebelumnya, sharding komposit digunakan untuk mendistribusikan data secara geografis dan menskalakan lapisan aplikasi Anda secara horizontal. Pemecahan komposit adalah kombinasi dari pemecahan yang dikelola sistem dan ditentukan pengguna, sehingga memberikan manfaat dari kedua metode tersebut. Dalam skenario sebelumnya, data dipecah terlebih dahulu di beberapa ruang pecahan yang dipisahkan menurut wilayah. Kemudian, data dibagi lebih lanjut dengan menggunakan hash yang konsisten di beberapa pecahan di ruang partisi.

Setiap ruang pecahan berisi beberapa grup pecahan. Setiap grup pecahan memiliki beberapa pecahan dan merupakan unit replikasi. Setiap grup pecahan berisi semua data dalam ruang pecahan. Grup pecahan A1 dan B1 adalah grup pecahan utama, sedangkan grup pecahan A2 dan B2 adalah grup pecahan siaga. Anda mungkin memilih untuk memiliki pecahan individual menjadi unit replikasi, bukan grup pecahan.

Dalam arsitektur sebelumnya, Global Service Manager (GSM)/direktur shard diterapkan di setiap zona ketersediaan untuk memastikan ketersediaan yang tinggi. Kami menyarankan agar Anda menyebarkan setidaknya satu direktur GSM/shard per pusat data/wilayah. Selain itu, instans server aplikasi disebarkan di setiap zona ketersediaan yang berisi grup pecahan. Penyiapan ini memungkinkan aplikasi untuk menjaga latensi antara server aplikasi dan database/kelompok pecahan tetap rendah. Jika database gagal, server aplikasi di zona yang sama dengan database siaga dapat menangani permintaan setelah transisi peran database terjadi. Azure Application Gateway dan pengelola shard terus melacak latensi permintaan dan tanggapan serta merutekan permintaan sesuai kebutuhan.

Dari sudut siaga aplikasi, sistem klien membuat permintaan ke Azure Application Gateway atau teknologi penyeimbangan beban lainnya di Azure, yang mengalihkan permintaan ke wilayah yang paling dekat dengan klien. Azure Application Gateway juga mendukung sesi lengket, sehingga setiap permintaan yang berasal dari klien yang sama dirutekan ke server aplikasi yang sama. Server aplikasi menggunakan pengumpulan koneksi di driver akses data. Fitur ini tersedia di driver seperti JDBC, ODP.NET, dan OCI. Para driver dapat mengidentifikasi kunci sharding yang ditentukan sebagai bagian dari permintaan. Oracle Universal Connection Pool (UCP) untuk klien JDBC dapat mengaktifkan klien aplikasi non-Oracle seperti Apache Tomcat dan IIS agar berfungsi dengan Oracle Sharding. Untuk informasi selengkapnya, lihat Gambaran Umum Area Memori Bersama UCP untuk Database Sharding.

Pada permintaan awal, server aplikasi terhubung ke pengelola shard di wilayahnya untuk mendapatkan informasi perutean untuk shard tujuan permintaan harus dirutekan. Berdasarkan kunci sharding yang diteruskan, pengendali merutekan server aplikasi ke shard masing-masing. Server aplikasi menyimpan cache informasi ini dengan membuat peta, dan untuk permintaan berikutnya, melewati direktur pecahan dan merutekan permintaan langsung ke pecahan.

Oracle Sharding menggunakan GoldenGate

Diagram berikut adalah arsitektur referensi untuk Oracle Sharding dengan Oracle GoldenGate yang digunakan untuk ketersediaan tinggi di setiap pecahan wilayah. Dibandingkan dengan arsitektur sebelumnya, arsitektur ini hanya menggambarkan ketersediaan tinggi dalam satu wilayah Azure, dengan beberapa zona ketersediaan. Anda dapat menyebarkan database dengan ketersediaan tinggi yang tersebar di beberapa wilayah dan terpecah-pecah, mirip dengan contoh sebelumnya, dengan menggunakan Oracle GoldenGate.

Diagram yang memperlihatkan Oracle Database Sharding menggunakan zona ketersediaan dengan GoldenGate.

Arsitektur referensi sebelumnya menggunakan metode pemecahan yang dikelola sistem untuk memecah data. Karena replikasi Oracle GoldenGate dilakukan pada tingkat gugus, setengah data yang direplikasi ke satu pecahan dapat direplikasi ke pecahan lain. Setengah lainnya dapat direplikasi ke pecahan data yang berbeda.

Cara data direplikasi bergantung pada faktor replikasi. Dengan faktor replikasi dua, Anda memiliki dua salinan dari setiap potongan data di tiga pecahan Anda di grup pecahan. Demikian pula, dengan faktor replikasi tiga dan tiga pecahan dalam grup pecahan Anda, semua data di setiap pecahan direplikasi ke setiap pecahan lain dalam grup pecahan. Setiap pecahan dalam grup pecahan dapat memiliki faktor replikasi yang berbeda. Pengaturan ini membantu Anda mendefinisikan desain high availability dan pemulihan bencana secara efisien dalam satu grup pecahan dan di antara beberapa grup pecahan.

Dalam arsitektur sebelumnya, grup pecahan A dan grup pecahan B keduanya berisi data yang sama tetapi berada di zona ketersediaan yang berbeda. Jika grup pecahan A dan grup pecahan B memiliki faktor replikasi yang sama dari tiga, setiap baris/potongan tabel pecahan Anda direplikasi enam kali di dua grup pecahan. Jika grup pecahan A memiliki faktor replikasi tiga dan grup pecahan B memiliki faktor replikasi dua, setiap baris/potongan direplikasi lima kali di dua grup pecahan.

Penyiapan ini mencegah hilangnya data jika terjadi kegagalan tingkat instans atau tingkat zona ketersediaan. Lapisan aplikasi dapat membaca dari dan menulis ke setiap pecahan. Untuk mengurangi konflik, Oracle Sharding menunjuk cuplikan master untuk setiap rentang nilai hash. Fitur ini memastikan bahwa permintaan tulis untuk gugus tertentu diarahkan ke potongan yang sesuai. Selain itu, Oracle GoldenGate menyediakan deteksi dan resolusi konflik otomatis untuk menangani konflik apa pun yang mungkin muncul. Untuk informasi selengkapnya dan batasan penerapan GoldenGate dengan Oracle Sharding, lihat Menggunakan Oracle GoldenGate dengan Database Pecahan.

Dalam arsitektur sebelumnya, direktur GSM/shard ditempatkan di setiap zona ketersediaan untuk memastikan ketersediaan tinggi. Kami menyarankan agar Anda menyebarkan setidaknya satu direktur GSM/shard per pusat data atau wilayah. Instance aplikasi server disebarkan di setiap zona ketersediaan yang berisi shardgroup. Penyiapan ini memungkinkan aplikasi untuk menjaga latensi antara server aplikasi dan database/kelompok pecahan tetap rendah. Jika database gagal, server aplikasi di zona yang sama dengan database siaga dapat menangani permintaan setelah transisi peran database terjadi. Azure Application Gateway dan pengelola shard terus melacak latensi permintaan dan tanggapan serta merutekan permintaan sesuai kebutuhan.

Dari sudut siaga aplikasi, sistem klien membuat permintaan ke Azure Application Gateway atau teknologi penyeimbangan beban lainnya di Azure, yang mengalihkan permintaan ke wilayah yang paling dekat dengan klien. Azure Application Gateway juga mendukung sesi lengket, sehingga setiap permintaan yang berasal dari klien yang sama dirutekan ke server aplikasi yang sama. Server aplikasi menggunakan pengumpulan koneksi di driver akses data. Fitur ini tersedia di driver seperti JDBC, ODP.NET, dan OCI. Para driver dapat mengidentifikasi kunci sharding yang ditentukan sebagai bagian dari permintaan. Oracle Universal Connection Pool (UCP) untuk klien JDBC dapat mengaktifkan klien aplikasi non-Oracle seperti Apache Tomcat dan IIS agar berfungsi dengan Oracle Sharding.

Pada permintaan awal, server aplikasi terhubung ke pengelola shard di wilayahnya untuk mendapatkan informasi perutean untuk shard tujuan permintaan harus dirutekan. Berdasarkan kunci sharding yang diteruskan, pengendali merutekan server aplikasi ke shard masing-masing. Server aplikasi menyimpan cache informasi ini dengan membuat peta, dan untuk permintaan berikutnya, melewati direktur pecahan dan merutekan permintaan langsung ke pecahan.

Patching dan pemeliharaan

Saat Anda menyebarkan beban kerja Oracle ke Azure, Microsoft menangani semua patching tingkat sistem operasi host. Microsoft mengomunikasikan pemeliharaan tingkat sistem operasi yang direncanakan kepada pelanggan terlebih dahulu. Dua server dari dua zona ketersediaan yang berbeda tidak pernah di-patch secara bersamaan. Untuk informasi selengkapnya tentang pemeliharaan dan patching VM, lihat Opsi ketersediaan untuk Azure Virtual Machines.

Patching pada sistem operasi mesin virtual dapat diotomatisasi menggunakan Azure Automation Update Management. Patching dan memelihara database Oracle Anda dapat diotomatisasi dan dijadwalkan menggunakan Azure Pipelines atau Pengelolaan Pembaruan Azure Automation untuk meminimalkan waktu henti. Untuk informasi selengkapnya tentang pengiriman berkelanjutan dan penyebaran biru/hijau, lihat Teknik paparan progresif.

Pertimbangan arsitektur dan desain

  • Pertimbangkan untuk menggunakan mesin virtual yang dioptimalkan untuk memori dan hyperthreaded dengan vCPU berinti terbatas untuk VM Database Oracle Anda guna menghemat biaya lisensi dan memaksimalkan performa. Gunakan beberapa disk premium atau ultra (disk terkelola) untuk meningkatkan performa dan ketersediaan.
  • Saat Anda menggunakan disk terkelola, nama disk/perangkat mungkin berubah saat memulai ulang. Kami menyarankan agar Anda menggunakan UUID perangkat alih-alih nama untuk memastikan pengaitan Anda bertahan meskipun perangkat di-restart. Untuk informasi selengkapnya, lihat Menambahkan sistem file baru ke /etc/fstab.
  • Gunakan zona ketersediaan untuk mencapai ketersediaan tinggi dalam wilayah.
  • Pertimbangkan untuk menggunakan disk ultra saat tersedia atau disk premium untuk database Oracle Anda.
  • Pertimbangkan untuk menyiapkan database Oracle siaga di wilayah Azure lain menggunakan Oracle Data Guard.
  • Pertimbangkan untuk menggunakan grup penempatan proksimitas untuk mengurangi latensi antara tingkat database dan aplikasi Anda.
  • Bandwidth jaringan maksimum Azure VM (biasanya) lebih tinggi dari throughput disk maksimum pada SKU yang sama. Anda dapat mencapai throughput yang lebih tinggi pada SKU VM yang sama atau menggunakan SKU VM yang lebih kecil dengan menggunakan penyimpanan jaringan berkinerja tinggi dan latensi rendah seperti Azure NetApp Files. untuk database.
  • Siapkan Oracle Enterprise Manager untuk pengelolaan, pemantauan, dan pengelogan.
  • Pertimbangkan untuk menggunakan Oracle Automatic Storage Management untuk manajemen penyimpanan yang disederhanakan untuk database Anda.
  • Pengantar Oracle Data Guard
  • Sesuaikan kode aplikasi Anda untuk menambahkan pola cloud-native yang mungkin membantu aplikasi Anda menjadi lebih tangguh. Pertimbangkan pola seperti pola coba lagi, pola pemutus sirkuit, dan lainnya yang didefinisikan dalam panduan Pola Desain Cloud.

Langkah berikutnya

Tinjau artikel referensi Oracle berikut yang berlaku untuk skenario Anda.