Весьма и весьма часто всплывает вопрос - а какой из типов дисков для ВМ лучше?
Напомню, что эти три типа следующие:
- HDD -> vmdk - файл , лежащий на VMFS. VMFS это специализированная файловая система, и специализация заключается:
- доступ к одной и той же LUN большого количества ВМ, в том числе с разных хостов
- на этой LUN могут лежать очень большие файлы
- ну и программисты VMware догадывались, что I/O нагрузка может быть весьма сильной к vmfs разделам, и они должны обеспечивать максимально хорошую скорость.
- HDD -> Raw LUN virtual. RDM - файл vmdk все равно создается, но он фиктивный, и в качестве диска ВМ реально используется весь LUN. Используется для, в первую очередь, кластеризации аля MSCS, и для того, чтобы на LUN были привычные и понятные файловые системы и файлы. Их можно бекапить по уже существующим схемам, и средствами СХД.
- HDD -> Raw LUN physical.В этом варианте vmkernel перехватывает\обрабатывает одну единственную SCSI команду от гостевой ОС к диску. В этом режиме не работают снапшоты, в отличие от virtual RDM и vmdk.
Тут лежит официальный VMware'овский документик на эту тему, "Performance Characteristics of VMFS and RDM".
Из него я узнал, что:
- В случае "Random mixed /IO per second" - VMDK > vRDM > pRDM
- То же самое в случае "Random read I/O operations per second"
- То же самое в случае "Random write I/O operations per second "
- Наоборот в случае "Sequential read I/O operations per second" - VMDK <>
- и так же в случае "Sequential write I/O operations per second"
Вывод:
- При случайном доступе VMFS и RDM похожи по производительности в I/O.
- При последовательном доступе с малым размером блока RDM лучше. Правда, при увеличении размера блока разница сокращается вплоть до нуля.
- При случайном доступе с небольшими блоками накладные расходы похожи, в других случаях RDM менее накладен.
Отсюда.
Странно, я думал будет VMDK < vRDM < pRDM во всех случаях. Интересно чем обусловлены такие результаты.
ОтветитьУдалитьНу как чем - тем, что VMFS не дает потерь\накладных расходов при работе с малыми блоками - так она устроена. :)
ОтветитьУдалитьНу а тонкости устроения - вопрос закрытый :(
Насчет закрытости - скажи плз, а ведь используя GNU Linux, которая распространяется по GPL, VMware необходимо выложить сырци как минимум и лицензироваться как GPL как максимум. Прокомментируйте плз что знаете по этому поводу. Думаю даже удобно будет наверное новым постом в блог. Спасибо.
ОтветитьУдалитьНичего не знаю по этому поводу.
ОтветитьУдалитьmindprovider: Тут непонимание. Это так, если продукт использует внутри своего кода какой-то GPL-код. Если же он использует программный продукт "как есть", даже в составе решения, то ничего никому не должен. ESX использует Linux как хост-систему, для запуска своего гипервизора, и только, он не использует программный код, и, значит, ничего GPL-ю не должен.
ОтветитьУдалитьПодтверждаю последний пост romx-а
ОтветитьУдалить