Beban kerja SAP di Azure: daftar periksa perencanaan dan penyebaran
Artikel
29 menit untuk membaca
Daftar periksa ini dirancang untuk pelanggan yang memindahkan aplikasi SAP ke infrastruktur Azure sebagai layanan. Aplikasi SAP dalam dokumen ini mewakili produk SAP yang menjalankan kernel SAP, termasuk SAP NetWeaver, S/4HANA, BW dan BW/4 dan lainnya. Sepanjang durasi proyek, pelanggan dan/atau mitra SAP harus mengulas daftar periksa. Penting untuk dicatat bahwa banyak pemeriksaan selesai pada awal proyek dan selama fase perencanaan. Setelah penyebaran selesai, perubahan langsung pada infrastruktur Azure yang disebarkan atau rilis perangkat lunak SAP dapat menjadi kompleks.
Mengulas daftar periksa di kunci milestone selama proyek Anda. Melakukannya akan mengaktifkan Anda untuk mendeteksi masalah kecil sebelum menjadi masalah besar. Anda juga akan memiliki cukup waktu untuk merekayasa ulang dan menguji perubahan yang diperlukan. Jangan anggap daftar periksa ini lengkap. Tergantung pada situasi Anda, Anda mungkin perlu melakukan pemeriksaan tambahan.
Daftar periksa tidak menyertakan tugas yang independen dari Azure. Misalnya, antarmuka aplikasi SAP berubah selama perpindahan ke platform Azure atau ke penyedia hosting. Dokumentasi SAP dan catatan dukungan juga akan berisi tugas lebih lanjut, yang tidak spesifik azure tetapi perlu menjadi bagian dari daftar periksa perencanaan Anda secara keseluruhan.
Daftar periksa ini juga dapat digunakan untuk sistem yang sudah disebarkan. Fitur baru atau rekomendasi yang diubah mungkin berlaku untuk lingkungan Anda. Sangat berguna untuk meninjau daftar periksa secara berkala untuk memastikan Anda mengetahui fitur baru di platform Azure.
Konten utama dalam dokumen ini diatur dalam tab, dalam urutan kronologis proyek yang khas. Lihat konten setiap tab dan pertimbangkan setiap tab berikutnya untuk membangun di atas tindakan yang dilakukan dan pembelajaran yang diperoleh pada fase sebelumnya. Untuk migrasi produksi, konten semua tab harus dipertimbangkan dan bukan hanya tab produksi. Untuk membantu Anda memetakan fase proyek umum dengan definisi fase yang digunakan dalam artikel ini, lihat tabel di bawah ini.
Fase daftar periksa penyebaran
Contoh fase atau pencapaian proyek
Fase persiapan dan perencanaan
Proyek kick-off / desain dan fase definisi
Fase pilot
Validasi awal / bukti konsep / percontohan
Fase non-produksi
Penyelesaian desain terperinci/fase pembangunan/pengujian lingkungan non-produksi
Fase persiapan produksi
Pengujian latihan gaun / penerimaan pengguna / pemeriksaan cut-over / go-live tiruan
Selama fase ini, Anda merencanakan migrasi beban kerja SAP Anda ke platform Azure. Dokumen seperti panduan perencanaan untuk SAP di Azure dan Cloud Adoption Framework untuk SAP mencakup banyak topik dan membantu sebagai informasi dalam persiapan Anda. Minimal, selama fase ini Anda perlu membuat dokumen berikut, menentukan, dan mendiskusikan elemen migrasi berikut:
Dokumen desain tingkat tinggi
Dokumen ini harus berisi:
Inventaris komponen SAP dan aplikasi saat ini, dan inventaris aplikasi target untuk Azure.
Matriks penugasan tanggung jawab (RACI) yang mendefinisikan tanggung jawab dan penugasan dari pihak-pihak yang terlibat. Mulai dari tingkat tinggi, dan bekerja ke tingkat yang lebih terperinci sepanjang perencanaan dan penyebaran pertama.
Arsitektur solusi tingkat tinggi. Praktik terbaik dan contoh arsitektur dari Azure Architecture Center harus dikonsultasikan.
Prinsip keamanan untuk menjalankan data bisnis berdampak tinggi di Azure. Untuk mempelajari tentang keamanan data, mulailah dengan dokumentasi keamanan Azure.
Strategi penyimpanan untuk mencakup perangkat blok (Disk Terkelola) dan sistem file bersama (seperti Azure Files atau Azure NetApp Files) yang harus disempurnakan lebih lanjut ke ukuran dan tata letak sistem file dalam dokumen desain teknis.
Dokumen desain teknis
Dokumen ini harus berisi:
Diagram blok untuk solusi yang menunjukkan aplikasi dan layanan SAP dan non-SAP
Proyek SAP Quicksizer berdasarkan volume dokumen bisnis. Output Quicksizer kemudian dipetakan ke komponen komputasi, penyimpanan, dan jaringan di Azure. Atau untuk SAP Quicksizer, ukuran rajin berdasarkan beban kerja sistem SAP sumber saat ini. Dengan mempertimbangkan informasi yang tersedia, seperti laporan beban kerja DBMS, Laporan EarlyWatch SAP, indikator performa komputasi dan penyimpanan.
Kelangsungan bisnis dan arsitektur pemulihan bencana.
Informasi terperinci tentang OS, DB, kernel, dan versi paket dukungan SAP. Tidak selalu benar bahwa setiap rilis OS yang didukung oleh SAP NetWeaver atau S/4Hana didukung pada Azure VM. Hal yang sama berlaku untuk rilis DBMS. Periksa sumber berikut untuk menyelaraskan dan jika perlu, tingkatkan rilis SAP, rilis DBMS, dan rilis OS untuk memastikan dukungan SAP dan Azure. Anda harus memiliki kombinasi rilis yang didukung oleh SAP dan Azure untuk mendapatkan dukungan penuh dari SAP dan Microsoft. Jika perlu, Anda perlu merencanakan untuk meningkatkan beberapa komponen perangkat lunak. Detail selengkapnya tentang perangkat lunak SAP, OS, dan DBMS yang didukung didokumentasikan di sini:
Catatan SAP 2039619. Catatan ini mendefinisikan matriks dukungan Oracle untuk Azure. Oracle hanya mendukung Windows dan Oracle Linux sebagai sistem operasi tamu di Azure untuk beban kerja SAP. Pernyataan dukungan ini juga berlaku untuk lapisan aplikasi SAP yang menjalankan instans SAP, selama berisi Klien Oracle.
Azure VM yang didukung SAP Hana tercantum di situs web SAP. Detail untuk setiap entri berisi persyaratan dan spesifik, termasuk versi OS yang didukung. Ini mungkin tidak cocok dengan versi OS terbaru sesuai catatan SAP 2235581.
Tata letak dan ukuran volume SMB dan/atau NFS, titik pemasangan jika berlaku
Ketersediaan tinggi, pencadangan, dan arsitektur pemulihan bencana
Berdasarkan RTO dan RPO, tentukan seperti apa ketersediaan tinggi dan arsitektur pemulihan bencana.
Tentukan penggunaan zona ketersediaan untuk perlindungan optimal atau set ketersediaan dalam suatu wilayah.
Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP dan dokumen terkait. Di Azure, menggunakan konfigurasi disk bersama untuk lapisan DBMS karena, misalnya, yang dijelaskan untuk SQL Server, tidak didukung. Sebagai gantinya, gunakan solusi seperti:
Untuk pemulihan bencana di seluruh wilayah Azure, ulas solusi yang ditawarkan oleh vendor DBMS yang berbeda. Sebagian besar dari mereka mendukung replikasi asinkron atau pengiriman catatan.
Untuk lapisan aplikasi SAP, tentukan apakah Anda akan menjalankan sistem uji regresi bisnis Anda, yang idealnya adalah replika penyebaran produksi Anda, di wilayah Azure yang sama atau di wilayah DR Anda. Dalam kasus kedua, Anda dapat menargetkan sistem regresi bisnis sebagai target DR untuk penyebaran produksi Anda.
Untuk proyek yang diperlukan untuk tetap berada dalam satu wilayah karena alasan kepatuhan, pertimbangkan konfigurasi HADR gabungan dengan menggunakan Zona Ketersediaan Azure.
Inventarisasi semua antarmuka SAP dan sistem yang terhubung (SAP dan non-SAP)
Operasi keamanan untuk sumber daya dan beban kerja Azure di dalamnya
Konsep keamanan untuk melindungi beban kerja SAP Anda. Ini harus mencakup semua aspek - pemantauan jaringan dan perimeter, keamanan aplikasi dan database, sistem operasi yang mengamankan, dan langkah-langkah infrastruktur apa pun yang diperlukan, seperti enkripsi. Identifikasi persyaratan dengan tim kepatuhan dan keamanan Anda.
Microsoft merekomendasikan kontrak Professional Direct, Premier, atau Unified Support. Identifikasi jalur eskalasi dan kontak Anda untuk dukungan dengan Microsoft. Untuk persyaratan dukungan SAP, lihat catatan SAP 2015553.
Pengurangan data dan rencana migrasi data untuk memigrasikan data SAP ke Azure. Untuk sistem SAP NetWeaver, SAP memiliki panduan tentang cara membatasi volume data dalam jumlah besar. Lihat panduan SAP ini tentang manajemen data dalam sistem SAP ERP. Beberapa konten juga berlaku untuk sistem NetWeaver dan S/4Hana pada umumnya.
Pendekatan penyebaran otomatis. Banyak pelanggan mulai dengan skrip, menggunakan kombinasi PowerShell, CLI, Ansible, dan Terraform.
Solusi yang dikembangkan Microsoft untuk otomatisasi penyebaran SAP adalah:
Tentukan irama ulasan desain dan penyebaran reguler antara Anda sebagai pelanggan, integrator sistem, Microsoft, dan pihak lain yang terlibat.
Fase pilot (sangat disarankan)
Anda dapat menjalankan pilot sebelum atau selama perencanaan dan persiapan proyek. Anda juga dapat menggunakan fase pilot untuk menguji pendekatan dan desain yang dilakukan selama fase perencanaan dan persiapan. Dan Anda dapat memperluas fase pilot untuk menjadikannya bukti konsep yang nyata.
Kami menyarankan agar Anda menyiapkan dan memvalidasi solusi HADR lengkap dan desain keamanan selama penyebaran pilot. Beberapa pelanggan melakukan tes skalabilitas selama fase ini. Pelanggan lain menggunakan penyebaran sistem kotak pasir SAP sebagai fase pilot. Kami berasumsi Anda telah mengidentifikasi sistem yang ingin Anda migrasikan ke Azure untuk pilot.
Optimalkan transfer data ke Azure. Pilihan optimal sangat tergantung pada skenario spesifik. Jika konektivitas privat diperlukan untuk replikasi database, Azure ExpressRoute adalah yang tercepat jika sirkuit ExpressRoute memiliki bandwidth yang cukup. Dalam skenario lain, mentransfer melalui internet lebih cepat. Secara opsional, gunakan VPN migrasi khusus untuk konektivitas privat ke Azure. Jalur jaringan migrasi apa pun selama pilot harus mencerminkan penggunaan untuk sistem produksi di masa mendatang, menghilangkan dampak apa pun terhadap beban kerja – SAP atau non-SAP - yang sudah berjalan di Azure.
Untuk migrasi SAP heterogen yang melibatkan ekspor dan impor data, uji dan optimalkan fase ekspor dan impor. Untuk migrasi lingkungan SAP besar, lakukan praktik terbaik yang tersedia. Gunakan alat yang sesuai untuk skenario migrasi, tergantung pada rilis SAP sumber dan target Anda, DBMS, dan jika menggabungkan migrasi dengan tugas lain seperti peningkatan rilis atau bahkan konversi Unicode atau S/4HANA. SAP menyediakan Monitor Migrasi/SWPM, SAP DMO , atau DMO dengan perpindahan sistem, selain pendekatan lain untuk meminimalkan waktu henti yang tersedia sebagai layanan terpisah dari SAP. Dalam rilis terbaru SAP DMO dengan perpindahan sistem, penggunaan azcopy untuk transfer data melalui internet juga didukung, memungkinkan jalur jaringan tercepat secara asli.
Memigrasi database yang sangat besar (VLDB) ke Azure untuk SAP
Validasi teknis
Jenis komputasi /VM
Tinjau sumber daya dalam catatan dukungan SAP, di direktori perangkat keras SAP Hana, dan di SAP PAM lagi. Pastikan untuk mencocokkan VM yang didukung untuk Azure, rilis OS yang didukung untuk jenis VM tersebut, dan rilis SAP dan DBMS yang didukung.
Validasi lagi ukuran aplikasi Anda dan infrastruktur yang Anda sebarkan di Azure. Jika Anda memindahkan aplikasi yang ada, Anda sering kali dapat memperoleh SAPS yang diperlukan dari infrastruktur yang Anda gunakan dan halaman web tolok ukur SAP dan membandingkannya dengan nomor SAPS yang tercantum dalam catatan SAP 1928533. Perhatikan juga artikel ini tentang peringkat SAPS.
Evaluasi dan uji ukuran Azure VM Anda untuk penyimpanan maksimum dan throughput jaringan dari jenis VM yang Anda pilih selama fase perencanaan. Detail batas performa VM tersedia, untuk penyimpanan, penting untuk mempertimbangkan batas throughput disk maks yang tidak di-cache untuk ukuran. Pertimbangkan ukuran dan efek sementara disk dan bursting tingkat VM dengan hati-hati.
Uji dan tentukan apakah Anda ingin membuat gambar OS Anda sendiri untuk VM Anda di Azure atau apakah Anda ingin menggunakan gambar dari galeri komputasi Azure (sebelumnya dikenal sebagai galeri gambar bersama). Jika Anda menggunakan gambar dari galeri komputasi Azure, pastikan untuk menggunakan gambar yang mencerminkan kontrak dukungan dengan vendor OS Anda. Untuk beberapa vendor OS, Azure Compute Gallery memungkinkan Anda membawa gambar lisensi Anda sendiri. Untuk gambar OS lainnya, dukungan disertakan dalam harga yang dikuotasi oleh Azure.
Menggunakan gambar OS sendiri memungkinkan Anda menyimpan dependensi perusahaan yang diperlukan, seperti agen keamanan, pengerasan, dan penyesuaian langsung dalam gambar. Dengan cara ini mereka segera disebarkan dengan setiap VM. Jika Anda memutuskan untuk membuat gambar OS Anda sendiri, Anda dapat menemukan dokumentasi di artikel ini:
Jika Anda menggunakan gambar Linux dari galeri komputasi Azure dan menambahkan pengerasan sebagai bagian dari alur penyebaran, Anda perlu menggunakan gambar yang cocok untuk SAP yang disediakan oleh vendor Linux.
Memilih gambar OS menentukan jenis generasi Azure VM. Azure mendukung VM Hyper-V generasi 1 dan 2. Beberapa keluarga VM hanya tersedia sebagai generasi 2, beberapa keluarga VM disertifikasi untuk penggunaan SAP hanya sebagai generasi 2 (catatan SAP 1928533) bahkan jika Azure mengizinkan kedua generasi. Disarankan untuk menggunakan VM generasi 2 untuk setiap VM lanskap SAP.
Minimal, gunakan penyimpanan SSD standar Azure untuk VM yang mewakili lapisan aplikasi SAP dan untuk penyebaran DBMS yang tidak sensitif terhadap performa. Perlu diingat berbagai jenis penyimpanan Azure memengaruhi SLA ketersediaan VM tunggal.
Secara umum, kami tidak merekomendasikan penggunaan disk HDD standar Azure untuk SAP.
Untuk berbagai jenis DBMS, periksa dokumentasi DBMS terkait SAP generik dan dokumentasi khusus DBMS yang dituju dokumen pertama. Gunakan striping disk di beberapa disk dengan penyimpanan premium (v1 atau v2) untuk data database dan area log. Verifikasi bahwa striping disk lvm aktif dan dengan ukuran stripe yang benar dengan perintah 'lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices' di Linux, lihat properti ruang penyimpanan di Windows.
Gunakan LVM untuk semua disk di VM Linux, karena memungkinkan manajemen dan ekspansi online yang lebih mudah. Ini termasuk volume pada disk tunggal, misalnya /usr/sap.
Jaringan
Uji dan evaluasi infrastruktur jaringan virtual Anda dan distribusi aplikasi SAP Anda di seluruh atau dalam jaringan virtual Azure yang berbeda.
Evaluasi pendekatan arsitektur jaringan virtual hub-and-spoke atau virtual WAN dengan spoke jaringan virtual diskrit untuk beban kerja SAP. Untuk skala yang lebih kecil, pendekatan segmentasi mikro dalam satu jaringan virtual Azure. Mendasarkan evaluasi ini pada:
Keuntungan dari pemutusan cepat serekan antara jaringan virtual Azure dibandingkan dengan mengubah grup keamanan jaringan untuk mengisolasi subnet dalam jaringan virtual. Evaluasi ini untuk kasus ketika aplikasi atau VM yang di-hosting dalam subnet jaringan virtual menjadi risiko keamanan.
Pencatatan pusat dan audit lalu lintas jaringan antara lokal, dunia luar, dan pusat data virtual yang Anda bangun di Azure.
Mengevaluasi dan menguji jalur data antara lapisan aplikasi SAP dan lapisan SAP DBMS.
Penempatan appliance virtual jaringan Azure di jalur komunikasi antara aplikasi SAP dan lapisan DBMS sistem SAP yang menjalankan kernel SAP tidak didukung.
Penempatan lapisan aplikasi SAP dan SAP DBMS di jaringan virtual Azure yang berbeda yang tidak disalah serekan tidak didukung.
Pastikan jaringan yang dipercepat diaktifkan pada setiap VM yang digunakan untuk SAP.
Uji dan evaluasi latensi jaringan antara VM lapisan aplikasi SAP dan VM DBMS sesuai dengan catatan SAP 500235 dan 1100926. Selain niping SAP, Anda dapat menggunakan alat seperti sockperf atau ethr untuk pengukuran latensi tcp. Evaluasi hasil terhadap panduan latensi jaringan dalam catatan SAP 1100926. Latensi jaringan harus dalam kisaran sedang atau baik.
Optimalkan throughput jaringan pada VM vCPU tinggi, biasanya digunakan untuk server database. Sangat penting untuk peluasan skala HANA dan sistem SAP besar apa pun. Ikuti rekomendasi dalam artikel ini untuk pengoptimalan.
Jika menyebarkan dengan set ketersediaan dan nilai pengukuran latensi tidak memenuhi persyaratan SAP dalam catatan SAP 1100926, pertimbangkan panduan dalam grup penempatan kedekatan artikel untuk mendapatkan latensi jaringan yang optimal. Tidak ada penggunaan grup penempatan kedekatan untuk pola penyebaran zonal atau lintas zona.
Verifikasi ketersediaan, perutean, dan akses yang aman yang benar dari lanskap SAP ke titik akhir Internet yang diperlukan, seperti repositori patch OS, alat penyebaran, atau titik akhir layanan. Demikian pula, jika lingkungan SAP Anda menyediakan layanan yang dapat diakses publik seperti SAP Fiori atau SAProuter, pastikan dapat dijangkau dan diamankan.
Ketersediaan tinggi dan penyebaran pemulihan bencana
Selalu gunakan load balancer standar untuk lingkungan berkluster. Load balancer dasar akan dihentikan.
Jika Anda menyebarkan lapisan aplikasi SAP tanpa menentukan zona ketersediaan tertentu, pastikan bahwa semua VM yang menjalankan instans aplikasi SAP dari satu sistem SAP disebarkan dalam set ketersediaan.
Saat Anda melindungi Layanan Pusat SAP dan lapisan DBMS untuk ketersediaan tinggi dengan menggunakan replikasi pasif, tempatkan dua simpul untuk Layanan Pusat SAP dalam satu set ketersediaan terpisah dan dua simpul DBMS dalam set ketersediaan lain. Jangan mencampur peran VM aplikasi di dalam set ketersediaan.
Jika Anda menyebarkan ke zona ketersediaan, Anda tidak dapat menggabungkan dengan set ketersediaan. Tetapi Anda perlu memastikan Anda menyebarkan node layanan pusat aktif dan pasif ke dalam dua zona ketersediaan yang berbeda. Gunakan dua zona ketersediaan yang memiliki latensi terendah di antaranya.
Jika Anda menggunakan Azure Load Balancer bersama dengan sistem operasi tamu Linux, periksa apakah parameter jaringan Linux net.ipv4.tcp_timestamps diatur ke 0. Rekomendasi ini bertentangan dengan rekomendasi dalam versi catatan SAP yang lebih lama 2382421. Catatan SAP sekarang diperbarui untuk menyatakan bahwa parameter ini perlu diatur ke 0 untuk bekerja dengan Azure Load Blancer.
Pengaturan waktu habis
Periksa jejak pengembang SAP NetWeaver dari instans SAP untuk memastikan tidak ada putus koneksi antara server enqueue dan proses kerja SAP. Anda dapat menghindari putus koneksi ini dengan mengatur dua parameter registri ini:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Untuk informasi selengkapnya, lihat KeepAliveTime.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Untuk informasi selengkapnya, lihat KeepAliveInterval.
Untuk menghindari batas waktu GUI antara antarmuka SAP GUI lokal dan lapisan aplikasi SAP yang disebarkan di Azure, periksa apakah parameter ini diatur di default.pfl atau profil instans:
rdisp/keepalive_timeout = 3600
rdisp/keepalive = 20
Untuk mencegah gangguan koneksi yang dibuat antara proses enqueue SAP dan proses kerja SAP, Anda perlu mengatur enque/encni/set_so_keepalive parameter ke true. Lihat juga 2743751 catatan SAP.
Jika Anda menggunakan konfigurasi kluster failover Windows, pastikan bahwa waktu untuk bereaksi pada simpul non-responsif diatur dengan benar untuk Azure. Artikel Penyetelan Ambang Jaringan Kluster Failover mencantumkan parameter dan bagaimana pengaruhnya terhadap sensitivitas failover. Dengan asumsi simpul kluster berada di subnet yang sama, Anda harus mengubah parameter ini:
SameSubNetDelay = 2000 (jumlah milidetik antara "heartbeat")
SameSubNetThreshold = 15 (jumlah maksimum heartbeat yang terlewat berturut-turut)
Untuk menjalankan HANA di SAP, baca catatan dan dokumentasi ini, selain dokumentasi spesifik SAP non-Azure dan catatan dukungan lainnya:
Catatan SAP khusus Azure yang ditautkan ke komponen dukungan SAP BC-OP-NT-AZR atau BC-OP-LNX-AZR. Buka catatan secara rinci karena berisi solusi yang diperbarui
Menguji ketersediaan tinggi dan prosedur pemulihan bencana Anda
Simulasikan situasi failover dengan menggunakan alat seperti NotMyFault (Windows) atau menempatkan sistem operasi dalam mode panik atau menonaktifkan antarmuka jaringan dengan ifdown (Linux). Langkah ini akan membantu Anda mencari tahu apakah konfigurasi failover Anda berfungsi seperti yang dirancang.
Ukur berapa lama waktu yang dibutuhkan untuk menjalankan failover. Jika waktu terlalu lama, pertimbangkan:
Untuk SUSE Linux, gunakan perangkat SBD alih-alih agen Azure Fence untuk mempercepat peralihan.
Untuk SAP Hana, jika muat ulang data terlalu lama, pertimbangkan untuk menyediakan lebih banyak bandwidth penyimpanan.
Uji urutan dan waktu pencadangan/pemulihan Anda dan lakukan koreksi jika perlu. Pastikan waktu pencadangan cukup. Anda juga perlu menguji aktivitas pemulihan dan pemulihan waktu. Pastikan bahwa waktu pemulihan berada dalam SLA RTO Anda di mana pun RTO Anda bergantung pada database atau proses pemulihan VM.
Uji fungsionalitas dan arsitektur DR lintas wilayah, verifikasi RPO dan RTO sesuai dengan harapan Anda
Pemeriksaan keamanan
Uji validitas arsitektur kontrol akses berbasis peran Azure (Azure RBAC) Anda. Pemisahan tugas mengharuskan untuk memisahkan dan membatasi akses dan izin tim yang berbeda. Misalnya, anggota tim SAP Basis harus dapat menyebarkan VM dan menetapkan disk dari Azure Storage ke komputer virtual Azure tertentu. Tetapi tim SAP Basis seharusnya tidak dapat membuat jaringan virtual sendiri atau mengubah pengaturan jaringan virtual yang ada. Anggota tim jaringan seharusnya tidak dapat menyebarkan VM ke jaringan virtual di mana aplikasi SAP dan DBMS VM berjalan. Anggota tim ini juga tidak boleh mengubah atribut VM atau bahkan menghapus VM atau disk.
Pastikan bahwa semua sumber daya yang perlu dienkripsi terenkripsi. Tentukan dan terapkan proses untuk mencadangkan sertifikat, menyimpan dan mengakses sertifikat tersebut, dan memulihkan entitas terenkripsi.
Untuk enkripsi penyimpanan, enkripsi sisi server dengan kunci yang dikelola platform (SSE-PMK) diaktifkan untuk setiap layanan penyimpanan yang digunakan untuk SAP di Azure secara default, termasuk disk terkelola, Azure Files, dan Azure NetApp Files. Manajemen kunci dengan kunci yang dikelola pelanggan dapat dipertimbangkan, jika diperlukan untuk rotasi kunci milik pelanggan.
Jangan gunakan Azure Disk Encryption di Linux dengan SAP sebagai gambar OS 'untuk SAP' tidak didukung.
Enkripsi asli database disebarkan oleh sebagian besar pelanggan SAP di Azure untuk melindungi data dan cadangan DBMS. Enkripsi Data Transparan (TDE) biasanya tidak memiliki overhead performa yang nyata, sangat meningkatkan keamanan, dan harus dipertimbangkan. Manajemen dan lokasi kunci enkripsi harus diamankan. Enkripsi database terjadi di dalam VM dan tidak bergantung pada enkripsi penyimpanan apa pun seperti SSE.
Pengujian performa Di SAP, berdasarkan pelacakan dan pengukuran SAP, buat perbandingan ini:
Inventori dan garis besar sistem lokal saat ini
Laporan SAR / perfmon
STAT melacak 10 laporan online teratas
Mengumpulkan riwayat pekerjaan batch
Fokus pengujian untuk memverifikasi performa proses bisnis. Jangan bandingkan KPI perangkat keras pada awalnya dan dalam vakum, hanya saat memecahkan masalah perbedaan performa apa pun.
Jika berlaku, bandingkan 10 laporan daring teratas dengan implementasi Anda saat ini.
Jika berlaku, bandingkan 10 tugas batch teratas dengan implementasi Anda saat ini.
Bandingkan transfer data melalui antarmuka ke dalam sistem SAP. Fokus pada antarmuka di mana Anda tahu transfer akan antara lokasi yang berbeda, seperti dari lokal ke Azure.
Fase non-produksi
Dalam fase ini, kami berasumsi bahwa setelah pilot atau proof of concept (POC) yang sukses, Anda mulai menyebarkan sistem SAP non-produksi ke Azure. Menggabungkan semua yang Anda pelajari dan alami selama POC untuk penyebaran ini. Semua kriteria dan langkah-langkah yang tercantum untuk POC berlaku untuk penyebaran ini juga.
Selama fase ini, Anda biasanya menyebarkan sistem pengembangan, sistem pengujian unit, dan sistem pengujian regresi bisnis ke Azure. Kami menyarankan bahwa setidaknya satu sistem non-produksi dalam satu lini aplikasi SAP memiliki konfigurasi ketersediaan tinggi penuh yang akan dilakukan sistem produksi di masa depan. Berikut adalah beberapa tugas yang perlu Anda selesaikan selama fase ini:
Sebelum Anda memindahkan sistem dari platform lama ke Azure, kumpulkan data konsumsi sumber daya, seperti penggunaan CPU, throughput penyimpanan, dan data IOPS. Terutama mengumpulkan data ini dari unit lapisan DBMS, tetapi juga mengumpulkannya dari unit lapisan aplikasi. Juga mengukur latensi jaringan dan penyimpanan. Sesuaikan ukuran dan desain Anda dengan data yang diambil. Alat seperti systat, KSAR, nmon dan nmon analyzer untuk Excel harus digunakan untuk menangkap dan menyajikan pemanfaatan sumber daya selama periode puncak.
Catat pola waktu penggunaan ketersediaan sistem Anda. Tujuannya adalah untuk mencari tahu apakah sistem non-produksi perlu tersedia sepanjang hari, setiap hari atau apakah ada sistem non-produksi yang dapat dimatikan selama fase tertentu dalam seminggu atau bulan.
Evaluasi kembali pilihan gambar OS Anda, generasi VM (Generasi 2 di seluruh lanskap SAP), dan strategi patch OS.
Pastikan untuk memenuhi persyaratan dukungan SAP untuk perjanjian dukungan Microsoft. Lihat 2015553 catatan SAP.
Periksa catatan SAP yang terkait dengan Azure, seperti catatan 1928533, untuk SKU VM baru dan rilis OS dan DBMS yang baru didukung. Bandingkan harga jenis VM baru dengan jenis VM yang lebih lama, sehingga Anda dapat sebarkan VM dengan rasio harga / performa terbaik.
Periksa kembali catatan dukungan SAP, direktori perangkat keras SAP Hana, dan PAM SAP. Pastikan tidak ada perubahan dalam VM yang didukung untuk Azure, rilis OS yang didukung pada VM tersebut, dan rilis SAP dan DBMS yang didukung.
Periksa situs web SAP untuk SKU bersertifikat HANA baru di Azure. Bandingkan harga SKU baru dengan yang Anda rencanakan untuk digunakan. Akhirnya, lakukan perubahan yang diperlukan untuk menggunakan yang memiliki rasio harga / performa terbaik.
Sesuaikan otomatisasi penyebaran Anda untuk menggunakan jenis VM baru dan menggabungkan fitur Azure baru yang ingin Anda gunakan.
Setelah penyebaran infrastruktur, uji dan evaluasi latensi jaringan antara VM lapisan aplikasi SAP dan VM DBMS, menurut catatan SAP 500235. Evaluasi hasil terhadap panduan latensi jaringan dalam catatan SAP 1100926. Latensi jaringan harus dalam kisaran sedang atau baik. Selain menggunakan alat seperti niping, sockperf atau ethr, gunakan alat HCMT SAP untuk pengukuran jaringan antara VM HANA untuk peluasan skala atau replikasi sistem.
Pastikan VM Anda disebarkan ke zona ketersediaan yang benar. Jika menggunakan set ketersediaan dan melihat latensi yang lebih tinggi dari yang diharapkan antara VM, lihat artikel Grup penempatan kedekatan Azure untuk aplikasi SAP untuk penggunaan yang benar.
Lakukan semua pemeriksaan lain yang tercantum untuk fase bukti konsep sebelum menerapkan beban kerja.
Saat beban kerja berlaku, catat konsumsi sumber daya sistem di Azure. Bandingkan konsumsi ini dengan catatan dari platform lama Anda. Sesuaikan ukuran VM penyebaran di masa mendatang jika Anda melihat bahwa Anda memiliki perbedaan besar. Perlu diingat bahwa ketika Anda menurunkan ukuran, penyimpanan, dan bandwidth jaringan VM juga akan berkurang.
Bereksperimenlah dengan fungsionalitas dan proses salinan sistem. Tujuannya adalah untuk memudahkan Anda menyalin sistem pengembangan atau sistem uji, sehingga tim proyek bisa mendapatkan sistem baru dengan cepat.
Optimalkan dan asah akses, izin, dan proses berbasis peran Azure tim Anda untuk memastikan Anda memiliki pemisahan tugas. Pada saat yang sama, pastikan semua tim dapat melakukan tugas mereka di infrastruktur Azure.
Latihan, pengujian, dan dokumen prosedur ketersediaan tinggi dan pemulihan bencana untuk mengaktifkan staf Anda menjalankan tugas-tugas ini. Identifikasi kekurangan dan sesuaikan fungsionalitas Azure baru yang Anda integrasikan ke dalam penyebaran Anda.
Fase persiapan produksi
Pada fase ini, kumpulkan apa yang Anda alami dan pelajari selama penyebaran non-produksi Anda dan terapkan ke penyebaran produksi di masa depan.
Selesaikan peningkatan rilis SAP yang diperlukan dari sistem produksi Anda sebelum pindah ke Azure.
Setuju dengan pemilik bisnis tentang tes fungsional dan bisnis yang perlu dilakukan setelah migrasi sistem produksi.
Pastikan pengujian ini dilengkapi dengan sistem sumber di lokasi hosting saat ini. Hindari melakukan pengujian untuk pertama kalinya setelah sistem dipindahkan ke Azure.
Uji proses migrasi sistem produksi ke Azure. Jika Anda tidak memindahkan semua sistem produksi ke Azure selama jangka waktu yang sama, bangun grup sistem produksi yang harus berada di lokasi hosting yang sama. Menguji migrasi data termasuk aplikasi dan antarmuka non-SAP yang terhubung.
Berikut adalah beberapa metode umum:
Gunakan metode DBMS seperti pencadangan/pemulihan dalam kombinasi dengan SQL Server Always On, Replikasi Sistem HANA, atau pengiriman log untuk menyemai dan menyinkronkan konten database di Azure.
Gunakan pencadangan/pemulihan untuk database yang lebih kecil.
Gunakan proses SAP DMO untuk skenario yang didukung untuk memindahkan atau jika Anda perlu menggabungkan migrasi Anda dengan peningkatan rilis SAP dan/atau pindah ke HANA. Perlu diingat bahwa tidak semua kombinasi sumber DBMS dan target DBMS didukung. Anda dapat menemukan informasi lebih lanjut dalam catatan dukungan SAP tertentu untuk rilis DMO yang berbeda. Misalnya, Database Migration Option (DMO) sum 2.0 SP15.
Uji apakah throughput transfer data lebih baik melalui internet atau melalui Azure ExpressRoute, jika Anda perlu memindahkan cadangan atau file ekspor SAP. Jika Anda memindahkan data melalui internet, Anda mungkin perlu mengubah beberapa aturan grup keamanan jaringan /grup keamanan aplikasi yang harus Anda miliki untuk sistem produksi di masa mendatang.
Sebelum memindahkan sistem dari platform lama Anda ke Azure, kumpulkan data konsumsi sumber daya. Data yang berguna mencakup penggunaan CPU, throughput penyimpanan, dan data IOPS. Terutama mengumpulkan data ini dari unit lapisan DBMS, tetapi juga mengumpulkannya dari unit lapisan aplikasi. Juga mengukur latensi jaringan dan penyimpanan.
Centang ulang catatan SAP dan pengaturan OS yang diperlukan, direktori perangkat keras SAP Hana, dan SAP PAM. Pastikan tidak ada perubahan dalam VM yang didukung untuk Azure, rilis OS yang didukung di VM tersebut, dan rilis SAP dan DBMS yang didukung.
Perbarui otomatisasi penyebaran Anda untuk mempertimbangkan keputusan terbaru yang telah Anda buat pada jenis VM dan fungsionalitas Azure.
Buat playbook untuk bereaksi terhadap peristiwa pemeliharaan Azure yang direncanakan. Tentukan urutan di mana sistem dan VM harus di-boot ulang untuk pemeliharaan terencana.
Latihan, pengujian, dan dokumentasikan prosedur ketersediaan tinggi dan pemulihan bencana untuk memungkinkan staf Anda menjalankan tugas-tugas ini selama migrasi dan segera setelah keputusan langsung.
Fase siaran langsung
Selama fase siaran langsung, pastikan untuk mengikuti playbook yang Anda kembangkan selama fase sebelumnya. Jalankan langkah-langkah yang Anda uji dan praktikkan. Jangan menerima perubahan konfigurasi dan proses di menit-menit terakhir. Juga selesaikan langkah-langkah ini:
Verifikasi bahwa pemantauan portal Microsoft Azure dan alat pemantauan lainnya berfungsi. Gunakan alat Azure seperti Azure Monitor untuk pemantauan infrastruktur. Azure Monitor untuk SAP untuk kombinasi OS dan KPI aplikasi, memungkinkan Anda mengintegrasikan semua dalam satu dasbor untuk visibilitas selama dan setelah ditayangkan.
Untuk indikator performa kunci sistem operasi:
Di Linux, pastikan alat sysstat diinstal dan menangkap detail secara berkala
Setelah migrasi data, lakukan semua tes validasi yang Anda setujui dengan pemilik bisnis. Terima hasil uji validasi hanya ketika Anda memiliki hasil untuk sistem sumber asli.
Periksa apakah antarmuka berfungsi dan apakah aplikasi lain dapat berkomunikasi dengan sistem produksi yang baru disebarkan.
Periksa sistem transportasi dan koreksi melalui STMS transaksi SAP.
Lakukan pencadangan database setelah sistem dirilis untuk produksi.
Lakukan pencadangan VM untuk lapisan aplikasi SAP VM setelah sistem dirilis untuk produksi.
Untuk sistem SAP yang bukan bagian dari fase siaran langsung saat ini tetapi yang berkomunikasi dengan sistem SAP yang Anda pindahkan ke Azure selama fase siaran langsung ini, Anda perlu mengatur ulang buffer nama host di SM51. Melakukannya akan menghapus alamat IP cache lama yang terkait dengan nama instans aplikasi yang Anda pindahkan ke Azure.
Pascaproduksi
Fase ini adalah tentang pemantauan, pengoperasian, dan administrasi sistem. Dari sudut pandang SAP, tugas-tugas biasa yang harus Anda selesaikan di lokasi hosting lama Anda berlaku. Selesaikan tugas khusus Azure ini juga:
Ulasan faktur Azure untuk sistem pengisian daya tinggi. Instal budaya finOps dan bangun kemampuan pengoptimalan biaya Azure di organisasi Anda.
Optimalkan efisiensi harga/performa di sisi VM dan sisi penyimpanan.
Setelah SAP di Azure Anda stabil, fokus Anda perlu beralih ke budaya peninjauan ukuran dan kapasitas berkelanjutan. Tidak seperti lokal, di mana kita mengukur untuk jangka waktu yang lama, ukuran yang tepat adalah manfaat utama menjalankan SAP pada beban kerja Azure, dan perencanaan kapasitas yang rajin akan menjadi kuncinya.
Optimalkan waktu saat Anda dapat mematikan sistem.
Setelah solusi Anda stabil di Azure, pertimbangkan untuk menjauh dari model komersial Pay-As-You-Go dan manfaatkan Azure Reserved Instances.
Rencanakan dan jalankan latihan pemulihan bencana reguler.
Tentukan dan terapkan strategi Anda sekeliling 'ever-greeneing', untuk menyelaraskan peta strategi Anda sendiri dengan peta strategi SAP di Azure Microsoft untuk mendapatkan manfaat dari kemajuan teknologi.
Daftar Periksa Infrastruktur SAP di Azure
Setelah menyebarkan infrastruktur dan aplikasi dan sebelum setiap migrasi dimulai, validasi bahwa:
Jenis VM yang benar disebarkan, dengan atribut dan konfigurasi penyimpanan yang benar.
VM berada pada rilis dan patch OS, DBMS, dan SAP Kernel terbaru serta seragam OS, DB, dan SAP Kernel di seluruh lanskap
VM diamankan dan diperkeras sesuai kebutuhan dan dengan cara yang seragam di seluruh lingkungan masing-masing.
VM disebarkan ke zona ketersediaan Azure atau set ketersediaan seperti yang direncanakan.
VM Generasi 2 telah disebarkan. VM Generasi 1 tidak boleh digunakan untuk penyebaran baru
Azure Premium Storage atau Premium Storage v2 digunakan untuk disk sensitif latensi atau di mana SLA VM tunggal sebesar 99,9% diperlukan.
Pastikan bahwa, dalam VM, ruang penyimpanan, atau set garis dibangun dengan benar di seluruh sistem file yang memerlukan lebih dari disk, seperti data DBMS dan area log.
Ukuran stripe yang benar dan ukuran blokir sistem file digunakan, jika dicatat dalam panduan DBMS masing-masing
Penyimpanan dan penembolokan Azure VM digunakan dengan tepat
Pastikan bahwa hanya disk yang menyimpan log online DBMS yang di-cache dengan None+ Write Accelerator.
Disk lain dengan penyimpanan premium menggunakan pengaturan cache tidak ada atau ReadOnly, tergantung pada penggunaan
Menggunakan layanan Azure – Azure Files atau Azure NetApp Files – untuk volume atau berbagi SMB atau NFS apa pun. Volume NFS atau berbagi SMB dapat dijangkau oleh lingkungan SAP masing-masing atau sistem SAP individual. Perutean jaringan ke server NFS/SMB melewati ruang alamat jaringan privat, menggunakan titik akhir privat jika diperlukan.
Tidak ada appliance virtual jaringan yang berada di jalur komunikasi antara aplikasi SAP dan lapisan DBMS sistem SAP berdasarkan Platform SAP NetWeaver atau ABAP.
Semua load balancer untuk komponen SAP dengan ketersediaan tinggi menggunakan load balancer standar dengan ip mengambang dan port HA diaktifkan.
Aplikasi SAP dan DBMS VM ditempatkan di subnet yang sama atau berbeda dari satu jaringan virtual atau di jaringan virtual yang di-peering secara langsung.
Aturan kelompok keamanan aplikasi dan jaringan memungkinkan komunikasi seperti yang diinginkan dan direncanakan, dan memblokir komunikasi jika diperlukan.
Pengaturan waktu habis diatur dengan benar, seperti yang dijelaskan sebelumnya.
Jika menggunakan grup penempatan kedekatan, periksa apakah set ketersediaan dan VM mereka disebarkan ke PPG yang benar.
Latensi jaringan antara VM lapisan aplikasi SAP dan VM DBMS diuji dan divalidasi seperti yang dijelaskan dalam catatan SAP 500235 dan 1100926. Evaluasi hasil terhadap panduan latensi jaringan dalam catatan SAP 1100926. Latensi jaringan harus dalam kisaran sedang atau baik.
Enkripsi diimplementasikan jika perlu dan dengan metode enkripsi yang sesuai.
Kunci enkripsi sendiri dilindungi dari kehilangan, penghancuran, atau penggunaan berbahaya.
Antarmuka dan aplikasi lain dapat terhubung ke infrastruktur yang baru disebarkan.
Pemeriksaan dan wawasan otomatis dalam lanskap SAP
Beberapa pemeriksaan di atas diperiksa secara otomatis dengan SAP di Azure Quality Check Tool. Pemeriksaan ini dapat dijalankan secara otomatis dengan proyek sumber terbuka yang disediakan. Meskipun tidak ada remediasi otomatis masalah yang ditemukan dilakukan, alat ini akan memperingatkan tentang konfigurasi terhadap rekomendasi Microsoft.
Alat lebih lanjut untuk memungkinkan pemeriksaan penyebaran dan temuan dokumen yang lebih mudah, merencanakan langkah-langkah remediasi berikutnya dan umumnya mengoptimalkan SAP Anda di lanskap Azure adalah:
Tinjauan Azure Well-Architected Framework Penilaian beban kerja Anda yang berfokus pada lima pilar utama keandalan, keamanan, pengoptimalan biaya, keunggulan operasi, dan efisiensi performa. Mendukung beban kerja SAP dan direkomendasikan untuk menjalankan tinjauan pada awal dan setelah setiap fase proyek.
Pemeriksaan Azure Inventory untuk SAP Buku kerja sumber terbuka Azure Monitor, yang memperlihatkan inventarit Azure Anda dengan kecerdasan untuk menyoroti penyimpangan konfigurasi dan meningkatkan kualitas.