vsenguel hat geschrieben:Hi irix
VBR ist im gleichen Netz wie das SAN und der vCenter, resp. erweichbar per 10Gig. Weitere Netze anbinden per 10Gig ist kein Problem da das ja Design noch nicht fest steht.
Du must dich entscheiden ob du Proxies auf den Hosts haben moechtest um LanFree(SCSI HotAdd) zu verwenden oder aber SAN Mode bzw. LAN.
1. HotAdd, die vDISKs werden vom Proxy gemountet und die Daten gelesen, komprimiert und dann direkt zum Backup Server. Der phys. VBR hat keine Last da er nur die Jobs verwaltet.
Ist das ein virtueller VBR so ist dieser automatisch auch immer ein Proxy. Hier laeuft dann die Last auf und er ESXi muss hier Resource bereitstellen. Wenn man mehre Proxies hat verteilt sich die Last bzw. man kann je Job diese zuweisen.
2. San Mode bedingt das VBR auf einem phys. Host installiert ist und er Zugriff auf das SAN hat. Buerdet die komplette Last dem VBR auf
3. Hier werden die Daten ueber die VADP Schnittstelle ueber den MGMT Kernel des ESXi angefordert. Ist definitiv die langsamste Methode und buerdet die Teillast dem VBR auf.
Die Frage ist natürlich wenn ich das per VM mache dass der VBR Server virtuell ist, kriege ich doch ein Problem bei einem Desaster (?).
Wie gehe ich dann vor wenn z.B. der ESXi Cluster sich in Luft aufgelöst hat (ich übertreibe hier mal)?
Ein frisch installierter VBR kann vorhandene Repositories wieder importieren. Das was in der DB steht sind nur die Stats und Jobdefinitionen. Aber..... das VBR dedup sowie Syntetic Backup kann und macht dauert so ein Import ewig und drei Tage je nach Groesse. Somit ist dein Punkt nicht ganz von der Hand zuweisen.
Das Ziel von mir war, dass ich nicht auf eine VM setze für VBR sondern eine Hardware damit ich unabhängig von VMWare bleibe (Desaster).
Bewerte die einzelnen Punkte wie Backup, Restore und DR. Um alle 3 Punkte gleichwertig zu loesen ist entsprechender Aufwand notwendig.
Ich habe Veeam bis Dato nur in kleineren Umgebungen um Einsatz und die groesseren haben historisch bedingt Quest vRanger. Bei diesem sind einige Details anders geloest was aber bedingt wird das dieses Programm weniger Funktionalitaet hat bzw. diese anders realisiert.
Das Bild oben ist nur Demo oder? Wenn du magst koennen wir Montag mal telefonieren. Schick einfach eine PM mit deinen Kontaktdaten.
Anmerkungen:
- Damals, als es im Winter noch schneite war SANMode nicht viel schneller. Das muesste ich heute halt nochmal testen
- Bei inkrementeller Sicherung von 12 VMs gleichzeitig kommen nach der Komprimierung und entfernen geloeschter Daten niemals mehr als 1GB beim Backup Server an und das bei 5 Hosts. Wir haben hier einen LAG aus 2 oder mehreren 1GbE. Anders ist es bei einer Vollsicherung aber hier wird eher der Backupserver zum Flaschenhals weil dieser dann auch 200MB/s wegschreiben koennen muss. Sehen tue ich bis zu 750MB/s was das lesen angeht aber das auch nur wenn mal ThinProvisioning Disks dran kommen bzw. VM groesseren freien Speicher intern haben. Ansonsten ist das mit den Leseraten so 100-200MB/s
- Uns gehen die 10GbE Ports aus bzw. wir fanden sie fuer Server und Storage wichtiger als fuer das Backup
- Ich kann nicht sagen wie man das vNFS beeinflussen kann. Da muesste man mal wissen was moeglich ist. Wenn es nur ueber das MGMT geht und die hier unbedingt 10GbE haben moechtet dann muss der Backup und VBR sowie ESXi Host im gleichen Subnet liegen.
- Ich meine mich zu erinneren das VBR auch Restore auf das SAN kann? Die Frage wie die Daten da fliessen koennen
Was sagt denn der welcher dir das Veeam und die Umgebung verkauft hat?
Gruss
Joerg
) Falls doch an das diskpart automount disable denken wobei das Veeam angeblich fuer dich macht.
