Назначение и принципы работы систем иерархического хранения данных.

Аксиома сетевых администраторов гласит: "Сколько дисков на сервере ни ставь, все равно будет мало". Неимоверно раздутые прикладные программы, активное использование графики и мультимедиа, увеличение количества обрабатываемой информации - все это приводит к тому, что дисковой памяти никогда не бывает много.

В издательстве "Открытые системы" дисковая память на серверах за год выросла с 10 до 100 Гбайт, но, как и прежде, ощущается ее острый дефицит. Тот объем дисковой памяти, который еще год назад казался пределом мечтаний, сейчас представляется явно недостаточным. Подключение новых винчестеров превращается в постоянное занятие администраторов.

Хотя цены на жесткие диски снижаются, их емкость увеличивается, а надежность повышается, последовательное увеличение дисковой памяти чревато несколькими неприятными последствиями. Несмотря на низкую стоимость винчестеров (в Москве диск SCSI на 18 Гбайт стоит менее 800 долларов), большие массивы дисков стоят немало. Кроме самих винчестеров они содержат стойки для накопителей, средства повышения отказоустойчивости, контроллеры и т. д. Надежность дисковой системы понижается с каждым новым винчестером или дисковым массивом.

Увеличение дискового пространства влечет за собой увеличение объема оперативной памяти. Это связано с тем, что для повышения скорости обмена данными часть оперативной памяти отводится под кэш. И чем больше дисковая система, тем больший кэш должен ее обслуживать. Например, в операционной системе NetWare оптимальное соотношение между объемом оперативной памяти и размером дисковой системы следующее: на каждый гигабайт дискового пространства должно приходиться 16 Мбайт оперативной памяти. Как следствие, дисковую систему на одном сервере невозможно увеличивать бесконечно, поэтому в сети требуется устанавливать все новые и новые серверы.

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

БОРЬБА С НЕХВАТКОЙ ДИСКОВОГО ПРОСТРАНСТВА

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

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

Еще одним достаточно популярным методом борьбы с нехваткой дисковой памяти является архивирование информации (более подробно см. "ПО резервирования глазами администратора" в LAN № 7-8 за 1998 год). При таком методе неиспользуемые файлы переносятся на магнитные ленты, сами же файлы на первичном носителе удаляются. Это недорогой и эффективный метод, но у него есть ряд принципиальных недостатков.

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

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

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

Для обработки больших объемов нерегулярно используемой информации лучше подходят системы иерархического хранения данных (Hierarchical Storage Manager, HSM). В системе HSM все файлы доступны в любой момент времени. При этом редко используемые файлы автоматически переносятся с винчестеров на более медленные и менее дорогие носители (магнитооптические диски, диски WORM, магнитные ленты). Когда пользователь обращается к данным файлам, они автоматически копируются обратно на жесткие диски. Таким образом, хранилище HSM, с точки зрения пользователя, выглядит как огромного размера дисковая система. На Западе подобные системы весьма популярны, но в России они малоизвестны.

Системы HSM активно используются в крупных и средних западных компаниях. Чем же вызвана такая популярность? Дело в том, что HSM - сравнительно недорогое решение для хранения больших объемов информации. Пользователь всегда имеет возможность обратиться к любому файлу независимо от того, когда он был создан. Единственная проблема - это небольшая задержка по времени (от 5 до 80 секунд) при доступе к файлам, к которым давно никто не обращался.

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

УРОВНИ ИЕРАРХИИ HSM



Рисунок 1. Типичная схема хранилища HSM.

Системы HSM включают два или три уровня хранения информации (максимальное количество уровней зависит от конкретной используемой системы HSM). На Рисунке 1 показана типичная схема хранилища HSM. Иногда в состав системы HSM включают четвертый уровень, который представляет собой носители, выведенные из интерактивного использования и хранящиеся отдельно. Но обычно этот уровень не учитывается.

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

Первый уровень иерархии - это обычные жесткие диски. Винчестеры могут применяться и на других уровнях иерархии, но чаще всего здесь используют следующие виды носителей: магнитооптические диски, оптические диски с однократной записью (Write Once Read Many, WORM) и магнитные ленты. Однако эти носители имеют сравнительно небольшую емкость, поэтому для HSM обычно применяют библиотеки таких носителей. Тем не менее ничто не препятствует использованию одиночных накопителей и стримеров.

Каждый вид носителей характеризуется следующими основными особенностями.

Жесткие диски являются самым быстрым типом носителя, к тому же винчестеры достаточно вместительны. Емкость современных дисков достигает 25 Гбайт и более. Но винчестер выступает не только как носитель, но и как накопитель (дисковод). Поэтому их общая надежность самая низкая, а цена - высокая. С учетом стоимости сопутствующего оборудования цена может достигать 0,2 доллара за один мегабайт и даже более. Среднее время доступа составляет около 10 мс.

Магнитооптические (МО) диски до недавнего времени считались более дешевыми, чем винчестеры. Однако появление новых технологий записи на жесткие диски и снижение их стоимости не позволяют утверждать это столь категорично. Правда, надежность дисков МО выше, чем у винчестеров. Емкость дисков МО достигает 5,2 Гбайт, что явно недостаточно для современных приложений. Вместе с тем библиотеки МО способны хранить от нескольких десятков до нескольких сотен гигабайтов информации. Тем не менее размер файла в МО не может превышать 2,6 Гбайт, так как он весь должен помещаться на одной стороне диска. Библиотека имеет в своем составе один или несколько накопителей и специальное устройство подачи дисков в накопители, называемое роботом. Такая архитектура значительно увеличивает стоимость системы на основе МО. Стоимость мегабайта информации достигает 0,15 доллара. Чем больше библиотека по вместимости, тем более ощутима отдача от нее. Время доступа к файлу составляет в среднем 5-10 секунд из-за задержки на загрузку диска в накопитель. МО наиболее часто используют в качестве второго уровня HSM.

Диски WORM имеют несколько меньшую стоимость в пересчете на мегабайт, чем МО. Данные на диске WORM нельзя перезаписывать, поэтому WORM применяют в качестве постоянного хранилища и только как последний уровень HSM. Так же, как и в случае магнитооптики, диски WORM помещают в библиотеки. Среднее время доступа - 5-10 секунд.

Магнитные ленты - самые вместительные и самые дешевые носители. Тем не менее емкость кассеты не превышает 35 Гбайт несжатой информации (DLT 7000). Для HSM обычной практикой является применение библиотек и автозагрузчиков магнитных лент, емкость которых порой достигает нескольких терабайт. Стоимость одного мегабайта составляет от 0,03 долларов. Поскольку магнитные ленты представляют собой носители с последовательным доступом, среднее время доступа (учитывая время загрузки картриджа в накопитель) достигает 40-80 секунд. Хотя магнитные ленты являются перезаписываемыми носителями, но перезаписывать их можно только целиком: один файл или каталог с магнитной ленты удалить невозможно. В результате магнитные ленты можно применять лишь в качестве самого последнего уровня HSM. При правильной эксплуатации магнитные ленты имеют весьма высокие показатели надежности.

Существуют и другие типы носителей, прежде всего это CD-R, DVD-RW, DVD-RAM, но они не нашли применения в системах HSM. Это связано с тем, что подобные носители предназначены для пользователей, а не для корпоративных решений. Например, в дисках DVD в качестве подложки используется пластик, что неприемлемо для роботов библиотек, поскольку в процессе работы диски изнашиваются, и робот не может гарантировать надлежащего центрирования дисков.

При конфигурировании иерархии (уровней) HSM следует учитывать ряд правил и рекомендаций.

