Организация иерархического хранения данных с помощью службы Microsoft RSS

На первый взгляд это всего лишь «косметический ремонт», однако при ближайшем рассмотрении становится ясно, что разработчики Microsoft добавили к характеристикам NTFS набор свойств, которые скрыты от поверхностного взгляда, но на самом деле предоставляют администраторам систем ряд ценных возможностей по обслуживанию хранения данных в сетях масштаба предприятия. На страницах Windows 2000 Magazine/RE было уже немало рассказано об этих новых функциях, в том числе о шифровании, ведении протокола работы, об использовании reparse points. Для более подробного ознакомления с названными возможностями рекомендуем обратиться к статье Шона Дейли «NTFS5 против FAT32», опубликованной в этом же номере журнала.

Hовая характеристика - reparse points - может показаться несущественной, но именно она позволяет задействовать одну из передовых технологий хранения информации в сети - иерархическое хранение данных. Администратор, избравший иерархический подход, во всяком случае теоретически, становится обладателем хранилища неограниченного объема, доступ к которому возможен в любое время. Разработчики Microsoft постарались реализовать эту технологию так, чтобы работать с хранилищем данных было удобно и просто.

Иерархический менеджмент хранения данных

Рисунок 1. Процесс извлечения файла с помощью reparse points.

Для того чтобы овладеть принципами работы иерархического хранения, нужно сначала разобраться, что представляют собой так называемые точки монтирования (reparse points) и как они функционируют в среде Windows 2000 Server. Сразу хочу пояснить, что я буду рассматривать reparse points как некий специальный объект NTFS. Когда операционная система или пользователь запрашивает файл или каталог, файловая система на самом деле получает от reparse points сообщение примерно следующего содержания: «Вместо того чтобы разыскивать файл (или каталог) здесь, попробуй обратиться в другое место». Файловая система «не возражает» и извлекает файл (или каталог) из альтернативного местоположения. Поскольку операционная система или пользователь обратились ко вполне определенному месту, файл будет предоставлен в их распоряжение именно оттуда, но его реальное местонахождение будет отличаться от указанного. Рисунок 1 иллюстрирует описанный процесс извлечения файла.

Операционные системы на базе UNIX обладают такой функциональностью вот уже несколько лет. Технология reparse points очень важна, поскольку Microsoft собирается вывести свою систему Windows 2000 на рынок промышленных приложений, а это означает, что нужно продемонстрировать функциональность, связанную с иерархическим хранением данных. Даже крупные, а тем более мелкие, организации не могут позволить себе (да им это и не нужно) хранить всю историю используемых данных в оперативном режиме 24 ч в сутки. Следовательно, служба удаленного хранения Remote Storage Service (RSS) - это та долгожданная возможность для промышленных систем, которую разработчики Microsoft реализовали в операционной системе Windows 2000 Server.

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

Технология Hierarchical Storage Management (HSM) - управления иерархической структурой хранения информации - позволяет автоматизировать весь описанный процесс. В соответствии с принципом построения HSM, имеется два типа систем хранения. Назовем их для наглядности хранилищем оперативного доступа и хранилищем почти оперативного доступа. Хранилище оперативного доступа, как правило, состоит из нескольких жестких дисков и других, относительно дорогих носителей, данные с которых можно получить практически мгновенно. Хранилище почти оперативного доступа создается, например, на магнитных лентах, и стоимость носителей в нем существенно ниже, чем для оперативного хранилища, но и доступ к данным при этом происходит медленнее. Технология HSM подразумевает, что доступ к носителям информации осуществляется без вмешательства человека. Поскольку отдельно хранящийся архив данных на лентах (неоперативного доступа) требует ручных манипуляций, хранилище этого типа в HSM использоваться не может.

В Microsoft для обозначения хранилищ оперативного доступа и почти оперативного доступа применяются термины «локальное хранилище» (local storage) и «удаленное хранилище» (remote storage), и далее по ходу статьи я буду использовать именно их.

Программное обеспечение, реализующее функции HSM, в процессе анализа файлов, расположенных в разделе NTFS, устанавливает, какие именно файлы можно передвинуть из локального хранилища в удаленное, а затем физически перемещает эти файлы - и все это без вмешательства оператора. Специалисты Microsoft лицензировали эту технологию у VERITAS Software и «упаковали» в сервере Windows 2000 уже как службу Microsoft RSS.

Служба удаленного хранения

Служба RSS играет важную роль в операционной системе Windows 2000 Server. Фактически, именно с помощью RSS осуществляется надзор за локальными носителями (читай - дисками) сервера и перемещение данных, если диски переполняются. RSS перемещает данные в удаленное хранилище, после чего в прежнем месте хранения файла размещает reparse points. Предположим, что имеется локальное хранилище объемом 8 Гбайт и удаленное хранилище в 24 Гбайт, реализованное на DAT-устройстве с лентой 12/24 Гбайт. Теоретически, с точки зрения конечного пользователя, хранилище имеет размер 32 Гбайт, поскольку в тот момент, когда он запрашивает файл, который какое-то время тому назад мигрировал, служба RSS извлекает этот файл из удаленного хранилища и восстанавливает его в локальном хранилище по зарезервированному для него адресу. Имея надлежащее аппаратное обеспечение, администратор сервера без особого труда раздвинет границы своих хранилищ данных, не обращаясь к архиву лент.

Удаленное хранилище

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

Служба RSS способна взаимодействовать далеко не со всяким ленточным накопителем. Согласно сопроводительной документации Microsoft, RSS поддерживает все ленточные DLT-библиотеки класса 4 мм и 8 мм, подключаемые как SCSI-устройства. В данном случае под библиотекой подразумевается и автоматическое мультимедийное устройство со множеством накопителей, и устройство с одним-единственным накопителем, которое управляется вручную. Корпорация Microsoft не обеспечила поддержку QIC-библиотек (библиотек с четвертьдюймовым картриджем, т. е. картриджем с магнитной лентой шириной 6,3 мм) и оптических библиотек - досадное исключение, так как магнитооптические носители получают все более широкое распространение. Тем же из потенциальных заказчиков, кому предстоит работать с магнитооптикой в качестве удаленного хранилища, остается только поискать на рынке программного обеспечения подходящий HSM-продукт производства независимых компаний.

Установка RSS

Предположим, у администратора сервера имеется надлежащее ленточное устройство. Он может сразу же приступать к работе со службой RSS. Если к этому моменту соответствующее приложение на сервере еще не установлено, запускается модуль Add/Remove Programs в Control Panel и выбирается закладка Add/Remove Windows Components. В ней нужно выбрать пункт Remote Storage, после чего выполнить установку службы RSS. При подготовке статьи я использовал следующую конфигурацию: Windows 2000 Server на компьютере Compaq с внешним SCSI-устройством HP SureStore 12/24GB DAT. Если на Windows 2000 Server ленточное SCSI-устройство (в виде отдельного устройства или библиотеки) установлено и работает, можно начинать знакомиться со службой RSS, запустив Remote Storage из группы Administrative Tools.

Когда служба RSS стартует, мастер Remote Storage Setup Wizard предлагает сообщить системе, какое именно ленточное устройство пользователь планирует задействовать в качестве удаленного хранилища. В том случае, когда совместимое с RSS устройство в системе отсутствует, процедура установки на самом первом шаге - при попытке обнаружить подходящее устройство - выдаст ошибку. Если же первый шаг завершен успешно, обнаруженное в системе ленточное устройство будет работать со службой RSS нормально.

Экран 1. Задание основных рабочих параметров для RSS.

Далее Remote Storage Setup Wizard запрашивает сведения о том, какие именно тома NTFS предстоит обслуживать. В контексте RSS понятие «том обслуживания» означает обычный раздел NTFS, мониторинг которого выполняется службой RSS и с которого в случае необходимости производится перенос файлов. RSS может осуществлять управление на любом числе томов NTFS (но только не FAT или FAT32: эти файловые системы не поддерживают reparse points). Нужно указать те тома NTFS, которые должны обслуживаться RSS, затем щелкнуть на кнопке Next. Откроется диалоговое окно Volume Settings, изображенное на Экране 1.

Примерно 80% конфигурационных установок RSS выполняется на этом шаге, в диалоговом окне Volume Settings. Для выбранного тома нужно задать условия проведения миграции файла из локального хранилища в удаленное, которыми будет руководствоваться RSS. Чтобы процесс миграции выполнялся корректно, необходимо предварительно ознакомиться с его логикой.

