Niezawodność Erlanga na poziomie 99,9999999% (dziewięć dziewiątek)

Podano, że Erlang był używany w systemach produkcyjnych od ponad 20 lat z procentowym czasem sprawności 99,9999999%.

Zrobiłem matematykę w następujący sposób:

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

Oznacza to, że system ma tylko mniej niż jedną sekundę przestoju w okresie 20 lat. Nie próbuję kwestionować słuszności tego, jestem po prostu ciekawy, jak możemy zamknąć system (celowo lub przez przypadek) tylko na 0,631 sekundy. Czy ktoś, kto jest zaznajomiony z dużym systemem oprogramowania, mógłby nam to wyjaśnić? Dziękuję Ci.

Czy ktoś wie, jak obliczyć przestój usługi na klastrze jednostek przetwarzania (lub maszyn)?

Wskaźnik niezawodności nie miał mierzyć całkowitego czasu, w którym jakakolwiek część AXD301(omawianego projektu) była kiedykolwiek zamknięta przez ponad 20 lat. Przedstawia całkowity czas w ciągu tych 20 lat, przez który usługa świadczona przez AXD301system była kiedykolwiek offline. Subtelna różnica. Jak mówi tutaj Joe Armstrong :

AXD301 osiągnął DZIEWIĘĆ dziewiątek niezawodności (tak, dobrze czytasz, 99,9999999%). Umieśćmy to w kontekście: 5 dziewiątek uważa się za dobre (5,2 minuty przestoju / rok). 7 dziewiątek prawie nieosiągalne ... ale zrobiliśmy 9.

Dlaczego to? Brak stanu współdzielonego oraz wyrafinowany model odzyskiwania po błędzie.

Jeśli zagłębisz się nieco głębiej, w pracy doktorskiej napisanej przez Joe, pierwotnego autora Erlang (która zawiera studium przypadku AXD301), przeczytałeś:

Jednym z projektów analizowanych w tym rozdziale jest Ericsson AXD301, wysokowydajny, wysoce niezawodny przełącznik ATM .

Tak więc, o ile sieć, której częścią był przełącznik, działała bez przestojów, autor może określić „niezawodność dziewięciu dziewiątek” AXD301(co było wszystkim, co kiedykolwiek powiedział, unikając szczegółów). Niekoniecznie oznacza to, że Erlang jest jedyną przyczyną tak wysokiej niezawodności.

EDYCJA: W rzeczywistości samo „20 lat” wydaje się błędną interpretacją. Joe wspomina liczbę 20 lat w tym samym artykule, ale tak naprawdę nie jest ona powiązana z liczbą dziewięciu dziewiątek, która potencjalnie pochodzi ze znacznie krótszych badań (jak wspominali inni).

Podczas gdy inni zajęli się konkretnym przypadkiem, o który pytasz, Twoje pytanie wydaje się być oparte na niezrozumieniu. Sposób, w jaki zadałeś to pytanie, sprawia, że ​​sądzisz, że istnieje ręczny proces ponownego uruchomienia systemu po awarii lub wyłączeniu go w celu konserwacji.

Erlang ma kilka funkcji, które usuwają ludzki czas pracy jako źródło przestojów:

1. Ponowne ładowanie kodu na gorąco . W systemie Erlang łatwo jest skompilować i załadować moduł zastępczy dla już istniejącego. Emulator BEAM dokonuje zamiany automatycznie, bez widocznego zatrzymywania czegokolwiek. Jest niewątpliwie niewielka ilość czasu, w którym ten transfer ma miejsce, ale dzieje się to automatycznie w czasie komputera, a nie ręcznie w czasie ludzkim. Dzięki temu możliwe jest dokonywanie uaktualnień praktycznie bez przestojów. (Możesz mieć przestój, jeśli moduł zastępczy ma błąd, który powoduje awarię systemu, ale dlatego testujesz przed wdrożeniem do produkcji).

2. Przełożeni . Biblioteka OTP firmy Erlang ma wbudowaną strukturę nadzorczą, która pozwala zdefiniować, jak system powinien reagować w przypadku awarii modułu. Standardową czynnością tutaj jest ponowne uruchomienie uszkodzonego modułu. Zakładając, że ponownie uruchomiony moduł nie ulega natychmiastowej awarii, całkowity czas przestoju naliczany w systemie może być kwestią milisekund. Solidny system, który prawie nigdy nie ulega awarii, może w rzeczywistości skumulować tylko ułamek sekundy całkowitego przestoju na przestrzeni lat.

3. Procesy . Odpowiadają one z grubsza wątkom w innych językach, z wyjątkiem tego, że nie współużytkują stanu z wyjątkiem trwałych magazynów danych. Poza tym komunikacja odbywa się poprzez przekazywanie wiadomości. Ponieważ procesy Erlang są bardzo niedrogie (znacznie tańsze niż wątki systemu operacyjnego), zachęca to do luźno powiązanego projektu, tak że jeśli proces umiera, tylko jedna mała część systemu doświadcza przestoju. Zwykle przełożony ponownie uruchamia ten jeden proces, bez wpływu lub bez wpływu na resztę systemu.

4. Asynchroniczne przekazywanie wiadomości . Kiedy jeden proces chce coś powiedzieć drugiemu, w języku Erlang istnieje operator pierwszej klasy, który na to pozwala. Proces wysyłania wiadomości nie musi czekać na przetworzenie wiadomości przez odbiorcę i nie musi koordynować własności przesyłanych danych. Dba o to asynchroniczna funkcjonalność systemu przekazywania wiadomości Erlanga. Pomaga to w utrzymaniu wysokich przestojów, ponieważ zmniejsza wpływ, jaki przestój jednej części systemu może mieć na inne części.

5. Klastrowanie . Wynika to z poprzedniego punktu: mechanizm przekazywania wiadomości Erlanga działa w sposób transparentny między maszynami w sieci, więc proces wysyłania nie musi nawet zwracać uwagi na to, że odbiorca znajduje się na oddzielnym komputerze. Zapewnia to łatwy mechanizm podziału obciążenia na wiele maszyn, z których każda może zostać wyłączona osobno bez szkody dla ogólnego czasu pracy systemu.

Liczba dostępności na poziomie 99,9999999% jest często cytowaną, ale zasadniczo mylącą statystyką. Mats Cronqvist, jeden z członków zespołu AXD-301, przedstawił prezentację (wideo) (w której uczestniczyłem) na konferencji Erlang Factory w 2010 roku w San Francisco, omawiając tę ​​dokładną statystykę dostępności. Według niego, British Telecom zażądał tego na okres próbny (wydaje mi się, że od stycznia do września 2002) wynoszący „5 węzłów-lat” przy użyciu AXD-301. Do końca okresu próbnego było 14 węzłów obsługujących ruch na żywo.

Cronqvist wyraźnie stwierdził, że nie jest to reprezentatywne dla całej historii AXD-301 lub ogólnie Erlanga i że nie był zadowolony, że Joe Armstrong wciąż to cytował, co doprowadziło do przesadzonych oczekiwań co do niezawodności Erlanga. Inni napisali, że pięć dziewiątek to bardziej realistyczna liczba.

Należy powiedzieć, że jestem zagorzałym zwolennikiem i programistą Erlanga, który uważa, że ​​profesjonalne wykorzystanie Erlanga może rzeczywiście doprowadzić do bardzo wysokiej dostępności systemów, ale chce tylko zmniejszyć szum. Oczywiście zakładam, że przedstawienie faktów przez Cronqvist jest dokładne i nie mam powodu, by sądzić, że jest inaczej.

Rozumiem, że te statystyki są obliczane na WSZYSTKICH produkowanych systemach AXD301. Możemy się spodziewać, że gdy AXD301 ma poważny problem, będzie wyłączony przez ponad 0,631 sekundy. W tym okresie inne AXD301 przejmą kontrolę, aby sieć działała.

Jednak po zsumowaniu całkowitej liczby godzin wszystkich uruchomionych AXD301, określmy stosunek dla jednego z wadliwym AXD301, znajdziemy 99,9999999%

Tak rozumiem tę liczbę.

Mam nadzieję, że to pomoże.