На форуме VMTN часто поднимается миф о фрагментации VMFS и ее влиянии на дисковую производительность.
При создании тома VMFS вы выбираете размер блока форматирования (1, 2, 4 или 8 МБ). Этот размер блока влияет на то, как гипервизор будет выделять место для VMDK файлов. Для толстых дисков - размер блока, подлежащего заполнению нулями при первом доступе, для тонких - соотв. еще и размер блока для роста.
Так значит тонкие диски в сочетании с маленьким размером блока приведут к фрагментации? Да, это более чем возможно. Однако, вопрос должен звучать: а приведет ли это к снижению производительности? И ответ - нет. Прежде всего, размер блока форматирования VMFS не имеет никакого отношения к вводу-выводу гостевой ОС. Скажем, у вас обычная ВМ с Windows и эта ВМ читает и пишет блоками по 8кБ на томе с 1МБ блоками. Гипервизор не будет читать блоками по 1 МБ, поскольку это вызовет серьезную деградацию общей производительности. Нет, гипервизор передаст СХД запрос гостевой ОС, и СХД в свою очередь будет действовать в соответствии с собственными настройками. Вероятно люди беспокоятся о том, что фрагментации повлияет на последовательные чтение / запись, но подумайте секунду-две. О каком последовательном вводе-выводе мы говорим, если смотреть со стороны СХД? Множество хостов, на каждом из которых не одна ВМ, обращающихся к целой куче виртуальных дисков, размазанных по один Ньютон знает какому количеству шпинделей. Последовательный ввод-вывод вдруг оказывается не таким уж последовательным, не так ли?
Оригинал: Duncan Epping (yellow-bricks.com)
понедельник, 14 марта 2011 г.
Подписаться на:
Комментарии к сообщению (Atom)
А где там в оригинале про Ньютона? ;)
ОтветитьУдалитьКстати, вывод тоже можно было перевести - он хороший и правильный.