New Blog

Dear reader,

To work more inline with my twitter activities and to open my blog for more interessting stuff (not just Veeam related), I am blogging only on the http://andyandthevms.com/ blog from now.

If I will write some updates at individual posts (e.g. Exchange Backup stuff) I will add an warning message with a link to the article on this blog.

So do not hesitate to check out my new blog under http://andyandthevms.com

Thanks for all the Feedback and support

Andy

Freitag, 26. Oktober 2012

Veeam Backup Sizing in größeren Enterprise Umgebungen *UPDATE2*

Hallo Leser,

ich werde heufig  von Partnern und Kunden nach dem Sizing in größeren Umgebung von Veeam befragt. Meine Einschätzungen finden Sie hierzu anbei. Bitte beachten Sie, dass dies Expliziet nicht auf kleinere Umgebung unter 100 Server zutrifft. Das hier dargestellte ist für einen Kunden der einige hundert Server am Hauptstandort hat und noch einige weitere Lokationen.

Das hier dargestellte kann nur als Hinweis versehen werden und stellt kein Verbindliches Setup dar.
Die von Veeam zur Verfügung gestellten Dokumente "Release Notes" & "UserGuide" sowie die Veeam Lizenzbedingungen sind maßgebend.

Ich gebe keine Gewähr auf Richtigkeit. Dies ist kein offizielles Veeam Statement. Änderungen und Fehler vorbehalten.

Für das Verständnis dieses Textes ist es erforderlich, dass Sie in den Veeam Produkten geschult sind.

Backup & Replication "Management" Server (je Lokation)
VM
Für die Zentrale 4 virtuelle CPUs  (für kleinere Außenstandorte   2 virtuelle CPUs)
3GB + 350MB für gleichzeitig (current) gestartete Jobs
Disk 40GB + 10 GB per 100 VM (am Standort)
Win2012 recommended (wegen Gastrestore von Win2012 VMs)  ansonsten Win2008R2
(wenn hier der Enterprise Manager  oder Veeam ONE zusätzlich laufen soll, müssen dessen Ressourcen on Top hinzugefügt werden. Siehe unten)

Datenbank Server (Backup & Replication / Enterprise Manager)
Standard Datenbank auf MGMT Server (im B&R Setup enthalten) für bis zu 200 virtuelle Server Backup
Bei Standort größer 200 VMs muss die Datenbank  auf einem normalen MS SQL Server (keine Express Version) angelegt werden.
Es kann auch ein vorhandener Datenbankserver verwendet werden.
Ansonsten 4 (virtuelle) Kerne 4GB RAM
VM (oder Physik)
Win2008R2/Win2012
SQL2008R2  (oder 2005/2012)
Plattenperformance sollte ordentlich sein.

1 Enterprise Manager (1x weltweit)
VM
4-8 Kerne 8GB RAM  (falls mehr)
Win2008R2/Win2012
Disk 40GB + 10 GB per 100 VM (weltweit)
ab 250VM sollte die Datenbank auf einen externen SQL Server (non EXPRESS) gelegt werden.

1 Hat der Kunde die Backup Enterprise Management Suite lizenziert muss ein Veeam ONE Server + Datenbankserver eingerichtet werden.
Das Sizing geht davon aus, dass Sie mehr als 400-1000 VMs im Veeam ONE Server einbinden wollen.
4-8 Cores oder vCPUs + 12GB RAM  (weniger VMs dementsprechend weniger Ressourcen)
100GB Platte auf ordentlichen Platten

Veeam ONE Datenbankserver (bei Backup Management Suite lizenziert)
Bis 200VMs SQL Express vielleicht ausreichend. Über Zeit vielleicht ein Problem aufgrund Datenmenge.
200-400VMs SQL (non EXPRESS) Datenbank > 4-8 Cores oder vCPUs + 12GB RAM 
Ab 400VMs eigener Server/VM mit im SQL Server nur der ONE Datenbank. > 4-8 Cores oder vCPUs + 12GB RAM 
Plattenperformance ist Key. => Schnelldrehende Platten im Raid 10 + separate Platten Raid10/1 für Logs im SQL.
Platten-Platz ergibt sich in der Regel aus den per Performance gesizten Raid 10 Systemen. Fragen Sie einen Veeam SE nach dem Veeam ONE Sizing calculator aus dem Veeam internen Forum für genauere Werte.



Allgemeine Infos Proxy- und Repository-Server
Proxy Server rufen die Daten von VMware ab.
Repository Server speichern die Daten auf Disk ab.

Proxy Server können physikalisch ausgelegt werden wenn die VMware Datastores als SAN oder iSCSI vorliegen. Hierbei werden alle VMware Datastore LUNs nach der Installation von Veeam an den Veeam Server gemappt.

Proxys können immer auch als VM ausgelegt werden. Hier wird mindestens 1 Proxy pro VMware Cluster benötigt (fast Restore).

 Im Schnitt werden 10VMs zu einem Job zusammengefügt => 1000VM => 100 Jobs. Diese können dann über das Backupzeitfenster verteilt werden. Z.B. 10 current Jobs pro halbe Stunde.

Die Backupinfrastruktur könnte dann z.B. für 10-20 gleichzeitig laufende Jobs ausgelegt werden.

 Je gleichzeitig laufendem Job wird folgende Ausstattung an den Proxy/Repository Servern benötigt:
2 Kerne/vCPU 2GB RAM

Es können beide Rollen von einem physischen oder virtuellen Server übernommen werden.
Die Anforderungen summieren sich dementsprechend auf!!!!!
Bei der Verwendung von CIFS Repositories übernehmen die Proxys die Rolle des Veeam Repositories mit. Hier also ebenfalls doppelte Anforderung (4 Kerne 4GB RAM)!!!!
Wird bei der Replikation der gleiche Server als Source- und Target-Proxy eingetragen ergeben sich hier auch doppelte Anforderungen (4 Kerne 4GB RAM)!!!!

Im Gesamten kann später die RAM Anforderung geprüft werden (Veeam ONE z.B.)
Ist die Peak Belastung unterhalb von 85% Gesamtarbeitsspeicher (innerhalb einer Woche gemessen) kann der RAM reduziert werden (15% Reserve überhalb des gemessenen Peaks noch lassen.)


 

Proxy Server
2virtuelle CPUs oder 2 Kerne je current Job welcher von dem jeweiligen Proxy gehandelt wird
2GB RAM für System + 2GB RAM je current Job welcher von dem jeweiligen Proxy gehandelt wird
40GB Disk (OS)
2x  8Gbps FC HBA oder Dualkarte (4Gbps nur falls kein 8Gbps LAN Netzwerk zur Verfügung steht)
Bei iSCSI - 10Gbe (oder mehrfach 1GBe falls kein 10GB möglich)
Ohne iSCSI (sprich wenn FC-SAN eingesetzt wird) reicht 1Gbe
Wenn als VM möglichst schnelles Netzwerk zwischen Proxy und Repository
Win2008R2 oder Win 2012

Restore Proxy (Optional wenn alle anderen Proxys physikalisch ausgelegt sind)
Falls die Proxy Server pysikalisch ausgelegt werden empfehle ich an größeren Standorten eine weitere VM hinzuzufügen als „Hot-Add Restore Proxy“
Diese VM kann auch ausgeschaltet werden und bei Bedarf dann eingeschaltet werden.
2GB RAM 2 virtuelle CPUs
40GB Disk (OS)
Win2008R2 oder Win2012
Oder mehr wenn mehrere VMs gleichzeitig Wiederhergestellt werden sollen (betrifft nicht Instant VM Recovery)

 

Repository Server
2virtuelle CPUs oder 2 Kerne je current Job welcher von dem jeweiligen Repository gehandelt wird
4GB RAM + 2GB RAM je current Job
40GB Disk (OS)
100GB Disk (möglichst schnell drehende Platten mit viel IO Performance oder (Desktop-) SSD für vPower NFS Verzeichnis)
Win 2012 bevorzugt (wegen Win2012 globaler dedup Möglichkeiten) ansonsten Win 2008R2  (bei NFS Shares als Backupziel muss Repository OS Linux (inkl.SSH/Pearl) sein)
10Gbe zwischen Repository Server und VMware ESX(i) Server Verwaltungsschnittstelle (oder mehrfach 1Gbe)
Möglichst schnelle Disks auf die gesichert werden können.


Sicherungsdisks (Target)
Block Level (SAN/iSCSI/SAS/LocalDisks) gegenüber CIFS/NFS bevorzugt.
NFS mit Linux Repository Server vor CIFS Share ohne Proxy Server bevorzugt.
Standard Storage vor Deduplication Storage System bevorzugt
Wenn Deduplication Storagesystem dann nach Möglichkeit mit undeduplizierter Cache Zone für aktuelle Backup Files.
Win2012 mit Windows Deduplizierung als Repository gut geeignet da es so eingestellt werden kann, dass nur ältere Dateien dedupliziert werden. (Schneller Restore/SureBackup vom aktuellen Stand)
Raid10 vor Raid5   (Raid 6 meist ungeeignet aber möglich)
15K Disks vor 10k Disks vor 7.2K Disks

Reverse Incremental am besten auf Raid 10 oder auf Storage Virtualisierung mit Raid5 im Hintergrund (4-5x höherer IO als Incremental Modus mit Syntetic Fulls) (Normaler Raid5 auch Möglich aber langsamer)

Incremental mit Syntetic Full für Raid5 Disksysteme und Deduplizierungs-Storagesysteme mit undeduplizierter Cache Landingzone

Incremental mit aktiven Fulls für Deduplizierungs-Storagesysteme die sämtliche Blöcke gleich beim schreiben deduplizieren.

 
Calculation for Forward Incremental                                                                                                                                  

                                                                                                                                            

Backup size = C * (F*Data + R*D*Data)                                                                                                                             

                                                                                                                                            

                                                                                                                                            

                Data = sum of processed VMs size by the specific job (actually used, not provisioned)                                                                                                              

                C = average compression/dedupe ratio (depends on too many factors, compression and dedupe can be very high, but we use 50% - worst case)                                                                                                                

                F = number of full backups in retention policy (1, unless backup mode with periodic fulls is used)                                                                                                                       

                R = number of rollbacks (or increments) according to retention policy (14 by default)                                                                                                                

                D = average amount of VM disk changes between cycles in percent                                                                                                                  

                                                                                                                                            

                                                                                                                                            

Calculation for Reverse Incremental                                                                                                                                  

                                                                             

                Backup size = C * (F*Data + R*D*Data)                                                              

                Replica size = Data + C*R*D*Data                                                                                                                        

                                                                                                                                            

                Data = sum of processed VMs size by the specific job (actually used, not provisioned)                                                                                                              

                C = average compression/dedupe ratio (depends on too many factors, compression and dedupe can be very high, but we use 50% - worst case)                                                                                                                

                F = number of full backups in retention policy (1, unless backup mode with periodic fulls is used)                                                                                                                       

                R = number of rollbacks (or increments) according to retention policy (14 by default)                                                                                                                

                D = average amount of VM disk changes between cycles in percent                                                                                                                  

                                                                                                                                        
Beispiel aus der Praxis:
Kunde 1000VMs 100TB an VMware den VMs zugewiesener Kapazität.
Tägliches Backup von Mo-Fr mit Reverse Incremental und 14 tägiger Aufbewahrungsfrist.
40TB BackupDisk Space (Kunde hat noch Luft zum wachsen)

Kunde hat
4x Proxy mit 2x QC CPU und 24GB RAM  (1 Server kann Ausfallen bzw. für Update zu neuen Versionen in das Testsystem integriert werden) 2x 8Gbps FC HBA
2x Repository Server 2x QC CPU mit 48GB RAM
1VM für Verwaltung und Enterprise Manager  8 virtuelle CPUs mit 32GB RAM
Die 1000VMs sind verteilt auf 120 Jobs


Standard, Enterprise oder Management Suite Version
Ich würde dem Kunden beim Backup immer mindestens Enterprise anbieten wie sämtliche Restore Möglichkeiten enthalten sind. Macht der Kunde ausschließlich Replikation kann auch die Standard Version verwendet werden.
In den Enterprise Projekten würde ich allerdings immer die Management Suite anbieten, da hier Erweitertes Backup Reporting möglich ist. Z.B. Reports wie "Gibt es VMs die noch nicht im Backup hinzugefügt wurden und wer hat Sie wann erstellt" oder "Gibt es VMs die Seit X Tagen kein Erfolgreiches Backup haben" und "Läuft mein Backup Storage in nächster Zeit voll?" + weitere Tools zur Dokumentation, Kapazitätsplanung und Change Management


Gruß Andy

Keine Kommentare:

Kommentar veröffentlichen

Dieses Blog durchsuchen