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íť

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).

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ě.

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.

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)

Ú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č).

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ě VMware v síť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.