Bagikan melalui

Ketersediaan SAP Hana dalam satu wilayah Azure

  • Artikel

Artikel ini menjelaskan beberapa skenario ketersediaan untuk SAP Hana dalam satu wilayah Azure. Azure memiliki banyak wilayah, tersebar di seluruh dunia. Untuk daftar kawasan Azure, lihat Kawasan Azure. Untuk menyebarkan SAP Hana pada VM dalam satu wilayah Azure, Microsoft menawarkan penyebaran VM tunggal dengan instans HANA. Untuk peningkatan ketersediaan, Anda dapat menyebarkan dua VM dengan dua instans HANA menggunakan set skala fleksibel dengan FD=1, zona ketersediaan, atau set ketersediaan yang menggunakan replikasi sistem HANA untuk ketersediaan.

Wilayah Azure yang menyediakan Zona Ketersediaan terdiri dari beberapa pusat data, masing-masing dengan sumber daya, pendinginan, dan infrastruktur jaringannya sendiri. Tujuan menawarkan zona yang berbeda dalam satu wilayah Azure adalah untuk mengaktifkan penyebaran aplikasi di dua atau tiga Zona Ketersediaan yang tersedia. Dengan mendistribusikan penyebaran aplikasi Anda di seluruh zona, masalah daya atau jaringan apa pun yang memengaruhi infrastruktur Zona Ketersediaan Azure tertentu tidak akan sepenuhnya mengganggu fungsionalitas aplikasi Anda dalam wilayah Azure. Meskipun mungkin ada beberapa kapasitas yang berkurang, seperti potensi hilangnya VM dalam satu zona, VM di zona yang tersisa akan terus beroperasi tanpa gangguan. Untuk menyiapkan dua instans HANA di VM terpisah yang mencakup berbagai zona, Anda memiliki opsi untuk menyebarkan VM menggunakan set skala fleksibel dengan FD=1 atau opsi penyebaran zona ketersediaan.

Untuk peningkatan ketersediaan dalam suatu wilayah, disarankan untuk menyebarkan dua VM dengan dua instans HANA menggunakan set ketersediaan. Set Ketersediaan Azure adalah kemampuan pengelompokan logis yang memastikan bahwa sumber daya VM yang dikonfigurasi dalam Set Ketersediaan diisolasi kegagalan satu sama lain saat disebarkan dalam pusat data Azure. Azure memastikan bahwa VM yang Anda tempatkan dalam Set Ketersediaan berjalan di beberapa server fisik, rak komputasi, unit penyimpanan, dan pengalihan jaringan. Dalam beberapa dokumentasi Azure, konfigurasi ini disebut sebagai penempatan di domain pembaruan dan kesalahan yang berbeda. Penempatan ini biasanya berada dalam pusat data Azure. Dengan asumsi bahwa sumber daya dan masalah jaringan akan memengaruhi pusat data yang Anda sebarkan, semua kapasitas Anda di satu wilayah Azure akan terpengaruh.

Penempatan pusat data yang mewakili Zona Ketersediaan Azure adalah kompromi antara memberikan latensi jaringan yang dapat diterima antar layanan yang disebarkan di zona yang berbeda, dan jarak antar pusat data. Bencana alam idealnya tidak akan memengaruhi daya, pasokan jaringan, dan infrastruktur untuk semua Zona Ketersediaan di wilayah ini. Namun, seperti yang telah ditunjukkan oleh bencana alam monumental, Zona Ketersediaan mungkin tidak selalu menyediakan ketersediaan yang Anda inginkan dalam satu wilayah. Misalnya Badai Maria yang melanda pulau Puerto Rico pada 20 September 2017. Badai tersebut menyebabkan pemadaman hampir 100 persen di pulau selebar 90 mil itu.

Skenario VM Tunggal

Dalam skenario VM tunggal, Anda membuat Azure VM untuk instans SAP Hana. Anda menggunakan Penyimpanan Premium Azure untuk menghosting disk sistem operasi dan semua disk data Anda. SLA waktu aktif Azure sebesar 99,9 persen dan SLA komponen Azure lainnya cukup bagi Anda untuk memenuhi ketersediaan SLA untuk pelanggan Anda. Dalam skenario ini, Anda tidak perlu menggunakan Set Ketersediaan Azure untuk VM yang menjalankan lapisan DBMS. Dalam skenario ini, Anda mengandalkan dua fitur berbeda:

  • Mulai ulang otomatis Azure VM (juga disebut sebagai penyembuhan layanan Azure)
  • Mulai ulang otomatis SAP Hana

