На одном из форумов VMTN написали о неожиданном влиянии единого размера блока для всех томов VMFS. Пользователь произвел обнуление неиспользуемого пространства, чтобы диски скомпрессировались при Storage vMotion. Сюрпризом стало то, что диски остались того-же самого размера и после Storage vMotion.
После нескольких тестов было обнаружено, что при Storage vMotion между массивами, или между датасторами с различными размерами блока VMFS диски компрессировались. Почему?
Ответ прост: в этом случае используется другой
datamover (модуль перемещения данных). Поскольку вам это мало о чем говорит, объясню какие бывают datamover'ы:
- fsdm - самый старый datamover, с минимумом функций и самый медленный, поскольку данные проходят по всему стеку.
- fs3dm - был включен в состав vSphere 4.0 и содержал некоторые значительные изменения, позволяющие данным проходить не все уровни стека.
- fs3dm – hardware offload – datamover с поддержкой VAAI, аппаратной интеграции операций ввода/вывода с массивом. Появился в vSphere 4.1, имеет максимальную производительность и минимальные накладные расходы.
Так в чем же проблема? А проблема в одной маленькой строке текста в VAAI FAQ:
- The source and destination VMFS volumes have different block sizes
Как только выбирается датастор с другим размером блока, или датастор на другом массиве - гипервизор переключается на fsdm. Одно из немногих преимуществ этого datamover'а в том, что он "съедает" нули. В то время как fs3dm, вне зависимости от software / hardware offload, этого не делает и копирует блоки целиком.
Источник: Duncan Epping (
yellow-bricks.com)
Сообщения
