SAP S/4HANA Linux on Azure

Arsitektur referensi ini menampilkan serangkaian praktik yang telah terbukti untuk menjalankan S/4HANA dan Suite di HANA dalam lingkungan ketersediaan tinggi yang mendukung pemulihan bencana di Azure. Informasi Fiori hanya berlaku untuk aplikasi S/4HANA.

Arsitektur

Unduh file Visio arsitektur ini.

Alur kerja

Arsitektur referensi ini menjelaskan sistem produksi umum. Arsitektur ini digunakan dengan ukuran komputer virtual yang dapat diubah untuk mengakomodasi kebutuhan organisasi Anda. Agar sesuai dengan kebutuhan bisnis Anda, konfigurasi ini dapat dikurangi menjadi satu komputer virtual.

Tata letak jaringan sangat disederhanakan untuk menunjukkan prinsip arsitektur dan tidak dimaksudkan untuk menggambarkan jaringan perusahaan penuh.

Komponen berikut diperlukan.

Azure Virtual Network. Layanan Azure Virtual Network (VNet) menyambungkan sumber daya Azure yang satu dengan yang lain secara aman. Dalam arsitektur ini, VNet tersambung ke lingkungan lokal melalui gateway yang disebarkan di hub topologi hub-spoke. Spoke adalah VNet yang digunakan untuk aplikasi SAP dan tingkat database.

Peering jaringan virtual. Arsitektur ini menggunakan beberapa jaringan virtual yang diserekan bersama-sama. Topologi ini menawarkan segmentasi jaringan dan isolasi untuk layanan yang diterapkan di Azure. Peering menghubungkan jaringan secara transparan melalui jaringan backbone Microsoft dan tidak dikenakan penalti kinerja jika diimplementasikan dalam satu wilayah. Subnet terpisah digunakan untuk setiap aplikasi tingkat (SAP NetWeaver), database, dan layanan bersama (seperti jumpbox dan Active Directory).

Komputer virtual. Arsitektur ini menggunakan komputer virtual yang menjalankan Linux untuk tingkat aplikasi dan tingkat database, dikelompokkan sebagai berikut:

• Tingkat aplikasi. Termasuk kumpulan Server Front-end Fiori, kumpulan SAP Web Dispatcher, kumpulan server aplikasi, dan kluster Layanan Pusat SAP. Untuk ketersediaan Layanan Pusat yang tinggi saat berjalan pada komputer virtual Linux di Azure, Anda memerlukan layanan berbagi file jaringan ketersediaan tinggi, seperti berbagi file NFS di server Azure Files, Azure NetApp Files, Network File System (NFS) terkluster, atau SIOS Protection Suite untuk Linux. Untuk menyiapkan berbagi file ketersediaan tinggi untuk kluster Central Services di Red Hat Enterprise Linux, Anda dapat mengonfigurasi GlusterFS di komputer virtual Azure yang menjalankan Red Hat Enterprise Linux. Di SUSE Linux Enterprise Server 15 SP1 dan versi yang lebih baru atau di SUSE Linux Enterprise Server untuk Aplikasi SAP, Anda dapat menggunakan disk bersama Azure pada kluster Pacemaker untuk mencapai ketersediaan tinggi.

• SAP Hana. Tingkat database menggunakan dua atau lebih komputer virtual Linux dalam kluster untuk mencapai ketersediaan tinggi dalam penyebaran skala. HANA System Replication (HSR) digunakan untuk mereplikasi konten antara sistem HANA primer dan sekunder. Pengelompokan Linux digunakan untuk mendeteksi kegagalan sistem dan memfasilitasi failover otomatis. Mekanisme anggar berbasis penyimpanan atau berbasis cloud harus digunakan untuk memastikan sistem yang gagal diisolasi atau dimatikan untuk menghindari kondisi pemisahan otak kluster. Dalam penyebaran scale-out HANA, ketersediaan tinggi database dicapai dengan mengonfigurasi node siaga tanpa perlu komponen kluster Linux.

• Jumpbox. Juga disebut host bastion, komputer virtual aman ini pada jaringan digunakan untuk terhubung ke komputer virtual lainnya dan biasanya digunakan sebagai bagian dari layanan bersama, seperti pengendali domain dan layanan pencadangan. Jumpbox ini digunakan pada komputer virtual untuk mendukung SAP HANA Studio, SAPGUI, transfer file, dan fungsi lain yang biasa digunakan untuk tujuan instalasi dan administrasi. Untuk layanan protokol desktop jarak jauh (RDP) atau shell aman (SSH), coba Azure Bastion. Jika hanya RDP dan SSH yang digunakan untuk administrasi, Azure Bastion adalah alternatif yang bagus.

Load balancer. Untuk mendistribusikan lalu lintas ke komputer virtual di subnet tingkat aplikasi SAP untuk ketersediaan tinggi, kami merekomendasikan Load Balancer Standar. Load Balancer Standar memberikan keamanan tinggi secara default. Tidak ada komputer virtual di belakang Load Balancer Standar yang memiliki konektivitas internet keluar. Untuk mengaktifkan konektivitas internet keluar di komputer virtual ini, Anda perlu mengubah konfigurasi Load Balancer Standar Anda. Untuk ketersediaan tinggi untuk aplikasi berbasis web SAP, gunakan SAP Web Dispatcher bawaan atau load balancer lain yang tersedia secara komersial, tergantung pada jenis lalu lintas (seperti HTTP atau SAP GUI) atau layanan jaringan yang diperlukan (seperti penghentian SSL).

Set ketersediaan. Mesin virtual untuk semua kumpulan dan kluster (Web Dispatcher, server aplikasi SAP, Layanan Pusat, dan HANA) dikelompokkan ke dalam set ketersediaan yang terpisah, dan setidaknya dua mesin virtual diprovisikan per peran. Rangkaian ketersediaan meningkatkan ketersediaan aplikasi dan komputer virtual melalui manajemen kesalahan sistem host atau peristiwa pemeliharaan dengan mendistribusikan instans peran ke beberapa host. Alternatifnya adalah menggunakan Zona Ketersediaan untuk meningkatkan ketersediaan beban kerja seperti yang dijelaskan nanti dalam artikel ini.

