Panduan pemulihan bencana untuk aplikasi SAP
Untuk mengonfigurasi Pemulihan Bencana (DR) untuk beban kerja SAP di Azure, Anda perlu menguji, menyempurnakan, dan memperbarui proses secara teratur. Menguji pemulihan bencana membantu dalam mengidentifikasi urutan layanan dependen yang diperlukan sebelum Anda dapat memicu failover DR beban kerja SAP atau memulai sistem di situs sekunder. Organisasi biasanya memiliki sistem SAP mereka yang terhubung ke layanan Active Directory (AD) dan Domain Name System (DNS) agar berfungsi dengan benar. Saat Anda menyiapkan DR untuk beban kerja SAP Anda, pastikan layanan AD dan DNS berfungsi sebelum Anda memulihkan SAP dan sistem non-SAP lainnya, untuk memastikan aplikasi berfungsi dengan benar. Untuk panduan tentang melindungi Active Directory dan DNS, pelajaricara melindungi Active Directory dan DNS. Rekomendasi DR untuk aplikasi SAP yang dijelaskan dalam dokumen ini berada pada tingkat abstrak. Anda perlu merancang strategi DR Berdasarkan penyiapan spesifik Anda dan mendokumen skenario end-to-end.
Rekomendasi DR untuk beban kerja SAP
Biasanya dalam sistem SAP NetWeaver terdistribusi; layanan pusat, database, dan penyimpanan bersama (NFS/SMB) adalah titik kegagalan tunggal (SPOF). Untuk mengurangi efek SPOF yang berbeda, perlu untuk menyiapkan redundansi komponen ini. Redundansi komponen SPOF ini di wilayah utama dicapai dengan mengonfigurasi ketersediaan tinggi. Pengaturan ketersediaan tinggi komponen melindungi sistem SAP dari kegagalan lokal atau bencana. Tetapi untuk melindungi aplikasi SAP dari bencana yang tersebar secara geografis, strategi DR harus diterapkan untuk semua komponen SAP.
Untuk sistem SAP yang berjalan di komputer virtual, Anda dapat menggunakan Azure Site Recovery untuk membuat rencana pemulihan bencana. Berikut ini adalah pendekatan pemulihan bencana yang direkomendasikan untuk setiap komponen sistem SAP. Mesin SAP non-NetWeaver mandiri seperti aplikasi TREX dan non-SAP tidak tercakup dalam dokumen ini.
Komponen | Rekomendasi |
---|---|
SAP Web Dispatcher | Mereplikasi VM menggunakan Azure Site Recovery |
Layanan Pusat SAP | Mereplikasi VM menggunakan Azure Site Recovery |
Server Aplikasi SAP | Mereplikasi VM menggunakan Azure Site Recovery |
SAP Database | Menggunakan metode replikasi yang ditawarkan oleh database |
Penyimpanan Bersama | Mereplikasi konten, menggunakan metode yang sesuai per jenis penyimpanan |
SAP Web Dispatcher
Komponen SAP Web Dispatcher berfungsi sebagai load balancer untuk lalu lintas SAP di antara server aplikasi SAP. Anda memiliki opsi yang berbeda untuk mencapai ketersediaan tinggi komponen SAP Web Dispatcher di wilayah utama. Untuk informasi selengkapnya tentang opsi ini, lihat Ketersediaan Tinggi SAP Web Dispatcher dan penyiapan SAP Web dispatcher HA di Azure.
- Opsi 1: Ketersediaan tinggi menggunakan solusi kluster.
- Opsi 2: Ketersediaan tinggi dengan SAP Web Dispatcher paralel.
Untuk mencapai DR untuk penyiapan SAP Web Dispatcher yang sangat tersedia di wilayah utama, Anda dapat menggunakan Azure Site Recovery. Untuk dispatcher web paralel (opsi 2) yang berjalan di wilayah utama, Anda dapat mengonfigurasi Azure Site Recovery untuk mencapai DR. Tetapi untuk SAP Web Dispatcher yang dikonfigurasi menggunakan opsi 1 di wilayah utama, Anda perlu membuat beberapa perubahan tambahan setelah failover memiliki penyiapan HA serupa di wilayah DR. Karena konfigurasi ketersediaan tinggi SAP Web Dispatcher dengan solusi kluster dikonfigurasi dengan cara yang sama dengan layanan pusat SAP. Ikuti panduan yang sama seperti yang disebutkan untuk Layanan Pusat SAP.
Layanan Pusat SAP
Layanan pusat SAP berisi antrean dan server pesan, yang merupakan salah satu SPOF dari aplikasi SAP Anda. Dalam sistem SAP, hanya ada satu instans tersebut, dan dapat dikonfigurasi untuk ketersediaan tinggi. Baca Ketersediaan Tinggi untuk Layanan Pusat SAP untuk memahami berbagai solusi ketersediaan tinggi untuk beban kerja SAP di Azure.
Mengonfigurasi ketersediaan tinggi untuk Layanan Pusat SAP melindungi sumber daya dan proses dari insiden lokal. Untuk mencapai DR untuk Layanan Pusat SAP, Anda dapat menggunakan Azure Site Recovery. Azure Site Recovery mereplikasi VM dan disk terkelola yang terlampir, tetapi ada pertimbangan tambahan untuk strategi DR. Periksa bagian berikut untuk informasi selengkapnya, berdasarkan sistem operasi yang digunakan untuk layanan pusat SAP.
Untuk sistem SAP, redundansi komponen SPOF di wilayah utama dicapai dengan mengonfigurasi ketersediaan tinggi. Untuk mencapai penyiapan ketersediaan tinggi serupa di wilayah pemulihan bencana setelah failover, Anda perlu mempertimbangkan poin tambahan. Ini termasuk mengonfigurasi ulang kluster, memastikan direktori bersama SAP tersedia, dan mereplikasi VM dan disk terkelolanya ke situs DR dengan Azure Site Recovery. Di Linux, ketersediaan tinggi aplikasi SAP dapat dicapai menggunakan solusi kluster pacemaker. Diagram di bawah ini menunjukkan berbagai komponen yang terlibat dalam mengonfigurasi ketersediaan tinggi untuk layanan pusat SAP dengan Pacemaker. Setiap komponen harus dipertimbangkan agar ketersediaan tinggi serupa disiapkan di situs DR. Jika Anda telah mengonfigurasi SAP Web Dispatcher menggunakan solusi kluster pacemaker, pertimbangan serupa juga akan berlaku.
Load Balancer internal
Azure Site Recovery mereplikasi VM ke situs DR, tetapi tidak mereplikasi load balancer Azure. Anda harus membuat load balancer internal terpisah di situs DR sebelum atau setelah failover. Jika Anda membuat load balancer internal sebelumnya, buat kumpulan backend kosong dan tambahkan VM setelah peristiwa failover.
Solusi kluster Pacemaker
Konfigurasi kluster pacemaker berada di file lokal VM, yang direplikasi ke situs DR dengan Azure Site Recovery. Konfigurasi kluster pacemaker apa adanya tidak akan berfungsi di luar kotak pada VM setelah failover. Konfigurasi ulang kluster tambahan diperlukan untuk membuat solusi berfungsi.
Baca blog ini untuk mempelajari tentang konfigurasi ulang kluster pacu jantung di wilayah DR, berdasarkan jenis mekanisme penyimpanan dan anggar Anda.
- Kluster SAP ASCS/ERS HA dengan failover perangkat SBD (menggunakan server target iSCSI) ke wilayah DR menggunakan Azure Site Recovery.
- Failover Kluster SAP ASCS HA (di OS Linux) ke wilayah DR menggunakan Azure Site Recovery.
Direktori bersama SAP untuk Linux
Pengaturan ketersediaan tinggi platform SAP NetWeaver atau ABAP menggunakan server replikasi antrean untuk mencapai redundansi tingkat aplikasi untuk layanan antrean sistem SAP dengan konfigurasi kluster Pacemaker. Pengaturan ketersediaan tinggi layanan pusat SAP (ASCS dan ERS) menggunakan pemasangan NFS. Jadi Anda perlu memastikan biner dan data SAP di pemasangan NFS ini direplikasi ke situs DR. Azure Site Recovery mereplikasi VM dan disk terkelola lokal yang terpasang, tetapi tidak mereplikasi pemasangan NFS. Berdasarkan jenis penyimpanan NFS yang dikonfigurasi untuk penyiapan, Anda perlu memastikan data direplikasi dan tersedia di situs DR. Metodologi replikasi lintas wilayah untuk setiap penyimpanan disajikan pada tingkat abstrak. Anda perlu mengonfirmasi langkah-langkah yang tepat untuk mereplikasi penyimpanan dan melakukan pengujian.
Direktori bersama SAP | Replikasi lintas wilayah |
---|---|
NFS pada file Azure | Kustom (seperti rsync) |
NFS di ANF | Ya (Replikasi Lintas Wilayah) |
Kluster NFS | Adat |
Tip
Sebaiknya sebarkan salah satu layanan NFS pihak pertama Azure: NFS pada volume Azure Files atau NFS ANF untuk menyimpan data bersama dalam sistem SAP yang sangat tersedia. Ketahuilah, bahwa kami membatalkan penekanan arsitektur referensi SAP, menggunakan kluster NFS.
Mekanisme Anggar
Terlepas dari sistem operasi (SLES atau RHEL) dan versinya, pacemaker memerlukan mekanisme pagar yang valid agar seluruh solusi berfungsi dengan baik. Berdasarkan jenis mekanisme anggar yang telah Anda siapkan di wilayah utama Anda, Anda perlu memastikan mekanisme pagar yang sama disiapkan di situs DR setelah failover.
Mekanisme Anggar | Rekomendasi DR lintas wilayah |
---|---|
SBD menggunakan server target iSCSI | Replikasi server target iSCSI menggunakan Azure Site Recovery. Pada VM DR, temukan disk iSCSI lagi. |
Agen pagar Azure | Aktifkan Identitas Sistem Terkelola (MSI) pada VM DR. Menetapkan peran kustom. Perbarui sumber daya agen pagar dalam kluster. |
SBD menggunakan disk bersama Azure* | Konfigurasikan Disk Bersama Azure baru di wilayah DR. Lampirkan Disk Bersama Azure ke VM DR setelah failover. Siapkan perangkat SBD disk bersama Azure. |
*ZRS untuk disk bersama Azure tersedia di wilayah terbatas.
Catatan
Kami menyarankan untuk memiliki mekanisme anggar yang sama untuk wilayah primer dan DR untuk kemudahan operasi dan failover. Tidak disarankan untuk memiliki mekanisme anggar yang berbeda setelah failover ke situs DR.
Server Aplikasi SAP
Di wilayah utama, redundansi server aplikasi SAP dicapai dengan menginstal instans di beberapa VM. Untuk memiliki DR untuk server aplikasi SAP, Azure Site Recovery dapat disiapkan untuk setiap VM server aplikasi. Untuk penyimpanan bersama (sistem file transportasi, sistem file data antarmuka) yang dilampirkan ke server aplikasi, ikuti praktik DR yang sesuai berdasarkan jenis penyimpanan bersama.
Server Database SAP
Untuk database yang menjalankan beban kerja SAP, gunakan teknologi replikasi DBMS asli untuk mengonfigurasi DR. Penggunaan Azure Site Recovery untuk database tidak disarankan, karena tidak menjamin konsistensi DB dan memiliki batasan churn data. Teknologi replikasi untuk setiap database berbeda, jadi ikuti panduan database masing-masing. Tabel berikut ini memperlihatkan daftar database yang digunakan untuk beban kerja SAP dan rekomendasi DR yang sesuai.
Database | Rekomendasi DR |
---|---|
SAP HANA | Replikasi Sistem HANA (HSR) |
Oracle | Oracle Data Guard (FarSync) |
IBM DB2 | Pemulihan bencana ketersediaan tinggi (HADR) |
Microsoft SQL | Microsoft SQL Always On |
SAP ASE | ASE HADR Selalu Aktif |
SAP MaxDB | Database Siaga |
Untuk solusi yang dioptimalkan biaya, Anda bahkan dapat menggunakan opsi pencadangan dan pemulihan untuk strategi DR database.
Mencadangkan dan memulihkan
Pencadangan dan pemulihan adalah solusi lain yang dapat Anda gunakan untuk mencapai pemulihan bencana untuk beban kerja SAP Anda jika RTO dan RPO bisnis bersifat noncritical. Anda dapat menggunakan pencadangan Azure, layanan pencadangan berbasis cloud untuk mengambil salinan berbagai komponen beban kerja SAP Anda seperti komputer virtual, disk terkelola, dan database yang didukung. Untuk mempelajari selengkapnya tentang pengaturan dan batasan dukungan umum untuk skenario dan penyebaran Azure Backup, lihat matriks dukungan Azure Backup.
Layanan | Komponen | Dukungan Azure Backup |
---|---|---|
Compute | Azure VM | Didukung |
Penyimpanan | Disk Terkelola Azure termasuk disk bersama | Didukung |
Penyimpanan | Berbagi File Azure - SMB (Standar atau Premium) | Didukung |
Penyimpanan | Azure blob | Didukung |
Penyimpanan | Berbagi File Azure - NFS (Standar atau Premium) | Tidak Didukung |
Penyimpanan | File Azure NetApp | Tidak Didukung |
Database | Database SAP Hana di Azure VM | Didukung |
Database | Server SQL di Azure VM | Didukung |
Database | Oracle | Didukung* |
Database | IBM DB2, SAP ASE | Tidak Didukung |
Catatan
*Azure backup mendukung database Oracle menggunakan cadangan Azure VM untuk rekam jepret yang konsisten dengan database.
Pencadangan Azure tidak mendukung semua penyimpanan dan database Azure yang digunakan untuk beban kerja SAP.
Azure Backup menyimpan cadangan dalam vault layanan pemulihan, yang mereplikasi data Anda berdasarkan jenis replikasi yang dipilih (LRS, ZRS, atau GRS). Untuk penyimpanan Geo-redundan (GRS), data cadangan Anda direplikasi ke wilayah sekunder yang dipasangkan. Dengan fitur pemulihan lintas wilayah diaktifkan, Anda dapat memulihkan data jenis manajemen yang didukung di wilayah sekunder.
Pencadangan dan pemulihan adalah pendekatan yang dioptimalkan biaya yang lebih tradisional tetapi dilengkapi dengan trade-off RTO yang lebih tinggi. Karena Anda perlu memulihkan semua aplikasi dari cadangan jika ada failover ke wilayah DR. Jadi Anda perlu menganalisis kebutuhan bisnis Anda dan mendesain strategi DR yang sesuai.
Referensi
- Menyiapkan pemulihan bencana untuk Azure VM
- Layanan Azure Backup.