Täna esitan teile rõõmuga taas kasulikke näpunäiteid oma kolleegilt Jevgeni Ivanovilt, Veeami tehnilise toe meeskonna meeskonnajuhilt. Seekord jagas Ženja soovitusi varukoopiate ja kopeerimisega töötamiseks. Loodan, et need aitavad teil vältida tavalisi vigu ning teie koopiad ja varukoopiad ei saa kunagi „nõrgaks lüliks” taastamisprotsessis, kui see peaks vajalikuks osutuma.

Nii et tere tulemast allapoole.

Eelmises artiklis artiklis arutasime, kuidas optimeerida kopeerimisprotsesside koormust ning vaatasime tavapäraseid konfiguratsioonivigu. Liigume edasi teise olulise teema juurde – varukoopiate ettevalmistamine ja taastamine. Ka seda käsitleme reaalsetes näidetes, millega tehnilise toe meeskond on kokku puutunud.

Varukoopia ilma kanalisatsioonita – raha raiskamine

Kasutajad pöörduvad meie poole regulaarselt, kui nad järjekordse sarnase probleemi ees seisavad: varukoopiast on vaja taastada, kuid katsed sellega hakkama saada satuvad lahendamatutesse probleemidesse. See probleem ei ole sugugi mitte varukoopia puudumine, CryptoLockeri tegevus või midagi sarnast. See on „vaid” piisava tähelepanu puudumine varukoopiate ja koopiate taastamiskõlblikkuse kontrollimisele. Paljud keskenduvad ainult varukoopia loomise protsessile, unustades, et lihtsalt varukoopia olemasolu ei ole imerohi võimalike murede eest. Tuleb mõista, et taastamine on täiesti teine protsess, millel on oma eripärad ja mida tuleb kindlasti kontrollida ja testida enne tootmisse viimist. Siin on mõned näitlikud näited:

Kasutajal ilmnes 20 TB suuruse kriitilise virtuaalmasina rike. Seisaku perioodid, loomulikult, ei ole vastuvõetavad ja administraator käivitab kiire taastamise protsessi (VM instant recovery) – 5 minuti pärast on masin taas töövalmis. Kuid me peame meeles pidama, et sellist seadme seisundit saab kasutada vaid ajutiselt – see tuleb kindlasti migreerida tootmisandmemassiivi (datastore). Ja antud näites selgus, et infrastruktuuri võimalused ei võimaldanud 20 TB andmete kopeerimist mõistliku ajaga. Instant recovery protsessi seadetes oli valitud muudatuste salvestamine kettale. C: Veeam Backup & Replication serverid (erinevalt vSphere’i snapshotsest) – selle tulemusena täitus kõvaketas kiiresti. Sel ajal, kui kasutaja toetas, olid VM-il muutused, mida ei saanud ignoreerida. Seega olime olukorras, kus kriitilise masina kiire taastamise protsessi lõpetamine ei olnud võimalik – kuidas siis andmeid päästa?
Pean tunnistama, et aastate jooksul ei mäleta ma kõiki lõpu üksikasju, kuid mäletan, et me ei leidnud midagi geniaalset. Klientidel õnnestus probleemi lahendada, suurendades oma C: ketast reserveerimise teel, kopeerisid nad kõige olulisemad failid ja seejärel sulgesid nad VM-i ning migratsioon toimus. Ühesõnaga, imet ei juhtunud.
Kliendi infrastruktuuris töötas üks domeenikontroller ja kõik Veeam Backup & Replication komponendid olid seadistatud DNS-i abil. Just nii, te ei kuulnud vale. Sündmuste arenguvõimalusi oli vähemalt sada, kuid reaalsus kujunes selliseks: inimesed plaanisid hooldustöid ja otsustasid lülituda oma domeeneneseme koopiale. Nad kasutasid plaanilise lülitamist, nagu sellistes olukordades soovitatakse. Esimese etapi kõik sujus hästi, samas kui teises etapis lülitati algne VM lühikeseks ajaks välja, et andmete jääkide edastamiseks. Loomulikult lõpetati lülitusülesanne koheselt veaga, kuna DNS ei töötanud.
Õnneks suutsime me olukorraga hakkama saada, aktiveerides koopiat käsitsi vSphere'i kaudu (sellist toimingut ei soovitata iseseisvalt sooritada, nagu näete järgmises näites). Kuid nagu te mõistate, katkestati ja lükati tehnilise hoolduse protsess edasi. Lisaks pidime me käsitsi sisestama hostide nimed faili C:WindowsSystem32driversetchosts Veeam Backup & Replication serveris, et tagada korrektne tagasivõtmise käigus.
Ühe teise kliendi varundamise infrastruktuur oli üles ehitatud magnetlintide ümber, samas kui kettale hoiti vaid lühikesi failijadasid. Kui nad vajasid suurelt failiserverilt mitmete failide taastamist, selgus, et ühtegi masinat ei saanud kasutada abirepositooriumina taastamiseks lintidelt, kuna ühelgi polnud piisavalt vaba ruumi. (Otsene taastamine magnetlintidelt ja abirepositooriumi kasutamine on võimalik lugeda siin (praegu inglise keeles)).

Arvan, et kõigis kolmes näites olid kasutajad, kuidas öeldakse, illusioonide meeles – nad eeldasid, et kui varukoopia läks edukalt, ei teki taastamisega probleeme. Kuid nagu te mõistate, ei ole see sugugi alati nii, ja seetõttu tuleb taastumiseks valmistuda sama hoolikalt kui varukoopia tegemiseks. Alustuseks tasub uurida kasutajate käsiraamat, kus leidub üsna põhjalikku teavet erinevate taastamisviiside kohta. Iga lõpu alguses on loetletud nõuded, ettevalmistavad toimingud ja võimalikud piirangud. Kirjeldusi taastamisest magnetlintidelt või seadme snapshot'ide kaudu saab leida dokumentatsiooni ja meie artiklites Habrast. Lisaks on Veeam Explorers'i rakenduste objektide taastamise ettevalmistuse tegevused kirjeldatud jaotises 'Planing and preparation' (planeerimine ja ettevalmistus) juhiseid kõikide tööriistade jaoks. Soovitan neid hoolikalt tutvuda – see aitab teil süsteemi õigesti ette valmistada taastamiseks, kui see peaks vajalikuks osutuma. Vene keeles on SQL Serveri andmebaasi taastamise juhised esitatud siin.

Miks ei peaks vSphere'i konsoolist replikatega töötama?

Teoorias on Veeami replikad tavalised virtuaalsed masinad, millega oleks loogiline töötada vSphere'i tööriistade abil, eriti vSphere'i kliendi kaudu. Kuid me ei soovita seda teha, ja siin on põhjused: Veeam Backup & Replication'is replikale üleminek on piisavalt keeruline protsess, mis nõuab sammude ranget järjestikust järgimist (et vajadusel saaks samme tagasi kerida) ja korrektseid lõpptoime – vaadake lihtsalt pilti, mis illustreerib protsessi:

Kui te kavatsete käivitada koopiat vSphere kliendist, ootavad teid tõenäoliselt mitmed probleemid.

Veeam Backup & Replication (skeemis näidatud) replika vahetusmehhanism ei tööta enam selle masina jaoks.
Andmed Veeam Backupi andmebaasis ei vasta VM-i tegelikule seisundile. Halvimal juhul peate andmebaasi parandamiseks redigeerima.
On võimalik isegi andmete kaotus, nagu ühel juhul: kasutaja lubas käsitsi replika vSphere kliendis ja otsustas selle kallal edasi töötada. Mõne aja pärast märkis ta, et replika on endiselt Veeam Backup & Replicationi konsoolis nähtav ning otsustas selle eemaldada. Ta klõpsas sellele hiire parema nupuga ja andis käsu „Kustuta kettalt“. Veeam Backup & Replication kustutas koheselt repliika, mis oli juba aktiivselt kasutusel nagu tavaline VM ja sisaldas vajalikke ja kasulikke andmeid.

Muidugi esinevad olukorrad, kus tuleb siiski lubada replika vSphere kliendist - tavaliselt on need olukorrad, kus Veeam server on välja lülitatud ja replika tuleb lubada viivitusega. Kuid kui Veeam serveriga on kõik korras, tuleb replikaid hallata just selle konsoolist.

Samuti ei tohiks replikaid Veeam kliendi kaudu kustutada. Veeam Backup & Replication jääb sellise muudatuse osas teadmatusse, mis võib viia vigade ja aegunud andmeteni. Kui replika pole enam vajalik, kustutage see Veeam konsooli kaudu, mitte nagu VM vSphere klientist. Nii on teil alati ajakohane replika loend.

„O“ - ettevaatust, uuendused!

Siin mõtleme loomulikult hüperviisorite ja erinevate rakenduste uuendustele, mis varundatakse Veeamiga. Kui vaadata neid Veeam Backup & Replicationi töötamise aspektist, võib uuendused tinglikult jagada kaheks kategooriaks: suuremad, tõsised, palju muudatusi tõukavad - ja väiksemad.

Vaatame esmalt esimest kategooriat.

Kõige olulisemad uuendused on need, mis on mõeldud hypervisorile. Enne sellise uuenduse installimist tuleb kindlasti veenduda, et see on toetatud Veeam Backup & Replication poolt. Sellised uuendused toovad kaasa palju muudatusi Veeam Backup & Replication'i kasutatavate raamatukogude ja API-de liideses, seega ametliku toe kinnitamiseks tuleb Veeam Backup & Replication'i kood uuendada ja põhjalik testimine läbi viia.

Samuti tuleb arvestada, et näiteks VMware ei paku varajast ligipääsu uusimatele vSphere versioonidele tarkvaratootjatele, seega saavad Veeami arendajad ja testerid uue versiooni samaaegselt kogu muu areneva inimkonnaga – sellepärast kulub tavaliselt teatud aeg VMware väljaandmise ja ametlikult väljakuulutatud toe vahel. Vajalikud muudatused on nii palju ja nii mitmekesised, et neid on keeruline kokku suruda ühe lihtsa hotfix'i sisse – ametlik tugi kuulutatakse tavaliselt välja koos Veeam Backup & Replication'i versiooniga.

Lõpuks tekib ootamatu olukord, kus pärast uue vSphere väljaandmist hüppab tehnilise toe nõudmiste arv järsult üles, sest kasutajad kiirustavad uue versiooni installimisega ning nende varukoopiad lakkavad töötamast. Meile, Veeami tehnilisele toele, tuleb selgitada kasutajatele, mis nad valesti tegid, paluda neil vajadusel tagasi rulluda või leida keerulisi teid olukorrast välja. Seetõttu kontrollige enne tõsise uuenduse installimist kindlasti selle ühilduvust sellega, mis tarkvara teil töötab, palun!

Kõik eelnevalt mainitu kehtib ka rakenduste kohta, mida te varundate ja loodate Veeam'i abil taastada. Veeam Explorers'i tööriistade rida sisaldab samuti toetatud rakenduste versioonide loetelu, mis täieneb iga Veeam Backup & Replication'i väljaandmisega. Seetõttu enne oma rakenduse, olgu selleks Exchange, Oracle või SharePoint, uue versiooni installimist, lugege kindlasti vastavat jaotist Veeam Explorers'i dokumentatsioonist.

Teise kategooria, st väikeste uuenduste alla kuuluvad näiteks VMware Toolsi uued versioonid, kumulatiivsed Exchange uuendused, vSphere turvauuendused jne. Need ei too tavaliselt kaasa mingeid tõsiseid muudatusi ning enamikul juhtudel ei tekita Veeam Backup & Replication'iga probleeme. (Seetõttu pole nende jaoks ka avalikke teateid ametliku toe kohta tootest.) Siiski on meie praktikas olnud juhtumeid, kus isegi sellised uuendused muudavad oluliselt tavapärast asjaolu, põhjustades Veeam Backup & Replication'is vigu. Sellistes olukordades püüavad Veeami insenerid pärast probleemi kinnitamist kiiresti välja anda kuumakorrigeeringut.

Neile, kes valdavad tehnilist inglise keeltKui soovite olla teadlik sellest, mille kallal töötavad insenerid ning millega silmitsi seisavad süsteemiarhitektid ja tugiteenuse spetsialistid, soovitan teil liituda meie foorumitega. Igal nädalal saadab selle tellijatele välja uudiskirja "Word from Gostev", mille autoriks on TheRealGostev. Selles räägib Anton Gostev, tootehalduse osakonna juht, hiljuti avastatud probleemidest (ja mitte ainult Veeami poolel), kavandatud uute versioonide plaanidest ning IT-maailma uudistest. Kui vajate rohkem teavet, võite lugeda foorumi teemasid – kui kliendil tekib toote tööprobleem pärast mõnda uuendust, on tõenäoliselt keegi juba sellest foorumis kirjutanud.

Nagu te mõistate, võivad plaastrid ja uuendused põhjustada probleeme mitte ainult varukoopiate, vaid ka rakenduste jaoks, mille jaoks need varukoopiad tehakse. Siin tulevad appi virtuaallaborid – Veeam DataLabs. Olete tõenäoliselt kuulnud SureBackup funktsionaalsusest, mis on mõeldud varukoopiate valideerimiseks. See põhineb just DataLabsi kasutamisel, luues isoleeritud keskkonna, kus saab näiteks enne tootmisse installimist uuendusi testida. Soovitan seda kindlasti teha – säästate end paljusid närvirakke. Ja kui keegi ei tea veel SureBackupist, soovitan lugeda dokumentatsioon.

Tänaseks on mul kõik, aitäh tähelepanu eest!