Резервирование вычислительных и телекоммуникационных компонентов

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

Результат проверки относится именно к проектным мерам резервирования. Он подтверждает, что перечисленные механизмы предусмотрены документацией. Фактическая эксплуатационная надёжность системы, время переключения на резерв, успешность восстановления и численные показатели MTBF/MTTR этим результатом не устанавливаются.

Состав проектных мер отказоустойчивости

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

Профессиональный смысл такой проверки состоит в сопоставлении нескольких способов обеспечения отказоустойчивости. Дублирование создаёт резерв для основных узлов и носителей. Диагностика относится к выявлению состояния и неисправностей. ЗИП обеспечивает предусмотренный проектом комплект запасных частей и принадлежностей. Структурное резервирование отражает резервирование на уровне построения самой системы.

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

Дублирование основных узлов и носителей

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

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

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

Диагностика и ЗИП в общей схеме резервирования

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

Отдельно подтверждено наличие ЗИП — комплекта запасных частей и принадлежностей. В профессиональной логике отказоустойчивости ЗИП относится уже к обеспечению восстановления и замены компонентов. Это другой уровень меры по сравнению с непосредственным дублированием работающего узла.

Так формируется последовательная система проектных решений. Резервирование предусматривает альтернативный компонент или структуру. Диагностика позволяет работать с информацией о состоянии. ЗИП обеспечивает предусмотренную проектом материальную основу для замены или восстановления отдельных элементов.

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

Структурное резервирование вычислительной инфраструктуры

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

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

Поэтому результат проверки сформирован из нескольких подтверждений: проект предусматривает резервирование компонентов, содержит средства диагностики, включает ЗИП и предусматривает структурное резервирование. Такая совокупность соответствует предмету выполненной проверки — оценке резервирования основных компонентов отказоустойчивой аппаратной платформы.

Что подтверждено по результатам проверки

По рассмотренному проекту подтверждены следующие решения:

• предусмотрено дублирование основных узлов и носителей;
• предусмотрена диагностика;
• предусмотрен ЗИП;
• предусмотрено структурное резервирование.

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

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

Проверка аналогичного решения по резервированию

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

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

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

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