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.

Arsitektur

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 Virtual Network. 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 diimplementasikan 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. Tingkat ini mencakup kumpulan server front-end Fiori, kumpulan SAP Web Dispatcher, kumpulan server aplikasi, dan kluster SAP Central Services. 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) 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 di 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.

• Jump box/host bastion. Jump box, yang juga disebut host bastion, adalah VM aman di jaringan yang Anda gunakan untuk terhubung ke VM lain. Ini biasanya disebarkan sebagai bagian dari layanan bersama, seperti pengendali domain dan layanan cadangan. Jump box disebarkan pada VM untuk mendukung SAP Hana Studio, SAPGUI, transfer file, dan fungsi lain yang umumnya digunakan untuk tujuan penginstalan dan administratif. 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. Jika Anda menggunakan alat manajemen lain, seperti SQL Server Management Studio atau SAP Front End, 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. Penting untuk dicatat bahwa Load Balancer Standar aman secara default, dan tidak ada VM yang berada di belakang Standard Load Balancer memiliki konektivitas internet keluar. Untuk mengaktifkan internet keluar di VM, Anda harus memperbarui konfigurasi Load Balancer Standar Anda. 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 Enqeue (ERS)

Kedua komponen ini dapat berbagi load balancer untuk menyederhanakan solusi.

Standard Load Balancer juga mendukung kluster SAP pengidentifikasi multi-keamanan (multi-SID). Dengan kata lain, beberapa sistem SAP pada SLES atau RHEL dapat berbagi infrastruktur ketersediaan tinggi umum untuk mengurangi biaya. Kami menyarankan agar Anda mengevaluasi penghematan biaya dan menghindari penempatan terlalu banyak sistem dalam satu kluster. Azure mendukung tidak lebih dari 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. Load balancer tradisional beroperasi pada 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.

Set ketersediaan. VM untuk semua kumpulan dan kluster (Web Dispatcher, server aplikasi SAP, Central Services, dan HANA) dikelompokkan ke dalam set ketersediaan terpisah. Setidaknya dua VM disediakan per peran. Set ketersediaan meningkatkan ketersediaan aplikasi dan VM. Dengan mengelola kesalahan sistem host dan peristiwa pemeliharaan, set ketersediaan 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 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 maya (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 mendetail 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

Dalam kumpulan dan kluster server aplikasi, sesuaikan jumlah VM berdasarkan kebutuhan Anda. Untuk informasi terperinci tentang menjalankan SAP NetWeaver di 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 Marketplace Layanan SAP. Untuk daftar Azure VM 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. Embedded Web Dispatcher di ASCS adalah opsi khusus. Jika Anda menggunakan opsi ini, pertimbangkan ukuran yang tepat karena beban kerja tambahan di 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 tersemat atau hub, tergantung pada skenarionya—lihat Opsi penyebaran SAP Fiori dan rekomendasi lanskap sistem. Untuk kesederhanaan dan performa, rilis perangkat lunak antara komponen teknologi Fiori dan aplikasi S/4 digabungkan dengan erat. Penyiapan ini membuat penyebaran hub yang hanya cocok 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 terkluster atau multi-host: gunakan lapisan database server siaga, lapisan ASCS terkluster dengan NFS ketersediaan tinggi untuk penyimpanan bersama, dan setidaknya dua server aplikasi. Lalu lintas diseimbangkan 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 Azure AD 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 atau beban kerja yang masuk di antara kumpulan server aplikasi SAP yang menangani GUI SAP dan lalu lintas RFC.

Kluster SAP Central Services

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 dari penyeimbang beban. 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.

Set ketersediaan

Set ketersediaan mendistribusikan server ke infrastruktur fisik yang berbeda dan memperbarui grup untuk meningkatkan ketersediaan layanan. Masukkan VM yang melakukan peran yang sama ke dalam set ketersediaan yang sama. Penyiapan semacam itu membantu melindungi dari waktu henti yang disebabkan oleh pemeliharaan infrastruktur Azure. Ini juga membantu memenuhi SLA. Untuk memenuhi SLA yang lebih tinggi, Anda harus memiliki dua VM atau lebih per set ketersediaan.

Semua VM dalam satu set harus melakukan peran yang sama. Jangan mencampur server dengan peran yang berbeda dalam set ketersediaan yang sama. Misalnya, jangan menempatkan simpul ASCS dalam set ketersediaan yang sama dengan server aplikasi.

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

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 Marketplace Layanan SAP.

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 mendetail 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 sirkuit ExpressRoute atau lebih untuk menjenjang dua domain perutean ExpressRoute. Jangkauan Global 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.

Load balancer

SAP Web Dispatcher menangani penyeimbangan beban lalu lintas HTTP ke kumpulan server aplikasi SAP. Load balancer 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 Central Services menyeimbangkan beban melalui grup masuk server aplikasi SAP. Tidak diperlukan load balancer 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 Virtual Machines. 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 partisi 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.

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

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 Write Accelerator untuk volume log untuk meningkatkan latensi tulis log. Write Accelerator tersedia untuk mesin virtual seri M.

Untuk mengoptimalkan komunikasi antar-server, gunakan Jaringan yang Dipercepat. Opsi ini hanya tersedia untuk VM 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. Untuk mengakses catatan SAP, Anda memerlukan akun Marketplace Layanan SAP.

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 SAP Hana Azure.

Ultra Disk Storage adalah penyimpanan generasi baru yang memenuhi IOPS intensif dan tuntutan bandwidth transfer aplikasi seperti SAP Hana. Anda dapat secara dinamis mengubah performa disk ultra 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.

Kami menyarankan agar Anda tidak menempatkan appliance virtual jaringan (NVA) antara aplikasi dan lapisan database tumpukan aplikasi SAP apa pun. NVA membutuhkan banyak 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 meluaskan skala. Untuk daftar inklusif, lihat "Aplikasi SAP di Azure: Produk yang Didukung dan jenis Azure VM" di SAP Note 1928533. Untuk mengakses catatan SAP, Anda memerlukan akun Marketplace Layanan SAP. 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 12 terabyte (TB) dalam satu instans. Jika beban kerja Anda melebihi ukuran VM maksimum, Anda dapat menggunakan Instans Besar Azure untuk SAP Hana, opsi yang jauh melebihi kapasitas RAM 12 TB. Revisi 4 instans server fisik ini berada di pusat data Microsoft Azure. Mereka 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).

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 Virtual Machines. Saat Anda menyebarkan sumber daya redundan dalam set ketersediaan atau di seluruh zona ketersediaan, ketersediaan layanan 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

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 Layanan Pusat 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 hemat biaya atau kuat lainnya seperti NFS melalui Azure Files atau Azure NetApp Files sebagai gantinya. Sebagai catatan sampingan, Azure NetApp Files berbagi 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 sangat tersedia seperti /sapmnt, /saptrans dalam penginstalan SAP.