Gateway. Gateway menyambungkan jaringan yang berbeda, memperluas jaringan lokal Anda ke Azure VNet. Kami merekomendasikan Azure ExpressRoute untuk membuat koneksi privat yang tidak melalui internet publik. Sebagai alternatif, Anda dapat menggunakan koneksi situs-ke-situs . Untuk mengurangi latensi, Anda dapat menggunakan ExpressRoute Global Reach atau ExpressRoute FastPath. Opsi ini dibahas nanti dalam artikel ini.

Gateway zona redundan. Gateway ExpressRoute atau jaringan privat maya (VPN) dapat disebarkan di seluruh zona untuk melindungi dari kegagalan zona. Arsitektur ini menggunakan gateway VNet zona redundan untuk ketahanan, dan bukan penyebaran zona berdasarkan Zona Ketersediaan yang sama.

Grup penempatan kedekatan. Grup logis ini menempatkan batasan pada VM yang disebarkan dalam set ketersediaan atau set skala komputer virtual. Grup penempatan kedekatan mendukung kolokasi, sehingga komputer virtual berada di pusat data yang sama untuk meminimalkan latensi aplikasi.

Kelompok keamanan jaringan. Untuk membatasi lalu lintas masuk, keluar, dan intra-subnet di jaringan virtual, Anda dapat membuat kelompok keamanan jaringan (NSG).

Kelompok keamanan aplikasi. Untuk menentukan kebijakan keamanan jaringan yang terperinci berdasarkan beban kerja dan berpusat pada aplikasi, gunakan kelompok keamanan aplikasi, dan bukan alamat IP eksplisit. Anda dapat mengelompokkan komputer virtual menurut nama dan aplikasi yang aman dengan memfilter lalu lintas dari segmen tepercaya jaringan Anda.

Azure Storage. Untuk memberikan kegigihan data untuk komputer virtual berupa virtual hard disk (VHD). Azure Managed Disk disarankan.

Rekomendasi

Arsitektur ini menjelaskan penyebaran tingkat produksi yang kecil. Penyebaran Anda akan berbeda berdasarkan kebutuhan bisnis Anda, jadi pertimbangkan rekomendasi ini sebagai titik awal.

Komputer virtual

Di kumpulan server aplikasi dan kluster, sesuaikan jumlah komputer virtual berdasarkan kebutuhan Anda. Panduan perencanaan dan implementasi Azure Virtual Machines mencakup detail tentang menjalankan SAP NetWeaver pada mesin virtual, dan informasi ini juga berlaku untuk penyebaran SAP S/4HANA.

Untuk detail tentang dukungan SAP untuk jenis mesin virtual Azure dan metrik throughput (SAPS), lihat SAP Note 1928533. (Untuk mengakses catatan SAP, Anda harus memiliki akun Marketplace Layanan SAP.) Direktori Perangkat Keras SAP Bersertifikat dan Didukung SAP Hana memiliki daftar komputer virtual Azure bersertifikat untuk database HANA.

SAP Web Dispatcher

Komponen Web Dispatcher digunakan sebagai load balancer untuk lalu lintas SAP di antara beberapa server aplikasi SAP. Untuk mencapai ketersediaan tinggi SAP Web Dispatcher, Azure Load Balancer menerapkan kluster failover atau penyiapan Web Dispatcher paralel. Untuk komunikasi yang menghadap internet, solusi mandiri di DMZ akan menjadi arsitektur yang direkomendasikan untuk mengatasi masalah keamanan. Dispatcher Web yang Tersemat di ASCS adalah opsi khusus, ukuran yang tepat karena beban kerja tambahan di ASCS harus diperhitungkan.

Fiori Front-end Server (FES)

Arsitektur ini membahas persyaratan dasar yang luas dan mengasumsikan bahwa model Embedded Fiori FES digunakan. Semua komponen teknologi dipasang pada sistem S/4 itu sendiri, yang berarti bahwa setiap sistem S/4 memiliki Fiori Launchpad sendiri. Pengaturan ketersediaan tinggi untuk model penyebaran ini adalah sistem S/4 - tidak diperlukan pengelompokan tambahan atau komputer virtual. Itu sebabnya diagram arsitektur tidak menampilkan komponen FES.

Dokumen Opsi Penyebaran SAP Fiori dan Rekomendasi Lanskap Sistem menjelaskan opsi penyebaran utama, baik yang disematkan atau hub, bergantung pada skenario. Dalam mencapai penyederhanaan dan kinerja, perangkat lunak rilis antara komponen teknologi Fiori dan aplikasi S/4 digabungkan erat, membuat penyebaran hub cocok hanya untuk beberapa kasus penggunaan sempit.

Jika Anda menggunakan penyebaran hub FES, FES adalah komponen add-on ke tumpukan ABAP SAP NetWeaver klasik. Siapkan ketersediaan tinggi dengan cara yang sama Anda melindungi tumpukan aplikasi ABAP tiga tingkat dengan kemampuan kluster atau multi-host-dengan lapisan database server siaga, lapisan ASCS mengelompokkan dengan NFS ketersediaan tinggi untuk penyimpanan bersama, dan setidaknya dua server aplikasi. Lalu lintas dengan beban diseimbangkan melalui sepasang Web Dispatchers terkluster atau paralel. Untuk aplikasi Fiori yang menghadap internet, penyebaran hub FES di DMZ akan direkomendasikan. Gunakan Azure Application Gateway/WAF sebagai komponen penting untuk mempertahankan lalu lintas dengan Azure AD dengan SAML untuk autentikasi pengguna dan SSO untuk SAP Fiori.

Kumpulan server aplikasi

Untuk mengelola grup log masuk untuk server aplikasi ABAP, biasanya menggunakan transaksi SMLG untuk memuat pengguna log masuk load-balance, SM61 untuk grup server batch, RZ12 untuk grup RFC, dan sebagainya. Transaksi ini menggunakan kemampuan load balancer dalam server pesan Central Services untuk mendistribusikan sesi masuk atau beban kerja di antara kumpulan server aplikasi SAP untuk SAPGUIs dan lalu lintas RFC.

Kluster SAP Central Services

Central Services dapat digunakan ke satu komputer virtual saat SLA ketersediaan VM instans tunggal Azure memenuhi kebutuhan Anda. Namun, komputer virtual menjadi potensi titik kegagalan tunggal (SPOF) untuk lingkungan SAP. Untuk penyebaran Layanan Pusat yang sangat tersedia, gunakan NFS melalui Azure Files atau layanan Azure NetApp Files dan kluster Layanan Pusat.

Opsi lainnya adalah menggunakan Azure Shared Disks untuk mencapai ketersediaan tinggi. Di SUSE Linux Enterprise Server 15 SP1 dan yang lebih baru atau SUSE Linux Enterprise Server untuk Aplikasi SAP, Anda dapat menyiapkan kluster Pacemaker menggunakan Azure Shared Disks untuk Linux.

Sebagai alternatif, berbagi file NFS dapat digunakan untuk penyimpanan bersama kluster Linux.

Pada penyebaran Azure, server aplikasi terhubung ke Central Services yang sangat tersedia melalui nama host virtual Central Services atau layanan ERS. Nama host ini ditetapkan ke konfigurasi IP frontend kluster dari load balancer. Azure Load Balancer mendukung beberapa IP frontend, sehingga baik Central Services dan ERS virtual IP (VIP) dapat terikat ke satu load balancer beban.

Dukungan kluster Linux untuk penginstalan multi-SID ASCS di Azure kini didukung. Lebih sedikit kluster yang membantu menyederhanakan lanskap SAP.

Set ketersediaan

Set ketersediaan mendistribusikan server ke infrastruktur fisik yang berbeda dan memperbarui grup untuk meningkatkan ketersediaan layanan. Tempatkan mesin virtual yang menjalankan peran yang sama ke dalam ketersediaan yang ditetapkan untuk membantu menjaga dari waktu henti yang disebabkan oleh pemeliharaan infrastruktur Azure dan untuk memenuhi perjanjian tingkat layanan (SLA). Dua atau lebih komputer virtual per set ketersediaan diperlukan untuk mendapatkan SLA yang lebih tinggi.

Semua komputer virtual dalam satu set harus melakukan peran yang sama. Jangan mencampur server dari peran yang berbeda dalam kumpulan ketersediaan yang sama. Misalnya, jangan menempatkan node ASCS dalam ketersediaan yang sama dengan server aplikasi.

Anda dapat menyebarkan set ketersediaan Azure dalam Zona Ketersediaan Azure saat menggunakan grup penempatan kedekatan.

Jaringan

Arsitektur ini menggunakan topologi hub-spoke, di mana hub VNet bertindak sebagai titik pusat konektivitas ke jaringan lokal. Juru bicara adalah VNet yang mengintip dengan hub, dan mereka dapat digunakan untuk mengisolasi beban kerja. Arus lalu lintas antara pusat data lokal dan hub melalui koneksi gateway.

Kartu antarmuka jaringan (NIC)

Penyebaran SAP lokal tradisional menerapkan beberapa NIC per komputer untuk memisahkan lalu lintas administratif dari lalu lintas bisnis. Di Azure, VNet adalah jaringan yang ditentukan perangkat lunak yang mengirimkan semua lalu lintas melalui kain jaringan yang sama. Oleh karena itu, penggunaan beberapa NIC tidak perlu untuk pertimbangan kinerja. Namun, jika organisasi Anda perlu memisahkan lalu lintas, Anda dapat menerapkan beberapa NIC per komputer virtual, menghubungkan setiap NIC ke subnet yang berbeda, lalu menggunakan NSGs untuk menerapkan kebijakan kontrol akses yang berbeda.

Azure NIC mendukung banyak IP, yang mendukung praktik yang direkomendasikan SAP untuk menggunakan nama host virtual dalam penginstalan sebagaimana diuraikan dalam Catatan SAP 962955. (Untuk mengakses catatan SAP, Anda harus memiliki akun SAP Service Marketplace.)

Subnet dan NSG

Arsitektur ini membagi ruang alamat VNet menjadi subnet. Setiap subnet dapat dikaitkan dengan NSG yang menentukan kebijakan akses untuk subnet. Tempatkan server aplikasi pada subnet terpisah sehingga Anda dapat mengamankannya dengan lebih mudah dengan mengelola kebijakan keamanan subnet, alih-alih server individual.

Ketika dikaitkan dengan subnet, NSG berlaku untuk semua server dalam subnet dan menawarkan kontrol fine-grained atas server. Siapkan menggunakan portal, PowerShell, atau Azure CLI.

Jangkauan Global ExpressRoute

Jika lingkungan jaringan Anda mencakup dua atau lebih sirkuit ExpressRoute, opsi untuk mengurangi lompatan jaringan dan latensi yang lebih rendah adalah dengan menggunakan ExpressRoute Global Reach. Ini adalah pengaturan peering rute Border Gateway Protocol (BGP) antara dua atau lebih sirkuit ExpressRoute untuk menjembatani dua domain perutean ExpressRoute. Global Reach menurunkan latensi saat lalu lintas jaringan melintasi lebih dari satu sirkuit ExpressRoute dan saat ini hanya tersedia untuk peering pribadi di sirkuit ExpressRoute.

Saat ini, tidak ada daftar kontrol akses jaringan (ACL) atau atribut lain yang dapat diubah di Global Reach, yang berarti bahwa semua rute yang dipelajari oleh sirkuit ExpressRoute tertentu (dari lokal dan Azure) diiklankan di seluruh sirkuit mengintip ke sirkuit ExpressRoute lainnya. Disarankan untuk membuat pemfilteran lalu lintas jaringan di tempat untuk membatasi akses ke sumber daya.

ExpressRoute FastPath

FastPath mengimplementasikan pertukaran Microsoft Edge di titik masuk jaringan Azure. Ini mengurangi hop jaringan untuk sebagian besar paket data. FastPath menurunkan latensi jaringan, meningkatkan kinerja aplikasi, dan merupakan default untuk koneksi ExpressRoute baru ke Azure.

Untuk sirkuit ExpressRoute yang ada, aktifkan FastPath dengan dukungan Azure.

FastPath tidak mendukung peering VNet. Jika Anda memiliki VNet lain yang diinjak dengan VNet yang tersambung ke ExpressRoute, lalu lintas jaringan dari jaringan lokal Anda ke VNet lain yang berbicara akan terus dikirim ke gateway VNet. Solusinya adalah menghubungkan semua VNet ke sirkuit ExpressRoute secara langsung.

Load balancer

SAP Web Dispatcher menangani penyeimbangan beban lalu lintas HTTP(S) ke kumpulan server aplikasi SAP. Penyeimbang beban perangkat lunak ini menawarkan layanan lapisan aplikasi (disebut sebagai lapisan 7 dalam model jaringan ISO) yang mampu melakukan penghentian SSL dan fungsi pembongkaran lainnya.

Azure Load Balancer adalah layanan lapisan transmisi jaringan (lapisan 4), yang menyeimbangkan lalu lintas dengan hash 5 tupel dari aliran data (berdasarkan IP sumber, port sumber, IP tujuan, port tujuan, dan jenis protokol). Ini digunakan dalam pengaturan kluster untuk mengarahkan lalu lintas ke instans layanan utama atau node sehat jika terjadi kesalahan. Sebaiknya gunakan Azure Standard Load Balancer untuk semua skenario SAP. Penting untuk digarisbawahi bahwa Standard Load Balancer aman secara default, dan tidak ada mesin virtual di balik Standard Load Balancer yang memiliki konektivitas internet keluar. Untuk mengaktifkan internet keluar di mesin virtual, Anda harus mempertimbangkan konfigurasi Standard Load Balancer.

Untuk lalu lintas dari klien SAP GUI yang menyambungkan server SAP melalui protokol DIAG atau Remote Function Calls (RFC), server pesan Layanan Pusat menyeimbangkan beban melalui grup masuk server aplikasi SAP. Tidak diperlukan load balancer tambahan.

Azure Storage

Beberapa pelanggan menggunakan penyimpanan standar untuk server aplikasi mereka. Karena disk terkelola standar tidak didukung, seperti yang dinyatakan dalam catatan SAP 1928533, sebaiknya gunakan Disk Terkelola Azure Premium atau Azure NetApp Files dalam semua kasus. Perhatikan bahwa pembaruan terbaru untuk Catatan SAP 2015553 mengecualikan penggunaan Penyimpanan HDD Standar dan Penyimpanan SSD Standar untuk beberapa kasus penggunaan tertentu.

Karena server aplikasi tidak menghosting data bisnis, Anda juga dapat menggunakan disk P4 dan P6 Premium yang lebih kecil untuk membantu meminimalkan biaya. Untuk informasi tentang SLA ketersediaan VM yang terkait dengan berbagai jenis penyimpanan, lihat SLA untuk Virtual Machines. Untuk skenario High-Availability fitur Disk Bersama Azure tersedia di SSD Premium dan Disk Terkelola Azure SSD Ultra. Azure Shared Disks dapat digunakan dengan Windows Server, SUSE Enterprise Linux 15 SP 1 dan yang lebih baru, atau SUSE Enterprise Linux For SAP. Azure NetApp Files memiliki fungsi berbagi file bawaan.

Untuk skenario NFS Share, Azure NetApp Files menyediakan ketersediaan 99,99% (empat sembilan) untuk berbagi NFS yang dapat digunakan untuk volume /hana/shared, /hana/data, dan /hana/log. Menggunakan berbagi NFS berbasis Azure NetApp Files untuk volume /hana/data dan /hana/log memerlukan penggunaan protokol NFS v4.1. Untuk volume /hana/shared, protokol NFS v3 didukung.

Untuk penyimpanan data cadangan, sebaiknya gunakan tingkat arsip dan dingin Azure. Tingkat penyimpanan ini adalah cara hemat biaya untuk menyimpan data berumur panjang yang jarang diakses. Anda juga dapat mempertimbangkan untuk menggunakan tingkat standar Azure NetApp Files sebagai target cadangan atau opsi Azure NetApp Files Backup. Untuk Disk terkelola, tingkat data cadangan yang direkomendasikan adalah tingkat akses dingin atau arsip Azure.

SSD Ultra dan tingkat performa Ultra Azure NetApp Files sangat mengurangi latensi disk dan menguntungkan aplikasi penting performa dan server database SAP.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian prinsip panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Efisiensi performa

Server aplikasi SAP melakukan komunikasi konstan dengan server database. Untuk aplikasi yang penting performa yang berjalan pada platform database apa pun, termasuk SAP Hana, aktifkan Write Accelerator (WA) untuk volume log guna meningkatkan latensi penulisan log. WA tersedia untuk VM seri-M.

Untuk mengoptimalkan komunikasi antar-server, gunakan Jaringan yang Dipercepat. Opsi ini hanya tersedia untuk mesin virtual yang didukung, termasuk D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2, dan Ms/Mms.

Untuk detail tentang persyaratan performa SAP Hana, lihat Catatan SAP 1943937 - Alat Pemeriksaan Konfigurasi Perangkat Keras (diperlukan akun SAP Service Marketplace untuk mengaksesnya).

Untuk mencapai IOPS dan throughput bandwidth disk yang tinggi, praktik umum dalam pengoptimalan performa volume penyimpanan berlaku untuk tata letak penyimpanan Azure. Misalnya, menggabungkan beberapa disk bersama untuk membuat volume disk tersegmentasi akan meningkatkan performa IO. Mengaktifkan cache baca pada konten penyimpanan yang jarang berubah akan meningkatkan kecepatan pengambilan data. Lihat juga rekomendasi tentang konfigurasi penyimpanan untuk berbagai ukuran mesin virtual saat menjalankan SAP Hana.

