Примеры расчета «коэффициента готовности» для комплектов сетевого оборудования

    image

    Теория и основные моменты по методики расчета «коэффициента готовности» были описаны мной ранее в этой статье.

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

    Зачем вообще нужно делать расчеты «коэффициента готовности» для разных случаев компоновки оборудования?

    У нас данные по расчету «коэффициента готовности» в итоговых результатах могут быть некорректны, слишком идеальны, завышены и занижены. А где же там закралась ошибка или все правильно посчитано, можно понять, лишь когда есть возможность увидеть все элементы системы вместе, их варианты использования и расположения.

    Пример «идеального» расчета «коэффициента готовности».

    Основные компоненты комплекта №1 сетевого оборудования:

    • Cisco ASR 9010 — 2 шт.;
    • Cisco ASR 9000v — 2 шт.;
    • щит распределительный питания «48В» ЩРЗ-10-2К – 2 шт.

    Комплектность оборудования Cisco ASR 9010:

    image

    Схема шкафа с установленным комплектом №1 выглядит вот так:

    image

    Расчет коэффициента готовности оборудования комплекта №1:

    image

    (*) – исходные данные по параметру MTBF являются оценочными, предоставленными по данным позициям оборудования производителя или их аналогам.

    The Cisco ASR 9000 Series Routers are designed to have high Mean Time Between Failures (MTBF) and low Mean Time To Resolve (MTTR) rates, thus providing a reliable platform that minimizes outages or downtime and maximizes availability. The MTBF is calculated based on the Ground Benign condition. The values may be adjusted based on the different router usage.

    Итоговые расчетные данные для комплекта №1:

    • вероятность отказа оборудования системы в течение года: 0,0008023;
    • MTBF оборудования системы (лет): 1246 (10918609 часов);
    • среднее время устранения неисправности (часов): 24;
    • коэффициент готовности оборудования системы (%): 99,99978;
    • среднее время простоя в год (часов): 0,019 (1,15 минут).

    Что же в данном расчете неправильно учтено?

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

    В идеальном расчете все элементы задублированы (что редко бывает по факту), предполагается, что ЗИП у нас под рукой, а работы можем проводить на живую на включенном рядом рабочем оборудовании без проблем.

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

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

    И еще давайте будем реалистами, добавим в расчет 60 минут в год для «Restart\Shutdown procedure». Загрузить новое шасси, настроить и запустить в штатный режим этого времени должно хватить с момента нажатия тумблера включения на корпусе. Для 60 минут простоя вероятность отказа за год — 0,04167. Это будет самая нижняя строчка в расчетах далее.

    Пример «реального» расчета «коэффициента готовности».

    Расчет коэффициента готовности оборудования комплекта №1 без дублирования:

    image

    Итоговые расчетные данные для комплекта №1 без дублирования:

    • вероятность отказа оборудования системы в течение года: 0,5001666;
    • MTBF оборудования системы (лет): 1,99 (17514 часов);
    • среднее время устранения неисправности (часов): 24;
    • коэффициент готовности оборудования системы (%): 99,86;
    • среднее время простоя в год (часов): 11,98 (719 минут).

    Разница между двумя выше выполненными примерами по расчетам огромна. И этот момент нужно всегда помнить и анализировать.

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

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

    Пример «стандартного» расчета «коэффициента готовности».

    Основные компоненты комплекта №2 сетевого оборудования:

    • Cisco ASR 9006 — 2 шт.;
    • Cisco ASR 9000v — 2 шт.;
    • щит распределительный питания «48В» ЩРЗ-48-5 – 2 шт.

    Комплектность оборудования Cisco ASR 9006:

    image

    Схема шкафа с установленным комплектом №2 выглядит вот так:

    image

    Расчет коэффициента готовности оборудования комплекта №2 с учетом не дублированности шасси и щитов электропитания:

    image

    Итоговые расчетные данные для комплекта №2:

    • вероятность отказа оборудования системы в течение года: 0,2167769;
    • MTBF оборудования системы (лет): 4,7 (40410 часов);
    • среднее время устранения неисправности (часов): 24;
    • коэффициент готовности оборудования системы (%): 99,94;
    • среднее время простоя в год (часов): 5,2 (311 минут).

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

    Например, при замене шасси у нас будет демонтирован весь комплект плат и адаптеров с этого шасси, а это может занять время и более 2-3 часов. А демонтировать элементы, когда рядом в стойке включенное оборудование – это большой риск для возникновения дополнительной нештатной ситуации.

    Для идеального варианта – два шкафа с оборудованием, в каждом по 2 шасси – одно рабочее, второе пустое для быстрой активации с переносом элементов из вышедшего из строя. Но это слишком идеальная ситуация.
    Поделиться публикацией
    Комментарии 17
      +1
      Что, наработка на отказ у распредщита и автомата меньше, чем у циски ASR? Вы сами в это верите?
        0
        Интересный вопрос. Смотря какой производитель.
        В таблице для расчетов приведены стандартные данные, ABB обычно выдает mtbf 15 лет, шнайдер 100 лет.

        Про щиток еще проще — плата там такая в поставке встречается, что часто бывает нужно допаивать контакты.
        image
        –1

        Какой то странный "стандартный" расчёт, который каждый раз выдаёт неправильный результат. И почему вы не показываете структуру схему? Ведь именно от неё и зависят ваши разные реальные случаи. А то вы говорите, что мол к.г. для лохов, неправильно считает, а сами только половину работы показываете.

          0
          У вас в тексте указан ASR9000v. Но в таблицах я его не увидел. Так задумано?

          (*) – исходные данные по параметру MTBF являются оценочными, предоставленными по данным позициям оборудования производителя или их аналогам.

          Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен. Фраза: «являются оценочными», к сожалению, на него в полной мере не отвечает. Хотелось бы увидеть выкладки (методику оценки, входные данные и пр.). А без этого трудно верить итоговым результатам.

          Не совсем, понятно, почему Вы решили ещё ввести «Restart\Shutdown procedure». Ведь точкой отчёта является уже готовая, работающая система. Проектирование, настройка, ввод в эксплуатацию явно выходят за рамки.
            0
            У вас в тексте указан ASR9000v. Но в таблицах я его не увидел. Так задумано?
            в таблицах это поз.13 и поз.12 в крайней табличке.

            Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен.
            Эти данные обычно запрашиваются напрямую у вендора на оборудование после процедур квотирования, оформления закупки и поставки и т.д. В открытом доступе их сейчас нет. В публикации приведены близкие к реальным параметрам данные.

            The Cisco ASR 9000 Series Routers are designed to have high Mean Time Between Failures (MTBF) and low Mean Time To Resolve (MTTR) rates, thus providing a reliable platform that minimizes outages or downtime and maximizes availability. The MTBF is calculated based on the Ground Benign condition. The values may be adjusted based on the different router usage.
            +1
            У меня всего два вопроса.
            1. При существующей стоимости ASR-9006, является ли критичной экономия на еще одном шкафу телекоммуникационном.
            2. Зачем вы на КДПВ сожгли колобка в пентаграмме?
              +1
              И два ответа.
              1. Подобный расчет делается при расчете количества ЗИПа при очень большом количестве оборудования, уровня Hetzner и прочих Akamai.
              В отдельно стоящей стойке с количеством цисок равным 2 — вероятность равна 33%.
              Или откажет только одна, или обе, или будет работать.
              2. На КПДВ изображен инженер-эксплуатационщик, которого поджаривают за простой, потому что проектанты прикрылись подобным расчетом, но в силу протекшего потолка/кондиционера/пожара/срабатывания пиропатрона/техуборщицы/бракованной партии/чегоугодно оно поломалось все и сразу, не смотря на MTBF.
                0
                А вот фиг ты все учтешь. Сколько ставить надежность потолка в автозале? А сколько у бачка у кондиционера? Сколько у инженера, который сервисы прописывает? Сколько у прошивки на железке?
                0
                1. Смотря какая скидка у поставщика при закупке. У меня был вариант монтажа в одном шкафу 9006 и 9006, 9006 и 9010. Две 9010 в один шкаф не ставили пока что никогда — в публикации отражен идеальный случай, но с монтажом будет сложно при таком шкафе даже. Два шкафа это еще квадрат площади в цод и игры с патчами — между шкафами без перегородки или под фальшполом…

                2. Это продакшин-колобок и он в теме.
                  0
                  1. Смотря какая скидка у поставщика при закупке.

                  Битый эксплуатационщик никогда не сложит яйца в одну… корзину, если она находится в том же здании. Никакая скидка не компенсирует форс-мажор.

                  2. Это продакшин-колобок и он в теме.

                  Как менеджер менеджера — я вас прекрасно понимаю.
                  Но если эксплуатационщиков долго бить и унижать — из них течет кровь.
                  Они тоже, внезапно, люди.
                0
                И ещё интересный момент — производитель грубо говоря берет все тривиальные компоненты электросхемы (транзисторы, кодеры и тд), загоняет в специальную прогу и считает в ней итоговую наработку на отказ. Для измерения надежности элементарных компонент есть возможности (f.e. Камеры искусственного старения). Но как учесть этот показатель для софта? Даётся ли какая-нибудь табличка по вероятности нахождения баг различного уровня? Думаю, вопрос риторический.
                  0
                  Таблички вероятности бага (публичной) нет, хотя внутренние исследования по этой теме проводили наверное многие из тех кто софт разрабатывает.

                  Конкретно по сетевому оборудованию и софту есть, например, такие данные:

                  источник, если не ошибаюсь, то метод получения этих цифр дан в книге High Availability Network Fundamentals (Cisco Press, 2001)
                    0

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


                    Но это же противоречит с концепцией постоянных апдейтов для той же кибербезопасности, например. Что делать?

                      0
                      Сиско тут пишет не о сборках, а скорее о ветках ПО, причём параллельно находящихся в продакшне (так получены данные, из которых выведены цифры MTBF).

                      Т.е. более старая актуальная ветка (например, IOS XE 3.6.x) более стабильна, чем более новая (IOS XE 3.9.x).
                      Это не значит, что сборка 3.6.3 более стабильна, чем 3.6.7. Очевидно, что в пределах одной ветки в самой последней сборке (ожидаемо) закрыто больше багов.
                        0

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

                        0
                        Однозначного ответа нет. С одной стороны, обновление — шанс нарваться на новый баг. С другой, оставаясь на старой стабильной ветке, в один прекрасный момент получить отказ устройства из-за уязвимости.
                        Если нет каких-то требований со стороны внешних регулирующих органов(организаций), зачастую обновляют софт на устройствах внутри периметра сети только при острой необходимости (появившийся баг, требования новой функциональности). Тут стабильность в приоритете.
                        С устройствами на внешнем периметре ситуация чуточку другая. В этом случае вопрос безопасности становится острее.
                    0
                    И ещё интересный момент — производитель грубо говоря берет все тривиальные компоненты электросхемы (транзисторы, кодеры и тд), загоняет в специальную прогу и считает в ней итоговую наработку на отказ.

                    Так обычно делается для систем, для которых очень трудно собрать реальную статистику отказов — например выпускаемые в единственном экземпляре. Расчетное значение обычно получается очень консервативным, поэтому данная методика не очень популярная.


                    Но как учесть этот показатель для софта? Даётся ли какая-нибудь табличка по вероятности нахождения баг различного уровня?

                    Считается, что баги в софте будут рано или поздно вылезаны, поэтому для софта вероятность отказов не будет постоянной во времени и как тут считать наработку на отказ?

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

                    Самое читаемое