Menjalankan SAP NetWeaver di Windows pada Azure

Arsitektur referensi ini menunjukkan serangkaian praktik yang telah terbukti untuk menjalankan SAP NetWeaver di lingkungan Windows, di Azure, dengan ketersediaan tinggi. Database adalah AnyDB, istilah SAP untuk sistem manajemen database yang didukung (DBMS) selain SAP Hana.

Arsitektur

Diagram pertama menunjukkan SAP NetWeaver di lingkungan Windows dalam skenario set ketersediaan. Arsitektur menggunakan Azure NetApp Files untuk lapisan file berbagi dan grup penempatan kedekatan untuk meningkatkan performa:

Unduh file Visio yang menunjukkan arsitektur ini.

Diagram kedua menunjukkan SAP NetWeaver di lingkungan Windows. Zona Ketersediaan digunakan untuk meningkatkan ketahanan:

Unduh file Visio yang menunjukkan arsitektur ini.

Arsitektur referensi ini menjelaskan sistem produksi. Arsitektur ini disebarkan dengan ukuran mesin virtual (VM) tertentu yang dapat diubah untuk mengakomodasi kebutuhan organisasi Anda. Ukuran dapat dikurangi menjadi satu mesin virtual. Tata letak jaringan sangat disederhanakan untuk menunjukkan prinsip-prinsip arsitektur. Hal ini tidak dimaksudkan untuk menggambarkan jaringan perusahaan secara penuh.

Alur kerja

Komponen berikut ini membuat anotasi alur kerja arsitektur ini:

Jaringan virtual. Layanan Azure Virtual Network menghubungkan sumber daya Azure satu sama lain dengan keamanan yang ditingkatkan. Dalam arsitektur ini, jaringan virtual terhubung ke lingkungan lokal melalui gateway jaringan privat maya (VPN) 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 topologi jaringan hub-and-spoke dengan beberapa jaringan virtual yang di-peer bersama. Topologi ini menyediakan segmentasi dan isolasi jaringan untuk layanan yang disebarkan di Azure. Peering memungkinkan konektivitas transparan antara jaringan virtual di-peering melalui jaringan pusat Microsoft. Peering tidak dikenakan penalti performa jika disebarkan dalam satu wilayah. Jaringan virtual dibagi menjadi subnet terpisah untuk setiap aplikasi tingkat (SAP NetWeaver), database, dan layanan bersama (seperti Jumpbox dan Active Directory).

Komputer virtual. Arsitektur ini menggunakan mesin virtual untuk tingkat aplikasi dan tingkat database, dikelompokkan seperti:

• SAP NetWeaver. Tingkat aplikasi menggunakan mesin virtual Windows untuk menjalankan Layanan Pusat SAP dan server aplikasi SAP. VM yang menjalankan Central Services dikonfigurasi sebagai Windows Server Failover Cluster (WSFC) untuk ketersediaan tinggi. Mereka didukung oleh azure File Shares (AFS) atau disk bersama Azure.

• AnyDB. Tingkat database menjalankan AnyDB sebagai database, seperti Microsoft SQL Server, Oracle, atau IBM Db2.

• Jumpbox (juga disebut host bastion). Administrator menggunakan mesin virtual keamanan yang ditingkatkan ini untuk terhubung ke mesin virtual lainnya. Hal ini biasanya merupakan bagian dari layanan bersama, seperti pengendali domain dan layanan pencadangan. Jika Secure Shell Protocol (SSH) dan Remote Desktop Protocol (RDP) adalah satu-satunya layanan yang digunakan untuk administrasi server, host Azure Bastion adalah alternatifnya. Tetapi jika Anda menggunakan alat manajemen lain, seperti SQL Server Management Studio atau SAP Front End, gunakan jump box tradisional yang disebarkan sendiri.

• Pengendali domain Active Directory lokal. Pengendali domain digunakan untuk manajemen identitas semua mesin virtual dan pengguna di domain.

Load balancer. Load balancer digunakan untuk mendistribusikan lalu lintas ke mesin virtual di subnet tingkat aplikasi. Untuk ketersediaan tinggi, gunakan SAP Web Dispatcher bawaan, Azure Load Balancer, atau appliance jaringan. Pilihan Anda bergantung pada jenis lalu lintas (seperti HTTP atau GUI SAP) atau layanan jaringan yang diperlukan, seperti penghentian Secure Sockets Layer (SSL). Saat Anda menggabungkan Azure Load Balancer dalam penyebaran zona SAP, pastikan Anda memilih load balancer SKU Standar karena penyeimbang SKU Dasar tidak dilengkapi dengan redundansi zona.

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

Gateway zona redundan. Azure ExpressRoute atau gateway VPN dapat disebarkan di seluruh zona untuk menjaga dari kegagalan zona. Lihat Gateway jaringan virtual zona-redundan untuk memahami perbedaan antara penyebaran zona dan penyebaran zona-redundan. Perlu disebutkan di sini bahwa alamat IP yang digunakan harus dari SKU Standar untuk penyebaran zona gateway.

Grup penempatan kedekatan. Grup logis ini menempatkan batasan pada mesin virtual yang disebarkan di set ketersediaan atau virtual machine scale set. Grup penempatan kedekatan menyukai kolokasi, artinya mesin virtual berada di pusat data yang sama untuk meminimalkan latensi aplikasi.

Kelompok keamanan jaringan. Untuk membatasi lalu lintas masuk, keluar, dan intra-subnet di jaringan virtual, buat kelompok keamanan jaringan.

Kelompok keamanan aplikasi. Untuk menentukan kebijakan keamanan jaringan yang terperinci berdasarkan beban kerja yang dipusatkan pada aplikasi, gunakan kelompok keamanan aplikasi daripada alamat IP eksplisit. Kelompok keamanan aplikasi memungkinkan Anda mengelompokkan mesin virtual berdasarkan nama dan membantu Anda mengamankan aplikasi dengan memfilter lalu lintas dari segmen tepercaya dari jaringan.

Gateway. Gateway menghubungkan jaringan yang berbeda, memperluas jaringan lokal Anda ke jaringan virtual Azure. Sebaiknya Anda menggunakan ExpressRoute untuk membuat koneksi privat yang tidak melalui internet publik, tetapi Anda juga dapat menggunakan koneksi site-to-site. Untuk mengurangi latensi atau meningkatkan throughput, pertimbangkan Jangkauan Global ExpressRoute dan ExpressRoute FastPath, seperti yang akan dibahas nanti dalam artikel ini.

Azure Storage. Azure Storage menyediakan persistensi data untuk mesin virtual dalam bentuk hard disk virtual (VHD). Kami menyarankan Disk terkelola Azure.

Rekomendasi

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

Komputer virtual

Di kumpulan server aplikasi dan kluster, sesuaikan jumlah komputer virtual berdasarkan kebutuhan Anda. Panduan perencanaan dan penerapan Azure Virtual Machines mencakup detail tentang menjalankan SAP NetWeaver pada mesin virtual.

Untuk detail tentang dukungan SAP untuk jenis mesin virtual Azure dan metrik throughput (SAPS), lihat SAP Note 1928533. (Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.)

SAP Web Dispatcher (SWD)

Komponen Web Dispatcher digunakan sebagai load balancer untuk lalu lintas SAP di antara beberapa server aplikasi SAP. Untuk mencapai ketersediaan tinggi untuk komponen Web Dispatcher, Azure Load Balancer digunakan untuk menerapkan kluster failover SWD atau penyiapan SWD paralel. Lihat Ketersediaan Tinggi SAP Web Dispatcher untuk penjelasan rinci tentang solusi.

Kumpulan server aplikasi

Transaksi SAP SMLG biasanya digunakan untuk mengelola grup masuk untuk server aplikasi ABAP dan untuk menyeimbangkan beban pengguna masuk. Transaksi lain, seperti SM61 untuk grup server batch dan RZ12 untuk grup RFC, juga menyeimbangkan beban pengguna masuk. Transaksi ini menggunakan kemampuan penyeimbangan beban dalam server pesan dari Layanan Pusat SAP untuk mendistribusikan sesi masuk atau beban kerja di antara kluster server aplikasi SAP untuk lalu lintas GUI SAP dan RFC.

Kluster Layanan Pusat SAP

Arsitektur rujukan ini menjalankan Layanan Pusat pada komputer virtual di tingkat aplikasi. Layanan Pusat berpotensi menjadi titik kegagalan tunggal (SPOF) saat disebarkan ke satu mesin virtual. Untuk menerapkan solusi yang sangat tersedia, gunakan kluster berbagi file atau kluster disk bersama.

Untuk berbagi file yang sangat tersedia, ada beberapa opsi. Sebaiknya Anda menggunakan pembagian Azure Files sebagai pembagian SMB atau NFS yang dikelola penuh di cloud-native. Alternatif untuk Azure Files adalah Azure NetApp Files, yang menyediakan pembagian NFS dan SMB dengan performa tinggi.

Anda juga dapat menerapkan berbagi file yang sangat tersedia pada instans Layanan Pusat dengan menggunakan WSFC dengan (Azure Files). Solusi ini juga mendukung Kluster Windows dengan disk bersama dengan menggunakan disk bersama Azure sebagai volume bersama kluster (CSV). Jika Anda lebih suka menggunakan disk bersama, sebaiknya gunakan disk bersama Azure untuk menyiapkan kluster failover Windows Server untuk Kluster Layanan Pusat SAP.

Ada juga produk pihak ketiga seperti SIOS DataKeeper Cluster Edition dari SIOS Technology Corp. Add-on ini mereplikasi konten dari disk independen yang terpasang ke node kluster ASCS dan kemudian menampilkan disk sebagai CSV ke perangkat lunak kluster.

Dalam kasus pemartisian jaringan kluster, perangkat lunak kluster menggunakan suara kuorum untuk memutuskan segmen jaringan mana dan layanan terkaitnya yang akan berfungsi sebagai otak kluster yang sekarang terfragmentasi. Windows menawarkan sejumlah model kuorum. Solusi ini menggunakan Cloud Witness Azure karena lebih sederhana dan menyediakan lebih banyak ketersediaan daripada node witness komputasi. Azure file share witness adalah alternatif lain untuk memberikan pilihan kuorum kluster.

Pada penyebaran Azure, server aplikasi terhubung ke Layanan Pusat yang sangat tersedia melalui nama host virtual dari layanan ASCS atau ERS. Nama host ini ditetapkan ke konfigurasi IP front-end kluster load balancer. Azure Load Balancer mendukung beberapa IP front-end, sehingga IP virtual (VIP) ASCS dan ERS dapat dibatasi ke satu load balancer.

Kumpulan ketersediaan

Kumpulan ketersediaan mendistribusikan server ke berbagai infrastruktur fisik dan memperbarui grup untuk meningkatkan ketersediaan layanan. Untuk memenuhi perjanjian tingkat layanan (SLA), masukkan mesin virtual yang menjalankan peran yang sama ke dalam kumpulan ketersediaan. Dengan melakukan hal ini, membantu menjaga dari waktu henti yang direncanakan dan tidak direncanakan yang disebabkan oleh pemeliharaan infrastruktur Azure atau yang disebabkan oleh kesalahan perangkat keras. Untuk mendapatkan SLA yang lebih tinggi, Anda harus memiliki dua atau lebih mesin virtual pada setiap kumpulan ketersediaan.

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

Anda dapat menyebarkan kumpulan ketersediaan Azure di Zona Ketersediaan Azure saat menggunakan grup penempatan kedekatan.

Jaringan

Arsitektur ini menggunakan topologi hub-spoke. Jaringan virtual hub bertindak sebagai titik pusat konektivitas ke jaringan lokal. Spoke adalah jaringan virtual yang menghubungkan dengan hub dan mengisolasi beban kerja SAP. Arus lalu lintas antara pusat data lokal dan hub melalui koneksi gateway.

Kartu antarmuka jaringan (NIC)

Kartu antarmuka jaringan memungkinkan semua komunikasi antara mesin virtual di jaringan virtual. 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. Jadi tidak perlu menggunakan banyak NIC untuk alasan performa. Tetapi jika organisasi Anda perlu memisahkan lalu lintas, Anda dapat menyebarkan beberapa NIC per mesin virtual dan menghubungkan setiap NIC ke subnet yang berbeda. Anda kemudian dapat menggunakan kelompok keamanan jaringan untuk menerapkan kebijakan kontrol akses yang berbeda.

Azure NIC mendukung banyak IP. Dukungan ini sesuai dengan praktik yang disarankan SAP dalam menggunakan nama host virtual untuk penginstalan. Untuk ringkasan lengkap, lihat 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 melakukan hal ini, Anda dapat mengamankan server lebih mudah dengan mengelola kebijakan keamanan subnet daripada server terpisah.

Saat dikaitkan dengan subnet, kelompok keamanan jaringan berlaku untuk semua server di dalam subnet dan menawarkan kontrol mendetail atas server. Siapkan dengan menggunakan portal Microsoft Azure, PowerShell, atau Azure CLI.

Jangkauan Global ExpressRoute

Jika lingkungan jaringan Anda mencakup dua atau lebih koneksi ExpressRoute, Jangkauan Global ExpressRoute dapat membantu Anda mengurangi lonjakan dan latensi jaringan. Teknologi ini adalah peering rute BGP yang diatur antara dua atau lebih koneksi ExpressRoute untuk menghubungkan dua domain perutean ExpressRoute. Jangkauan Global mengurangi latensi saat lalu lintas melintasi lebih dari satu koneksi ExpressRoute. Saat ini hanya tersedia untuk peering privat di sirkuit ExpressRoute.

Saat ini, tidak ada daftar kontrol akses jaringan (ACL) 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

Juga dikenal sebagai Microsoft Edge Exchange (MSEE) v2, FastPath menerapkan MSEE pada titik entri jaringan Azure. Ini mengurangi hop jaringan untuk sebagian besar paket data.

Untuk semua koneksi ExpressRoute baru ke Azure, FastPath adalah konfigurasi default. 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 dari jaringan lokal Anda ke jaringan virtual spoke lainnya akan terus dikirim ke gateway virtual. Solusinya adalah menghubungkan semua jaringan virtual ke sirkuit ExpressRoute secara langsung.

Load balancer

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

Azure Load Balancer adalah layanan lapisan transmisi jaringan (lapisan 4) yang menyeimbangkan lalu lintas dengan menggunakan hash 5 tupel dari aliran data. (Hash didasarkan pada IP sumber, port sumber, IP tujuan, port tujuan, dan jenis protokol.) Dalam penyebaran SAP di Azure, Load Balancer digunakan dalam penyiapan kluster untuk mengarahkan lalu lintas ke instans layanan utama atau ke simpul sehat jika ada kesalahan.

