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

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

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

    Разберем их чуть детальнее:

    Отсутствие произвольного доступа (важно для снижения времени восстановления и, например, технологий устранения дубликатов хранимых данных)

    Магнитная лента это устройство принципиально последовательного чтения-записи. Это хорошо для задач упрядоченной записи или чтения. Когда-то таким и было резервное копирование. Подключили /mt и пошли tar-ом лить. Долили – перешли к следующему хосту. Сегодня существует много вариантов, когда последовательный доступ сильно ограничивает возможности процесса. Простейший пример – дедупликация данных. В устройстве последовательного доступа, если это не проделывается на этапе до записи на ленту, на некоем промежуточном устройстве (с произвольным доступом), нет способа воспользоваться методами дедупликации, для этого нужна возможность произвольного доступа к произвольному фрагменту записанных данных. На сегодня же дедупликация, пожалуй, самая горячая и многообещающая тема в этом сегменте рынка.

    Избыточная скорость и емкость для множества применений.

    Последовательность доступа строго определяет скорость оптимальной записи на картридж магнитной ленты. Возможно это покажется парадоксальным, но скорость бывает избыточна. Современные форматы и стандарты магнитных магнитных лент так шустро наращивали скорости и плотности записи, что на сегодня, для современных устройств записи на ленту, далеко не всякий сервер способен обеспечить необходимую им скорость. А значит лента или переходит в “старт-стопный” режим, останавливаясь и перематывая катушку снова и снова (скорость записи, разумеется, падает кардинально), либо, если такой вариант предусмотрен в стандарте – снижает скорость (кстати сказать “снижение скрости”, напрмер для стандарта LTO отнюдь не плавное, и минимальная скорость в этом случае – ~30MB/s. Нет устойчивого потока в 30MB/s – переходим в стартстоп, постепенно “убивая” картридж рывками и перемотками.
    30 мегабайт в секунду, это, прошу заметить, скорость примерно в три раза превосходящая скорость порта 100Mbit/s Fast Ethernet. Довольно серьезный трафик для иного сервера. Если ваш клиент отдает свои данные через агента по локальной сети (обычное решение для массового бэкапа) то, если вы не используете гигагбитную сеть, тогда 30 мегабайт в секунду вы от одного клиента не получите никак.
    В таком случае используется мультиплексирование, когда поток данных от нескольких серверов чередуется на ленте поблочно, обеспечивая достаточную скорость загрузки данными магнитофона. Мультиплексирование же нескольких потоков данных от нескольких серверов означает, например, что при повреждении данного картриджа ленты вы потеряете данные нескольких серверов разом. Уж не говоря о том, что такая схема усложняет “retention”, в особенности если разные сервера имеют разные периоды “устаревания данных”.

    Невозможность организации защиты с избыточностью (RAID) кроме тупого ручного “зеркалирования” в виде записи двух экземпляров.

    Немаловажная особенность. Если в случае дисков в enterprise мы уже привыкли, что данные на дисках защищены тем или иным RAID, то в случае магнитной ленты мы вновь возвращаемся к дремучему “до-RAID-ному” каменному веку IT, когда надежность хранения и доступа к данным определялась надежностью одного конкретного устройства. Да, теретически можно устроить запись с “зеркалированием” на два устройства. Кое-какие системы резервного копирования такое позволяют. Но даже если и так, кто этим в реальной жизни пользуется, положите руку кто на что хочет? Не видел ни разу, если честно. А вы думаете, что катриджи ленты так надежны, что это им не нужно? Повторите это в тот момент, когда картриджу с единственной копией вашей базы в момент загрузки, когда организация встала в ожидании когда вы восстановите ее бэкап, выдрало “лидер” (хвост со специальным креплением, за который вытягивается лента при заправке из картриджа LTO/SDLT).

    Невозможность контроля состояния записанных данных при хранении (повреждения и невозможность считывания данных, зачастую обнаруживаются только при попытке восстановления данных в час “Ч”)

    Часто недооценивамый в практической жизни недостаток. Но достаточно только раз, экстренно восстанавливая посреди рабочего дня рабочую базу данных предпрития, увидеть внезапно, что “End marker unreadable” или еще какой “Tape device read error”, и узнать что бэкапа – нет, просто нет и все, как вопрос надежности сохранения казалось бы надежно записанной резервной копии станет для вас куда как важным.

    Пассивность ленты как носителя, при своих определенных отдельных плюсах, несет и огромный минус. Пока лента не загружена в привод и не запущено чтение, узнать что происходит с записанными на нее данными мы не можем. А многие ли из владельцев резервных копий на магнитных лентах не только проверяют их на то, что “бэкап записался правильно”, но и делают регулярные проверки восстановления данных с него на протяжении всего его retention period? А ведь без такой предосторожности узнать вовремя о проблемах с лентой, или устройством чтения, “магнитофоном”, невозможно.
    В то время, как устройство на дисках может проконтролировать состояние записанной информации на считываемость и целостность в любой момент. Большинство систем хранения осуществляют операцию под названием disk scrubbing, контроль состояния дисков и записанных данных, во время простоя системы, и за счет алгоритмов предсказания способны забить тревогу еще до того, как диск на самом деле выйдет из строя.

    Механическая непрочность носителя, строгие требования по условиям хранения и использования (влажность, запыленность).

    Выше я уже упоминал механические проблемы картриджей и “магнитофонов”, виденные в том числе и по опыту практической IT-жизни и работы в сервисе ленточных библиотек. Хотя “механика” современных жестких дисков куда как более “точная”, чем у магнитных лент, но она производится милионными тиражами, и размещается в герметично изолированных “банках”. Ни влажность, ни пыль, ни температура на них не повлияет.
    Наоборот, ленты устройства открытые, целостность их зависит от корректной работы механизма протяжки ленты, который в случае какой-то случайной механической неисправности при загрузке-выгрузке запросто может угробить даже не один картридж, прежде чем вы спохватитесь, бывали случаи. А каждый картридж LTO-4 это около 800GB некомпрессированных данных. А толщина ленты в нем – всего 6,6 микрон. А длина ее – 820 метров.

    Сложность и высокая точность устройства чтения (лентопротяного механизма), и, как следствие, легкость его повреждений.

    Механизм, обеспечивающий запись с плотностью 13300 бит на миллиметр открыт и отделен от всех внешних воздействий в лучшем случае только миллиметровой толщины качающейся на пружине пластиковой шторкой.
    А стоит при этом около 2000-2500 долларов. И не зря. Тонкая работа.

    Сложность организации управляемого устройства емкостью выше одного картриджа (роботизированные библиотеки)

    В том случае, если объемы вашей резервной копии превышают размеры одного картриджа (800GB некомпрессированной емкости в LTO-4) вы во весь рост встречаетесь с проблемой необхдимости организовать возможность записи на “более чем один” картридж ленты. Расширить емкость ленточного устройства – совсем не то же самое, что добавить новый чистый диск в дисковую систему хранения и расширить на него RAID. В случае лент, если вас не устраивает среди ночи во время окна резервного копирования менять по списку один картридж в устройстве на другой (видел и такое “решение”), вы попадаете на специальную роботизированную библиотеку, где к всем возможностям поломок вам прибавится еще и поломка механической “руки” меняющей в “магнитофоне” картридж с пленкой. Стоит же такая библиотека – соответствующе своей механической сложности. Одна из наиболее недорогих – Overland NEO 200 – около 4000 долларов.

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

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

    Romx (http://blog.aboutnetapp.ru)
    Оригинал опубликован там: http://blog.aboutnetapp.ru/archives/619

Комментарии

  1. Ну приступим.
    >Отсутствие произвольного доступа (важно для снижения времени восстановления и, например, технологий устранения дубликатов хранимых данных)
    – да, это огромный минус лент. и уйти от него никуда не получится. с другой стороны стоит помнить, что тот же симантек советует бэкапить сначала на B2D носители, а с них уже, после осуществления дедупликации (если необходимо), бросать на ленты.
    >Избыточная скорость и емкость для множества применений.
    пример из жизни. у меня 2гигабитный канал в лучшем случае загружается на 20%. почему? потому что больше не позволяет дисковая подсистема, которая держит папки B2D. что делать? покупать SAS под цели бэкапа? по-моему расточительно. так что эту проблему (но с другой стороны =)) имеют и дисковые носители. решить ее можно перейдя на SSD-носители. но на текущий момент это дорого.
    >Невозможность организации защиты с избыточностью (RAID) кроме тупого ручного “зеркалирования” в виде записи двух экземпляров.
    библиотека решит проблему. другой вопрос – нужна ли избыточность при хранении резервных копий? как утверждал Александр Трофимов в предыдущей дискуссии, ценность бэкапа (не архива) экспоненциально падает с удалением от точки его создания. и я с ним полностью согласен. чем старше бэкап, тем большая вероятность, что он не потребуется никогда в течение срока своей жизни. так что единственная проблема, с моей точки зрения, это вероятность поломки самого устройства чтения/записи. но от этого не застрахована и дисковая полка, используемая для B2D бэкапа.
    >Невозможность контроля состояния записанных данных при хранении (повреждения и невозможность считывания данных, зачастую обнаруживаются только при попытке восстановления данных в час “Ч”)
    а вот этот вопрос уже к технологиям практически никакого отношения не имеет. это вопрос воспитания. многие ли администраторы систем резервного копирования вообще проверяют бэкапы, периодически их восстанавливая? не важно на чём они хранятся – на лентах или на дисках.

  2. Отвлёкся на встречу, а тут уже всё за меня написали…

    Добавлю, что емкие винчестеры в рейд-массивах, согласно заявлениям профессионалов, с высокой вероятностью выходят из строя во время ребилда (т.е. один за другим). Тут задумаешься об экономической составляющей 🙂

  3. > Добавлю, что емкие винчестеры в рейд-массивах, согласно заявлениям профессионалов, с высокой вероятностью выходят из строя во время ребилда

    Практика вашу гипотезу, как ни странно, не подтверждает.
    http://blog.aboutnetapp.ru/archives/397

    Тот факт, что RAID уровня 5 иногда разваливается при ребилде чаще чем при “обычной работе” объясняется скорее тем, что при ребилде, когда масив полностью незащищен от ошибок чтения, в процессе чтения всего его содержимого, обнаруживаются ошибки чтения в так называемых cold data, данных, лежащих подолгу без обращения.
    То есть, кстати, та же проблема, что и с лентами.
    Именно для этого любой приличный RAID-массив должен (и чаще всего делает) так называемый scrubbing, то есть фоновую операцию контроля состояния данных, независимо от того, читает ли эти данные приложение, или нет.

  4. Николай, вы имели ввиду RAID5?

  5. > а с них уже, после осуществления дедупликации (если необходимо), бросать на ленты.

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

    > библиотека решит проблему.

    Библиотека проблему не решит.

    > а вот этот вопрос уже к технологиям практически никакого отношения не имеет. это вопрос воспитания.

    Я бы предпочел, по возможности, не доверять обеспечение надежности хранения вопросам “воспитания” сисадминов 😉

  6. rpv, да, именно RAID5.

    >> Добавлю, что емкие винчестеры в рейд-массивах, согласно заявлениям профессионалов, с высокой вероятностью выходят из строя во время ребилда
    >Практика вашу гипотезу, как ни странно, не подтверждает.
    > Именно для этого любой приличный RAID-массив должен (и чаще всего делает) так называемый scrubbing, то есть фоновую операцию контроля состояния данных, независимо от того, читает ли эти данные приложение, или нет.
    Гипотеза не моя, но обоснованная. А приличный RAID-массив прилично стоит, Вы не находите? Выгоды по деньгам тут нет.

    >> библиотека решит проблему.
    >Библиотека проблему не решит.
    Нет, решит 🙂

    >> а вот этот вопрос уже к технологиям практически никакого отношения не имеет. это вопрос воспитания.
    >Я бы предпочел, по возможности, не доверять обеспечение надежности хранения вопросам «воспитания» сисадминов
    Назовите это не воспитанием, а правильно поставленным рабочим процессом. Человеческому фактору подвержена любая система.

  7. > А приличный RAID-массив прилично стоит, Вы не находите?

    Ну мы же о вопросах сохранности данных бизнеса говорим?

    > Человеческому фактору подвержена любая система.

    “Хорошая система” отличается от “любой” тем, что влияние пресловутого “человеческого фактора” в ней сведено к минимуму.

  8. >>А приличный RAID-массив прилично стоит, Вы не находите?
    >Ну мы же о вопросах сохранности данных бизнеса говорим?
    Ну не все предлагают лентами печку топить 😉 RAID-массив под задачи бекапа, да по той же цене, что и библиотека, это как-то нелогично – возможностей меньше.

    >> Человеческому фактору подвержена любая система.
    >«Хорошая система» отличается от «любой» тем, что влияние пресловутого «человеческого фактора» в ней сведено к минимуму.
    Правильно поставленный рабочий процесс почти исключает человеческий фактор. Будем продолжать играть словами? 🙂

  9. После “RAID-массив под задачи бекапа” добавить “вместо библиотеки”.
    fix

  10. А скажите я один на ленту бекаплю только архивные данные, копии данных храню при этом на дисках бекапного сервера? Из-за чего спор-то? 🙂

  11. Кстати, тема копирования в другой локейшен не раскрыта! 🙂

  12. > Будем продолжать играть словами?

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

  13. > А скажите я один на ленту бекаплю только архивные данные, копии данных храню при этом на дисках бекапного сервера? Из-за чего спор-то?

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

    Целью постов является не убедить немедленно ленты выбросить, а библиотеки сдать на лом. У каждого инструмента есть своя область применения. Попытка использовать инструмент не по назначению, особенно когда “всегда так делали”, но уже много лет существует приемлемая и удобная альтернатива, ведет к излишней, непроизводительной трате денег и сил.
    Если в результате чтения кто-то задумается об всем этом – уже не зря писал.

  14. > возможностей меньше.

    Возможностей больше. Вон, наверху, целых семь разных преимуществ дисков над лентами приведено.

  15. >> Будем продолжать играть словами?
    > Ну вы первым начали, вам и первому прекращать.
    Не согласен, но пусть так.

    > То есть, плюс к расходам на библиотеку, надо еще приплюсовать расходы на правильную организаци рабочего процесса. Это при том, что дисковый массив просто не имеет этих проблем «бай дизайн», тех самых, которые мы героически преодолеваем в случае библиотек.
    Планировать резервное копирование придется “бай дизайн” в любом случае, иначе ни лент, ни винтов не хватит. А про “не имеет этих проблем” Вы мне еще расскажете в следующей статье, когда offsite backup будете описывать.

    >> возможностей меньше.
    >Возможностей больше. Вон, наверху, целых семь разных преимуществ дисков над лентами приведено.
    Возможностей меньше 🙂

    Ссылки на самого себя – это демагогия.

    Всё это очень забавно, конечно, однако почему нет экономического обоснования? Техническая аргументация хромает, так давайте деньги подсчитаем для сферического датацентра в вакууме 🙂

  16. > однако почему нет экономического обоснования?

    Такие работы я обычно делаю за деньги 😉

  17. если меня зачислили в сторонники “«панацеей» хранение на лентах”, то это не так =)
    просто оба инструмента имеют свои плюсы и минусы. и однозначно списывать со счётов ленты не стоит. но, я думаю, вы к этому вопросу вернётесь в следующей части, когда речь зайдёт про офссайтовый бэкап. =)
    я сторонник разумного подхода к выбору инструмента под задачи поставленные бизнесом.

  18. А только у меня вторая часть не отображается в списке новых статей? Или так задумано?

  19. >А только у меня вторая часть не отображается в списке новых статей?
    Исправолено. Спасибо.

  20. А о каких объемах копья ломаем ?

  21. хм… ну давайте возьмем 100Тб как типичный объем для бекапов, зависит от длительности хранения, бывает в разы больше.
    кассета LTO5 стоит около $100 это 1,5Тб raw data.
    нам понадобится 67 кассет.
    Стоимость роботизированной библиотеки $30k-$40k + софт
    Итого примерно $50k за 100Тб, при этом надо учитывать, что библиотека в режиме ожидания практически не потребляет энергии, а при работе потребляет около 200Вт, что нельзя сказать о дисковом массиве, который жрет постоянно в 10 раз больше.
    Также стоит учитывать что данные которые льются на библиотеку как правило уже упакованы и дедуплецированы тем или иным образом.
    Стоимость добавления емкости копейки.

    Стоимость системы от NetApp на такой объем примерно в 10 раз больше. Стоимость добавления емкости сказочная, т.к. из за малого объема заказа скидка будет маленькой, т.е. систему надо брать с запасом, а это еще дороже.

    Брать дешевую китайскую дисковую систему? нет уж…

    При нормальных объемах данных, экономически оправданной альтернативы ленточным библиотекам нет.

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

  23. Вот 🙂 100Тб это уже и библиотеки и тд.
    а если всех данных 1-2Тб ? (это и то много для малого бизнеса) тогда дисковые массивы лучше ?

  24. > а если всех данных 1-2Тб ?
    Тогда берем 2-5 USB винтов и меняем их каждое утро 🙂

  25. > да и обычно последний бекап на лентах вынимают и кладут в сейф, ибо от пожара RAID не поможет.

    От пожара или от “выемки документов” лента в локальном сейфе (как и библиотека на локальном сайте) тоже ничем не поможет, это профанация и самоуспокоение. Поможет в банковской ячейке.
    А это уже несколько более сложная процедура.

    > ну давайте возьмем 100Тб как типичный объем для бекапов,
    А почему 100, а не один, и не миллион? 😉
    Налицо классический пример подгонки условий задачи под необходимый результат.

  26. а если вместо usb ethernet диск и удаленная разностная репликацмя ?

  27. > Стоимость системы от NetApp на такой объем примерно в 10 раз больше.

    Вы традиционно попадаете в плен одной типичной ошибке при сравнении. Это снова про “молоток”.
    Система “от NetApp” будет стоить “в десять раз больше” (кавычки мои, прим. romx), да, при равных объемах. Но при этом, например, вы забываете, что емкость решения с использованием NetApp может оказаться в десять раз меньше за счет использования ее технологий, той же дедупликации или FlexClone, а восстанавливать данные она будет в десять раз быстрее, что в десять раз сократит простой вашей бизнес-системы в случае сбоя.
    Это вы учитываете? По видимому нет.

    Получается сравнение: “А телега весит всего 300 кг, а ваш автомобиль – три тонны. Это ж в него придется целый табун лошадей запрячь, а на них столько сена да овса уйдет!”
    Разные устройства, с разными принципами действия, требуют разных подсчетов стоимости. “Стоимость решения” не равно “цена устройства”!