воскресенье, 16 декабря 2007 г.

VMDK, RDM - отличия по сути и по скорости

Весьма и весьма часто всплывает вопрос - а какой из типов дисков для ВМ лучше?
Напомню, что эти три типа следующие:

  • 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"
По накладным расходам на CPU зависит от размера блока, но в любом случае меньше всего нагрузки в случае pRDM.

Вывод:
  • При случайном доступе VMFS и RDM похожи по производительности в I/O.
  • При последовательном доступе с малым размером блока RDM лучше. Правда, при увеличении размера блока разница сокращается вплоть до нуля.
  • При случайном доступе с небольшими блоками накладные расходы похожи, в других случаях RDM менее накладен.
В общем, документ из разряда маст хэв.

Отсюда.


6 комментариев:

  1. Странно, я думал будет VMDK < vRDM < pRDM во всех случаях. Интересно чем обусловлены такие результаты.

    ОтветитьУдалить
  2. Ну как чем - тем, что VMFS не дает потерь\накладных расходов при работе с малыми блоками - так она устроена. :)
    Ну а тонкости устроения - вопрос закрытый :(

    ОтветитьУдалить
  3. Насчет закрытости - скажи плз, а ведь используя GNU Linux, которая распространяется по GPL, VMware необходимо выложить сырци как минимум и лицензироваться как GPL как максимум. Прокомментируйте плз что знаете по этому поводу. Думаю даже удобно будет наверное новым постом в блог. Спасибо.

    ОтветитьУдалить
  4. Ничего не знаю по этому поводу.

    ОтветитьУдалить
  5. mindprovider: Тут непонимание. Это так, если продукт использует внутри своего кода какой-то GPL-код. Если же он использует программный продукт "как есть", даже в составе решения, то ничего никому не должен. ESX использует Linux как хост-систему, для запуска своего гипервизора, и только, он не использует программный код, и, значит, ничего GPL-ю не должен.

    ОтветитьУдалить
  6. Подтверждаю последний пост romx-а

    ОтветитьУдалить