Ich bin in den Genuss gekommen noch vor dem offiziellen Release der Version 9 von Veeam Backup & Replication einige interne Tests durchzuführen, am meisten hat mich der lang erwartete HP StoreOnce Catalyst Support interessiert.
Wenn man bereits eine HP StoreOnce mit Veeam Backup & Replication v8 einsetzt, konnte man doch einige Schwächen in der SMB Performance feststellen.
Voraussetzungen für StoreOnce Catalyst Repositorys
- HP StoreOnce Version 3.13.1
- Veeam Backup & Replication v9
Der schematische Aufbau
Wegen einer 100% virtuellen Umgebung kommt für mich nur Catalyst over Ethernet in Frage. Die Alternative ist die Anbindung per FC, welche auch von Veeam unterstützt werden würde.
Neue Option für Veeam Repositorys
Die neue Option „per-VM backup file“ (Details) steht für alle Repositorys zur Verfügung, ist aber bei Catalyst Stores nicht abzuwählen.
Job Optionen für StoreOnce Catalyst
Der BestPractice für Catalyst Stores weicht enorm von dem für SMB Shares einer StoreOnce ab.
Speziell der Verzicht auf „inline data deduplication“ und damit auf das Caching (Details) hat mich verwundert. Die Option wurde aber von einem Veeam Mitarbeiter bestätigt.
Currently, default setting for deduplication storages is to disable Veeam B&R inline deduplication (to avoid opening of the entire chain for metadata reading when building deduplication tree, which on dedupe devices can take considerable time).
Testergebnisse
Alle Werte sind in MB/s. Die expliziten Werte spielen hierbei nicht die große Rolle sondern ehr die unterscheide zwischen den beiden Protokollen.
Backup
Backup Copy
Replication
Mein Fazit
Durch die Umstellung von SMB auf Catalyst haben alle Jobs einen enormen Performance Sprung gemacht. Vor allem wenn gelesen wird von einem StoreOnce Store (Copy, Replication oder Restore) sind es Welten.
Für alle ServiceProvider gibt es aber auch schlechte Neuigkeiten:
Catalyst Stores sind nicht für Veeam CloudConnect freigegeben!
Nachtrag
25.01.2016 – Dedup Ratio
Da nun mittlerweile ähnliche Datenmengen aufgelaufen sind, hier mein Nachtrag zum Vergleich der Dedup-Raten:
NAS
Rohdaten: 4,8 TB Deduprate: 10,6:1
Catalyst
Rohdaten: 3,7 TB Deduprate: 14,2:1
Damit ist mit identischen Daten unter Verwendung von Catalyst eine wesentlich höhere „Dedup Ratio“ zu erreichen als mit renen NAS Shares.
Catalyst bzw. generell jede Dedupe Appliance würde bei Cloud Connect wenig Sinn machen, da die Kunden die Daten ja üblicherweise verschlüsselt ablegen und eine Dedupe Appliance somit nichts mehr deduplizieren könnte.
Da gebe ich dir absolut recht Thorben.
Das Dedup Ergebnis wird sich verschlüsselt absolut in grenzen halten (ca. 1,9:1), dieses ist aber ohnehin ähnlich wie auf NAS Shares bei Veeam Daten auf einer StoreOnce.
Ich konnte hierzu allerdings noch keine genaue Aussage treffen, da unterschiedliche Datenbestände vorliegen.
Aktuell Sieht es so aus:
NAS
Rohdaten: 4,8 TB Deduprate: 10,6:1
Catalyst
Rohdaten: 2,6 TB Deduprate: 11,6:1
Identische VMs, unverschlüsselt.
Es wäre nur schön den Performance Benefit des Catalyst Protokolls auch für CloudConnect mitzunehmen.
Viele Grüße,
Markus
Ich persönlich würde aus Kostengründen überhaupt keine Dedupe Appliance für CloudConnect verwenden. Weil die 1,9:1 kommen ja aus der Veeam internen Datenreduktion. Und diese bleibt bei Verschlüsselung erhalten.
Das Catalyst besser ist als NAS Zugriff, das passt schon, aber am schnellsten wäre der Zugriff mit einfachem billigen Blockstorage. Um bei HP zu bleiben, eine MSA oder kleine 3par 🙂
Absolut korrekt.
Wenn man auf grüner Wiese startet, würde ich hier auch die günstigst mögliche Lösung wählen. Sicher lässt sich auch etwas als Scal-Out Backup Repository designen, damit gewinnt man noch etwas mehr Flexibilität.
Es scheint mir hier keine Limitierung zu geben:
http://helpcenter.veeam.com/backup/vsphere/backup_repository_sobr.html
http://helpcenter.veeam.com/backup/cloud/cloud_connect_limitations.html
Viele Grüße,
Markus
leider geht Scale Out Repo im Moment nicht für Cloud Connect: „You cannot use a scale-out backup repository as a cloud repository“ (ein erster Link), aber warten wir auf die Zukunft…
Tatsache, habe ich völlig überlesen. Danke für die Info!