Merencanakan dan menerapkan penyebaran SAP di Azure

  • Artikel

Di Azure, organisasi bisa mendapatkan sumber daya dan layanan cloud yang mereka butuhkan tanpa menyelesaikan siklus pengadaan yang panjang. Tetapi menjalankan beban kerja SAP Anda di Azure memerlukan pengetahuan tentang opsi yang tersedia dan perencanaan yang cermat untuk memilih komponen dan arsitektur Azure untuk mendukung solusi Anda.

Azure menawarkan platform komprehensif untuk menjalankan aplikasi SAP Anda. Penawaran infrastruktur sebagai layanan (IaaS) dan platform as a service (PaaS) Azure digabungkan untuk memberi Anda pilihan optimal untuk keberhasilan penyebaran seluruh lanskap perusahaan SAP Anda.

Artikel ini melengkapi dokumentasi SAP dan Catatan SAP, sumber utama untuk informasi tentang cara menginstal dan menyebarkan perangkat lunak SAP di Azure dan platform lainnya.

Definisi

Sepanjang artikel ini, kami menggunakan istilah berikut:

  • Komponen SAP: Aplikasi SAP individual seperti SAP S/4HANA, SAP ECC, SAP BW, atau SAP Solution Manager. Komponen SAP dapat didasarkan pada teknologi Advanced Business Application Programming (ABAP) atau Java tradisional, atau dapat menjadi aplikasi yang tidak didasarkan pada SAP NetWeaver, seperti SAP BusinessObjects.
  • Lingkungan SAP: Beberapa komponen SAP yang dikelompokkan secara logis untuk melakukan fungsi bisnis, seperti pengembangan, jaminan kualitas, pelatihan, pemulihan bencana, atau produksi.
  • Lanskap SAP: Seluruh set aset SAP dalam lanskap IT organisasi. Lanskap SAP mencakup semua lingkungan produksi dan non-produksi.
  • Sistem SAP: Kombinasi lapisan sistem manajemen database (DBMS) dan lapisan aplikasi. Dua contohnya adalah sistem pengembangan SAP ERP dan sistem pengujian SAP BW. Dalam penyebaran Azure, kedua lapisan ini tidak dapat didistribusikan antara lokal dan Azure. Sistem SAP harus disebarkan secara lokal atau disebarkan di Azure. Namun, Anda dapat mengoperasikan sistem yang berbeda dalam lanskap SAP baik di Azure atau lokal.

Sumber

Titik masuk untuk dokumentasi yang menjelaskan cara menghosting dan menjalankan beban kerja SAP di Azure adalah Mulai menggunakan SAP di komputer virtual Azure. Dalam artikel, Anda menemukan tautan ke artikel lain yang membahas:

  • Beban kerja SAP khusus untuk penyimpanan, jaringan, dan opsi yang didukung.
  • Panduan SAP DBMS untuk berbagai sistem DBMS di Azure.
  • Panduan penyebaran SAP, baik manual maupun otomatis.
  • Detail ketersediaan tinggi dan pemulihan bencana untuk beban kerja SAP di Azure.
  • Integrasi dengan SAP di Azure dengan layanan lain dan aplikasi pihak ketiga.

Penting

Untuk prasyarat, proses penginstalan, dan detail tentang fungsionalitas SAP tertentu, penting untuk membaca dokumentasi dan panduan SAP dengan hati-hati. Artikel ini hanya membahas tugas tertentu untuk perangkat lunak SAP yang diinstal dan dioperasikan pada komputer virtual (VM) Azure.

Catatan SAP berikut membentuk dasar panduan Azure untuk penyebaran SAP:

Nomor catatan Judul
1928533 Aplikasi SAP di Azure: Produk dan Ukuran yang Didukung
2015553 SAP di Azure: Prasyarat Dukungan
2039619 Aplikasi SAP di Azure menggunakan Oracle Database
2233094 DB6: Aplikasi SAP di Azure Menggunakan IBM Db2 untuk Linux, UNIX, dan Windows
1999351 Pemecahan masalah Pemantauan Azure yang Disempurnakan untuk SAP
1409604 Virtualisasi pada Windows: Pemantauan yang Ditingkatkan
2191498 SAP di Linux dengan Azure: Pemantauan yang ditingkatkan
2731110 Dukungan Network Virtual Appliances (NVA) untuk SAP di Azure

Untuk batasan default umum dan maksimum langganan dan sumber daya Azure, lihat Batas, kuota, dan batasan langganan dan layanan Azure.

Skenario

Layanan SAP sering dianggap sebagai salah satu aplikasi paling penting misi di perusahaan. Arsitektur dan operasi aplikasi bersifat kompleks, dan penting untuk memastikan bahwa semua persyaratan untuk ketersediaan dan performa terpenuhi. Perusahaan biasanya berpikir dengan cermat tentang penyedia cloud mana yang harus dipilih untuk menjalankan proses bisnis yang penting bagi bisnis tersebut.

Azure adalah platform cloud publik yang ideal untuk aplikasi SAP dan proses bisnis yang penting bagi bisnis. Sebagian besar perangkat lunak SAP saat ini, termasuk sistem SAP NetWeaver dan SAP S/4HANA, dapat dihosting di infrastruktur Azure saat ini. Azure menawarkan lebih dari 800 jenis CPU dan VM yang memiliki banyak terabyte memori.

Untuk deskripsi skenario yang didukung dan beberapa skenario yang tidak didukung, lihat Skenario yang didukung SAP di Azure VM. Periksa skenario ini dan kondisi yang ditunjukkan sebagai tidak didukung saat Anda merencanakan arsitektur yang ingin Anda sebarkan ke Azure.

Agar berhasil menyebarkan sistem SAP ke Azure IaaS atau ke IaaS secara umum, penting untuk memahami perbedaan signifikan antara penawaran cloud privat tradisional dan penawaran IaaS. Host atau outsourcing tradisional mengadaptasi infrastruktur (jaringan, penyimpanan, dan jenis server) dengan beban kerja yang ingin dihosting pelanggan. Dalam penyebaran IaaS, pelanggan atau mitra bertanggung jawab untuk mengevaluasi beban kerja potensial mereka dan memilih komponen Azure yang benar dari VM, penyimpanan, dan jaringan.

Untuk mengumpulkan data untuk merencanakan penyebaran Anda ke Azure, penting untuk:

  • Tentukan produk dan versi SAP apa yang didukung di Azure.
  • Evaluasi apakah rilis sistem operasi yang Anda rencanakan untuk digunakan didukung dengan Azure VM yang akan Anda pilih untuk produk SAP Anda.
  • Tentukan rilis DBMS apa pada VM tertentu yang didukung untuk produk SAP Anda.
  • Evaluasi apakah meningkatkan atau memperbarui lanskap SAP Anda diperlukan untuk menyelaraskan dengan sistem operasi yang diperlukan dan rilis DBMS untuk mencapai konfigurasi yang didukung.
  • Evaluasi apakah Anda perlu pindah ke sistem operasi yang berbeda untuk disebarkan di Azure.

Detail tentang komponen SAP yang didukung di Azure, unit infrastruktur Azure, dan rilis sistem operasi terkait dan rilis DBMS dijelaskan dalam perangkat lunak SAP yang didukung untuk penyebaran Azure. Pengetahuan yang Anda peroleh dari mengevaluasi dukungan dan dependensi antara rilis SAP, rilis sistem operasi, dan rilis DBMS memiliki dampak besar pada upaya Anda untuk memindahkan sistem SAP Anda ke Azure. Anda mempelajari apakah upaya persiapan yang signifikan terlibat, misalnya, apakah Anda perlu meningkatkan rilis SAP Atau beralih ke sistem operasi yang berbeda.

Langkah pertama untuk merencanakan penyebaran

Langkah pertama dalam perencanaan penyebaran bukan mencari VM yang tersedia untuk menjalankan aplikasi SAP.

Langkah pertama untuk merencanakan penyebaran adalah bekerja dengan tim kepatuhan dan keamanan di organisasi Anda untuk menentukan kondisi batas untuk menyebarkan jenis beban kerja SAP atau proses bisnis di cloud publik. Prosesnya bisa memakan waktu, tetapi dasar penting untuk diselesaikan.

Jika organisasi Anda telah menyebarkan perangkat lunak di Azure, prosesnya mungkin mudah. Jika perusahaan Anda lebih pada awal perjalanan, diskusi yang lebih besar mungkin diperlukan untuk mengetahui kondisi batas, kondisi keamanan, dan arsitektur perusahaan yang memungkinkan data SAP tertentu dan proses bisnis SAP dihosting di cloud publik.

Rencana untuk kepatuhan

Untuk daftar penawaran kepatuhan Microsoft yang dapat membantu Anda merencanakan kebutuhan kepatuhan Anda, lihat Penawaran kepatuhan Microsoft.

Merencanakan keamanan

Untuk informasi tentang masalah keamanan khusus SAP, seperti enkripsi data untuk data tidak aktif atau enkripsi lain dalam layanan Azure, lihat Gambaran umum enkripsi Azure dan Keamanan untuk lanskap SAP Anda.

Mengatur sumber daya Azure

Bersama dengan tinjauan keamanan dan kepatuhan, jika Anda belum melakukan tugas ini, rencanakan cara Anda mengatur sumber daya Azure Anda. Proses ini mencakup pengambilan keputusan tentang:

  • Konvensi penamaan yang Anda gunakan untuk setiap sumber daya Azure, seperti untuk VM dan grup sumber daya.
  • Langganan dan desain grup manajemen untuk beban kerja SAP Anda, seperti apakah beberapa langganan harus dibuat per beban kerja, per tingkat penyebaran, atau untuk setiap unit bisnis.
  • Penggunaan Azure Policy di seluruh perusahaan untuk langganan dan grup manajemen.

Untuk membantu Anda membuat keputusan yang tepat, banyak detail arsitektur perusahaan dijelaskan dalam Azure Cloud Adoption Framework.

Jangan meremehkan fase awal proyek dalam perencanaan Anda. Hanya ketika Anda memiliki perjanjian dan aturan yang berlaku untuk kepatuhan, keamanan, dan organisasi sumber daya Azure jika Anda memajukan perencanaan penyebaran Anda.

Langkah selanjutnya adalah merencanakan penempatan geografis dan arsitektur jaringan yang Anda sebarkan di Azure.

Geografi dan wilayah Azure

Layanan Azure tersedia dalam wilayah Azure terpisah. Wilayah Azure adalah kumpulan pusat data. Pusat data berisi perangkat keras dan infrastruktur yang menghosting dan menjalankan layanan Azure yang tersedia di wilayah tersebut. Infrastruktur ini mencakup sejumlah besar simpul yang berfungsi sebagai simpul komputasi atau simpul penyimpanan, atau yang menjalankan fungsionalitas jaringan.

Untuk daftar wilayah Azure, lihat Geografi Azure. Untuk peta interaktif, lihat Infrastruktur global Azure.

Tidak semua wilayah Azure menawarkan layanan yang sama. Bergantung pada produk SAP yang ingin Anda jalankan, persyaratan ukuran Anda, dan sistem operasi dan DBMS yang Anda butuhkan, ada kemungkinan bahwa wilayah tertentu tidak menawarkan jenis VM yang diperlukan untuk skenario Anda. Misalnya, jika Anda menjalankan SAP Hana, Anda biasanya memerlukan VM dari berbagai keluarga VM seri M. Keluarga VM ini hanya disebarkan di subset wilayah Azure.

Saat Anda mulai merencanakan dan memikirkan wilayah mana yang akan dipilih sebagai wilayah utama dan akhirnya wilayah sekunder, Anda perlu menyelidiki apakah layanan yang Anda butuhkan untuk skenario Anda tersedia di wilayah yang Anda pertimbangkan. Anda dapat mempelajari dengan tepat jenis VM, jenis penyimpanan Azure, dan layanan Azure lainnya yang tersedia di setiap wilayah di Produk yang tersedia menurut wilayah.

Wilayah berpasangan Azure

Di wilayah berpasangan Azure, replikasi data tertentu diaktifkan secara default antara dua wilayah. Untuk informasi selengkapnya, lihat Replikasi lintas wilayah di Azure: Kelangsungan bisnis dan pemulihan bencana.

Replikasi data dalam pasangan wilayah terkait dengan jenis penyimpanan Azure yang dapat Anda konfigurasi untuk direplikasi ke wilayah yang dipasangkan. Untuk detailnya, lihat Redundansi penyimpanan di wilayah sekunder.

Jenis penyimpanan yang mendukung replikasi data wilayah yang dipasangkan adalah jenis penyimpanan yang tidak cocok untuk komponen SAP dan beban kerja DBMS. Kegunaan replikasi penyimpanan Azure terbatas pada Azure Blob Storage (untuk tujuan pencadangan), berbagi file dan volume, dan skenario penyimpanan latensi tinggi lainnya.

Saat Anda memeriksa wilayah berpasangan dan layanan yang ingin Anda gunakan di wilayah utama atau sekunder, ada kemungkinan bahwa layanan Azure atau jenis VM yang ingin Anda gunakan di wilayah utama Anda tidak tersedia di wilayah berpasangan yang ingin Anda gunakan sebagai wilayah sekunder. Atau Anda mungkin menentukan bahwa wilayah berpasangan Azure tidak dapat diterima untuk skenario Anda karena alasan kepatuhan data. Untuk skenario tersebut, Anda perlu menggunakan wilayah yang tidak berpasangan sebagai wilayah sekunder atau pemulihan bencana, dan Anda perlu menyiapkan beberapa replikasi data sendiri.

Zona ketersediaan

Banyak wilayah Azure menggunakan zona ketersediaan untuk memisahkan lokasi secara fisik dalam wilayah Azure. Setiap zona ketersediaan terdiri dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan independen. Contoh penggunaan zona ketersediaan untuk meningkatkan ketahanan adalah menyebarkan dua VM di dua zona ketersediaan terpisah di Azure. Contoh lain adalah menerapkan kerangka kerja ketersediaan tinggi untuk sistem SAP DBMS Anda di satu zona ketersediaan dan menyebarkan SAP (A)SCS di zona ketersediaan lain, sehingga Anda mendapatkan SLA terbaik di Azure.

Untuk informasi selengkapnya tentang SLA VM di Azure, periksa versi terbaru SLA Komputer Virtual. Karena wilayah Azure berkembang dan berkembang dengan cepat, topologi wilayah Azure, jumlah pusat data fisik, jarak antara pusat data, dan jarak antara zona ketersediaan Azure berevolusi. Latensi jaringan berubah saat infrastruktur berubah.

Ikuti panduan dalam konfigurasi beban kerja SAP dengan zona ketersediaan Azure saat Anda memilih wilayah yang memiliki zona ketersediaan. Tentukan juga model penyebaran zona mana yang paling cocok untuk kebutuhan Anda, wilayah yang Anda pilih, dan beban kerja Anda.

Domain kesalahan

Domain kesalahan mewakili unit fisik kegagalan. Domain kesalahan terkait erat dengan infrastruktur fisik yang terkandung dalam pusat data. Meskipun bilah atau rak fisik dapat dianggap sebagai domain kesalahan, tidak ada pemetaan langsung satu-ke-satu antara elemen komputasi fisik dan domain kesalahan.

Saat Anda menyebarkan beberapa VM sebagai bagian dari satu sistem SAP, Anda dapat secara tidak langsung memengaruhi pengontrol fabric Azure untuk menyebarkan VM Anda ke domain kesalahan yang berbeda, sehingga Anda dapat memenuhi persyaratan untuk SLA ketersediaan. Namun, Anda tidak memiliki kontrol langsung atas distribusi domain kesalahan melalui unit skala Azure (kumpulan ratusan simpul komputasi atau simpul penyimpanan dan jaringan) atau penugasan VM ke domain kesalahan tertentu. Untuk memanuver pengontrol fabric Azure untuk menyebarkan sekumpulan VM melalui domain kesalahan yang berbeda, Anda perlu menetapkan ketersediaan Azure yang diatur ke VM pada waktu penyebaran. Untuk informasi selengkapnya, lihat Set ketersediaan.

Domain Pembaruan

Domain pembaruan mewakili unit logis yang mengatur bagaimana VM dalam sistem SAP yang terdiri dari beberapa VM diperbarui. Ketika pembaruan platform terjadi, Azure melalui proses memperbarui domain pembaruan ini satu per satu. Dengan menyebarkan VM pada waktu penyebaran melalui domain pembaruan yang berbeda, Anda dapat melindungi sistem SAP Anda dari potensi waktu henti. Mirip dengan domain kesalahan, unit skala Azure dibagi menjadi beberapa domain pembaruan. Untuk memanuver pengontrol fabric Azure untuk menyebarkan sekumpulan VM melalui domain pembaruan yang berbeda, Anda perlu menetapkan ketersediaan Azure yang diatur ke VM pada waktu penyebaran. Untuk informasi selengkapnya, lihat Set ketersediaan.

Diagram that depicts update domains and failure domains.

Kumpulan ketersediaan

Azure VM dalam satu set ketersediaan Azure didistribusikan oleh pengontrol fabric Azure melalui domain kesalahan yang berbeda. Distribusi melalui domain kesalahan yang berbeda adalah untuk mencegah semua VM sistem SAP dimatikan selama pemeliharaan infrastruktur atau jika kegagalan terjadi dalam satu domain kesalahan. Secara default, VM bukan bagian dari set ketersediaan. Anda dapat menambahkan VM dalam set ketersediaan hanya pada waktu penyebaran atau saat VM disebarkan ulang.

Untuk mempelajari selengkapnya tentang set ketersediaan Azure dan bagaimana set ketersediaan terkait dengan domain kesalahan, lihat Kumpulan ketersediaan Azure.

Penting

Zona ketersediaan dan set ketersediaan di Azure saling eksklusif. Anda dapat menyebarkan beberapa VM ke zona ketersediaan tertentu atau ke set ketersediaan. Tetapi tidak baik zona ketersediaan maupun set ketersediaan dapat ditetapkan ke VM.

Anda dapat menggabungkan set ketersediaan dan zona ketersediaan jika Anda menggunakan grup penempatan kedekatan.

Saat Anda menentukan set ketersediaan dan mencoba mencampur berbagai VM dari keluarga VM yang berbeda dalam satu set ketersediaan, Anda mungkin mengalami masalah yang mencegah Anda menyertakan jenis VM tertentu dalam set ketersediaan. Alasannya adalah bahwa set ketersediaan terikat ke unit skala yang berisi jenis host komputasi tertentu. Jenis host komputasi tertentu hanya dapat berjalan pada jenis keluarga VM tertentu.

Misalnya, Anda membuat set ketersediaan, dan Anda menyebarkan VM pertama dalam set ketersediaan. VM pertama yang Anda tambahkan ke set ketersediaan ada di keluarga VM Edsv5. Ketika Anda mencoba menyebarkan VM kedua, VM yang ada di keluarga M, penyebaran ini gagal. Alasannya adalah bahwa VM keluarga Edsv5 tidak berjalan pada perangkat keras host yang sama dengan VM dalam keluarga M.

Masalah yang sama dapat terjadi jika Anda mengubah ukuran VM. Jika Anda mencoba memindahkan VM dari keluarga Edsv5 dan ke jenis VM yang ada di keluarga M, penyebaran gagal. Jika Anda mengubah ukuran ke keluarga VM yang tidak dapat dihosting pada perangkat keras host yang sama, Anda harus mematikan semua VM yang ada di set ketersediaan Anda dan mengubah ukuran semuanya agar dapat berjalan pada jenis komputer host lainnya. Untuk informasi tentang SLA VM yang disebarkan dalam set ketersediaan, lihat SLA Komputer Virtual.

Set skala komputer virtual dengan orkestrasi fleksibel

Set skala komputer virtual dengan orkestrasi fleksibel menyediakan pengelompokan logis komputer virtual yang dikelola platform. Anda memiliki opsi untuk membuat set skala dalam wilayah atau menjangkaunya di seluruh zona ketersediaan. Saat membuat, skala fleksibel yang ditetapkan dalam wilayah dengan platformFaultDomainCount>1 (FD>1), VM yang disebarkan dalam set skala akan didistribusikan di sejumlah domain kesalahan tertentu di wilayah yang sama. Di sisi lain, membuat skala fleksibel yang ditetapkan di seluruh zona ketersediaan dengan platformFaultDomainCount=1 (FD=1) akan mendistribusikan VM di seluruh zona yang ditentukan dan set skala juga akan mendistribusikan VM di berbagai domain kesalahan dalam zona dengan upaya terbaik.

Untuk beban kerja SAP hanya set skala fleksibel dengan FD=1 yang didukung. Keuntungan menggunakan set skala fleksibel dengan FD=1 untuk penyebaran lintas zona, alih-alih penyebaran zona ketersediaan tradisional adalah bahwa VM yang disebarkan dengan set skala akan didistribusikan di berbagai domain kesalahan dalam zona dengan cara upaya terbaik. Untuk mempelajari selengkapnya tentang penyebaran beban kerja SAP dengan set skala, lihat panduan penyebaran skala komputer virtual yang fleksibel.

Saat menyebarkan beban kerja SAP ketersediaan tinggi di Azure, penting untuk mempertimbangkan berbagai jenis penyebaran yang tersedia, dan bagaimana mereka dapat diterapkan di berbagai wilayah Azure (seperti di seluruh zona, dalam satu zona, atau di wilayah tanpa zona). Untuk informasi selengkapnya, lihat Opsi penyebaran ketersediaan tinggi untuk beban kerja SAP.

Tip

Saat ini tidak ada cara langsung untuk memigrasikan beban kerja SAP yang disebarkan dalam set ketersediaan atau Zona ketersediaan ke skala fleksibel dengan FD=1. Untuk beralih, Anda perlu membuat ulang VM dan disk dengan batasan zona dari sumber daya yang ada. Proyek sumber terbuka menyertakan fungsi PowerShell yang dapat Anda gunakan sebagai sampel untuk mengubah VM yang disebarkan dalam set ketersediaan atau zona ketersediaan ke set skala fleksibel dengan FD=1. Posting blog menunjukkan kepada Anda cara memodifikasi sistem HA atau non-HA SAP yang disebarkan di set ketersediaan atau zona ketersediaan ke set skala fleksibel dengan FD=1.

Grup penempatan terdekat

Latensi jaringan antara masing-masing VM SAP dapat memiliki implikasi yang signifikan untuk performa. Waktu pulang pergi jaringan antara server aplikasi SAP dan DBMS terutama dapat berdampak signifikan pada aplikasi bisnis. Secara optimal, semua elemen komputasi yang menjalankan VM SAP Anda terletak sedekat mungkin. Opsi ini tidak dimungkinkan dalam setiap kombinasi, dan Azure mungkin tidak tahu VM mana yang harus disatukan. Di sebagian besar situasi dan wilayah, penempatan default memenuhi persyaratan latensi pulang pergi jaringan.

Ketika penempatan default tidak memenuhi persyaratan pulang pergi jaringan dalam sistem SAP, grup penempatan kedekatan dapat mengatasi kebutuhan ini. Anda dapat menggunakan grup penempatan kedekatan dengan batasan lokasi wilayah Azure, zona ketersediaan, dan ketersediaan yang diatur untuk meningkatkan ketahanan. Dengan grup penempatan kedekatan, menggabungkan zona ketersediaan dan ketersediaan yang ditetapkan sambil mengatur domain pembaruan dan kegagalan yang berbeda dimungkinkan. Grup penempatan kedekatan hanya boleh berisi satu sistem SAP.

Meskipun penyebaran dalam grup penempatan kedekatan dapat menghasilkan penempatan yang paling dioptimalkan latensi, menyebarkan dengan menggunakan grup penempatan kedekatan juga memiliki kelemahan. Beberapa keluarga VM tidak dapat digabungkan dalam satu grup penempatan kedekatan, atau Anda mungkin mengalami masalah jika Anda mengubah ukuran antara keluarga VM. Batasan keluarga VM, wilayah, dan zona ketersediaan mungkin tidak mendukung kolokasi. Untuk detailnya, dan untuk mempelajari tentang keuntungan dan tantangan potensial menggunakan grup penempatan kedekatan, lihat Skenario grup penempatan kedekatan.

VM yang tidak menggunakan grup penempatan kedekatan harus menjadi metode penyebaran default dalam sebagian besar situasi untuk sistem SAP. Default ini terutama berlaku untuk penyebaran zonal (zona ketersediaan tunggal) dan lintas zona (VM yang didistribusikan antara dua zona ketersediaan) dari sistem SAP. Menggunakan grup penempatan kedekatan harus terbatas pada sistem SAP dan wilayah Azure jika diperlukan hanya karena alasan performa.

Jaringan Azure

Azure memiliki infrastruktur jaringan yang memetakan ke semua skenario yang mungkin ingin Anda terapkan dalam penyebaran SAP. Di Azure, Anda memiliki kemampuan berikut:

  • Akses ke layanan Azure dan akses ke port tertentu di VM yang digunakan aplikasi.
  • Akses langsung ke VM melalui Secure Shell (SSH) atau Windows Remote Desktop (RDP) untuk manajemen dan administrasi.
  • Komunikasi internal dan resolusi nama antara VM dan oleh layanan Azure.
  • Konektivitas lokal antara jaringan lokal dan jaringan Azure.
  • Komunikasi antara layanan yang disebarkan di wilayah Azure yang berbeda.

Untuk informasi terperinci tentang jaringan, lihat Azure Virtual Network.

Merancang jaringan biasanya adalah aktivitas teknis pertama yang Anda jalankan saat Anda menyebarkan ke Azure. Mendukung arsitektur perusahaan pusat seperti SAP sering kali merupakan bagian dari persyaratan jaringan secara keseluruhan. Dalam tahap perencanaan, Anda harus mendokumen arsitektur jaringan yang diusulkan sedetail mungkin. Jika Anda membuat perubahan di titik selanjutnya, seperti mengubah alamat jaringan subnet, Anda mungkin harus memindahkan atau menghapus sumber daya yang disebarkan.

Jaringan virtual Azure

Jaringan virtual adalah blok penyusun dasar untuk jaringan privat Anda di Azure. Anda dapat menentukan rentang alamat jaringan dan memisahkan rentang menjadi subnet jaringan. Subnet jaringan dapat tersedia untuk digunakan VM SAP atau dapat didedikasikan untuk layanan atau tujuan tertentu. Beberapa layanan Azure, seperti Azure Virtual Network dan Azure Application Gateway, memerlukan subnet khusus.

Jaringan virtual bertindak sebagai batas jaringan. Bagian dari desain yang diperlukan saat Anda merencanakan penyebaran adalah menentukan jaringan virtual, subnet, dan rentang alamat jaringan privat. Anda tidak dapat mengubah penetapan jaringan virtual untuk sumber daya seperti kartu antarmuka jaringan (NIC) untuk VM setelah VM disebarkan. Membuat perubahan pada jaringan virtual atau ke rentang alamat subnet mungkin mengharuskan Anda memindahkan semua sumber daya yang disebarkan ke subnet yang berbeda.

Desain jaringan Anda harus memenuhi beberapa persyaratan untuk penyebaran SAP:

  • Tidak ada appliance virtual jaringan, seperti firewall, yang ditempatkan di jalur komunikasi antara aplikasi SAP dan lapisan DBMS produk SAP melalui kernel SAP, seperti S/4HANA atau SAP NetWeaver.
  • Pembatasan perutean jaringan diberlakukan oleh kelompok keamanan jaringan (NSG) pada tingkat subnet. IP grup VM ke dalam kelompok keamanan aplikasi (ASG) yang dipertahankan dalam aturan NSG, dan menyediakan peran, tingkat, dan pengelompokan izin SID.
  • Aplikasi SAP dan VM database berjalan di jaringan virtual yang sama, dalam subnet yang sama atau berbeda dari satu jaringan virtual. Gunakan subnet yang berbeda untuk VM aplikasi dan database. Atau, gunakan aplikasi khusus dan DBMS ASG untuk mengelompokkan aturan yang berlaku untuk setiap jenis beban kerja dalam subnet yang sama.
  • Jaringan yang dipercepat diaktifkan pada semua kartu jaringan semua VM untuk beban kerja SAP jika memungkinkan secara teknis.
  • Pastikan akses aman untuk dependensi pada layanan pusat, termasuk untuk resolusi nama (DNS), manajemen identitas (domain Windows Server Active Directory/ID Microsoft Entra), dan akses administratif.
  • Berikan akses ke dan berdasarkan titik akhir publik, sesuai kebutuhan. Contohnya termasuk untuk manajemen Azure untuk operasi ClusterLabs Pacemaker dalam ketersediaan tinggi atau untuk layanan Azure seperti Azure Backup.
  • Gunakan beberapa NIC hanya jika diperlukan untuk membuat subnet yang ditunjuk yang memiliki rute dan aturan NSG mereka sendiri.

Untuk contoh arsitektur jaringan untuk penyebaran SAP, lihat artikel berikut ini:

Pertimbangan jaringan virtual

Beberapa konfigurasi jaringan virtual memiliki pertimbangan khusus yang harus diperhatikan.

  • Konfigurasi appliance virtual jaringan di jalur komunikasi antara lapisan aplikasi SAP dan lapisan DBMS komponen SAP dengan menggunakan kernel SAP, seperti S/4HANA atau SAP NetWeaver, tidak didukung.

    Peralatan virtual jaringan dalam jalur komunikasi dapat dengan mudah menggandakan latensi jaringan antara dua mitra komunikasi. Peralatan tersebut juga dapat membatasi throughput dalam jalur penting antara lapisan aplikasi SAP dan lapisan DBMS. Dalam beberapa skenario, appliance virtual jaringan dapat menyebabkan kluster Linux Pacemaker gagal.

    Jalur komunikasi antara lapisan aplikasi SAP dan lapisan DBMS harus merupakan jalur langsung. Pembatasan tidak termasuk aturan ASG dan NSG jika aturan ASG dan NSG memungkinkan jalur komunikasi langsung.

    Skenario lain di mana appliance virtual jaringan tidak didukung adalah:

  • Memisahkan lapisan aplikasi SAP dan lapisan DBMS ke dalam jaringan virtual Azure yang berbeda tidak didukung. Kami menyarankan agar Anda memisahkan lapisan aplikasi SAP dan lapisan DBMS dengan menggunakan subnet dalam jaringan virtual Azure yang sama alih-alih menggunakan jaringan virtual Azure yang berbeda.

    Jika Anda menyiapkan skenario yang tidak didukung yang memisahkan dua lapisan sistem SAP di jaringan virtual yang berbeda, kedua jaringan virtual harus di-peering.

    Lalu lintas jaringan antara dua jaringan virtual Azure yang di-peering tunduk pada biaya transfer. Setiap hari, volume besar data yang terdiri dari banyak terabyte dipertukarkan antara lapisan aplikasi SAP dan lapisan DBMS. Anda dapat dikenakan biaya besar jika lapisan aplikasi SAP dan lapisan DBMS dipisahkan antara dua jaringan virtual Azure yang di-peering.

Resolusi nama dan layanan domain

Mengatasi nama host ke alamat IP melalui DNS sering kali merupakan elemen penting untuk jaringan SAP. Anda memiliki banyak opsi untuk mengonfigurasi nama dan resolusi IP di Azure.

Seringkali, perusahaan memiliki solusi DNS pusat yang merupakan bagian dari arsitektur keseluruhan. Beberapa opsi untuk menerapkan resolusi nama di Azure secara asli, alih-alih dengan menyiapkan server DNS Anda sendiri, dijelaskan dalam Resolusi nama untuk sumber daya di jaringan virtual Azure.

Seperti halnya layanan DNS, mungkin ada persyaratan agar Direktori Aktif Windows Server dapat diakses oleh VM atau layanan SAP.

Penetapan alamat IP

Alamat IP untuk NIC tetap diklaim dan digunakan di seluruh keberadaan NIC VM. Aturan ini berlaku untuk penetapan IP dinamis dan statis. Tetap benar apakah VM berjalan atau dimatikan. Penetapan IP dinamis dirilis jika NIC dihapus, jika subnet berubah, atau jika metode alokasi berubah menjadi statis.

Dimungkinkan untuk menetapkan alamat IP tetap ke VM dalam jaringan virtual Azure. Alamat IP sering kali ditetapkan ulang untuk sistem SAP yang bergantung pada server DNS eksternal dan entri statis. Alamat IP tetap ditetapkan, baik sampai VM dan NIC-nya dihapus atau sampai alamat IP tidak ditetapkan. Anda perlu memperhitungkan jumlah keseluruhan VM (berjalan dan berhenti) ketika Anda menentukan rentang alamat IP untuk jaringan virtual.

Untuk informasi selengkapnya, lihat Membuat VM yang memiliki alamat IP privat statis.

Catatan

Anda harus memutuskan antara alokasi alamat IP statis dan dinamis untuk Azure VM dan NIC-nya. Sistem operasi tamu VM akan mendapatkan IP yang ditetapkan ke NIC saat VM boot. Anda tidak boleh menetapkan alamat IP statis dalam sistem operasi tamu ke NIC. Beberapa layanan Azure seperti Azure Backup mengandalkan fakta bahwa setidaknya NIC utama diatur ke DHCP dan bukan ke alamat IP statis di dalam sistem operasi. Untuk informasi selengkapnya, lihat Memecahkan masalah pencadangan Azure VM.

Alamat IP sekunder untuk virtualisasi nama host SAP

Setiap NIC Azure VM dapat memiliki beberapa alamat IP yang ditetapkan untuknya. IP sekunder dapat digunakan untuk nama host virtual SAP, yang dipetakan ke catatan DNS A atau catatan DNS PTR. Alamat IP sekunder harus ditetapkan ke konfigurasi IP Azure NIC. IP sekunder juga harus dikonfigurasi dalam sistem operasi secara statis karena IP sekunder sering tidak ditetapkan melalui DHCP. Setiap IP sekunder harus berasal dari subnet yang sama dengan yang terikat dengan NIC. IP sekunder dapat ditambahkan dan dihapus dari Azure NIC tanpa menghentikan atau membatalkan alokasi VM. Untuk menambahkan atau menghapus IP utama NIC, VM harus dibatalkan alokasinya.

Catatan

Pada konfigurasi IP sekunder, alamat IP mengambang azure load balancer tidak didukung. Load balancer Azure digunakan oleh arsitektur ketersediaan tinggi SAP dengan kluster Pacemaker. Dalam skenario ini, load balancer memungkinkan nama host virtual SAP. Untuk panduan umum tentang menggunakan nama host virtual, lihat Catatan SAP 962955.

Azure Load Balancer dengan VM yang menjalankan SAP

Load balancer biasanya digunakan dalam arsitektur ketersediaan tinggi untuk menyediakan alamat IP mengambang antara node kluster aktif dan pasif. Anda juga dapat menggunakan load balancer untuk satu VM untuk menyimpan alamat IP virtual untuk nama host virtual SAP. Menggunakan load balancer untuk satu VM adalah alternatif untuk menggunakan alamat IP sekunder pada NIC atau menggunakan beberapa NIC di subnet yang sama.

Load balancer standar memodifikasi jalur akses keluar default karena arsitekturnya aman secara default. VM yang berada di belakang load balancer standar mungkin tidak lagi dapat mencapai titik akhir publik yang sama. Beberapa contohnya adalah titik akhir untuk repositori pembaruan sistem operasi atau titik akhir publik layanan Azure. Untuk opsi untuk menyediakan konektivitas keluar, lihat Konektivitas titik akhir publik untuk VM dengan menggunakan load balancer standar Azure.

Tip

Load balancer dasar tidak boleh digunakan dengan arsitektur SAP apa pun di Azure. Load balancer dasar dijadwalkan untuk dihentikan.

Beberapa vNIC per VM

Anda dapat menentukan beberapa kartu antarmuka jaringan virtual (vNIC) untuk Azure VM, dengan setiap vNIC ditetapkan ke subnet apa pun di jaringan virtual yang sama dengan vNIC utama. Dengan kemampuan untuk memiliki beberapa vNIC, Anda dapat mulai menyiapkan pemisahan lalu lintas jaringan, jika perlu. Misalnya, lalu lintas klien dirutekan melalui vNIC utama dan beberapa admin atau lalu lintas back-end dirutekan melalui vNIC kedua. Tergantung pada sistem operasi dan gambar yang Anda gunakan, rute lalu lintas untuk NIC di dalam sistem operasi mungkin perlu diatur untuk perutean yang benar.

Jenis dan ukuran VM menentukan berapa banyak vNIC yang dapat ditetapkan VM. Untuk informasi tentang fungsionalitas dan pembatasan, lihat Menetapkan beberapa alamat IP ke VM dengan menggunakan portal Azure.

Menambahkan vNIC ke VM tidak meningkatkan bandwidth jaringan yang tersedia. Semua antarmuka jaringan berbagi bandwidth yang sama. Kami menyarankan agar Anda menggunakan beberapa NIC hanya jika VM perlu mengakses subnet privat. Kami merekomendasikan pola desain yang bergantung pada fungsionalitas NSG dan yang menyederhanakan persyaratan jaringan dan subnet. Desain harus menggunakan antarmuka jaringan seserang mungkin, dan optimal hanya satu. Pengecualian adalah peluasan skala HANA, di mana vNIC sekunder diperlukan untuk jaringan internal HANA.

Peringatan

Jika Anda menggunakan beberapa vNIC pada VM, kami sarankan Anda menggunakan subnet NIC utama untuk menangani lalu lintas jaringan pengguna.

Jaringan yang dipercepat

Untuk lebih mengurangi latensi jaringan antara Azure VM, kami sarankan Anda mengonfirmasi bahwa jaringan terakselerasi Azure diaktifkan pada setiap VM yang menjalankan beban kerja SAP. Meskipun jaringan yang dipercepat diaktifkan secara default untuk VM baru, sesuai daftar periksa penyebaran, Anda harus memverifikasi status. Manfaat jaringan yang dipercepat adalah performa jaringan dan latensi yang sangat ditingkatkan. Gunakan saat Anda menyebarkan Azure VM untuk beban kerja SAP pada semua VM yang didukung, terutama untuk lapisan aplikasi SAP dan lapisan SAP DBMS. Dokumentasi tertaut berisi dependensi dukungan pada versi sistem operasi dan instans VM.

Konektivitas lokal

Penyebaran SAP di Azure mengasumsikan bahwa arsitektur jaringan dan hub komunikasi di seluruh perusahaan berada di tempat untuk mengaktifkan konektivitas lokal. Konektivitas jaringan lokal sangat penting untuk memungkinkan pengguna dan aplikasi mengakses lanskap SAP di Azure untuk mengakses layanan organisasi pusat lainnya, seperti DNS pusat, domain, dan infrastruktur manajemen keamanan dan patch.

Anda memiliki banyak opsi untuk menyediakan konektivitas lokal untuk penyebaran SAP di Azure Anda. Penyebaran jaringan paling sering adalah topologi jaringan hub-spoke, atau ekstensi topologi hub-spoke, WAN virtual global.

Untuk penyebaran SAP lokal, kami sarankan Anda menggunakan koneksi privat melalui Azure ExpressRoute. Untuk beban kerja SAP yang lebih kecil, wilayah jarak jauh, atau kantor yang lebih kecil, konektivitas VPN lokal tersedia. Menggunakan ExpressRoute dengan koneksi situs-ke-situs VPN sebagai jalur failover adalah kombinasi yang mungkin dari kedua layanan.

Konektivitas internet keluar dan masuk

Lanskap SAP Anda memerlukan konektivitas ke internet, baik untuk menerima pembaruan repositori sistem operasi, untuk membuat koneksi ke aplikasi SAP SaaS di titik akhir publik mereka, atau untuk mengakses layanan Azure melalui titik akhir publiknya. Demikian pula, Anda mungkin diharuskan untuk menyediakan akses bagi klien Anda ke aplikasi SAP Fiori, dengan pengguna internet mengakses layanan yang disediakan oleh lanskap SAP Anda. Arsitektur jaringan SAP Anda mengharuskan Anda merencanakan jalur menuju internet dan untuk permintaan masuk apa pun.

Amankan jaringan virtual Anda dengan menggunakan aturan NSG, dengan menggunakan tag layanan jaringan untuk layanan yang diketahui, dan dengan membuat perutean dan alamat IP ke firewall Anda atau appliance virtual jaringan lainnya. Semua tugas atau pertimbangan ini adalah bagian dari arsitektur. Sumber daya dalam jaringan privat perlu dilindungi oleh firewall Lapisan 4 dan Lapisan 7 jaringan.

Jalur komunikasi dengan internet adalah fokus arsitektur praktik terbaik.

Azure VM untuk beban kerja SAP

Beberapa keluarga Azure VM sangat cocok untuk beban kerja SAP, dan beberapa lebih khusus untuk beban kerja SAP Hana. Cara menemukan jenis VM yang benar dan kemampuannya untuk mendukung beban kerja SAP Anda dijelaskan dalam Perangkat lunak SAP apa yang didukung untuk penyebaran Azure. Selain itu, SAP Note 1928533 mencantumkan semua VM Azure bersertifikat dan kemampuan performanya sebagaimana diukur oleh tolok ukur dan batasan SAP Application Performance Standard (SAPS), jika berlaku. Jenis VM yang disertifikasi untuk beban kerja SAP tidak menggunakan provisi berlebihan untuk sumber daya CPU dan memori.

Selain hanya melihat pilihan jenis VM yang didukung, Anda perlu memeriksa apakah jenis VM tersebut tersedia di wilayah tertentu berdasarkan Produk yang tersedia menurut wilayah. Setidaknya yang penting adalah menentukan apakah kemampuan berikut untuk VM sesuai dengan skenario Anda:

  • Sumber daya CPU dan memori
  • Bandwidth operasi input/output per detik (IOPS)
  • Kapabilitas jaringan
  • Jumlah maksimum disk yang dapat dipasang
  • Kemampuan untuk menggunakan jenis penyimpanan Azure tertentu

Untuk mendapatkan informasi ini untuk keluarga dan jenis FM tertentu, lihat Ukuran untuk komputer virtual di Azure.

Model harga untuk Azure VM

Untuk model harga VM, Anda dapat memilih opsi yang anda sukai untuk digunakan:

  • Model harga bayar sesuai penggunaan
  • Paket cadangan atau penghematan satu tahun
  • Paket cadangan atau penghematan tiga tahun
  • Model harga spot

Untuk mendapatkan informasi terperinci tentang harga VM untuk berbagai layanan Azure, sistem operasi, dan wilayah, lihat Harga komputer virtual.

Untuk mempelajari tentang harga dan fleksibilitas paket penghematan satu tahun dan tiga tahun dan instans cadangan, lihat artikel berikut:

Untuk informasi selengkapnya tentang harga spot, lihat Azure Spot Virtual Machines.

Harga untuk jenis VM yang sama mungkin bervariasi di antara wilayah Azure. Beberapa pelanggan mendapat manfaat dari penyebaran ke wilayah Azure yang lebih murah, sehingga informasi tentang harga menurut wilayah dapat membantu saat Anda merencanakan.

Azure juga menawarkan opsi untuk menggunakan host khusus. Menggunakan host khusus memberi Anda lebih banyak kontrol siklus patching untuk layanan Azure. Anda dapat menjadwalkan patching untuk mendukung jadwal dan siklus Anda sendiri. Penawaran ini khusus untuk pelanggan yang memiliki beban kerja yang tidak mengikuti siklus normal beban kerja. Untuk informasi selengkapnya, lihat Host khusus Azure.

Menggunakan host khusus Azure didukung untuk beban kerja SAP. Beberapa pelanggan SAP yang ingin memiliki kontrol lebih besar atas patching infrastruktur dan rencana pemeliharaan menggunakan host khusus Azure. Untuk informasi selengkapnya tentang cara Microsoft memelihara dan menambal infrastruktur Azure yang menghosting VM, lihat Pemeliharaan untuk komputer virtual di Azure.

Sistem operasi untuk VM

Saat Anda menyebarkan VM baru untuk lanskap SAP di Azure, baik untuk menginstal atau memigrasikan sistem SAP, penting untuk memilih sistem operasi yang benar untuk beban kerja Anda. Azure menawarkan banyak pilihan gambar sistem operasi untuk Linux dan Windows dan banyak opsi yang cocok untuk sistem SAP. Anda juga dapat membuat atau mengunggah gambar kustom dari lingkungan lokal Anda, atau Anda dapat menggunakan atau menggeneralisasi dari galeri gambar.

Untuk detail dan informasi tentang opsi yang tersedia:

Rencanakan infrastruktur pembaruan sistem operasi dan dependensinya untuk beban kerja SAP Anda, jika diperlukan. Pertimbangkan untuk menggunakan lingkungan penahapan repositori untuk menjaga semua tingkatan lanskap SAP (kotak pasir, pengembangan, praproduksi, dan produksi) sinkron dengan menggunakan versi patch dan pembaruan yang sama selama periode waktu pembaruan Anda.

VM Generasi 1 dan generasi 2

Di Azure, Anda dapat menyebarkan VM sebagai generasi 1 atau generasi 2. Dukungan untuk VM generasi 2 di Azure mencantumkan keluarga Azure VM yang dapat Anda sebarkan sebagai generasi 2. Artikel ini juga mencantumkan perbedaan fungsional antara VM generasi 1 dan generasi 2 di Azure.

Saat Anda menyebarkan VM, gambar sistem operasi yang Anda pilih menentukan apakah VM akan menjadi VM generasi 1 atau generasi 2. Versi terbaru dari semua gambar sistem operasi untuk SAP yang tersedia di Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux, dan Windows atau Oracle Enterprise Linux) tersedia di generasi 1 dan generasi 2. Penting untuk memilih gambar dengan hati-hati berdasarkan deskripsi gambar untuk menyebarkan pembuatan VM yang benar. Demikian pula, Anda dapat membuat gambar sistem operasi kustom sebagai generasi 1 atau generasi 2, dan memengaruhi generasi VM saat VM disebarkan.

Catatan

Kami menyarankan agar Anda menggunakan VM generasi 2 di semua penyebaran SAP Anda di Azure, terlepas dari ukuran VM. Semua Azure VM terbaru untuk SAP memiliki kemampuan generasi 2 atau hanya terbatas pada generasi 2. Beberapa keluarga VM saat ini hanya mendukung VM generasi 2. Beberapa keluarga VM yang akan segera tersedia mungkin hanya mendukung generasi 2.

Anda dapat menentukan apakah VM adalah generasi 1 atau hanya generasi 2 berdasarkan gambar sistem operasi yang dipilih. Anda tidak dapat mengubah VM yang ada dari satu generasi ke generasi lainnya.

Mengubah VM yang disebarkan dari generasi 1 ke generasi 2 tidak dimungkinkan di Azure. Untuk mengubah generasi VM, Anda harus menyebarkan VM baru yang merupakan generasi yang Anda inginkan dan menginstal ulang perangkat lunak Anda pada VM generasi baru. Perubahan ini hanya memengaruhi gambar VHD dasar VM dan tidak berdampak pada disk data atau berbagi Network File System (NFS) atau Server Message Block (SMB) yang terpasang. Disk data, berbagi NFS, atau berbagi SMB yang awalnya ditetapkan ke VM generasi 1 dapat dilampirkan ke VM generasi 2 baru.

Beberapa keluarga VM, seperti seri Mv2, hanya mendukung generasi 2. Persyaratan yang sama mungkin berlaku untuk keluarga VM baru di masa depan. Dalam skenario itu, VM generasi 1 yang ada tidak dapat diubah ukurannya untuk bekerja dengan keluarga VM baru. Selain persyaratan platform Azure generasi 2, komponen SAP Anda mungkin memiliki persyaratan yang terkait dengan generasi VM. Untuk mempelajari tentang persyaratan generasi 2 apa pun untuk keluarga VM yang Anda pilih, lihat Catatan SAP 1928533.

Batas performa untuk Azure VM

Sebagai cloud publik, Azure bergantung pada berbagi infrastruktur dengan cara yang aman di seluruh basis pelanggannya. Untuk mengaktifkan penskalaan dan kapasitas, batas performa ditentukan untuk setiap sumber daya dan layanan. Di sisi komputasi infrastruktur Azure, penting untuk mempertimbangkan batas yang ditentukan untuk setiap ukuran VM.

Setiap VM memiliki kuota yang berbeda pada disk dan throughput jaringan, jumlah disk yang dapat dilampirkan, apakah VM memiliki penyimpanan sementara lokal yang memiliki batas throughput dan IOPS sendiri, ukuran memori, dan berapa banyak vCPU yang tersedia.

Catatan

Saat Anda membuat keputusan tentang ukuran VM untuk solusi SAP di Azure, Anda harus mempertimbangkan batas performa untuk setiap ukuran VM. Kuota yang dijelaskan dalam dokumentasi mewakili nilai maksimum teoritis yang dapat dicapai. Batas performa IOPS per disk mungkin dicapai dengan nilai input/output kecil (I/O) (misalnya, 8 KB), tetapi mungkin tidak dicapai dengan nilai I/O besar (misalnya, 1 MB).

Seperti VM, batas performa yang sama ada untuk setiap jenis penyimpanan untuk beban kerja SAP dan untuk semua layanan Azure lainnya.

Saat Anda merencanakan dan memilih VM untuk digunakan dalam penyebaran SAP Anda, pertimbangkan faktor-faktor berikut:

  • Mulailah dengan persyaratan memori dan CPU. Pisahkan persyaratan SAPS untuk daya CPU ke bagian DBMS dan bagian aplikasi SAP. Untuk sistem yang ada, SAPS yang terkait dengan perangkat keras yang sering Anda gunakan dapat ditentukan atau diperkirakan berdasarkan Tolok Ukur Aplikasi Standar SAP yang ada. Untuk sistem SAP yang baru disebarkan, selesaikan latihan ukuran untuk menentukan persyaratan SAPS untuk sistem.

  • Untuk sistem yang ada, throughput I/O dan IOPS pada server DBMS harus diukur. Untuk sistem baru, latihan ukuran untuk sistem baru juga harus memberi Anda gambaran umum tentang persyaratan I/O di sisi DBMS. Jika Anda tidak yakin, Anda akhirnya perlu melakukan bukti konsep.

  • Bandingkan persyaratan SAPS untuk server DBMS dengan SAPS yang dapat disediakan oleh berbagai jenis VM Azure. Informasi tentang SAPS dari berbagai jenis Azure VM didokumentasikan dalam SAP Note 1928533. Fokusnya harus pada DBMS VM terlebih dahulu karena lapisan database adalah lapisan dalam sistem SAP NetWeaver yang tidak memperluas skala di sebagian besar penyebaran. Sebaliknya, lapisan aplikasi SAP dapat diskalakan. Panduan DBMS individual menjelaskan konfigurasi penyimpanan yang direkomendasikan.

  • Ringkas temuan Anda untuk:

    • Jumlah Azure VM yang anda harapkan untuk digunakan.
    • Keluarga VM individual dan SKU VM untuk setiap lapisan SAP: DBMS, (A)SCS, dan server aplikasi.
    • Throughput I/O mengukur atau menghitung persyaratan kapasitas penyimpanan.

Layanan Instans Besar HANA

Azure menawarkan kemampuan komputasi untuk menjalankan database HANA besar peningkatan atau peluasan skala pada penawaran khusus yang disebut SAP Hana di Instans Besar Azure. Penawaran ini memperluas VM yang tersedia di Azure.

Catatan

Layanan Instans Besar HANA dalam mode matahari terbenam dan tidak menerima pelanggan baru. Menyediakan unit untuk pelanggan Instans Besar HANA yang ada masih dimungkinkan.

Penyimpanan untuk SAP di Azure

Azure VM menggunakan berbagai opsi penyimpanan untuk persistensi. Dalam istilah sederhana, VM dapat dibagi menjadi jenis penyimpanan persisten dan sementara atau tidak persisten.

Anda dapat memilih dari beberapa opsi penyimpanan untuk beban kerja SAP dan untuk komponen SAP tertentu. Untuk informasi selengkapnya, lihat Penyimpanan Azure untuk beban kerja SAP. Artikel ini membahas arsitektur penyimpanan untuk setiap bagian SAP: sistem operasi, biner aplikasi, file konfigurasi, data database, file log dan pelacakan, dan antarmuka file dengan aplikasi lain, baik disimpan di disk atau diakses pada berbagi file.

Disk sementara pada VM

Sebagian besar Azure VM untuk SAP menawarkan disk sementara yang bukan disk terkelola. Gunakan disk sementara hanya untuk data yang dapat dibuang. Data pada disk sementara mungkin hilang selama peristiwa pemeliharaan yang tidak terduga atau selama penyebaran ulang VM. Karakteristik performa disk sementara membuatnya ideal untuk file pertukaran/halaman sistem operasi.

Tidak ada aplikasi atau data sistem operasi yang tidak dapat diskalakan yang harus disimpan pada disk sementara. Di lingkungan Windows, drive sementara biasanya diakses sebagai drive D. Dalam sistem Linux, titik pemasangan sering kali adalah perangkat /dev/sdb, /mnt, atau /mnt/resource.

Beberapa VM tidak menawarkan drive sementara. Jika Anda berencana menggunakan ukuran VM ini untuk SAP, Anda mungkin perlu meningkatkan ukuran disk sistem operasi. Untuk informasi selengkapnya, lihat catatan SAP 1928533. Untuk VM yang memiliki disk sementara, dapatkan informasi tentang ukuran disk sementara dan batas IOPS dan throughput untuk setiap seri VM dalam Ukuran untuk komputer virtual di Azure.

Anda tidak dapat langsung mengubah ukuran antara seri VM yang memiliki disk sementara dan seri VM yang tidak memiliki disk sementara. Saat ini, perubahan ukuran antara dua keluarga VM tersebut gagal. Resolusinya adalah membuat ulang VM yang tidak memiliki disk sementara dalam ukuran baru dengan menggunakan rekam jepret disk sistem operasi. Pertahankan semua disk data lain dan antarmuka jaringan. Pelajari cara mengubah ukuran VM yang memiliki disk sementara lokal ke ukuran VM yang tidak.

Berbagi dan volume jaringan untuk SAP

Sistem SAP biasanya memerlukan satu atau beberapa berbagi file jaringan. Berbagi file biasanya adalah salah satu opsi berikut:

  • Direktori transportasi SAP (/usr/sap/trans atau TRANSDIR).
  • Volume SAP atau volume sapmnt atau saploc bersama untuk menyebarkan beberapa server aplikasi.
  • Volume arsitektur ketersediaan tinggi untuk SAP (A)SCS, SAP ERS, atau database (/hana/shared).
  • Antarmuka file yang menjalankan aplikasi pihak ketiga untuk impor dan ekspor file.

Dalam skenario ini, kami sarankan Anda menggunakan layanan Azure, seperti Azure Files atau Azure NetApp Files. Jika layanan ini tidak tersedia di wilayah yang Anda pilih, atau jika tidak tersedia untuk arsitektur solusi Anda, alternatifnya adalah menyediakan berbagi file NFS atau SMB dari aplikasi yang dikelola sendiri, berbasis VM atau dari layanan pihak ketiga. Lihat Catatan SAP 2015553 tentang batasan dukungan SAP jika Anda menggunakan layanan pihak ketiga untuk lapisan penyimpanan dalam sistem SAP di Azure.

Karena sifat berbagi jaringan yang sering kritis, dan karena sering kali merupakan satu titik kegagalan dalam desain (untuk ketersediaan tinggi) atau proses (untuk antarmuka file), kami sarankan Anda mengandalkan setiap layanan asli Azure untuk ketersediaan, SLA, dan ketahanannya sendiri. Dalam fase perencanaan, penting untuk mempertimbangkan faktor-faktor ini:

  • Desain berbagi NFS atau SMB, termasuk berbagi mana yang akan digunakan per ID sistem SAP (SID), per lanskap, dan per wilayah.
  • Ukuran subnet, termasuk persyaratan IP untuk titik akhir privat atau subnet khusus untuk layanan seperti Azure NetApp Files.
  • Perutean jaringan ke sistem SAP dan aplikasi yang terhubung.
  • Penggunaan titik akhir publik atau privat untuk Azure Files.

Untuk informasi tentang persyaratan dan cara menggunakan berbagi NFS atau SMB dalam skenario ketersediaan tinggi, lihat Ketersediaan tinggi.

Catatan

Jika Anda menggunakan Azure Files untuk berbagi jaringan, kami sarankan Anda menggunakan titik akhir privat. Jika terjadi kegagalan zona, klien NFS Anda secara otomatis dialihkan ke zona sehat. Anda tidak perlu melepas kembali berbagi NFS atau SMB di VM Anda.

Keamanan untuk lanskap SAP Anda

Untuk melindungi beban kerja SAP Anda di Azure, Anda perlu merencanakan beberapa aspek keamanan:

  • Segmentasi jaringan dan keamanan setiap subnet dan antarmuka jaringan.
  • Enkripsi pada setiap lapisan dalam lanskap SAP.
  • Solusi identitas untuk akses pengguna akhir dan administratif serta layanan akses menyeluruh.
  • Pemantauan ancaman dan operasi.

Topik dalam bab ini bukan daftar lengkap dari semua layanan, opsi, dan alternatif yang tersedia. Ini mencantumkan beberapa praktik terbaik yang harus dipertimbangkan untuk semua penyebaran SAP di Azure. Ada aspek lain yang harus dibahas tergantung pada persyaratan perusahaan atau beban kerja Anda. Untuk informasi selengkapnya tentang desain keamanan, lihat sumber daya berikut ini untuk panduan Umum Azure:

Mengamankan jaringan virtual dengan menggunakan grup keamanan

Merencanakan lanskap SAP Anda di Azure harus mencakup beberapa tingkat segmentasi jaringan, dengan jaringan virtual dan subnet yang didedikasikan hanya untuk beban kerja SAP. Praktik terbaik untuk definisi subnet dijelaskan dalam Jaringan dan di panduan arsitektur Azure lainnya. Kami menyarankan agar Anda menggunakan NSG dengan ASG dalam NSG untuk mengizinkan konektivitas masuk dan keluar. Saat Anda merancang ASG, setiap NIC pada VM dapat dikaitkan dengan beberapa ASG, sehingga Anda dapat membuat grup yang berbeda. Misalnya, buat ASG untuk VM DBMS, yang berisi semua server database di seluruh lanskap Anda. Buat ASG lain untuk semua VM (aplikasi dan DBMS) dari satu SAP SID. Dengan cara ini, Anda dapat menentukan satu aturan NSG untuk ASG database keseluruhan dan aturan lain yang lebih spesifik hanya untuk ASG khusus SID.

NSG tidak membatasi performa dengan aturan yang Anda tentukan untuk NSG. Untuk memantau arus lalu lintas, Anda dapat mengaktifkan pengelogan alur NSG secara opsional dengan log yang dievaluasi oleh manajemen peristiwa informasi (SIEM) atau sistem deteksi intrusi (IDS) pilihan Anda untuk memantau dan bertindak pada aktivitas jaringan yang mencurigakan.

Tip

Aktifkan NSG hanya pada tingkat subnet. Meskipun NSG dapat diaktifkan pada tingkat subnet dan tingkat NIC, aktivasi pada keduanya sangat sering menjadi hambatan dalam memecahkan masalah situasi ketika menganalisis pembatasan lalu lintas jaringan. Gunakan NSG pada tingkat NIC hanya dalam situasi luar biasa dan jika diperlukan.

Titik akhir privat untuk layanan

Banyak layanan Azure PaaS diakses secara default melalui titik akhir publik. Meskipun titik akhir komunikasi terletak di jaringan back-end Azure, titik akhir diekspos ke internet publik. Titik akhir privat adalah antarmuka jaringan di dalam jaringan virtual privat Anda sendiri. Melalui Azure Private Link, titik akhir privat memproyeksikan layanan ke jaringan virtual Anda. Layanan PaaS yang dipilih kemudian diakses secara privat melalui IP di dalam jaringan Anda. Bergantung pada konfigurasi, layanan berpotensi dapat diatur untuk berkomunikasi hanya melalui titik akhir privat.

Menggunakan titik akhir privat meningkatkan perlindungan terhadap kebocoran data, dan sering menyederhanakan akses dari jaringan lokal dan yang di-peering. Dalam banyak situasi, perutean dan proses jaringan untuk membuka port firewall, yang sering diperlukan untuk titik akhir publik, disederhanakan. Sumber daya sudah ada di dalam jaringan Anda karena diakses oleh titik akhir privat.

Untuk mempelajari layanan Azure mana yang menawarkan opsi untuk menggunakan titik akhir privat, lihat Layanan private Link yang tersedia. Untuk NFS atau SMB dengan Azure Files, kami sarankan Anda selalu menggunakan titik akhir privat untuk beban kerja SAP. Untuk mempelajari tentang biaya yang dikeluarkan dengan menggunakan layanan, lihat Harga titik akhir privat. Beberapa layanan Azure mungkin secara opsional menyertakan biaya dengan layanan. Informasi ini disertakan dalam informasi harga layanan.

Enkripsi

Bergantung pada kebijakan perusahaan Anda, enkripsi di luar opsi default di Azure mungkin diperlukan untuk beban kerja SAP Anda.

Enkripsi untuk sumber daya infrastruktur

Secara default, disk terkelola dan penyimpanan blob di Azure dienkripsi dengan kunci yang dikelola platform (PMK). Selain itu, bawa enkripsi kunci Anda sendiri (BYOK) untuk disk terkelola dan penyimpanan blob didukung untuk beban kerja SAP di Azure. Untuk enkripsi disk terkelola, Anda dapat memilih dari berbagai opsi, tergantung pada persyaratan keamanan perusahaan Anda. Opsi enkripsi Azure meliputi:

  • Enkripsi sisi penyimpanan (SSE) PMK (SSE-PMK)
  • Kunci yang dikelola pelanggan SSE (SSE-CMK)
  • Enkripsi ganda saat tidak aktif
  • Enkripsi berbasis host

Untuk informasi selengkapnya, termasuk deskripsi Azure Disk Encryption, lihat perbandingan opsi enkripsi Azure.

Catatan

Saat ini, jangan gunakan enkripsi berbasis host pada VM yang ada dalam keluarga VM seri M saat berjalan dengan Linux karena potensi keterbatasan performa. Penggunaan enkripsi SSE-CMK untuk disk terkelola tidak terpengaruh oleh batasan ini.

Untuk penyebaran SAP pada sistem Linux, jangan gunakan Azure Disk Encryption. Azure Disk Encryption memerlukan enkripsi yang berjalan di dalam VM SAP dengan menggunakan CMK dari Azure Key Vault. Untuk Linux, Azure Disk Encryption tidak mendukung gambar sistem operasi yang digunakan untuk beban kerja SAP. Azure Disk Encryption dapat digunakan pada sistem Windows dengan beban kerja SAP, tetapi tidak menggabungkan Azure Disk Encryption dengan enkripsi asli database. Kami menyarankan agar Anda menggunakan enkripsi asli database alih-alih Azure Disk Encryption. Untuk informasi lebih lanjut, lihat bagian berikutnya.

Mirip dengan enkripsi disk terkelola, enkripsi Azure Files saat tidak aktif (SMB dan NFS) tersedia dengan PMK atau CMK.

Untuk berbagi jaringan SMB, tinjau Azure Files dengan cermat dan dependensi sistem operasi dengan versi SMB karena konfigurasi memengaruhi dukungan untuk enkripsi dalam transit.

Penting

Pentingnya rencana yang cermat untuk menyimpan dan melindungi kunci enkripsi jika Anda menggunakan enkripsi yang dikelola pelanggan tidak dapat dilebih-lebihkan. Tanpa kunci enkripsi, sumber daya terenkripsi seperti disk tidak dapat diakses dan dapat menyebabkan kehilangan data. Pertimbangkan untuk melindungi kunci dan akses ke kunci hanya untuk pengguna atau layanan istimewa.

Enkripsi untuk komponen SAP

Enkripsi pada tingkat SAP dapat dipisahkan menjadi dua lapisan:

  • Enkripsi DBMS
  • Enkripsi transportasi

Untuk enkripsi DBMS, setiap database yang didukung untuk penyebaran SAP NetWeaver atau SAP S/4HANA mendukung enkripsi asli. Enkripsi database transparan sepenuhnya independen dari enkripsi infrastruktur apa pun yang ada di Azure. Anda dapat menggunakan enkripsi SSE dan database secara bersamaan. Saat Anda menggunakan enkripsi, lokasi, penyimpanan, dan pengamanan kunci enkripsi sangat penting. Hilangnya kunci enkripsi menyebabkan kehilangan data karena Anda tidak akan dapat memulai atau memulihkan database Anda.

Beberapa database mungkin tidak memiliki metode enkripsi database atau mungkin tidak memerlukan pengaturan khusus untuk diaktifkan. Untuk database lain, cadangan DBMS mungkin dienkripsi secara implisit saat enkripsi database diaktifkan. Lihat dokumentasi SAP berikut untuk mempelajari cara mengaktifkan dan menggunakan enkripsi database transparan:

Hubungi SAP atau vendor DBMS Anda untuk dukungan tentang cara mengaktifkan, menggunakan, atau memecahkan masalah enkripsi perangkat lunak.

Penting

Tidak dapat terlalu berlebihan betapa pentingnya memiliki rencana yang cermat untuk menyimpan dan melindungi kunci enkripsi Anda. Tanpa kunci enkripsi, database atau perangkat lunak SAP mungkin tidak dapat diakses dan Anda mungkin kehilangan data. Pertimbangkan dengan cermat cara melindungi kunci. Izinkan akses ke kunci hanya oleh pengguna atau layanan istimewa.

Enkripsi transportasi atau komunikasi dapat diterapkan ke koneksi SQL Server antara mesin SAP dan DBMS. Demikian pula, Anda dapat mengenkripsi koneksi dari lapisan presentasi SAP (koneksi jaringan aman SAPGui atau SNC) atau koneksi HTTPS ke ujung depan web. Lihat dokumentasi vendor aplikasi untuk mengaktifkan dan mengelola enkripsi saat transit.

Pemantauan dan pemberitahuan ancaman

Untuk menyebarkan dan menggunakan solusi pemantauan dan pemberitahuan ancaman, mulailah dengan menggunakan arsitektur organisasi Anda. Layanan Azure memberikan perlindungan ancaman dan tampilan keamanan yang dapat Anda masukkan ke dalam rencana penyebaran SAP Anda secara keseluruhan. Microsoft Defender untuk Cloud memenuhi persyaratan perlindungan ancaman. Defender untuk Cloud biasanya adalah bagian dari model tata kelola keseluruhan untuk seluruh penyebaran Azure, bukan hanya untuk komponen SAP.

Untuk informasi selengkapnya tentang solusi manajemen peristiwa informasi keamanan (SIEM) dan respons otomatis orkestrasi keamanan (SOAR), lihat Solusi Microsoft Azure Sentinel untuk integrasi SAP.

Perangkat lunak keamanan di dalam VM SAP

Catatan SAP 2808515 untuk Linux dan SAP Note 106267 untuk Windows menjelaskan persyaratan dan praktik terbaik saat Anda menggunakan pemindai virus atau perangkat lunak keamanan di server SAP. Kami menyarankan agar Anda mengikuti rekomendasi SAP saat Anda menyebarkan komponen SAP di Azure.

Ketersediaan tinggi

Ketersediaan tinggi SAP di Azure memiliki dua komponen:

  • Ketersediaan tinggi infrastruktur Azure: Ketersediaan tinggi komputasi Azure (VM), jaringan, dan layanan penyimpanan, dan bagaimana mereka dapat meningkatkan ketersediaan aplikasi SAP.

  • Ketersediaan tinggi aplikasi SAP: Bagaimana hal itu dapat dikombinasikan dengan ketersediaan tinggi infrastruktur Azure dengan menggunakan penyembuhan layanan. Contoh yang menggunakan ketersediaan tinggi dalam komponen perangkat lunak SAP:

    • Instans SAP (A)SCS dan SAP ERS
    • Server database

Untuk informasi selengkapnya tentang ketersediaan tinggi untuk SAP di Azure, lihat artikel berikut ini:

Pacemaker di Linux, dan pengklusteran failover Windows Server adalah satu-satunya kerangka kerja ketersediaan tinggi untuk beban kerja SAP yang didukung langsung oleh Microsoft di Azure. Kerangka kerja ketersediaan tinggi lainnya tidak didukung oleh Microsoft dan akan memerlukan dukungan desain, detail implementasi, dan operasi dari vendor. Untuk informasi selengkapnya, lihat Skenario yang didukung untuk SAP di Azure.

Pemulihan dari bencana

Seringkali, aplikasi SAP adalah salah satu proses yang paling penting bagi bisnis di perusahaan. Berdasarkan kepentingan mereka dan waktu yang diperlukan untuk beroperasi lagi setelah gangguan yang tidak terduga, skenario kelangsungan bisnis dan pemulihan bencana (BCDR) harus direncanakan dengan hati-hati.

Untuk mempelajari cara mengatasi persyaratan ini, lihat Gambaran umum pemulihan bencana dan panduan infrastruktur untuk beban kerja SAP.

Cadangan

Sebagai bagian dari strategi BCDR Anda, pencadangan untuk beban kerja SAP Anda harus menjadi bagian integral dari setiap penyebaran yang direncanakan. Solusi cadangan harus mencakup semua lapisan tumpukan solusi SAP: VM, sistem operasi, lapisan aplikasi SAP, lapisan DBMS, dan solusi penyimpanan bersama apa pun. Pencadangan untuk layanan Azure yang digunakan oleh beban kerja SAP Anda, dan untuk sumber daya penting lainnya seperti enkripsi dan kunci akses juga harus menjadi bagian dari pencadangan dan desain BCDR Anda.

Azure Backup menawarkan solusi PaaS untuk pencadangan:

  • Konfigurasi VM, sistem operasi, dan lapisan aplikasi SAP (penguatan ukuran data pada disk terkelola) melalui Azure Backup untuk VM. Tinjau matriks dukungan untuk memverifikasi bahwa arsitektur Anda dapat menggunakan solusi ini.
  • Data database dan cadangan log SQL Server dan SAP Hana . Ini termasuk dukungan untuk teknologi replikasi database, seperti replikasi sistem HANA atau SQL Always On, dan dukungan lintas wilayah untuk wilayah yang dipasangkan.
  • Pencadangan berbagi file melalui Azure Files. Verifikasi dukungan untuk NFS atau SMB dan detail konfigurasi lainnya.

Atau, jika Anda menyebarkan Azure NetApp Files, opsi cadangan tersedia di tingkat volume, termasuk integrasi SAP Hana dan Oracle DBMS dengan cadangan terjadwal.

Solusi Azure Backup menawarkan opsi penghapusan sementara untuk mencegah penghapusan berbahaya atau tidak disengaja dan untuk mencegah kehilangan data. Penghapusan sementara juga tersedia untuk berbagi file yang Anda sebarkan dengan menggunakan Azure Files.

Opsi pencadangan tersedia untuk solusi yang Anda buat dan kelola sendiri, atau jika Anda menggunakan perangkat lunak pihak ketiga. Opsinya adalah menggunakan layanan dengan Azure Storage, termasuk dengan menggunakan penyimpanan yang tidak dapat diubah untuk data blob. Opsi yang dikelola sendiri ini saat ini akan diperlukan sebagai opsi pencadangan DBMS untuk beberapa database seperti SAP ASE atau IBM Db2.

Gunakan rekomendasi dalam praktik terbaik Azure untuk melindungi dan memvalidasi dari serangan ransomware .

Tip

Pastikan strategi pencadangan Anda termasuk melindungi otomatisasi penyebaran, kunci enkripsi untuk sumber daya Azure, dan enkripsi database transparan jika digunakan.

Pencadangan lintas wilayah

Untuk persyaratan pencadangan lintas wilayah, tentukan Tujuan Waktu Pemulihan (RTO) dan Tujuan Titik Pemulihan (RPO) yang ditawarkan oleh solusi dan apakah cocok dengan desain dan kebutuhan BCDR Anda.

Migrasi SAP ke Azure

Tidak dimungkinkan untuk menjelaskan semua pendekatan dan opsi migrasi untuk berbagai produk SAP, dependensi versi, dan sistem operasi asli dan teknologi DBMS yang tersedia. Tim proyek untuk organisasi dan perwakilan Anda dari sisi penyedia layanan Anda harus mempertimbangkan beberapa teknik untuk migrasi SAP yang lancar ke Azure.

  • Menguji performa selama migrasi. Bagian penting dari perencanaan migrasi SAP adalah pengujian performa teknis. Tim migrasi perlu mengizinkan waktu dan ketersediaan yang memadai bagi personel kunci untuk menjalankan aplikasi dan pengujian teknis sistem SAP yang dimigrasikan, termasuk antarmuka dan aplikasi yang terhubung. Untuk migrasi SAP yang sukses, sangat penting untuk membandingkan runtime pramigrasi dan pascamigrasi dan akurasi proses bisnis utama di lingkungan pengujian. Gunakan informasi untuk mengoptimalkan proses sebelum Anda memigrasikan lingkungan produksi.

  • Gunakan layanan Azure untuk migrasi SAP. Beberapa beban kerja berbasis VM dimigrasikan tanpa perubahan ke Azure dengan menggunakan layanan seperti Azure Migrate atau Azure Site Recovery, atau alat pihak ketiga. Konfirmasikan dengan rajin bahwa versi sistem operasi dan beban kerja SAP yang dijalankannya didukung oleh layanan.

    Seringkali, beban kerja database apa pun sengaja tidak didukung karena layanan tidak dapat menjamin konsistensi database. Jika jenis DBMS didukung oleh layanan migrasi, perubahan database atau tingkat churn sering terlalu tinggi. Sebagian besar sistem SAP yang sibuk tidak akan memenuhi tingkat perubahan yang diizinkan alat migrasi. Masalah mungkin tidak terlihat atau ditemukan hingga migrasi produksi. Dalam banyak situasi, beberapa layanan Azure tidak cocok untuk memigrasikan sistem SAP. Azure Site Recovery dan Azure Migrate tidak memiliki validasi untuk migrasi SAP skala besar. Metodologi migrasi SAP yang terbukti adalah mengandalkan replikasi DBMS atau alat migrasi SAP.

    Penyebaran di Azure alih-alih migrasi VM dasar lebih disukai dan lebih mudah dicapai daripada migrasi lokal. Kerangka kerja penyebaran otomatis seperti Azure Center untuk solusi SAP dan kerangka kerja otomatisasi penyebaran Azure memungkinkan eksekusi cepat tugas otomatis. Untuk memigrasikan lanskap SAP Anda ke infrastruktur baru yang disebarkan dengan menggunakan teknologi replikasi asli DBMS seperti replikasi sistem HANA, pencadangan dan pemulihan DBMS, atau alat migrasi SAP menggunakan pengetahuan teknis yang ditetapkan tentang sistem SAP Anda.

  • Peningkatan skala infrastruktur. Selama migrasi SAP, memiliki lebih banyak kapasitas infrastruktur dapat membantu Anda menyebarkan lebih cepat. Tim proyek harus mempertimbangkan untuk meningkatkan ukuran VM untuk menyediakan lebih banyak CPU dan memori. Tim juga harus mempertimbangkan untuk meningkatkan penyimpanan agregat VM dan throughput jaringan. Demikian pula, pada tingkat VM, pertimbangkan elemen penyimpanan seperti disk individual untuk meningkatkan throughput dengan bursting sesuai permintaan dan tingkat performa untuk Premium SSD v1. Tingkatkan nilai IOPS dan throughput jika Anda menggunakan Premium SSD v2 di atas nilai yang dikonfigurasi. Perbesar berbagi file NFS dan SMB untuk meningkatkan batas performa. Perlu diingat bahwa Azure mengelola disk tidak dapat dikurangi ukurannya, dan pengurangan ukuran, tingkat performa, dan KPI throughput dapat memiliki berbagai waktu pendinginan.

  • Optimalkan salinan jaringan dan data. Memigrasikan sistem SAP ke Azure selalu melibatkan pemindahan sejumlah besar data. Data mungkin berupa database dan cadangan file atau replikasi, transfer data aplikasi ke aplikasi, atau ekspor migrasi SAP. Bergantung pada proses migrasi yang Anda gunakan, Anda perlu memilih jalur jaringan yang benar untuk memindahkan data. Untuk banyak operasi pemindahan data, menggunakan internet alih-alih jaringan privat adalah jalur tercepat untuk menyalin data dengan aman ke penyimpanan Azure.

    Menggunakan ExpressRoute atau VPN dapat menyebabkan hambatan:

    • Data migrasi menggunakan terlalu banyak bandwidth dan mengganggu akses pengguna ke beban kerja yang berjalan di Azure.
    • Penyempitan jaringan lokal, seperti firewall atau pembatasan throughput, sering kali hanya ditemukan selama migrasi.

    Terlepas dari koneksi jaringan yang digunakan, performa jaringan aliran tunggal untuk pemindahan data sering kali rendah. Untuk meningkatkan kecepatan transfer data melalui beberapa aliran TCP, gunakan alat yang dapat mendukung beberapa aliran. Terapkan teknik pengoptimalan yang dijelaskan dalam dokumentasi SAP dan dalam banyak posting blog tentang topik ini.

Tip

Dalam tahap perencanaan, penting untuk mempertimbangkan jaringan migrasi khusus apa pun yang akan Anda gunakan untuk transfer data besar ke Azure. Contohnya termasuk pencadangan atau replikasi database atau menggunakan titik akhir publik untuk transfer data ke penyimpanan Azure. Dampak migrasi pada jalur jaringan untuk pengguna dan aplikasi Anda harus diharapkan dan dimitigasi. Sebagai bagian dari perencanaan jaringan Anda, pertimbangkan semua fase migrasi dan biaya beban kerja yang sebagian produktif di Azure selama migrasi.

Dukungan dan operasi untuk SAP

Beberapa area lain penting untuk dipertimbangkan sebelum dan selama penyebaran SAP di Azure.

Ekstensi Azure VM untuk SAP

Ekstensi Pemantauan Azure, Pemantauan yang Ditingkatkan, dan Ekstensi Azure untuk SAP semuanya mengacu pada ekstensi VM yang perlu Anda sebarkan untuk menyediakan beberapa data dasar tentang infrastruktur Azure ke agen host SAP. Catatan SAP mungkin merujuk ke ekstensi sebagai Ekstensi Pemantauan atau Pemantauan yang Ditingkatkan. Di Azure, ini disebut Ekstensi Azure untuk SAP. Untuk tujuan dukungan, ekstensi harus diinstal pada semua Azure VM yang menjalankan beban kerja SAP. Untuk mempelajari selengkapnya, lihat Ekstensi Azure VM untuk SAP.

SAProuter untuk dukungan SAP

Mengoperasikan lanskap SAP di Azure memerlukan konektivitas ke dan dari SAP untuk tujuan dukungan. Biasanya, konektivitas dalam bentuk koneksi SAProuter, baik jika melalui saluran jaringan enkripsi melalui internet atau melalui koneksi VPN privat ke SAP. Untuk praktik terbaik dan untuk contoh implementasi SAProuter di Azure, lihat skenario arsitektur Anda di Koneksi internet masuk dan keluar untuk SAP di Azure.

Langkah berikutnya