Archives for Desember 2018

Praktik Terbaik Untuk Menghilangkan SPoF Dalam Arsitektur Cluster

Desember 16, 2018 by Jason Aw Leave a Comment

Praktik Terbaik Untuk Menghilangkan SPoF Dalam Arsitektur Cluster

Banyak sebagai rantai hanya sekuat tautan terlemah, efektivitas cluster ketersediaan tinggi dibatasi oleh satu titik kegagalan (SPOF) yang ada dalam penyebarannya. Untuk memastikan tingkat ketersediaan tertinggi absolut, SPOF harus dihapus. Ada metode langsung untuk membersihkan kelompok dari tautan yang lemah ini.

Mengambil Langkah Pertama

Dengan bijaksana, identifikasi setiap SPOF yang ada dengan perhatian khusus yang dibayarkan ke server, koneksi jaringan, dan perangkat penyimpanan ketika Anda perlu Menghilangkan SPoF Dalam Arsitektur Cluster. Server modern dilengkapi dengan redundan dan kesalahan mengoreksi memori, data striping di hard disk dan beberapa CPU yang menghilangkan sebagian besar komponen perangkat keras sebagai SPOF. Perangkat lunak dan kesalahan manusia, bagaimanapun, dapat mengakibatkan server atau aplikasi downtime. Menyebarkan solusi klaster ketersediaan tinggi yang memantau kesehatan server dan aplikasi penting dan mengambil tindakan pemulihan otomatis jika terjadi kegagalan menghilangkan SPOF ini. Semua solusi pengelompokan menyediakan tes ping dasar untuk memvalidasi fungsionalitas server. Tetapi hanya penawaran yang lebih canggih yang juga melacak kesehatan aplikasi dan memiliki kemampuan untuk pulih secara otomatis dari kegagalan yang terdeteksi. Tingkat deteksi dan pemulihan yang lebih dalam ini meminimalkan waktu henti. Membuat arsitektur semua komponen cluster untuk redundansi sangat penting untuk memaksimalkan waktu kerja. Koneksi ke penyimpanan sering mewakili SPOF dan sangat penting bahwa multi-pathing diarsipkan ke konfigurasi penyimpanan bersama. Linux DM Multipath (DM-MPIO) menyediakan pengubahan rute blok I / O ke jalur alternatif jika terjadi kegagalan jalur. Ini menghilangkan semua komponen di jalur dari server ke penyimpanan sebagai SPOF potensial dan menyediakan pemulihan otomatis jika terjadi kegagalan.

Apa Lagi Yang Bisa Dilakukan

Tetapi bahkan dikonfigurasi dengan multi-pathing, penyimpanan bersama / SAN masih merupakan titik kegagalan tunggal seperti halnya pusat data fisik di mana ia berada. Untuk memberikan perlindungan lebih lanjut, replikasi data penting di luar lokasi yang dikombinasikan dengan pengelompokan lintas-situs harus diterapkan. Dikombinasikan dengan redundansi jaringan antar situs, solusi optimal ini akan Menghilangkan SPoF In Cluster Architecture. Replikasi real-time memastikan bahwa salinan data penting bisnis terkini selalu tersedia. Melakukan hal ini di luar situs ke pusat data cadangan atau ke layanan cloud juga melindungi terhadap penghentian pusat data utama yang dapat dihasilkan dari kebakaran, pemadaman listrik, dll. Penggunaan pemantauan tingkat aplikasi dan pemulihan otomatis, multi-jalur untuk penyimpanan bersama, dan replikasi data untuk perlindungan di luar lokasi masing-masing menghilangkan potensi Titik Tunggal Kegagalan dalam arsitektur klaster Anda. Memperhatikan komponen-komponen ini selama arsitektur cluster dan penyebaran akan memastikan tingkat uptime yang paling mungkin.

Mencari cara terbaik Menghilangkan SPoF Dalam Arsitektur Cluster bukanlah ilmu roket, mengobrol dengan kami Direproduksi dengan izin dari Linuxclustering

Cara Mengatur Biaya Rendah SAN Dengan Perangkat Lunak Linux Target iSCSI

Desember 12, 2018 by Jason Aw Leave a Comment

Panduan Langkah-demi-Langkah Untuk Mengatur Biaya Rendah SAN Dengan Perangkat Lunak Linux Target iSCSI

Target iSCSI perangkat lunak dapat menjadi cara yang bagus untuk menyiapkan penyimpanan bersama saat Anda tidak memiliki cukup adonan untuk membeli perangkat keras SAN yang mahal. Target iSCSI bertindak seperti rangkaian perangkat keras iSCSI yang sebenarnya, kecuali itu hanya perangkat lunak yang berjalan di server tradisional (atau bahkan VM!). Menyiapkan target iSCSI adalah cara mudah dan murah untuk mendapatkan penyimpanan bersama yang Anda butuhkan. Tidak masalah jika Anda menggunakan produk pengelompokan seperti Microsoft Windows Server Failover Clustering (WSFC), sistem file klaster seperti GFS atau OCFS. Atau bahkan jika Anda ingin mendapatkan hasil maksimal dari platform virtualisasi Anda (baik itu VMware, XenServer, atau Hyper-V) dengan mengaktifkan penyatuan penyimpanan dan migrasi langsung.

Tentang Lio-Target

Baru-baru ini, kernel Linux telah mengadopsi LIO-Target sebagai target iSCSI standar untuk Linux. LIO-Target tersedia di kernel Linux 3.1 dan lebih tinggi. LIO-Target mendukung SCSI-3 Persistent Reservations, yang diperlukan oleh Windows Server Failover Clustering, VMware vSphere, dan produk pengelompokan lainnya. The LUNs (disk) yang disajikan oleh target iSCSI dapat berupa seluruh disk, partisi, atau bahkan file lama pada sistem file. LIO-Target mendukung semua opsi ini. Di bawah ini, kami akan membahas langkah-langkah untuk mengonfigurasi LIO-Target pada server Ubuntu 12.04. Distro baru lainnya mungkin akan berfungsi juga, tetapi langkah-langkahnya mungkin sedikit berbeda.

Langkah-Langkah Konfigurasi

Pertama, instal paket Lio-target:

# apt-get install –no-install-recommends targetcli python-urwid Lio-target dikontrol menggunakan utilitas baris perintah targetcli. Langkah pertama adalah membuat backing store untuk LUN. Dalam contoh ini, kami akan menggunakan LUN yang didukung file, yang hanya file biasa pada sistem file server target iSCSI. # targetcli /> cd backstores / / backstores> ls o- backstores …………………………………………………… […] o- fileio ………………………… ………………. [0 Obyek Penyimpanan] o-iblock …………………………………………. [0 Objek Penyimpanan] o- pscsi ………………………………………… .. [0 Objek Penyimpanan] o- rd_dr ………………………………………… .. [0 Objek Penyimpanan] o- rd_mcp …………………………………………. [0 Objek Penyimpanan] / backstores> cd fileio / backstores / fileio> membantu membuat (untuk bantuan) / backstores / fileio> membuat lun0 / root / iscsi-lun0 2g (membuat file 2GB yang didukung LUN)

Tahap kedua

Sekarang LUN dibuat. Setengah jalan di sana untuk Mengatur Biaya Rendah SAN dengan Perangkat Lunak Linux iSCSI Target. Selanjutnya, kami akan menyiapkan target sehingga sistem klien dapat mengakses penyimpanan. / backstores / fileio / lun0> cd / iscsi / iscsi> buat (buat iqn dan grup port target) Buat target iqn.2003-01.org.linux-iscsi.murray.x8664: sn.31fc1a672ba1. Tag TPG yang dipilih 1. Berhasil menciptakan TPG 1. Memasukkan node baru /iscsi/iqn.2003-01.org.linux-iscsi.murray.x8664:sn.31fc1a672ba1/tpgt1 /iscsi/iqn.20…a672ba1/tpgt1> mengatur otentikasi atribut = 0 (menonaktifkan chap auth) / iscsi / iqn.20… a672ba1 / tpgt1> cd luns /iscsi/iqn.20…a1/tpgt1/luns> buat / backstores / fileio / lun0 (buat target LUN) LUN 0 terpilih. Berhasil membuat LUN 0. Memasukkan new node /iscsi/iqn.2003-01.org.linux-iscsi.murray.x8664:sn.31fc1a672ba1/tpgt1/luns/lun0/iscq/iqn.20…gt1/luns/lun0> cd ../ .. / Portal lalu lintas iSCSI dapat menghabiskan banyak bandwidth. Anda mungkin ingin lalu lintas iSCSI berada di jaringan khusus (atau SAN), bukan jaringan publik Anda. /iscsi/iqn.20…tpgt1/portals> buat 10.10.102.164 (buat portal untuk mendengarkan koneksi) Menggunakan port IP default 3260 Berhasil membuat portal jaringan 10.10.102.164:3260. Memasukkan new node /iscsi/iqn.2003-01.org.linux-iscsi.murray.x8664:sn.31fc1a672ba1/tpgt1/portals/10.10.102.164:3260/iscsi/iqn.20….102.164:3260> cd .. /iscsi/iqn.20…tpgt1/portals> buat 10.11.102.164 Menggunakan port IP default 3260 Berhasil membuat portal jaringan 10.11.102.164:3260. Memasukkan new node /iscsi/iqn.2003-01.org.linux-iscsi.murray.x8664:sn.31fc1a672ba1/tpgt1/portals/10.11.102.164:3260 /iscsi/iqn.20…102.164:3260> cd ../ ../acls

Langkah terakhir

Daftarkan inisiator iSCSI (sistem klien) untuk Mengatur SAN Biaya Rendah dengan Perangkat Lunak Linux iSCSI Target. Untuk melakukan ini, Anda harus menemukan nama pemrakarsa sistem. Untuk Linux, ini biasanya ada di /etc/iscsi/initiatorname.iscsi. Untuk Windows, nama inisiator ditemukan di Panel Properti Inisiator iSCSI di Tab Konfigurasi. /iscsi/iqn.20…a1/tpgt1/acls> buat iqn.1994-05.com.redhat: f5b312caf756 (daftar inisiator – ini IQN adalah IQN dari inisiator – lakukan ini untuk setiap inisiator yang akan mengakses target) Berhasil dibuat Node ACL untuk iqn.1994-05.com.redhat: f5b312caf756 Dibuat memetakan LUN 0. Memasukkan node baru /iscsi/iqn.2003-01.org.linux-iscsi.murray.x8664:sn.31fc1a672ba1/tpgt1/acls/iqn.1994-05.com.redhat:f5b312caf756/iscsi/iqn.20….102.164 : 3260> cd / Sekarang, ingatlah untuk menyimpan konfigurasi. Tanpa langkah ini, konfigurasi tidak akan persisten. /> saveconfig (SIMPAN konfigurasi!) /> keluar Anda sekarang harus menghubungkan penggagas Anda ke target. Umumnya Anda harus memberikan alamat IP target untuk menyambungkannya. Setelah koneksi dibuat, sistem klien akan melihat disk baru. Disk harus diformat sebelum digunakan. Dan itu dia! Anda siap menggunakan SAN baru Anda. Selamat bersenang-senang! Memiliki masalah untuk Mengatur SAN Biaya Rendah dengan Perangkat Lunak Linux Target iSCSI, baca artikel bermanfaat kami yang lain

Platform untuk mereplikasi data (Replikasi Berbasis Host vs Replikasi SAN)

Desember 10, 2018 by Jason Aw Leave a Comment

Memilih Platform Untuk Menggandakan Data – Berbasis Host Atau Berbasis Penyimpanan?

Dua platform umum untuk mereplikasi data adalah dari host server yang beroperasi terhadap data dan dari array penyimpanan yang menyimpan data. Saat membuat replika jarak jauh untuk kelangsungan bisnis, keputusan apakah akan menerapkan solusi berbasis host atau penyimpanan sangat bergantung pada platform yang sedang direplikasi dan persyaratan bisnis untuk aplikasi yang sedang digunakan. Jika bisnis menuntut dampak nol untuk operasi jika terjadi bencana situs, maka teknik berbasis host memberikan satu-satunya solusi yang layak.

Replikasi Berbasis Host

Salah satu dari dua platform untuk mereplikasi data adalah replikasi berbasis Host. Itu tidak mengunci pengguna ke susunan penyimpanan tertentu dari salah satu vendor. SIOS SteelEye DataKeeper, misalnya, dapat mereplikasi dari berbagai array ke array apa pun, terlepas dari vendor. Kemampuan ini pada akhirnya menurunkan biaya dan memberikan pengguna fleksibilitas untuk memilih apa yang tepat untuk lingkungan mereka. Sebagian besar solusi replikasi berbasis host juga dapat mereplikasi data secara native melalui jaringan IP, sehingga pengguna tidak perlu membeli perangkat keras yang mahal untuk mencapai fungsi ini. Solusi berbasis host adalah penyimpanan-agnostik, memberikan manajer TI kebebasan penuh untuk memilih penyimpanan apa pun yang sesuai dengan kebutuhan perusahaan. Perangkat lunak replikasi berfungsi dengan perangkat penyimpanan apa pun yang dapat dipasang ke platform aplikasi, menawarkan dukungan penyimpanan yang heterogen. Dapat beroperasi di blok atau tingkat volume juga cocok untuk konfigurasi cluster. Salah satu kelemahannya adalah solusi berbasis host mengkonsumsi sumber daya server dan dapat mempengaruhi kinerja server secara keseluruhan. Meskipun kemungkinan ini, solusi berbasis host mungkin masih tepat ketika manajer TI memerlukan infrastruktur penyimpanan multi-vendor atau memiliki investasi warisan atau keahlian internal dalam aplikasi berbasis host spesifik.

Replikasi Berbasis Penyimpanan

Platform lain untuk mereplikasi data adalah replikasi berbasis penyimpanan yang OS-independen dan menambahkan tidak ada biaya pemrosesan. Namun, vendor sering menuntut pengguna untuk mereplikasi dari dan ke array serupa. Persyaratan ini bisa mahal, terutama ketika Anda menggunakan disk berperforma tinggi di situs utama Anda – dan sekarang harus menggunakan yang sama di situs sekunder Anda. Juga, solusi berbasis penyimpanan secara asli bereplikasi melalui Fibre Channel dan sering membutuhkan perangkat keras tambahan untuk mengirim data melalui jaringan IP, semakin meningkatkan biaya. Alternatif berbasis penyimpanan memang memberikan manfaat solusi terintegrasi dari vendor penyimpanan khusus. Solusi ini memanfaatkan pengontrol dari penyimpanan array sebagai platform operasi untuk fungsionalitas replikasi. Integrasi yang ketat antara perangkat keras dan perangkat lunak memberi vendor penyimpanan kontrol yang belum pernah terjadi sebelumnya atas konfigurasi replikasi dan memungkinkan jaminan tingkat layanan yang sulit dicocokkan dengan pendekatan replikasi alternatif. Sebagian besar vendor penyimpanan juga telah menyesuaikan produk mereka untuk melengkapi virtualisasi server dan menggunakan fitur utama seperti failover penyimpanan mesin virtual. Beberapa perusahaan mungkin juga memiliki hubungan bisnis jangka panjang dengan vendor penyimpanan tertentu; dalam kasus seperti itu, solusi penyimpanan mungkin cocok relevan.

Pilihan

Namun, kualitas layanan yang tinggi membutuhkan biaya. Replikasi berbasis penyimpanan selalu menetapkan prakondisi konfigurasi perangkat penyimpanan seperti-ke-suka. Ini berarti bahwa dua kumpulan penyimpanan high-end yang dikonfigurasikan harus dikerahkan untuk mendukung fungsi replikasi, meningkatkan biaya dan mengikat organisasi ke satu solusi penyimpanan vendor. Penguncian ini ke vendor penyimpanan tertentu dapat menjadi kelemahan. Beberapa vendor penyimpanan memiliki batasan kompatibilitas dalam lini produk penyimpanan-array mereka, berpotensi membuat peningkatan teknologi dan migrasi data mahal. Ketika menyelidiki alternatif penyimpanan, manajer TI harus memperhatikan total biaya kepemilikan: Biaya biaya lisensi masa depan dan kontrak dukungan akan mempengaruhi biaya dalam jangka panjang. Biaya merupakan pertimbangan utama, tetapi dipengaruhi oleh beberapa faktor di luar biaya lisensi. Apakah solusi membutuhkan perangkat keras khusus, atau dapatkah itu digunakan dengan perangkat keras yang sudah ada sebelumnya? Apakah solusinya memerlukan perluasan infrastruktur jaringan dan jika ya, berapa banyak? Jika Anda menggunakan replikasi untuk menempatkan salinan data sekunder pada server, penyimpanan, atau situs terpisah, sadari bahwa pendekatan ini menyiratkan pengulangan perangkat keras tertentu. Produk replikasi yang memberikan opsi untuk memindahkan infrastruktur yang ada untuk memenuhi persyaratan perangkat keras yang berlebihan memerlukan lebih sedikit pengeluaran modal.

Pro dan kontra

Sebelum memutuskan antara solusi replikasi berbasis host atau penyimpanan, pertimbangkan dengan hati-hati pro dan kontra masing-masing, seperti yang diilustrasikan dalam tabel berikut.

	Replikasi Berbasis Host	Replikasi Berbasis Penyimpanan
Pro	Penyimpanan agnostik Sinkronkan dan asinkronkan Data dapat berada di penyimpanan apa pun	Tidak terpengaruh oleh peningkatan penyimpanan Vendor tunggal untuk penyimpanan dan replikasi Tidak ada beban pada sistem host OS agnostik
Cons	Penggunaan sumber daya komputasi pada host	Penguncian vendor Biaya lebih tinggi Data harus berada di larik Keterbatasan jarak Fibre Channel
Paling cocok	Lingkungan penyimpanan multi-vendor Perlu opsi sinkronisasi atau asinkron Menerapkan kluster failover Replikasi ke beberapa target	Lebih memilih vendor tunggal Jarak terbatas dan lingkungan yang terkendali Replikasi menjadi target tunggal

Untuk memahami bagaimana SIOS dapat bekerja pada platform untuk mereplikasi data, bacalah kisah sukses kami

Persamaan Ketersediaan – Solusi Ketersediaan Tinggi

Desember 9, 2018 by Jason Aw Leave a Comment

Persamaan Ketersediaan

Apakah Anda akrab dengan Persamaan Ketersediaan? Singkatnya, persamaan ini menunjukkan bagaimana total waktu yang diperlukan untuk mengembalikan aplikasi ke kegunaan sama dengan waktu yang diperlukan untuk mendeteksi bahwa aplikasi mengalami masalah ditambah waktu yang diperlukan untuk melakukan tindakan pemulihan:

T_RESTORE = T_DETECT + T_RECOVER

Konsep Kunci Solusi Ketersediaan Tinggi

Persamaan ini memperkenalkan konsep kunci ketersediaan tinggi (HA): pengelompokan, deteksi masalah, dan pemulihan selanjutnya. Solusi HA memantau kesehatan komponen aplikasi bisnis; ketika masalah terdeteksi, solusi ini bertindak untuk mengembalikannya ke layanan. Tujuan menyebarkan solusi ketersediaan tinggi adalah untuk meminimalkan waktu henti. Mengurangi waktu deteksi dan pemulihan adalah dua tugas penting dari solusi HA apa pun yang Anda pilih untuk diterapkan. Aplikasi saat ini adalah kombinasi teknologi: server, penyimpanan, infrastruktur jaringan, dan sebagainya. Saat meninjau opsi HA Anda, pastikan bahwa Anda memahami teknologi yang digunakan setiap solusi untuk mendeteksi dan memulihkan dari semua jenis pemadaman. Setiap teknologi memiliki dampak langsung pada waktu pemulihan layanan.

Deteksi dan Pemulihan Lokal

Solusi ketersediaan tinggi sangat mudah. Satu teknologi yang sangat penting untuk menyediakan waktu pemulihan tercepat mungkin dikenal sebagai deteksi lokal dan pemulihan (alias deteksi dan pemulihan masalah tingkat layanan). Dalam solusi pengelompokan dasar, server terhubung. Mereka dikonfigurasi bahwa satu atau lebih server dapat mengambil alih operasi yang lain dalam hal kegagalan server. Node server dalam gugus terus mengirim paket data kecil, sering disebut sinyal detak jantung, satu sama lain untuk menunjukkan bahwa mereka "hidup". Dalam lingkungan cluster sederhana, ketika satu server berhenti menghasilkan detak jantung, anggota cluster lainnya menganggap bahwa server ini sedang down. Kemudian akan memulai proses pengambilalihan tanggung jawab untuk domain operasi server tersebut. Pendekatan ini cukup untuk mendeteksi kegagalan pada tingkat server. Tetapi kecuali masalah menyebabkan gangguan atau penghentian sinyal detak jantung, deteksi tingkat server tidak memadai. Lebih dari itu, itu benar-benar dapat memperbesar jangkauan dan dampak dari pemadaman listrik. Sebagai contoh, jika proses Apache hang, server mungkin masih mengirimkan detak jantung. Meskipun subsistem server Web telah berhenti melakukan fungsi utamanya. Daripada memulai kembali subsistem Apache pada server yang sama atau berbeda, solusi pengelompokan tingkat server dasar akan memulai ulang seluruh tumpukan perangkat lunak server gagal di server cadangan, sehingga menyebabkan gangguan bagi pengguna dan memperpanjang waktu pemulihan.

Bagaimana itu bekerja

Dengan menggunakan deteksi dan pemulihan lokal, solusi pengelompokan lanjutan menggunakan agen pemantauan kesehatan dalam server cluster individu, untuk memantau komponen sistem individual seperti sistem file, database, aplikasi tingkat pengguna, alamat IP, dan sebagainya. Agen-agen ini menggunakan heuristik yang khusus untuk komponen yang dipantau. Oleh karena itu, agen dapat memprediksi dan mendeteksi masalah operasional dan kemudian mengambil tindakan pemulihan yang paling tepat. Seringkali, metode pemulihan yang paling efisien adalah menghentikan dan me-restart subsistem masalah pada server yang sama. Waktu untuk mengembalikan aplikasi ke ketersediaan pengguna dapat sangat dikurangi dengan memungkinkan pemulihan dalam server fisik yang sama. Juga, dengan mendeteksi kegagalan pada tingkat yang lebih rinci daripada hanya dengan mengamati denyut jantung tingkat server. Solusi seperti SteelEye Protection Suite untuk Linux dari SIOS menyediakan tingkat deteksi dan pemulihan untuk lingkungan Anda. Pastikan bahwa solusi HA yang Anda gunakan juga dapat mendukung deteksi dan pemulihan lokal. Apakah Anda ingin menikmati solusi ketersediaan tinggi untuk proyek Anda? Hubungi kami. Butuh lebih banyak referensi, berikut adalah kisah sukses kami. Direproduksi dengan izin dari Linuxclustering

12 Item Daftar Periksa untuk Memilih Solusi Berkesediaan Tinggi

Desember 6, 2018 by Jason Aw Leave a Comment

12 Item Checklist Untuk Memilih Solusi Berkesediaan Tinggi

Ketika memilih solusi ketersediaan tinggi, Anda harus mempertimbangkan beberapa kriteria. Ini berkisar dari total biaya solusi, untuk kemudahan yang dapat Anda konfigurasikan dan kelola klaster, hingga pembatasan spesifik yang ditempatkan pada perangkat keras dan perangkat lunak. Posting ini menyentuh secara singkat pada 12 item daftar periksa yang paling penting.

1 Dukungan untuk Versi OS dan Aplikasi Standar

Solusi yang memerlukan versi OS, database, atau perangkat lunak aplikasi perusahaan atau versi lanjutan dapat sangat mengurangi manfaat biaya pindah ke lingkungan server komoditas. Gunakan middleware HA yang tepat. Dengan cara ini, Anda dapat membuat versi standar aplikasi dan OS yang sangat tersedia. Dan pada saat yang sama, memenuhi persyaratan uptime dari lingkungan bisnis Anda.

2 Mendukung Berbagai Konfigurasi Penyimpanan Data

Ketika Anda menyebarkan gugus HA, data yang diperlukan oleh aplikasi yang dilindungi harus tersedia untuk semua sistem yang mungkin perlu untuk membawa aplikasi ke layanan. Anda dapat membagikan data ini melalui replikasi data, dengan menggunakan penyimpanan SCSI bersama atau Fibre Channel, atau dengan menggunakan perangkat NAS. Metode apa pun yang Anda pilih untuk diterapkan, produk HA yang Anda gunakan harus dapat mendukung semua konfigurasi data sehingga Anda dapat mengubah sesuai kebutuhan bisnis Anda.

3 Kemampuan Untuk Menggunakan Komponen Solusi Heterogen

