Ketersediaan SAP Hana di seluruh wilayah Azure

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

Mengapa menyebarkan di beberapa wilayah Azure

Wilayah Azure sering dipisahkan oleh jarak yang besar. Tergantung pada wilayah geopolitik, jarak antara wilayah Azure mungkin ratusan mil, atau bahkan beberapa ribu mil, seperti di Amerika Serikat. Karena jaraknya, lalu lintas jaringan antara aset yang disebarkan di dua wilayah Azure yang berbeda mengalami latensi pulang pergi jaringan yang signifikan. Latensi ini cukup signifikan untuk mengecualikan pertukaran data sinkron antara dua instans SAP Hana di bawah beban kerja SAP umum.

Di sisi lain, organisasi sering memiliki persyaratan jarak antara lokasi pusat data utama dan pusat data sekunder. Persyaratan jarak membantu memberikan 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 merancang 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, lalu melengkapi dengan penyebaran tambahan di wilayah kedua.

Aspek lain yang perlu dipertimbangkan dalam skenario ini adalah failover dan pengalihan klien. Asumsinya adalah bahwa failover antara instans SAP Hana di dua wilayah Azure yang berbeda selalu merupakan failover manual. Karena mode replikasi sistem SAP HANA diatur ke asinkron, ada potensi bahwa data yang diterapkan pada instans HANA utama belum mencapai instans HANA sekunder. Oleh karena itu, failover otomatis bukanlah opsi untuk konfigurasi di mana replikasi tidak sinkron. Bahkan dengan failover yang dikontrol secara manual, seperti dalam latihan failover, Anda perlu mengambil langkah-langkah untuk memastikan bahwa semua data yang telah disimpan di sisi utama telah dipindahkan ke sistem sekunder sebelum Anda beralih secara manual 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 pengalihan.

Ketersediaan sederhana antara dua wilayah Azure

Anda mungkin memilih untuk tidak menempatkan konfigurasi ketersediaan apa pun dalam satu wilayah, tetapi masih memiliki permintaan untuk melayani beban kerja jika bencana terjadi. Contoh kasus yang umum untuk skenario tersebut adalah sistem nonproduksi. Meskipun sistem mati selama setengah hari atau bahkan sehari, masih dapat ditoleransi, Anda tidak dapat mengizinkan sistem mati total selama 48 jam atau lebih. Untuk membuat pengaturan lebih murah, jalankan sistem lain yang bahkan kurang penting di VM. Sistem lainnya berfungsi sebagai tujuan. Anda juga dapat mengubah ukuran VM di wilayah sekunder menjadi lebih kecil, dan memilih untuk tidak memuat data terlebih dahulu. Karena failover dilakukan secara manual dan memerlukan lebih banyak langkah untuk melakukan failover pada seluruh tumpukan aplikasi, waktu tambahan yang dibutuhkan untuk mematikan VM, mengubah ukurannya, lalu memulai ulang VM dianggap 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 seperti itu
• Kedua mode operasi memiliki persyaratan memori yang berbeda tanpa memuat data sebelumnya
• Delta_datashipping mungkin membutuhkan memori yang jauh lebih sedikit tanpa opsi pramuat dibandingkan dengan memori yang mungkin dibutuhkan oleh logreplay. Lihat bab 4.3 dari 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% dari memori instans utama. Memori untuk mode operasi logreplay tidak tergantung pada apakah Anda memilih untuk mengatur data yang sudah dimuat sebelumnya atau tidak.

Nota

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

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

Menggabungkan ketersediaan dalam satu wilayah dan di seluruh wilayah

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

• Persyaratan RPO=0 dalam wilayah Azure.
• Organisasi tidak bersedia atau tidak dapat memungkinkan operasi global terpengaruh oleh bencana alam besar yang memengaruhi wilayah yang lebih besar. Ini adalah kasus untuk beberapa badai yang melanda Karibia selama beberapa tahun terakhir.
• Peraturan yang meminta jarak antara situs primer dan sekunder yang jelas melebihi 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 mengetahui lebih lanjut 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), arsitektur akan terlihat seperti:

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

Penting

Mode operasi antara berbagai tingkatan 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 lain yang perlu konsisten untuk semua tingkatan. Karena delta_datashipping tidak cocok untuk memberi Anda RPO=0, satu-satunya mode operasi yang wajar untuk konfigurasi multi-tingkat tersebut tetap 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