Bagikan melalui

Konfigurasi beban kerja SAP dengan Azure Availability Zones

  • Artikel

Penyebaran berbagai lapisan arsitektur SAP di seluruh Zona Ketersediaan Azure adalah arsitektur yang direkomendasikan untuk penyebaran beban kerja SAP di Azure. 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. Artikel ini mencantumkan wilayah mana yang menyediakan Zona Ketersediaan. Sebagian besar wilayah Azure yang dilengkapi untuk menghosting beban kerja SAP yang lebih besar menyediakan Zona Ketersediaan. Wilayah Azure baru menyediakan Zona Ketersediaan sejak awal. Beberapa wilayah lama berada atau sedang dalam proses untuk diretrofit dengan 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 lusin Virtual Machines (VM). Anda ingin meminimalkan kemungkinan VM disebarkan di server host yang sama. Anda juga ingin VM tersebut berada di dekat lapisan database yang dapat diterima untuk menjaga latensi jaringan di jendela yang dapat diterima
  • Lapisan SAP ASCS/SCS yang mewakili satu titik kegagalan dalam arsitektur SAP NetWeaver 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 database SAP, 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 pusat data zona secara keseluruhan. Dengan set ketersediaan, juga tidak ada penyelarasan paksa antara VM dan disknya. Berarti, disk dapat berada di pusat data wilayah Azure mana pun, terlepas dari struktur zona wilayah. Sisi positifnya, VM diselaraskan dengan domain pembaruan dan kesalahan dalam zona atau pusat data tersebut. Khusus untuk SAP ASCS atau lapisan database di mana kami melindungi dua VM per set ketersediaan, penyelarasan dengan domain kesalahan mencegah bahwa kedua VM berakhir pada perangkat keras host yang sama.
  • Saat menyebarkan 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 pusat data zona secara keseluruhan. VM dan disk terkaitnya juga terletak di Zona Ketersediaan yang sama. 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, menyebarkan melalui Zona Ketersediaan sangat ideal untuk SAP ASCS dan lapisan database di mana kita biasanya melihat masing-masing dua VM. Untuk lapisan aplikasi SAP, yang dapat secara drastis lebih dari dua VM, Anda mungkin perlu kembali 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:

  • Informasi selengkapnya tentang Zona Ketersediaan Azure disajikan 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.
  • Jika Anda menggunakan Zona Ketersediaan sebagai solusi DR jarak kecil, perlu diingat bahwa kami mengalami bencana alam yang menyebabkan kerusakan luas di berbagai wilayah di dunia, termasuk kerusakan berat dan meluas pada infrastruktur listrik. Jarak antara berbagai zona mungkin tidak selalu cukup besar untuk mengimbangi bencana alam yang lebih besar tersebut.
  • Latensi jaringan di seluruh Zona Ketersediaan tidak sama di semua wilayah Azure. Bahkan dalam wilayah Azure, latensi jaringan antara zona yang berbeda dapat bervariasi. Meskipun dalam kasus terburuk, replikasi sinkron pada tingkat database berdasarkan Replikasi Sistem HANA atau SQL Server Always On akan berfungsi tanpa memengaruhi skalabilitas beban kerja.
  • 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 database yang perlu memiliki replikasi sinkron. Berdasarkan operasi yang sangat sukses dari sistem NetWeaver dan S/4HANA terbesar antara zona dengan latensi jaringan yang lebih tinggi (kurang dari 1,5 milidetik), pertimbangan ini dapat diabaikan
    • Perbedaan latensi jaringan antara VM yang menjalankan instans dialog SAP di zona dengan instans database aktif dan VM serupa di zona lain. Ketika perbedaan ini meningkat, pengaruh pada waktu berjalan proses bisnis dan pekerjaan batch juga meningkat, tergantung pada apakah mereka berjalan di zona dengan database atau di zona yang berbeda (lihat nanti di artikel ini).
  • Latensi jaringan dengan Zona Ketersediaan Azure, bahkan di zona terbesar, cukup rendah untuk menjalankan proses bisnis SAP. Sejauh ini, kami hanya melihat beberapa kasus luar biasa di mana pelanggan perlu mengumpulkan lapisan aplikasi SAP dan lapisan database di bawah satu tulang belakang jaringan pusat data.

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 Anda dapat menyebarkan lapisan database SAP dan layanan pusat di seluruh zona dan pada saat yang sama menyebarkan lapisan aplikasi SAP menggunakan set ketersediaan dan masih mencapai kedekatan VM 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.
  • Anda perlu menyebarkan versi zona alamat ExpressRoute Gateway, VPN Gateway, dan IP Publik Standar untuk mendapatkan perlindungan zonal yang Anda inginkan.

