100% waktu aktif untuk aplikasi web

Kami menerima "persyaratan" yang menarik dari klien hari ini.

Mereka ingin 100% uptime dengan failover di luar situs pada aplikasi web. Dari sudut pandang aplikasi web kami, ini bukan masalah. Itu dirancang untuk dapat memperluas berbagai server database, dll.

Namun, dari masalah jaringan saya sepertinya tidak tahu bagaimana membuatnya bekerja.

Singkatnya, aplikasi akan hidup di server dalam jaringan klien. Ini diakses oleh orang internal dan eksternal. Mereka ingin kita menyimpan salinan sistem di luar lokasi yang jika terjadi kegagalan serius di tempat mereka akan segera mengambil dan mengambil alih.

Sekarang kita tahu sama sekali tidak ada cara untuk menyelesaikannya untuk orang-orang internal (merpati pos?), Tetapi mereka ingin pengguna eksternal bahkan tidak menyadarinya.

Sejujurnya, saya tidak punya ide foggiest tentang bagaimana ini mungkin. Tampaknya jika mereka kehilangan konektivitas Internet maka kita harus melakukan perubahan DNS untuk meneruskan lalu lintas ke mesin eksternal ... Yang, tentu saja, membutuhkan waktu.

Ide ide?

MEMPERBARUI

Saya berdiskusi dengan klien hari ini dan mereka mengklarifikasi masalah ini.

Mereka terjebak oleh angka 100%, mengatakan aplikasi harus tetap aktif bahkan jika terjadi banjir. Namun, persyaratan itu hanya berlaku jika kami menyediakannya untuk mereka. Mereka mengatakan akan menangani persyaratan waktu aktif jika aplikasi sepenuhnya hidup di server mereka. Anda dapat menebak respons saya.

Berikut ini adalah bagan Wikipedia tentang pengejaran sembilan:

Yang menarik, hanya 3 dari 20 situs web teratas yang mampu mencapai mitos 5 nines atau 99,999% uptime pada 2007. Mereka adalah Yahoo, AOL, dan Comcast. Dalam 4 bulan pertama 2008, beberapa jejaring sosial paling populer , bahkan tidak mendekati itu.

Dari grafik, harus jelas betapa konyol mengejar pengejaran 100% adalah ...

Minta mereka untuk mendefinisikan 100% dan bagaimana hal itu akan diukur Selama periode apa. Mereka mungkin berarti hampir 100% yang mereka mampu. Beri mereka biaya.

Untuk menguraikan. Saya telah berdiskusi dengan klien selama bertahun-tahun dengan persyaratan yang dianggap konyol. Dalam semua kasus mereka sebenarnya hanya menggunakan bahasa yang tidak tepat.

Cukup sering mereka membingkai hal-hal dengan cara yang tampak absolut - seperti 100% tetapi pada kenyataannya pada investigasi yang lebih dalam mereka cukup masuk akal untuk melakukan analisis biaya / manfaat yang diperlukan ketika disajikan dengan penetapan biaya untuk risiko data mitigasi. Menanyakan kepada mereka bagaimana mereka akan mengukur ketersediaan adalah pertanyaan penting. Jika mereka tidak mengetahui hal ini maka Anda berada dalam posisi yang harus menyarankan kepada mereka bahwa ini perlu didefinisikan terlebih dahulu.

Saya akan meminta klien untuk menentukan apa yang akan terjadi dalam hal dampak / biaya bisnis jika situs turun dalam keadaan berikut:

• Pada jam tersibuk mereka selama x jam
• Setidaknya jam sibuk mereka selama x jam

Dan juga bagaimana mereka akan mengukur ini.

Dengan cara ini Anda dapat bekerja dengan mereka untuk menentukan level '100%' yang tepat. Saya menduga dengan mengajukan pertanyaan-pertanyaan semacam ini mereka akan dapat lebih menentukan prioritas persyaratan mereka yang lain. Misalnya mereka mungkin ingin membayar tingkat SLA tertentu dan kompromi fungsi lainnya untuk mencapai ini.

Klien Anda gila. Uptime 100% tidak mungkin tidak peduli berapa banyak uang yang Anda habiskan untuk itu. Polos dan sederhana - tidak mungkin. Lihatlah Google, Amazon, dll. Mereka memiliki jumlah uang yang hampir tak ada habisnya untuk dilemparkan ke infrastruktur mereka, namun mereka masih bisa mengalami downtime. Anda perlu menyampaikan pesan itu kepada mereka, dan jika mereka terus bersikeras bahwa mereka menawarkan tuntutan yang masuk akal. Jika mereka tidak menyadari bahwa beberapa jumlah downtime tidak bisa dihindari, maka parit 'em.

Yang mengatakan, Anda tampaknya memiliki mekanisme penskalaan / distribusi aplikasi itu sendiri. Bagian jaringan akan perlu melibatkan uplink yang berlebihan ke ISP yang berbeda, mendapatkan alokasi ASN dan IP, dan mendapatkan leher yang dalam di BGP dan gear routing nyata sehingga ruang alamat IP dapat bergerak di antara ISP jika perlu.

Ini, tentu saja, jawaban yang sangat singkat. Anda belum memiliki pengalaman dengan aplikasi yang memerlukan tingkat uptime ini, jadi Anda benar-benar perlu melibatkan seorang profesional jika Anda ingin mendapatkan mendekati mitos 100% uptime.

Yah, itu pasti yang menarik. Saya tidak yakin saya ingin mendapatkan kontrak uptime 100%, tetapi jika saya harus, saya pikir itu akan terlihat seperti ini:

Mulailah dengan IP publik pada penyeimbang beban yang sepenuhnya keluar dari jaringan dan buat setidaknya dua di antaranya sehingga yang satu bisa gagal ke yang lain. Sebuah program seperti Heatbeart dapat membantu dengan kegagalan otomatis dari mereka.

Varnish terutama dikenal sebagai solusi caching tetapi melakukan beberapa load balancing yang sangat baik juga. Mungkin itu akan menjadi pilihan yang baik untuk menangani keseimbangan beban. Hal ini dapat diatur agar memiliki 1 hingga n backend secara opsional dikelompokkan dalam direksi yang akan memuat keseimbangan baik secara acak atau round-robin. Pernis dapat dibuat cukup pintar untuk memeriksa kesehatan setiap ujung belakang dan menjatuhkan ujung yang tidak sehat keluar dari loop sampai kembali online. Backend tidak harus berada di jaringan yang sama.

Saya agak jatuh cinta dengan IP Elastis di Amazon EC2 hari ini, jadi saya mungkin akan membangun penyeimbang beban di EC2 di berbagai wilayah atau setidaknya di zona ketersediaan berbeda di kawasan yang sama. Itu akan memberi Anda pilihan untuk memutar secara manual (Tuhan melarang) memutar load balancer baru jika Anda harus dan memindahkan IP record A yang ada ke kotak baru.

Varnish tidak dapat mengakhiri SSL, jadi jika itu yang Anda khawatirkan, Anda mungkin ingin melihat sesuatu seperti Nginx.

Anda dapat memiliki sebagian besar backend Anda di jaringan klien Anda dan satu atau lebih di luar jaringan mereka. Saya percaya, tetapi saya tidak 100% yakin, bahwa Anda dapat memprioritaskan backend sehingga mesin klien Anda akan menerima prioritas sampai semuanya menjadi tidak sehat.

Di situlah saya akan mulai jika saya memiliki tugas ini dan tidak diragukan lagi memperbaikinya saat saya melanjutkan.

Namun, seperti yang dinyatakan oleh @ErikA, Internet dan selalu ada bagian jaringan yang berada di luar kendali Anda. Anda akan ingin memastikan bahwa hukum Anda hanya mengikat Anda dengan hal-hal yang berada di bawah kendali Anda.

Tidak masalah - kata-kata kontrak yang sedikit direvisi:

... menjamin waktu kerja 100% (dibulatkan ke nol tempat desimal).

Jika Facebook dan Amazon tidak bisa melakukannya, maka Anda tidak bisa. Sesederhana itu.

Untuk menambahkan jawaban oconnore dari Hacker News

Saya tidak mengerti apa masalahnya. Klien ingin Anda merencanakan bencana, dan mereka tidak berorientasi matematika, jadi meminta probabilitas 100% terdengar masuk akal. Insinyur, seperti yang cenderung dilakukan oleh para insinyur, ingat hari pertamanya tentang masalah & stat 101, tanpa mempertimbangkan bahwa klien mungkin tidak. Ketika mereka mengatakan ini, mereka tidak berpikir tentang musim dingin nuklir, mereka berpikir tentang Fred menumpahkan kopinya di server kantor, disk crash, atau ISP turun. Lebih lanjut, Anda dapat mencapai ini. Dengan server pemantauan mandiri yang berbeda secara geografis, Anda pada dasarnya tidak akan memiliki waktu henti. Dengan 3 server yang beroperasi pada keandalan (1) tiga 9 independen, dengan mode failover yang baik, waktu henti yang diharapkan adalah di bawah satu detik per tahun (2). Bahkan jika ini terjadi sekaligus, Anda masih berada dalam SLA yang wajar untuk koneksi web, dan oleh karena itu downtime praktis tidak ada. Klien masih harus berurusan dengan skenario kiamat, tetapi Godzilla dikecualikan, ia akan memiliki layanan yang "selalu" naik.

(1) Sebuah server di LA cukup independen dari server di Boston, tapi ya, saya mengerti bahwa ada beberapa persimpangan yang melibatkan perang nuklir, peretas Cina menabrak jaringan listrik, dll. Saya tidak berpikir klien Anda akan kecewa dengan ini.

(2) Kegagalan DNS dapat menambahkan beberapa detik. Anda masih dalam skenario di mana klien harus mencoba kembali permintaan setahun sekali, yang, sekali lagi, dalam SLA yang wajar, dan biasanya tidak dianggap dalam nada yang sama dengan "downtime". Dengan aplikasi yang secara otomatis mengalihkan ke simpul yang tersedia pada kegagalan, ini bisa menjadi tidak terlihat.

Anda diminta sesuatu yang mustahil.

Tinjau jawaban lain di sini, duduk bersama klien Anda, dan jelaskan MENGAPA tidak mungkin, dan ukur respons mereka.

Jika mereka masih bersikeras 100% uptime, dengan sopan beri tahu mereka bahwa itu tidak dapat dilakukan dan menolak kontrak. Anda tidak akan pernah memenuhi permintaan mereka, dan jika kontraknya tidak sepenuhnya menyedot Anda akan ditusuk dengan hukuman.

Harga sesuai, dan kemudian menetapkan dalam kontrak bahwa setiap downtime yang melewati SLA akan dikembalikan pada tingkat yang mereka bayar.

ISP di pekerjaan terakhir saya melakukan itu. Kami memiliki pilihan jalur DSL "biasa" dengan 99,9% waktu kerja untuk $ 40 / bulan, atau trio T1 terikat pada 99,99% waktu kerja untuk $ 1100 / bulan. Sering terjadi pemadaman 10+ jam per bulan, yang membawa waktu uptime mereka jauh di bawah $ 40 / bulan DSL, namun kami hanya dikembalikan sekitar $ 15 atau lebih, karena itulah tarif per jam * jam berakhir pada. Mereka keluar seperti bandit dari kesepakatan itu.

Jika Anda menagih $ 450.000 sebulan untuk uptime 100%, dan Anda hanya mencapai 99,999%, Anda harus mengembalikannya $ 324. Saya berani bertaruh biaya infrastruktur untuk mencapai 99,999% berada di sekitar $ 45.000 per bulan dengan asumsi colo terdistribusi penuh, beberapa uplink 1 tingkat, perangkat keras fancypants, dll.

Jika para profesional mempertanyakan apakah ketersediaan 99,999 persen adalah kemungkinan yang praktis atau layak secara finansial , maka ketersediaan 99,9999% bahkan lebih tidak mungkin atau praktis. Apalagi 100%.

Anda tidak akan memenuhi sasaran ketersediaan 100% untuk periode waktu yang lama. Anda mungkin lolos begitu saja selama seminggu atau satu tahun, tetapi kemudian sesuatu akan terjadi dan Anda akan bertanggung jawab. Kejatuhan dapat berkisar dari reputasi yang rusak (Anda berjanji, Anda tidak memberikan) untuk kebangkrutan dari denda kontrak.

Ada dua jenis orang yang meminta waktu aktif 100%:

1. Orang yang sama sekali tidak memiliki pengetahuan tentang komputer, sistem komputer, atau Internet. *
2. Orang-orang yang dengan sengaja membuat kesalahan diri mereka sendiri, baik untuk menguji kemampuan Anda untuk mengatakan TIDAK (Google "the Orange Juice Test"), atau mencoba untuk mendapatkan semacam leverage kontrak SLA untuk keluar dari membayar Anda nanti.

Saran saya, setelah menderita kedua jenis klien ini pada banyak kesempatan, adalah untuk tidak menerima klien ini. Biarkan mereka membuat orang lain menjadi gila.

* Orang yang sama ini mungkin tidak memiliki rasa malu untuk bertanya tentang perjalanan yang lebih cepat dari Cahaya, Gerakan Abadi, Cold Fusion, dll.

Saya akan berkomunikasi dengan klien untuk menentukan dengan mereka apa sebenarnya arti uptime 100%. Mungkin mereka tidak benar-benar melihat perbedaan antara 99% uptime dan 100% uptime. Bagi kebanyakan orang (mis. Bukan admin server) kedua angka itu sama.

100% uptime?

Inilah yang Anda butuhkan:

Beberapa, (& redundant) server DNS, menunjuk ke beberapa situs di seluruh dunia, dengan SLA yang tepat dengan masing-masing ISP.

Pastikan server DNS diatur dengan benar, dengan TTL dikenali secara efektif.

Ini mudah. Amazon EC2 SLA dengan jelas menyatakan:

"Persentase Uptime Tahunan" dihitung dengan mengurangi dari 100% persentase periode 5 menit selama Tahun Layanan di mana Amazon EC2 berada dalam keadaan "Wilayah Tidak Tersedia."

http://aws.amazon.com/ec2-sla/

Cukup tentukan 'uptime' sebagai relatif terhadap seluruh bundel layanan yang Anda dapat tetap beroperasi 100% dari waktu, dan Anda seharusnya tidak memiliki masalah.

Juga, ada baiknya menunjukkan bahwa seluruh poin dalam SLA adalah untuk menentukan apa kewajiban Anda dan apa yang terjadi jika Anda tidak dapat memenuhinya. Tidak masalah jika klien meminta 3 nines atau 5 nines atau sejuta nines - pertanyaannya adalah apa yang mereka dapatkan ketika / jika Anda tidak dapat mengirimkannya. Jawaban yang jelas adalah memberikan item baris untuk waktu aktif 100% pada harga 5x harga yang ingin Anda bebankan, dan kemudian mereka mendapatkan pengembalian dana 4x jika Anda melewatkan target itu. Anda mungkin mencetak gol!

Perubahan DNS hanya memakan waktu jika dikonfigurasi untuk mengambil waktu. Anda dapat mengatur TTL pada catatan menjadi satu detik - satu-satunya masalah Anda adalah memastikan bahwa Anda memberikan respons yang tepat waktu terhadap permintaan DNS, dan bahwa server DNS dapat mengatasi tingkat pertanyaan itu.

Inilah cara GTM bekerja di F5 Big IP - DNS TTL secara default diatur ke 30 detik dan jika salah satu anggota cluster perlu mengambil alih, DNS diperbarui dan IP baru segera diambil. Maksimal pemadaman 30 detik, tetapi itu adalah tepi kasus, rata-rata akan menjadi 15 detik.

Anda tahu ini tidak mungkin.

Tidak diragukan bahwa klien fokus melihat "100%", jadi yang terbaik yang dapat Anda lakukan adalah berjanji 100%, kecuali untuk [semua penyebab yang masuk akal yang bukan kesalahan Anda].

Meskipun saya ragu 100% adalah mungkin, Anda mungkin ingin mempertimbangkan Azure (atau sesuatu dengan SLA serupa) sebagai suatu kemungkinan. Apa yang terjadi:

Server Anda adalah mesin virtual. Jika ada masalah perangkat keras pada satu server, mesin virtual Anda dipindahkan ke mesin baru. Penyeimbang beban menangani pengalihan sehingga pelanggan tidak akan melihat waktu henti (meskipun saya tidak yakin bagaimana keadaan sesi Anda akan terpengaruh).

Yang mengatakan, bahkan dengan kegagalan ini, perbedaan antara 99,999 dan 100 berbatasan dengan kegilaan.

Anda harus memiliki kontrol penuh atas faktor-faktor berikut.
- Faktor manusia, baik internal maupun eksternal, baik kedengkian dan impotensi. Contohnya adalah seseorang mendorong sesuatu ke kode produksi yang menjatuhkan server. Lebih buruk lagi, bagaimana dengan sabotase?
- Masalah bisnis. Bagaimana jika penyedia Anda keluar dari bisnis atau lupa membayar tagihan listrik mereka, atau hanya memutuskan untuk berhenti mendukung infrastruktur Anda tanpa peringatan yang memadai?
- Alam. Bagaimana jika tornado yang tidak terkait secara bersamaan mengenai pusat data yang cukup untuk membanjiri kapasitas cadangan?
- Lingkungan yang sepenuhnya bebas bug. Apakah Anda yakin tidak ada kasus tepi dengan kontrol pihak ketiga atau sistem inti yang belum terwujud tetapi masih bisa melakukannya di masa depan?
- Bahkan jika Anda memiliki kontrol penuh atas faktor-faktor di atas, apakah Anda yakin perangkat lunak / orang yang memantau ini tidak akan memberi Anda negatif palsu ketika memeriksa apakah sistem Anda menyala?

Jujur 100% benar-benar gila tanpa setidaknya goyah dalam hal serangan peretasan. Taruhan terbaik Anda adalah melakukan apa yang dilakukan Google dan Amazon karena Anda memiliki solusi hosting terdistribusi geografis tempat Anda memiliki situs dan DB yang direplikasi di beberapa server di beberapa lokasi geografis. Ini akan menjamin itu dalam apa pun kecuali bencana besar seperti tulang punggung internet yang dipotong ke suatu wilayah (yang memang terjadi dari waktu ke waktu) atau sesuatu yang hampir apokaliptik.

Saya akan memasukkan klausa untuk kasus-kasus seperti itu (DDOS, pemotongan backbone internet, serangan teroris apokaliptik atau perang besar, dll).

Selain itu melihat ke Amazon S3 atau layanan cloud Rackspace. Pada dasarnya pengaturan cloud tidak hanya menawarkan redundansi di setiap lokasi tetapi juga skalabilitas dan geo-distribusi lalu lintas bersama dengan kemampuan untuk mengarahkan ulang di sekitar area geografis yang gagal. Padahal pengertian saya adalah bahwa geo-distribusi membutuhkan lebih banyak uang.

Saya hanya ingin menambahkan suara lain ke pesta " bisa (secara teoritis) dilakukan".

Saya tidak akan mengambil kontrak yang menetapkan ini tidak peduli berapa banyak mereka membayar saya, tetapi sebagai masalah penelitian, ia memiliki beberapa solusi yang agak menarik. Saya tidak cukup akrab dengan jaringan untuk menguraikan langkah-langkahnya, tetapi saya membayangkan kombinasi konfigurasi yang berhubungan dengan jaringan + kelistrikan kabel / perangkat keras, kegagalan perangkat lunak, mungkin, dalam beberapa konfigurasi atau pekerjaan lain untuk benar-benar melakukannya.

Hampir selalu ada satu titik kegagalan di suatu tempat dalam konfigurasi apa pun, tetapi jika Anda bekerja cukup keras, Anda dapat mendorong titik kegagalan itu menjadi sesuatu yang dapat diperbaiki "langsung" (mis. Root dns turun, tetapi nilainya masih di-cache di tempat lain sehingga Anda punya waktu untuk memperbaikinya).

Sekali lagi, tidak mengatakan itu layak .. Saya hanya tidak suka bagaimana tidak satu jawaban menjawab fakta bahwa itu bukan "jalan keluar" - itu bukan sesuatu yang mereka inginkan jika mereka memikirkannya.

Pikirkan kembali metodologi Anda mengukur ketersediaan kemudian bekerja dengan pelanggan Anda untuk menetapkan target yang berarti .

Jika Anda menjalankan situs web besar, uptime tidak berguna sama sekali. Jika Anda mengajukan pertanyaan selama 10 menit ketika pelanggan Anda sangat membutuhkannya (lalu lintas puncak), itu bisa lebih merusak bisnis daripada pemadaman selama satu jam pada pukul 3 pagi pada hari Minggu.

Terkadang perusahaan web besar mengukur ketersediaan, atau keandalan, menggunakan metrik berikut:

1. persentase kueri yang berhasil dijawab, tanpa kesalahan sisi server (HTTP 500s).
2. persentase kueri yang dijawab di bawah target latensi tertentu .
3. kueri yang hilang harus dihitung terhadap statistik Anda (lihat di bawah).

