7 pelajaran setelah penerapan SAP HANA berdasarkan MS Azure untuk perusahaan Rusia





Lebih dari 10 tahun yang lalu, Microsoft mengumumkan ketersediaan platform Azure untuk banyak pengguna. Selama ini, banyak perusahaan ingin memanfaatkan infrastruktur cloud untuk menyelesaikan masalah IT saat ini. Beberapa dari mereka menghubungi kami untuk meminta saran tentang penerapan sistem di cloud. Tetapi waktu berlalu dan sekarang bisnis sedang mempertimbangkan kemungkinan untuk menempatkan sistem intensif sumber daya seperti SAP HANA di cloud. Kami, pada gilirannya, telah menerapkan beberapa proyek serupa dan siap untuk membagikan pengamatan tersebut yang dapat memastikan penerapan sistem SAP yang lebih berhasil di cloud MS Azure. Beberapa pengamatan tidak akan menjadi penemuan, tetapi kami ingin menunjukkan penerapan beberapa pendekatan dalam platform cloud. Kami ingin berbagi pelajaran utama dengan Anda.



# 1: Mengoptimalkan Arsitektur TI Secara Konsisten Menggunakan Cloud



Sebagai bagian dari migrasi sistem produktif, kami menghadapi masalah konsumsi sumber daya yang tinggi dalam proses pengujian dan pengembangan, yang pada akhirnya membuat kami berpikir tentang mengapa kami membutuhkan begitu banyak sumber daya untuk lingkungan Pengujian dan Pengembangan dan cara mengoptimalkan konsumsi sumber daya infrastruktur oleh sistem produktif.



Pendekatan yang direkomendasikan untuk membangun sistem SAP didasarkan pada penilaian kapasitas yang diperlukan menggunakan kalkulator SAP Quick Sizer. Hingga saat ini, metodologi SAP didasarkan pada pendekatan standar yang tidak memperhitungkan kekhasan teknologi cloud. Kami menerima persyaratan dari Pelanggan, memasukkan data awal ke dalam penaksir SAP dan menerima konfigurasi lanskap awal. Dalam kasus infrastruktur konvensional, dimungkinkan untuk berhenti di situ dan beralih ke pembelian peralatan, tetapi dalam kasus kami, hal itu memungkinkan untuk memanfaatkan cloud. Di cloud, sumber daya dapat ditingkatkan kapan saja, dan oleh karena itu, kami mengabaikan cadangan sumber daya berlebih di pengukur dan menerapkan mesin dengan kinerja yang lebih rendah. Ini memungkinkan untuk mengurangi biaya,dan saat beban meningkat, kami selalu dapat meningkatkan kinerja mesin virtual SAP dalam hitungan menit.



Microsoft menyediakan dukungan SAP hanya pada VM seri M. Penggunaan sumber daya uji yang mirip dengan lingkungan produksi dalam hal tingkat dukungan pada tahap pengembangan awal tampak berlebihan bagi kami.



Pada saat yang sama, mesin seri-E memiliki karakteristik yang mirip dengan seri-M, tetapi biayanya jauh lebih murah. Hasilnya, kami mengganti mesin uji dengan seri E. Kelemahan dari penggantian ini adalah pengalihan tanggung jawab untuk pengoperasian sistem di lingkungan pengujian dari penyedia ke integrator. Ini memaksakan kebutuhan integrator untuk memiliki keahlian SAP.



gambar

gambar



# 2: Cara menghemat konsumsi sumber daya



MS Azure memungkinkan Anda untuk menghemat secara signifikan saat memesan sumber daya dengan pembayaran di muka simultan selama satu atau 3 tahun.



Seringkali, pada tahap awal, pelanggan tidak dapat secara akurat memperkirakan tanggal peluncuran sistem produksi, karena pengembangan dan pengujiannya sering dikaitkan dengan banyak variabel yang ada di pihak pengembang bisnis atau kontraktor.



Misalnya, pada saat peluncuran salah satu proyek, kami merencanakan penerapan semua lingkungan secara bersamaan berdasarkan rencana Pelanggan saat ini. Seperti yang sering terjadi, pengembangan tersebut membutuhkan koordinasi yang lebih lama dengan dunia usaha, yang mengakibatkan penundaan peluncuran produksi selama beberapa bulan.



Dalam contoh ini, saat memesan sumber daya dengan pembayaran di muka, Pelanggan akan kehilangan sejumlah besar dana. Tentu saja, perlu untuk mencadangkan sumber daya, tetapi akan lebih efisien untuk melakukannya pada tahap proyek selanjutnya, ketika sebagian besar sistem produktif telah stabil, dan pembangunan telah dapat diprediksi dalam hal konsumsi sumber daya. Seringkali, ketika Anda mencadangkan sumber daya komputasi selama 3 tahun, Anda bisa mendapatkan penghematan sekitar 70% dibandingkan dengan metode pembayaran Pay-As-You-Go.



gambar



# 3: Cara memilih wilayah Azure



Azure memiliki berbagai wilayah hosting sumber daya. Salah satu kriteria utama untuk memilih wilayah adalah keterpencilan infrastruktur Anda dari pengguna akhir, yang memengaruhi respons sistem dan kerja integrasi dan pengguna akhir.



Kriteria kedua yang tidak kalah pentingnya adalah daftar layanan di wilayah tertentu.



Beberapa layanan tersedia tergantung pada wilayah. Seringkali, layanan disediakan sebagai pratinjau sebelum rilis resmi. Beberapa wilayah lebih cepat memperkenalkan teknologi baru dan memungkinkan pengujian satu atau beberapa layanan baru. Tidak semua kawasan menyediakan kemampuan untuk menggunakan rangkaian lengkap rangkaian mesin virtual.

Dalam praktik kami, perbandingan kecepatan akses sering kali menunjukkan keunggulan kawasan Eropa Barat. Ini terutama terlihat untuk perusahaan yang server dan kliennya berlokasi di bagian Eropa Rusia. Dalam setiap kasus tertentu, dan terutama jika pusat data dan pelanggan Anda berada di Timur Jauh, sebaiknya periksa penundaan dari pusat data Anda (atau dari wilayah geografis tempat pelanggan Anda berada) untuk memilih wilayah Azure terbaik.



gambar



gambar



Layanan seperti Azure Latency Test memungkinkan Anda menguji latensi secara proaktif ke setiap wilayah Azure dari jaringan pusat data Anda. Contoh hasil pengukuran latensi menggunakan layanan yang disebutkan saat menguji dari kantor kami di Moskow:



gambar



# 4: Cara Menerapkan Metode Berbasis Tanah ke Instalasi Cloud



Dalam setiap migrasi, kami bertanya pada diri sendiri tentang bagaimana menggunakan solusi tradisional yang dibuktikan oleh infrastruktur klasik di cloud. Secara khusus, saat menyiapkan solusi, kami mengandalkan rekomendasi vendor untuk mengembangkan solusi yang secara teknis benar. Proyek SAP HANA tidak terkecuali dan juga melewati prisma rekomendasi dan praktik terbaik.



Di salah satu proyek, selama tahap pertama solusi, server Jump berbasis Windows telah digunakan. Untuk mengoptimalkan biaya tahap pengembangan awal, server NFS dipasang di server yang sama untuk kebutuhan lingkungan yang tidak produktif, yang mencakup kebutuhan pengembang saat ini dan memungkinkan penghematan sumber daya yang signifikan.



Seiring berjalannya waktu, persyaratan lingkungan dan sumber daya tumbuh, dan server NFS mengatasi semua tugas. Secara bertahap, dalam kerangka kerja proyek, kami mendekati penipisan sumber daya VM awal. Sumber daya VM di MS Azure dapat ditingkatkan dalam beberapa menit, tetapi pada saat yang sama persyaratan untuk toleransi kesalahan server telah meningkat, yang membuat kami mempertimbangkan konfigurasi ulang skala yang lebih besar.



Untuk implementasi, server Linux, layanan DRBD dan fungsionalitas kumpulan Ketersediaan digunakan, yang menutup masalah replikasi data antara node cluster NFS dan peningkatan ketersediaan jika terjadi kegagalan salah satu dari dua node cluster.



gambar



Omong-omong: beberapa bulan setelah implementasi solusi cluster, layanan File NetApp telah ditambahkan ke Azure, yang memungkinkan Anda untuk memanfaatkan array NetApp, tetapi dibayar oleh model Pay-As-You-Go.



# 5: Cara Mengotomatiskan Jadwal VM



Saat menggunakan infrastruktur cloud apa pun, selalu masuk akal untuk menganalisis mekanisme tambahan apa yang dapat digunakan untuk memaksimalkan penghematan biaya.



Dalam kasus kami, sistem diuji selama jam kerja. Sedangkan di server infrastruktur konvensional downtime diterjemahkan terutama ke dalam tagihan energi yang meningkat, di cloud, server yang tidak berguna menghabiskan dana untuk menyewa kapasitas. Kami mengevaluasi grafik beban pada server pengujian dan pengembangan dan melihat bahwa sebagian besar pengembang dan penguji menggunakan sistem pada hari kerja dari jam 8-00 hingga 20-00.



gambar



gambar



Jika jadwal pemuatan pada sistem yang tidak produktif dapat diprediksi dan bersiklus, kami mencoba menggunakan skrip untuk mengaktifkan / menonaktifkan VM secara otomatis. Azure memiliki beberapa alat: Auto-Shutdown, Automation Accounts, dan Cloud Shell. Tidak semuanya cocok untuk kita. Auto-shutdown dikecualikan karena hanya dapat mematikan VM. Cloud Shell juga tidak terlibat, karena memerlukan persiapan skrip tambahan, diagram dikembangkan, dan tempat yang aman untuk menyimpan semua ini dengan adanya redundansi, yang meminimalkan penghematan.



gambar



Dalam kasus kami, mekanisme yang lebih fleksibel digunakan. Automation Accounts menawarkan solusi yang siap pakai dan berfungsi dalam bentuk runbook, memungkinkan Anda untuk menghidupkan dan mematikan mesin virtual sesuai jadwal.



gambar



Kami menyiapkan grafik untuk masing-masing sumber daya, memuat runbook, dan membentuk tautan antara grafik dan sumber daya.



gambar



Hasilnya, kami semakin mengurangi total biaya kepemilikan. Awalnya, alat ini tidak direncanakan untuk diterapkan, tetapi sudah diimplementasikan pada tahap operasi awal.



Mengubah jadwal dilakukan dalam beberapa menit. Pertama, jadwal baru terbentuk, kemudian jadwal yang dihasilkan dikaitkan dengan sumber daya yang dibutuhkan. Jika perlu dan ada banyak perubahan, Cloud Shell dapat digunakan untuk mengotomatiskan proses ini.



# 6: Memantau konsumsi sumber daya





Sementara untuk pusat data konvensional, pemantauan kesehatan dan konsumsi sumber daya, sayangnya, biasanya menghilang ke latar belakang, maka dalam Azure tidak diinginkan untuk mengizinkan ini. Informasi tentang sejarah konsumsi sumber daya secara langsung mempengaruhi kemungkinan pengoptimalan biaya. Dan dalam kasus reservasi awal sumber daya, ini dapat berfungsi sebagai sinyal untuk perbaikan arsitektural.



# 7: Asuransi Force Majeure



Banyak perusahaan yang takut menempatkan sistem TI mereka pada sumber daya cloud karena takut akan penyumbatan, yang sebelumnya ditargetkan oleh regulator. Seperti risiko lainnya, ini juga dapat diperhitungkan saat merancang sistem. Dalam proyek, kami, sebagai suatu peraturan, menerapkan pembongkaran cadangan sistem mingguan dari cloud ke pusat data Pelanggan. Ini memungkinkan Anda untuk memastikan bahwa sistem dapat dipulihkan dalam segala kemungkinan. Selain itu, kami menggunakan strategi penginstalan multicloud, yang memungkinkan jika terjadi pembatasan akses tidak akan dibiarkan tanpa akses ke sumber daya. Dalam skenario ini, penyedia cloud alternatif digunakan sebagai situs DR untuk cloud utama, yang memungkinkan sistem dipulihkan jika terjadi penyumbatan besar-besaran.



No 7 + Pemrosesan data pribadi

Selama pekerjaan kami, kami telah membentuk pendekatan tentang cara menyimpan dan memproses data pribadi dalam sistem yang menyertakan sumber daya cloud asing. Perhatikan bahwa penerapan pendekatan ini harus dilakukan dengan mempertimbangkan persyaratan regulator. Topik ini cukup luas, dan kami akan mencoba membahasnya di artikel berikut jika kami memperhatikan minat yang sesuai pada komentar.



Hasil



Dalam artikel ini, kami meninjau beberapa pelajaran praktis tentang hosting SAP di cloud MS Azure. Jelas sekali, topiknya sangat luas dan kami hanya dapat menyentuh sebagian dari kemungkinan pengoptimalan saat bermigrasi ke cloud.



Nuansa apa yang Anda temui? Kami akan berterima kasih jika Anda membagikan pengalaman Anda di komentar.



All Articles