Надежность Erlang на 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.

Почему это? Нет общего состояния, плюс сложная модель восстановления после ошибок.

Если вы копнете немного глубже, в докторской диссертации, написанной Джо, первоначальным автором Erlang (который включает в себя тематическое исследование AXD301), вы читаете:

Одним из проектов, рассмотренных в этой главе, является Ericsson AXD301, высокопроизводительный и надежный коммутатор ATM .

Итак, пока сеть, частью которой был коммутатор, работала без простоев, автор может заявить "надежность на девять девяток" для AXD301 (это все, что он когда-либо говорил, избегая конкретики). Это не обязательно означает, что Erlang - единственная причина такой высокой надежности.

РЕДАКТИРОВАТЬ: Фактически, «20 лет» сами по себе кажутся неправильным толкованием. Джо упоминает цифру в 20 лет в той же статье, но на самом деле она не связана с цифрой надежности девять девять, которая потенциально была получена в результате гораздо более короткого исследования (как уже упоминалось другими).

В то время как другие рассмотрели конкретный случай, о котором вы спрашиваете, ваш вопрос, похоже, основан на неправильном понимании. То, как вы задали вопрос, заставляет меня поверить в то, что вы думаете, что есть ручной процесс для возобновления работы системы после ее сбоя или остановки для обслуживания.

В Erlang есть несколько функций, которые исключают человеческое рабочее время как источник простоя:

1. Перезагрузка горячего кода . В системе Erlang легко скомпилировать и загрузить заменяющий модуль для существующего. Эмулятор BEAM выполняет подкачку автоматически, ничего не останавливая. Несомненно, существует небольшой промежуток времени, в течение которого эта передача происходит, но это происходит автоматически в компьютерном времени, а не вручную в человеческом времени. Это позволяет сделать обновление с практически нулевым временем простоя. (У вас может быть простой, если в заменяющем модуле есть ошибка, приводящая к сбою системы, но именно поэтому вы проводите тестирование перед развертыванием в производственной среде.)

2. Супервайзеры . Библиотека OTP Erlang имеет встроенную структуру надзора, которая позволяет вам определять, как система должна реагировать на сбой модуля. Стандартным действием здесь является перезапуск неисправного модуля. Если предположить, что перезапущенный модуль не сразу снова выйдет из строя, общее время простоя, взимаемое с вашей системы, может составить несколько миллисекунд. Надежная система, которая почти никогда не выходит из строя, действительно может накапливать лишь долю секунды от общего времени простоя в течение многих лет работы.

3. Процессы . Они примерно соответствуют потокам на других языках, за исключением того, что они не разделяют состояние, кроме как через постоянные хранилища данных. Помимо этого, общение происходит посредством передачи сообщений. Поскольку процессы Erlang очень недороги (намного дешевле, чем потоки ОС), это способствует слабосвязанной конструкции, так что, если процесс умирает, только одна крошечная часть системы испытывает простой. Обычно супервизор перезапускает этот процесс, практически не влияя на остальную систему.

4. Асинхронная передача сообщений . Когда один процесс хочет что-то сказать другому, в языке Erlang есть первоклассный оператор, который позволяет ему это делать. Процесс отправки сообщения не должен ждать, пока получатель обработает сообщение, и ему не нужно координировать владение отправленными данными. Обо всем этом позаботится асинхронная функциональная природа системы передачи сообщений Erlang. Это помогает поддерживать высокое время безотказной работы, поскольку снижает влияние простоя одной части системы на другие части.

5. Кластеризация . Это следует из предыдущего пункта: механизм передачи сообщений Erlang прозрачно работает между машинами в сети, поэтому процессу отправки даже не нужно заботиться о том, чтобы получатель находился на отдельной машине. Это обеспечивает простой механизм для разделения рабочей нагрузки между множеством машин, каждая из которых может выйти из строя отдельно, без ущерба для общего времени безотказной работы системы.

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

Кронквист специально заявил, что это не является репрезентативным для всей истории AXD-301 или Erlang в целом, и что он недоволен тем, что Джо Армстронг продолжал цитировать это, что привело к завышенным ожиданиям надежности Erlang. Другие написали что пять девяток - более реальная цифра.

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

Насколько я понимаю, эта статистика рассчитывается для ВСЕХ систем AXD301 в производстве. Мы можем ожидать, что когда у AXD301 возникнет серьезная проблема, он будет отключен более чем на 0,631 секунды. В течение этого периода другой AXD301 будет поддерживать работу сети.

Однако, когда вы суммируете общее количество часов всех работающих AXD301, сделайте соотношение для одного отказавшего AXD301, вы обнаружите 99,999999%

Вот как я понимаю эту цифру.

Надеюсь на эту помощь.