Дадзеная нататка завяршае цыкл аб рэзервовым капіяванні. У ёй пайдзе прамову аб лагічнай арганізацыі вылучанага сервера (ці VPS), зручнай для рэзервовага капіявання, а таксама будзе прапанаваны варыянт хуткага ўзнаўлення сервера з рэзервовай копіі без адмысловых прастояў у выпадку аварыі.
Зыходныя дадзеныя
Выдзелены сервер часцей за ўсё мае мінімум два цвёрдых дыска, служачых для арганізацыі RAID масіва першага ўзроўню (люстэрка). Гэта трэба для магчымасці працягнуць працу сервера калі адзін дыск выйшаў са строю. Калі гэта звычайны вылучаны сервер - можа быць асобны апаратны RAID-кантролер, з актыўнай тэхналогіяй кэшавання на SSD, так што ў даважку да звычайных цвёрдых кружэлак можа быць падлучаны адзін або больш SSD. Часам прапануюцца вылучаныя сервера, у якіх з лакальных дыскаў прысутнічаюць толькі SATADOM (невялікія дыскі, канструктыўна - флэшка, якая падключаецца ў порт SATA), а то і звычайная невялікая (8-16гб) флэшка, якая падключаецца ў спецыяльны ўнутраны порт, а дадзеныя бяруцца з СХ , падлучанай па выдзеленай сетцы захоўвання дадзеных (Ethernet 10G, FC і г.д.), а бываюць вылучаныя сервера, якія загружаюцца і напрамую з СХД. Падобныя варыянты я не буду разглядаць, паколькі ў такіх выпадках задача рэзервовага капіявання сервера плыўна пераходзіць адмыслоўцу, які абслугоўвае СХД, звычайна тамака ёсць розныя фірмовыя тэхналогіі стварэння здымкаў стану, убудаваная дэдуплікацыя і іншыя радасці сісадміна, разгледжаныя ў папярэдніх частках гэтага цыклу. Аб'ём дыскавага масіва выдзеленага сервера можа дасягаць некалькіх дзясяткаў тэрабайт, у залежнасці ад ліку і аб'ёму дыскаў, падлучаных да сервера. У выпадку VPS аб'ёмы сціплей: звычайна не больш за 100гб (але бываюць і больш), а тарыфы на такія VPS лёгка могуць быць даражэй самых танных выдзеленых сервераў ад гэтага ж хосцера. У VPS часцей за ўсё дыск адзін, таму што пад ім будзе СХД (ці нешта гіперканвергентнае). Часам у VPS бывае некалькі дыскаў з рознымі характарыстыкамі, для розных мэт:
- невялікі сістэмны - для ўстаноўкі аперацыйнай сістэмы;
- вялікі - захоўванне карыстацкіх дадзеных.
Пры пераўсталёўцы сістэмы сродкамі панэлі кіравання дыск з карыстацкімі дадзенымі не заціраецца, а вось сістэмны перазаліваецца цалкам. Таксама ў выпадку з VPS хостэр можа прапаноўваць кнопку, якая робіць здымак стану VPS (ці дыска), аднак калі ўсталяваць сваю аперацыйную сістэму або забыцца актываваць патрэбны сэрвіс усярэдзіне VPS - частка дадзеных можа быць усё роўна згубленая. У даважку да кнопкі звычайна прапануецца сэрвіс захоўвання дадзеных, часцей за ўсё моцна абмежаваны. Звычайна гэта ўліковы запіс з доступам па пратаколе FTP ці SFTP, часам разам з SSH, са зрэзаным shell (да прыкладу rbash), або абмежаваннем на запуск каманд праз authorized_keys (праз ForcedCommand).
Выдзелены сервер падлучаны да сеткі двума партамі з хуткасцю 1гбітсек, часам гэта могуць быць карты са хуткасцю 10гбітсек. У VPS сеткавы інтэрфейс часцей за ўсё адзін. Часцей за ўсё датацэнтры не абмяжоўваюць хуткасць сеткі ўнутры датацэнтра, але абмяжоўваюць хуткасць доступу ў інтэрнэт.
Тыпавую нагрузку падобнага вылучанага сервера ці VPS складае вэб-сервер, база дадзеных, сервер прыкладанняў. Часам могуць быць устаноўлены розныя дадатковыя дапаможныя сэрвісы, у тым ліку для вэб-сервера або базы даных: пошукавы рухавічок, паштовая сістэма і г.д.
У якасці прасторы для захоўвання рэзервовых копій выступае спецыяльна падрыхтаваны сервер, пра яго будзе больш падрабязна напісана далей.
Лагічная арганізацыя дыскавай сістэмы
Калі ёсць RAID-кантролер, ці гэта VPS з адной кружэлкай, а таксама няма адмысловых пераваг па працы дыскавай падсістэмы (да прыкладу, асобная хуткая кружэлка для базы дадзеных) — уся вольная прастора дзеліцца так: ствараецца адна частка, па-над ім ствараецца група тамоў LVM , у ёй ствараюцца некалькі тамоў: 2 невялікіх аднолькавага памеру, якія выкарыстоўваюцца ў якасці каранёвай файлавай сістэмы (мяняюцца па чарзе пры абнаўленнях для магчымасці хуткага адкату, ідэя падгледжана ў дыстрыбутыва Calculate Linux), яшчэ адзін - для часткі падпампоўкі, астатняя вольная прастора дзеліцца на невялікія тамы , якія выкарыстоўваюцца ў якасці каранёвай файлавай сістэмы для паўнавартасных кантэйнераў, дыскаў для віртуальных машын, файлавых сістэм для ўліковых запісаў у /home (кожнага ўліковага запісу - свая файлавая сістэма), файлавых сістэм для кантэйнераў-прыкладанняў.
Важная заўвага: тамы павінны быць цалкам самадастатковымі, г.зн. не павінны залежаць як сябар ад сябра, так і ад каранёвай файлавай сістэмы. У выпадку з віртуальнымі машынамі ці кантэйнерамі гэты момант выконваецца аўтаматычна. Калі ж гэта кантэйнеры прыкладанняў або хатнія каталогі - варта падумаць аб падзеле канфігурацыйных файлаў вэб-сервера і іншых сэрвісаў такім чынам, каб максімальна прыбраць залежнасці тамоў паміж сабой. Да прыкладу, кожны сайт працуе ад свайго карыстальніка, канфігурацыйныя файлы сайта - у хатнім каталогу карыстальніка, у наладах вэб-сервера канфігурацыйныя файлы сайтаў уключаюцца не праз /etc/nginx/conf.d/.conf, а, да прыкладу, /home//configs/nginx/*.conf
Калі ж дыскаў некалькі - можна стварыць праграмны масіў RAID (і наладзіць яго кэшаванне на SSD, калі ёсць запатрабаванне і магчымасці), па-над якім сабраць LVM па правілах, прапанаваным вышэй. Таксама ў гэтым выпадку можна выкарыстоўваць ZFS ці BtrFS, але тут варта некалькі разоў падумаць: абедзве патрабуюць значна больш сур'ёзнага падыходу да рэсурсаў, да таго ж ZFS не ідзе ў камплекце з ядром Linux.
Незалежна ад выкарыстоўванай схемы заўсёды загадзя варта прыкінуць прыкладную хуткасць запісу змен на дыскі, пасля чаго вылічыць памер вольнага месца, якое будзе зарэзервавана для стварэння здымкаў. Да прыкладу, калі наш сервер будзе пісаць дадзеныя са хуткасцю 10 мегабайт у секунду, а памер усяго масіва з дадзенымі складае 10 тэрабайт – час сінхранізацыі можа дасягаць сутак (22 гадзіны – столькі будзе перадавацца такі аб'ём па сетцы 1гбітсек) – варта зарэзерваваць парадку 800 гб . У рэальнасці лічба будзе меншай, можна смела падзяліць яе на лік лагічных тамоў.
Прылада сервера захоўвання рэзервовых копій
Галоўнае адрозненне сервера для захоўвання рэзервовых копій - вялікія, танныя і адносна павольныя дыскі. Паколькі сучасныя HDD ужо перасягнулі планку ў 10тб у адным дыску - абавязкова прымяненне файлавых сістэм або RAID з кантрольнымі сумамі, таму што за час перабудовы масіва або аднаўлення файлавай сістэмы (некалькі сутак!) можа выйсці з ладу другі дыск з-за падвышанай нагрузкі. На дысках ёмістасцю да 1тб гэта было не так адчувальна. Для прастаты апісання мяркую, што дыскавая прастора падзелена на дзве прыкладна аднолькавыя па памеры часткі (ізноў жа, да прыкладу, з дапамогай LVM):
- тамы, якія адпавядаюць на серверах, якія выкарыстоўваюцца для захоўвання карыстацкіх дадзеных (на іх будзе разгортвацца апошняя зробленая рэзервовая копія для праверкі);
- тамы, якія выкарыстоўваюцца як рэпазітары BorgBackup (сюды непасрэдна будуць трапляць дадзеныя для рэзервовых копій).
Прынцып працы складаецца ў тым, што ствараюцца асобныя тамы для кожнага сервера пад рэпазітары BorgBackup, куды і будуць пападаць дадзеныя з баявых сервераў. Рэпазітары працуюць у рэжыме толькі дадання, што выключае магчымасць наўмыснага выдалення дадзеных, а за кошт дэдуплікацыі і перыядычнай чысткі рэпазітараў ад старых рэзервовых копій (застаюцца гадавыя копіі, штомесячныя за апошні год, штотыднёвыя за апошні месяц, штодзённыя за апошні тыдзень, магчыма - у адмысловых выпадках - штогадзінныя за апошні дзень: разам 24 + 7 + 4 + 12 + гадавыя - прыкладна 50 копій для кожнага сервера).
У рэпазітарах BorgBackup не актывуецца рэжым толькі даданні, замест гэтага выкарыстоўваецца ForcedCommand у .ssh/authorized_keys прыкладна такога плана:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Па паказаным шляху размешчаны скрыпт-акрутка па-над borg, які, акрамя запуску бінарніка з параметрамі, дадаткова запускае працэс аднаўлення рэзервовай копіі пасля заканчэння зняцця дадзеных. Для гэтага скрыпт-абгортка стварае файл-прыкмета побач з адпаведным рэпазітаром. Апошняя зробленая рэзервовая копія пасля заканчэння працэсу залівання даных аўтаматычна аднаўляецца на адпаведны лагічны том.
Дадзеная канструкцыя дазваляе перыядычна чысціць непатрэбныя рэзервовыя копіі, а таксама не дазваляе баявым серверам выдаляць штосьці на серверы захоўвання рэзервовых копій.
Працэс рэзервовага капіявання
Ініцыятарам рэзервовага капіявання выступае сам выдзелены сервер ці VPS, паколькі такая схема дае больш кантролю над працэсам рэзервовага капіявання са боку гэтага сервера. У першую чаргу робіцца здымак стану актыўнай каранёвай файлавай сістэмы, які манціруецца і запампоўваецца з дапамогай BorgBackup на сервер захоўвання рэзервовых копій. Пасля заканчэння зняцця дадзеных здымак размантуецца і выдаляецца.
У выпадку наяўнасці невялікай базы дадзеных (да 1 гб для кожнага сайта) робіцца дамп базы дадзеных, які захоўваецца ў адпаведны лагічны том, туды, дзе размешчаны астатнія дадзеныя гэтага ж сайта, але так, каб дамп не быў даступны праз вэб-сервер. Калі ж базы вялікія - варта наладзіць "гарачае" зняцце дадзеных, да прыкладу з дапамогай xtrabackup для MySQL, або працу WAL c archive_command у PostgreSQL. У гэтым выпадку база даных будзе аднаўляцца асобна ад дадзеных сайтаў.
Калі ўжываюцца кантэйнеры ці віртуальныя машыны - варта наладзіць qemu-guest-agent, CRIU ці іншыя, патрэбныя тэхналогіі. У астатніх выпадках дадатковых налад часцей за ўсё не спатрэбіцца - проста ствараем здымкі лагічных тамоў, якія потым апрацоўваюцца аналагічна здымку стану каранёвай файлавай сістэмы. Пасля зняцця дадзеных здымкі выдаляюцца.
Далейшая праца ідзе на серверы захоўвання рэзервовых копій:
- правяраецца апошняя зробленая рэзервовая копія ў кожным рэпазітары,
- правяраецца наяўнасць файла-пазнакі, які паказвае, што працэс зняцця дадзеных завершаны,
- выконваецца разгортванне дадзеных на які адпавядае лакальны том,
- выдаляецца файл-пазна
Працэс аднаўлення працаздольнасці сервера
Калі асноўны сервер гіне, то запускаецца аналагічны выдзелены сервер, які загружаецца з некаторай стандартнай выявы. Верагодней за ўсё загрузка будзе адбывацца па сетцы, аднак тэхнік ЦАД, які выконвае наладу сервера, можа адразу ж скапіяваць гэты стандартны вобраз на адзін з дыскаў. Загрузка адбываецца ў аператыўную памяць, пасля чаго запускаецца працэс аднаўлення:
- выконваецца запыт на далучэнне блокавай прылады па iscsinbd ці іншаму падобнаму пратаколу лагічнага тома, утрымоўвальнага каранёвую файлавую сістэму загінулага сервера; паколькі каранёвая файлавая сістэма павінна быць невялікі - гэты этап павінен быць завершаны за некалькі хвілін. Таксама праводзіцца аднаўленне загрузніка;
- узнаўляецца структура лакальных тамоў, далучаюцца лагічныя тамы з сервера рэзервовага капіявання з дапамогай модуля ядра dm_clone: пачынаецца аднаўленне дадзеных, а змены запісваюцца адразу ж на лакальныя дыскі
- запускаецца кантэйнер з усімі даступнымі фізічнымі дыскамі - цалкам аднаўляецца працаздольнасць сервера, але з паніжанай прадукцыйнасцю;
- пасля заканчэння сінхранізацыі дадзеных лагічныя тамы з сервера рэзервовага капіявання адлучаюцца, кантэйнер выключаецца, сервер перазагружаецца;
Пасля перазагрузкі сервер будзе мець усе дадзеныя, якія былі на момант стварэння рэзервовай копіі, а таксама ўключаць усе змены, якія былі зроблены ў працэсе аднаўлення.
Іншыя артыкулы цыкла
Рэзервовае капіраванне, частка 7: Высновы
Запрашаю абмеркаваць прапанаваны варыянт у каментарах, дзякую за ўвагу!
Крыніца: habr.com