Určite poznáte ten pocit, keď sa kritické systémy začnú spomaľovať práve vtedy, keď ich používatelia najviac potrebujú, a vy ako administrátor presne viete, prečo sa to deje. Zálohovacie okná sa nebezpečne prekrývajú s produkčným časom, servery hučia na plný výkon a diskové polia nestíhajú obsluhovať požiadavky, pretože sa práve snažíte odoslať terabajty dát do bezpečia. Tento scenár bol dlhé roky nočnou morou mnohých IT oddelení, ktoré bojovali s rovnováhou medzi bezpečnosťou dát a výkonom infraštruktúry. Nie je nič horšie, ako vysvetľovať vedeniu, že aplikácia je pomalá preto, lebo ju práve chránime pred haváriou.
Práve do tohto napätého prostredia vstúpila technológia, ktorá sľúbila zásadnú zmenu v prístupe k ochrane virtualizovaných dát. Nejde len o obyčajný nástroj, ale o zmenu filozofie, kde sa ťažká práca presúva z citlivých produkčných serverov na vyhradené zariadenie, ktoré "znesie" záťaž bez toho, aby to pocítil koncový používateľ. V nasledujúcich riadkoch sa pozrieme na mechanizmy, ktoré umožnili tento posun, a rozoberieme si, ako centralizácia zálohovania zmenila pravidlá hry v dátových centrách.
Ak sa začítate ďalej, získate hlboký vhľad do architektúry, ktorá formovala moderné zálohovacie stratégie a pochopíte princípy, na ktorých stoja aj dnešné pokročilé riešenia. Odhalíme technické detaily, skryté úskalia konfigurácie a logiku, ktorá stojí za "off-host" spracovaním dát, čo vám pomôže lepšie spravovať staršie prostredia alebo pochopiť evolúciu tých súčasných. Pripravte sa na technickú cestu, ktorá vám objasní, prečo bolo oddelenie toku zálohovaných dát od produkčnej siete jedným z najlepších nápadov v histórii virtualizácie.
Evolúcia zálohovania a potreba zmeny
Tradičné metódy ochrany dát boli navrhnuté pre fyzický svet, kde každý server bol samostatným ostrovom s vlastnými zdrojmi. Keď sme tento model preniesli do virtuálneho prostredia, narazili sme na tvrdý múr reality, pretože inštalácia zálohovacieho agenta do každého virtuálneho stroja spôsobovala "búrku" požiadaviek. Hostiteľský server, na ktorom bežali desiatky virtuálnych strojov, sa zrazu ocitol pod paľbou, keď sa všetky agenty naraz prebudili a začali čítať dáta z disku.
Riešenie tohto problému si vyžadovalo krok stranou, doslova vystúpenie z kruhu bežnej prevádzky. Bolo nevyhnutné nájsť spôsob, ako extrahovať dáta priamo z úložiska bez toho, aby sme museli prechádzať cez vrstvu operačného systému virtuálneho stroja alebo zaťažovať hypervízor.
Ľahkosť, s akou dnes pristupujeme k zálohovaniu virtuálnych strojov, stojí na ramenách technológií, ktoré ako prvé pochopili, že zálohovanie nesmie byť parazitom na výkone produkčného systému, ale jeho tichým a neviditeľným partnerom.
Virtualizácia priniesla konsolidáciu serverov, čo je skvelé pre efektivitu, ale katastrofálne pre tradičné I/O operácie počas zálohovania. Ak máte na jednom fyzickom hostiteľovi dvadsať virtuálnych serverov a spustíte zálohu, diskové pole dostane "infarkt". Preto vznikla potreba prostredníka.
Architektúra riešenia a off-host spracovanie
Základná myšlienka spočíva v zavedení dedikovaného servera, ktorý preberá zodpovednosť za presun dát. Tento sprostredkovateľ, často bežiaci na operačnom systéme Windows, slúži ako most medzi úložiskom dát (SAN) a zálohovacím softvérom. Namiesto toho, aby dáta tiekli cez sieť LAN z produkčného servera, sú "vytiahnuté" priamo zo zdieľaného úložiska.
Tento prístup sa nazýva "server-free" alebo "LAN-free" zálohovanie, hoci technicky tam server stále je, len to nie je ten, na ktorom beží vaša databáza alebo e-mailový server. Proxy server vidí tie isté diskové zväzky (LUNy) ako ESX hostitelia, ale pristupuje k nim v režime len na čítanie.
Mechanizmus funguje nasledovne:
- Zálohovací softvér pošle požiadavku na vytvorenie snímky (snapshotu) virtuálneho stroja.
- Tým sa zmrazí stav disku a všetky nové zápisy idú do dočasného súboru.
- Proxy server pripojí (mountne) tento zmrazený disk virtuálneho stroja ako svoj vlastný lokálny disk.
- Dáta sa prečítajú a odošlú na pásku alebo diskové úložisko záloh.
- Disk sa odpojí a snímka sa zahodí (konsoliduje).
Porovnanie prístupov k zálohovaniu
Aby sme lepšie pochopili, aký skok v efektivite VCB Proxy priniesol, je užitočné porovnať ho s klasickým prístupom, ktorý mu predchádzal. Rozdiely nie sú len v rýchlosti, ale najmä v dopade na infraštruktúru.
| Vlastnosť | Tradičné zálohovanie (Agent v OS) | Zálohovanie cez VCB Proxy |
|---|---|---|
| Zaťaženie CPU hostiteľa | Vysoké (spracovanie agentom v každom VM) | Minimálne (len vytvorenie snapshotu) |
| Zaťaženie siete LAN | Extrémne (dáta tečú cez produkčnú sieť) | Žiadne alebo nízke (dáta tečú cez SAN) |
| Inštalácia softvéru | Nutná v každom jednom VM | Iba na Proxy serveri |
| Zložitosť správy | Vysoká (aktualizácia agentov všade) | Centralizovaná na jednom mieste |
| Dostupnosť zdrojov | Súťaženie aplikácií o I/O operácie | Aplikácie majú plný prístup k zdrojom |
Význam snapshotov a konzistencie dát
Kľúčovým prvkom celého procesu je schopnosť vytvoriť konzistentný obraz systému v určitom čase. Bez toho by sme zálohovali "otvorené rany" súborového systému, čo by viedlo k poškodeným a nepoužiteľným dátam pri obnove.
Keď sa iniciuje proces, systém musí zabezpečiť takzvané "quiescing" – teda utíšenie súborového systému. V prostredí Windows sa na to využíva služba VSS (Volume Shadow Copy Service), ktorá povie aplikáciám ako SQL alebo Exchange, aby na zlomok sekundy zastavili zápis a vyprázdnili vyrovnávacie pamäte na disk.
Až keď je disk v konzistentnom stave, vytvorí sa snapshot. Pre proxy server je tento snapshot statickým, nemenným objektom, z ktorého môže bezpečne čítať dáta celé hodiny, zatiaľ čo produkčný virtuálny stroj veselo pracuje ďalej a zapisuje zmeny do delta súboru.
Schopnosť zmraziť čas pre dáta, zatiaľ čo svet okolo nich beží ďalej, je základným pilierom modernej dátovej ochrany. Bez tohto mechanizmu by sme boli odkázaní na nočné odstávky systémov.
Niekedy sa však stane, že snapshoty zostanú "visieť". Ak sa po skončení zálohy snapshot korektne neodstráni, delta súbor môže narásť do obludných rozmerov a zaplniť celé úložisko, čo paradoxne spôsobí pád systému, ktorý sme chceli chrániť.
Technické požiadavky na implementáciu
Nasadenie tohto riešenia nie je len o inštalácii softvéru, vyžaduje si precíznu konfiguráciu hardvéru a sietí. Proxy server musí byť fyzický server (v pôvodných implementáciách), alebo neskôr aj virtuálny, no s priamym prístupom k úložisku.
Základom je správne nastavenie zónovania na Fibre Channel prepínačoch (SAN switchoch). Proxy server musí "vidieť" tie isté LUNy ako ESX hostitelia. Tu však číha obrovské nebezpečenstvo.
Operačný systém Windows na proxy serveri má tendenciu automaticky inicializovať a podpisovať nové disky, ktoré zbadá. Ak by to urobil s LUNom, na ktorom bežia živé virtuálne stroje (VMFS zväzok), došlo by k okamžitej korupcii dát a strate celého datastore.
Preto je kriticky dôležité nastaviť na proxy serveri "automount disable" a "scrub" politiky tak, aby sa disky pripájali výlučne v režime Read-Only. Jedna chyba v tomto kroku môže znamenať katastrofu pre celé dátové centrum.
Režimy prenosu dát
Flexibilita je dôležitá, pretože nie každé prostredie má k dispozícii Fibre Channel SAN. VCB Proxy preto podporuje niekoľko režimov, ako sa dostať k dátam, pričom každý má svoje špecifiká.
Najvýkonnejším je SAN mód. V tomto prípade dáta putujú priamo z diskového poľa do proxy servera a odtiaľ na zálohovacie médium. Sieť LAN sa používa len na riadiace príkazy, čo je ideálny stav pre veľké podnikové prostredia.
Ak SAN nie je k dispozícii, existuje možnosť využiť NBD (Network Block Device) protokol. Tu dáta tečú cez sieť LAN, ale stále sú spracovávané proxy serverom, čím sa šetrí CPU na hostiteľovi, hoci sieťová karta dostane zabrať.
| Režim prenosu | Popis fungovania | Vhodné použitie |
|---|---|---|
| SAN (Storage Area Network) | Priamy prístup k blokom na poli, obchádza LAN | Veľké objemy dát, kritické systémy |
| HotAdd | Virtuálny proxy pripojí disk iného VM k sebe | Virtuálne proxy servery, flexibilita |
| NBD (Network Block Device) | Prenos dát cez Ethernet sieť | Menšie prostredia, kde nie je SAN |
| NBDSSL | Šifrovaný prenos cez sieť | Vyššia bezpečnosť, ale vyššia záťaž CPU |
Integrácia so softvérom tretích strán
Samotný nástroj od VMware je v podstate len "otvárač dverí". Neposkytuje grafické rozhranie na plánovanie záloh, správu katalógu pások alebo deduplikáciu. Je to framework, príkazový riadok a súbor ovládačov.
Skutočnú mágiu robia až partneri ako Veritas NetBackup, Commvault, Tivoli Storage Manager alebo Veeam (v jeho začiatkoch). Tieto aplikácie volajú skripty VCB, aby pripravili dáta, a následne ich prevezmú a uložia podľa definovaných politík.
Sila ekosystému nespočíva v jednom monolitickom nástroji, ale v schopnosti rôznych špecializovaných riešení spolupracovať cez štandardizované rozhrania, čím vzniká robustná ochrana, ktorá je väčšia než súčet jej častí.
Zálohovací softvér musí vedieť, ako interpretovať dáta, ktoré dostane. Môže ísť o "Full VM" zálohu, kde sa berie celý obraz disku, alebo o "File Level" zálohu, kde sa disk pripojí do Windows prieskumníka na proxy serveri a zálohovací softvér kopíruje jednotlivé súbory.
Úskalia pri obnove dát
Zatiaľ čo zálohovanie cez proxy je elegantné a rýchle, obnova dát bola v ranných fázach tejto technológie často bolestivá. Obnoviť celý virtuálny stroj bolo relatívne priamočiare – jednoducho sa "naliali" dáta späť na disk.
Problém nastával pri potrebe obnoviť jeden konkrétny zmazaný e-mail alebo excelovskú tabuľku. Ak bola záloha vykonaná na úrovni obrazu (Image Level), administrátor musel často obnoviť celý virtuálny stroj do izolovaného prostredia, tam ho spustiť, nájsť súbor a manuálne ho skopírovať.
Novšie verzie zálohovacích softvérov sa naučili "vidieť dovnútra" týchto obrazov. Dokážu indexovať obsah VMDK súboru bez toho, aby ho museli celý obnoviť, čo je funkcia, ktorá dnes šetrí hodiny času pri granular restore operáciách.
Bezpečnostné aspekty
Zavedenie centrálneho bodu, cez ktorý tečú všetky dáta organizácie, vytvára nové bezpečnostné riziko. Proxy server sa stáva mimoriadne atraktívnym cieľom pre útočníkov, pretože má prístup ku všetkému – od databáz HR až po finančné výkazy.
Je nevyhnutné tento server "opevniť". Nemal by mať prístup na internet, mal by mať striktne nastavené firewally a prístup k nemu by mal byť obmedzený len na úzky okruh administrátorov.
Dáta prenášané cez VCB Proxy v režime SAN sú zvyčajne nešifrované (pretože Fibre Channel sa považuje za bezpečnú zónu), ale akonáhle opustia proxy smerom na úložisko záloh, mali by byť šifrované, najmä ak sa ukladajú na pásky, ktoré opúšťajú budovu.
Bezpečnosť záloh je často prehliadanou kapitolou kybernetickej ochrany. Pritom kompromitovaný zálohovací server je ako kľúč od všetkých dverí v dome, ktorý ste nechali pod rohožkou.
Nezabúdajte ani na audit logov. Každé pripojenie disku, každý prenos dát by mal byť zaznamenaný, aby ste v prípade incidentu vedeli spätne zrekonštruovať, čo sa s dátami dialo.
Diagnostika a riešenie problémov
Prax ukazuje, že najčastejšie problémy vznikajú pri komunikácii so snapshotmi. Chyba "Consolidation needed" je strašiakom mnohých adminov. Stáva sa to, keď proxy server drží zámok na disku dlhšie, než je zdravé, alebo keď proces spadne uprostred zálohy.
V takýchto prípadoch je nutné manuálne zasiahnuť. Často pomôže reštart služieb na proxy serveri, alebo v horšom prípade manuálne odstránenie snapshotov cez príkazový riadok ESXi.
Ďalšou oblasťou je výkon. Ak proxy server nestíha spracovávať dáta, stáva sa úzkym hrdlom. Sledovanie vyťaženia CPU a pamäte na proxy serveri je rovnako dôležité ako na produkčných serveroch. Niekedy je lepšie nasadiť viacero proxy serverov a rozdeliť záťaž paralelne.
Prechod na vStorage APIs for Data Protection (VADP)
Technológia sa nezastavuje a aj VCB sa stalo obeťou vlastného úspechu a potreby zjednodušenia. VMware postupne nahradil tento rámec novším a integrovanejším riešením známym ako VADP.
VADP odstránilo potrebu inštalovať zložité skripty a proxy služby priamo do Windows. Namiesto toho poskytlo API rozhranie, ktoré zálohovací softvér volá priamo. Princíp off-host zálohovania zostal zachovaný (stále používame proxy), ale implementácia je omnoho čistejšia a stabilnejšia.
Dôležité je pochopiť, že VCB Proxy vydláždilo cestu. Všetky koncepty, ktoré dnes používame – CBT (Changed Block Tracking) pre inkrementálne zálohy, HotAdd transport a bezagentové zálohovanie – majú svoje korene v lekciách, ktoré sme sa naučili pri prevádzke VCB.
História technológií nás učí, že žiadne riešenie nie je konečné. To, čo bolo včera revolúciou, je dnes zastaraným dedičstvom, no bez pochopenia včerajška by sme nevedeli správne budovať zajtrajšok.
Pre administrátorov, ktorí ešte spravujú staršie systémy (legacy environments), je znalosť VCB stále nenahraditeľná. Migrácia z týchto starých platforiem často vyžaduje práve tieto znalosti, aby sa dáta bezpečne dostali do nového sveta.
Budúcnosť a cloudové zálohovanie
S nástupom cloudu sa koncept proxy servera opäť mení. Dnes často vidíme "cloud proxy", ktoré komprimujú a deduplikujú dáta predtým, než ich pošlú cez internetovú linku do cloudu.
Princíp však zostáva rovnaký: odľahčiť produkčný systém. Či už dáta posielame na pásku v suteréne alebo do dátového centra na druhom konci sveta, potreba inteligentného prostredníka, ktorý optimalizuje tok dát, tu bude vždy.
Zálohovacie procesy sa stávajú čoraz viac automatizovanými, riadenými umelou inteligenciou, ktorá predikuje najvhodnejší čas na zálohu. No kdesi v hĺbke toho všetkého stále bije srdce logiky, ktorú definovalo VCB – oddeliť, spracovať, uložiť a neobmedzovať pri tom používateľa.
Čo presne znamená skratka VCB v kontexte VMware?
Skratka znamená VMware Consolidated Backup. Ide o sadu nástrojov a skriptov, ktoré umožňovali presunúť záťaž spojenú so zálohovaním z hostiteľského ESX servera na dedikovaný proxy server.
Je VCB Proxy stále súčasťou najnovších verzií vSphere?
Nie, VCB bolo oficiálne nahradené technológiou vStorage APIs for Data Protection (VADP) už vo verzii vSphere 4.1 a v neskorších verziách (vSphere 5 a vyššie) už nie je podporované.
Aký operačný systém je potrebný pre VCB Proxy server?
Proxy server musel bežať na operačnom systéme Windows (zvyčajne Windows Server 2003 alebo 2008), pretože využíval ovládače a služby špecifické pre toto prostredie na pripájanie NTFS a VMFS zväzkov.
Môžem použiť VCB na zálohovanie fyzických serverov?
Nie, táto technológia bola navrhnutá výlučne pre virtuálne prostredie VMware. Pre fyzické servery je stále nutné používať tradičných agentov inštalovaných v operačnom systéme.
Aký je rozdiel medzi SAN módom a HotAdd módom?
SAN mód vyžaduje fyzické pripojenie k úložisku (Fibre Channel/iSCSI) a umožňuje najrýchlejší prenos. HotAdd je funkcia (častejšie pri VADP), kde virtuálny proxy server pripojí disk zálohovaného VM "za jazdy" ako svoj ďalší disk, čo nevyžaduje fyzický prístup k SAN.
Prečo je dôležité vypnúť automount na proxy serveri?
Pretože Windows by sa mohol pokúsiť zapísať signatúru na VMFS zväzky (LUNy), ktoré vidí na SAN sieti. Tým by poškodil súborový systém VMware a spôsobil stratu dát na produkčných virtuálnych strojoch.
Podporuje VCB inkrementálne zálohy?
Pôvodné VCB bolo zamerané primárne na plné zálohy (Full Backups). Efektívne inkrementálne zálohy na blokovej úrovni (CBT – Changed Block Tracking) prišli naplno až s nástupom VADP, hoci niektoré softvéry tretích strán sa snažili o vlastné implementácie aj nad VCB.
