Обзор современных платформ архивации данных

Позиционирование платформ архивации

Под архивом подразумевается набор данных, который больше не изменяется, но который должен быть доступен для чтения на протяжении длительного времени. Как правило, подобные данные имеют большой объем (более 10 TB) и относятся к так называемым неструктурированным статическим данным (см. рис. 1 ).

Рис. 1. Классификация прикладных данных

Прикладные данные можно разделить на четыре условных класса:

1. Структурированные динамические данные (Structured Dynamic Data). Как правило, это данные реляционных СУБД или OLTP-приложений. Требования к хранилищу подобных данных: высокая скорость доступа, высокая скорость ввода/вывода и высокая доступность, что как правило обеспечивается SAN или DAS-решениями на базе дисковых массивов.
2. Неструктурированные динамические данные (Unstructured Dynamic Data). Это различные разделяемые между пользователями документы (MS Word, MS Project, CAD и т.п.), а также пользовательские файловые хранилища. Наиболее популярным решением для организации подобных хранилищ на сегодняшний момент  является NAS. NAS легко внедрить, отсутствует проблема организации доступа в гетерогенной среде Unix и Windows.
3. Структурированные статические данные (Structured Fixed Data). Как правило это данные транзакций или специфические прикладные данные, требования к хранилищу которых зависят от бизнес-приложения.
4. Неструктурированные статические данные (Unstructured Fixed Data). Широкий класс данных, включающий в себя цифровые архивы, фото и видео данные, архивные записи финансовых приложений и т.п. Их ключевой особенностью является следующее: неизменяемые данные должны храниться в течении длительного времени и в тоже время обладать высокой доступностью и возможностью поиска. Именно для данных такого типа разрабатываются и применяются платформы архивации.

Причины появления современных платформ архивации

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

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

• Данные архива находятся вне непосредственного доступа (выгружены из библиотеки или перевезены в архивное хранилище), и требуется значительное время, чтобы найти и восстановить требуемые архивные данные.
• Нет возможности поиска по содержимому архива, и для нахождения требуемой информации зачастую требуется восстановить значительную часть архива, и только после этого производить поиск по восстановленным данным.
• Нет гарантии от порчи или потери носителя архивной информации.
• Нет гарантии того, что данные архива не были удалены или изменены.
• В архив попадает множество дублирующей информации, что приводит к увеличению размеров архива, а как следствие – усложняется работа с архивными данными и увеличивается стоимость содержания архива;
• Так как технологии записи на ленты со временем изменяются, необходимо производить своевременную миграцию архива, а это длительный и требующий значительных трудозатрат процесс.

На сегодняшний момент запросы на поиск официальных или корпоративных данных часто сочетают требования к поиску с жестким ограничением по времени обработки запроса; при этом необходимые данные должны быть найдены быстро и в неизменном виде во избежание финансового ущерба или ущерба для репутации организации. Более того, в ряде нормативных документов (например, SEC Rule 17a-4) явно озвучено требование к реализации механизмов, позволяющих быстро делать необходимые выборки из архива, а также обеспечивать аутентичность хранимых данных (более подробная информация по наи­более распространенным нормативным требованиям приведена в разделе «Нормативные требования к хранению данных» этого документа).

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

• Масштабируемая и устойчивая к отказам отдельных компонент архитектура, обеспечивающая наращивание емкости архива без процедур миграции или изменения логической структуры архива.
• Полноценный контекстный поиск, предоставляющий возможность нахождения необходимой информации за минимальное время.
• Защиту архивной информации от уничтожения или изменения (технология Write Once Read Many, WORM).
• Средства дедупликации архивной информации – одинаковые данные записываются в архив только один раз, все последующие записи не приводят к реальному добавлению новых объектов.

Архитектура платформ архивации

Архитектуру современных платформ архивации условно можно разделить на две категории: платформы, использующие RAIN-архитектуру (или ее модификации), и платформы, построенные по принципу специализированного сервера (Appliance).

Архитектура RAIN (Redundant Array of Independent Nodes) представляет собой избыточное объединение независимых узлов (или Nodes), каждый из которых является самостоятельным и независимым узлом хранения и обработки данных архива ( рис. 2 ).

Рис. 2. Архитектура RAIN

Узел, как правило, представляет 1-2-х процессорный сервер начального уровня с несколькими внутренними SATA-дисками, на котором работает специализированное ПО. Все узлы связаны между собой общей шиной (1 Гб Ethernet). При поступлении запроса на запись один из узлов платформы обрабатывает его и производит запись данных на внутренние диски нескольких узлов платформы. Алгоритм размещения данных производит запись таким образом, что при выходе из строя диска (или дисков) одного из узлов или полный отказ одного узла не приводит к потере данных. Для этого, как правило, используется программный RAID-1 или RAID-5 на дисках одного узла и парное зеркалирование между собой узлов платформы. Конечный вариант защиты и расположения данных зависит от конкретного продукта.

Архитектуру RAIN или ее модификации используют такие платформы архивации, как EMC Centera, Hitachi HCAP, HP IAP, SUN STK 5800.

Платформы архивации на базе appliance используют один сервер (или несколько объединенных в HA-кластер серверов), имеющих общий доступ к массиву хранения данных. На сервере выполняется специализированное ПО, обеспечивающее прием/передачу архивных данных и запись их на устройства хранения. В виде специализированного сервера спроектированы такие платформы, как IBM DR550 и NetApp SnapLock.

Интеграция платформ архивации с бизнес-приложениями

Основным отличием платформы архивации данных от обычного дискового массива или NAS является методика хранения и модификации данных, впервые предложенная EMC и названная «Content Address Storage». Методика подразумевает хранение объектов данных (а не файлов на файловой системе или блоков LUN) и описывает эти объекты информации – метаданных архива. Как следствие, у платформы архивации отсутствует привычный блочный или файловый доступ
к данным.

Весь обмен данными производится только через специализированное API, реализующее такие операции, как помещение данных в архив, извлечение данных из архива, поиск по метаданным, удаление данных.  Каждому сохраненному приложением объекту данных присваивается уникальный идентификатор, который в дальнейшем используется для манипуляции с данными архива. Передача данных между клиентом и платформой архивации производится по протоколу TCP/IP (см. рис. 3 ).

Рис. 3. Принцип работы Content Address Storage на примере EMC Centera

Использование подобной методики позволяет легко реализовать ряд важных для архивной платформы особенностей:

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

Рис. 4. Взаимодействие с архивом через шлюз сопряжения

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

• Использовать готовые программные модули управления архивацией приложений. Модуль архивации приложений представляет собой специализированное под определенное бизнес-приложение (например, почтовый сервер или СУБД) ПО, позволяющее прозрачно для конечного пользователя архивировать данные приложения. Как правило, каждый производитель платформ архивации имеет ряд модулей архивации для распро­страненных приложений. Более подробно виды подобных модулей и принципы их работы описаны в разделе «Продукты и решения по управления архивацией».
• Модифицировать приложение, добавив в него поддержку требуемой платформы архивации. Если готового коммерческого модуля архивации для требуемого приложения нет (например, приложение разработано самостоятельно или «на заказ»), необходимо интегрировать приложение с требуемой архивной платформой, добавив в него возможность взаимодействия с архивом, используя поставляемый с платформой архивации API.
• Использовать шлюз сопряжения между файловыми протоколами (NFS/CIS/FTP) и архивной платформой. Если вышеописанные варианты по тем или иным причинам невозможны, в качестве решения в этом случае возможно использование шлюза сопряжения. Шлюз сопряжения с архивной платформой, как правило, представляет собой выделенный сервер3 с приложением, транслирующим операции чтения/записи файлов в соответствующие API-вызовы к архиву (см. рис. 4 ). Это позволяет представить клиент­скому приложению архивную платформу как  обычный файловый, FTP или HTTP-сервер. Разумеется, в этом случае отсутствует возможность самостоятельного определения метаданных. Из-за этого привлекательность подобного варианта меньше вышеописанных, так как поиск по метаданным и возможность логической организации данных является большим достоинством платформ архивации.

Продукты и решения по управлению архивацией

Как уже упоминалось выше, взаимодействие с архивной платформой «напрямую» из приложения, как правило, невозможно. На рынке существует ряд продуктов, выполняющих роль прослойки (middleware) между приложениями – генераторами архивных данных и платформой архивации.

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

Можно выделить три большие области применения, определяемые приложениями – генераторами архивных данных:

• Архивация почтовых приложений. Основными независимыми решениями в этой области является ПО Symantec Enterprise Vault или CA Message Manager. Кроме непосредственной связи почтовых приложений с архивом подобные продукты реализуют управление выборкой на архивацию, т.е. позволяют задать набор правил, по которым те или иные почтовые сообщения будут помещены в архив, задают и поддерживают сроки хранения почтовых сообщений в архиве в соответствии с политикой хранения, а также  поддерживают специализированный для данного приложения поиск по содержимому архива. Кроме вышеописанного ПО, каждая архивная платформа имеет собственный программный модуль интеграции с распространенными почтовыми системами (как правило, с Microsoft Exchange или Lotus Notes);
• Архивация баз данных. Это такие продукты, как Solix, Princeton Softech Optim или поставляемые с архивными платформами модули архивации баз данных.
• Архивация файлов. Основными решениями в этой области является Symantec Enterprise Vault, CommVault DataArchiver, Arkivio. Функции, выполняемые подобным ПО, это задание и поддержка правил архивации, сроков хранения данных и так называемый «stubbing» – реализация ссылки на архивированный файл в файловой системе.

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

• Управление документооборотом – контроль версий, форматизированные процедуры создания и удаления документа, каталогизация документации;
• Средства совместной работы над документацией – поддержка проектного офиса;
• Управление записями – реализация заданных политик жизнедеятельности документа (доступ, время жизни);
• Средства перевода бумажной документации в электронный вид.

Примерами подобных решений являются ПО OpenText, CA Record Manager, FileNet. 

Обзор решений по архивации данных

Общие положения

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

Практически все платформы, представленные ниже, обеспечивают ключевые требования к платформам архивации (более подробно эта информация приведена в табл. 4 ), как то:

• обеспечение аутентичности хранимой информации (хранение в формате WORM или шифрование данных);
• управление сроком хранения архивных данных;
• контекстный поиск по содержимому архива;
• дедупликацией архивируемых данных.

Различия между системами заключаются во внутренней архитектуре, а также количестве поддерживающего платформу архивации ПО, что подробнее рассмотрено ниже. На сегодняшний момент лидером рынка, имеющем наибольшее количество инсталляций, является продукт EMC  Сentera – следствие того, что EMC Centera является пионером на рынке платформ архивации. Но тем не менее с развитием рынка платформ архивации EMC Centera уступила часть своих позиций конкурирующим решениям других вендоров – HDS, HP и IBM и т.д.  Новые программные продукты учитывали уже полученный опыт работы платфом архивации и приносили с собой альтернативные способы решения проблем или более высокие скоростные показатели.

EMC Centera Content Addressed Storage

Краткое описание

Платформа архивации данных EMC Centera Content Addressed Storage (далее EMC Centera) является пионером на рынке подобных продуктов – анонс платформы состоялся в августе 2002 года. Первоначально продукт разрабатывался компанией FilePool NV, впоследствии приобретенной EMC.
Основным нововведением EMC Centera являлось понятие «content address storage», описывающее методику хранения данных в архиве. Данная методика подразумевает хранение объектов данных, а не файлов на файловой системе или блоков LUN (более подробно подобный подход был описан ранее в разделе «Интеграция платформ архивации с бизнес-приложениями»).

Архитектура продукта

EMC Centera состоит из избыточного набора узлов доступа и узлов хранения данных (access node и storage node). Узлы доступа и узлы хранения представляют собой сервера платформы Intel c ATA дисками. Сервера соединены между собой во внутреннюю Ethernet LAN, а также имеют Ethernet для внешнего подключения. Узлы доступа используются для приема/передачи архивных данных, хранения данных и управления платформой. Узлы хранения данных предназначены только для хранения информации и проверки целостности данных (см. рис. 5 ). Данные между узлами доступа и узлами хранения данных передаются
по внутренней LAN.

Рис. 5 Архитектура EMC Centera

Аппаратная платформа едина для всех типов узлов и имеет следующие характеристики:

• процессор Intel Pentium 4 c частотой 2 GHz и 512 MB RAM;
• четыре параллельных ATA диска емкостью 250 GB;
• два встроенных интерфейса Ethernet 10/100 Base-T;
• дублированную систему охлаждения и электропитания.

Все узлы работают под управлением модифицированной ОС Linux, имеющей название CentraStar Operating Environment.

Табл. 1 Возможная емкость EMC Centera

Для обеспечения доступности и надежности хранения данных используется принцип избыточности. Узлы EMC Centera объединены в так называемый RAIN (Redundant Array of Independent Nodes), и при выходе из  строя любого из узлов платформы не вызывают потерю данных или отказа в доступе к системе (см. рис. 2 ). Защита данных обеспечивается применением либо зеркалирования (RAID-1), либо RAID-5 в конфигурации 6+1. Для использования RAID-5 необходимо как минимум 16 узлов в конфигурации.
Для повышения надежности хранения данных  в EMC Centera работает фоновый процесс, проверяющий целостность данных архива. При нахождении поврежденных данных процесс производит восстановление информации и отправляет сервисное уведомление администратору архива.

Конфигурация

Конфигурация EMC Centera определяется количеством узлов, входящих в монтажный шкаф. Минимальное количество узлов – 4, максимальное – 32. Расширение производится по 8 узлов (исключением является начальная конфигурация с 4 узлами). Система с количеством узлов, превышающим 8, может быть сконфигурирована как RAID-5, так и с зеркалированием узлов. При использовании 8-узловой конфигурации возможно только зеркалирование.

Если емкость, предоставляемая максимальной конфигурацией (32 узла), недостаточна, EMC Centera может быть кластеризована. Максимальное количество узлов в кластере – 32, что позволяет создавать архивные хранилища емкостью до 384 TB «сырой» емкости.

Программное обеспечение и интеграция

Взаимодействие с архивной платформой EMC Centera по умолчанию возможно только через Centera API, поддержка которого присутствует в во всех сторонних продуктах и решениях по управлению архивацией (см. раздел «Продукты и решения по управлению архивацией»). EMC также поставляет собственные программные продукты управления архивацией:

• Семейство EMC Disk Xtender. Продукт позволяет управлять архивацией файлов на платформе Windows и Unix.
• Семейство EMC Mail Xtender. Продукт поддерживает архивацию почтовых сообщений для Microsoft Exchange и IBM LotusNotes.
• Семейство Documentum Arhive Services (for SAP, for Images, for Report, for SharePoint).

Для интеграции с приложениями, не поддерживающими Centera API, возможно применение EMC Centera Universal Access, представляющего собой шлюз сопряжения между протоколами CIFS/NFS/FTP/HTTP и Centera API (см. рис. 4 ). Продукт требует для своей работы выделенный сервер.

Поиск по архиву EMC Centera осуществляется через ПО Centera Seek and Chargeback Reporter, разработанный компанией FAST Search and Transfer (FAST). Приложение устанавливается на выделенном сервере, который периодически опрашивает платформу архивации и индексирует полученную информацию. Управление  Centera Seek and Chargeback Reporter осуществляется через GUI, также поддерживается управление через API на C++ или JAVA. Поиск возможен только по метаданным архива, контекстный поиск не поддерживается.

Для интеграции с системами резервного копирования EMC предлагает модуль EMC Centera Backup and Recovery Module (далее CBRM). Модуль обеспечивает взаимодействие по протоколу NDMP с ПО резервного копирования, получая или передавая данные с платформы архивирования через Centera API. Протокол NDMP на сегодняшний день поддерживают все корпоративные системы резервного копирования, такие как Symantec NetBackup, IBM Tivoli Storage Manager, HP Data Protector, Legato NetWorker и др. Существует версия CBRM под управлением ОС Windows и ОС Solaris.

HDS Content Archive Platform

Краткое описание

Платформа архивации данных HDS Content Archive Platform (далее HDS HCAP) является первым продуктом компании Hitachi Data Systems, с которым связан ее выход на рынок платформ архивного хранения данных. После заключения партнерского соглашения с фирмой Archivas HDS в феврале 2006 года анонсирует первую версию HCAP. В 2007 году HDS приобретает компанию Archivas и выпускает вторую версию этого продукта.

Как и вышеописанная EMC Centera, HCAP реализует концепцию хранения объектов данных, а не файлов или блоков. Отличительной особенностью платформы HCAP является собственная архитектура платформы (SAIN, более подробно эта архитектура описана ниже), а также возможность полноценного контекстного поиска по содержимому архивного хранилища, реализованного на патентованной технологии компании Archivas. Модуль индексации и поиска поддерживает большое количество распространенных файловых форматов и языков.

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

• текстовые форматы (ASCII, HTML, RTF, XML и т.п);
• форматы текстовых редакторов (Microsoft Word, Adobe Frame Maker, StarOffice, Lotus Word Pro и т.п);
• форматы ПО подготовки презентаций (Microsoft PowerPoint, StarOffice Impress и т.п);
• электронные таблицы (Microsoft Excel, Lotus 1-2-3 и т.п);
• графические форматы (CorelDraw, Adobe Illustrator, GIF, PNG, BMP и т.п);
• компрессированные данные (GZIP, ZIP, TAR, LZH и т.п);
• форматы баз нереляционных данных (Access, dBase, Paradox и т.п).

Поддержка русского языка также присутствует, причем поддерживаются все существующие кодировки.

Архитектура продукта

HCAP состоит из избыточного набора узлов поиска и узлов архивации (search node и archive node). Каждый узел представляет собой сервер Gateway E-9422R (1 RU 2-х ядерный сервер на платформе AMD), на котором выполняется ПО Archivas Cluster (AcC), в качестве ОС используется модифицированная версия Linux. Также как и в EMC Centera, узлы соединены между собой по внутренней LAN и имеют отдельный LAN для внешнего подключения. Узлы поиска выполняют прием и передачу данных архива внешним клиентам, а также отвечают за контекстный поиск информации по данным архива. Узлы архивации предназначены исключительно для записи/чтения архивной информации на СХД.

Рис. 6. Отличие архитектур RAIN и SAIN

Отличительной особенностью HCAP является то, что система хранения данных отделена от узлов архивации и доступна с выделенных дисковых массивов через SAN. HDS именует подобную архитектуру аббревиатурой SAIN – SAN + Array of Independent Nodes. Отличие в реализации архитектур RAIN и SAIN приведены на рис. 6 . Очевидно, что отделив систему хранения данных от служб архивирования, HCAP имеет большую гибкость в выборе характеристик СХД и лучшее масштабирование, чем платформы на архитектуре RAIN. Кроме этого, так как в SAIN разделены узлы архивирования и front-end узлы приема и поиска информации (search node), становится возможным реализовывать архитектуру, необходимую для оптимальной реализации работы платформы. Например, если количество объектов хранения невелико, но каждый имеет большой размер, число узлов архивации может быть уменьшено по сравнению с системой, где присутствует большое количество небольших объектов хранения.

Рис. 7. Архитектура HCAP

Конфигурация

HCAP поставляется в двух разных конфигурациях: в виде готового appliance и бездискового решения. В первом случае HCAP в качестве дисковой подсистемы использует массивы HDS WMS100, минимальная емкость архива составляет 5 ТБ. Система включает в себя 4 Archive Node, 2 Search Node, 1 Ethernet Switch и 1 или
2 массивa WMS100.

Рис. 8. Взаимодействие прикладных систем с HCAP

Бездисковая конфигурация имеет название HCAP-DL (HCAP Diskless), дисковая подсистема в этом случае выбирается клиентом самостоятельно из линейки массивов семейства, разумеется, Hitachi. Возможно применение фактически любого массива: Adaptive Modular Storage (AMS 200/500/1000), Network Storage Controller, USP-V. Емкость архивного хранилища в этом случае определяется дисковой подсистемой клиента и количеством узлов архивации. Один узел архивации способен поддерживать до 400 миллионов объектов в архиве и 256 TB дискового пространства. Архитектурно возможно расширение архива до 2 PB, проверенная HDS максимальная емкость архива составляет 300 TB (наполнение – более 300 миллиардов файлов в архиве).

Программное обеспечение и интеграция HDS в продукте HCAP сделало ставку на простоту интеграции со своей платформой архивации. Это позволяет HCAP эффективно конкурировать с той же EMC Centera.

Ключевыми особенностями HCAP являются:

• Развитые средства поиска информации, находящейся в архивном хранилище. Для этого используются наработки компании Archivas, и как отмечалось ранее, HCAP обеспечивает полноценный контекстный поиск по содержимому архива (у EMC поиск по метаданным). Плюс к этому для организации поиска не требуется выделенного сервера или дополнительного ПО. В качестве интерфейса используется любой HTTP браузер, также есть возможность интеграции поиска в пользовательские приложения через HCAP HTTP-based API.
• Наличие встроенных шлюзов сопряжения для работы с архивом по протоколу, отличному от архивного API. Для файловых служб данные архива доступны по CIFS или NFS, позволяя приложениям работать с архивом как с обычным файл-сервером. Для почтовых серверов архив доступен по протоколу SMTP. Также возможно использовать API, в качестве транспортного протокола применяется  HTTP или WebDAV (см. рис. 8 ). Также, как и со средствами поиска, HCAP
  не требует выделенных серверов для работы шлюзов сопряжения – эту работу выполняют узлы платформы.

Рис. 9. Совместимые с платформой HCAP продукты управления архивацией (Источник: Презентация «Hitachi Content Archive Platform. Overview», Hitachi Data Systems)

Подобное сочетание встроенных возможностей позволяет быстро интегрировать ряд приложений (почтовые и файловые службы) с HCAP. Разумеется подобная связка через встроенные шлюзы сопряжения зачастую хуже работы с платформой через API (нет возможности определять собственные метаданные), но позволяет быстро получить рабочий вариант. На сегодняшний момент HDS заключил соглашения о поддержке HCAP с основными вендорами продуктов управлением архивацией: CA Message Manager, Symantec Enterprise Vault, CA File System Manager, Open Text, Princeton Softech Optim. Это позволяет полноценно использовать HCAP с широким кругом почтовых и прикладных систем (см. рис. 9 ).  Для интеграции с системами резервного копирования используется протокол NDMP, что позволяет использовать с HCAP практически любое корпоративное ПО резервного копирования.

HP IAP (ранее HP RISS)

Краткое описание

Продукт HP Reference Information Storage System (HP RISS) был выпущен на рынок компанией Hewlett-Packard в 2003 году, после приобретения HP компании Persist Technologies. Первоначально продукт позиционировался HP как реализация концепции GRID-Storage, позднее – как система хранения данных Tier 2, затем – как платформа архивации. В 2007 году HP производит переработку продукта и окончательно позиционирует HP RISS как платформу архивации, при этом меняет название продукта на HP Integrated Archive Platform (HP IAP).

Архитектура продукта

Архитектурно HP RISS представляет собой так называемый «Grid-storage», состоящий из объединенных между собой  по сети узлов, именуемых HP как «smart cell». Каждый узел HP RISS обладает подсистемой хранения, а также подсистемой индексирования и поиска информации.  Узлы можно группировать в логические домены, не пересекающиеся друг с другом (см. рис. 10 ). То есть фактически HP RISS имеет схожую с RAIN архитектуру. Для обеспечения надежности узлы зеркалируются, защита данных другого уровня RAID между Smart Cell  (например, RAID-5) не предусмотрена. Для решения задач класса Disaster Recovery HP RISS поддерживает двухстороннюю репликацию между платформами архивации.

Smart Cell представляет собой сервер HP DL320s со следующими характеристиками:

• процессор Intel Xeon c тактовой частотой 2.4 GHz и 4 GB RAM;
• 12 SATA дисков емкостью 250 GB;
• два встроенных интерфейса Ethernet 10/100 Base-T.

Один Smart Cell обеспечивает емкость хранения 2.5 TB, диски при этом объединены в RAID-6.

Конфигурация

Базовая конфигурация HP RISS включает в себя монтажный шкаф, три Smart Cell, Ethernet коммутатор и необходимое ПО. Максимально допустимая конфигурация HP RISS состоит из 21 шкафа расширения (expansion rack), емкость хранения подобной системы составляет 300 TB.

Рис. 10. Архитектура HP RISS

Программное обеспечение и интеграция

Взаимодействие с платформой архивации HP RISS осуществляется через HP RISS API. HP RISS поставляется с одним из модулей архивации приложений (application archiving software), обеспечивающим взаимодействие платформы архивации с почтовыми системами или файловыми серверами. Выбор осуществляется из:

• HP Reference Information Manager for Exchange;
• HP Reference Information Manager for Domino;
• HP File Migration Agent.

Кроме этого, доступен модуль архивации баз данных – HP Reference Information Manager for Databases (поддерживается СУБД Oracle и прикладные системы на ее основе: Oracle E-Business Suite, PeopleSoft).

Последняя версия HP RISS поддерживает полноценный контекстный поиск по всему домену RISS (в предыдущих версиях контекстный поиск был возможен только в пределах одного Smart Cell). Для интеграции с системами резервного копирования используется продукт Reference Information Manager Backup Option, позволяющий производить копирование данных HP RISS используя ПО HP Data Protector по протоколу NDMP.

IBM DR550

Краткое описание

Платформа архивации IBM System Storage DR550 (далее DR550) была анонсирована в мае 2005 года. Продукт пришел на смену ранее существовавшей архивации IBM System Storage DR450. DR550, также как и основные платформы архивации, реализует концепцию хранения информационных объектов, а не файлов или блоков данных. В отличие от конкурентов, в DR550 не предусмотрено расширение количества серверов (или узлов) в рамках одной системы, и существует только одноузловая  или двухузловая конфигурация.

В качестве аппаратного обеспечения используются сервера IBM System p5 520 и массивы IBM System Storage DS4700.

Рис. 11. Взаимодействие с платформой архивации IBM DR550

Архитектура продукта

DR 550 состоит из одного или двух серверов IBM System p5 520 и дисковой подсистемы. Сервера работают под управлением ОС AIX и ПО IBM Storage Archive Manager. При использовании двух IBM System p5 520 они объединяются в HA-кластер. В качестве дисковой подсистемы используются массивы DS4700, подключенные через коммутатор FC или внутренние SCSI-диски серверов.

Взаимодействие прикладных систем с DR550 осуществляется через специализированное API – System Storage Archive API. Если приложение не поддерживает System Storage Archive API, то возможна интеграция через протокол NFS или CIFS. Для этого необходимо применение дополнительного продукта DR550 File System Gateway (см. рис. 11 ).

Рис. 12. Варианты конфигурации DR550

DR550 позволяет реализовывать конфигурации класса Disaster Recovery, в этом случае содержимое архива реплицируется на удаленную площадку с помощью ПО Enhanced Remote Mirroring (ERM). ERM обеспечивает репликацию данных по SAN между архивами как в синхронном, так и в асинхронном режимах.
Также необходимо отметить, что в отличии от конкурентов, DR550 не заявляет о поддержке дедупликации данных. Для увеличения емкости архива предлагается использовать магнитоленточные библиотеки с лентами формата WORM.

Конфигурация

IBM DR550 поставляется в семи различных конфигурациях в зависимости от требований к объемам архивного хранения и отказоустойчивости конфигурации. Существует две конфигурации с одним узлом и пять конфигураций с двумя узлами, объединенными в HA-кластер. Минимальная «сырая» емкость DR550 составляет 8 TB, максимальная – 112 TB.

Типовая конфигурация с одни узлом состоит из:

• один сервер IBM System p5 520 с одним двухъядерным процессором с тактовой частотой 1.9 GHz и 1024 MB RAM;
• массив IBM System Storage DS4700 с «сырой» емкостью 8 TB;
• FC коммутатор IBM SAN Switch 2005-B16;
• Hardware Management Console;
• монтажный шкаф IBM 7014-T00.

В случае отказоустойчивой конфигурации добавляется еще один сервер IBM System p5 520, сервера объединены в HA-кластер, в качестве кластерного ПО используется HACMP Cluster. Также дублируется FC-коммутатор (устанавливается еще один IBM SAN Switch 2005-B16) и дисковая подсистема (добавляется второй массив IBM System Storage DS4700).

В комплект программного обеспечения DR550 входят:

• HACMP Cluster Software (конфигурация ограничена 2 узлами);
• IBM System Storage Archive Manager v. 5.4;
• IBM System Storage DS4000 Storage Manager.

Магнитоленточная библиотека не включена в базовые конфигурации и должна заказываться отдельно. ПО архивации приложений и шлюз, обеспечивающий NFS/CIFS интерфейс к DR550 (DR550 FSG), также необходимо приобретать отдельно.

Помимо DR550 IBM предлагает облегченную версию продукта – IBM System Storage DR550 Express (далее DR550 Express), нацеленную на SMB рынок. Отличие DR550 Express от DR550 заключается в том, что вместо Fibre Channel используются SATA диски, а также отсутствует возможность построения HA-конфигураций. 

Минимальная емкость платформы архивирования DR550 Express составляет 1 TB (используются внутренние диски сервера), максимальная емкость – 9.1 TB.

Программное обеспечение и интеграция

Основой DR550 является ПО IBM System Storage Archive Manager, осуществляющий функции HSM и ПО архивирования (см. рис. 13 ). IBM System Storage Archive Manager базируется на IBM Tivoli Storage Manager (TSM), функционал которого расширен возможностями управления сроком хранения данных (retention policy) и функциями защиты содержимого архива. Первоначально продукт назывался IBM Tivoli Storage Manager for Data Retention, впоследствии был переименован в IBM System Storage Archive Manager (далее SSAM).

Рис. 13. Функциональная схема IBM System Storage Archive Manager

Взаимодействие приложений с SSAM возможно организовать тремя способами:

1. Через System Storage Archive API. Интерфейс через API является предпочтительным способом взаимодействия с DR 550, передача архивной информации производится через LAN. У IBM существует линейка продуктов, обеспечивающих архивирование данных приложения, используя System Storage Archive API. Это IBM DB2 Content Manger, IBM Common Store for SAP R/3, IBM Common Store for Lotus, IBM Common Store for Exchange.
2. Через File System Gateway. В этом случае от приложения не требуется поддержки API, взаимодействие происходит по протоколам NFS или CIFS. File System Gateway представляет собой выделенный сервер, работающий под управлением SLES Linux (в отличии от самого SSAM, функционирующего под AIX).
3. Через Tivoli Storage Manager Archive Client. Так как SSAM базируется на TSM, для архивирования файловых систем достаточно использования стандартного Tivoli Storage Manager Archive Client.

Для решения задачи резервного копирования DR550 IBM предлагает Disaster Recovery Manager, осуществляющей бэкап ОС, конфигурационной базы  и содержимого архива DR550 на магнитоленточную библиотеку.

SUN StorageTek 5800

Краткое описание

Первоначально SUN Microsystems на рынке платформ архивации был представлен продуктом Content Infrastructure System (далее SUN CIS). Наличие SUN CIS было всего лишь первым шагом на этот рынок, так как по своей сути CIS не являлось полноценной платформой архивации, а представляла собой типичный продукт для Hierarchical Storage Management (HSM). В качестве реальной платформы архивации, способной составить конкуренцию продуктам EMC, HDS, HP в SUN был разработан продукт SUN StorageTek 5800, ранее имевший кодовое название «Project Honeycomb». Продукт был анонсирован в ноябре 2007 года. SUN StorageTek 5800 имеет RAIN-архитектуру на базе серверов семейства SUN с процессором AMD Opteron. Отличительная особенность SUN StorageTek 5800 от конкурентов является возможность определения процедур встроенной обработки и преобразования архивных данных, а также полностью настраиваемая пользователем архива схема метаданных.

Архитектура продукта

SUN StorageTek 5800 (далее STK 5800) состоит из набора универсальных узлов хранения информации (storage node). В STK 5800 нет деления на узлы хранения и узлы доступа – все узлы одинаковы и равноправны между собой. Любой узел может принять и обработать произвольный клиентский запрос, то есть архитектура STK 5800 представляет собой классический RAIN.  

Storage Node представляют собой сервер Sun Fire X2100 в следующей конфигурации:

• процессор single core AMD Opteron c тактовой частотой 2.2 GHz;
• 4 GB RAM (1x1GB DIMM и 2x512MB DIMM);
• 4 SATA диска емкостью 500 GB;
• два встроенных интерфейса Ethernet 10/100/1000 Base-T.

Все Storage Node работают под управлением ОС Solaris 10 x86. Кроме узлов хранения в состав STK5800 входит сервисный процессор (service processor) на базе Sun Fire X2100M2, который используется для первоначальной конфигурации системы, централизованного управления, а также для модернизации ПО STK5800. Для доступа к данным архива сервисный процессор не используется. Для организации сетевого доступа используется два 24-х портовых Ethernet коммутатора с возможностью Load Balancing, объединенных в HA-кластер.

Рис. 14. Архитектура STK5800 
 

Каждая Storage Node хранит на себе как данные, так и метаданные пользовательского архива. Узлы хранения доступны внешнему миру только через общий виртуальный IP-адрес, при обращении к которому Ethernet коммутатор производит балансировку нагрузки, равномерно распределяя  запросы между Storage Node (см. рис. 14 ).

Интересной особенностью STK 5800 является схема распределения данных внутри платформы архивации. STK 5800 не использует внутренних RAID на узлах хранения и зеркалирования данных между узлами. Вместо этого данные архивации разбиваются на фрагменты, из которых создается распределенный программный RAID-6 формата 5D + 2P (пять фрагментов данных и 2 фрагмента контроля четности, используется алгоритм Reed Solomon, причем  алгоритм размещения данных гарантирует, что фрагменты будут размещены на 7 разных узлах STK 5800).

Подобная конфигурация гарантирует работоспособность системы при отказе любых двух компонент платформы – Storage Node или внутреннего диска.

Рис. 15. Схема работы алгоритма размещения данных в STK 5800 
 

Схема работы алгоритма размещения данных приведена на рис. 15 . При поступлении данных:

• Ethernet коммутатор направляет их на один из узлов хранения данных. Выбор узла производится путем применения хэш-функции к IP-адресу и порту отправителя запроса. Тем самым обеспечивается равномерная загрузка Storage Node.
• Выбранный узел хранения данных становится координирующим узлом для этих данных и производит разбивку поступивших данных на блоки и подсчет контрольных сумм (на рис. 15 это Data1-Data5 и Par.1 и Par.2).
• Координирующий узел выбирает семь дисков на семи разных узлах и записывает на них блоки данных и контрольные суммы. При размещении данных существует ограниченное количество вариантов размещения данных (около 10000 вариантов при размещении на 64 дисках), координирующий узел случайным образом выбирает один из возможных. Выбранный вариант (а вернее его номер) является идентификатором, который позволяет однозначно идентифицировать расположение блоков между Storage Node. Этот номер является частью идентификатора объекта (Object Identifier, OID), который возвращается клиенту после успешной операции записи данных в архив.

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

Побочным эффектом такого решения является то, что количество узлов в одной конфигурации не может быть меньше семи (фактически ограничение – минимально 8 узлов), но и не может быть очень большим, так как в этом случае количество вариантов размещения становится  чрезвычайно велико. На сегодняшний момент максимальное количество узлов в одной конфигурации равно 16 (или 64 диска).

Конфигурация

Как было описано выше, конфигурация STK 5800 определяется особенностями внутренней архитектуры. Максимально возможное количество одновременно работающих в рамках одной логической конфигурации узлов называется cell. Размер одного cell составляет 16 узлов, при этом емкость хранения cell составляет 32 TB «сырой» емкости (то есть без учета хранения контрольных сумм и метаданных).

Если для хранения архива требуется большая емкость, два cell могут быть объединены в один логический архив, подобное объединение называетcя hive. При объединении каждая из cell имеет информацию о конфигурации и загрузке другой cell (количество узлов, IP-адреса, утилизация дисков) и может перенаправлять поступивший запрос в наименее загруженный узел. С точки зрения клиента работа с hive выглядит точно также, как и работа с одним cell.

На сегодняшний момент SUN предлагает три возможных конфигурации STK 5800: Half Cell, Cell и Two Cell (см. табл. 2 ).

Объединение более чем двух cell в один логический архив на данный момент не поддерживается, поэтому максимально возможный объем данных в STK 5800 не  превышает 64 TB «сырой» емкости. STK 5800 поставляется в монтажном шкафу SUN Rack 1000 модели 1038 (38 RU), в конфигурации Two Cell монтажный шкаф полностью занят оборудованием.

Программное обеспечение и интеграция

Взаимодействие с платформой архивации STK 5800 осуществляется через API, существующее под JAVA и С. Кроме этого, STK 5800 имеет встроенную поддержку протокола WebDAV, что позволяет осуществлять просмотр содержимого архива через обычный WEB-браузер.

Табл. 2. Варианты конфигурации STK 5800 
 

Для интеграции с системами резервного копирования используется протокол NDMP. Однако в текущей версии STK 5800 реализовано только подмножество протокола NDMP (нет реализации Direct Access Recovery), поэтому восстановление данных архива имеет ограничения:

• данные архива могут восстанавливаться только полностью, частично восстановление данных невозможно;
• данные должны восстанавливаться на «чистую», свободную от данных конфигурацию.

Резервное копирование STK 5800 тестировалось SUN на платформе BackBone NetVault 7.4.5, упоминаний о совместимости с другими платформами резервного копирования на данный момент нет.

В отличие от основных конкурентов, STK 5800 пока что не имеет поддержки основных вендоров продуктов управлением архивацией (например, CA Message Manager, Symantec Enterprise Vault, CA File System Manager, Open Text и т.п.). Также не существует шлюзов NFS/CIFS и агентов архивации таких приложений, как
MS Exchange, Lotus Notes и т.п.

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

• WORM Storage;
• управление длительностью хранения данных (Retention Periods);
• контекстный поиск по содержимому архива.

Также на данный момент отсутствует поддержка технологии Storage Beans для STK 5800.

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

Необходимо отметить, что SUN также предоставляет в свободном распространении эмулятор STK 5800 и SDK к нему, что позволяет разрабатывать решения для этой архивной платформы, не приобретая для этого дополнительное оборудование.

Несмотря на относительно недавний анонс STK 5800 v.1.1.1, 30 сентября 2008 SUN Microsystems объявил о переходе на другую платформу архивации данных. Будет ли это новая версия или принципиальные изменения в продукте – пока не известно.

Network Appliance SnapLock

Краткое описание

Продукт NetApp SnapLock анонсирован компанией Network Appliance в 2003 году. NetApp SnapLock (далее SnapLock) представляет собой программный комплекс, работающий на платформе Data ONTAP и файловой системе WAFL.  Функционально SnapLock является одним из модулей операционной системы Data ONTAP, основным назначением которого является реализация WORM – хранилища на линейке массивов Network  Appliance. Никаких архитектурных модификаций существующего аппаратного обеспечения SnapLock
не производит.

Архитектура продукта

Как было сказано выше, SnapLock является отдельно лицензируемым программным модулем операционной системы Data ONTAP. В отличие от платформы EMC, SnapLock не требует применения специального API для взаимодействия с архивом, архив на базе SnapLock доступен приложением по протоколу NFS или CIFS (см. рис. 16 ).

Рис. 16. Схема работы с платформой архивации SnapLock 
 

Защита данных архива обеспечивается средствами аппаратной платформы, это может быть RAID-4 или RAID-DP (аналог RAID-6). Также возможна удаленная репликация WORM-архивов на базе SnapLock средствами ПО SnapMirror. SnapLock поддерживает программную дедупликацию архивных данных, используя фирменную технологию A-SYS (Advanced Single Instance Storage).

Конфигурация

Продукт SnapLock доступен в двух вариантах: SnapLock Compliance и SnapLock Enterprise. SnapLock Compliance обеспечивает соответствие нормативным требованиям к хранению данных, предписанных для бирж и брокерских компаний (SEC Rule 17a-4), медицинских учреждений (HIPAA), бизнеса (Sarbanes-Oxley), производства продуктов питания и фармацевтики (21CFR часть 11) и государственных учреждений (DOD 5015.2). Удаление данных или изменение архивной информации ранее установленного срока хранения в SnapLock Compliance штатными средствами невозможно, за исключением физического уничтожения или порчи дисков.  SnapLock Enterprise отличается от SnapLock Compliance тем, что администратор имеет возможность целиком удалить том SnapLock раньше установленного срока хранения. При этом возможность модификации или удаления отдельных архивных записей также отсутствует.

Емкость хранения архива на базе SnapLock определяется емкостью платформы, на которую устанавливается эта лицензия. В качестве платформы может использоваться как семейство NetApp FAS, так и NetApp NearStore.

Программное обеспечение и интеграция

В состав SnapLock не входят продукты контекстного поиска по архиву и модули архивации приложений. Для обеспечения возможности контекстного поиска необходимо приобретение платформы NetApp Information Server 1200. NetApp Information Server 1200 производит индексирование и предоставляет возможность контекстного поиска по архиву на базе SnapLock. Модулей архивации приложений (например, почтовых систем) Network Appliance не разрабатывает, необходимо приобретение продуктов сторонних производителей.

Для интеграции с системами резервного копирования используется протокол NDMP, также возможно организовать дисковое резервное копирование на хранилище NetApp NearStore, для этого необходимо приобретение продукта SnapVault.

Заключение

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

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

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

Табл. 3. Сводная таблица платформ архивации 
 

При наличии явных достоинств, приведенных выше,  внедрение и использование платформ архивации сопряжено с рядом проблем:

• Внедрение архивной платформы требует больших трудозатрат – необходимо разработать модули сопряжения архивируемых приложений с API платформы (если их нет) или обеспечить взаимодействие через сущест­вующие программные модули управления архивацией. И в том, и в другом случае это достаточно трудоемкий процесс.
• Скорость работы платформы архивации по сравнению с классическими FC массивами заведомо невелика по ряду причин.  Взаимодействие производится только по LAN,  что сразу ограничивает пропускную способность одного потока архивации (или чтения данных ) пропускной способностью TCP/IP по 1GE (это в среднем 50-60 МБ/сек). Кроме записи данных, запись в архив сопровождается записью метаданных, а также внутренними дисциплинами работы платформы архивации (программные RAID, индексация метаданных и т.п.). Из-за этого скорость работы платформы сильно зависит от характера архивируемых объектов (наиболее «неприятный» характер данных для архивной платформы – большое количество объектов небольшого размера). Таким образом, пропускная способность платформы может сильно меняться в зависимости от характера данных, поэтому  поставщики архивных платформ  измеряют скорость работы систем архивации  в количестве сохраненных объектов за определенный промежуток времени.
• Емкость архива, в отличии от дисковых массивов, не может быть предоставлена в виде обычных LUN другим системам. То есть купленное «про запас» дисковое пространство в архивной платформы нельзя использовать для других целей или произвольных систем.

Таким образом, можно определить несколько областей, где возможно эффективное применение платформ архивации. Первой и наиболее очевидной областью является архивирование электронной почты и финансовой документации,  наиболее распространенная ниша применения подобных платформ. Интерес к этому решению должен быть в первую очередь у коммерческих банков и компаний, чьи акции торгуются на американских биржах. Интерес первых к архивации электронной переписки обусловлен документом Банка России «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения», интерес вторых – необходимостью выполнять требования SOX.

Второй областью применения платформ архивации является интеграция подобных систем в собственные программные и проектные решения компании, например, применение архивных платформ в качестве одной из компонент заказных решений по документообороту. В этом случае архивная платформа замещает собой связку «Сервер СУБД – ПО СУБД – Собственное ПО», что позволяет быстро организовывать хранилище документов с готовой иерархической структурой и возможностями поиска по архиву. Например, в STK 5800 присутствует штатная возможность организации виртуальных иерархических файловых систем с отображением их через WEB-интерфейс. В качестве элементов иерархической структуры используются метаданные, в качестве протокола взаимодействия – протокол HTTP. Ниже приведен пример для платформы STK 5800. В архив добавляются MP3 файлы, в качестве метаданных каждый файл имеет атрибуты «artist» и «album», «year». Администратор определяет ряд виртуальных файловых систем с требуемой иерархией, например, «by Artist», «by Album», «by Year».  Пользователь «видит» эту файловую систему через WEB-браузер и имеет возможность перемещения по заданной иерархии: Преимущества применения очевидны – это отсутствие затрат на покупку и поддержку СУБД и меньшие затраты на разработку собственного ПО. Ограничением является то, что изменение данных в архиве невозможно, и для оперативной работы с данными подобные решения не подходят.

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

Вместе с тем необходимо отметить, что широкого распространения платформы архивации у нас (имеется ввиду Россия и СНГ) пока что не получили. На западном рынке внедрение таких систем, как правило, обусловлено нормами различных регулирующих актов, предъявляющих требования к хранению и доступности информации (например, требования SOX, см. раздел «Нормативные требования к хранению данных»). Так как на данный момент подобных обязательных требований к коммерческим структурам в российском законодательстве не наблюдается, нет и большого спроса на платформы архивации данных.  Тем не менее интерес к подобным решениям у ряда коммерческих структур (например, банков) и федеральных структур есть. Это обусловлено наличием рекомендательных нормативных актов РФ, в частности Федеральным Законом «Об архивном деле в Российской Федерации» и рекомендательным документом «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения». Кроме этого, применение платформ архивации данных может быть целесообразно во внутренних проектах компаний и заказных  разработках.

Приложение A Нормативные требования к хранению данных

Сводная таблица требований к хранению данных

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

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

Табл. 4. Сводная таблица требований к хранению данных 
 

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

Sarbanes-Oxley Act

Sarbanes-Oxley Act (далее SOX) является федеральным законом США, принятым 30 июля 2002. SOX значительно ужесточает требования к финансовой отчетности и к процессу ее подготовки – результат многочисленных корпоративных скандалов, связанных с недобросовестными менеджерами крупных корпораций.

Согласно этому закону все предприятия, которые либо представлены на фондовом рынке США, либо планируют выйти на эти рынки, должны в обязательном порядке соответствовать требованиям SOX в сфере создания эффективной системы внутреннего контроля при составлении финансовой отчетности, а также отчитываться в надежности и достоверности данной финансовой отчетности. Закон требует регламентации процедур тестирования и мониторинга всей внутренней системы контроля рисков, влияющих на качест­во финансовой отчетности. Компании должны подтвердить наличие эффективных механизмов контроля для всех процессов, имеющих отношение к отчетности, и проводить регулярный аудит.

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

Как минимум четыре следующих параграфа раздела имеют прямое отношение к деятельности ИТ-подразделений компаний:

• параграф 302 требует от генерального и финансового директоров проверки финансовой отчетности компании на точность и полноту;
• параграф 404 требует от генерального и финансового директоров, а так же от сторонних аудиторских организаций, периодически подтверждать эффективность внутренних механизмов контроля финансовой отчетности;
• параграф 409 требует от компании максимально быстро отчитываться в любых изменениях финансовых условий, а также сообщать об этом инвесторам (как правило от 24 до 48 часов);
• секция 803 требует, чтобы компании и внешние подрядчики, отвечающие за аудит, хранили бухгалтерские документы, финансовые отчеты и другие виды рабочих бумаг в течение минимум 7 лет.

Предписание для бирж и брокерских компаний

Комиссия по ценным бумагам США (Securities and Exchange Commission, далее SEC) в 2004 году ужесточила требования SOX для компаний, работающих в сфере финансовых услуг. Согласно постановлению SEC Rule 17a-4 все финансовые фирмы обязаны сохранять переписку с клиентами в виде базы данных. Эта база должна соответствовать нормативам по таким параметрам, как поиск и проверка информации, поддержка и архивирование. Срок хранения данных в архиве должен быть не менее 3 лет. Компании также должны обеспечить аутентичность электронных сообщений, сохраняемых в базе.

HIPAA

Закон HIPAA (Health Insurance Portability and Accountability Act) был принят в США в 1996 году. В сферу его деятельности попадают абсолютно все американские компании, хранящие или каким-либо образом обрабатывающие приватные медицинские сведения граждан. Это, прежде всего, страховые компании и учреждения здравоохранения, а также любые посредники, также имеющие доступ к приватным медицинским сведениям.

В рамках закона HIPAA действует целый ряд обязательных стандартов, среди которых следует отметить Security и Privacy Rule. Согласно требованиям этих стандартов все медицинские, страховые и финансовые организации, работающие с чувствительной медицинской информацией, обязаны хранить не менее 6 лет с момента создания или последнего использования всю свою электронную документацию.

Директива Евросоюза о сохранении данных

Директива Евросоюза о сохранении данных (Data Retention Directive, далее DRD) была утверждена в конце 2005 года на волне борьбы с терроризмом. DRD требует от телекоммуникационных компаний, занимающихся бизнесом на территории Европы, архивировать и хранить в течение минимум одного года все данные, передаваемые по электронным каналам связи. Под действие закона попадают переговоры через мобильные и проводные телефоны, обмен документами по факсу, а также любой обмен информацией в Интернете. Авторы директивы особо отмечают необходимость создания архивов электронной корреспонденции в связи с распространенностью этого способа коммуникаций.

Федеральный Закон  «Об архивном деле в Российской Федерации»

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

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

Стандарт Банка России

Данный стандарт на сегодняшний момент носит рекомендательный характер. Но тем не менее, согласно этому документу всем банкам РФ рекомендуется вести архив электронной почты и обеспечить его неизменность, а также контроль доступа к собранной архивной информации.
Вполне возможно, что по мере развития банковского сектора требования к архивации электронного обмена перерастут из рекомендательных в обязательные. В частности сам документ содержит прямое указание на то, что это может случиться. «Настоящий стандарт может быть введен в действие организаций БС РФ в качестве обязательного к исполнению в случае, если такая необходимость существует», – предупреждают авторы стандарта.

Список используемой литературы

При подготовке документа использовалась следующая литература:

• «Analysis of the EMC Centera», Evaluator Group;
• «EMC Centera Universal Access», EMC Data Sheet;
• «EMC Centera Backup and Recovery Module», EMC Data Sheet;
• «EMC Centera Product Brief», Enterprise Storage Group;
• «Active Archive Solution Brief», Hitachi Data Systems;
• «Hitachi Content Archive Platform Data Sheet», Hitachi Data Systems;
• «Hitachi Content Archive Platform Research Study», Data Mobility Group;
• «Hitachi Content Archive Platform Technical Brief», Hitachi Data Systems;
• «Hitachi's New Generation Active Archive Platform», IT Centrix White Paper;
• «HP Reference Information Storage System Architecture Overview», Data Mobility Group;
• «HP Reference Information Storage System Quick Specs», HP
• «HP Storage Works Grid Technical White Paper», HP
• «SUN Customer Ready Content Infrastructure System Datasheet», SUN Microsystems;
• «SUN StorEdge QFC and SAM-FS Software Technical Overview», SUN Microsystems;
• «SUN STORAGETEK 5800 SYSTEM ARCHITECTURE», SUN Microsystems;
• «SUN StorageTek 5800 System Administration Guide», SUN Microsystems;
• «SUN StorageTek 5800 System Client API Reference Manual», SUN Microsystems;
• «SUN StorageTek 5800 System Next Generation Fixed Content Storage», SUN Microsystems White Paper;
• «IBM System Storage DR550 Setup and Implementation», IBM;
• «IBM System Storage DR550 Data Sheet», IBM;
• "IBM System Storage DR550 Backup and Restore», IBM;
• «Understanding JIC Data and Information Lifecycle Management», IBM;
• «IBM System Storage DR550 Express Data Sheet», IBM;
• «Infrastructure Solutions. Electronic Discovery for Litigation Request», Network Appliance;
• WEB информация, доступная на сайтах производителей платформ архивирования, а также информация с сайта www.cnews.ru.

Перечень принятых сокращений