Как стать автором
Обновить
Veeam Software
Продукты для резервного копирования информации

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

Время на прочтение 9 мин
Количество просмотров 8.1K

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

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

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

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

Но из-за своей природы (пластиковая лента с магнитным слоем) у лент есть несколько очень неприятных моментов. Например, на ленту можно не слишком быстро писать данные, а потом очень долго и медленно их считывать. Особенно если речь идёт о файлике, который физически оказался в самом конце вашей кассеты. Пока вы будете ждать перемотки ленты на необходимое место, тут даже HDD с его задержками на раскрутку шпинделя и необходимостью двигать коромысло со считывающей головкой покажется манной небесной. Другая ленточная беда - невозможность изменять файлы. Файл, записанный на ленту, можно только удалить. Изменили полтора байта в вашем файле? Добро пожаловать в конец дорожки, кажется, там ещё оставалось место, чтобы перезаписать весь файл ещё раз.

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

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

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

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

 И на тот момент это сработало. Появились эмуляторы, функциональность которых находилась на уровне архиватора: упаковать файлы в свой формат и радостно отчитаться по SCSI (или любому другому) порту о том, что ленточка старательно записана, робот её вынул и даже положил вот в такой вот слот в своей библиотеке. Самое натуральное переливание из пустого в порожнее под флагом имитации бурной деятельности. Но дабы не только ругать VTL на чём свет стоит, стоит всё же упомянуть и про их плюсы. Самый главный, действительно, это всё ещё скорость. Если вам совсем некуда девать деньги и ваш VTL пишет свои файлы на SSD, то вы победитель по жизни. Но если с деньгами не настолько всё хорошо, а весь фронт работ — это записать буквально десяток плёнок, то диски будут дешевле, как ни крути. Если не верите, то просто посмотрите, сколько стоят современные LTO приводы. Ну и вишенка на торте - нет необходимости перематывать кассету на нужное место. Читай сразу откуда хочешь.

Поэтому главное что хочется сказать - не обманитесь заманчивыми плюсами VTL. Буква V значит Virtual, а все преимущества (и недостатки) лент исходят из их физической природы. Так что VTL может принести вам только моральное удовлетворение, но никак не решить задачу недорогого хранения отчуждаемых бекапов на случай аварии. Да и смысл интеграции с бекапным софтом уже давно пропал из-за наличия встроенных функций для перекладывания бекапов из одной корзины в другую. Например, в Veeam эта функция называется Backup Copy. Пользуйтесь на здоровье.

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

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

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

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

yum install httpd gcc perl sg3_utils kernel-devel

Наверняка большая часть этих пакетов и так уже стоит, но вдруг вы такой же маньяк и начинаете с CentOS minimal. Также рекомендуется проверить, что установленные версии ядра и тулзов совпадают, а то в наших планах QUADstor компилировать, и лишние проблемы нам ни к чему. Так что сравниваем выводы uname -r и rpm -qa | grep kernel-devel

 [root@centos ~]# uname -r

3.10.0-1160.15.2.el7.x86_64

[root@centos ~]# rpm -qa | grep kernel-devel

kernel-devel-3.10.0-1160.15.2.el7.x86_64

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

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

wget https://quadstor.com/vtldownloads/quadstor-vtl-ext-3.0.51-rhel.x86_64.rpm

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

rpm -ivh quadstor.rpm

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

rpm -ivh quadstor.rpm

error: Failed dependencies:

        libcrypto.so.10()(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64

        libcrypto.so.10(libcrypto.so.10)(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64

        libssl.so.10()(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64

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

systemctl enable httpd

service httpd start

/etc/rc.d/init.d/quadstorvtl start

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

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

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

Но самое интересное находится в секции Virtual Libraries. Здесь мы выбираем, хозяина какой именно железки мы будем из себя изображать.  А то и нескольких сразу, ведь кто нам запретит?  Так уж сложилось, что душой я за HP, поэтому хотел выбрать себе HP MSL 6000 с двумя приводами Ultrium 6250, но потом передумал и для наглядности выбрал ветерана ленточных боев - ESL 9000.

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

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

Тут наступает важный момент: надо обязательно открыть Device Manager и посмотреть как определились новые устройства. Крайне рекомендуется поставить драйвера, чтобы избежать проблем при работе с библиотекой. Veeam использует стандартные системные вызовы, поэтому если система может работать с библиотекой, Veeam тоже будет работать. А нет драйверов - нет мультиков. Так что если у вас старьё вроде того, что я добавил в свою лабу, система сама всё поставит. Если что-то новое, то качайте с сайта производителя. Технически, Veeam может работать и с универсальным Microsoft Tape Format (MTF), но оригинальные драйвера всегда в приоритете.

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Теги:
Хабы:
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
+14
Комментарии 17
Комментарии Комментарии 17

Публикации

Информация

Сайт
veeam.com
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Швейцария

Истории