Дебют

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

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

1. Информация делится на сохраненную вне информационной системы - и разрушенную.
2. Резервные копии данных делаются не в единственном экземпляре, а в нескольких, как минимум по принципу "дед-отец-сын"
3. Выбираются наиболее надежные носители информации для выполнения резервных копий.
4. Создаются полноценные резервные копии.
5. Обеспечивается надежное хранение резервных копий в отдельном помещении - территориально удаленном от первичного носителя информации.
6. Обеспечивается регулярный контроль качества резервных копий и их пригодность к восстановлению.

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

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

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

Однако нельзя сбрасывать со счетов так называемый человеческий фактор. Зачастую, безответственное отношение к своим обязанностям и удручающе низкий уровень подготовки специалистов, эксплуатирующих современные информационные системы, приводит к тому, что настолько важная вещь, как стратегия резервирования и восстановления, отсутствует или разработана формально, с нарушением принципов и правил. Результатом является тот факт, что, по данным Gartner Group, до 75% всех резервных копий являются непригодными к восстановлению. Стоит отметить, что такой высокий процент характерен для относительно благополучных в отношении подготовки специалистов западных стран - с их жесткими требованиями к квалификации исполнителей любого звена и персональной ответственностью за состояние эксплуатируемых систем. Практика стран СНГ показала, что процент непригодных резервных копий значительно выше, а стратегий резервирования и восстановления, как правило, не имеется вовсе.

Миттельшпиль

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

Соответственно, появившийся спрос породил предложение. Была создана концепция Высокой Доступности (High Availability).¹ Согласно этой концепции, с высоконадежным дисковым массивом (обычно организованным при помощи технологии RAID²) работает несколько кластерных узлов, обрабатывающих данные. Считается, что такое решение является наиболее надежным, однако при этом упускается из виду одно важное обстоятельство. Данное решение фактически защищено лишь от отказа отдельных узлов обработки - а поскольку дисковая система одна на всех, ее отказ приводит к выходу из строя всего кластера. Кроме того, опыт эксплуатации подобных систем показал, что полные отказы RAID-массивов - вовсе не редкость, причем их последующее восстановление чрезвычайно сложно или невозможно. По этой причине, если персонал полностью доверял заверениям поставщика о высочайшей надежности подобного решения и отказывался от классической стратегии резервирования - отказ приводил к катастрофическим простоям.

Постепенно произошло разделение кластерных систем на HA (High Availability) и HP (High Performance)³, с постепенным вытеснением последними первых, коль скоро выяснилось, что за дорогостоящими фасадами HA-систем редко скрывается по-настоящему надежное решение по защите данных.

Однако коль скоро кластерные системы являются столь дорогостоящими и приносящими такую прибыль поставщику, хоронить их никто не торопится. Более того, с появлением на свет концепции масштабируемых решений (недорогих изначально и, якобы, имеющих многократно меньшую величину TCO⁴) большинство крупных поставщиков программного обеспечения предлагают кластерные решения. При этом обычно они не афишируют тот факт, что приоритетом данных решений все в большей степени становится возможность масштабирования системы, а не надежность.⁵

Некоторые из производителей, полностью отдавая отчет в том, что кластерные решения не являются по-настоящему надежными, стали развивать концепции так называемых резервных (или standby) систем. Пионером в данной области является ныне не существующая компания Digital, разработавшая в свое время самый надежный сервер баз данных - RDB (данная технология была приобретена корпорацией Oracle и полностью поддерживается в СУБД Oracle9i).

Одновременно начали появляться разнообразные альтернативные решения.

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

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

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

Чудес, разумеется, не бывает, и в данном конкретном случае перехода количества компонентов в качество не происходит. Более того, хотя исходная стоимость построения такого решения находится более-менее в разумных пределах, стоимость его сопровождения и, следовательно, совокупная стоимость владения взлетает до небес.⁶

У решения на основе "Резервного Центра" есть еще одно совершенно очевидное следствие: всецело полагаясь на надежность столь дорогостоящей системы, клиенты забывают о необходимости обеспечения защиты при помощи базовых стратегий, зачастую оправдывая это необходимостью функционирования информационной системы в режиме 24x7x365 (что практически всегда не соответствует действительности - за весьма нечастыми исключениями). Соответственно, общая надежность системы снижается. Кроме того, необычайно высокое значение приобретает человеческий фактор - несмотря на уверения поставщиков решения о способности системы якобы функционировать полностью автоматически.⁷

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

Возникает вопрос - существует ли решение по защите данных, являющееся удовлетворительным со всех точек зрения?

Эндшпиль

Ответ на данный вопрос - да, существует. И существует достаточно давно. Это решение - standby-системы. Или, говоря точнее, технология standby в области промышленных баз данных.

Данная технология, как было сказано выше, была впервые предложена компанией Digital и получила широкое распространение в СУБД Oracle (начиная с версии 7). Причем, в последних версиях СУБД Oracle поддерживается не только классическая технология standby - с переключением при любом отказе на резервную систему, идентичную первичной, но и технология hot-standby - позволяющая иметь резервную систему с другой архитектурой, нежели первичная, производить многократные переключения между системами и обеспечивать доступность резервной системы на чтение с целью снижения нагрузки на первичную. При использовании данной технологии отпадает необходимость в применении каких-либо дополнительных программных или аппаратных компонентов третьих производителей (поскольку поддержка данной технологии фактически встроена в ядро СУБД), и, следовательно, в их поддержке и сопровождении. Суть технологии заключается в дублировании (как минимум двукратном) первоначальной системы и возможностью быстрой активации резервной системы и переключения пользователей и приложений для работы с ней.

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

Следует отметить еще один важный аспект построения высоконадежных систем. Зачастую клиент плохо представляет себе свои истинные потребности в надежности информационной системы, и неадекватно определяет величину этой самой надежности. При определении необходимой степени надежности системы следует оперировать следующими факторами:

1. Степенью важности данных для предприятия и что произойдет в случае их полного уничтожения.
2. Графиком работы системы (то есть определить - действительно ли система относится к классу 24x7x365 и какая величина технологического простоя в действительности является допустимой)
3. Существует ли базовая стратегия резервирования и восстановления и насколько она удовлетворительна
4. Насколько в действительности высока вероятность катастрофического отказа любого рода (опыт показывает, что опасения зачастую оказываются беспочвенными ввиду крайне малой вероятности того или иного катастрофического события вообще).
5. Предприняты ли первичные мероприятия по защите данных (обеспечен ли сервер чистым питанием, насколько надежна система кондиционирования серверного помещения, нет ли в серверном помещении водопроводных и отопительных труб, нет ли в серверном помещении окон, обеспечивается ли отдельное от серверов хранение резервных копий - опыт показывает, что, как правило, резервные копии хранятся в одном помещении с серверами, что сводит их ценность к нулю - и.т.п)

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

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

---

1. HA - High Availability. Так принято называть высоконадежные решения для ИС, обычно на основе кластерных систем.
2. RAID - Redundancy Array of Independent Disks - дисковый массив с высокой надежностью и/или скоростью работы. Обычно состоит из некоторого количества недорогих дисков, организованных при помощи контроллера с целью получения большей надежности, чем надежность составляющих его дисков.
3. HP - High Performance. Высокопроизводительные кластерные решения. Как правило, идеологически противоположны HA-системам, защита данных обеспечивается либо классическим образом, либо посредством технологий standby.
4. TCO - Total Cost of Ownership - "совокупная стоимость владения". Термин, обозначающий полную стоимость приобретения, сопровождения, эксплуатации и поддержки информационной системы на протяжении ее жизненного цикла.
5. Теоретически концепция масштабирования систем, например, корпорации Oracle (RAMP - Reliability Availability Manageability Performance), предполагает надежность как одну из основополагающих частей.
6. Совершенно очевидное следствие. Необходимость поддержки очень большого количества разнородных аппаратных и программных компонентов резко увеличивает затраты на эксплуатацию. Фактически мы приходим к состоянию ИС до появления клиент - серверных архитектур.
7. Чем сложнее система, тем большими степенями свободы она обладает и тем сложнее запрограммировать необходимые реакции на все возможные сочетания меняющихся условий. Кроме того, совершенно упускается из виду еще одно обстоятельство - что, если откажет одно из звеньев, обеспечивающее защиту?