Ленточная библиотека что это такое

Ленточная библиотека

Ле́нточный накопи́тель, или стри́мер [1] (от англ. streamer ), — запоминающее устройство на принципе магнитной записи на ленточном носителе, с последовательным доступом к данным, по принципу действия аналогичен бытовому магнитофону.

Основное назначение: запись и воспроизведение информации, архивация и резервное копирование данных.

Содержание

Достоинства и недостатки

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

Базовые способы записи

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

Линейная магнитная запись

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

Наклонно-строчная магнитная запись («Helical Scan»)

Если используется данный метод, то блок головок записи-воспроизведения (БГЗВ) размещается на вращающемся барабане, мимо которого механизм протягивает ленту, при чтении и записи. Запись при этом ведётся в одном направлении. В зависимости от используемого формата записи лента проходит вокруг БВГ под некоторым углом, причём ось самого цилиндра БГЗВ также наклонена под небольшим углом к ленте. Лента при записи-чтении движется в одном направлении. Данный способ записи предполагает наличие наклонных дорожек на поверхности ленты. Аналогичная технология применяется в видеомагнитофонах. Наклонно-строчный метод был изобретён, чтобы добиться более высокой плотности записи, чем при линейном методе, без необходимости уменьшения зазора в головках и увеличения скорости движения ленты (однако в настоящее время эти технические ограничения преодолены и в рамках линейного метода).

История

Магнитная лента была впервые использована для записи компьютерных данных в 1951 году в компании Eckert-Mauchly Computer Corporation на ЭВМ UNIVAC I. В качестве носителя использовалась тонкая полоска металла шириной 12,65 мм, состоящая из никелированной бронзы (называемая Vicalloy). Плотность записи была 128 символов на дюйм (198 микрометров / символ) на восемь дорожек.

В ЭВМ, выпускавшихся до момента появления и широкого распространения жестких дисков, накопители на магнитной ленте (НМЛ), аналогичные ленточным накопителям, использовались как основной долговременный носитель информации. В дальнейшем в мейнфреймах НМЛ стали использоваться в системах иерархического управления носителями для хранения редко используемых данных. Некоторое время они достаточно широко применялись в качестве съёмного ЗУ при переносе большого количества информации.

9-дорожечная лента

Широкое распространение ленточных накопителей было связано с большими ЭВМ и, в частности, мейнфреймами IBM. Начиная с представленного в 1964 году семейства IBM System/360, в фирме IBM был принят стандарт 9-дорожечной ленты с линейной записью, который впоследствии распространился также в системах других производителей и широко использовался до 1980-х годов. В СССР этот стандарт магнитных лент абсолютно доминировал, благодаря использованию ленточных накопителей семейства ЕС ЭВМ, в том числе и в составе компьютеров других архитектур.

Аудиокассета

В домашних персональных компьютерах 1970-х и начала 1980-х годов (вплоть до середины 1990-х) в качестве основного внешнего запоминающего устройства во многих случаях использовался обычный бытовой магнитофон или, изредка, специальные устройства на его основе с автоматическим управлением (например, Commodore Datasette). Эта технология была недостаточно приспособлена для компьютерных нужд, зато была весьма дёшева и доступна для домашнего пользователя (так как сам аудиомагнитофон у многих из них уже имелся). Для промышленных ПК использовались ленточные накопители, такие как TEAC MT-2ST c кассетами CT-500H, CT-600H 50 и 60 Мб соответственно.

Технология DDS

Формат хранения данных DDS (англ. Digital Data Storage ) был разработан в 1989 году компаниями Hewlett-Packard и Sony на базе формата DAT (Digital Audio Tape), разработанного компаниями Sony и Philips в середине 1980-х. По внешнему виду он напоминает уменьшенную в два раза аудиокассету, поскольку представляет собой четырёхмиллиметровую магнитную ленту, заключённую в защитный пластиковый корпус размера 73 мм × 54 мм × 10,5 мм. Как подсказывает само название, запись на магнитную ленту производится цифровым, а не аналоговым способом, при этом используется 16-битная импульсно-кодовая модуляция (PCM) без сжатия, как у CD, а частота дискретизации может быть как больше, чем у CD (44,1 кГц), так и меньше, а именно: 48, 44,1 или 32 кГц. Это означает, что запись производится без потери качества исходного сигнала, в отличие от более поздних форматов DCC (англ. Digital Compact Cassette ) и MD (англ. MiniDisc ). Накопители DDS используют технику записи, аналогичную применяемой в DAT-аудиомагнитофонах и основанную как на перемещении носителя в горизонтальном направлении, так и головок чтения-записи — в вертикальном направлении.

Технология QIC

В 1990-е годы для систем резервного копирования персональных компьютеров были популярны стандарты QIC-40 и QIC-80, использовавшие небольшие кассеты физической ёмкостью 40 и 80 Мбайт соответственно. Поддерживалось аппаратное сжатие данных. Накопители этих стандартов устанавливались в стандартный 5-дюймовый отсек и подключались к интерфейсу контроллера флоппи-дисков. В дальнейшем появилось большое количество сходных стандартов под торговыми марками QIC и Travan, определяющих носители ёмкостью до 10 Гбайт.

Технология DLT

Технология DLT была представлена фирмой Quantum [en] в начале 1990-х годов на основе более ранней технологии CompacTape для компьютеров VAX фирмы Digital Equipment Corporation, ленточное подразделение которой приобрела Quantum. Дальнейшим развитием DLT явилась технология Super DLT (SDLT).
Линейка стандартов CompacTape/DLT/SDLT определяет носители физической ёмкостью от 100 Мбайт до 800 Гбайт.

С 2007 года развитие стандарта SDLT фирмой Quantum прекращено в пользу LTO, но оборудование и носители записи ещё выпускаются.

Современные стандарты

Современные ленточные накопители, как правило, подключаются через высокопроизводительный интерфейс SAS, обеспечивающий передачу данных со скоростью 3 или 6 Гбит/с. Старшие модели IBM имеют возможность подключения через интерфейс FICON.

Технология LTO

В настоящее время на рынке доминируют ленточные накопители, соответствующие линейке стандартов LTO (Linear Tape-Open).

Технология IBM 3592

Будучи, в отличие от стандарта LTO, ориентирован не только на архивацию и резервное копирование, но и на произвольный доступ к данным, стандарт IBM 3592 обеспечивает удовлетворение более жёстких требований по количеству перезаписей носителя. Также в IBM 3592 использован ряд решений для оптимизации производительности в старт-стопном режиме записи, такие, как глубокое кеширование данных и многоскоростное движение ленты (6 или 7 скоростей, в зависимости от модели ленточного накопителя).

IBM 3592 использует линейный метод записи.

Отличительной особенностью стандарта IBM 3592 является заложенная в него возможность переформатирования магнитных носителей старого поколения под формат более новых устройств с соответствующим повышением информационной ёмкости (в отличие от других современных стандартов, обеспечивающих совместимость новых устройств со старыми носителями только в старом формате). В общем случае предусматривается совместимость на 2 поколения вперёд, конкретные допустимые режимы использования конкретного носителя в конкретном устройстве определяются по таблице:

Перспективные разработки

В 2020 году Fujifilm и IBM сумели повысить емкость ленточных накопителей до 580 ТБ, при плотности записи 317 Гбит на квадратный дюйм (

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

В Unix-подобных операционных системах простейшая, но достаточная во многих случаях, работа с ленточным накопителем поддерживается из командной строки при помощи команд tar и mt (исключением является Mac OS X, в которой mt отсутствует, а tar не поддерживает ленточные накопители). Более развитые средства резервного копирования обеспечиваются специальными программами, доступными для всех распространённых операционных систем.

Ленточная библиотека

Источник

Блеск и нищета Virtual Tape Library

VTL (они же Virtual Tape Library, если по паспорту) можно назвать одним из самых странных порождений IT индустрии. Родившись в эпоху расцвета ленточных накопителей как классический софтовый эмулятор настоящего железа, многими они были восприняты как ответ на главный вопрос жизни (Вселенной и всего такого), и теперь одни умудряются продавать их за деньги, а другие использовать в проде и считать, что всё нормально.

Я не буду кричать что первые плохие, а вторых надо гнать из профессии. Нет. Я только лишь предлагаю трезво взглянуть на суть VTL.

А в чём проблема?

Чтобы разобраться с вопросом о легитимности использовании VTL, давайте вспомним, зачем вообще нужны ленты. Это самое дешёвое, не самое быстрое, зато физически отчуждаемое устройство для хранения информации. Про дешевизну можем говорить, если посчитаем цену условного терабайта хранения. Прямо сейчас LTO-8 лента в режиме сжатия способна принять на себя 30 Терабайт данных, при цене около 9000 рублей. Для объективности можно даже откинуть маркетологов с их сжатием и записать только честные, физически наносимые 12,8 Тб. Для сравнения, за те же деньги можно взять SSD на один терабайт или обычный HDD на четыре. А тут сразу 12,8. Или даже 30, если повезёт. Да, для ленты ещё нужен привод, а лучше даже библиотека с роботом ценой в несколько сотен тысяч рублей, но там, где есть приличные объёмы данных, для которых встаёт вопрос о хранении на протяжении многих лет, это всё-таки дешевле, чем закупать дисковые полки и заниматься их обслуживанием.

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

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

Но есть тут один нюанс, который объяснит нам причины появления VTL почти тридцать лет назад. Представьте, что ваше основное боевое хранилище — это дорогущий SAN, сделанный с использованием самых последних технологий своего времени. И вдруг выясняется, что к этому FiberChanel монстру надо подключить ленточную библиотеку по страшному и медленному SCSI интерфейсу. Полученная скорость работы вызовет у вас депрессию, не извольте сомневаться. И вот, после недельного запоя у вас появляется светлая мысль: “А может ну их, эти ленты?”. Но потом вы вспоминаете, что это “Ну их” может стоить многих денег вашей компании в виде штрафов от регулятора. Ну и весёлых приключений лично вам, если звёзды сойдутся особенно удачно. Поэтому у вас рождается очень хитрый план: а давайте вместо лент мы будем использовать всё те же диски, а чтобы рисовать красивые отчёты, мы напишем эмулятор, который будет подключаться к нашему софту, отвечающему за резервные копии, и будет тщательно кивать головой на все его команды к лентам.

Да, есть ещё так называемые D2D2T системы, где VTL используется в виде кеша, а потом готовые файлы просто записываются на ленты. Правда, сейчас их будет правильнее называть D2D2C, где C — это Cloud.

Препарируем VTL

Ну ладно, раз VTL — это идеальная лаба, чтобы ознакомиться с функционалом ленточного бекапа, давайте таки развернём эту лабу и попробуем записать наши бекапы на ленту, хоть и виртуальную. Я долго выбирал между более хардкорным MHvtl и QUADstor с его симпатичным GUI, но в итоге остановился на втором исключительно из-за большей его популярности. Хотя оба проекта бесплатные и обеспечивают плюс-минус одни и те же функции. А производить все манипуляции я буду на CentOS.

Первым делом, конечно же, yum update && yum upgrade и ставим все необходимые пакеты:

Если у вас циферки разошлись, то спасаемся yum upgrade kernel и ребутом.

С подготовкой закончено, и мы можем полноценно переходить к установке подопытного. В стандартных репозиториях его нет, поэтому на помощь нам приходит wget и официальный сайт. На момент февраля 2021 у меня получилось вот так:

Теперь идём в директорию, куда скачался файл (если она у вас не стандартная), и устанавливаем пакет. Внимание: я это делают в чисто лабораторных целях и условиях, поэтому поэтому могу себе позволить делать всё от рута. А вы нет! Делайте все с правами рядового пользователя.

На что я получил отлуп по зависимостям (ох уж эти CentOS minimal)

Ладно, мы не гордые, идём и ставим compat-openssl10, так как это всё его библиотеки. И повторяем установку, которая в этот раз завершается успехом за пару минут, и мы становимся обладателями QUADstor, mini PostgreSQL сервера, где будут храниться данные конфигурации, и небольшого Apache Web Server для Web-GUI. Хотя никто не запрещает и дальше всё делать через консоль, но мы пойдём по более наглядному пути. Только перед этим нам надо запустить веб сервер и проверить, запустился ли демон VTL.

Также установщик вас предупредит, что если хочется работать по FC, то надо обязательно перезагрузиться для корректной установки драйверов. Но в наши планы входит исключительно iSCSI, так что храним аптайм. На этом с консолью действительно всё, и мы можем открывать в любимом браузере WebGUI по IP нашей машины.

Первым делом надо зайти в Physical Storage и выбрать диски для работы. По умолчанию QUADstor выбирает первый диск, который обнаруживает. Читай, диск с системой. У меня на скриншоте виден второй диск, подключённый к этой виртуалке, так что смело выбираю его кнопкой Add.

Сразу предложат добавить этот диск в один из Storage Pool’ов, которые надо создать заранее. Это некая логическая единица для смыслового объединения лент по какому-то признаку. Как видите, ничего супер-необычного здесь нет, весь джентльменский набор: дедупликация для экономии места, WORM кассеты и репликация кассет. Но нам сейчас это всё не так интересно, поэтому ограничимся стандартным пулом.

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

На этом с настройкой VTL всё, и хочется перейти в интерфейс Veeam, дабы скрестить его с библиотекой. Однако мы не ищем лёгких путёй и подключим библиотеку к другой Windows машине, которая будет работать у нас в качестве Tape Server. Для чего заходим на этот сервер, запускаем iSCSI сервис и iSCSI инициатор. Там находим нашу библиотеку любым из доступных способов и подключаемся к ней. По умолчанию будет использоваться порт 3260, так что может потребоваться добавить соответствующее правило на вашем фаерволе.

И теперь (наконец-то) можно идти на сервер Veeam и открывать вкладку Tape Infrastructure. Где первым делом запустим мастер добавления Tape Server.

Выбираем нужную машину (или добавляем новую), выставляем правила обработки трафика, проверяем, что всё верно, и запускаем процесс деплоя. По его завершении мастер нам предложит провести инвентаризацию нашей библиотеки. Не вижу причин отказываться, поэтому на всё соглашаюсь и нажимаю Finish.

Если всё было сделано правильно, то Veeam начнёт бодро двигать туда-сюда кассеты, проверяя и внося их в свой стандартный медиа пул.

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

Но мы отвлеклись, так что давайте вернёмся в Veeam и проверим, что всё добавилось верно.

Как мы видим на скриншоте, библиотека определилась верная, приводы на месте, а количество кассет совпадает с заданным. Все кассеты находятся в медиа пуле Free, так как мы провели инвентаризацию. Если её пропустить, то все неизвестные ленты попадут в пул Unrecognized. Можно принимать поздравления, ибо всё действительно работает как и должно.

Давайте же тогда посмотрим, как бекапы находят своё пристанище в недрах ленточных приводов! На самом деле про это уже были исчерпывающие посты от моих коллег. Вот этот и вот тот. Поэтому я здесь пробегусь по самым верхам, дабы не переписывать уже написанное.

Итак, запускаем мастер Backup to Tape, задаём имя джобе и на втором шаге добавляем бекап, который хотим хранить на ленте. Технически можно добавить не просто бекап, а хоть целый репозиторий с бекапами, но мы такого делать не будем. Просто берём один красивый бекапчик.

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

Про медиа пулы, опять же, отсылаю вас читать документацию и статьи коллег, а для наших целей отлично подойдёт согласиться на все предлагаемое по умолчанию и добавить все имеющиеся кассеты. Главное, не забудьте на шаге Options выбрать использование сразу нескольких приводов. Можно ограничиться и одним, но зачем это делать, если мы создали два?

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

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

Ну а почему бы и нет? Имею право на мечты! Разве не для этого были придуманы VTL решения?

И на последок, ловите ссылку на раздел документации посвящённый работе с ленточными девайсами. Скорее всего там вы найдёте ответы на все свои вопросы.

Источник

На чем хранить бэкапы: Лента VS Дисковые СХД

Многие компании используют ленточные архивы для долговременных бэкапов и резервного копирования самой важной информации. Понять их несложно: достаточно дешевый, простой и надёжный метод хранения данных, успешно используюшийся много лет — срок годности картриджа составляет 2-3 десятка лет, информации на него влезает много, потоковый бэкап пишется быстрей, чем на классические дисковые системы, иными словами: зачем что-то менять, если это тебя устраивает?

Хранить бэкапы и бэкапы бэкапов на дисковых системах — дорого и неэффективно, а восстанавливать что-либо из бэкапа нужно не так часто, так что общая неторопливость системы мало кого беспокоит.

К счастью, мир не стоит на месте, технологии развиваются, и сегодня VTL (virtual tape library) уже догнали в стоимости владения ленточные архивы, многократно превосходя их по ряду других параметров. Давайте разберёмся, чем собирается крыть лента, и не пора ли переходить на дисковые библиотеки?

Лента VS Диски

Преимущества HP StoreOnce D2D Backup System

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

Со скоростью и так всё понятно: чтение и запись отдельных файлов с ленты куда медленней, чем с обычных жестких дисков. Дисковые же системы давно эволюционируют, используются не только в серверах, но и в обычных десктопах, и уже накоплен богатый опыт по ускорению повседневных операций. Надёжность мы также рассмотрели в предыдущем абзаце: RAID-6, физическая неподвижность жёстких дисков, отсутствие необходимости в переносе или хранении их в том виде, в котором хранятся картриджи для ленточных систем (картридж можно и физически украсть при транспортировке, например). А вот к масштабируемости и гибкости, я уверен, есть вопросы, и сейчас я постараюсь на них ответить.

Масштабируемость

Вопрос масштабируемости системы предлагаю рассмотреть на примере HP StoreOnce B6200:

Базовая система содержит два контроллера и две дисковые полки суммарноё ёмкостью в 48ТБ. Каждый контроллер может управлять четырьмя полками, под завязку набитыми ЖД объёмом до 2ТБ каждый. Таких контроллеров можно подключить до восьми штук (3 пары в добавок к двум имеющимся). Таким образом, B6200 будет обеспечивать до 768ТБ сырой ёмкости (из-за RAID-системы полезная ёмкость меньше на треть, но и 512ТБ всё ещё внушительный показатель), при этом с ростом объёма хранилища растёт и его производительность.

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

Гибкость

За широчайшие возможности по резервному копированию отвечает специализированное ПО — HP Catalyst. HP Catalyst – это программный агент, который устанавливается на медиа-сервер (сервер резервного копирования), на котором работает ПО резервного копирования HP DataProtector или Symantec NetBackup и Backup Exec. HP Catalyst производит дедупликацию данных прямо на медиа-серверах, задействуя функционал этого ПО и уже дедуплицированные данные отправляет на систему HP StoreOnce. Это позволяет добиться высоких скоростей резервного копирования, так как несколько медиасерверов способены обработать гораздо больший поток, чем одно выделенное целевое устройство. Например, топовая система HP B6200 может записывать данные сдедупликацией со скоростью до 40 ТБ/час, а с использованием HP Catalyst – уже до 100ТБ/час.

Главным отличием HP Catalyst от большинства аналогов является работа не только по LAN, но и по WAN. Таким образом, в малых региональных офисах можно не ставить выделенную библиотеку HP StoreOnce, а только установить на медиасервер HP Catalyst + ПО резервного копирования. Далее бэкап в дедуплицированном виде пойдет на библиотеку HP StoreOnce в центральном офисе или крупном территориальном отделении. Это позволяет мультифилиальным организациям организовать централизованное управление бэкапом и его консолидацию с минимальными затратами.

Если использовать только аппаратные средства, то для территориально распределенных организаций консолидация бэкапа выглядит следующим образом. В филиалах ставятся библиотеки начального уровня – HP 2620, а в центре – старшая модель, например HP 4430 или B6200. Филиальный backup записывается на HP StoreOnce Backup System и уже дедуплицированные данные (в 20 раз меньше исходных) передаются в центр, где записываются на большую библиотеку. Дедупликация реплицируемых данных существенно сокращает стоимость каналов связи. Одна HP B6200 позволяет собирать данные с 384 филиалов и вся эта сеть управляется одним администратором, что позволяет отказаться от администраторов резервного копирования в филиалах. Такая схема весьма популярна в мире, а самая крупная подобная инсталляция в России насчитывает уже порядка 100 устройств HP StoreOnce и продолжает расти.

У нас уже есть ленточный бэкап, куда его девать?

Источник