SAP S/4HANA Linux on Azure

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

Sistem

Unduh file Visio arsitektur ini.

Panduan ini menjelaskan sistem produksi umum. Arsitektur ini disebarkan dengan ukuran komputer virtual (VM) yang dapat Anda ubah untuk mengakomodasi kebutuhan organisasi Anda. Agar sesuai dengan kebutuhan bisnis Anda, Anda dapat mengurangi konfigurasi ini ke satu VM.

Dalam panduan ini, tata letak jaringan sangat disederhanakan untuk menunjukkan prinsip arsitektur. Hal ini tidak dimaksudkan untuk menggambarkan jaringan perusahaan secara penuh.

Arsitektur menggunakan komponen berikut. Beberapa layanan bersama bersifat opsional.

Azure Jaringan Virtual. Layanan Virtual Network menghubungkan sumber daya Azure dengan aman satu sama lain. 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 diserekan bersama-sama. Topologi ini menawarkan 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 diterapkan dalam satu wilayah. Subnet terpisah digunakan untuk setiap aplikasi tingkat (SAP NetWeaver), database, dan untuk layanan bersama, seperti jump box dan Windows Server Active Directory.

Mesin Virtual. Arsitektur ini menggunakan VM yang menjalankan Linux untuk tingkat aplikasi dan tingkat database, yang dikelompokkan 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 ketersediaan tinggi Layanan Pusat di Azure yang berjalan di VM Linux, layanan berbagi file jaringan yang sangat tersedia diperlukan, seperti berbagi file NFS di Azure Files, Azure NetApp Files, server Network File System (NFS) berkluster, 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) 15 SP1 dan versi yang lebih baru atau SLES untuk Aplikasi SAP, Anda dapat menggunakan disk bersama Azure pada kluster Pacemaker untuk mencapai ketersediaan tinggi.

• SAP Hana. Tingkat database menggunakan dua atau beberapa VM Linux dalam kluster untuk mencapai ketersediaan tinggi dalam penyebaran peningkatan skala. Replikasi sistem HANA (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 bahwa sistem yang gagal diisolasi atau dimatikan untuk menghindari kondisi split-brain kluster. Dalam penyebaran peluasan skala HANA, Anda dapat mencapai ketersediaan tinggi database dengan menggunakan salah satu opsi berikut:

  • Konfigurasikan simpul siaga HANA dengan menggunakan Azure NetApp Files tanpa komponen pengklusteran Linux.
  • Peluasan skala tanpa simpul siaga dengan menggunakan penyimpanan premium Azure. Gunakan pengklusteran Linux untuk failover.

• Azure Bastion. Layanan ini memungkinkan Anda terhubung ke komputer virtual dengan menggunakan browser dan portal Azure, atau melalui klien SSH atau RDP asli yang sudah diinstal di komputer lokal Anda. Jika hanya RDP dan SSH yang digunakan untuk administrasi, Azure Bastion adalah solusi yang bagus. Jika Anda menggunakan alat manajemen lain, seperti SQL Server Management Studio atau front end SAP, gunakan jump box tradisional yang disebarkan 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 ketersediaan tinggi, kami sarankan Anda menggunakan Azure Standard Load Balancer. Perhatikan bahwa Load Balancer Standar menyediakan lapisan keamanan secara default. VM yang berada di belakang Standard Load Balancer tidak memiliki konektivitas internet keluar. 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 ketersediaan tinggi aplikasi berbasis web SAP, gunakan SAP Web Dispatcher bawaan, atau load balancer lain yang tersedia secara komersial. Dasarkan pilihan Anda pada:

• Jenis lalu lintas Anda, seperti HTTP atau SAP GUI.
• Layanan jaringan yang Anda butuhkan, seperti penghentian Secure Sockets Layer (SSL).

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

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Server Replikasi Antrean (ERS)

Kedua komponen ini dapat berbagi load balancer untuk menyederhanakan solusi.

Standard Load Balancer juga mendukung kluster SAP pengidentifikasi multi-sistem (multi-SID). Dengan kata lain, beberapa sistem SAP pada SLES atau RHEL dapat berbagi infrastruktur ketersediaan tinggi umum untuk mengurangi biaya. Sebaiknya Anda mengevaluasi penghematan biaya dan menghindari penempatan terlalu banyak sistem dalam satu kluster. Azure mendukung tidak lebih dari lima SID per kluster.

Application gateway. Azure Application Gateway adalah penyeimbang beban lalu lintas web yang dapat Anda gunakan untuk mengelola lalu lintas ke aplikasi web Anda. Load balancer tradisional beroperasi di lapisan transportasi (OSI lapisan 4 - TCP dan UDP). 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 URI atau header host. Jenis perutean ini dikenal sebagai penyeimbangan beban lapisan aplikasi (OSI layer 7). S/4HANA menawarkan layanan aplikasi web melalui Fiori. Anda dapat menyeimbangkan beban front end Fiori ini, yang terdiri dari aplikasi web, dengan menggunakan Application Gateway.

Gateway. 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, tetapi Anda juga dapat menggunakan koneksi situs-ke-situs . Untuk mengurangi latensi, ExpressRoute Global Reach dan ExpressRoute FastPath adalah opsi konektivitas yang dibahas nanti di artikel ini.

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 daripada 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 mendukung lokasi bersama, yang menempatkan VM 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 grup keamanan jaringan.

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 Disk terkelola Azure.

Rekomendasi

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

VM

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

Untuk detail tentang dukungan SAP untuk jenis Azure VM dan untuk metrik throughput (SAPS), 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 penyiapan Web Dispatcher paralel. Untuk komunikasi yang terhubung ke internet, solusi yang berdiri sendiri di jaringan perimeter adalah arsitektur yang direkomendasikan untuk memenuhi masalah keamanan. Dispatcher Web yang Disematkan di ASCS adalah opsi khusus. Jika Anda menggunakan opsi ini, pertimbangkan ukuran yang tepat karena beban kerja tambahan pada ASCS.

Server front-end Fiori (FES)

Arsitektur ini membahas banyak persyaratan dan mengasumsikan bahwa model Fiori FES yang disematkan digunakan. Semua komponen teknologi dipasang pada sistem S/4 itu sendiri, yang berarti bahwa setiap sistem S/4 memiliki launchpad Fiori sendiri. Penyiapan ketersediaan tinggi untuk model penyebaran ini adalah dari sistem S/4—tidak diperlukan pengklusteran atau VM tambahan. Untuk alasan itu, diagram arsitektur tidak menampilkan komponen FES.

Untuk deskripsi opsi penyebaran utama—baik yang disematkan atau hub, tergantung skenarionya—lihat Opsi penyebaran SAP Fiori dan rekomendasi lanskap sistem. Untuk kesederhanaan dan performa, perangkat lunak merilis antara komponen teknologi Fiori dan aplikasi S/4 digabungkan dengan erat. Penyiapan ini membuat penyebaran hub yang hanya sesuai dengan beberapa kasus penggunaan yang 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 seperti Anda melindungi tumpukan aplikasi ABAP tiga tingkat yang memiliki kemampuan kluster atau multi-host: gunakan lapisan database server siaga, lapisan ASCS berkluster dengan NFS ketersediaan tinggi 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 MICROSOFT Entra ID dengan SAML untuk autentikasi pengguna dan SSO untuk SAP Fiori.

Untuk beberapa contoh desain masuk/keluar yang menghadap internet, lihat Koneksi internet masuk dan keluar untuk SAP di Azure.

Kumpulan server aplikasi

Untuk mengelola grup masuk untuk server aplikasi ABAP, biasanya menggunakan transaksi SMLG untuk memuat pengguna masuk keseimbangan, untuk menggunakan SM61 untuk grup server batch, untuk menggunakan RZ12 untuk grup panggilan fungsi jarak jauh (RFC), dan sebagainya. Transaksi ini menggunakan kemampuan penyeimbangan beban yang ada di server pesan Layanan Pusat untuk mendistribusikan sesi masuk atau beban kerja di antara kumpulan server aplikasi SAP yang menangani GUI SAP dan lalu lintas RFC.

Klaster Layanan Pusat SAP

Anda dapat menyebarkan Layanan Pusat ke satu VM saat perjanjian tingkat layanan (SLA) ketersediaan VM instans tunggal Azure memenuhi persyaratan Anda. Namun, VM menjadi titik kegagalan tunggal (SPOF) potensial 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 lain adalah menggunakan disk bersama Azure untuk mencapai ketersediaan tinggi. Pada SLES 15 SP1 dan yang lebih baru atau SLES untuk Aplikasi SAP, Anda dapat menyiapkan kluster Pacemaker dengan menggunakan disk bersama Azure untuk Linux.

Secara bergantian, Anda dapat menggunakan berbagi file NFS 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 front-end kluster load balancer. Load Balancer mendukung beberapa IP frontend, sehingga IP virtual (VIP) Central Services dan ERS dapat dikonfigurasi ke satu load balancer.

Dukungan kluster Linux untuk penginstalan multi-SID ASCS di Azure sekarang tersedia secara umum. Berbagi kluster ketersediaan di antara beberapa sistem SAP menyederhanakan lanskap SAP.

Jaringan

Arsitektur ini menggunakan topologi hub-spoke, di mana jaringan virtual hub bertindak sebagai titik pusat konektivitas ke jaringan lokal. Spoke adalah jaringan virtual yang dipasangkan 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 (NIC)

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

Azure NIC mendukung banyak IP. Dukungan ini selaras dengan praktik yang direkomendasikan SAP untuk menggunakan nama host virtual untuk penginstalan, seperti yang diuraikan dalam catatan SAP 962955. Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.

Subnet dan kelompok keamanan jaringan

Arsitektur ini membagi ruang alamat jaringan virtual menjadi subnet. Anda dapat mengaitkan setiap subnet dengan kelompok keamanan jaringan yang menentukan kebijakan akses untuk subnet. Tempatkan server aplikasi pada subnet terpisah. Dengan demikian, Anda dapat mengamankannya dengan lebih mudah dengan mengelola kebijakan keamanan subnet daripada server individual.

Saat Anda mengaitkan grup keamanan jaringan dengan subnet, grup keamanan jaringan berlaku untuk semua server dalam subnet dan menawarkan kontrol terperintah atas server. Siapkan grup keamanan jaringan dengan menggunakan portal 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 latensi yang lebih rendah. Teknologi ini adalah peering rute Border Gateway Protocol (BGP) yang disiapkan antara dua atau beberapa sirkuit ExpressRoute untuk menjenjang dua domain perutean ExpressRoute. Global Reach menurunkan latensi saat lalu lintas jaringan melintasi lebih dari satu sirkuit ExpressRoute. Saat ini hanya tersedia untuk peering privat di sirkuit ExpressRoute.

Saat ini tidak ada daftar kontrol akses jaringan atau atribut lain yang dapat diubah di Jangkauan Global. Jadi semua rute yang dipelajari oleh sirkuit ExpressRoute tertentu (dari lokal dan Azure) diiklankan di seluruh sirkuit yang melakukan peering ke sirkuit ExpressRoute lainnya. Sebaiknya Anda membuat pemfilteran lalu lintas lokal untuk membatasi akses ke sumber daya.

ExpressRoute FastPath

FastPath mengimplementasikan pertukaran Microsoft Edge di titik masuk jaringan Azure. FastPath mengurangi hop jaringan untuk sebagian besar paket data. Akibatnya, FastPath menurunkan 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 lain di-peering dengan jaringan yang terhubung ke ExpressRoute, lalu lintas jaringan dari jaringan lokal Anda ke jaringan virtual spoke lainnya akan dikirim ke gateway jaringan virtual. Solusinya adalah menghubungkan semua jaringan virtual ke sirkuit ExpressRoute secara langsung.

Penyeimbang muatan

SAP Web Dispatcher menangani penyeimbangan beban lalu lintas HTTP (S) ke kumpulan server aplikasi SAP. Penyeimbang muatan perangkat lunak ini menawarkan layanan lapisan aplikasi (disebut 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 IP sumber, port sumber, 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. Sebaiknya Anda menggunakan Azure Standard Load Balancer untuk semua skenario SAP. Penting untuk dicatat bahwa Load Balancer Standar aman secara default, dan tidak ada VM di belakang Standard Load Balancer 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 DIAG atau RFC, server pesan Layanan Pusat 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, seperti yang dinyatakan dalam catatan SAP 1928533, sebaiknya gunakan disk terkelola Azure premium atau Azure NetApp Files dalam semua kasus. 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 apa pun, Anda juga dapat menggunakan disk premium P4 dan P6 yang lebih kecil untuk membantu mengelola biaya. Untuk memahami bagaimana jenis penyimpanan memengaruhi SLA ketersediaan VM, lihat SLA untuk Komputer Virtual. Untuk skenario ketersediaan tinggi, fitur disk bersama Azure tersedia di Azure Premium SSD dan Azure Ultra Disk Storage. Untuk informasi selengkapnya, lihat Disk terkelola Azure.

Anda dapat menggunakan disk bersama Azure dengan Windows Server, SLES 15 SP 1 dan yang lebih baru, atau SLES untuk SAP. Saat Anda menggunakan disk bersama Azure di kluster Linux, disk bersama Azure berfungsi sebagai perangkat blok STONITH (SBD). Ini menawarkan suara kuorum dalam situasi 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 ketersediaan untuk berbagi NFS yang dapat digunakan untuk /hana/sharedvolume , /hana/data, dan /hana/log . Untuk jaminan ketersediaan, lihat SLA untuk Azure NetApp Files. Jika Anda menggunakan berbagi NFS berbasis Azure NetApp Files untuk /hana/data volume dan /hana/log , Anda perlu menggunakan protokol NFS v4.1. /hana/shared Untuk volume, protokol NFS v3 didukung.

Untuk penyimpanan data cadangan, kami sarankan Anda menggunakan tingkat akses azure cool dan arsip. 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 pencadangan Azure NetApp Files. Untuk disk terkelola, tingkat data cadangan yang direkomendasikan adalah tingkat akses dingin atau arsip Azure.

Tingkat performa ultra Ultra Disk Storage dan Azure NetApp Files sangat mengurangi latensi disk dan menguntungkan aplikasi penting performa dan server database SAP.

Azure Premium SSD v2 dirancang untuk beban kerja kritis performa seperti SAP. Lihat Menyebarkan SSD Premium v2 untuk informasi tentang manfaat solusi penyimpanan ini dan batasannya saat ini.

Pertimbangan performa

Server aplikasi SAP berkomunikasi secara konstan dengan server database. Untuk aplikasi penting performa yang berjalan pada platform database apa pun, termasuk SAP Hana, aktifkan Akselerator Tulis untuk volume log jika Anda menggunakan SSD Premium v1. Hal ini dapat meningkatkan latensi penulisan log. 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 hyperthreading, instans VM dengan empat vCPU atau lebih mendukung Accelerated Networking.

Untuk detail tentang persyaratan performa SAP Hana, lihat catatan SAP 1943937 - Alat Pemeriksaan Konfigurasi Perangkat Keras. Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.

Untuk mencapai throughput IOPS dan bandwidth disk yang tinggi, praktik umum dalam pengoptimalan performa volume penyimpanan berlaku untuk tata letak Penyimpanan Anda. Misalnya, jika Anda menggabungkan beberapa disk untuk membuat volume disk bergaris, Anda dapat meningkatkan performa IO. Dengan mengaktifkan cache baca pada konten penyimpanan yang jarang berubah, Anda dapat meningkatkan kecepatan pengambilan data. Untuk rekomendasi tentang konfigurasi penyimpanan untuk berbagai ukuran VM saat Anda menjalankan SAP Hana, lihat Konfigurasi penyimpanan komputer virtual Azure SAP Hana.

Azure Premium SSD v2 dirancang untuk beban kerja kritis performa seperti SAP. Lihat Jenis disk terkelola Azure untuk mempelajari tentang manfaat dan batasannya serta skenario penggunaan yang optimal.

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 MB/dtk tanpa me-reboot VM Anda. Ketika Penyimpanan Disk Ultra tersedia, kami merekomendasikan Penyimpanan Disk Ultra alih-alih Akselerator Tulis.

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

Penempatan appliance virtual jaringan (NVA) antara aplikasi dan lapisan database 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, seperti yang dijelaskan nanti di artikel ini. 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 yang memenuhi kebutuhan lingkungan SAP yang paling menuntut. Untuk pertimbangan performa yang perlu diingat saat Anda menggunakan Azure NetApp Files, lihat Ukuran untuk database HANA di Azure NetApp Files.

Pertimbangan skalabilitas

Pada lapisan aplikasi SAP, Azure menawarkan 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. Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace. 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 Hana S/4 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-node untuk sebanyak 96 TB (4 x 24) untuk aplikasi pemrosesan transaksi online (OLTP). 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 Komputer Virtual. Untuk meningkatkan ketersediaan layanan di Azure, sebarkan sumber daya VM dengan Virtual Machine Scale Sets dengan orkestrasi fleksibel, zona ketersediaan, atau set ketersediaan.

Dalam penginstalan aplikasi SAP terdistribusi ini, penginstalan dasar direplikasi untuk mencapai ketersediaan tinggi. Untuk setiap lapisan arsitektur, desain ketersediaan tinggi dapat 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 (FD=1), zona ketersediaan, dan set ketersediaan, untuk meningkatkan ketersediaan sumber daya. Untuk mendapatkan pemahaman komprehensif tentang opsi penyebaran yang tersedia dan penerapannya di berbagai wilayah Azure (termasuk di seluruh zona, dalam satu zona, atau di wilayah tanpa zona), lihat Arsitektur dan skenario ketersediaan tinggi untuk SAP NetWeaver.

Web Dispatcher di tingkat server aplikasi

Anda dapat mencapai ketersediaan tinggi dengan menggunakan instans Web Dispatcher yang berlebihan. Untuk informasi selengkapnya, lihat SAP Web Dispatcher dalam dokumentasi SAP. Tingkat ketersediaan tergantung pada ukuran aplikasi yang berada di belakang Web Dispatcher. Dalam penyebaran kecil dengan beberapa masalah skalabilitas, Anda dapat menemukan Web Dispatcher bersama dengan VM ASCS. Dengan cara ini, Anda menghemat pemeliharaan OS independen dan mendapatkan ketersediaan tinggi secara bersamaan.

Layanan Pusat di tingkat server aplikasi

Untuk ketersediaan tinggi Central Services di Azure Linux VM, gunakan ekstensi ketersediaan tinggi yang sesuai untuk distribusi Linux yang dipilih. Ini adalah kebiasaan untuk menempatkan sistem file bersama pada penyimpanan NFS yang sangat tersedia dengan menggunakan SUSE DRBD 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 sebagai gantinya. Sebagai catatan, berbagi Azure NetApp Files dapat menghosting data SAP Hana dan file log. Penyiapan ini memungkinkan model penyebaran peluasan skala HANA dengan simpul siaga, sementara NFS melalui Azure Files baik untuk berbagi file non-database yang sangat tersedia.

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

Azure NetApp Files mendukung ketersediaan ASCS yang tinggi di SLES. Untuk informasi terperinci tentang ASCS tentang ketersediaan tinggi RHEL, lihat SIOS Protection Suite untuk Linux.

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

Opsi lain adalah menggunakan disk bersama Azure untuk mencapai ketersediaan tinggi. Pada SLES 15 SP 1 dan yang lebih baru atau SLES untuk SAP, Anda dapat menyiapkan kluster Pacemaker dengan menggunakan disk bersama Azure untuk mencapai ketersediaan tinggi.

Di Azure Standard Load Balancer, Anda dapat mengaktifkan port ketersediaan tinggi dan menghindari kebutuhan untuk mengonfigurasi aturan penyeimbangan beban untuk banyak port SAP. Secara umum, jika Anda mengaktifkan fitur pengembalian server langsung (DSR) saat Anda menyiapkan load balancer, respons server terhadap pertanyaan klien dapat melewati load balancer. Fitur ini juga dikenal sebagai IP Mengambang. Penyeimbang beban dapat berada di tempat atau di Azure. Sambungan langsung ini menjaga penyeimbang beban agar tidak menjadi penyempitan di jalur transmisi data. Untuk kluster ASCS dan HANA DB, kami sarankan Anda mengaktifkan DSR. Jika VM di kumpulan back-end memerlukan konektivitas keluar publik, diperlukan lebih banyak konfigurasi .

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 di tingkat server aplikasi

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

Tingkat ASCS

Seperti halnya lapisan server aplikasi, solusi ketersediaan tinggi HANA yang umum disebarkan untuk Linux adalah Pacemaker.

Tingkat database

Arsitektur dalam panduan ini menggambarkan sistem database SAP Hana yang sangat tersedia yang terdiri dari dua Azure VM. Fitur replikasi sistem asli dari tingkat database 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 ketersediaan tinggi (HAE) HSR dan Linux 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.

Menyebarkan VM di seluruh zona ketersediaan

Zona ketersediaan dapat meningkatkan ketersediaan layanan. Zona merujuk ke lokasi yang terpisah 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 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.

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 (jenis VM) yang sama 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. Mereka diaktifkan hanya ketika diperlukan.

Kluster dua node untuk Layanan Pusat dan database membentang 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 tidak aktif, atau 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 ketika terhubung ke ASCS dan layanan database karena jarak fisik antar zona.

Jika zona 1 offline, layanan ASCS dan database gagal ke zona 2. Server aplikasi yang tidak aktif dapat dibuat online guna 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 detail implementasi, lihat Gambaran umum pemulihan bencana dan panduan infrastruktur untuk beban kerja SAP dan Panduan pemulihan bencana untuk aplikasi SAP.

Pertimbangan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya.

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

VM

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

Ada beberapa opsi pembayaran untuk VM secara umum:

• Untuk beban kerja tanpa 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 mungkin membayar sedikitnya 72 persen dari biaya layanan bayar sesuai pemakaian.

• 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 yang terkait dengan VM spot lebih rendah daripada untuk VM lain. 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 bayar sesuai penggunaan sehingga Anda dapat mengelola biaya di seluruh beban kerja yang dapat diprediksi dan variabel. Untuk informasi selengkapnya tentang penawaran ini, lihat Azure Reserved Virtual Machine Instances.

Untuk gambaran umum harga, lihat Harga Komputer Virtual Linux.

Load Balancer

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 (NAT) 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 dikenakan biaya berdasarkan tarif yang telah ditentukan. Untuk informasi selengkapnya, lihat Harga Azure ExpressRoute.

Pertimbangan manajemen dan operasi

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

Solusi Azure Center for 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. Selain itu, 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 membantu Anda mengotomatiskan penginstalan perangkat lunak SAP sesuai dengan praktik terbaik Microsoft. Anda dapat memanfaatkan kemampuan manajemen untuk sistem SAP berbasis Azure baru maupun lama. Untuk informasi selengkapnya, lihat Azure Center untuk solusi SAP.

Cadangan

Anda dapat mencadangkan data SAP Hana dalam banyak hal. Setelah Anda bermigrasi ke Azure, lanjutkan menggunakan solusi cadangan yang ada yang Anda miliki. Azure menyediakan dua pendekatan native untuk pencadangan. Anda dapat mencadangkan SAP Hana di VM atau menggunakan Azure Backup di 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.

Pengelolaan 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).

• Berikan akses ke Azure VM melalui Lightweight Directory Access Protocol (LDAP), 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, 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 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 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. Biaya transfer data adalah alasan untuk menempatkan server front-end aktif yang menjalankan aplikasi Fiori di jaringan virtual yang sama dengan sistem S/4. Alternatifnya adalah menempatkannya di jaringan perimeter dan menghubungkannya ke S/4 melalui peering jaringan virtual.

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 berisi informasi tentang keamanan jaringan yang berlaku untuk S/4HANA. Panduan itu juga menentukan port jaringan untuk dibuka pada firewall untuk memungkinkan komunikasi aplikasi.

Untuk mengenkripsi disk VM Linux, Anda memiliki berbagai pilihan, seperti yang dijelaskan dalam Gambaran umum enkripsi Disk. Untuk enkripsi data SAP Hana saat tidak aktif, kami sarankan Anda menggunakan teknologi enkripsi asli SAP Hana. Untuk dukungan enkripsi disk Azure pada distribusi, versi, dan gambar Linux tertentu, lihat Enkripsi disk Azure untuk VM Linux.

Untuk enkripsi data SAP Hana saat tidak aktif, kami sarankan Anda menggunakan teknologi enkripsi asli SAP Hana.

Komunitas

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

• Menjalankan Aplikasi SAP di Blog Platform Microsoft
• Dukungan Komunitas Azure
• Komunitas SAP
• SAP Stack Overflow

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Ben Trinh | Arsitek Utama

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

Langkah berikutnya

Untuk informasi selengkapnya dan untuk 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
• Perencanaan dan implementasi Azure Virtual Machines untuk SAP NetWeaver
• Menggunakan Azure untuk menghosting dan menjalankan skenario beban kerja SAP

Sumber daya terkait

• Menjalankan beban kerja produksi SAP menggunakan Oracle Database di Azure