ProHoster > Blogs > Administrācija > Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Kapacitātes lÄ«menis (vai kā mēs to saucam Vim iekÅ”ienē - captir) parādÄ«jās Veeam dublÄ“Å”anas un replikācijas 9.5 atjauninājuma 4 dienās ar nosaukumu Archive Tier. Tās ideja ir nodroÅ”ināt iespēju pārvietot dublējumkopijas, kas izkrituÅ”as no tā sauktā operatÄ«vās atjaunoÅ”anas loga, uz objektu krātuvi. Tas palÄ«dzēja atbrÄ«vot vietu diskā tiem lietotājiem, kuriem tās bija maz. Un Å”o opciju sauca par pārvietoÅ”anas režīmu.

Lai veiktu Å”o vienkārÅ”o (kā Ŕķiet) darbÄ«bu, pietika ar divu nosacÄ«jumu izpildi: visiem punktiem no pārvietotās dublējuma jāatrodas ārpus iepriekÅ” minētā operatÄ«vās atjaunoÅ”anas loga robežām, kas ir skaidri iestatÄ«ts lietotāja interfeisā. Un otrkārt: ķēdei jābÅ«t tā sauktajā ā€œaizzÄ«mogotajā formāā€ (aizzÄ«mogotā rezerves ķēde vai neaktÄ«vā rezerves ķēde). Tas ir, laika gaitā Å”ajā ķēdē nenotiek nekādas izmaiņas.

Bet VBR v10 koncepts tika papildināts ar jaunām funkcijām - Copy Mode, Sealed Mode un parādījās lieta ar grūti izrunājamu nosaukumu Immutability.

Å Ä«s ir aizraujoŔās lietas, par kurām mēs Å”odien runāsim. Vispirms par to, kā tas darbojās VBR9.5u4, un pēc tam par izmaiņām desmitajā versijā.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Un lai man piedod tīrās valodas čempioni, bet ir pārāk daudz terminu, kurus nevar iztulkot.
Tātad Ŕeit būs ļoti daudz anglicismu.
Un daudz gifu.
Un bildes.

  • Bez mazākās nožēlas. Raksta autors.

Kā tas bija

Sāksim ar darbÄ«bas atjaunoÅ”anas loga un aizzÄ«mogotās dublējuma (vai kā tie tiek saukti neaktÄ«vās dublÄ“Å”anas ķēdes dokumentācijā) analÄ«zi. Bez viņu izpratnes tālāka skaidroÅ”ana nebÅ«s iespējama.

Kā redzams attēlā, mums ir sava veida rezerves ķēde ar datu blokiem, kas atrodas tā repozitorija veiktspējas līmenī SOBR, kuram ir pievienots Capacity Tier. Mūsu darbības rezerves periods ir trīs dienas.

AttiecÄ«gi pirmdien izveidotais .vbk aizzÄ«mogo iepriekŔējo ķēdi, kuras logs ir iestatÄ«ts uz trÄ«s dienām. Un tas nozÄ«mē, ka varat droÅ”i sākt vest uz Å”autuvi visu, kas vecāks par Ŕīm trim dienām.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Bet ko Ä«sti nozÄ«mēja aizzÄ«mogotā ķēde un ko varēja nosÅ«tÄ«t uz kapacitātes Å”autuvi 4. atjauninājumā?

Forward Incremental ķēdes aizzÄ«mogoÅ”anas pazÄ«me ir jaunas pilnas rezerves izveide. Un nav svarÄ«gi, kā tiek iegÅ«ta Ŕī pilnā dublÄ“Å”ana: tiek ņemtas vērā gan sintētiskās pilnās, gan aktÄ«vās pilnās dublējumkopijas.

Reverse gadījumā tie visi ir faili, kas neietilpst darbības logā.

Ja tiek veikta pārsÅ«tÄ«Å”anas palielināŔana ar atcelÅ”anu, tās visas ir atgrieÅ”anas un .vbk, ja veiktspējas apjomam ir cits .vbk.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Tagad apsveriet iespēju strādāt ar rezerves kopiju ķēdēm. Å eit tika transportētas tikai preces, uz kurām attiecas GFS saglabāŔana. Jo viss, kas glabājas jaunākās rezerves kopiju ķēdēs, var tikt mainÄ«ts vienā vai otrā veidā.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Tagad paskatÄ«simies zem pārsega. Tur notiek process, ko sauc par dehidratāciju - tukÅ”u dublējuma failu atstāŔana apjomā un bloku vilkÅ”ana no Å”iem failiem uz jaudas Å”auÅ”anas diapazonu. Lai optimizētu Å”o procesu, tiek izmantots tā sauktais dehidratācijas indekss, kas ļauj izvairÄ«ties no jau iekopētu bloku kopÄ“Å”anas jaudas Å”autuvē.

ApskatÄ«sim, kā tas izskatās, izmantojot piemēru: Pieņemsim, ka mums ir .vbk, kas iznāca no darÄ«juma loga un pieder noslēgtai ķēdei. Tas nozÄ«mē, ka mums ir visas tiesÄ«bas to pārvietot uz kapacitātes Å”autuvi. PārvietoÅ”anas laikā tiek izveidots metadatu fails pārsÅ«tÄ«tā faila ietilpÄ«bas joslā un blokos. Saites lÄ«meņa metadatu failā ir aprakstÄ«ts, no kādiem blokiem sastāv mÅ«su fails. Attēlā redzamajā gadÄ«jumā mÅ«su pirmais fails sastāv no blokiem a, b, c, un metadatos ir saites uz Å”iem blokiem. Kad mums ir otrs .vbk fails, kas ir gatavs pārvietoÅ”anai un sastāv no blokiem a, b un d, mēs, analizējot dehidratācijas indeksu, saprotam, ka ir jāpārnes tikai bloks d. Un tā metadatu failā bÅ«s saites uz diviem iepriekŔējiem blokiem un vienu jaunu.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

AttiecÄ«gi Å”o tukÅ”o vietu aizpildÄ«Å”anu ar datiem sauc par rehidratāciju. Tas jau izmanto savu rehidratācijas indeksu, kura pamatā ir vecākais .vbk fails par vietējo veiktspējas apjomu. Tas ir, ja lietotājs vēlas atgriezt failu no jaudas Å”auÅ”anas diapazona, mēs vispirms izveidojam vecākās pilnas dublējuma bloku indeksu un pārsÅ«tām tikai trÅ«kstoÅ”os blokus no kapacitātes Å”auÅ”anas galerijas. Attēlā redzamajā gadÄ«jumā, lai rehidrētu FullBackup1.vbk pēc rehidratācijas indeksa, nepiecieÅ”ams tikai bloks C, kuru paņemam no kapacitātes Å”autuves. Ja krātuves mākoņa objekts kalpo kā ietilpÄ«bas Å”autuve, tas ļauj ietaupÄ«t milzÄ«gas naudas summas.

Å eit var Ŕķist, ka Ŕī tehnoloÄ£ija ir identiska tai, kas tiek izmantota WAN paātrinātājos, taču tā tikai Ŕķiet. Paātrinātājos dedublikācija ir globāla; Å”eit katrā failā tiek izmantota vietējā dedublikācija ar noteiktu nobÄ«di. Tas notiek risināmo uzdevumu atŔķirÄ«bu dēļ: Å”eit mums ir jākopē lieli pilni dublējuma faili, un saskaņā ar mÅ«su pētÄ«jumu, pat ja starp tiem paiet ilgs laika periods, Å”is dedublikācijas algoritms dod vislabāko rezultātu.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Bet vairāk indeksi indeksu dievam! Ir arÄ« datu atkopÅ”anas indekss! Kad mēs sākam atjaunot iekārtu, kas atrodas ietilpÄ«bas domuzÄ«mē, mēs nolasÄ«sim tikai unikālus datu blokus, kas neatrodas veiktspējas panelÄ«.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Kā tas notika?

Tas arÄ« viss ievaddaļai. Tas ir diezgan detalizēts, taču, kā minēts iepriekÅ”, bez Ŕīm detaļām nebÅ«s iespējams izskaidrot, kā darbojas jaunās funkcijas. Tāpēc bez papildu piepÅ«les pāriesim pie pirmā.

KopÄ“Å”anas režīms

Tas lielā mērā ir balstÄ«ts uz esoÅ”ajām tehnoloÄ£ijām, taču tam ir pavisam cita lietoÅ”anas loÄ£ika. 

Å Ä« režīma mērÄ·is ir nodroÅ”ināt, lai visiem datiem, kas atrodas vietējā mērogā, ir kopija ietilpÄ«bas domuzÄ«mē.