Restart otomatis Azure VM, atau penyembuhan layanan, adalah fungsionalitas di Azure yang berfungsi pada dua tingkat:

  • Host server Azure memeriksa kesehatan VM yang dihosting di host server.
  • Pengontrol kain Azure memantau kesehatan dan ketersediaan host server.

Fungsionalitas pemeriksaan kesehatan memantau kesehatan setiap VM yang dihosting di host server Azure. Jika VM berada dalam keadaan tidak sehat, reboot VM dapat dimulai oleh agen host Azure yang memeriksa kesehatan VM. Pengontrol kain memeriksa kesehatan host dengan memeriksa banyak parameter berbeda yang mungkin menunjukkan masalah dengan perangkat keras host. Pengontrol kain juga memeriksa aksesibilitas host melalui jaringan. Indikasi masalah dengan host dapat menyebabkan peristiwa berikut:

  • Jika host memberi sinyal kondisi kesehatan yang buruk, reboot host dan restart VM yang berjalan pada host dipicu.
  • Jika host tidak dalam keadaan sehat setelah reboot berhasil, penyebaran ulang VM yang awalnya pada node yang sekarang tidak sehat ke server host yang sehat dimulai. Dalam hal ini, host asli ditandai sebagai tidak sehat. Host asli tidak akan digunakan untuk penyebaran lebih lanjut sampai dibersihkan atau diganti.
  • Jika host yang tidak sehat bermasalah selama proses reboot, tindakan hidupkan ulang segera mesin virtual pada host yang sehat akan dipicu.

Dengan host dan pemantauan VM yang disediakan oleh Azure, Azure VM yang mengalami masalah host secara otomatis dimulai ulang pada host Azure yang sehat.

Penting

Penyembuhan layanan Azure tidak akan memulai ulang VM Linux di mana OS tamu dalam keadaan panik kernel. Pengaturan default dari rilis Linux yang umum digunakan, tidak secara otomatis memulai ulang VM atau server di mana kernel Linux dalam keadaan panik. Sebaliknya, default akan mempertahankan OS dalam keadaan panik kernel untuk dapat melampirkan debugger kernel untuk dianalisis. Azure menghormati perilaku tersebut dengan tidak secara otomatis memulai ulang VM dengan OS tamu dalam keadaan seperti itu. Asumsinya adalah bahwa kejadian seperti itu sangat jarang terjadi. Anda bisa mengganti perilaku default untuk mengaktifkan restart VM. Untuk mengubah perilaku default aktifkan parameter 'kernel.panic' di /etc/sysctl.conf. Waktu yang Anda tetapkan untuk parameter ini adalah dalam hitungan detik. Nilai yang direkomendasikan umumnya adalah menunggu selama 20-30 detik sebelum memicu reboot melalui parameter ini. Untuk informasi selengkapnya, lihat sysctl.conf.

Fitur kedua yang Anda andalkan dalam skenario ini adalah fakta bahwa layanan HANA yang berjalan dalam VM yang dimulai ulang dimulai secara otomatis setelah VM melakukan reboot. Anda dapat menyiapkan mulai ulang otomatis layanan HANA melalui layanan pengawas dari berbagai layanan HANA.

Anda dapat meningkatkan skenario VM tunggal ini dengan menambahkan node kegagalan dingin ke konfigurasi SAP Hana. Dalam dokumentasi SAP Hana, penyiapan ini disebut host autofailover. Konfigurasi ini mungkin masuk akal dalam situasi penyebaran lokal di mana perangkat keras server terbatas, dan Anda mendedikasikan simpul server tunggal sebagai simpul autofailover host untuk serangkaian host produksi. Tetapi di Azure, di mana infrastruktur yang mendasar Azure menyediakan server target yang sehat untuk menghidupkan ulang VM yang berhasil, tidak masuk akal untuk menyebarkan autofailover host SAP Hana. Karena penyembuhan layanan Azure, tidak ada arsitektur referensi yang meratakan simpul siaga untuk autofailover host HANA.

Kasus khusus konfigurasi peluasan skala SAP Hana di Azure

Arsitektur ketersediaan tinggi berdasarkan simpul siaga atau Replikasi Sistem HANA dapat ditemukan dalam dokumen berikut. Dalam kasus di mana simpul siaga atau ketersediaan tinggi replikasi sistem HANA tidak digunakan dalam konfigurasi peluasan skala SAP Hana, Anda dapat bergantung pada kemampuan penyembuhan layanan Azure VM dan mulai ulang otomatis instans SAP Hana setelah VM beroperasi lagi.

Skenario ketersediaan untuk dua VM yang berbeda

Untuk memastikan ketersediaan sistem HANA dalam wilayah tertentu, Anda memiliki opsi untuk mengonfigurasi dua VM di seluruh zona ketersediaan wilayah atau di dalam wilayah. Untuk mencapai tujuan ini, Anda dapat mengonfigurasi VM menggunakan set skala fleksibel, zona ketersediaan, atau opsi penyebaran set ketersediaan. Pengaturan dasar di Azure akan terlihat seperti:

Diagram dua VM dengan semua lapisan.

Untuk mengilustrasikan skenario ketersediaan SAP Hana yang berbeda, beberapa lapisan dalam diagram dihilangkan. Diagram hanya memperlihatkan lapisan yang menggambarkan VM, host, Set Ketersediaan, dan wilayah Azure. Instans, grup sumber daya, dan langganan Azure Virtual Network tidak turut serta dalam skenario yang dijelaskan di bagian ini.

Mereplikasi cadangan ke komputer virtual kedua

Salah satu pengaturan yang paling mendasar adalah menggunakan cadangan. Khususnya, Anda mungkin memiliki cadangan log transaksi yang dikirim dari satu VM ke Azure VM lain. Anda dapat memilih jenis Azure Storage. Dalam penyiapan ini, Anda bertanggung jawab untuk membuat skrip salinan cadangan terjadwal yang dilakukan pada VM pertama ke VM kedua. Jika Anda perlu menggunakan instans VM kedua, Anda harus memulihkan cadangan lengkap, inkremental/diferensial, dan log transaksi ke titik yang Anda butuhkan.

Arsitekturnya terlihat seperti:

Diagram yang menunjukkan arsitektur dua VM dengan replikasi penyimpanan.

Penyiapan ini tidak cocok untuk mencapai waktu Tujuan Titik Pemulihan (RPO) dan Tujuan Waktu Pemulihan (RTO) yang hebat. Waktu RTO, terutama, akan menderita karena kebutuhan untuk sepenuhnya memulihkan database lengkap dengan menggunakan cadangan yang disalin. Namun, pengaturan ini berguna untuk memulihkan dari penghapusan data yang tidak diinginkan pada instans utama. Dengan pengaturan ini, kapan saja, Anda dapat memulihkan ke titik waktu tertentu, mengekstrak data, dan mengimpor data yang dihapus ke instans utama Anda. Oleh karena itu, mungkin masuk akal untuk menggunakan metode salinan cadangan yang dikombinasikan dengan fungsionalitas ketersediaan tinggi lainnya.

Saat cadangan sedang disalin, Anda mungkin dapat menggunakan VM yang lebih kecil daripada VM utama yang dijalankan instans SAP Hana. Perlu diingat bahwa Anda dapat melampirkan jumlah VHD yang lebih kecil ke VM yang lebih kecil. Untuk informasi tentang batas jenis VM individual, lihat Ukuran untuk komputer virtual Linux di Azure.

Replikasi sistem SAP Hana tanpa kegagalan otomatis

Skenario yang dijelaskan di bagian ini menggunakan replikasi sistem SAP Hana. Untuk dokumentasi SAP, lihat Replikasi sistem. Skenario tanpa failover otomatis tidak umum untuk konfigurasi dalam satu wilayah Azure. Konfigurasi tanpa kegagalan otomatis, meskipun menghindari pengaturan Pacemaker, mewajibkan Anda untuk memantau dan kegagalan secara manual. Karena ini membutuhkan upaya juga, sebagian besar pelanggan mengandalkan penyembuhan layanan Azure sebagai gantinya. Ada beberapa kasus edge di mana konfigurasi ini mungkin membantu dalam hal skenario kegagalan. Atau, dalam beberapa kasus, pelanggan mungkin ingin mewujudkan lebih banyak efisiensi.

Replikasi sistem SAP Hana tanpa kegagalan otomatis dan tanpa preload data

Dalam skenario ini, Anda menggunakan replikasi sistem SAP Hana untuk memindahkan data secara sinkron untuk mencapai RPO 0. Di sisi lain, Anda memiliki RTO yang cukup panjang sehingga Anda tidak memerlukan kegagalan atau preload data ke dalam cache instans HANA. Dalam hal ini, dimungkinkan untuk mencapai ekonomi lebih lanjut dalam konfigurasi Anda dengan mengambil tindakan berikut:

  • Jalankan instans SAP Hana lain di VM kedua. Instans SAP Hana di VM kedua memakan sebagian besar memori komputer virtual. Jika terjadi kegagalan pada VM kedua, Anda perlu mematikan instans SAP Hana yang berjalan yang memiliki data yang dimuat penuh di VM kedua, sehingga data yang direplikasi dapat dimuat ke dalam cache instans HANA yang ditargetkan di VM kedua.
  • Gunakan ukuran VM yang lebih kecil pada VM kedua. Jika kegagalan terjadi, Anda memiliki langkah tambahan sebelum kegagalan manual. Dalam langkah ini, Anda mengubah ukuran VM ke ukuran VM sumber.

Skenarionya terlihat seperti:

Diagram dua VM dengan replikasi penyimpanan.

Catatan

Bahkan jika Anda tidak menggunakan preload data dalam target replikasi sistem HANA, Anda memerlukan setidaknya 64 GB memori. Anda juga membutuhkan memori yang cukup selain 64 GB untuk menyimpan data rowstore dalam memori instans target.

Replikasi sistem SAP Hana tanpa kegagalan otomatis dan dengan preload data

Dalam skenario ini, data yang direplikasi ke instans HANA di VM kedua dimuat sebelumnya. Hal ini menghilangkan dua keuntungan dari tidak melakukan preload data. Dalam hal ini, Anda tidak dapat menjalankan sistem SAP Hana lain pada VM kedua. Anda juga tidak dapat menggunakan ukuran VM yang lebih kecil. Oleh karena itu, pelanggan jarang menerapkan skenario ini.

Replikasi sistem SAP Hana dengan kegagalan otomatis

Dalam konfigurasi ketersediaan standar dan paling umum dalam satu wilayah Azure, dua Azure VM yang menjalankan Linux dengan paket HA memiliki kluster failover yang ditentukan. Kluster HA Linux didasarkan pada Pacemaker kerangka kerja menggunakan SLES atau RHEL dengan fencing device SLES atau RHEL sebagai contoh.

Dari perspektif SAP Hana, mode replikasi yang digunakan disinkronkan dan kegagalan otomatis dikonfigurasi. Pada VM kedua, instans SAP Hana bertindak sebagai node siaga panas. Node siaga menerima aliran rekaman perubahan yang sinkron dari instans SAP Hana utama. Karena transaksi dilakukan oleh aplikasi di node utama HANA, node HANA utama menunggu untuk mengkonfirmasi penerapan pada aplikasi sampai node SAP Hana sekunder mengkonfirmasi bahwa ia menerima rekaman penerapan. SAP Hana menawarkan dua mode replikasi sinkron. Untuk detail dan untuk deskripsi perbedaan antara dua mode replikasi sinkron ini, lihat artikel SAP Mode replikasi untuk replikasi sistem SAP Hana.

Konfigurasi keseluruhan terlihat seperti:

Diagram dua VM dengan replikasi penyimpanan dan failover.

Anda dapat memilih solusi ini karena memungkinkan Anda mencapai RPO=0 dan RTO rendah. Konfigurasikan konektivitas klien SAP Hana sehingga klien SAP Hana menggunakan alamat IP virtual untuk terhubung ke konfigurasi replikasi sistem HANA. Konfigurasi demikian menghilangkan kebutuhan untuk mengonfigurasi ulang aplikasi jika kegagalan pada node sekunder terjadi. Dalam skenario ini, SKU Azure VM untuk VM primer dan sekunder harus sama.

Langkah berikutnya

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

Untuk informasi selengkapnya tentang ketersediaan SAP Hana di seluruh wilayah Azure, lihat: