Компания
155,88
рейтинг
16 июля 2013 в 20:03

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

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

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

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

Image #1864362, 151.3 KB

Лента VS Диски


Ленточный архив, безусловно, надёжный и простой способ защитить информацию, но он не лишён недостатков, прямо вытекающих из его ленточной природы, в основном эти трудности связаны с восстановлением маленьких файлов:
  • Значительное время поиска данных;
  • Одно приложение может на 100% загрузить один привод, создавая проблемы для бэкапа другим приложениям; *
  • Невозможность одновременного чтения и записи, если все приводы заняты чем-либо (требуется подождать полного завершения операции);
  • Сложность контроля качества и корректности записи.

*прим.: решается грамотным ПО, умеющим мультистрим-запись.

Дисковый массив лишён всех этих недостатков:
  • Поиск данных на винчестере в сотни раз быстрее, чем на ленте, которую требуется найти в архиве, принести, вставить в привод, перемотать, начать считывание;
  • VTL может эмулировать десятки и сотни приводов за раз: параллельное копирование и восстановление данных для множества приложений без увеличения стоимости владения системой;
  • Высокая надёжность хранения данных: серверные жесткие диски работают в жесточайших условиях годами, нагрузка VTL-системы для них не является сильно изнашивающей. Кроме того, все данные копируются внутри самой VTL и защищены при помощи RAID-массива, что увеличивает как надёжность хранения данных, так и сложность несанкционированного доступа к ней: даже если удастся украсть несколько жёстких дисков, никакой реальной целостной информации на них не будет.


Преимущества 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 и продолжает расти.

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


Мы не призываем полностью отказаться от проверенной временем технологии: вы можете установить HP Store Once как промежуточное звено между пользовательскими системами и долгосрочным архивом, что позволит уменьшить время ожидания ежедневного бэкапа, проводить частичный бэкап изменённых частей больших файлов, не перезаписывая ленточный массив полностью, ускорить работу по резервному копированию и восстановлению данных, а на ленту писать всё то, что может пригодиться в долгосрочной перспективе и не требует частого доступа.
Автор: @Shirixae

Комментарии (30)

  • +6
    Отвал полки во что выльется в этой системе?
  • +2
    Чем данная система лучше DataDomain?
    • 0
      Ничем. Особенно после недавнего выхода DD Boost over Fibre Channel. Но это всё-таки лучше, чем провальный VLS, так что сторонники HP могут порадоваться.
  • +11
    Интересно, хоть и не очень убедительно, и не лишено недостатков.
    Например вы уже совершенно традиционно путаете и смешиваете архивное хранения с резервной копией. Если бы вы их не путали, то никогда бы не написали, что для бэкапа «общая неторопливость системы мало кого беспокоит.»
  • +1
    Я понимаю что есть компании где за день набегает ~512Тб ежедневных бекапов, но я не понимаю зачем нужна железка отдельная, если можно и так использовать обычную полку для дисков.
    Да еще и ставится софт какой-то в промежутку между бекап системой и полкой.
    Всё это круто, но вижу тут ряд минусов:
    1. Зачем хранить бекапы бекапов на жесктих дисках с рейдом? Это дорого. Или полка умеет выключать диски с бекапами бекапов и в случае необходимости включать при доступе?
    2. Т.е. база дедупликации у филиала и центра единая, раз туда передаются уже дедуплицированные данные?
    3. WAN — ok, LAN — ok. FC?
  • 0
    * лента — 1.2 круб/тб. (http://www.wit.ru/equipment/sannas/hp-streamer.asp)
    * винт — 1.5 круб/тб (http://key.ru/shop/devices/ustrojstva_hraneniya_i_chteniya_dannyh/hdd_ssd/vinchester_3_tb_wd_caviar_green/)
    Согласен с автором.
  • +2
    Все это хорошо, но сколько жрет это электричества, сколько выделяет тепла… а это дополнительное питание, дополнительные кондиционеры…

    Мы активно используем ленты, да — это, мягко говоря, не оперативно, но записав раз, можно убрать чемодан с лентами в сейф и забыть до завтра). Как вариант еще смотрим на BD (привет ЭЛАРу с его ценниками),

    p.s. это совершенно не значит, что мы против полок) но они совсем для другого… Для работы, но не для хранения точно.
    • 0
      В спокойном состоянии очень мало, ну забили полку с дисками выключите её.
  • +3
    Ну я, например, разделяю хранение «Оперативных» копий, где важна скорость бэкапа/восстановления, на полку и «Долгосрочных» копий, где важна сохранность информации за длительные периоды, на ленту. Ленточки дополнительно можно убрать в несгораемый сейф, что весьма полезно для Disaster Recovery.
  • 0
    А как быть с софтом под linux? Есть коммерческие решения или amanda и bacula наше все?
    • +1
      HP Data Protector лет, наверно, 10 как поддерживается на платформе Линукс. Естественно, только RHEL+SLES.
      • 0
        Спасибо.
        Ужас, где были мои глаза когда я искал?
    • +1
      Symantec NBU, Backup exec
      EMC Networker
      • 0
        Спасибо, буду смотреть.
  • +1
    По поводу масштабируемости дисковых систем можно поспорить. Вы привели цифры лишь о емкости, а как же входяший/исходяший трафик? К примеру, у нас в ДЦ стоит EMC Datadomain 890 у которой максимум 3 порта FC 8Gb/s и больше нет слотов. И стоит лента Quantum Scalar i6000 с 24 LTO5 драйверами FC 4Gb/s (96 драйверов максимум). Получается что для того, чтобы достичь уровня ленточной библиотеки в трафике, нужно несколько DD, стоимость которых зашкаливает. То есть там где нужна реальная масштабируемость и большие объемы резервных копий — лента пока имеет свое место исходя из экономических соображений. Но это скорее частный случай.

    А в общем случае, дисковая система выигрывает у ленты так же в силу дополнительного функционала:
    — дедупликация
    — репликация
    — client direct LAN (клиентский сервер может напрямую отправлять данные дисковой системе, без участия медиа-сервера)
    • 0
      У DD890 4 порта FC
    • 0
      Не совсем верно. Ленточные приводы не могут быть использованы совместно, в смысле, что два клиента не могут писать одновременно на один и тот же драйв. При этом скорость записи драйва LTO-5 — 140 МБ/с без компрессии, что заведомо ниже 400 МБ/с (предел для 4-гигабитного FC), поэтому при 24 драйвах у вас заведомо не используется довольно широкая полоса пропускания на каждом порту. В случае Дата Домена, через каждый из 4-х портов (8-гигабитных) вы можете презентовать хоть по 10 приводов, и на каждый из них писать одновременно. Это даёт лучшую утилизацию полосы пропускания, и контроллер Дата Домена имеет достаточные ресурсы, чтобы принимать такой поток.

      Но и это ещё не вся история. Несмотря на все эти запредельные скорости, узким местом в бэкапе всё равно остаётся дисковая подсистема клиента, с которой данные читаются. С неё как раз, как правило, и не снять ни 400 МБ/с, ни даже 140.
      • +1
        Именно так… Пропускная способность библиотеки далеко не всегда узкое место…
      • 0
        Два клиента могут вполне использовать один и тот же драйвер, естественно они при этом пишут или читают попеременно. Так же как и один клиент может писать на несколько драйверов. У datadomain полоса пропускания одна на всех клиентов — 4х8 Гб/с. У ленты — каждый драйвер со своим контроллером FC.
        • 0
          DataDomain пишет не только через FC. Никто не мешает писать в то же время и через 1/10Гбит Ethernet. Кроме того — через все существующие интерфейсы потоки идут одновременно и параллельно. А DDBoost работает и через Ethernet, и через FC. Дедупликация же, при использовании DDBoost, начинается именно на клиенте, а не на медиа сервере… Где тут преимущества ленты???
          • 0
            Я ведь написал, что у DD890 только 4 порта, которые уже заняты, интерфейс 10 Гб вставить некуда. Я так же писал в каком конкретном случае лента выигрывает у дисковой системы: большие объемы ежедневного трафика (несколько клонов по 15 То), много клиентов резервного копирования. По экономическим соображениям здесь лента будет выгоднее.

            Про дедупликацию сейчас речь не идет. Это тема отдельная, там свои заморочки.
      • 0
        По моему interleaving с нескольких клиентов на одну ленту умеют уже все пишущие на ленты системы бэкапа. Это умел уже «привет из каменного века» Legato Networker 4, двадцатилетней давности.

        PS. Что, впрочем, само по себе не слишком уменьшает число недостатков ленты для бэкапа.
  • 0
    У лент есть еще одна неупомянутая большая проблема: Если привод сдох, то в магазин за новым не сбегаешь…
    Более того, однажды у нас привод таки здох. Заказали новый, но он прочитать старые бакап-ленты не смог… Свои записанные ленты читал и писал нормально… Поставщик менять привод отказался. С тех пор ленты как решение надежное решение нами не рассматривается в принципе…
    • 0
      Если он у вас был один, то вы ССЗБ.
      • 0
        Не лично у меня, а у работодателя… Ленточный накопитель был в единственном числе и out-of-service у производителя когда я пришел.
    • 0
      Рейд контроллер тоже если умирает, в магазине новый не купите…
      • 0
        Данные с диска можно снять и без RAID контроллера. А с лентой вы в полном пролёте… Привод кстати, отремонтировали, но больше с ним связываться не стали…
        • 0
          Снимите данные с raid5…
          • 0
            Вот именно по этой причине мы не используем RAID5-6…
          • 0
            А в чем проблема реконструкировать софтверно схему чередования страйпов в RAID-5? Она фиксирована и достаточно очевидна. Это умеют уже даже бытового уровня утилитки типа RAID Reconstructor.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка