Menjalankan SAP NetWeaver di Windows pada Azure

Azure ExpressRoute
SAP HANA on Azure Large Instances
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

Panduan ini menyajikan serangkaian praktik yang 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.

Sistem

Diagram berikut menunjukkan SAP NetWeaver di lingkungan Windows.

Diagram arsitektur yang menunjukkan solusi untuk SAP NetWeaver di Windows. Database adalah AnyDB di Azure VM dengan set ketersediaan.

Unduh file Visio arsitektur ini.

Catatan

Untuk menyebarkan arsitektur ini, Anda memerlukan lisensi produk SAP yang sesuai dan teknologi non-Microsoft lainnya.

Panduan ini menjelaskan sistem produksi. Sistem ini disebarkan dengan ukuran komputer virtual (VM) tertentu yang dapat Anda ubah untuk mengakomodasi kebutuhan organisasi Anda. Sistem dapat dikurangi menjadi satu VM. Dalam panduan ini, tata letak jaringan sangat disederhanakan untuk menunjukkan prinsip arsitektur. Hal ini tidak dimaksudkan untuk menggambarkan jaringan perusahaan secara penuh.

Alur kerja

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

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 tingkatan: aplikasi (SAP NetWeaver), database, dan layanan bersama seperti Bastion dan solusi pencadangan pihak ketiga.

Mesin Virtual. Arsitektur ini menggunakan VM untuk tingkat aplikasi dan tingkat database, yang dikelompokkan dengan cara berikut:

  • SAP NetWeaver. Tingkat aplikasi menggunakan VM Windows untuk menjalankan SAP Central Services dan server aplikasi SAP. Untuk ketersediaan tinggi, VM yang menjalankan Layanan Pusat dikonfigurasi dalam kluster failover server Windows. Mereka didukung oleh berbagi file Azure atau disk bersama Azure.

  • AnyDB. Tingkat database menjalankan AnyDB sebagai database, yang dapat berupa Microsoft SQL Server, Oracle, atau IBM Db2.

  • Layanan bastion. Administrator menggunakan VM keamanan yang ditingkatkan yang disebut host bastion untuk terhubung ke VM lain. Biasanya merupakan bagian dari layanan bersama, seperti layanan cadangan. Jika Secure Shell Protocol (SSH) dan Remote Desktop Protocol (RDP) adalah satu-satunya layanan yang digunakan untuk administrasi server, host Azure Bastion adalah solusi yang baik. Jika Anda menggunakan alat manajemen lain, seperti SQL Server Management Studio atau SAP Frontend, 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 mengatasi nama domain di jaringan virtual, tanpa perlu mengonfigurasi solusi DNS kustom.

Load balancer. Untuk mendistribusikan lalu lintas ke VM di subnet tingkat aplikasi SAP untuk ketersediaan tinggi, kami sarankan Anda menggunakan load balancer standar Azure. Perhatikan bahwa load balancer standar menyediakan tingkat keamanan secara default. VM yang berada di belakang load balancer standar tidak memiliki konektivitas internet keluar. Untuk mengaktifkan internet keluar di VM, Anda perlu 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).

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

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

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

SKU Standar juga mendukung kluster SAP pengidentifikasi multi-sistem (multi-SID). Dengan kata lain, beberapa sistem SAP di Windows dapat berbagi infrastruktur ketersediaan tinggi umum untuk menghemat biaya. Evaluasi penghematan biaya, dan hindari menempatkan 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).

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

Kelompok keamanan aplikasi. Untuk menentukan kebijakan keamanan jaringan berbasis beban kerja yang terpusat pada aplikasi, gunakan grup keamanan aplikasi alih-alih alamat IP eksplisit. Kelompok keamanan aplikasi menyediakan cara untuk mengelompokkan VM berdasarkan nama dan membantu Anda mengamankan aplikasi dengan memfilter lalu lintas dari segmen tepercaya jaringan Anda.

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. Penyimpanan menyediakan persistensi data untuk VM dalam bentuk hard disk virtual. Kami menyarankan Disk terkelola Azure.

Rekomendasi

Arsitektur ini menjelaskan penyebaran tingkat produksi kecil. Penyebaran berbeda 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 Perencanaan dan implementasi Azure Virtual Machines untuk SAP NetWeaver.

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

SAP Web Dispatcher

Komponen Web Dispatcher digunakan untuk menyeimbangkan beban lalu lintas SAP di antara server aplikasi SAP. Untuk mencapai ketersediaan tinggi untuk komponen Web Dispatcher, Load Balancer digunakan untuk mengimplementasikan kluster failover instans Web Dispatcher atau penyiapan Web Dispatcher paralel. Untuk deskripsi terperinci tentang solusi ini, lihat Ketersediaan Tinggi SAP Web Dispatcher.

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 panggilan fungsi jarak jauh (RFC), juga memuat pengguna masuk keseimbangan. 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.

Klaster Layanan Pusat SAP

Arsitektur ini menjalankan Layanan Pusat pada VM 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. Kami menyarankan agar Anda menggunakan berbagi Azure Files sebagai berbagi Server Message Block (SMB) cloud-native yang dikelola sepenuhnya atau Network File System (NFS). 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 kluster failover server Windows dengan Azure Files. Solusi ini juga mendukung kluster Windows dengan disk bersama dengan menggunakan disk bersama Azure sebagai volume bersama kluster. Jika Anda lebih suka menggunakan disk bersama, kami sarankan Anda menggunakan disk bersama Azure untuk menyiapkan kluster failover Windows Server untuk kluster Layanan Pusat SAP.

Ada juga produk mitra seperti SIOS DataKeeper Cluster Edition dari SIOS Technology Corp. Add-on ini mereplikasi konten dari disk independen yang dilampirkan ke node kluster ASCS dan kemudian menyajikan disk sebagai volume bersama kluster ke perangkat lunak kluster.

Jika Anda menggunakan partisi jaringan kluster, perangkat lunak kluster menggunakan suara kuorum untuk memilih segmen jaringan dan layanan terkait untuk berfungsi sebagai otak kluster terfragmentasi. Windows menawarkan banyak model kuorum. Solusi ini menggunakan Cloud Witness karena lebih sederhana dan menyediakan lebih banyak ketersediaan daripada bukti simpul komputasi. Bukti berbagi file Azure adalah alternatif lain untuk memberikan suara kuorum kluster.

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

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)

NIC memungkinkan semua komunikasi di antara VM pada 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 direkomendasikan SAP untuk 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 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 mencakup dua atau lebih koneksi ExpressRoute, Jangkauan Global ExpressRoute dapat membantu Anda mengurangi lonjakan dan latensi jaringan. Teknologi ini adalah peering rute Border Gateway Protocol (BGP) yang disiapkan antara dua atau beberapa koneksi ExpressRoute untuk menjebak 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 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 dirancang untuk meningkatkan performa jalur data antara jaringan lokal dan jaringan virtual Anda. Ketika diaktifkan, FastPath mengirim lalu lintas jaringan langsung ke komputer virtual di jaringan virtual, melewati gateway.

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 jaringan dari jaringan lokal Anda ke jaringan virtual spoke lainnya dikirim ke gateway jaringan virtual. Solusinya adalah menghubungkan semua jaringan virtual ke sirkuit ExpressRoute secara langsung. Fitur ini masih dalam pratinjau umum.

Penyeimbang muatan

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 lima tuple 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 node yang sehat jika ada kesalahan.

Kami menyarankan agar Anda menggunakan Load Balancer Standar untuk semua skenario SAP. Jika VM 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 mengizinkan konektivitas keluar kecuali Anda secara eksplisit mengonfigurasinya.

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. Untuk jenis penyiapan ini, Anda tidak memerlukan load balancer lain.

Penyimpanan

Beberapa organisasi menggunakan penyimpanan standar untuk server aplikasi mereka. Disk terkelola standar tidak didukung. Lihat Catatan SAP 1928533. Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace. Sebaiknya Anda menggunakan disk terkelola Azure premium dalam semua kasus. 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 demikian, Anda dapat memperoleh manfaat dari SLA VM instans tunggal jika Anda memiliki penginstalan tumpukan SAP pusat.

Untuk skenario ketersediaan tinggi, Anda dapat menggunakan berbagi file Azure dan disk bersama Azure. Disk terkelola Azure Premium SSD dan Azure Ultra Disk Storage tersedia untuk disk bersama Azure, dan SSD Premium tersedia untuk berbagi file Azure.

Penyimpanan juga digunakan oleh Cloud Witness untuk mempertahankan kuorum dengan perangkat di wilayah Azure jarak jauh, 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.

Penyimpanan disk Azure Premium SSD v2 dirancang untuk beban kerja penting performa seperti sistem pemrosesan transaksi online yang secara konsisten membutuhkan latensi sub-milidetik yang dikombinasikan dengan IOPS dan throughput tinggi.

Penyimpanan Disk Ultra sangat mengurangi latensi disk. Akibatnya, ini menguntungkan aplikasi penting performa seperti server database SAP. Untuk membandingkan opsi penyimpanan blok di Azure, lihat Jenis disk terkelola 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 ketika Anda menghosting data aplikasi.

Pertimbangan performa

Server aplikasi SAP berkomunikasi secara konstan dengan server database. Untuk aplikasi penting performa yang berjalan pada platform database, aktifkan Write Accelerator untuk volume log jika Anda menggunakan Premium SSD v1. Hal ini dapat meningkatkan latensi penulisan log. 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 mencapai IOPS dan throughput disk yang tinggi, ikuti praktik umum dalam pengoptimalan performa volume penyimpanan, yang berlaku untuk tata letak penyimpanan Azure. Misalnya, Anda dapat memposisikan beberapa disk bersama-sama untuk membuat volume disk bergaris untuk meningkatkan performa I/O. Mengaktifkan cache baca pada konten penyimpanan yang jarang berubah akan meningkatkan kecepatan pengambilan data.

SSD premium v2 memberikan performa yang lebih tinggi daripada SSD Premium dan umumnya lebih murah. Anda dapat mengatur disk Premium SSD v2 ke ukuran yang didukung dan membuat penyesuaian terperinci pada performa tanpa waktu henti.

Penyimpanan Disk Ultra tersedia untuk aplikasi intensif I/O. Jika disk ini tersedia, kami merekomendasikannya melalui penyimpanan premium Write Accelerator . Anda dapat meningkatkan atau mengurangi metrik performa secara individual seperti IOPS dan MBps tanpa perlu melakukan boot ulang.

Untuk panduan tentang mengoptimalkan penyimpanan Azure untuk beban kerja SAP di SQL Server, lihat Perencanaan dan implementasi Azure Virtual Machines untuk SAP NetWeaver.

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

Grup penempatan terdekat

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 menetapkan batasan logis pada VM yang disebarkan dalam set ketersediaan. Grup penempatan kedekatan mendukung lokasi bersama dan performa dibandingkan skalabilitas, ketersediaan, atau biaya. Grup penempatan kedekatan dapat meningkatkan pengalaman pengguna dengan signifikan untuk sebagian besar aplikasi SAP. Untuk skrip yang tersedia di GitHub dari tim penyebaran SAP, lihat Skrip.

Zona ketersediaan

Zona ketersediaan menyediakan cara bagi Anda untuk menyebarkan VM di seluruh pusat data, yang merupakan lokasi yang dipisahkan secara fisik dalam wilayah Azure tertentu. Tujuan mereka adalah untuk meningkatkan ketersediaan layanan. Tetapi menyebarkan sumber daya di seluruh zona dapat meningkatkan latensi, jadi ingatlah pertimbangan performa.

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 VM kecil di setiap zona untuk pengujian. Alat yang disarankan untuk pengujian ini meliputi PsPing dan Iperf. Setelah pengujian selesai, hapus VM yang Anda gunakan untuk pengujian. Sebagai alternatif, pertimbangkan untuk menggunakan alat pemeriksaan latensi antar-zona Azure.

Pertimbangan skalabilitas

Untuk lapisan aplikasi SAP, Azure menawarkan berbagai ukuran VM untuk meningkatkan dan memperluas skala. Untuk daftar inklusif, lihat catatan SAP 1928533 - Aplikasi SAP di Azure: Produk yang Didukung dan Jenis Azure VM. Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.

Anda dapat menskalakan server aplikasi SAP dan kluster Layanan Pusat ke atas dan ke bawah. Anda juga dapat menskalakannya keluar atau masuk dengan mengubah jumlah instans yang Anda gunakan. 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 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.

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

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, Load Balancer mengimplementasikan kluster failover atau penyiapan Web Dispatcher paralel.

Untuk komunikasi yang terhubung ke internet, kami merekomendasikan solusi mandiri di jaringan perimeter, yang juga dikenal sebagai DMZ, 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.

Layanan Pusat di tingkat server aplikasi

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

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

  • 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. Untuk contoh implementasi, lihat kluster ASCS menggunakan disk bersama Azure. Cara lain untuk menerapkan disk bersama berkluster adalah dengan menggunakan SIOS DataKeeper untuk melakukan tugas-tugas berikut:

    • Replikasi konten disk independen yang dilampirkan ke node kluster.
    • Mengabstraksi drive sebagai volume bersama kluster untuk manajer kluster.

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

Jika Anda menggunakan Load Balancer Standar, Anda dapat mengaktifkan port ketersediaan tinggi. Dengan demikian, Anda dapat menghindari perlunya mengonfigurasi aturan penyeimbangan beban untuk beberapa port SAP. Selain itu, saat Anda menyiapkan load balancer Azure, aktifkan Direct Server Return (DSR), yang juga disebut FLOATING IP. Melakukannya menyediakan cara untuk respons server untuk melewati load balancer. Koneksi langsung ini menjaga load balancer agar tidak menjadi hambatan di jalur transmisi data. Kami menyarankan agar Anda mengaktifkan DSR untuk kluster ASCS dan database.

Layanan aplikasi di tingkat server aplikasi

Ketersediaan tinggi untuk server aplikasi SAP dicapai dengan menyeimbangkan beban lalu lintas dalam kumpulan server aplikasi. Anda tidak memerlukan perangkat lunak kluster, SAP Web Dispatcher, atau penyeimbang muatan Azure. Server pesan SAP dapat memuat lalu lintas klien keseimbangan ke server aplikasi yang ditentukan dalam grup masuk ABAP oleh transaksi SMLG.

Tingkat database

Dalam arsitektur ini, database sumber berjalan di AnyDB—DBMS seperti SQL Server, SAP ASE, IBM Db2, atau Oracle. Fitur replikasi asli tingkat database menyediakan failover manual atau otomatis antara simpul yang direplikasi.

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

VM yang disebarkan di seluruh zona ketersediaan

Zona ketersediaan terdiri dari satu atau beberapa pusat data. Ini dirancang untuk 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 kesalahan. Saat Anda memilih penyebaran zona, VM di zona yang sama didistribusikan ke domain kesalahan berdasarkan upaya terbaik.

Di wilayah Azure yang mendukung beberapa zona, setidaknya tiga zona tersedia. 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.

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

Catatan

Zona ketersediaan mendukung ketersediaan tinggi intra-wilayah, tetapi tidak efektif untuk pemulihan bencana (DR). Jarak antara zona terlalu pendek. Situs DR umum harus setidaknya 100 mil jauhnya dari wilayah utama.

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. 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 layanan database tersebar 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 sekarang terletak bersama di zona yang sama, latensi jaringan diminimalkan.

Contoh penyebaran aktif/aktif

Dalam penyebaran aktif/aktif, dua set server aplikasi dibangun di dua zona. Dalam setiap zona, dua server aplikasi di setiap set server tidak aktif, karena 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 gagal ke zona 2. Anda dapat mengaktifkan server aplikasi yang tidak aktif untuk menyediakan kapasitas penuh untuk pemrosesan aplikasi.

Pertimbangan DR

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

Catatan

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

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.

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

Cadangan

Database adalah beban kerja penting yang memerlukan tujuan titik pemulihan (RPO) rendah dan retensi jangka panjang.

  • Untuk SAP di SQL Server, salah satu pendekatannya adalah menggunakan Azure Backup untuk mencadangkan database SQL Server yang berjalan pada VM. 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 Windows Volume Shadow Copy Service (VSS), gunakan rekam jepret VSS untuk pencadangan yang konsisten dengan aplikasi.

Pengelolaan identitas

Gunakan sistem manajemen identitas terpusat seperti MICROSOFT Entra ID dan Active Directory Domain Services (AD DS) 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 Azure VM dengan menggunakan Lightweight Directory Access Protocol (LDAP), MICROSOFT Entra ID, Kerberos, atau sistem lain.

Dukung akses dalam aplikasi itu sendiri dengan menggunakan layanan yang disediakan SAP. Atau gunakan 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 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 lainnya, pertimbangkan untuk menggunakan jaringan perimeter yang menggunakan 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. Untuk informasi tentang keamanan jaringan, lihat bagian "Rekomendasi keamanan" di perencanaan dan implementasi Azure Virtual Machines untuk SAP NetWeaver. Artikel ini juga menentukan port jaringan yang perlu Anda buka pada firewall untuk memungkinkan komunikasi aplikasi.

Anda dapat menggunakan Azure Disk Encryption untuk mengenkripsi disk VM Windows. Layanan ini 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 VM dienkripsi saat tidak aktif di penyimpanan Azure Anda.

Untuk enkripsi data tidak aktif, enkripsi data transparan SQL Server (TDE) mengenkripsi file data SQL Server, Azure SQL Database, dan Azure Synapse Analytics. Untuk informasi selengkapnya, lihat Penyebaran DBMS Azure Virtual Machines SQL Server untuk SAP NetWeaver.

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

Seperti biasa, kelola pembaruan dan patch keamanan 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 VM vCPU yang dibatasi untuk mengurangi biaya lisensi perangkat lunak yang dibebankan per vCPU.

VM

Arsitektur ini menggunakan VM 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 SQL Server, Oracle, atau IBM DB2. VM juga digunakan sebagai jump box untuk manajemen.

Ada beberapa opsi pembayaran untuk VM:

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

  • 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 yang telah ditentukan atau SLA. 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, lihat Azure Reserved Virtual Machine Instances.

Load Balancer

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

Anda hanya dikenakan biaya untuk jumlah aturan load-balancing dan outbound yang dikonfigurasi, ditambah data yang diproses melalui load balancer. 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.

Komunitas

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

Kontributor

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

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