Konfigurasi beban kerja SAP dengan Azure Availability Zones

  • Artikel

Selain penyebaran lapisan arsitektur SAP yang berbeda dalam set ketersediaan Azure, Zona Ketersediaan Azure juga dapat digunakan untuk penyebaran beban kerja SAP. Zona Ketersediaan Azure didefinisikan sebagai: "Lokasi fisik unik dalam suatu wilayah. Setiap zona terdiri dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen". Zona Ketersediaan Azure tidak tersedia di semua wilayah. Untuk wilayah Azure yang menyediakan Zona Ketersediaan, periksa peta kawasan Azure. Peta ini akan menunjukkan kepada Anda wilayah mana yang menyediakan atau diumumkan untuk menyediakan Zona Ketersediaan.

Pada arsitektur SAP NetWeaver atau S/4HANA yang khas, Anda perlu melindungi tiga lapisan berbeda:

  • Lapisan aplikasi SAP, yang dapat berupa satu hingga beberapa mesin virtual. Anda ingin meminimalkan kemungkinan VM disebarkan di server host yang sama. Anda juga ingin VM tersebut berada dalam kedekatan yang dapat diterima dengan lapisan DBMS untuk menjaga latensi jaringan di jendela yang dapat diterima
  • Lapisan ASCS/SCS SAP yang mewakili satu titik kegagalan dalam arsitektur NetWeaver SAP dan S/4Hana. Anda biasanya melihat dua VM yang ingin Anda tutupi dengan kerangka kerja failover. Oleh karena itu, VM ini harus dialokasikan di domain kesalahan infrastruktur yang berbeda
  • Lapisan SAP DBMS, yang juga mewakili satu titik kegagalan. Dalam kasus biasa, ia terdiri dari dua VM yang ditutupi oleh kerangka kerja failover. Oleh karena itu, VM ini harus dialokasikan di domain kesalahan infrastruktur yang berbeda. Pengecualian adalah penyebaran peluasan skala SAP Hana dengan lebih dari dua VM dapat digunakan

Perbedaan utama antara menyebarkan VM penting Anda melalui set ketersediaan atau Zona Ketersediaan adalah:

  • Menyebarkan dengan set ketersediaan adalah menyusun VM dalam set pada satu zona atau pusat data (apa pun yang berlaku untuk wilayah tertentu). Akibatnya penyebaran melalui set ketersediaan tidak dilindungi oleh masalah daya, pendinginan, atau jaringan yang memengaruhi pemisah data zona secara keseluruhan. Sisi positifnya, VM diselaraskan dengan domain pembaruan dan kesalahan dalam zona atau pusat data tersebut. Khusus untuk lapisan SAP ASCS atau DBMS di mana kami melindungi dua VM per set ketersediaan, penyelarasan dengan domain kesalahan mencegah bahwa kedua VM berakhir pada perangkat keras host yang sama.
  • Pada penyebaran VM melalui Zona Ketersediaan Azure dan memilih zona yang berbeda (maksimum tiga kemungkinan), akan menyebarkan VM di berbagai lokasi fisik dan dengan itu menambahkan perlindungan dari masalah daya, pendinginan, atau jaringan yang memengaruhi dataceter zona secara keseluruhan. Namun, saat Anda menyebarkan lebih dari satu VM dari keluarga VM yang sama ke Zona Ketersediaan yang sama, tidak ada perlindungan dari VM tersebut yang berakhir pada host yang sama atau domain kesalahan yang sama. Akibatnya, penyebaran melalui Zona Ketersediaan sangat ideal untuk lapisan SAP ASCS dan DBMS dengan kita biasanya melihat masing-masing dua VM. Untuk lapisan aplikasi SAP, yang dapat secara drastis lebih dari dua VM, Anda mungkin perlu mundur ke model penyebaran yang berbeda (lihat nanti)

Motivasi Anda untuk penyebaran di seluruh Zona Ketersediaan Azure adalah bahwa Anda, selain menutupi kegagalan satu VM penting atau kemampuan mengurangi waktu henti untuk melakukan patching perangkat lunak dalam kritis, ingin melindungi dari masalah infrastruktur yang lebih besar yang mungkin memengaruhi ketersediaan satu atau beberapa pusat data Azure.

