Kelangsungan bisnis dan pemulihan bencana untuk migrasi SAP
Artikel ini dibangun berdasarkan pertimbangan dan rekomendasi di area desain zona pendaratan Azure untuk BCDR. Artikel itu menjelaskan batasan unik pada zona pendaratan yang mendukung platform SAP. SAP adalah platform misi penting, jadi Anda juga harus menggabungkan panduan misi penting lainnya ke dalam desain Anda.
Skenario dan cakupan
Masukkan prinsip-prinsip ke dalam arsitektur Anda yang membahas skenario kelangsungan bisnis dan pemulihan bencana (BCDR) lokal. Prinsip-prinsip ini juga berlaku di Azure. Tetapi Azure mungkin memiliki lebih banyak kapasitas perangkat keras daripada lingkungan lokal Anda untuk mengimbangi kegagalan host. Untuk memulihkan secara otomatis bahkan komputer virtual (VM) Azure terbesar, Anda dapat mengonfigurasinya untuk memulai ulang di server lain. Siapkan penyebaran Azure Anda untuk menggunakan kondisi yang sama dengan penyebaran lokal Anda. Jika Anda menggunakan konfigurasi kluster failover otomatis untuk menyebarkan sistem lokal atau perangkat keras bare-metal, sebarkan dengan cara yang sama di Azure. Aplikasi SAP yang menjalankan proses bisnis organisasi Anda yang paling penting memerlukan:
Ketersediaan layanan dan proses bisnis.
Tujuan waktu pemulihan (RTO) untuk skenario kegagalan atau skenario bencana.
Tujuan titik pemulihan (RPO) untuk skenario kegagalan.
Tugas manajemen operasional dan siklus hidup, dan teknologi yang berjalan selama skenario kegagalan. Tugas manajemen ini termasuk menambal sistem operasi tamu dan sistem manajemen {i>database
Tip
Tentukan solusi ketersediaan tinggi dan pemulihan bencana (HADR) untuk setiap arketipe di lanskap SAP Anda sejak dini. Pastikan bahwa solusi mencakup semua komponen SAP.
Konfigurasikan solusi HADR di Azure lebih awal, dalam setidaknya satu lanskap, dan tetap aktifkan. Kemudian tim Anda bisa mendapatkan pengalaman dengan teknologi solusi, yang mungkin berbeda dari teknologi yang ada. Konfigurasikan HADR lebih awal untuk membantu mengembangkan dan mengembangkan prosedur operasi standar (SOP) Anda.
Rencanakan untuk memiliki ketersediaan tinggi lengkap, pemulihan bencana, dan perlindungan cadangan untuk beban kerja produksi segera setelah sistem ditayangkan.
Artikel ini mencakup aspek BCDR berikut untuk skenario SAP skala perusahaan:
Ketersediaan tinggi dalam wilayah Azure
Pertimbangan pencadangan dan pemulihan
Kriteria untuk memutuskan antara pemulihan bencana lintas wilayah dan regional
Ketersediaan tinggi dalam wilayah Azure
Bagian berikut memberikan pertimbangan desain dan rekomendasi untuk ketersediaan tinggi dalam wilayah Azure untuk skenario perusahaan SAP.
Pertimbangan desain untuk ketersediaan tinggi
Ketika Anda menerapkan ketersediaan tinggi, tujuannya adalah untuk menyediakan ketersediaan untuk titik kegagalan tunggal perangkat lunak SAP, seperti:
Sistem manajemen database.
Titik kegagalan tunggal dalam aplikasi, seperti SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS), dan SAP Central Services (SCS). Contoh ketersediaan tinggi termasuk SAP NetWeaver dan arsitektur SAP S/4HANA.
Alat lain, seperti SAP Web Dispatcher.
Untuk skenario lain, jangan batasi ketersediaan untuk kegagalan infrastruktur atau kegagalan perangkat lunak. Terapkan ketersediaan ke semua tugas manajemen siklus hidup yang diperlukan. Misalnya, Anda dapat menambal OS di VM, sistem manajemen database (DBMS), dan perangkat lunak SAP. Untuk meminimalkan pemadaman yang mungkin terjadi selama operasi downtime dan manajemen siklus hidup yang direncanakan, gunakan alat umum yang membantu melindungi sistem Anda dari gangguan layanan yang tidak direncanakan.
{i>Database
Untuk informasi selengkapnya, lihat Skenario yang didukung untuk beban kerja SAP pada Azure VM dan Skenario yang didukung untuk Instans Besar SAP Hana.
Untuk lapisan DBMS, pola arsitektur umum adalah mereplikasi database secara bersamaan dan dengan tumpukan penyimpanan yang berbeda dari yang digunakan VM utama dan VM sekunder. Azure tidak mendukung arsitektur tempat VM utama dan VM sekunder berbagi penyimpanan untuk data DBMS. Azure juga tidak mendukung log transaksi atau mengulangi log. Prinsip panduannya adalah menggunakan dua tumpukan penyimpanan independen, bahkan jika didasarkan pada berbagi Network File System (NFS). Batasan ini eksklusif untuk solusi Azure dan bukan solusi lokal.
Azure menyediakan opsi lain karena mendukung berbagi NFS dan Blok Pesan Server. Anda dapat menggunakan disk bersama Azure di Windows untuk komponen ASCS dan SCS dan skenario ketersediaan tinggi tertentu. Siapkan kluster failover Anda secara terpisah untuk komponen lapisan aplikasi SAP dan lapisan DBMS. Azure tidak mendukung arsitektur ketersediaan tinggi yang menggabungkan komponen lapisan aplikasi SAP dan lapisan DBMS menjadi satu kluster failover.
Sebagian besar kluster failover untuk komponen lapisan aplikasi SAP dan lapisan DBMS memerlukan alamat IP virtual untuk kluster failover. Pengecualian umum adalah ketika Anda menggunakan Oracle Data Guard, yang tidak memerlukan alamat IP virtual. Azure Load Balancer harus menangani alamat IP virtual untuk semua kasus lainnya. Anda dapat menggunakan satu load balancer untuk setiap konfigurasi kluster. Kami menyarankan agar Anda menggunakan versi standar load balancer. Untuk informasi selengkapnya, lihat Konektivitas titik akhir publik untuk VM dengan menggunakan Azure Load Balancer Standar dalam skenario ketersediaan tinggi SAP.
Untuk informasi selengkapnya, lihat arsitektur dan skenario ketersediaan tinggi untuk SAP NetWeaver.
Tabel berikut menunjukkan perjanjian tingkat layanan (SLA) tingkat platform untuk berbagai opsi penyebaran ketersediaan tinggi. Mitra yang menyediakan layanan terkelola juga menyediakan SLA tingkat aplikasi.
| Tingkat | Skenario ketersediaan tinggi | Platform SLA |
|---|---|---|
| 1 | Zona ketersediaan | 99,99% |
| 2 | Rangkaian ketersediaan | 99,95% |
| 3 | VM tunggal (penyembuhan diri) | 99,90% |
Set ketersediaan Azure vs. zona ketersediaan
Sebelum Anda menyebarkan infrastruktur ketersediaan tinggi, tentukan apakah akan menyebarkan dengan set ketersediaan Azure atau zona ketersediaan tergantung pada wilayah yang Anda pilih. Perbedaan utama untuk VM yang Anda sebarkan dengan set ketersediaan adalah:
VM tidak tersebar di berbagai zona ketersediaan.
Jenis VM yang dapat Anda sebarkan melalui satu set ketersediaan dibatasi karena VM pertama yang Anda sebarkan di set menentukan host. Misalnya, Anda tidak dapat menggabungkan VM seri M dan VM seri-E ke dalam satu set ketersediaan.
Saat Anda menyebarkan arsitektur ketersediaan tinggi di berbagai zona ketersediaan, Anda dapat memiliki SLA yang lebih tinggi untuk VM. Untuk informasi selengkapnya, lihat Azure VM SLA. Bergantung pada wilayah Azure, Anda mungkin menemukan berbagai kondisi latensi jaringan di lalu lintas jaringan antar beberapa VM. Untuk informasi selengkapnya, lihat Konfigurasi beban kerja SAP dengan zona ketersediaan Azure.
Jika Anda memilih pendekatan penyebaran zona, pertimbangkan bagaimana latensi lintas zona untuk wilayah Azure yang dipilih dapat memengaruhi pilihan desain performa dan arsitektur. Pertimbangkan latensi antara server aplikasi dan database dan antara dua simpul database.
Jika Anda menggunakan penyebaran zonal aktif/pasif untuk tingkat server aplikasi tempat server aplikasi harus terhubung ke database di zona ketersediaan yang sama, konfigurasikan otomatisasi dan buat SOP untuk mengaktifkan pemulihan cepat dan otomatis jika kegagalan database terjadi.
Jika Anda menggunakan zona ketersediaan dalam solusi SAP Anda, desain semua layanan Azure dan komponen infrastruktur lainnya di lanskap SAP Anda untuk redundansi zona juga sehingga Anda dapat mencapai redundansi zona yang sebenarnya. Contoh layanan dan komponen yang perlu diperhitungkan termasuk gateway Azure ExpressRoute, Load Balancer, Azure Files, Azure NetApp Files, proksi terbalik, firewall, layanan antivirus, dan infrastruktur cadangan.
Rekomendasi desain untuk ketersediaan tinggi
Azure menyediakan beberapa opsi untuk membantu Anda memenuhi SLA infrastruktur aplikasi Anda. Anda harus memilih opsi yang sama untuk ketiga komponen SAP: layanan pusat, server aplikasi, dan database. Untuk informasi selengkapnya tentang SLA untuk VM, set ketersediaan, dan zona ketersediaan, lihat SLA untuk layanan online.
Saat Anda menyebarkan VM dalam set ketersediaan, penyelarasan dengan domain kesalahan dan pembaruan mencegah VM berada di perangkat keras host yang sama, yang memberikan perlindungan terhadap kegagalan perangkat keras. Saat Anda menyebarkan VM melalui zona ketersediaan dan menggunakan zona yang berbeda, Anda membuat VM di berbagai lokasi fisik. Konfigurasi ini memberikan perlindungan ekstra terhadap masalah daya, pendinginan, atau jaringan yang memengaruhi pusat data zona secara keseluruhan. Tetapi Anda tidak dapat menyebarkan set ketersediaan Azure dalam zona ketersediaan Azure kecuali Anda menggunakan grup penempatan kedekatan.
Jika Anda memilih pendekatan penyebaran zona, SAP DBMS, layanan pusat, dan lapisan aplikasi berjalan di zona ketersediaan yang berbeda. Tetapi setiap zona ketersediaan kemungkinan besar memiliki beberapa server aplikasi. Dalam skenario ini, server aplikasi di setiap zona tidak secara otomatis mendapat manfaat dari domain kesalahan dan domain pembaruan. Anda dapat menggunakan set ketersediaan untuk mendapatkan manfaat tersebut. Untuk informasi selengkapnya, lihat Grup penempatan kedekatan Azure untuk latensi jaringan yang optimal dengan SAP.
Saat Anda membuat set ketersediaan, gunakan jumlah maksimum domain kesalahan dan perbarui domain yang tersedia. Misalnya, jika Anda menyebarkan lebih dari dua VM dalam satu set ketersediaan, gunakan jumlah maksimum domain kesalahan (tiga). Dan gunakan domain pembaruan yang cukup untuk membatasi efek potensi kegagalan perangkat keras fisik, pemadaman jaringan, atau gangguan daya, selain pemeliharaan terencana Azure. Jumlah default domain kesalahan adalah dua, dan Anda tidak dapat mengubahnya secara online nanti.
Dalam penyebaran set ketersediaan, setiap komponen sistem SAP harus berada dalam set ketersediaannya sendiri. Layanan pusat SAP, database, dan VM aplikasi harus berada dalam set ketersediaan mereka sendiri.
Saat Anda menggunakan grup penempatan kedekatan Azure dalam penyebaran set ketersediaan, pastikan bahwa ketiga komponen SAP (layanan pusat, server aplikasi, dan database) berada dalam grup penempatan kedekatan yang sama.
Jika Anda menggunakan grup penempatan kedekatan, gunakan satu untuk setiap SAP System Identification (SID). Grup tidak mencakup seluruh zona ketersediaan atau wilayah Azure.
Saat Anda menggunakan grup penempatan kedekatan Azure dalam penyebaran zona ketersediaan, pastikan bahwa dua komponen SAP (layanan pusat dan server aplikasi) berada dalam grup penempatan kedekatan yang sama. VM database di dua zona tidak lagi menjadi bagian dari grup penempatan kedekatan. Grup penempatan kedekatan untuk setiap zona dilingkup dengan penyebaran VM yang menjalankan instans SAP ASCS dan SCS. Keuntungan dari konfigurasi ini adalah Anda memiliki lebih banyak fleksibilitas untuk mengubah ukuran VM. Anda juga dapat dengan mudah beralih ke jenis VM baru baik di lapisan DBMS atau lapisan aplikasi sistem SAP.
Azure tidak mendukung penggadangan ASCS dan ketersediaan tinggi database dalam satu kluster Linux Pacemaker. Pisahkan ke dalam kluster individual. Anda dapat menggabungkan sebanyak lima kluster layanan pusat dalam sepasang VM.
Gunakan Load Balancer Standar di depan ASCS dan kluster database.
Jalankan semua sistem produksi di Azure Premium SSD, dan gunakan Azure NetApp Files atau Azure Ultra Disk Storage. Minimal, pastikan disk OS berada di tingkat Premium sehingga Anda dapat meningkatkan performa dan mendapatkan SLA terbaik.
Sebarkan kedua VM dalam pasangan ketersediaan tinggi dalam set ketersediaan atau di zona ketersediaan. Pastikan VM ini berukuran sama dan memiliki konfigurasi penyimpanan yang sama.
Gunakan teknologi replikasi database asli untuk menyinkronkan database dalam pasangan ketersediaan tinggi.
Gunakan salah satu layanan berikut untuk menjalankan kluster layanan pusat SAP, tergantung pada OS:
Siapkan parameter batas waktu kluster seperti yang direkomendasikan dalam dokumentasi untuk layanan pusat dan kluster database.
Penyimpanan untuk beban kerja SAP
Pilih opsi penyimpanan yang tepat saat Anda merancang ketahanan dalam beban kerja SAP Anda. Desain penyimpanan Azure yang tepat untuk beban kerja SAP dapat meminimalkan latensi dan memaksimalkan throughput. Pertimbangkan implementasi Anda dan bagaimana panduan berikut dapat membantu Anda membuat keputusan arsitektur untuk implementasi SAP di Azure Anda. Untuk informasi selengkapnya, lihat Jenis penyimpanan Azure untuk beban kerja SAP.
Anda harus menjalankan SAP Hana di Azure hanya pada jenis penyimpanan bersertifikat SAP. Anda harus menjalankan volume tertentu pada konfigurasi disk tertentu. Misalnya, konfigurasi mungkin mengaktifkan Write Accelerator atau menggunakan penyimpanan SSD Premium. Anda juga perlu memastikan bahwa sistem file yang berjalan pada penyimpanan kompatibel dengan DBMS yang berjalan pada komputer. Untuk informasi selengkapnya, lihat Konfigurasi penyimpanan untuk SAP Hana.
Selain disk data terkelola Azure yang dilampirkan ke VM, berbagai solusi penyimpanan bersama asli Azure menjalankan aplikasi SAP di Azure. Konfigurasi ketersediaan tinggi Anda mungkin berbeda karena Azure Site Recovery tidak mendukung beberapa layanan penyimpanan yang tersedia di Azure. Gunakan jenis penyimpanan berikut untuk beban kerja SAP.
Jenis penyimpanan Dukungan konfigurasi ketersediaan tinggi Disk bersama Azure (penyimpanan redundan lokal (LRS) atau penyimpanan redundan zona (ZRS)) Kluster failover Windows Server 2022. Untuk detail konfigurasi, lihat Mendesain ketersediaan tinggi SAP dengan pengklusteran failover Windows Server 2022. NFS di Azure Files (LRS atau ZRS) Kluster berbasis Pacemaker pada lingkungan Linux. Pastikan untuk memeriksa ketersediaan NFS di berbagai wilayah. NFS di Azure NetApp Files Kluster berbasis Pacemaker pada lingkungan Linux. Untuk informasi selengkapnya, lihat Azure NetApp Files untuk VM SAP. SMB di Azure Files (LRS atau ZRS) Kluster failover Windows Server 2022. Untuk detail konfigurasi, lihat Menginstal SAP NetWeaver ketersediaan tinggi dengan Azure Files SMB. SMB di Azure NetApp Files Kluster failover Windows Server 2022. Untuk detail konfigurasi, lihat Ketersediaan tinggi untuk SAP NetWeaver dengan Azure NetApp Files (SMB) untuk aplikasi SAP. Alih-alih layanan penyimpanan bersama asli Azure, Anda dapat menggunakan kluster NFS tradisional (berdasarkan replikasi Perangkat Blok Terdistribusi Yang Direplikasi), GlusterFS, atau volume bersama kluster dengan Storage Spaces Direct sebagai solusi penyimpanan bersama alternatif untuk menjalankan beban kerja SAP di Azure. Pilihan ini sangat berguna ketika layanan penyimpanan bersama asli Azure tidak tersedia di wilayah Azure yang ditargetkan atau tidak mendukung arsitektur target. Untuk informasi selengkapnya tentang ketersediaan layanan penyimpanan, lihat Produk Azure menurut wilayah.
Untuk informasi tentang opsi penyimpanan yang tersedia untuk beban kerja SAP di Azure, lihat Rekomendasi dan panduan penyimpanan untuk menyiapkan pemulihan bencana.
Pencadangan dan pemulihan
Bagian berikut menjelaskan pertimbangan desain dan rekomendasi untuk pencadangan dan pemulihan dalam skenario SAP.
Meskipun pencadangan dan pemulihan biasanya tidak dianggap sebagai solusi ketersediaan tinggi yang memadai untuk beban kerja SAP produksi, teknologi ini memberikan manfaat lain. Sebagian besar perusahaan yang menggunakan aplikasi SAP perlu mengikuti peraturan kepatuhan yang memerlukan penyimpanan cadangan jangka panjang. Dalam skenario lain, Anda juga harus memiliki cadangan yang dapat Anda pulihkan. Panduan ini mengasumsikan bahwa Anda sudah membuat pencadangan dan pemulihan serta mengikuti praktik terbaik untuk aplikasi SAP, yang berarti Anda dapat:
Lakukan pemulihan point-in-time untuk database produksi Anda kapan saja, dalam jangka waktu yang memenuhi RTO Anda. Pemulihan titik waktu biasanya memberikan perlindungan dari kesalahan operator seperti menghapus data, baik pada lapisan DBMS atau melalui SAP.
Pertahankan penyimpanan untuk menyimpan cadangan jangka panjang Anda untuk memenuhi peraturan kepatuhan.
Gunakan cadangan database untuk mengkloning sistem SAP dan memulihkan cadangan terhadap server atau VM lain.
Gunakan data {i>database
Cadangkan server aplikasi SAP dan VM, disk, atau rekam jepret VM.
Cadangkan sistem SAP Hana dengan replikasi diaktifkan.
Cadangkan rekam jepret instans database SAP Hana.
Jika Anda mencadangkan dan memulihkan lokal, Anda perlu membawa kemampuan ini ke sistem SAP di Azure. Jika Anda menyukai solusi Anda saat ini, periksa apakah vendor cadangan Anda mendukung penyebaran Azure atau apakah ia memiliki solusi perangkat lunak sebagai layanan (SaaS) untuk Azure.
Azure menyediakan layanan SaaS cadangan yang disebut Azure Backup, yang mengambil rekam jepret VM dan mengelola streaming cadangan SQL Server dan SAP Hana . Jika Anda menggunakan Azure NetApp Files untuk menyimpan database SAP Hana, Anda dapat menjalankan pencadangan berdasarkan rekam jepret penyimpanan yang konsisten dengan HANA.
Anda juga dapat menggunakan Azure Backup untuk mencadangkan database yang mengaktifkan replikasi sistem SAP Hana (HSR). Azure Backup secara otomatis mengelola cadangan saat failover terjadi dan menghilangkan kebutuhan akan intervensi manual. Pencadangan juga menyediakan:
Perlindungan langsung tanpa pencadangan penuh perbaikan, sehingga Anda dapat melindungi instans HANA atau node penyiapan HSR sebagai kontainer HSR tunggal.
Manfaat pencadangan instan dan pemulihan instan.
Pendekatan berbasis rekam jepret yang konsisten dengan HANA yang terintegrasi dengan Backint untuk SAP Hana. Anda dapat menggunakan Backup sebagai produk tunggal untuk seluruh lanskap HANA Anda dan untuk ukuran database apa pun.
Untuk informasi selengkapnya, lihat sistem database SAP Hana dengan replikasi diaktifkan dan cadangan rekam jepret instans SAP Hana.
Rekomendasi desain untuk pencadangan dan pemulihan
Anda dapat menggunakan Azure Backup untuk mencadangkan server aplikasi SAP dan VM layanan pusat.
Anda dapat menggunakan cadangan SAP Hana untuk penyebaran HANA yang hingga 8 TB. Untuk informasi selengkapnya, lihat Matriks dukungan untuk pencadangan database SAP Hana di Azure VM.
Jika Anda menggunakan infrastruktur sebagai solusi pencadangan layanan, ukur infrastruktur cadangan untuk memastikan bahwa infrastruktur tersebut dapat mencadangkan semua sistem berukuran produksi secara bersamaan atau, seperti dalam skenario kehidupan nyata, dalam jangka waktu yang diharapkan. Gunakan penyiapan produksi atau penyiapan serupa untuk area seperti jaringan dan keamanan.
Uji waktu pencadangan dan pemulihan untuk memverifikasi bahwa mereka memenuhi persyaratan RTO Anda untuk memulihkan semua sistem secara bersamaan setelah bencana.
Idealnya, hindari menarik cadangan Anda dari Azure ke infrastruktur cadangan lokal Anda, terutama untuk database besar. Pendekatan ini dapat memengaruhi berapa banyak bandwidth yang digunakan sirkuit ExpressRoute.
Uji beban alat pencadangan dan pemulihan sebagai bagian dari rencana pengujian performa.
Pemulihan dari bencana
Bagian berikut menjelaskan pertimbangan desain dan rekomendasi untuk pemulihan bencana dalam skenario SAP.
Pertimbangan desain untuk pemulihan bencana
Peta wilayah Azure mencakup lebih dari 65 wilayah Azure, dan tidak semuanya menjalankan layanan yang sama. Untuk penyebaran perangkat lunak SAP yang lebih besar, terutama yang menggunakan SAP Hana, cari wilayah Azure yang menawarkan VM seri M Azure atau VM seri Mv2. Azure Storage juga memasangkan wilayah yang berbeda untuk mereplikasi subset yang lebih kecil dari jenis penyimpanan ke wilayah lain. Untuk informasi selengkapnya, lihat Gambaran umum wilayah yang dipasangkan Azure.
Tantangan utama memasangkan wilayah Azure untuk beban kerja SAP adalah:
Pasangan ini tidak selalu konsisten dengan layanan VM seri M atau Mv2. Banyak organisasi yang menyebarkan sistem SAP mereka tidak menggunakan wilayah berpasangan Azure. Sebaliknya, mereka memilih wilayah berdasarkan ketersediaan jenis VM yang diperlukan.
Anda dapat mereplikasi penyimpanan standar antar wilayah yang dipasangkan, tetapi Anda tidak dapat menggunakan penyimpanan standar untuk menyimpan database atau hard disk virtual Anda. Anda hanya dapat mereplikasi cadangan antara wilayah berpasangan yang Anda gunakan. Untuk semua data lainnya, jalankan replikasi Anda dengan menggunakan fitur DBMS asli seperti SQL Server Always On atau replikasi sistem SAP Hana. Gunakan kombinasi Site Recovery, alat seperti
rsyncataurobocopy, dan perangkat lunak non-Microsoft lainnya untuk lapisan aplikasi SAP.Jika bencana terjadi, beberapa pelanggan yang terpengaruh di wilayah Azure melakukan failover ke wilayah pemulihan bencana berpasangan yang sesuai. Situasi ini menyebabkan persaingan sumber daya untuk memunculkan VM yang tidak aktif di wilayah pemulihan bencana. Solusinya adalah menjalankan sistem nonproduksi di wilayah pemulihan bencana dan menggunakan sumber daya yang sama untuk menghosting replika pemulihan bencana sistem produksi. Penggunaan dual-purpose infrastruktur Azure di wilayah pemulihan bencana ini membantu Anda menghindari batasan kapasitas sumber daya.
Pertimbangan penting lainnya adalah mengamankan kapasitas operasi yang diperlukan di wilayah bencana. Jika bencana terjadi, Anda mungkin perlu menjalankan aplikasi SAP untuk jangka waktu minimal dengan kapasitas IT minimal dan oleh sumber daya manusia penting hanya saat Anda bekerja untuk memulihkan operasi normal di wilayah utama. Strategi ini mengharuskan Anda memiliki infrastruktur TI minimal yang tersedia di wilayah pemulihan bencana.
Setelah menentukan wilayah Azure, Anda harus memilih pola penyebaran:
Apakah Anda akan menyebarkan sistem produksi ke wilayah utama Anda?
Apakah Anda akan menyebarkan sistem SAP nonproduksi ke wilayah pemulihan bencana?
Apakah Anda akan menggunakan arsitektur yang mengelompokkan semua sistem SAP ke wilayah utama? Konfigurasi ini memastikan bahwa wilayah pemulihan bencana hanya digunakan untuk pemulihan bencana.
Sebagian besar organisasi menggunakan kedua wilayah untuk mengoperasikan sistem SAP. Organisasi yang menjalankan salinan lengkap sistem produksi sebagai sistem uji regresi bisnis biasanya berencana untuk menggunakan sistem uji regresi bisnis lini produk SAP sebagai target pemulihan bencana.
Saat Anda memilih wilayah pemulihan bencana, pastikan untuk memiliki konektivitas ExpressRoute ke wilayah tersebut. Jika Anda memiliki beberapa sirkuit ExpressRoute yang tersambung ke Azure, setidaknya salah satu sirkuit tersebut harus tersambung ke wilayah Azure utama. Yang lain harus terhubung ke wilayah pemulihan bencana. Jenis arsitektur ini menghubungkan Anda ke jaringan Azure di area geografis atau geopolitik yang berbeda dan membantu melindungi koneksi Anda jika bencana memengaruhi salah satu wilayah Azure.
Beberapa organisasi menggunakan kombinasi ketersediaan tinggi dan arsitektur pemulihan bencana, yang mengelompokkan ketersediaan tinggi dengan pemulihan bencana di wilayah Azure yang sama. Tetapi mengelompokkan ketersediaan tinggi dengan pemulihan bencana tidak ideal. Zona ketersediaan Azure mendukung arsitektur ini. Jarak antara zona ketersediaan dalam satu wilayah Azure tidak sebesar jarak antara dua wilayah Azure, sehingga bencana alam dapat membahgi layanan aplikasi di wilayah tempatnya terjadi. Anda juga perlu mempertimbangkan latensi antara server aplikasi SAP dan server database. Menurut catatan SAP 1100926, waktu pulang pergi kurang dari atau sama dengan 0,3 ms adalah nilai yang baik, dan waktu kurang dari atau sama dengan 0,7 ms adalah nilai sedang. Jadi untuk zona dengan latensi tinggi, memiliki prosedur operasional untuk memastikan bahwa server aplikasi SAP dan server database selalu berjalan di zona yang sama. Organisasi memilih arsitektur ini karena alasan berikut:
Kepatuhan cukup dengan konfigurasi yang mendukung jarak yang lebih kecil antara penyebaran produksi dan target pemulihan bencana.
Kedaulatan data adalah faktor.
Faktor geopolitik terlibat.
Ini adalah opsi bernilai rendah yang mendukung kegagalan zonal, kadang-kadang dikombinasikan dengan transfer cadangan ke wilayah sekunder untuk bencana alam yang memengaruhi radius besar.
Faktor lain yang perlu dipertimbangkan ketika Anda memilih wilayah pemulihan bencana Anda adalah RPO dan RTO untuk failover ke situs pemulihan bencana. Semakin besar jarak antara wilayah produksi dan wilayah pemulihan bencana, semakin tinggi latensi jaringan. Anda mereplikasi secara asinkron antar wilayah Azure, tetapi latensi jaringan dapat memengaruhi throughput yang dapat Anda replikasi dan target RPO. Untuk meminimalkan RPO, Anda dapat menggunakan gabungan ketersediaan tinggi dan arsitektur pemulihan bencana. Tetapi konfigurasi ini menimbulkan risiko yang berpotensi lebih tinggi dari bencana alam skala besar.
Rekomendasi desain untuk pemulihan bencana
Pastikan bahwa perutean antar-domain tanpa kelas (CIDR) untuk jaringan virtual utama tidak bertentangan atau tumpang tindih dengan CIDR jaringan virtual situs pemulihan bencana.
Siapkan koneksi ExpressRoute dari lokal ke wilayah pemulihan bencana Azure primer dan sekunder.
Pertimbangkan untuk menyiapkan koneksi VPN dari lokal ke wilayah pemulihan bencana Azure primer dan sekunder. Gunakan metode ini sebagai alternatif untuk menggunakan ExpressRoute.
Gunakan Site Recovery untuk mereplikasi server aplikasi ke situs pemulihan bencana. Site Recovery juga dapat membantu Anda mereplikasi VM kluster layanan pusat ke situs pemulihan bencana. Ketika Anda memanggil pemulihan bencana, Anda perlu mengonfigurasi ulang kluster Linux Pacemaker di situs pemulihan bencana. Misalnya, Anda mungkin perlu mengganti alamat IP virtual atau SBD atau menjalankan corosync.conf.
Replikasi konten brankas kunci seperti sertifikat, rahasia, atau kunci di seluruh wilayah sehingga Anda dapat mendekripsi data di wilayah pemulihan bencana.
Gunakan replikasi lintas wilayah di Azure NetApp Files untuk menyinkronkan volume file antara wilayah utama dan wilayah pemulihan bencana.
Gunakan replikasi database asli, bukan Site Recovery, untuk menyinkronkan data ke situs pemulihan bencana.
Serekan jaringan virtual utama dan pemulihan bencana. Misalnya, untuk replikasi sistem HANA, Anda perlu melakukan peering jaringan virtual SAP Hana DB ke jaringan virtual SAP Hana DB situs pemulihan bencana.
Jika Anda menggunakan penyimpanan Azure NetApp Files untuk penyebaran SAP Anda, minimal, buat dua akun Azure NetApp Files di tingkat Premium, di dua wilayah.
Pertimbangkan untuk mengelompokkan sistem berdasarkan kepentingan bisnis dan dependensi kedekatannya berdasarkan performa aplikasi. Untuk meminimalkan efek bisnis pemadaman regional, sebarkan setiap grup ke wilayah terpisah dalam konstruksi wilayah berpasangan. Misalnya, untuk meminimalkan efek pemadaman regional, Anda dapat menyebarkan dua sistem Komponen Pusat ERP penting yang melayani dua unit bisnis yang berbeda, di UK Selatan dan UK Barat.