Надежность Эрланга 99,9999999% (9 девяток)

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

Erlang имеет несколько особенностей которые извлекают человеческое рабочее время как источник времени простоя:

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

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

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

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

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

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

пишут что пять девяток-это более реалистичная цифра.

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

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

однако, когда вы суммируете общее количество часов всех запущенных AXD301, сделайте соотношение для одного неудачного AXD301, вы найдете 99.999999%

вот как я это понимаю фигура.

надеюсь, что это поможет.