Rdm vmware что это

Обновлено: 05.07.2024

Четвертая часть полностью посвящена моментам работы ESXi с дисковой подсистемой и СХД.

VMware vStorage APIs for Array Integration (VAAI)

Как уже говорилось в первой части, рекомендуется использовать дисковые хранилища с поддержкой VAAI. Данные возможности СХД позволяют перенести нагрузку с гипервизора на хранилище, улучшая в некоторых ситуациях производительность.

Если SAN, либо NAS массив поддерживает VAAI, ESXi автоматически это определит и начнет использовать предоставленные возможности.

LUN Access Methods

Помимо классической файловой системы VMFS поверх луна, ESXi также поддерживает технологию raw device mapping (RDM), позволяющую подключать лун напрямую в виртуальную машину. Зачастую RDM может использоваться в кластерных системах.

RDM – файл на VMFS, который выступает как прокси для нижележащего блочного устройства (луна).

RDM может работать в двух режимах – virtual compatibility, либо physical compatibility:

  1. Virtual Mode – функции взаимодействия с диском виртуализируются по аналогии с любым диском, располагаемым на VMFS. Данный режим, например, позволяет создавать снапшоты дисков RDM;
  2. Physical mode – минимизирует функции виртуализации и взаимодействия с диском, перекладывая данные функции на виртуальную машину. Снапошты создавать нельзя.

Virtual Disk Modes

Для каждого диска виртуальной машины ESXi поддерживает три режима:

Стоит понимать, что использование Independent дисков не отключает возможность создания снапшотов с виртуальной машины, однако с данного типа дисков снимки делаться не будут.

Virtual Disk Types

ESXi поддерживает два основных типа дисков – Thick Provisioned и Thin Provisioned.

Thick Provisioned – тип виртуального диска, который сразу резервирует дисковое пространство на хранилище VMFS. Подразделяется на два типа:

  1. Eagerzeroed – при создании виртуального диска, полностью его «зануляет». Увеличивает производительность при первой записи в каждый предварительной зануленный блок, но увеличивает время создания диска (чем больше диск – тем больше время, соответственно). VAAI может ускорить процесс создания таких дисков.
  2. Lazyzeroed – так же резервирует пространство под виртуальный жесткий диск, но зануление блоков происходит только в момент первой записи в них. Диск создается практически моментально, однако, при первой записи будет немного снижена производительность. При последующих записях обладает такой же производительностью, как и eager zeroed диски;
  3. Thinprovisioned – В отличии от Thick provisioned дисков, которые сразу резервируют требуемое пространство на VMFS, пространство под тонкие диски выделяется при записи. Производительность при первой записи в новый блок будет ниже, однако при последующих записях в ранее записанные блоки производительность аналогична eager-zeroed дискам.

Automatic Space Reclamation (UNMAP)

Хранилища VMFS6 (начиная с версии vSphere 6.5) поддерживают автоматическое высвобождение освободившегося пространства для thin provisioned дисков.

Стоит отметить, что VMFS5 так же поддерживает UNMAP, правда только в ручном режиме с помощью esxcli storage vmfs unmap.

Partition Alignment

Выравнивание файловой системы относительно блочного устройства, на котором она располагается, может влиять на производительность, поскольку при неверно выровненной файловой системе, количество операций чтения и записи может увеличиться.

Как и многие другие файловые системы, VMFS может испытывать проблемы с производительностью в случае неправильного выравнивания (misalignment). Начиная с ESXi 5.0 при создании файловой системы через клиента vSphere, VMFS3/5/6 автоматически выравниваются, начиная от границы в 1MB;

Если файловая система VMFS3 создана на более ранней версии гипервизора, чем ESXi5, выравнивание такой FS начинается от границы в 64KB. В случае если файловая система будет обновлена до VMFS5, выравнивание в 64KB так же сохраняется. Единственным решением является пересоздание файловой системы с гипервизора с версией 5 или выше.

Файловые системы VMFS3 и VMFS5 нельзя обновить до VMFS6. Единственный вариант – создание нового datastore на базе VMFS6 и перенос виртуальных машин на него.

Для того, чтобы выровнять VMFS разделы вручную, рекомендуется ознакомиться с документацией производителя СХД, с которой выделяется LUN (в большинстве случаев на выравнивание влияет тип ОС, указанный при создании луна на СХД), ну и, конечно, на рабочей файловой системе такое не делается.

Если выясняется, что с выравниванием не все в порядке, правильным решение будет создать новое, уже выравненное хранилище VMFS и выполнить Storage vMotion виртуальных машин на него.

SAN Multipathing

Поскольку практически во всех инсталляциях доступ к СХД осуществляется по нескольким путям (через несколько портов HBA и несколько свитчей (в SAN это называется фабрикой)), необходимо использовать специальное ПО, управляющие всеми путями и определяющие использование путей до СХД (Multipathing software). В ESXi за это отвечает PSA – Pluggable Storage Architecture.

Политики мультипасинга могут влиять на производительность дисковой подсистемы. В большинстве случаев, политика, выставленная ESXi по умолчанию для СХД будет лучшим выбором.

Если выбрана иная политика, рекомендуется свериться с документацией производителя системы хранения данных и убедиться, что она поддерживаема.

Round Robin – политика, позволяющая в некоторых ситуациях улучшить производительность за счет балансировки нагрузки между активными путями, ведущими к СХД, отправляя фиксированное количество I/O запросов на каждый из путей. Не все массивы поддерживают политику Round Robin. Использование неподдерживаемой политики может привести к проблемам с доступом к предоставленным дисковым ресурсам. Рекомендуется обратиться к документации производителя СХД, чтобы получить список поддерживаемых политика.

ALUA (Asymmetric Logical Unit Access) – использование данной политики позволяет увеличить производительность при работе с СХД, которая, собественно, поддерживает ALUA. ALUA информирует ESXi об оптимальных путях до луна (Active Optimized), а так же дополнительных, не оптимальных путях (Active Non-Optimized). В сочетании с Round Robin, ESXi балансирует запросы к СХД между оптимальными путями.

ESXi так же поддерживает сторонние плагины (PSPs), которые могут предоставить наилучшую производительность для конкретных типов хранилищ (обычно поставляются производителем СХД).

Storage I/O Resource Allocation

VMware предоставляет механизмы для динамического управления дисковым вводом-выводом, позволяя критически важным приложениям сохранять их производительность даже во время нехватки ресурсов.

Дисковый ввод-вывод доступный ESXi можно разграничить с помощью Shares, либо Limits:

  1. Часть ввода вывода виртуальных дисков можно разграничить с помощью Shares. В таком случае, каждый виртуальный диск будет иметь часть пропускной способности к хранилищу, в зависимости от выставленной величины Shares;
  2. Максимальное количество I/O доступных виртуальному диску можно ограничить с помощью Limits. Limits выставляются в количестве IOPS. По умолчанию количество IOPS не ограничивается.

Limits и Shares выставляются на уровне виртуального диска в настройках машины.

iSCSI and NFS Recommendations

  1. Если возможно, стоит использовать выделенные сетевые подключения для iSCSI и NFS между сервером и СХД (еще лучше отдельные коммутаторы). Если выделенной сети нет и не предвидится, стоит отделить дисковый трафик хотя бы с помощью VLAN.;
  2. Рекомендованная скорость подключения 10Gb/s и выше. В случае с NFS агрегация сетевых интерфейсов может предоставить большую пропускную способность;
  3. Если возможно – стоит использовать Jumbo frames (MTU 9000).

NVMe/NVMe-oF Recommendations

  1. Для максимальной производительность рекомендуется включить high-performance plug-in (HPP) на хосте ESXi;
  2. Увеличить максимальное количество I/O с параметром Disk.SchedNumReqOutstanding;
  3. Максимальная пропускная способность NVMe может быть достигнута с запуском большого количества виртуальных дисков, либо виртуальных машин, поскольку в NVMe хорошо развит параллелизм;
  4. Необходимо выбирать корректны storage adapter в виртуальной машине. Это может быть, как PVSCSI, так и vNMVe.

vSphere Virtual Machine Encryption Recommendations

Начиная с версии 6.5 vSphere может шифровать виртуальные диски .vmdk, файлы снапшотов .vmsn, NVRAM .nvram, swap .vswp и конфигурационные файлы .vmx.

Шифрация и дешифрация выполняется центральным процессором и, соответственно, потребляет его ресурсы.

  1. При достаточном количестве процессорных ресурсов, в большинстве случаев потеря производительности крайне незначительная. Однако, в случае нехватки ресурсов ЦПУ, могут начаться проблемы с производительностью;
  2. Для минимизации потребления CPU, рекомендуется выбирать процессоры, которые поддерживают инструкции AES-NI;
  3. Необходимо убедиться, что AES-NI в состоянии Enabled в BIOS. Иногда, для этого необходимо обновить версию BIOS;
  4. Поскольку шифрование выполняется непосредственно хостом и СХД видит только зашифрованные данные, это может сказаться на таких показателях как дедупликация и компрессия.

General ESXi Storage Recommendations

Running Storage Latency Sensitive Workloads

С самого начала подсистема дискового ввода-вывода в ESXi сконфигурирована для получения максимальной пропускной способности с минимальными затратами процессорных ресурсов.

Для приложений, чувствительных к дисковым задержкам следует рассмотреть и сконфигурировать следующие моменты:

  1. Host Power Management может влиять на значения Latency дискового ввода-вывода, ввиду чего рекомендуется возможно переключить политику в режим «Maximum Performance», либо отключить Power Management в BIOS. Отключить C1E и прочие C-states в BIOS. Включить Turbo Boost в BIOS;
  2. Если в виртуальной машине используется контроллер LSILogic, либо PVSCSI, можно отрегулировать параметр reqCallThreshold. Данный параметр влияет на скорость прохождения дисковых запросов виртуальной машины, однако может увеличить потребление ресурсов CPU.

На этом часть, посвященная работе с дисковой подсистемой, подходит к концу. В следующей части посмотри более внимательно на работу сетевой подсистемы.

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

RDM - это альтернатива VMFS. В случае хранилища VMFS мы создаем на диске/LUN раздел, форматируем его в VMFS и храним там файлы ВМ. Обычно - многих ВМ на одном VMFS. Однако мы можем какой-то LUN выделить напрямую одной ВМ. И даже не одной, например для диска с данными кластера Майкрософт может и должен использоваться как раз RDM, подключенный к двум виртуальным машинам сразу.

При таком подключении LUN гипервизор будет пропускать SCSI команды гостевой ОС прямо на него. Таким образом, на LUN, подключенном как RDM, будет создана файловая система гостевой ОС (NTFS, к примеру).

При создании RDM создается файл vmdk, который выполняет роль ссылки для открытия, - фактически же чтение и запись идут на сам LUN. См. рис. 3.30.

Размер этого файла vmdk отображается равным объему RDM LUN (объему LUN 14 в моем примере), однако на самом деле он занимает 1-8 Мб (в зависимости от размера блока VMFS).

Иллюстрация подключения RDM Источник: VMware

Рис. 3.30. Иллюстрация подключения RDM Источник: VMware

RDM вам интересен в случае, если:

- происходит миграция физической инфраструктуры на виртуальную. Переносимый физический сервер использует LUN для хранения своих данных. Мы можем не копировать данные с этого LUN внутрь файла vmdk на каком-то VMFS, а прямо этот LUN подключить к перенесенному в ВМ серверу как RDM;

- вы хотите поднять кластер Майкрософт с переходом по отказу (MSCS/ MFC), хотя бы одним из узлов которого будет ВМ. В таком случае кворум-ным диском и диском с общими данными должен выступать RDM;

- вы хотите использовать механизм снапшотов или какие-то другие функции на уровне системы хранения для данных виртуальных машин. Например, мы можем средствами системы хранения создать снапшот LUN и этот снапшот подключить к серверу резервного копирования. В случае VMFS + vmdk такая схема, скорее всего, не заработает, потому что сервер резервного копирования не сможет забрать данные с проприетарной файловой системы VMFS. А если этот LUN подключен как RDM к виртуальной машине, то файловую систему на нем создает гостевая ОС, и эта файловая система может быть знакома серверу резервного копирования;

- из политических соображений - хранение каких-то данных в проприетарном формате (VMFS + vmdk) противоречит корпоративным политикам или предписаниям регулирующих органов.

Однако использование RDM не дает заметных изменений в скорости работы с дисковой подсистемой. По данным VMware, разница в скорости доступа к одному и тому же LUN как к RDM или к файлу vmdk на нем различается на проценты, и иногда VMFS + vmdk даже быстрее.

Чтобы добавить RDM к ВМ:

- зайдите в свойства виртуальной машины, на закладе Hardware нажмите Add. Вам нужно добавить Hard Disk;

- Device Type - выберите Raw Device Mapping;

- Select a Disk - выберите LUN из списка. В этом списке только те LUN, на которых нет VMFS. Важно! Среди них могут быть уже задействованные как RDM с другими ВМ, обращайте внимание на адреса и номера LUN во избежание ошибок и потери данных;

- Select Datastore - здесь вы выбираете, на каком хранилище VMFS будет располагаться файл виртуального диска (vmdk), являющийся ссылкой на этот LUN. Скорее всего, вариант по умолчанию вас устроит;

- Compatibility Mode - тип RDM-подключения, о нем чуть ниже;

- Advanced Options - здесь мы, как и для файлов виртуальных дисков, указываем адрес SCSI добавляемого диска с точки зрения ВМ. SCSI (0:1) означает, что диск будет подключен на первый SCSI ID контроллера 0. А если мы выберем SCSI (1:0), то диск будет подключен как ID 0 контроллера 1. В частности, второй вариант означает, что в ВМ будет добавлен и второй контроллер SCSI - это часто нам надо для MSCS/MFC (первый SCSI-контроллер с номером 0 обычно уже существует, если добавляемый RDM - не первый диск этой ВМ). Если RDM Virtual, то мы можем поставить флажок Independent. Если он стоит, то к этому диску ВМ не будут создаваться снимки состояния (snapshot). Дополнительные настройки в режиме Independent:

• Persistent означает монолитный диск, к которому не применяются снимки состояния (snapshot). Все изменения сразу пишутся на диск;

• Nonpersistent означает, что при включении ВМ именно для этого ее диска создается файл дельты, в который записываются все изменения. После выключения ВМ эта дельта отбрасывается. То есть диск в режиме nonpersistent автоматически возвращается в исходное состояние после выключения ВМ.

RDM бывает двух типов:

- Physical означает, что гипервизор подавляющее большинство команд SCSI пропускает до LUN без изменений;

- Virtual разрешает перехватывать и изменять команды SCSI.

С точки зрения использования, Virtual RDM не препятствует снятию снимков состояния (средствами ESX(i)) и позволяет клонировать и создавать шаблон из ВМ. То есть позволяет RDM LUN использовать так же, как файл виртуального диска. Физические характеристики диска (LUN) будут скрыты.

Physical RDM дает прямой доступ к LUN. Пригодится для кластера MSCS/ MFC в варианте cluster-across-boxes и physical-to-virtual. Однако если внутри ВМ у вас будет ПО, которому требуются прямой доступ на диск и работа с физическими характеристиками системы хранения, physical RDM - ваш выбор.

Выбирайте Virtual, если задача, под которую создается RDM, явно не требует использования physical RDM.

Если к ВМ подключен RDM, то с ней можно осуществлять большинство операций типа VMotion, Storage VMotion и др. Также для VMotion необходимо, чтобы отдаваемый как RDM LUN был виден всем серверам (виден с точки зрения zoning и masking).

Невозможно как RDM подключить раздел - только LUN целиком.

Управлять путями к RDM LUN можно точно так же, как к LUN с VMFS. Только доступ к этим настройкам осуществляется из другого места - зайдите в свойства ВМ, выделите ее диск RDM и нажмите кнопку Manage Path.

Иногда ESX(i) не позволяет подключить LUN как RDM. Обычно это происходит, когда LUN подключен к локальному контроллеру. Тогда может выручить командная строка

vmkfstools -r /vmfs/devices/disks/naa.5xxxxxxxxxxx VM1_rdm.vmdk

С помощью этой команды вы создадите файл-vmdk с именем VM1_rdm. vmdk, который будет являться ссылкой на LUN/диск с идентификатором naa.5xxxxxxxxxxx. Затем следует подключить этот файл-vmdk к виртуальной машине через Add HDD ^ Use Existing vmdk.

Обратите внимание. Подключенный к виртуальной машине RDM LUN не является препятствием для VMotion. Однако если у виртуальной машины по умолчанию изменено значение настройки SCSI Bus Sharing (это настройка виртуального контроллера SCSI), то тогда VMotion для нее будет невозможен. RDM LUN подключается к контроллеру SCSI с таким значением настройки SCSI Bus Sharing, если виртуальная машина является узлом кластера Майкрософт и узлы этого кластера запущены на разных физических серверах.

NPIV - это стандарт, описывающий, как один порт FC HBA может регистрировать несколько WWN на коммутаторах FC. ESX(i) поддерживает NPIV, что означает возможность сгенерировать для каждой ВМ уникальный WWN.

Теоретически эта функция пригодится нам для:

- анализа нагрузки на SAN со стороны отдельной ВМ, чтобы отделить трафик одной ВМ от всего остального по ее уникальному WWN;

- осуществления зонирования и презентования LUN для отдельных ВМ;

- предоставления определенного качества обслуживания для отдельных ВМ;

- улучшения производительности для отдельных виртуальных машин путем индивидуальной настройки кеширования на уровне СХД.

На практике же я вижу данную функцию малоиспользуемой. Причин тому несколько:

- уникальным WWN помечается только трафик к RDM LUN, который так и так презентован одной (за исключением кластерных конфигураций) ВМ;

- эти LUN все равно должны быть доступны (с точки зрения зонирования и презентования) каждому серверу ESX(i), где использующая LUN виртуальная машина может оказаться;

- для представления оговоренного качества обслуживания появилась эффективная и простая в использовании функция SIOC (доступна не для всех лицензий vSphere);

- для виртуальной машины от включения NPIV не меняется ничего. Как ВМ работала с локальным SCSI-контроллером, так и продолжает. NPIV - это указание гипервизору, какой WWN подставлять в соответствующие обращения на СХД.

Однако два применения NPIV мне кажутся более оправданными:

- если SIOC мы не можем использовать (например потому что наша лицензия этого не позволяет), то некоторые FC HBA позволят нам указать приоритет для трафика с тем или иным WWN. Таким образом, мы можем приоритезировать трафик некоторых виртуальных машин;

- если мы используем RDM, то без настроенного NPIV для ВМ с RDM нам сложно массово сопоставить виртуальные машины и прокинутые как RDM LUN с СХД.

Чтобы ESX(i) позволил настраивать NPIV для виртуальных машин, необходимо, чтобы HBA и коммутаторы FC поддерживали NPIV.

Сама настройка осуществляется в свойствах конкретной ВМ, на вкладке Options (рис. 3.31). Если для ВМ не указан свой уникальный WWN, ее обращения к RDM LUN исходят от WWN сервера.

Настройка NPIV

Рис. 3.31. Настройка NPIV

ВМ с включенным NPIV можно мигрировать с помощью VMotion, но нельзя с помощью Storage VMotion.

Есть еще некоторые мелкие нюансы, но их имеет смысл уточнять уже в документе Fibre Channel SAN Configuration Guide.

Raw Disk Mapping (RDM) можно использовать для подачи «сырого», настоящего LUN непосредственно с SAN в виртуальную машину. Этим часто можно добиться повышения производительности системы виртуализации, эта технология зачастую применяется в приложениях, генерирующих интенсивный дисковый ввод/вывод, например это могут быть серверы баз данных.

Первый шаг при добавлении RDM в вашу виртуальную машину – презентация неиспользуемого LUN вашему ESX / ESXi серверу. Эта процедура специфична для каждой из технологии построения SAN и вендора используемого решения.

Для того, чтобы новый LUN стал доступен, необходимо обновить выполнить рескан на устройствах HBA (Rescan HBA) на всех серверах ESX.


Виртуальную машина, к которой нужно подключить RDM, должна быть выключена. RDM не может быть добавлен прямо на ходу, во время работы виртуалки.


Выберите добавленный недавно LUN и нажмите кнопку Далее.


В следующем окне вы можете указать хотите ли вы хранить линк RDM прямо рядом с файлами виртуальной машины (Store with virtual machine), или можете указать для этого линка конкретное хранилище. Затем нажмите кнопку Далее.




Подтвердите сделанные настройки и выберите Готово (finish).


В результате новый SCSI контроллер и жесткий диск будут добавлены в конфигурацию виртуальной машины. Теперь включите свою виртуалку. В зависимости от типа гостевой операционной системы вам придется обнаружить и смонтировать/отформатировать новый диск.

В данной статье хочу рассказать о том, как немного повысить производительность хоста ESXi с помощью SSD кэширования. На работе и дома я использую продукты от компании VMware, домашняя лаборатория построена на базе Free ESXi 6.5. На хосте запущены виртуальные машины как для домашней инфраструктуры, так и для тестирования некоторых рабочих проектов (как-то мне пришлось запустить на нем инфраструктуру VDI). Постепенно приложения толстых ВМ начали упираться в производительность дисковой системы, а на SDD все не помещалось. В качестве решения был выбран lvmcache. Логическая схема выглядит так:




Основой всей схемы является ВМ svm на базе CentOS 7. Ей презентованы HDD диски средствами RDM и небольшой диск VMDK с датастора SSD. Кэширование и зеркалирование данных реализуются программными средствами — mdadm и lvmcache. Дисковое пространство ВМ монтируется к хосту как NFS датастор. Часть датастора SSD отведена ВМ, которым требуется производительная дисковая подсистема.

Вычислительный узел собран на десктопном железе:

MB: Gygabyte GA-Z68MX-UD2H-B3 (rev. 1.0)
HDD: 2 x Seagate Barracuda 750Gb, 7200 rpm
SSH: OCZ Vertex 3 240Gb

На материнской плате имеется 2 RAID контроллера:

— Intel Z68 SATA Controller
— Marvell 88SE9172 SATA Controller

Завести 88SE9172 в ESXi у меня не получилось (There is a bug in the firmware of some Marvell adapters (at least 88SE91xx)), решил оставить оба контроллера в режиме ACHI.

Технология RDM (Raw Device Mapping) позволяет виртуальной машине обращаться напрямую к физическому накопителю. Связь обеспечивается через специальные файлы «mapping file» на отдельном томе VMFS. RDM использует два режима совместимости:

— Виртуальный режим — работает так же, как и в случае с файлом виртуального диска, позволяет использовать преимущества виртуального диска в VMFS (механизм блокировки файлов, мгновенные снэпшоты);
— Физический режим — предоставляет прямой доступ к устройству для приложений, которые требуют более низкого уровня управления.

В виртуальном режиме на физическое устройство отправляются операции чтения\записи. RDM устройство представлено в гостевой ОС как файл виртуального диска, аппаратные характеристики скрыты.

В физическом режиме на устройство передаются практически все команды SCSI, в гостевой ОС устройство представлено как реальное.

Подключив дисковые накопители к ВМ средствами RDM, можно избавиться от прослойки VMFS, а в физическом режиме совместимости их состояние можно будет мониторить в ВМ (с помощью технологии S.M.A.R.T.). К тому же, если что-то случится с хостом, то получить доступ к ВМ можно, примонтировав HDD к рабочей системе.

lvmcache


lvmcache обеспечивает прозрачное кэширование данных медленных устройств HDD на быстрых устройствах SSD. LVM cache размещает наиболее часто используемые блоки на быстром устройстве. Включение и выключение кэширования можно производить, не прерывая работы.

При попытке чтения данных выясняется, имеются ли эти данные в кэше. Если требуемых данных там нет, то чтение происходит с HDD, и попутно данные записываются в кэш (cache miss). Дальнейшее чтение данных будет происходить из кэша (cache hit).

Запись

— Режим write-through — когда происходит операция записи, данные записываются и в кэш, и на HDD диск, более безопасный вариант, вероятность потери данных при аварии мала;
— Режим write-back — когда происходит операция записи, данные записываются сначала в кэш, после чего сбрасываются на диск, имеется вероятность потери данных при аварии. (Более быстрый вариант, т.к. сигнал о завершении операции записи передается управляющей ОС после получения данных кэшем).

Так выглядит сброс данных из кэша (write-back) на диски:


Настройка системы

На хосте создается SSD датастор. Я выбрал такую схему использования доступного пространства:

220Gb — DATASTORE_SSD
149Gb — Отведено для особых ВМ
61Gb — Том для кэша и метаданных
10Gb — Host Swap Cache

Виртуальная сеть выглядит следующим образом:


Создан новый vSwitch:

Networking → Virtual Switches → Add standart virtual switch — указываем желаемое имя виртуального свитча (svm_vSwitch, в названиях я использую префикс svm_), остальное оставляем как есть.

К нему через порт группу подключается VMkernel NIC:

Networking → VMkernel NICs → Add VMkernel NIC
— Port group — New Port group
— New port group — Имя порт группы — svm_PG
— Virtual switch — svm_vSwitch
— IPv4 settings — Configuration — Static — указываем IP и маску сети

Создана порт группа, к которой будет подключена ВМ svm:

Networking → Port Groups → Add port group — указываем имя (svm_Network) и свитч svm_vSwitch

Подготовка дисков

Необходимо зайти на хост по ssh и выполнить следующие команды:

Подготовка ВМ

Теперь эти диски можно подключить (Existing hard disk) к новой ВМ. Шаблон CentOS 7, 1vCPU, 1024Gb RAM, 2 RDM disk, 61Gb ssd disk, 2 vNIC (порт группы VM Network, svm_Network) – во время установки ОС используем Device Type – LVM, RAID Level — RAID1

Настройка NFS сервера довольно проста:


Подготавливаем тома кэша и метаданных для включения кэширования тома cl_svm/data:


Уведомления о изменении состояния массива:

Чтобы изменения вступили в силу, нужно перезапустить службу mdmonitor:


Почта с ВМ отправляется средствами ssmtp. Так как я использую RDM в режиме виртуальной совместимости, то проверять состояние дисков будет сам хост.

Подготовка хоста

Добавляем NFS датастор в ESXi:

Настройка автозапуска ВМ:

Host → Manage → System → Autostart → Edit Settings
Enabled — Yes
Start delay — 180sec
Stop delay — 120sec
Stop action — Shut down
Wait for heartbeat — No

Virtual Machines → svm → Autostart → Increase Priority
(Автозапуск не сработал, пришлось удалить ВМ из Inventory и добавить заново)

Данная политика позволит ВМ svm запуститься первой, гипервизор примонтирует NFS датастор, после этого будут включаться остальные машины. Выключение происходит в обратном порядке. Время задержки запуска ВМ подобрано по итогам краш-теста, т. к. при малом значении Start delay NFS датастор не успевал примонтироваться, и хост пытался запустить ВМ, которые еще недоступны. Также можно поиграться параметром NFS.HeartbeatFrequency .

Более гибко автостарт ВМ можно настроить с помощью командной строки:


Небольшая оптимизация

Включить Jumbo Frames на хосте:

Jumbo Frames: Networking → Virtual Switches → svm_vSwitch указать MTU 9000;
Networking → Vmkernel NICs → vmk1 указать MTU 9000

В Advanced Settings установить следующие значения:

NFS.HeartbeatFrequency = 12
NFS.HeartbeatTimeout = 5
NFS.HeartbeatMaxFailures = 10
Net.TcpipHeapSize = 32 (было 0)
Net.TcpipHeapMax = 512
NFS.MaxVolumes = 256
NFS.MaxQueueDepth = 64 (было 4294967295)

Включить Jumbo Frames на ВМ svm:

Производительность

Производительность измерялась синтетическим тестом (для сравнения, я снял показания с кластера на работе (в ночное время)).

Используемое ПО на тестовой ВМ:

— ОС CentOS 7.3.1611 (8 vCPU, 12Gb vRAM, 100Gb vHDD)
— fio v2.2.8


Полученные результаты представлены в таблицах (* во время тестов отмечал среднюю загрузку ЦП на ВМ svm):

VMFS6 Datastore
Тип диска FIO depth 1 (iops) FIO depth 24 (iops)
randread randwrite randread randwrite
HDD 77 99 169 100
SSD 5639 17039 40868 53670

NFS Datastore
SSD Cache FIO depth 1 (iops) FIO depth 24 (iops) CPU/Ready* %
randread randwrite randread randwrite
Off 103 97 279 102 2.7/0.15
On 1390 722 6474 576 15/0.1

Рабочий кластер
Тип диска FIO depth 1 (iops) FIO depth 24 (iops)
randread randwrite randread randwrite
900Gb 10k (6D+2P) 122 1085 2114 1107
4Tb 7.2k (8D+2P) 68 489 1643 480

Результаты, которые можно потрогать руками, получились при одновременном запуске пяти ВМ с Windows 7 и офисным пакетом (MS Office 2013 Pro + Visio + Project) в автозагрузке. По мере нагревания кэша, ВМ грузились быстрее, при этом HDD практически не участвовал в загрузке. При каждом запуске отмечал время полной загрузки одной из пяти ВМ и полной загрузки всех ВМ.
Одновременный запуск пяти ВМ
Datastore Первый запуск Второй запуск Третий запуск
Время загрузки первой ВМ Время загрузки всех ВМ Время загрузки первой ВМ Время загрузки всех ВМ Время загрузки первой ВМ Время загрузки всех ВМ
1 HDD VMFS6 4мин. 8сек. 6мин. 28сек. 3мин. 56сек. 6мин. 23сек. 3мин. 40сек. 5мин. 50сек.
2 NFS (SSD Cache Off) 2мин. 20сек. 3мин. 2сек. 2мин. 34сек. 3мин. 2сек. 2мин. 34сек. 2мин. 57сек.
3 NFS (SSD Cache On) 2мин. 33сек. 2мин. 50сек. 1мин. 23сек. 1мин. 51сек. 1мин. 0сек. 1мин. 13сек.

Время загрузки одиночной ВМ составило:

— HDD VMFS6 - 50 секунд
— NFS с выключенным кэшем - 35 секунд
— NFS с включенным и нагретым кэшем - 26 секунд


Краш-тест

Отключение питания

После включения и загрузки хоста ВМ svm загрузилась с проверкой ФС (данные остались в кэше), на хосте примонтировался NFS датастор, далее загрузились остальные ВМ, проблем и потери данных не наблюдалось.

Выход из строя HDD (имитация)

Решил отключить питание SATA диска. К сожалению, горячая замена не поддерживается, необходимо аварийно выключать хост. Сразу после отключения диска появляется информация в Events.


Неприятным моментом оказалось, что при потере диска гипервизор просит для ВМ svm ответить на вопрос — «You may be able to hot remove this virtual device from the virtual machine and continue after clicking Retry. Click Cancel to terminate this session» — машина находится в состоянии фриза.

Если представить, что с диском была временная, незначительная проблема (например, причина в шлейфе), то после устранения проблемы и включения хоста все загружается в штатном режиме.

Выход из строя SSD

Наиболее неприятная ситуация — выход ssd из строя. Доступ к данным осуществляется в аварийном режиме. При замене ssd необходимо повторить процедуру настройки системы.

Обслуживание (Замена диска)

Если с диском вот-вот случится беда (по результатам S.M.A.R.T.), для того чтобы заменить его на рабочий необходимо выполнить следующую процедуру (на ВМ svm):


В настройках ВМ нужно «оторвать» погибающий vHDD, затем заменить HDD на новый.
После чего подготовить RDM накопитель и добавить к ВМ svm:

Аварийный доступ к данным

Один из дисков подключается к рабочей станции, далее необходимо «собрать» RAID, отключить кэш и получить доступ к данным, примонтировав LVM том:


Также я пробовал загрузить систему непосредственно с диска, настроил сеть и на другом хосте подключил NFS датастор — ВМ доступны.


Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type. dozentmi
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Коллеги, подскажите пожалуйста с выбором типа дисков для файлового хранилища и MS Exchange.

Поставлена задача создать виртуальный файловый сервер и MS Exchange на Windows Server 2008 на ESXi 4.1.

Имеется хранилище MSA2324sa, 10 дисков SAS. Возник вопрос производительности дисковой системы: какая производительность будет лучше, VMDK или RDM?

FondRGS
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Пользователей у Exch сколько?

michigun
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend
dozentmi
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Пользователей чуть больше 100.. И еще вопрос, нужно ли разделять диски для MS Exchange и для файлового сервера?

FondRGS
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

>Пользователей чуть больше 100..

Даже не заморачивайтесь с RDM.

>И еще вопрос, нужно ли разделять диски для MS Exchange и для файлового сервера?

