Azure bertemu SAP: Penjelasan SAP di Azure untuk Microsoft Teams

By Mirko Peters · 2026-11-05

Apa arti sebenarnya menjalankan SAP di Microsoft Azure: mesin virtual dan penyimpanan yang tersertifikasi, landing zone yang dibangun lebih dulu, konektivitas hybrid, tiga jalur deployment, dan kesalahan yang mengubah sistem SAP yang didukung menjadi tidak didukung.

Automatically translated with AI from the original post. Read the English original

Sebagai Microsoft MVP, sebagian besar waktu saya dihabiskan bersama orang-orang yang sangat memahami Azure, Entra ID, dan Microsoft 365, dan yang tiba-tiba diminta untuk "mendukung perpindahan SAP". Bagi banyak dari mereka, SAP terasa seperti dunia terpisah dengan kosakatanya sendiri. Kabar baiknya: SAP di Azure jauh lebih biasa daripada kedengarannya. Intinya ada dua aturan. Tetap berada dalam konfigurasi yang tersertifikasi, dan bangun fondasinya sebelum sistem SAP pertama masuk. Artikel ini membahas keduanya, sesuai urutan kerja yang sebenarnya.

Apa Arti SAP di Azure Sebenarnya

SAP di Azure berarti sistem SAP Anda berjalan di Microsoft Azure. Database SAP HANA, application server, dan central services berada di mesin virtual Azure serta menggunakan penyimpanan dan jaringan Azure. Perangkat lunak SAP itu sendiri tidak berubah: SAP S/4HANA tetap S/4HANA, SAP NetWeaver tetap NetWeaver. Yang berubah hanyalah fondasi di bawahnya.

Pembagian ini menunjukkan siapa memiliki apa. Microsoft menyediakan platform: mesin virtual, disk, jaringan, identitas, dan monitoring. SAP menyediakan aplikasi dan database, dan Anda mengoperasikannya sesuai dengan yang diharapkan SAP. Titik pertemuan keduanya adalah infrastruktur tersertifikasi di tengah.

Ada baiknya memisahkan ini dari topik kedua yang berkaitan. Menyalin data SAP ke Azure untuk laporan di Power BI atau Microsoft Fabric adalah integrasi data, pekerjaan yang berguna tetapi berbeda. Menjalankan SAP di Azure berarti sistem produksinya sendiri berada di sana, memproses transaksinya di sana, dan melayani penggunanya dari sana.

Jika Anda ingin melihat gambaran besar keluarga produk SAP terlebih dahulu, halaman topik SAP di M365.FM mengumpulkan konten terkait kami.

Mengapa Sertifikasi Menentukan Segalanya

Dalam dunia SAP, "berjalan di Azure" sebenarnya berarti "berjalan di Azure yang tersertifikasi". SAP dan Microsoft menguji jenis mesin virtual dan opsi penyimpanan tertentu terhadap produk dan skenario SAP tertentu, dan hanya kombinasi tersebut yang didukung. Microsoft mendokumentasikan sertifikasi dan konfigurasi SAP untuk Azure serta perangkat lunak SAP yang didukung di Azure. Untuk SAP HANA, SAP HANA Hardware Directory milik SAP adalah daftar resminya; untuk sistem berbasis NetWeaver, SAP Note 1928533 mencantumkan jenis VM Azure yang didukung.

Sertifikasi bukan properti Azure secara keseluruhan. Sertifikasi adalah properti dari kombinasi spesifik antara satu VM, satu opsi penyimpanan, dan satu skenario SAP. VM yang sangat lapang dan sempurna untuk aplikasi web mungkin saja tidak ada dalam daftar untuk HANA. Jika tetap memilihnya, Anda tidak menghemat biaya; Anda justru membangun sistem yang tidak ada vendor pun bersedia bertanggung jawab atasnya.

Storage mengikuti logika yang sama. Azure managed disks adalah blok bangunan sehari-hari, Azure NetApp Files menyediakan penyimpanan NFS yang digunakan di beberapa arsitektur SAP, dan Azure Files pada penyimpanan premium (SSD) dapat menjadi host direktori bersama. Tier standar Azure Files yang lebih murah tidak didukung untuk share high-availability SAP central services, jadi opsi yang murah justru menjadi opsi yang salah di sana. Microsoft mencantumkan batasan ini dalam supported scenarios for SAP workloads on Azure VMs.

Kebiasaan yang paling banyak mencegah masalah: sebelum Anda menentukan ukuran satu mesin pun, buka daftar bersertifikat untuk produk dan skenario SAP Anda, lalu rancang berdasarkan daftar tersebut.

Landing zone yang Anda bangun pertama

Azure landing zone adalah fondasi yang memberi setiap workload identitas, jaringan, keamanan, dan tata kelola sebelum apa pun di-deploy ke dalamnya. Cloud Adoption Framework dari Microsoft membaginya menjadi dua bagian:

• Platform landing zone: dasar bersama yang berisi management group, konektivitas pusat, identitas, keamanan, dan layanan manajemen.
• Application (workload) landing zone: lingkungan individual, biasanya development, test, dan production, yang masing-masing terdiri dari subscription yang mewarisi guardrail platform.

Untuk SAP, hal ini lebih penting dibanding kebanyakan workload lain, karena SAP menangani keuangan, supply chain, dan operasi. Kebijakan, aturan jaringan, dan identitas sebaiknya sudah ada sebelum sistem SAP pertama masuk. Menambahkannya belakangan berarti memindahkan resource di tengah sistem bisnis yang sedang berjalan.

Microsoft menyediakan SAP on Azure landing zone accelerator dengan desain referensi berbasis topologi jaringan hub-and-spoke atau Azure Virtual WAN. Azure Policy dan hierarki management group menetapkan guardrail, dan setiap sistem SAP kemudian masuk di dalamnya. Dengan begitu, sistem SAP kedua dan ketiga bisa hadir tanpa perdebatan baru soal penamaan, akses, dan aturan jaringan.

Menjaga SAP tetap terhubung dengan data center Anda

Memindahkan SAP ke Azure jarang berarti meninggalkan semuanya. Sebagian besar lanskap tetap bersifat hybrid dalam waktu lama, sehingga konektivitas menjadi jembatan yang menyatukannya.

Opsi privat utama adalah Azure ExpressRoute, yaitu koneksi privat khusus antara data center Anda dan Azure, bukan lalu lintas melalui internet publik. Jika ExpressRoute tidak tersedia, site-to-site VPN menjadi alternatifnya. Apa pun pilihannya, koneksi biasanya berakhir di hub pusat atau Virtual WAN, dan virtual network SAP mengaksesnya dari sana. Di dalam Azure, desain SAP yang umum memisahkan tier aplikasi dan database ke subnet masing-masing, dilindungi oleh network security group, route table, dan firewall.

Identitas layak dicermati dengan saksama, karena di sinilah tim Microsoft sering membuat asumsi. Microsoft Entra ID sangat baik untuk single sign-on ke aplikasi SAP. Namun, sistem SAP NetWeaver dan S/4HANA yang berjalan di Windows tidak menggunakan akun Entra ID untuk aplikasi SAP itu sendiri. Sistem tersebut tetap memerlukan Active Directory Domain Services, baik yang diperluas dari on-premises maupun yang disediakan oleh Microsoft Entra Domain Services. Sign-on dan direktori sistem operasi adalah dua cerita yang berbeda.

Tiga opsi deployment Anda

Tidak ada satu cara yang benar untuk men-deploy SAP di Azure. Pilih jalur yang sesuai dengan cara tim Anda beroperasi.

1. Azure virtual machines biasa. Anda sendiri yang mengelola sistem operasi, instalasi SAP, patching, dan monitoring. Kontrol maksimal, pekerjaan maksimal. Cocok jika keahlian SAP dan Azure yang mendalam sudah tersedia di dalam tim.
2. Azure Center for SAP solutions. Layanan Azure yang menjadikan SAP sebagai beban kerja kelas utama. Layanan ini dapat membuat infrastruktur dan menginstal perangkat lunak SAP untuk sistem server tunggal, sistem terdistribusi, dan sistem terdistribusi dengan ketersediaan tinggi, atau mendaftarkan sistem SAP yang sudah berjalan di Azure. Setiap sistem menjadi Virtual Instance for SAP solutions, tampilan logis dari SID, layanan pusat, database, dan server aplikasi. Dari sana Anda dapat melihat kondisi dan status, memulai serta menghentikan sistem, menjalankan pemeriksaan kualitas berdasarkan praktik terbaik, dan memantau data pemantauan. Rincian selengkapnya ada di ikhtisar Azure Center for SAP solutions.
3. SAP on Azure deployment automation framework. Pendekatan infrastruktur sebagai kode yang bersifat open-source, untuk tim yang menginginkan penerapan yang dapat diulang, dikelola versinya, dan mengikuti alur kerja DevOps.

Aturan sederhana untuk memutuskan: kontrol penuh dan keahlian yang kuat mengarah ke VM biasa; penyiapan terpandu dengan satu tempat untuk mengelola sistem mengarah ke Azure Center for SAP solutions; banyak sistem yang diterapkan dengan cara yang sama mengarah ke automation framework.

Kesalahan yang umum terjadi

Sebagian besar migrasi pertama yang paling menyulitkan memiliki pola yang sama: sebuah langkah yang terasa opsional.

• Menganggap sertifikasi sebagai formalitas. VM atau jenis penyimpanan yang tidak tersertifikasi akan mengubah sistem yang didukung menjadi tidak didukung, dan Anda biasanya baru menyadarinya pada saat yang paling buruk.
• Melewati landing zone. Anggapan "tata kelola akan kita tambahkan nanti" jarang terwujud, dan menyesuaikan aturan identitas dan jaringan di sekitar sistem SAP yang sudah berjalan itu lambat dan berisiko.
• Menganggap Entra ID menggantikan Active Directory untuk sistem SAP berbasis Windows. Hal itu tidak benar.
• Merancang konektivitas di tahap terakhir. Memisahkan lapisan aplikasi SAP dan lapisan database antara on-premises dan Azure, atau lintas wilayah Azure, tidak didukung.
• Menganggap semuanya berjalan di Azure. Azure VMware Solution umumnya bukan platform yang didukung untuk menjadi host beban kerja SAP, dan SAP HANA Large Instances tidak lagi ditawarkan kepada pelanggan baru.
• Menggunakan Azure Site Recovery untuk database. Azure Site Recovery tidak didukung untuk lapisan database SAP; gunakan replikasi bawaan database, seperti SAP HANA System Replication, untuk pemulihan bencana.

Setiap poin di atas adalah titik di mana batas dukungan Microsoft dan SAP tidak lagi sejalan. Batasan ini bukan untuk memperlambat Anda; batasan ini menandai area di mana kedua vendor akan tetap bertanggung jawab atas sistem Anda.

Kesimpulan: urutan pekerjaan

Jika hanya ada satu hal yang perlu diingat, ingatlah urutannya. Tentukan kebutuhan sistem SAP dalam hal performa, ketersediaan, dan pemulihan. Bangun landing zone. Hubungkan jaringan dan direktori kembali ke pusat data Anda. Tentukan seberapa banyak yang ingin Anda kelola: VM biasa, Azure Center for SAP solutions, atau automation framework. Pilih compute dan penyimpanan yang tersertifikasi. Kemudian rancang high availability dan disaster recovery berdasarkan kemampuan bawaan database.

Anda tidak harus memindahkan semuanya sekaligus. Memulai dengan satu sistem menunjukkan di mana landing zone Anda masih tipis dan di mana tim Anda membutuhkan dukungan, selagi taruhannya masih kecil. Bagi para profesional Microsoft, SAP di Azure bukanlah dunia asing. Ini adalah rangkaian keputusan rekayasa yang lazim, dengan sertifikasi sebagai satu-satunya aturan yang tidak boleh Anda langgar.