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

    image

    Задача: в Техническом Задании на комплексную IT-систему был пункт – «выполнить расчет коэффициента готовности системы».

    Решение: использовать материалы из ГОСТ, запросить дополнительные данные у вендоров по элементам оборудования и использовать несложную математику для выполнения итогового расчета.

    Нормативные ссылки:

    ГОСТ Р 27.002-2009 («Надежность в технике (ССНТ). Термины и определения»)

    ГОСТ Р 27.003-2011 Надежность в технике (ССНТ). Управление надежностью. Руководство по заданию технических требований к надежности

    ГОСТ 27.002-89 Надежность в технике (ССНТ). Основные понятия. Термины и определения

    Согласно ГОСТ Р 27.002-2009 («Надежность в технике (ССНТ). Термины и определения») коэффициент готовности (в области надежности в технике) — это вероятность того, что изделие в данный момент времени находится в работоспособном состоянии, определенная в соответствии с проектом при заданных условиях функционирования и технического обслуживания.

    Таким образом, готовность отражает способность системы непрерывно выполнять свои функции.

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

    Коэффициент готовности (K) определяется по формуле:

    K = MTBF/(MTBF+MTTR),

    где:
    — MTBF (Mean Time Between Failure) — среднее время наработки на отказ (средняя наработка между отказами);
    — MTTR (Mean Time To Repair) — среднее время восстановления работоспособности (среднее время до восстановления).

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

    Итак, у нас есть определенная IT-система (сервера стоечного исполнения, блейд-сервера, система хранения данных).

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

    Отказоустойчивость функционирования внутренних компонентов IT-системы достигается применением следующих технологий:

    • резервирование блоков питания серверного оборудования, систем хранения данных;
    • резервирование сетевых адаптеров серверов;
    • резервирование оптических адаптеров серверов;
    • резервирование линий кабельных соединений коммутации серверов и сети передачи данных и сети хранения данных;
    • дублирование модулей блэйд-шасси: блоки питания, модули управления, вентиляторы, модули коммутации;
    • размещение информации на дисковых системах хранения данных с применением отказоустойчивых групп дисков (RAID).

    В итоге, все основные компоненты оборудования IT-системы – сервера, блоки питания, дисковые накопители, сетевые адаптеры, коммутаторы — имеют резервирование с возможностью горячей замены.

    Электропитание оборудования IT-системы осуществляется от двух независимых источников. Подключение оборудования IT-системы к внешним сетям передачи данных и сетям хранения данных также дублируется.

    Все подсистемы IT-системы имеют резервирование, поэтому при отказе любого элемента оборудование IT-системы в целом останется в работоспособном состоянии. Более того, замена отказавшего элемента возможна без остановки оборудования IT-системы.

    Вероятность (P) выхода одного компонента из строя в течение одного года составляет:
    P = 1/MTBF.

    Отказ дублированного компонента приведет к отказу оборудования только при условии, что компонент-дублер тоже выйдет из строя в течение времени, необходимого для «горячей» замены компонента, отказавшего первым. Если гарантированное время замены компонента составляет 24 часа (1/365 года) (что соответствует сложившейся практике обслуживания серверного оборудования), то вероятность такого события в течение года:
    image

    Вычислив вероятность отказа всех N компонентов оборудования IT-системы, можно рассчитать вероятность отказа оборудования IT-системы в течение одного года путем суммирования каждой вероятности отказа:
    image

    Так как отказы компонентов обычно распределены во времени равномерно, то, зная вероятность отказа оборудования IT-системы в течение года, можно определить время его наработки на отказ:
    MTBFs = 1/Ps.

    Коэффициент готовности оборудования IT-системы будет равен:
    Kit = MTBFs/(MTBFs+MTTR).

    Выполним расчет коэффициента готовности оборудования IT-системы из 26 компонентов (каждый из компонентов имеет несколько элементов).

    Основная проблема в таблице ниже – актуальные данные по параметру MTBF для каждого компонента. Эти данные очень неохотно предоставляют вендоры. Часто приходится вступать в переписку с представителями вендоров для просьбы предоставления и уточнения этих данных.

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

    image
    image
    image
    image

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

    В итоге расчетные данные по оборудованию нашей системы:

    • вероятность отказа оборудования системы в течение года: 0,0966;
    • MTBF оборудования системы (лет): 10,35 (90666 часов);
    • среднее время устранения неисправности (часов): 24;
    • коэффициент готовности оборудования системы (%): 99,97;
    • среднее время простоя в год (часов):2,61 (156 минут).

    По итоговым строчкам из таблицы можно увидеть, что у нас есть не дублированные элементы СХД и этот момент очень сильно влияет на расчетные данные. По возможности нужно дублировать эти элементы (как рекомендация) или использовать другую компоновку СХД.

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

    По факту данные таблицы с расчетами заносятся в нужный раздел проектной документации и выдаются Заказчику.

    Интересно выполнить такой расчет для комплекта сетевого оборудования (с максимальным разбиением на элементы до SFP-модуля и блоков питания) и сравнить с разными вендорами данные итоговые.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 4
      0
      Интересная попытка расчета, но не убедительная.
      Есть ряд вопросов (отчасти риторических) на примере первой таблицы для серверов DL980 (я так понял у вас их два):
      1. Вероятно, один сервер резервирует второй, иначе как объяснить, что вы замесили два серверных шасси (строка № 1 в таблице) в формулу дублирования Md. Отсюда первый вопрос, если догадка про резервирование серверов верна, почему вы не посчитали вероятность выхода из строя (Р) сначала для одного сервера (учитывая все его компоненты), а потом не подставили эту Р в формулу Md? Ибо сейчас кажется, что у вас каша из компонентов для двух серверов.
      2. У вас два набора по четыре процессора (строка № 2 в таблице). Это значит по четыре проца на шасси, или все же 8 процов на шасси? В любом случае, откуда появилось дублирование у процессоров? Ведь выход из строя хотя бы одного процессора приводит к циклическому перезапуску сервера, что приводит к простою сервера. В пределах одного сервера нет резервирования по процессорам, а вероятность выхода из строя всего сервера тем выше, чем больше в нем процессоров.
      3. Примерно тоже самое и с памятью (№ 3). Дублирования память в пределах сервера может быть только если используется зеркалирование памяти, но DL980 таким фокусам не обучен. Хоть потеря планки памяти и приведет только к перезагрузке сервера, а не полной его потере (как в случае с процессором). Тем не менее, надежность сервера тем ниже, чем больше планок памяти. К тому же в какой-то момент (после потери одной, двух или больше планок) перестанет запускаться целевая задача (база данных или виртуалки), так как ей перестанет хватать ресурсов (оперативки).
      4. Жесткие диски (№ 5). Всего шесть дисков на сервер? При этом 2 дублируются? У вас массив уровня RAID 5? Иначе не понятно, как такие цифры получились. Сюда же вопрос про RAID-контроллер, он у вас есть? Если есть, и он навернулся, потеряли сервер.
      5. Сетевые карты (№ 7). У вас интерфейсы в группе (bonding, teaming, прочее), раз вы посчитали дублирование?
      6. Еще вы забыли блоки вентиляторов. Если вы правильно собрали сервер, их суммарной эффективности хватает, чтобы сервер не перегрелся после выхода из строя первого же вентилятора. Но опять же, 2-3 вентилятора засбоят, и ваш сервер перестанет запускаться.
      7. Заявление о том, что «отказы компонентов обычно распределены во времени равномерно», особенно из расчета эффективного времени работы системы 10 лет, мягко говоря ошибочно.
      8. Если вы под IT-системой подразумеваете аппаратно-программный комплекс в целом, а не только аппаратную платформу под какие-либо задачи, то не стоит забывать про вероятность ошибок в ОС и прочем софте, что тоже приведет к простою системы. Именно поэтому Uptime Institute еще в 2009 году убрала из требований к уровням Teir показатели availability и annual downtime, соответственно.
      9. А что случится, если в расчет ввести электрические подстанции, ИБП, кондиционирование и провайдера?

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

        Данный расчет делался для соответствия пункта ТЗ и согласования с Заказчиком проектной документации.
        В расчете, как Вы справедливо заметили, не затрагиваются многие нюансы технической (физической и логической) архитектуры системы.
        Но по требованию Заказчика в данном случае хватало списка оборудования системы из спецификации.

        Вероятно, один сервер резервирует второй, иначе как объяснить, что вы замесили два серверных шасси (строка № 1 в таблице) в формулу дублирования Md. Отсюда первый вопрос, если догадка про резервирование серверов верна, почему вы не посчитали вероятность выхода из строя (Р) сначала для одного сервера (учитывая все его компоненты), а потом не подставили эту Р в формулу Md? Ибо сейчас кажется, что у вас каша из компонентов для двух серверов.

        На самом деле этих серверов четыре — 2 на основной площадке и 2 на резервной, данный расчет для одной площадки.

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

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

        Вентиляторы как и прочее встроенное оборудование должны обслуживаться и проходить тестирование. Так же в ЗИП нужно иметь несколько их.

        Заявление о том, что «отказы компонентов обычно распределены во времени равномерно», особенно из расчета эффективного времени работы системы 10 лет, мягко говоря ошибочно.

        7 лет работы 4 серверов 365*24*7 — 4 HDD и 2 планки памяти, ежегодное обслуживание. Тут смотря какой вендор, обслуживание и окружающая среда.

        Если вы под IT-системой подразумеваете аппаратно-программный комплекс в целом, а не только аппаратную платформу под какие-либо задачи, то не стоит забывать про вероятность ошибок в ОС и прочем софте, что тоже приведет к простою системы. Именно поэтому Uptime Institute еще в 2009 году убрала из требований к уровням Teir показатели availability и annual downtime, соответственно.
        В данном случае ОС и софт уже немного в другой лиге у нас по ГОСТ.

        А что случится, если в расчет ввести электрические подстанции, ИБП, кондиционирование и провайдера?
        Получить данные от представителя услуг (электрокомпании\провайдера) в нужном для нас формате не получится. Тут только можем добавить какое устройство стоит у провайдера в нашу сторону, например. И то это обычно можно сделать только физическим путем наглядно.
        И данные по этому устройству добавить в таблицу. По ИБП и АКБ проще — данные есть у вендоров.

        Поймите правильно, я не пытаюсь вас подловить или завалить вопросами, просто сам пытался (не раз) произвести такие расчеты и ни разу не довел их до конца.

        Расчеты и данные тут очень «абстрактны» — так как их можно корректировать в нужную сторону.
        По факту нужно делать матрицу из коэффициентов готовности по оборудованию с дублирующими элементами, внешнему оборудованию и питанию, дополнительным элементам. Чем больше компонентов будет в расчете, тем более точен он может быть по факту. Но тем меньше по времени работы будет итог.

        Вендоры могли бы изначально в своих «конфигураторах оборудования» предоставлять точные данные по каждому элементу и общие итоговые данные по сборке\комплекту.
        Но так как обычно в системах «сборная солянка» из оборудования и элементов — это не делается кем то снаружи, может только понимающий все элементы систем сотрудник выполнить расчет.
          0
          Сначала хотел описать идеальную схему, по которой нужно производить расчеты, но опять пришел к тому, что абсолютно теряется любое понимание какие формулы для этого подойдут, ибо схема зависимостей элементов сервера очень сложна. Я даже не готов описать в формулах (ну я и не математик, правда), например, разницу между надежностью RAID6 и RAID10 на шести дисках и одним диском в горячем резерве.

          На чем я настаиваю, так это на том, что отказы не равномерны по времени. Не забываем про:
          1) Брак. Зачастую по одной закупке приходят компоненты (жесткие диски, планки памяти и прочие расходники) из одной партии. И вся партия может полечь в первые же месяцы использования.
          2) Износ. Все, что имеет подвижные элементы со временен начинает хуже работать. Если вы, конечно, в рамках ТО регулярно не заменяете смазку на осях вентиляторов, и еще чего-нибудь. Но ТО это простой оборудования, а значит понижение доступности, это тоже нужно учитывать в формулах.
          3) Батареи. У RAID-контроллеров, у ИБП. Используете кэш на запись, но прозевали, когда сдохла батарея RAID-контроллера, получите потерю данных при непредвиденном отключении сервера. Хотя формально, контроллер не выходил из строя, данные потеряны, пока они восстанавливаются, сервер не доступен. 3-4 года для батарей ИБП, и он (ИБП) превращается просто в большой горячий сетевой фильтр.
          4) Всякого рода смазки. Выгорание заводской термопасты, например, такое бывает на долго живущих серверах.
          5) Накопление ошибок. В дисках, например. Идеально одинаковые диски с одинаковым MTTF проживут разное время в одиноком сервере или в сервере, набитом дисками, в стойке где таких серверов еще десяток. Вибрация сделает свое.
          Ну вы поняли.

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

          Не могли бы и не будут, об этом писал не один крупный производитель серверного оборудования (достаточно поискать по их форумам). Любой показатель MTTF – это чисто статистика, замещенная на ожидании. Это сферический, а не «точный» показатель, в реальности вмешиваются куча факторов, о которых я выше написал, и еще всякие не упомянутые. Поэтому одни (вендоры) боятся такие цифры обнародовать, другие (Uptime Institute) исключают показатели надежности из рассмотрения реальных систем, третьи (Google) пишет статьи/исследования о том, как все на самом деле с надежностью на примере жестких дисков.

          И как здорово, что Заказчик даже не запаривается всем этим и ему достаточно хоть каких-то расчетов, которые он, вероятно, даже перепроверять не будет.
            0
            На чем я настаиваю, так это на том, что отказы не равномерны по времени. Не забываем про:

            Вы неправильно настаиваете. Расчеты надежности на MTBF берут за основу модель отказов "ванны" и выделяют из нее область постоянной вероятности отказов. Есть еще "детская смертность" слева и износ справа, — для этих областей расчет надежности никто не делает.


            Таким образом полученные с помощью расчетов цифры имеют смысл только в при таких условиях (по вашим же пунктам):
            1) Прошел период детской смертности — т.е. исключены возможные браки в производстве. В случае критически важных систем это достигается "burn-in" тестами. В обычном случае — через определенное время эксплуатации.
            2) 3) 4) Все изнашивающиеся элементы — вентиляторы, батареи, смазки, жесткие диски периодически проходят ТО и заменяются согласно регламенту производителя до того, как они входят в фазу "износа"


            И только в случае если все эти условия выполнены, можно считать, что вероятность отказов равномерна во времени и можно производить расчет MTBF.


            Не могли бы и не будут, об этом писал не один крупный производитель серверного оборудования (достаточно поискать по их форумам). Любой показатель MTTF – это чисто статистика, замещенная на ожидании. Это сферический, а не «точный» показатель, в реальности вмешиваются куча факторов, о которых я выше написал, и еще всякие не упомянутые. Поэтому одни (вендоры) боятся такие цифры обнародовать, другие (Uptime Institute) исключают показатели надежности из рассмотрения реальных систем, третьи (Google) пишет статьи/исследования о том, как все на самом деле с надежностью на примере жестких дисков.

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


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

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

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