Buku Putih: Solusi Ketersediaan Tinggi Memberikan Penghematan Biaya dan Fleksibilitas untuk Oracle

Migrasi database Oracle bisa sangat sulit. Prosesnya seringkali rumit dan bisa mahal. Namun, terkadang migrasi tidak dapat dihindari. Hal ini terutama benar ketika pertimbangan dukungan dan perizinan bersama-sama membuat migrasi menjadi suatu keharusan. Dan saat memigrasikan database penting bisnis, penting untuk memberikan perlindungan ketersediaan tinggi untuk mencegah waktu henti, yang mengakibatkan hilangnya pendapatan dan produktivitas. Oracle telah mengumumkan bahwa dukungan untuk Oracle Database 12c akan segera berakhir. Oleh karena itu, organisasi yang menjalankan Oracle Database 12c akan menghadapi persyaratan segera untuk bermigrasi.

Unduh Buku Putih: Solusi Ketersediaan Tinggi Memberikan Penghematan Biaya dan Fleksibilitas untuk Oracle

Buku Putih: Memahami Kompleksitas Ketersediaan Tinggi untuk Aplikasi Bisnis-Kritis

Dalam ekonomi global yang sangat kompetitif dan selalu aktif saat ini, waktu henti menjadi lebih mahal daripada sebelumnya untuk bisnis modern. Selain kehilangan produktivitas dan pendapatan, organisasi berisiko kehilangan pelanggan ketika sistem, database, dan aplikasi penting bisnis mereka tidak tersedia untuk memberikan pengalaman pelanggan yang andal dan unggul. Laporan singkat teknologi dari SIOS ini menjelaskan kerumitan dalam mencapai ketersediaan tinggi dalam aplikasi penting bisnis.

Unduh Buku Putih: Memahami Kompleksitas Ketersediaan Tinggi untuk Aplikasi Bisnis-Kritis

Memperkenalkan Kit Penyeimbang Beban Umum untuk SIOS LifeKeeper dan Google Cloud

Ini akan membahas Kit Pemulihan Aplikasi Penyeimbang Beban Umum (ARK) untuk SIOS Lifekeeper untuk Linux dan khususnya cara mengonfigurasinya di Google Cloud. SIOS ARK adalah plug-in ke produk SIOS LifeKeeper yang menambahkan platform atau aplikasi – kesadaran.

Blog ini menunjukkan bagaimana menggunakan kluster NFS dua simpul dan ekspor NFS yang mereka berikan pada akhirnya dapat diakses melalui penyeimbang beban.

SIOS telah membuat ARK ini untuk memfasilitasi pengalihan klien di SIOS LifeKeeper cluster yang berjalan di GCP .

Karena GCP tidak mendukung ARP serampangan – permintaan siaran untuk alamat IP router sendiri – klien tidak dapat terhubung langsung ke alamat IP virtual cluster tradisional. Sebaliknya, klien harus terhubung ke penyeimbang beban dan penyeimbang beban mengalihkan lalu lintas ke node cluster aktif. GCP mengimplementasikan solusi load-balancer terpisah yang beroperasi pada layer 4 TCP, layer 4 UDP atau layer 7 HTTP/HTTP, Load-Balancer dapat dikonfigurasi untuk memiliki IP frontend pribadi atau publik, sebuah health-probe yang dapat menentukan mana node aktif, serangkaian alamat IP backend (untuk setiap node dalam 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 GCP Load-balancer sebagai Health Probe Port. Hal ini memungkinkan node cluster aktif untuk merespons pemeriksaan kesehatan TCP, memungkinkan pengalihan klien otomatis..

Instalasi dan konfigurasi di GCP sangat mudah dan terperinci di bawah ini:

Di dalam portal GCP, pilih load-balancing Dalam contoh ini kami ingin TCP Load Balancing Buat penyeimbang beban, Anda akan memilih grup sumber daya di mana Anda ingin ini digunakan serta namanya, saya suka menggunakan nama yang sejalan dengan tipe cluster yang saya menggunakan load balancer misalnya IMA-NFS-LB akan duduk di depan kedua node IMA-NFS.

Anda dapat menentukan apakah ini akan menghadap ke Internet atau internal ke VPC Anda. Dalam hal ini saya mengonfigurasi Load-Balancer internal saja ke depan server NFS saya untuk digunakan hanya di dalam VPC saya.

Setelah Anda menentukan nama, wilayah, dll., maka Anda akan diminta untuk menetapkan konfigurasi Backend, ini akan memerlukan grup instance yang berisi node HA yang akan Anda front-end.

Setelah Anda menetapkan grup instans, Anda akan menentukan pemeriksaan kesehatan – ini adalah port yang cocok dengan port yang akan Anda gunakan dalam konfigurasi Lifekeeper Generic Load-balancer dalam hal ini saya menggunakan 54321. Sekali lagi, perhatikan nomor port karena ini akan digunakan dengan Lifekeeper.

Saya hanya terjebak dengan nilai default untuk kriteria Kesehatan.

Setelah informasi konfigurasi backend dan healthcheck dimasukkan untuk load-balancer, Anda perlu menentukan konfigurasi frontend. Ini terdiri dari subnet, wilayah, dan IP yang ingin Anda buat untuk penyeimbang beban.

Anda akan mengonfigurasi IP Anda dan ini akan cocok dengan IP Lifekeeper yang Anda lindungi.

Setelah Anda puas dengan konfigurasinya, Anda dapat meninjaunya atau cukup klik buat.

Setelah kita memilih “buat” maka GCP akan memulai penerapan Load Balancer, ini dapat memakan waktu beberapa menit dan setelah selesai maka konfigurasi beralih ke SIOS Protection Suite.

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 GCP. saya menggunakan Penjaga data untuk mereplikasi data yang disimpan pada 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 Suite Perlindungan SIOS 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 Saat diminta untuk Info Aplikasi, kami ingin memasukkan nomor port yang sama seperti yang kami konfigurasikan di port Pemeriksaan Kesehatan 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 memudahkan untuk mengidentifikasi 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 GCP 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 GCP (Internet atau Internal) menentukan node mana yang saat ini menghosting aplikasi.

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 .