Kapan waktu yang tepat untuk memperkenalkan ketersediaan tinggi untuk situs web?

16

Ada banyak artikel tentang opsi Ketersediaan Tinggi. Tidak begitu jelas namun KAPAN waktu yang tepat untuk beralih dari satu server ke konfigurasi ketersediaan tinggi.

Silakan pertimbangkan situasi saya:
http://www.postjobfree.com adalah situs web 24/7 dengan lalu lintas yang signifikan:
http://www.similarweb.com/website/postjobfree.com

Saat ini saya menjalankannya di satu server: baik server web IIS 7.0 dan SQL Server 2008 dijalankan pada kotak perangkat keras yang sama.

Ada sesekali (~ satu per bulan) ~ 5 menit downtime biasanya disebabkan oleh reboot yang diperlukan oleh beberapa pembaruan Windows Server. Biasanya downtime dijadwalkan dan terjadi pada malam hari. Tetap saja tidak menyenangkan, karena Google Bot dan beberapa pengguna masih aktif di malam hari.

Pendapatan situs web saat ini adalah ~ $ 8K / bulan.

Saya mempertimbangkan untuk beralih ke konfigurasi dua server (web farm dari 2 server web dan sekelompok 2 SQL Server yang dihosting pada dua server perangkat keras).

Kelebihan:
1) Ketersediaan Tinggi (secara teoritis tidak ada downtime). Bahkan jika salah satu server turun - server lain akan mengambil alih.
2) Tidak ada kehilangan data: tanpa SQL cluster, hingga satu hari data dapat hilang jika terjadi kegagalan perangkat keras (kami membuat cadangan harian).

Cons:
1) Lebih banyak upaya untuk mengatur dan memelihara konfigurasi tersebut.
2) Biaya hosting lebih tinggi. Alih-alih ~ $ 600 / bulan itu akan menjadi sekitar $ 1200 / bulan.

Apa yang akan menjadi rekomendasi Anda?

— Dennis Gorelik
sumber

Jawaban atas pertanyaan saya mungkin memengaruhi perkembangan. Sebagai contoh, saya dapat mempertimbangkan memisahkan database menjadi beberapa bagian dan menyimpan data yang membutuhkan keandalan tinggi (input pengguna) secara terpisah dari data yang membutuhkan kinerja tinggi (perhitungan).

2

Halo Dennis, ini bukan rekomendasi, jadi saya menusuknya sebagai komentar, tetapi biaya hosting Anda tampaknya cukup tinggi untuk satu server windows? Saya berasumsi itu adalah server yang sepenuhnya berdedikasi (bukan VM), tetapi bahkan Anda harus melihat mungkin setengah dari biaya untuk server spesifikasi yang layak dengan 8GB RAM, jumlah ruang disk yang baik, dll. Mungkin perlu berbicara dengan perusahaan hosting Anda tentang mendapatkan harga yang lebih baik.

— Ewan Leith

6

Saya pikir Ketersediaan Tinggi harus direncanakan sejak saat pertama konsepsi proyek.

— Tom O'Connor

Ewan, saya ingin situs web saya bekerja cepat, jadi saya punya prosesor Quad dengan memori 8 GB dan drive SDD. Faktor dalam biaya lisensi perangkat lunak (Windows, SQL Server), SSL dan dukungan teknis. Apakah Anda punya solusi bagus dengan harga murah untuk itu? Saat ini saya menggunakan Server Intellect (didukung oleh SoftLayer) untuk hosting. Apakah Anda merekomendasikan sesuatu yang lebih baik?

— Dennis Gorelik

2

Pembaruan Windows akan datang dengan pembaruan keamanan. Jika saya tidak menambal server saya, itu mungkin rentan terhadap serangan. Apa frekuensi pembaruan yang akan Anda rekomendasikan untuk server produksi Windows?

— Dennis Gorelik

15

Jawaban singkat: Ketika waktu henti atau risiko biayanya lebih banyak daripada biaya untuk memiliki ketersediaan tinggi.

Ini secara fundamental merupakan keputusan ekonomi. Sebagai contoh. $ 8k / bulan menyiratkan bahwa pemadaman 2 jam akan dikenakan biaya $ 22. Jika Anda dapat mengkonfigurasi sistem Anda sedemikian rupa sehingga Anda dapat beralih dari awal ke situs yang berfungsi penuh dalam 2 jam, maka ketersediaan tinggi hanya akan memberi Anda $ 22 fungsionalitas di atas itu.

Dengan kata lain, Anda dapat menghemat uang kecuali / sampai Anda memiliki 54 jam down-down yang tidak dapat dicegah dalam bulan tertentu.

— Slartibartfast
sumber

16

Anda harus mempertimbangkan risiko terhadap reputasi juga

— gbn

7

Biaya per jam downtime hampir pasti akan tergantung pada saat server turun. Transaksi sangat tidak mungkin tersebar secara merata dalam periode 24 jam. Lebih normal terjadi hanya dalam beberapa jam puncak, pada saat itu kerugiannya akan jauh lebih besar.

— John Gardeniers

Slartibartfast, saya memahami jawaban Anda dengan cara itu: pastikan waktu pemulihan setelah kegagalan katastropik masuk akal (beberapa jam), kehilangan data masuk akal (beberapa jam), dan izinkan diri saya memiliki jadwal henti singkat yang dijadwalkan dari waktu ke waktu (setidaknya untuk sekarang) . Itu berarti memiliki cadangan harian, cadangan parsial tambahan, dan server tersedia untuk mengembalikan semua konfigurasi itu. Apakah itu terdengar benar?

— Dennis Gorelik

Tanggapan: gbn: Setuju; Saya mencari penjelasan sederhana, tetapi reputasi bisa dengan mudah menjadi faktor penting. John Gardeniers: Tentu, tetapi jika situs tersebut hanya digunakan pada hari Minggu antara jam 11 pagi dan 1 siang, maka waktu henti yang dijadwalkan sebenarnya tidak menjadi masalah, sedangkan label harga $ 2k untuk pemadaman 2 jam yang tidak direncanakan right_then adalah. Pada saat itu Anda harus mencari tahu seberapa besar kemungkinan pemadaman dini (dengan biaya pendapatan $ 2k) terhadap biaya $ 600 / bulan tertentu untuk server addnl. Petunjuk: kecuali kegagalan acak selama periode kritis terjadi lebih sering dari 4 / tahun, itu tidak layak.

— Slartibartfast

Dennis Gorelik: Tentukan risiko yang ingin Anda lindungi, (mis. Kehilangan bisnis selama pemeliharaan, kehilangan server, kehilangan pusat data, akun / keamanan / pangkalan data) dan bertindak untuk melindungi mereka. Dalam hal ini Anda melindungi dari waktu henti karena pemeliharaan dan kegagalan yang tidak terduga (sejauh yang saya tahu). Apa yang Anda gambarkan harus melakukan trik, tetapi perlu diingat bahwa Anda tidak harus memiliki server selama Anda dapat yakin bahwa Anda dapat membeli dan mengaturnya dalam periode pemulihan.

— Slartibartfast

11

Stakeholder / kaum bisnis Anda (yang mungkin Anda!) Harus memutuskan

kehilangan pendapatan yang dapat diterima
konsekuensi kehilangan reputasi, kehormatan, dll
kehilangan data yang dapat diterima ( Tujuan titik pemulihan )
waktu henti yang dapat diterima ( Sasaran Waktu Pemulihan )

Kehilangan pendapatan mudah untuk diukur: sisanya tidak dapat dijawab di sini, maaf ...

— gbn
sumber

2

Saya pikir sebagian besar pengguna dapat menangani sedikit downtime yang dijadwalkan. Pertimbangkan bahwa ebay memiliki pembaruan mingguan pada malam Jumat, dan tawaran sekitar terkadang tidak berfungsi. Perbankan online bank saya (australia) telah menjadwalkan pemadaman berjam-jam setiap minggu. Twitter menjadi offline setiap saat. Heroku / EC2 turun selama beberapa hari baru-baru ini.

Saya akan tetap dalam perspektif itu, jika Anda benar-benar hanya berbicara 5 menit sebulan, Anda melakukan pekerjaan yang cukup baik sebagai sysadmin.

— Chris
sumber

1

Anda telah menyebutkan Google sebagai faktor dalam pengindeksan, tetapi mungkin juga layak mempertimbangkan dampak bahwa latensi / respons situs mungkin terhadap SEO. Ini kotak hitam dan sebagainya, sangat sulit untuk diukur - meskipun untuk apa nilainya, Matt Cutts menganggap itu adalah satu-persen . Saya akan lebih peduli tentang reputasi, seperti yang orang lain katakan.

1

Perlu diingat bahwa HA, seperti keamanan, bukan produk, melainkan sebuah proses.

Misalnya, replikasi basis data hanya akan membawa Anda ke titik di mana setiap mirror dari basis data akan dapat melanjutkan sendiri, tetapi Anda juga akan memerlukan strategi untuk sinkronisasi ulang setelah komponen yang gagal diganti.

Pertimbangkan sistem pemesanan sebagai contoh: pelanggan mengirimkan pesanan, dan selama pemrosesan, sistem fisik yang ia ajak bicara gagal setelah menyimpan informasi pesanan dalam salinan lokal dari basis data. Dengan tidak sabar, pelanggan menekan "kirim" lagi, dan diarahkan ke server lain, yang menerima pesanan. Jika database Anda disinkronkan ulang dengan hanya memutar ulang pernyataan INSERT yang hilang di sisi lain, maka pesanan akan digandakan, yang mungkin bukan yang Anda inginkan.

Seperti yang disarankan @Slartibartfast, itu semua bermuara pada keputusan ekonomi, namun saya sarankan Anda juga merencanakan beberapa tahun di masa depan di sini. Jika Anda berharap membutuhkan pengaturan HA yang tepat, maka sekarang adalah saat yang tepat untuk menyisihkan sumber daya untuk pekerjaan persiapan.

— Simon Richter
sumber

1

Sementara Anda memikirkan hal ini, saya pikir Anda mempertimbangkan untuk membuat halaman "paus gagal".

Ada banyak cara untuk melakukan ini tetapi kombinasi rute53 dan s3 bekerja dengan baik di situs kecil saya.

Saya mengatur domain dengan pemeriksaan kesehatan sehingga pada kegagalan DNS mengirim pengguna ke pengguna ke halaman html statis di s3; Biaya hampir tidak ada.

Dalam pengalaman saya memiliki situs Anda mengatakan "maaf ada yang rusak tetapi kami sedang mengusahakannya" membuat perbedaan bagi pengguna. Akun Twitter tempat Anda dapat berkomunikasi dengan pengguna bahkan lebih baik.

Ini perlu waktu lama untuk mengurangi "kehilangan reputasi" yang bisa menjadi dampak paling signifikan dari pemadaman.

lihat: https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ untuk panduan tentang pengaturannya.

Kegagalan sosial DynDns http://dyn.com/managed-dns/social-failover/ adalah sejenis hal yang serupa.

Anda dapat memutar sendiri dan melakukan pemeriksaan kesehatan, lalu skrip perubahan DNS, asalkan catatan DNS Anda memiliki TTL rendah dan Anda memiliki beberapa cara untuk memanipulasinya secara terprogram.

— Nath
sumber

Apakah pemeriksaan kesehatan ini harus dijalankan dari server yang sama dengan host DNS? Saya tidak bisa membayangkan cara membuat pembaruan DNS bersyarat.

— Dennis Gorelik

@ DennisGorelik tidak perlu tetapi catatan DNS Anda perlu TTL pendek dan apa pun yang dilakukan pemeriksaan kesehatan Anda harus dapat mengubah catatan dengan cepat. Memperbarui jawabannya dengan info lebih lanjut tentang cara mencapai ini.

— Nath

TTL pendek untuk DNS dalam kombinasi dengan ketergantungan pada pemeriksaan kesehatan dapat membuat sistem secara keseluruhan sedikit kurang stabil (dapat beralih bahkan jika server utama berfungsi dengan baik). Ini sebenarnya dapat membuat situasi lebih buruk bagi pengguna akhir, tidak lebih baik.

— Dennis Gorelik

TTL pendek sendiri seharusnya tidak menjadi masalah dengan penyedia DNS yang layak dan jika Anda menetapkan bilah yang cukup rendah pada pemeriksaan kesehatan Anda (yaitu Failover jika Tidak ada http 200s selama 10 menit) maka stabilitas bukanlah masalah. Atau Anda dapat melewati bagian pemeriksaan kesehatan dan melakukan perampingan manual. Ini akan berarti periode waktu yang lebih lama ketika pengguna Anda mendapatkan "waktu habis koneksi" dan kesalahan jelek lainnya tetapi tidak ada kemungkinan positif palsu.

— Nath

0

Sudahkah Anda mempertimbangkan untuk menggunakan sesuatu seperti EC2 yang akan membuat Anda skala secara fleksibel dan juga meniadakan kontra Anda? Ini pada akhirnya merupakan keputusan ekonomi apakah menggunakan EC2 layak atau tidak, tetapi paling tidak, opsi untuk dipertimbangkan.

— manku
sumber

-2

Untuk menghindari kehilangan data, Anda harus melihat konfigurasi Raid sebelum cluster. Anda juga harus mengkonfigurasi IP Failover yang dapat Anda alihkan dari satu server ke server lain jika terjadi bencana tanpa harus menunggu propagasi DNS.

— yqt
sumber

dari mana ini berasal? apa yang membuat Anda berpikir bahwa poster tersebut belum menggunakan RAID?

— Chopper3

Chopper3. Yang saya katakan adalah bahwa Raid akan menyelesaikan masalah kehilangan datanya.

— yqt

2

Bagaimana? jika satu disk mati pasti tetapi bagaimana jika controller-nya rusak

— Chopper3