Sebaiknya Anda menggunakan Azure Standard Load Balancer untuk semua skenario SAP. Jika komputer virtual di kumpulan back-end memerlukan konektivitas keluar publik, atau jika digunakan dalam penyebaran zona Azure, load balancer standar memerlukan konfigurasi tambahan karena aman secara default; mereka tidak akan mengizinkan konektivitas keluar kecuali Anda mengonfigurasinya secara eksplisit.

Untuk lalu lintas dari klien GUI SAP yang terhubung ke server SAP melalui protokol DIAG atau Remote Function Calls (RFC), server pesan Layanan Pusat menyeimbangkan beban melalui grup info masuk server aplikasi SAP. Untuk ini, Anda tidak memerlukan load balancer lain.

Azure Storage

Beberapa organisasi menggunakan penyimpanan standar untuk server aplikasi mereka. Disk terkelola standar tidak didukung. Lihat Catatan SAP 1928533. (Akun Marketplace Layanan SAP diperlukan.) Kami menyarankan agar Anda menggunakan disk premium yang dikelola Azure dalam semua kasus. Perhatikan bahwa pembaruan terbaru untuk Catatan SAP 2015553 mengecualikan penggunaan penyimpanan HDD Standar dan penyimpanan SSD Standar untuk beberapa kasus penggunaan tertentu.

Server aplikasi tidak menghosting data bisnis. Jadi, Anda juga dapat menggunakan disk premium P4 dan P6 yang lebih kecil untuk membantu meminimalkan biaya. Dengan melakukan hal ini, Anda dapat memanfaatkan SLA Mesin Virtual instans tunggal jika memiliki penginstalan tumpukan SAP pusat.

Untuk skenario ketersediaan tinggi, Anda dapat menggunakan Azure File Shares dan disk bersama Azure. Premium disk terkelola SSD dan Ultra SSD Azure tersedia untuk disk bersama Azure, dan Premium SSD tersedia untuk Berbagi File Azure.

Azure Storage juga digunakan oleh Cloud Witness untuk mempertahankan kuorum dengan perangkat di wilayah Azure jarak jauh,yang jauh dari wilayah utama tempat kluster berada.

Untuk penyimpanan data cadangan, kami menyarankan Azure tingkat akses cool dan arsip. Tingkat penyimpanan ini menyediakan cara hemat biaya untuk menyimpan data berumur panjang yang jarang diakses.

Ultra disk sangat mengurangi latensi disk dan menguntungkan aplikasi yang sangat membutuhkan performa seperti server database SAP. Bandingkan opsi penyimpanan blok di Azure.

Untuk penyimpanan data bersama dengan ketersediaan tinggi dan performa tinggi, gunakan Azure NetApp Files. Teknologi ini sangat berguna untuk tingkat database saat Anda menggunakan Oracle, dan juga saat Anda menghosting data aplikasi.

Pertimbangan performa

Server aplikasi SAP berkomunikasi secara konstan dengan server database. Untuk aplikasi yang membutuhkan performa yang berjalan pada platform database, aktifkan Write Accelerator untuk volume log. Hal ini dapat meningkatkan latensi penulisan log. Write Accelerator tersedia untuk mesin virtual seri M. Untuk mengoptimalkan komunikasi antar-server, gunakan jaringan yang dipercepat. Jaringan yang dipercepat hanya tersedia untuk seri mesin virtual yang didukung, termasuk D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2, dan Ms/Mms. Untuk informasi selengkapnya, lihat Memaksimalkan performa mesin virtual dengan jaringan yang dipercepat.

Untuk mencapai IOPS dan throughput disk yang tinggi, praktik umum dalam pengoptimalan performa volume penyimpanan berlaku untuk tata letak penyimpanan Azure. Misalnya, Anda dapat menggabungkan beberapa disk bersamaan untuk membuat volume disk bergaris untuk meningkatkan performa I/O. Mengaktifkan cache baca pada konten penyimpanan yang jarang berubah akan meningkatkan kecepatan pengambilan data.

Ultra disk sekarang tersedia untuk aplikasi yang membutuhkan I/O. Jika ultra disk tersedia, kami merekomendasikannya melalui penyimpanan premium Write Accelerator. Anda dapat meningkatkan atau menurunkan metrik performa satu per satu, seperti IOPS dan MBps, tanpa perlu memulai ulang.

Untuk SAP di Azure, Perencanaan dan penerapan Azure Virtual Machines untuk SAP NetWeaver memberikan saran yang sangat baik tentang pengoptimalan penyimpanan Azure untuk beban kerja SAP di SQL Server.

Kami tidak merekomendasikan penempatan appliance virtual jaringan (NVA) apa pun antara aplikasi dan lapisan database untuk tumpukan aplikasi SAP apa pun. Praktik ini memperkenalkan waktu pemrosesan yang signifikan untuk paket data, yang mengarah pada performa aplikasi yang tidak dapat diterima.

Grup penempatan kedekatan

Beberapa aplikasi SAP memerlukan komunikasi yang sering dengan database. Kedekatan fisik aplikasi dan lapisan database mempengaruhi latensi jaringan, yang dapat mempengaruhi performa aplikasi.

Untuk mengoptimalkan latensi jaringan, Anda dapat menggunakan grup penempatan kedekatan, yang mengatur batasan logis pada mesin virtual yang disebarkan dalam kumpulan ketersediaan. Grup penempatan kedekatan lebih menyukai kolokasi dan performa daripada skalabilitas, ketersediaan, atau biaya. Grup penempatan kedekatan dapat meningkatkan pengalaman pengguna dengan signifikan untuk sebagian besar aplikasi SAP. Skrip tersedia di GitHub.

Zona Ketersediaan

Zona Ketersediaan memungkinkan Anda menyebarkan mesin virtual di seluruh zona. Artinya, lokasi yang terpisah secara fisik dalam wilayah Azure tertentu. Tujuannya adalah untuk meningkatkan ketersediaan layanan, tetapi pertimbangkan performa saat Anda menyebarkan sumber daya dengan zona.

Administrator memerlukan profil latensi jaringan yang jelas di antara semua zona wilayah target sebelum mereka dapat menentukan penempatan sumber daya dengan latensi antar zona yang minimum. Untuk membuat profil ini, sebarkan mesin virtual kecil di setiap zona untuk pengujian. Alat yang disarankan untuk pengujian ini meliputi PsPing dan Iperf. Saat pengujian selesai, hapus mesin virtual yang Anda gunakan untuk pengujian. Sebagai alternatif, ada juga alat pemeriksaan latensi antar zona Azure yang tersedia untuk kenyamanan Anda.

Pertimbangan skalabilitas

Untuk lapisan aplikasi SAP, Azure menawarkan berbagai ukuran mesin virtual untuk penyempitan penskalaan dan peluasan penskalaan. Untuk daftar inklusif, lihat Catatan SAP 1928533 - Aplikasi SAP di Azure: Produk yang Didukung dan Jenis Mesin Virtual Azure. (Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.)

Anda dapat menskalakan server aplikasi SAP dan kluster Layanan Pusat ke atas, ke bawah, atau ke luar dengan menambahkan lebih banyak instans. Database AnyDB dapat ditingkatkan dan diturunkan skalanya tetapi tidak diluaskan. Kontainer database SAP untuk AnyDB tidak mendukung sharding.

Pertimbangan ketersediaan

Redundansi sumber daya adalah tema umum dalam solusi infrastruktur dengan ketersediaan tinggi. Untuk perusahaan yang memiliki SLA yang tidak terlalu ketat, mesin virtual Azure instans tunggal dengan disk premium menyediakan SLA waktu aktif. Saat Anda menyebarkan sumber daya redundan dalam kumpulan ketersediaan atau di seluruh Zona Ketersediaan, ketersediaan layanan akan meningkat.

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

Komponen Web Dispatcher digunakan sebagai load balancer untuk lalu lintas SAP di antara beberapa server aplikasi SAP. Untuk mencapai ketersediaan tinggi SAP Web Dispatcher, Azure Load Balancer menerapkan kluster failover atau penyiapan Web Dispatcher paralel.

Untuk komunikasi yang terhubung ke internet, kami menyarankan solusi yang berdiri sendiri di jaringan sekitar (juga dikenal sebagai DMZ) untuk memenuhi masalah keamanan.

Dispatcher Web yang Disematkan di ASCS adalah opsi khusus. Anda harus mempertimbangkan ukuran yang tepat karena beban kerja tambahan pada ASCS.

Layanan Pusat di tingkat server aplikasi

Ketersediaan tinggi Layanan Pusat diimplementasikan dengan WSFC. Ketika penyimpanan kluster untuk kluster failover disebarkan di Azure, Anda dapat mengonfigurasinya dengan dua cara: sebagai disk bersama terkluster atau sebagai berbagi file berkluster.

1. Sebaiknya Anda menggunakan Azure Files sebagai pembagian SMB atau NFS cloud-native yang dikelola penuh. Cara lain adalah menggunakan Azure NetApp Files, yang menyediakan berbagi NFS dan SMB kelas perusahaan berkinerja tinggi.

2. Ada dua cara untuk menyiapkan kluster dengan disk bersama di Azure. Pertama, kami sarankan Anda menggunakan disk bersama Azure untuk menyiapkan Kluster Failover Server Windows untuk Layanan Pusat SAP. Contoh implementasi tersedia dengan kluster SAP ASCS menggunakan disk bersama Azure. Cara lain untuk mengimplementasikan disk bersama terkluster adalah dengan menggunakan SIOS DataKeeper untuk melakukan tugas-tugas berikut:

   • Replikasi konten disk independen yang dilampirkan ke node kluster.
   • Memisahkan drive sebagai CSV untuk manajer kluster.

   Untuk detail implementasi, lihat Pengklusteran SAP ASCS di Azure dengan SIOS.

