Keandalan Erlang 99.9999999% (sembilan sembilan)

Erlang dilaporkan telah digunakan dalam sistem produksi selama lebih dari 20 tahun dengan persentase uptime 99.9999999%.

Saya melakukan matematika sebagai berikut:

20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s

Artinya, sistem hanya memiliki downtime kurang dari satu detik selama periode 20 tahun. Saya tidak mencoba menantang validitas ini, saya hanya ingin tahu tentang bagaimana kita dapat mematikan sistem (sengaja atau tidak sengaja) hanya dalam 0,631 detik. Adakah yang tahu tentang sistem perangkat lunak besar yang menjelaskan hal ini kepada kami? Terima kasih.

Apakah ada yang tahu cara menghitung waktu henti layanan melalui sekelompok unit pemrosesan (atau mesin)?

Angka keandalan tidak seharusnya mengukur total waktu setiap bagian dari AXD301(proyek yang dimaksud) pernah ditutup selama lebih dari 20 tahun. Ini mewakili total waktu selama 20 tahun itu layanan yang disediakan oleh AXD301sistem pernah offline. Perbedaan halus. Seperti yang dikatakan Joe Armstrong di sini :

AXD301 telah mencapai keandalan SEMBILAN sembilan (ya, Anda membacanya dengan benar, 99,9999999%). Mari kita letakkan ini dalam konteks: 5 sembilan dianggap baik (waktu henti 5,2 menit / tahun). 7 sembilan hampir tidak bisa diraih ... tapi kami berhasil 9.

Kenapa ini? Tidak ada status bersama, ditambah model pemulihan kesalahan yang canggih.

Jika Anda menggali lebih dalam, dalam tesis PhD yang ditulis oleh Joe, penulis asli Erlang (yang mencakup studi kasus AXD301), Anda membaca:

Salah satu proyek yang dipelajari dalam bab ini adalah Ericsson AXD301, saklar ATM berkinerja tinggi yang sangat andal .

Jadi, selama jaringan yang merupakan bagian dari sakelar itu berjalan tanpa waktu henti, penulis dapat menyatakan "sembilan sembilan keandalan" untuk AXD301(hanya itu yang dia katakan, menghindari spesifik). Ini tidak berarti Erlang adalah satu-satunya penyebab keandalan yang tinggi tersebut.

EDIT: Faktanya, "20 tahun" itu sendiri tampak seperti salah tafsir. Joe menyebutkan angka 20 tahun dalam artikel yang sama, tetapi itu tidak benar-benar terkait dengan angka reliabilitas sembilan-sembilan, yang berpotensi muncul dari studi yang jauh lebih pendek (seperti yang disebutkan orang lain).

Sementara yang lain telah membahas kasus spesifik yang Anda tanyakan, pertanyaan Anda tampaknya didasarkan pada kesalahpahaman. Cara Anda mengajukan pertanyaan membuat saya yakin Anda berpikir ada proses manual untuk menjalankan kembali sistem setelah macet atau dihapus untuk pemeliharaan.

Erlang memiliki beberapa fitur yang menghilangkan waktu kerja manusia sebagai sumber waktu henti:

1. Memuat ulang kode panas . Dalam sistem Erlang, mudah untuk mengkompilasi dan memuat modul pengganti untuk yang sudah ada. Emulator BEAM melakukan swap secara otomatis tanpa menghentikan apa pun. Tidak diragukan lagi ada sedikit waktu di mana transfer ini terjadi, tetapi itu terjadi secara otomatis dalam waktu komputer, bukan secara manual dalam waktu manusia. Hal ini memungkinkan untuk melakukan peningkatan dengan waktu henti nol pada dasarnya . (Anda bisa mengalami waktu henti jika modul pengganti memiliki bug yang membuat sistem mogok, tetapi itulah alasan Anda menguji sebelum menerapkan ke produksi.)

2. Supervisor . Pustaka OTP Erlang memiliki kerangka kerja pengawasan yang dibangun di dalamnya yang memungkinkan Anda menentukan bagaimana sistem harus bereaksi jika modul macet. Tindakan standar di sini adalah memulai ulang modul yang gagal. Dengan asumsi modul yang direstart tidak langsung mogok lagi, total waktu henti yang dibebankan pada sistem Anda mungkin dalam hitungan milidetik. Sistem solid yang hampir tidak pernah crash mungkin memang mengakumulasi hanya sepersekian detik dari total waktu henti selama bertahun-tahun waktu berjalan.

3. Proses . Ini kira-kira sesuai dengan utas dalam bahasa lain, kecuali bahwa mereka tidak berbagi status kecuali melalui penyimpanan data yang terus-menerus. Selain itu, komunikasi terjadi melalui penyampaian pesan. Karena proses Erlang sangat murah (jauh lebih murah daripada utas OS), ini mendorong desain yang digabungkan secara longgar, sehingga jika suatu proses mati, hanya satu bagian kecil dari sistem yang mengalami waktu henti. Biasanya, supervisor memulai kembali satu proses itu, dengan sedikit atau tidak ada dampak pada sisa sistem.

4. Pengiriman pesan tidak sinkron . Ketika satu proses ingin menceritakan sesuatu yang lain, ada operator kelas satu dalam bahasa Erlang yang memungkinkannya melakukan itu. Proses pengiriman pesan tidak harus menunggu penerima untuk memproses pesan tersebut, dan tidak harus mengkoordinasikan kepemilikan data yang dikirim. Sifat fungsional asynchronous dari sistem penyampaian pesan Erlang menangani semua itu. Ini membantu mempertahankan waktu kerja yang tinggi karena mengurangi efek waktu henti di satu bagian sistem di bagian lain.

5. Pengelompokan . Ini mengikuti dari poin sebelumnya: Mekanisme penyaluran pesan Erlang bekerja secara transparan antara mesin di jaringan, sehingga proses pengiriman bahkan tidak harus memperhatikan bahwa penerima berada di mesin terpisah. Ini menyediakan mekanisme yang mudah untuk membagi beban kerja di antara banyak mesin, yang masing-masing dapat turun secara terpisah tanpa mengganggu waktu kerja sistem secara keseluruhan.

Angka ketersediaan 99,9999999% adalah statistik yang sering dikutip tetapi pada dasarnya menyesatkan. Mats Cronqvist, salah satu anggota tim AXD-301, memberikan presentasi (video) (yang saya hadiri) di konferensi Erlang Factory 2010 di San Francisco, membahas statistik ketersediaan yang tepat ini. Menurut dia, itu diklaim oleh British Telecom untuk masa percobaan (saya percaya dari Januari hingga September 2002) dari "5 node-tahun" menggunakan AXD-301. Ada 14 node yang membawa lalu lintas langsung pada akhir percobaan.

Cronqvist secara khusus menyatakan bahwa ini tidak mewakili seluruh sejarah AXD-301, atau Erlang pada umumnya, dan bahwa dia tidak senang bahwa Joe Armstrong terus mengutip ini, yang menyebabkan ekspektasi berlebihan akan keandalan Erlang. Yang lain menulis bahwa lima sembilan adalah angka yang lebih realistis.

Harus dinyatakan bahwa saya adalah pendukung dan pengembang Erlang yang gigih, yang percaya bahwa penggunaan ahli Erlang memang dapat menghasilkan sistem yang sangat tersedia, tetapi hanya ingin mengurangi sensasi. Saya tentu saja berasumsi bahwa representasi fakta Cronqvist akurat, dan tidak punya alasan untuk percaya sebaliknya.

Pemahaman saya tentang statistik tersebut adalah bahwa ini dihitung melalui SEMUA sistem AXD301 dalam produksi. Kami dapat mengharapkan bahwa ketika AXD301 memiliki masalah yang parah, itu akan turun lebih dari 0,631 detik. Selama pediod ini, AXD301 lain akan mengambil alih agar jaringan tetap beroperasi.

Namun, ketika Anda menjumlahkan jumlah jam semua menjalankan AXD301, membuat rasio untuk salah satu AXD301 yang gagal, Anda menemukan 99,999999%

Begitulah cara saya memahami angka ini.

Semoga bantuan ini.