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”
