Erlang'ın% 99,99999999 (dokuz dokuz) güvenilirliği

Erlang 99.9999999% bir kesintisiz çalışma yüzdesi üzerinden 20 yıl üretim sistemlerinde kullanılmıştır bildirilmiştir.

Matematiği şu şekilde yaptım:

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

Bu, sistemin 20 yıllık süre içinde yalnızca bir saniyeden daha az kesinti süresine sahip olduğu anlamına gelir. Bunun geçerliliğini sorgulamaya çalışmıyorum, bir sistemi (kasıtlı veya kazara) yalnızca 0.631 saniye için nasıl kapatabileceğimizi merak ediyorum. Büyük yazılım sistemine aşina olan biri bunu bize açıklayabilir mi? Teşekkür ederim.

Bir grup işlem birimi (veya makine) üzerinden bir hizmetin kesinti süresini nasıl hesaplayacağını bilen var mı?

Güvenilirlik rakamının, herhangi bir kısmının AXD301(söz konusu projenin) 20 yıldan fazla bir süredir kapatıldığı toplam süreyi ölçmesi beklenmiyordu . AXD301Sistem tarafından sağlanan hizmetin çevrimdışı olduğu bu 20 yıllık toplam süreyi temsil eder . İnce fark. Joe Armstrong'un burada dediği gibi :

AXD301, Dokuz dokuzlu güvenilirliğe ulaştı (evet, doğru okudunuz,% 99,9999999). Şunu bağlam içinde koyalım: 5 dokuzun iyi olduğu kabul edilir (5.2 dakika kesinti / yıl). 7 dokuz neredeyse ulaşılamaz ... ama 9 yaptık.

Bu neden? Paylaşılan durum yok, ayrıca gelişmiş bir hata kurtarma modeli.

Biraz daha derine inerseniz, Erlang'ın orijinal yazarı Joe'nun yazdığı doktora tezinde (bir vaka çalışmasını içeren AXD301) okursunuz:

Bu bölümde incelenen projelerden biri, yüksek performanslı, son derece güvenilir bir ATM anahtarı olan Ericsson AXD301'dir .

Dolayısıyla, anahtarın bir parçası olduğu ağ kesinti olmadan çalıştığı sürece, yazar "dokuz dokuzlu güvenilirlik" belirtebilir AXD301(tüm söylediği şey, ayrıntılardan kaçınarak). Bu, Erlang'ın bu kadar yüksek güvenilirliğin tek nedeni olduğu anlamına gelmez.

DÜZENLEME: Aslında, "20 yıl" kendisi bir yanlış yorumlama gibi görünüyor. Joe, aynı makalede 20 yıllık bir rakamdan bahsediyor, ancak bu aslında potansiyel olarak çok daha kısa bir çalışmadan çıkan dokuz dokuzlu güvenilirlik rakamıyla bağlantılı değil (diğerlerinin de bahsettiği gibi).

Diğerleri sorduğunuz özel durumu ele alırken, sorunuz bir yanlış anlamaya dayanıyor gibi görünüyor. Soruyu sorma şekliniz, sistem çöktükten veya bakım için kapatıldıktan sonra tekrar çalıştırılması için manuel bir işlem olduğunu düşündüğünüze inanmamı sağlıyor.

Erlang, insan çalışma süresini kesinti kaynağı olarak ortadan kaldıran çeşitli özelliklere sahiptir:

1. Sıcak kod yeniden yükleniyor . Bir Erlang sisteminde, mevcut bir modül için yedek bir modül derlemek ve yüklemek kolaydır. BEAM emülatörü, görünüşte hiçbir şeyi durdurmadan değişimi otomatik olarak yapar. Kuşkusuz bu transferin gerçekleştiği çok az bir zaman vardır, ancak insan zamanında manuel olarak değil, bilgisayar zamanında otomatik olarak gerçekleşir. Bu, temelde sıfır arıza süresiyle yükseltme yapmayı mümkün kılar . (Değiştirilen modülde sistemin çökmesine neden olan bir hata varsa kesinti yaşayabilirsiniz, ancak bu nedenle üretime dağıtmadan önce test edersiniz.)

2. Süpervizörler . Erlang'ın OTP kitaplığı, bir modül çöktüğünde sistemin nasıl tepki vermesi gerektiğini tanımlamanıza izin veren yerleşik bir denetim çerçevesine sahiptir. Buradaki standart eylem, başarısız olan modülü yeniden başlatmaktır. Yeniden başlatılan modülün hemen tekrar çökmeyeceğini varsayarsak, sisteminize yüklenen toplam kesinti süresi milisaniyelerle ilgili olabilir. Neredeyse hiç çökmeyen sağlam bir sistem, yıllar süren çalışma süresi boyunca toplam aksama süresinin yalnızca bir saniyesinin sadece bir kısmını biriktirebilir.

3. Süreçler . Bunlar, kalıcı veri depoları haricinde durumu paylaşmamaları dışında, kabaca diğer dillerdeki iş parçacıklarına karşılık gelir. Bunun dışında iletişim, mesaj geçişi yoluyla gerçekleşir. Erlang süreçleri çok ucuz olduğundan (işletim sistemi iş parçacığından çok daha ucuz) bu, gevşek bağlı bir tasarımı teşvik eder, böylece bir süreç ölürse, sistemin yalnızca küçük bir parçası kesinti yaşar. Tipik olarak, süpervizör sistemin geri kalanı üzerinde çok az etkisi olan veya hiç etkisi olmayan bu süreci yeniden başlatır.

4. Eşzamansız mesaj geçişi . Bir süreç başka bir şey söylemek istediğinde, Erlang dilinde bunu yapmasına izin veren birinci sınıf bir operatör vardır. Mesaj gönderme süreci, alıcının mesajı işlemesini beklemek zorunda değildir ve gönderilen verilerin sahipliğini koordine etmek zorunda değildir. Erlang'ın mesaj geçirme sisteminin eşzamansız işlevsel doğası tüm bunları halleder. Bu, yüksek çalışma sürelerinin korunmasına yardımcı olur çünkü bir sistemin bir bölümündeki kesinti süresinin diğer parçalar üzerinde yaratabileceği etkiyi azaltır.

5. Kümeleme . Bu, bir önceki noktadan izler: Erlang'ın mesaj aktarma mekanizması, bir ağdaki makineler arasında şeffaf bir şekilde çalışır, bu nedenle, bir gönderme işleminin, alıcının ayrı bir makinede olmasına dikkat etmesi bile gerekmez. Bu, bir iş yükünü birçok makineye bölmek için kolay bir mekanizma sağlar ve bunların her biri genel sistem çalışma süresine zarar vermeden ayrı ayrı kapatılabilir.

% 99,9999999 kullanılabilirlik rakamı, sık sık alıntılanan ancak temelde yanıltıcı bir istatistiktir. AXD-301 ekip üyelerinden biri olan Mats Cronqvist, San Francisco'daki 2010 Erlang Fabrikası konferansında bu kesin kullanılabilirlik istatistiğini tartışan bir sunum (video) (katıldığım) verdi. Ona göre, British Telecom tarafından AXD-301 kullanılarak "5 düğüm-yıllık" bir deneme süresi (Ocak'tan Eylül 2002'ye kadar inanıyorum) için talep edildi. Duruşmanın sonunda canlı trafik taşıyan 14 düğüm vardı.

Cronqvist, bunun tüm AXD-301 tarihini veya genel olarak Erlang'ı temsil etmediğini ve Joe Armstrong'un bundan alıntı yapmaya devam etmesinden memnun olmadığını ve bu da Erlang'ın güvenilirliğine dair aşırı beklentilere yol açtığını özellikle belirtti. Diğerleri , beş dokuzun daha gerçekçi bir rakam olduğunu yazdı .

Erlang'ın uzman kullanımının gerçekten çok yüksek kullanılabilirlikli sistemlere yol açabileceğine inanan, ancak sadece aldatmacayı azaltmak isteyen ateşli bir Erlang destekçisi ve geliştiricisi olduğumu belirtmek gerekir. Elbette, Cronqvist'in gerçekleri temsilinin doğru olduğunu ve aksini düşünmek için bir neden olmadığını varsayıyorum.

Bu istatistiklerden anladığım kadarıyla, üretimde TÜM AXD301 sistemleri üzerinden hesaplanıyor. Bir AXD301'in ciddi bir sorunu olduğunda 0,631 saniyeden daha uzun süre kapalı kalacağını bekleyebiliriz. Bu pediod sırasında, ağı çalışır durumda tutmak için diğer AXD301 devreye girecektir.

Ancak, çalışan tüm AXD301'in toplam saat sayısını topladığınızda, başarısız olan AXD301'in oranını yapın,% 99,999999

Bu rakamı böyle anlıyorum.

Umarım bu yardımcı olur.