Системы хранения данных как предмет разговора
Posts tagged ‘backup’
??менно так, 31 марта празднуется Всемирный День Бэкапа.
А что ты сделал сегодня, чтобы бесцельно провести этот день не остаться первого апреля главным дураком года?
Давай-давай, закрой уже блог, завтра придешь почитать, никуда он от тебя не денется, он-то как раз еженедельно дампает базу, а вот ты, да-да, ты, что ты сделал сегодня полезного, если завтра придет песец жареный петух?
Продолжим наш курс Back to basics. Кроме репликации SnapMirror у NetApp есть еще один Snap-что-то продукт – SnapVault. Давайте посмотрим, что это и для чего может в жизни сгодиться.
SnapVault, как можно догадаться из названия, это средство, позволяющее сложить снэпшоты (Snap) на долговременое хранилище (Vault), то есть это такое средство бэкапа данных с системы хранения, например главной, рабочей, или, в терминах NetApp – Primary, на резервную, или Secondary.
Зачем? Ну, зачем вообще используется резервное копирование на другой сторадж? Чтобы обезопаситься и обезопасить данные от физического отказа системы хранения. Почму бы для этого не использовать SnapMirror? Очень просто. Потому же, почему RAID это не бэкап. Репликация никак не поможет в случае повреждения непосредственно данных. Поврежденные данные, например испорченные на уровне приложения, точно также отреплицируются на резервную систему, и вы будете иметь два комплекта плохих данных. Тут выручили бы снэпшоты. Но снэпшоты, как вы помните, хранятся на самой системе хранения, непосредственно на исходном томе, такова их принциппиальная конструкция, и если мы вдобавок ко всему, имеем поврежденную или физически потерянную primary систему хранения, то вместе с ней погибнут и данные снэпшотов. Хорошо бы эти снэпшоты уметь выносить куда-то наружу, чтобы потом иметь возможность из них исходные данные не любой сохраненный момент восстанавливать. Вот как раз этим и занимается SnapVault.
Думаю, что все мои читатели уже относятся к категории “уже делающих бэкапы”. Однако остается вопрос: как именно он их делают? Какой метод создания резервных копий данных вы выбрали для вашей системы хранения NetApp?
[poll id="6"]
Опрос, как и всегда, анонимен.
Возможны множественные ответы.
Если у вас есть вариант, не перечисленный выше, и который вы хотите указать - не стесняйтесь привести его в комментариях.
Все предшествующие опросы в блоге можно посмотреть в рубрике Опрос
Совсем кратенько об анонсированном на днях продукте NetApp SnapProtect.
В новостях, конечно, вывалена тонна маркетингового булшыта, который я не люблю точно также, как и вы.
Но чтобы сразу прояснить что к чему, позвольте сразу расставлю “точки над ё“. NetApp SnapProtect это OEM версия продукта организации резервного копирования Commvault Simpana 9, который будет продаваться непосредственно от NetApp и по его каналам, под названием SnapProtect (ну вот примерно как IBM продает N-series).
Продукт очень интересный, возможно даже самый интересный, “фичастый” и перспективный на всем сегодняшнем рынке резервного копирования, и с NetApp он дружит много лет. В недавнем гартнеровском Magic Quadrant по Disk-to-Disk Backup, Commvault – безусловный лидер рынка. Просто даже удивительно, отчего на российском рынке продукты Commvault так плохо представлены и плохо знакомы потребителям.
Ну и вполне естественным и разумным ходом для NetApp было бы не изобретать свой собственный велосипед, а взять в качестве готового решения лучшую модель на рынке, и продавать ее.
Вообще ситуация с продуктами резервного копирования у NetApp довольно любопытная. В разных продуктах NetApp встречаются сразу три разных вендора софта резервного копирования. Open Systems SnapVault делал Bakbone, ранее в этом году был обнародован продукт NSB (NetApp Syncsort Backup) совместный с еще одним малоизвестным и нишевым бэкап-вендором – Syncsort, и вот, наконец, NetApp решил не мелочить, а заняться продуктом-лидером.
Ну и прекрасный выбор, я считаю.
??з основных и самых заметных фич перечислю:
SnapProtect Management Software
NetApp SnapProtect Management Software Overview and Design Considerations
The Virtual Storage Guy: Introducing NetApp SnapProtect Backup
Я уже рассказывал в этом блоге отчего, несмотря на то, что на хранилище NetApp вы видите LUN, то есть объект SAN-сети, как “файл”, лежащий на пространстве тома, LUN в NetApp делаются совсем НЕ через “эмуляцию поверх файловой системы”. Однако такая любопытная “оптическая иллюзия” с видимостью LUN-а как файла, часто приводит к определенным (к сожалению распространенным) ошибкам понимания, в частности к соблазну “сбэкапить” такой LUN как файл.
Так вот, обратите внимание, что из того факта, что на “зашаренном” volume вы видите LUN-ы на нем созданные как файлы, не следует, что “LUN-ы это файлы”.
Если вы, допустим, бэкапите такие LUN-ы, то бэкапить их надо ТОЛЬКО как содержимое volume, то есть от “корня”, вместе с томом, либо с qtree, если последний используется. ??наче вы потеряете при таком копировании metadata (они хранятся внутри volume), определяющие внутри NetApp LUN именно как LUN, и не сможете восстановить его на прежнее место как LUN, то есть как устройство с блочным доступом.
То есть, для бэкапа содержимого LUN, например это LUN01, лежащий на томе vol1, недостаточно просто скопировать “файл”, лежащий по адресу //filer1/vol1/LUN01, нужно копировать целиком vol1!
Аналогична ситуация и с восстановлением. Восстанавливать надо том вместе со всеми LUN-ами на нем, а не просто отдельный “файл” LUN-а, так как, в противном случае, не будут востановлены специфические метаданные SAN-объекта.
То есть, если вы сбэкапили LUN, а затем восстановили, и не можете смонтировать его как LUN, а видите его как “просто большой файл”, то это вот тот самый случай.
Разумеется, все изложенное выше касается только “бэкапа со стороны стораджа” (например по NDMP), а не бэкапа “изнутри” OS, работающей с данным, смонтированным на нее LUN-ом, как своей файловой системой.
Еще читать: https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb37566
Тема магнитных лент не отпускает долго. Тем не менее, приближаемся к финалу.
В прошлой и позапрошлой статье под заголовком “Так ли незаменимы магнитные ленты для бэкапов” я рассмотрел два популярных “кейса”, считающихся классической “вотчиной” ленточного метода хранения, а именно: удаленное хранение копии и “длиные” retention, или циклы хранения копий, и показал, как эти задачи могут быть решены с использованием дисковых систем хранения, в частности интересующих меня NetApp.
Однако в комментариях подсказали и еще один кейс. Дело в том, что “оффлайновое” хранение данных в случае ленты облегчает неизменямое хранение сохраненных данных. Ведь в случае онлайн-хранения на дисках, при всех плючах такого хранения, сохраняется определенная опасность того, что онлайн-копия може быть случайно или злонамеренно повреждена. Особенно это важно в случаях, когда немодифицируемое долговременное хранение определено соответствующим законодательством страны. Так, например, такие условия хранения архивных данных определены в США для публичных компаний (акт Sarbanes-Oxley), для биржевых брокеров (SEC Rule 17a-4), компаний, работающих в области здравоохранения (HIPAA), правительственных учреждений (DOD 5015.2) и других случаях. Зачастую в этих требованиях фигурируют сроки такого хранения, исчисляемые десятками лет.
Для решеня этой залачи у NetApp есть сравнительно малоизвестная в России функция, и о которой я пока еще не писал, но которая, тем не менее, по понятным и описанным выше причинам, широко применятся в инсталляциях за рубежом – SnapLock.
Я уже рассказывал, что лежащая в основе всех систем хранения NetApp пециальная файловая структура – WAFL, имеет одну очень интересную особенность. Эта особенность, в свою очередь, определяет один из базовых приципов ее работы, используемой системой.
В WAFL единожды записанный блок в дальнейшем не модифицируется. В случае необходимости изменить данные, хранящиеся в этом блоке, диспетчер блоков выделяет для записи измененных данных пустой блок из пула свободных блоков. На основе этого принципа работает механизм снэпшотов (Snapshots), о котором я уже таже писал, и иллюстрировал принцип работы несложной анимацией, посмотрите по ссылке, возможно станет понятнее, как это работает.
Процесс записи изменений в новые блоки происходит до тех пор, пока файл, которому принадлежат эти блоки данных существует. После того, как удаляется файл и все его снэпшоты, все блоки помечаются в битовой карте как “пустые”. Таким образом, процесс записи возможен только таким образом: если блок пустой, то его можно записать. Если блок уже не пустой, то повторная запись в него невозможна. Пока файл существует, то все принадлежащие ему блоки WAFL сохраняются неизменными. Если блок записан, то средств изменить его “непустое” содержимое у OS нет.
Это, так сказать, основа функциональности WAFL.
Таким образом, мы видим, что заблокировав в OS одну единственную функцию, которая помечает блоки данной файловой системы как неиспользуемые, мы легко превратим наш раздел на системе хранения в строгий WORM (write once, read many).
У системы хранения просто не будет никакой физической возможности внести изменения в уже записанные данные, а при необходимости, даже заблокировать удаление их.
??менно этот функционал в NetApp называется опцией SnapLock.
SnapLock существует в двух вариантах, отличающихся строгостью их использования: SnapLock Compliance и SnapLock Enterprise.
Первый вариант – это самая строгая реализация описанных требований Compliance. Для дискового тома в момент конфигурирования задается срок его WORM-состояния, и после этого нет никаких возможностей изменить или удалить записываемые на этот том данные на весь заданный срок. Вообще никаких. Никому, включая админа системы с “рутовыми” правами. Даже после физической перестановки дисков в другую систему. Надежность работы подтверждена многочисленными сертификациями на соответствие вышеперечисленным законодательным актам.
Менее строгая SnapLock Enterprise позволяет, также как и для SnapLock Compliance, задавать период неизменяемого хранения, однако “высший” администратор системы хранения, по-прежнему не имея возможности изменить хранимые данные, может, при необходимости, такой том удалить целиком.
Таким образом, использование SnapLock на системах хранения NetApp может помочь реализовать заведомо надежно защищенное от возможности удаления или изменения данных хранилище, в тех случаях, когда такие требования стоят во главе угла.
Обычно “в пику” дискам сторонники лент приводят два возражения. Во-первых – как сделать удаленное хранение, о варианте решения этой задачи я говорил в прошлом посте. Во-вторых - как организовать “длинные” циклы retention. Несмотря на то, что я рассказывал в самом первом посте цикла, о той разнице, которая разделяет понятие “резервная копия” и “архивная копия”, многие компании хотят иметь резервные копии на протяжении значительного периода времени, например года, такие резервные копии уже постепенно переходятпо своему статусу в “архивные”, но согласен, что длинный цикл ротации бэкапов, с возможностью откатиться на довольно отдаленный момент времени состояния данных может быть удобен во многих случаях.
Поскольку в этом блоге я обычно пишу преимущественно о системах хранения NetApp, а вот уже три выпуска подряд я говорю о системах хранения “вообще”, позволю себе вернуться именно к NetApp, и рассматривать в дальнейшем именно их, впрочем, за вычетом ряда специальных возможностей, могие вещи будут иметь сходные реализации и в дисковых системах хранения других вендоров.
Давайте посмотрим, насколько длинный цикл retention мы можем организовать с помощью систем NetApp FAS и их возможности создавать снэпшоты.
Напомню, что каждый том данных на системе NetApp FAS может иметь до 255 снэпшотов.
Давайте воспользуемся ими и организуем с их помощью классическую бэкапную ротацию:
|
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 лет!
??так, в двух предыдущих постах серии я попытался вас убедить, что на сегоднящний день устройства для записи на магнитную ленту (стримеры или ленточные библиотеки, “tape library”) часто значительно проигрывают в удобстве, цене и надежности решения простым и эффективным дисковым NAS-массивам на дисках SATA.
Continue reading ‘Так ли незаменимы магнитные ленты для бэкапа? Часть 3’ »
В прошлый раз мы начали разговор о том, насколько полезно забивать шурупы молотком правильно рассматривать магнитные ленты как единственную опцию в качестве способа хранения данных при резервном копировании, и пришли к выводу, что примененяя их для задачи резервного коирования мы сталкиваемся с рядом существенных, и что самое неприятное, врожденных и неизлечимых их недостатков.
Недостатков этих лишены дисковые системы хранения, которые, впрочем, долгое время, пока не случилось обвальное удешевление недорогих дисков SATA, использовать для хранения резервных копий было накладно. Однако при сегодяшних ценах дисковые массивы уже вполне способны составить конкуренцию магнитным лентам по цене хранения, одновременно будучи лишены уже названных выше недостатков.
Разберем их чуть детальнее:
Continue reading ‘Так ли незаменимы магнитные ленты для бэкапа? Часть 2’ »
Есть такая поговорка про “зашоренность мышления” и следование типовыми путями:
“Если в руке молоток, то все вокруг кажется гвоздями”
в том смысле, что когда человек смотрит на задачу только с одной стороны, то всегда хочется выбрать уже известное решение, даже если возможное решение и не одно.
Одним из самых консервативных направлений в IT является направление систем и устройств резервного копирования.
Действительно, зачем “искать от добра добра”, всю жизнь использовали ленты (зачастую это не метафора, подозреваю что у большинства меня читающих вся жизнь, с рождения и по сегодня, с запасом уложилась в срок существования магнитных лент как средства хранения информации в индустрии), зачем от них отказываться, раз и так все работает?
Тем не менее давайте посмотрим на нынешнее положение в отрасли и оценим, возможно не все кругом – гвозди, и есть возможность не заколачивать шурупы молотком.
Continue reading ‘Так ли незаменимы магнитные ленты для бэкапа? Часть 1’ »