Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Так ли незаменимы магнитные ленты для бэкапа? Часть 2 | about NetApp

Так ли незаменимы магнитные ленты для бэкапа? Часть 2

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

Недостатков этих лишены дисковые системы хранения, которые, впрочем, долгое время, пока не случилось обвальное удешевление недорогих дисков 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 (”вынесенное” хранение резервных копий), а также длинные ротации бэкапов, исчсляемые годами.

15 комментариев

  1. kdv:

    30 мегабайт в секунду - это скорость чтения-записи на внешний usb-диск (usb 2.0). А примерно 35 мегабайт в секунду - максимальная реальная скорость передачи данных по 1гбит ethernet.
    Просто для справки.

  2. Добейтесь этой скорости при резервном копировании, например, десяти тысяч файлов 1-2 кбайт размером, и если вам это удастся - вернемся к этому разговору ;)

  3. murzic:

    В данный момент NetApp подключенный к ленточной библиотеке по FC выдает нужные ей 120Mb/s
    Если люди знают, что такое лента, то скорость 35 Mb/s это смешно.

  4. > Если люди знают, что такое лента, то скорость 35 Mb/s это смешно.

    Не вполне ясно понял, что именно вы хотели сказать, изините.

  5. murzic:

    На предприятиях, которые способны позволить себе ленты (по деньгам), скорость бэкапа 35Mb/s это слишком мало. Врятли люди будут покупать LTO и при этом иметь Ethernet 100Mbps.

  6. Дело в том, что бэкап делается, как правило, на тех условиях, которые удобны бизнесу, данные которого бэкап сохраняет, а не сисадмину.
    ? это не зависит от богатства предприятия.

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

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

    Третий вариант - кроме серверов, которые наверняка уже “на гигабите” есть еще и локальные рабочие места, их данные тоже надо сохранять в очень большом количестве случаев. Они, все еще чаще всего, не на гигабите. А даже если и на гигабите, то опять же: мелкие файлы или слабые процессора.

    То есть ограничений скорости в реальной жизни всегда достаточно, и в них нет ничего смешного.

  7. Алексей:

    ?нтересно, что приведенные цифры сравнимы со стоимостью дисков в СХД. А уже если посчитать СХД целиком.

    ? ещё с первого поста на эту тему хотел отметить, что существую как библиотеки, так и ПО резервного копирования, осуществляющие, грубо говоря, RAIT (вместо disks tapes).

    ?МХО (впрочем, как и многих других) наиболее оптимальным по скорости/сохранности/цене является двухступенчатое резервное копирование, когда сначала льётся бэкап на диски, а после некоторого времени ротации с весьма быстрой скоростью сливается на ленты. Ну и, конечно же, резервное копирование выполняется не с оригинала данных и не на основном сервере, а с клонов на выделенном сервере резервного копирования.

    Так что по сути единственным, но безусловно сильно решающим фактором перехода только на B2D является набирающая силы дедупликация.

    PS. А про слабые процессоры в предыдущем коментарии - это вообще просто смешно!

  8. > ?нтересно, что приведенные цифры сравнимы со стоимостью дисков в СХД. А уже если посчитать СХД целиком.

    Какие цифры?

    > ? ещё с первого поста на эту тему хотел отметить, что существую как библиотеки, так и ПО резервного копирования, осуществляющие, грубо говоря, RAIT (вместо disks tapes).

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

    > А про слабые процессоры в предыдущем коментарии - это вообще просто смешно!

    Было приятно вас повеселить, но увы, это реальность жизни.

  9. Еще хороший пример про производительность гигабитной сети при копировании данных.
    Вот тут: http://forum.ixbt.com/topic.cgi?id=66:7954 человек уже третью неделю пытается выяснить, отчего у него по гигабитной сети скорость передачи между двумя win-клиентвми никак не поднимается выше 22-24 мегабайт в секунду.
    Так что остерегитесь ориентироваться на “паспортные” и “проспектные” показатели. Жизнь - непростая штука ;)

  10. Евгений:

    Спасибо автору, как обычно, полезно
    Хотел узанать вот что: вроде как есть библиотеки (какой то айбиэмовский стандарт) с произвольным доступом к носителю. Узнал об этом тупо из википедии. Не встречался ли автор с таким железои или кто-то из сообщества в “природе”?

  11. Чото как-то с трудом представляю себе ленту с random access. Я слышал, что есть(были) такие ленты с небольшим количеством в них ленты и быстрым позиционированием при этом. Даже в стандарте LTO такие были описаны, правда судя по всему остались на бумаге, и никогда не выпускались.
    У IBM был аналогичный формат 3570 Magstar

  12. Алексей:

    >>> ?нтересно, что приведенные цифры сравнимы со стоимостью дисков в СХД. А уже если посчитать СХД целиком.

    >>Какие цифры?

    Различные цифры стоимости, которые приводятся для сравнения. По стоимости хранения библиотеки пока (подчёркиваю, пока) остаются выгоднее дисков. Особенно при долговременном хранении.

    >>> ? ещё с первого поста на эту тему хотел отметить, что существую как библиотеки, так и ПО резервного копирования, осуществляющие, грубо говоря, RAIT (вместо disks tapes).

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

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

    >>> А про слабые процессоры в предыдущем коментарии - это вообще просто смешно!

    >>Было приятно вас повеселить, но увы, это реальность жизни.

    У наших заказчиков (особенно на рынке Enterprise) соблюдается старое доброе правило 80/20, т.е. 80% CPU загружены на 20%. А уж с выходом новых Power7 от IBM и новой серии Xeon от Intel вряд ли будет меняться без консолидации. ?менно поэтому так активно сейчас развивается виртуализация.

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

  13. > Различные цифры стоимости, которые приводятся для сравнения.

    Я не привожу никаких цифр для сравнения.

    > но есть ряд “нишевых” задач, где без лент не обойтись.

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

  14. bbk:

    Алексей>?МХО (впрочем, как и многих других) наиболее оптимальным по скорости/сохранности/цене является двухступенчатое резервное копирование
    Почти что согласен, но с учётом _предыдущего_поста_, являются ли копии, в этом вашем случае, заливаемые на ленту, _резервными_ али _архивными_? В чём разница? См. предыдущий пост.

    Алексей>Но упомяну так же наличие функционала периодической проверки лент.
    ? вот настаёт час Х и вы узнаете, что лента повреждена - царапина, к примеру, что дальше? Также не стоит забывать, что от того чем больше проверяются (и вообще используются) ленты, тем больше вероятность того, что они повредятся.

    Алексей>Я согласен с тем, что B2D более правильное и удобное решение, но есть ряд “нишевых” задач, где без лент не обойтись.
    В предыдущем посте и предложен вариант применения лент.

  15. GAV:

    Хотел прояснить немного по скорости бэкапа на ленту разных наборов данных:
    У нас бэкап происходит на ленточную библиотеку - HP MSL2024 (1*LTO6, SAS).
    Так вот, скорость заливки на стример _толстых_ файлах доходит до 320 Мб/сек, но на мелких падает до 3-5 Мб/сек.
    ? роботизированная ленточная библиотека - это реально круто!

Оставить комментарий

20/0.103

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.