Tuan rumah cadangan panas vs tuan rumah cadangan dingin?

Kami memiliki beberapa host di mana kami memiliki host cadangan panas yang identik, yang ditambal dan diperbarui sehingga sangat dekat dengan perangkat lunak dan konfigurasi yang sama. Jika terjadi kegagalan, kabel jaringan diaktifkan dan server DHCP diperbarui dengan alamat MAC yang baru. Ini adalah kasus terbaik, karena biasanya ada sedikit lebih yang memerlukan modifikasi.

Saya merasa ini adalah pemborosan listrik untuk memiliki host cadangan panas dan buang waktu untuk memeliharanya, dan karena konfigurasi konfigurasi diperlukan jika terjadi failover, saya ingin bertanya yang berikut:

Apakah tuan rumah lama cadangan panas dan ada cara yang lebih baik sekarang?

Alih-alih memiliki host cadangan panas, apakah masuk akal untuk membuatnya menjadi cadangan dingin, ambil hard drive dan letakkan di host utama dan ubah RAID dari 1 menjadi 1 + 1. Jika terjadi kegagalan, yang harus saya lakukan adalah mengganti kabel jaringan, memperbarui server DHCP, mengambil hard drive, dan memasukkannya ke dalam cold cold dan hidupkan. Keuntungannya, seperti yang saya lihat, adalah bahwa disk 2x2 selalu sinkron, jadi hanya satu host yang harus dipelihara dan tidak ada perubahan konfigurasi yang diperlukan ketika gagal.

Apakah itu ide yang bagus?

Sobrique menjelaskan bagaimana intervensi manual menyebabkan solusi yang Anda usulkan menjadi optimal , dan banyak orang yang berbicara tentang kemungkinan kegagalan berbagai komponen . Kedua IMO itu membuat poin yang sangat bagus dan harus dipertimbangkan dengan kuat.

Namun ada satu masalah yang tampaknya tidak ada yang mengomentari sejauh ini, yang sedikit mengejutkan saya. Anda melamar:

menjadikan [host cadangan panas saat ini] cadangan dingin, ambil hard drive, dan masukkan ke host utama dan ubah RAID dari 1 menjadi 1 + 1.

Ini tidak melindungi Anda dari apa pun yang dilakukan OS pada disk.

Ini hanya benar-benar melindungi Anda terhadap kerusakan disk, yang dengan berpindah dari mirror (RAID 1) ke mirror of mirror (RAID 1 +1) Anda sangat mengurangi dampak untuk memulainya. Anda bisa mendapatkan hasil yang sama dengan menambah jumlah disk di setiap set mirror (mulai dari 2-disk RAID 1 ke 4-disk RAID 1, misalnya), bersama dengan kemungkinan besar meningkatkan kinerja membaca selama operasi biasa.

Kalau begitu, mari kita lihat beberapa cara ini bisa gagal .

• Katakanlah Anda menginstal pembaruan sistem, dan sesuatu menyebabkan proses gagal setengah jalan; mungkin ada kegagalan daya dan UPS , atau mungkin Anda mengalami kecelakaan aneh dan menabrak bug kernel yang melumpuhkan (Linux cukup andal akhir-akhir ini, tetapi masih ada resikonya).
• Mungkin pembaruan memperkenalkan masalah yang tidak Anda tangkap selama pengujian (Anda melakukan pembaruan sistem pengujian, kan?) Yang memerlukan failover ke sistem sekunder saat Anda memperbaiki yang utama
• Mungkin bug dalam kode sistem file menyebabkan penulisan palsu ke disk.
• Mungkin administrator dengan jari yang gendut (atau bahkan jahat) melakukannya rm -rf ../*atau rm -rf /*sebaliknya rm -rf ./*.
• Mungkin bug dalam perangkat lunak Anda sendiri menyebabkannya merusak konten database secara besar-besaran.
• Mungkin virus berhasil menyelinap masuk.

Mungkin, mungkin, mungkin ... (dan saya yakin ada banyak lagi cara pendekatan yang diusulkan Anda bisa gagal.) Namun, pada akhirnya ini bermuara pada "dua set Anda selalu sinkron" "keuntungan". Terkadang Anda tidak ingin mereka benar-benar sinkron.

Tergantung pada apa yang sebenarnya telah terjadi, saat itulah Anda ingin siaga panas atau dingin siap untuk dinyalakan dan dinyalakan, atau cadangan yang tepat. Either way, RAID mirror of mirror (atau RAID mirror) tidak membantu Anda jika mode kegagalan melibatkan banyak hal selain dari kegagalan perangkat penyimpanan perangkat keras (disk crash). Sesuatu seperti raidzN ZFS mungkin bisa melakukan sedikit lebih baik dalam beberapa hal tetapi sama sekali tidak lebih baik dalam hal lain.

Bagi saya, ini akan membuat pendekatan yang Anda usulkan tidak boleh dilakukan sejak awal jika tujuannya adalah segala jenis bencana yang gagal.

Ya, ini sekolah yang agak tua. Perangkat keras modern tidak hanya sering gagal . Fokus baik pada membuat aplikasi Anda lebih tinggi tersedia (tidak selalu memungkinkan), atau pada item yang diperlukan untuk membuat host Anda lebih tangguh ...

Untuk host:

• Beli perangkat keras yang lebih baik.
• Pastikan Anda memiliki kontrak dukungan.
• DAFTARKAN kontrak dukungan server Anda (suku cadang tersedia secara lokal berdasarkan data registrasi!)
• Gunakan catu daya redundan, (perangkat keras?) RAID, kipas berlebihan.
• Jika server tidak mampu mengakomodasi fitur-fitur yang berlebihan di atas, simpan sasis atau komponen cadangan agar dapat memperbaiki sendiri jika terjadi kegagalan.

Dalam rangka mengurangi frekuensi kegagalan, saya melihat: disk, RAM, catu daya, kipas paling sering ... Kadang-kadang board sistem atau CPU. Tapi dua yang terakhir adalah di mana kontrak dukungan Anda harus dimulai.

Ini agak tidak efisien - paling tidak karena ketergantungan pada intervensi manual untuk beralih.

Saya telah bekerja di tempat-tempat yang menjalankan situs DR panas - secara harfiah, server identik dengan yang utama, siap untuk langsung digunakan. Namun peralihan DR adalah proses otomatis - kita tidak berbicara kabel, sedikit mengutak-atik dan beralih, tetapi proses ketika kita menekan tombol membalik segalanya dari satu situs ke situs lainnya.

Pendekatan ini sangat mahal, tetapi itu adalah keputusan bisnis - risiko yang dapat diterima vs uang yang dibutuhkan untuk mencapai tujuan. Sebagai aturan, ada kurva eksponensial pada sasaran waktu pemulihan - semakin dekat ke nol, semakin banyak biayanya.

Tapi itulah pertanyaan Anda sebenarnya. Apa adalah tujuan waktu pemulihan Anda, dan apa cara yang paling efektif untuk mencapai itu. Menunggu server untuk boot akan memakan waktu beberapa menit. Berapa lama seseorang untuk melakukan penyesuaian dan 'tugas pemulihan' ketika tiba jam 4 pagi?

Dan berapa lama pemadaman yang dapat diterima?

Saya menyarankan bahwa jika Anda melakukan 'pemulihan panas' Anda ingin berpikir tentang pengelompokan. Anda bisa menjadi cukup murah dalam pengelompokan dengan penggunaan VMWare yang baik - 'gagal' ke VM - bahkan dari fisik - berarti Anda tidak menjalankan perangkat keras yang berlebihan. (Ya, N +1 daripada 2N).

Jika RTO Anda cukup panjang, matikan kotaknya. Anda mungkin menemukan bahwa RTO cukup bahwa membangun kembali dingin dari cadangan tidak masalah.

Fakta bahwa itu adalah sekolah tua tidak selalu membuat penggunaan cadangan panas ide yang buruk.

Perhatian utama Anda harus menjadi alasan, apa risiko yang Anda jalankan, dan bagaimana menjalankan cadangan panas meredakannya. Karena dalam persepsi saya cadangan panas Anda hanya mengatasi kegagalan perangkat keras, yang walaupun tidak jarang, bukan satu-satunya risiko operasional yang Anda jalankan, atau yang paling mungkin. Kekhawatiran kedua adalah apakah strategi alternatif memberikan lebih banyak pengurangan risiko atau penghematan yang signifikan.

Menjalankan cadangan panas dengan beberapa langkah kegagalan manual akan memakan waktu lama dan kemungkinan akan salah, tetapi saya juga tampaknya failover otomatis dengan suite HA cluster yang berubah menjadi f * cks cluster besar.

Hal lain adalah bahwa siaga panas atau dingin di lokasi yang sama tidak memberikan kelangsungan bisnis jika terjadi bencana lokal.

Konsep memiliki cadangan panas atau bahkan dingin tergantung bagaimana aplikasi dibangun di tempat pertama.

Yang saya maksudkan adalah bahwa jika aplikasi telah dibangun sedemikian rupa sehingga data dan beban layanan tersebar di beberapa mesin, maka konsep mesin tunggal mana saja yang menurunkan sistem harus hilang. Dalam situasi itu Anda tidak perlu cadangan panas. Alih-alih, Anda perlu kapasitas berlebih yang cukup untuk menangani ketika mesin / komponen individual mati.

Misalnya, aplikasi web standar umumnya memerlukan server web dan server database. Untuk server web, cukup masukkan saldo 2 atau lebih. Jika seseorang meninggal, tidak ada masalah besar. Basis data biasanya lebih sulit karena harus dirancang agar multi-master dengan semua data disinkronkan di mesin yang berpartisipasi. Jadi, alih-alih server DB tunggal Anda berakhir dengan 2 (atau lebih) yang keduanya melayani kebutuhan data Anda. Penyedia layanan besar seperti Google, Amazon, Facebook, dll telah menempuh rute ini. Ada lebih banyak biaya dimuka dalam pengembangan waktu, tetapi membayar dividen jika Anda perlu skala.

Sekarang, jika aplikasi Anda tidak terstruktur sedemikian rupa atau hanya menghambat untuk menyesuaikan aplikasi maka ya Anda mungkin ingin cadangan panas.