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

1. Защита данных должна строиться исходя из логики бизнес-приложений. Компании используют десятки, иногда сотни пользовательских приложений. Часть из них выполняет ключевые функции, часть — служебные. Администратор должен понимать сценарий поведения каждого пользовательского приложения в случае остановки основного ЦОДа и подключения резервного.

Чаще всего это решается набором разнородных сторонних решений, каждое из которых выполняет узкоспециализированную функцию — кластеризацию, репликацию систем хранения или резервных копий и другие задачи. В критической ситуации разнородные инфраструктурные сервисы могут вести себя непредсказуемо. Это проявляется, например, в некорректном переключении с основного на резервный ЦОД. Поэтому мы рекомендуем выбирать платформенные решения, которые представляют собой единственный центр принятия решений, по необходимости восстанавливающий данные на уровне приложения (а не на уровне системы хранения или кластерной файловой системы), и могут обеспечить предсказуемую и стабильную работу всех функциональных блоков.

Консистентность данных должна определяться не на уровне файловой системы, логических томов СХД, а на уровне бизнес-приложения. К сожалению, когда разрабатывают дорогостоящие DR-решения (Disaster Recovery) по репликации и синхронизации данных, иногда об этом забывают. Ведь блочные данные на уровне системы хранения могут оказаться нечитаемыми логическими блоками, если DR-алгоритм отработал некорректно.

При этом стратегия защиты данных изначально должна строиться от потребностей бизнес-приложений. У администратора должна быть возможность работать через интерфейс приложения и при необходимости восстанавливать данные, не обращаясь непосредственно к средствам защиты. Фактически инфраструктура по защите данных должна быть прозрачна, как бы невидима, абстрагирована от основного инфраструктурного уровня.

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

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

3. Необходимо сочетать возможность автономии на местах для удаленных офисов с возможностью эффективного мониторинга из центра. Еще один важный момент — удаленные офисы. Например, небольшое торговое представительство в регионе, где нужно всего 10 компьютеров для рабочей группы и нет возможности поставить в офис сервер. В этом случае необходимо выбрать облачный сервис, и чаще всего выбор падает на Dropbox. Это удобно, но контроль из центра теряется.

Современная система защиты и управления данными должна иметь возможность создания аналога Dropbox в рамках корпоративной инфраструктуры. Это дает возможность контролировать активность пользователей из единого центра мониторинга — когда и куда они подключаются, осуществлять контекстный поиск по всей информации, а также соблюдать требования регулятора. Кроме того, это дает возможность сэкономить на локальных администраторах на местах.

4. Современное решение — сочетание DRaaS и BaaS на одной платформе. Перечисленные возможности обычно реализуются в рамках единой DR-стратегии. Однако их разработка, как правило, стоит существенных вложений. К счастью, современные подходы предлагают возможность организовать распределенную инфраструктуру с контролем из единого центра в рамках моделей DRaaS (Disaster Recovery-as-a-Service) и BaaS (Backup-as-a-Service). Мы считаем, что современные средства управления данными должны включать обе технологии, интегрированные на одной платформе с единым центром мониторинга и управления.

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

Современные стратегии распределенных и удаленных ЦОДов позволяют объединить режим восстановления после сбоя, репликацию и резервное копирование в одну стратегию. На практике это дает возможность делать не только восстановление данных с резервной копии, но и «откатить» приложение на несколько минут назад в состояние до обрушения практически в режиме реального времени. Также сочетание DRaaS- и BaaS-моделей дает возможность приостанавливать удаленный ЦОД, переводить его из одного режима в другой и в том числе делать мгновенные снимки всего ЦОДа на любой момент времени. И все это управляется из единой консоли.

Автор статьи — технический консультант компании Commvault в России и СНГ.