Blog ini akan menjabarkan mengenai pengalaman dan riset dalam melakukan POC di SAPLinuxLab dengan menerapkan metode container. Aplikasi SAP cluster yang digunakan tersebut diinstall pada Kubernetes. Pada bagian pertama ini akan dijelaskan mengenai cakupan kerja, tujuan, instalasi, dan bagaimana mengembangkan ABAP di kubernetes.
Ketahui juga untuk apa saja keunggulan menggunakan SAP Hana “Keuntungan SAP HANA”
1. Cakupan Kerja SAP Cluster
Setiap sistem ABAB terbagi menjadi 3 bagian: pertama yaitu database yang digunakan untuk menyimpan data dan program, kedua yaitu aplikasi server, dan ketiga client. Pembahasan dari POC ini hanya mencakup pada aplikasi server saja.
SAP NetWeaver Aplication Server ABAP dapat dipecah menjadi beberapa bagian, dimana masing-masing bagian tersebut dapat ditaruh pada container. Aplikasi Server Instance diproritaskan untuk ditaruh di container
karena tidak memiliki dampak yang besar terhadap aplikasi lainnya, serta kebutuhannya cenderung dapat diukur dengan mudah. Namun, kita juga dapat memilih untuk melakukan deployment beberapa komponen mandatori dari ABAB Central Services, yaitu Message Server dan Enqueue Server. Pada tahap akhir, kita men-deploy SAP Webdispatcher dan SAP Router untuk dikonfigurasi.
Pembahasan mengenai database SAP cluster HANA berada di luar pembahasan saat ini, database SAP cluster Hana dianggap memberikan eksternal resource yang dapat dihubungkan melalui konfigurasi credential.
2. Konfigurasi
Docker Image dan Kubernetes Deployment File
Pada Kubernetes, aplikasi “dipecah” sebelum melakukan pembuatan image container dengan file deployment Kuberntes YAML.
Tujuan kami adalah membangun image ABAP dengan environment yang dikonfigurasi menggunakan file Kubernetes YAML. Pada saat deployment, ABAP image akan diinjeksi pada environment Kubernetes.
Beberapa atribut sifatnya statik, tidak dapat dirubah, serta tidak akan dikonfigurasi pada POC ini adalah :
- SAP SID
- SAP Instance Number
- SAP Admin User
Kami juga memilih SAP cluster Kernel yang paling baru dan compatible dengan NetWeaver dan S4Hana.
Ketahui juga cara untuk “Memilih Provider SAP on Cloud” yang tepat untuk menjalankan SAP Anda
3. Deployment di Kubernetes
Application Server
Beban kerja sesungguhnya pada sistem ABAP Application Server berada di sisi server. Pada sisi ini, memori dan CPU akan bekerja lebih banyak, selain database. Sehingga penting untuk mendefinisikan beban kerja terlebih dahulu. Sangat tidak disarankan untuk menurunkan kapasitas atau scale down dari Application Server Instance karena berisiko merusak user sessions. Sedangkan deployment dapat diturunkan pada user-controlled order, berkebalikan dengan “Statefulset” dimana bersifat reversed-ordered yang memungkinkan untuk di scale down tanpa menghiraukan beban sesi user.
Kami memecahkan masalah shutdown dengan mengimplementasikan logika “Horizontal Pod Autoscaler” : Anotasi prioritas ditugaskan menurut beban sesi saat terjadi. Kapanpun scale down dilakukan, server dengan prioritas rendah akan di-shutdown.
Sebagai aplikasi yang proses pengerjaannya memproduksi beberapa log file, sidecar container digunakan untuk menarik log dan meneruskan log target ke setiap pod Application Server.
Message Server dan Enqueue Server
Message Server adalah instance tunggal, seperti enqueue server. Untuk fleksibilitas yang lebih baik dibuat pembagian image container, dengan meletakannya dalam 1 pods yang dinamakan ASCS (ABAP SAP Central Instance). Sejak itu diperlukan untuk application server untuk meraih message server melalui DNS statis, oleh karena itu penempatan ASCS pods di statefulset dapat memecahkan masalah.
Sejak message server menjadi stateless, proses restart container menjadi hal yang tidak kritikal. Enqueue Server tetap mengunci table sehingga tidak stateless. Untuk mengimplementasikan high availability untuk enqueue server disarankan untuk membuat enqueue server cadangan untuk menyimpan hasil pengkopian tabel. Hal ini disebut dengan replikasi enqueue dan dapat dilakukan dengan membuat pod singleton lainnya.
Ketahui juga untuk kemudahan melakukan Disaster Recovery untuk SAP di Cloud “Disaster recovery plan for SAP”
SAPRouter dan Web Dispatcher
SAP Router berfungsi untuk menghubungkan klien kepada application server dalam mengakses sistem melalui SAP GUI. Berbeda dengan load balancer Kubernetes, SAP Router mengetahui protokol SAPDIAG dan meneruskannya ke koneksi sesi terkait. SAP Router merupakan stateless dan dapat di-scale dengan mudah jika diperlukan.
Komunikasi dan Konektivitas Klien
Setelah seluruh komponen SAP cluster diatur dalam pods kubernetes, kita harus memastikan seluruh komponen tersebut dapat saling terhubung satu sama lain, termasuk dengan klien.
– Services
Komunikasi antara pods di cluster Kubernetes dikerjakan melalui services. Sejak Kubernetes melakukan port mapping secara otomatis pada node dimana beberapa pods membuka port identic, konfigurasi ini mengijinkan application server SAP ditingkatkan pada single node tanpa adanya konflik antar port. Application server Deployment dan ASCS statefullset disimpan pada service Kubernetes.
–Load Balancer
Koneksi dari klien eksternal (SAP GUI, Web) menuju services dikerjakan oleh external load balancer. Tipe load balancer tergantung dari infrastruktur di mana Kubernetes berjalan. Untuk POC ini kita menggunakan OpenStack dengan load balancer HAProxy, layaknya infrastruktur bare-metal. Deploy load balancer membutuhkan koneksi API ke dalam layer IaaS.
Dapatkan Layanan Cloud SAP dan Solusi dari permasalahan SAP Anda di Datacomm disini “SAP Landing Page“
–Namespaces
Pada tahap akhir, dilakukan pengaturan terhadap seluruh objek SAP Kubernetes di dalam Namespace Kubernetes yang telah dipecah menjadi beberapa clustero Selanjutnya, beberapa SAP Instances dapat disimpan di cluster tunggal dengan membaginya ke dalam beberapa namespace, seperti Sapqa, sapdev, sapprod.
Referensi: SAP Blog