Како вам ГитЛаб помаже да направите резервну копију великих НектЦлоуд складишта

Хеј Хабр!

Данас желим да причам о нашем искуству у аутоматизацији прављења резервних копија великих података из Нектцлоуд складишта у различитим конфигурацијама. Радим као сервисна станица у Молнииа АК, где се бавимо управљањем конфигурацијом ИТ система; Нектцлоуд се користи за складиштење података. Укључујући, са дистрибуираном структуром, са редундантношћу.

Проблеми који произилазе из карактеристика инсталација су што постоји много података. Верзија коју обезбеђује Нектцлоуд, редундантност, субјективни разлози и друго ствара много дупликата.

praistorija

Приликом администрирања Нектцлоуд-а јавља се проблем организовања ефективне резервне копије, која мора бити шифрована, пошто су подаци вредни.

Нудимо опције за чување резервних копија код нас или код корисника на одвојеним машинама из Нектцлоуда, што захтева флексибилан аутоматизовани приступ администрацији.

Постоји много клијената, сви са различитим конфигурацијама, и сви на својим сајтовима и са својим карактеристикама. Ово је стандардна техника када цео сајт припада вама, а резервне копије се праве од круна; не уклапа се добро.

Прво, погледајмо улазне податке. Морамо:

• Скалабилност у смислу једног или више чворова. За велике инсталације користимо минио као складиште.
• Сазнајте више о проблемима са прављењем резервних копија.
• Морате да чувате резервну копију код својих клијената и/или код нас.
• Решите проблеме брзо и лако.
• Клијенти и инсталације се веома разликују једни од других - не може се постићи уједначеност.
• Брзина опоравка треба да буде минимална у два сценарија: потпуни опоравак (катастрофа), једна фасцикла је обрисана грешком.
• Потребна је функција дедупликације.

Да бисмо решили проблем управљања резервним копијама, инсталирали смо ГитЛаб. Више детаља по хватању.

Наравно, нисмо први који је решио такав проблем, али нам се чини да наше практично, тешко стечено искуство може бити занимљиво и спремни смо да га поделимо.

Пошто наша компанија има политику отвореног кода, тражили смо решење отвореног кода. Заузврат, ми делимо наше развоје и објављујемо их. На пример, на ГитХуб-у постоји наш додатак за Нектцлоуд, које пружамо клијентима, побољшавајући сигурност података у случају случајног или намерног брисања.

Алати за прављење резервних копија

Започели смо потрагу за методама решења одабиром алата за прављење резервних копија.

Обични тар + гзип не функционише добро - подаци се дуплирају. Инкремент често садржи врло мало стварних промена, а велики део података унутар једне датотеке се понавља.
Постоји још један проблем - редундантност дистрибуираног складиштења података. Користимо минио и његови подаци су у основи сувишни. Или сте морали да направите резервну копију преко самог минио-а - учитајте га и користите све одстојнике између система датотека, и, што није мање важно, постоји ризик да заборавите на неке канте и мета-информације. Или користите дедупликацију.

Алати за прављење резервних копија са дуплирањем доступни су у отвореном коду (на Хабре-у је било Чланак о овој теми) а наши финалисти су били Борг и Рестиц. Наше поређење две апликације је у наставку, али за сада ћемо вам рећи како смо организовали целу шему.

Управљање резервним копијама

Борг и Рестиц су добри, али ниједан производ нема централизован механизам контроле. За потребе управљања и контроле, одабрали смо алат који смо већ имплементирали, без којег не можемо замислити наш рад, укључујући аутоматизацију – ово је добро познати ЦИ/ЦД – ГитЛаб.

Идеја је следећа: гитлаб-руннер је инсталиран на сваком чвору који чува Нектцлоуд податке. Тркач покреће скрипту према распореду који прати процес прављења резервних копија и покреће Борг или Рестиц.

Шта смо добили? Повратне информације о извршењу, погодна контрола промена, детаљи у случају грешке.

ovde је овде на ГитХуб-у поставили смо примере скрипте за различите задатке и на крају смо је приложили резервној копији не само Нектцлоуда, већ и многих других сервиса. Ту је и планер ако не желите да га конфигуришете ручно (а ми не желимо) и .гитлаб-ци.имл

Још увек не постоји начин да се промени ЦИ/ЦД тимеоут у Гитлаб АПИ-ју, али је мали. Треба га повећати, рецимо 1d.

ГитЛаб, на срећу, може да се покрене не само према урезивању, већ само према распореду, то је управо оно што нам треба.

Сада о скрипти омотача.

Поставили смо следеће услове за ову скрипту:

