Ketersediaan SAP Hana di seluruh wilayah Azure

Artikel ini menjelaskan skenario yang terkait dengan ketersediaan SAP Hana di seluruh wilayah Azure. Karena jarak antar wilayah Azure, menyiapkan ketersediaan SAP Hana di beberapa wilayah Azure melibatkan pertimbangan khusus.

Alasan menyebarkan di seluruh wilayah Azure

Wilayah Azure sering dipisahkan oleh jarak yang jauh. Tergantung pada wilayah geopolitik, jarak antar wilayah Azure mungkin ratusan mil, atau bahkan beberapa ribu mil, seperti di Amerika Serikat. Karena jaraknya, lalu lintas jaringan antar aset yang disebarkan di dua wilayah Azure yang berbeda mengalami latensi bolak-balik jaringan yang signifikan. Latensi tersebut cukup signifikan untuk mengecualikan pertukaran data sinkron antara dua instans SAP Hana pada beban kerja SAP biasa.

Di sisi lain, organisasi seringkali memiliki persyaratan jarak antara lokasi pusat data utama dan pusat data sekunder. Persyaratan jarak membantu menyediakan ketersediaan jika bencana alam terjadi di lokasi geografis yang lebih luas. Contohnya termasuk badai yang melanda Karibia dan Florida pada September dan Oktober 2017. Organisasi Anda mungkin memiliki setidaknya persyaratan jarak minimum. Untuk sebagian besar pelanggan Azure, definisi jarak minimum mengharuskan Anda mendesain ketersediaan di seluruh wilayah Azure. Karena jarak antara dua wilayah Azure terlalu besar untuk menggunakan mode replikasi sinkron HANA, persyaratan RTO dan RPO mungkin memaksa Anda untuk menyebarkan konfigurasi ketersediaan di satu wilayah, kemudian melengkapinya dengan penyebaran tambahan di wilayah kedua.

Aspek lain yang perlu dipertimbangkan dalam skenario ini adalah failover dan pengalihan klien. Asumsinya adalah bahwa failover antar instans SAP Hana di dua wilayah Azure yang berbeda selalu merupakan failover manual. Karena mode replikasi dari replikasi sistem SAP Hana diatur menjadi asinkron, ada kemungkinan data yang diterapkan dalam instans HANA utama belum berhasil sampai ke instans HANA sekunder. Oleh karena itu, failover otomatis bukanlah pilihan untuk konfigurasi yang replikasinya asinkron. Bahkan dengan failover yang dikontrol secara manual, seperti dalam latihan failover, Anda perlu mengambil tindakan untuk memastikan bahwa semua data yang diterapkan di sisi utama berhasil mencapai instans sekunder sebelum Anda secara manual pindah ke wilayah Azure lainnya.

Azure Virtual Network menggunakan rentang alamat IP yang berbeda. Alamat IP disebarkan di wilayah Azure kedua. Jadi, Anda perlu mengubah konfigurasi klien SAP Hana, atau sebaiknya, Anda perlu membuat langkah-langkah untuk mengubah resolusi nama. Dengan cara ini, klien diarahkan ke alamat IP server situs sekunder baru. Untuk informasi selengkapnya, lihat artikel SAP Pemulihan koneksi klien setelah pengambilalihan.

Ketersediaan sederhana antara dua wilayah Azure

Anda mungkin memilih untuk tidak menempatkan konfigurasi ketersediaan apa pun dalam satu wilayah, tetapi masih memiliki permintaan agar beban kerja dilayani jika terjadi bencana. Kasus umum untuk skenario tersebut adalah sistem nonproduksi. Meskipun sistem tidak berfungsi selama setengah hari atau bahkan sehari berkelanjutan, Anda tidak dapat membiarkan sistem tidak tersedia selama 48 jam atau lebih. Untuk membuat penyiapan lebih murah, jalankan sistem lain yang bahkan kurang penting di VM. Fungsi sistem lain sebagai tujuan. Anda juga dapat mengubah ukuran VM di wilayah sekunder menjadi lebih kecil, dan memilih data tidak dimuat sebelumnya. Karena failover bersifat manual dan memerlukan lebih banyak langkah untuk memindahkan pada tumpukan aplikasi yang lengkap, waktu tambahan untuk mematikan VM, mengubah ukurannya, dan kemudian menghidupkan ulang VM dapat diterima.

Jika Anda menggunakan skenario berbagi target DR dengan sistem QA dalam satu VM, Anda perlu mempertimbangkan pertimbangan ini:

