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 можно использовать везде.