RSS выполняет мониторинг тома обслуживания, выясняя, сколько на нем осталось свободного пространства, и составляет список файлов, доступ к которым пользователи до сих пор не осуществляли. Каждому подпроцессу в рамках общего процесса мониторинга соответствует некоторая специфическая функция, а все вместе они и реализуют то, что принято называть HSM-технологией. Во-первых, во время мониторинга система устанавливает, к каким файлам в последнее время не было обращений. Если в течение х дней (значение, которое администратор системы задает в окне Volume Settings в поле Not accessed in: __ days) к файлу обращений не было, RSS выполняет превентивную миграцию (premigrate) файла из локального в удаленное хранилище. Другими словами, RSS копирует файл в удаленное хранилище (скажем, на ленту), но из локального хранилища (с диска) пока не удаляет. Вместо этого для данного файла выставляется флажок premigrate.

Деятельность RSS становится заметной лишь тогда, когда пространство на томе становится критически важным фактором. Если свободное пространство на томе опускается ниже предельного порога на х% (задается в поле Desired free space), служба RSS начинает перемещать файлы, помеченные флажком premigrate, из локального хранилища в удаленное, а на их место подставляет reparse points NTFS. Следовательно, если процент использования дискового пространства внезапно возрастает, службе RSS ничего особенного делать не приходится. Требуемые файлы уже помечены к переносу, и для поддержания надлежащего уровня использования дискового пространства остается только удалить их из локального хранилища и установить reparse points на место, где находились удаленные файлы. Эта процедура протекает очень быстро, поэтому RSS в состоянии моментально отреагировать на внезапное сокращение объема свободного дискового пространства.

Последний параметр, который нужно установить в окне Volume Settings, - это минимальный размер файла для миграции. Значение по умолчанию равно 12 Кбайт. Вероятнее всего, оно подходит для большинства случаев. Но если нужно, администратор может вручную произвести полную инвентаризацию файловой системы сервера. Можно явно указать, какое количество файлов данного размера должна иметь система и каков средний размер файла. Понятно, что миграция файлов размером 1 Кбайт на ленту скорее всего не будет замечена вовсе, так как трудно ожидать сколько-нибудь заметного воздействия на производительность системы от перемещения столь малого файла, а повлиять нужно на производительность системы в целом. Следует выбрать подходящее число перемещаемых файлов для конкретных условий работы, а затем щелкнуть Next для перехода к следующему шагу процедуры установки Remote Storage Setup Wizard.

В окне Media Type указываются сведения о типе носителя, предназначенного для удаленного хранилища. При этом нельзя использовать тот же самый тип устройства, что и для обычной штатной процедуры резервирования, поскольку ленты для работы со службой RSS должны быть всегда смонтированы. Выбрав тип носителя, нужно в последний раз щелкнуть Next, и Remote Storage Setup Wizard завершается.

Инициализация носителя

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

Перед тем как инициализировать носитель, нужно сперва убедиться в том, что в соответствующем устройстве находятся именно те ленты, которые предполагается использовать для RSS. Затем следует проверить, появились ли эти ленты в snap-in-модуле Remote Storage консоли управления Microsoft Management Console (MMC). Для этого нужно открыть в каталоге Removable Storage подкаталог Physical Locations (под значком системного ленточного устройства). Несмотря на то что модуль Removable Storage обнаруживает в системе ленточное устройство, нужно специально оговорить возможность применения именно этого ленточного устройства. Для того чтобы служба RSS могла использовать данные с ленты, достаточно скопировать значок того носителя, который предполагается выделить для иерархического менеджмента данных в объект Media Pools, Free. Для системы Windows 2000 Server и службы RSS это действие будет означать, что ленты доступны для иерархического обслуживания. Затем Windows 2000 инициализирует их, и вот, наконец, служба RSS полностью готова к работе.

Настройка томов обслуживания

Экран 2. Изменение настроек RSS.

В зависимости от применяемых в организации приложений, администратору системы может потребоваться выполнить тонкую подстройку параметров RSS, например сообщить что-то новое о томах обслуживания. Через snap-in Remote Storage консоли управления MMC сделать это очень просто.

Для настройки общих параметров следует перейти в левую панель Remote Storage и щелкнуть правой кнопкой мыши на Remote Storage. Выбрав пункт меню Properties, откроется страница Remote Storage (Local) Properties, как это показано на Экране 2. С помощью четырех закладок, представленных на этой странице, администратор может определить объем данных, переносимых в удаленное хранилище, поменять время и частоту активизации службы RSS (по умолчанию устанавливается ежедневный запуск службы в 2 ч ночи) и, наконец, изменить параметры настройки носителя удаленного хранилища.

Экран 3. Изменение настроек для конкретного тома.

Вполне возможно, что в дальнейшем может потребоваться внести изменения в настройки отдельного тома. Для этого в левой панели окна Remote Storage нужно выбрать объект Managed Volumes, раскрыть контекстное меню данного тома и обратиться к свойствам тома (Properties). Как изображено на Экране 3, индивидуальные свойства томов обслуживания могут изменяться, и для различных типов данных при желании устанавливаются различные типы параметров переноса. В приведенном примере я модифицировал свойства диска Е, чтобы в любой момент времени гарантировать наличие на диске 50% свободного пространства, а также то, что любые файлы размером более 10 Кбайт, к которым никто не обращался за последние 24 ч, могут быть перенесены.

Тестирование RSS

Экран 4. Просмотр статистики переноса файлов.

После активизации служба RSS начинает помечать файлы для переноса на магнитную ленту. Действия RSS регистрируются в системном журнале событий, его можно всегда просмотреть с помощью приложения Event Viewer или через snap-in Remote Storage в MMC. Чтобы заставить RSS выполнить реальную миграцию помеченных специальным флажком файлов, я скопировал около 500 Мбайт новых данных на диск Е. Как и ожидалось, объем свободного пространства упал ниже 50% уже во время процесса копирования, но вскоре был восстановлен, после того как RSS переместила из системы помеченные файлы и заменила их соответствующими reparse points.

Экран 5. Ожидание обратного переноса файла.

Затем мне захотелось убедиться в правильности функционирования RSS. Для этого я решил отыскать некоторые файлы, которые были полностью перенесены из моего локального хранилища (не просто помечены флажком «превентивная миграция», а действительно перемещены с диска), и попробовать вернуть их обратно. Чтобы отыскать такой файл или каталог, нужно просто обратиться к странице Properties искомого объекта (см. Экран 4). Если служба RSS уже перенесла данный файл, то сразу видна разница в значениях Size и Size on disk. (Так, в моем примере приблизительно половина системного каталога i386 перенесена на ленту.) Отыскав перенесенный файл, я скопировал его на рабочий стол своей станции. Штатная функция копирования Windows 2000 начала было свой обычный процесс, но служба RSS быстро вмешалась и раскрыла диалоговое окно, представленное на Экране 5. Мне было предложено подождать, пока система не восстановит искомый файл из удаленного хранилища.

Перемещение пятимегабайтного файла с устройства 12/24 Гбайт DAT заняло около минуты. (Интересно, что основное время было потрачено на разгон ленты и ее сканирование для определения местонахождения файла.) Согласитесь, что одна минута - не слишком долго, но, вот если администратор решит предоставить поддержку службы RSS своим пользователям, обязательно нужно будет учесть такого рода задержки, изначально присущие RSS. Если выполнение пользовательского приложения приостанавливается на время извлечения заархивированных файлов из удаленного хранилища, многие пользователи сети наверняка кинутся звонить в службу технической поддержки. Прежде чем разворачивать RSS в «боевых условиях», следует протестировать ее работу в экспериментальной среде, приближенной к промышленной с точки зрения часто используемых в сети приложений.

RSS не заменит Backup

В этой статье не обсуждаются вопросы резервирования данных, тем не менее надо ясно себе представлять, что RSS не заменит рутинную процедуру резервирования данных системы. Так как процедура миграции RSS не в состоянии охватить все системные файлы (и, между прочим, при всем желании не сможет перенести каталог winnt), то нельзя будет использовать эту службу и для восстановления системы. Старая добрая технология резервирования по-прежнему остается незаменимой.

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

ОБ АВТОРЕ

Дуглас Тумбс - редактор Windows NT Magazine, имеет сертификаты NetArchitect Consulting, MCSE, Compaq ASE и Novell CNA. Соавтор готовящейся к выпуску книги «Mastering Windows 2000 Server» (издательство Sybex). С ним можно связаться по электронной почте по адресу: doug@netarchitect.com.