12 Item Daftar Periksa untuk Memilih Solusi Berkesediaan Tinggi

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

Apakah Anda Tahu Berapa Banyak Bandwidth Untuk Mendukung Replikasi Real-Time?

Berapa Banyak Bandwidth yang Mendukung Replikasi Real-Time?

Untuk cara cepat seperti mencari Bandwidth Untuk Mendukung Replikasi Real-Time, baca blog kami Diproduksi ulang dengan izin dari Linuxclustering

Solusi Ketersediaan Tinggi SAP Untuk Linux

Cara Membuat Cluster MySQL 2-Node Tanpa Penyimpanan Bersama – Bagian 2

Langkah-demi-Langkah: Cara Membuat Cluster MySQL 2-Node Tanpa Penyimpanan Bersama, Bagian 2

Posting sebelumnya memperkenalkan keuntungan menjalankan cluster MySQL, menggunakan konfigurasi penyimpanan shared-nothing. Kami juga mulai berjalan melalui proses pengaturan cluster, menggunakan replikasi data dan SteelEye Protection Suite (SPS) untuk Linux. Dalam posting ini, kami menyelesaikan proses untuk Membuat Cluster 2-Node MySQL Tanpa Penyimpanan Bersama. Mari mulai.

Menciptakan Path Kom

Sekarang saatnya untuk mengakses SteelEye LifeKeeper GUI. LifeKeeper adalah komponen terintegrasi SPS untuk Linux. GUI LifeKeeper adalah aplikasi berbasis Java yang dapat dijalankan sebagai aplikasi Linux asli atau sebagai applet dalam browser Web yang mendukung Java. (GUI didasarkan pada Java RMI dengan callback, jadi nama host harus dapat dipecahkan atau Anda mungkin menerima kesalahan Java 115 atau 116.) Untuk memulai aplikasi GUI, masukkan perintah ini pada salah satu dari node cluster: / opt / LifeKeeper / bin / lkGUIapp & Or, untuk membuka applet GUI dari browser Web, buka http: // <hostname>: 81.

Langkah pertama adalah memastikan bahwa Anda memiliki setidaknya dua jalur komunikasi TCP (Comm) antara masing-masing server utama dan setiap server target, untuk redundansi detak jantung. Dengan cara ini, kegagalan satu jalur komunikasi tidak akan menyebabkan situasi perpecahan-otak. Verifikasi jalur di server utama. Screenshot berikut memandu Anda melalui proses masuk ke GUI, menghubungkan ke kedua node cluster, dan membuat jalur Comm.

Langkah 1: Sambungkan ke server primer Langkah 2: Sambungkan ke server sekunder Langkah 3: Buat jalur Comm. Langkah 4: Pilih server lokal dan jarak jauh. Langkah 5: Pilih jenis perangkat Selanjutnya, Anda akan disajikan dengan serangkaian kotak dialog. Untuk setiap kotak, berikan informasi yang diperlukan dan klik Berikutnya untuk maju. (Untuk setiap bidang dalam kotak dialog, Anda dapat mengklik Bantuan untuk informasi tambahan.) Langkah 6: Pilih alamat IP untuk server lokal yang akan digunakan untuk jalur Comm. Langkah 7: Pilih alamat IP untuk server jarak jauh yang akan digunakan untuk jalur Comm. Langkah 8: Masukkan Prioritas jalur kom di server lokal Setelah memasukkan data di semua bidang yang diperlukan, klik Buat. Anda akan melihat pesan yang menunjukkan bahwa jalur Comm jaringan berhasil dibuat. Langkah 9: Finalisasi pembuatan jalur Comm Klik Next. Jika Anda memilih beberapa alamat IP lokal atau server jarak jauh dan mengatur jenis perangkat ke TCP, maka prosedur mengembalikan Anda ke wizard pengaturan untuk membuat jalur Comm berikutnya. Setelah selesai, klik Selesai di kotak dialog terakhir. Ulangi proses ini sampai Anda telah menetapkan semua jalur Comm yang Anda rencanakan untuk digunakan. Verifikasi bahwa jalur komunikasi dikonfigurasi dengan benar dengan melihat kotak dialog Server Properties. Dari GUI, pilih Edit> Server> Properties, lalu pilih tab CommPaths. Status yang ditampilkan harus HIDUP. Anda juga dapat memeriksa ikon server di panel utama kanan GUI. Jika hanya satu jalur Comm yang dibuat, ikon server dihamparkan dengan ikon peringatan kuning. Tanda centang detak jantung hijau menunjukkan bahwa setidaknya dua jalur Comm dikonfigurasi dan HIDUP. Langkah 10: Tinjau status jalur Comm

Membuat dan Memperluas Sumber Daya IP

Dalam GUI LifeKeeper, buat sumber daya IP dan perluas ke server sekunder dengan menyelesaikan langkah-langkah berikut. IP virtual ini dapat berpindah antar node cluster bersama dengan aplikasi yang bergantung padanya. Dengan menggunakan IP virtual sebagai bagian dari konfigurasi cluster Anda, Anda menyediakan pengalihan tanpa batas dari klien setelah peralihan atau failover sumber daya antara node cluster karena mereka terus mengakses database melalui FQDN / IP yang sama. Langkah 11: Buat hierarki sumber daya Langkah 12: Pilih IP ARK Masukkan informasi yang sesuai untuk konfigurasi Anda, menggunakan nilai-nilai yang disarankan berikut ini. (Klik tombol Bantuan untuk informasi lebih lanjut.) Klik Next untuk melanjutkan setelah memasukkan informasi yang diperlukan.

LifeKeeper membuat dan memvalidasi sumber daya Anda. Setelah menerima pesan bahwa sumber daya telah berhasil dibuat, klik Berikutnya. Langkah 13: Tinjau pemberitahuan tentang penciptaan sumber daya yang sukses Sekarang Anda dapat menyelesaikan proses perluasan sumber daya IP ke server sekunder. Langkah 14: Perluas sumber daya IP ke server sekunder Proses memperluas sumber daya IP dimulai secara otomatis setelah Anda selesai membuat sumber daya alamat IP dan klik Berikutnya. Anda juga dapat memulai proses ini dari sumber alamat IP yang ada, dengan mengklik kanan sumber daya aktif dan memilih Extend Resource Hierarchy. Gunakan informasi dalam tabel berikut untuk menyelesaikan prosedur.

Setelah menerima pesan bahwa operasi ekstensi hierarki selesai, klik Selesai dan kemudian klik Done. Sumber daya IP Anda (contoh: 192.168.197.151) sekarang sepenuhnya terlindung dan dapat mengapung di antara node klaster, sesuai kebutuhan. Dalam GUI LifeKeeper, Anda dapat melihat bahwa sumber daya IP terdaftar sebagai Aktif pada node klaster utama dan Standby pada simpul klaster sekunder. Langkah 15: Tinjau status sumber daya IP pada nodus primer dan sekunder

Membuat Cermin Dan Memulai Replikasi Data

Setengah untuk Membuat Cluster 2-Node MySQL Tanpa Penyimpanan Bersama! Anda siap untuk menyiapkan dan mengonfigurasi sumber replikasi data, yang akan Anda gunakan untuk menyinkronkan data MySQL antara node cluster. Untuk contoh ini, data yang akan direplikasi berada di partisi / var / lib / mysql pada simpul klaster utama. Volume sumber harus dipasang di server utama, volume target tidak boleh dipasang di server sekunder, dan ukuran volume target harus sama dengan atau lebih besar dari ukuran volume sumber. Screenshot berikut mengilustrasikan serangkaian langkah berikutnya. Langkah 16: Buat hierarki sumber daya. Langkah 17: Pilih ARK Replikasi Data. Gunakan nilai-nilai ini di panduan Replikasi Data.

Klik Berikutnya untuk memulai pembuatan hirarki sumber daya replikasi data. GUI akan menampilkan pesan berikut. Langkah 18: Mulai membuat sumber daya Replikasi Data Klik Berikutnya untuk memulai proses memperluas sumber daya replikasi data. Terima semua pengaturan default. Ketika ditanya tentang target disk, pilih partisi gratis pada server target Anda yang Anda buat sebelumnya dalam proses ini. Pastikan untuk memilih partisi yang lebih besar atau lebih besar dari volume sumber dan yang tidak terpasang pada sistem target. Langkah 19: Mulai ekstensi sumber Replikasi Data Akhirnya, Anda diminta untuk memilih jaringan tempat replikasi yang Anda inginkan berlangsung. Secara umum, memisahkan lalu lintas pengguna dan aplikasi dari lalu lintas replikasi Anda adalah praktik terbaik. Konfigurasi contoh ini memiliki dua antarmuka jaringan terpisah, "NIC publik" kami pada subnet 192.168.197.X dan "private / backend NIC" pada subnet 192.168.198.X. Kami akan mengkonfigurasi replikasi untuk melewati jaringan back-end 192.168.198.X, sehingga lalu lintas pengguna dan aplikasi tidak bersaing dengan replikasi. Langkah 20: Pilih jaringan untuk lalu lintas replikasi. Klik Selanjutnya untuk melanjutkan melalui wisaya. Setelah selesai, hierarki sumber daya Anda akan terlihat seperti ini: Langkah 21: Meninjau hierarki sumber Replikasi Data

Membuat Hirarki Sumber Daya MySQL

Anda perlu membuat sumber daya MySQL untuk melindungi database MySQL dan membuatnya sangat tersedia antara node cluster. Pada titik ini, MySQL harus berjalan di server utama tetapi tidak berjalan di server sekunder. Dari toolbar GUI, klik Create Resource Hierarchy. Pilih Database MySQL dan klik Berikutnya. Lanjutkan melalui wizard Sumber Daya Kreasi, dengan memberikan nilai-nilai berikut.

  Klik Buat untuk menentukan hirarki sumber daya MySQL di server utama. Klik Berikutnya untuk memperluas sumber daya sistem file ke server sekunder. Di Wisaya Perluas, pilih Terima Default. Klik Selesai untuk keluar dari panduan Perpanjang. Hierarki sumber daya Anda akan terlihat seperti ini: Langkah 22: Tinjau hierarki sumber daya MySQL

Menciptakan Ketergantungan Alamat IP MySQL

Selanjutnya, Anda akan mengonfigurasi MySQL agar bergantung pada IP virtual (192.168.197.151) sehingga alamat IP mengikuti database MySQL saat ia bergerak. Dari toolbar GUI, klik kanan sumber daya mysql. Pilih Buat Ketergantungan dari menu konteks. Di menu tarik-turun Tag Sumber Daya Anak, pilih ip-192.168.197.151. Klik Berikutnya, klik Buat Ketergantungan, lalu klik Selesai. Hirarki sumber daya Anda sekarang akan terlihat seperti ini: Langkah 23: Tinjau hirarki sumber daya MySQL IP Pada titik ini dalam evaluasi, Anda telah sepenuhnya dilindungi MySQL dan sumber daya dependen (alamat IP dan penyimpanan yang direplikasi). Uji lingkungan Anda, dan Anda siap untuk pergi. Anda dapat menemukan lebih banyak informasi dan langkah-langkah terperinci untuk setiap tahap proses evaluasi di SIOS SteelEye Protection Suite untuk Linux MySQL dengan Panduan Evaluasi Replikasi Data. Untuk mengunduh salinan evaluasi SPS untuk Linux, kunjungi situs web SIOS atau hubungi SIOS di info@us.sios.com. Tertarik untuk belajar Membuat 2-Node MySQL Cluster Tanpa Penyimpanan Bersama, inilah kisah sukses masa lalu kami dengan klien yang puas. Direproduksi dengan izin dari Linuxclustering

Cara Membuat Cluster MySQL 2-Node Tanpa Penyimpanan Bersama – Bagian 1