www.SAMURAJ-cz.com 

29.01.2023 Zdislava Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Veeam Backup & Replication - přenos dat a rychlost záloh či obnovy

Sobota, 17.12.2022 15:30 | Samuraj - Petr Bouška |
Devátý díl mého seznamování se zálohovacím řešením Veeam. Podíváme se na efektivitu zálohování a obnovy. Jaká je topologie pro různé zálohovací situace a kudy se přenáší jaká data. Zkoumáním jsem zjistil překvapivou věc, že Veeam může jako síť využít místo LAN také iSCSI SAN, což může zvýšit rychlost přenosu. Pro sledování výkonu zálohování nám pomohou statistiky běhu úlohy a také detekce úzkého místa (komponenty). Na závěr si uvedeme reálné rychlosti zálohování a obnovy z mého prostředí.

Pozn.: Popis v článku vychází z Veeam Backup & Replication 11a, licencováno pomocí Veeam Universal License (VUL), tedy obdoba Enterprise Plus.

Síťová cesta pro přenos dat

Při zálohování nebo obnově se přenáší velké množství dat. Takže, mimo potřebného HW výkonu na zpracování, je zásadní, přes jaké sítě se data přenáší, a jaká je jejich propustnost. To je ovlivněno topologií zálohování , kde je řada možností. Další věc, která ovlivňuje rychlost, jaká data (jak velká) se přenáší. Prakticky, zda jsou redukovaná (primárně deduplikovaná a komprimovaná) nebo surová.

Obecně přenos dat při zálohování (při obnově je opačný) probíhá následně:

  • zálohovaný zdroj (server) má data uložena (na lokálních discích nebo) na diskovém poli přístupná přes SAN síť
  • Backup Proxy (Data Mover) nebo Veeam Agent nebo Veeam Plugin čte data ze zdroje, buď běží přímo na zdroji nebo přenáší přes LAN síť
  • Backup Proxy nebo Veeam Agent provede úpravu/redukci dat (deduplikaci a kompresi)
  • Backup Proxy nebo Veeam Agent nebo Veeam Plugin přenáší (redukovaná) data na Backup Repository, někdy může Proxy běžet na stejném serveru jako Repository, v ostatních případech se přenáší přes LAN síť
  • Backup Repository může mít úložiště připojeno z diskového pole přes SAN síť
Veeam Backup & Replication - komponenty a přenos dat při zálohování

Existují další možnosti, které schéma výše nezahrnuje, jako je využití Direct Storage Access (Backup from Storage Snapshot).

Umístění Backup Proxy

Značný rozdíl je, kde běží Backup Proxy. Variant je hodně, ale podíváme se jen na základní, kdy máme na Backup Serveru všechny role. Pro VMware vSphere běží na Backup Serveru spolu s Backup Repository. Při transportním režimu Network se data ze zdroje přenáší po síti a redukce dat proběhne až před uložením. Pro uložení se data nemusí přenášet po síti na Backup Repository, ale rovnou se ukládají na úložiště (přes SAN).

Veeam Backup & Replication VMware topologie

Pro Microsoft Hyper-V (a podobně pro Veeam Agent nebo Veeam Plugin, které jsou instalované na zálohovaném serveru) můžeme využít On-Host Proxy, která běží na Hyper-V serveru, kde se nachází zálohované VM. Takže se nepřenáší data po síti, ale čtou se přímo z úložiště serveru (po SAN). Provede se redukce dat a zmenšená data se posílají po síti na Backup Repository. Tam se (přes SAN) ukládají na úložiště.

Veeam Backup & Replication Hyper-V topologie

Využití iSCSI SAN pro přenos dat

Dokumentace Veeam (například Backup Architecture - On-Site Backup) na mnoha místech uvádí, že se data mezi Backup Proxy a Backup Repository přenáší přes LAN. Ani mne nenapadlo uvažovat, že by to mohlo být jinak. Ale zkoumal jsem, že některé zálohy probíhají příliš rychle na 1 Gbps síť. Z monitoringu jsem zjistil, že v době zálohování nebyl na LAN adaptérech Backup serveru skoro žádný provoz.

Nakonec jsem došel k následujícímu poznatku (studováním provozu a Veeam logů na serverech), o kterém jsem nenašel žádné informace v dokumentaci ani na fórech. Ale snad bude pravdivý a nakonec vypadá logicky.

Pokud nějaká Veeam komponenta (Source Data Mover) přenáší data na Backup Repository (Target Data Mover), tak vybírá, jakou síťovou cestu použije. Od Backup Serveru dostane pokyny a seznam všech IP adres pro Backup Repository. Zkouší jejich dostupnost a patrně také kvalitu/rychlost a zvolí tu nejlepší.

Pokud využíváme iSCSI SAN síť pro připojení disků z pole, tak ji (patrně) Veeam bere stejně jako LAN. Je to částečně logické, protože obě sítě využívají Ethernet a TCP/IP. Takže se přes ně dá komunikovat identicky. Když běžně komunikujeme mezi servery, tak používáme IP adresy z LAN, a proto jde provoz tudy. Ale Veeam používá informace i z iSCSI adaptérů.

Můžeme mít zdrojový server připojený do jedné nebo více LAN (VLAN) o rychlosti 1 Gbps a také do iSCSI SAN o rychlosti 10 Gbps. Pokud je zálohovací server (Backup Repository) připojen do stejné LAN i SAN sítě, tak se pro přenos dat zvolí rychlejší SAN síť. Toto se v praxi uplatní při zálohování Microsoft Hyper-V, Veeam Plug-in for Oracle RMAN, patrně také Veeam Agent.

Veeam Backup & Replication - přenos dat přes iSCSI SAN

V dokumentaci jsem k tomuto tématu našel pouze část Network Traffic Management. Kde je informace, jak bychom toto chování určitým způsobem omezili, pokud by bylo potřeba, Specifying Preferred Networks. V popisech, jak funguje zálohování, je navázání spojení popsáno velice stručně:

Veeam Data Movers on the backup proxy and backup repository establish a connection with each other for data transfer.

Veeam Agent service that runs on the protected computer and Veeam DataMover that runs on the backup repository establish a connection with each other for data transfer.

Výkon či rychlost zálohování a obnovy

Základní otázka je, jaký údaj brát jako rychlost zálohování nebo obnovy dat. V praxi nám jde o to, za jak dlouho proběhne záloha či obnova určitého množství dat. Přehledný údaj je průměrná rychlost v MB za vteřinu. To může být rychlost přenosu po síti nebo rychlost zpracování.

Statistiky běhu úlohy

Veeam Backup & Replication nám pro úlohy zobrazuje statistiky, kde je řada informací - Viewing Real-Time Statistics. Ale je potřeba se v nich dobře orientovat (a ne všemu důvěřovat).

  • Processed - celková velikost VM (velikost všech disků) nebo obsazený prostor disků při zálohování agentem
  • Read - objem dat načtený zdrojovým Data Mover před deduplikací a kompresí, pro VM obsazené místo na disku, při přírůstkové záloze pouze změněné bloky (CBT), pro agenta se také použije CBT, případně pouze filtrovaná data pro zálohu
  • Transferred - objem dat přenesený ze zdrojového Data Mover na cílový Data Mover, tedy po deduplikaci a kompresi, pro Hyper-V a agenta jde o data přenášená po LAN síti
  • Duration - doba běhu úlohy
  • Processing rate - průměrná rychlost zpracování dat, má jít o poměr načtených dat (Read) a trvání úlohy (Duration), to je jednoduchá matematika, v praxi se ovšem velice často uvádí rychlost mnohem vyšší než vyjde tímto výpočtem, nápadné je již to, že je rychlost často mnohem vyšší než uvedená rychlost čtení disku (v detailu VM)
  • Throughput - pro poslední běh úlohy vidíme barevný graf, který ukazuje rychlost čtení a přenosu v průběhu času (můžeme najet na určitý časový moment a zobrazit detaily)
Veeam Backup & Replication - Job Session Statistics

Úzká místa - Performance Bottlenecks

Veeam Backup & Replication se snaží identifikovat úzká místa v procesu přenosu dat při zálohování - Performance Bottlenecks. Zobrazuje procentuální využití různých zdrojů (komponent), což nám může pomoci v optimalizaci využití zdrojů a efektivity datového toku. Ve statistikách provedené úlohy vidíme Bottleneck, který krok zpracování je nejvíce vytížený. Po najetí na údaj se zobrazí procenta pro všechny fáze. Ty vidíme uvedené také v logu úlohy. V logu máme tyto hodnoty také pro jednotlivé objekty (VM, počítač).

Veeam Backup & Replication - Job Session Statistics - Bottleneck

Využití zdrojů (procenta) ukazuje dobu, po kterou jsou komponenty během úlohy zaneprázdněny. Efektivní datový tok předpokládá, že všechny jeho součásti pracují přibližně stejnou dobu. Pokud je některá komponenta neefektivní, tak pracuje 100 % času, zatímco ostatní jsou nečinné a čekají na přenos dat.

Body v datovém kanálu (etapy zpracování) jsou

  • Source - komponenta čtení zdrojového disku, zodpovědná za získávání dat ze zdrojového úložiště
  • Proxy - komponenta Backup Proxy, zodpovědná za zpracování dat
  • Network - komponenta zápisu síťové fronty, zodpovědná za získávání zpracovaných dat z Backup Proxy a jejich odeslání po síti na Backup Repository
  • Target - komponenta cílového zápisu na disk (zálohovací úložiště)

Pozn.: Pokud používáme WAN Acceleration, tak se přidává ještě Source a Target WAN accelerator.

Narazil jsem na docela zajímavý PDF dokument Extremely fast processing to deliver the MAXIMUM performance.

Praktické příklady rychlosti zálohování a obnovy

Uvedeme si příklady různých typů zálohování a reálně dosahované rychlosti v prostředí, kde je LAN síť o rychlosti 1 Gbps a iSCSI SAN o rychlosti 10 Gbps. Snažím se uvádět reálné hodnoty, což není vždy údaj uvedený jako Processing rate. Tedy něco, co odpovídá poměru načtených dat a doby běhu úlohy. Vždy pro Active Full Backup.

Veeam Agent

Při zálohování a obnově pomocí Veeam Agent jde komunikace po LAN síti (na serveru s Agentem jsem neměl připojenu iSCSI SAN). Agent provádí deduplikaci a kompresi, takže po síti na úložiště se přenáší méně dat.

Při zálohování i obnově na síti o rychlosti 1 Gbps dosahuji rychlosti 100 až 130 MBps. Obnova 6 TB trvala 13:15:23, průměrná rychlost 132 MBps.

VMware Network Mode

Při zálohování a obnově VMwaresíťovém transportním režimu (nbd/nbdssl) se využívá VMkernel network interface. Pokud máme síť o rychlosti 1 Gbps, tak můžeme dosáhnout dost špatné propustnosti. V mnoha diskusích lidé uvádí, že mají rychlosti 20 až 50 MBps, ale některé odpovědi jsou, že by to mělo fungovat na plné rychlosti sítě. Stará dokumentace (Network Mode) přímo uvádí, že pro VMware Management Interface jsou implementovány škrtící mechanismy (Throttling mechanisms), takže se dosahuje propustnosti 40 %. Potvrzení této informace jsem nenalezl.

Při zálohování i obnově na síti o rychlosti 1 Gbps dosahuji rychlosti 50 až 60 MBps. Obnova 25,3 GB (30 GB) trvala 9:51, průměrná rychlost 52 MBps.

VMware Direct Storage Access

Pokud využijeme Direct SAN transportní režim (san), tak se data načítají/ukládají přes SAN síť, která má typicky vyšší rychlost než LAN. Pro zálohování můžeme využít Backup from Storage Snapshot.

Zálohování typu Backup from Storage Snapshot na síti o rychlosti 10 Gbps dosahuje rychlosti až 400 MBps (ale často menší 200 až 300 MBps). Ovšem obnova v testech probíhala pomaleji. Obnova 25,3 GB (30 GB) trvala 5:47, průměrná rychlost 89 MBps.

VMware Virtual Appliance

V různých materiálech se doporučuje, jako nejvýhodnější pro obnovu VMware, využít Hot-Add Proxy, tedy transportní režim Virtual Appliance. Bude rychle číst/zapisovat data ze zdroje přes SAN (přímým přístupem na Datastore), ale pak je otázka, jakou síť máme pro komunikaci s Repository. Proxy provádí deduplikaci a kompresi, takže po síti na úložiště se přenáší méně dat. Pro přenos se nevyužívá VMkernel network interface, takže se neuplatní jeho případné omezování (mělo by být vždy rychlejší než Network Mode).

Tento režim jsem zatím netestoval.

Microsoft Hyper-V

Při zálohování a obnově Hyper-V můžeme využít On-Host Proxy, která běží na Hyper-V serveru, kde se nachází zálohované VM. Ta provádí deduplikaci a kompresi, takže po síti na úložiště se přenáší méně dat. Přenos dat probíhá po LAN síti, ale jak jsme si uvedli, tak může také využít iSCSI SAN (což je můj případ).

Zálohování na síti o rychlosti 10 Gbps dosahuje rychlosti až 550 MBps (v jednom případě i 720 MBps, dochází ke slušné redukci dat, takže po síti se přenáší i méně než polovina). Obnova 34,5 GB trvala 1:52, průměrná rychlost 315 MBps.

zobrazeno: 464krát | Komentáře [4]

Autor:

Související články:

Zálohování - Backup

Články věnující zálohování (Backup), replikaci (Replication) a obnově (Restore) dat. Tedy ochraně dat (Data Protection) pomocí záložních kopií a obnově po havárii (Disaster Recovery).

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

  1. [1] Martin Manan

    Veeam je v tomto skutecne flexibilni. Jeste s Win2012R2 jsem pouzival s Hyper-V off-host backup, kdy se zalohovany LUN (jeho snapshot) pripojil primo na backup server a teprve tam se nacitaly data. Proc zminuji verzi OS, slo primarne o workaround bugu, kdy CSV na hyper-v pri velkem vytizeni padal a nikdy to nebylo opravene (i kdyz changelog k Win updatu m nekolikrat tvrdil opak).

    V tomto rezimu je ovsem rychlost limitovana tim jednim off-host serverem, takze stale jeste s Win2012R2 byla vyhodnejsi kombinace on-host+LUN snapshot, kdy deduplikaci a kompresi provadi paralelne vsechny hyper-v nody, ale zaroven se zaloha provadela pripojenim vytvoreneho snapshotu LUNu diskoveho pole k temto nodum.

    No a konecne u Win2019 uz je to opravene, zadne snapshoty na diskovem poli uz nejsou potreba a rychlost zalohovani je klidne pres 1TiB/sec :)

    Sobota, 17.12.2022 21:05 | odpovědět
  2. [2] Martin Manan

    odpověď na [1]Martin Manan: Pardon, samozrejme 1GiB/sec, s terabajty bychom uz byly trochu nekde jinde.

    Sobota, 17.12.2022 21:18 | odpovědět
  3. [3] Pe.S.

    Řesili jste někdo zalohovani cluster in cluster? Tj. příklad: mám na dvou HyperV nodech dva virtuály, na kterých běží cluster filesystem (sdileny disk je typu shared vhdx ulozeny na csv a přístup k němu má vždy ten server, na kterém je přesunuta role FS). Při prvním zálohování téhle legrace Veeam udělá snapshot shared vhdx disku, ale po dokončení zálohy už neudělal nikdy merge disků, což je problém. Druhá záloha už pak nikdy neproběhla, případně došlo k jiným nečekaným problémům. Co jsem četl na fórech, tak se to řeší už roky. Nevím jestli třeba na VMware to funguje, to jsem zatím nezkoušel, ale na HyperV mi to prostě odzálohovat nešlo.

    Neděle, 18.12.2022 09:06 | odpovědět
  4. [4] Martin Manan

    odpověď na [3]Pe.S.: To jsem resil relativne nedavno. Vysledek odpovedi od Veeam supportu byl ano, je to bug, ne, opraveny neni.

    Nicmene pri blizsim pohledu, jak funguje na Hyper-V Shared vhdx jsem zjistil, ze ne moc optimalne. Na podkladovy LUN, kde se nachazi dany shared vhdx, komunikuje vzdy jen hyper-v node, ktery je aktualni owner toho LUNu. Coz ovsem neni nijak provazane s tim, kde se nachazi VM, ktere ho maji pripojeny a uz vubec ne tim, kde bezi dana clusterovana sluzba uvnitr VM (Fileserver, SQL atp.).

    Takze po vetsinu casu pak probiha komunikace na diskove pole pres CSV redirected access (podobne jako pri vypadku nejake cesty ci kdyz se pouzije ReFS file system, ktery rovnez nepodporuje direct access na CSV z vice serveru najednou). Tedy misto treba primo fibre channelu, tak se prenos dat jeste proxuje pres hyper-v cluster network, v mem pripade klasickou 1Gb ethernetem a jiny node.

    Za me naprosto nepouzitelne, vyresil jsem pripojenim disku primo do VM z diskoveho pole pres FC passthrough a zalohy pres Veeam agenta (instance). VM potom potrebuje mit idealne pristup na Veeam Backup Repository.

    Úterý, 20.12.2022 14:16 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách