Ketersediaan server tinggi untuk bisnis kecil

Setelah memiliki sedikit ketakutan dengan server yang tidak akan muncul suatu pagi, para petinggi telah memutuskan bahwa bisnis membutuhkan ketersediaan tinggi / gagal atas pengaturan.

Kami memiliki 5 server utama (4x Linux, 1x OpenBSD) yang semuanya harus berjalan agar perusahaan dapat beroperasi. Tiga server cukup standar (File / Web / Database), yang keempat menangani sebagian besar perutean jaringan dan proxy web, sedangkan yang kelima mendukung sistem telepon kami dan memiliki perangkat keras yang tidak standar.

Bos saya telah menyatakan bahwa waktu penyelesaian untuk kegagalan server harus di bawah 30 menit.

Pengalaman saya di bidang ini tidak ada (saya hanya seorang programmer yang 'dipromosikan'), jadi saya kira pertanyaan saya benar-benar bermuara pada:

• Apakah ini sesuatu yang bahkan harus dicoba oleh seseorang dengan rata-rata keterampilan server-admin. Jika demikian, apa yang harus saya baca, dan kepada siapa saya harus berbicara?

Terima kasih.

Saya pikir Anda harus mulai dengan mengumpulkan angka-angka untuk menggambarkan biaya yang terkait dengan memenuhi "persyaratan" yang dinyatakan untuk melihat apakah itu bahkan termasuk dalam anggaran. Jika Anda tidak nyaman dengan semua metode "normal" yang akan digunakan untuk memenuhi persyaratan (pengelompokan failover, hypervisor dengan kemampuan "migrasi panas", dll.), Maka Anda mungkin sebaiknya mencari konsultan yang dapat membantu.

Akan ada beberapa biaya yang terkait dengan studi kelayakan, tetapi biayanya akan jauh lebih murah untuk menemukan bahwa solusi yang baik tidak akan sesuai dengan persyaratan yang dinyatakan (yang berarti bahwa harapan perlu ditetapkan lebih realistis oleh manajemen - atau mereka perlu menambah lebih banyak uang) daripada biaya untuk melakukan sesuatu setengah-setengah yang akhirnya tidak memenuhi persyaratan sama sekali dan menghabiskan banyak uang dalam proses itu.

Sepertinya bos Anda baru saja mengeluarkan nomor itu. Mungkin dia telah melakukan beberapa analisis dan tahu apa biaya per jam yang terkait dengan downtime dari berbagai sistem, tapi saya ragu. Kedengarannya seperti angka pai di langit yang tidak terikat dengan kenyataan. Saya akan terkejut jika semua sistem Anda membutuhkan ketersediaan semacam itu. Mungkin, dalam perjalanan mempelajari bisnis, bahwa Anda menemukan bahwa hanya sebagian dari fungsi yang perlu memiliki tingkat uptime dan toleransi kesalahan (dan, dengan demikian, solusi seperti itu pada akhirnya akan lebih murah). Saya yakin bahwa ponsel dan aplikasi lini bisnis ada di sana, tetapi Anda mungkin memiliki toleransi untuk downtime pada beberapa sistem lain.

Naluri saya mengatakan bahwa Anda mungkin akan menemukan kemenangan dalam menggunakan teknologi virtualisasi untuk membuat sistem failover berdasarkan migrasi mesin virtual antara perangkat keras yang berlebihan. Apakah itu sesuai dengan anggaran Anda atau tidak akan tergantung pada bisnis Anda, karena Anda pasti membutuhkan beberapa jenis SAN untuk membuatnya bekerja secara efektif.

Namun, jangan mengabaikan pengelompokan failover "tradisional". Pasti ada "kemenangan" di sana, juga, jika aplikasi Anda cocok untuk konfigurasi seperti itu.

Saya ingin tahu apakah bos Anda telah memikirkan skenario kegagalan bencana (kebakaran gedung, banjir, angin puting beliung, pencurian, dll). Jika itu belum direncanakan, ini akan menjadi peluang emas untuk bekerja dalam beberapa perencanaan kesinambungan bisnis umum dan kontinjensi pemulihan bencana.

Dapatkan bantuan dari seseorang yang dapat datang dan mempelajari bisnis Anda dan membuat rekomendasi. Anda tidak akan menyesalinya.

"Jalan ini mengarah ke banyak rasa sakit dan sakit ..."

Jadi, apa Rencana Kesinambungan Bisnis Anda? Anda berencana Disaster Recovery?

Sudahkah Anda mendiskusikannya? Menulisnya? MENGUJI ITU?

Anda perlu melakukan percakapan yang tepat dengan "atasan" dan benar-benar sampai ke bagian bawah persyaratan untuk ketersediaan tinggi karena berbeda untuk layanan yang berbeda.

Jadi apa sebenarnya "titik sakit" yang mereka rasakan pagi itu?

Apakah itu?

• Telepon berhenti bekerja? Masalah yang cukup besar (dan terlihat). Dan ya - ini akan membutuhkan "solusi" tetapi mudah-mudahan ini berada di bawah perjanjian dukungan?
• Situs web gagal? OK - Cukup terlihat tetapi tidak terduga, dan kecuali Anda memiliki kehadiran web BESAR maka tidak penting. OK untuk menurunkan server ini selama beberapa jam.
• Server basis data turun? Menakutkan ... Semoga Anda mendapat cadangan yang bagus! Jangan kehilangan data kalau tidak bisnisnya AKAN gagal. Tapi, selama datanya aman maka itu adalah server yang penting dan harus memiliki rencana pemulihan.
• File dan cetak (dan aplikasi internal dll). Ini adalah PITA untuk kebanyakan orang karena mereka akan duduk dan tidak melakukan apa pun untuk pagi hari saat Anda memperbaikinya.

Saya berasumsi Anda telah membeli perangkat keras berkualitas tinggi untuk sistem utama Anda? Bagus, karena murah pada perangkat keras adalah ekonomi yang salah karena server ini datang dengan "dual" semuanya di dalam kotak.

Saya juga akan menganggap Anda tahu BAGAIMANA membangun kembali server, bertukar kipas, catu daya, memutar server, mengkonfigurasi jaringan jalur ganda menjadi sakelar yang berlebihan? Anda telah melakukan ini cukup waktu untuk memahami apa yang berhasil dan yang tidak, apa yang normal dan apa yang erron? Jika tidak maka dapatkan bantuan dan pelatihan (atau setidaknya latihan dan pengalaman).

Mungkin banyak masalah yang TAKUT. Mereka tidak memiliki petunjuk bahwa masalah seperti itu dapat terjadi (dan seberapa penting server untuk bisnis mereka) dan Anda tidak benar-benar tahu apa yang Anda lakukan (?) Masalah kepercayaan diri?

Anda harus mendapatkan semua hak di atas SEBELUM menyusuri rute HA yang sangat mahal. Bisakah bisnis membeli peralatan mahal ini (dan sebagian besar, menurut definisi, hanya akan digunakan dalam kegagalan dan sering tidak pernah digunakan!)

Evan mendapatkan beberapa poin bagus, tapi mungkin ada beberapa cara efektif untuk mendapatkan waktu pemulihan 1 jam dalam menghadapi kegagalan.

Small Business cenderung berarti perangkat keras kecil, jadi mungkin tidak banyak biaya untuk melakukan beberapa hal sederhana yang sebenarnya menambah jumlah ketahanan yang signifikan dalam menghadapi masalah. Ide utamanya adalah hanya memiliki perangkat keras tambahan yang siap digunakan.

Pertama, merasa nyaman dengan pemikiran IP virtual. Itu adalah alamat IP yang akan diajak bicara pengguna, tetapi dapat berada di server mana pun yang Anda berikan. Ini adalah alamat IP yang Anda pengguna, dan aplikasi ingin diajak bicara. Dan itu akan menjadi yang paling bermanfaat untuk akhirnya solusi apa pun yang Anda pilih. Memiliki VIP berarti Anda tidak perlu mengkonfigurasi ulang aplikasi mana pun ketika gagal. Juga, perlu diingat bahwa memiliki perangkat keras yang berlebihan juga berdampak meningkatkan biaya administrasi, melakukan dua pembaruan konfigurasi daripada 1.

Jika kami mulai dengan perutean / server proxy web Anda, itu mungkin yang termudah karena mereka tidak akan menjadi keadaan nyata yang perlu disimpan di kotak itu sendiri. Jadi, dapatkan duplikat dari kotak yang sama, dan konfigurasikan hal yang sama. Saya akan tetap terhubung pada segmen LAN, dan dengan asumsi Anda internet di antarmuka lain, tukar kabel jika mereka gagal. Dari perspektif perutean, Anda menetapkan semua yang Anda klien untuk menargetkan alamat .1 (VIP) untuk rute default mereka dan server proxy memberikan server A alamat .2 dan server B alamat .3. Dengan cara ini keduanya dapat dikelola untuk pembaruan konfigurasi (berlaku untuk keduanya). Dan yang harus Anda lakukan untuk failover adalah menghapus tugas IP .1 dari .2 dan memindahkannya ke .3, dan memindahkan koneksi internet ke antarmuka lainnya. Itu tidak terlalu rumit, mudah dilakukan dan dipahami, dan biaya perangkat keras tambahan dari kotak kedua. Jika Anda bisa mendapatkan redundansi di sisi internet, Anda bisa menambahkan beberapa kompleksitas, dan mendapatkan failover otomatis menggunakan sesuatu seperti VRRP.

Tanpa spesifik, sulit dikatakan tetapi server web Anda mungkin sesederhana itu. Tambahkan server kedua dengan konfigurasi Identik, buat vIP di antara keduanya, dan pindahkan VIP ke cadangan saat menghadapi kegagalan. Saya biasanya tidak keberatan jika keadaan sesi hilang pada failover (itu masalah kritis yang menyebabkan failover). Jadi, jika pengguna harus masuk lagi, bukan masalah besar. Sekali lagi, vrrp mungkin dapat digunakan untuk failover otomatis.

Pindah ke Anda DB, ini jauh lebih kompleks. Sebagian besar DB memiliki semacam model primer / sekunder, di mana Anda membuat cadangan DB asli ke sekunder, dan kemudian menyalin semua log transaksi atau perubahan DB ke sekunder. Sekali lagi, Anda dapat menggabungkan ini dengan VIP untuk aplikasi / pengguna yang benar-benar mengakses DB. Namun, failover lebih sering terjadi. Bergantung pada kegagalan utama, Anda mungkin harus benar-benar menjalankan dan menjalankan untuk menyalin dan sisa log transaksi. Kemudian aktifkan sekunder. Jika Anda dapat mentolerir beberapa data yang hilang, maka Anda dapat segera mengaktifkan yang sekunder. Setelah failover, server B sekarang Anda utama, dan Anda sedang bekerja untuk mengembalikan server A, dan mengubahnya menjadi cadangan baru sehingga siap gagal ketika server b akhirnya memiliki masalah.

File server selalu merupakan bagian yang paling sulit, karena tidak seperti DB, banyak fitur yang sulit didapat dari sistem file. Namun, beberapa tingkat ketahanan dapat dicapai dengan memiliki server kedua, dan menulis skrip yang memindai sistem file untuk perubahan, dan menyalin file baru apa pun ke sekunder. Pada dasarnya Anda dapat menjalankan rsync pada cron yang saya percayai untuk melakukan ini. Sekali lagi, Anda menggunakan VIP yang Anda berikan kepada pengguna, bahwa Anda pindah jika Anda melakukan failover. Dalam skrip Anda, saya sangat merekomendasikan agar Anda memeriksa untuk memastikan bahwa sistem adalah pemilik VIP sebelum mentransfer file. Anda benar-benar benar-benar tidak ingin rsync dieksekusi di arah yang salah dan menimpa setiap perubahan yang Anda buat pengguna. Ini bisa kehilangan beberapa file jika gagal,

Saya tidak tahu apa yang dapat Anda lakukan terhadap sistem telepon Anda ... itu benar-benar tergantung pada vendor dan bagaimana pengaturannya. Vendor mungkin memiliki beberapa solusi untuk ketahanan.