Ketersediaan tidak boleh diukur menggunakan probe sampel, yang dapat dilaporkan oleh entitas eksternal seperti pingdom dan pingability. Jangan hanya mengandalkan itu. Jika Anda ingin melakukannya dengan benar, setiap permintaan tunggal harus dihitung . Ukur ketersediaan Anda dengan melihat keberhasilan Anda yang sebenarnya dan dirasakan.

Cara paling efisien adalah mengumpulkan log atau statistik dari load-balancer Anda dan menghitung ketersediaan berdasarkan metrik di atas.

Persentase kueri yang dijatuhkan juga harus dihitung terhadap statistik Anda. Itu bisa dipertanggungjawabkan dalam ember yang sama dengan kesalahan sisi server. Jika ada masalah dengan jaringan atau dengan infrastruktur lain seperti DNS atau load balancers, Anda bisa menggunakan matematika sederhana untuk memperkirakan berapa banyak kueri yang hilang . Jika Anda mengharapkan pertanyaan X untuk hari itu dalam seminggu tetapi Anda mendapat X-1000, Anda mungkin menjatuhkan 1000 pertanyaan. Plot lalu lintas Anda ke grafik kueri per menit (atau detik). Jika kesenjangan muncul, Anda menjatuhkan kueri. Gunakan geometri dasar untuk mengukur area celah itu, yang memberi Anda jumlah total kueri yang dijatuhkan.

Diskusikan metodologi ini dengan pelanggan Anda dan jelaskan manfaatnya. Tetapkan garis dasar dengan mengukur ketersediaan mereka saat ini. Akan menjadi jelas bagi mereka bahwa 100% adalah target yang mustahil.

Kemudian Anda dapat menandatangani kontrak berdasarkan perbaikan pada baseline. Katakanlah, jika mereka saat ini mengalami 95% ketersediaan, Anda bisa berjanji untuk memperbaiki situasi sepuluh kali lipat dengan mencapai 98,5%.

Catatan: ada kelemahan cara mengukur ketersediaan ini. Pertama, mengumpulkan log, memproses dan membuat laporan sendiri mungkin tidak sepele, kecuali jika Anda menggunakan alat yang ada untuk melakukannya. Kedua, bug aplikasi dapat mengganggu ketersediaan Anda. Jika aplikasi berkualitas rendah, itu akan melayani lebih banyak kesalahan. Solusi untuk ini adalah dengan hanya mempertimbangkan 500-an yang dibuat oleh load-balancer daripada yang berasal dari aplikasi.

Hal-hal mungkin menjadi sedikit rumit dengan cara ini, tetapi ini satu langkah lebih dari sekadar mengukur waktu server Anda .

Sementara beberapa orang mencatat di sini, bahwa 100% itu gila atau tidak mungkin , mereka entah bagaimana melewatkan poin sebenarnya. Mereka berpendapat, bahwa alasan untuk ini adalah kenyataan bahwa bahkan perusahaan / layanan terbaik tidak dapat mencapainya.

Yah, ini jauh lebih sederhana dari itu. Secara matematis tidak mungkin .

Semuanya memiliki probabilitas. Mungkin ada gempa bumi simultan di semua lokasi di mana Anda menyimpan server Anda, menghancurkan semuanya. Agaknya itu adalah probabilitas yang sangat kecil, tetapi itu bukan 0. Semua penyedia layanan internet Anda dapat menghadapi serangan teroris / cyber secara simultan. Sekali lagi, sangat tidak mungkin, tetapi juga tidak nol. Apa pun yang Anda berikan, Anda bisa mendapatkan skenario probabilitas non-nol yang membawa seluruh layanan turun. Karena ini, waktu aktif Anda juga tidak dapat 100%.

Pergi ambil buku tentang kontrol kualitas pembuatan menggunakan sampling statistik. Sebuah diskusi umum dalam buku ini, konsep-konsep yang mana manajer akan terkena dalam kursus statistik umum di perguruan tinggi, menentukan biaya untuk pergi dari 1 pengecualian dalam seribu, ke 1 dalam sepuluh ribu ke 1 dalam satu juta ke 1 dalam satu miliar kenaikan secara eksponensial. Pada dasarnya kemampuan untuk mencapai 100% uptime akan membutuhkan biaya dana yang hampir tidak terbatas, seperti jumlah bahan bakar yang dibutuhkan untuk mendorong objek ke kecepatan cahaya.

Dari perspektif rekayasa kinerja saya akan menolak persyaratan karena tidak dapat diuji dan tidak masuk akal, bahwa ungkapan ini lebih merupakan keinginan daripada persyaratan yang sebenarnya. Dengan dependensi aplikasi yang ada di luar aplikasi apa pun untuk jaringan, resolusi nama, perutean, cacat yang dipropagasi dari komponen arsitektural yang mendasari atau alat pengembangan, menjadi mustahil secara praktis untuk meminta siapa pun menjamin uptime 100%.

Saya tidak berpikir pelanggan sebenarnya meminta 100% uptime, atau bahkan 99,999% uptime. Jika Anda melihat apa yang mereka gambarkan, mereka berbicara tentang mengambil di mana mereka tinggalkan jika sebuah meteor mengeluarkan pusat data di tempat mereka.

Jika persyaratannya adalah orang luar yang tidak menyadarinya, seberapa drastis hal itu? Apakah membuat permintaan Ajax coba lagi dan tunjukkan spinner selama 30 detik kepada pengguna akhir bisa diterima?

Itu adalah hal-hal yang dipedulikan pelanggan. Jika pelanggan benar-benar memikirkan SLA yang tepat, maka mereka akan cukup tahu untuk menyatakannya sebagai 99,99 atau 99,999.

2 sen saya. Saya bertanggung jawab untuk situs web yang sangat populer untuk perusahaan keberuntungan-5 yang akan mengeluarkan iklan untuk mangkuk super. Saya harus berurusan dengan lonjakan besar dalam lalu lintas dan cara saya menyelesaikannya adalah dengan menggunakan layanan seperti Akamai. Saya tidak bekerja untuk Akamai tetapi saya menemukan layanan mereka sangat bagus. Mereka memiliki sistem DNS mereka sendiri yang lebih pintar yang tahu dengan node / host tertentu baik di bawah beban berat atau sedang turun dan dapat merutekan lalu lintas yang sesuai.

Yang rapi tentang layanan mereka adalah bahwa saya tidak benar-benar harus melakukan sesuatu yang sangat rumit untuk mereplikasi konten di server di pusat data saya sendiri ke pusat data mereka. Selain itu, saya tahu dari bekerja dengan mereka, mereka menggunakan banyak server HTTP Apache.

Meskipun tidak 100% aktif, Anda dapat mempertimbangkan opsi seperti itu untuk menyebarkan konten di seluruh dunia. Ketika saya mengerti banyak hal, Akamai juga memiliki kemampuan untuk melokalkan lalu lintas yang berarti jika saya berada di Michigan, saya mendapatkan konten dari server Michigan / Chicago dan jika saya berada di California, saya seharusnya mendapatkan konten dari server yang berbasis di California.

Alih-alih failover off-site, jalankan aplikasi dari dua lokasi secara bersamaan, internal dan eksternal. Dan menyinkronkan dua basis data ... Kemudian jika internal turun, orang-orang internal masih akan dapat bekerja dan orang-orang eksternal masih dapat menggunakan aplikasi. Ketika internal kembali online, sinkronkan perubahan. Anda dapat memiliki dua entri DNS untuk satu nama domain atau bahkan router jaringan dengan round robin.

Untuk situs yang dihosting secara eksternal, waktu uptime terdekat Anda akan 100% menjadi hosting situs Anda di Google App Engine dan menggunakan datastore replikasi tinggi (HRD) , yang secara otomatis mereplikasi data Anda di setidaknya tiga pusat data secara real time. Demikian juga, server ujung-depan App Engine secara otomatis diskalakan / direplikasi untuk Anda.

Namun, bahkan dengan semua sumber daya Google dan platform paling canggih di dunia, jaminan uptime App Engine SLA hanya "99,95% dari waktu dalam bulan kalender apa pun."

Sederhana dan langsung: Anycast

http://en.wikipedia.org/wiki/Anycast

Inilah yang cloudflare, google, dan perusahaan besar lainnya gunakan untuk melakukan redundansi, latensi rendah, lintas benua, kegagalan / penyeimbangan.

Tetapi juga perlu diingat bahwa tidak mungkin memiliki uptime 100%, dan bahwa biaya untuk beralih dari 99,999% menjadi 99,9999% jauh lebih besar.