Если в случае с VMFS мы диск(LUN) форматируем в файловую систему VMFS, на ней помещаем файл .vmdk - и внутрь этого файла ВМ пишет данные своего HDD; то в случе RDM все проще - тот диск(LUN), который виден хосту, мы напрямую отдаем ВМ. Т.е. она сразу на этом диске(LUN) делает свою файловую систему(NTFS\ext3 или что там у нее), и располагает свои данные. Картинко: В зависимости от чего мы используем RDM или VMFS\vmdk:
Несколько нюансов: RDM может делаться в двух вариантах - "physical" и "virtual". pRDM и vRDM. Отличаются они тем, что в первом случае гипервизор не перехватывает и не обрабатывает SCSI команды от ВМ к диску. В следствии этого, pRDM немного быстрее. pRDM необходим для общих дисков в случае кластера типа MSCS. Но в режиме vRDM работаю снапшоты ESX, как следствие - VCB. VMotion, DRS, HA - работают и при vRDM и при pRDM. VCB работает только для vRDM - т.к. ему необходимы снапшоты, невозможные для pRDM. Если вы используете RDM - вас поджидает опасность. Заключается она в том, что если какой то LUN как RDM подключен к ВМ на ESX1, то ESX2,ESX3,..,ESXn воспринимают этот LUN как незадействованный, и позволяют его задействовать. Отформатировав в VMFS. Т.е., уничтожив все данные на нем. А спрятать этот LUN от прочих хостов нельзя, если нам нужны возможности VMotion, DRS, HA для этой ВМ. Есть такая штука, как NPIV. Поддержка N_Port ID Virtualization со стороны ESX 3.5 означает, что мы можем выдавать виртуальные WWN каждой ВМ. Благодаря ей можно отслеживать нагрузку на SAN со стороны индивидуально от каждой ВМ. Смысл она имеет как раз и только для RDM. Информация об NPIV - от Cisco, Emulex и VMware - "A Technology Overview for SAN Connectivity using NPIV in a VMware ESX Server 3.5 Environment" Просто так - VMDK, RDM - отличия по сути и по скорости. То, что я раньше писал в блоге на эту тему. |