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