Dengan diperkenalkannya Azure Standard Load Balancer, sekarang Anda cukup mengaktifkan port ketersediaan tinggi. Dengan melakukan hal ini, Anda dapat menghindari mengonfigurasi aturan penyeimbangan beban untuk banyak port SAP. Selain itu, saat Anda menyiapkan load balancer secara umum, baik lokal atau di Azure, aktifkan fitur Pengembalian Server Langsung (juga disebut Floating IP atau DSR). Dengan melakukan hal tersebut dapat memungkinkan respons server untuk melewati load balancer. Koneksi langsung ini menjaga load balancer agar tidak menjadi hambatan di jalur transmisi data. Untuk SAP ASCS dan kluster database, sebaiknya Anda mengaktifkan DSR.

Layanan aplikasi di tingkat server aplikasi

Ketersediaan tinggi untuk server aplikasi SAP dicapai dengan lalu lintas penyeimbangan beban dalam kumpulan server aplikasi.

Tingkat database

Untuk arsitektur referensi ini, kami mengasumsikan database sumber berjalan di AnyDB. Artinya, DBMS seperti SQL Server, SAP ASE, IBM Db2, atau Oracle. Fitur replikasi native tingkat database menyediakan failover manual atau otomatis antara node yang direplikasi.

Untuk detail penerapan tentang sistem database tertentu, lihat Penyebaran DBMS Azure Virtual Machines untuk SAP NetWeaver.

Mesin virtual disebarkan di seluruh Zona Ketersediaan

Zona Ketersediaan adalah konstruksi logis yang dirancang untuk meningkatkan ketersediaan beban kerja dan melindungi layanan aplikasi dan mesin virtual dari kegagalan pusat data. Mesin virtual dalam satu zona diperlakukan seolah-olah mesin virtual tersebut berada dalam domain kesalahan atau pembaruan tunggal. Saat Anda memilih penyebaran zona, mesin virtual di zona yang sama didistribusikan ke domain kesalahan dan peningkatan berdasarkan upaya terbaik.

Di wilayah Azure yang mendukung fitur ini, tersedia setidaknya tiga zona. Tetapi jarak maksimum antara pusat data di zona ini tidak dijamin. Untuk menyebarkan sistem SAP multitingkat di seluruh zona, Anda perlu mengetahui latensi jaringan di dalam zona dan di seluruh zona yang ditargetkan. Anda juga perlu mengetahui seberapa sensitif aplikasi yang Anda sebarkan terhadap latensi jaringan.

Periksa pertimbangan ini saat Anda memutuskan untuk menyebarkan sumber daya di seluruh Zona Ketersediaan:

• Latensi antara mesin virtual dalam satu zona.

• Latensi antara mesin virtual di seluruh zona yang dipilih.

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

Contoh penyebaran aktif/tidak aktif

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. Satu set lain dari empat server aplikasi pasif dibangun di zona 2 tetapi dimatikan. Server akan diaktifkan hanya saat dibutuhkan.

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

Contoh penyebaran aktif/aktif

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

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

Jika zona 1 offline, Layanan Pusat dan layanan database akan beralih ke zona 2. Anda dapat mengaktifkan server aplikasi yang tidak aktif untuk menyediakan kapasitas penuh untuk pemrosesan aplikasi.

Pertimbangan Pemulihan Bencana

Setiap tingkat dalam tumpukan aplikasi SAP menggunakan strategi DR yang berbeda.

Tingkat server aplikasi

Server aplikasi SAP tidak berisi data bisnis. Di Azure, strategi DR sederhana adalah membuat server aplikasi SAP di wilayah sekunder, lalu menonaktifkannya. Jika ada perubahan konfigurasi atau pembaruan kernel di server aplikasi utama, Anda perlu menerapkan perubahan yang sama ke mesin virtual di wilayah sekunder. Misalnya, salin file yang dapat dijalankan kernel SAP ke mesin virtual DR.

Untuk replikasi otomatis server aplikasi ke wilayah sekunder, sebaiknya gunakan Azure Site Recovery. Anda juga dapat menggunakan Azure Site Recovery untuk menyiapkan DR untuk penyebaran aplikasi SAP NetWeaver multitingkat.

Layanan Pusat

Komponen tumpukan aplikasi SAP ini tidak menyimpan data bisnis. Untuk perlindungan DR yang mencakup seluruh wilayah, replikasi berbagi file AFS SMB atau disk bersama Azure dari kluster ASCS Anda, yang berisi direktori /sapmnt dan konten lainnya, ke berbagi atau disk AFS SMB yang sesuai di wilayah DR. Jika Anda menggunakan SIOS, Anda dapat menggunakan Site Recovery untuk mereplikasi kluster Central Services dengan menggunakan disk SIOS DataKeeper.

Jika Anda membuat proses replikasi sendiri tanpa menggunakan alat apa pun, Anda dapat membangun komputer virtual di wilayah DR untuk mereplikasi peran dan konten Layanan Pusat. Satu-satunya konten dari node Layanan Pusat utama untuk disinkronkan adalah pembagian /sapmnt. Jika perubahan konfigurasi atau pembaruan kernel terjadi di server Layanan Pusat utama, Anda perlu mengulangi perubahan pada mesin virtual di wilayah DR. Untuk detail tentang proses pembangunan, penyalinan, dan pengujian failover metode replikasi ini, unduh SAP NetWeaver: Membangun Solusi Pemulihan Bencana berbasis Hyper-V dan Microsoft Azure. Lihat "4.3. Lapisan SAP SPOF (ASCS)."

