Di blog ini saya akan membahas tentang Kit Pemulihan Aplikasi Penyeimbang Beban Umum (ARK) untuk SIOS Lifekeeper untuk Linux dan khususnya cara mengkonfigurasinya di Microsoft Azure. Saya akan menggunakan dua node NFS cluster dan ekspor NFS yang mereka berikan pada akhirnya akan diakses melalui load-balancer.

SIOS telah membuat ARK ini untuk memfasilitasi pengalihan klien di kluster LifeKeeper yang berjalan di Azure.

Karena Azure tidak mendukung ARP serampangan, klien tidak dapat terhubung langsung ke alamat IP virtual klaster tradisional. Sebaliknya, klien harus terhubung ke penyeimbang beban dan penyeimbang beban mengalihkan lalu lintas ke node cluster aktif. . Azure mengimplementasikan solusi penyeimbang beban yang beroperasi pada lapisan 4 (TCP, UDP), Penyeimbang Beban dapat dikonfigurasi untuk memiliki IP frontend pribadi atau publik, pemeriksaan kesehatan yang dapat menentukan simpul mana yang aktif, serangkaian alamat IP backend (untuk setiap node dalam sebuah cluster) dan aturan lalu lintas jaringan masuk/keluar.

Secara tradisional, pemeriksaan kesehatan akan memantau port aktif pada aplikasi dan menentukan node tempat aplikasi aktif, ARK penyeimbang beban generik SIOS dikonfigurasi untuk membuat node aktif mendengarkan pada port yang ditentukan pengguna. Port ini kemudian dikonfigurasi di Azure Load-balancer sebagai Port Probe Kesehatan. Hal ini memungkinkan node cluster aktif untuk merespons pemeriksaan kesehatan TCP, memungkinkan pengalihan klien otomatis..

Instalasi dan konfigurasi di Azure mudah dan terperinci di bawah ini:

Di dalam portal Azure, pilih load-balancing Buat penyeimbang beban, Anda akan memilih grup sumber daya tempat Anda ingin ini digunakan serta namanya, saya suka menggunakan nama yang sejalan dengan jenis klaster yang saya gunakan penyeimbang beban dengan misalnya IMA -NFS-LB akan berada di depan kedua node IMA-NFS.

Anda dapat menentukan apakah ini akan menjadi LB publik atau swasta. Dalam hal ini saya mengonfigurasi Load-Balancer pribadi ke depan server NFS saya untuk digunakan hanya dalam grup sumber daya ini.

Setelah Anda menentukan nama, grup sumber daya, dll., maka Anda akan diminta untuk menetapkan Nama, Jaringan virtual, subnet, dan IP untuk penyeimbang beban. Alamat IP harus sama dengan alamat IP yang akan Anda buat di LifeKeeper sebagai alamat IP virtual.

Setelah informasi dasar dimasukkan untuk penyeimbang beban, Anda perlu menentukan mesin mana yang akan dikonfigurasi di backend untuk melayani penyeimbang beban, dalam kasus saya kumpulan backend ini akan terdiri dari dua simpul yang saya gunakan untuk server NFS saya.

Anda akan memerlukan aturan load-balancing, ini adalah bagaimana load-balancer akan menentukan lalu lintas apa yang akan dirutekan ke node aktif. – Nomor port yang dikonfigurasi di sini akan digunakan di SPS-L saat Anda mengonfigurasi aplikasi generik untuk mendukung Load-balancer. Dalam contoh ini kami menggunakan "Port HA", yang akan mengarahkan semua lalu lintas ke node aktif. Jika Anda ingin membatasi lalu lintas yang akan dirutekan, Anda dapat menentukan port aplikasi tertentu.

IP frontend harus menjadi IP penyeimbang beban, kumpulan backend harus berupa node yang Anda konfigurasikan untuk menjadi sumber daya yang digunakan oleh penyeimbang beban. Pastikan tombol “HA Ports” dipilih dan “Floated IP” diaktifkan. "TCP reset" dapat dibiarkan dinonaktifkan.

Saat Anda membuat health probe, pastikan Anda mencatat port yang Anda konfigurasikan di sini karena akan digunakan saat kami membuat aplikasi generik di dalam SIOS Protection Suite. Anda dapat menggunakan nilai standar untuk "interval" dan "Ambang batas tidak sehat". Ini dapat diubah di lain waktu jika Anda memiliki persyaratan khusus aplikasi.

Sekarang aturan load balancing harus lengkap dengan pemeriksaan kesehatan. Pilih “Tambah” Setelah kami memilih "tambah" maka Azure akan memulai penyebaran Penyeimbang Beban, ini dapat memakan waktu beberapa menit dan setelah selesai maka konfigurasi beralih ke Suite Perlindungan SIOS.

CATATAN: Setelah mesin backend dikonfigurasi di belakang penyeimbang beban, mereka akan kehilangan akses ke gateway internet sehingga hal-hal seperti pembaruan sistem tidak akan berfungsi. Anda dapat menghapus mesin dari grup sumber daya backend untuk mengizinkan akses internet lagi.

Konfigurasi dengan SIOS Protection Suite

Untuk blog ini saya telah mengonfigurasi tiga ekspor NFS untuk dilindungi menggunakan SPS-L, ketiga ekspor tersebut dikonfigurasikan untuk menggunakan IP yang sama dengan IP frontend penyeimbang beban Azure. Saya menggunakan Datakeeper untuk mereplikasi data yang disimpan di ekspor.

Langkah pertama adalah mendapatkan skrip, cara paling sederhana adalah menggunakan wget tetapi Anda juga dapat mengunduh seluruh paket dan mengunggah rpm langsung ke node menggunakan wincp atau alat serupa. Anda perlu menginstal Hotfix di semua node di kluster Lifekeeper.

Seluruh kit pemulihan dapat diperoleh di sini: http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1 Bagian-bagiannya dapat ditemukan di sini dengan wget: wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt Setelah diunduh, verifikasi jumlah MD5 terhadap nilai yang tercatat di situs FTP.

Instal RPM sebagai berikut: rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm Periksa apakah penginstalan berhasil dengan menjalankan: rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172 Jika Anda perlu menghapus RPM karena alasan tertentu, ini dapat dilakukan dengan menjalankan: rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154 .x86_64 Di bawah ini adalah GUI yang menunjukkan tiga ekspor NFS saya yang telah saya konfigurasikan: Apa yang perlu kita lakukan dalam SIOS Protection Suite adalah menentukan Load Balancer menggunakan skrip Hotfix yang disediakan oleh SIOS.

Pertama kami membuat hierarki sumber daya baru, kami memilih Aplikasi Generik dari drop down Tentukan skrip restore.pl yang terletak di /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ Tentukan skrip remove.pl yang terletak di /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ Tentukan skrip quickCheck yang terletak di /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ Tidak ada skrip pemulihan lokal, jadi pastikan Anda menghapus input ini Ketika diminta untuk Info Aplikasi, kami ingin memasukkan nomor port yang sama seperti yang kami konfigurasikan dalam konfigurasi Health Probe misalnya 54321 Kami akan memilih untuk membawa layanan ke layanan setelah dibuat.

Resource Tag adalah nama yang akan kita lihat ditampilkan di GUI SPS-L, saya suka menggunakan sesuatu yang membuatnya mudah untuk diidentifikasi.

Jika semuanya dikonfigurasi dengan benar, Anda akan melihat "AKHIR pemulihan yang berhasil", kami kemudian dapat memperluas ini ke node lain sehingga sumber daya dapat di-host di salah satu node.

Ini menunjukkan konfigurasi Load Balancer yang telah selesai mengikuti ekstensi ke kedua node.

Langkah terakhir untuk cluster ini adalah membuat dependensi turunan untuk ketiga ekspor NFS, artinya semua ekspor NFS lengkap dengan mirror dan IP Datakeeper akan mengandalkan Load Balancer. Jika masalah serius terjadi pada node aktif maka semua sumber daya ini akan dialihkan ke node lain yang berfungsi.

Di atas, hierarki lengkap di Lifekeeper GUI. Di bawah ini menunjukkan tampilan GUI yang diperluas yang menunjukkan ekspor NFS, IP, Filesystems, dan volume replikasi DataKeeper sebagai anak-anak dari sumber daya Load Balancer.

Ini hanyalah salah satu contoh bagaimana Anda dapat menggunakan SIOS LifeKeeper di Biru langit untuk melindungi cluster NFS sederhana. Konsep yang sama berlaku untuk aplikasi penting bisnis apa pun yang perlu Anda lindungi. Anda hanya perlu memanfaatkan ARK Penyeimbang Beban yang disediakan oleh SIOS untuk memungkinkan Penyeimbang Beban Azure (Internal atau Eksternal) untuk menentukan node mana yang saat ini menghosting aplikasi.

Dalam Disney dan Pixar’s Soul, karakter utama Joe Gardner (disuarakan oleh Jamie Foxx) bermimpi menjadi pianis jazz profesional.Namun, terlepas dari banyak upayanya, yang membuat ibunya cemas, dia mendapati dirinya bermil-mil jauhnya dari mimpinya, hidup sebagai “guru band sekolah menengah setengah baya.” Tapi kemudian, “berkat kesempatan menit terakhir untuk bermain dalam kuartet legenda jazz Dorothea Williams, mimpinya sepertinya akan menjadi kenyataan.Itu sampai “salah langkah yang menentukan mengirimnya ke The Great Before—tempat di mana jiwa mendapatkan minat, kepribadian, dan kebiasaan mereka—dan Joe dipaksa untuk bekerja dengan “22”, jiwa kuno yang tidak tertarik untuk hidup di bumi, untuk “entah bagaimana kembali ke Bumi sebelum terlambat ( D23.com ).” Disney and Pixar’s Soul adalah film hebat dengan banyak karakter yang menarik dan dapat dihubungkan, lucu, deskriptif, dan kadang-kadang mengganggu yang berhubungan dengan kehidupan, tujuan, dan kehidupan.Tapi, itu juga film dengan kekayaan pelajaran kepemimpinan , pelajaran hidup, dan pelajaran tentang ketersediaan yang lebih tinggi.

Tujuh pemikiran tentang ketersediaan yang lebih tinggi dari Disney dan Pixar’s Soul.

1. Perhatikan apa yang terjadi

Di Disney dan Pixar’s Soul, Joe mendapatkan pertunjukan impiannya.Tetapi ketika Joe mulai berjalan dan berbagi berita bagus, dia begitu sibuk dengan teleponnya sehingga dia berjalan ke jalan, hampir tertimpa satu ton batu bata, dan kemudian dia mengembara dengan berbahaya menuju lubang got yang terbuka, tetapi ditandai dengan jelas.Jadi apa pelajaran untuk ketersediaan yang lebih tinggi– perhatikan.Perhatikan peringatan dan pesan kesalahan dari solusi pemantauan dan pemulihan Anda.Perhatikan perubahan yang dibuat oleh penyedia hosting Anda, dan terutama pemberitahuan penting dari vendor dan mitra serta tim keamanan.Peringatan dan peringatan ada karena suatu alasan, gagal mengatasinya atau mengambil tindakan yang tepat ketika Anda melihat peringatan itu dapat membawa Anda ke lubang yang dalam.

2. Jangan jatuh ke dalam lubang

Tidak menyadari peringatan, atau mengabaikannya, Joe akhirnya menemui ajalnya ketika dia jatuh ke dalam lubang terbuka dan menjadi jiwa.Ini segera mengubah mimpi dan rencananya.Jadi, lubang apa yang bisa dimasuki perusahaan Anda?Apakah ada lubang terbuka yang mengintai di jalur perusahaan Anda seperti: lubang cakupan, kesenjangan versi, lubang dalam rencana dan kenyataan pemeliharaan, atau bahkan lubang hitam dengan respons vendor?Lihatlah ke sekeliling lingkungan Anda, lubang apa yang bisa membuat Anda jatuh di luar titik kegagalan yang jelas?Apakah ada peringatan bahwa Anda memiliki lubang terbuka terkait dengan aplikasi penting yang tidak dilindungi, kesenjangan komunikasi antara tim Anda, atau bahkan lubang dalam proses dan manajemen krisis Anda.Jangan jatuh ke dalam lubang yang dapat merusak atau bahkan mengakhiri ketersediaan tinggi .

3. Jangan terburu-buru ketersediaan tinggi

Setelah menjadi jiwa, Joe mulai aktif mencoba kembali ke tubuhnya sendiri.Ketika dia dipasangkan dengan 22, dia membawanya ke Moonwind yang setuju untuk mencoba membantunya menemukan tubuhnya, yang mereka lakukan.Tapi Joe menjadi terlalu bersemangat untuk melompat kembali ke tubuhnya, meskipun Moonwind berhati-hati.Dalam ketergesaannya dia dan 22 jatuh kembali ke bumi, tetapi Joe berakhir di tubuh kucing dan 22 berakhir di tubuhnya.Seperti Joe jika kita tidak sabar, lompatan terjadi terlalu cepat dan kita berakhir dalam situasi genting atau bahkan lebih buruk.Kita mungkin tidak berada dalam tubuh kucing, tetapi kita mungkin juga jauh dari posisi terbaik yang diperlukan untuk mempertahankan HA.Melompat terlalu cepat terlihat seperti:

1. Menyebarkan perangkat lunak tanpa arsitektur atau solusi holistik
2. Menyebarkan dalam produksi tanpa pengujian di QA
3. Menyebarkan ke cloud tanpa memahami cloud atau apa yang dimaksud cloud dengan HA
4. Menyebarkan ke produksi berdasarkan garis waktu dan tidak menyelesaikan tes penerimaan
5. Menerapkan tanpa tujuan, solusi kelas komersial untuk pemantauan dan orkestrasi aplikasi

4. Jangan berhenti terlalu cepat – ketersediaan tinggi tidak pernah mudah

Ketika Connie, seorang pemain trombon muda, datang ke apartemen gurunya, dia frustrasi dan ingin berhenti.Dia mulai dengan memberi tahu Joe (yang sebenarnya berusia 22 tahun dalam tubuh Joe) bahwa dia frustrasi dan dia hanya ingin menyerah dan berhenti.Tetapi setelah beberapa saat, dia memainkan satu bagian terakhir pada trombon dan menyadari bahwa terlalu dini untuk berhenti.Dalam ketersediaan yang lebih tinggi, kita semua sangat mirip dengan Connie. Terkadang, sebuah kesulitan membuat kita merasa seperti berada di ujung tali kita dan ingin berhenti.Terkadang pemadaman akan membuat kita merasa yakin bahwa inilah saatnya untuk menyerah. Jangan terlalu cepat untuk berhenti.HA tidak pernah mudah, tidak pernah!Tapi, selalu terlalu dini untuk berhenti berjuang untuk mengakhiri waktu henti, jadi seperti Connie, mungkin kita hanya perlu terus melakukannya.Yang membawa saya ke pelajaran berikutnya.

5. Anda belum mencoba semuanya

Dalam film 22 adalah jiwa yang belum hidup.Dia percaya bahwa dia telah mencoba semua hal yang mungkin untuk memberinya percikan, tetapi ketika dia jatuh ke tubuh Joe, dia menyadari ada banyak hal yang belum dia coba.Dalam menciptakan solusi ketersediaan yang lebih tinggi, mungkin mudah untuk merasa seperti Anda telah mencoba segalanya dan setiap produk, tetapi kemungkinan besar Anda belum mencoba.Perspektif baru, atau melihat tantangan dan masalah dengan pandangan baru dapat membantu Anda meningkatkan ketersediaan sistem dan perusahaan Anda.

Beberapa hal yang perlu dicoba untuk ketersediaan yang lebih tinggi bisa sederhana, seperti:

1. Siapkan lansiran tambahan untuk metrik pemantauan utama
2. Tambahkan analitik.
3. Lakukan perawatan rutin (tambalan, pembaruan, perbaikan keamanan)
4. Dokumentasikan proses Anda
5. Dokumentasikan buku pedoman operasional Anda
6. Tingkatkan jalur komunikasi Anda
7. Lakukan perawatan rutin

Ide-ide lain mungkin memerlukan lebih banyak pekerjaan, penelitian, waktu, dan uang, tetapi dapat bermanfaat jika Anda belum menjelajahinya di masa lalu.

Cara untuk meningkatkan ketersediaan Anda yang lebih tinggi dengan lebih banyak waktu dan upaya meliputi:

1. Hapus peretasan dan solusi.
2. Buat arsitektur solusi berulang yang solid
3. Go komersial dan tujuan dibangun
4. Sewa konsultan
5. Audit dan dokumentasikan arsitektur Anda
6. Tingkatkan ukuran VM Anda; CPU, memori, dan IOP
7. Tambahkan redundansi tambahan di tingkat zona atau wilayah

6. Ajukan lebih banyak (dan lebih baik) pertanyaan

Setelah Joe, sebagai Tuan Mittens, secara tidak sengaja memotong jalan di tengah rambutnya, Tuan Mittens dan Joe harus melakukan perjalanan untuk melihat Dez, tukang cukur Joe.Sementara Joe berada di kursi tukang cukur dengan Dez, mereka mulai mengobrol tentang tujuan, kehidupan, keberadaan eksistensial, dan banyak lagi.Setelah potong rambut, 22 bertanya kepada Dez mengapa mereka tidak pernah melakukan percakapan seperti ini sebelumnya, tentang kehidupan Dez.Dez menjawab bahwa dia tidak pernah bertanya sebelumnya.Terkadang kita bisa begitu fokus pada solusi, dalam metode untuk cloud atau di lokasi, dalam bahasa dan arsitektur, dan dalam memberi tahu orang lain apa yang kita lakukan sehingga kita lupa untuk mengajukan pertanyaan yang dapat membuka dunia yang sama sekali baru.Saat Joe mengajukan pertanyaan, dia belajar lebih banyak tentang Dez, dan tentang dirinya sendiri.Mungkin pelajaran untuk HA yang lebih baik adalah mulai mengajukan lebih banyak pertanyaan tentang solusi kami, tentang arsitektur, tentang tujuan dan tantangan bisnis, tentang tujuan pelanggan akhir, tentang tim kami, dan bahkan tentang peran dan tanggung jawab kami dalam gambaran yang lebih besar.

Beberapa pertanyaan sederhana untuk meningkatkan ketersediaan kami meliputi:

1. Jika bencana terjadi besok, sistem, proses, produk, atau solusi apa yang menjadi penyebabnya?
2. Apa satu-satunya hal yang paling penting untuk dilindungi?Aplikasi, data, metadata, semua di atas?
3. RPO apa yang dapat ditoleransi oleh aplikasi dan database kita?
4. Apa yang tidak akan ditoleransi oleh pelanggan kami?
5. Apa yang saya lewatkan?
6. Di mana kita mendokumentasikan arsitektur ini?
7. Apa yang tidak saya mengerti?

7. Ketekunan membuahkan hasil

“Penghitungan mundur,” kata Terry.Ditugaskan untuk melacak pendatang ke The Great Beyond, Terry dengan cermat menghitung jumlah jiwa yang harus tiba atau telah tiba.Setelah Joe mengambil jalan memutar ke The Great Before, Terry semakin bertekad untuk menemukan jiwa yang hilang dan memperbaiki penghitungannya. Ketika dia memulai pekerjaannya, dia berada di koridor panjang lemari arsip yang membentang sejauh dan setinggi mata memandang.Tetapi setelah beberapa saat, dia menemukan file Joe dan menemukan bahwa Joe telah menemukan celah dan itulah sebabnya penghitungannya dibatalkan.Ketekunan yang sama yang ditunjukkan oleh Terry juga akan terbayar di ranah ketersediaan yang lebih tinggi.Dalam menghadapi ketidakpastian yang menakutkan, sejumlah besar file log, dan lautan skenario kegagalan yang mungkin, momen ketekunan untuk mengungkap dan kemudian memperbaiki masalah sebelum terjadi, atau menganalisis dan memulihkannya secara efektif setelah terjadi akan membawa kita ke arah yang lebih baik. hasil yang kita inginkan.Demikian pula, kurangnya ketekunan dan ketekunan akan berarti bahwa masalah yang sama kemungkinan akan muncul kembali nanti, bahkan di lingkungan baru dengan perangkat lunak baru.

Saat film Soul berakhir, Joe kembali ke Great Before, menemukan dan kemudian meyakinkan 22 untuk mengambil Earth pass-nya dan mengambil risiko.Mengingatkan ketika dia jatuh ke bumi dengan Joe, dia mengambil risiko lain.Yang membuat anak-anak saya kecewa, film itu berakhir tanpa menggambarkan apa yang dibuatnya dalam hidupnya atau peluang-peluang baru yang mengikutinya.Dia hanya melompat dari Great Before dengan antisipasi apa yang akan terjadi selanjutnya.Mungkin kita juga berdiri di saat di mana kita bisa mengambil risiko… momen di “Sebelumnya Hebat” dan kesempatan untuk menjadikan ini tahun ketersediaan tambahan yang lebih tinggi.

– Cassius Rhee, VP Pengalaman Pelanggan