Disk ultra adalah penyimpanan generasi baru untuk memenuhi IOPS yang intensif dan permintaan bandwidth transfer aplikasi seperti SAP Hana. Anda dapat secara dinamis mengubah performa disk ultra dan secara mandiri mengonfigurasi metrik seperti IOPS dan MB/s tanpa me-reboot mesin virtual. Jika tersedia, SSD Ultra direkomendasikan sebagai pengganti WA.

Beberapa aplikasi SAP memerlukan komunikasi yang sering dengan database. Latensi jaringan antara lapisan database dan aplikasi, karena jarak yang dekat, dapat berdampak buruk pada performa aplikasi. Grup penempatan kedekatan Azure menetapkan batasan penempatan untuk mesin virtual yang disebarkan dalam set ketersediaan. Dalam konstruksi logis grup, kolokasi dan performa lebih disukai daripada skalabilitas, ketersediaan, dan biaya. Grup penempatan kedekatan dapat sangat meningkatkan pengalaman pengguna untuk sebagian besar aplikasi SAP, dan skrip dan utilitas tersedia di GitHub.

Sebaiknya jangan menempatkan appliance virtual jaringan (NVA) apa pun di antara lapisan database dan aplikasi untuk tumpukan aplikasi SAP apa pun, karena praktik ini memperkenalkan waktu pemrosesan paket data yang signifikan dan memperlambat performa aplikasi secara tidak wajar.

Kami juga menyarankan agar Anda mempertimbangkan performa saat menyebarkan sumber daya dengan Zona Ketersediaan, yang dapat meningkatkan ketersediaan layanan seperti yang dijelaskan nanti dalam artikel ini. Pertimbangkan untuk membuat profil latensi jaringan yang jelas di antara semua zona wilayah target. Ini membantu Anda memutuskan penempatan sumber daya untuk latensi minimum antar-zona. Untuk membuat profil ini, jalankan pengujian dengan menyebarkan mesin virtual kecil di setiap zona. Alat yang direkomendasikan untuk pengujian termasuk PsPing dan Iperf. Setelah pengujian, hapus mesin virtual ini. Alat pengujian latensi jaringan domain publik juga tersedia untuk kemudahan Anda.

Azure NetApp Files memiliki fitur performa unik yang memungkinkan penyetelan real time yang memenuhi kebutuhan lingkungan SAP yang paling menuntut. Untuk pertimbangan performa menggunakan Azure NetApp Files lihat artikel ini.

Skalabilitas

Pada lapisan aplikasi SAP, Azure menawarkan berbagai ukuran mesin virtual untuk peningkatan dan penskalaan. Untuk daftar inklusif, lihat Catatan SAP 1928533 - Aplikasi SAP di Azure: Produk yang Didukung dan jenis VM Azure (diperlukan akun SAP Service Marketplace untuk mengaksesnya). Karena kami terus mensertifikasi lebih banyak jenis mesin virtual, Anda dapat meningkatkan atau menurunkan skala dalam penyebaran cloud yang sama.

Pada lapisan database, arsitektur ini menjalankan aplikasi SAP Hana S/4 pada mesin virtual Azure yang dapat ditingkatkan skalanya hingga 6 terabyte (TB) dalam satu instans. Jika beban kerja Anda melebihi ukuran mesin virtual maksimum, Microsoft menawarkan Azure Large Instances untuk SAP Hana, opsi yang jauh melebihi batas RAM 12 TB. Rev. 4 dari server fisik ini terletak di pusat data Microsoft Azure dan, pada saat penulisan ini, menyediakan kapasitas memori hingga 24 TB untuk satu instans. Konfigurasi multi-node juga dimungkinkan dengan total kapasitas memori hingga 24 TB untuk aplikasi pemrosesan transaksi online (OLTP) dan 60 TB untuk aplikasi pemrosesan analitik daring (OLAP).

Ketersediaan

Redundansi sumber daya adalah tema umum dalam solusi infrastruktur dengan ketersediaan tinggi. Untuk SLA ketersediaan VM instans tunggal yang terkait dengan berbagai jenis penyimpanan, lihat SLA untuk Virtual Machines. Saat sumber daya yang redundan disebarkan dalam set ketersediaan atau di seluruh Zona Ketersediaan, ketersediaan layanan akan ditingkatkan.

Dalam penginstalan aplikasi SAP terdistribusi ini, penginstalan dasar direplikasi untuk mencapai ketersediaan tinggi. Untuk setiap lapisan arsitektur, desain ketersediaan tinggi dapat bervariasi.

Web Dispatcher di tingkat server aplikasi

Ketersediaan tinggi dicapai dengan instans Web Dispatcher redundan. Lihat SAP Web Dispatcher dalam dokumentasi SAP.

Layanan Pusat di tingkat server aplikasi

Ekstensi ketersediaan tinggi yang sesuai untuk distribusi Linux yang dipilih digunakan untuk ketersediaan tinggi Layanan Pusat pada komputer virtual Azure Linux. Sistem file bersama biasanya ditempatkan pada penyimpanan NFS ketersediaan tinggi yang dikonfigurasi dengan SUSE DRBD atau Red Hat GlusterFS. Anda dapat menggunakan solusi hemat biaya atau kuat lainnya seperti NFS melalui Azure Files atau Azure NetApp Files untuk menyediakan NFS dengan ketersediaan tinggi. Melakukannya menghilangkan kebutuhan akan kluster NFS. Perhatikan bahwa berbagi Azure NetApp Files dapat menghosting data SAP Hana dan file log. Konfigurasi ini memungkinkan model penyebaran peluasan skala HANA dengan simpul siaga. NFS melalui Azure Files cukup untuk berbagi file non-database dengan ketersediaan tinggi.

NFS melalui Azure Files sekarang mendukung berbagi file dengan ketersediaan tinggi untuk SUSE Linux Enterprise Server dan Redhat Enterprise Linux. Solusi ini berfungsi dengan baik untuk berbagi file ketersediaan tinggi seperti yang ada di /sapmnt dan /saptrans dalam penginstalan SAP.

Azure NetApp Files mendukung ketersediaan ASCS yang tinggi di SUSE Linux Enterprise Servers (SLES). Lihat SIOS Protection Suite untuk Linux untuk detail tentang ASCS di Red Hat Enterprise Linux (RHEL) HA.

Agen Fence Azure yang ditingkatkan tersedia untuk SUSE dan Red Hat dan menyediakan failover layanan yang jauh lebih cepat dibandingkan dengan versi agen sebelumnya.

Opsi lainnya adalah menggunakan Azure Shared Disks untuk mencapai ketersediaan tinggi. Pada SUSE Enterprise Linux 15 SP 1 dan yang lebih baru, atau SUSE Enterprise Linux For SAP, kluster Pacemaker dapat disiapkan menggunakan Azure Shared Disk untuk mencapai ketersediaan tinggi.

Dengan Standard Azure Load Balancer SKU, Anda cukup mengaktifkan port ketersediaan tinggi dan menghindari kebutuhan untuk mengonfigurasi aturan penyeimbangan beban untuk banyak port SAP. Selain itu, saat menyiapkan penyeimbang beban secara umum, baik di lingkungan lokal atau di Azure, pengaktifan fitur Pengembalian Server Langsung (juga dikenal sebagai Floating IP atau DSR) memungkinkan respons server terhadap pertanyaan klien untuk melewati penyeimbang beban. Sambungan langsung ini menjaga penyeimbang beban agar tidak menjadi penyempitan di jalur transmisi data. Untuk kluster SAP ASCS dan HANA DB, kami menyarankan untuk mengaktifkan DSR. Jika mesin virtual di kumpulan backend memerlukan konektivitas keluar publik, diperlukan konfigurasi tambahan.

Untuk lalu lintas dari klien SAP GUI yang tersambung ke server SAP melalui protokol DIAG atau RFC, server pesan Layanan Pusat menyeimbangkan beban melalui grup masuk server aplikasi SAP. Tidak diperlukan load balancer tambahan.

Server aplikasi di tingkat server aplikasi

Ketersediaan tinggi dicapai dengan menyeimbangkan beban lalu lintas dalam kumpulan server aplikasi.

Tingkat database

Arsitektur referensi ini menggambarkan sistem database SAP Hana yang sangat tersedia, yang terdiri dari dua mesin virtual Azure. Fitur replikasi sistem native tingkat database menyediakan failover manual atau otomatis antara node yang direplikasi:

• Untuk failover manual, sebarkan lebih dari satu instans HANA dan gunakan HANA System Replication (HSR).

• Untuk failover otomatis, gunakan HSR dan Linux High Availability Extension (HAE) untuk distribusi Linux Anda. Linux HAE menyediakan layanan kluster ke sumber daya HANA, mendeteksi peristiwa kegagalan dan mengatur failover layanan yang salah ke node yang sehat.

• Sama seperti lapisan server aplikasi, solusi ketersediaan tinggi HANA yang umum disebarkan untuk SLES adalah Pacemaker dan SIOS LifeKeeper untuk RHEL.

Menyebarkan mesin virtual di seluruh Zona Ketersediaan

Zona Ketersediaan dapat membantu meningkatkan ketersediaan layanan. Zona merujuk ke lokasi yang terpisah secara fisik dalam wilayah Azure tertentu. Zona meningkatkan ketersediaan beban kerja dan melindungi layanan aplikasi dan mesin virtual dari pemadaman pusat data. Mesin virtual dalam satu zona diperlakukan seolah-olah mesin virtual tersebut berada dalam domain kesalahan atau pembaruan tunggal. Ketika penyebaran zona dipilih, mesin virtual di zona yang sama didistribusikan ke domain kesalahan dan peningkatan berdasarkan upaya terbaik.

Di Wilayah Azure yang mendukung fitur ini, tersedia setidaknya tiga zona. Namun, jarak maksimum antara pusat data di zona ini tidak dijamin. Untuk menyebarkan sistem SAP multi-tingkat di seluruh zona, Anda harus mengetahui latensi jaringan di dalam zona dan di seluruh zona yang ditargetkan, serta seberapa sensitif aplikasi yang Anda sebarkan terhadap latensi jaringan.

Saat Anda menyebarkan sumber daya di seluruh Zona Ketersediaan, beberapa pertimbangan berlaku, termasuk:

• Latensi antara mesin virtual dalam satu zona.

• Latensi antara mesin virtual di seluruh zona yang dipilih.

• Ketersediaan layanan Azure yang sama (jenis mesin virtual) di zona yang dipilih.

Contoh penyebaran aktif/pasif

Dalam penyebaran contoh ini, status aktif/pasif mengacu pada status layanan aplikasi dalam zona. Di lapisan aplikasi, keempat server aplikasi aktif dari sistem SAP berada di zona 1. Set lain dari empat server aplikasi pasif dibangun di zona 2 tetapi dimatikan, hanya untuk diaktifkan saat dibutuhkan.

Kluster dua node untuk Layanan Pusat dan database membentang di dua zona. Jika zona 1 gagal, Layanan Pusat dan layanan database akan berjalan di zona 2. Server aplikasi pasif di zona 2 diaktifkan. Setelah semua komponen sistem SAP ini dikolokasikan di zona yang sama, latensi jaringan diminimalkan.

Contoh penyebaran aktif/aktif

Dalam penyebaran aktif/aktif, dua set server aplikasi dibangun di dua zona. Dalam setiap zona, dua di setiap set server aplikasi tidak aktif (dimatikan). Akibatnya, ada server aplikasi aktif di kedua zona dalam operasi normal.

ASCS dan layanan database berjalan di zona 1. Server aplikasi di zona 2 mungkin memiliki latensi jaringan yang lebih lama saat menyambung ke ASCS dan layanan database karena jarak fisik antar-zona.

Jika zona 1 offline, ASCS dan layanan database akan melakukan failover ke zona 2. Server aplikasi yang tidak aktif dapat dibuat online guna menyediakan kapasitas penuh untuk pemrosesan aplikasi.

Pemulihan dari bencana

Setiap tingkat dalam tumpukan aplikasi SAP menggunakan pendekatan yang berbeda untuk memberikan perlindungan DR.

Tingkat server aplikasi

Server aplikasi SAP tidak berisi data bisnis. Di Azure, strategi DR sederhana adalah dengan membuat server aplikasi SAP di wilayah sekunder, lalu mematikannya. Setelah perubahan konfigurasi atau pembaruan kernel pada server aplikasi utama, perubahan yang sama harus diterapkan pada mesin virtual di kawasan sekunder. Misalnya, salin file kernel SAP yang dapat dieksekusi ke mesin virtual DR.

Azure Site Recovery juga dapat digunakan untuk menyiapkan DR untuk penyebaran aplikasi SAP NetWeaver multi-tingkat.

Layanan Pusat

Komponen tumpukan aplikasi SAP ini juga tidak mempertahankan data bisnis. Anda dapat membangun mesin virtual di wilayah DR untuk menjalankan peran Layanan Pusat.

File host global ASCS, yaitu berbagi /sapmnt, biasanya dilayani oleh kluster NFS yang sangat tersedia atau Azure NetApp Files. Untuk melindungi konten ini, salin ke layanan file jarak jauh (NFS atau Azure NetApp Files) yang menyediakan berbagi /sapmnt ke sistem DR SAP. Gunakan Rsync atau alat penyalinan file apa pun yang andal.

Azure Site Recovery mendukung replikasi perangkat STONITH yang dibuat dengan target iSCSI.

Untuk mereplikasi dua drive sistem operasi dari server Layanan Pusat ke wilayah DR, Anda dapat menggunakan Azure Site Recovery.

Untuk panduan langkah demi langkah, lihat Membangun Solusi Pemulihan Bencana untuk SAP menggunakan Azure Site Recovery.

Tingkat database

Gunakan HSR untuk replikasi yang didukung HANA. Selain penyiapan ketersediaan tinggi dua node lokal, HSR mendukung replikasi multi-tingkat di mana node ketiga di wilayah Azure terpisah bertindak sebagai entitas asing, bukan bagian dari kluster, dan mendaftar ke replika sekunder dari pasangan HSR yang dikluster sebagai target replikasinya. Ini membentuk daisy chain replikasi.

Failover ke node DR adalah proses manual. Karena HANA 2.0 SPS 03, dimungkinkan untuk mengonfigurasi replikasi sistem multi-target, yang mendukung replika tambahan dengan mereplikasi simpul utama di wilayah DR secara asinkron. Selain itu, jika menggunakan Azure NetApp Files untuk Layanan Pusat atau lapisan database HANA, gunakan rsync atau alat replikasi konten pilihan.

DR untuk layanan bersama

Banyak layanan TI yang digunakan bersama oleh semua aset cloud yang disebarkan, seperti jumpbox administratif, layanan direktori berbasis cloud, pencadangan, dan layanan pemantauan. Replikasi layanan bersama Anda ke wilayah DR menggunakan cara apa pun yang disediakan layanan.

DR Otomatis dengan Azure Site Recovery

Untuk menggunakan Azure Site Recovery guna secara otomatis membangun situs produksi yang sepenuhnya direplikasi dari konfigurasi asli Anda, Anda harus menjalankan skrip penyebaran yang dikustomisasi. Misalnya, Site Recovery pertama-tama menyebarkan VM dalam set ketersediaan, kemudian menjalankan skrip kustom Anda untuk melampirkan penyeimbang beban (bawaan) yang sudah ada, dengan kumpulan backend yang telah ditentukan, ke NIC mesin virtual failover. Contoh skrip Runbook Automasi Site Recovery kustom tersedia di GitHub.

Pengoptimalan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya.

Untuk informasi selengkapnya, lihat bagian biaya di Microsoft Azure Well-Architected Framework.

Komputer virtual

Arsitektur ini menggunakan mesin virtual yang menjalankan Linux, untuk tingkat aplikasi dan tingkat database. Tingkat SAP NetWeaver menggunakan mesin virtual Windows untuk menjalankan layanan dan aplikasi SAP. Tingkat database menjalankan AnyDB sebagai database, seperti Microsoft SQL Server, Oracle, atau IBM DB2. Mesin virtual juga digunakan sebagai jump box untuk manajemen.

Secara umum, ada beberapa opsi pembayaran untuk mesin virtual:

Untuk beban kerja tanpa waktu penyelesaian atau konsumsi sumber daya yang dapat diprediksi, pertimbangkan opsi PAYG.

Pertimbangkan untuk menggunakan Azure Reservations jika Anda dapat berkomitmen untuk menggunakan mesin virtual selama jangka waktu satu tahun atau tiga tahun. Reservasi VM dapat mengurangi biaya hingga 72% jika dibandingkan dengan harga PAYG.

Gunakan VM Azure Spot untuk menjalankan beban kerja yang dapat diinterupsi dan tidak memerlukan penyelesaian dalam jangka waktu atau SLA yang telah ditentukan sebelumnya. Azure menyebarkan Mesin Virtual Spot jika ada kapasitas yang tersedia dan mengeluarkannya saat membutuhkan kembali kapasitas tersebut. Biaya yang terkait dengan Spot lebih rendah secara signifikan. Pertimbangkan Spot VM untuk beban kerja ini:

• Skenario komputasi berperforma tinggi, pekerjaan pemrosesan batch, atau aplikasi perenderan visual.
• Lingkungan pengujian, termasuk integrasi berkelanjutan dan beban kerja pengiriman berkelanjutan.
• Aplikasi tanpa status berskala besar.

Untuk informasi selengkapnya Harga Mesin Virtual Linux.

Mesin virtual dan kumpulan ketersediaan

