Надійність Ерланга на 99,9999999% (дев'ять дев'ять)

Повідомлялося, що Erlang використовувався у виробничих системах протягом більше 20 років з відсотком тривалості експлуатації 99,9999999%.

Я зробив математику так:

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

Це означає, що система має лише менше однієї секунди простою протягом 20 років. Я не намагаюся оскаржувати справедливість цього, мені просто цікаво, як ми можемо вимкнути систему (навмисно чи випадково) всього за 0,631 секунди. Чи може хтось, хто знайомий з великою програмною системою, пояснити це нам? Дякую.

Хтось знає, як розрахувати час простою послуги над кластером процесорних блоків (або машин)?

Показник надійності не повинен був вимірювати загальний час, коли будь-яка частина AXD301(проект, про який йдеться) було закрито протягом більше 20 років. Він представляє загальний час за ці 20 років, коли послуга, що надається AXD301системою, коли-небудь була в режимі офлайн. Тонка різниця. Як говорить тут Джо Армстронг :

AXD301 досяг дев'ятидесяти надійності (так, ви правильно це прочитали, 99,9999999%). Давайте поставимо це в контексті: 5 дев'яток вважаються хорошими (5,2 хвилини простою / рік). 7 дев'яток майже недосяжних ... але ми зробили 9.

Чому це? Немає загального стану, а також складна модель відновлення помилок.

Якщо ви копаєте трохи глибше, в кандидатській дисертації, написаній Джо, оригінальним автором Ерланг (який включає тематичне дослідження AXD301), ви читаєте:

Один з проектів, що вивчаються в цій главі, - це високоефективний високонадійний перемикач банкоматів Ericsson AXD301 .

Отже, доки мережа, до складу якої входив комутатор, працює без простоїв, автор може констатувати "дев'ять дев'ять надійності" для AXD301(що було все, що він коли-небудь говорив, уникаючи специфіки). Це не обов'язково означає, що Erlang є єдиною причиною такої високої надійності.

EDIT: Насправді, "20 років" саме по собі здається неправильним трактуванням. Джо в цій же статті згадує цифру 20 років, але насправді це не пов'язано з цифрою надійності дев'ятидесяти, яка потенційно вийшла з набагато коротшого дослідження (як згадували інші).

Хоча інші вирішували конкретний випадок, про який ви питаєте, схоже, ваше питання ґрунтується на неправильному розумінні. Те, що ви задали це питання, змушує мене вважати, що ви думаєте, що існує ручний процес відновлення роботи системи після її виходу з ладу або зняття для обслуговування.

У Erlang є кілька функцій, які усувають робочий час людини як джерело простоїв:

1. Перезавантаження гарячого коду . У системі Erlang скласти та завантажити модуль заміни для вже існуючого легко. Емулятор BEAM виконує заміну автоматично, мабуть, нічого не зупиняючи. Безперечно, існує невеликий проміжок часу, протягом якого ця передача відбувається, але це відбувається автоматично в комп'ютерний час, а не вручну в людський час. Це дає можливість робити оновлення з фактично нульовим простоєм. (У вас може виникнути простої, якщо модуль заміни має помилку, яка збиває систему, але саме тому ви протестуєте перед тим, як розгорнутися до виробництва.)

2. Наглядові органи . У OTP-бібліотеці Ерланга вбудована система нагляду, яка дозволяє визначити, як система повинна реагувати, якщо модуль виходить з ладу. Стандартною дією тут є перезапуск несправного модуля. Якщо припустити, що перезапущений модуль не одразу завершиться збоєм, то загальний час простою, стягнутий із вашої системи, може скласти мілісекунд. Солідна система, яка навряд чи коли може вийти з ладу, може справді накопичити лише частину секунди загального простою протягом років роботи.

3. Процеси . Вони приблизно відповідають потокам інших мов, за винятком того, що вони не поділяють стан, за винятком постійних сховищ даних. Крім цього, спілкування відбувається за допомогою передачі повідомлення. Оскільки процеси Erlang дуже недорогі (набагато дешевші, ніж потоки ОС), це заохочує слабко пов'язану конструкцію, так що, якщо процес загине, лише одна крихітна частина системи зазнає простоїв. Як правило, керівник запускає цей процес, мало впливаючи на решту системи.

4. Асинхронне проходження повідомлення . Коли один процес хоче щось сказати іншому, є оператор першого класу на мові Erlang, який дозволяє це зробити. Процес надсилання повідомлень не повинен чекати, коли одержувач обробить повідомлення, і він не повинен координувати право власності на надсилані дані. Асинхронна функціональна природа системи передачі повідомлень Ерланга забезпечує все це. Це допомагає підтримувати високий час роботи, оскільки зменшує ефект, який простої в одній частині системи можуть мати на інші частини.

5. Кластеризація . Це випливає з попереднього пункту: механізм передачі повідомлень Ерланга працює прозоро між машинами в мережі, тому процес надсилання навіть не повинен піклуватися про те, щоб приймач знаходився на окремій машині. Це забезпечує простий механізм розподілу робочого навантаження між багатьма машинами, кожен з яких може знижуватися окремо, не завдаючи шкоди загальному режиму роботи системи.

Показник наявності 99,9999999% - це часто цитовані, але принципово оманливі статистичні дані. Матс Кронквіст, один із членів команди AXD-301, виступив з доповіддю (відео) (в якому я брав участь) на конференції Erlang Factory 2010 у Сан-Франциско, обговорюючи цю точну статистику щодо доступності. За його словами, Британський Телеком заявив, що протягом випробувального періоду (я вважаю, з січня по вересень 2002 р.) "5 вузлових років" з використанням AXD-301 було заявлено. До кінця випробування було 14 вузлів, які перевозили живий рух.

Кронквіст спеціально заявив, що це не є репрезентом всієї історії AXD-301, або Ерланг взагалі, і що він не радий, що Джо Армстронг продовжує цитувати це, що призводить до переоцінки очікувань на надійність Ерланга. Інші написали, що п’ять дев'яток - реалістичніша цифра.

Слід зазначити, що я є прихильним прихильником і розробником Erlang, який вважає, що експертне використання Erlang дійсно може призвести до дуже доступних систем, але просто хоче зменшити ажіотаж. Я, звичайно, припускаю, що представлення фактів Кронквіста є точним, і немає підстав вважати інше.

Я розумію ці статистичні дані, що вона обчислюється для ВСІХ систем AXD301 у виробництві. Ми можемо очікувати, що коли AXD301 має серйозну проблему, він буде знищений протягом більше 0,631 секунди. Під час цього періоду інші AXD301 візьмуть на себе, щоб підтримувати роботу мережі.

Однак, коли ви підсумовуєте загальну кількість годин усіх запущених AXD301, складіть коефіцієнт для одного, що вийшов з ладу AXD301, ви знаходите 99,999999%

Ось як я розумію цю цифру.

Сподіваюся, що це допоможе.