SIOS SANless clusters

Oktober 6, 2022	Kit Pemulihan Aplikasi Umum Kit Pemulihan Aplikasi Umum Itu Suite Perlindungan SIOS untuk Linux hadir dengan serangkaian Kit Pemulihan Aplikasi praktis yang mencakup basis data utama seperti SAP HANA dan Peramal , IP, Sistem File dan NAS atau NFS berbagi dan mengekspor. Setiap ARK yang disediakan SIOS memiliki skrip pemulihan (mulai), hapus (hentikan), periksa cepat, dan pulihkan – ini tidak dapat dikonfigurasi dengan mudah di luar opsi apa pun yang diminta selama konfigurasi dan penambahan ke dalam hierarki yang dilindungi. ARK ini dikembangkan, dipelihara, diperiksa kualitas, dan dalam beberapa kasus “disertifikasi dukungan” oleh vendor aplikasi itu sendiri. Apa yang Anda lakukan jika Anda memiliki aplikasi atau layanan yang tidak tercakup oleh SIOS ARK yang sudah ada? Masukkan ARK generik. ARK generik dapat ditambahkan ke dalam hierarki dan dikonfigurasi dengan cara yang mirip dengan ARK SIOS lainnya; hal khusus tentang ARK generik adalah Anda harus menyediakan skrip pemulihan, penghapusan, dan quickCheck dan secara opsional skrip pemulihan. Anda dapat menggunakan bahasa skrip yang dikonfigurasi untuk membuat skrip Anda (BASH atau Perl adalah umum), mari selidiki skrip ini lebih jauh: memulihkan: Ini adalah skrip yang digunakan untuk memulai layanan atau aplikasi Anda menghapus: Ini adalah skrip yang digunakan untuk menghentikan layanan atau aplikasi Anda pemeriksaan cepat: Skrip ini digunakan untuk menentukan apakah aplikasi atau layanan Anda berfungsi seperti yang Anda harapkan pulih: Skrip ini akan digunakan untuk mencoba pemulihan setelah kegagalan, aplikasi dan layanan tertentu memungkinkan untuk dimulai ulang atau perintah tertentu dijalankan untuk mencoba memulihkan dari skenario kegagalan Secara default, skrip quickCheck berjalan setiap 180 detik. Jika skrip quickCheck mendeteksi kegagalan aplikasi, skrip tersebut akan memanggil skrip pemulihan. Skrip pemulihan mencoba memulai ulang aplikasi pada node saat ini. Jika skrip pemulihan gagal memulai ulang aplikasi, atau skrip pemulihan tidak disediakan, skrip hapus akan dijalankan. Ini memulai failover ke node siaga. Template untuk Kit Aplikasi Generik SIOS menyediakan contoh template untuk Kit Aplikasi Generik.Contoh-contoh ini diinstal dengan perangkat lunak lifekeeper dan dapat ditemukan di sini: quickPeriksa, hapus, dan pulihkan /opt/Lifekeeper/lkadm/subsys/gen/app/template/actions/ pemulihan /opt/Lifekeeper/lkadm/subsys/gen/app/templates/recovery Ada contoh untuk quickCheck, hapus, dan pulihkan dalam bahasa BASH (.sh) dan Perl (.pl). Contoh skrip didokumentasikan sendiri dengan komentar di seluruh skrip. Dengan asumsi Anda terbiasa dengan BASH atau Perl maka Anda akan dapat memahami apa yang dilakukan skrip.. Kode pengembalian 0 menunjukkan proses yang berhasil, nilai lainnya menunjukkan kegagalan. Hasil skrip akan memicu tindakan selanjutnya yang diambil LifeKeeper. Pengaturan dalam Lifekeeper Setelah Anda membuat skrip Anda, Anda dapat membuat Aplikasi Generik dengan mengklik tanda plus hijau untuk membuat sumber daya baru. Pilih "Aplikasi Generik" untuk meluncurkan wizard konfigurasi. Tambahkan sumber daya dan pilih Aplikasi Generik Pilih skrip Pulihkan Pilih skrip Hapus mulai dari sini Pilih skrip QuickCheck Pilih skrip Pemulihan (tidak ada dalam contoh ini) Info Aplikasi adalah cara untuk menyampaikan informasi ke skrip GenAPP. Sebagai contoh, di GenAPP kami untuk penyeimbang beban generik, kami menggunakan bidang ini untuk melewati port yang didengarkan oleh penyeimbang beban. Pilih apakah Anda ingin membawa GenAPP online atau tidak setelah dibuat, terkadang Anda ingin membiarkan GenAPP offline sehingga Anda dapat membuat dependensi apa pun yang mungkin diperlukan. Beri nama resource yang akan dibuat Setelah Anda memasukkan semua informasi, sumber daya akan dibuat. Jadi, Anda dapat melihat bahwa membuat GenAPP untuk melindungi hampir semua aplikasi sangatlah mudah dan sederhana. GenAPP memungkinkan Anda untuk melindungi aplikasi APAPUN, bahkan aplikasi khusus yang dibuat secara internal. Jika Anda ingin mempelajari lebih lanjut tentang bagaimana SIOS dapat membantu Anda menjaga agar aplikasi penting bisnis Anda tetap tersedia, silakan hubungi kami! Direproduksi dengan izin oleh SIOS
Oktober 4, 2022	AWS Summit Singapura – SPONSOR PERAK AWS Summit Singapura – SPONSOR PERAK 6 Oktober @ 8:00 pagi – 5:00 sore SIOS senang menjadi sponsor Perak di AWS Summit Singapura tahun ini. Temukan bagaimana organisasi sektor publik dari semua ukuran menggunakan AWS untuk berinovasi dengan cepat, meningkatkan kehidupan warga, dan mengubah operasi mereka. Dengarkan rekan dan pakar materi pelajaran dari seluruh dunia yang telah berhasil membangun solusi di AWS.
Oktober 2, 2022	Cara mengonversi dari sumber daya SIOS NFS ke EFS Cara mengonversi dari sumber daya SIOS NFS ke EFS Karena banyak pelanggan ingin memigrasikan solusi SAP mereka ke AWS, mereka mungkin juga ingin mengonversi pembagian file jaringan (NFS) yang ada untuk sistem file /sapmnt atau /usr/sap/<SID> menjadi pembagian sistem file elastis (EFS).Pembagian EFS dihosting sebagai penyimpanan file cloud yang dapat dikelola sama seperti sistem file lokal mana pun. Dalam hal ini, data apa pun yang ditempatkan di bagian EFS akan memiliki perlindungan yang jauh lebih tinggi karena ketersediaan tinggi dan daya tahan yang disediakan. Langkah-langkah untuk Mengonversi Hirarki SAP yang Ada menggunakan NFS ke EFS Perusahaan yang saat ini menggunakan SIOS LifeKeeper untuk kluster Linux untuk melindungi SAP di tempat dapat dengan mudah mengubah hierarki SAP mereka dari NFS ke EFS menggunakan langkah-langkah langsung berikut. Prosesnya hanya memakan waktu sekitar 20 menit. Dalam contoh ini, solusi SIOS LifeKeeper Linux melindungi bagian ekspor NFS /exports/sapmnt/EDM dengan titik pemasangan lokal /sapmnt/EDM (yaitu 12.1.4.10:/exports/sapmnt/EDM /sapmnt/EDM) (Gambar 1) . Buat referensi berbagi EFS: https://docs.aws.amazon.com/efs/latest/ug/gs-step-two-create-efs-resources.html Pastikan untuk memperbarui grup keamanan ke yang digunakan instance Anda, ini harus dilakukan agar dapat dipasang. Alamat IP sistem file dapat ditemukan di bawah tab jaringan. Pasang bagian EFS pada simpul utama (ISP) ke lokasi sementara (yaitu /sapmnttmp) mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <ipaddress-filesystem>:/ /sapmnttmp Tambahkan SAP_NFS_CHECK_IGNORE=1 ke /etc/default/LifeKeeper di kedua node Pada titik ini ada entri yang dipasang untuk sistem file EFS. Sebelum pemeriksaan ini disetel, LifeKeeper sedang memeriksa mount NFS yang telah ada, Karena, kami tahu bahwa kami telah memasang sistem file efs, aman untuk mengaktifkan pemeriksaan ini untuk mengabaikan peringatan nfs karena sistem baru ini saat ini tidak dapat dikenali. Gunakan alat lkbackup LifeKeeper untuk membuat salinan cadangan dari konfigurasi LifeKeeper a./opt/LifeKeeper/bin/lkbackup -c -n Gunakan LifeKeeper GUI atau CLI untuk menghentikan sumber daya SAP (melakukan Out-of-Service) (Gambar 2) a./opt/LifeKeeper/bin/perform_action -t SAP-EDM_ASCS00 -penghapusan 6. Hentikan sapstartsrv yang tersisa, SAP ERS atau proses saposcol dan saphostexec pada node standby dan primer sebuah. lsof -c sap saya. bunuh <pid> 7. Salin data NFS dari ekspor NFS ke lokasi EFS baru sebuah. cp -pra /ekspor/sapmnt /sapmnttmp b. cp -pra /ekspor/usr/sap/EDM/ASCS00 /sapmnttmp 8. Ambil sumber daya hanfs osu sebuah. /opt/LifeKeeper/bin/perform_action -t hanfs-/exports/sapmnt/EDM -a hapus (Gambar 3) b. /opt/LifeKeeper/bin/perform_action -t hanfs-/exports/usr/sap/EDM/ASCS00 -a hapus (Gambar 4) 9. Gunakan umount untuk meng-unmount /sapmnt yang ada dan mount lokal NFS lainnya. sebuah. jumlah /ekspor/sapmnt/EDM b. umount /ekspor/usr/sap/EDM/ASCS00 10. Gunakan LifeKeeper GUI atau CLI untuk mengambil sumber dataep-sapmnt terkait OSU sebuah ./opt/LifeKeeper/bin/perform_action -t dataep-EDM -a hapus (Gambar 5) */opt/LifeKeeper/bin/perform_action -t dataep-ASCS00 -a hapus* (Gambar 6) Tambahkan entri mount untuk EFS ke /etc/fstab pada node 1 sebuah. Ganti tunggangan ekspor getah dengan efs saya. :/sapmnt/EDM /sapmnt/EDM nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 ii. :/ASCS00 /usr/sap/EDM/ASCS00 nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 Gunakan perintah umount untuk meng-unmount mount point /sapmnttmp sementara pada node 1 sebuah. umount /sapmnttmp Lepas dudukan getah sebuah. umount -l /sapmnt/EDM b. umount -l /usr/sap/EDM/ASCS00 Gunakan perintah mount untuk me-remount sistem file EFS pada node 1 sebuah. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport :/sapmnt/EDM /sapmnt/EDM b. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport :/ASCS00 /usr/sap/EDM/ASCS00 Sekarang Anda siap untuk menghapus ketergantungan antara Sumber daya SAP dan sumber daya SIOS HANFS dan NFS lama. Gunakan GUI untuk menghapus dependensi antara sumber daya SAP dan sumber daya HANFS dan NFS sebuah. Hapus nfs-/exports/dependencies dari SAP-EDM_ASCS00 b. Hapus dependensi hanfs-/ anak dari ip-12.1.4.10 c. Hapus dependensi anak, ip-12.1.4.10, dari sistem file nfs-/export/ d. Gunakan LifeKeeper GUI atau CLI untuk memulai sumber daya SAP (bawa sumber daya SAP dalam layanan) e. Hirarki baru akan terlihat seperti berikut (Gambar 7): f. Hapus hierarki hanfs-/exports dan nfs-/exports (Gambar 8) Tambahkan entri mount untuk EFS ke /etc/fstab pada node 2. sebuah. :/sapmnt/EDM /sapmnt/EDM nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 b. :/ASCS00 /usr/sap/EDM/ASCS00 nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 Gunakan perintah mount untuk me-remount sistem file EFS pada node 2, lihat langkah 13 sebelum menambahkan entri. sebuah. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 10.0.147.83:/sapmnt /sapmnt b. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 10.0.147.83:/ASCS00 /usr/sap/EDM/ASCS00 Verifikasi sumber daya SAP dimulai dengan benar termasuk sumber daya IP dan EC2 Gunakan LK GUI untuk melakukan peralihan ke target (atau node siaga) Selesai Kesimpulan Mengonversi sistem file NFS ke EFS adalah cara yang pasti untuk memberikan lebih banyak perlindungan pada data Anda dan memanfaatkan sumber daya cloud AWS. Ini juga menyederhanakan hierarki sumber daya yang membuat sistem file Anda lebih mudah dibaca dan dikelola. Langkah-langkah yang diberikan di atas akan memungkinkan transisi data Anda yang disimpan di cloud jauh lebih cepat dan lancar. Direproduksi dengan izin dari SIOS
September 28, 2022	Apa yang baru di SIOS LifeKeeper untuk Linux v 9.6.2? Apa yang baru di SIOS LifeKeeper untuk Linux v 9.6.2? SIOS LifeKeeper untuk Linux versi 9.6.2 sekarang tersedia! Versi baru ini mendukung v 8.6 dari distribusi Linux terkemuka, mendukung Azure Shared Disk, dan memberikan perlindungan tambahan dari skenario split brain yang dapat terjadi ketika koneksi jaringan antara node cluster gagal. Baru di SIOS LifeKeeper Linux, Versi 9.6.2 SIOS LifeKeeper Linux, versi 9.6.2 memanfaatkan perbaikan bug terbaru, pembaruan keamanan, dan dukungan aplikasi penting untuk infrastruktur mereka dan menambahkan dukungan untuk Miracle Linux v 8.4 untuk pertama kalinya serta dukungan untuk versi sistem operasi berikut: Red Hat Enterprise Linux (RHEL)8.6 Oracle Linux 8.6 Rocky Linux 8.6 Dukungan Baru untuk Disk Bersama Azure LifeKeeper untuk Linux v 9.6.2 sekarang disertifikasi untuk digunakan dengan disk bersama Azure, memungkinkan pelanggan untuk membangun klaster HA Linux di Azure yang memanfaatkan sumber daya disk bersama Azure yang baru. Perlindungan Penulisan Node Siaga LifeKeeper sekarang dapat menggunakan fitur Pemeriksaan Kesehatan Node Siaga yang baru untuk mengunci node siaga dari upaya penulisan ke perangkat penyimpanan bersama yang dilindungi, melindungi dari kerusakan data yang dapat diakibatkan oleh hilangnya koneksi jaringan antar node cluster. LifeKeeper Load Balancer Health Check Application Recovery Kit (ARK) SIOS LifeKeeper untuk Linux hadir dengan Application Recovery Kits (ARKs) yang menambahkan kecerdasan khusus aplikasi, memungkinkan otomatisasi konfigurasi cluster dan orkestrasi failover sesuai dengan praktik terbaik aplikasi. Versi terbaru SIOS LifeKeeper menyertakan ARK baru yang memudahkan pengguna untuk menginstal, menemukan, dan menggunakan fungsionalitas Load Balancer di AWS EC2. Hubungi SIOS di sini untuk informasi pembelian. Direproduksi dengan izin dari SIOS
September 24, 2022	Opsi Baru untuk Cluster Ketersediaan Tinggi, SIOS Memperkuat Dukungannya untuk Disk Bersama Microsoft Azure Opsi Baru untuk Cluster Ketersediaan Tinggi, SIOS Memperkuat Dukungannya untuk Disk Bersama Microsoft Azure Microsoft memperkenalkan Azure Shared Disk pada Q1 tahun 2022. Disk Bersama memungkinkan Anda untuk melampirkan disk yang dikelola ke lebih dari satu host. Secara efektif ini berarti bahwa Azure sekarang memiliki penyimpanan SAN yang setara, memungkinkan cluster Sangat Tersedia untuk menggunakan disk bersama di cloud! Keuntungan utama menggunakan Azure Shared Disk dengan hierarki cluster SIOS Lifekeeper adalah Anda tidak lagi diharuskan memiliki kuorum penyimpanan atau node saksi untuk menghindari apa yang disebut split-brain – yang terjadi ketika komunikasi antar node hilang dan beberapa node berpotensi mengubah data secara bersamaan. Lebih sedikit node berarti lebih sedikit biaya dan kompleksitas. SIOS telah memperkenalkan Kit Pemulihan Aplikasi (ARK) untuk kami LifeKeeper untuk Linux produk; disebut LifeKeeper SCSI-3 Persistent Reservations (SCSI3) Recovery Kit yang memungkinkan Azure Shared Disks digunakan bersama dengan reservasi SCSI-3. ARK ini menjamin bahwa disk bersama hanya dapat ditulis dari node yang saat ini menyimpan reservasi SCSI-3 pada disk tersebut. Saat menginstal SIOS Lifekeeper, penginstal akan mendeteksi bahwa itu berjalan di Microsoft Azure EC2 dan secara otomatis menginstal Kit Pemulihan LifeKeeper SCSI-3 Persistent Reservations (SCSI3) untuk mengaktifkan dukungan untuk Azure Shared Disk. Pembuatan sumber daya dalam Lifekeeper sangat mudah dan sederhana (Gambar 1). Setelah dipasang secara lokal, Azure Shared Disk hanya ditambahkan ke Lifekeeper sebagai sumber daya jenis sistem file. Lifekeeper akan memberinya ID (Gambar 2) dan mengelola penguncian SCSI-3 secara otomatis. Gambar 1] Pembuatan /sapinst dalam Lifekeeper. Gambar 2] /sapinst dibuat dan diperluas ke kedua node cluster. Reservasi SCSI-3 menjamin bahwa Azure Shared Disk hanya dapat ditulis pada node yang menyimpan reservasi (Gambar 3). Dalam skenario di mana node cluster kehilangan komunikasi satu sama lain, server siaga akan online, menyebabkan potensi situasi otak terbelah . Namun, karena reservasi SCSI-3 hanya satu node yang dapat mengakses disk pada satu waktu, yang mencegah skenario split-brain yang sebenarnya. Hanya satu sistem yang akan menahan reservasi dan itu akan menjadi node aktif baru (dalam hal ini yang lain akan reboot) atau tetap menjadi node aktif. Node yang tidak memegang reservasi Azure Shared Disk hanya akan berakhir dengan sumber daya dalam status "Siaga" karena mereka tidak dapat memperoleh reservasi. Gambar 3] Keluaran dari log Lifekeeper saat mencoba memasang disk yang sudah dicadangkan. Tautan ke definisi Microsoft tentang Azure Shared Disks https://docs.microsoft.com/en-us/azure/virtual-machines/disks-shared Saat ini SIOS mendukung Penyimpanan Berlebihan Lokal (LRS) dan kami bekerja sama dengan Microsoft untuk menguji dan mendukung Penyimpanan Berlebihan-Zona (ZRS). Idealnya kami ingin tahu kapan ada kegagalan ZRS sehingga kami dapat mengalihkan hierarki sumber daya ke node paling lokal ke penyimpanan aktif. Saat ini SIOS mengharapkan dukungan Azure Shared Disk akan tiba di rilis Lifekeeper 9.6.2 berikutnya untuk Linux, Q3 2022. Direproduksi dengan izin dari SIOS