Cara Mengurangi Waktu Henti di SAP

Memikirkan bagaimana caranya mengurangi waktu henti di SAP adalah topik penting yang harus dikunjungi selama desain solusi awal. Perubahan pada lanskap SAP yang ada dapat dibuat, ini bisa lebih rumit di lingkungan produksi yang ada di mana waktu henti akan menjadi masalah.

Ada beberapa komponen khas dalam lanskap SAP yang dapat dianggap sebagai titik kegagalan tunggal; ASCS (Layanan Pusat), HANA DB, node NFS, dan server Aplikasi SAP. Idealnya ini harus dilindungi dengan menggunakan server redundan dalam konfigurasi Ketersediaan Tinggi.

Sasaran HA/DR untuk SAP

Sasaran inti saat merancang komponen Ketersediaan Tinggi/Pemulihan Bencana untuk SAP harus:

● Minimalkan Waktu Henti ● Hilangkan kehilangan data ● Pertahankan integritas data ● Aktifkan konfigurasi yang fleksibel Di lingkungan cloud modern saat ini, infrastruktur perangkat keras yang mendasari biasanya terlindungi dengan baik dari kegagalan dengan menggunakan beberapa NIC redundan, penyimpanan redundan, dan zona ketersediaan perangkat keras – namun, ini masih tidak 't menjamin bahwa aplikasi SAP Anda akan berjalan dan menanggapi permintaan.

Menggunakan sebuah ketersediaan tinggi solusi seperti SIOS Protection Suite memperkenalkan Ketersediaan Tinggi yang cerdas yang digabungkan dengan replikasi disk lokal untuk memastikan bahwa aplikasi dan layanan SAP Anda terus dipantau, dilindungi, dan memiliki kemampuan untuk secara otomatis beralih ke perangkat keras yang berlebihan ketika kegagalan terdeteksi.

Sekarang mari kita pertimbangkan contoh sederhana dari konfigurasi SAP yang tidak dilindungi HA, mungkin terlihat seperti ini (gambar 1): Jika lingkungan ini digunakan untuk memproses transaksi dari server web yang digunakan untuk menjual pakaian kepada pelanggan, SAP digunakan untuk memproses penjualan, melacak pesanan, melacak inventaris, dan menyediakan beberapa pemesanan otomatis, dll berdasarkan transaksi ini.

Sekarang mari kita bayangkan bahwa lingkungan pemrosesan penjualan ini (gambar di atas) dikonfigurasi di cloud tanpa HA karena arsitek berpikir bahwa perangkat keras yang sangat redundan di lingkungan cloud cukup baik untuk melindungi dari kegagalan.Jika HANA DB mengalami masalah dan mati, mari kita lihat langkah-langkah yang biasanya diperlukan untuk membuat database kembali aktif dan berjalan: ● Bahkan jika HANA dikonfigurasi dengan Replikasi Sistem HANA, failover ke sistem DB HANA sekunder tidak otomatis. Ini akan membutuhkan seseorang yang mengetahui HANA untuk memperbaikinya, setelah kegagalan terdeteksi dan mereka diberitahu tentang pemadaman.
● Transaksi Waktu Nyata dari server web akan ditangguhkan hingga masalah teratasi Jika pengecer pakaian kecil ini bertransaksi sekitar $10 juta per tahun dari penjualan berbasis web, itu setara dengan kira-kira $1150 per jam dalam penjualan yang disamakan sepanjang tahun. Waktu puncak akan lebih mahal per jamnya.

Laporan ini dari IBM menunjukkan bahwa biaya waktu henti rata-rata per jam adalah $10k Gambar 2: Lanskap SAP dengan HA/DR Jika perangkat lunak HA telah digunakan (gambar 2), failover HANA DB akan otomatis dan interupsi ke server web akan berada dalam batas waktu yang dikonfigurasi dan sama sekali tidak ada penjualan yang hilang. Peringatan akan dibuat dan penyebabnya dapat dilihat dan didiagnosis dengan cara yang lebih santai daripada situasi sistem mati.

Tingkatkan ukuran pelanggan dan sangat mungkin bahwa situasi penurunan sistem apa pun akan mulai menelan biaya ratusan ribu dolar dan menghabiskan sumber daya orang yang signifikan untuk diselesaikan.

Lain laporan IBM menunjukkan bahwa 44% responden mengalami pemadaman tak terencana dua bulanan dan 35% lainnya mengalami pemadaman tak terencana bulanan.

Pemadaman terencana itu sendiri merupakan masalah potensial lainnya dengan 46% responden melaporkan pemadaman terencana bulanan dan 29% lainnya melaporkan pemadaman terencana tahunan. Memiliki aplikasi dan layanan yang dilindungi oleh perangkat lunak HA juga dapat mengurangi pemadaman terencana ini dengan mengizinkan layanan dipindahkan ke sistem yang berjalan selama aktivitas pemeliharaan.

Belajar lebih tentang ketersediaan tinggi untuk SAP dan S/4HANA .

Di blog ini saya akan membahas tentang Kit Pemulihan Aplikasi Penyeimbang Beban Umum (ARK) untuk SIOS Lifekeeper untuk Linux dan khususnya cara mengkonfigurasinya di Microsoft Azure. Saya akan menggunakan dua node NFS cluster dan ekspor NFS yang mereka berikan pada akhirnya akan diakses melalui load-balancer.

SIOS telah membuat ARK ini untuk memfasilitasi pengalihan klien di kluster LifeKeeper yang berjalan di Azure.

Karena Azure tidak mendukung ARP serampangan, klien tidak dapat terhubung langsung ke alamat IP virtual klaster tradisional. Sebaliknya, klien harus terhubung ke penyeimbang beban dan penyeimbang beban mengalihkan lalu lintas ke node cluster aktif. . Azure mengimplementasikan solusi penyeimbang beban yang beroperasi pada lapisan 4 (TCP, UDP), Penyeimbang Beban dapat dikonfigurasi untuk memiliki IP frontend pribadi atau publik, pemeriksaan kesehatan yang dapat menentukan simpul mana yang aktif, serangkaian alamat IP backend (untuk setiap node dalam sebuah cluster) dan aturan lalu lintas jaringan masuk/keluar.

Secara tradisional, pemeriksaan kesehatan akan memantau port aktif pada aplikasi dan menentukan node tempat aplikasi aktif, ARK penyeimbang beban generik SIOS dikonfigurasi untuk membuat node aktif mendengarkan pada port yang ditentukan pengguna. Port ini kemudian dikonfigurasi di Azure Load-balancer sebagai Port Probe Kesehatan. Hal ini memungkinkan node cluster aktif untuk merespons pemeriksaan kesehatan TCP, memungkinkan pengalihan klien otomatis..

Instalasi dan konfigurasi di Azure mudah dan terperinci di bawah ini:

Di dalam portal Azure, pilih load-balancing Buat penyeimbang beban, Anda akan memilih grup sumber daya tempat Anda ingin ini digunakan serta namanya, saya suka menggunakan nama yang sejalan dengan jenis klaster yang saya gunakan penyeimbang beban dengan misalnya IMA -NFS-LB akan berada di depan kedua node IMA-NFS.

Anda dapat menentukan apakah ini akan menjadi LB publik atau swasta. Dalam hal ini saya mengonfigurasi Load-Balancer pribadi ke depan server NFS saya untuk digunakan hanya dalam grup sumber daya ini.

Setelah Anda menentukan nama, grup sumber daya, dll., maka Anda akan diminta untuk menetapkan Nama, Jaringan virtual, subnet, dan IP untuk penyeimbang beban. Alamat IP harus sama dengan alamat IP yang akan Anda buat di LifeKeeper sebagai alamat IP virtual.

Setelah informasi dasar dimasukkan untuk penyeimbang beban, Anda perlu menentukan mesin mana yang akan dikonfigurasi di backend untuk melayani penyeimbang beban, dalam kasus saya kumpulan backend ini akan terdiri dari dua simpul yang saya gunakan untuk server NFS saya.

Anda akan memerlukan aturan load-balancing, ini adalah bagaimana load-balancer akan menentukan lalu lintas apa yang akan dirutekan ke node aktif. – Nomor port yang dikonfigurasi di sini akan digunakan di SPS-L saat Anda mengonfigurasi aplikasi generik untuk mendukung Load-balancer. Dalam contoh ini kami menggunakan "Port HA", yang akan mengarahkan semua lalu lintas ke node aktif. Jika Anda ingin membatasi lalu lintas yang akan dirutekan, Anda dapat menentukan port aplikasi tertentu.

IP frontend harus menjadi IP penyeimbang beban, kumpulan backend harus berupa node yang Anda konfigurasikan untuk menjadi sumber daya yang digunakan oleh penyeimbang beban. Pastikan tombol “HA Ports” dipilih dan “Floated IP” diaktifkan. "TCP reset" dapat dibiarkan dinonaktifkan.

Saat Anda membuat health probe, pastikan Anda mencatat port yang Anda konfigurasikan di sini karena akan digunakan saat kami membuat aplikasi generik di dalam SIOS Protection Suite. Anda dapat menggunakan nilai standar untuk "interval" dan "Ambang batas tidak sehat". Ini dapat diubah di lain waktu jika Anda memiliki persyaratan khusus aplikasi.

Sekarang aturan load balancing harus lengkap dengan pemeriksaan kesehatan. Pilih “Tambah” Setelah kami memilih "tambah" maka Azure akan memulai penyebaran Penyeimbang Beban, ini dapat memakan waktu beberapa menit dan setelah selesai maka konfigurasi beralih ke Suite Perlindungan SIOS.

CATATAN: Setelah mesin backend dikonfigurasi di belakang penyeimbang beban, mereka akan kehilangan akses ke gateway internet sehingga hal-hal seperti pembaruan sistem tidak akan berfungsi. Anda dapat menghapus mesin dari grup sumber daya backend untuk mengizinkan akses internet lagi.

Konfigurasi dengan SIOS Protection Suite

Untuk blog ini saya telah mengonfigurasi tiga ekspor NFS untuk dilindungi menggunakan SPS-L, ketiga ekspor tersebut dikonfigurasikan untuk menggunakan IP yang sama dengan IP frontend penyeimbang beban Azure. Saya menggunakan Datakeeper untuk mereplikasi data yang disimpan di ekspor.

Langkah pertama adalah mendapatkan skrip, cara paling sederhana adalah menggunakan wget tetapi Anda juga dapat mengunduh seluruh paket dan mengunggah rpm langsung ke node menggunakan wincp atau alat serupa. Anda perlu menginstal Hotfix di semua node di kluster Lifekeeper.

Seluruh kit pemulihan dapat diperoleh di sini: http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1 Bagian-bagiannya dapat ditemukan di sini dengan wget: wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt Setelah diunduh, verifikasi jumlah MD5 terhadap nilai yang tercatat di situs FTP.

Instal RPM sebagai berikut: rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm Periksa apakah penginstalan berhasil dengan menjalankan: rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172 Jika Anda perlu menghapus RPM karena alasan tertentu, ini dapat dilakukan dengan menjalankan: rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154 .x86_64 Di bawah ini adalah GUI yang menunjukkan tiga ekspor NFS saya yang telah saya konfigurasikan: Apa yang perlu kita lakukan dalam SIOS Protection Suite adalah menentukan Load Balancer menggunakan skrip Hotfix yang disediakan oleh SIOS.

Pertama kami membuat hierarki sumber daya baru, kami memilih Aplikasi Generik dari drop down Tentukan skrip restore.pl yang terletak di /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ Tentukan skrip remove.pl yang terletak di /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ Tentukan skrip quickCheck yang terletak di /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ Tidak ada skrip pemulihan lokal, jadi pastikan Anda menghapus input ini Ketika diminta untuk Info Aplikasi, kami ingin memasukkan nomor port yang sama seperti yang kami konfigurasikan dalam konfigurasi Health Probe misalnya 54321 Kami akan memilih untuk membawa layanan ke layanan setelah dibuat.

Resource Tag adalah nama yang akan kita lihat ditampilkan di GUI SPS-L, saya suka menggunakan sesuatu yang membuatnya mudah untuk diidentifikasi.

Jika semuanya dikonfigurasi dengan benar, Anda akan melihat "AKHIR pemulihan yang berhasil", kami kemudian dapat memperluas ini ke node lain sehingga sumber daya dapat di-host di salah satu node.

Ini menunjukkan konfigurasi Load Balancer yang telah selesai mengikuti ekstensi ke kedua node.

Langkah terakhir untuk cluster ini adalah membuat dependensi turunan untuk ketiga ekspor NFS, artinya semua ekspor NFS lengkap dengan mirror dan IP Datakeeper akan mengandalkan Load Balancer. Jika masalah serius terjadi pada node aktif maka semua sumber daya ini akan dialihkan ke node lain yang berfungsi.

Di atas, hierarki lengkap di Lifekeeper GUI. Di bawah ini menunjukkan tampilan GUI yang diperluas yang menunjukkan ekspor NFS, IP, Filesystems, dan volume replikasi DataKeeper sebagai anak-anak dari sumber daya Load Balancer.

Ini hanyalah salah satu contoh bagaimana Anda dapat menggunakan SIOS LifeKeeper di Biru langit untuk melindungi cluster NFS sederhana. Konsep yang sama berlaku untuk aplikasi penting bisnis apa pun yang perlu Anda lindungi. Anda hanya perlu memanfaatkan ARK Penyeimbang Beban yang disediakan oleh SIOS untuk memungkinkan Penyeimbang Beban Azure (Internal atau Eksternal) untuk menentukan node mana yang saat ini menghosting aplikasi.