Ja salÄ«dzināsit pārvietoÅ”anas un kopÄ“Å”anas režīmus, tas izskatÄ«sies Ŕādi:

  • Var pārvietot tikai noslēgto ķēdi. KopÄ“Å”anas režīma gadÄ«jumā tiek pārsÅ«tÄ«ts pilnÄ«gi viss, neatkarÄ«gi no tā, kas notiek dublÄ“Å”anas darbā.
  • PārvietoÅ”ana tiek aktivizēta, ja faili pārsniedz darbÄ«bas dublÄ“Å”anas loga robežas, un kopÄ“Å”ana tiek aktivizēta, tiklÄ«dz parādās dublējuma fails.
  • Jaunu datu uzraudzÄ«ba kopÄ“Å”anai notiek pastāvÄ«gi, un pārvietoÅ”anai tie tika aktivizēti reizi 4 stundās.

Apsverot jauno režīmu, es ierosinu pāriet no vienkārÅ”iem piemēriem uz sarežģītiem.

Visbiežāk mums vienkārÅ”i ir jauni faili ar pieaugumiem, un mēs tos vienkārÅ”i kopējam uz jaudas Å”auÅ”anas diapazonu. NeatkarÄ«gi no tā, kāds režīms tiek izmantots dublÄ“Å”anas darbā, neatkarÄ«gi no tā, vai tas pieder ķēdes noslēgtajai daļai vai nē, neatkarÄ«gi no tā, vai mÅ«su darbÄ«bas logs ir beidzies. Viņi to vienkārÅ”i paņēma un nokopēja.

Process aiz tā joprojām ir dehidratācija, kā aprakstÄ«ts iepriekÅ”. KopÄ“Å”anas režīmā tas arÄ« nodroÅ”ina, ka mēs nekopējam blokus, kas jau atrodas mÅ«su krātuvē. VienÄ«gā atŔķirÄ«ba ir tāda, ka, ja filmas režīmā mēs aizstājām reālus failus ar fiktÄ«viem failiem, mēs tos nekādā veidā nepieskaramies un atstājam visu kā ir. Pretējā gadÄ«jumā tas ir tieÅ”i tas pats dehidratācijas indekss, kas rÅ«pÄ«gi cenÅ”as ietaupÄ«t jÅ«su naudu un laiku.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Rodas jautājums ā€“ ja paskatās uz lietotāja interfeisu, ir iespēja izvēlēties abas opcijas vienlaicÄ«gi. Kā Ŕāds kombinētais režīms darbosies?

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Sapratīsim.

Sākums ir standarta: tiek izveidots un nekavējoties kopēts dublējuma fails. Tam tiek izveidots un arÄ« kopēts pieaugums. Tas notiek lÄ«dz brÄ«dim, kad saprotam, ka faili ir pametuÅ”i mÅ«su darbÄ«bas logu un ir parādÄ«jusies aizzÄ«mogota ķēde. Å ajā brÄ«dÄ« mēs veicam dehidratācijas darbÄ«bu un aizstājam Å”os failus ar fiktÄ«viem failiem. Protams, mēs neko vairs nekopējam kapacitātes Å”autuvē.

Visa Ŕī aizraujoŔā loÄ£ika ir atbildÄ«ga tikai par vienu saskarnes izvēles rÅ«tiņu: kopējiet dublējumus objektu krātuvē, tiklÄ«dz tie ir izveidoti.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Kāpēc mums ir nepiecieÅ”ams Å”is kopÄ“Å”anas režīms?

Vēl labāk ir pārfrāzēt jautājumu Ŕādi: no kādiem riskiem mēs esam pasargāti ar tā palÄ«dzÄ«bu? Kādu problēmu tas mums palÄ«dz atrisināt?

Atbilde ir acÄ«mredzama: protams, tā ir datu atkopÅ”ana. Ja mums ir pilnÄ«ga vietējo datu kopija objekta krātuvē, tad neatkarÄ«gi no tā, kas notiek ar mÅ«su produktu, mēs vienmēr varam atjaunot datus no failiem, kas atrodas nosacÄ«tajā Amazon.

Tāpēc apskatÄ«sim iespējamos scenārijus, sākot no vienkārŔākā lÄ«dz sarežģītākajam.

VienkārŔākā nelaime, kas var uzkrist uz mÅ«su galvām, ir viena no rezerves ķēdes faila nepieejamÄ«ba.

Skumjāks stāsts ir tas, ka viens no mūsu SOBR repozitorija apjomiem sabojājās.

Vēl sliktāk kļūst, kad visa SOBR krātuve ir kļuvusi nepieejama, bet ietilpÄ«bas Å”autuve darbojas.
Un viss tieŔām ir slikti ā€“ tas ir tad, kad nomirst rezerves serveris un tava pirmā vēlme ir desmit minÅ«Å”u laikā mēģināt aizskriet lÄ«dz Kanādas robežai.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Tagad aplūkosim katru situāciju atseviŔķi.

Kad esam pazaudējuÅ”i vienu (un pat vairākus) dublējuma failus, viss, kas mums jādara, ir jāuzsāk repozitorija atkārtotas skenÄ“Å”anas process, un pazaudētais fails tiks aizstāts ar fiktÄ«vu failu. Un, izmantojot rehidratācijas procesu (kas tika apspriests raksta sākumā), lietotājs varēs lejupielādēt datus no jaudas Å”auÅ”anas diapazona uz vietējo krātuvi.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Tagad situācija ir sarežģītāka. Pieņemsim, ka mÅ«su SOBR sastāv no diviem apjomiem, kas darbojas veiktspējas režīmā, kas nozÄ«mē, ka mÅ«su .vbk un .vib ir sadalÄ«ti pa tiem diezgan nevienmērÄ«gā slānÄ«. Un kādā brÄ«dÄ« viens no apjomiem kļūst nepieejams, un lietotājam steidzami jāatjauno iekārta, kuras datu daļa atrodas tieÅ”i Å”ajā apjomā.

Lietotājs palaiž atkopÅ”anas vedni, izvēlas punktu, uz kuru viņŔ vēlas atjaunot, un vednis, strādājot, saprot, ka viņam nav visu vietējai atkopÅ”anai nepiecieÅ”amo datu, un tāpēc tie ir jālejupielādē no jaudas Å”auÅ”anas. galerija. Tajā paŔā laikā bloki, kas paliek lokālajā krātuvē, netiks lejupielādēti no mākoņa. Slava atjaunoÅ”anas indeksam (jā, tas arÄ« tika minēts raksta sākumā).

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Å Ä«s lietas apakÅ”tips ir tāds, ka viss SOBR repozitorijs kļuva nepieejams. Å ajā gadÄ«jumā mums nav ko kopēt no vietējās krātuves, un visi bloki tiek lejupielādēti no mākoņa.

Un visinteresantākā situācija ir tāda, ka rezerves serveris nomira. Šeit ir divas iespējas: administrators ir lielisks un izveidoja konfigurācijas dublējumkopijas, un administrators ir pats ļaunais Pinokio un neveidoja konfigurācijas dublējumkopijas.

Pirmajā gadÄ«jumā viņam pietiks vienkārÅ”i kaut kur izvietot tÄ«ru VBR instalāciju un atjaunot tās datu bāzi no dublējuma, izmantojot standarta lÄ«dzekļus. Å Ä« procesa beigās viss atgriezÄ«sies normālā stāvoklÄ«. Vai arÄ« tas tiks atjaunots saskaņā ar kādu no iepriekÅ” minētajiem scenārijiem.

Bet, ja administrators ir vai nu viņa paÅ”a ienaidnieks, vai arÄ« konfigurācijas dublējums cieta episkā kļūme, tad pat Å”eit mēs viņu neatstāsim likteņa žēlastÄ«bā. Å ajā gadÄ«jumā esam ieviesuÅ”i jaunu procedÅ«ru ar nosaukumu Import Object Storage. Tas ļauj izlaist SOBR repozitorija manuālas atkārtotas izveides procesu un tam pievienojot ietilpÄ«bas Å”auÅ”anas diapazonu ar sekojoÅ”u atkārtotu skenÄ“Å”anu, kā arÄ« vienkārÅ”i pievienot Vim saskarnei krātuves objektu un palaist krātuves krātuves importÄ“Å”anas procedÅ«ru. VienÄ«gais, kas var traucēt jums un jÅ«su dublējumkopijām, ir pieprasÄ«jums ievadÄ«t paroli, ja jÅ«su dublējumkopijas ir Å”ifrētas.

Tas, iespējams, ir saistÄ«ts ar kopÄ“Å”anas režīmu, un mēs turpinām

Aizzīmogotais režīms

Galvenā ideja ir tāda, ka jaunas dublējumkopijas nevar parādÄ«ties repozitorija atlasÄ«tajā SOBR apjomā. Pirms versijas 10 mums bija tikai uzturÄ“Å”anas režīms, kad jebkurÅ” darbs ar repozitoriju bija pilnÄ«bā aizliegts. Sava veida cietais režīms krātuves izslēgÅ”anai, kur ir pieejama tikai poga Evacuate, kas vienreiz pārsÅ«ta dublējumus citā apjomā.

Un Sealed režīms ir sava veida ā€œmÄ«kstāā€ opcija: mēs aizliedzam jaunu dublējumkopiju izveidi un pakāpeniski izdzÄ“Å”am vecās atbilstoÅ”i izvēlētajai saglabāŔanai, taču Å”ajā procesā mēs nezaudējam iespēju atjaunot no saglabātajiem punktiem. Ä»oti noderÄ«ga lieta, kad vai nu kāda aparatÅ«ra tuvojas mūža beigām un ir jānomaina, vai arÄ« vienkārÅ”i jāatbrÄ«vo kaut kam svarÄ«gākam, bet nav kur paņemt un visu uzreiz pārvietot. Vai arÄ« to nevar izdzēst.

AttiecÄ«gi darbÄ«bas princips ir pavisam vienkārÅ”s: ir jāaizliedz visas rakstÄ«Å”anas darbÄ«bas (jaunu datu parādÄ«Å”anās), lasÄ«Å”anas (atjaunoÅ”anas) un dzÄ“Å”anas (saglabāŔanas) atstāŔana.

Abus režīmus var izmantot vienlaikus, taču ņemiet vērā, ka apkopei ir augstāka prioritāte.

Kā piemēru apsveriet SOBR, kas sastāv no diviem apjomiem. Pieņemsim, ka pirmās četras dienas mēs izveidojām dublējumus Forward Forever Incremental režīmā un pēc tam apzīmogojam apmēru. Tas noved pie tā, ka mēs uzsākam jaunas aktīvās pilnas izveidi otrajā pieejamajā apjomā. Ja mūsu aizture ir četri, tad, kad visa ķēde, kas atrodas uz aizzīmogotā apjoma, pārsniedz tās robežas, tā tiek dzēsta ar tīru sirdsapziņu.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Pastāv situācijas, kad dzÄ“Å”ana notiek agrāk. Piemēram, tas ir uz priekÅ”u inkrementāls ar periodiskām pilnām vērtÄ«bām. Ja pirmās divas dienas izveidojām pilnas dublējumkopijas un ceturtdien nolemjam repozitoriju aizzÄ«mogot, tad piektdien, kad tiks izveidota jauna dublējumkopija, pirmdienas fails tiks dzēsts, jo lÄ«dz Å”im nav atkarÄ«bu. Un pats punkts nav atkarÄ«gs no neviena. Pēc tam gaidām, lÄ«dz tiek izveidoti četri punkti pieejamajā apjomā, un izdzÄ“Å”am atlikuÅ”os trÄ«s, kurus nevar dzēst neatkarÄ«gi vienu no otra.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Lietas ir vienkārŔākas ar Reverse Incremental. Tajā vecākie punkti nav ne no kā atkarÄ«gi un tos var droÅ”i dzēst. Tāpēc, tiklÄ«dz tiks izveidots jauns .vbk jaunā apjomā, vecie .vrb tiks dzēsti pa vienam.

Starp citu, kāpēc mēs katru reizi veidojam jaunu .vbk: ja mēs to neveidotu, bet turpinātu veco pieauguma ķēdi, tad vecais .vbk sastingtu uz bezgala ilgu laiku jebkurā režīmā, neļaujot to izdzēst. Tāpēc tika nolemts, ka tiklīdz apjoms ir aizzīmogots, mēs izveidojam pilnu rezerves kopiju uz bezmaksas apjomu.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Sarežģītāk lietas ir ar kapacitātes Ŕautuvi.

Vispirms apskatÄ«sim kopÄ“Å”anas režīmu. Pieņemsim, ka četras dienas aktÄ«vi veidojām dublējumus, un tad jaudas Å”autuve tika noslēgta. Neko neizdzÄ“Å”am, bet pazemÄ«gi pacieÅ”am saglabāŔanu, pēc kuras izdzÄ“Å”am datus no kapacitātes Å”autuves.

Apmēram tas pats notiek pārvietoÅ”anas režīmā - gaidām retuŔēŔanu, izdzÄ“Å”am veco lokālajā krātuvē un izdzÄ“Å”am objektu krātuvē saglabāto.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Interesants piemērs ar Forever forward incremental. Mēs instalējam saglabāŔanu trÄ«s punktos un pirmdien sākam veidot dublējumus, kas regulāri tiek kopēti mākonÄ«. Pēc krātuves aizzÄ«mogoÅ”anas tiek turpināta dublējumkopiju veidoÅ”ana, saglabājot trÄ«s punktus, taču ietilpÄ«bas domuzÄ«mē saglabātie dati paliek atkarÄ«gi un tos nevar izdzēst. Tāpēc gaidām lÄ«dz ceturtdienai, kad mÅ«su .vbk iziet ārpus saglabāŔanas robežām, un tikai tad mierÄ«gi dzÄ“Å”am visu saglabāto ķēdi.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Un neliela atruna: visi piemēri Å”eit ir parādÄ«ti ar vienu maŔīnu. Ja jÅ«su dublējumkopijā ir vairāki no tiem, to retuŔēŔana atŔķirsies atkarÄ«bā no tā, vai tika veikta Active Full vai nē.

Tas būtībā ir viss. Tātad, pāriesim pie vissmagākās funkcijas -

Nemainīgums

Tāpat kā iepriekŔējos punktos, vispirms ir jautājums, kādu problēmu Ŕī funkcija atrisina. TiklÄ«dz mēs kaut kur augÅ”upielādējam savus dublējumus glabāŔanai, ir liela vēlme garantēt to droŔību, tas ir, fiziski aizliegt to dzÄ“Å”anu un jebkādas modifikācijas noteiktā saglabāŔanas laikā. Tostarp administratori, tostarp viņu saknes konti. Tas ļauj aizsargāt tos no nejauÅ”iem vai tÄ«Å”iem bojājumiem. Ikviens, kurÅ” strādā ar AWS, iespējams, ir saskāries ar lÄ«dzÄ«gu funkciju ar nosaukumu Object Lock.

Tagad aplÅ«kosim režīmu vispārÄ«gi un pēc tam iedziļināsimies detaļās. MÅ«su piemērā nemaināmÄ«ba tiks iespējota mÅ«su kapacitātes Å”autuvē ar četru dienu saglabāŔanu. Un dublējumkopijā ir iespējots kopÄ“Å”anas režīms.

NemainÄ«gums nekādā veidā neietekmē vispārējo saglabāŔanu. Piemēram, tas nepievieno papildu punktus vai kaut ko tamlÄ«dzÄ«gu. Tas ir tikai tas, ka persona nevar izdzēst dublējuma failus četru dienu laikā. Ja pirmdien izveidosit dublējumu, tā failu varēsiet izdzēst tikai piektdien.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Visi iepriekÅ” izskaidrotie dehidratācijas jēdzieni, indeksi un metadati turpina darboties tieÅ”i tāpat. Bet ar vienu nosacÄ«jumu - bloks ir iestatÄ«ts ne tikai datiem, bet arÄ« metadatiem. Tas tiek darÄ«ts gadÄ«jumā, ja viltÄ«gs uzbrucējs nolemj dzēst mÅ«su metadatu datu bāzi un neļautu datu blokiem pārvērsties bezjēdzÄ«gā binārā putrā.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Tagad ir lielisks laiks, lai izskaidrotu mÅ«su bloku Ä£enerÄ“Å”anas tehnoloÄ£iju. Vai bloku Ä£enerÄ“Å”ana. Lai to izdarÄ«tu, apsveriet situāciju, kas noveda pie tā parādÄ«Å”anās.

Ņemsim seÅ”u dienu laika skalu un zemāk atzÄ«mēsim laiku, kad gaidāms negrozāmÄ«bas termiņŔ. Pirmajā dienā mēs ņemam un izveidojam failu, kas sastāv no datu bloka a un tā metadatiem. Ja nemainÄ«gums ir iestatÄ«ts uz trÄ«s dienām, ir loÄ£iski pieņemt, ka ceturtajā dienā dati tiks atbloķēti un dzēsti. Otrajā dienā mēs pievienosim jaunu failu2, kas sastāv no bloka b ar tādiem paÅ”iem iestatÄ«jumiem. Ceturtajā dienā ir jānoņem bloks a joprojām. Bet treÅ”ajā dienā notiek kaut kas Å”ausmÄ«gs - tiek izveidots File3 fails, kas sastāv no jauna bloka d un saites uz veco bloku a. Tas nozÄ«mē, ka blokam un tā nemainÄ«guma karogam ir jāatiestata jauns datums, kas tiek pārvietots uz sesto dienu. Un Å”eit rodas problēma - reālos dublējumkopijās ir milzÄ«gs skaits Ŕādu bloku. Un, lai pagarinātu to nemainÄ«guma periodu, katru reizi ir jāiesniedz milzÄ«gs skaits pieprasÄ«jumu. Un patiesÄ«bā tas bÅ«s gandrÄ«z bezgalÄ«gs ikdienas process, jo ar lielu varbÅ«tÄ«bas pakāpi mēs katrā kopijā atradÄ«sim dūŔīgas dedublēto bloku kaudzes. Ko nozÄ«mē liels pieprasÄ«jumu skaits no objektu krātuves nodroÅ”inātājiem? Pa labi! MilzÄ«gs rēķins mēneÅ”a beigās.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Un, lai no zila gaisa neatklātu savus iecienÄ«tos klientus par pamatÄ«gu naudu, tika izgudrots bloku Ä£enerÄ“Å”anas mehānisms. Å is ir papildu periods, ko pievienojam noteiktajam nemainÄ«guma periodam. Tālāk esoÅ”ajā piemērā Å”is periods ir divas dienas. Bet tas ir tikai piemērs. PatiesÄ«bā viņi izmanto savu formulu, kas ikmēneÅ”a bloÄ·Ä“Å”anas laikā dod aptuveni desmit papildu dienas.

Turpināsim izskatÄ«t to paÅ”u situāciju, bet ar bloku Ä£enerÄ“Å”anu. Pirmajā dienā mēs izveidojam failu1 no bloka a un metadatiem. Mēs saskaitām Ä£enerÄ“Å”anas periodu un nemainÄ«gumu - tas nozÄ«mē, ka iespēja izdzēst failu bÅ«s sestajā dienā. Ja otrajā dienā izveidojam Failu2, kas sastāv no bloka b un saites uz bloku a, tad ar paredzamo dzÄ“Å”anas datumu nekas nenotiek. Viņa stāvēja tāpat kā sestajā dienā. Un tādējādi mēs cenÅ”amies ietaupÄ«t naudu uz pieprasÄ«jumu skaitu. VienÄ«gā situācija, kad termiņu var pārcelt, ir tad, ja ir beidzies Ä£enerÄ“Å”anas periods. Tas ir, ja treÅ”ajā dienā jaunajā File3 ir saite, lai bloķētu a, tiks pievienota 2. paaudze, jo Gen1 jau ir beidzies. Un paredzamais bloka a dzÄ“Å”anas datums tiks pārcelts uz astoto dienu. Tas ļauj mums ievērojami samazināt pieprasÄ«jumu skaitu, lai pagarinātu dedublēto bloku kalpoÅ”anas laiku, kas klientiem ietaupa daudz naudas.

Kas mainījās jaudas līmenī, kad Veeam kļuva par v10

Pati tehnoloÄ£ija ir pieejama ar S3 un S3 saderÄ«gas aparatÅ«ras lietotājiem, kuru ražotāji garantē, ka to ievieÅ”ana neatŔķiras no Amazon. LÄ«dz ar to atbilde uz leÄ£itÄ«mo jautājumu, kāpēc Azure netiek atbalstÄ«ts ā€“ tiem ir lÄ«dzÄ«ga funkcija, taču tā darbojas konteineru, nevis atseviŔķu objektu lÄ«menÄ«. Starp citu, paÅ”ai Amazon ir objektu bloÄ·Ä“Å”ana divos režīmos: atbilstÄ«ba un pārvaldÄ«ba. Otrajā gadÄ«jumā joprojām pastāv iespēja, ka lielākais administrators virs administratoriem un saknes virs saknēm, neskatoties uz objekta bloÄ·Ä“Å”anu, joprojām dzÄ“Å” datus. AtbilstÄ«bas gadÄ«jumā viss ir stingri pienaglots un neviens nevar izdzēst dublējumus. Pat Amazon administratori (saskaņā ar viņu oficiālajiem paziņojumiem). Å o režīmu mēs atbalstām.

Un, kā parasti, dažas noderīgas saites:

Avots: www.habr.com

Pievieno komentāru