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 и обнаруживают, что уровень данных недостаточно защищен, только при первой аварии, приведшей к простою либо потере данных.

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

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

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

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

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

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

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

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

Существует огромное количество ограничений, как технических, так и не технических. Определяющим фактором обычно является бюджет. Большее количество оборудования значит больший расход электроэнергии, что предполагает большее выделение тепла, а это, в свою очередь, просит наилучшего кондиционирования, и, опять, дополнительных расходов на электроэнергию.Все это вместе предполагает необходимость огромных площадей и огромных расходов на физическую инфраструктуру. Следует также принять во внимание цена оборудования, дополнительных лицензий 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 (Значимость тестирования плана аварийного восстановления)»

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.