Šiandien vėl džiaugiuosi galėdamas jums pateikti naudingų patarimų iš kolegos Jevgenijaus Ivanovo, „Veeam“ techninės pagalbos komandos vadovo. Šį kartą Zhenya pasidalino savo rekomendacijomis, kaip dirbti su atsarginėmis kopijomis ir kopijomis. Tikiuosi, kad jie padės išvengti įprastų klaidų, o jūsų kopijos ir atsarginės kopijos niekada nebus „silpnoji grandis“ atkūrimo procese, jei tokių bus.
Taigi, sveiki atvykę į katę.
Mano ankstesniame sugalvojome, kaip optimizuoti atsarginės infrastruktūros komponentų apkrovą ir pažvelgėme į dažniausiai pasitaikančias konfigūracijos klaidas. Pereikime prie kitos svarbios temos – kompetentingo pasiruošimo ir atsigavimo. Mes taip pat analizuosime jį naudodami realius pavyzdžius, su kuriais techninės pagalbos komanda turėjo galimybę dirbti.
Atsarginė kopija be atkūrimo – pinigai nuleidžiami į kanalizaciją
Į mus nuolat susisiekia vartotojai, atsidūrę panašiose sudėtingose situacijose: reikia atkurti iš atsarginės kopijos, tačiau bandant tai padaryti, žmonės užklumpa jiems neišsprendžiamą problemą. Ir ši problema visai nėra atsarginės kopijos nebuvimas, CryptoLocker veikla ar kažkas panašaus. Tai yra „tiesiog“ nepakankamas dėmesys atsarginių kopijų ir kopijų atkūrimo patikrinimui. Daugelis žmonių dažnai sutelkia dėmesį tik į atsarginės kopijos kūrimo procesą, pamiršdami, kad vien atsarginės kopijos turėjimas nėra panacėja nuo galimų negerovių. Turite suprasti, kad atkūrimas yra visiškai kitoks procesas, kuris turi savo ypatybes ir kuris turi būti kontroliuojamas ir išbandytas prieš pradedant gamybą. Štai keletas iliustruojančių pavyzdžių:
- Vartotojas patyrė kritinį 20 TB virtualios mašinos gedimą. Prastovos, žinoma, yra nepriimtinos, o administratorius pradeda momentinį atkūrimo procesą (VM momentinis atkūrimas) - po 5 minučių aparatas pakyla. Bet mes prisimename, kad tokia mašinos būsena gali būti naudojama tik laikinai – ji turi būti perkelta į gamybos duomenų saugyklą (duomenų saugyklą). O šiame pavyzdyje, kaip paaiškėjo, infrastruktūros galimybės neleido per protingą laiką nukopijuoti 20 TB duomenų. Momentinio atkūrimo proceso nustatymuose buvo pasirinkta išsaugoti pakeitimus diske C: Veeam atsarginės kopijos ir replikacijos serveris (priešingai nei vSphere momentinė nuotrauka) – dėl to, žinoma, laisva vieta diske greitai užsipildė. Tuo metu, kai vartotojas susisiekė su palaikymo tarnyba, VM turėjo pakeitimų, kurių nebuvo galima ignoruoti. Tai yra, turime situaciją, kai neįmanoma greitai užbaigti momentinio kritinės mašinos atkūrimo proceso – kaip čia išsaugoti duomenis?
Atvirai pasakius, dėl metų recepto jau neprisimenu visų finalo detalių, bet prisimenu, kad galiausiai mes niekada nesugalvojome nieko puikaus. Klientai iš savo pusės šią problemą kažkaip išsprendė išplėtę C: diską iš rezervų, nukopijavo svarbiausius failus ir tik tada išjungė VM ir taip migravo. Apskritai stebuklas neįvyko.
- Infrastruktūroje vartotojas turėjo vieną domeno valdiklį, o visi Veeam atsarginės kopijos ir replikacijos komponentai buvo sukonfigūruoti naudojant DNS. Taip, teisingai išgirdote. Buvo šimtas įvykių plėtros variantų, ne mažiau, tačiau iš tikrųjų viskas vyko taip: žmonės planavo techninę priežiūrą ir nusprendė pereiti prie savo domeno valdiklio kopijos. Jie naudojo suplanuotą perjungimą, kurį apskritai rekomenduojama daryti tokiose situacijose. Pirmajame etape viskas klostėsi gerai, o antrajame etape pradinė VM buvo trumpam išjungta, kad būtų perkelti likę duomenys. Žinoma, perjungimo darbas iš karto nepavyko, nes DNS nustojo veikti.
Laimei, galėjome išspręsti šią situaciją rankiniu būdu įgalinę repliką iš vSphere (paprastai nerekomenduojame to daryti patiems, kaip matysite kitame pavyzdyje). Bet, kaip suprantate, techninės priežiūros procesas buvo nutrauktas ir atidėtas. Be to, mes turėjome rankiniu būdu įvesti pagrindinio kompiuterio pavadinimus į failą C: „WindowsSystem32driversetchosts“ „Veeam“ atsarginės kopijos ir replikacijos serveryje, kad būtų užtikrintas teisingas perkėlimas.
- Kitas klientas turėjo visą atsarginę infrastruktūrą, sukurtą aplink juostinius įrenginius, o diske buvo saugomos tik trumpos failų grandinės. Kai jiems reikėjo atkurti daugybę failų iš didelio failų serverio, jie pastebėjo, kad nė vienas įrenginys negali būti naudojamas kaip atsarginė saugykla atkuriant iš juostos, nes nė viename neturėjo pakankamai laisvos vietos. (Galite perskaityti apie atkūrimą iš magnetinės juostos tiesiogiai ir naudojant pagalbinę saugyklą (iki šiol anglų kalba)).
Manau, kad visuose trijuose pavyzdžiuose vartotojai, taip sakant, buvo iliuzijų nelaisvėje - jie manė, kad jei atsarginė kopija bus sėkminga, tada nebus problemų su atkūrimu. Bet tai, kaip jūs suprantate, jokiu būdu ne visada, todėl atkūrimui reikia ruoštis taip pat atsargiai, kaip atsarginei kopijai. Pradedantiesiems verta patyrinėti , kuriame yra gana išsami informacija apie skirtingus atkūrimo būdus. Kiekvienos pastraipos pradžioje pateikiami reikalavimai, parengiamieji veiksmai ir galimi apribojimai. Atkūrimo iš juostų ar saugojimo momentinių nuotraukų aprašymą galite rasti dokumentacijos skyriuose ir mūsų apie Habr. Be to, pasiruošimo atkurti taikomųjų programų objektus naudojant Veeam Explorers įrankius veiksmai aprašyti skyriuje Planavimas ir paruošimas. kiekvienam instrumentui. Rekomenduoju juos atidžiai perskaityti – tai padės tinkamai paruošti sistemą atkūrimui, jei reikės. Rusų kalba pateikiamos SQL serverio duomenų bazės atkūrimo instrukcijos .
Kodėl nedirbus su vSphere konsolės kopijomis?
Teoriškai Veeam kopijos yra paprastos virtualios mašinos, su kuriomis, atrodytų, būtų logiška dirbti naudojant vSphere įrankių rinkinį, ypač vSphere klientą. Tačiau mes nerekomenduojame to daryti ir štai kodėl: perėjimas prie replikos „Veeam Backup & Replication“ yra gana sudėtingas procesas, reikalaujantis griežtai nuoseklių veiksmų (kad tokiu atveju galėtumėte atšaukti vieną žingsnį) ir taisyti galutinius veiksmus – tiesiog pažiūrėkite į paveikslėlį, iliustruojantį procesą:
Jei nuspręsite įjungti „vSphere“ kliento repliką, ateityje greičiausiai susidursite su daugybe problemų:
- Perjungimo į repliką iš Veeam atsarginės kopijos ir replikacijos mechanizmas (parodytas diagramoje) šiam įrenginiui nebeveiks.
- Duomenys Veeam Backup duomenų bazėje neatitiks tikrosios VM būsenos. Blogiausiu atveju turėsite redaguoti duomenų bazę, kad ją ištaisytumėte.
- Galimas net duomenų praradimas, kaip šiame pavyzdyje: vartotojas rankiniu būdu įgalino repliką vSphere kliente ir nusprendė toliau su ja dirbti. Po kurio laiko jis pastebėjo, kad replika vis dar rodoma Veeam Backup & Replication pulte, ir nusprendė ją pašalinti kaip nereikalingą. Dešiniuoju pelės mygtuku spustelėkite jį ir duokite komandą "Ištrinti iš disko". Veeam Backup & Replication iš karto pašalino kopiją iš disko, kuri akimirką jau buvo pilnai naudojama kaip įprasta VM ir kurioje buvo reikalingi ir naudingi duomenys.
Žinoma, yra situacijų, kai vis tiek turite įjungti repliką iš vSphere kliento - paprastai tai yra atvejai, kai Veeam serveris yra išjungtas, o repliką reikia įjungti su uždelsimu. Bet jei su Veeam serveriu viskas tvarkoje, tuomet reikia dirbti su kopijomis iš jo konsolės.
Be to, neištrinkite kopijų naudodami vSphere klientą. „Veeam Backup & Replication“ nežinos apie tokį pakeitimą, o tai kupina klaidų ir pasenusių duomenų. Jei jums nebereikia kopijos, ištrinkite ją naudodami Veeam konsolę, o ne kaip VM iš vSphere kliento. Taigi jūs visada turėsite naujausią kopijų sąrašą.
„O“ – saugokitės atnaujinimų!
Čia, žinoma, turime omenyje hipervizorių ir įvairių programų, kurių atsarginės kopijos kuriamos naudojant Veeam, atnaujinimus. Jei pažvelgsite į juos darbo su Veeam Backup & Replication požiūriu, naujinimus galima suskirstyti į 2 kategorijas: didelius, didelius, atnešančius daug pakeitimų ir mažus.
Pirmiausia pažvelkime į pirmąją kategoriją.
Svarbiausi atnaujinimai yra hipervizoriui. Prieš diegdami tokį naujinimą, turite įsitikinti, kad jį palaiko „Veeam Backup & Replication“. Šie naujinimai pateikia daug pakeitimų bibliotekoms ir API, kurias naudoja Veeam Backup & Replication, todėl Veeam atsarginės kopijos ir replikacijos kodas turi būti atnaujintas ir nuodugniai išbandytas, kad būtų galima oficialiai paskelbti, kad jie palaikomi.
Taip pat reikia nepamiršti, kad, pavyzdžiui, „VMware“ nesuteikia programinės įrangos gamintojams išankstinės prieigos prie naujausių „vSphere“ versijų, todėl „Veeam“ kūrėjai ir bandytojai gauna naują versiją tuo pačiu metu, kaip ir likusi progresyvi žmonija – todėl tarp VMware išleidimo ir oficialiai paskelbto palaikymo paprastai yra tam tikras laiko tarpas. Pakeitimų, kuriuos reikia atlikti, skaičius ir įvairovė yra tokie, kad yra mažai galimybių juos pritaikyti paprastoje karštojoje pataisoje – o oficialus palaikymas, kaip taisyklė, skelbiamas kartu su „Veeam Backup & Replication“ išleidimo versija.
Dėl to ateina tas nepatogus momentas, kai išleidus naują „vSphere“ versiją, techninės pagalbos bilietų skaičius smarkiai išauga, nes vartotojai stačia galva skuba diegti naują versiją, o jų atsarginės kopijos, žinoma, iš karto nustoja veikti. . Mes, „Veeam“ palaikymo komanda, turime paaiškinti vartotojams, ką tiksliai jie padarė ne taip, paprašyti atšaukti (jei įmanoma) arba sugalvoti sudėtingų būdų, kaip išeiti iš aklavietės. Todėl prieš diegdami pagrindinį naujinimą būtinai patikrinkite jo suderinamumą su jūsų programine įranga, prašau!
Visa tai, kas išdėstyta pirmiau, taikoma programoms, kurių atsargines kopijas kuriate ir tikitės atkurti naudodami Veeam. „Veeam Explorers“ įrankių eilutėje taip pat yra palaikomų atitinkamų programų versijų sąrašas, kuris atnaujinamas su kiekvienu Veeam atsarginės kopijos ir replikacijos leidimu. Todėl prieš diegdami naują programos versiją – ar tai būtų „Exchange“, „Oracle“ ar „SharePoint“ – būtinai dar kartą perskaitykite atitinkamą skyrių .
Į antrą kategoriją, t.y. nedideli naujinimai apima, pavyzdžiui, naujas VMware Tools versijas, Exchange kaupiamuosius naujinimus, vSphere saugos naujinimus ir kt. Paprastai jie neturi jokių didelių modifikacijų ir daugeliu atvejų „Veeam Backup & Replication“ neturi problemų su jais. (Todėl nėra viešų pranešimų apie oficialų jų palaikymą gaminyje.) Tačiau mūsų praktikoje buvo atvejų, kai tokie atnaujinimai taip pakeitė įprastą dalykų eigą, kad dėl jų atsirado Veeam Backup & Replication klaidų. Tokiose situacijose, kai problema patvirtinama, Veeam inžinieriai bando greitai išleisti karštąsias pataisas.
Tie, kurie moka techninę anglų kalbąJei norite neatsilikti nuo to, ką dirba inžinieriai ir su kuo susiduria sistemų architektai bei techninės pagalbos specialistai, rekomenduoju užsiprenumeruoti . Kiekvieną savaitę jo prenumeratoriams yra naujienlaiškis „Žodis iš Gostevo“, kurio autorius . Jame produktų valdymo skyriaus vadovas Antonas Gostevas pasakoja apie neseniai rastas problemas (ir ne tik Veeam pusėje), naujų versijų planus, naujienas iš IT pasaulio. Jei jums reikia daugiau informacijos, galite perskaityti forumo temas - jei kuris nors iš klientų po bet kurio atnaujinimo turi problemų su produktu, greičiausiai jie jau rašė apie tai forume.
Kaip suprantate, pataisymai ir naujinimai gali sukelti problemų ne tik su atsarginėmis kopijomis, bet ir su programomis, kurioms yra daromos šios atsarginės kopijos. O čia jums padės virtualios laboratorijos – Veeam DataLabs. Tikriausiai girdėjote apie „SureBackup“ atsarginių kopijų tikrinimo funkciją. Jis pagrįstas tik „DataLabs“ naudojimu, sukuriant izoliuotą aplinką, kurioje visų pirma galite išbandyti naujinimus prieš įdiegdami juos gamyboje. Primygtinai patariu tai padaryti – sutaupysite daug nervų ląstelių. Ir jei kas nors nežino apie SureBackup, rekomenduoju perskaityti .
Manau, šiandien viskas, ačiū už dėmesį!
Ką dar skaityti
Straipsniai apie Habré:
Šaltinis: www.habr.com