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

Системы хранения в катастрофоустойчивых решениях.

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

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

Две хорошо известные метрики, которые позволяют количественно описывать восстановление при сбое:

• RTO (Recovery Time Objective, целевое время восстановления) - время, за которое должно быть восстановлено выполнение сервисов (приложений, бизнес-процессов);
• RPO (Recovery Point Objective, целевая точка восстановления) - промежуток времени до наступления сбоя, данные за который могут быть утрачены.

Если с RPO обычно вопросов не возникает (если данные полностью копируются на удаленную систему раз в сутки, то и RPO составит величину не более суток), то с RTO дело обстоит несколько сложнее. Время восстановления будет зависеть от самых разных факторов (кроме того, оно очевидно будет отличаться для сервиса, например приложения SQL, и для бизнес-процесса, который активно этот сервис использует). Спланированность организационных действий и взаимосвязи сервисов и бизнес-процессов могут существенным образом отразиться на итоговом времени восстановления. Если работоспособность СУБД будет восстановлена за 20 минут, консистентность данных - за еще за 25, а сотрудники смогут подключиться к системе еще через 45 минут, то и время восстановления будет не менее полутора часов.

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

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

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

Зачастую в зависимости от требований RTO/RPO используемые технологии в системах хранения разделяются на несколько уровней:

• Уровень 1 и 2: физический транспорт носителей с резервными копиями в удаленное хранилище или на резервную площадку. Время восстановления может достигать нескольких суток (и даже недель в случае, если резервная площадка не оснащена соответствующим оборудованием). RPO в данном случае также велико и составляет, как правило, не менее суток. Кроме того, существуют риски, связанные с утратой/хищением носителей во время их транспортировки.
• Уровень 3: репликация резервных копий. Резервные копии по электронным каналам связи передаются на удаленную площадку. Параллельно, на удаленной площадке может происходить периодическое восстановление данных, с тем чтобы максимально сократить возможное время запуска в работу в случае аварии на основной площадке. Использование дедупликации и компрессии при передаче данных позволяет существенно сократить требования к каналам передачи данных между площадками, шифрование же дает возможность использовать открытые каналы передачи данных без риска доступа к ним злоумышленников В качестве аппаратной основы для данной реализации мы предлагаем использовать возможности виртуальных ленточных библиотек Falconstor VTL.
• Уровень 4 и 5: использование мгновенных снимков в системах хранения или возможностей приложений для обеспечения консистентности реплицируемых данных. На данных уровнях мы не будем останавливаться подробно - мгновенные снимки активно и успешно используются в большинстве решений резервного копирования и здесь нет никаких радикальных отличий, а программные решения по репликации (на уровне приложения) узкоспецифичны и не дают возможности создать универсальную инфраструктуру.
• Уровень 6: репликация данных средствами дисковой системы (синхронная или асинхронная репликация). Начиная с систем хранения среднего класса такой функционал доступен практически у всех производителей:
  
  IBM    Metro Mirror / Global Mirror
  EMC    SRDF / SRDF/A
  HDS    TrueCopy / TrueCopy Asyncronous
  IBM Nseries (NetApp)    SnapMirror
  Falconstor NSS    Replication
  
  В зависимости от используемого механизма репликации и программного обеспечения, величины RPO и RTO могут быть сокращены до десятков и даже единиц минут.
• Следующий, 7й уровень включает кластеризацию с автоматизированным восстановлением работоспособности сервисов после сбоя на одной из площадок. Для обеспечения таких возможностей существует ряд технических решений, которые помогают достичь практически нулевого времени простоя (на уровне системы хранения данных):
  • IBM SAN Volume Controller (SVC) - при разделении I/O группы между площадками и с использованием VDisk mirror;
  • Falconstor NSS Failover Syncronous Mirroring - при размещении узлов NSS на разных площадках;
  • IBM Nseries (NetApp) Fabric MetroCluster SyncMirror
  Суть этих решений сводится к тому, что "половинки" системы хранения работают в режиме active/active параллельно на двух площадках, а данные синхронно (т.е. без отставания по времени) зеркалируются между площадками). Все эти решения накладывают серьезные ограничения на расстояние между площадками, тип и число каналов связи между ними, но позволяют стоить территориально распределенные кластеры, работающие по схеме active/active с близкими к нулю величинами RTO/RPO.

Комбинируя перечисленные решения можно построить многоуровневую систему защиты от катастроф, обеспечивающую практически любые заданные сочетания RTO/RPO.

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