Sebagai fungsionalitas penyebaran ketahanan lain, Azure memperkenalkan set skala komputer virtual dengan orkestrasi fleksibel untuk beban kerja SAP. Set skala komputer virtual menyediakan pengelompokan logis komputer virtual yang dikelola platform. Orkestrasi fleksibel set skala komputer virtual menyediakan opsi untuk membuat set skala dalam wilayah atau menjangkaunya di seluruh zona ketersediaan. Saat membuat, skala fleksibel yang ditetapkan dalam wilayah dengan platformFaultDomainCount>1 (FD>1), VM yang disebarkan dalam set skala akan didistribusikan di sejumlah domain kesalahan tertentu di wilayah yang sama. Di sisi lain, membuat skala fleksibel yang ditetapkan di seluruh zona ketersediaan dengan platformFaultDomainCount=1 (FD=1) akan mendistribusikan komputer virtual di berbagai zona dan set skala juga akan mendistribusikan VM di berbagai domain kesalahan di setiap zona berdasarkan upaya terbaik. Untuk beban kerja SAP hanya set skala fleksibel dengan FD=1 yang didukung. Keuntungan menggunakan set skala fleksibel dengan FD=1 untuk penyebaran lintas zona, alih-alih penyebaran zona ketersediaan tradisional adalah bahwa VM yang disebarkan dengan set skala akan didistribusikan di berbagai domain kesalahan dalam zona dengan cara upaya terbaik. Untuk informasi selengkapnya, lihat panduan penyebaran set skala fleksibel untuk beban kerja SAP.

Pertimbangan untuk menyebarkan di seluruh Zona Ketersediaan

Pertimbangkan hal berikut saat Anda menggunakan Zona Ketersediaan:

  • Latensi pulang pergi jaringan maksimum antara Zona Ketersediaan Azure dinyatakan di Wilayah dokumen dan zona ketersediaan.
  • Latensi pulang pergi jaringan yang berpengalaman tidak selalu menunjukkan jarak geografis nyata pusat data yang membentuk zona yang berbeda. Latensi pulang pergi jaringan juga dipengaruhi oleh konektivitas kabel dan perutean kabel antara pusat data yang berbeda ini.
  • Zona Ketersediaan bukan solusi DR yang ideal. Bencana alam dapat menyebabkan kerusakan luas di wilayah dunia, termasuk kerusakan berat pada infrastruktur listrik. Jarak antara berbagai zona mungkin tidak cukup besar untuk membentuk solusi DR yang tepat.
  • Latensi jaringan di seluruh Zona Ketersediaan tidak sama di semua wilayah Azure. Dalam beberapa kasus, Anda dapat menyebarkan dan menjalankan lapisan aplikasi SAP di berbagai zona karena latensi jaringan dari satu zona ke DBMS VM aktif dapat diterima. Akan tetapi, di beberapa wilayah Azure, latensi antara DBMS VM aktif dan instans aplikasi SAP, ketika disebarkan di zona yang berbeda, mungkin tidak dapat diterima untuk proses bisnis SAP. Dalam kasus ini, arsitektur penyebaran harus berbeda dengan arsitektur aktif/aktif untuk aplikasi atau arsitektur aktif/pasif dengan latensi jaringan lintas zona terlalu tinggi.
  • Saat memutuskan di mana akan menggunakan Zona Ketersediaan, buat keputusan Anda berdasarkan pada latensi jaringan antar zona. Latensi jaringan memainkan peran penting di dua area:
    • Latensi antara dua instans DBMS yang perlu memiliki replikasi sinkron. Semakin tinggi latensi jaringan, semakin besar kemungkinannya memengaruhi skalabilitas beban kerja Anda.
    • Perbedaan latensi jaringan antara VM yang menjalankan instans dialog SAP di zona dengan instans DBMS aktif dan VM serupa di zona lain. Ketika perbedaan ini meningkat, pengaruh pada durasi dari proses bisnis dan tugas batch juga meningkat, tergantung pada apakah mereka berjalan di zona dengan DBMS atau di zona yang berbeda.

Saat Anda menerapkan Azure VM di seluruh Zona Ketersediaan dan menetapkan solusi failover dalam wilayah Azure yang sama, beberapa pembatasan berlaku:

  • Anda harus menggunakan Disk Terkelola Azure saat Anda menyebarkan ke Zona Ketersediaan Azure.
  • Pemetaan enumerasi zona ke zona fisik ditetapkan berdasarkan langganan Azure. Jika Anda menggunakan langganan yang berbeda untuk menerapkan sistem SAP, Anda harus menentukan zona ideal untuk setiap langganan. Jika Anda ingin membandingkan pemetaan logis langganan Anda yang berbeda, pertimbangkan skrip Pemetaan Avzone
  • Anda tidak dapat menyebarkan set ketersediaan Azure dalam Zona Ketersediaan Azure kecuali Anda menggunakan Grup Penempatan Kedekatan Azure. Cara bagaimana Anda dapat menerapkan lapisan DBMS SAP dan layanan pusat di seluruh zona serta pada saat yang sama menerapkan lapisan aplikasi SAP menggunakan set ketersediaan dan masih mencapai kedekatan VM yang didokumentasikan dalam artikel Grup Penempatan Kedekatan Azure untuk latensi jaringan yang optimal dengan aplikasi SAP. Jika Anda tidak menggunakan grup penempatan kedekatan Azure, Anda perlu memilih satu atau yang lain sebagai kerangka kerja penyebaran untuk komputer virtual.
  • Anda tidak dapat menggunakan Azure Basic Load Balancer untuk membuat solusi kluster failover berdasarkan Pengklusteran Failover Windows Server atau Linux Pacemaker. Sebagai gantinya, Anda perlu menggunakan SKU Azure Standard Load Balancer.

Kombinasi Zona Ketersediaan yang ideal

Jika Anda ingin menyebarkan sistem SAP NetWeaver atau S/4HANA di seluruh zona, ada dua pola arsitektur yang dapat Anda sebarkan:

  • Aktif/aktif: Pasangan mesin virtual yang menjalankan ASCS/SCS dan pasangan mesin virtual yang menjalankan lapisan DBMS didistribusikan di dua zona. Jumlah VM yang menjalankan lapisan aplikasi SAP disebarkan dalam jumlah genap di dua zona yang sama. Jika DBMS atau ASCS/SCS VM gagal, beberapa transaksi terbuka dan aktif mungkin akan dibatalkan. Akan tetapi, pengguna tetap masuk. Tidak terlalu penting di zona mana VM DBMS aktif dan instans aplikasi berjalan. Arsitektur ini merupakan arsitektur yang lebih disukai untuk digunakan di seluruh zona.
  • Aktif/pasif: Pasangan mesin virtual yang menjalankan ASCS/SCS dan pasangan mesin virtual yang menjalankan lapisan DBMS didistribusikan di dua zona. Jumlah VM yang menjalankan lapisan aplikasi SAP disebarkan ke salah satu Zona Ketersediaan. Anda menjalankan lapisan aplikasi di zona yang sama dengan instans ASCS/SCS dan DBMS aktif. Anda menggunakan arsitektur penyebaran ini jika latensi jaringan di berbagai zona terlalu tinggi untuk menjalankan lapisan aplikasi yang didistribusikan di seluruh zona. Sebaliknya lapisan aplikasi SAP perlu berjalan di zona yang sama dengan ASCS/SCS aktif dan/atau instans DBMS. Jika ASCS/SCS atau DBMS VM gagal ke zona sekunder, Anda mungkin mengalami latensi jaringan yang lebih tinggi dan dengan pengurangan throughput tersebut. Dan Anda diharuskan untuk melakukan failback pada VM yang sebelumnya gagal sesegera mungkin untuk kembali ke tingkat throughput sebelumnya. Jika pemadaman zona terjadi, lapisan aplikasi harus gagal ke zona sekunder. Aktivitas yang dialami pengguna sebagai pematian sistem total. Di beberapa wilayah Azure, arsitektur ini adalah satu-satunya arsitektur yang layak ketika Anda ingin menggunakan Zona Ketersediaan. Jika Anda tidak dapat menerima dampak potensial dari ASCS/SCS atau DBMS VMS yang gagal ke zona sekunder, Anda mungkin lebih baik tetap menggunakan penyebaran set ketersediaan

Jadi sebelum Anda memutuskan bagaimana cara menggunakan Zona Ketersediaan, Anda perlu menentukan:

  • Latensi jaringan di antara tiga zona wilayah Azure. Mengetahui latensi jaringan antara zona suatu wilayah akan memungkinkan Anda untuk memilih zona dengan latensi jaringan paling kecil dalam lalu lintas jaringan lintas zona.
  • Perbedaan antara latensi VM-ke-VM dalam salah satu zona, pilihan Anda, dan latensi jaringan di dua zona yang Anda pilih.
  • Penentuan apakah jenis VM yang perlu Anda sebarkan tersedia di dua zona yang Anda pilih. Dengan beberapa SKU VM, Anda mungkin mengalami situasi di mana beberapa SKU hanya tersedia di dua dari tiga zona.

Latensi jaringan antara dan di dalam zona

Untuk menentukan latensi antara zona yang berbeda, Anda perlu:

  • Terapkan VM SKU yang ingin Anda gunakan untuk instans DBMS Anda di ketiga zona. Pastikan Azure Accelerated Networking diaktifkan saat Anda melakukan pengukuran ini. Jaringan terakselerasi adalah pengaturan default sejak beberapa tahun. Namun demikian, periksa apakah diaktifkan dan berfungsi
  • Ketika Anda menemukan dua zona dengan latensi jaringan paling kecil, sebarkan tiga VM lain dari VM SKU yang ingin Anda gunakan sebagai VM lapisan aplikasi di tiga Zona Ketersediaan. Ukur latensi jaringan terhadap dua DBMS VM di dua zona DBMS yang Anda pilih.
  • Gunakan niping sebagai alat pengukuran. Alat ini, dari SAP, dijelaskan dalam catatan dukungan SAP #500235 dan #1100926. Fokus pada perintah yang didokumentasikan untuk pengukuran latensi. Karena ping tidak berfungsi melalui jalur kode Azure Accelerated Networking, kami tidak menyarankan Anda menggunakannya.

Anda tidak perlu melakukan tes ini secara manual. Anda dapat menemukan prosedur PowerShell Tes Latensi Zona Ketersediaan yang mengotomatiskan tes latensi yang dijelaskan.

Berdasarkan pengukuran dan ketersediaan SKU VM Anda di Zona Ketersediaan, Anda perlu membuat beberapa keputusan:

  • Tentukan zona ideal untuk lapisan DBMS.
  • Tentukan apakah Anda ingin mendistribusikan lapisan aplikasi SAP aktif Anda di satu, dua, atau ketiga zona, berdasarkan perbedaan latensi jaringan dalam zona versus lintas zona.
  • Tentukan apakah Anda ingin menyebarkan konfigurasi aktif/pasif atau konfigurasi aktif/aktif, dari sudut pandang aplikasi. (Konfigurasi ini akan dijelaskan nanti di artikel ini.)

Dalam membuat keputusan ini, juga perhitungkan rekomendasi latensi jaringan SAP, seperti yang didokumentasikan dalam catatan SAP #1100926.

Penting

Pengukuran dan keputusan yang Anda buat valid untuk langganan Azure yang Anda gunakan saat melakukan pengukuran. Jika Anda menggunakan langganan Azure lain, pemetaan zona enumerasi mungkin berbeda untuk langganan Azure lainnya. Akibatnya, Anda perlu mengulangi pengukuran atau mencari tahu pemetaan langganan baru yang diwujudkan ke langganan lama alat skrip Pemetaan Avzone.

Penting

Diharapkan pengukuran yang dijelaskan sebelumnya akan memberikan hasil yang berbeda di setiap wilayah Azure yang mendukung Zona Ketersediaan. Bahkan jika persyaratan latensi jaringan Anda sama, Anda mungkin perlu mengadopsi strategi penyebaran yang berbeda di wilayah Azure yang berbeda karena latensi jaringan antar zona bisa berbeda. Di beberapa wilayah Azure, latensi jaringan di antara tiga zona yang berbeda bisa sangat berbeda. Di wilayah lain, latensi jaringan di antara tiga zona yang berbeda mungkin lebih seragam. Klaim bahwa selalu ada latensi jaringan antara 1 dan 2 milidetik tidak benar. Latensi jaringan di seluruh Zona Ketersediaan di wilayah Azure tidak dapat digeneralisasi.

Penyebaran Aktif/Aktif

Arsitektur penyebaran ini disebut aktif/aktif karena Anda menyebarkan server aplikasi SAP aktif Anda di dua atau tiga zona. Instans Layanan Pusat SAP yang menggunakan replikasi pengantrean akan disebarkan di antara dua zona. Hal yang sama berlaku untuk lapisan DBMS yang akan digunakan di seluruh zona yang sama dengan Layanan Pusat SAP. Saat mempertimbangkan konfigurasi ini, Anda perlu menemukan dua Zona Ketersediaan di wilayah Anda yang menawarkan latensi jaringan lintas zona yang dapat diterima untuk beban kerja Anda dan replikasi DBMS sinkron Anda. Anda juga ingin memastikan delta antara latensi jaringan dalam zona yang Anda pilih dan latensi jaringan lintas zona tidak terlalu besar.

