Arsitektur untuk database Oracle di Azure Virtual Machines

  • Artikel

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 penyebaran 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

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 yang akan 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 cloud-native seperti pola coba lagi dan pola pemutus sirkuit. Untuk pola lain yang dapat membantu membuat aplikasi Anda lebih tangguh, lihat Panduan Pola Desain Cloud.

Oracle RAC di cloud

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 bersama-semua. 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 database Anda dari kegagalan tingkat rak, tingkat pusat data, dan 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 tempat zona ketersediaan belum ada, Anda dapat menggunakan set ketersediaan dan mencapai SLA waktu aktif 99,95%.

Catatan

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

Pemulihan dari bencana untuk database Oracle

Saat menghosting aplikasi penting misi di cloud, ketersediaan tinggi dan pemulihan dari bencana harus didesain.

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 dari bencana. Untuk kehilangan data nol, kami sarankan Anda menyebarkan instans Oracle Data Guard Far Sync selain Active Data Guard.

Jika aplikasi Anda mengizinkan latensi, pertimbangkan untuk menyiapkan instans Data Guard Far Sync di zona ketersediaan yang berbeda dari database utama Oracle Anda. Uji konfigurasi secara menyeluruh. Gunakan mode Ketersediaan Maksimum untuk menyiapkan transport tersinkron file pengulangan Anda ke instans Far Sync. File ini kemudian ditransfer secara asinkron ke database siaga.

Aplikasi Anda mungkin tidak mengizinkan kehilangan performa saat menyiapkan instans Far Sync di zona ketersediaan lain dalam mode Ketersediaan Maksimum (sinkron). Jika tidak, Anda mungkin menyiapkan instans Far Sync di zona ketersediaan yang sama dengan database utama Anda. Untuk ketersediaan tambahan, pertimbangkan untuk menyiapkan beberapa instans Far Sync yang dekat dengan database utama Anda dan setidaknya satu instans yang dekat dengan database siaga Anda, jika peran bertransisi. Untuk informasi selengkapnya, lihat Oracle Active Data Guard Far Sync.

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

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. Jika database utama tidak tersedia karena pemadaman yang direncanakan atau tidak direncanakan, Data Guard dapat mengalihkan database siaga apa pun ke peran utama, meminimalkan waktu henti.

Saat menggunakan Oracle Data Guard, Anda mungkin juga membuka database sekunder untuk tujuan baca-saja. Konfigurasi ini disebut Active Data Guard. Oracle Database 12c memperkenalkan fitur yang disebut Data Guard Far Sync Instance. Instans ini memungkinkan Anda menyiapkan konfigurasi kehilangan data nol database Oracle tanpa harus memengaruhi performa.

Catatan

Active Data Guard memerlukan pemberian lisensi tambahan. Lisensi ini juga diperlukan untuk menggunakan fitur Far Sync. Hubungi perwakilan Oracle Anda untuk membahas implikasi lisensi.

Oracle Data Guard dengan Failover Mulai Cepat

Oracle Data Guard dengan Fast-Start Failover (FSFO) dapat memberikan lebih banyak ketahanan dengan menyiapkan broker pada komputer terpisah. Broker Data Guard dan database sekunder menjalankan pengamat dan mengamati database utama selama waktu henti. Pendekatan ini memungkinkan redundansi dalam penyiapan pengamat Data Guard Anda juga.

Dengan Oracle Database versi 12.2 ke atas, dimungkinkan juga untuk mengonfigurasi beberapa pengamat dengan satu konfigurasi broker Oracle Data Guard. Penyiapan ini menyediakan ketersediaan tambahan, jika satu pengamat dan database sekunder mengalami waktu henti. Data Guard Broker ringan dan dapat dihost di komputer virtual yang relatif kecil. Untuk informasi selengkapnya tentang Broker Data Guard dan keuntungannya, lihat Konsep Broker Oracle Data Guard.

Diagram berikut adalah rekomendasi arsitektur untuk penggunaan Oracle Data Guard di Azure dengan zona ketersediaan. Arsitektur ini memungkinkan Anda mendapatkan SLA waktu aktif VM sebesar 99,99%.

Diagram that shows a recommended architecture for using Oracle Data Guard on Azure with availability zones.

Dalam diagram sebelumnya, sistem klien mengakses aplikasi kustom dengan backend Oracle dengan menggunakan web. Frontend web dikonfigurasi dalam penyeimbang muatan. Frontend web melakukan panggilan ke server aplikasi yang sesuai untuk menangani pekerjaan. Server aplikasi meminta kueri database Oracle utama. Database Oracle telah dikonfigurasi menggunakan komputer virtual yang dioptimalkan memori hyper-threading dengan vCPU inti yang dibatasi untuk menghemat biaya pemberian lisensi dan memaksimalkan performa. Beberapa disk premium atau ultra (Disk Terkelola) digunakan untuk performa dan ketersediaan tinggi.

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 dan melakukan failover atas database ke sekunder saat gangguan terjadi.

Anda dapat menyiapkan pengamat lain atau database siaga di zona ketersediaan yang berbeda, AZ 1, dalam hal ini, daripada zona yang ditunjukkan dalam arsitektur sebelumnya. Terakhir, Oracle Enterprise Manager (OEM) memantau database Oracle untuk waktu aktif dan performa. OEM juga memungkinkan Anda menghasilkan berbagai laporan performa dan penggunaan.

Di wilayah di mana zona ketersediaan tidak didukung, Anda mungkin menggunakan set ketersediaan untuk menyebarkan Oracle Database Anda dengan cara yang sangat tersedia. Set ketersediaan memungkinkan Anda mencapai waktu aktif VM sebesar 99,95%. Diagram berikut adalah arsitektur referensi dari penggunaan ini:

Diagram that shows Oracle Database using availability sets with Data Guard Broker - FSFO.

Catatan

  • Karena hanya ada satu instans OEM yang disebarkan, Anda tidak perlu menempatkan VM Oracle Enterprise Manager dalam set ketersediaan.
  • Disk ultra saat ini tidak didukung dalam konfigurasi set ketersediaan.

Oracle Data Guard Far Sync

Oracle Data Guard Far Sync dilengkapi dengan kemampuan perlindungan kehilangan data nol untuk Oracle Database. Kemampuan ini memungkinkan Anda untuk melindungi dari kehilangan data jika mesin database Anda gagal. Oracle Data Guard Far Sync perlu dipasang di VM terpisah. Far Sync adalah instans Oracle ringan yang hanya memiliki file kontrol, file kata sandi, spfile, dan log siaga. Tidak ada file data atau mengulangi file log.

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, Data Guard secara otomatis menggunakan transportasi asinkron ke database sekunder dari database utama untuk mempertahankan perlindungan kehilangan data hampir nol. Untuk ketahanan tambahan, pelanggan mungkin menyebarkan beberapa instans Far Sync per setiap instans database, termasuk primer dan sekunder.

Diagram berikut adalah arsitektur ketersediaan tinggi menggunakan Oracle Data Guard Far Sync:

Diagram that shows Oracle database using availability zones with Data Guard Far Sync & Broker - FSFO.

Dalam arsitektur sebelumnya, ada instans Far Sync yang disebarkan di zona ketersediaan yang sama dengan instans database untuk mengurangi latensi antara keduanya. Dalam kasus di mana aplikasi bersifat sensitif latensi, pertimbangkan untuk menyebarkan database dan instans Far Sync atau instans dalam grup penempatan proksimitas.

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

Diagram that shows Oracle Database using availability zones for disaster recovery with Data Guard Far Sync and Broker - FSFO.

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 aktif-aktif. Diagram berikut adalah rekomendasi arsitektur untuk penyiapan aktif-aktif Oracle GoldenGate di Azure. Dalam arsitektur berikut, database Oracle telah dikonfigurasi menggunakan komputer virtual yang dioptimalkan memori hyper-threading dengan vCPU inti yang dibatasi untuk menghemat biaya pemberian lisensi dan memaksimalkan performa. Arsitektur ini menggunakan beberapa disk premium atau ultra (disk terkelola) untuk performa dan ketersediaan.

Diagram that shows Oracle Database using availability zones with Data Guard Broker - FSFO.

Catatan

Arsitektur serupa dapat disiapkan menggunakan set ketersediaan di wilayah tempat zona ketersediaan saat ini tidak 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 menyiapkan replikasi dua arah untuk memastikan ketersediaan database Anda yang tinggi jika ada waktu henti 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

Pemecahan adalah pola tingkat data yang diperkenalkan di Oracle 12.2. Ini memungkinkan Anda mempartisi secara horizontal dan menskalakan data Anda di seluruh database independen. Ini adalah arsitektur share-nothing di mana setiap database dihosting pada komputer virtual khusus. Pola ini memungkinkan throughput baca dan tulis yang tinggi selain ketahanan dan peningkatan ketersediaan.

Pola ini menghilangkan satu titik kegagalan, menyediakan isolasi kesalahan, dan memungkinkan peningkatan versi bergulir tanpa gangguan. Waktu henti satu shard atau kegagalan tingkat pusat data tidak memengaruhi performa atau ketersediaan shard lain di pusat data lain.

Pemecahan cocok untuk aplikasi OLTP throughput tinggi yang tidak dapat mengupayakan semua waktu henti. Semua baris dengan kunci sharding yang sama selalu dijamin berada di pecahan 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 pecahan Anda, lihat Ketersediaan Tinggi Tingkat Shard.

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 pecahan juga berisi salinan master 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 dan kueri multi-pecahan yang tidak menentukan kunci sharding.

    Sebaiknya gunakan Oracle Data Guard dengan zona ketersediaan atau set ketersediaan untuk ketersediaan tinggi katalog shard sebagai praktik terbaik. Ketersediaan katalog shard 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.

  • Sutradara 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.

    Saat menyambungkan ke database awalnya, direktur shard menyiapkan informasi perutean dan menyimpan informasi untuk permintaan berikutnya, yang melewati direktur shard. Setelah sesi dibuat dengan pecahan, semua kueri SQL dan DML didukung dan dieksekusi dalam cakupan pecahan yang ditentukan. Perutean ini cepat dan digunakan untuk semua beban kerja OLTP yang melakukan transaksi intra-pecahan. Kami menyarankan agar Anda menggunakan perutean langsung untuk semua beban kerja OLTP yang memerlukan performa dan ketersediaan tertinggi. Cache perutean secara otomatis di-refresh saat pecahan menjadi tidak tersedia atau perubahan terjadi pada topologi pemecahan.

    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 dan toleransi 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 shard baca-saja, Anda dapat membuat layanan global lain untuk beban kerja baca-saja. Klien dapat menggunakan layanan global ini untuk menyambungkan ke database.

  • Database shard. 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 pecahan. Aspek ini secara otomatis dikonfigurasi dan disebarkan saat database bersama dibuat. Jika pecahan tertentu gagal, Berbagi Oracle gagal melalui koneksi database dari primer ke siaga.

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 tingkat pecahan yang ditentukan oleh admin.

Ada berbagai cara untuk memecah database:

  • Sharding yang dikelola sistem: Mendistribusikan secara otomatis di seluruh pecahan menggunakan 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 Sharding.

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

Tabel duplikasi disimpan di semua pecahan, sedangkan tabel pecahan didistribusikan di berbagai pecahan. Sebaiknya Anda menduplikasi tabel kecil dan dimensi dan mendistribusikan/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 Pecahan.

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 pecahan. Diagram arsitektur menunjukkan metode pemecahan 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 that shows Oracle Database Sharding using availability zones with 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.

Dalam arsitektur sebelumnya, sharding komposit digunakan untuk mendistribusikan data dan menskalakan tingkat 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 dipartisi lebih lanjut dengan menggunakan hash yang konsisten di beberapa pecahan di shardspace.

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)/shard director disebarkan di setiap zona ketersediaan untuk ketersediaan 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/grup 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 direktur pecahan terus melacak latensi permintaan dan respons dan merutekan permintaan.

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 rumit, 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. Driver dapat mengenali 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 Kumpulan Bersama UCP untuk Sharding Database.

Selama permintaan awal, server aplikasi terhubung ke direktur pecahan di wilayahnya untuk mendapatkan informasi perutean untuk pecahan tempat tujuan permintaan harus dirutekan. Berdasarkan kunci pemecahan yang diloloskan, direktur merutekan server aplikasi ke pecahan 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 dengan GoldenGate

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

Diagram that shows Oracle Database Sharding using availability zones with 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 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. Penyiapan ini membantu Anda menentukan ketersediaan tinggi dan desain pemulihan dari bencana secara efisien dalam grup pecahan dan di 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 meminimalkan konflik, Oracle Sharding menunjuk potongan 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.

Di arsitektur sebelumnya, direktur GSM/pecahan disebarkan di setiap zona ketersediaan untuk ketersediaan tinggi. Kami menyarankan agar Anda menyebarkan setidaknya satu direktur GSM/shard per pusat data atau wilayah. Instans server aplikasi disebarkan di setiap zona ketersediaan yang berisi grup pecahan. Penyiapan ini memungkinkan aplikasi untuk menjaga latensi antara server aplikasi dan database/grup 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 direktur pecahan terus melacak latensi permintaan dan respons dan merutekan permintaan.

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 rumit, 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. Driver dapat mengenali 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.

Selama permintaan awal, server aplikasi terhubung ke direktur pecahan di wilayahnya untuk mendapatkan informasi perutean untuk pecahan tempat tujuan permintaan harus dirutekan. Berdasarkan kunci pemecahan yang diloloskan, direktur merutekan server aplikasi ke pecahan 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 sistem operasi komputer virtual dapat diotomatisasi menggunakan Pengelolaan Pembaruan Azure Automation. 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

  • Database Oracle telah dikonfigurasi menggunakan komputer virtual yang dioptimalkan memori hyper-threading dengan vCPU inti yang dibatasi untuk VM Oracle Database guna menghemat biaya pemberian lisensi dan memaksimalkan performa. Gunakan beberapa disk premium atau ultra (disk terkelola) digunakan untuk 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 pemasangan Anda bertahan dalam sprite mulai ulang. 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.
  • Gunakan Azure Pipelines untuk mengelola patching dan pembaruan ke database Anda tanpa waktu henti.
  • 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.