Exagrid Backup Appliance

Verwendung von Exagrid Deduplication Appliances als Veeam Repository

Die Bedeutung von Backup und Recovery Lösugen stehen heute außerhalb jeder Diskussion. War es vor etwa 10 Jahren noch ein gerne vernachlässigtes Thema, kann sich heute kein Unternehmen mehr Datenverlust oder Ausfall von Service-Verfügbarkeit leisten. Damit rückten Backup-Lösungen in Bezug auf Wichtigkeit auf Augenhöhe mit den eigentlichen Produktivsystemen. Die Zeitfenster für RPO und RTO werden folglich immer kleiner und der hierfür notwendige Aufwand und damit die Kosten immer höher. Wer ein Backupkonzept plant muss eine Balance finden zwischen Geschwindigkeit, Zuverlässigkeit und Kosten. Low-Cost NAS Boxen sind nicht sehr zuverlässig und langsam – vor allem wenn man davon ein Instant Recovery fahren muss. Premium Storages sind schnell und verlässlich, aber auch sehr teuer. Die darauf abgelegten Backupdaten sind unter Umständen hochredundant, sodaß hier ein hohes Einsparpotenzial in Deduplizierung liegt. „Exagrid Backup Appliance“ weiterlesen

Different Blocksizes are evil!

Geahnt habe ich das schon immer, aber heute durfte ich das selbst miterleben. Storage vMotion von einem Volume (8MB Blocksize) auf ein frisch mit vmfs5 formatiertes Volume (1MB Blocksize). Zwanzig Gigabyte verschieben kann quälend langsam sein. Eine gleichgroße VM zwischen zwei LUNs mit gleicher Blockgröße dauerte nur einen Bruchteil der Zeit!

svMotion mit unterschiedlicher Blocksize
VM Protokoll LUN Source LUN Target Zeit [min]
 20 GB  FC 4Gbit  SAS 15k 8MB  SAS 15k 1MB  23
 20 GB  FC 4GBit  SAS 15k 8MB  SAS 15k 8MB  3

Wie kommt es zu derart frappierenden Unterschieden bei svMotion?

Die Ursache liegt in der Verwendung der unterschiedlichen Datamover, die vSphere5 für svMotion verwendet. Wenn die Storage kein Hardware Offload unterstützt, dann stehen zwei Datamover zur Auswahl:

  • fsdm der Standard Datamover. Liest den Block in den Applikationspuffer (svMotion) und schreibt diesen dann zum Ziel.
  • fs3dm : optimierter Datamover, der mit vSphere4 eingeführt wurde. Er Verschiebt die Daten auf Hypervisor Ebene unter Umgehung des Applikationspuffers.

Sobald Quelle und Ziel unterschiedliche Blockgrößen haben, fällt vSphere zurück auf den Standard Datamover fsdm. Die Blöcke werden gelesen und wegen unterschiedlicher Blockgröße an Quelle und Ziel neu organisiert, bevor sie geschrieben werden.

Ein sehr schöner Artikel hierzu erschien unter dem Titel “Blocksize impact” bei Yellow-Bricks und ein weiterer bei Frank Denneman unter dem Titel “Upgrading VMFS Datastores and SDRS