Sifat arsitektur SAP adalah bahwa, kecuali jika Anda mengonfigurasinya secara berbeda, pengguna dan tugas batch dapat dijalankan dalam instans aplikasi yang berbeda. Efek samping dari fakta ini dengan penyebaran aktif/aktif adalah bahwa tugas batch dapat dijalankan oleh setiap instans aplikasi SAP independen apakah mereka berjalan di zona yang sama dengan DBMS aktif atau tidak. Jika perbedaan dalam latensi jaringan antara zona yang berbeda cukup kecil dibandingkan dengan latensi jaringan dalam suatu zona, perbedaan dalam durasi tugas batch mungkin tidak signifikan. Namun, semakin besar perbedaan latensi jaringan dalam zona, dibandingkan dengan lalu lintas jaringan di seluruh zona adalah, durasi pekerjaan batch dapat terpengaruh lebih banyak jika pekerjaan dieksekusi di zona tempat instans DBMS tidak aktif. Ada pada Anda sebagai pelanggan untuk memutuskan apa perbedaan yang dapat diterima dalam run time. Dan dengan itu, latensi jaringan yang dapat ditoleransi untuk lalu lintas zona adalah untuk beban kerja Anda.

Wilayah Azure di mana penyebaran aktif/aktif seperti itu dapat dimungkinkan tanpa perbedaan besar yang signifikan dalam durasi dan throughput dalam lapisan aplikasi yang disebarkan di berbagai Zona Ketersediaan, daftar seperti:

  • Australia Timur (dua dari tiga zona)
  • Brasil Selatan (ketiga zona)
  • India Tengah (ketiga zona)
  • US Tengah (ketiga zona)
  • Asia Timur (ketiga zona)
  • US Timur (dua dari tiga zona)
  • US2 Timur (ketiga zona)
  • Jerman Barat Tengah (ketiga zona)
  • Israel Tengah (ketiga zona)
  • Italia Utara (dua dari tiga zona)
  • Korea Tengah (ketiga zona)
  • Polandia Tengah (ketiga zona)
  • Qatar Tengah (ketiga zona)
  • Eropa Utara (ketiga zona)
  • Norwegia Timur (dua dari tiga zona)
  • Afrika Selatan Utara (dua dari tiga)
  • US Tengah Selatan (ketiga zona)
  • Asia Tenggara (ketiga zona)
  • Swedia Tengah (ketiga zona)
  • Swiss Utara (ketiga zona)
  • UAE Utara (ketiga zona)
  • UK Selatan (dua dari tiga zona)
  • Eropa Barat (dua dari tiga zona)
  • US2 Barat (ketiga zona)
  • US3 Barat (ketiga zona)

Daftar wilayah yang disediakan tidak melegakan Anda sebagai pelanggan untuk menguji beban kerja Anda untuk memutuskan apakah arsitektur penyebaran aktif/aktif dimungkinkan.

Wilayah Azure tempat arsitektur penyebaran SAP aktif/aktif di seluruh zona mungkin tidak dimungkinkan, daftar seperti:

  • Kanada Tengah
  • Prancis Tengah
  • Jepang Timur

Meskipun untuk beban kerja individu Anda, itu mungkin berhasil. Oleh karena itu, Anda harus menguji sebelum memutuskan arsitektur. Azure terus berupaya meningkatkan kualitas dan latensi jaringannya. Pengukuran yang dilakukan bertahun-tahun ke belakang mungkin tidak mencerminkan kondisi saat ini lagi.

Bergantung pada apa yang ingin Anda toleransi pada perbedaan run time wilayah lain yang tidak tercantum juga dapat memenuhi syarat.

Skema penyebaran aktif/aktif yang disederhanakan di dua zona bisa terlihat seperti ini:

Active/Active zone deployment

Pertimbangan berikut berlaku untuk konfigurasi ini:

Penting

Dalam skenario aktif/aktif ini, biaya untuk lalu lintas zona berlaku. Periksa dokumen Detail Harga Bandwidth. Transfer data antara lapisan aplikasi SAP dan lapisan SAP DBMS cukup intensif. Oleh karena itu skenario aktif/aktif dapat berkontribusi pada biaya.

