Главная Storages, Без рубрики, Новое Так ли незаменимы магнитные ленты для бэкапа? Часть 3
  • Так ли незаменимы магнитные ленты для бэкапа? Часть 3

    Dds_tape_drive_01 Итак, в двух предыдущих постах серии я попытался вас убедить, что на сегодняшний день устройства для записи на магнитную ленту (стримеры или ленточные библиотеки, “tape library”) часто значительно проигрывают в удобстве, цене и надежности решения простым и эффективным дисковым NAS-массивам на дисках SATA.

    Такие массивы:

    1. Обеспечивают приемлемую надежность, а также, в случае организации RAID, непрерывность работы в случае сбоя диска.
    2. На них возможна организация непрерывного контроля целостности данных, своевременная упреждающая индикация возможных сбоев через SMART или иные средства контроля.
    3. Относительная простота и доступность служб восстановления данных с поврежденных или вышедших из строя дисков (никогда не слышал про такие в отношении поврежденных лент).
    4. Эффективно экономят место за счет не только компрессии, но и значительно более выгодной по результатам дедупликации.
    5. Обеспечивают произвольный доступ, в том числе одновременно на запись и чтение, для произвольного количества хостов, и независимость скорости бэкапа от стабильности потока записи с хоста
    6. Стандартность, гибкость и легкодоступность “расширения емкости”, быстрота и дешевизна процесса расширения, не связана с необходимостью покупать “библиотеку” и менять стратегии бэкапа.
    7. Отсутствие у решения проблем “механического” характера и открытой “точной механики”.
    8. Недороги – стоимость терабайта на сегодня снизилась до 76$ за диск , против примерно 45$ за картридж LTO-4 на 800GB некомпрессированного объема, к которому, для его использования, необходим еще как минимум стример за 2000-2500$, а при превышении емкости картриджа авточенджер или библиотека, стоимостью 4 – 15 тысяч $.

    Обычно, когда я начинаю рассказывать про преимущества дискового хранения резервных и архивных копий, мне всегда приводится одно возражение: “Когда мы делаем копии на ленту, то мы можем легко вынуть сделанную копию из библиотеки лент, и послать ее в удаленное хранилище, на случай серьезной потери данных на основном сайте. А как это сделать в случае дискового массива? Ведь просто вынуть диск из RAID нельзя, значит оффлайн-хранение в случае дисков невозможно!”

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

    Да, нельзя вынуть жесткий диск из RAID и отвезти его в хранилище. Но это просто попытка решить задачу с непригодным для ее решения подходом, ограничив себя выбором неподходящего инструмента.
    Давайте попробуем решить задачу “оффлайн бэкапа”, двигаясь “от задачи”, а не от возможностей инструмента, не станем забивать шурупы молотком, только оттого, что он у нас уже оказался в руке, и найдем оптимальное решение.

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

    Поможет ли нам в решении этой задачи хранение картириджа с бэкапом недельной давности в банковской ячейке, в том случае, если мы по той или иной причине потеряли данные, а зачастую и оборудование на первичном сайте? Очевидно что нет. Нам нужно, по крайней мере, быстро найти для этой ленты устройство считывания, и куда-то восстановить данные с этой ленты. Напомню, потеря всего основного сайта вполне реальная перспектива, которую мы должны учитывать, раз уж мы решаем хранить резервные данные удаленно. При этом сами по себе, как вы видите,  данные ленты для нас ничуть не помогают решить нашу задачу – восстановления работоспособности бизнеса. Тем более, если состояние данных в этой копии, например, недельной давности (как правило offline baсkup редко делается с более частой ротацией).  Часто этот момент также игнорируется.

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

    Практически любой серьезный дисковый массив (а при выборе не-“аппаратного” устройства – множество программных решений, от коммерческих до rsync) сегодня умеет производить так называемую “репликацию”, то есть синхронизацию своего содержимого по сети с другим дисковым массивом. При этом на удаленный дисковый массив передаются только изменения, а в случае использования асинхронной репликации, это также снижает требования к каналу передачи данных, пусть и за счет “актуальности” данных. все равно это будут секунды, минуты, может быть часы, но никак не дни, как в случае offsite backup на магнитных лентах.

    Сколько же способен пропустить через себя данных канал репликации? Давайте, для примера, возьмем достаточно “бытовой” канал в internet, с полосой пропускания в 10Mbit.
    Нетрудно посчитать, что канал полосой 10Mbit за 24 часа может пропустить сквозь себя около 100 гигабайт.
    Допустим, что на накладные расходы, такие как VPN-шифрование и возможные снижения полосы пропускания, ухудшат данные показатели, думаю, что рассчитывать на 75% от “паспортной” пропускной будет вполне резонно. Это около 75 гигабайт данных в сутки. Это, надо сказать, довольно немалый объем, не забывайте, что речь идет о измененных за сутки данных, а не о данных вообще, так как передаются фактически только “инкрементальные копии”, измененные блоки. При этом, за счет асинхронности репликации мы не ограничиваем возможностями этого канала нашу рабочую систему. Допустим, наши изменения данных в пиковое время дня превышают пропускную способность такого канала. Ничего страшного, просто на какое-то время увеличится data gap, когда закончится рабочий день и количество записываемых на первичную систему  изменений снизится, реплицированный сторадж “догонит” основное хранилище. Все равно этот gap будет меньше, чем при записи данных ночью на ленту и вывоз ее утром курьером в удаленное хранилище. При этом мы еще и избавляемся от “участия человека” как, на практике, наиболее слабого звена, организуя процесс автоматически.

    Таким образом, “оффлайн бэкап” в случае дисковых хранилищ называется “удаленная репликация”. Просто?

    Как в первом, так и во втором случае мы получаем копию наших данных в недоступном форсмажорным стихийным бедствиям месте, однако, при этом, во первых, такая копия является гораздо более “актуальной” по отношению к рабочим, основным данным, во вторых – данные с нее могут быть непосредственно использованы при восстановлении работоспособности бизнеса, например перевезя, в случае необходимости, резервную систему с репликой на основной сайт и запустив доступ “в пожарном порядке” к данным непосредственно с нее. Зачастую “быстрый старт” после аварии бывает критически важен не только для репутации.
    Впоследствии же на базе сетевой инфраструктуры репликации, использовав уже вложенные в нее деньги, можно начать строить полноценное disaster recovery & busines continuity solution. О необходимости такого решения при организации бизнеса сейчас задумываются все больше компаний.

    Плюсы “удаленной репликации” перед “оффлайн-хранением носителя”:

    1. “Резервная копия” при удаленной репликации “моментальна”. В случае асинхронной репликации отставание от состояния данных первичного сайта составляет обычно от секунд до единиц минут, в отличие от дней, в случае копии ленты. Соответственно “актуализация”, то есть приведение к “текущему состоянию”, например базы данных, которая осуществляется “накатом” archive redo logs, занимает не часы и дни, а минуты и секунды.
    2. “Резервная копия” данных на удаленном реплицированном хранилище доступна не “потенциально”, как в случае картриджа с лентой, а вполне физически. В случае потери данных вместе с оборудованием первичного сайта, в результате какого-то стихийного бедствия, такого как пожар, наводнение, или “проведение следственных мероприятий”. В случае необходимости реплицированное хранилище можно вернуть на первичный сайт и практически немедленно, пусть и с ограничениями, связанными, например, с возможной меньшей производительностью резервного хранилища, возобновить работу с текущим состоянием данных.
    3. Стоимость канала передачи данных стабильно снижается, а его полоса пропускания – расширяется, гарантируя в будущем все более быструю репликацию, в соответствии с растущими потребностями бизнеса, и, со временем, все улучшая характеристики выбранного решения.
    4. В дальнейшем, на базе уже построенной инфраструктуры репликации можно построить и полноценное катастрофоустойчивое решение с двумя рабочими сайтами. Таким образом текущие, нынешние вложения в канал репликации, для решения защиты данных на базе удаленной репликации, могут быть использованы в будущем при создании катастрофоустойчивой системы, как его уже реализованной части (это то, что наши англоязычные коллеги называют “investment protection”).

    Несмотря на то, что блог, который я пишу, преимущественно занимается продуктами компании NetApp, в трех вышедших постах под заглавием “Так ли незаменимы магнитные ленты для бэкапа” я рассматривал задачу резервного копирования “в общем”, без привязки к каким-то конкретным решениям и технологиям NetApp. В следующей части мы приблизимся к основной теме моего блога, добавим конкретики, и рассмотрим возможности, которые предлагают для организации “дискового резервного хранения” продукты компании NetApp, которыми я занимаюсь.

    romx

    http://blog.aboutnetapp.ru

Комментарии

  1. Когда речь идет о работоспособности бизнеса, цена становится не очень важна. Можно выбрать, потратить $$$ на (1) ленточные механизмы или (2) на два стореджа и безлимитный канал на год-два. Однако с ростом объема бэкапов цена второго варианта растет экспоненциально, в отличие от линейного роста для “ленточного” решения.

    К тому же, на велосипеде отвезти десяток кассет в банковскую ячейку будет тупо быстрее, чем тужиться с 10 мегабитами.

    Если наш бизнес мелкий (хостинг блогов, и т.п.), нам подойдет что угодно. Хоть облако хранения, хоть винт в кладовке. Если же речь идет о серьезных объемах, да с перспективой их роста, то продавец HDD-бекапа должен быть гением 🙂

    Хотя, в госструктурах можно и без гениальности. Они вроде любят большие ценники 🙂

  2. Коллекция спорных, неаргументированных утверждений. 🙂

    > Когда речь идет о работоспособности бизнеса, цена становится не очень важна.
    Почему?

    > Однако с ростом объема бэкапов цена второго варианта растет экспоненциально, в отличие от линейного роста для «ленточного» решения.
    Почему?

    > К тому же, на велосипеде отвезти десяток кассет в банковскую ячейку будет тупо быстрее, чем тужиться с 10 мегабитами.
    Почему?

  3. >> Когда речь идет о работоспособности бизнеса, цена становится не очень важна.
    >Почему?
    Пример из не очень далекого прошлого. Четыре сборочные линии Seagate. На каждой – управляющий компьютер (рабочая станция Sun). Если один компьютер ломается, Seagate начинает терять деньги с сумасшедшей скоростью – 25% производства стоИт. В этом случае директор Sun садится в самолет с новым компьютером, и везет его прямо на сборочную линию. Дорого? Пофиг, убытки обойдутся куда дороже.

    >> Однако с ростом объема бэкапов цена второго варианта растет экспоненциально, в отличие от линейного роста для «ленточного» решения.
    >Почему?
    Добавьте пяток терабайт в ленточную библиотеку (4 ленты LTO-4), и добавьте пяток терабайт в дисковый массив. Максимум, что придется поменять в первом случае – автолоадер. Во втором есть шанс попасть на две новых полки.

    >> К тому же, на велосипеде отвезти десяток кассет в банковскую ячейку будет тупо быстрее, чем тужиться с 10 мегабитами.
    >Почему?
    Не хочу показаться занудой, но “канал полосой 10Mbit за 24 часа может пропустить сквозь себя около 100 гигабайт”. Велосипед будет быстрее, даже если в соседний город ехать придется.

    Остальные утверждения, видимо, достаточно аргументированы? 🙂

  4. 1. а что делать, если нам нужно передать больше 75Гб в сутки через 10мегабитный канал?
    2. в предложенном решении предлагается использовать второй ЦОД. стоимость его, включая железо и лицензии, будет несравненно выше стоимости ленточной библиотеки. не очень корректное сравнение.
    3. предполагается, что стоимость гигабайта информации на жёстких дисках не включает в себя стоимость хранилища? я правильно понял? тогда почему приводится цифра стоимости ленточной библиотеки? =) опять некорректное сравнение.

  5. > а что делать, если нам нужно передать больше 75Гб в сутки через 10мегабитный канал?

    Например купить/арендовать еще один канал, или расширить имеющийся.
    У вас все вопросы такого уровня будут? 😉

    > в предложенном решении предлагается использовать второй ЦОД.

    Нет, варианты могуь быть разные. Это может быть аренда 2-4 юнитов в стойке датацентра, в которой будет стоять “коробка с дисками”, подключенная в интернет.

    > предполагается, что стоимость гигабайта информации на жёстких дисках не включает в себя стоимость хранилища? я правильно понял? тогда почему приводится цифра стоимости ленточной библиотеки?

    Потому что стоимость вообще непросто посчитать. Но если хотите – можно попробовать.
    Но главная особенность преимущества дисков перед лентами в том, что вариант с дисками предлагает множество вариантов, за самую разную стоимость, от варианта диска в USB-коробке, до полноценного дискового массива, на любой вкус и кошелек. В то время как вариант решения с лентой может быть или стример плюс кассеты при объеме суточного бэкапа меньше кассеты (или “стример, кассеты и плюс сисадмин” в случае ручной замены), или стример, библиотека с авточенджером и кассеты в случае емкости бэкапа больше кассеты.
    Других вариантов решение с лентой не предлагает. И это серьезный ее минус во множесте применений.

  6. > пример из не очень далекого прошлого.
    Ой, давайте “ближе к телу”, не надо “о космических кораблях” рассказывать 😉

    > Добавьте пяток терабайт в ленточную библиотеку (4 ленты LTO-4), и добавьте пяток терабайт в дисковый массив.

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

    Серьезный минус лент, как я уже написал в комменте выше – отсутствие гибкости решения. “Или так – или никак”. В то время, как диски позволяю организовать множество разных вариантов, за разные деньги. Это мы сейчас даже не рассматриваем (а зря) многочисленные минусы лент, о которых я писал на прошлой неделе.

  7. >Давайте рассмотрим другой вариант. Мне нужно бэкапить два терабайта данных каждую ночь. В случае лент LTO4 я буду вынужден купить стример с авточенджером или библиотеку, в случае же дисков — всего два диска по терабайту, которые подключу к имеющемуся контроллеру в сервере.
    >Видите как все непросто и зависит от?
    Конечно, вижу. См.выше – “Если наш бизнес мелкий (хостинг блогов, и т.п.), нам подойдет что угодно.” (черт, цитирую сам себя :))

  8. >У вас все вопросы такого уровня будут?
    при однобоком освещении проблемы – да =)
    >Нет, варианты могуь быть разные. Это может быть аренда 2-4 юнитов в стойке датацентра, в которой будет стоять «коробка с дисками», подключенная в интернет.
    при полноценном дизастере коробка с дисками мало поможет в оперативном восстановлении инфраструктуры. в данной ситуации смысла в ней будет не больше чем в кассетах, хранящихся в банковской ячейке.
    так то да – варианты могут быть разными. поэтому скидывать со счетов ленты не стоит =)
    >Но главная особенность преимущества дисков перед лентами в том, что вариант с дисками предлагает множество вариантов, за самую разную стоимость, от варианта диска в USB-коробке, до полноценного дискового массива, на любой вкус и кошелек. В то время как вариант решения с лентой может быть или стример плюс кассеты при объеме суточного бэкапа меньше кассеты (или «стример, кассеты и плюс сисадмин» в случае ручной замены), или стример, библиотека с авточенджером и кассеты в случае емкости бэкапа больше кассеты.
    вариант с кассетами так же предлагает множество вариантов – вы их все и перечислили =) диски предлагают примерно столько-же. простое решение из одного внешнего usb-диска/мобил-рэка -> простенькая дисковая полка -> более сложные и дорогостоящие варианты.

  9. можно про мелкий бизнес сказать ? 🙂

    usb диск (2 шт рулит) – все прозрачно и понятно и дешево
    а попробуйте в ИП Иванов продать стриммер или дисковую полку 🙂
    у них вся “серверная” дешевле

  10. dim-soft +100 – про мелкий бизнес. Как раз недавно с такой ситуацией сталкивался – мелкий бизнес, нужно обеспечить резервирование данных, бюджет – USB диск :-). (до этого резервированием занималась их девочка-сотрудница по вечерам – на DVD-RW’шки бекапила :-))

  11. У мелкого бизнес и простои = бюджету. Так что это намано. Про мелкий здесь никто не говорит.

    По статье:
    >задачи хранение картириджа
    а я вот всё-таки картриджи храню 😉

    Это всё конечно отлично (кроме конечно этих волшебных “10мБит” (да, за МКАД-ом есть жизнь!))
    НО. Очень часто требуется не просто хранить данные в сейфе, а хранить их там от 5ти до 15ти лет. Предлагаешь пихать туда полки или хранить всё на полках? Н-р ежемесячных заархивированный размер БД в одной не очень крупной телефонной компании (порядка 150тыс. абон) – 15Гб. Не бог весть что, но за 5 лет набегает. А это только сырые данные. Потом их обрабатывают, привязывают в билиинг. И размер удваивается, а то и утраивается.
    В другой компании – БД 300Гб, ежемесячный слепок хранить 7 лет.

    А репликация – это круто, только работает она не так уж и прексрано в реалиях российского (да и не только) инета. Н-р – что будет при задержках 400-500ms? А при 1,5 сек? Не видели такого? А я видел 🙂

  12. Как итог – вы конечно правы. Но с какой-то своей, далекой от реалий колокольни. Да и флаг netapp виден на этой колокольни очень издалека.

  13. > Да и флаг netapp виден на этой колокольни очень издалека.

    Спасибо, я старался 😀

    > Но с какой-то своей, далекой от реалий колокольни.

    А мне кажется что наоборот, это ваш погост от нашей колокольни далек. Продолжаем?

    > Очень часто требуется не просто хранить данные в сейфе, а хранить их там от 5ти до 15ти лет.

    Пост номер один, про отличие между “бэкапом” (резервной копией) и “архивом”.

    > ежемесячный слепок хранить 7 лет.

    Про 7 лет – пост номер четыре (в четверг).

    > Н-р — что будет при задержках 400-500ms? А при 1,5 сек? Не видели такого? А я видел

    Да ничего плохого не будет. Видел и не такое. Видел даже репликацию по диалапу. Асинхронная репликация.

  14. Честно, вот пользуюсь лентами для архивного хранения, как дополненик к основному на дисках. Как то душе спокойнее когда я знаю что лента ОТКЛЮЧЕНА и лежит в хорошом месте, не доступна не пожару/хакеру/вирусу.

    Меня до сих пор удивляет что нет вируса, который бы “чу-чуть портил данные” бекапов и куча систем с онлайн бекапированием и дедупликацией становился дорогой игрушкой, с которой толком и не подняться

  15. сглазил – уже есть