Manfaat SIOS Protection Suite/LifeKeeper untuk Linux

• SIOS perangkat lunak mendukung beberapa versi dan rasa sistem operasi (Linux dan Windows).
  • Pengalaman pengguna yang konsisten untuk melindungi sumber daya mission-critical terlepas dari sistem operasinya.
• SIOS memberikan solusi ketersediaan tinggi untuk berbagai lingkungan termasuk lingkungan lokal, virtual (VMware) dan cloud termasuk platform publik dari AWS , Azure, Google Cloud, serta lingkungan cloud yang dihosting secara pribadi. Alat yang sama dapat digunakan di lingkungan yang berbeda.
  • Lingkungan hybrid juga didukung. Dimungkinkan untuk mengonfigurasi node di lokasi sebagai lokasi utama dengan node sekunder dihosting di cloud pribadi dan node ketiga yang terletak di platform cloud publik yang menyediakan opsi DR (pemulihan bencana) tambahan.

• SIOS menyediakan mekanisme perlindungan aplikasi-sadar termasuk Kit Pemulihan Aplikasi ( TABUT s), tersedia untuk penyedia aplikasi dan database perusahaan terkemuka di dunia.
  • Perpustakaan lengkap kami tentang TABUT s melindungi jangkauan terluas aplikasi 'off-the-shelf'.
  • Aplikasi 'non-standar' atau warisan lainnya dapat dilindungi dengan 'GenApp' bawaan TABUT atau dengan mengembangkan kebiasaan TABUT baik in-house atau bekerja sama dengan SIOS insinyur.

• Tidak seperti alat sumber terbuka (yang memaksa pengguna untuk secara manual menetapkan parameter lingkungan terlebih dahulu dan kemudian mengetikkan serangkaian parameter baris perintah yang kompleks), serangkaian layar instalasi dan konfigurasi berbasis wizard memungkinkan pemilihan sumber daya yang intuitif yang memerlukan perlindungan dan membantu dalam memilih jenis dan tingkat perlindungan yang akan diberikan.
  • Wizards memindai sistem dan lingkungan untuk mengidentifikasi sumber daya yang akan dilindungi. Dalam kebanyakan kasus, operator hanya perlu mengonfirmasi pilihan default dan memasukkan ID host khusus lingkungan yang unik, dll. untuk menyelesaikan instalasi.
  • Ini mengurangi kemungkinan kesalahan konfigurasi solusi HA dan waktu henti tak terduga yang tak terhindarkan sebagai akibat dari kegagalan sistem atau aplikasi.
• SIOS menyediakan rangkaian lengkap opsi dukungan teknis termasuk dukungan kritis 24×7, menawarkan opsi dukungan yang disesuaikan dengan anggaran yang tersedia, kompleksitas sistem, atau kekritisan aplikasi yang membutuhkan ketersediaan tinggi.

Direproduksi dengan izin dari SIOS

Panduan Evaluasi SIOS Protection Suite untuk Linux untuk Lingkungan AWS Cloud

Mulai Mengevaluasi Suite Perlindungan SIOS untuk Linux di AWS

Gunakan panduan langkah demi langkah ini untuk mengonfigurasi dan menguji kluster dua simpul di AWS untuk melindungi sumber daya seperti Oracle, SQL Server, PostgreSQL, NFS, SAP, dan SAP HANA.

Sebelum Anda Memulai Evaluasi Anda

Tinjau tautan ini untuk memahami konsep utama yang Anda perlukan sebelum memulai proyek pengelompokan failover di AWS.

• Ketersediaan Tinggi, RTO , dan RPO – Dapatkan pemahaman yang jelas tentang konsep dasar HA.

• SIOS Suite Perlindungan untuk Linux – Komponen Terintegrasi – Memahami komponen yang disertakan dalam SIOS Protection Suite: SIOS LifeKeeper, DataKeeper, dan kit pemulihan aplikasi/

• Manfaat dari SIOS Paket Perlindungan untuk Linux – Pelajari bagaimana SIOS Protection Suite untuk Linux memberikan perlindungan data yang superior

• Bagaimana Beban Kerja Harus Didistribusikan saat Bermigrasi ke Lingkungan Cloud – Tidak seperti lingkungan di=lokasi, penawaran cloud publik memberi Anda berbagai zona ketersediaan wilayah geografis untuk dipilih saat menerapkan beban kerja Anda. Pelajari praktik terbaik untuk memilih strategi distribusi beban kerja untuk cloud.

• Platform Cloud Publik dan Perbedaan Struktur Jaringannya – Penyedia cloud publik memiliki struktur jaringan mereka sendiri. Pelajari dasar-dasar bagaimana struktur ini memengaruhi konfigurasi cluster Anda.

• Bagaimana Klien Terhubung ke Node Aktif – Pelajari mekanisme pengelompokan kunci yang mendeteksi dan mengelola respons terhadap kegagalan aplikasi.

• Bagaimana Replikasi Data antar Node Bekerja?– Memastikan redundansi penyimpanan sangat penting. Pelajari bagaimana SIOS DataKeeper secara efisien mereplikasi data antar node.

• Apa itu "Otak Terbelah" dan Bagaimana Menghindarinya Pelajari cara memastikan Anda mempertahankan satu node aktif dan satu atau lebih node siaga bahkan ketika koneksi jaringan gagal.

Mengonfigurasi Komponen Jaringan

Bagian ini menguraikan sumber daya komputasi yang diperlukan untuk setiap node, struktur jaringan dan proses yang diperlukan untuk mengkonfigurasi komponen ini.

• Pelajari cara mengonfigurasi komponen jaringan untuk pengelompokan failover
• Struktur Jaringan yang Digunakan dalam Tutorial ini
• Menghitung Sumber Daya yang Digunakan dalam Tutorial ini

Membuat Instance di AWS EC2 dari Awal

• Membuat Instance di AWS dari Awal
• Beralih antara AWS Jasa
• Memutuskan AWS Wilayah
• Menciptakan VPC
• Membuat Subnet
• Membuat Gateway Internet dan Menetapkannya ke VPC
• Membuat Tabel Rute
• Membuat Grup Keamanan
• Membuat Instans EC2 Pertama
• Membuat Instance Kedua dan Ketiga

Konfigurasikan Node Linux untuk Menjalankan SIOS Protection Suite untuk Linux

• Konfigurasikan Node Linux untuk Menjalankan SIOS Protection Suite untuk Linux

Instal Suite Perlindungan SIOS untuk Linux

• Instal Suite Perlindungan SIOS untuk Linux

Login dan Konfigurasi Dasar

• Login dan Konfigurasi Dasar

Melindungi Sumber Daya Kritis

• Membuat Sumber Daya IP di Lingkungan di tempat
• Beralih antar Node dalam a Lingkungan Awan

Setelah sumber daya IP dilindungi, lakukan peralihan (di mana simpul "siaga" menjadi simpul "aktif") untuk menguji fungsionalitasnya.

• Cara Beralih ke Simpul Siaga untuk Mengonfirmasi Peralihan Berfungsi
• Melindungi Sumber Daya Oracle
• Melindungi MSSQL Menggunakan Perlindungan Layanan Cepat
• Melindungi Sumber Daya PostgreSQL
• Melindungi dan NFS Sumber
• Melindungi GETAH Sumber daya
• Melindungi GETAH HANA Sumber daya

Direproduksi dengan izin dari SIOS

Kinerja Azure Shared Disk Dengan Zone Redundant Storage (ZRS)

Pada 9 September 2021, Microsoft diumumkan ketersediaan umum Penyimpanan Zona-Redundan (ZRS) untuk Penyimpanan Disk Azure , termasuk Disk Bersama Azure.

Yang membuat hal ini menarik adalah Anda sekarang dapat membangun instans cluster failover berbasis penyimpanan bersama yang menjangkau Availability Zone (AZ).Dengan node cluster yang berada di AZ yang berbeda, pengguna kini dapat memenuhi syarat untuk SLA ketersediaan 99,99%. Sebelum dukungan untuk Zone Redundant Storage, Azure Shared Disks hanya mendukung Locally Redundant Storage (LRS), membatasi penerapan cluster ke satu AZ, membuat pengguna rentan terhadap pemadaman jika AZ offline.

Namun ada beberapa batasan yang harus diperhatikan saat menggunakan Azure Shared Disk dengan ZRS.

• Hanya didukung dengan solid-state drive (SSD) premium dan SSD standar. Azure Ultra Disk tidak didukung.
• Disk Bersama Azure dengan ZRS saat ini hanya tersedia di wilayah AS Barat 2, Eropa Barat, Eropa Utara, dan Prancis Tengah
• Disk Caching, baik membaca dan menulis, tidak didukung dengan Premium SSD Azure Shared Disks
• Disk bursting tidak tersedia untuk SSD premium
• Dukungan Pemulihan Situs Azure belum tersedia.
• Azure Backup hanya tersedia melalui Azure Disk Backup.
• Hanya enkripsi sisi server yang didukung, Enkripsi Disk Azure saat ini tidak didukung.

Saya juga menemukan catatan menarik di dokumentasi .

“Kecuali untuk latensi tulis yang lebih banyak, disk yang menggunakan ZRS identik dengan disk yang menggunakan LRS, mereka memiliki target skala yang sama. Benchmark disk Anda untuk mensimulasikan beban kerja aplikasi Anda dan membandingkan latensi antara disk LRS dan ZRS.” Sementara dokumentasi menunjukkan bahwa ZRS akan menimbulkan beberapa latensi tulis tambahan, terserah pengguna untuk menentukan berapa banyak latensi tambahan yang dapat mereka harapkan. Tautan ke patokan disk dokumen disediakan untuk membantu memandu Anda dalam pengujian kinerja Anda.

Mengikuti panduan dalam dokumen, saya menggunakan DiskSpd untuk mengukur latensi tulis tambahan yang mungkin Anda alami. Tentu saja hasil akan bervariasi dengan beban kerja, jenis disk, ukuran instans, dll., tetapi inilah hasil saya.

	Penyimpanan Lokal Redundan (LRS)	Penyimpanan Berlebihan Zona (ZRS)
Tulis IOPS	5099.82	4994.63
Latensi Rata-rata	7.830	7.998

Tes DiskSpd yang saya jalankan menggunakan parameter berikut.

diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat Saya menulis ke disk P30 dengan ZRS dan P30 dengan LRS terpasang ke Standar DS3 v2 (4 vcpus, memori 14 GiB ) jenis contoh. ZRS P30 bersama juga dilampirkan ke instans identik di AZ berbeda dan ditambahkan sebagai penyimpanan bersama ke aplikasi klaster kosong.

Overhead 2% tampaknya merupakan harga yang wajar untuk dibayar agar data Anda didistribusikan secara sinkron di dua AZ. Namun, saya bertanya-tanya apa yang akan terjadi jika Anda memindahkan aplikasi berkerumun ke node jarak jauh, secara efektif menempatkan disk Anda di satu AZ dan instans Anda di AZ yang berbeda.

Berikut adalah hasilnya.

	Penyimpanan Lokal Redundan (LRS)	Penyimpanan Berlebihan Zona (ZRS)	ZRS saat menulis dari remote AZ
Tulis IOPS	5099.82	4994.63	4079.72
Latensi Rata-rata	7.830	7.998	9.800

Dalam skenario itu saya mengukur peningkatan latensi tulis 25%. Jika Anda mengalami kegagalan total pada AZ, penyimpanan dan instans akan dialihkan ke AZ sekunder dan Anda tidak akan mengalami peningkatan latensi ini sama sekali. Namun, skenario kegagalan lain yang tidak seluas AZ dapat membuat aplikasi terklaster Anda berjalan di satu AZ dengan Azure Shared Disk Anda berjalan di AZ yang berbeda. Dalam skenario tersebut, Anda ingin memindahkan beban kerja yang dikelompokkan kembali ke node yang berada di AZ yang sama dengan penyimpanan Anda sesegera mungkin untuk menghindari overhead tambahan.

Microsoft mendokumentasikan cara memulai failover akun penyimpanan ke wilayah yang berbeda saat menggunakan GRS, tetapi tidak ada cara untuk secara manual memulai failover akun penyimpanan ke AZ yang berbeda saat menggunakan Penyimpanan Zona Redundan. Anda harus memantau instans kluster failover untuk memastikan Anda diberi tahu setiap kali beban kerja kluster pindah ke server lain dan berencana untuk memindahkannya kembali segera setelah aman untuk melakukannya.

Anda dapat menemukan diri Anda dalam situasi ini secara tak terduga, tetapi itu juga pasti akan terjadi selama pemeliharaan terencana dari server aplikasi berkerumun saat Anda melakukan pembaruan bergulir. Kesadaran adalah kunci untuk membantu Anda meminimalkan jumlah waktu penyimpanan Anda bekerja dalam keadaan terdegradasi.

Saya berharap di masa depan Microsoft mengizinkan pengguna untuk memulai failover manual dari disk ZRS sama seperti yang mereka lakukan dengan GRS. Alasan mereka menambahkan fitur ke GRS adalah untuk menempatkan kekuasaan di tangan pengguna jika kegagalan otomatis tidak terjadi seperti yang diharapkan. Dalam kasus Zone Redundant Storage, saya dapat melihat orang-orang yang ingin mencoba menyatukan penyimpanan dan aplikasi, memastikan keduanya selalu berjalan di AZ yang sama, mirip dengan cara solusi replikasi berbasis host seperti SIOS DataKeeper melakukannya.