Встречный вопрос: MSA-йка к скольким серверам подключена?

dozentmi
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Будет подключена к 2 серверам. Я так понимаю необходимо будет создать три LUN'a: один на почтовый сервер, второй на файловый, третий на остальные сервисы. Тогда тут возникает еще один вопрос: на каком RAID это создавать?

FondRGS
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

>Будет подключена к 2 серверам

Вот и создай два луна. Один - первому, второй второму : )

>тут возникает еще один вопрос: на каком RAID это создавать?

На пятом и не заморачивайся. Доверь хоть контрольные суммы эмэсайке считать. А то купить дорогую железку и не пользоваться - грех.

Главное, не читать рекомендации MS по расположению Exch. У тебя всего 150 пользователей,

Umlyaut
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Михаил, из этой ссылки следует, что

HDD -> Raw LUN physical. В этом варианте vmkernel перехватывает\обрабатывает одну единственную SCSI команду от гостевой ОС к диску.

RDM может делаться в двух вариантах - "physical" и "virtual". pRDM и vRDM.

>Отличаются они тем, что в первом случае гипервизор НЕ перехватывает и НЕ обрабатывает SCSI команды от ВМ к диску.

Поскольку Вы имеете касательство и ко второму источнику, то хотелось бы получить Ваш комментарий - чему, всё-таки, верить.

ЗЫ: мне почему-то кажется, что вторая цЫтата более должна правильно отражать суть дела. Иными словами, VM`ка со iSCSI-инициатором, работающая на хосте Сферы без включенного iSCSI/vkernel, всё равно сможет получить в своё распоряжение LUN с iSCSI-таргета - в этом случае будет осуществляться "прозрачный" проброс iSCSI-команд по IP-сети (так как это было бы между физическими таргетом и инициатором). В ближайшее время могу попробовать смоделировать ситуацию на запасном хосте.

michigun
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

первую цитату следует читать как "..в случае pRDM гипервизор перехватывает единственную команду..", тогда как в случае vRDM - много больше.

ну и проекция этого на прикладной уровень:

для vRDM работают снапшоты (дельта создается на vmfs в каталоге ВМ), и клонирование. И миграция - упаси вас бог при миграции хранилища ВМ с vRDM поменять тип диска (шаг мастера миграции) - тогда vRDM будет перенесен в vmdk соответствующего типа. Разумеется, когда-то это может быть фича, но если вы не ожидаете такого поведения - это больше похоже на неприятный сюрприз.

Так же, при pRDM ВМ вроде как должна видеть честные аппаратные характеристики LUN\диска - правда я толком не знаю зачем это может понадобиться.

Umlyaut
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Email to a Friend

Михаил, Вам опять не спится по ночам. :smileygrin:

первую цитату следует читать как "..в случае pRDM гипервизор перехватывает единственную команду..", тогда как в случае vRDM - много больше.

Стоп-стоп! Что такое "первая цитата"? Первый процитированный мною источник - vm4.ru? Дык там и так так и написано. А вот в wiki.vm4.ru (второй процитированный источник) нет никаких изъятий - "Не перехватывает и не обрабатывает. ". Согласно правилам русского языка и логики вторая цитата ни о какой "единственной команде" не говорит. Определитесь, пожалуйста.

ну и проекция этого на прикладной уровень:

для vRDM работают снапшоты (дельта создается на vmfs в каталоге ВМ), и клонирование. И миграция - упаси вас бог при миграции хранилища ВМ с vRDM поменять тип диска (шаг мастера миграции) - тогда vRDM будет перенесен в vmdk соответствующего типа. Разумеется, когда это может быть фича, но если вы не ожидаете такого поведения - это больше похоже на неприятный сюрприз.

Спасибо за советы "прикладного уровня".

Правда, я не фанат снапшотов и клонирования. С миграцией же (и хранилищами) я буду разбираться совсем отдельно (тут "разбираться" значит "строить схему для конкретных условий эксплуатации").

Так же, при pRDM ВМ вроде как должна видеть честные аппаратные характеристики LUN\диска - правда я толком не знаю зачем это может понадобиться.

Я пока тоже не знаю. Однако в общем и целом солидарен с теми, кто ценит RDM за отсутствие "матрёшечной" капсуляции: LUN -> VMFS -> VMDK -> OS FS. В отсутствие нормальной утвари для починки "в случае чего" VMFS и VMDK хочется "быть поближе" к своим данным.

//Дисклаймер: да, быкапы - наше фсьо! Однако нет гарантии, что не занадобится вытащить данные, попавшие в "матрёшку" между быкапами. //

UPD: И всё-таки, Михаил: с точки зрения "обработки единственной scsi-команды" vkernel`ом при pRDM на VM`ку - уже ль iscsi невозможен при отсутствии на хосте vkernel?

Читайте также: