Системы высокой готовности

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

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

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

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

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

Уровень требования к времени восстановления задается на этапе проектирования системы высокой готовности и может иметь вид, например «98%», что означает, что система должна быть доступна в течение 98 процентов времени в году или быть в недоступном состоянии 175 часов 12 минут (7,3 дней). Ниже в таблице приведены расчеты по различным требованиям к доступности:

Требование к доступности, % времени в год

Состояние отказа, % времени в год

Дней

Часов

Минут

90,00

10,00

36,5

876

52560

98,00

2,00

7,3

175,2

10512

99,00

1,00

3,65

87,6

5256

99,50

0,50

1,825

43,8

2628

99,90

0,10

0,365

8,76

525,6

99,99

0,01

0,0365

0,876

52,56

99,999

0,001

0,00365

0,0876

5,256

99,9999

0,0001

0,000365

0,00876

0,5256

Как видим, от величины требования зависит время, необходимое для восстановления системы от сбоя. Норма доступности может быть ужесточена требованием по длительности каждого сбоя. Так, например, если общее время недоступности системы определено в 7,3 дня, то максимальная длительность каждого сбоя может быть ограничена 24 часами. Это означает, что система имеет право на примерно семь крупных сбоев в году, однако средства для восстановления должны быть уже принципиально другими в сравнении с простым требованием 7,3 дня (98%).

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

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

Типы систем высокой готовности

Балансировка сетевой нагрузки
Основная задача кластера балансировки сетевой нагрузки (Network Load Balancing Cluster, NLB) — обеспечение оптимальной загрузки серверов при минимально-необходиомом времени отклика прикладных сервисов информационной системы во всех географических точках, где они должны быть доступны пользователям. Балансировка нагрузки достигается путем разгрузки запросов на несколько параллельно-установленных серверов. При этом технологии реализации балансировки могут быть различными.
Отказоустойчивые кластеры
Задача отказоустойчивого кластера — обеспечение доступности севиса в сети за счет минимально-необходимого времени восстановления после сбоя любого происхождения (пожар, аппаратная ошибка, атака и др.). Время восстановления сервиса в таком кластере, как правило, не должно превышать нескольких минут, а в ряде случаев, в зависимости от требований, и секунд.