Kombinasi Zona Ketersediaan yang ideal

Kecuali Anda mengonfigurasi penetapan proses bisnis dengan fungsionalitas SAP seperti Grup Masuk, Grup Server RFC, Grup Server Batch, dan yang serupa, proses bisnis dapat dijalankan dalam instans aplikasi yang berbeda di seluruh lapisan aplikasi SAP Anda. Efek samping dari fakta ini adalah bahwa pekerjaan batch mungkin dijalankan oleh instans aplikasi SAP apa pun yang independen pada apakah yang berjalan di zona yang sama dengan instans database 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 database 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. Murni dari sudut pandang teknis, latensi jaringan antara Zona Ketersediaan Azure dalam wilayah Azure berfungsi untuk arsitektur NetWeaver, S/4HANA, atau aplikasi SAP lainnya. Anda juga berpotensi untuk mengurangi perbedaan tersebut menggunakan konsep SAP Grup Masuk, Grup Server RFC, Grup Server Batch, dan serupa ketika Anda memutuskan salah satu konsep penyebaran yang kami perkenalkan dalam artikel ini.

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

  • Aktif/aktif: Pasangan VM yang menjalankan ASCS/SCS dan sepasang VM yang menjalankan lapisan database didistribusikan di dua zona. VM yang menjalankan lapisan aplikasi SAP disebarkan dalam jumlah genap di dua zona yang sama. Jika database atau ASCS/SCS VM gagal, beberapa transaksi terbuka dan aktif mungkin digulung balik. Akan tetapi, pengguna tetap masuk. Tidak terlalu penting di zona mana VM database aktif dan instans aplikasi berjalan. Arsitektur ini merupakan arsitektur yang lebih disukai untuk digunakan di seluruh zona. Dalam kasus di mana latensi jaringan antar zona menyebabkan perbedaan yang lebih besar saat menjalankan proses bisnis, Anda dapat menggunakan fungsionalitas seperti Grup Masuk SAP, Grup Server RFC, Grup Server Batch, dan mirip dengan merutekan eksekusi proses bisnis ke instans dialog tertentu yang berada di zona yang sama dengan instans database aktif
  • Aktif/pasif: Pasangan VM yang menjalankan ASCS/SCS dan sepasang VM yang menjalankan lapisan database didistribusikan di dua zona. VM yang menjalankan lapisan aplikasi SAP disebarkan ke salah satu Zona Ketersediaan. Anda menjalankan lapisan aplikasi di zona yang sama dengan ASCS/SCS aktif dan instans database. Anda dapat menggunakan arsitektur penyebaran ini jika Anda dianggap latensi jaringan di berbagai zona terlalu tinggi. Dan dengan itu menyebabkan perbedaan yang tidak dapat ditoleransi dalam runtime proses bisnis Anda. Atau jika Anda ingin menggunakan penyebaran Zona Ketersediaan sebagai penyebaran DR Jarak Pendek. zona. Jika ASCS/SCS atau VM database 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.

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:

  • Sebarkan SKU VM yang ingin Anda gunakan untuk instans database 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 VM database di dua zona yang Anda pilih.
  • Gunakan niping sebagai alat pengukuran. Alat ini, dari SAP, dijelaskan dalam catatan dukungan SAP #500235 dan #1100926. Perlakukan klasifikasi latensi jaringan di Catatan SAP #1100926 sebagai panduan kasar. Latensi jaringan yang lebih besar dari 0,7 milidetik tidak berarti bahwa sistem tidak akan berfungsi secara teknis atau bahwa proses bisnis tidak memenuhi SLA individu Anda. Catatan ini tidak dimaksudkan untuk menyatakan apa yang didukung atau tidak didukung oleh SAP dan/atau Microsoft. 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 database.
  • 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.)

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 bahwa pengukuran yang dijelaskan sebelumnya 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 antrean disebarkan di antara dua zona. Hal yang sama berlaku untuk lapisan database, yang disebarkan 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. Anda juga ingin memastikan delta antara latensi jaringan dalam zona yang Anda pilih dan latensi jaringan lintas zona dapat diterima untuk beban kerja Anda.

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

Penyebaran zona Aktif/Aktif

Pertimbangan berikut berlaku untuk konfigurasi ini:

  • Tidak menggunakan Grup Penempatan Kedekatan Azure, Anda memperlakukan Zona Ketersediaan Azure sebagai domain kesalahan untuk semua VM karena set ketersediaan tidak dapat disebarkan di Zona Ketersediaan Azure.
  • Jika Anda ingin menggabungkan penyebaran zona untuk lapisan database dan layanan pusat, tetapi ingin menggunakan set ketersediaan Azure untuk lapisan aplikasi, Anda perlu menggunakan grup kedekatan Azure seperti yang dijelaskan dalam artikel Grup Penempatan Kedekatan Azure untuk latensi jaringan yang optimal dengan aplikasi SAP.
  • Untuk load balancer kluster failover SAP Central Services dan lapisan database, Anda perlu menggunakan Standard SKU Azure Load Balancer. Load Balancer Dasar tidak berfungsi di seluruh zona.
  • Anda perlu menyebarkan versi zona alamat ExpressRoute Gateway, VPN Gateway, dan IP Publik Standar untuk mendapatkan perlindungan zonal yang Anda inginkan.
  • Jaringan virtual Azure yang Anda sebarkan untuk meng-host sistem SAP, bersama dengan subnet-nya, terbentang di seluruh zona. Anda tidak memerlukan jaringan virtual dan subnet 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.
  • Azure Premium SSD v2, penyimpanan Ultra SSD, atau Azure NetApp Files tidak mendukung replikasi penyimpanan sinkron di seluruh zona. Untuk penyebaran database, kami mengandalkan metode database untuk mereplikasi data di seluruh zona.
  • SSD premium v1 yang mendukung replikasi zona sinkron di seluruh Zona Ketersediaan belum diuji dengan beban kerja database SAP. Oleh karena itu, replikasi zona sinkron Azure Premium SSD v1 perlu dianggap tidak didukung untuk beban kerja database SAP.
  • 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 lainnya.
  • Untuk mencapai konsistensi run time untuk proses bisnis penting, Anda dapat mencoba mengarahkan pekerjaan batch dan pengguna tertentu ke instans aplikasi yang berada di zona dengan instans database aktif dengan menggunakan grup server batch SAP, grup masuk SAP, atau grup RFC. Namun, dalam proses failover zonal, Anda harus memindahkan grup ini secara manual ke instans yang berjalan pada VM yang berada di zona dengan VM DB aktif.
  • Anda mungkin ingin menyebarkan instans dialog yang tidak aktif di setiap zona.

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 database SAP cukup intensif. Oleh karena itu skenario aktif/aktif dapat berkontribusi pada biaya.

Penyebaran Aktif/Pasif

Jika Anda tidak dapat menemukan konfigurasi yang mengurangi delta potensial dalam runtime proses bisnis SAP atau jika Anda ingin menyebarkan konfigurasi pemulihan bencana jarak pendek, 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 instans database aktif dan instans Layanan Pusat SAP. Dengan konfigurasi seperti itu, Anda perlu memastikan Anda tidak memiliki variasi run time yang ekstrem, tergantung pada apakah pekerjaan berjalan di zona dengan instans database aktif atau tidak, dalam transaksi bisnis dan pekerjaan batch.

Tata letak dasar arsitektur terlihat seperti ini:

Penyebaran zona Aktif/Pasif

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.
  • Saat Anda menggunakan arsitektur ini, Anda perlu memantau status dengan cermat dan mencoba menyimpan instans database aktif dan instans Layanan Pusat SAP di zona yang sama dengan lapisan aplikasi yang Anda sebarkan. Jika ada failover SAP Central Service atau instans database, Anda ingin memastikan bahwa Anda dapat melakukan failback secara manual ke zona dengan lapisan aplikasi SAP yang disebarkan secepat mungkin.
  • Untuk load balancer kluster failover SAP Central Services dan lapisan database, Anda perlu menggunakan Standard SKU Azure Load Balancer. Load Balancer Dasar tidak berfungsi di seluruh zona.
  • Anda perlu menyebarkan versi zona alamat ExpressRoute Gateway, VPN Gateway, dan IP Publik Standar untuk mendapatkan perlindungan zonal yang Anda inginkan.
  • 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.
  • Azure Premium SSD v2, penyimpanan Ultra SSD, atau Azure NetApp Files tidak mendukung replikasi penyimpanan sinkron di seluruh zona. Untuk penyebaran database, kami mengandalkan metode database untuk mereplikasi data di seluruh zona.
  • SSD premium v1 yang mendukung replikasi zona sinkron di seluruh Zona Ketersediaan belum diuji dengan beban kerja database SAP. Oleh karena itu, replikasi sinkron zonal yang dapat dikonfigurasi dari Azure Premium SSD v1 perlu dianggap tidak didukung untuk beban kerja database SAP.
  • 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 database) 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 konfigurasi HA dan DR gabungan (DR jarak pendek) yang menjanjikan tujuan titik pemulihan (RPO) nol. RPO nol berarti Anda tidak boleh kehilangan transaksi database yang diterapkan bahkan dalam kasus pemulihan bencana.

Catatan

Jika Anda menggunakan Zona Ketersediaan sebagai solusi DR jarak kecil, perlu diingat bahwa kami mengalami bencana alam yang menyebabkan kerusakan luas di wilayah yang berbeda di dunia, termasuk kerusakan berat dan luas pada infrastruktur listrik. Jarak antara berbagai zona mungkin tidak selalu cukup besar untuk mengimbangi bencana alam yang lebih besar tersebut.

Berikut adalah salah satu contoh bagaimana konfigurasi tersebut mungkin terlihat:

Gabungan DR ketersediaan tinggi di zona

Pertimbangan berikut berlaku untuk konfigurasi ini:

  • Anda juga berasumsi bahwa ada jarak yang signifikan antara fasilitas yang menghosting Zona Ketersediaan. Atau Anda dipaksa untuk tetap berada dalam 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 database aktif dan instans Layanan Pusat SAP di zona yang sama dengan lapisan aplikasi yang Anda sebarkan. Jika ada failover SAP Central Service atau instans database, 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 load balancer kluster failover SAP Central Services dan lapisan database, Anda perlu menggunakan Standard SKU Azure Load Balancer. Load Balancer Dasar tidak berfungsi di seluruh zona.
  • Anda perlu menyebarkan versi zona alamat ExpressRoute Gateway, VPN Gateway, dan IP Publik Standar untuk mendapatkan perlindungan zonal yang Anda inginkan.
  • 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.
  • Azure Premium SSD v2, penyimpanan Ultra SSD, atau Azure NetApp Files tidak mendukung replikasi penyimpanan sinkron di seluruh zona. Untuk penyebaran database, kami mengandalkan metode database untuk mereplikasi data di seluruh zona.
  • SSD premium v1 yang mendukung replikasi zona sinkron di seluruh Zona Ketersediaan belum diuji dengan beban kerja database SAP. Oleh karena itu, replikasi sinkron zonal yang dapat dikonfigurasi dari Azure Premium SSD v1 perlu dianggap tidak didukung untuk beban kerja database SAP.
  • 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: