Beban kerja SAP di Azure: daftar periksa perencanaan dan penyebaran

  • Artikel
  • 26 menit untuk membaca

Daftar periksa ini dirancang untuk pelanggan yang memindahkan aplikasi SAP NetWeaver, S/4Hana, dan Hybris ke infrastruktur Azure sebagai layanan. 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 lebih banyak pemeriksaan.

Daftar periksa tidak menyertakan tugas yang independen dari Azure. Misalnya, antarmuka aplikasi SAP berubah selama perpindahan ke platform Azure atau ke penyedia hosting.

Daftar periksa ini juga dapat digunakan untuk sistem yang sudah disebarkan. Fitur baru, seperti Write Accelerator dan Zona Ketersediaan, dan jenis VM baru mungkin telah ditambahkan sejak Anda sebarkan. Jadi berguna untuk mengulas daftar periksa secara berkala untuk memastikan Anda mengetahui fitur baru di platform Azure.

Tahap persiapan dan perencanaan proyek

Selama fase ini, Anda merencanakan migrasi beban kerja SAP Anda ke platform Azure. Minimal, selama fase ini Anda perlu membuat dokumen berikut dan menentukan dan mendiskusikan elemen migrasi berikut:

  1. 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.
    • Keputusan tentang wilayah Azure mana yang akan disebarkan. Lihat daftar wilayah Azure. Untuk mempelajari layanan mana yang tersedia di setiap wilayah, lihat Produk yang tersedia menurut wilayah.
    • Arsitektur jaringan untuk terhubung dari lokal ke Azure. Mulailah membiasakan diri dengan Cetak biru Pusat data virtual untuk Azure.
    • Prinsip keamanan untuk menjalankan data bisnis berdampak tinggi di Azure. Untuk mempelajari tentang keamanan data, mulailah dengan dokumentasi keamanan Azure.
  2. Dokumen desain teknis. Dokumen ini harus berisi:
  3. Inventaris semua antarmuka SAP (SAP dan non-SAP).
  4. Desain layanan dasar. Desain ini harus mencakup item berikut:
    • Layanan Domain Active Directory dan DNS desain.
    • Topologi jaringan dalam Azure dan penugasan sistem SAP yang berbeda.
    • Struktur Kontrol akses berbasis peran Azure (Azure RBAC) untuk tim yang mengelola infrastruktur dan aplikasi SAP di Azure.
    • Topologi grup sumber daya.
    • Strategi penandaan.
    • Konvensi penamaan untuk VM dan komponen infrastruktur lainnya dan/atau nama logis.
  5. Kontrak Dukungan Microsoft Professional atau Premier. Identifikasi Microsoft Technical Account Manager (TAM) jika Anda memiliki kontrak dukungan Premier dengan Microsoft. Untuk persyaratan dukungan SAP, lihat Catatan dukungan SAP #2015553.
  6. Jumlah langganan Azure dan kuota inti untuk langganan. Buka permintaan dukungan untuk meningkatkan kuota langganan Azure sesuai kebutuhan.
  7. 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.
  8. Pendekatan penyebaran otomatis. Tujuan dari otomatisasi penyebaran infrastruktur di Azure adalah untuk menyebarkan dengan cara yang deterministik dan mendapatkan hasil yang deterministik. Banyak pelanggan menggunakan skrip berbasis PowerShell atau CLI. Tetapi ada berbagai teknologi sumber terbuka yang dapat Anda gunakan untuk menyebarkan infrastruktur Azure untuk SAP dan bahkan memaang perangkat lunak SAP. Anda dapat menemukan contoh di GitHub:
  9. Tentukan irama ulasan desain dan penyebaran reguler antara Anda sebagai pelanggan, integrator sistem, Microsoft, dan pihak lain yang terlibat.

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.

  1. Optimalkan transfer data ke Azure. Pilihan optimal sangat tergantung pada skenario spesifik. Transfer dari lokal melalui Azure ExpressRoute adalah yang tercepat jika sirkuit ExpressRoute memiliki bandwidth yang cukup. Dalam skenario lain, mentransfer melalui internet lebih cepat.
  2. Untuk migrasi platform SAP heterogen yang melibatkan ekspor dan impor data, uji dan optimalkan fase ekspor dan impor. Untuk migrasi besar di mana Microsoft SQL Server adalah platform tujuan, Anda dapat menemukan rekomendasi. Anda dapat menggunakan Migration Monitor/SWPM jika Anda tidak memerlukan peningkatan rilis gabungan. Anda dapat menggunakan proses SAP DMO saat menggabungkan migrasi dengan peningkatan rilis SAP. Untuk melakukannya, Anda perlu memenuhi persyaratan tertentu untuk kombinasi platform DBMS sumber dan target. Proses ini didokumentasikan dalam Opsi Migrasi Database (DMO) dari SUM 2.0 SP03.
    1. Ekspor ke sumber, ekspor unggahan file ke Azure, dan impor performa. Maksimalkan tumpang tindih antara ekspor dan impor.
    2. Mengevaluasi volume database pada platform target dan tujuan untuk keperluan ukuran infrastruktur.
    3. Memvalidasi dan mengoptimalkan waktu.
  3. Validasi teknis.
    1. Jenis Komputer Virtual.
      • Tinjau sumber daya dalam catatan dukungan SAP, di direktori perangkat keras SAP Hana, dan di SAP PAM lagi. Pastikan tidak ada perubahan pada 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 dapat memperoleh SAPS yang diperlukan dari infrastruktur yang Anda gunakan dan halaman web benchmark SAP dan membandingkannya dengan nomor SAPS yang tercantum dalam catatan dukungan SAP #1928533. Perhatikan juga artikel ini tentang peringkat SAPS.
      • Evaluasi dan uji ukuran Azure VM Anda sehubungan dengan keluaran penyimpanan maksimum dan keluaran jaringan dari jenis VM yang Anda pilih selama fase perencanaan. Anda dapat menemukan data di sini:
    2. Penyimpanan.
    3. 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 pendekatan mikro segmentasi dalam satu jaringan virtual Azure. Mendasarkan evaluasi ini pada: 1. Biaya pertukaran data antara jaringan virtual Azure yang dipasangkan. Untuk informasi tentang biaya, lihat Harga Microsoft Azure Virtual Network. 2. Keuntungan pemutusan cepat peering 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. 3. Pencatatan dan pengauditan terpusat lalu lintas jaringan antara lokal, dunia luar, dan pusat data virtual yang Anda buat di Azure.
      • Mengevaluasi dan menguji jalur data antara lapisan aplikasi SAP dan lapisan SAP DBMS.
        • Penempatan peralatan virtual jaringan Azuredi jalur komunikasi antara aplikasi SAP dan lapisan DBMS sistem SAP berdasarkan SAP NetWeaver, Hybris, atau S/4Hana tidak didukung.
        • Penempatan lapisan aplikasi SAP dan SAP DBMS di jaringan virtual Azure yang berbeda yang tidak disalah serekan tidak didukung.
        • Anda dapat menggunakan grup keamanan aplikasi dan aturan grup keamanan jaringan untuk menentukan rute antara lapisan aplikasi SAP dan lapisan SAP DBMS.
      • Pastikan bahwa Jaringan Ter-akselerasi Azure diaktifkan pada VM yang digunakan di lapisan aplikasi SAP dan lapisan SAP DBMS. Perlu diingat bahwa tingkat OS yang berbeda diperlukan untuk mendukung Accelerated Networking di Azure:
        • Windows Server 2012 R2 atau versi lebih baru.
        • SUSE Linux 12 SP3 atau yang lebih baru.
        • RHEL 7.4 atau yang lebih baru.
        • Oracle Linux 7.5. Jika Anda menggunakan kernel RHCKL, rilis 3.10.0-862.13.1.el7 diperlukan. Jika Anda menggunakan kernel Oracle UEK, rilis 5 diperlukan.
      • Uji dan evaluasi latensi jaringan antara lapisan aplikasi SAP VM dan DBMS VM sesuai catatan dukungan #500235 dan #1100926. Mengevaluasi hasil terhadap panduan latensi jaringan di catatan dukungan SAP #1100926. Latensi jaringan harus dalam kisaran sedang atau baik. Pengecualian berlaku untuk lalu lintas antara VM dan unit Instans Besar Hana, seperti yang didokumentasikan dalam artikel ini.
      • Pastikan penyebaran ILB disiapkan untuk menggunakan Direct Server Return. Pengaturan ini akan mengurangi latensi saat ILB Azure digunakan untuk konfigurasi ketersediaan tinggi pada lapisan DBMS.
      • 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 yang lebih lama dari Catatan SAP #2382421. Catatan SAP sekarang diperbarui untuk menyatakan bahwa parameter ini perlu diatur ke 0 untuk bekerja dengan Azure Load Blancer.
      • Pertimbangkan untuk menggunakan grup penempatan kedekatan Azure untuk mendapatkan latensi jaringan yang optimal. Untuk informasi selengkapnya, lihat Grup penempatan kedekatan Azure untuk latensi jaringan yang optimal dengan aplikasi SAP.
    4. Ketersediaan tinggi dan penyebaran pemulihan bencana.
      • Jika Anda menyebarkan lapisan aplikasi SAP tanpa menentukan Zona Ketersediaan Azuree tertentu, pastikan bahwa semua VM yang menjalankan instans dialog SAP atau instans middleware dari satu sistem SAP disebarkan dalam kumpulan ketersediaan.
      • Jika Anda tidak memerlukan ketersediaan tinggi untuk Layanan Pusat SAP dan DBMS, Anda dapat menyebarkan VM ini ke dalam rangkaian ketersediaan yang sama dengan lapisan aplikasi SAP.
      • Jika Anda melindungi Layanan Pusat SAP dan lapisan DBMS untuk ketersediaan tinggi dengan menggunakan replikasi pasif, tempatkan dua simpul untuk Layanan Pusat SAP dalam satu rangkaian ketersediaan terpisah dan dua simpul DBMS dalam ketersediaan lain yang ditetapkan.
      • Jika Anda menyebarkan ke dalam Zona Ketersediaan Azure, Anda tidak dapat menggunakan rangkaian ketersediaan. Tetapi Anda perlu memastikan Anda menyebarkan simpul Layanan Pusat yang aktif dan pasif ke dalam dua Zona Ketersediaan yang berbeda. Gunakan Zona Ketersediaan yang memiliki latensi terendah di antaranya. Perlu diingat bahwa Anda perlu menggunakan Azure Standard Load Balancer untuk kasus penggunaan pembuatan kluster failover Windows atau Pacemaker untuk lapisan Layanan Pusat DBMS dan SAP di seluruh Zona Ketersediaan. Anda tidak dapat menggunakan Basic Load Balancer untuk penyebaran zona.
    5. 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 Catatan SAP #2743751.
      • 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
        • SameSubNetThreshold = 15
        • RoutingHistoryLength = 30
    6. Pengaturan atau Patch OS
  4. Uji ketersediaan tinggi dan prosedur pemulihan bencana Anda.
    1. Simulasikan situasi failover dengan mematikan VM (sistem operasi tamu Windows) atau menempatkan sistem operasi dalam mode panik (sistem operasi tamu Linux). Langkah ini akan membantu Anda mencari tahu apakah konfigurasi failover Anda berfungsi seperti yang dirancang.
    2. 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.
    3. 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.
    4. Uji fungsionalitas dan arsitektur DR lintas wilayah.
  5. Pemeriksaan keamanan.
    1. Uji validitas arsitektur kontrol akses berbasis peran Azure (Azure RBAC) Anda. Tujuannya adalah untuk memisahkan dan membatasi akses dan izin dari tim yang berbeda. Misalnya, anggota tim SAP Basis harus dapat menyebarkan VM dan menetapkan disk dari Azure Storage ke dalam jaringan 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.
    2. Verifikasi bahwa grup keamanan jaringan dan aturan ASC berfungsi seperti yang diharapkan dan melindungi sumber daya yang dilindungi.
    3. 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.
    4. Gunakan Azure Disk Encryption untuk disk OS jika memungkinkan dari sudut pandang dukungan OS.
    5. Pastikan Anda tidak menggunakan terlalu banyak lapisan enkripsi. Dalam beberapa kasus, masuk akal untuk menggunakan Azure Disk Encryption bersama dengan salah satu metode Enkripsi Data Transparan DBMS untuk melindungi disk atau komponen yang berbeda di server yang sama. Misalnya, pada server SAP DBMS, Azure Disk Encryption (ADE) dapat diaktifkan pada disk boot sistem operasi (jika OS mendukung ADE) dan disk data tersebut yang tidak digunakan oleh file persistensi data DBMS. Contohnya adalah menggunakan Azure Disk Encryption pada disk yang memegang kunci enkripsi TDE DBMS.
  6. Pengujian performa. Dalam SAP, berdasarkan pelacakan SAP dan pengukuran, buat perbandingan ini:
    • 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 langkah tambahan yang perlu Anda selesaikan selama fase ini:

  1. 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.
  2. 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.
  3. Uji dan tentukan apakah Anda ingin membuat gambar OS Anda sendiri untuk mesin virtual Anda di Azure atau apakah Anda ingin menggunakan gambar dari Azure Compute Gallery (sebelumnya dikenal sebagai Shared Image Gallery). Jika Anda menggunakan gambar dari Azure Compute Gallery, 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. Jika Anda memutuskan untuk membuat gambar OS Anda sendiri, Anda dapat menemukan dokumentasi di artikel ini:
  4. Jika Anda menggunakan gambar SUSE dan Red Hat Linux dari Azure Compute Gallery, Anda perlu menggunakan gambar untuk SAP yang diberikan oleh vendor Linux di Azure Compute Gallery.
  5. Pastikan untuk memenuhi persyaratan dukungan SAP untuk perjanjian dukungan Microsoft. Lihat catatan dukungan SAP #2015553. Untuk Instans Besar Hana, lihat Persyaratan Orientasi.
  6. Pastikan orang yang tepat mendapatkan pemberitahuan pemeliharaan terencana sehingga Anda dapat memilih waktu henti terbaik.
  7. Sering periksa presentasi Azure di saluran seperti Channel 9 untuk fungsionalitas baru yang mungkin berlaku untuk penyebaran Anda.
  8. Periksa catatan SAP yang terkait dengan Azure, seperti catatan dukungan #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.
  9. 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.
  10. Periksa situs web SAP untuk SKU baru bersertifikat Hana 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.
  11. Sesuaikan skrip penyebaran Anda untuk menggunakan jenis VM baru dan menggabungkan fitur Azure baru yang ingin Anda gunakan.
  12. Setelah penyebaran infrastruktur, uji dan evaluasi latensi jaringan antara VM lapisan aplikasi SAP dan DBMS VM, menurut catatan dukungan SAP #500235 dan #1100926. Mengevaluasi hasil terhadap panduan latensi jaringan di catatan dukungan SAP #1100926. Latensi jaringan harus dalam kisaran sedang atau baik. Pengecualian berlaku untuk lalu lintas antara VM dan unit Instans Besar Hana, seperti yang didokumentasikan dalam artikel ini. Pastikan bahwa tidak ada batasan yang disebutkan dalam Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP dan konfigurasi dan operasi infrastruktur SAP Hana di Azure berlaku untuk penyebaran Anda.
  13. Pastikan VM Anda disebarkan ke grup penempatan kedekatan Azure yang benar, seperti yang dijelaskan dalam grup penempatan kedekatan Azure untuk latensi jaringan yang optimal dengan aplikasi SAP.
  14. Lakukan semua pemeriksaan lain yang tercantum untuk fase bukti konsep sebelum menerapkan beban kerja.
  15. 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 mengurangi ukuran, penyimpanan, dan bandwidth jaringan VM juga akan berkurang.
  16. 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.
  17. 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.
  18. 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. Anda juga perlu menyiapkan pekerjaan transfer data antara lokasi hosting Anda saat ini dan Azure.

  1. Selesaikan peningkatan rilis SAP yang diperlukan dari sistem produksi Anda sebelum pindah ke Azure.
  2. Setuju dengan pemilik bisnis tentang tes fungsional dan bisnis yang perlu dilakukan setelah migrasi sistem produksi.
  3. Pastikan pengujian ini dilengkapi dengan sistem sumber di lokasi hosting saat ini. Hindari melakukan pengujian untuk pertama kalinya setelah sistem dipindahkan ke Azure.
  4. 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. Uji migrasi data. Berikut adalah beberapa metode umum:
    • Gunakan metode DBMS seperti pencadangan/pemulihan dalam kombinasi dengan Microsoft SQL Server Grup Ketersediaan AlwaysOn, Hana System Replication, atau Catatan pengiriman untuk menambahkan dan menyinkronkan konten database di Azure.
    • Gunakan pencadangan/pemulihan untuk database yang lebih kecil.
    • Gunakan SAP Migration Monitor, yang diintegrasikan ke dalam SAP SWPM, untuk melakukan migrasi heterogen.
    • Gunakan proses SAP DMO jika Anda perlu menggabungkan migrasi Anda dengan peningkatan rilis SAP. 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) dari SUM 2.0 SP04.
    • 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.
  5. 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.
  6. Periksa kembali catatan dukungan SAP dan pengaturan OS yang diperlukan, direktori perangkat keras SAP Hana, dan PAM SAP. Pastikan tidak ada perubahan dalam VM yang didukung untuk Azure, rilis OS yang didukung di VM tersebut, dan rilis SAP dan DBMS yang didukung.
  7. Perbarui skrip penyebaran untuk memperhitungkan keputusan terbaru yang Anda buat pada jenis VM dan fungsionalitas Azure.
  8. Setelah menyebarkan infrastruktur dan aplikasi, validasi bahwa:
    • Jenis VM yang benar disebarkan, dengan atribut dan ukuran penyimpanan yang benar.
    • VM berada pada rilis OS yang benar dan diinginkan dan patch dan seragam.
    • VM diperkeras sesuai yang diperlukan dan dengan cara yang seragam.
    • Rilis dan patch aplikasi yang benar dipasang dan disebarkan.
    • VM disebarkan ke dalam rangkaian ketersediaan Azure seperti yang direncanakan.
    • Penyimpanan Premium Azure digunakan untuk disk sensitif latensi atau di mana SLA VM tunggal sebesar 99,9% diperlukan.
    • Azure Write Accelerator disebarkan dengan benar.
    • Disk yang dikelola Azure digunakan secara eksklusif.
    • VM disebarkan ke dalam rangkaian ketersediaan dan Zona Ketersediaan yang benar.
    • Jaringan Ter-akselerasi Azure diaktifkan pada VM yang digunakan di lapisan aplikasi SAP dan lapisan SAP DBMS.
    • Tidak ada peralatan virtual jaringan Azure yang berada di jalur komunikasi antara aplikasi SAP dan lapisan DBMS sistem SAP berdasarkan SAP NetWeaver, Hybris, atau S/4Hana.
    • Grup keamanan aplikasi dan aturan grup keamanan jaringan memungkinkan komunikasi seperti yang diinginkan dan direncanakan dan memblokir komunikasi jika diperlukan.
    • Pengaturan waktu habis diatur dengan benar, seperti yang dijelaskan sebelumnya.
    • VM disebarkan ke grup penempatan kedekatan Azure yang benar, seperti yang dijelaskan dalam grup penempatan kedekatan Azure untuk latensi jaringan yang optimal dengan aplikasi SAP.
    • Latensi jaringan antara VM lapisan aplikasi SAP dan DBMS VM diuji dan divalidasi seperti yang dijelaskan dalam catatan dukungan SAP#500235 dan #1100926. Mengevaluasi hasil terhadap panduan latensi jaringan di catatan dukungan SAP #1100926. Latensi jaringan harus dalam kisaran sedang atau baik. Pengecualian berlaku untuk lalu lintas antara VM dan unit Instans Besar Hana, seperti yang didokumentasikan dalam artikel ini.
    • Enkripsi diimplementasikan jika perlu dan dengan metode enkripsi yang sesuai.
    • Antarmuka dan aplikasi lainnya dapat menghubungkan infrastruktur yang baru disebarkan.
  9. Buat pedoman untuk bereaksi terhadap pemeliharaan Azure yang direncanakan. Tentukan urutan di mana sistem dan VM harus di-boot ulang untuk pemeliharaan terencana.

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:

  1. Verifikasi bahwa pemantauan portal Microsoft Azure dan alat pemantauan lainnya berfungsi. Kami merekomendasikan Windows Performance Monitor (perfmon) untuk Windows dan SAR untuk Linux.
    • Penghitung CPU.
      • Waktu CPU rata-rata, total (semua CPU)
      • Waktu CPU rata-rata, setiap prosesor individual (128 prosesor pada M128 VM)
      • Waktu kernel CPU, setiap prosesor individual
      • Waktu pengguna CPU, setiap prosesor individual
    • Memori.
      • Memori bebas
      • Halaman memori dalam/detik
      • Halaman memori keluar/detik
    • Disk.
      • Disk dibaca dalam KBps, per disk individual
      • Disk membaca/detik, per disk individual
      • Disk dibaca dalam mikrodetik/baca, per disk individual
      • Disk ditulis dalam KBps, per disk individual
      • Disk tulis/detik, per disk individual
      • Disk ditulis dalam mikrodetik/baca, per disk individual
    • Jaringan.
      • Paket jaringan dalam/detik
      • Paket jaringan keluar/detik
      • KB jaringan dalam/detik
      • KB jaringan keluar/detik
  2. 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.
  3. Periksa apakah antarmuka berfungsi dan apakah aplikasi lain dapat berkomunikasi dengan sistem produksi yang baru disebarkan.
  4. Periksa sistem transportasi dan koreksi melalui STMS transaksi SAP.
  5. Lakukan pencadangan database setelah sistem dirilis untuk produksi.
  6. Lakukan pencadangan VM untuk lapisan aplikasi SAP VM setelah sistem dirilis untuk produksi.
  7. 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:

  1. Ulasan faktur Azure untuk sistem pengisian daya tinggi.
  2. Optimalkan efisiensi harga/performa di sisi VM dan sisi penyimpanan.
  3. Optimalkan waktu saat Anda dapat mematikan sistem.

Langkah berikutnya

Lihat artikel ini: