В Разказахме ви за новите функции в излезлия през януари ъпдейт Update 4 за Veeam Backup & Replication 9.5 (VBR), където съзнателно не споменахме бекъпи на магнитни ленти. Разказът за тази област заслужава отделна статия, защото новите функции бяха наистина много.
– Хей, момчета от QA, ще напишете статия?
– Защо не!
Магнитни носители в XXI век
Съхранение на данни на магнитни ленти (касети, 'ленти‘, как както ги наричаме в R&D) не се ограничава до отминалия компютър ZX-Spectrum, чиято една игра можеше да зарежда в оперативната памет 48 kb от в продължение на няколко минути. През последните 25 години скоростите и капацитетът на лентите са се увеличили с 6-7 порядъка. Това не е съвсем коректно сравнение и спрямо стандарт не успява да се справи. Въпреки това, съвременните технологии позволяват на километрова лента от една касета да се запишат 12 терабайта данни (до 30 терабайта в компресионен режим), така че 160-доларовият носител оставя конкурентите зад себе си по разходите за дългосрочно съхранение на големи обеми данни, дори с оглед на вложенията в оборудването за запис/четене. Данните на такива касети се съхраняват надеждно в продължение на 15-30 години.
Да погледнем от друга страна. В последно време постигнаха ново ниво. Те могат да чакат своя час в инфраструктурата на голяма компания седмици и месеци, а с появата на нова уязвимост нулев ден – да унищожат (не без помощта на човек, понеже на карта стоят големи пари) не само всички данни, но и всички резервни копия, до които могат да достигнат. Ето , когато компанията се е наложило да плати на изнудвачите. Така наречените air gap, т.е. физически изолирани от инфраструктурата бекъпи станаха по същество единственото надеждно спасение от такива истории. Магнитната лента тук е едно от непреходните решения.
Но само спецификации и технологични иновации от водещите производители (IBM, HPE, Oracle, Dell) не са достатъчни за надеждна защита на данните, нужен е добър софтуер. При нас във Veeam цяла команда се занимава с ленточни бекъпи, около 10 души ежедневно анализират, планират, изследват, разработват и тестват. Резултатите от тази работа сте могли да видите в предишни статии (, ). Какво беше направено през последната година?
Глосар
Изборът е между свободите, свързани с родния език, и усложняващите четенето канцеларизми. Аз предпочитам първото, затова предварително се извинявам, ако на някого жаргонните думи от списъка по-долу ще му направят впечатление. Искам да припомня накратко какво означава всеки от термините.
На корифеите на VBR тази част може да бъде пропусната.Джоба – job – задача за резервно копиране. Всъщност, целият VBR е изградени на джобове. Освен резервното копие и репликацията, това може да бъде и копиране на магнитна лента (backup to tape job, тейп-джоба). Трябва да се уточни, че възстановяването от резервно копие (рестор) също е джоба, но в тази статия под това понятие ще се има предвид именно бэкап.
Сторадж – storage – исторически сложилото се наименование. Това са файлове в репозитории (repository – хранилище), които съдържат резервни копия – пълни и инкрементални. В един сторадж може да има както едната, така и няколко виртуални машини.
Цепочка – chain – последователност от свързани помежду си стораджи. За възстановяване на данни от n-то инкрементално сторадж са необходими всички предходни от (n-1)-то до 1-вото и пълното сторадж, на което се позовава първото инкрементално.
Сорс, таргет – source, target. Сорс – изходната същност, която обработва джобът. В случай на бэкапи/реплики това обикновено е виртуална машина в хипервизора. В случая на тейп-джоба сорсът е самата бэкап-джоба (или файловете в случай на file to tape-джоба). Таргет за бэкап-джоб е репозитория, където се съхраняват бэкапите. За тейп-джоб това е медия-пул.
Медиа-пул – – пул от носители на информация, в нашия случай – касети. Логически контейнер, създаден от потребителя, и съдържащ в себе си касети от една или няколко библиотеки. И така, тейп-джоба винаги има медия-пул като таргет, т.е. данните не се записват на конкретна касета или на каквато и да е касета в библиотеката, а на определен набор от тях. Медия-пулът има настройка за време на съхранение на данните, след което касетата може да бъде презаписана. Потребителят може да създава обикновени (standard) и . Всеки от тези видове сега може да бъде WORM и не-WORM, за което по-долу.
Медиа-сет – – набор касети в медиа пул, на които непрекъснато се записват резервни копия/файлове. За GFS пулове, медийните сетове също имат обвързване с интервал (например, годишен – yearly), касетите се ротира само в рамките на своя интервал.
– елементи на библиотеката с ленти. Дискът чете и пренавива касетата, чейнджерът – това е робот, който прехвърля касетите между слотовете за съхранение, слотовете за извеждане и диска. Има и стендалон дискове (standalone – самостоятелен), ролята на чейнджера тук се изпълнява от човек. За диска е задължително правилно инсталирания драйвер на производителя на Windows машина, на която е свързана библиотеката; с чейнджера, обаче, можем да работим и без драйвери, по native SCSI.
Тенант за лента. Защитен е доставчикът – защитени са клиентите
Веднага козирите на масата. Най-значимата функция на нашето обновление, предназначена за , използващи VBR в своята инфраструктура. Разработката започна преди две години. Скоро осъзнахме, че не можем да се справим с тази сериозна задача за следващия релиз, взехме малко пауза и в крайна сметка пуснахме функцията в 9.5 Update 4.
Накратко, сега доставчиците получиха възможност да копират резервните копия на своите клиенти на касети чрез тейп работа в GFS пул. Това дава на доставчиците – а те са много ценни за нашето сърце и търговския отдел – две възможности:
- да защитят своите клиенти (тенанти, tenant – наемател) от загуба на данни в резултат на случайно изтриване или инфраструктурни проблеми ("наводнение в сървърната зала");
- да предоставят на тенантите допълнителна услуга за възстановяване на данни от стара резервна копия, която вече отдавна е изтрита от облачния репозиторий в съответствие с политиката за съхранение на данни, но на касетите все още е останала.
От маркетингова гледна точка функционалността е много "вкусна", а за нас – не по-малко сложна за реализиране.
Разработка
Основният проблем, който възникна – криптиране на данни. Повечето облачни резервни копия са криптирани, статистиката показва ⅔ от общия брой. За нас това число беше изненада, предполагахме, че почти всичко е криптирано, но не – много клиенти, изглежда, безусловно вярват на своите доставчици.
Простата на парадигмата: провайдерът не трябва да може да дешифрира данните на своите наематели. В същото време, в рамките на новата функция, провайдерът трябва да отваря хранилища с резервни копия. Това е необходимо, за да могат да се прехвърлят блокове от данни, например, за създаването . Най-важното е, че това трябва да се прави независимо от наемателя, когато необходимите ключове не се предават на страната на провайдера по време на изпълнението на задачата.
Решението на този проблем, което, между другото, бе използвано и в друга важна функция на новото допълнение – – се състои в добавянето на допълнителен ключ за криптиране. Архивният ключ (Archive key) се съхранява в базата данни на провайдера в зашифрован вид. По хитра схема на страната на провайдера с негова помощ може да се отваря хранилището, да се преместват и перешифроват блокове от данни между хранилищата (все пак всяко има свой ключ), но не може да се дешифрират самите данни.
Хитра схема (работещ вариант)
Добавям, че всички инженери в R&D много обичат криптирането в нашия продукт, обаче никой не знае в детайли как работи. (Имаше и шега „защо изобщо работи“, но редакторите не я пропуснаха.)
Тестиране
По функцията бяха записани стотици бъгове. Най-сложните области – криптиране, потребителски интерфейс, проблеми при възстановяване.
От гледна точка на тестването, трудността представляваше голямата вариативност, „комбинаториката“ на видовете и типовете наемателски задачи и репозитории – имам предвид както източника, така и целта при възстановяването на резервни копия в инфраструктурата. Всичко това се нанизва на логиката в рамките на (включително новата – паралелизъм и ежедневни медия-сетове, за които ще стане дума по-долу), а и изобщо на непривичната за наемателите облачна специфика. Не забравяйте да подправите обилно с криптиране. Ако продължим метафората, добре се наядохме с това ястие – но и го опитахме от всички страни.
Фрагмент от тестовия план
В резултат
Подробно описание може да се намери в (за сега на английски): , . Ще се спра на основните моменти.
Резервно копие
Провайдърът добавя наематели в тейп-задание с GFS пул в качеството на цел. При наличие на облачна лицензия на втория етап от wizard-a е налична опцията TenantsМожете да добавите всички тенанти наведнъж или поотделно, а можете да изберете и само отделна квота (но не подсметка) на отделен тенант. Не е възможно да смесвате тенантски бекъпи и обикновени локални в една работа.
Останалите настройки почти напълно съвпадат с обичайната работа в GFS пул.
Възстановяването на данни може да се извърши както от страна на доставчика, така и от самия тенант.
Възстановяване от страна на доставчика
Извършва се чрез новия помощник. Тук можете да слезете до отделна работа, възстановява се изцяло веригата, която е била в репозитория на определен ден.
Има три варианта за възстановяване:
- В оригиналната локация. В този случай оригиналният бекъп, ако съществува, се изтрива; работите на тенанта автоматично се препонастройват на възстановената верига. Предполага се, че такова възстановяване ще бъде напълно незабележимо за клиента, само за кратко време той ще бъде изключен от облачния репозитория.
- В нова квота/репозиторий. Доставчикът може, например, да създаде за тази цел отделен временен акаунт, който по-късно ще изтрие. Бекъпът се появява в инфраструктурата на тенанта след синхронизация с базата на доставчика.
- Просто на диск на Linux или Windows сървър, регистриран в инфраструктурата на доставчика. След това тази верига може да бъде запазена на флаш памет и изпратена на тенанта.
Възстановяване от страна на тенанта
Тази опция предполага, че клиентът разполага със собствена tape инфраструктура и голям обем данни за възстановяване. Касетата с записаните бекъпи доставчикът може физически да изпрати на клиента с куриер, който я каталогизира на своето оборудване, дешифрира касетите и бекъпите и работи с резервните копия така, сякаш сам е записал данните на лентата. Ето един трик, за да не сваляте терабайти по WAN.
Масштабни подобрения на GFS пул
-медийните пулове се появиха в VBR преди две години, в версия 9.5. В последното обновление, както поради появата на функцията Tenant to tape, така и по искане на потребителите, ние значително подобрихме тази функционалност.
Ежедневни медийни сетове
Появи се нов ежедневен (daily) медиа-сет. Сега в GFS пула можете да съхранявате резервни копия за всеки ден, не само пълни, но и инкрементални. Последните заемат значително по-малко място и това е направено с цел спестяване на лента. Предполага се, че тези касети постоянно се ротират в библиотеката и не се пренасят за отдалечено съхранение. За възстановяване от инкрементална точка обаче ще са необходими касети от един от по-старите медиа-сетове (седмичен, месечен, тримесечен или годишен). Включването на ежедневния медиа-сет без включване на седмичния не е възможно, тъй като в повечето случаи, за възстановяване от инкременталната копия, са необходими именно седмичните касети. Те или са винаги в библиотеката, или се съхраняват в не толкова отдалечен склад.
Логика на работа на тейп джобовете в GFS медиа пул , техническите писатели могат да потвърдят. С две думи, без подробности, в седмичните и по-старите медиа-сетовe се копират само пълни резервни копия (включително виртуални пълни резервни копия), по едно за всяка дата, а в ежедневния – всички резервни копия, налични в репозитория за текущия ден, тъй като резервен джоб може да се стартира по-често от веднъж на ден.
Паралелизъм, време на стартиране и изчакване в GFS пулове
Сега е възможно паралелното записване на няколко верижки или джобове на няколко диска в библиотеката и в GFS медиа-пулове (по-рано – само в обикновените). Включва се на стъпка Options медиа-пула.
Важно уточнение: един и същи файл винаги се записва в един поток, затова в случай на няколко големи виртуални машини се препоръчва да се включи , за да се състои резервното копие от няколко верижки.
Освен това стана възможно да се избира време на стартиране на самата GFS джоба. На много потребители не им харесваше стартирането в полунощ и последващото изчакване почти цял ден, докато източниковата джоба приключи. Сега това време може, например, да се зададе за късния вечер, когато вече има какво да се копира на лента. Освен това, по искания на потребителите, изнесохме в разширените настройки опция, която по-рано можеше да се активира само с помощта на регистров ключ. Достатъчно е да се избере Обработете най-новата точка на възстановяване вместо да чакате – и на касетата се копира това, което има в репозитория в момента на стартиране на тейп джобата (точка от вчера, например), без никакво изчакване.
Подобрена работа с множество библиотеки
Тук ще говорим за ситуация, когато в един медиапул са добавени повече от една библиотека. Ние сме поддържали подобно и преди, но от време на време получавахме оплаквания от клиенти относно непредсказуемото поведение.
Беше
Например, ако се стартира тейп-работа, която заема две устройства в първата библиотека, но настройките за паралелизъм позволяват да използва 4 устройства наведнъж. Тази работа трябва ли да премине към втората библиотека на медиапула и да използва и нея, или това ще се счита за изразходване на ресурси?
В друг случай. Избрана е опцията за превключване при условие „няма налични касети“, в първата библиотека има само една касета, но потенциално на нея може да се съхранят всички данни. Но настройките позволяват паралелно записване на две касети. Трябва ли да включим втората библиотека в този случай?
Решихме да приведем тази област в ред, като дадем възможност за явно конфигуриране на поведението.
Стана
се появиха роли – активна и пасивна. А самият медиапул има два режима: отказоустойчиви, или фейловер (failover) и паралелен запис (paralleling). Сега в зависимост от изискванията, медиапулът може да се конфигурира по различен начин.
- Ако имате няколко равноправни библиотеки и е необходимо да разпаралелите записването в тях – включвате режима на паралелен запис, за това на всички библиотеки трябва да се назначат активни роли. В този случай новите касети и устройства ще започнат да се използват веднага щом има нужда, независимо къде се намират. Приоритет все пак има – първо ще се опитваме да намерим ресурси в библиотеката, разположена по-нагоре в списъка.
- Ако обаче имате една основна библиотека и един стар или самостоятелен драйв в резерв, включвате режима на фейловер, като поставяте основната библиотека най-горе в списъка и избирате пасивна роля за резервните устройства. Превключването към такова устройство ще се случва само когато наистина е необходимо, за да може работата да продължи по някакъв начин. Тази ситуация ще се счита за извънредна, за което ще бъде изпратено уведомление по имейл.
Има по-сложна ситуация, която в момента не поддържаме – няколко активни библиотеки в присъствието на пасивни. Обратната връзка ще покаже дали има нужда от такива конфигурации и дали трябва да доразвием функцията в бъдеще. Стандартна практика.
Поддръжка на WORM
WORM – Write Once Read Many – касети, които не могат да бъдат изтрити или презаписани , може само да се добавят данни. Задължителната им употреба е регламентирана от правилата на някои организации, например, работещи в областта на медицината. Основният проблем с такива касети по-рано беше, че VBR при или записва заглавие, което по-късно не може да бъде изтрито и тейп-джобовете падат с грешка при опит за такава.
В Update 4 на 9.5 е реализирана пълна поддръжка на такива касети. Добавени са WORM медийни пулове, обикновен и GFS, където могат да се поставят само касети от този тип.
Новите касети имат синя, „замразена“ иконка. От гледна точка на потребителя, работата с WORM касетите не се различава от работата с обикновените.
WORM-ността на касетите първоначално се определя по суффикса , ако баркодът им е обикновен или нечетим, информацията се предоставя от драйвера при първоначалното вмъкване на касетата. Невъзможно е да се поставят WORM касети в обикновен медий на пул и да се записва на тях. От забавните неща: вече има потребители, които са залепили WORM баркодове на обикновени касети и са се удивили на промените в своята инфраструктура след обновлението.
Чип на касетата
Паралелно с внедряването на неперезаписваеми касети, започнаха да работят с Стандартните атрибути в чипа преди не бяха използвани от нас, сега в някои от тях пишем и четем, но не ги възприемаме като основен източник на данни. Основният ориентир остава заглавието на касетата. Това решение се оказа правилно: след месец след релиза виждаме, как „зоопаркът“ на хардуера на потребителите предоставя изненади в плана на работата с чипа.
Бэкап NDMP-томов на ленту
В заключение – за най-търсената по количество отзиви функция на това обновление. Стана възможен бекъп на NDMP томовете на касети. В инфраструктурата на VBR е необходимо , след което в файловата тейп-джоб става възможно да се изберат томовете от този хост. Те се поставят в касети под формата на файлове със специален атрибут, за да се различават от обикновените при каталогизация.
В първата реализация има определени ограничения: не се поддържат разширения (extensions), плюс е възможен бекъп и рестор само на целия том, а не на отделни файлове. Бекъпът работи чрез (в случай на NetApp – ), тук има свои особености: максималният брой инкрементални точки е 9, след което се принуждава пълна резервна копия.
В заключение
Това бяха само най-значимите нововъведения в областта на резервното копиране на магнитна лента в VBR 9.5 Update 4. Други промени ще представя в списък:
- възможност за задаване на реда на сорс-джоб и файлове в тейп-джобовете;
- добавена роля Tape Operator (потребителят може да прави всичко, освен да възстановява от лента – за това има Restore Operator);
- добавени са пълноценни include/exclude-маски в файловата тейп-джоб (освен NDMP);
- допреработено възстановяването в файловата тейп-джоб (папката се възстановява с файловете, които са били там по време на бекъпа, а не с всички, които някога са били в нея – много търсена функция, между другото);
- увеличена е скоростта на възстановяване на много голям брой файлове от касети;
- допреработен е алгоритъмът за избор на следващата касета за запис, в частност, при други равни условия се взема предвид обемът на записаните/прочетените данни за цялата й история, вземат се най-новите;
- подобрена е стабилността на продукта.
Полезни линкове
За разнообразие ще представя няколко линка и на руски език ресурси:
- И да се върнем на предишното място, обзорните видеа «Как работи това» (в момента само на английски език) – могат да се видят . За тейповете се говори в слайдове 95 – 102.
Източник: habr.com
