Arsitektur serta skenario dengan ketersediaan tinggi untuk SAP NetWeaver
Definisi terminologi
Ketersediaan tinggi: Mengacu pada kumpulin teknologi yang meminimalkan gangguan IT dengan menyediakan kelangsungan bisnis layanan IT melalui komponen yang redundan, toleran terhadap kesalahan, atau dilindungi kegagalan di dalam pusat data sama. Dalam kasus kami, pusat data berada dalam satu wilayah Azure.
Pemulihan bencana: Juga mengacu pada meminimalkan gangguan layanan IT dan pemulihannya, tetapi di berbagai pusat data yang mungkin berjarak ratusan mil dari satu sama lain. Dalam kasus kami, pusat data mungkin berada di berbagai wilayah Azure dalam wilayah geopolitik yang sama atau di lokasi yang ditetapkan oleh Anda sebagai pelanggan.
Gambaran umum ketersediaan tinggi
Ketersediaan tinggi SAP di Azure dapat dipisahkan menjadi tiga jenis:
Ketersediaan tinggi infrastruktur Azure:
Misalnya, ketersediaan tinggi dapat mencakup komputasi (VM), jaringan, atau penyimpanan dan manfaatnya untuk meningkatkan ketersediaan aplikasi SAP.
Menggunakan mulai ulang VM infrastruktur Azure untuk melindungi aplikasi SAP:
Jika Anda memutuskan untuk tidak menggunakan fungsionalitas seperti Windows Server Failover Clustering (WSFC) atau Pacemaker di Linux, pemulaian ulang Azure VM digunakan. Ini memulihkan fungsionalitas dalam sistem SAP jika ada waktu henti yang direncanakan dan tidak direncanakan dari infrastruktur server fisik Azure dan platform Azure yang mendasarinya secara keseluruhan.
Ketersediaan tinggi aplikasi SAP:
Untuk mencapai ketersediaan tinggi sistem SAP penuh, Anda harus melindungi semua komponen sistem SAP yang penting. Contohnya:
- Server aplikasi SAP berlebihan.
- Komponen unik. Contohnya mungkin komponen titik kegagalan tunggal (SPOF), seperti instans SAP ASCS/SCS atau sistem manajemen basis data (DBMS).
Ketersediaan tinggi SAP di Azure berbeda dari ketersediaan tinggi SAP di lingkungan fisik atau virtual secara lokal.
Tidak ada konfigurasi ketersediaan tinggi SAP yang terintegrasi dengan sapinst untuk Linux karena ada untuk Windows. Untuk informasi tentang SAP ketersediaan tinggi di lingkungan lokal untuk Linux, lihat Informasi mitra ketersediaan tinggi.
Ketersediaan tinggi infrastruktur Azure
SLA untuk komputer virtual instans tunggal
Saat ini ada SLA VM tunggal sebesar 99,9% dengan penyimpanan premium. Untuk mendapatkan gambaran tentang ketersediaan VM tunggal, Anda dapat membuat produk dari berbagai Perjanjian Tingkat Layanan Azure yang tersedia.
Dasar perhitungannya adalah 30 hari per bulan, atau 43.200 menit. Misalnya, waktu henti 0,05% sama dengan 21,6 menit. Seperti biasa, ketersediaan berbagai layanan dihitung dengan cara berikut:
(Layanan Ketersediaan #1/100) x (Layanan Ketersediaan #2/100) x (Layanan Ketersediaan #3/100) *...
Contohnya:
(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 atau ketersediaan keseluruhan 99,75%.
Beberapa instans komputer virtual dalam kumpulan ketersediaan yang sama
Untuk semua komputer virtual yang memiliki dua instans atau lebih yang disebarkan dalam set ketersediaan yang sama, kami menjamin bahwa Anda memiliki konektivitas komputer virtual ke setidaknya satu instans setidaknya 99,95% dari waktu.
Ketika dua atau beberapa VM merupakan bagian dari kumpulan ketersediaan yang sama, setiap komputer virtual dalam kumpulan ketersediaan ditetapkan sebagai domain pembaruan dan domain kesalahan oleh platform Azure yang mendasarinya.
- Domain pembaruan menjamin bahwa beberapa VM tidak di-boot ulang secara bersamaan selama pemeliharaan infrastruktur Azure yang direncanakan. Hanya satu VM yang di-boot ulang pada satu waktu.
- Domain kesalahan menjamin bahwa VM disebarkan pada komponen perangkat keras yang tidak berbagi sumber daya umum dan sakelar jaringan. Saat server, sakelar jaringan, atau sumber daya mengalami waktu henti yang tidak direncanakan, hanya satu VM yang terpengaruh.
Untuk informasi selengkapnya, lihat mengelola ketersediaan komputer virtual di Azure menggunakan set ketersediaan.
Azure Availability Zone
Azure sedang dalam proses meluncurkan konsep Zona Ketersediaan Azure di seluruh Wilayah Azure yang berbeda. Di wilayah Azure tempat Zona Ketersediaan ditawarkan, wilayah Azure memiliki beberapa pusat data, yang independen dalam memasok sumber daya, pendinginan, dan jaringan. Alasan menawarkan zona berbeda dalam satu wilayah Azure adalah untuk memungkinkan Anda menyebarkan aplikasi di dua atau tiga Zona Ketersediaan yang ditawarkan. Dengan asumsi bahwa masalah di sumber daya dan/atau jaringan hanya akan memengaruhi satu infrastruktur Zona Ketersediaan, penerapan aplikasi Anda dalam wilayah Azure masih berfungsi penuh. Akhirnya dengan beberapa pengurangan kapasitas karena beberapa VM dalam satu zona mungkin hilang. Tetapi VM di dua zona lainnya masih aktif dan berjalan. Wilayah Azure yang menawarkan zona tercantum di Zona Ketersediaan Azure.
Saat menggunakan Zona Ketersediaan, ada beberapa hal yang perlu dipertimbangkan. Daftar pertimbangan seperti:
- Anda tidak dapat menyebarkan Kumpulan Ketersediaan Azure dalam Zona Ketersediaan. Satu-satunya kemungkinan untuk menggabungkan Set ketersediaan dan Zona Ketersediaan adalah dengan grup penempatan kedekatan. Untuk informasi selengkapnya, lihat artikel Menggabungkan set ketersediaan dan zona ketersediaan dengan grup penempatan kedekatan.
- Anda tidak dapat menggunakan Load Balancer Dasar untuk membuat solusi kluster failover berdasarkan Windows Failover Cluster Services atau Linux Pacemaker. Sebagai gantinya , Anda perlu menggunakan SKU Azure Standard Load Balancer.
- Zona Ketersediaan Azure tidak memberikan jaminan jarak tertentu antara zona yang berbeda dalam satu wilayah.
- Latensi jaringan antara Zona Ketersediaan Azure yang berbeda dalam wilayah Azure yang berbeda mungkin berbeda dari wilayah Azure ke wilayah. Akan ada kasus, di mana Anda sebagai pelanggan dapat secara wajar menjalankan lapisan aplikasi SAP yang disebarkan di berbagai zona karena latensi jaringan dari satu zona ke VM DBMS aktif masih dapat diterima dari dampak proses bisnis. Sedangkan mungkin ada skenario pelanggan di mana latensi antara DBMS VM aktif dalam satu zona dan instans aplikasi SAP di VM di zona lain bisa terlalu mengganggu dan tidak dapat diterima untuk proses bisnis SAP. Akibatnya, arsitektur penyebaran harus berbeda dengan arsitektur aktif/aktif untuk aplikasi atau arsitektur aktif/pasif jika latensi terlalu tinggi.
- Menggunakan disk terkelola Azure wajib untuk disebarkan ke Zona Ketersediaan Azure.
Virtual Machine Scale Set dengan Flexible Orchestration
Di Azure, Virtual Machine Scale Sets dengan orkestrasi Fleksibel menawarkan sarana untuk mencapai ketersediaan tinggi untuk beban kerja SAP, sama seperti kerangka kerja penyebaran lainnya seperti set ketersediaan dan zona ketersediaan. Dengan set skala yang fleksibel, VM dapat didistribusikan di berbagai zona ketersediaan dan domain kesalahan, menjadikannya opsi yang cocok untuk menyebarkan beban kerja SAP yang sangat tersedia.
Set skala komputer virtual dengan orkestrasi fleksibel menawarkan fleksibilitas 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 VM di berbagai zona dan set skala juga akan mendistribusikan VM di berbagai domain kesalahan dalam 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 menghindari keterbatasan yang terkait dengan pemanfaatan grup penempatan kedekatan untuk memastikan ketersediaan VM di semua pusat data Azure atau di bawah setiap tulang belakang jaringan, disarankan untuk menyebarkan beban kerja SAP di seluruh zona ketersediaan menggunakan set skala fleksibel dengan FD=1. Strategi penyebaran ini memastikan bahwa VM yang disebarkan di setiap zona tidak dibatasi untuk satu pusat data atau tulang belakang jaringan, dan semua komponen sistem SAP, seperti database, ASCS/ERS, dan tingkat aplikasi tercakup pada tingkat zonal.
Jadi, untuk penyebaran beban kerja SAP baru di seluruh zona ketersediaan, kami menyarankan untuk menggunakan set skala fleksibel dengan FD=1. Untuk informasi selengkapnya, lihat set skala komputer virtual untuk dokumen beban kerja SAP.
Pemeliharaan komputer virtual yang terencana dan tidak terencana
Dua jenis peristiwa platform Azure dapat memengaruhi ketersediaan komputer virtual Anda:
- Peristiwa Pemeliharaan terencana adalah pembaruan berkala yang dibuat oleh Microsoft untuk platform Azure yang mendasarinya. Pembaruan meningkatkan keandalan, performa, dan keamanan keseluruhan infrastruktur platform yang dijalankan oleh komputer virtual Anda.
- Peristiwa Pemeliharaan tidak terencana terjadi saat perangkat keras atau infrastruktur fisik yang mendasari komputer virtual Anda gagal dalam beberapa hal. Peristiwa ini mungkin termasuk kegagalan jaringan lokal, kegagalan disk lokal, atau kegagalan tingkat rak lainnya. Ketika kegagalan tersebut terdeteksi, platform Azure secara otomatis memigrasikan komputer virtual Anda dari server fisik tidak sehat yang menghosting komputer virtual Anda ke server fisik yang sehat. Peristiwa seperti itu jarang terjadi, tetapi mungkin juga menyebabkan komputer virtual Anda melakukan boot ulang.
Untuk informasi selengkapnya, lihat pemeliharaan komputer virtual di Azure.
Redundansi Azure Storage
Data di akun penyimpanan Anda selalu direplikasi untuk memastikan ketahanan dan ketersediaan tinggi, memenuhi SLA Azure Storage bahkan dalam menghadapi kegagalan perangkat keras sementara.
Karena Azure Storage menyimpan tiga gambar data secara default, penggunaan RAID 5 atau RAID 1 di beberapa disk Azure tidak diperlukan.
Untuk informasi selengkapnya, lihat Replikasi Azure Storage.
Azure Managed Disks
Disk Terkelola adalah jenis sumber daya di Azure Resource Manager, adalah opsi penyimpanan yang direkomendasikan alih-alih hard disk virtual (VHD) yang disimpan di akun penyimpanan Azure. Disk terkelola secara otomatis selaras dengan set ketersediaan Azure dari komputer virtual yang dilampirkan. Disk terkelola meningkatkan ketersediaan komputer virtual Anda dan layanan yang berjalan di dalamnya.
Untuk informasi selengkapnya, lihat gambaran umum Disk Terkelola Azure.
Sebaiknya Anda menggunakan disk terkelola karena disk terkelola tersebut menyederhanakan penyebaran dan manajemen komputer virtual Anda.
Perbandingan jenis penyebaran yang berbeda untuk beban kerja SAP
Berikut adalah ringkasan cepat dari berbagai jenis penyebaran yang tersedia untuk beban kerja SAP.
| Fitur | Virtual Machine Scale Set dengan Flexible Orchestration (FD=1) | Zona Ketersediaan | Kumpulan Ketersediaan |
|---|---|---|---|
| Perilaku penyebaran | Instans mendarat di 1, 2, atau 3 zona ketersediaan dan didistribusikan di berbagai rak dalam setiap zona berdasarkan upaya terbaik | Instans mendarat di 1, 2, atau 3 zona ketersediaan | Instans mendarat di dalam wilayah dan didistribusikan di berbagai domain kesalahan/pembaruan |
| Menetapkan VM dan disk terkelola ke zona Ketersediaan tertentu | Ya | Ya | Tidak |
| Domain kesalahan - Penyebaran maks (Azure akan menyebarkan instans secara maksimal) | Ya | Tidak | Ya, berdasarkan jumlah domain kesalahan yang ditentukan selama pembuatan. |
| Menghitung ke perataan domain kesalahan penyimpanan | Tidak | No | Ya |
| Reservasi Kapasitas | Ya (tetapkan reservasi kapasitas di tingkat VM) | Ya | Tidak |
Catatan
- Domain pembaruan tidak digunakan lagi dalam mode Orkestrasi Fleksibel. Untuk informasi selengkapnya, lihat Memigrasikan penyebaran dan sumber daya ke Virtual Machine Scale Sets dalam orkestrasi Fleksibel
- Untuk informasi selengkapnya tentang perataan domain kesalahan komputasi ke penyimpanan, lihat Memilih jumlah domain kesalahan yang tepat untuk Set Skala Komputer Virtual dan Bagaimana cara kerja set ketersediaan?.
- Untuk mengaktifkan reservasi kapasitas, penting untuk memeriksa batasan dan batasan reservasi kapasitas.
Opsi penyebaran ketersediaan tinggi untuk beban kerja SAP
Saat menyebarkan beban kerja SAP ketersediaan tinggi di Azure, penting untuk mempertimbangkan berbagai jenis penyebaran yang tersedia, dan bagaimana mereka dapat diterapkan di berbagai wilayah Azure (seperti di seluruh zona, dalam satu zona, atau di wilayah tanpa zona). Tabel berikut mengilustrasikan beberapa opsi ketersediaan tinggi untuk sistem SAP di wilayah Azure.
| Jenis sistem | Di berbagai zona di suatu wilayah | Di zona bernyanyi dari suatu wilayah | Di wilayah tanpa zona |
|---|---|---|---|
| Sistem SAP Ketersediaan Tinggi | Set skala fleksibel dengan FD=1 | Set Ketersediaan dengan Grup Penempatan Kedekatan | Set Ketersediaan |
| Set Ketersediaan dan Zona Ketersediaan dengan Grup Penempatan Kedekatan | Set skala fleksibel dengan FD=1 (pilih hanya satu zona) | Set skala fleksibel dengan FD=1 (tidak ada zona yang ditentukan) | |
| Zona Ketersediaan | Set Ketersediaan |
- Penyebaran di berbagai zona di suatu wilayah: Untuk ketersediaan tertinggi, sistem SAP harus disebarkan di berbagai zona di suatu wilayah. Ini memastikan bahwa jika satu zona tidak tersedia, sistem SAP terus tersedia di zona lain. Jika Anda menyebarkan beban kerja SAP baru di seluruh zona ketersediaan, disarankan untuk menggunakan skala komputer virtual fleksibel yang diatur dengan opsi penyebaran FD=1. Ini memungkinkan Anda untuk menyebarkan beberapa VM di berbagai zona di suatu wilayah tanpa khawatir tentang batasan kapasitas atau grup penempatan. Kerangka kerja set skala memastikan bahwa VM yang disebarkan dengan set skala akan didistribusikan di berbagai domain kesalahan dalam zona dengan cara upaya terbaik. Semua komponen SAP dengan ketersediaan tinggi seperti SAP ASCS/ERS, database SAP didistribusikan di berbagai zona, sedangkan beberapa server aplikasi di setiap zona didistribusikan ke berbagai domain kesalahan berdasarkan upaya terbaik.
- Penyebaran di satu zona wilayah: Untuk menyebarkan sistem SAP ketersediaan tinggi Anda secara regional di lokasi dengan beberapa zona ketersediaan, dan jika penting bagi semua komponen sistem untuk berada dalam satu zona, maka disarankan untuk menggunakan Set Ketersediaan dengan opsi penyebaran Grup Penempatan Kedekatan. Pendekatan ini memungkinkan Anda mengelompokkan semua komponen sistem SAP dalam satu zona ketersediaan, memastikan bahwa komputer virtual dalam set ketersediaan tersebar di berbagai domain kesalahan dan pembaruan. Meskipun penyebaran ini menyelaraskan komputasi ke domain kesalahan penyimpanan, kedekatan tidak dijamin. Namun, karena opsi penyebaran ini bersifat regional, opsi ini tidak mendukung Azure Site Recovery untuk pemulihan bencana zona-ke-zona. Selain itu, opsi ini membatasi seluruh penyebaran SAP ke satu pusat data, yang dapat menyebabkan keterbatasan kapasitas jika Anda perlu mengubah ukuran SKU atau menskalakan instans aplikasi.
- Penyebaran di wilayah tanpa zona: Jika Anda menyebarkan sistem SAP di wilayah yang tidak memiliki zona apa pun, disarankan untuk menggunakan Set ketersediaan. Opsi ini menyediakan redundansi dan toleransi kesalahan dengan menempatkan VM di domain kesalahan yang berbeda dan memperbarui domain.
Penting
Perlu dicatat bahwa opsi penyebaran untuk wilayah Azure hanyalah saran. Strategi penyebaran yang paling cocok untuk sistem SAP Anda akan bergantung pada persyaratan dan lingkungan khusus Anda.
Memanfaatkan infrastruktur Azure dengan ketersediaan tinggi untuk melindungi aplikasi SAP
Jika Anda memutuskan untuk tidak menggunakan fungsionalitas seperti WSFC atau Pacemaker di Linux (didukung untuk SUSE Linux Enterprise Server 12 dan yang lebih baru, dan Red Hat Enterprise Linux 7 dan yang lebih baru), mulai ulang Azure VM digunakan. Ini memulihkan fungsionalitas dalam sistem SAP jika ada waktu henti yang direncanakan dan tidak direncanakan dari infrastruktur server fisik Azure dan platform Azure yang mendasarinya secara keseluruhan.
Untuk informasi selengkapnya tentang pendekatan ini, lihat Memanfaatkan mulai ulang VM infrastruktur Azure untuk mencapai ketersediaan sistem SAP yang lebih tinggi.
Ketersediaan tinggi aplikasi SAP di Azure IaaS
Untuk mencapai ketersediaan tinggi sistem SAP penuh, Anda harus melindungi semua komponen sistem SAP yang penting. Contohnya:
- Server aplikasi SAP berlebihan.
- Komponen unik. Contohnya mungkin komponen titik kegagalan tunggal (SPOF), seperti instans SAP ASCS/SCS atau sistem manajemen basis data (DBMS).
Bagian selanjutnya membahas bagaimana mencapai ketersediaan tinggi untuk ketiga komponen sistem SAP yang penting.
Arsitektur ketersediaan tinggi untuk server aplikasi SAP
Windows dan
Linux
Anda biasanya tidak memerlukan solusi ketersediaan tinggi khusus untuk server aplikasi SAP dan instans dialog. Anda mencapai ketersediaan tinggi dengan redundansi, dan Anda mengonfigurasi beberapa contoh dialog dalam berbagai contoh komputer virtual Azure. Anda harus memiliki setidaknya dua instans aplikasi SAP yang terinstal di dua instans komputer virtual Azure.
Bergantung pada jenis penyebaran (set skala fleksibel dengan FD=1, zona ketersediaan atau set ketersediaan), Anda harus mendistribusikan instans server aplikasi SAP yang sesuai untuk mencapai redundansi.
- Set skala fleksibel dengan platformFaultDomainCount=1 (FD=1): Server aplikasi SAP yang disebarkan dengan set skala fleksibel (FD=1) mendistribusikan komputer virtual di berbagai zona ketersediaan dan set skala juga akan mendistribusikan VM di berbagai domain kesalahan di setiap zona berdasarkan upaya terbaik. Ini memastikan bahwa jika satu zona tidak tersedia, server aplikasi SAP yang disebarkan di zona lain terus tersedia.
- Zona ketersediaan: Server aplikasi SAP yang disebarkan di seluruh zona ketersediaan memastikan bahwa VM tersebar di berbagai zona untuk mencapai redundansi. Ini memastikan bahwa jika satu zona tidak tersedia, server aplikasi SAP yang disebarkan di zona lain terus tersedia. Untuk informasi selengkapnya, lihat Konfigurasi beban kerja SAP dengan Zona Ketersediaan Azure
- Set ketersediaan: Server aplikasi SAP yang disebarkan dalam set ketersediaan memastikan bahwa VM didistribusikan di berbagai domain kesalahan dan domain pembaruan. Saat menempatkan VM di berbagai domain pembaruan, pastikan bahwa VM tidak diperbarui pada saat yang sama selama waktu henti pemeliharaan terencana. Sedangkan, menempatkan VM di domain kesalahan yang berbeda memastikan bahwa VM dilindungi dari kegagalan perangkat keras atau gangguan daya dalam pusat data. Tetapi jumlah domain kesalahan dan pembaruan yang dapat Anda gunakan di set ketersediaan Azure dalam unit skala Azure terbatas. Jika Anda terus menambahkan VM ke satu set ketersediaan, dua atau beberapa VM pada akhirnya akan berakhir di domain kesalahan atau pembaruan yang sama. Untuk informasi selengkapnya, lihat bagian Kumpulan ketersediaan Azure dari perencanaan dan implementasi komputer virtual Azure untuk dokumen SAP NetWeaver.
Hanya disk yang tidak dikelola: Saat menggunakan disk yang tidak dikelola dengan set ketersediaan, penting untuk mengenali bahwa akun penyimpanan Azure menjadi satu titik kegagalan. Oleh karena itu, sangat penting untuk memposisikan minimal dua akun penyimpanan Azure, di mana setidaknya dua komputer virtual didistribusikan. Dalam pengaturan yang ideal, disk dari setiap mesin virtual yang menjalankan instance dialog SAP akan digunakan di akun penyimpanan yang berbeda.
Penting
Sebaiknya Anda menggunakan disk terkelola Azure untuk penginstalan ketersediaan tinggi SAP Anda. Karena disk terkelola secara otomatis disejajarkan dengan kumpulan ketersediaan komputer virtual yang dilampirkan, disk tersebut meningkatkan ketersediaan komputer virtual Anda dan layanan yang berjalan di dalamnya.
Arsitektur dengan ketersediaan tinggi untuk instans SAP ASCS/SCS di Windows
Anda dapat menggunakan solusi WSFC untuk melindungi instans SAP ASCS/SCS. Berdasarkan jenis konfigurasi berbagi kluster (berbagi file atau disk bersama), Anda dapat merujuk ke solusi yang sesuai berdasarkan jenis penyimpanan Anda.
Berbagi kluster - Berbagi file
Berbagi kluster - Disk bersama
Arsitektur ketersediaan tinggi untuk instans SAP ASCS/SCS di Linux
Di Linux, konfigurasi pengklusteran instans SAP ASCS/SCS tergantung pada distribusi sistem operasi dan jenis penyimpanan yang digunakan. Disarankan untuk menerapkan solusi yang sesuai sesuai dengan kerangka kerja kluster OS spesifik Anda.
SUSE Linux Enterprise Server (SLES)
- Ketersediaan tinggi instans SAP ASCS/SCS menggunakan NFS dengan pemasangan sederhana.
- Ketersediaan tinggi instans SAP ASCS/SCS menggunakan NFS di Azure Files.
- Ketersediaan tinggi instans SAP ASCS/SCS menggunakan NFS di Azure NetApp Files.
- Ketersediaan tinggi instans SAP ASCS/SCS menggunakan NFS Server.
Red Hat Enterprise Linux (RHEL)
Konfigurasi multi-SID SAP NetWeaver untuk instans SAP ASCS/SCS yang berkluster
Multi-SID didukung dengan WSFC, menggunakan berbagi file dan disk bersama. Untuk informasi selengkapnya tentang arsitektur ketersediaan tinggi multi-SID di Windows, lihat:
- Berbagi file: Ketersediaan tinggi multi-SID instans SAP ASCS/SCS untuk Pengklusteran Failover Windows Server dan berbagi file.
- Disk bersama: Ketersediaan tinggi multi-SID instans SAP ASCS/SCS untuk Pengklusteran Failover Windows Server dan disk bersama.
Pengklusteran multi-SID didukung pada kluster Linux Pacemaker untuk SAP ASCS/ERS, terbatas pada lima SAP SID pada kluster yang sama. Untuk informasi selengkapnya tentang arsitektur ketersediaan tinggi multi-SID di Linux, lihat:
- SUSE Linux Enterprise Server (SLES): HA untuk SAP NW di Azure VM di SLES untuk panduan multi-SID aplikasi SAP.
- Red Hat Linux Enterprise (RHEL): HA untuk SAP NW di Azure VM di RHEL untuk panduan multi-SID aplikasi SAP.
Ketersediaan tinggi instans DBMS
Dalam sistem SAP, server DBMS juga sebagai titik kegagalan tunggal. Jadi, penting untuk melindungi database dengan menerapkan solusi ketersediaan tinggi. Solusi ketersediaan tinggi DBMS bervariasi berdasarkan database yang digunakan untuk sistem SAP. Berdasarkan database Anda, ikuti panduan untuk mencapai ketersediaan tinggi pada database Anda.
| Database | Rekomendasi DR |
|---|---|
| SAP HANA | Replikasi Sistem HANA (HSR) |
| Oracle | Oracle Data Guard |
| IBM DB2 | Pemulihan bencana ketersediaan tinggi (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | ASE HADR Selalu Aktif |