Penyebaran Aktif/Pasif

Jika Anda tidak dapat menemukan delta yang dapat diterima antara latensi jaringan dalam satu zona dan latensi lalu lintas jaringan lintas zona, Anda dapat menyebarkan arsitektur yang memiliki karakter aktif/pasif dari sudut pandang lapisan aplikasi SAP. Anda menentukan zona aktif yang merupakan zona tempat Anda menyebarkan lapisan aplikasi lengkap dan tempat Anda mencoba menjalankan DBMS aktif dan instans Layanan Pusat SAP. Dengan konfigurasi seperti itu, Anda perlu memastikan bahwa Anda tidak memiliki variasi durasi yang ekstrem, tergantung pada apakah pekerjaan berjalan di dalam zona dengan instans DBMS aktif atau tidak, dalam transaksi bisnis dan tugas batch.

Wilayah Azure tempat jenis arsitektur penyebaran ini di berbagai zona dapat lebih disukai adalah:

  • Kanada Tengah
  • Prancis Tengah
  • Jepang Timur
  • Norwegia Timur
  • Afrika Selatan Utara

Tata letak dasar arsitektur terlihat seperti ini:

Active/Passive zone deployment

Pertimbangan berikut berlaku untuk konfigurasi ini:

  • Set ketersediaan tidak dapat disebarkan di Zona Ketersediaan Azure. Untuk menguranginya, Anda dapat menggunakan grup penempatan kedekatan Azure seperti yang didokumentasikan dalam artikel Grup Penempatan Kedekatan Azure untuk latensi jaringan yang optimal dengan aplikasi SAP.
  • Ketika Anda menggunakan arsitektur ini, Anda perlu memantau status dengan cermat dan mencoba untuk menjaga DBMS aktif dan instans Layanan Pusat SAP di zona yang sama dengan lapisan aplikasi yang Anda sebarkan. Jika ada failover SAP Central Service atau instans DBMS, Anda ingin memastikan bahwa Anda dapat melakukan failback secara manual ke zona dengan lapisan aplikasi SAP yang disebarkan secepat mungkin.
  • Untuk penyeimbang beban kluster failover dari Layanan Pusat SAP dan lapisan DBMS, Anda perlu menggunakan SKU Standar Azure Load Balancer. Azure Basic Load Balancer tidak akan berfungsi di seluruh zona.
  • Jaringan virtual Azure yang Anda sebarkan untuk meng-host sistem SAP, bersama dengan subnet-nya, terbentang di seluruh zona. Anda tidak memerlukan jaringan virtual terpisah untuk setiap zona.
  • Untuk semua komputer virtual yang Anda sebarkan, Anda perlu menggunakan Disk Terkelola Azure. Disk yang tidak dikelola tidak didukung untuk penyebaran zona.
  • Penyimpanan Premium Azure, penyimpanan SSD Ultra, atau ANF tidak mendukung semua jenis replikasi penyimpanan di seluruh zona. Untuk penyebaran DBMS, kami mengandalkan metode database untuk mereplikasi data di seluruh zona
  • Untuk berbagi SMB dan NFS berdasarkan Azure Premium Files, redundansi zona dengan replikasi sinkron ditawarkan. Periksa dokumen ini untuk ketersediaan ZRS untuk Azure Premium Files di wilayah yang ingin Anda sebarkan. Penggunaan berbagi NFS dan SMB yang direplikasi zona sepenuhnya didukung dengan penyebaran lapisan aplikasi SAP dan kluster failover ketersediaan tinggi untuk layanan pusat NetWeaver atau S/4HANA. Dokumen yang mencakup kasus-kasus ini adalah:
  • Zona ketiga digunakan untuk meng-host perangkat SBD jika Anda membangun kluster SUSE Linux Pacemaker dan menggunakan perangkat SBD alih-alih Azure Fencing Agent. Atau untuk instans aplikasi tambahan.
  • Anda harus menyebarkan VM yang tidak aktif di zona pasif (dari sudut pandang DBMS) sehingga Anda dapat memulai sumber daya aplikasi untuk kasus kegagalan zona. Kemungkinan lain adalah menggunakan Azure Site Recovery, yang dapat mereplikasi VM aktif ke VM yang tidak aktif antar zona.
  • Anda harus berinvestasi dalam otomatisasi yang memungkinkan Anda untuk secara otomatis memulai lapisan aplikasi SAP di zona kedua jika terjadi pemadaman zona.

Gabungan ketersediaan tinggi dan konfigurasi pemulihan bencana

Microsoft tidak membagikan informasi apa pun tentang jarak geografis antara fasilitas yang menjadi penyelenggara Zona Ketersediaan Azure yang berbeda di wilayah Azure. Namun, beberapa pelanggan menggunakan zona untuk gabungan konfigurasi HA dan DR yang menjanjikan objek titik pemulihan (RPO) nol. RPO nol berarti Anda tidak boleh kehilangan transaksi database yang diterapkan bahkan dalam kasus pemulihan bencana.

Catatan

Kami menyarankan agar Anda menggunakan konfigurasi seperti ini hanya dalam keadaan tertentu. Misalnya, Anda mungkin menggunakannya saat data tidak dapat meninggalkan wilayah Azure karena alasan keamanan atau kepatuhan.

Berikut adalah salah satu contoh bagaimana konfigurasi tersebut mungkin terlihat:

Combined high-availability DR in zones

Pertimbangan berikut berlaku untuk konfigurasi ini:

  • Anda juga berasumsi bahwa ada jarak yang signifikan antara fasilitas yang menyelenggarakan Zona Ketersediaan atau Anda terpaksa tinggal di wilayah Azure tertentu. Set ketersediaan tidak dapat disebarkan di Zona Ketersediaan Azure. Untuk mengimbanginya, Anda dapat menggunakan grup penempatan kedekatan Azure seperti yang didokumentasikan dalam artikel Grup Penempatan Kedekatan Azure untuk latensi jaringan yang optimal dengan aplikasi SAP.
  • Saat Anda menggunakan arsitektur ini, Anda perlu memantau status dengan cermat, dan mencoba menyimpan instans DBMS dan SAP Central Services aktif di zona yang sama dengan lapisan aplikasi yang Anda sebarkan. Jika ada failover SAP Central Service atau instans DBMS, Anda ingin memastikan bahwa Anda dapat melakukan failback secara manual ke zona dengan lapisan aplikasi SAP yang disebarkan secepat mungkin.
  • Anda harus memiliki instans aplikasi produksi yang telah diinstal sebelumnya di VM yang menjalankan instans aplikasi QA aktif.
  • Dalam kasus kegagalan zonal, matikan instans aplikasi QA dan mulai instans produksi sebagai gantinya. Anda perlu menggunakan nama virtual untuk instans aplikasi untuk membuatnya berfungsi.
  • Untuk penyeimbang beban kluster failover dari Layanan Pusat SAP dan lapisan DBMS, Anda perlu menggunakan SKU Standar Azure Load Balancer. Azure Basic Load Balancer tidak akan berfungsi di seluruh zona.
  • Jaringan virtual Azure yang Anda sebarkan untuk meng-host sistem SAP, bersama dengan subnet-nya, terbentang di seluruh zona. Anda tidak memerlukan jaringan virtual terpisah untuk setiap zona.
  • Untuk semua komputer virtual yang Anda sebarkan, Anda perlu menggunakan Disk Terkelola Azure. Disk yang tidak dikelola tidak didukung untuk penyebaran zona.
  • Penyimpanan Premium Azure, penyimpanan SSD Ultra, atau ANF tidak mendukung semua jenis replikasi penyimpanan di seluruh zona. Untuk penyebaran DBMS, kami mengandalkan metode database untuk mereplikasi data di seluruh zona
  • Untuk berbagi SMB dan NFS berdasarkan Azure Premium Files, redundansi zona dengan replikasi sinkron ditawarkan. Periksa dokumen ini untuk ketersediaan ZRS untuk Azure Premium Files di wilayah yang ingin Anda sebarkan. Penggunaan berbagi NFS dan SMB yang direplikasi zona sepenuhnya didukung dengan penyebaran lapisan aplikasi SAP dan kluster failover ketersediaan tinggi untuk layanan pusat NetWeaver atau S/4HANA. Dokumen yang mencakup kasus-kasus ini adalah:
  • Zona ketiga digunakan untuk meng-host perangkat SBD jika Anda membangun kluster SUSE Linux Pacemaker dan menggunakan perangkat SBD alih-alih Azure Fencing Agent.

Langkah berikutnya

Berikut adalah beberapa langkah berikutnya untuk menyebarkan di seluruh Zona Ketersediaan Azure: