Виртуальные ленточные библиотеки могут облегчить жизнь корпоративного пользователя — но не всегда. Если здесь не сделать всё правильно, то результат может быть и обратным.
Всё начиналось весьма тривиально. Пользователи мучались, копируя свои данные на ленту. Цены на жесткие диски, особенно с появлением SATA, снижались, а их доступная емкость росла. И тогда эти SATA-диски стали использовать как буфер перед копированием на ленту, что дало выигрыш в скорости. Если требовалось восстановить данные, то сделать это с диска также было быстрее и проще, чем с ленты. Приобрели популярность дисковые массивы. Но очень многие компании не могли позволить себе покупку устройств достаточной емкости для резервного копирования всех своих данных (что дало бы возможность вообще отказаться от лент).
Данные приходилось вручную переносить с дискового массива через сервер резервного копирования на ленточную библиотеку. Кроме того, чтобы полностью отказаться от ленты, стал необходим перенос этих скопированных данных через сеть на другой дисковый массив в удаленном узле. Однако большинство сегментов глобальных сетей были слишком узки (и остаются таковыми), чтобы пропустить весь информационный объем, который может создать типичная программа резервного копирования для очередной выгрузки.
И тогда появились виртуальные ленточные библиотеки (Virtual Tape Library, VTL). Это дисковые массивы, которые выглядят как обычные ленточные библиотеки для программ резервного копирования. Их задача — обеспечить интеграцию копирования с диска на ленту и сделать диск идеальным кэшем для ленточных операций. Перенос данных, как и текущее копирование на диск, по-прежнему осуществляется вручную через программу резервного копирования на ленточное устройство. VTL — это массивы, оптимизированные для задачи резервного копирования. Они способны справляться с возросшим объемом данных, который создается программой резервного копирования. Кроме того, некоторые VTL помогают файловой системе справиться с фрагментацией, а также с файлами очень большого размера. Однако компании принимают VTL весьма неохотно. Почему?
Они сложны
Во-первых, VTL сложны для внедрения. Большинство из них построены на основе SAN (сеть хранения данных) и как результат привносят с собой все сложности Fibre Channel (FC). У многих заказчиков и по сей день очень мало серверов, подключенных к SAN, не говоря уже о резервном копировании через такие сети. Это слишком сложно, чтобы оправдать затраты, особенно в крупных хозяйствах, где FC встречаются чаще. VTL усугубляют ситуацию, требуя интеграции инородного устройства в SAN. Это вызывает дополнительные трудности ввиду необходимости создания зон и разделов в SAN, чтобы процесс резервного копирования мог мирно сосуществовать с текущим хранением данных.
Даже если вы приобретаете VTL у того же вендора, что и SAN, большинство крупных поставщиков базовых сетей хранения либо купили эту технологию, либо продают ее на правах OEM, и интеграция еще не доведена до совершенства. Так что даже если логотип производителя на вашей VTL тот же, что и на массиве SAN, внедрение и сопровождение всё равно остается очень сложным.
Возрастает общее время резервного копирования
Многие центры обработки данных не считают данные защищенными, пока не сделана вторая копия для целей аварийного восстановления (DR). В случае VTL это означает, что данные резервной копии должны быть как на диске, так и на ленте. Поскольку большинство VTL-решений имеют ограниченную дисковую емкость, то перенос с дисков на ленту должен выполняться довольно часто — обычно каждую ночь.
Но даже VTL-решения с дополнительной функцией удаления дубликатов имеют свои проблемы. Как правило, отсутствует обратная интеграция с ленточным устройством. Данные, созданные программой резервного копирования, должны быть снова через сервер резервного копирования извлечены из VTL и затем перенесены на ленточную библиотеку. Так что теперь, чтобы отправить данные на ленту, требуется трехкратный перенос вместо однократного: сначала данные переносятся с сервера резервного копирования в VTL, затем из VTL обратно на сервер и после этого с сервера на ленточную библиотеку. В результате вероятность сбоя при передаче увеличивается втрое. И такой процесс в мире VTL происходит почти при каждом резервном копировании.
Больше времени до создания аварийной копии
Помимо этого VTL ограничивают возможность создания электронной аварийной копии. Обычно на дисках хранится довольно объемная резервная копия, но многие VTL-решения способны тиражировать данные на другое устройство. В силу размера хранимой копии для этого требуется наикратчайший канал связи. С такой целью программу резервного копирования зачастую просто заставляли скопировать данные из одной VTL в другую на другом конце глобальной сети. Некоторые VTL могли состыковываться напрямую, но тогда программа ничего не знала о второй копии, да и размер всего массива данных был слишком велик. Чаще всего избирался способ долгосрочного хранения: данные копировались на другой комплект лент (т. е. это уже четырехкратный перенос данных), который погружали на машину и отвозили в хранилище.
Восстановление чаще происходит не с диска
В мире VTL отправка данных в хранилище осуществлялась путем перевозки лент на машине, и эти ленты нужно было создать вскоре после резервной копии, чтобы соблюсти политику DR. В результате был аннулирован еще один большой стимул к использованию дисковых решений — восстановление с диска. Большинство VTL создают виртуальные носители со штрихкодами, соответствующие реальным носителям и штрихкодам в библиотеке. Программы резервного копирования чаще всего могут оперировать только с одним экземпляром резервной копии и одним экземпляром штрихкода. Поэтому после того как сделана копия на ленте, набор резервирования, который был на диске, оказывается устраненным, и для восстановления он уже недоступен. Таким образом, даже если вы и могли позволить себе большой дисковый кэш, у вас не было возможности использовать его для восстановления.
Не снижаются расходы на ленты
Поскольку перенос на ленту должен происходить почти сразу, как только сделана резервная копия, и при этом создается второй комплект лент для аварийного восстановления в удаленном узле, количество необходимых носителей не уменьшается. На самом деле многие VTL, которые переносят данные прямо на ленту в фоновом режиме, не могут правильно вычислить разницу в емкости между хранением резервной копии в несжатом дисковом разделе VTL и в сжатом ленточном разделе. В качестве компенсации они рекомендуют отключить сжатие ленточного тома, что практически удваивает требуемый объем лент. Либо они рекомендуют не использовать фоновый перенос на ленту и позволить программе сделать всё самой.
Неэффективное удаление дубликатов
Стремясь компенсировать недостаточную привлекательность VTL, вендоры решили предложить функцию удаления дубликатов данных. Однако большинство этих систем осуществляют такое удаление дубликатов уже после копирования, что дополнительно усложняет процесс, требуя отдельных областей хранения, которые должны быть выделены и которыми нужно управлять (до удаления дубликатов и после него). Очевидно, что это увеличивает время тиражирования, снижая безопасность локальной аварийной копии, пока не завершен весь процесс удаления дубликатов.
Таким образом, VTL не только сложны в установке, но и не удовлетворяют главные требования пользователя: ускорение резервного копирования, возможность электронной отправки в хранилище, восстановление с диска и снижение стоимости носителей.
Каковы могут быть решения?
Первое и самое простое — попытаться вообще устранить ленту или по крайней мере уменьшить количество обращений к ней в данном процессе. Этого можно достичь, взяв дисковую систему резервного копирования с оптимизированной емкостью, использующую технологию удаления дубликатов (дедупликации). Эта функция находит дублирующие сегменты данных до того, как они могут быть записаны на диск, и вместо их записи делается указатель на исходный сегмент. Поскольку данные полной резервной копии текущей недели скорее всего очень похожи на те, что были неделю назад, вполне достижим двадцатикратный рост эффективности хранения — иными словами, резервное копирование 200 Тб данных будет стоить столько же, сколько сейчас стоит копирование 10 Тб.
Подобно VTL более сложные устройства удаления дубликатов могут обеспечить тиражирование с одного устройства на другое. Однако на таком устройстве хранятся только уникальные сегменты, и только их оно тиражирует, так что вполне возможна электронная отправка в хранилище по весьма медленным каналам глобальной сети (и сейчас это широко используется). Как и в случае VTL, процесс резервного копирования не будет завершен, пока не создана аварийная копия набора резервирования. С системой удаления дубликатов, использующей такой тип электронной отправки в хранилище, особенно с удалением дубликатов на лету, это происходит очень быстро.
Имея возможность более эффективного дискового хранения данных, некоторые ЦОДы вообще могут устранить перенос на ленту. Но большинству из них по-прежнему придется это делать, и ценность таких устройств с оптимизированной емкостью в том, что этот перенос может происходить гораздо реже. Кроме того, здесь уменьшается риск потери данных, поскольку каждое задание резервного копирования тиражируется в системе удаления дубликатов, что находится в хранилище. А затем уже лента служит для долговременного хранения данных. При этом требуется меньше носителей, потому что данные реже отправляются на ленту. А на другую систему удаления дубликатов они отправляются по сети, и лента, созданная на месте для долговременного хранения, может стать окончательной хранимой копией. Благодаря системам удаления дубликатов вполне достижимо сокращение затрат на носители на две трети.
Наконец, некоторые системы удаления дубликатов работают через IP. Интеграция в уже существующую инфраструктуру проста, и не нужно использовать специальный протокол для лент Fibre Channel. Ведь и ИТ-персонал лучше знает IP, чем FC, и конфигурирование среды проще и гораздо меньше вторгается в имеющуюся сеть. И процесс внедрения длится не сутками, а всего несколько часов.
Удаление дубликатов на лету
Оперативное удаление дубликатов (т. е. в процессе обработки данных, пока они не попали на диск) упрощает весь процесс, так как не требует отдельных областей для хранения. В большинстве систем тиражирование на DR может происходить, когда данные записываются на систему удаления дубликатов в самом ЦОДе. Таким образом, системы удаления дубликатов помогают решить главную проблему, столь тягостную для ИТ-персонала. Они повышают надежность и упрощают очень сложный процесс.
VTL — это решение, расширяющее возможности ленточного хранения. Пока что его могут позволить себе лишь крупные компании. VTL может служить “быстрым” кэшем перед лентой в крупных центрах обработки данных, осуществивших консолидацию хранения. Именно здесь стратегия виртуализации резервного копирования даст наибольший выигрыш и будет включать виртуализацию систем удаления дубликатов.
Джордж Крамп является учредителем аналитической фирмы Storage Switzerland, которая специализируется на виртуализации и хранении данных.