Untuk semua kumpulan dan kluster (Web Dispatcher, server aplikasi SAP, Layanan Pusat, dan HANA) mesin virtual dikelompokkan ke dalam set ketersediaan yang terpisah. Tidak ada biaya untuk set ketersediaan. Anda hanya membayar untuk setiap instans VM yang Anda buat.

Azure Load Balancer

Dalam skenario ini, Azure Load Balancer digunakan untuk mendistribusikan lalu lintas ke mesin virtual di subnet tingkat aplikasi.

Anda hanya dikenakan biaya untuk jumlah aturan penyeimbangan beban dan keluar yang dikonfigurasi. Aturan NAT masuk gratis. Tidak ada biaya per jam untuk Standard Load Balancer jika tidak ada aturan yang dikonfigurasi.

Azure ExpressRoute

Dalam arsitektur ini, Azure ExpressRoute adalah layanan jaringan yang digunakan untuk membuat koneksi privat antara jaringan lokal dan jaringan virtual Azure.

Semua transfer data masuk gratis. Semua transfer data keluar dikenakan biaya berdasarkan tarif yang telah ditentukan. Lihat Harga Azure ExpressRoute Untuk info selengkapnya.

Manajemen dan operasi

Cadangan

Data SAP Hana dapat dicadangkan dengan berbagai cara. Setelah bermigrasi ke Azure, terus gunakan solusi pencadangan yang sudah Anda miliki. Azure menyediakan dua pendekatan native untuk pencadangan. Anda dapat mencadangkan SAP Hana di komputer virtual atau menggunakan Azure Backup di tingkat file. Azure Backup BackInt disertifikasi oleh SAP. Lihat juga FAQ Azure Backup.

Manajemen identitas

Gunakan sistem manajemen identitas terpusat untuk mengontrol akses ke sumber daya di semua tingkatan:

• Memberikan akses ke sumber daya Azure melalui kontrol akses berbasis peran Azure (RBAC Azure).

• Memberikan akses ke mesin virtual Azure melalui LDAP, Azure Active Directory, Kerberos, atau sistem lain.

• Dukung akses dalam aplikasi itu sendiri melalui layanan yang disediakan SAP, atau menggunakan OAuth 2.0 dan Azure Active Directory.

Pemantauan

Untuk memaksimalkan ketersediaan dan performa aplikasi dan layanan, gunakan Azure Monitor, sebuah solusi komprehensif untuk mengumpulkan, menganalisis, dan bertindak berdasarkan telemetri dari lingkungan cloud dan lokal Anda. Azure Monitor menunjukkan bagaimana performa aplikasi dan secara proaktif mengidentifikasi masalah yang memengaruhi mereka serta sumber daya yang mereka andalkan.

Untuk menyediakan pemantauan berbasis SAP atas sumber daya dan performa layanan infrastruktur SAP, ekstensi Azure SAP Enhanced Monitoring digunakan. Ekstensi ini memasukkan statistik pemantauan Azure ke dalam aplikasi SAP untuk pemantauan sistem operasi dan fungsi DBA Cockpit. Pemantauan yang ditingkatkan SAP adalah prasyarat wajib untuk menjalankan SAP di Azure. Untuk detailnya, lihat Catatan SAP 2191498 – "SAP di Linux dengan Azure: Pemantauan yang Ditingkatkan". (Diperlukan akun SAP Service Marketplace untuk mengaksesnya)

Keamanan

SAP memiliki Users Management Engine (UME) sendiri untuk mengontrol akses dan otorisasi berbasis peran dalam aplikasi dan database SAP. Untuk detailnya, lihat Keamanan SAP Hana: Ikhtisar.

Untuk keamanan jaringan tambahan, pertimbangkan untuk mengimplementasikan DMZ jaringan, yang menggunakan appliance virtual jaringan guna membuat firewall di depan subnet untuk kluster Web Dispatcher dan Fiori Front-End Server.

Untuk keamanan infrastruktur, data dienkripsi saat transit dan saat tidak aktif. Bagian "Pertimbangan keamanan" dari SAP NetWeaver di Azure Virtual Machines–Panduan Perencanaan dan Implementasi mulai membahas keamanan jaringan dan berlaku untuk S/4HANA. Panduan ini juga menentukan port jaringan yang harus Anda buka di firewall untuk memungkinkan komunikasi aplikasi.

Untuk mengenkripsi disk komputer virtual Linux, Anda memiliki berbagai pilihan, seperti yang dijelaskan dalam Gambaran Umum Enkripsi Disk. Untuk enkripsi data SAP Hana nonaktif, sebaiknya gunakan teknologi enkripsi asli SAP Hana. Untuk dukungan Azure Disk Encryption pada distro/versi/gambar Linux tertentu, periksa dokumen Azure Disk Encryption untuk VM Linux.

Untuk enkripsi data SAP Hana nonaktif, sebaiknya gunakan teknologi enkripsi asli SAP Hana.

Komunitas

Komunitas dapat menjawab pertanyaan dan membantu Anda menyiapkan penyebaran yang berhasil. Pertimbangkan hal berikut:

• Menjalankan Aplikasi SAP di Blog Platform Microsoft

• Dukungan Komunitas Azure

• Komunitas SAP

• Stack Overflow SAP

Kontributor

Artikel ini dikelola oleh Microsoft. Awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Ben Trinh | Arsitek Utama

Kontributor lainnya:

• Mick Alberts | Penulis Teknis

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Lihat artikel berikut untuk informasi selengkapnya dan contoh beban kerja SAP yang menggunakan beberapa teknologi yang sama:

• Menyebarkan SAP S/4HANA atau BW/4HANA di Azure

• Perencanaan dan penerapan Microsoft Azure Virtual Machines Azure untuk SAP NetWeaver

• Menggunakan Azure untuk melakukan hosting dan menjalankan skenario beban kerja SAP

Sumber daya terkait

• Menjalankan beban kerja produksi SAP menggunakan Oracle Database di Azure

• Lingkungan pengembangan/pengujian untuk beban kerja SAP di Azure