SIOS SANless clusters - SIOS SANless clusters High-availability Machine Learning monitoring

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
September 20, 2022	Webinar: Pemulihan Bencana untuk SQL Server di Cloud Publik Webinar: Pemulihan Bencana untuk SQL Server di Cloud Publik Daftar untuk Webinar Sesuai Permintaan Menjalankan instans SQL Server Anda ke salah satu platform cloud publik utama memerlukan strategi yang solid untuk pemulihan bencana dan ketersediaan tinggi. Pelajari cara merencanakan pemulihan bencana dan ketersediaan tinggi serta cara memutuskan yang terbaik untuk lingkungan Anda. Daftar untuk Webinar Sesuai Permintaan Direproduksi dengan izin dari SIOS
September 17, 2022	Webinar: Memahami Rantai Ketersediaan dan Dampaknya pada SQL Server Webinar: Memahami Rantai Ketersediaan dan Dampaknya pada SQL Server Daftar untuk Webinar Sesuai Permintaan Ada banyak faktor yang perlu dipertimbangkan saat mengevaluasi kemanjuran ketersediaan SQL Server Anda. Dalam webinar ini, Penginjil Teknis SIOS dan Microsoft Cloud and Datacenter MVP, Dave Bermingham, menguraikan komponen utama yang memungkinkan akses ke aplikasi Anda. Dia membahas rantai ketersediaan dan cara menentukan risiko waktu henti dan kegagalan Anda untuk setiap tautan – dan cara melindungi aplikasi bisnis Anda yang paling penting. Daftar untuk Webinar Sesuai Permintaan Direproduksi dengan izin dari SIOS