Как было уже отмечено, диски WORM и магнитные ленты могут составлять только самый послед-ний уровень иерархии. Нельзя, например, на втором уровне устанавливать стример, а на третьем уровне - библиотеку МО.

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

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

НАЗНАЧЕНИЕ HSM

Системы иерархического хранения бывают трех основных типов: специализированные HSM, универсальные HSM и HSM резервного копирования и архивирования.

Специализированные системы иерархического хранения предназначены для обработки больших объемов нерегулярно используемой информации в конкретных прикладных программах. Например, немало систем учета документов и документооборота включают в свой состав средства HSM. Редко запрашиваемые документы автоматически или ручным способом перемещаются с дисков на МО или магнитную ленту. При обращении пользователя к перенесенному файлу HSM вернет его на жесткие диски. Достоинством специализированных HSM является их оптимизация для конкретного приложения. Недостатком можно считать то, что другие приложения не могут воспользоваться как услугами HSM, так и аппаратными средствами HSM (накопителями МО, магнитных лент и т. д.).

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

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

В данной статье речь будет идти только об универсальных HSM, поскольку именно они доминируют на рынке. HSM выпускаются для большинства серверных операционных систем: Novell NetWare, Microsoft Windows NT, IBM MVS, различных версий UNIX - всего же их насчитывается несколько десятков, причем они очень сильно отличаются друг от друга своими возможностями.

Универсальные HSM можно условно разделить на три основные категории:

  • системы иерархического хранения в составе сетевых ОС;
  • недорогие HSM, поддерживающие два уровня иерархии, причем в качестве второго уровня выступает магнитооптика;
  • мощные полнофункциональные системы HSM.

В настоящее время только одна операционная система - NetWare (четвертая и пятая версии) - включает в себя средства иерархического хранения. Эти средства носят название системы хранения большой емкости (High Capacity Storage System, HCSS). Как ожидается, Microsoft Windows 2000 также будет включать средства иерархического хранения. К сожалению, система HCSS в составе NetWare имеет слишком большие ограничения и не подходит для корпоративной среды. В частности, она поддерживает лишь два уровня, вдобавок вторым уровнем может быть только магнитооптика. Но самыми неприятными недостатками HCSS являются следующие:

  • хранилищем HCSS может быть только один том сервера NetWare;
  • сервер NetWare поддерживает только одну библиотеку МО;
  • поддержка только пространства имен DOS;
  • на томе HCSS каталоги привязываются к определенным сторонам конкретных дисков МО;
  • подкаталоги на томе HCSS переименовывать запрещено, независимо от уровня вложенности.

Таким образом, даже при наличии вместительной библиотеки МО после заполнения стороны диска МО файлы конкретного каталога больше не переносятся на второй уровень. Данный каталог увеличивается в размере лишь за счет первого уровня - дисковой системы. Из-за перечисленных ограничений система HCSS практически не применяется на практике.

Системы HSM среднего класса более популярны. Среди подобных систем можно выделить Optical Server for Windows NT компании Computer Associates, Highway Server for NetWare компании Camino и несколько других. Характерной особенностью таких систем является то, что в качестве второго уровня может применяться только магнитооптика. Они не имеют свойственных HCSS недостатков, хотя и налагают ряд собственных ограничений. Самым главным из них является то, что HSM обычно привязана к единственному серверу сети. К тому же, несмотря на невысокую цену HSM, библиотеки МО достаточно дороги и не очень вместительны.

В случае корпоративных сетей и большого объема информации лучшее решение - это использование HSM старшего класса. Наиболее популярными из них для сетей NetWare являются: HSM for NetWare компании Computer Associates, Seagate Storage Manager for NetWare; для сетей Windows NT: Seagate Storage Manager for Windows NT. Для UNIX известно не менее десятка реализаций HSM, причем некоторые из них, такие, как FileTrek HSM компании Artecon, - многоплатформенные. Мощные HSM поддерживают различные виды накопителей (винчестеры, МО, WORM, магнитные ленты) и все уровни иерархии. Несмотря на относительно высокую цену программного обеспечения (от 3000 до 20 000 долларов), полнофункциональные HSM дают ощутимый экономический эффект при хранении больших объемов информации.

Поскольку целью статьи является не сравнительный анализ различных систем HSM, а ознакомление читателей с их возможностями, то для описания принципов работы систем иерархического хранения мы выбрали HSM for NetWare компании Computer Associates.

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

ПРАВИЛА МИГРАЦИИ

HSM for NetWare поддерживает три уровня иерархии, причем третий является факультативным (необязательным). В качестве второго и третьего уровней могут использоваться винчестеры, магнитооптика, диски WORM и магнитные ленты. Однако, как было отмечено, диски WORM и магнитные диски могут применяться на втором уровне лишь при условии отсутствия третьего уровня. Применение винчестеров в качестве второго или третьего уровня имеет тот плюс, что для их обслуживания на сервере не требуется устанавливать дополнительную оперативную память. Второй или третий уровень может состоять из нескольких однотипных устройств, например из нескольких библиотек МО, что делает систему HSM for NetWare легко масштабируемой при увеличении объема информации. Единственное ограничение состоит в том, что все устройства одного уровня иерархии должны быть подключены к одному и тому же серверу NetWare. Различные уровни иерархии могут быть реализованы как на одном сервере, так и на совершенно разных машинах. Например, магнитооптику для второго уровня можно разместить на одном сервере сети, а библиотеку магнитных лент в качестве третьего уровня подключить к специально выделенному компьютеру, оснащенному ОС NetWare.

HSM for NetWare в качестве первого уровня иерархии поддерживает произвольное количество серверов NetWare (оно ограничено лишь приобретенной лицензией). При этом для иерархического хранения могут быть выделены как серверы целиком, так и отдельные тома, каталоги и даже файлы. Для пользователей и приложений система HSM for NetWare полностью прозрачна с точки зрения файловых операций. Такая архитектура обеспечивает исключительную гибкость при хранении больших массивов информации в распределенной корпоративной среде.

Процесс миграции контролируется правилами миграции, которые включают:

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

Хотя система HSM активна все время, процесс миграции происходит строго по расписанию (см. Рисунок 2); он может повторяться от нескольких раз в сутки до одного раза в неделю. В отличие от миграции, демиграция может происходить в любое время - при обращении пользователя к перенесенному файлу.

Самая важная задача настройки HSM - установка пределов заполнения уровней иерархии (watermark). Таких границ три: нижняя (low), верхняя (high) и критическая (critical). Они задаются в процентах от емкости уровня иерархии (см. Рисунок 3) и устанавливаются для всех уровней иерархии, кроме последнего. Значение критической границы больше, чем у верхней, а оно, в свою очередь, больше, чем у нижней.

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

Если же время миграции еще не наступило, а заполнение достигло критической границы, то миграция осуществляется немедленно, без учета расписания. В таком случае файлы переносятся до тех пор, пока объем хранимой информации не снизится до верхней границы. Следует иметь в виду, что критическая граница имеет значение только для первого уровня иерархии HSM, со второго уровня миграция происходит всегда исключительно по расписанию. Более того, в ряде систем HSM возможность миграции вне расписания вообще не предусматривается, поэтому сам термин "критическая граница" в них не используется. Верхняя и критическая границы для хранилища первого уровня не должны быть слишком высоки, так как оно должно иметь место для размещения возвращаемых файлов. Пределы заполнения могут быть установлены как на уровне всего сервера, так и на уровне тома NetWare.

Еще одной важной задачей конфигурирования HSM является установка интервала времени, в течение которого файлы должны храниться в пределах данного уровня иерархии до их последующей миграции (retention time). Критерий "Интервал времени до начала миграции" можно устанавливать в соответствии с одним из следующих параметров: времени создания, времени модификации и времени последнего обращения (см. Рисунок 4). По желанию администратора критерий "Интервал времени до начала миграции" может вступать в силу независимо от установки границ заполнения. В этом случае, если период времени с момента создания, обновления или последнего доступа к файлу соответствует критерию "Интервал до начала миграции", то файлы переносятся на следующий уровень независимо от степени заполнения хранилища. Но обычно критерий "Интервал времени до начала миграции" и границы заполнения применяются совместно, причем первый имеет приоритет. Т. е. если даже объем заполнения хранилища данного уровня превысил критическую границу, а критерий "Интервал до начала миграции" не выполнен, то миграция производиться не будет. Поэтому администратору надо очень осторожно подходить к вопросу выбора оптимального значения критерия. По большому счету, задание границ заполнения и критерия "интервал до начала миграции" является самой сложной задачей при настройке системы. Интервал времени до начала миграции может быть установлен на уровне сервера, тома и каталога.

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

  • Фильтр размера файла. HSM позволяет исключить из процесса миграции файлы, размер которых меньше определенной величины, находится в заданном диапазоне или больше определенной величины.
  • Фильтр атрибутов файлов. С его помощью файлы можно разрешить/запретить мигрировать на основе атрибутов файлов. Например, фильтр может запрещать мигрировать файлы с атрибутом "системный".
  • Фильтр каталогов и файлов. Он задает списки подлежащих/не подлежащих миграции файлов и каталогов, в том числе с помощью метасимволов (масок) (см. Рисунок 5).
  • Фильтр владельца файлов. Он позволяет обрабатывать файлы в зависимости от имени их владельца.
  • Фильтр пространства имен. Он дает возможность задавать файлы на основе пространства имен (DOS, Mac, NFS, OS/2), в котором они были созданы. Фактически фильтр пространства имен позволяет идентифицировать клиентскую платформу, где был создан файл.

ПРИНЦИПЫ МИГРАЦИИ

Когда файл мигрирует с первого уровня иерархии, то вместо него на жестком диске помещается заглушка (в англоязычной литературе используется термин "migration key"), которая указывает, где хранится файл. Кроме того, в операционных системах NetWare 4.x и 5.x файлу выставляется атрибут "миграция". Пользователь не видит заглушку, для него файл продолжает находиться на винчестере.

Для резервного копирования иерархии HSM используют программы резервирования, совместимые с HSM. Они подвергают резервному копированию не сами мигрированные файлы, а только заглушки первого уровня.

Система HSM for NetWare имеет опцию SaveKey, задание которой приводит к сохранению копии мигрированного файла на носителях второго и третьего уровней даже после демиграции файла. Использование SaveKey дает возможность значительно увеличить скорость миграции файлов, если они были ранее мигрированы, а затем демигрированы.

С точки зрения HSM for NetWare все файлы делятся на следующие категории.

  • Немигрированными (Unmigrated) файлами называют файлы, которые никогда не подвергались миграции, или файлы, ранее мигрированные без опции SaveKey, а затем демигрированные.
  • Мигрированные (Migrated) файлы - это файлы, которые находятся в хранилищах второго и третьего уровня независимо от установки опции SaveKey.
  • Демигрированные (Demigrated) файлы - это файлы, которые ранее были мигрированы с опцией SaveKey, а затем были демигрированы (т. е. перенесены на первый уровень иерархии).
  • Ремигрированными (Remigrated) называются те файлы, которые были мигрированы, затем демигрированы и снова мигрированы с опцией SaveKey.

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

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

Когда файл мигрирует с первого уровня на второй, то сам файл на первом уровне удаляется немедленно (но не уничтожается), и устанавливается уже упоминавшаяся заглушка. Когда файл мигрирует со второго уровня на третий, то копия файла на втором уровне не удаляется, ей присваивается метка "Marked Deleted", а заглушка на первичном носителе обновляется с указанием нового местонахождения файла.

В системе иерархического хранения файлы с меткой "Marked Deleted" уничтожаются по расписанию (обычно один раз в несколько дней), задаваемому администратором. Это так называемый цикл уничтожения (Purge Cycle). Правда, в случае дисков WORM и магнитных лент уничтожаются не сами файлы, а лишь записи о них в базе данных HSM.

Почему же при миграции со второго уровня на третий файлы на втором уровне не уничтожаются, а помечаются как "Marked Deleted"? Дело в том, что если незадолго до миграции проводилось резервное копирование, то при восстановлении информации с резервной копии заглушки будут указывать на носители второго уровня. Именно поэтому файлы второго уровня уничтожаются не сразу.

При демиграции файлов, ранее мигрированных с опцией SaveKey, копии файлов на втором или третьем уровне не удаляются. Это делается в целях ускорения процесса миграции, в случае если демигрированные файлы снова подвергнутся миграции. При повторной миграции система HSM проверяет факт обновления файлов. При отсутствии изменений файл на первичном носителе просто удаляется, и устанавливается заглушка. Никакого переноса данных между уровнями не происходит. Если же файл был модифицирован, то копия файла, находящаяся на втором или третьем уровне, помечается меткой "Marked Deleted". Файл мигрирует на новое место, а заглушка обновляется.

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

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

При удалении файлов, подвергнутых миграции, система HSM не предпринимает никаких действий. В свою очередь, операционная система удаляет (delete) заглушку, которую можно восстановить (salvage) обычными средствами ОС.

Если же мигрированный файл уничтожается (purge), то операционная система уничтожает заглушку, а HSM помечает файл меткой "Marked Deleted" (он будет полностью ликвидирован в течение следующего цикла уничтожения HSM). Такая схема дает возможность восстановить информацию с резервных копий.

РЕЗЕРВНОЕ КОПИРОВАНИЕ HSM

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

Применяемые для резервного копирования программы должны быть совместимы с данной конкретной системой HSM. Например, для HSM for NetWare рекомендуется использовать ARCserve for NetWare компании Computer Associates.

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

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

Поясним схему на примере. Если на втором уровне используется библиотека магнитооптики с 32 дисками МО, то 16 дисков выделяются для HSM, а остальные 16 отводятся для резервного копирования. Таким образом, для каждого носителя создается своя копия. Программа резервирования автоматически обрабатывает и копирует диски.

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

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

НЕДОСТАТКИ HSM

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

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

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

Системы HSM достаточно требовательны в отношении аппаратного обеспечения. Далеко не каждая библиотека магнитооптики или магнитных лент подойдет для конкретной системы HSM (со стримерами и обычными накопителями МО таких проблем нет). Поэтому перед приобретением библиотеки необходимо выяснить, в какой мере она совместима с HSM. Аналогично, системы HSM весьма чувствительны в отношении операционной системы сервера. Если HSM работает в среде конкретной ОС, то это не значит, что она будет работать под управлением новой версии ОС. Например, мы столкнулись с тем, что HSM for NetWare прекрасно работает в NetWare 4.10, но, когда ее инсталлировали на NetWare 4.11, уровень иерархии на базе магнитных лент отказался работать.

Что касается экономии от использования системы HSM, то она имеет место, когда речь ведется о сотнях гигабайт информации. Если же объем информации не превышает ста гигабайтов, то экономически выгоднее добавить дополнительные винчестеры. Но не надо забывать о перспективе. Быстрый рост объемов информации может привести к тому, что через два-три года экономия на HSM выйдет боком. Во всяком случае подсчет экономического эффекта от внедрения (или отказа от внедрения) HSM следует проводить очень скрупулезно.

ЗАКЛЮЧЕНИЕ

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

Константин Пьянзин - обозреватель LAN. С ним можно связаться по адресу: koka@lanmag.ru.