Beberapa kata peringatan terakhir. Pastikan Anda benar-benar menguji pengaturan yang akan Anda lakukan. Pastikan Anda tahu bagaimana cara membuatnya gagal tanpa kehilangan informasi penting itu. Tes tes tes untuk memastikan itu akan berfungsi saat Anda membutuhkannya. Pastikan Anda memiliki proses yang memungkinkan perubahan konfigurasi, pembaruan perangkat lunak, dll. Diterapkan dengan benar ke cadangan utama dan cadangan. Berita baiknya adalah, Anda mungkin dapat melakukan failover yang terkontrol saat Anda ingin menurunkan server, dan lain-lain. Ini bukan pengaturan aktif-aktif, jadi Anda tidak tahu apakah sekunder akan berfungsi saat Anda membutuhkannya.

Saya bekerja di bidang telekomunikasi, dan peralatan kami sangat redundan, termasuk dalam kebanyakan kasus redundansi geografis. Titik kegagalan nomor 1 kami adalah redundansi tidak diuji setelah perubahan, dan pengguna membuat perubahan yang tidak tahu cara kerja model redundansi. Namun, kami memiliki masalah tambahan bahwa semua peralatan kami perlu mendukung failover otomatis dalam waktu tidak lebih dari beberapa detik. Anda dapat mentolerir intervensi manual dalam kegagalan Anda jika Anda hanya perlu bangun dan berjalan dalam waktu 30 - 60 menit. Anda hanya perlu dipersiapkan. Semoga berhasil.

Poin semua orang bagus, jadi hanya beberapa komentar.

30 menit tidak mungkin dijamin, terutama untuk semuanya. Anda dapat mengatakan ini sebagai target, tetapi tidak ada cara untuk menjamin, karena selalu ada faktor X. Anda dapat memiliki 2 saluran ISP dan sebuah truk menabrak gedung dan mengeluarkan keduanya karena Anda tidak berpikir bahwa memiliki mereka dialihkan dari ujung gedung yang berlawanan adalah salah satu contoh.

Sebagai awal penetapan biaya, gandakan semuanya. Anda memiliki 5 server sehingga Anda perlu menggandakannya. Tidak semua harus menggunakan perangkat keras, Anda dapat melakukan virtualisasi, tetapi Anda mengerti maksud saya. Selain itu, semuanya harus sadar HA yang juga akan menambah biaya, Anda mungkin tahu Anda harus mengganti router Anda dengan yang baru dan oh Anda membutuhkan 2 dari mereka. Jangan lupa untuk menggandakan feed daya dan mendapatkan generator, karena Anda tidak dapat menjamin perusahaan listrik akan kembali dalam 30 menit.

Contoh-contoh ini berpikir ini adalah pengaturan siaga yang panas yang menurut saya bos Anda sedang berpikir.

Apa yang saya temukan lebih baik untuk bisnis kecil adalah merancang rencana untuk memulihkan dan mengklasifikasikan segalanya.

Cari tahu layanan apa yang tersedia

kritis (berhenti bisnis)

penting (bisnis melambat)

rutin (bisnis dapat bertahan tanpa itu untuk sementara waktu).

Misalnya, telepon pusat panggilan Anda sangat penting, jadi mungkin seseorang layak membeli server kedua dan ISP kedua dan pemadaman listrik rata-rata Anda adalah sekitar 15 menit sehingga kami akan mendapatkan UPS untuk yang akan bertahan 60 menit (jangan lupakan juga workstation). Sekarang katakanlah ERP hanya penting, artinya Anda dapat berfungsi tanpa sedikit. Mungkin orang-orang call center Anda menggunakannya, tetapi jika tidak berfungsi, mereka dapat kembali ke pulpen dan kertas atau notepad lalu memperbarui ERP setelahnya. Prosedur untuk melakukannya jika turun mungkin lebih murah daripada mencoba menjadikannya layanan yang kritis. Dan yang rutin mungkin sesuatu seperti printer, ok itu menyebalkan tapi kita bisa membayar untuk beberapa hari jika mereka semua turun.

Itu juga memberi Anda perintah untuk memperbaiki barang-barang jika s ** t benar-benar mengenai penggemar suatu hari :)