Azure NetApp Files mendukung ketersediaan ASCS yang tinggi pada 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. Koneksi langsung ini menjaga load balancer agar tidak menjadi hambatan 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 Central Services menyeimbangkan beban dengan menggunakan grup masuk server aplikasi SAP. Tidak diperlukan load balancer tambahan.

Server aplikasi di tingkat server aplikasi

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

Tingkat database

Arsitektur dalam panduan ini menggambarkan sistem database SAP Hana dengan ketersediaan tinggi 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 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.
• Seperti halnya lapisan server aplikasi, solusi ketersediaan tinggi HANA yang umum disebarkan untuk SLES adalah Pacemaker. Untuk RHEL, ini SIOS LifeKeeper.

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 yang 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, ASCS dan layanan 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.

Tingkat server aplikasi

Server aplikasi SAP tidak berisi data bisnis. Di Azure, strategi DR sederhana adalah membuat server aplikasi SAP di wilayah sekunder lalu mematikannya. Ketika ada perubahan konfigurasi atau pembaruan kernel di server aplikasi utama, perubahan yang sama harus diterapkan ke VM di wilayah sekunder. Misalnya, Anda perlu menyalin executable kernel SAP ke VM DR.

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

Layanan Pusat

Seperti server aplikasi, komponen tumpukan aplikasi SAP ini juga tidak mempertahankan data bisnis. Anda dapat membangun VM di wilayah DR untuk menjalankan peran Layanan Pusat.

File host global ASCS, yaitu /sapmnt berbagi, biasanya dilayani oleh NFS melalui Azure Files atau Azure NetApp Files. Untuk melindungi konten ini saat Anda menggunakan NFS melalui Azure Files, gunakan skrip replikasi kustom, seperti rsync. Skrip ini berjalan secara terjadwal dengan menyalin konten ke berbagi file lain di wilayah DR. Saat Anda menggunakan Azure NetApp Files, gunakan fitur replikasi lintas wilayah aslinya untuk mereplikasi konten untuk /sapmnt berbagi sistem DR SAP.

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

Untuk mereplikasi dua drive sistem operasi server Central Services ke wilayah DR, Anda dapat menggunakan 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 pengaturan ketersediaan tinggi dua node lokal, HSR mendukung replikasi multi-tingkat di mana simpul ketiga di wilayah Azure terpisah bertindak sebagai entitas asing, bukan bagian dari kluster. Simpul ketiga itu mendaftar dengan replika sekunder dari pasangan HSR terkluster sebagai target replikasinya. Penyiapan ini membentuk rantai daisy replikasi.

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

DR untuk layanan bersama

Banyak layanan TI dibagikan oleh semua aset cloud yang Anda sebarkan, seperti jump box administratif, layanan direktori berbasis cloud, layanan cadangan, dan layanan pemantauan. Replikasikan layanan bersama Anda ke wilayah DR dengan menggunakan cara apa pun yang disediakan layanan.

DR otomatis dengan Site Recovery

Untuk menggunakan Site Recovery untuk secara otomatis membangun situs produksi yang sepenuhnya direplikasi dari konfigurasi asli Anda, Anda harus menjalankan skrip penyebaran yang disesuaikan. Misalnya, Site Recovery terlebih dahulu menyebarkan VM dalam set ketersediaan. Kemudian menjalankan skrip kustom Anda untuk melampirkan load balancer yang ada (bawaan), yang sudah memiliki kumpulan back-end yang ditentukan, ke NIC VM failover. Misalnya di GitHub skrip runbook automasi Site Recovery kustom, lihat Azure Site Recovery Runbooks.

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 tingkat aplikasi dan tingkat database. Tingkat SAP NetWeaver menggunakan VM Windows untuk menjalankan layanan dan aplikasi SAP. Tingkat database menjalankan AnyDB sebagai database, seperti Microsoft SQL Server, Oracle, atau IBM DB2. VM juga digunakan sebagai jump box untuk manajemen.

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 prabayar.

• Gunakan VM spot Azure untuk menjalankan beban kerja yang dapat terganggu dan tidak memerlukan penyelesaian dalam jangka waktu atau SLA yang telah ditentukan sebelumnya. Azure menyebarkan VM spot saat ada kapasitas yang tersedia dan mengeluarkannya saat membutuhkan kapasitas kembali. Biaya yang terkait dengan VM spot lebih rendah daripada untuk 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

Untuk informasi selengkapnya, lihat Harga Virtual Machines Linux.

VM dan set ketersediaan

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

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.

Cadangan

Anda dapat mencadangkan data SAP Hana dalam banyak hal. Setelah Anda bermigrasi ke Azure, terus gunakan solusi pencadangan yang sudah ada yang sudah Anda miliki. Azure menyediakan dua pendekatan native untuk pencadangan. Anda dapat mencadangkan SAP Hana pada VM atau menggunakan Azure Backup di tingkat file. Azure Backup disertifikasi BackInt oleh SAP. Untuk mengetahui informasi lebih lanjut, lihat Azure Backup FAQ.

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

• Berikan akses ke Azure VM melalui Lightweight Directory Access Protocol (LDAP), Azure Active Directory (Azure AD), Kerberos, atau sistem lain.

• Mendukung akses dalam aplikasi itu sendiri melalui layanan yang disediakan SAP, atau menggunakan OAuth 2.0 dan Azure AD.

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. Monitor menunjukkan bagaimana performa aplikasi dan secara proaktif mengidentifikasi masalah yang memengaruhinya dan sumber daya yang bergantung padanya.

Untuk menyediakan pemantauan sumber daya dan performa layanan infrastruktur SAP berbasis SAP, gunakan ekstensi pemantauan yang ditingkatkan Azure SAP . Ekstensi ini memasukkan statistik pemantauan Azure ke dalam aplikasi SAP untuk pemantauan sistem operasi dan fungsi DBA Cockpit. SAP Enhanced Monitoring adalah prasyarat wajib untuk menjalankan SAP di Azure. Untuk detailnya, lihat "SAP di Linux dengan Azure: Pemantauan yang Ditingkatkan" di Catatan SAP 2191498. Untuk mengakses catatan SAP, Anda memerlukan akun Marketplace 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 tidak aktif SAP Hana, 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 tidak aktif SAP Hana, 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
• Stack Overflow SAP

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 ini:

• 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 dan pengujian untuk beban kerja SAP di Azure