Так ли незаменимы магнитные ленты для бэкапа? Часть 4
Обычно “в пику” дискам сторонники лент приводят два возражения. Во-первых – как сделать удаленное хранение, о варианте решения этой задачи я говорил в прошлом посте. Во-вторых - как организовать “длинные” циклы retention. Несмотря на то, что я рассказывал в самом первом посте цикла, о той разнице, которая разделяет понятие “резервная копия” и “архивная копия”, многие компании хотят иметь резервные копии на протяжении значительного периода времени, например года, такие резервные копии уже постепенно переходятпо своему статусу в “архивные”, но согласен, что длинный цикл ротации бэкапов, с возможностью откатиться на довольно отдаленный момент времени состояния данных может быть удобен во многих случаях.
Поскольку в этом блоге я обычно пишу преимущественно о системах хранения NetApp, а вот уже три выпуска подряд я говорю о системах хранения “вообще”, позволю себе вернуться именно к NetApp, и рассматривать в дальнейшем именно их, впрочем, за вычетом ряда специальных возможностей, могие вещи будут иметь сходные реализации и в дисковых системах хранения других вендоров.
Давайте посмотрим, насколько длинный цикл retention мы можем организовать с помощью систем NetApp FAS и их возможности создавать снэпшоты.
Напомню, что каждый том данных на системе NetApp FAS может иметь до 255 снэпшотов.
Давайте воспользуемся ими и организуем с их помощью классическую бэкапную ротацию:
- “Часовой” снэпшот, с интервалом каждые 6 часов круглосуточно, с хранением затем в течении суток.
- “Дневной” снэпшот, каждый день, всю неделю, в 10 вечера, с хранением в течении 4 месяцев
- “Недельный” снэпшот, каждое воскресенье в 10 вечера, с хранением на 2 года
- “Месячный” снэпшот, каждое первое воскресенье месяца, с хранением на 7 лет
|
Example Schedule |
||||
|
Retention |
||||
|
Schedule |
Frequency |
Time |
||
|
Hourly |
Every 6 hours |
4AM, 10AM, 4PM |
24 |
Hours |
|
Daily |
Mon-Sun |
10PM |
90 |
Days |
|
Weekly |
Every Sunday |
10PM |
104 |
Weeks |
|
Monthly |
1st Sunday in Month |
10PM |
84 |
Months |
Обратите внимание, что по принципу действия такого снэпшота, любой из них будет являться для потребителя full backup (хотя внутри, скрыто от пользователя, конечно же incremental), то есть любой из этих 245 снэпшотов будет иметь полный набор данных тома на соответствующий момент времени.
??того такая схема ротации всего в 245 снэпшотов на том позволит нам иметь цикл непрерывной ротации бэкапов данного тома, ни много ни мало – 7 лет!
romx - Четвертый снимок отсутствует в первом расписании.
Ivan ээээ… См. второе расписание? 8)
Что именно? шедулить месячный бекап средствами массива нельзя, на сколько я в курсе. Например, тот же SAP Snapmanager hourly класс позволяет задать с промежутками, и если идет через каждые 6 часов, то и делать он их будет 4 в сутки, что не так? ??ли snapmanger сам решает какое расписание имеет больший приоритет?
ЗЫ: я ждал этого возражения :)
Ivan, SM for Hyper-V использует виндовый скедулер + указывается срок убийства или количество хранимых по данному schedule, соответственно настраивается всё что угодно, и вышеприведённая табличка вполне реализуема. Если в каком-то из тулзов неудобная система скедулинга, то тут вопрос к это программе (просить разработчиков допилить; использовать другую программу; использовать совместно с ней какой-нибудь скрипт, удаляющий лишние снэпшоты), а не к хранилке.
Проблема со снапшотами заключается в том, что из них неудобно восстанавливаться, особенно в случае VMWare. Классический пример - снапшот VMFS или NFS раздела. Задача - восстановить отдельный файл внутри виртуальной машины или, например, обьект какого-либо приложения (tablespace в базе данных, почтовый ящик в Exchnage и т.д.) внутри виртуальной машины. При использовании традиционного бекап софта, установленного внутри гостевой OS, восстановление происходит нажатием одной кнопки. В случе снапшотов приходится монтировать снапшот и ковырять vmdk файл, это не всегда тривиальная задача, особенно если задачу восстановления нужно доверить людям из суппорт-деск. В данном случае я не говорю что бекапы на диск плохи “вообще”, но использование только снапшотов при полном отсутствии нормального бекап-софта накладывает серьёзные ограничения на процесс восстановления. При этом есть уже куча бекап-продуктов, которые умеют оптимально использовать диск в качестве target’a для бекапа, делают дедупликацию данных и прочее. Это я всё к тому, что в случае НетАппа мы имеем ту же ситуацию с молотком и гвоздями: у них есть снапшоты которыми они пытаются решить ВСЕ проблемы восстановления, даже когда есть более эффективные методы.
deepblue,
Как вы сами и сказали - стороннего цельного софта нет (есть NetAppовский но недопиленный\нецентрализованный он какой-то: россыпь SnapManager продуктов для разных нужд).
Кстати для чисто VMWare нужд SMVI вполне пригож. Уж машину из бэкапа поднять просто.
Не храните в vdmk ту информацию, которая лучше себя будет чувствовать в виде файлов на CIFS/NFS. Покупайте те программы, которые Вас устраивают: решения средствами СХД предлагает NetApp, решения другими средствами - другие вендоры.
Про единую могучую систему восстановления Всего - улыбнуло. ??нтересно, чей же это должен быть инструмент - Властелина Мира? Чтоб и за БД отвечал он, и за виртуалки он, и за файлы пользователей - он - Великий и Ужасный. Я сомневаюсь, что рынок SOHO/SB (где для всего этого - один админ) интересен NetApp.
> Классический пример - снапшот VMFS или NFS раздела. Задача - восстановить отдельный файл внутри виртуальной машины или, например, обьект какого-либо приложения
Не совсем понятна претензия к NetApp в данном ключе. Да, NetApp много что не может. Кофе варить и за пивом сбегать - тоже :)
Но его ли это задача? Вина ли NetApp в том, что VMware сделала VMFS закрытой, и не обеспечила сторонним решениям доступ к его содержимому (кроме как через ублюдского VCB)?
Разве задача NetApp обеспечить доступ к данным приложения для резервного копирования, разве не само это приложение должно об этом позаботиться, и предоставить соответствующие инструменты?
По моему вы брсаетесь в другую крайность и считаете NetApp и снэпшоты “идеальной панацеей”, “единственым возможным решением для всего”, иначе я не могу представить что именно вас спровоцировало на такое о нем мнение.
Это просто система хранения данных. Не нужно требовать от нее больше функций, чем выполняет внешняя сетевая система хранения данных.
Да, есть снэпшоты, и средства их использующие для комплексной защиты данных _конкретного_ приложения за счет глубокой интеграции с ним. Но если о гранулярности своих данных через снэпшоты не позаботится само приложение, то NetApp сможет ровно то, что может - сохранить crash-consistent копию файловой системы или LUN.
Претензий у меня ни к кому нет :) Просто то, как мы перешли с темы бэкапа на диски (что есть гуд) к теме снэпшотов, может создать впечатление, что снэпшоты - это самый правильный метод решения задачи бэкапа на диски. Я попытался указать, почему во многих случаях это не так. ??дея бэкапа на диски не нова, проблема всегда была в том, что мейнстрим бэкап софт не умел и до сих пор часто не умеет эффективно эти самые диски использовать. Потом появились нишевые продукты, которые эту проблему решили с помощью дедупликации - PureDisk, Avamar. Сейчас с разным успехом эти функции встраиваются в мейнстрим продукты. Ну и про DataDomain с которым у НетАппа не получилось, тоже забывать не стоит. На мой взгляд снэпшотами заменить функционал полноценного бэкап софта нельзя.
> может создать впечатление, что снэпшоты - это самый правильный метод решения задачи бэкапа на диски.
Знаете что самое сложное в “общении с читателями”?
Разгорваривать с “вчитывающими”. Так я называю тех, которые вместо прочтения того, что написано автором, то есть мной, начинают читать (и спорить следом) то, что автор не писал, а то, что их самих “беспокоит” в даный момент.
За прошедшие полторы недели меня успели обвинить (по порядку):
1. В том, что я предлагаю выкинуть все ленты, и использовать только диски
2. В том что я пиарю NetApp и пощу проплаченне посты (на тот момент даже слово NetApp ни в одном посте из трех еще даже не упоминалось).
4. В том, что приведенные мной описания “наполнены однобокими расчетами” (при том что я вообще никаких ценовых расчетов кроме цены отдельного устрйства “по прайсру” не привел).
Может что и пропустил, лень бегать по комментам.
Можете смело добавить к этому ваше: “что снэпшоты - это самый правильный метод решения задачи бэкапа на диски”.
Возможно вы будете шокированы внимательно прочитав пост, но то, что вы там “прочитали” родилось в вашей голове, и я этого не говорил. Спасибо за доверие, конечно, но если вы хотите говорить со мной, то давайте говорить о том, что я на самом деле утверждал, а не о том, что вы мне приписали. Благодарю за внимание :)
> проблема всегда была в том, что мейнстрим бэкап софт не умел и до сих пор часто не умеет эффективно эти самые диски использовать.
Самое смешное, что в недавнем посте в параллельном треде (про VTL) меня чуть не на британский флаг порвали, оспаривая необходимость эмуляции ленты на VTL, “ведь все давно умеют писать на диски”. Строго говоря все это действительно так. Например популярный Backup Exec 10d (и далее), появившийся в 2006, если не ошибаюсь, году, именно потому и “d”, что умеет использовать диски нативно. NetBackup 6.5 умеет это точно, про 6.0 не помню, 5.0 умел работать с дисками как с “псевдолентами”.
Так кто из современного бэкап-софта не умеет писать на диски нативно или через “псевдоленту” (без эмуляции) хотя бы?
> Ну и про DataDomain с которым у НетАппа не получилось
Ну насчет “не получилось” это еще вопрос, кому больше хотелось. У NetApp есть уже лет пять как есть и продается вполне неплохой свой собственный продукт этого класса - NetApp VTL.
>Возможно вы будете шокированы внимательно прочитав пост, но то, что вы там
>“прочитали” родилось в вашей голове, и я этого не говорил. Спасибо за доверие,
>конечно, но если вы хотите говорить со мной, то давайте говорить о том, что я на
>самом деле утверждал, а не о том, что вы мне приписали. Благодарю за внимание :)
ОК, просто ваша серия постов прочиталась иманно так. Раз посты называются часть 1,2,3,4, я за вас додумал, что вы рассматриваете вариант замены снэпшотами традиционной связки “бэкап софт-лента”. “Бэкап софт-диск” - более равнозначная замена, это всё, что я хотел сказать.
Если я вас не так понял, то беру свои слова обратно, мир-дружба-жевачка.
>Самое смешное, что в недавнем посте в параллельном треде (про VTL) меня чуть
>не на британский флаг порвали, оспаривая необходимость эмуляции ленты на
>VTL, “ведь все давно умеют писать на диски”. Строго говоря все это действительно
>так. Например популярный Backup Exec 10d (и далее), появившийся в 2006, если
>не ошибаюсь, году, именно потому и “d”, что умеет использовать диски нативно.
>NetBackup 6.5 умеет это точно, про 6.0 не помню, 5.0 умел работать с дисками как
>с “псевдолентами”.
>Так кто из современного бэкап-софта не умеет писать на диски нативно или через
>“псевдоленту” (без эмуляции) хотя бы?
??мелось в виду, что если использовать традиционные политики типа “полный бэкап раз в неделю/инкрементальный раз в день” с дисками, то дисковое решение быстро становится слишком дорогим, вы сами об этом писали. Только сейчас вендоры начали добовлять фичи в бэкап-софт типа той же дедупликации, которые делают задачу бекапа на диск экономомически оправданной.
>Ну насчет “не получилось” это еще вопрос, кому больше хотелось. У NetApp есть
>уже лет пять как есть и продается вполне неплохой свой собственный продукт этого
>класса - NetApp VTL.
Ну NetApp VTL с DataDomain я сравнивать не стал бы, это разного класса продукты, иначе бы NetApp не предлагал за них $ 1.9 миллиарда. :)
Дабы не навлечь на себя потоков гнева на этом блоге, добавлю, что DataDomain и NetApp VTL - разного класса продукты в рамках конкретной задачи (backup 2 disk). Насколько я понял, NetApp VTL, как отдельный продукт, вообще собираются прибить, что, в принципе, логично:
http://www.enterprisestorageforum.com/continuity/news/article.php/3863086/NetApp-Halts-VTL-Deduplication-Development.htm
> Только сейчас вендоры начали добовлять фичи в бэкап-софт типа той же дедупликации, которые делают задачу бекапа на диск экономомически оправданной.
Ну тут я могу лишь сказать, что считаю возложение задачи дедупликации на сторадж, выбранный NetApp абсолютно правильным.
> иначе бы NetApp не предлагал за них $ 1.9 миллиарда. :)
Мое мнение (которое может не совпадать с мнением NetApp) что в истории с покупкой DDUP NetApp покупал в первую очередь клиентскую базу.
> NetApp VTL, как отдельный продукт, вообще собираются прибить
Там вообще запутанная история какая-то. Официально это звучт так: прекращена дальнейшая разработка VTL как продукта. Продолжается его продажа по состоянию на сентябрь прошлого года. Почему-отчего - комментариев получить не удалось, увы.
> Ну тут я могу лишь сказать, что считаю возложение задачи дедупликации на сторадж, выбранный NetApp абсолютно правильным.
??нтересно, на основании чего вы думаете, что дедуплицировать лучше на сторадже? Понятно что у NetApp выбора особенно не было, но в зависимости от задачи будут разные аргументы “за” и “против”. Раз уж мы взялись за бэкап, то здесь всё совсем неоднозначно. Традиционно бэкап - это самые большие потоки данных и логично их дедуплицировать на стороне хоста, чтобы снизить нагрузку на сеть, особенно при бэкапах на расстоянии. DataDomain, вот, придумал DD Boost, который дедуплицирует данные на стороне бэкап сервера, хотя на сторадже уже давно это умеют делать, как с этим дела у НетАппа?
> ??нтересно, на основании чего вы думаете, что дедуплицировать лучше на сторадже?
По-моему очевидно. Потому что в таком случае это прозрачно для приложений, работает с любой системой резервного копирования, и грузит этой задачей (притом оффлайново) только сторадж, снимая нагрузку с сервера резервного копирования, которому и так обычно нелегко.
> чтобы снизить нагрузку на сеть, особенно при бэкапах на расстоянии.
В решении NetApp “на расстояние” ( на вторичное, удаленное хранилище) передаются уже дедуплицированные на первичном хранилище данные. То есть сперва оно бэкапится локально (не слишком разумно сразу бэкапить удаленно, помним про неободимость быстрого рестора оперативного бэкапа “только что”), дедуплицируется в процессе жизни, после чего реплицируется уже дедуплицированным.
Раз уж перечислили все “за”, стоит перечислить и все “против” использования НетАпп дедупликации для бэкапных данных:
- Если делать дедупликацию на хосте, то запись идёт быстрее, так как данные по сети передаются в уже дедуплицированном виде и сеть загружается намного меньше. Это особенно актуально для VMWare, где сетевой ресурс часто ограничивает коэффициент консолидации. Чаще всего при миграции с физических на виртуальные хосты приходится переделывать всю схему бэкапа и дисковая дедупликация здесь к сожалению никак не помогает.
- Низкий коэффициент дедупликации (fixed-length block алгоритм), обычно не удаётся добиться больше, чем 10-20% дедупликации, в интернете полно материала на эту тему. Решения специально заточенные под эту задачу дают намного лучший результат.
- Дедупликация делается по расписанию ПОСЛЕ того, как данные записаны на диск. Даже если можно 100Гб дедуплицировать до 90Гб, первоначально всё равно нужно будет 100Гб свободного места.
Вообще моё личное субъективное мнение - самое лучшее место для такой дедупликации - “файловые шары”. “Включил и забыл” и место экономится.
Для бэкапов эта функция почти бесполезна именно по причинам перечисленным выше.
> Если делать дедупликацию на хосте, то запись идёт быстрее
Зато нагружается процессор хоста _в момент бэкапа_, что снижает его производительность, и, как следствие, скорость записи. От чего ушли - к тому пришли.
> Это особенно актуально для VMWare, где сетевой ресурс часто ограничивает коэффициент консолидации.
Если датасторы VMware хранятся на NetApp FAS, то они обычно уже дедуплицированы на момент бэкапа (и весьма эффективно, обычно, по практическому опыту, 70-90%. Если использовать нетапповское же решение репликации Volume SnapMirror, то трафик оказывается дедуплицированным.
> Низкий коэффициент дедупликации (fixed-length block алгоритм)
На VTL есть и variable block.
> обычно не удаётся добиться больше, чем 10-20% дедупликации
У NetApp на этот счет есть другие сведения.
> Дедупликация делается по расписанию ПОСЛЕ того, как данные записаны на диск.
Да, и это не минус, повторюсь, это огромный плюс! Процесс дедупликации никак не влияет на производительность системы, так как асинхронен с процессами. А место… Что место? Это просто диски. Диски купить куда как проще и дешевле, чем производительность и время сохранния/восстановления. Как я уже говорил по другому поводу: получить производительность по цене дисков это весьма неплохой deal по нынешним временам.
> Для бэкапов эта функция почти бесполезна именно по причинам перечисленным выше.
Я ответил?
deepblue>??нтересно, на основании чего вы думаете, что дедуплицировать лучше на сторадже?
К примеру одно ПО может дедуплицировать, другое нет, в рамках стораджа так хранить данные не эффективно: одни данные дедуплицированны, другие нет. Что вас подвигло на этот _странный_ вопрос не пойму, ответ очевиден.