• Ada dua mode operasi dengan delta_datashipping dan logreplay, yang tersedia untuk skenario tersebut
• Kedua mode operasi memiliki persyaratan memori yang berbeda tanpa memuat data sebelumnya
• Delta_datashipping mungkin memerlukan memori yang jauh lebih sedikit tanpa opsi muat sebelumnya daripada yang dibutuhkan oleh logreplay. Lihat bab 4.3 dokumen SAP Cara Melakukan Replikasi Sistem untuk SAP Hana
• Persyaratan memori mode operasi logreplay tanpa pramuat tidak deterministik dan tergantung pada struktur penyimpan kolom yang dimuat. Dalam kasus ekstrem, Anda mungkin memerlukan 50% memori instans utama. Memori untuk mode operasi logreplay tidak tergantung pada apakah Anda memilih untuk mengatur data yang dimuat sebelumnya atau tidak.

Catatan

Dalam konfigurasi ini, Anda tidak dapat memberikan RPO=0 karena mode replikasi sistem HANA Anda tidak sinkron. Jika Anda perlu memberikan RPO=0, konfigurasi ini bukan konfigurasi pilihan.

Perubahan kecil yang dapat Anda buat dalam konfigurasi mungkin mengonfigurasi data sebagai memuat sebelumnya. Namun, mengingat sifat failover yang manual dan fakta bahwa lapisan aplikasi juga perlu dipindahkan ke wilayah kedua, mungkin tidak masuk akal untuk data dimuat sebelumnya.

Menggabungkan ketersediaan dalam satu wilayah dan seluruh wilayah

Kombinasi ketersediaan di dalam dan di seluruh wilayah mungkin didorong oleh faktor-faktor berikut:

• Persyaratan RPO=0 dalam wilayah Azure.
• Organisasi tidak ingin atau tidak mampu memiliki operasi global yang dipengaruhi oleh bencana alam besar yang memengaruhi wilayah yang lebih besar. Ini adalah kasus beberapa badai yang melanda Karibia selama beberapa tahun terakhir.
• Peraturan yang menuntut jarak antara situs utama dan sekunder yang jelas melampaui apa yang dapat disediakan oleh zona ketersediaan Azure.

Dalam kasus ini, Anda dapat menyiapkan apa yang disebut SAP konfigurasi replikasi sistem multi-tingkat SAP Hana dengan menggunakan replikasi sistem HANA. Arsitekturnya akan terlihat seperti:

SAP memperkenalkan replikasi sistem multi-target dengan HANA 2.0 SPS3. Replikasi sistem multi-target membawa beberapa keuntungan dalam skenario pembaruan. Misalnya, situs DR (Wilayah 2) tidak terpengaruh ketika situs HA sekunder tidak berfungsi untuk pemeliharaan atau pembaruan. Anda dapat mencari tahu selengkapnya tentang replikasi sistem multi-target HANA di Portal Bantuan SAP. Arsitektur yang mungkin dengan replikasi multi-target akan terlihat seperti:

Jika organisasi memiliki persyaratan untuk kesiapan ketersediaan tinggi di wilayah Azure kedua (DR), arsitekturnya akan terlihat seperti:

Menggunakan logreplay sebagai mode operasi, konfigurasi ini memberikan RPO=0, dengan RTO rendah, dalam wilayah utama. Konfigurasi tersebut juga memberikan RPO yang layak jika pemindahan ke wilayah kedua terlibat. Waktu RTO di wilayah kedua bergantung pada apakah data sudah dimuat sebelumnya. Banyak pelanggan menggunakan VM di wilayah sekunder untuk menjalankan sistem uji. Dalam kasus penggunaan tersebut, data tidak dapat dimuat sebelumnya.

Penting

Mode operasi antar tingkatan yang berbeda harus homogen. Anda tidak dapat menggunakan logreplay sebagai mode operasi antara tingkat 1 dan tingkat 2 dan delta_datashipping untuk menyediakan tingkat 3. Anda hanya dapat memilih satu atau mode operasi lainnya yang konsisten untuk semua tingkatan. Karena delta_datashipping tidak cocok untuk memberi Anda RPO=0, satu-satunya mode operasi yang masuk akal untuk konfigurasi multi-tingkat seperti itu tetaplah logreplay. Untuk detail tentang mode operasi dan beberapa batasan, lihat artikel SAP Mode operasi untuk replikasi sistem SAP Hana.

Langkah berikutnya

Untuk panduan langkah demi langkah tentang menyiapkan konfigurasi tersebut di Azure, lihat:

• Menyiapkan replikasi sistem SAP Hana pada Azure VM
• Ketersediaan tinggi untuk SAP Hana menggunakan replikasi sistem