- •Вопрос 2 Международные стандарты информационного обмена.
- •12. Модели безопасности и их применение.
- •13. Таксономия нарушений информационной безопасности вычислительной системы и причины, обуславливающие их существование.
- •23. Анализ отказоустойчивости Информационной системы. Определение отказоустойчивости
- •24. Защита Информационных систем с применением аппаратных средств.
- •40. Система управления инцидентами как основа обеспечения информационной безопасности организации.
- •41. Управление рисками безопасности информационных систем организаций.
- •42. Методы и средства аудита информационной безопасности.
- •43. Построение и функционирование службы корпоративной безопасности компании
- •47. Измерение эффективности информационной безопасности
- •27. Служба информационной безопасности и системы безопасности.
- •28. Организация допуска предприятий к сведениям, составляющими государственную тайну.
- •26. Защита информации в персональных компьютерах.
- •29. Организация допуска и доступа персонала к конфиденциальной информации.
23. Анализ отказоустойчивости Информационной системы. Определение отказоустойчивости
Согласно общепринятым представлениям, отказоустойчивость ИТ-системы определяется ее способностью сохранять работоспособность при отказе одного или нескольких компонентов. Исходя из типовой архитектуры ИТ-систем, можно выделить несколько компонентных составляющих общей отказоустойчивости:
отказоустойчивость программного обеспечения (как системного, так и прикладного);
отказоустойчивость аппаратного обеспечения ИТ-системы на уровне логических модулей (например, подсистемы хранения данных);
отказоустойчивость аппаратного обеспечения ИТ-системы на уровне отдельного устройства (например, сервера);
отказоустойчивость отдельных модулей внутри устройства (например, отказоустойчивость конфигурации жестких дисков);
отказоустойчивость отдельной площадки (в случае, если ИТ-система имеет географически распределенную архитектуру).
Механизмы реализации отказоустойчивости
В настоящее время единственным механизмом обеспечения отказоустойчивости ИТ-системы является избыточность входящих в нее компонентов. Рассмотрим как реализуется отказоустойчивость на компонентных уровнях.
Отказоустойчивость программного обеспечения. Речь идет об использовании различных способов кластеризации с установкой идентичного программного обеспечения на всех узлах кластера. В случае отказа ПО или программного сбоя на одном из узлов кластера его нагрузка перераспределяется между корректно функционирующими узлами. За это отвечает кластерное ПО, которое по определенным критериям определяет, на каком из узлов неверно функционирует системное или прикладное программное обеспечение и «выключает» данный узел из активной деятельности.
Стоит отметить, что отказ аппаратной части узла приводит к тем же последствиям, но диагностировать причину неработоспособности прикладного или системного программного обеспечения сложно и не имеет особого смысла. Отказ одного из узлов кластера не приводит к остановке ИТ-системы или ограничению ее функциональности. Типичный негативный эффект от такого единичного отказа проявляется в снижении производительности системы и возможной задержке в выполнении операций ввода-вывода на время переноса нагрузки сбойного кластера на другие узлы.
Отказоустойчивость аппаратного обеспечения ИТ-системы на уровне логических модулей. В этом случае механизм реализации отказоустойчивости идентичен вышеописанному, но предполагает кластеризацию аппаратных средств без использования внешнего программного обеспечения. Такой вид кластеризации применяется главным образом в системах хранения данных и серверных многоузловых сборках. Средства управления таким аппаратным кластером отвечают только за исправность аппаратной составляющей и не контролируют корректность функционирующего на этом кластере программного обеспечения. Отказ одного сервера или одной системы хранения данных в такой логической сборке не вызовет остановку всей ИТ-системы, а лишь ограничит ее производительность.
Отказоустойчивость аппаратного обеспечения ИТ-системы на уровне отдельного устройства. Аппаратная отказоустойчивость отдельного устройства обеспечивается избыточностью наименее надежных его компонентов. Например, сервер может иметь несколько дополнительных блоков питания и вентиляторов охлаждения, при этом условия, когда он оказывается неработоспособным, определяются реализованной схемой избыточности тех или иных компонентов. Наиболее распространены схемы N+1 (избыточным является только один компонент в подсистеме, и, соответственно, допускается отказ только одного такого же компонента) и 2N (двукратная избыточность, допускающая выход из строя половины установленных в функциональном блоке идентичных компонентов).
Отказоустойчивость отдельных модулей внутри устройства. Обеспечение отказоустойчивости на уровне отдельных модулей распространено, в частности, при организации хранения данных, причем как оперативного, так и долговременного, и так же основано на избыточности отдельных аппаратных компонентов: жестких дисков и (значительно реже) модулей оперативной памяти. Обычно в таких случаях пользователь аппаратного устройства сам ищет разумный компромисс между отказоустойчивостью и производительностью модуля, а также риском потери данных и стоимостью их хранения. При этом схема реализации отказоустойчивости выбирается из жестко заданных производителем оборудования вариантов. Вместе с тем варианты здесь могут быть самые разные. Применяются схемы N+1, N+2, 2N, а также множество производных схем, заданных производителем в виде шаблонов. Стоит также отметить, что такого рода решения могут предусматривать автоматическое устранение отказа через некоторый период времени.
Катастрофоустойчивое решение
В редких случаях причиной утраты работоспособности ИТ-системы может стать отказ ЦОДа в целом в результате локальной или глобальной катастрофы. Стоимость катастрофоустойчивого решения весьма значительна, поскольку требует дублирования функционала ЦОДа на географически удаленной площадке. При этом используют два разных подхода. Первый предполагает практически полное воспроизведение функционала защищаемого ЦОДа на удаленной площадке с той же или, как вариант, с несколько меньшей производительностью. В случае отказа основного ЦОДа его функции берет на себя резервный. Факторами риска в данном случае являются административный ИТ-персонал, который должен своевременно принять решение о переносе сервисов на другую площадку, и наличие отработанного регламента для успешного выполнения этой операции. Во время переноса нагрузки в резервный ЦОД предоставляемые сервисы могут быть временно недоступны. Существует также риск потерять некоторый объем данных, определяемый тем, как организована репликация данных между ЦОДами. Данный подход к обеспечению катастрофоустойчивости ИТ-систем базируется на нескольких кластерах, объединенных в так называемый метрокластер.
Второй подход предполагает обеспечение сохранности данных, то есть в случае отказа основного ЦОДа на удаленной площадке остаются невредимыми резервные копии и/или реплики данных с СХД основного ЦОДа. Это менее дорогое решение, поскольку на удаленной площадке создается только избыточная часть системы резервного копирования или часть системы хранения данных. Оно не защищает полностью от отказа ЦОДа, но позволяет свести к минимуму риск потери данных.
Для оценки отказоустойчивости новой системы и ее надежности, важен регулярный анализ статистической информации, т.к. отказы могут возникать внезапно (без предварительного ухудшения выходных характеристик), либо заранее прогнозироваться постепенным изменением выходных характеристик.
Как измерить отказоустойчивость? IT-профессионалы определяют отказоустойчивость как
A = (F - (D + R))/F
где A - отказоустойчивость, F - время между сбоями, D - время, необходимое для выявления сбоя и выбора контрмер, а R - время восстановления после сбоя.
Чтобы выявить сбой, нужны технология и компетентный персонал. Высококвалифицированный сотрудник может предотвратить одни сбои и выявить другие, до того как они вызовут какие-либо проблемы, действуя при этом так, что система совсем не выходит из рабочего режима. Частью такого планово-предупредительного обслуживания являются действенные процедуры по развертыванию программ, обеспечивающих операторов базовыми показателями производительности систем. Одна из самых важных задач администратора баз данных - уметь отличать, когда система работает в плановом режиме, а когда происходит что-то необычное. Если тестирование на нагрузку не применяется, получить характеристики функционирования можно, только исследуя приложение, после того как оно запущено в производственном режиме, что может дать ложные результаты, если с самого начала развертывания приложения возникали ошибки. Результаты тестирования производительности приложений дают администраторам больше возможностей с точки зрения быстрой диагностики проблем в производственной среде.
Единственный фактор, не поддающийся контролю, - это промежуток времени между сбоями; он совершенно непредсказуем. Следовательно, инвестиции в высокую отказоустойчивость делятся на инвестиции в персонал и методы, сокращающие время выявления и принятия решения, и инвестиции в технологии, сокращающие время выявления и восстановления.
