Bagikan melalui

Arsitektur lanskap SAP

Azure Virtual Machines
Microsoft Azure Virtual Network
Azure Files
Penyeimbang Beban Azure

Artikel ini menyediakan praktik terbaik untuk merancang seluruh lanskap SAP di Azure. Lanskap SAP mencakup beberapa sistem SAP di seluruh hub, produksi, non-produksi, dan lingkungan pemulihan bencana. Kami memberikan rekomendasi yang berfokus pada desain jaringan dan bukan sistem SAP tertentu. Tujuannya adalah untuk memberikan rekomendasi kami untuk merancang lanskap SAP yang aman, berkinerja tinggi, dan tangguh.

Sistem

Diagram yang memperlihatkan sampel lanskap SAP secara keseluruhan di Azure.

Unduh file Visio arsitektur.

Alur kerja

  1. Jaringan lokal: Koneksi ExpressRoute dari jaringan lokal ke wilayah Azure yang terhubung.
  2. Hub regional langganan Azure: Langganan Azure yang berisi layanan pusat untuk seluruh perusahaan, bukan hanya SAP. Langganan hub menyediakan layanan pusat dan konektivitas dengan melakukan peering ke jaringan virtual spoke yang berisi beban kerja SAP.
  3. Jaringan virtual hub: Jaringan virtual berbicara untuk hub pusat di wilayah utama atau wilayah A.
  4. Hub jaringan virtual di wilayah pemulihan bencana (DR): Jaringan virtual berbicara untuk hub pusat di wilayah pemulihan bencana. Ini mencerminkan desain subnet jaringan virtual produksi di wilayah utama.
  5. Langganan Azure SAP non-produksi: Langganan Azure untuk semua beban kerja SAP non-produksi. Ini termasuk pra-produksi, jaminan kualitas, pengembangan, dan lingkungan kotak pasir.
  6. Jaringan virtual spoke non-produksi SAP: Memisahkan jaringan virtual untuk beban kerja non-produksi SAP di wilayah utama. Setiap lingkungan SAP memiliki jaringan virtual dan subnetnya sendiri.
  7. Produksi SAP langganan Azure: Langganan Azure untuk semua beban kerja SAP produksi.
  8. Jaringan virtual spoke produksi SAP: Jaringan virtual untuk lingkungan produksi SAP dengan beberapa subnet. Jaringan virtual ini berada di wilayah utama.
  9. Jaringan virtual spoke (DR) pemulihan bencana produksi SAP: Jaringan virtual untuk produksi SAP di wilayah sekunder pemulihan bencana. Ini mencerminkan desain subnet jaringan virtual produksi di wilayah utama.
  10. Layanan Azure: Pengambilan sampel layanan Azure yang dapat Anda sambungkan ke lanskap SAP.
  11. SAP Business Technology Platform (BTP): Lingkungan SAP mengakses Platform Teknologi Bisnis SAP melalui Azure Private Link.

Langganan Azure

Sebaiknya gunakan desain jaringan hub-spoke. Dengan desain hub-spoke, Anda memerlukan setidaknya tiga langganan untuk membagi lingkungan SAP Anda. Anda harus memiliki langganan untuk (1) jaringan virtual hub regional, (2) jaringan virtual non-produksi, dan (3) jaringan virtual produksi. Langganan menyediakan batas penagihan, kebijakan, dan keamanan. Tidak ada jumlah langganan yang benar. Jumlah langganan yang Anda gunakan tergantung pada kebutuhan penagihan, kebijakan, dan keamanan Anda. Secara umum, Anda ingin menghindari penggunaan terlalu banyak langganan. Terlalu banyak langganan dapat menambahkan overhead manajemen dan kompleksitas jaringan yang tidak diperlukan. Misalnya, Anda tidak memerlukan langganan untuk setiap sistem SAP. Arsitektur kami menggunakan tiga langganan:

  • Hub regional: Langganan hub virtual Azure tempat jaringan virtual hub ada untuk wilayah utama dan sekunder. Langganan ini untuk semua layanan pusat dan bukan hanya SAP.

  • Non-produksi SAP: Langganan non-produksi Azure SAP di mana sistem non-produksi, termasuk kotak pasir, pengembangan, jaminan kualitas, atau sistem pra-produksi, berada.

  • Produksi SAP: Langganan produksi Azure SAP tempat kami mengonfigurasi sistem produksi dan pemulihan bencana.

Untuk informasi selengkapnya, lihat:

Desain jaringan

Topologi hub-spoke adalah desain jaringan yang direkomendasikan untuk lanskap SAP. Dalam topologi ini, jaringan virtual hub produksi bertindak sebagai titik pusat konektivitas. Ini terhubung ke jaringan lokal dan berbagai jaringan virtual spoke dan memungkinkan pengguna dan aplikasi mengakses beban kerja SAP. Dalam topologi hub-spoke ini, berikut adalah rekomendasi kami untuk desain jaringan SAP.

Gunakan ExpressRoute untuk koneksi lokal. Untuk beban kerja SAP, sebaiknya gunakan ExpressRoute untuk menyambungkan jaringan lokal ke jaringan virtual Hub dan jaringan virtual Hub DR. Anda dapat menggunakan topologi Azure virtual WAN jika Anda memiliki lokasi global. Pertimbangkan untuk menyiapkan VPN situs-ke-situs (S2S) sebagai cadangan ke Azure ExpressRoute atau persyaratan rute pihak ketiga apa pun.

Untuk informasi selengkapnya, lihat:

Gunakan satu jaringan virtual per lingkungan. Sebaiknya gunakan satu jaringan virtual per lingkungan (tingkat penyebaran SAP). Arsitektur ini menggunakan jaringan virtual yang berbeda untuk produksi, pengembangan, jaminan kualitas, dan sandbox. Desain jaringan ini sangat ideal untuk arsitektur perusahaan besar.

Gunakan firewall pusat. Semua lalu lintas jaringan ke jaringan virtual spoke, termasuk koneksi panggilan fungsi jarak jauh (RFC), harus melewati firewall pusat di jaringan virtual Hub. Komunikasi jaringan antara jaringan virtual spoke (komunikasi spoke-to-spoke) melewati firewall jaringan virtual hub di subnet Azure Firewall dari jaringan virtual Hub. Demikian pula, komunikasi jaringan antara jaringan virtual spoke dan jaringan lokal juga melewati firewall jaringan virtual hub. Kami menggunakan peering jaringan virtual untuk menghubungkan berbagai jaringan virtual spoke ke jaringan virtual hub. Semua komunikasi antara jaringan virtual spoke melewati firewall jaringan virtual Hub. Anda juga dapat menggunakan appliance virtual jaringan alih-alih firewall. Untuk informasi selengkapnya, lihat appliance virtual jaringan.

Lalu lintas jaringan yang tetap berada di jaringan virtual tidak boleh melewati firewall. Misalnya, jangan letakkan firewall antara subnet aplikasi SAP dan subnet database SAP. Tidak didukung untuk menempatkan firewall atau peralatan virtual jaringan (NVA) antara aplikasi SAP dan lapisan sistem manajemen database (DBMS) sistem SAP yang menjalankan kernel SAP. Melakukannya akan berdampak negatif pada latensi jaringan untuk semua akses database dan sangat berdampak pada performa SAP.

Hindari jaringan virtual spoke peering. Peering jaringan virtual antara jaringan virtual spoke harus dihindari jika memungkinkan. Peering jaringan virtual spoke-to-spoke memungkinkan komunikasi spoke-to-spoke untuk melewati firewall jaringan virtual Hub. Anda hanya boleh mengonfigurasi peering jaringan virtual spoke-to-spoke ketika Anda memiliki persyaratan bandwidth tinggi, misalnya, dengan replikasi database antara lingkungan SAP. Semua lalu lintas jaringan lainnya harus berjalan melalui jaringan virtual Hub dan firewall. Untuk informasi selengkapnya, lihat koneksi internet masuk dan keluar untuk SAP di Azure.

Subnet

Ini adalah praktik terbaik untuk membagi setiap lingkungan SAP (produksi, pra-produksi, pengembangan, kotak pasir) menjadi subnet dan menggunakan subnet untuk mengelompokkan layanan terkait. Berikut adalah rekomendasi kami untuk subnet lanskap SAP.

Jumlah subnet

Jaringan virtual produksi dalam arsitektur memiliki lima subnet. Desain ini sangat ideal untuk solusi perusahaan besar. Jumlah subnet bisa kurang atau lebih. Jumlah sumber daya di jaringan virtual harus menentukan jumlah subnet di jaringan virtual.

Ukuran subnet

Pastikan subnet memiliki ruang alamat jaringan yang memadai. Jika Anda menggunakan nama host virtual SAP, Anda memerlukan lebih banyak ruang alamat di subnet SAP Anda. Seringkali setiap instans SAP memerlukan 2-3 alamat IP dan menyertakan satu alamat IP untuk nama host komputer virtual. Layanan Azure lainnya mungkin memerlukan subnet khusus mereka sendiri saat disebarkan di jaringan virtual beban kerja SAP.

Subnet aplikasi

Subnet aplikasi berisi komputer virtual yang menjalankan server aplikasi SAP, SAP Central Services (ASCS), SAP Enqueue Replication Services (ERS), dan instans SAP Web Dispatcher. Subnet juga berisi titik akhir privat ke Azure Files. Dalam diagram, kami mengelompokkan komputer virtual berdasarkan peran. Sebaiknya gunakan set skala komputer virtual dengan orkestrasi fleksibel yang dikombinasikan dengan zona ketersediaan untuk penyebaran yang tangguh. Untuk informasi selengkapnya, lihat langkah berikutnya.

Subnet database

Subnet database menyimpan komputer virtual yang menjalankan database. Dalam diagram, sepasang komputer virtual dengan replikasi sinkron mewakili semua komputer virtual database dari satu lingkungan SAP.

Subnet perimeter

Subnet perimeter menghadap internet dan menyertakan subnet perimeter SAP dan subnet Application Gateway. Berikut adalah rekomendasi kami untuk merancang kedua subnet ini.

Subnet perimeter SAP: Subnet perimeter SAP adalah jaringan perimeter yang berisi aplikasi yang terhubung ke internet seperti SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent, dan Application Gateway. Layanan ini memiliki dependensi pada sistem SAP yang harus disebarkan, dikelola, dan dikonfigurasi oleh tim SAP. Tim IT pusat tidak boleh mengelola layanan di subnet perimeter SAP. Untuk alasan ini, Anda harus menempatkan layanan ini di jaringan virtual spoke SAP dan bukan jaringan virtual Hub. Diagram arsitektur hanya menunjukkan jaringan perimeter SAP produksi. Ini tidak memiliki subnet perimeter SAP di jaringan virtual non-produksi. Beban kerja dalam langganan SAP non-produksi menggunakan layanan di subnet perimeter SAP.

Anda dapat membuat subnet perimeter SAP set terpisah dalam langganan non-produksi. Kami hanya merekomendasikan pendekatan ini untuk beban kerja atau beban kerja penting yang sering berubah. Perimeter SAP non-produksi khusus sangat membantu untuk pengujian dan penyebaran fitur baru. Aplikasi atau aplikasi yang kurang penting yang hanya akan memiliki beberapa modifikasi dari waktu ke waktu tidak memerlukan subnet perimeter SAP non-produksi terpisah.

Subnet Application Gateway: Azure Application Gateway memerlukan subnetnya sendiri. Gunakan untuk mengizinkan lalu lintas dari Internet yang dapat digunakan layanan SAP, seperti SAP Fiori. Arsitektur yang direkomendasikan menempatkan Azure Application Gateway bersama dengan alamat IP publik ujung depannya di jaringan virtual Hub. Azure Application Gateway memerlukan setidaknya subnet ukuran /29. Kami merekomendasikan ukuran /27 atau lebih besar. Anda tidak dapat menggunakan kedua versi Application Gateway (v1 dan v2) di subnet yang sama. Untuk informasi selengkapnya, lihat subnet untuk Azure Application Gateway.

Tempatkan subnet perimeter di jaringan virtual terpisah untuk meningkatkan keamanan: Untuk peningkatan keamanan, Anda dapat menempatkan subnet perimeter SAP dan subnet Application Gateway di jaringan virtual terpisah dalam langganan produksi SAP. Jaringan virtual spoke perimeter SAP di-peering dengan jaringan virtual Hub, dan semua lalu lintas jaringan ke jaringan publik mengalir melalui jaringan virtual perimeter. Pendekatan alternatif ini menunjukkan Azure Application Gateway dengan alamat IP publiknya untuk koneksi masuk yang ditempatkan di jaringan virtual spoke untuk penggunaan SAP secara eksklusif.

Diagram yang menunjukkan aliran jaringan antara spoke jaringan virtual melalui jaringan virtual Hub.

Unduh file Visio termasuk arsitektur alternatif ini.

Desain jaringan ini memberikan kemampuan respons insiden yang lebih baik dan kontrol akses jaringan terperindas. Namun, ini juga meningkatkan kompleksitas manajemen, latensi jaringan, dan biaya penyebaran. Mari kita bahas setiap poin.

Respons insiden yang lebih baik: Jaringan virtual spoke perimeter SAP memungkinkan isolasi cepat layanan yang disusupi jika Anda mendeteksi pelanggaran. Anda dapat menghapus peering jaringan virtual dari jaringan virtual spoke perimeter SAP ke hub dan segera mengisolasi beban kerja perimeter SAP dan aplikasi jaringan virtual aplikasi SAP dari internet. Anda tidak ingin mengandalkan perubahan aturan kelompok keamanan jaringan (NSG) untuk respons insiden. Mengubah atau menghapus aturan NSG hanya memengaruhi koneksi baru dan tidak akan memotong koneksi berbahaya yang ada.

Kontrol akses jaringan terperinci: Jaringan virtual perimeter SAP menyediakan kontrol akses jaringan yang lebih ketat ke dan dari jaringan virtual spoke produksi SAP.

Peningkatan kompleksitas, latensi, dan biaya: Arsitektur meningkatkan kompleksitas manajemen, biaya, dan latensi. Komunikasi yang terikat internet dari jaringan virtual produksi SAP di-peering dua kali, sekali ke jaringan virtual Hub dan sekali lagi ke jaringan virtual perimeter SAP ke internet. Firewall di jaringan virtual Hub memiliki efek terbesar pada latensi. Sebaiknya ukur latensi untuk melihat apakah kasus penggunaan Anda dapat mendukungnya.

Untuk informasi selengkapnya, lihat praktik terbaik jaringan perimeter.

Subnet Azure NetApp Files

Jika Anda menggunakan NetApp Files, Anda harus memiliki subnet yang didelegasikan untuk menyediakan berbagi file sistem file jaringan (NFS) atau blok pesan server (SMB) untuk skenario SAP yang berbeda di Azure. Subnet /24 adalah ukuran default untuk subnet NetApp Files, tetapi Anda dapat mengubah ukurannya untuk memenuhi kebutuhan Anda. Gunakan persyaratan Anda sendiri untuk menentukan ukuran yang tepat. Untuk informasi selengkapnya, lihat subnet yang didelegasikan.

Keamanan subnet

Menggunakan subnet untuk mengelompokkan sumber daya SAP yang memiliki persyaratan aturan keamanan yang sama memudahkan pengelolaan keamanan.

Kelompok keamanan jaringan (NSG): Subnet memungkinkan Anda menerapkan grup keamanan jaringan di tingkat subnet. Mengelompokkan sumber daya dalam subnet yang sama yang memerlukan aturan keamanan yang berbeda memerlukan grup keamanan jaringan di tingkat subnet dan tingkat antarmuka jaringan. Dengan penyiapan dua tingkat ini, aturan keamanan dengan mudah bertentangan dan dapat menyebabkan masalah komunikasi tak terduga yang sulit di memecahkan masalah. Aturan NSG juga memengaruhi lalu lintas dalam subnet. Untuk informasi selengkapnya tentang NSG, lihat kelompok keamanan jaringan.

Kelompok keamanan aplikasi (ASG): Sebaiknya gunakan kelompok keamanan aplikasi untuk mengelompokkan antarmuka jaringan komputer virtual dan mereferensikan grup keamanan aplikasi dalam aturan kelompok keamanan jaringan. Konfigurasi ini memungkinkan pembuatan dan manajemen aturan yang lebih mudah untuk penyebaran SAP. Setiap antarmuka jaringan dapat termasuk dalam beberapa kelompok keamanan aplikasi dengan aturan kelompok keamanan jaringan yang berbeda. Untuk informasi selengkapnya, lihat kelompok keamanan aplikasi.

Sebaiknya gunakan Azure Private Link untuk meningkatkan keamanan komunikasi jaringan. Azure Private Link menggunakan titik akhir privat dengan alamat IP privat untuk berkomunikasi dengan layanan Azure. Azure Private Links menghindari pengiriman komunikasi jaringan melalui internet ke titik akhir publik. Untuk informasi selengkapnya, lihat titik akhir privat di layanan Azure.

Gunakan titik akhir privat di subnet aplikasi: Sebaiknya gunakan titik akhir privat untuk menyambungkan subnet aplikasi ke layanan Azure yang didukung. Dalam arsitektur, ada titik akhir privat untuk Azure Files di subnet Aplikasi dari setiap jaringan virtual. Anda dapat memperluas konsep ini ke layanan Azure yang didukung.

Gunakan Azure Private Link untuk SAP Business Technology Platform (BTP): Azure Private Link for SAP Business Technology Platform (BTP) sekarang tersedia secara umum. SAP Private Link Service mendukung koneksi dari SAP BTP, runtime Cloud Foundry, dan layanan lainnya. Contoh skenario termasuk SAP S/4HANA atau SAP ERP yang berjalan di komputer virtual. Mereka dapat tersambung ke layanan asli Azure seperti Azure Database for MySQL.

Arsitektur ini menggambarkan koneksi SAP Private Link Service dari lingkungan SAP BTP. Layanan Private Link SAP membangun koneksi privat antara layanan SAP BTP tertentu dan layanan tertentu di setiap jaringan sebagai akun penyedia layanan. Tautan privat memungkinkan layanan BTP mengakses lingkungan SAP Anda melalui koneksi jaringan privat. Ini meningkatkan keamanan dengan tidak menggunakan internet publik untuk berkomunikasi.

Untuk informasi selengkapnya, lihat:

Berbagi file sistem file jaringan (NFS) dan blok pesan server (SMB)

Sistem SAP sering bergantung pada volume sistem file jaringan atau pembagian blok pesan server. Berbagi file ini memindahkan file antara komputer virtual atau fungsi sebagai antarmuka file dengan aplikasi lain. Sebaiknya gunakan layanan Azure asli, seperti Azure Premium Files dan Azure NetApp Files, sebagai berbagi file sistem file jaringan (NFS) dan blok pesan server (SMB). Layanan Azure memiliki ketersediaan gabungan, ketahanan, dan perjanjian tingkat layanan (SLA) yang lebih baik daripada alat berbasis sistem operasi.

Untuk informasi selengkapnya, lihat:

Saat merancang solusi SAP Anda, Anda perlu mengukur volume berbagi file individual dengan benar dan mengetahui berbagi file sistem SAP mana yang terhubung. Ingatlah skalabilitas dan target performa layanan Azure selama perencanaan. Tabel berikut menguraikan berbagi file SAP umum dan memberikan deskripsi singkat dan penggunaan yang direkomendasikan di seluruh lingkungan SAP.

Nama berbagi Penggunaan Rekomendasi
sapmnt Direktori sistem, profil, dan global SAP terdistribusi Berbagi khusus untuk setiap sistem SAP, tidak ada penggunaan kembali
cluster Berbagi ketersediaan tinggi untuk ASCS, ERS, dan database per desain masing-masing Berbagi khusus untuk setiap sistem SAP, tidak ada penggunaan kembali
saptrans Direktori transportasi SAP Satu berbagi untuk satu atau beberapa lanskap SAP (ERP, Gudang Bisnis)
interface Pertukaran file dengan aplikasi non-SAP Persyaratan khusus pelanggan, berbagi file terpisah per lingkungan (produksi, non-produksi)

Anda hanya dapat berbagi saptrans antara lingkungan SAP yang berbeda, dan, dengan demikian, Anda harus mempertimbangkan penempatannya dengan hati-hati. Hindari mengonsolidasikan terlalu banyak sistem SAP ke dalam satu saptrans berbagi karena skalabilitas dan alasan performa.

Kebijakan keamanan perusahaan akan mendorong arsitektur dan pemisahan volume antar lingkungan. Direktori transportasi dengan pemisahan per lingkungan atau tingkat membutuhkan komunikasi RFC antara lingkungan SAP untuk memungkinkan grup transportasi SAP atau tautan domain transportasi. Untuk informasi selengkapnya, lihat:

Layanan data

Arsitektur berisi layanan data Azure yang membantu Anda memperluas dan meningkatkan platform data SAP Anda. Untuk membantu membuka wawasan bisnis, kami sarankan Anda menggunakan layanan seperti Azure Synapse Analytics, Azure Data Factory, dan Azure Data Lake Storage. Layanan data ini membantu Anda menganalisis dan memvisualisasikan data SAP dan data non-SAP.

Untuk banyak skenario integrasi data, runtime integrasi diperlukan. Runtime integrasi Azure adalah infrastruktur komputasi yang digunakan alur Azure Data Factory dan Azure Synapse Analytics untuk menyediakan kemampuan integrasi data. Kami merekomendasikan penyebaran komputer virtual runtime untuk layanan ini untuk setiap lingkungan secara terpisah. Untuk informasi selengkapnya, lihat:

Layanan Bersama

Solusi SAP mengandalkan layanan bersama. Load balancer dan gateway aplikasi adalah contoh layanan yang digunakan beberapa sistem SAP. Arsitektur tetapi kebutuhan organisasi Anda harus menentukan bagaimana Anda merancang layanan bersama Anda. Berikut panduan umum yang harus Anda ikuti.

Load balancer: Kami merekomendasikan satu penyeimbang beban per sistem SAP. Konfigurasi ini membantu meminimalkan kompleksitas. Anda ingin menghindari terlalu banyak kumpulan dan aturan pada satu penyeimbang beban. Konfigurasi ini juga memastikan penamaan dan penempatan selaras dengan sistem SAP dan grup sumber daya. Setiap sistem SAP dengan arsitektur ketersediaan tinggi (HA) berkluster harus memiliki setidaknya satu penyeimbang beban. Arsitektur ini menggunakan satu load balancer untuk komputer virtual ASCS dan load balancer kedua untuk komputer virtual database. Beberapa database mungkin tidak memerlukan load balancer untuk membuat penyebaran ketersediaan tinggi. SAP Hana tidak. Periksa dokumentasi khusus database untuk detail selengkapnya.

Application Gateway: Kami merekomendasikan setidaknya satu gateway aplikasi per lingkungan SAP (produksi, non-produksi, dan kotak pasir) kecuali kompleksitas dan jumlah sistem yang terhubung terlalu tinggi. Anda dapat menggunakan gateway aplikasi untuk beberapa sistem SAP untuk mengurangi kompleksitas karena tidak semua sistem SAP di lingkungan memerlukan akses masuk dari Internet. Gateway aplikasi tunggal dapat melayani beberapa port dispatcher web untuk satu sistem SAP S/4HANA atau digunakan oleh sistem SAP yang berbeda.

Komputer virtual SAP Web Dispatcher: Arsitektur menunjukkan kumpulan dua atau lebih VM SAP Web Dispatcher. Kami menyarankan agar Anda tidak menggunakan kembali komputer virtual SAP Web Dispatcher di antara sistem SAP yang berbeda. Memisahkannya memungkinkan Anda untuk mengukur komputer virtual Web Dispatcher untuk memenuhi kebutuhan setiap sistem SAP. Untuk solusi SAP yang lebih kecil, sebaiknya sematkan layanan Web Dispatcher dalam instans ASCS.

Layanan SAP: Layanan SAP seperti SAProuter, Cloud Connector, dan Analytics Cloud Agent, disebarkan berdasarkan persyaratan aplikasi, baik secara terpusat maupun terpisah. Tidak ada rekomendasi tentang penggunaan kembali antara sistem SAP karena beragam persyaratan pelanggan. Keputusan utama untuk dibuat disebutkan di bagian jaringan, jika dan kapan subnet perimeter SAP untuk non-produksi harus digunakan. Jika tidak, hanya dengan subnet perimeter produksi untuk SAP, layanan perimeter SAP dikonsumsi oleh seluruh lanskap SAP.

Pemulihan dari bencana

Pemulihan bencana (DR) membahas persyaratan untuk kelangsungan bisnis jika wilayah Azure utama tidak tersedia atau disusupi. Dari perspektif lanskap SAP secara keseluruhan dan ditunjukkan dalam diagram, berikut adalah rekomendasi kami untuk desain pemulihan bencana.

Gunakan rentang alamat IP yang berbeda Jaringan virtual hanya mencakup satu wilayah Azure. Solusi pemulihan bencana apa pun harus menggunakan wilayah yang berbeda. Anda perlu membuat jaringan virtual yang berbeda di wilayah sekunder. Jaringan virtual di lingkungan DR memerlukan rentang alamat IP yang berbeda untuk mengaktifkan sinkronisasi database melalui teknologi asli database.

Layanan pusat dan konektivitas ke lokal: Konektivitas ke layanan pusat lokal dan utama (DNS atau firewall) harus tersedia di wilayah pemulihan bencana. Ketersediaan dan perubahan konfigurasi layanan IT pusat perlu menjadi bagian dari rencana pemulihan bencana Anda. Layanan IT pusat adalah komponen utama untuk lingkungan SAP yang berfungsi.

Gunakan Azure Site Recovery Azure Site Recovery mereplikasi dan melindungi disk terkelola dan konfigurasi komputer virtual untuk server aplikasi ke wilayah DR.

Pastikan ketersediaan berbagi file: SAP bergantung pada ketersediaan berbagi file utama. Pencadangan atau replikasi berbagi file berkelanjutan diperlukan untuk menyediakan data pada berbagi file ini dengan kehilangan data minimal dalam skenario DR.

Replikasi database Azure Site Recovery tidak dapat melindungi server database SAP karena tingkat perubahan yang tinggi dan kurangnya dukungan database oleh layanan. Anda perlu mengonfigurasi replikasi database berkelanjutan dan asinkron ke wilayah pemulihan bencana.

Untuk informasi selengkapnya, lihat gambaran umum pemulihan bencana dan panduan infrastruktur untuk beban kerja SAP.

Arsitektur SAP yang lebih kecil

Untuk solusi SAP yang lebih kecil, mungkin bermanfaat untuk menyederhanakan desain jaringan. Setiap jaringan virtual lingkungan SAP kemudian akan menjadi subnet di dalam jaringan virtual gabungan tersebut. Setiap penyederhanaan kebutuhan desain jaringan dan langganan dapat memengaruhi keamanan. Anda harus mengevaluasi kembali perutean jaringan, akses ke dan dari jaringan publik, akses ke layanan bersama (berbagi file), dan mengakses layanan Azure lainnya. Berikut adalah beberapa opsi untuk menyusutkan arsitektur untuk memenuhi kebutuhan organisasi dengan lebih baik.

Gabungkan aplikasi SAP dan subnet database menjadi satu. Anda dapat menggabungkan subnet aplikasi dan database untuk membuat satu jaringan SAP besar. Desain jaringan ini mencerminkan banyak jaringan SAP lokal. Kombinasi kedua subnet ini membutuhkan perhatian yang lebih tinggi terhadap keamanan subnet dan aturan kelompok keamanan jaringan. Grup keamanan aplikasi penting saat menggunakan subnet tunggal untuk aplikasi SAP dan subnet database.

Gabungkan subnet perimeter SAP dan subnet aplikasi. Anda dapat menggabungkan subnet perimeter dan subnet aplikasi SAP. Perhatian yang tinggi harus ditempatkan pada aturan kelompok keamanan jaringan dan penggunaan kelompok keamanan aplikasi. Kami hanya merekomendasikan pendekatan penyederhanaan ini untuk kawasan SAP kecil.

Gabungkan jaringan virtual spoke SAP antara lingkungan SAP yang berbeda Arsitektur menggunakan jaringan virtual yang berbeda untuk setiap lingkungan SAP (hub, produksi, non-produksi, dan pemulihan bencana). Tergantung pada ukuran lanskap SAP Anda, Anda dapat menggabungkan jaringan virtual spoke SAP menjadi lebih sedikit atau bahkan hanya satu spoke SAP. Anda masih perlu membagi antara lingkungan produksi dan non-produksi. Setiap lingkungan produksi SAP menjadi subnet dalam satu jaringan virtual produksi SAP. Setiap lingkungan non-produksi SAP menjadi subnet dalam satu jaringan virtual non-produksi SAP.

Kontributor

Microsoft mempertahankan artikel ini. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Langkah berikutnya