• Требало би да се покреће и од стране тркача и ручно са конзоле са истом функционалношћу.
• Морају постојати обрађивачи грешака:
• повратни код.
• потражите стринг у дневнику. На пример, за нас грешка може бити порука коју програм не сматра фаталном.
• Временско ограничење обраде. Време испоруке мора бити разумно.
• Потребан нам је веома детаљан дневник. Али само у случају грешке.
• Бројни тестови се такође врше пре почетка.
• Мали бонуси за практичност које смо сматрали кориснима током процеса подршке:
• Почетак и крај се бележе у системском дневнику локалне машине. Ово помаже у повезивању системских грешака и раду резервних копија.
• Део дневника грешака, ако га има, излази на стдоут, цео дневник се уписује у засебну датотеку. Погодно је одмах погледати ЦИ и проценити грешку ако је тривијална.
• Режими за отклањање грешака.

Цео дневник се чува као артефакт у ГитЛаб-у; ако нема грешке, дневник се брише. Пишемо сценарио у басх-у.

Бићемо срећни да размотримо све сугестије и коментаре у вези са отвореним кодом - добродошли.

Како ово ради

Тркач са Басх извршитељем се покреће на резервном чвору. Према планеру, посао ЦИ/ЦД се покреће у посебној репи. Руннер покреће универзалну скрипту омотача за такве задатке, проверава валидност резервног спремишта, тачака монтирања и свега што желимо, затим прави резервну копију и чисти стари. Сама готова резервна копија се шаље на С3.

Радимо према овој шеми - то је спољни АВС провајдер или руски еквивалент (брже је и подаци не напуштају Руску Федерацију). Или инсталирамо посебан минио кластер за клијента на његовом сајту у ове сврхе. Обично то радимо из безбедносних разлога, када клијент уопште не жели да подаци напусте своје коло.

Нисмо користили функцију слања резервне копије преко ссх-а. Ово не додаје сигурност, а мрежне могућности С3 провајдера су много веће од наше једне ссх машине.

Да бисте заштитили своју локалну машину од хакера, пошто он може да избрише податке на С3, морате омогућити верзионисање.
Резервна копија увек шифрује резервну копију.

Борг има нешифровани режим none, али не препоручујемо да га укључите. У овом режиму, не само да неће бити шифровања, већ се не израчунава контролна сума онога што се пише, што значи да се интегритет може проверити само индиректно, коришћењем индекса.

Засебан планер проверава резервне копије за интегритет индекса и садржаја. Провера је спора и дуга, па је водимо одвојено једном месечно. Може потрајати неколико дана.

Реадме на руском

Главне функције

• prepare обука
• testcheck провера спремности
• maincommand Главни тим
• forcepostscript функција која се извршава на крају или грешком. Користимо га за демонтажу партиције.

Сервисне функције

• cleanup Снимамо грешке или бришемо датотеку евиденције.
• checklog анализирати дневник за појаву реда са грешком.
• ret руковалац излазом.
• checktimeout проверите временско ограничење.

животна средина

• VERBOSE=1 Грешке одмах приказујемо на екрану (стдоут).
• SAVELOGSONSUCCES=1 сачувајте дневник након успеха.
• INIT_REPO_IF_NOT_EXIST=1 Направите спремиште ако не постоји. Подразумевано онемогућено.
• TIMEOUT максимално време за главну операцију. Можете га поставити као 'м', 'х' или 'д' на крају.

Режим складиштења старих копија. Уобичајено:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Променљиве унутар скрипте

• ERROR_STRING — стринг за пријаву грешке.
• EXTRACT_ERROR_STRING — израз за приказ стринга ако грешка.
• KILL_TIMEOUT_SIGNAL — сигнал за убијање ако је истекло.
• TAIL — колико низова са грешкама на екрану.
• COLORMSG — боја поруке (подразумевано жута).

Та скрипта, која се зове вордпресс, има условно име, њен трик је у томе што такође прави резервну копију базе података мискл. То значи да се може користити за Некцлоуд инсталације са једним чвором, где такође можете направити резервну копију базе података. Погодност није само што је све на једном месту, већ је и садржај базе података близак садржају фајлова, пошто је временска разлика минимална.

Рестиц против Борга

Постоје и поређења између Борга и Рестића овде на Хабреу, а ми нисмо имали задатак да направимо само још једну, већ своју. Било нам је важно како ће то изгледати на нашим подацима, са нашим специфичностима. Доносимо их.

Наши критеријуми за избор, поред већ поменутих (дедупликација, брз опоравак, итд.):

• Отпор недовршеном послу. Провери за убиство -9.
• Величина на диску.
• Захтеви за ресурсе (ЦПУ, меморија).
• Величина ускладиштених мрља.
• Рад са С3.
• Провера интегритета.

За тестирање смо узели једног клијента са стварним подацима и укупном величином од 1,6 ТБ.
Услови.

Борг не зна да ради директно са С3, а ми смо монтирали диск као осигурач, преко гоофис. Рестиц га је послао самом С3.

Гоофис ради веома брзо и добро, а има их кеш модул диска, што још више убрзава рад. Налази се у бета фази и, искрено, срушио се са губитком података на тестовима (другим). Али погодност је у томе што сама процедура резервне копије не захтева много читања, већ углавном писања, тако да користимо кеш само током провера интегритета.

Да бисмо смањили утицај мреже, користили смо локалног провајдера - Иандек Цлоуд.

Поређење резултата испитивања.

• Убиство -9 са даљим поновним покретањем оба су била успешна.
• Величина на диску. Борг може да компримује, тако да су резултати очекивани.

Бацкупер
Величина

Борг
КСНУМКСГб

Рестиц
КСНУМКСГб

• Би ЦПУ
  Сам Борг троши мало, са подразумеваном компресијом, али мора да се процени заједно са глупим процесом. Укупно, они су упоредиви и користе око 1,2 језгра на истој виртуелној машини за тестирање.
• Меморија. Рестиц је приближно 0,5 ГБ, Борг је приближно 200 МБ. Али ово је све безначајно у поређењу са кешом системских датотека. Зато је препоручљиво издвојити више меморије.
• Разлика у величини мрље је била упадљива.

Бацкупер
Величина

Борг
око 500МБ

Рестиц
око 5МБ

• Рестицово С3 искуство је одлично. Рад са Боргом преко глупости не изазива никаква питања, али је примећено да је препоручљиво урадити умоунт након што се резервна копија заврши да бисте потпуно ресетовали кеш. Посебност С3 је у томе што недовољно испумпани комади никада неће бити послати у канту, што значи да непотпуно попуњени подаци доводе до великих оштећења.
• Провера интегритета ради добро у оба случаја, али се брзина значајно разликује.
  Рестиц КСНУМКС сати.
  Борг, са ССД кешом од 100 ГБ – КСНУМКС сати.Приближно исти резултат брзине ако су подаци на локалном диску.
  Борг чита директно са С3 без кеша КСНУМКС сати. Монструозно дуго.

Суштина је да Борг може да компримује и да има веће мрље - што чини складиштење и ГЕТ/ПУТ операције у С3 јефтинијим. Али ово долази по цену сложеније и спорије верификације. Што се тиче брзине опоравка, нисмо приметили никакву разлику. Рестиц узима следеће резервне копије (после прве) мало дуже, али не значајно.

На крају, али не и најмање важно, у избору је била величина заједнице.

И ми смо изабрали Борг.

Неколико речи о компресији

Борг има одличан нови алгоритам компресије у свом арсеналу - зстд. Квалитет компресије није лошији од гзипа, али много бржи. И упоредив по брзини са подразумеваним лз4.

На пример, думп МиСКЛ базе података је компримован два пута боље од лз4 при истој брзини. Међутим, искуство са стварним подацима показује да постоји врло мала разлика у односу компресије Нектцлоуд чвора.

Борг има прилично бонус режим компресије - ако датотека има високу ентропију, онда се компресија уопште не примењује, што повећава брзину. Омогућено опцијом приликом креирања
-C auto,zstd
за зстд алгоритам
Дакле, са овом опцијом, у поређењу са подразумеваном компресијом, добили смо
560Гб и 562Гб респективно. Подаци из горњег примера, да вас подсетим, без компресије резултат је 628Гб. Резултат разлике од 2ГБ нас је донекле изненадио, али смо мислили да ћемо ипак то изабрати. auto,zstd.

Резервни метод верификације

Према планеру, виртуелна машина се покреће директно од провајдера или од клијента, што у великој мери смањује оптерећење мреже. Барем је јефтиније него да га сами подигнете и покренете саобраћај.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

Користећи исту шему, проверавамо датотеке са антивирусом (после чињенице). На крају крајева, корисници постављају различите ствари на Нектцлоуд и немају сви антивирусни програм. Спровођење прегледа у време преливања одузима превише времена и омета пословање.

Скалабилност се постиже покретањем тркача на различитим чворовима са различитим ознакама.
Наш мониторинг прикупља статусе резервних копија преко ГитЛаб АПИ-ја у једном прозору; ако је потребно, проблеми се лако примећују и исто тако лако локализују.

Закључак

Као резултат тога, поуздано знамо да правимо резервне копије, да су наше резервне копије валидне, проблеми који се јављају код њих трају мало времена и решавају се на нивоу дежурног администратора. Резервне копије заузимају заиста мало простора у поређењу са тар.гз или Бацула.

Извор: ввв.хабр.цом