Bagikan melalui

Topologi jaringan dan konektivitas untuk migrasi SAP

  • Artikel

Artikel ini dibangun berdasarkan pertimbangan dan rekomendasi yang ditentukan dalam area desain zona pendaratan Azure untuk topologi dan konektivitas jaringan. Panduan dalam artikel ini memeriksa pertimbangan desain utama dan praktik terbaik untuk jaringan dan konektivitas ke, dari, dan dalam penyebaran Microsoft Azure dan SAP. Karena SAP adalah platform misi penting, desain Anda juga harus mengikuti panduan tentang area desain zona pendaratan Azure.

Rencana untuk alamat IP

Paket untuk alamat IP di Azure sangat penting untuk memastikan bahwa:

  • Ruang alamat IP tidak tumpang tindih di lokasi lokal dan wilayah Azure.
  • Jaringan virtual berisi ruang alamat yang benar.
  • Rencana konfigurasi subnet terjadi terlebih dahulu.

Diagram arsitektur berikut menunjukkan pertimbangan jaringan di SAP pada akselerator zona pendaratan Azure:

Diagram pertimbangan jaringan di SAP pada akselerator zona pendaratan Azure.

Pertimbangan desain untuk implementasi SAP:

Anda dapat mendedikasikan dan mendelegasikan subnet ke layanan tertentu lalu membuat instans layanan tersebut dalam subnet tersebut. Meskipun Azure membantu Anda membuat beberapa subnet yang didelegasikan dalam jaringan virtual, Anda hanya dapat memiliki satu subnet yang didelegasikan dalam jaringan virtual untuk Azure NetApp Files. Jika Anda menggunakan lebih dari satu subnet yang didelegasikan untuk Azure NetApp Files, maka Anda tidak dapat membuat volume baru.

Kasus penggunaan:

Anda memerlukan subnet yang didelegasikan untuk mengimplementasikan Azure NetApp Files. Pendekatan ini populer untuk penyebaran SAP yang berbagi sistem file. Anda memerlukan subnet yang didelegasikan hanya untuk gateway aplikasi selama penyeimbangan beban atau untuk Kecerdasan Bisnis SAP BusinessObjects, yang merupakan server aplikasi web SAP penyeimbang beban.

Mengonfigurasi DNS dan resolusi nama untuk sumber daya lokal dan Azure

Domain Name System (DNS) adalah bagian penting dari arsitektur zona pendaratan Azure. Beberapa organisasi mungkin ingin menggunakan investasi mereka yang ada di DNS. Kebanyakan orang mungkin menganggap adopsi {i>cloud

Rekomendasi desain untuk implementasi SAP:

Gunakan rekomendasi kasus penggunaan berikut saat DNS atau nama virtual komputer virtual tidak berubah selama migrasi.

Kasus penggunaan:

  • Latar belakang DNS dan nama virtual menghubungkan banyak antarmuka sistem dalam lanskap SAP, dan pelanggan hanya kadang-kadang menyadari antarmuka yang didefinisikan pengembang dari waktu ke waktu. tantangan Koneksi ion muncul antara sistem ketika nama virtual atau DNS berubah setelah migrasi. Untuk kesederhanaan, kami sarankan Anda mempertahankan alias DNS.

  • Gunakan zona DNS yang berbeda untuk membedakan setiap lingkungan, termasuk kotak pasir, pengembangan, praproduksi, dan lingkungan produksi, satu sama lain. Salah satu pengecualian adalah untuk penyebaran SAP yang memiliki jaringan virtual mereka sendiri. Dalam skenario ini, zona DNS privat mungkin tidak diperlukan.

Menentukan topologi jaringan Azure

Zona pendaratan skala perusahaan mendukung dua topologi jaringan. Satu topologi didasarkan pada Azure Virtual WAN. Yang lain adalah topologi jaringan tradisional yang didasarkan pada arsitektur hub-and-spoke. Bagian ini menjelaskan konfigurasi dan praktik SAP yang direkomendasikan untuk kedua model penyebaran.

Gunakan topologi jaringan berdasarkan Virtual WAN jika organisasi Anda berencana untuk:

  • Sebarkan sumber daya di beberapa wilayah Azure dan sambungkan lokasi global Anda ke lingkungan Azure dan lokal.
  • Sepenuhnya mengintegrasikan penyebaran WAN yang ditentukan perangkat lunak dengan Azure.
  • Sebarkan hingga 2.000 beban kerja komputer virtual di semua jaringan virtual yang terhubung ke satu hub Virtual WAN.

Organisasi menggunakan Virtual WAN untuk memenuhi persyaratan interkonektivitas skala besar. Microsoft mengelola layanan ini, yang membantu mengurangi kompleksitas jaringan secara keseluruhan dan memodernisasi jaringan organisasi Anda.

Gunakan topologi jaringan Azure tradisional berdasarkan arsitektur hub-and-spoke jika organisasi Anda:

  • Rencana untuk menyebarkan sumber daya hanya di wilayah Azure tertentu.
  • Tidak memerlukan jaringan global yang saling terhubung.
  • Memiliki beberapa lokasi jarak jauh atau cabang per wilayah dan membutuhkan kurang dari 30 terowongan Internet Protocol Security (IPSec).
  • Memerlukan kontrol penuh dan granularitas untuk mengonfigurasi jaringan Azure Anda secara manual.

Rekomendasi desain untuk implementasi SAP:

  • Gunakan Virtual WAN untuk penyebaran Azure di jaringan baru, besar, atau global tempat Anda memerlukan konektivitas transit global di seluruh wilayah Azure dan lokasi lokal. Dengan mengambil pendekatan ini, Anda tidak perlu menyiapkan perutean transitif secara manual untuk jaringan Azure, dan Anda dapat mengikuti standar untuk penyebaran SAP di Azure.

  • Pertimbangkan untuk menyebarkan appliance virtual jaringan (NVA) antar wilayah hanya jika Anda menggunakan NVA mitra. NVA antar wilayah atau jaringan virtual tidak diperlukan jika NVA asli ada. Saat Anda menyebarkan teknologi jaringan mitra dan NVA, ikuti panduan vendor untuk mengidentifikasi konfigurasi yang bertentangan dengan jaringan Azure.

  • Virtual WAN mengelola konektivitas antara jaringan virtual spoke untuk topologi berbasis Virtual WAN, sehingga Anda tidak perlu menyiapkan rute yang ditentukan pengguna (UDR) atau NVA. Throughput jaringan maksimum untuk lalu lintas jaringan-ke-jaringan di hub virtual yang sama adalah 50 Gbps. Untuk mengatasi batasan bandwidth ini, zona pendaratan SAP dapat menggunakan peering jaringan virtual untuk terhubung ke zona pendaratan lainnya.

  • Baik topologi tidak mendukung penyebaran NVA antara aplikasi SAP dan server database.

  • Peering jaringan virtual lokal dan global menyediakan konektivitas dan merupakan pendekatan yang disukai untuk memastikan konektivitas antara zona pendaratan untuk penyebaran SAP di beberapa wilayah Azure.

Rencana untuk konektivitas internet masuk dan keluar

Bagian ini menjelaskan model konektivitas yang direkomendasikan untuk konektivitas masuk dan keluar ke dan dari internet publik. Layanan keamanan jaringan asli Azure seperti Azure Firewall, Azure Web Application Firewall di Azure Application Gateway, dan Azure Front Door adalah layanan yang dikelola sepenuhnya, sehingga Anda tidak dikenakan biaya operasional dan manajemen yang terkait dengan penyebaran infrastruktur.

Rekomendasi desain untuk implementasi SAP:

  • Untuk pelanggan yang memiliki jejak global, Azure Front Door memfasilitasi penyebaran SAP dengan menggunakan kebijakan Web Application Firewall untuk mengirimkan dan melindungi aplikasi HTTP dan HTTPS global di seluruh wilayah Azure.

  • Manfaatkan kebijakan Web Application Firewall di Azure Front Door saat Anda menggunakan Azure Front Door dan Application Gateway untuk melindungi aplikasi HTTP dan HTTPS. Blokir lalu lintas ke Application Gateway sehingga hanya menerima lalu lintas dari Azure Front Door.

  • Application Gateway dan Web Application Firewall memiliki batasan ketika Application Gateway berfungsi sebagai proksi terbalik untuk aplikasi web SAP. Karena SAP Web Dispatcher dan NetScaler lebih cerdas daripada Application Gateway, Anda perlu melakukan pengujian ekstensif jika Anda menggantinya dengan Application Gateway. Verifikasi status terbaru dan daftar semua skenario yang didukung, tidak didukung, diuji, dan tidak diuji, jika memungkinkan.

  • Gunakan {i>firewall

  • Untuk mencegah kebocoran data, gunakan Azure Private Link untuk mengakses sumber daya platform as a service (PaaS) dengan aman seperti Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2, dan Azure Data Factory. Titik akhir privat juga dapat membantu mengamankan lalu lintas antara jaringan virtual dan layanan seperti Azure Storage dan Azure Backup. Lalu lintas antara jaringan virtual Anda dan layanan yang mendukung titik akhir privat berjalan di seluruh jaringan global Microsoft, yang mencegah paparannya ke internet publik.

Menerapkan Azure ExpressRoute dengan ketersediaan tinggi

Azure ExpressRoute dirancang untuk ketersediaan tinggi untuk menyediakan konektivitas jaringan privat tingkat operator ke sumber daya Microsoft. Tidak ada satu titik kegagalan di jalur ExpressRoute dalam jaringan Microsoft. Untuk memaksimalkan ketersediaan, pelanggan dan segmen penyedia layanan sirkuit ExpressRoute Anda juga harus dibangun untuk ketersediaan tinggi.

Rekomendasi desain untuk implementasi SAP:

Menentukan persyaratan enkripsi jaringan

Bagian ini menjelajahi rekomendasi utama untuk mengenkripsi jaringan antara lingkungan lokal dan Azure dan di seluruh wilayah Azure.

Pertimbangan desain untuk implementasi SAP:

  • Lalu lintas tidak dienkripsi secara default saat Anda menggunakan ExpressRoute untuk mengonfigurasi peering privat.

  • Anda tidak perlu mengenkripsi lalu lintas melalui ExpressRoute untuk penyebaran SAP. Lalu lintas SAP biasanya mengonsumsi banyak {i>bandwidth

  • Pelanggan menentukan apakah lalu lintas SAP harus dienkripsi. Untuk mempelajari selengkapnya tentang opsi enkripsi jaringan di zona pendaratan skala perusahaan, lihat Topologi dan konektivitas jaringan.

Memisahkan sistem

Ada lingkungan yang berbeda, termasuk lingkungan pengembangan, pengujian, kualitas, praproduksi, dan produksi, dalam skenario SAP, dan pelanggan cenderung mengategorikan sistem ini ke dalam konstruksi logis atau fisik untuk menegakkan standar keamanan dan kepatuhan. Idenya adalah mengelola semua sistem yang memiliki siklus hidup yang sama dalam satu grup sumber daya umum. Anda dapat menentukan grup ini di berbagai tingkatan, seperti di tingkat langganan atau grup sumber daya.

Organisasi Anda juga harus mempertimbangkan struktur keamanan dan kebijakan saat mengelompokkan sumber daya dalam lanskap SAP. Namun, agar transportasi SAP mengalir antara lingkungan pengembangan, pengujian, kualitas, dan produksi, organisasi Anda mungkin memerlukan:

  • Peering jaringan virtual.
  • Pembukaan port firewall antar jaringan virtual.
  • Aturan UDR dan kelompok keamanan jaringan (NSG).

Kami tidak menyarankan Agar Anda menghosting sistem manajemen database (DBMS) dan lapisan aplikasi sistem SAP di jaringan virtual yang berbeda dan menghubungkannya dengan menggunakan peering jaringan virtual. Lalu lintas jaringan yang berlebihan antara lapisan dapat menambah biaya besar.

Rekomendasi tambahan untuk implementasi SAP:

  • Baik topologi tidak mendukung penempatan lapisan aplikasi SAP dan SAP DBMS di jaringan virtual Azure yang berbeda yang tidak di-peering.

  • Anda dapat menggunakan aturan kelompok keamanan aplikasi (ASG) dan NSG untuk menentukan daftar kontrol akses keamanan jaringan antara aplikasi SAP dan lapisan DBMS. Anda dapat menambahkan komputer virtual ke ASG untuk membantu mengelola keamanannya.

  • Aktifkan jaringan terakselerasi Azure pada komputer virtual yang Anda gunakan di lapisan aplikasi SAP dan DBMS. Tingkat sistem operasi berikut mendukung jaringan yang dipercepat di Azure:

    • Windows Server 2012 R2 atau versi lebih baru
    • SUSE Linux Enterprise Desktop 12 SP3 atau yang lebih baru
    • Red Hat Enterprise Linux 7.4 atau yang lebih baru
    • Oracle Linux 7.5
      • Kernel yang kompatibel dengan Red Hat Enterprise Linux memerlukan rilis 3.10.0-862.13.1.el7.
      • Oracle Unbreakable Enterprise Kernel memerlukan rilis 5.

  • Pastikan Anda menyiapkan penyebaran internal untuk Azure Load Balancer untuk menggunakan fitur pengembalian server langsung. Fitur ini mengurangi latensi saat Anda menggunakan konfigurasi load balancer internal untuk konfigurasi ketersediaan tinggi pada lapisan DBMS.

  • Jika Anda menggunakan Load Balancer dengan sistem operasi tamu Linux, pastikan parameter jaringan net.ipv4.tcp_timestamps Linux diatur ke 0.

  • Untuk latensi jaringan yang optimal dengan aplikasi SAP, pertimbangkan untuk menggunakan grup penempatan kedekatan Azure.

  • Untuk proyek migrasi, pertimbangkan untuk menyetel parameter jaringan. Misalnya, Anda dapat meningkatkan performa dengan menonaktifkan pengakuan selama periode migrasi.

  • Jelajahi portal dukungan SAP dan SAP Note 2391465 untuk mempelajari lebih lanjut tentang menerapkan SAP.

Pertimbangan desain untuk implementasi RISE

Saat Anda menjalankan penyebaran SAP RISE di Azure, integrasi lingkungan yang dikelola SAP dengan ekosistem Azure Anda sendiri sangat penting. Untuk mempelajari selengkapnya tentang praktik dan panduan terbaik, lihat Mengintegrasikan Azure dengan beban kerja terkelola SAP RISE.

Implementasi SAP RISE biasanya memiliki dua opsi untuk konektivitas: VPN situs-ke-situs atau peering jaringan virtual. Jika Anda tidak memiliki beban kerja Azure sebelumnya, VPN situs-ke-situs mungkin menjadi opsi yang lebih mudah. Namun, jika Anda ingin mengadopsi Azure sebagai platform strategis, Anda dapat menyiapkan zona pendaratan Azure yang tepat dan menggunakan peering jaringan virtual ke penyewa SAP RISE. Untuk skenario ini, zona pendaratan yang disederhanakan seperti zona pendaratan Azure mungkin merupakan opsi yang baik. Anda dapat dengan mudah menyesuaikan pengalaman penyebaran siap pakai ini dengan kebutuhan Anda, khususnya parameter jaringan virtual.

Menyebarkan peering jaringan virtual lintas penyewa ke penyewa SAP RISE juga memerlukan lebih banyak pekerjaan. Anda perlu merencanakan arsitektur jaringan virtual dengan hati-hati untuk memastikan tidak ada rentang Perutean Antar-Domain Tanpa Kelas yang tumpang tindih. Anda juga harus melakukan peer DNS dengan benar ke penyewa SAP RISE.

Pertimbangkan batasan dan batasan jika Anda memutuskan untuk menyiapkan solusi Virtual WAN dan memerlukan koneksi VPN situs-ke-situs atau ExpressRoute.