Tingkat database

Sebaiknya gunakan teknologi replikasi database yang terintegrasi untuk DR. Misalnya, untuk SQL Server, sebaiknya Anda menggunakan grup ketersediaan Always On untuk membuat replika di wilayah jarak jauh dan mereplikasi transaksi secara asinkron dengan menggunakan failover manual. Replikasi asinkron menghindari dampak pada performa beban kerja interaktif di situs utama. Saat menggunakan failover manual, Anda kemudian dapat mengevaluasi dampak DR dan memutuskan apakah pengoperasian dari situs DR dapat dibenarkan.

Jika menggunakan Azure NetApp Files untuk penyimpanan database, Anda mungkin dapat menggunakan replikasi lintas wilayah untuk mereplikasi data ke wilayah sekunder. Fitur ini saat ini dalam pratinjau, jadi pastikan apakah fitur tersebut memenuhi persyaratan Anda untuk beban kerja produksi.

DR untuk layanan bersama

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

DR Otomatis dengan Azure Site Recovery

Untuk menggunakan Azure Site Recovery agar secara otomatis membangun situs produksi yang sepenuhnya direplikasi dari konfigurasi awal, Anda harus menjalankan skrip penyebaran yang disesuaikan. Misalnya, Site Recovery terlebih dahulu menyebarkan mesin virtual dalam kumpulan ketersediaan. Koneksi langsung kemudian menjalankan skrip kustom Anda untuk melampirkan load balancer (yang dibangun sebelumnya) yang ada, di mana kumpulan backend sudah ditentukan, ke NIC dari mesin virtual failover. Contoh skrip Runbook Automasi Site Recovery kustom tersedia di GitHub.

Pertimbangan manajemen dan operasi

Cadangan

Database adalah beban kerja penting yang memerlukan Recovery Point Objective (RPO) yang rendah dan retensi jangka panjang.

• Untuk SAP di SQL Server, salah satu pendekatannya adalah menggunakan Azure Backup untuk mencadangkan database SQL Server yang berjalan di mesin virtual. Opsi lainnya adalah menggunakan snapshot Azure Files untuk mencadangkan file database SQL Server.

• Untuk SAP di Oracle/Windows, lihat bagian "Cadangkan/pulihkan" di Penyebaran DBMS Mesin Virtual Azure untuk SAP.

• Untuk database lain, lihat rekomendasi pencadangan untuk penyedia database Anda. Jika database mendukung Layanan Menyalin Bayangan Volume (VSS) Windows, maka cadangan aplikasi-konsisten menggunakan snapshot VSS

Manajemen identitas

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

• Berikan akses ke sumber daya Azure dengan menggunakan kontrol akses berbasis peran Azure (RBAC Azure).

• Berikan akses ke mesin virtual Azure dengan menggunakan Lightweight Directory Access Protocol (LDAP), Azure Active Directory, Kerberos, atau sistem lain.

Dukung akses dalam aplikasi itu sendiri dengan menggunakan layanan yang disediakan SAP. Atau gunakan OAuth 2.0 dan Azure Active Directory.

Pemantauan

Azure Monitor menyediakan alat canggih untuk mengumpulkan dan menganalisis telemetri. Alat ini membantu Anda memaksimalkan performa dan ketersediaan cloud serta sumber daya dan aplikasi lokal. (Azure Monitor sekarang menyertakan Analitik Log dan Insights Aplikasi.) Anda dapat menggunakan Azure Monitor untuk memantau anomali infrastruktur dan aplikasi, administrator pemberitahuan, dan mengotomatiskan reaksi terhadap kondisi yang telah ditentukan sebelumnya.

Untuk menyediakan pemantauan berbasis SAP terhadap sumber daya dan performa layanan infrastruktur SAP, gunakan ekstensi Azure SAP Enhanced Monitoring. Ekstensi ini memasukkan statistik pemantauan Azure ke dalam aplikasi SAP untuk pemantauan sistem operasi dan fungsi DBA Cockpit. SAP Enhanced Monitoring diperlukan untuk menjalankan SAP di Azure. Untuk detailnya, lihat Catatan SAP 2191498, "SAP di Linux dengan Azure: Pemantauan yang Ditingkatkan." (Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.)

Azure Monitor untuk Solusi SAP adalah tujuan di masa depan untuk solusi pemantauan end-to-end Azure-native untuk SAP NetWeaver. Solusi ini saat ini dalam pratinjau dan hanya tersedia di wilayah yang terbatas. Anda harus mengevaluasi dengan cermat apakah solusi memenuhi persyaratan Anda.

Azure Monitor untuk Solusi SAP menyediakan serangkaian metrik dan telemetri awal yang lengkap untuk pemantauan. Definisi metrik disimpan sebagai kueri SQL di JSON. Anda dapat mengubah definisi metrik untuk memenuhi persyaratan Anda. Anda bisa mendapatkan kumpulan metrik awal di GitHub.

Pertimbangan keamanan

SAP memiliki mesin manajemen pengguna (UME) sendiri untuk mengontrol akses dan otorisasi berbasis peran dalam aplikasi dan database SAP. Untuk panduan keamanan aplikasi terperinci, lihat Panduan Keamanan SAP NetWeaver.

Untuk keamanan jaringan tambahan, pertimbangkan untuk menggunakan jaringan sekitar yang menggunakan appliance virtual jaringan (NVA) untuk membuat firewall di depan subnet untuk Web Dispatcher.

Anda dapat menyebarkan NVA untuk memfilter lalu lintas antara jaringan virtual, tetapi jangan menempatkannya di antara aplikasi SAP dan database. Selain itu, periksa aturan perutean yang dikonfigurasi pada subnet dan hindari mengarahkan lalu lintas ke NVA instans tunggal. Dengan melakukan hal tersebut dapat menyebabkan waktu henti pemeliharaan dan jaringan atau kegagalan node berkluster.

Untuk keamanan infrastruktur, data dienkripsi saat transit dan saat tidak aktif. Bagian "Rekomendasi keamanan" di Perencanaan dan penerapan Azure Virtual Machines untuk SAP NetWeaver membahas keamanan jaringan. Artikel ini juga menentukan port jaringan yang perlu Anda buka di firewall untuk memungkinkan komunikasi aplikasi.

Anda dapat menggunakan Azure Disk Encryption untuk mengenkripsi disk mesin virtual Windows. Azure Disk Encryption menggunakan fitur BitLocker Windows untuk menyediakan enkripsi volume untuk sistem operasi dan disk data. Solusi ini juga berfungsi dengan Azure Key Vault untuk membantu Anda mengontrol dan mengelola kunci enkripsi disk dan rahasia dalam langganan brankas kunci. Data pada disk mesin virtual dienkripsi saat tidak aktif di penyimpanan Azure Anda.

Untuk enkripsi data saat tidak aktif, SQL Server Transparent Data Encryption (TDE) mengenkripsi file data SQL Server, Azure SQL Database, dan Azure SQL Data Warehouse. Untuk informasi selengkapnya, lihat Penyebaran DBMS Azure Virtual Machines SQL Server untuk SAP NetWeaver.

Untuk memantau ancaman dari dalam dan di luar firewall, pertimbangkan untuk menyebarkan Microsoft Sentinel (dalam pratinjau). Solusi ini menyediakan deteksi dan analitik ancaman berkelanjutan untuk sistem SAP yang disebarkan di Azure, di cloud lain, atau lokal. Berikut panduan penyebaran Anda.

Seperti biasa, pastikan untuk mengelola penambal keamanan dan patch untuk melindungi aset informasi Anda. Pertimbangkan untuk menggunakan pendekatan otomatisasi menyeluruh untuk tugas ini.

Pertimbangan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya.

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

Jika beban kerja Anda memerlukan lebih banyak memori dan lebih sedikit CPU, pertimbangkan untuk menggunakan salah satu ukuran mesin virtual vCPU terbatas untuk mengurangi biaya lisensi perangkat lunak per vCPU.

Komputer virtual

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

Secara umum, ada beberapa opsi pembayaran untuk mesin virtual:

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

• Pertimbangkan untuk menggunakan Azure Reservations jika Anda dapat berkomitmen untuk menggunakan mesin virtual selama jangka waktu satu tahun atau tiga tahun. Reservasi mesin virtual dapat mengurangi biaya sebanyak 72 persen dibandingkan dengan harga prabayar.

Gunakan Azure Spot Virtual Machines untuk menjalankan beban kerja yang dapat diinterupsi dan tidak memerlukan penyelesaian dalam jangka waktu yang telah ditentukan atau SLA. Azure menyebarkan spot saat ada kapasitas yang tersedia dan mengeluarkannya saat membutuhkan kapasitas kembali. Biaya yang terkait dengan spot lebih rendah. Pertimbangkan Mesin Virtual Spot untuk beban kerja berikut:

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

Jika Anda memerlukan kontrol lebih besar atas peristiwa pemeliharaan atau isolasi perangkat keras, baik untuk performa maupun kepatuhan, pertimbangkan untuk menyebarkan mesin virtual Anda pada host khusus.

Mesin virtual dan kumpulan ketersediaan

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

Jika Anda menyebarkan beban kerja di seluruh Zona Ketersediaan, kumpulan ketersediaan tidak diperlukan.

Azure Load Balancer

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

Anda hanya dikenakan biaya untuk jumlah aturan penyeimbangan beban dan keluar yang dikonfigurasi, ditambah data yang diproses melalui load balancer. Aturan NAT masuk gratis. Tidak ada biaya per jam untuk Load Balancer Standar jika 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. Lihat harga Azure ExpressRoute untuk info selengkapnya.

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 untuk SAP

Langkah berikutnya

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

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

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

Sumber daya terkait

• Menjalankan beban kerja produksi SAP menggunakan Oracle Database di Azure

• Lingkungan pengembangan/pengujian untuk beban kerja SAP di Azure