Apa itu mungkin? Tentu. Apakah harganya terjangkau? Mungkin bukan untuk "bisnis kecil", terutama jika Anda memiliki bos yang memberi Anda nomor sewenang-wenang untuk bekerja, dan dia menuntut ketersediaan tinggi dari departemen TI yang terdiri dari seorang programmer yang diwakili (melihatnya berkali-kali di tempat lain dan tidak pernah cantik untuk tingkat stres Anda, jika situasi Anda seperti mereka).

Failover dimungkinkan tetapi biasanya membutuhkan perangkat keras yang berlebihan, SAN untuk berbagi data antar server, dll ... dengan kata lain, semoga berhasil didanai jika mereka tidak akan menyewa administrator yang berdedikasi untuk mengurusnya.

Perangkat keras sistem panggilan Anda yang Anda sebutkan adalah perangkat keras khusus, dan Anda disebut sebagai pusat panggilan. Anda harus berbicara dengan vendor tentang opsi untuk menjadikannya berlebihan. Bermain-main dengan itu bisa membatalkan dukungan di tempat pertama.

Sistem lain yang kemungkinan besar Anda bisa mendapatkan redundansi dengan berinvestasi pada solusi tipe VMWare (atau Hyper-V atau XenServer, tapi saya akan melihat VMware dan XenServer terlebih dahulu). Kemudian Anda dapat melihat mendapatkan SAN, beberapa server berdaging dengan switch jaringan cepat, dan menggunakan LiveMotion untuk memigrasikan server virtual antara server perangkat keras jika ada kegagalan, serta menyeimbangkan beberapa beban antara server sesuai kebutuhan.

Anda menyebutkan Anda menjalankan Linux di sistem itu. Dengan uang untuk mendapatkan beberapa server, Anda bisa melihat menyiapkan DRBD dengan program detak jantung dan STONITH untuk mereplikasi data antar server dan mengambil alih ketika ada yang tidak tersedia; Anda akan melihat pengaturan sistem di mana Anda telah benar-benar menduplikasi setiap server, serta menggandakan konsumsi daya dan pembuangan panas di ruang server (jika Anda memiliki ruang server). Itu bisa dilakukan untuk biaya perangkat keras dan kewarasan Anda. Ditambah lagi Anda harus mengujinya, Anda akan memiliki waktu henti saat mengonfigurasinya, dan Anda masih memiliki kemungkinan bahwa itu tidak akan bekerja di kali karena masih ada kemungkinan masalah muncul yang harus diurus (dibagi otak, misalnya).

Terakhir adalah rencana untuk membuat beberapa sistem bertindak sebagai sistem batu tulis kosong dan memiliki rencana cadangan yang sangat baik untuk memungkinkan Anda mengembalikan data ke salah satu sistem "kosong" jika server mati. Memiliki perangkat keras di tempat akan memberi Anda beberapa opsi jika / ketika server mati; tetapi Anda masih akan memiliki beberapa downtime saat memulihkan data, dan Anda memerlukan instruksi tentang cara menginstal aplikasi dengan benar ke server baru. Tergantung pada seberapa cepat Anda bekerja dan seberapa besar data Anda, Anda mungkin memiliki downtime yang berlangsung dari beberapa jam hingga satu atau dua hari. Anda memang memiliki cadangan yang berfungsi dan dikenal baik untuk server Anda, dengan rencana pemulihan, ya?

Haruskah Anda mencobanya? Reaksi pertama saya adalah bahwa jika Anda menggaruk-garuk kepala di salah satu saran atau merasa ada lubang di perut Anda saat mencoba memikirkan hal-hal ini, maka Anda seharusnya tidak melakukannya. Anda akan memerlukan perusahaan konsultan untuk datang dan melihat masalah dan mencari tahu biaya serta mengimplementasikannya, atau Anda perlu menyewa sysadmin khusus untuk melakukannya untuk perusahaan Anda.

Fakta mereka menyuruh Anda melakukannya dan Anda mengatakan Anda "hanya seorang programmer yang" dipromosikan "dan Anda memiliki PHB yang memberi tahu Anda untuk memberikan redundansi dengan waktu kegagalan maksimum 30 menit adalah Anda baik dari sebuah sungai.