Arsitektur referensi ini menunjukkan serangkaian praktik yang terbukti untuk menjalankan SAP NetWeaver dengan Oracle Database di Azure, dengan ketersediaan tinggi. Prinsip arsitekturnya adalah sistem operasi (OS) agnostik, namun, kecuali ditentukan lain, diasumsikan didasarkan pada Linux.
Diagram pertama menunjukkan arsitektur referensi untuk SAP di Oracle di Azure, yang menggunakan set ketersediaan.
Gambar - Arsitektur sistem SAP produksi di Oracle, di Azure dengan set ketersediaan.
Diagram kedua menunjukkan arsitektur referensi untuk SAP di Oracle di Azure, yang menggunakan zona ketersediaan untuk peningkatan ketahanan.
Gambar - Arsitektur sistem SAP produksi di Oracle, di Azure dengan zona ketersediaan.
Unduh file Visio arsitektur ini.
Catatan
Untuk menyebarkan arsitektur referensi ini, Anda memerlukan lisensi produk SAP yang sesuai dan teknologi non-Microsoft lainnya.
Komponen
Arsitektur referensi ini menjelaskan sistem produksi SAP khas yang berjalan di Oracle Database di Azure, dalam penyebaran yang sangat tersedia untuk memaksimalkan ketersediaan sistem. Arsitektur dan komponennya dapat disesuaikan berdasarkan persyaratan bisnis (RTO, RPO, harapan waktu aktif, peran sistem) dan berpotensi dikurangi menjadi satu VM. Tata letak jaringan disederhanakan untuk menunjukkan prinsip arsitektur lingkungan SAP tersebut dan tidak dimaksudkan untuk menggambarkan jaringan perusahaan penuh.
Jaringan
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. Aplikasi dan database SAP terkandung dalam jaringan virtual spoke sendiri. Jaringan virtual dibagi menjadi subnet terpisah untuk setiap aplikasi tingkat (SAP NetWeaver), database, dan layanan bersama (seperti jumpbox dan server DNS).
Arsitektur ini membagi ruang alamat jaringan virtual menjadi subnet. Tempatkan server aplikasi pada subnet dan server database terpisah di server lain. Melakukannya memungkinkan Anda untuk mengamankannya dengan lebih mudah dengan mengelola kebijakan keamanan subnet daripada server individual dan secara bersih memisahkan aturan keamanan yang berlaku untuk database dari server aplikasi.
Peering jaringan virtual Arsitektur ini menggunakan topologi jaringan hub-and-spoke dengan beberapa jaringan virtual yang di-peering bersama-sama. 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.
Gateway zona-redundan Gateway menyambungkan 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. 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.
Kelompok keamanan jaringan Untuk membatasi lalu lintas masuk, keluar, dan intra-subnet di jaringan virtual, buat grup keamanan jaringan yang pada gilirannya ditetapkan ke subnet tertentu. DB dan subnet aplikasi diamankan dengan NSG khusus beban kerja.
Kelompok keamanan aplikasi Untuk menentukan kebijakan keamanan jaringan mendetail di dalam NSG Anda berdasarkan beban kerja yang berpusat pada aplikasi, gunakan grup keamanan aplikasi alih-alih 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.
Kartu antarmuka jaringan (NIC) Kartu antarmuka jaringan memungkinkan semua komunikasi di antara komputer virtual 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 grup keamanan jaringan untuk menerapkan kebijakan kontrol akses yang berbeda pada setiap subnet.
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.)
Komputer Virtual
Arsitektur ini menggunakan komputer virtual (VM). Untuk tingkat aplikasi SAP, VM disebarkan untuk semua peran instans - dispatcher web dan server aplikasi - baik layanan pusat SAP (A)SCS dan ERS serta server aplikasi (PAS, AAS). Sesuaikan jumlah komputer virtual berdasarkan kebutuhan Anda. Panduan perencanaan dan penerapan Azure Virtual Machines mencakup detail tentang menjalankan SAP NetWeaver pada mesin virtual.
Demikian pula untuk semua tujuan Oracle komputer virtual digunakan, baik untuk Oracle Database maupun VM pengamat Oracle. VM pengamat dalam arsitektur ini lebih kecil dibandingkan dengan server database aktual.
- VM vCPU yang dibatasi Untuk berpotensi menghemat biaya pada lisensi Oracle, pertimbangkan untuk menggunakan VM yang dibatasi vCPU
- Keluarga VM bersertifikat untuk SAP Untuk detail tentang dukungan SAP untuk jenis komputer virtual Azure dan metrik throughput (SAPS), lihat catatan SAP 1928533. (Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.)
Grup Penempatan Kedekatan (PPG) Untuk mengoptimalkan latensi jaringan, Anda dapat menggunakan grup penempatan kedekatan, yang mendukung kolokasi, yang berarti bahwa komputer virtual berada di pusat data yang sama untuk meminimalkan latensi aplikasi. Grup penempatan kedekatan dapat meningkatkan pengalaman pengguna dengan signifikan untuk sebagian besar aplikasi SAP. Karena potensi pembatasan dengan PPG, menambahkan database AvSet ke PPG sistem SAP harus dilakukan secara jarang dan hanya ketika diperlukan untuk latensi antara aplikasi SAP dan lalu lintas database. Untuk detail selengkapnya tentang skenario penggunaan untuk PPG, lihat dokumentasi yang ditautkan.
Komputer virtual Generasi 2 (Gen2) Azure menawarkan pilihan saat menyebarkan VM jika harus generasi 1 atau 2. VM Generasi 2 mendukung fitur utama yang tidak tersedia untuk VM generasi 1. Terutama untuk database Oracle yang sangat besar, ini sangat penting karena beberapa keluarga VM seperti Mv2 atau Mdsv2hanya didukung sebagai VM Gen2. Demikian pula, sertifikasi SAP di Azure untuk beberapa VM yang lebih baru mungkin mengharuskannya hanya Gen2 untuk dukungan penuh, bahkan jika Azure mengizinkan keduanya. Lihat detail di SAP Note 1928533 - Aplikasi SAP di Microsoft Azure: Produk yang Didukung dan jenis Azure VM.
Karena semua VM lain yang mendukung SAP memungkinkan pilihan Gen2 saja atau Gen1+2 secara selektif, disarankan untuk menyebarkan semua VM SAP sebagai Gen2, bahkan jika persyaratan memori sangat rendah. Bahkan VM terkecil sekali disebarkan sebagai Gen2 dapat ditingkatkan ke yang terbesar yang tersedia dengan dealokasi sederhana dan mengubah ukuran. VM Gen1 hanya dapat diubah ukurannya menjadi keluarga VM yang diizinkan untuk menjalankan VM Gen1.
Penyimpanan
Arsitektur ini menggunakan disk terkelola Azure untuk komputer virtual dan Azure Files NFS atau Azure NetApp Files untuk persyaratan penyimpanan bersama NFS seperti volume NFS transportasi sapmnt dan SAP. Panduan untuk penyebaran penyimpanan dengan SAP di Azure secara rinci dalam jenis Azure Storage untuk panduan beban kerja SAP
- Penyimpanan bersertifikat untuk SAP Mirip dengan jenis VM bersertifikat untuk penggunaan SAP, amati detail dalam catatan SAP 2015553 dan catatan SAP 2039619
- Storage desain untuk SAP pada Oracle Direkomendasikan desain penyimpanan untuk SAP di Oracle di Azure dalam dokumentasi berikut dengan panduan khusus tentang tata letak sistem file, rekomendasi ukuran disk, dan opsi penyimpanan lainnya.
- Menyimpan file Oracle Database Pada sistem file Linux ext4 atau xfs perlu digunakan untuk database, NTFS untuk penyebaran Windows. Oracle ASM juga didukung untuk penyebaran Oracle untuk Oracle Database 12c Release 2 dan yang lebih tinggi.
- Opsi untuk disk terkelola adalah menggunakan Azure NetApp Files untuk Oracle Database juga, detail yang dijelaskan dalam catatan SAP yang disebutkan di atas 2039619 dan Oracle pada dokumentasi Azure. Azure Files volume NFS tidak dimaksudkan untuk menyimpan file Oracle Database, tidak seperti Azure NetApp Files.
Ketersediaan Tinggi
Arsitektur di atas menggambarkan penyebaran yang sangat tersedia, dengan setiap lapisan aplikasi terkandung pada 2 komputer virtual atau lebih. Komponen berikut digunakan.
Load BalancerAzure Load Balancer digunakan untuk mendistribusikan lalu lintas ke komputer virtual di subnet SAP. 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. Dalam kluster
Set ketersediaan Set ketersediaan mendistribusikan server melalui infrastruktur fisik Azure, untuk menyebarkannya melalui kegagalan yang berbeda dan memperbarui domain 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 menempatkan simpul ASCS dalam set ketersediaan yang sama dengan server aplikasi atau database.
Anda dapat menyebarkan kumpulan ketersediaan Azure di Zona Ketersediaan Azure saat menggunakan grup penempatan kedekatan.
Zona ketersediaan Zona ketersediaan adalah lokasi yang dipisahkan secara fisik dalam wilayah Azure tertentu. Tujuan mereka adalah untuk lebih meningkatkan ketersediaan layanan. Karena potensi penempatan geografis dan jaringan, administrator memerlukan profil latensi jaringan yang jelas antara semua zona wilayah target sebelum mereka dapat menentukan penempatan sumber daya dengan latensi antar-zona 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.
Pertimbangkan faktor keputusan saat menyebarkan VM di antara zona ketersediaan untuk SAP. Penggunaan grup penempatan kedekatan dengan penyebaran zona ketersediaan perlu dievaluasi dan hanya digunakan untuk VM tingkat aplikasi.
Catatan
Zona Ketersediaan mendukung ketersediaan tinggi intra-wilayah, tetapi tidak efektif untuk DR. Jarak antara zona terlalu pendek. Wilayah DR umumnya harus berjarak setidaknya 100 mil dari wilayah utama.
Komponen spesifik Oracle VM Oracle Database disebarkan dalam set ketersediaan atau di zona ketersediaan yang berbeda. Setiap VM berisi penginstalan perangkat lunak database dan penyimpanan database lokal VM sendiri. Siapkan replikasi database sinkron melalui Oracle Data Guard di antara database untuk memastikan konsistensi dan memungkinkan waktu layanan RPO RTO & rendah jika terjadi kegagalan individual. Selain VM database, VM tambahan dengan Oracle Data Guard Observer diperlukan untuk penyiapan Oracle Data Guard Fast-Start Failover. VM pengamat Oracle memantau database dan status replikasi dan memfasilitasi failover database dengan cara otomatis, tanpa perlu manajer kluster apa pun. Manajemen replikasi database dapat bertaruh yang dilakukan kemudian menggunakan Oracle Data Guard Broker untuk kemudahan penggunaan.
Untuk detail tentang penyebaran Oracle Data Guard lihat
- Laporan resmi SAP - Menyiapkan Oracle 12c Data Guard untuk Pelanggan SAP
- Dokumentasi Oracle Data Guard di Azure
Arsitektur ini menggunakan alat Oracle asli tanpa penyiapan kluster aktual atau kebutuhan akan load balancer di tingkat database. Dengan konfigurasi Oracle Data Guard Fast-Start Failover dan SAP, proses failover otomatis dan aplikasi SAP terhubung kembali ke database utama baru jika terjadi failover. Berbagai solusi kluster pihak ke-3 ada sebagai alternatif, seperti SIOS Protection Suite atau Veritas InfoScale, detail penyebaran mana yang masing-masing dapat ditemukan dalam dokumentasi vendor pihak ke-3.
ORACLE RAC Oracle Real Application Cluster (RAC) saat ini tidak disertifikasi atau didukung oleh Oracle di Azure. Namun teknologi dan arsitektur Oracle Data Guard untuk ketersediaan tinggi dapat memberikan lingkungan SAP yang sangat tangguh dengan perlindungan terhadap rak, pusat data, atau gangguan layanan regional.
Tingkat NFS Untuk semua penyebaran SAP yang sangat tersedia, tingkat NFS tangguh diperlukan untuk digunakan, menyediakan volume NFS untuk direktori transportasi SAP, volume sapmnt untuk biner SAP serta volume lebih lanjut untuk instans (A)SCS dan ERS. Opsi untuk menyediakan tingkat NFS adalah
- Azure Files NFS dengan panduan zonal redundant storage (ZRS) - SLES dan RHEL
- Azure NetApp Files penyebaran volume NFS - Panduan SLES dan RHEL
- Kluster NFS berbasis VM - dua VM tambahan dengan penyimpanan lokal, direplikasi antara VM dengan DRBD (Perangkat Blok Terdistribusi Replikasi) - Panduan SLES dan RHEL
Kluster layanan pusat SAP Arsitektur referensi ini menjalankan Layanan Pusat pada VM diskrit. Layanan Pusat berpotensi menjadi titik kegagalan tunggal (SPOF) saat disebarkan ke satu mesin virtual. Untuk menerapkan solusi yang sangat tersedia, perangkat lunak manajemen kluster diperlukan yang mengotomatiskan failover instans (A)SCS dan ERS ke VM masing-masing. Karena ini sangat terikat dengan solusi NFS yang dipilih
Solusi kluster yang dipilih memerlukan mekanisme untuk memutuskan jika perangkat lunak atau infrastruktur tidak tersedia VM mana yang harus melayani layanan masing-masing. Dengan SAP di Azure, dua opsi tersedia untuk implementasi STONITH berbasis Linux - cara menangani VM atau aplikasi yang tidak responsif
- SUSE-Linux-onlySBD (Perangkat Blok STONITH) - menggunakan satu atau tiga VM tambahan yang berfungsi sebagai ekspor iSCSI dari perangkat blok kecil, yang diakses secara teratur oleh VM anggota kluster aktual, dua VM (A)SCS/ERS di kumpulan kluster ini. VM menggunakan pemasangan SBD ini untuk memberikan suara dan dengan demikian mencapai kuorum untuk keputusan kluster. Arsitektur yang terkandung di halaman ini TIDAK berisi 1 atau 3 VM SBD tambahan. RedHat tidak mendukung implementasi SBD apa pun di Azure dan dengan demikian opsi ini hanya tersedia untuk sistem operasi SUSE SLES.
- Azure Fence Agent - tanpa menggunakan VM tambahan, API manajemen Azure digunakan untuk pemeriksaan reguler untuk ketersediaan VM.
Panduan yang ditautkan dalam bagian tingkat NFS berisi langkah-langkah dan desain yang diperlukan untuk pilihan kluster masing-masing. Manajer kluster bersertifikat Azure pihak ketiga juga dapat digunakan untuk menyediakan ketersediaan tinggi layanan pusat SAP.
Kumpulan server aplikasi SAP Dua server aplikasi atau lebih di mana ketersediaan tinggi dicapai dengan permintaan penyeimbangan beban melalui server pesan SAP atau dispatcher web. Setiap server aplikasi independen dan tidak ada penyeimbangan beban jaringan yang diperlukan untuk kumpulan VM ini.
Kumpulan dispatcher web SAP Komponen Web Dispatcher digunakan sebagai load balancer untuk lalu lintas SAP di antara server aplikasi SAP. Untuk mencapai ketersediaan tinggi SAP Web Dispatcher, Azure Load Balancer menerapkan kluster failover atau penyiapan Web Dispatcher paralel.
Embedded Web Dispatcher pada (A)SCS adalah opsi khusus. Anda harus mempertimbangkan ukuran yang tepat karena beban kerja tambahan pada (A)SCS.
Untuk komunikasi yang terhubung ke internet, kami menyarankan solusi yang berdiri sendiri di jaringan sekitar (juga dikenal sebagai DMZ) untuk memenuhi masalah keamanan.
Windows penyebaran Dokumen ini, sebagaimana diawali pada awalnya, difokuskan terutama dengan penyebaran berbasis Linux. Untuk penggunaan dengan Windows, prinsip arsitektur yang sama berlaku dan tidak ada perbedaan arsitektur dengan Oracle antara Linux dan Windows.
Untuk bagian aplikasi SAP, lihat detail dalam panduan arsitektur Jalankan SAP NetWeaver di Windows di Azure.
Pertimbangan Pemulihan Bencana
Gambar - Arsitektur sistem SAP produksi di Oracle di Azure dengan AvZone dan DR
Unduh file Visio arsitektur ini.
Setiap tingkat dalam tumpukan aplikasi SAP menggunakan strategi DR yang berbeda.
Layanan pusat dan tingkat server aplikasi Layanan pusat SAP dan server aplikasi 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. Saat melindungi lingkungan berkluster dengan Azure Site Recovery, tindakan pra-skrip perlu disiapkan dalam skrip kustom, diuji dan diatur untuk dijalankan dalam rencana pemulihan Azure Site Recovery untuk mengubah atau menonaktifkan layanan kluster.
Tingkat NFS Dengan sebagian besar data penting bisnis yang terletak di dalam volume NFS bersama SAP pusat seperti direktori transportasi dan sapmnt, melindunginya untuk gangguan yang membutuhkan failover DR sangat penting. Tergantung pada arsitektur NFS yang dipilih, solusi yang berbeda dimungkinkan
- Replikasi berbasis file Dengan tingkat NFS yang disebarkan di berbagai wilayah tetapi tanpa replikasi berbasis layanan langsung, alat terikat VM seperti rsync dapat dijalankan sesuai jadwal untuk menjaga replikasi asinkron dari volume NFS wilayah sumber ke volume NFS wilayah target. Untuk Azure Files NFS, VM di wilayah utama (misalnya (A)SCS VM) dapat mengakses volume NFS yang terletak di wilayah lain melalui peering vnet global. Selama situasi failover DR, sakelar DNS dan/atau konfigurasi perlu dilakukan agar sistem SAP di wilayah DR terhubung ke volume NFS yang terletak di DR.
- Azure NetApp Files volume dapat dilindungi dengan replikasi penyimpanan otomatis dan asinkron. Replikasi lintas wilayah tersedia di antara pasangan wilayah tertentu. Alternatif saat berhadapan dengan wilayah yang tidak berada di pasangan wilayah tertentu adalah menggunakan replikasi berbasis file yang disebutkan sebelumnya, yang mengharuskan VM beroperasi di wilayah target dengan volume NetApp NFS yang dipasang dari wilayah yang sama, karena Azure NetApp Files tidak mengizinkan akses lintas wilayah volume NFS. Replikasi berbasis file dengan demikian VM-ke-VM antar wilayah, setiap wilayah pemasangan masing-masing volume NetApp NFS.
- Alat pencadangan pihak ke-3 Peralatan vendor lain menyediakan replikasi berbasis file antara volume NFS dari sumber dan target apa pun.
Tingkat database
Oracle Data Guard dalam mode asinkron adalah cara yang disarankan untuk mereplikasi Oracle Database antar wilayah. Dengan replikasi asinkron, perubahan log dilakukan pada wilayah utama sebelum tiba di database wilayah sekunder, jarak antara wilayah dengan demikian tidak lagi menjadi faktor dalam performa sistem SAP secara keseluruhan.
VM database target di wilayah DR dapat berukuran berkurang karena tidak memerlukan daya dan memori CPU tambahan untuk memberikan waktu respons SAP yang cepat, satu-satunya beban adalah penerapan perubahan dari replikasi database. Dalam rencana atau proses pemulihan apa pun, aktivitas ukuran ulang VM tersebut perlu direncanakan untuk atau langsung otomatis.
Cadangan
Pencadangan untuk Oracle di Azure dapat dicapai melalui beberapa cara
- Azure BackupAzure menyediakan dan memelihara skrip untuk Oracle Database, untuk memfasilitasi tindakan Oracle sebelum dan pasca eksekusi pencadangan.
- Azure Storage Memanfaatkan cadangan database berbasis file, misalnya dijadwalkan dengan alat BR SAP, untuk disimpan dan diberi versi sebagai file/direktori di Azure Blob NFS, Azure Blob, atau layanan penyimpanan Azure Files. Lihat detail ter dokumentasi cara mencapai data Oracle dan pencadangan log.
- Solusi pencadangan pihak ke-3 Lihat arsitektur penyedia penyimpanan cadangan Anda, mendukung Oracle di Azure.
Untuk VM non-database, Azure Backup untuk VM disarankan untuk melindungi VM aplikasi SAP dan infrastruktur sekitar seperti SAP Web Dispatcher.
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
Kontributor
Artikel ini dikelola oleh Microsoft. Awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Robert Biro | Arsitek Senior
Langkah berikutnya
Sumber daya terkait
Lihat artikel ini untuk informasi selengkapnya dan untuk contoh beban kerja SAP yang menggunakan beberapa teknologi yang sama: