Veeam kapcsán mindig van mit tanulni, mindig van valamin agyalni való. Az egyik ügyfél megkeresett azzal, hogy a VMware környezet mentését milyen formában lehetne más hálózatra terelni, ezzel tehermentesítve a tűzfalakat. Nem ritka kérés ez és igazából sokkal többeket érdekelhet és érinthet, hiszen itt nem csak arról van szó hogy valaki már a vSphere ESXi-ből is hálózaton húzza ki a mentést, hanem arról, hogy a Veeam különböző komponensei hogyan kommunikáljanak egymással.
A példában egy végtelenül egyszerű Veeam telepítésben szeretném bemutatni miről is lenne szó. Van tehát négy (igazából öt) szerverem:
- vCenter Server és vSphere ESXi – a vCenter Server-t nem jelöltem külön.
- Veeam Backup Server (neve VEEAMBACKUPSERVER)
- Veeam Backup Proxy (neve VEEAMBACKUPROXY)
- Veeam Backup Repository (neve VEEAMBACKUPREPO)
Az alábbi egy hálózati ábra, de lényeges, hogy a Veeam Backup Proxy maga egy VM, azaz hot-add módon menti a mentendő virtuális gépeket, maga is az ESXi-n fut. A három Veeam komponens nem egy VLAN-ban van, azaz értelmezhető közöttük egy tűzfal is akár, a képen egy router-t tettem oda.
A mentési feladatban a Veeam Backup Proxy megadásánál explicit kiválasztottam a VEEAMBACKUPROXY-t, azaz a mentést nem a Veeam Backup Server, hanem ez a VM fogja majd elvégezni. A repository kiválasztásokor pedig a VEEAMBACKUPREPO-t adtam meg, azaz a VEEAMBACKUPPROXY majd ide küldi a mentett adatot.
Az alapvető működés
A mentést elindítva, majd közben és utána vizsgálva a hálózati forgalmat, látható hogy nyilvánvalóan az a hálózati interfész és közvetetten kapcsolat terhelt, amelyen a gépek interfésszel rendelkeznek. Mivel ebből egy darab van a példa ezen részében, ezért nem meglepő, hogy a VLAN 200-ból lesz mentési forgalom a VLAN 201 felé.
Azért ellenőrizzük le, hogy tényleg úgy mentett-e mint ahogyan azt terveztük. Látható hogy a VM-et bizony a VEEAMBACKUPPROXY hot-add segítségével mentette le.
A hálózati forgalmak tekintetében látszik, hogy a VEEAMBACKUPPROXY elég sokat küldött – transmit – kifelé az interfészén. (Kétszer futtattam le a mentést.)
Ami persze a VEEAMBACKUPREPOSITORY felé ment, amelynek az interfészén bizony jelentős bejövő forgalom látszott. (Kétszer futtattam le a mentést.)
És itt jön a kérdés, hogy rá lehet-e venni a Veeam-et, hogy ne így csinálja. A Veeam működése jelentősen a DNS-ben található bejegyzéseken múlik. Szóval a fenti komponensek mind-mind rendelkeznek A és PTR rekordokkal a zónában. Igazából két eset kínálkozik. Azonban ezek tárgyalása előtt nézzük meg azt a hálózati leosztást, amit szeretnénk.
A forgalmat szeretnénk a VLAN 66-ra terelni. Az alábbi kép azt sugallja, hogy a forgalom eljut a router-ig, viszont amennyiben például a két szerver az aggregációban találkozik egymással, akkor teljesen tehermentesül a router/tűzfal. A kép ezt feltételezi, ugyanakkor a switch-et nem rajzoltam be.
A mentési hálózatra történő terelés
Említettem, hogy két mód is van. Az egyik az, hogy a backup proxy-n felvesszük a host file-ba a backup repository szervert hoszt és FQDN-nel is, méghozzá a mentési hálózatra szánt – esetemben a 192.168.66.1-es IP-vel.
A másik megoldás pedig ennél sokkal egyszerűbb. Van egy beépített opció erre a Veeam-ben, méghozzá a bal felső sarokban a lenyiló menüben, a Network Traffic Rules rész.
Erről ír ez a cikk is: https://helpcenter.veeam.com/docs/backup/vsphere/select_backup_network.html?ver=120 Összefoglalva talán annyi a lényeg, hogy majdnem az összes Veeam-ben értelmezhető komponens preferálható egy vagy több hálózat a mentési célú forgalomra. „To define networks for data transfer, you must create a list of preferred networks. When Veeam Backup & Replication needs to transfer data, it uses networks from this list. If a connection over preferred networks cannot be established for some reason, Veeam Backup & Replication will automatically fail over to the production network.”
A megnyitásakor sok jót nem sejtet, mert teljesen irrelevánsnak mutatja magát, de van ott egy „Networks” rész, ami pont az ami nekem kell. Látható, hogy felvehető több subnet is, amiket preferálni fog a backup és replikációs forgalom esetén. Fel is vettem a fenti VLAN 66-ra illeszkedő tartományt, ami a 192.168.66.0/24.
Mást nem is szükséges tenni. Tehát a Veeam Backup Server továbbra is az eredeti és amúgy a DNS-be bejegyzett IP-n fog beszélgetni a Backup Server és Backup Repository kiszolgálókkal, de utóbbiak Data Mover által végzett forgalmára azt a hálózatot fogják preferálni, amit megadtam.
De ellenőrizzük le! Nos a Backup Proxy kimenő forgalma már a második – a diagramon 4001 – interfészt terheli, ami a backup proxy második interfésze, azaz pont az, ami a 192.168.66.0/24 hálózatban van.
A Backup Repository-n is ez látszik, azaz itt bejövő forgalom volt a 4001-es sorran jelölt, szintén a VM második interfészén, ami itt is a 192.168.66.0/24-ben van.
Összességében tehát simán megoldható, hogy külön hálózatba szervezzük a Veeam-et így tehermentesítve az amúgy elég drága hálózati eszközöket, amelyek elégséges performanciával rendelkeznének egy mentési forgalom „átengedéséhez”. Mikor azt mondják nekem, hogy minden forgalmat szűrni kell – sokszor még az iSCSI és NFS kapcsán is felmerül – akkor fel szoktam rántani a szemöldököm. A mentési forgalom – ahogy az előbb említett másik kettő is – jól meghatározott porton, teljes mértékben ismert IP-k között történhet és történik, ezeknek nincs dinamikus volta. Ráadásul ezekben a hálózatokban nem kell gateway, nem kell őket sehová sem route-olni.