Beberapa solusi pengelompokan HA mengharuskan setiap sistem dalam klaster memiliki konfigurasi yang identik. Persyaratan ini umum di antara solusi khusus perangkat keras di mana teknologi pengelompokan dimaksudkan untuk membedakan server atau penyimpanan dan di antara vendor OS yang ingin membatasi konfigurasi yang harus mereka dukung. Pembatasan ini membatasi kemampuan Anda untuk menyebarkan server yang diperkecil sebagai node cadangan sementara dan menggunakan kembali perangkat keras yang sudah ada dalam penyebaran kluster Anda. Menggunakan server yang dikonfigurasi secara terpisah mungkin merupakan pilihan yang tepat untuk kebutuhan Anda, tetapi keputusan tersebut tidak seharusnya didikte oleh penyedia solusi HA Anda.

4. Mendukung Lebih Dari Dua Node Dalam Cluster

Jumlah node yang dapat didukung dalam klaster merupakan ukuran skalabilitas yang penting. Solusi level-entry HA biasanya membatasi Anda untuk satu cluster dua-node, biasanya dalam mode aktif / pasif. Meskipun konfigurasi ini menyediakan peningkatan ketersediaan (melalui penambahan server siaga), itu masih dapat membuat Anda terpapar dengan downtime aplikasi. Dalam konfigurasi cluster dua-node, jika satu server mati karena alasan apa pun, maka server yang tersisa menjadi satu titik kegagalan. Dengan mengelompokkan tiga atau lebih node, Anda mendapatkan kemampuan untuk memberikan tingkat perlindungan yang lebih tinggi. Pada saat yang sama, Anda juga dapat membangun konfigurasi yang sangat skalabel.

5. Dukungan Untuk Aktif / Aktif Dan Aktif / Konfigurasi Siaga

Memilih Solusi Berkesediaan Tinggi yang sesuai dengan proyek Anda adalah kuncinya. Dalam konfigurasi aktif / siaga, satu server menganggur, menunggu untuk mengambil alih beban kerja anggota klasternya. Pengaturan ini memiliki kerugian yang jelas dari mengurangi investasi sumber daya komputasi Anda. Untuk mendapatkan manfaat maksimal dari pengeluaran TI Anda, pastikan bahwa node cluster dapat berjalan dalam konfigurasi aktif / aktif.

6 Deteksi Masalah Di Tingkat Layanan Node Dan Individu

Semua produk perangkat lunak HA dapat mendeteksi masalah dengan fungsionalitas server kluster. Tugas ini dilakukan dengan mengirimkan sinyal detak jantung antar server dalam kluster dan memulai pemulihan jika anggota klaster berhenti mengirimkan sinyal. Tetapi solusi HA yang canggih juga dapat mendeteksi masalah kelas lain. Salah satu yang terjadi ketika proses atau layanan individu menghadapi masalah yang membuat mereka tidak tersedia tetapi itu tidak menyebabkan server berhenti mengirim atau menanggapi sinyal detak jantung. Mengingat bahwa fungsi utama perangkat lunak HA adalah memastikan bahwa aplikasi tersedia bagi pengguna akhir, mendeteksi dan memulihkan dari gangguan tingkat layanan ini adalah fitur yang sangat penting. Pastikan bahwa solusi HA Anda dapat mendeteksi masalah tingkat node dan layanan.

7 Dukungan untuk pemulihan Node dan Cross-Node

Kemampuan untuk melakukan tindakan pemulihan baik di seluruh node cluster dan dalam node juga penting. Dalam pemulihan lintas-node, satu node mengambil alih domain tanggung jawab yang lengkap untuk yang lain. Ketika denyut jantung tingkat sistem dilewatkan, server yang seharusnya mengirimkan detak jantung diasumsikan tidak beroperasi, dan anggota cluster lainnya memulai operasi pemulihan. Dengan pemulihan in-node atau lokal, layanan sistem gagal upaya pertama untuk dipulihkan dalam server di mana mereka sedang berjalan. Tugas ini biasanya dilakukan dengan menghentikan dan memulai kembali layanan dan sumber daya sistem yang bergantung. Metode pemulihan ini jauh lebih cepat dan meminimalkan waktu henti.

8. Transparansi Untuk Koneksi Klien Pemulihan Sisi-Server

Pemulihan sisi server dari aplikasi atau bahkan seluruh node harus transparan untuk pengguna sisi-klien. Melalui penggunaan alamat IP virtualisasi atau nama server, pemetaan sumber daya komputasi virtual ke entitas klaster fisik selama pemulihan, dan pembaruan otomatis tabel routing jaringan, tidak ada perubahan pada sistem klien yang diperlukan untuk sistem untuk mengakses aplikasi dan data yang dipulihkan. Solusi yang memerlukan perubahan sisi klien secara manual untuk mengakses aplikasi yang dipulihkan sangat meningkatkan waktu pemulihan. Mereka memperkenalkan risiko kesalahan tambahan karena interaksi manusia yang dibutuhkan. Pemulihan harus dilakukan secara otomatis pada server dan klien.

9. Perlindungan Untuk Waktu Henti Yang Direncanakan Dan Tidak Terencana

Selain memberikan perlindungan terhadap penghentian layanan yang tidak direncanakan, solusi HA yang Anda gunakan harus dapat digunakan sebagai alat administrasi untuk mengurangi waktu henti yang disebabkan oleh aktivitas pemeliharaan. Dengan menyediakan fasilitas untuk memungkinkan pemindahan aplikasi berdasarkan permintaan di antara anggota kluster, Anda dapat memigrasikan aplikasi dan pengguna ke server kedua saat melakukan pemeliharaan pada yang pertama. Ini dapat menghilangkan kebutuhan untuk jendela pemeliharaan di mana sumber daya TI tidak tersedia untuk pengguna akhir. Pastikan bahwa solusi HA Anda menyediakan metode yang sederhana dan aman untuk melakukan pergerakan aplikasi manual (sesuai permintaan) dan sumber daya yang diperlukan di antara node cluster.

10. Perlindungan Off-The-Shelf untuk Fungsi Bisnis Umum

Setiap solusi HA yang Anda evaluasi harus mencakup agen dan modul yang diuji dan didukung yang dirancang untuk memantau kesehatan sumber daya sistem tertentu: sistem file, alamat IP, basis data, aplikasi, dan sebagainya. Modul-modul ini sering disebut modul pemulihan. Dengan menerapkan modul yang disediakan vendor, Anda mendapatkan manfaat dari waktu berjalan yang telah dilakukan oleh vendor dan pelanggan lain. Anda juga memiliki jaminan dukungan dan pemeliharaan berkelanjutan dari komponen solusi ini.

11. Kemampuan Untuk Dengan Mudah Memasukkan Perlindungan Untuk Aplikasi Bisnis Kustom

Kemungkinan akan ada aplikasi, mungkin kustom untuk perusahaan Anda, yang ingin Anda lindungi tetapi tidak ada modul pemulihan yang disediakan vendor. Oleh karena itu, penting bahwa Anda memiliki metode untuk menggabungkan aplikasi bisnis Anda dengan mudah ke skema perlindungan solusi HA Anda. Anda harus dapat melakukan ini tanpa memodifikasi aplikasi Anda, dan terutama tanpa harus menanamkan API khusus vendor. Kit pengembang perangkat lunak yang menyediakan contoh dan proses selangkah demi selangkah untuk melindungi aplikasi Anda harus tersedia. Juga, bersama dengan layanan dukungan yang disediakan vendor untuk membantu sesuai kebutuhan.

12. Kemudahan Penyebaran Dan Manajemen Kluster

Mitos umum seputar gugus HA adalah bahwa mereka mahal dan rumit untuk diterapkan dan dikelola. Ini belum tentu benar. Antarmuka administrasi kluster harus digerakkan oleh wizard untuk membantu dengan konfigurasi klaster awal. Ini harus mencakup penemuan otomatis elemen baru saat ditambahkan ke kluster. Demikian pula, harus memungkinkan pemantauan status sekilas dari seluruh cluster. Akhirnya, setiap metadata klaster harus disimpan dalam mode HA. Tidak pada disk quorum tunggal dalam kluster, di mana korupsi atau pemadaman bisa menyebabkan seluruh kluster menjadi berantakan. Dengan mencari kemampuan dalam daftar periksa ini, Anda dapat membuat keputusan terbaik untuk kebutuhan HA Anda. Memilih Solusi Ketersediaan Tinggi bukanlah ilmu roket. Berikut adalah kisah sukses kami Direproduksi dengan izin dari Linuxclustering