Pertanyaan tentang titik kegagalan tunggal untuk operasi kecil

1. Jika Anda tidak mampu atau tidak membutuhkan server cluster atau server cadangan yang menunggu untuk online jika terjadi kegagalan, sepertinya Anda dapat membagi layanan yang disediakan oleh satu server yang gemuk menjadi dua server yang kurang gemuk. Jadi jika Server A turun, klien mungkin kehilangan akses ke, katakan email, dan jika Server B turun, mereka mungkin kehilangan akses ke sistem ERP .

   Meskipun pada awalnya ini sepertinya akan lebih dapat diandalkan, bukankah itu hanya meningkatkan kemungkinan kegagalan perangkat keras? Jadi setiap kegagalan tidak akan berdampak besar pada produktivitas, tetapi sekarang Anda mempersiapkan diri untuk kegagalan sebanyak dua kali lipat.

   Ketika saya mengatakan "kurang gemuk", yang saya maksud adalah spec komponen yang lebih rendah, bukan kualitas yang lebih rendah. Jadi satu spesifikasi mesin keluar untuk visualisasi vs dua server yang ditentukan untuk masing-masing memuat lebih sedikit.

2. Seringkali SAN direkomendasikan sehingga Anda bisa menggunakan pengelompokan atau migrasi untuk menjaga layanan tetap terjaga. Tapi bagaimana dengan SAN itu sendiri? Jika saya menaruh uang di tempat kegagalan akan terjadi, itu tidak akan menjadi perangkat keras server dasar, itu akan ada hubungannya dengan penyimpanan. Jika Anda tidak memiliki semacam SAN redundan, maka server redundan itu tidak akan memberi saya rasa percaya diri yang besar. Secara pribadi untuk operasi kecil akan lebih masuk akal bagi saya untuk berinvestasi di server dengan komponen yang berlebihan dan drive lokal. Saya dapat melihat manfaat dalam operasi yang lebih besar di mana harga dan fleksibilitas SAN hemat biaya. Tetapi untuk toko-toko kecil saya tidak melihat argumen, setidaknya tidak untuk toleransi kesalahan.

Ini semua bermuara pada manajemen risiko. Melakukan analisis biaya / risiko yang tepat dari sistem TI Anda akan membantu Anda mencari tahu di mana harus menghabiskan uang dan risiko apa yang bisa atau harus Anda jalani. Ada biaya yang terkait dengan semuanya ... ini termasuk HA dan downtime.

Saya bekerja di tempat yang kecil jadi saya memahami perjuangan ini dan orang IT geek dalam diri saya tidak menginginkan satu titik kegagalan di mana pun, tetapi biaya untuk melakukan itu di setiap tingkat bukanlah pilihan yang realistis. Tapi di sini ada beberapa hal yang bisa saya lakukan tanpa anggaran besar. Ini tidak selalu berarti menghapus satu titik kegagalan.

Network Edge : Kami memiliki 2 koneksi internet T1 dan Comcast Business. Berencana untuk memindahkan firewall kami ke sepasang komputer lama yang menjalankan pfSense menggunakan CARP untuk HA.

Jaringan : Mendapatkan beberapa sakelar yang dikelola untuk inti jaringan dan menggunakan ikatan untuk membagi server kritis di antara kedua sakelar tersebut mencegah kegagalan sakelar dari mengeluarkan seluruh ruang penyimpanan data.

Server : Semua server memiliki RAID dan catu daya redundan.

Backup Server : Saya memiliki sistem yang lebih tua yang tidak sekuat server file utama tetapi memiliki beberapa sata drive besar di raid5 yang mengambil snapshot per jam dari server file utama. Saya memiliki pengaturan skrip untuk ini untuk beralih peran menjadi file server utama jika turun.

Offsite Backup Server : Mirip dengan backup di tempat kami melakukan backup malam hari ke server melalui terowongan vpn ke salah satu rumah pemilik.

Mesin Virtual : Saya memiliki sepasang server fisik yang menjalankan sejumlah layanan di dalam mesin virtual menggunakan Xen. Ini menjalankan berbagi NFS pada server file utama dan saya bisa melakukan migrasi langsung antara server fisik jika diperlukan.

Saya pikir ini adalah pertanyaan dengan banyak jawaban tetapi saya akan setuju di banyak toko kecil beberapa solusi server berfungsi dan seperti yang Anda katakan, setidaknya sesuatu terus berjalan jika ada kegagalan. Tetapi itu tergantung pada apa yang gagal.

Sangat sulit untuk menutupi semua pangkalan tetapi catu daya yang berlebihan, daya berkualitas baik dan cadangan yang baik dapat membantu.

Kami telah menggunakan Backup Exec System Recovery untuk beberapa sistem kritis. Tidak begitu banyak untuk pencadangan harian tetapi sebagai alat pemulihan. Kami dapat memulihkan ke perangkat keras yang berbeda, jika tersedia, dan kami juga menggunakan perangkat lunak untuk mengonversi gambar cadangan ke Mesin Virtual. Jika server gagal dan kami harus menunggu untuk perbaikan perangkat keras, kami dapat memulai VM di server atau workstation yang berbeda dan berjalan pincang. Tidak sempurna tetapi bisa berjalan dengan cepat.

Mengenai SAN: Hampir semua yang Anda gunakan akan mubazir. Bahkan jika itu adalah satu kandang, di dalamnya akan ada catu daya ganda, konektor ganda, dan 'kepala' ganda, masing-masing dengan tautan ke semua disk. Bahkan sesuatu yang sederhana seperti MD3000 yang dijual oleh Dell memiliki semua fitur ini. SAN dirancang untuk menjadi inti dari kotak Anda, jadi mereka dibuat untuk bertahan dari kegagalan perangkat keras apa pun.

Yang sedang berkata, Anda memiliki titik bahwa redundansi tidak selalu merupakan pilihan terbaik. TERUTAMA jika itu meningkatkan kompleksitas. (dan itu akan) Sebuah pertanyaan yang lebih baik untuk ditanyakan adalah ... "Berapa banyak perusahaan akan menerima downtime". Jika kehilangan server surat Anda selama satu atau dua hari bukanlah masalah besar, maka Anda mungkin tidak perlu repot dengan keduanya. Tetapi jika pemadaman server web mulai kehilangan uang nyata Anda setiap menit, maka mungkin Anda harus menghabiskan waktu membuat cluster yang tepat untuk itu.

Semakin banyak server yang Anda miliki, semakin besar peluang untuk terjadi sesuatu, itulah salah satu cara untuk melihatnya. Lain adalah jika salah satu istirahat, Anda berderak 100%, juga seperti yang Anda katakan.

Kegagalan perangkat keras yang paling umum adalah HDs, seperti yang Anda katakan di atas. Terlepas dari seberapa banyak Anda ingin membagi operasi, Anda harus RAIDing penyimpanan Anda.

Saya akan memilih beberapa server (tentu saja RAID) bukan satu server besar, baik untuk stabilitas operasi, dan kinerja. Lebih sedikit perangkat lunak yang saling bertabrakan dengan sumber daya yang diminta, mengurangi kekacauan, lebih banyak disk untuk dibaca / ditulis, dan sebagainya.

Saya pribadi akan memilih beberapa server. Saya tidak berpikir kegagalan peralatan lebih mungkin terjadi dalam skenario ini. Ya, Anda memiliki lebih banyak peralatan yang bisa gagal, tetapi peluang setiap unit gagal harus konstan.

Apa yang memiliki beberapa server dalam konfigurasi non-redundan / non-HA memberi saya kemampuan untuk memuat beberapa pekerjaan ke server lain jika terjadi kegagalan. Jadi, katakan server cetak saya turun. Jika saya dapat memetakan beberapa printer ke server file saat saya sedang memperbaiki server cetak, dampak operasi berkurang. Dan di situlah itu benar-benar penting. Kita sering cenderung berbicara tentang redundansi perangkat keras, tetapi perangkat keras hanya alat untuk kelangsungan operasi.

Saya bekerja di sebuah toko kecil (satu departemen IT pria) dan tidak akan menukar beberapa server saya dengan satu dalam situasi apa pun. Jika salah satu server rusak, saya memiliki opsi untuk menambahkan layanan yang sekarang hilang ke komputer lain atau bahkan hanya mengaturnya pada PC cadangan. Kita bisa hidup dengan pemadaman satu atau dua jam untuk sebagian besar hal, tetapi kita tidak bisa hidup dengan pemadaman total semua sistem. Meskipun saya dapat mengganti server kami dengan PC, setidaknya untuk sementara, saya tidak memiliki, atau dapat dengan mudah melakukan, apa pun di dekat yang cukup kuat untuk mengganti semua server sekaligus.

Posting asli Anda membuat hipotesis bahwa Anda tidak mampu membeli sebuah cluster, tetapi Anda mempertimbangkan solusi dengan dua server (tidak termasuk backup). Itu menyiratkan bahwa Anda kemungkinan besar memiliki tiga server di tangan, cukup untuk memulai sebuah cluster.

Ada solusi menengah yang dapat menghindari SPoF dan masih sesuai di usaha kecil / menengah: replikasi node-to-node tanpa penyimpanan SAN.

Ini didukung misalnya oleh Proxmox (tapi saya pikir itu juga didukung oleh XCP-ng / XenServer dan mungkin oleh ESXi).

Mari kita pertimbangkan pengaturan 3 node. Semua dengan RAID, redundant PSU, redundant network.

• Node A dan B memiliki CPU gemuk dan banyak RAM.
• Node C lebih sederhana dalam CPU / RAM tetapi memiliki banyak penyimpanan dan digunakan untuk memberikan kuorum pada pengawas ketersediaan tinggi, dan cadangan host.

Lalu dua opsi:

1. Semua VM biasanya berjalan pada node A dan direplikasi pada node B (membutuhkan CPU sepc yang layak)
2. VM dibagi antara node A dan B, dan direplikasi secara bersama-sama beberapa dari node A ke node B dan dari node B ke node A.

Setup semacam ini dapat mentolerir kegagalan jaringan, kegagalan total dan simpul utama (salah satu dari ketiganya), dengan downtime sekitar 1 menit (kira-kira waktu yang diperlukan untuk VM untuk boot up). Kelemahannya, adalah hilangnya data sejak replikasi terakhir (yang tergantung pada pengaturan dan kinerja perangkat keras Anda dapat serendah 1 menit, dan setinggi beberapa jam).

Dengan opsi ke-2 (VM biasanya terbagi antara node A dan B), Anda harus memprioritaskan VM mana yang diizinkan untuk kembali online. Karena, karena beban VM Anda biasanya terbagi antara dua server, memiliki semuanya berjalan pada satu node dapat menghabiskan RAM dari node atau congest CPU.

"Meskipun pada awalnya ini sepertinya akan lebih dapat diandalkan, bukankah itu hanya meningkatkan kemungkinan kegagalan perangkat keras?"

• Dari sudut pandang perangkat keras, saya tidak melihat bagaimana secara praktis meningkatkan peluang kegagalan. Ada banyak sekali variabel di sini, dan saya belum pernah mempelajari probabilitas, tetapi terlalu menyederhanakan: Katakanlah Dell membuat 1 server buruk per setiap 100.000 yang mereka buat. Peluang Anda telah berubah dari 1 dalam 100.000 menjadi 2 dalam 100.000 (atau 1 dalam 50.000). Jadi ya, dua kali kesempatan, tetapi masih karena skala peluang praktis tidak jauh berbeda.
• Saya pikir perspektif adalah kunci di sini. "Kau membuat dirimu gagal dua kali lebih banyak." Mungkin dari sudut pandang Anda , tetapi dalam kedua skenario yang Anda berikan, email berjalan di satu server dan ERP berjalan di satu server. Jadi dari perspektif email atau erp (yang menjadi perhatian bisnis), ini benar-benar sama. Kecuali mereka kesepian, atau suka ruang mereka ;-)
• Saya pikir Anda juga harus melihatnya dari sudut pandang orang. Saya pikir kegagalan karena kesalahan orang mungkin lebih mungkin, dan dengan cara ini seseorang mungkin hanya akan mengacaukan satu server pada suatu waktu. Ini juga membuatnya lebih mudah untuk mengidentifikasi masalah dengan hal-hal seperti memuat. Jika email dan situs web berjalan di server, waktu ekstra untuk mencari tahu di mana masalahnya.

Tidak pernah ini sederhana, server gemuk besar mungkin lebih baik dibuat atau lebih buruk dibuat. Mereka mungkin memiliki bagian berkualitas lebih tinggi, tetapi mungkin menghasilkan lebih banyak panas dan tidak didinginkan dengan benar. Server berdaging memiliki lebih banyak RAM, lebih banyak CPU dll, jadi pada akhirnya mungkin Anda memiliki banyak CPU di kedua skenario jadi mungkin server bukan unit yang tepat untuk dipikirkan.

Karena kerumitan peluangnya, apa pun yang paling efektif menurut hemat biaya, saya kira. Jika Anda harus membayar lisensi 1 server besar mungkin lebih murah daripada beberapa server kecil tergantung pada struktur lisensi.

Pendekatan default saya adalah untuk menghindari infrastruktur terpusat. Misalnya, ini berarti tidak ada SAN , tidak ada Load Balancer . Anda juga dapat menyebut pendekatan terpusat semacam itu "monolitik".

Sebagai seorang arsitek perangkat lunak, saya bekerja dengan infrastruktur pelanggan. Itu mungkin berarti menggunakan pusat data pribadi mereka sendiri, atau menggunakan sesuatu seperti AWS. Jadi saya biasanya tidak memiliki kendali atas apakah mereka menggunakan SAN atau tidak. Tetapi perangkat lunak saya biasanya menjangkau beberapa pelanggan, jadi saya membangunnya seolah-olah itu akan dijalankan pada mesin individu secara terpisah di jaringan.

Contoh Email

Surel itu aneh, karena ini sistem warisan (yang berfungsi). Jika email ditemukan hari ini, mungkin akan menggunakan RESTFul API di server web, dan data akan berada dalam database yang dapat direplikasi menggunakan alat normal (Replikasi Transaksional, Pencadangan Tambahan).

Solusi arsitektur perangkat lunak, adalah bahwa Aplikasi Web akan terhubung ke salah satu daftar node yang tersedia (secara acak), dan jika itu tidak tersedia, ia akan mencoba untuk terhubung ke node lain (secara acak). Seorang klien mungkin akan ditendang dari server, jika terlalu sibuk. Di sini, tidak perlu penyeimbang beban untuk terhubung ke web farm; dan, tidak perlu untuk SAN untuk ketersediaan tinggi. Mungkin juga untuk membuang basis data per-departemen atau geografi.

Komoditas berarti ...

Jadi, alih-alih memiliki server 1 atau 2 yang mahal dan SAN dengan langkah redundansi internal, Anda dapat menggunakan beberapa mesin berbiaya rendah yang berdaya rendah.

• Kesederhanaan - redundansi murni berasal dari jumlah perangkat. Anda dapat dengan mudah memverifikasi redundansi Anda dengan jumlah mesin. Dan Anda lebih tepat memperkirakan mereka memiliki peluang kegagalan yang lebih tinggi dan bersiap untuk itu.

• Persentase redundansi - Jika Anda memiliki 2 server, jika salah satu gagal, Anda memiliki 1 yang tersisa (50%). Jika Anda memiliki 10 server komoditas dan satu gagal, Anda memiliki 9 server tersisa (90%)

• Inventaris - alat komoditas tersedia dari toko terdekat dengan harga yang terjangkau.

• Kompatibilitas - dengan saluran serat, dan semua jenis standar untuk format volume disk, perangkat komoditas, dan arsitektur perangkat lunak berarti Anda tidak dikunci ke dalam model atau merek perangkat tunggal.

• Kinerja - Dengan 2 perangkat di SAN, mereka harus berada di ruangan yang sama. Dengan pendekatan mesin komoditas, jika Anda memiliki 5 kantor, Anda dapat memiliki 2 di setiap kantor, dengan redundansi WAN VPN antar kantor. Ini berarti perangkat lunak dan komunikasi ada di LAN pada waktu akses <1ms.

• Keamanan - membangun tingkat redundansi tingkat tinggi, Anda dapat dengan mudah membangun kembali node sebagai proses reguler komoditas. Ingin membangun kembali kluster 2-server monolitik? Keluar manualnya. Dengan membangun kembali mesin sesering mungkin (dengan otomatisasi) Anda memperbarui peranti lunak, dan mencegah peretas atau virus mendapatkan pijakan di jaringan Anda.

Catatan: Anda masih harus memiliki beberapa redundansi switch dan gateway router