Чтобы разобраться в том, как реализуется отказоустойчивость ИТ-систем, как она определяется, из чего складывается и на что влияет, лучше подойти к рассмотрению этого понятия с точки зрения обеспечения непрерывности бизнеса. В настоящее время прослеживается явная тенденция ужесточения требований к информационным системам, обеспечивающим непрерывность бизнеса, и тому есть простое объяснение — цена минуты простоя такой информационной системы с каждым годом увеличивается экспоненциально. При этом быстро растет и число ИТ-систем, которые обслуживают непрерывные бизнес-процессы, и, следовательно, тоже должны функционировать в непрерывном режиме.

Перечислим факторы, влияющие на непрерывность функционирования любой ИТ-системы:

  • инженерные системы ЦОДа;
  • административно-организационное обеспечение ИТ-систем;
  • средства безопасности (включая информационную безопасность);
  • средства контроля и управления ИТ-инфраструктурой и ПО;
  • реализация механизма создания резервных копий;
  • отказоустойчивость аппаратной и программной частей ИТ-системы;
  • наличие катастрофоустойчивого решения.

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

Инженерные системы ЦОДа

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

Административно-организационное обеспечение

Административно-организационное обеспечение ИТ-систем предполагает специально разработанные регламенты поддержки их непрерывного функционирования и характеризует отлаженность административных процедур. Регламенты делятся на периодические (определяют порядок планового обслуживания ИТ-систем) и инцидентные (описывают действия для выхода из кризисной ситуации).

Еще один аспект административно-организационного обеспечения — четко выстроенная ролевая модель с прописанными требованиями к персоналу на каждую роль, а также грамотная организация труда обслуживающего ИТ-систему персонала.

Средства безопасности

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

Средства контроля и управления ИТ-инфраструктурой и ПО

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

Реализация механизма создания резервных копий

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

Определение отказоустойчивости

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

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

Механизмы реализации отказоустойчивости

В настоящее время единственным механизмом обеспечения отказоустойчивости ИТ-системы является избыточность входящих в нее компонентов. Рассмотрим как реализуется отказоустойчивость на компонентных уровнях.

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

Стоит отметить, что отказ аппаратной части узла приводит к тем же последствиям, но диагностировать причину неработоспособности прикладного или системного программного обеспечения сложно и не имеет особого смысла. Отказ одного из узлов кластера не приводит к остановке ИТ-системы или ограничению ее функциональности. Типичный негативный эффект от такого единичного отказа проявляется в снижении производительности системы и возможной задержке в выполнении операций ввода-вывода на время переноса нагрузки сбойного кластера на другие узлы.

Примером кластерного ПО для обеспечения отказоустойчивости программного обеспечения может служить Veritas Cluster Service. Данный продукт имеет богатый функционал для построения зависимостей между разными уровнями ресурсов кластера, расширенные средства диагностики и определяемый набор политик для переноса нагрузки с отказавшего узла кластера на корректно функционирующие узлы.

Другой пример реализации механизма отказоустойчивости ПО — серверная виртуализация.

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

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

Отказоустойчивость аппаратного обеспечения ИТ-системы на уровне отдельного устройства. Аппаратная отказоустойчивость отдельного устройства обеспечивается избыточностью наименее надежных его компонентов. Например, сервер может иметь несколько дополнительных блоков питания и вентиляторов охлаждения, при этом условия, когда он оказывается неработоспособным, определяются реализованной схемой избыточности тех или иных компонентов. Наиболее распространены схемы N+1 (избыточным является только один компонент в подсистеме, и, соответственно, допускается отказ только одного такого же компонента) и 2N (двукратная избыточность, допускающая выход из строя половины установленных в функциональном блоке идентичных компонентов).

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

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

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

Катастрофоустойчивое решение

В редких случаях причиной утраты работоспособности ИТ-системы может стать отказ ЦОДа в целом в результате локальной или глобальной катастрофы. Стоимость катастрофоустойчивого решения весьма значительна, поскольку требует дублирования функционала ЦОДа на географически удаленной площадке. При этом используют два разных подхода. Первый предполагает практически полное воспроизведение функционала защищаемого ЦОДа на удаленной площадке с той же или, как вариант, с несколько меньшей производительностью. В случае отказа основного ЦОДа его функции берет на себя резервный. Факторами риска в данном случае являются административный ИТ-персонал, который должен своевременно принять решение о переносе сервисов на другую площадку, и наличие отработанного регламента для успешного выполнения этой операции. Во время переноса нагрузки в резервный ЦОД предоставляемые сервисы могут быть временно недоступны. Существует также риск потерять некоторый объем данных, определяемый тем, как организована репликация данных между ЦОДами. Данный подход к обеспечению катастрофоустойчивости ИТ-систем базируется на нескольких кластерах, объединенных в так называемый метрокластер.

Второй подход предполагает обеспечение сохранности данных, то есть в случае отказа основного ЦОДа на удаленной площадке остаются невредимыми резервные копии и/или реплики данных с СХД основного ЦОДа. Это менее дорогое решение, поскольку на удаленной площадке создается только избыточная часть системы резервного копирования или часть системы хранения данных. Оно не защищает полностью от отказа ЦОДа, но позволяет свести к минимуму риск потери данных.

Автор статьи — Алексей Амосов, директор департамента программно-аппаратных комплексов RedSys.

СПЕЦПРОЕКТ КОМПАНИИ REDSYS