SAP S/4HANA di Linux pada Azure

Panduan ini menyajikan serangkaian praktik yang terbukti untuk menjalankan S/4HANA dan Suite di HANA di lingkungan ketersediaan tinggi (HA) yang mendukung pemulihan bencana (DR) di Azure. Informasi Fiori hanya berlaku untuk aplikasi S/4HANA.

Arsitektur

Gambar berisi dua persegi besar berlabel Wilayah 1 (wilayah utama) dan Wilayah 2 (wilayah sekunder). Di dalam Wilayah 1 adalah dua bagian. Bagian pertama diberi label jaringan virtual Hub. Bagian ini memiliki subnet Gateway berlabel persegi panjang dan subnet layanan bersama berlabel persegi panjang. Jaringan lokal eksternal tersambung ke subnet gateway melalui panah solid berlabel ExpressRoute. Persegi panjang subnet Gateway berisi ikon yang mewakili gateway zona yang redundan. Persegi subnet layanan bersama berisi ikon yang mewakili Azure Bastion. Bagian kedua di Wilayah 1 diberi label jaringan virtual Spoke. Ini memiliki dua bagian. Bagian pertama diberi label Subnet lapisan aplikasi. Bagian ini memiliki empat persegi panjang berlabel kumpulan SAP Web Dispatcher, kluster Layanan Pusat SAP, kumpulan server aplikasi SAP, dan berbagi ZRS NFS/Azure Files. Tiga komponen pertama dikelompokkan bersama dan terhubung ke komputer virtual di wilayah 2. NFS/Azure Files berbagi ZRS tersambung ke ikon folder cloud di wilayah 2. Bagian kedua diberi label subnet lapisan basis data. Ini memiliki teks berisi 'replikasi HANA' dan ikon yang menggambarkan Load Balancer. Panah titik-titik menunjuk dari sini ke persegi panjang di Wilayah 2 berlabel Replika Basis Data.

Unduh file Visio arsitektur ini.

Nota

Untuk menyebarkan arsitektur ini, pastikan Anda memiliki lisensi yang diperlukan untuk produk SAP dan teknologi non-Microsoft lainnya.

Panduan ini menjelaskan sistem produksi yang khas. Arsitektur ini menggunakan berbagai ukuran komputer virtual (VM). Untuk mengakomodasi kebutuhan organisasi, Anda dapat menyesuaikan ukuran atau mengurangi konfigurasi ini ke satu VM.

Dalam panduan ini, tata letak jaringan disederhanakan untuk menunjukkan prinsip arsitektur. Ini tidak mewakili jaringan perusahaan yang lengkap.

Arsitektur menggunakan komponen berikut. Beberapa layanan bersama bersifat opsional.

Azure Virtual Network. Layanan Virtual Network menghubungkan sumber daya Azure satu sama lain dengan keamanan yang ditingkatkan. Dalam arsitektur ini, jaringan virtual terhubung ke lingkungan lokal melalui gateway yang disebarkan di hub topologi hub-spoke. Spoke adalah jaringan virtual yang digunakan untuk aplikasi SAP dan tingkat database.

Peering jaringan virtual. Arsitektur ini menggunakan beberapa jaringan virtual yang terhubung melalui peering. Topologi ini menyediakan segmentasi dan isolasi jaringan untuk layanan yang disebarkan di Azure. Peering menghubungkan jaringan secara transparan melalui jaringan backbone Microsoft dan tidak dikenakan penalti performa jika diimplementasikan dalam satu wilayah. Subnet terpisah digunakan untuk setiap tingkatan, termasuk tingkat aplikasi (SAP NetWeaver) dan tingkat database, dan untuk komponen bersama seperti jump box dan Windows Server Active Directory.

Mesin Virtual. Arsitektur ini mengatur VM yang menjalankan Linux ke dalam grup untuk tingkat aplikasi dan tingkat database dengan cara berikut:

• Tingkat aplikasi. Lapisan arsitektur ini mencakup kumpulan server front-end Fiori, kumpulan SAP Web Dispatcher, kumpulan server aplikasi, dan kluster Layanan Pusat SAP. Untuk HA Layanan Pusat di Azure yang berjalan di VM Linux, layanan berbagi file jaringan yang sangat tersedia diperlukan, seperti berbagi file Network File System (NFS) di Azure Files, Azure NetApp Files, server NFS terkluster, atau SIOS Protection Suite untuk Linux. Untuk menyiapkan berbagi file yang sangat tersedia untuk kluster Central Services di Red Hat Enterprise Linux (RHEL), Anda dapat mengonfigurasi GlusterFS pada Azure VM yang menjalankan RHEL. Pada SUSE Linux Enterprise Server (SLES) versi 15 SP1 dan yang lebih baru atau SLES untuk Aplikasi SAP, Anda dapat menggunakan disk bersama Azure pada kluster Pacemaker sebagai perangkat pemagaran untuk mencapai HA (High Availability).

• SAP HANA. Tingkat database menggunakan dua atau lebih VM Linux dalam sebuah kluster untuk mencapai ketersediaan tinggi dalam penyebaran skala naik. Replikasi sistem HANA (HSR) digunakan untuk mereplikasi konten antara sistem HANA primer dan sekunder. Pengklusteran Linux digunakan untuk mendeteksi kegagalan sistem dan memfasilitasi failover otomatis. Anda harus menggunakan mekanisme pemisahan berbasis penyimpanan atau berbasis cloud untuk membantu memastikan bahwa sistem yang gagal diisolasi atau dimatikan untuk menghindari terbelahnya kluster. Dalam penyebaran peluasan skala HANA, Anda dapat mencapai database HA dengan menggunakan salah satu opsi berikut:

  • Konfigurasikan simpul siaga HANA dengan menggunakan Azure NetApp Files tanpa komponen pengklusteran Linux.

  • Memperluas skala tanpa simpul siaga dengan menggunakan penyimpanan Premium Azure. Gunakan pengklusteran Linux untuk failover.

• Azure Bastion. Layanan ini memungkinkan Anda terhubung ke VM dengan menggunakan browser dan portal Microsoft Azure atau dengan menggunakan klien Secure Shell (SSH) atau Remote Desktop Protocol (RDP) asli yang diinstal di komputer lokal Anda. Jika hanya RDP dan SSH yang digunakan untuk administrasi, pertimbangkan untuk menggunakan Azure Bastion. Jika Anda menggunakan tools manajemen lain, seperti SQL Server Management Studio atau front end SAP, gunakan jump box tradisional yang dikelola sendiri.

Layanan DNS privat.Azure Private DNS menyediakan layanan DNS yang andal dan aman untuk jaringan virtual Anda. Azure Private DNS mengelola dan menyelesaikan nama domain di jaringan virtual tanpa harus mengonfigurasi solusi DNS kustom.

Load balancer. Untuk mendistribusikan lalu lintas ke VM di subnet tingkat aplikasi SAP untuk meningkatkan ketersediaan, gunakan Azure Standard Load Balancer. Load Balancer Standar menyediakan lapisan keamanan secara default. Mesin Virtual yang berada di belakang Standard Load Balancer tidak memiliki konektivitas internet ke luar. Untuk mengaktifkan internet keluar di VM, Anda perlu memperbarui konfigurasi Load Balancer Standar Anda. Anda juga dapat menggunakan Azure NAT Gateway untuk mendapatkan konektivitas keluar. Untuk aplikasi web SAP HA, gunakan SAP Web Dispatcher terintegrasi atau load balancer komersial lainnya. Dasarkan pilihan Anda pada:

• Jenis lalu lintas Anda, seperti lalu lintas antarmuka pengguna grafis (GUI) HTTP atau SAP.
• Fitur jaringan yang Anda butuhkan, seperti terminasi Secure Sockets Layer (SSL).

Standard Load Balancer mendukung beberapa alamat IP virtual pada front-end. Dukungan ini sangat ideal untuk implementasi kluster yang mencakup komponen berikut:

• Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)
• Mengantrekan server replikasi

Kedua komponen ini dapat berbagi load balancer untuk menyederhanakan solusi.

Load Balancer Standar juga mendukung kluster SAP dengan beberapa sistem pengenal (multi-SID). Fitur ini memungkinkan beberapa sistem SAP pada SLES atau RHEL berbagi infrastruktur HA umum untuk membantu mengurangi biaya. Sebaiknya Anda mengevaluasi penghematan biaya dan menghindari penempatan terlalu banyak sistem dalam satu kluster. Azure mendukung hingga lima SID per kluster.

Gateway aplikasi. Azure Application Gateway adalah penyeimbang beban lalu lintas web yang dapat Anda gunakan untuk mengelola lalu lintas ke aplikasi web Anda. Penyeimbang beban tradisional beroperasi pada lapisan transportasi, yang dikenal sebagai Open Systems Interconnection (OSI) layer 4, dengan menggunakan Protokol Kontrol Transmisi dan Protokol Datagram Pengguna. Mereka merutekan lalu lintas berdasarkan alamat IP sumber dan port ke alamat IP dan port tujuan. Application Gateway dapat membuat keputusan perutean berdasarkan atribut tambahan permintaan HTTP, seperti jalur pengidentifikasi sumber daya seragam atau header host. Jenis perutean ini dikenal sebagai penyeimbangan beban lapisan aplikasi, atau lapisan ke-7 OSI. S/4HANA menyediakan layanan aplikasi web melalui Fiori. Anda dapat menyeimbangkan beban front end Fiori ini, yang terdiri dari aplikasi web, dengan menggunakan Application Gateway. Jika Anda menggunakan alamat IP publik, pastikan mereka menggunakan SKU alamat IP Standar. Hindari SKU alamat IP Dasar karena akan dihentikan pada 30 September 2025.

Pintu Gerbang. Gateway menyambungkan jaringan yang berbeda dan memperluas jaringan lokal Anda ke jaringan virtual Azure. Azure ExpressRoute adalah layanan Azure yang direkomendasikan untuk membuat koneksi privat yang tidak melalui internet publik. Anda juga dapat menggunakan koneksi situs-ke-situs . Untuk membantu mengurangi latensi, gunakan ExpressRoute Global Reach atau ExpressRoute FastPath.

Gateway zona redundan. Anda dapat menyebarkan gateway ExpressRoute atau jaringan privat virtual (VPN) di seluruh zona untuk melindungi dari kegagalan zona. Arsitektur ini menggunakan gateway jaringan virtual zona-redundan untuk ketahanan alih-alih penyebaran zona yang didasarkan pada 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 membantu menerapkan kolokasi dengan memastikan bahwa VM disebarkan di pusat data yang sama. Konfigurasi ini mengurangi jarak fisik antar sumber daya untuk meminimalkan latensi aplikasi.

Nota

Untuk strategi konfigurasi yang diperbarui, lihat Opsi konfigurasi untuk meminimalkan latensi jaringan dengan aplikasi SAP. Artikel ini menjelaskan potensi kompromi dalam fleksibilitas penerapan saat Anda mengoptimalkan sistem SAP untuk latensi jaringan.

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

Kelompok keamanan aplikasi. Untuk menentukan kebijakan keamanan jaringan halus yang didasarkan pada beban kerja dan berpusat pada aplikasi, gunakan grup keamanan aplikasi alih-alih alamat IP eksplisit. Anda dapat mengelompokkan VM berdasarkan nama dan mengamankan aplikasi dengan memfilter lalu lintas dari segmen tepercaya jaringan Anda.

Azure Storage. Penyimpanan menyediakan persistensi data untuk VM dalam bentuk hard disk virtual. Kami menyarankan agar Anda menggunakan disk terkelola Azure.

Rekomendasi

Arsitektur ini menjelaskan penyebaran tingkat produksi yang kecil. Penyebaran bervariasi berdasarkan persyaratan bisnis, jadi pertimbangkan rekomendasi ini sebagai titik awal.

Vms

Di kumpulan dan kluster server aplikasi, sesuaikan jumlah VM berdasarkan kebutuhan Anda. Untuk informasi selengkapnya tentang cara menjalankan SAP NetWeaver di VM, lihat Panduan perencanaan dan implementasi Azure Virtual Machines. Panduan ini juga berlaku untuk penyebaran SAP S/4HANA.

Untuk informasi selengkapnya tentang dukungan SAP untuk jenis Azure VM dan untuk metrik throughput, lihat catatan SAP 1928533. Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace. Untuk daftar VM Azure bersertifikat untuk database HANA, lihat direktori perangkat keras SAP bersertifikat dan didukung SAP Hana.

SAP Web Dispatcher

Komponen Web Dispatcher digunakan untuk menyeimbangkan beban lalu lintas SAP di antara server aplikasi SAP. Untuk mencapai KETERSEDIAAN TINGGI SAP Web Dispatcher, Azure Load Balancer mengimplementasikan kluster failover atau konfigurasi paralel dari Web Dispatcher. Untuk komunikasi yang terhubung ke internet, solusi yang berdiri sendiri di jaringan perimeter adalah arsitektur yang direkomendasikan untuk memenuhi persyaratan keamanan. Embedded Web Dispatcher pada ASCS adalah konfigurasi tingkat lanjut. Jika Anda menggunakan konfigurasi ini, pertimbangkan ukuran yang tepat karena beban kerja tambahan di ASCS.

Server Front-End Fiori (FES)

Arsitektur ini memenuhi beberapa persyaratan dan mengasumsikan bahwa Anda menggunakan model FES Fiori yang disematkan. Semua komponen teknologi dipasang langsung pada sistem S/4, sehingga setiap sistem S/4 memiliki launchpad Fiori sendiri. Sistem S/4 mengelola konfigurasi ketersediaan tinggi untuk model penyebaran ini. Pendekatan ini menghilangkan kebutuhan akan pengklusteran atau VM tambahan. Untuk alasan ini, diagram arsitektur tidak menyertakan komponen FES.

Untuk informasi selengkapnya tentang opsi penyebaran, lihat Opsi penyebaran SAP Fiori dan rekomendasi lanskap sistem. Untuk kesederhanaan dan performa, versi perangkat lunak antara komponen teknologi Fiori dan aplikasi S/4 saling terkait erat. Konfigurasi ini menjadikan penyebaran hub hanya cocok untuk beberapa kasus penggunaan spesifik.

Jika Anda menggunakan penyebaran hub FES, FES adalah komponen add-on ke tumpukan ABAP SAP NetWeaver klasik. Siapkan KETERSEDIAAN TINGGI dengan cara yang sama seperti Anda melindungi tumpukan aplikasi ABAP tiga tingkat yang memiliki kemampuan terkluster atau beberapa host. Gunakan lapisan database server siaga, lapisan ASCS berkluster dengan HA NFS untuk penyimpanan bersama, dan setidaknya dua server aplikasi. Lalu lintas diseimbangkan beban melalui sepasang instans Web Dispatcher yang dapat diklusterkan atau paralel. Untuk aplikasi Fiori yang terhubung ke internet, kami merekomendasikan penyebaran hub FES di jaringan perimeter. Gunakan Azure Web Application Firewall di Application Gateway sebagai komponen penting untuk menangguhkan ancaman. Gunakan ID Microsoft Entra dengan Bahasa Markup Pernyataan Keamanan untuk autentikasi pengguna dan akses menyeluruh untuk SAP Fiori.

Gambar menunjukkan dua bagian utama yang diapit dalam persegi panjang putus-putus yang menunjukkan bahwa keduanya adalah jaringan virtual. Ada ikon yang mewakili internet. Ikon ini tersambung melalui panah dua sisi ke ikon yang mewakili navigasi web di bagian pertama. Bagian ini memiliki tiga persegi panjang. Persegi panjang pertama memiliki ikon yang mewakili Azure Web Application Firewall dan Azure Application Gateway. Persegi panjang kedua memiliki ikon yang mewakili instans SAP Web Dispatcher. Bagian ketiga memiliki ikon yang mewakili SAP Fiori. Ini juga memiliki teks yang berbunyi Hub Fiori atau Fiori Pusat. Panah menunjuk dari kotak pertama ke kotak kedua lalu dari kotak kedua ke kotak ketiga. Panah putus-putus yang diberi label Peering Jaringan Virtual menghubungkan dua jaringan virtual. Bagian utama kedua memiliki ikon yang mewakili SAP S/4HANA dan berisi teks yang bertuliskan back-end khusus atau Fiori tersemat.

Unduh file Visio arsitektur ini.

Untuk informasi selengkapnya, lihat Koneksi internet masuk dan keluar untuk SAP di Azure.

Kumpulan server aplikasi

Untuk mengelola grup masuk untuk server aplikasi ABAP, gunakan kode transaksi berikut:

• SMLG: Menyeimbangkan beban pengguna logon.
• SM61: Mengelola grup server batch.
• RZ12: Mengelola grup panggilan fungsi jarak jauh (RFC).

Transaksi ini mengandalkan kemampuan penyeimbangan beban di server pesan Layanan Pusat untuk mendistribusikan sesi masuk dan beban kerja di seluruh kumpulan server aplikasi SAP yang mengelola lalu lintas SAP GUI dan RFC.

Kluster Layanan Pusat SAP

Layanan Pusat SAP berisi satu instans server pesan dan layanan replikasi antrean. Tidak seperti proses kerja server aplikasi, komponen ini adalah titik kegagalan tunggal dalam tumpukan aplikasi SAP. Anda dapat menyebarkan Layanan Pusat ke satu VM saat perjanjian tingkat layanan (SLA) ketersediaan VM instans tunggal Azure memenuhi persyaratan Anda. Jika SLA Anda memerlukan ketersediaan yang lebih tinggi, Anda perlu menyebarkan layanan ini pada kluster HA. Untuk informasi selengkapnya, lihat Layanan Pusat di tingkat server aplikasi.

Jaringan

Arsitektur ini menggunakan topologi hub-spoke di mana jaringan virtual hub berfungsi sebagai titik pusat konektivitas ke jaringan lokal. Spoke adalah jaringan virtual yang berpasangan dengan hub. Anda dapat menggunakan spoke untuk mengisolasi beban kerja. Arus lalu lintas antara pusat data lokal dan hub melalui koneksi gateway.

Kartu antarmuka jaringan

Penyebaran SAP lokal tradisional menerapkan beberapa kartu antarmuka jaringan (NIC) per mesin untuk memisahkan lalu lintas administratif dari lalu lintas bisnis. Pada Azure, jaringan virtual adalah jaringan berbasis perangkat lunak yang merutekan semua lalu lintas melalui satu struktur jaringan. Akibatnya, Anda tidak memerlukan beberapa NIC karena alasan performa. Jika organisasi Anda perlu memisahkan lalu lintas, Anda dapat menyebarkan beberapa NIC untuk setiap VM, menghubungkan setiap NIC ke subnet yang berbeda, lalu menggunakan NSG untuk membantu menerapkan kebijakan kontrol akses yang berbeda.

NIC Azure mendukung beberapa alamat IP. Dukungan ini selaras dengan praktik yang direkomendasikan SAP untuk menggunakan nama host virtual untuk penginstalan di catatan SAP 962955.

Subnet dan NSG

Arsitektur ini membagi ruang alamat jaringan virtual menjadi subnet. Anda dapat mengaitkan setiap subnet dengan NSG yang menentukan kebijakan akses untuk subnet. Tempatkan server aplikasi pada subnet terpisah. Pendekatan ini memudahkan untuk mengamankan server aplikasi dengan mengelola kebijakan keamanan subnet alih-alih server individual.

Saat Anda mengaitkan NSG dengan subnet, NSG berlaku untuk semua server dalam subnet dan memberikan kontrol rinci atas server. Siapkan NSG dengan menggunakan portal Microsoft Azure, Azure PowerShell, atau Azure CLI.

Jangkauan Global ExpressRoute

Jika lingkungan jaringan Anda menyertakan dua sirkuit ExpressRoute atau lebih, ExpressRoute Global Reach dapat membantu Anda mengurangi hop jaringan dan mengurangi latensi. Teknologi ini adalah peering rute Border Gateway Protocol yang disiapkan antara dua atau lebih sirkuit ExpressRoute untuk menghubungkan dua domain perutean ExpressRoute. Jangkauan Global mengurangi latensi saat lalu lintas jaringan melintasi lebih dari satu sirkuit ExpressRoute. Ini hanya tersedia untuk peering privat di sirkuit ExpressRoute.

Jangkauan Global tidak mendukung perubahan pada daftar kontrol akses jaringan atau atribut lainnya. Semua rute yang dipelajari oleh sirkuit ExpressRoute, baik dari lokal (on-premises) atau Azure, disebarkan melalui peering ke sirkuit ExpressRoute lainnya. Kami menyarankan agar Anda menyiapkan pemfilteran lalu lintas jaringan lokal untuk membatasi akses ke sumber daya.

FastPath

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

Untuk sirkuit ExpressRoute yang ada, hubungi dukungan Azure untuk mengaktifkan FastPath.

FastPath tidak mendukung peering jaringan virtual. Jika jaringan virtual yang terhubung ke ExpressRoute dipasangkan dengan jaringan virtual lainnya, lalu lintas dari jaringan di tempat Anda ke jaringan virtual spoke lainnya akan dirutekan melalui gateway jaringan virtual. Untuk mengatasi masalah ini, sambungkan semua jaringan virtual langsung ke sirkuit ExpressRoute.

Penyeimbang beban

SAP Web Dispatcher menangani penyeimbangan beban lalu lintas HTTP dan HTTPS ke kumpulan server aplikasi SAP. Load balancer perangkat lunak ini menyediakan layanan lapisan aplikasi, yang dikenal sebagai lapisan 7 dalam model jaringan ISO, yang mampu menghentikan SSL dan fungsi offloading lainnya.

Load Balancer adalah layanan lapisan transmisi jaringan (lapisan 4) yang menyeimbangkan lalu lintas dengan menggunakan hash lima tuple dari aliran data. Hash didasarkan pada alamat IP sumber, port sumber, alamat IP tujuan, port tujuan, dan jenis protokol. Load Balancer digunakan dalam pengaturan kluster untuk mengarahkan lalu lintas ke instans layanan utama atau node sehat jika ada kesalahan. Kami menyarankan agar Anda menggunakan Load Balancer Standar untuk semua skenario SAP. Load Balancer Standar secara default aman, dan tidak ada VM di belakang Load Balancer Standar yang memiliki konektivitas internet keluar. Untuk mengaktifkan internet keluar di VM, Anda harus menyesuaikan konfigurasi Load Balancer Standar Anda.

Untuk lalu lintas dari klien SAP GUI yang terhubung ke server SAP melalui protokol Dynamic Information and Action Gateway (DIAG) atau RFC, server pesan Central Services menyeimbangkan beban melalui grup masuk server aplikasi SAP. Tidak diperlukan penyeimbang beban tambahan.

Penyimpanan

Beberapa pelanggan menggunakan penyimpanan standar untuk server aplikasi mereka. Karena disk terkelola standar tidak didukung, kami sarankan Anda menggunakan Azure Premium SSD atau Azure NetApp Files di semua skenario. Pembaruan terbaru untuk catatan SAP 2015553 mengecualikan penggunaan penyimpanan HDD Standar Azure dan penyimpanan Azure Standard SSD untuk beberapa kasus penggunaan tertentu.

Karena server aplikasi tidak menghosting data bisnis apa pun, Anda juga dapat menggunakan disk premium P4 dan P6 yang lebih kecil untuk membantu mengelola biaya. Untuk aplikasi SAP, kami sangat menyarankan Anda menggunakan Azure SSD v1, SSD v2, atau Ultra Disk. Untuk memahami bagaimana jenis penyimpanan memengaruhi SLA ketersediaan VM, lihat SLA untuk layanan online. Untuk skenario HA, fitur disk bersama Azure tersedia di Azure Premium SSD dan Azure Ultra Disk Storage. Untuk informasi selengkapnya, lihat Disk terkelola Azure dan jenis disk terkelola Azure.

Anda dapat menggunakan disk bersama Azure dengan Windows Server, SLES 15 Service Pack 1 (SP1) dan versi yang lebih baru, atau SLES untuk SAP. Saat Anda menggunakan disk bersama Azure di kluster Linux, disk bersama Azure berfungsi sebagai perangkat blok untuk isolasi simpul yang gagal. Ini memberikan suara kuorum dalam skenario pemartisian jaringan kluster. Disk bersama ini tidak memiliki sistem file dan tidak mendukung penulisan simultan dari beberapa VM anggota kluster.

Azure NetApp Files memiliki fungsi berbagi file bawaan untuk NFS dan SMB.

Untuk skenario berbagi NFS, Azure NetApp Files menyediakan HA untuk berbagi NFS yang dapat digunakan untuk volume /hana/shared, /hana/data, dan /hana/log. Untuk jaminan ketersediaan, lihat SLA untuk layanan online. Jika Anda menggunakan NFS berbasis Azure NetApp Files untuk volume /hana/data dan /hana/log, Anda perlu menggunakan protokol NFS v4.1. Untuk volume /hana/shared, protokol NFS v3 didukung.

Untuk penyimpanan data cadangan, kami sarankan Anda menggunakan Azure tingkat akses Cool dan Archive. Tingkat penyimpanan ini adalah cara hemat biaya untuk menyimpan data berumur panjang yang jarang diakses. Selain itu, pertimbangkan untuk menggunakan tingkat Standar Azure NetApp Files sebagai target cadangan atau opsi cadangan Azure NetApp Files. Untuk disk terkelola, tingkat data cadangan yang direkomendasikan adalah tingkat akses dingin atau arsip Azure.

Tingkat Ultra Disk Storage dan Azure NetApp Files Ultra secara signifikan mengurangi latensi disk dan meningkatkan performa aplikasi penting dan server database SAP.

Premium SSD v2 dirancang untuk beban kerja kritis performa seperti SAP. Untuk informasi selengkapnya tentang manfaat dan batasan solusi penyimpanan ini, lihat Menyebarkan SSD Premium v2.

Pertimbangan performa

Server aplikasi SAP berkomunikasi secara konstan dengan server database. Untuk aplikasi yang penting untuk performa yang berjalan pada platform database apa pun, termasuk SAP HANA, aktifkan Akselerator Tulis untuk volume log jika Anda menggunakan SSD Premium v1. Pendekatan ini dapat meningkatkan latensi log-write. SSD premium v2 tidak menggunakan Akselerator Tulis. Write Accelerator tersedia untuk mesin virtual seri M.

Untuk mengoptimalkan komunikasi antar-server, gunakan Jaringan yang Dipercepat. Sebagian besar ukuran instans VM tujuan umum dan yang dioptimalkan komputasi yang memiliki dua vCPU atau lebih mendukung Jaringan Terakselerasi. Pada instans yang mendukung hyper-threading, instans VM dengan empat vCPU atau lebih mendukung Accelerated Networking.

Anda harus mengoptimalkan tumpukan TCP/IP Linux dan buffer di antarmuka jaringan untuk mencapai performa yang konsisten. Ikuti pengaturan yang direkomendasikan Microsoft. Misalnya, Anda akan menyesuaikan item seperti:

• Parameter kernel untuk mengoptimalkan buffer memori baca dan tulis
• Bottleneck bandwidth dan pengendalian kemacetan waktu propagasi pulang-pergi (BBR)
• Sesuaikan parameter TCP untuk menghadirkan konsistensi dan throughput yang lebih baik
• Buffer antrian NIC untuk TX/RX

Untuk informasi selengkapnya tentang persyaratan performa SAP Hana, lihat catatan SAP 1943937.

Untuk mencapai operasi input/output per detik (IOPS) yang tinggi dan bandwidth throughput disk, ikuti praktik umum untuk pengoptimalan performa volume penyimpanan. Misalnya, menggabungkan beberapa disk untuk membuat volume disk bergaris dapat meningkatkan performa input/output (I/O) Anda. Mengaktifkan cache baca pada konten penyimpanan yang jarang berubah juga dapat mempercepat pengambilan data Anda. Untuk informasi selengkapnya, lihat Konfigurasi penyimpanan komputer virtual Azure SAP Hana.

Premium SSD v2 dirancang untuk beban kerja kritis performa seperti SAP. Untuk informasi selengkapnya tentang manfaat, batasan, dan skenario penggunaan optimalnya, lihat Jenis disk terkelola Azure.

Ultra Disk Storage adalah generasi penyimpanan baru yang memenuhi IOPS intensif dan tuntutan bandwidth transfer aplikasi seperti SAP Hana. Anda dapat mengubah performa disk ultra secara dinamis dan mengonfigurasi metrik secara independen seperti IOPS dan MBps tanpa me-reboot VM Anda. Kami menyarankan agar Anda menggunakan Ultra Disk Storage alih-alih Akselerator Tulis jika memungkinkan.

Beberapa aplikasi SAP memerlukan komunikasi yang sering dengan database. Karena jarak, latensi jaringan antara lapisan aplikasi dan database dapat berdampak negatif pada performa aplikasi. Grup penempatan berdekatan Azure menetapkan batasan penempatan untuk VM yang ditempatkan 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.

Penempatan appliance virtual jaringan (NVA) antara lapisan aplikasi dan database pada tumpukan aplikasi SAP apa pun tidak didukung. NVA membutuhkan sejumlah besar waktu untuk memproses paket data. Akibatnya, itu tidak dapat diterima memperlambat performa aplikasi.

Kami juga menyarankan agar Anda mempertimbangkan performa saat menyebarkan sumber daya dengan zona ketersediaan, yang dapat meningkatkan ketersediaan layanan. Pertimbangkan untuk membuat profil latensi jaringan yang jelas di antara semua zona wilayah target. Pendekatan ini membantu Anda memutuskan penempatan sumber daya untuk latensi minimum antar zona. Untuk membuat profil ini, jalankan pengujian dengan menyebarkan VM kecil di setiap zona. Alat yang direkomendasikan untuk pengujian termasuk PsPing dan Iperf. Setelah pengujian, hapus VM ini. Untuk alat uji latensi jaringan domain publik yang dapat Anda gunakan sebagai gantinya, lihat Uji latensi zona ketersediaan.

Azure NetApp Files memiliki fitur performa unik yang memungkinkan penyetelan real time untuk memenuhi kebutuhan lingkungan SAP yang paling menuntut. Untuk pertimbangan performa saat Anda menggunakan Azure NetApp Files, lihat Ukuran untuk database HANA di Azure NetApp Files.

Pertimbangan skalabilitas

Pada lapisan aplikasi SAP, Azure menyediakan berbagai ukuran VM untuk meningkatkan dan memperluas skala. Untuk daftar inklusif, lihat Aplikasi SAP di Azure: Produk yang didukung dan jenis Azure VM di catatan SAP 1928533. Lebih banyak jenis VM terus disertifikasi, sehingga Anda dapat meningkatkan atau menurunkan skala dalam penyebaran cloud yang sama.

Pada lapisan database, arsitektur ini menjalankan aplikasi SAP S/4HANA pada Azure VM yang dapat menskalakan hingga 24 terabyte (TB) dalam satu instans. Jika beban kerja Anda melebihi ukuran VM maksimum, Anda dapat menggunakan konfigurasi multi-simpul untuk sebanyak 96 TB (empat instans 24 TB) untuk aplikasi pemrosesan transaksi online. Untuk informasi selengkapnya, lihat Direktori perangkat keras SAP Hana bersertifikat dan didukung.

Pertimbangan ketersediaan

Redundansi sumber daya adalah tema umum dalam solusi infrastruktur dengan ketersediaan tinggi. Untuk SLA ketersediaan VM instans tunggal untuk berbagai jenis penyimpanan, lihat SLA untuk layanan online. Untuk meningkatkan ketersediaan layanan di Azure, sebarkan sumber daya VM dengan menggunakan Azure Virtual Machine Scale Sets, yang menyediakan orkestrasi fleksibel, zona ketersediaan, dan set ketersediaan.

Model penyebaran set ketersediaan regional Azure adalah opsi yang didukung. Namun, kami sarankan Anda mengadopsi model skala set mesin virtual dengan zona ketersediaan untuk penyebaran SAP baru guna meningkatkan ketersediaan dan fleksibilitas penyebaran.

Dalam instalasi aplikasi SAP yang terdistribusi ini, instalasi dasar direplikasi untuk mencapai tingkat ketersediaan yang tinggi. Untuk setiap lapisan arsitektur, desain HA (High Availability) bervariasi.

Pendekatan penyebaran

Di Azure, penyebaran beban kerja SAP dapat berupa regional atau zonal, tergantung pada persyaratan ketersediaan dan ketahanan aplikasi SAP. Azure menyediakan opsi penyebaran yang berbeda, seperti Virtual Machine Scale Sets dengan orkestrasi fleksibel (satu konfigurasi domain kesalahan), zona ketersediaan, dan set ketersediaan, untuk meningkatkan ketersediaan sumber daya.

Seiring dengan berkembangnya penyebaran pelanggan di Azure selama bertahun-tahun, Microsoft telah meningkatkan model penyebaran Azure VM untuk menyertakan Virtual Machine Scale Sets untuk membantu memastikan elastisitas dan ketahanan cloud. Mempertimbangkan opsi penyebaran yang tersedia, kami sangat merekomendasikan agar Anda menggunakan penyebaran zona dengan set skala fleksibel Azure untuk semua penyebaran baru. Untuk informasi selengkapnya tentang penyebaran di seluruh zona, dalam satu zona, dan di wilayah tanpa zona, lihat Arsitektur dan skenario HA untuk SAP NetWeaver.

Web Dispatcher di tingkat server aplikasi

Anda dapat mencapai High Availability (HA) dengan menggunakan instans Web Dispatcher yang redundan. Untuk informasi selengkapnya, lihat SAP Web Dispatcher. Tingkat ketersediaan tergantung pada ukuran aplikasi yang berada di belakang Web Dispatcher. Dalam penyebaran kecil yang tidak memiliki banyak kekhawatiran tentang skalabilitas, Anda dapat menempatkan Web Dispatcher bersama dengan VM ASCS. Pendekatan ini membantu Anda mengurangi biaya pemeliharaan sistem operasi independen dan memperoleh tingkat ketersediaan tinggi secara bersamaan.

Layanan Pusat di tingkat server aplikasi

Untuk HA Central Services pada VM Linux Azure, gunakan ekstensi HA yang sesuai untuk distribusi Linux yang dipilih. Ini adalah kebiasaan untuk menempatkan sistem file bersama pada penyimpanan NFS yang sangat tersedia dengan menggunakan SUSE Distributed Replicated Block Device atau Red Hat GlusterFS. Untuk menyediakan NFS yang sangat tersedia dan menghilangkan kebutuhan akan kluster NFS, Anda dapat menggunakan solusi lain yang hemat biaya atau kuat seperti NFS melalui Azure Files atau Azure NetApp Files. Azure NetApp Files dapat meng-host data dan file log SAP HANA. Penyiapan ini memungkinkan model penyebaran peluasan skala HANA dengan simpul siaga, sedangkan NFS di atas Azure Files bagus untuk berbagi file non-database dengan ketersediaan tinggi.

NFS melalui Azure Files sekarang mendukung berbagi file yang sangat tersedia untuk SLES dan RHEL. Solusi ini berfungsi dengan baik untuk berbagi file yang sangat tersedia seperti /sapmnt dan /saptrans dalam penginstalan SAP.

Azure NetApp Files mendukung Reliabilitas Tinggi ASCS pada SLES. Untuk informasi selengkapnya tentang ASCS di RHEL HA, lihat SIOS Protection Suite untuk Linux.

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

Opsi isolasi lain adalah menggunakan disk bersama Azure untuk perangkat isolasi. Pada SLES 15 SP1 atau SLES untuk SAP 15 SP1 dan yang lebih baru, Anda dapat menyiapkan kluster Pacemaker dengan menggunakan disk bersama Azure. Opsi ini sederhana dan tidak memerlukan port jaringan terbuka seperti agen pagar Azure.

Konfigurasi Pacemaker yang baru-baru ini didukung dan lebih sederhana pada SLES 15 dan yang lebih baru adalah HA SAP NetWeaver dengan pemasangan sederhana dan NFS pada SLES untuk VM Aplikasi SAP. Dalam konfigurasi ini, berbagi file SAP dikeluarkan dari manajemen kluster, yang membuatnya lebih mudah dioperasikan. Gunakan konfigurasi High Availability ini untuk semua penyebaran baru.

Untuk mengelola biaya lanskap SAP yang besar lebih lanjut, kluster Linux mendukung penginstalan multi-SID ASCS di Azure. Berbagi kluster ketersediaan di antara beberapa sistem SAP menyederhanakan lanskap SAP dan mengurangi biaya operasi.

Pada Load Balancer Standar, Anda dapat mengaktifkan port HA dan menghindari kebutuhan untuk mengonfigurasi aturan penyeimbangan beban untuk banyak port SAP. Secara umum, jika Anda mengaktifkan fitur pengembalian server langsung (DSR) saat menyiapkan load balancer, respons server terhadap pertanyaan dari klien dapat melewati load balancer. Fitur ini juga dikenal sebagai IP mengambang. Penyeimbang beban dapat berada di tempat atau di Azure. Koneksi langsung ini membuat load balancer tidak menjadi hambatan di jalur transmisi data. Untuk kluster database ASCS dan HANA, kami sarankan Anda mengaktifkan DSR. Jika VM di kumpulan back-end memerlukan konektivitas keluar publik, konfigurasi lebih lanjut diperlukan.

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

Server aplikasi pada lapisan server aplikasi

Anda dapat mencapai HA dengan menyeimbangkan beban lalu lintas dalam kumpulan server aplikasi.

Tingkat database

Arsitektur dalam panduan ini menggambarkan sistem database SAP Hana yang sangat tersedia yang terdiri dari dua Azure VM. Fitur replikasi sistem asli bawaan dari tingkat basis data menyediakan failover manual atau otomatis antara simpul yang direplikasi.

• Untuk failover manual, sebarkan lebih dari satu instans HANA dan gunakan HSR.

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

Menyebarkan VM di seluruh zona ketersediaan

Zona ketersediaan dapat meningkatkan ketersediaan layanan. Zona mengacu pada lokasi yang dipisahkan secara fisik dalam wilayah Azure tertentu. Mereka meningkatkan ketersediaan beban kerja dan melindungi layanan aplikasi dan VM dari pemadaman pusat data. VM dalam satu zona diperlakukan seolah-olah mereka berada dalam satu domain pembaruan atau kesalahan. Ketika penyebaran zona dipilih, VM di zona yang sama didistribusikan ke domain kesalahan dan peningkatan berdasarkan upaya terbaik.

Di wilayah Azure yang mendukung fitur ini, tersedia minimal tiga zona. Jarak maksimum antara pusat data di zona ini tidak dijamin. Untuk menyebarkan sistem SAP beberapa tingkat di seluruh zona, Anda harus mengetahui latensi jaringan dalam zona dan di seluruh zona yang ditargetkan dan seberapa sensitif aplikasi yang Anda sebarkan untuk latensi jaringan.

Pertimbangkan pertimbangan ini saat Anda memutuskan untuk menyebarkan sumber daya di seluruh zona ketersediaan:

• Latensi antara VM dalam satu zona
• Latensi antara VM di seluruh zona yang dipilih
• Ketersediaan layanan Azure yang sama, atau jenis VM, di zona yang dipilih

Nota

Kami tidak merekomendasikan zona ketersediaan untuk DR. Situs DR harus setidaknya 100 mil dari situs utama untuk memperhitungkan bencana alam. Jarak yang tepat antara pusat data tidak dapat dijamin.

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. Mereka diaktifkan hanya jika diperlukan.

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

Contoh penyebaran aktif/aktif

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

Layanan ASCS dan database berjalan di zona 1. Server aplikasi di zona 2 mungkin memiliki latensi jaringan yang lebih lama ketika terhubung ke ASCS dan layanan database karena jarak fisik antara zona.

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

Pertimbangan DR

Setiap tingkat dalam tumpukan aplikasi SAP menggunakan pendekatan yang berbeda untuk memberikan perlindungan DR. Untuk strategi DR dan informasi implementasi, lihat Gambaran umum DR dan panduan infrastruktur untuk beban kerja SAP dan panduan DR untuk aplikasi SAP.

Nota

Jika ada bencana regional yang menyebabkan peristiwa failover massal untuk banyak pelanggan Azure di satu wilayah, kapasitas sumber daya wilayah target tidak dijamin. Seperti semua layanan Azure, Site Recovery terus menambahkan fitur dan kemampuan. Untuk informasi terbaru tentang replikasi Azure-ke-Azure, lihat matriks dukungan.

Untuk membantu memastikan kapasitas sumber daya yang tersedia untuk wilayah DR, gunakan reservasi kapasitas sesuai permintaan. Azure memungkinkan Anda menggabungkan diskon instans cadangan dengan reservasi kapasitas Anda untuk mengurangi biaya.

Pertimbangan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya.

Untuk informasi selengkapnya, lihat Pengoptimalan biaya Azure Well-Architected Framework.

Vms

Arsitektur ini menggunakan VM yang menjalankan Linux untuk manajemen, aplikasi SAP, dan tingkat database.

Ada beberapa opsi pembayaran untuk VM:

• Untuk beban kerja yang tidak memiliki waktu penyelesaian atau konsumsi sumber daya yang dapat diprediksi, pertimbangkan opsi bayar sesuai penggunaan.

• Pertimbangkan untuk menggunakan reservasi Azure jika Anda dapat berkomitmen untuk menggunakan VM selama jangka waktu satu tahun atau tiga tahun. Reservasi VM dapat secara signifikan mengurangi biaya. Anda dapat menghemat hingga 72% dibandingkan dengan opsi bayar sesuai penggunaan.

• Gunakan Azure spot VM untuk menjalankan beban kerja yang dapat terganggu dan tidak memerlukan penyelesaian dalam jangka waktu atau SLA yang telah ditentukan. Azure menyebarkan VM spot ketika ada kapasitas yang tersedia dan mengeluarkannya saat membutuhkan kapasitas kembali. Biaya VM spot lebih rendah daripada VM lainnya. Pertimbangkan Mesin Virtual Spot untuk beban kerja berikut:

  • Skenario komputasi berkinerja tinggi, pekerjaan pemrosesan batch, atau aplikasi penyajian visual

  • Lingkungan pengujian, termasuk integrasi berkelanjutan dan beban kerja pengiriman berkelanjutan

  • Aplikasi stateless skala besar

• Azure Reserved Virtual Machine Instances dapat mengurangi total biaya kepemilikan Anda dengan menggabungkan tarif Azure Reserved Virtual Machine Instances dengan langganan prabayar sehingga Anda dapat mengelola biaya di seluruh beban kerja yang dapat diprediksi dan variabel. Untuk informasi selengkapnya, lihat Azure Reserved Virtual Machine Instances.

Untuk gambaran umum harga, lihat Harga komputer virtual Linux.

Penyeimbang Beban

Dalam skenario ini, load balancer Azure digunakan untuk mendistribusikan lalu lintas ke VM di subnet tingkat aplikasi.

Anda hanya dikenakan biaya untuk jumlah aturan penyeimbangan beban dan keluar yang dikonfigurasi. Aturan terjemahan alamat jaringan masuk gratis. Tidak ada biaya per jam untuk Load Balancer Standar saat tidak ada aturan yang dikonfigurasi.

ExpressRoute

Dalam arsitektur ini, 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 dibebankan berdasarkan tarif yang telah ditentukan. Untuk informasi selengkapnya, lihat Harga ExpressRoute.

Pertimbangan manajemen dan operasi

Untuk membantu menjaga sistem Anda tetap berjalan dalam produksi, pertimbangkan poin-poin berikut.

Azure Center untuk solusi SAP

Azure Center for SAP solutions adalah solusi menyeluruh yang memungkinkan Anda membuat dan menjalankan sistem SAP sebagai beban kerja terpadu di Azure serta menyediakan landasan inovasi yang lebih mulus. Pengalaman penyebaran terpandu solusi Azure Center for SAP menciptakan komponen komputasi, penyimpanan, dan jaringan yang diperlukan yang Anda butuhkan untuk menjalankan sistem SAP Anda. Kemudian Anda dapat mengotomatiskan penginstalan perangkat lunak SAP sesuai dengan praktik terbaik Microsoft. Anda dapat memanfaatkan kemampuan manajemen untuk sistem SAP berbasis Azure baru maupun lama.

Cadangan

Anda dapat mencadangkan data SAP HANA dalam berbagai cara. Setelah Anda bermigrasi ke Azure, terus gunakan solusi cadangan yang ada yang Anda miliki. Azure menyediakan dua pendekatan bawaan untuk pencadangan. Anda dapat mencadangkan SAP HANA pada VM atau menggunakan Azure Backup pada tingkat file. Azure Backup disertifikasi Backint oleh SAP. Untuk informasi selengkapnya, lihat FAQ Azure Backup dan matriks Dukungan untuk pencadangan database SAP Hana di Azure VM.

Nota

Hanya penyebaran kontainer tunggal atau peningkatan HANA yang mendukung rekam jepret penyimpanan Azure.

Pengelolaan identitas

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

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

• Berikan akses ke Azure VM melalui Lightweight Directory Access Protocol, Microsoft Entra ID, Kerberos, atau sistem lain.

• Mendukung akses dalam aplikasi itu sendiri melalui layanan yang disediakan SAP, atau menggunakan OAuth 2.0 dan ID Microsoft Entra.

Pemantauan

Untuk memaksimalkan ketersediaan dan performa aplikasi dan layanan di Azure, gunakan Azure Monitor. Azure Monitor adalah solusi komprehensif untuk mengumpulkan, menganalisis, dan bertindak berdasarkan telemetri dari lingkungan cloud dan lokal Anda. Azure Monitor menunjukkan bagaimana aplikasi berkinerja dan secara proaktif mengidentifikasi masalah yang memengaruhinya dan sumber daya yang bergantung padanya. Untuk aplikasi SAP yang berjalan di SAP Hana dan solusi database utama lainnya, lihat Azure Monitor untuk solusi SAP untuk mempelajari bagaimana Azure Monitor untuk SAP dapat membantu Anda mengelola ketersediaan dan performa layanan SAP.

Pertimbangan keamanan

SAP memiliki mesin manajemen pengguna sendiri untuk mengontrol akses dan otorisasi berbasis peran dalam aplikasi dan database SAP. Untuk informasi selengkapnya, lihat Gambaran umum keamanan SAP Hana.

Untuk meningkatkan keamanan jaringan, pertimbangkan untuk menggunakan jaringan perimeter yang menggunakan NVA untuk membuat firewall di depan subnet untuk Web Dispatcher dan kumpulan server front-end Fiori. Untuk meminimalkan biaya transfer data, sebarkan server front-end aktif yang menghosting aplikasi Fiori dalam jaringan virtual yang sama dengan sistem S/4. Atau, Anda dapat mengonfigurasi server front-end ini di jaringan perimeter, yang memanfaatkan peering jaringan virtual untuk membangun konektivitas dengan sistem S/4.

Untuk keamanan infrastruktur, data dienkripsi saat transit dan saat tidak aktif. Untuk informasi tentang keamanan jaringan yang berlaku untuk S/4HANA, lihat Keamanan untuk lanskap SAP Anda.

Untuk mengenkripsi disk VM Linux, Anda memiliki beberapa opsi. Untuk enkripsi data saat tidak aktif SAP Hana, kami sarankan Anda menggunakan teknologi enkripsi asli SAP Hana. Untuk dukungan enkripsi disk Azure pada distribusi, versi, dan citra Linux tertentu, lihat Azure Disk Encryption untuk Mesin Virtual Linux.

Nota

Jangan gunakan enkripsi data hana saat tidak aktif dan Azure Disk Encryption pada volume penyimpanan yang sama. Untuk HANA, gunakan enkripsi data HANA melalui enkripsi sisi server penyimpanan disk Azure. Menggunakan kunci yang dikelola pelanggan dapat memengaruhi throughput I/O.

Komunitas

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

• Menjalankan aplikasi SAP di blog platform Microsoft
• Dukungan komunitas Azure
• Komunitas SAP
• SAP Stack Overflow

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• Ben Trinh | Arsitek Utama

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

Untuk informasi selengkapnya dan contoh beban kerja SAP yang menggunakan beberapa teknologi yang sama dengan arsitektur ini, lihat artikel berikut:

• Menyebarkan SAP S/4HANA atau BW/4HANA di Azure
• Menggunakan Azure untuk menghosting dan menjalankan skenario beban kerja SAP
• Perencanaan dan implementasi Komputer Virtual untuk SAP NetWeaver

Sumber daya terkait

• Menjalankan beban kerja produksi SAP dengan menggunakan database Oracle di Azure