SQL Server: Защита данных любой ценой

Бизнес остановился бы в отсутствие возможности бесперебойного хранения и извлечения данных. В любой корпорации данные являются самыми важными активами — если не считать людей, конечно. Часто стратегия управления данными строится на базе SQL Server 2008 и SQL Server 2008 R2. Поэтому, если задуматься, именно разработчики и администраторы баз данных ответственны за жизнеспособность бизнеса.

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

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

Координация стратегии управления данными

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

• Удовлетворить требования по безопасности данных можно с помощью таких функций, как прозрачное шифрование данных, в ходе которого данные шифруются в момент бездействия системы, и расширенное управление ключами, позволяющее хранить ключи отдельно от зашифрованных данных.
• Требования к отчетности можно полностью удовлетворить с помощью служб отчетов SQL Server
• Регулятор ресурсов может помочь в прогнозировании производительности рабочей нагрузки.
• С помощью SQL Server Audit можно полностью удовлетворить самые сложные требования аудита.

Однако есть два важных бизнес-требования, которые зачастую трудно довести до исполнителей: время простоя и допустимая потеря данных. Они так же известны как минимальная продолжительность восстановления (Recovery Time Objective, RTO) и директивный срок восстановления (Recovery Point Objective, RPO), соответственно. К несчастью, менеджеры довольно часто пренебрегают учетом RTO и RPO и обнаруживают, что уровень данных недостаточно защищен, только при первой аварии, приведшей к простою или потере данных.

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

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

Работа с требованиями

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

1. Насколько важна та или иная область данных по сравнению с остальным корпоративным хранилищем данных? Бизнес-менеджеры часто утверждают, что все чрезвычайно важно и должно быть соответственно защищено. Этот подход работает только при небольших объемах данных, но становится чрезвычайно непрактичным, когда на множестве серверов SQL Server хранятся многие терабайты данных.
2. Сколько данных компания может позволить себе потерять? Владельцы компании хотели бы видеть нулевую потерю данных, но это не всегда целесообразно.
3. Как долго данные могут быть недоступны? Владельцам компании так же хотелось бы видеть нулевое время простоя, но в реальности этого достичь невозможно. Вместе с тем, это время можно значительно сократить.
4. Меняются ли первый или второй фактор в зависимости от времени суток или выходных дней? Это может иметь существенное влияние на возможность выполнения требований. Нулевого времени простоя или предотвращения потери данных легче добиться на ограниченном отрезке времени, скажем с 9 часов утра до 5 часов вечера в рабочие дни, чем в условиях постоянного доступа в режиме «24 часа 365 дней в году».
5. Можно сохранить доступность данных и отказоустойчивость в ущерб производительности бизнес-операций? Единственная технология, способная обеспечить нулевую потерю данных, — синхронное зеркальное отображение записей журнала транзакций или операций подсистемы ввода-вывода. И то, и другое может привести к снижению производительности обработки данных. Этот компромисс надо учитывать.

Хороший метод — проанализировать влияние недоступности или потери тех или иных данных на бизнес. Задумавшись над этим, вы узнаете много нового о влиянии данных на работу клиентов, имидж компании и взаимодействие с регулирующими органами.

Работа с ограничениями

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

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

Компромиссы и искусство решения корпоративных пазлов

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

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

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

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

Тестировать — не перетестировать

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

Впрочем, это проще сказать, чем сделать. Сложная это задача — убедить бизнес-менеджеров выполнить тестирование, которое может привести к простою. Можно попытаться убедить их, аргументируя, что лучше всего выполнить тестирование, когда каждый на своем месте в ожидании «аварии» и готов приступить к быстрому решению любых проблем. Альтернативный сценарий развития событий:недоработанность проекта выявляется при возникновении аварии в 2 часа утра в выходной день, когда в офисе находится лишь небольшая часть персонала.

Даже если выяснится, что ваш уровень данных недостаточно защищен от простоев и потерь данных, есть множество вариантов реализации стратегии, обеспечивающей высокую доступность и аварийное восстановление, средствами SQL Server 2008 или SQL Server 2008 R2. Ознакомьтесь с различными технологиями и их преимуществами и недостатками, и постарайтесь использовать архитектуры, уже успешно опробованные другими компаниями. Подробную информацию вы найдете в следующих источниках:

• «Белая книга»: «Высокая доступность средствами SQL Server 2008 R2»
• «Белая книга»: «Proven SQL Server Architectures for High Availability and Disaster Recovery (Проверенные архитектуры SQL Server для обеспечения высокого уровня доступности и аварийного восстановления)»
• Статья в блоге SQLSkills.com: «Importance of having a good disaster recovery plan (Важность наличия хорошего плана аварийного восстановления)»
• Статья в блоге SQLSkill.com: «Importance of testing your disaster recovery plan (Важность тестирования плана аварийного восстановления)»

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