vKernel прислал ссылку на документ, развенчивающий четыре мифа о vSphere:
– о том, что RDM быстрее, чем VMFS;
– о том, что Change Block Tracking тормозит виртуальные машины;
– о том, что Resource Pool спасет ваши виртуальные машины от нехватки ресурсов;
– и о том, что LSI Logic SCSI лучше, чем PVSCSI.
RDM vs VMFS
Корни предположения о том, что RDM быстрее, основаны на простом факте: VMFS предоставляет собой еще один слой инкапсуляции данных. Но так как VMFS при этом “практически” не осуществляет дополнительных операций, VMware удалось достичь практически такой же производительности, как у physical RDM. Конечно, тут есть свои подводные камни вроде SCSI Reservations/Conflicts и их решение в виде VAAI&ATS. Но в целом, толстый_обнуленный (eagerzeroed) VMDK выдает столько же операций ввода вывода, что и RDM.
Основные причины предпочесть RDM (physical) – это:
– использование функционала СХД при работе с данными (снапшоты, репликация);
– желание использовать более двух терабайт на дисковое устройство (в vSphere 5);
– ограничения виртуализуемого приложения, например, MS Cluster Services;
– нет небольшого перерасхода (overhead) на файловую систему VMFS.
Основные причины выбрать VMDK:
– Storage I/O Control;
– Storage DRS/Storage vMotion;
– поддержка Change Block Tracking;
– возможность использования снапшотов (снимков) виртуальных машин.
Медленный CBT
CBT – это специальный драйвер, который отслеживает изменения блоков диска виртуальной машины. Данная технология очень удобна для резервного копирования (в первую очередь инкрементального), так как позволяет более быстро находить изменившуюся информацию с момента последней резервной копии. Некоторые средства резервного копирования обещают использование CBT также и для восстановления виртуальной машины из резервной копии.
CBT требует выполнения следующих условий:
– версия хоста не ниже vSphere 4;
– версия виртуального оборудования ВМ не ниже v7 (седьмой версии);
– CBT должен быть “вручную” включен на виртуальной машине;
– CBT работает только поверх механизма VMKernel. Соответственно, он работает для VMFS, NFS и virtual RDM.
Автору статьи удалось выяснить, чем CBT нагружает виртуальную инфраструктуру:
– процессор переключает бит после выполнения операции ввода/вывода;
– в памяти занято 1,25КБ на каждые 10Гб места. Максимум, используется 256КБ для 2ТБ VMDK;
– на хранилище используется 512КБ для 10ГБ VMDK.
В общем, CBT не создает большой нагрузки.
Использование Resource Pool
С момента появления пулов ресурсов вы могли их использовать для категоризации вычислительных ресурсов. Дескать, вот 4ГГц для продуктивных ВМ и 2ГГц для тестовых.
Подводный камень тут следующий:
ВМ из третьего пула ресурсов при конкуренции смогут использовать не более 0,5ГГц.
Правда, решение есть: вы можете использовать резервирование ресурсов на пуле: например, зарезервировав по 10ГГц на продуктивные пулы ресурсов. В этом случае при необходимости продуктивные виртуальные машины смогут получить уже не 6ГГц, а 10.
С резервированием памяти на пул ресурсов все так же обстоит гораздо приятнее, чем с резервированием памяти на отдельную виртуальную машину:
– при резервировании памяти виртуальной машины, если память была затребована (а потом не использовалась), например, при старте MS Windows Server, то эта память недоступна другим виртуальным машинам;
– при резервировании памяти пулу ресурсов этот резерв может использоваться разными виртуальными машинами из пула.
LSI Logic SCSCI всегда лучше, чем PVSCSI
На чем основан данный миф я вообще не понимаю. VMware изначально добавляло PVSCSI для того, чтобы получить с его помощью лучшие результаты для тяжелых нагрузок. Причем эти результаты были лучше и с точки зрения количества IOPS, и с точки зрения “паразитной” нагрузки на процессор хоста.
В vSphere 4.0, когда адаптер появился, его не рекомендовали использовать для загрузочных томов и для томов со слабой нагрузкой. Вроде как генерировалась “паразитная” нагрузка то ли на процессор, то ли на СХД.
С тех пор много воды утекло и лет прошло. Данная проблема решена, PVSCSI можно использовать везде.