Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.

Компания VMware провела тестирование работы баз данных Oracle в среде vSAN ESA и опубликовала некоторые результаты.

Тестовый стенд

Тестовая площадка представляла собой кластер из 8 узлов vSAN 8 Express Storage Architecture (ESA) со следующими настройками:

• Версия vCenter 8.0.2 сборка 22385739
• 8 серверов Lenovo ThinkAgile VX7531 Node, 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU @ 2.60GHz, 1TB RAM
• VMware ESXi 8.0.2, сборка 22380479 с vSAN ESA (все хранилища - NVMe)
• Oracle 21.13 Grid Infrastructure, ASM Storage и Linux udev (размер блока базы данных 8k)
• OEL UEK 8.9

Детали кластера vSAN Express Storage Architecture (ESA) "env175" показаны ниже. Кластер ESA состоит из 8 серверов Lenovo ThinkAgile VX7531, как показано на картинке:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU на частоте 2.60GHz и 1TB RAM:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 6 внутренних накопителей NVMe, таким образом каждый сервер дает 6 внутренних устройств NVMe в качестве емкости датастора vSAN ESA:

Информация о сервере ThinkAgile VX7531 "env175-node1.pse.lab" в части деталей HBA и внутренних устройств NVMe:

Политики хранения кластера vSAN Express Storage Architecture (ESA) показаны на картинке ниже.

Базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана только для получения эталонных метрик для сравнения, кроме того, настоящая производственная нагрузка никогда не настраивается с FTT=0 (количество допустимых отказов) и без RAID (то есть без защиты).

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

Детали виртуальной машины "Oracle21C-OL8-DB_ESA" показаны на картинке ниже.

Виртуальная машина имеет 28 vCPU, 256 ГБ RAM. Один экземпляр базы данных "ORA21C" был создан с опцией multi-tenant на базе инфраструктуры Oracle Grid (ASM). Версия базы данных - 21.13 на операционной системе OEL UEK 8.9.

Oracle ASM использовалась как платформа хранения данных с Linux udev для обеспечения персистентности устройств. Oracle SGA и PGA были установлены на 64G и 10G соответственно. Также были соблюдены все лучшие практики платформы Oracle на VMware.

Виртуальная машина "Oracle21C-OL8-DB_ESA" имеет 4 контроллера vNVMe для дополнительной производительности:

58 устройств хранения привязаны к ВМ "Oracle21C-OL8-DB_ESA", они показаны ниже:

• NVME 0:0 – 80G для OS (/)
• NVME 0:1 – 80G для Oracle Grid и бинарников RDBMS
• NVME 0:2 – 100G для GRID_DG
• NVME 0:3 – 200G для DATA_DG
• NVME 0:4 – 200G для DATA_DG
• NVME 0:5 – NVME 0:12 – 8 дисков vmdk, каждый 25 ГБ – REDO_DG
• NVME 1:0 – 1:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 2:0 – 2:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 3:0 – 3:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG

Детали тестов разных политик хранения vmdk для ВМ "Oracle21C-OL8-Customer" показаны ниже:

• Тест 1 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT0 – NoRAID"
• Тест 2 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT1 – R5"
• Тест 3 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT2 – R6"

Детали группы дисков Oracle ASM показаны ниже:

Тестовый сценарий

Результаты ниже являются тестовым сценарием, демонстрирующим преимущества производительности использования vSAN 8 vSAN Express Storage Architecture (ESA) для бизнес-критичных производственных нагрузок Oracle.

Генератор нагрузки SLOB был запущен против 2 TB табличного пространства SLOB с 3 различными политиками хранения.

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

В качестве генератора нагрузки для этого эксперимента был выбран SLOB 2.5.4.0 с следующими установленными параметрами SLOB:

UPDATE_PCT=30
RUN_TIME=300
SCALE=25G
WORK_UNIT=1024

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

Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.

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

Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.

Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.

Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.

Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:

• Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
• Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
• Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов

Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":

В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Если вы откроете VMware vSphere Client и посмотрите на список виртуальных дисков, прикрепленных к виртуальному модулю (Virtual Appliance) сервера vCenter, то вы увидите там аж 17 виртуальных дисков VMDK. Многие администраторы удивляются - а не многовато ли это?

Для VMware vSphere 7 список дисков и их назначение указаны в статье базы знаний KB 78515 (их там 16), ну а ниже мы расскажем о семнадцати VMDK для VMware vSphere 8:

Много? Много!

В 2021 году мы писали об использовании дисков VMDK на платформе VMware vSphere в режиме Multi-writer для кластерных решений. Этот режим предназначен для поддержки технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) и для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance, когда требуется использование общего диска в кластерной конфигурации.

В этом случае необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли производить запись в файл VMDK одновременно с нескольких хостов ESXi (можно также организовать и запись от нескольких ВМ на одном хосте). Этот режим со стороны VMware поддерживается только для некоторых кластерных решений, таких как Oracle RAC, и для технологии Fault Tolerance, у которой техника vLockstep требует одновременного доступа к диску с обоих хостов ESXi.

В статье, на которую мы сослались выше, хоть и неявно, но было указано, что режим "Multi-writer" используется и для кластеров Microsoft Windows Server Failover Clustering (WSFC, ранее они назывались Microsoft Cluster Service, MSCS), однако это была неверная информация - он никогда не поддерживался для кластеров Microsoft.

Мало того, использовать режим "Multi-writer" для WSFC не только не рекомендуется, но и опасно - это может привести к потере данных. Кроме того, возможности поддержки VMware в этом случае будут очень ограничены.

Информация о поддержке "Multi-writer" и общих дисков VMDK

Использование файлов VMDK в качестве общих дисков для виртуальных машин Windows в среде vSphere возможно, но только когда файлы VMDK хранятся в кластеризованном хранилище данных с включенной поддержкой Clustered VMDK, как описано в статье Clustered VMDK support for WSFC, или ниже в этой статье.

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

Итак, какие варианты предлагает VMware, если вы уже используете кластеры WSFC в режиме multi-writer:

• Переконфигурирование общих дисков на основе файлов VMDK для кластеризованных виртуальных машин Windows, которые были настроены с использованием опции флага multi-writer.
• Перемещение файлов VMDK в одно или несколько официально поддерживаемых хранилищ данных с поддержкой Clustered VMDK.
• Представление файлов VMDK обратно виртуальным машинам таким образом, чтобы минимизировать или избежать необходимости перенастройки внутри гостевой операционной системы или на уровне приложений.

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

Как минимум, клиенты должны выполнить (или отметить) следующее перед началом этих процедур:

• Текущие конфигурации виртуальных машин, особенно:
  • Диски – какие файлы VMDK соответствуют каким томам в гостевой операционной системе.
  • Имена и расположение файлов для КАЖДОГО диска VMDK.
  • Номер SCSI и SCSI ID, к которому подключен КАЖДЫЙ диск. Мы должны присоединить диск к ТОМУ ЖЕ SCSI ID при повторном подключении.
  • В Windows - текущий владелец ресурсов диска (проверить это можно в конфигурации WSFC).
• Если владение ресурсами WSFC разделено между узлами, ПЕРЕКЛЮЧИТЕ ВСЕ РЕСУРСЫ на один узел. Это упрощает процесс реконфигурации и очень полезно, чтобы избежать путаницы. Выключите все пассивные узлы ПЕРЕД выключением активного узла. После завершения настройки необходимо включить сначала активный узел, а затем остальные узлы.

Переконфигурация кластера WSFC с Multi-Writer на режим Clustered VMDK

Давайте начнем с рассмотрения нашей текущей конфигурации, посмотрим на узлы (кликабельно):

И на диски:

Протестируем WSFC путем переключения ресурсов диска - в данном случае мы выключаем активный узел и наблюдаем, как кластерные ресурсы становятся доступными на пассивном узле. Этот тест очень важен для проверки работоспособности WSFC перед внесением изменений.

Текущая конфигурация общих дисков (отображение распространенной неправильной конфигурации с включенным multi-writer, где общие диски принадлежат выключенной третьей виртуальной машине).

Вот узел WSFC Node-1 и его расшаренные диски (флаг Multi-Writer установлен в Enabled):

Читайте статью далее->

Иногда при работе администратора с виртуальными машинами VMware vSphere происходит ошибка при работе с дескрипторными файлами дисков VMDK, которая проявляет себя следующим образом:

• Диск ВМ показывается в Datastore Browser, но иконка для него отсутствует
• При включении ВМ вы получаете ошибку " File not found"
• Сам файл ВМ вида <имя ВМ>-flat.vmdk есть в директории с машиной, но файла <имя ВМ>.vmdk вы не видите
• Сам файл <имя ВМ>.vmdk отсутствует, либо он есть, но его содержимое повреждено

Эти симптомы могут возникать по разным причинам, но суть их одна - дескрипторный файл ВМ поврежден или отсутствует. Ситуация поправима, если у вас есть основный диск с данными - <имя ВМ>-flat.vmdk, и он сохранился в целости.

В 2012 году мы писали о том, как быть, если у вас возникла проблема с дескрипторным файлом виртуальной машины в среде VMware vSphere. В целом, с тех времен ничего особо не поменялось. Процесс этот довольно простой и описан в KB 1002511, также он детально разобран в видео ниже:

Часть 1 - восстановление основного VMDK виртуальной машины

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

Если вкратце, то для восстановления вам нужно выполнить следующие шаги:

1. Соединяемся с хостом VMware ESXi по SSH как root. Либо операции можно проводить непосредственно в консоли DCUI.

2. Переходим в папку с ВМ и определяем геометрию основного диска VMDK с данными <имя ВМ>-flat.vmdk

Делается это командой:

# ls -l <имя диска>-flat.vmdk

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

3. Теперь нужно пересоздать заголовочный файл VMDK (<имя ВМ>.vmdk), чтобы он соответствовал диску с данными, используя тот же размер диска, полученный на предыдущем шаге:

# vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk

После этого переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Затем удаляем только что созданный пустой диск данных нового диска, который уже не нужен (temp-flat.vmdk).

4. Открываем переименованный дескрипторный файл VMDK и меняем выделенные красным строчки:

# Disk DescriptorFile
version=1
CID=fb183c20
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 8388608 VMFS "vmdisk0-flat.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "522"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.thinProvisioned = "1"

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

Вы также можете поменять тип адаптера ddb.adapterType = lsilogic на ddb.adapterType = pvscsi, если вы использовали паравиртуализованный SCSI-контроллер для исходной ВМ.

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

vmkfstools -e filename.vmdk

Если все в порядке, то в ответе команды вы получите вот такую строчку:

Disk chain is consistent.

Если же исправить ситуацию не получилось, то будет вот такой текст:

Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).

После этого можно запускать виртуальную машину, добавив ее повторно в окружение vSphere Client.

Часть 2 - исправление дескрипторов файлов снапшотов ВМ (delta-файлы)

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

drwxr-xr-x 1 root root 1400 Aug 16 09:39 .
drwxr-xr-t 1 root root 2520 Aug 16 09:32 ..
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002-delta.vmdk
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001-delta.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001.vmdk
-rw------- 1 root root 16106127360 Aug 16 09:32 examplevm-flat.vmdk
-rw------- 1 root root 469 Aug 16 09:32 examplevm.vmdk
-rw------- 1 root root 18396 Aug 16 14:39 examplevm-Snapshot1.vmsn
-rw------- 1 root root 18396 Aug 17 19:11 examplevm-Snapshot2.vmsn
-rw------- 1 root root 397 Aug 16 09:39 examplevm.vmsn
-rwxr-xr-x 1 root root 1626 Aug 16 09:39 examplevm.vmx
-rw------- 1 root root 259 Aug 16 09:36 examplevm.vmxf

Основной порядок действий в этой ситуации приведен в KB 1026353, здесь же мы опишем его вкратце (кстати, напомним про необходимость сделать полный бэкап всех файлов ВМ перед любыми операциями):

1. Определяем нужные нам файлы

Итак, заголовочные файлы снапшотов ВМ хранятся в так называемых файлах типа vmfsSparse, они же работают в связке с так называемым delta extent file, который непосредственно содержит данные (выше это, например, examplevm-000001-delta.vmdk).

Таким образом, опираясь на пример выше, нам интересны заголовочные файлы снапшотов examplevm-000001.vmdk и examplevm-000002.vmdk. Помните также, что диски и их снапшоты могут находиться в разных папках на разных датасторах, поэтому сначала вам нужно понять, где и что у вас хранится. Если у вас есть сомнения касательно имен нужных вам файлов, вы можете заглянуть в лог-файл vmware.log, чтобы увидеть там нужные пути к датасторам.

2. Создаем новый дескриптор снапшота

Итак, представим теперь, что файл examplevm-000001.vmdk у нас поврежден или отсутствует. Создадим новый дескриптор снапшота из исходного заголовочного файла examplevm.vmdk простым его копированием:

# cp examplevm.vmdk examplevm-000001.vmdk

3. Меняем указатели на файл с данными для снапшота

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

ddb.virtualHWVersion = "7"
ddb.longContentID = "5fd87dda1dc77cafd5be881a19741890"
ddb.uuid = "60 00 C2 9e 3d 8d 45 82-dd 1f e4 93 22 da 9c 61"
ddb.geometry.cylinders = "1958"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

Красным мы выделили то, что будем в этом файле изменять, а синим - то, что будем удалять.

С данным файлом нужно сделать следующие манипуляции:

• Строчку CID=19741890 заменяем на случайное восьмизначное значение (это идентификатор диска)
• Строчку parentCID=ffffffff заменяем на parentCID=19741890 (идентификатор родительского диска, им может быть не только родительский основной диск, но и родительский снапшот, то есть его дескриптор)
• Строчку createType="vmfs" заменяем на createType="vmfsSparse"
• Строчку RW 31457280 VMFS "examplevm-flat.vmdk" заменяем на RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk" (обратите внимание, что номер 31457280 остается тем же - он должен быть тем же самым для всей цепочки дочерних дисков)

4. Добавляем данные специфичные для снапшота

Теперь нам надо добавить в указатель снапшота кое-что новое:

• Под строчкой createType="vmfsSparse" добавляем строчку parentFileNameHint="examplevm.vmdk"

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

Ну а вот эту строчку нужно оставить:

ddb.longContentID = "5fd87dda1dc77cafd5be881a19741890"

Таким образом, содержимое результирующего файла должно быть следующим:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=7f3a1e17
parentCID=19741890
createType="vmfsSparse"
parentFileNameHint="examplevm.vmdk"

# Extent description
RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "5fd87dda1dc77cafd5be
881a19741890"

После этого вы можете попробовать запустить машину с дочерним снапшотом. Но перед этим также проверьте интеграцию дескриптора командой:

vmkfstools -e filename.vmdk

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

Компания VMware выпустила очень интересное видео про приложения, доставляемые пользователям в виртуальные ПК по запросу (On-Demand Applications) в инфраструктуре виртуальных томов App Volumes:

Данная функция появилась в версии App Volumes 2111 (анонсирована она была еще в 2019 году), она позволяет не монтировать VMDK с приложениями при загрузке виртуальной машины, но оставлять иконки приложений на рабочем столе. При клике на эти иконки происходит динамическое монтирование томов, выстраивание связей и подгрузка приложения в операционной системе. Это позволяет не тратить время на монтирование дисков при загрузке ВМ и ускорить логин пользователя.

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

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

Продолжаем рассказывать вам о продуктах компании StarWind, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Сегодня мы расскажем о бесплатной утилите V2V Converter / P2V Migrator, которая позволяет делать три важных для администратора вещи...

Многие администраторы VMware vSphere в крупных компаниях рано или поздно сталкиваются с необходимостью создания кластеров из виртуальных машин, например, для использования технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) или для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance. При использовании кластерных решений необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли...

Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.

Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.

Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.

К сожалению, все это работает только на хранилищах Fibre Channel.

Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":

Далее нужно понимать следующие условия и ограничения:

• Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
• LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
• LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
• VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
• Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
• Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
• Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.

Максимумы конфигураций для таких кластеров WSFC следующие:

Надо помнить еще о следующих ограничениях (более подробно тут):

• Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
• Горячее расширение VMDK кластерной ВМ не поддерживается.
• Не поддерживается Storage vMotion и снапшоты.
• VMFS 5 и более ранние версии не поддерживаются.

Интересный баг обнаружил Matt для своей виртуальной инфраструктуры, когда пытался клонировать виртуальные машины с выставленной опцией "customize this virtual machine’s hardware":

Оказалось, что после создания клона его VMDK-диск указывал на VMDK клонируемой машины, что, само собой, является серьезнейшим багом. После работы с техподдержкой оказалось, что баг не такой и частый, так как проявляется только когда в VMX-файле исходной машины параметр disk.enableuuid выставлен в значение TRUE (по умолчанию он отсутствует и применяется как FALSE).

Данный параметр иногда добавляется пользователями в соответствии с рекомендациями вендоров решений для резервного копирования и управления виртуальной средой - он позволяет убедиться в том, что VMDK диск предоставляет машине консистентный UUID для корректного монтирования.

Workaround для этого бага - это либо использовать для операций клонирования старый vSphere Web Client, либо делать это через PowerCLI. Можно также не использовать опцию "customize this virtual machine’s hardware", а настроить железо ВМ после выполнения клонирования. Также баг не проявляется если делать клонирование выключенной машины.

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

Что нового появилось в HCIBench 2.1:

• Интерфейс переключили на темную тему.
• Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
• Добавлена возможность обновления процесса подготовки VMDK.
• Добавлена проверка портов базы данных Graphite в процесс превалидации.
• Пароли vCenter и хостов ESXi затемняются при сохранении
• Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
• Пофикшены проблемы с дисплеями для Grafana.
• Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
• Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.

Не так давно мы писали о функции Site Locality в кластере VMware vSAN и некоторых ситуациях, когда эту функцию полезно отключать. Недавно Дункан Эппинг еще раз вернулся к этой теме и рассказал, что при использовании растянутых кластеров VMware vSAN надо иметь в виду некоторые особенности этого механизма.

При создании растянутого кластера вам предоставляют опции по выбору уровня защиты данных RAID-1 или RAID-5/6 средствами политики FTT (Failures to tolerate), а также позволяют определить, как машина будет защищена с точки зрения репликации ее хранилищ между датацентрами.

Некоторые дисковые объекты машин вы можете исключить из растянутого кластера и не реплицировать их между площадками. Такая настройка в HTML5-клиенте выглядит следующим образом:

В старом интерфейсе vSphere Web Client это настраивается вот тут:

Смысл настройки этих политик для виртуальной машины в том, чтобы вы могли однозначно определить размещение ее дисковых объектов, так как если у нее несколько виртуальных дисков VMDK, то если вы не зададите их локацию явно - может возникнуть такая ситуация, когда диски одной машины размещаются в разных датацентрах! Потому что при развертывании ВМ решение о размещении принимается на уровне дисковых объектов (то есть на уровне виртуальных дисков), которые по каким-то причинам могут разъехаться в разные сайты, если вы выберите первый пункт на первом скриншоте.

Это, конечно же, со всех сторон плохо, особенно с точки зрения производительности.

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

Поэтому всегда убеждайтесь, что машина и ее дисковые объекты всегда находятся на одном сайте, для этого задавайте их локацию явно:

Во время прошедшего летом прошлого года VMworld 2018 компания VMware представила много интересных новостей на тему будущей функциональности продукта для создания отказоустойчивых хранилищ VMware vSAN. Например, мы писали о технологии Native Data Protection (это часть 1 этого цикла статей), а сегодня поговорим о сервисах хранения.

Диски First Class Disk (FCD)

Для vSAN уже есть поддержка так называемых дисков First Class Disk (FCD), они же называются Improved Virtual Disk (IVDs) или Managed Virtual Disk. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes (он называется vSphere Cloud Provider) для создания постоянных (persistent) томов контейнеров Docker. Этим всем занимается опенсорсный проект Project Hatchway от VMware.

Работать с такими дисками очень неудобно - для них приходится создавать отдельную виртуальную машину к которой цепляется этот диск, а потом, по завершении какого-либо процесса, отсоединяется, и машина уничтожается. Так, например, работает средство для резервного копирования App Volumes Backup Utility, о котором мы писали вот тут. При бэкапе этих дисков создается временная Backup VM:

Второй пример - инфраструктура vSphere Integrated OpenStack (VIO), где для того, чтобы включить хранилище Cinder (OpenStack Block Storage) для потребления дисковой емкости VMDK-файлов, нужно создавать вспомогательные Shadow VM для каждого тома Cinder, к которому цепляется VMDK-диск.

Все это неудобно, поэтому и придумали формат дисков First Class Disk (FCD), которому не требуются временные виртуальные машины и которые реализуют сервисы, необходимые приложениям или другим сервисам. Например, бэкап таких дисков можно делать без создания вспомогательной ВМ.

Информация о дисках FCD хранится в каталоге базы данных vCenter. Она содержит глобальные уникальные идентификаторы UUID и имена дисков. UUID позволяет переместить диск в любое место без конфликтов.

Впервые API для работы с FCD появился в VMware vSphere 6.5, например, вот хороший пост от Вильяма Лама об этом. Но в этом релизе было ограничение на резервное копирование FCD-дисков, которые не присоединены к ВМ (в качестве workaround приходилось все же использовать Dummy VM).

В vSphere 6.7 это ограничение было снято, но остались еще некоторые требования - FCD нужно было восстанавливать с тем же UUID и на тот же датастор, откуда он был взят. Также еще одним ограничением была невозможность API отслеживать блоки, изменившиеся с момента последней резервной копии, то есть невозможность инкрементального резервного копирования (подробнее здесь).

Ну а в vSphere 6.7 Update 1 была анонсирована ограниченная поддержка FCD для vSAN. Пока поддержка предоставляется еще с ограничениями для служб health service и capacity monitoring. Однако при этом пользователи Kubernetes могут использовать диски FCD на хранилищах vSAN для персистентных хранилищ контейнеров, и в то же самое время тома vSAN могут использоваться для виртуальных машин:

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке.

В следующей статье мы расскажем про Cloud Native Storage (CNS) и vSAN File Services.

Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.

Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:

Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.

Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.

Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:

А далее привязываем эту политику к диску VMDK в настройках ВМ:

Тут же в настройках можно задать значение в поле Limit-IOPs, если не выбирать политику.

Именно ограничение по IOPS делает поведение инфраструктуры хранения для виртуальных машин предсказуемым и управляемым. Ограничения по вводу-выводу позволят обеспечить минимально приемлемый уровень обслуживания для виртуальных машин, которым требуются ресурсы хранилища, с гарантией того, что остальные системы не съедят все доступные IOPS.

Ну и в заключение несколько аспектов данного рода ограничений:

• Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
• IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
• IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
• Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
  • Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
  • А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
• Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.

Также рекомендуем почитать нашу статью "VMware Storage I/O Control (SIOC) - как это работает на практическом примере".

Часто администраторы виртуальной инфраструктуры VMware vSphere испытывают необходимость увеличить размер виртуального диска VMDK, который защищен технологией репликации VMware vSphere Replication. Если попытаться увеличить диск из vSphere Client, то вы получите вот такую ошибку:

vSphere Replication does not support changing the length of a replicated disk

Поэтому для увеличения реплицируемого VMDK-диска нужно сделать следующее:

• Переименуйте папку с виртуальной машиной и виртуальным диском на резервном сайте. Это нужно для того, чтобы при отключении репликации папка с ВМ на резервной площадке не удалилась.
• Запомните настройки репликации ВМ (RPO, датастор назначения и т.п.).
• Отключите репликацию виртуальной машины.
• Увеличьте размер виртуального диска на основной площадке из GUI vSphere Web Client через Edit Settings.
• Теперь увеличьте размер виртуального диска на резервной площадке с помощью утилиты vmkfstools. Для этого выполните команду:

vmkfstools –X 50G virtual_machine.vmdk

• Далее на резервном сайте переименуйте папку с ВМ обратно к исходному имени.
• Настройте репликацию ВМ заново, выбрав пункт Specify datastore folder и указав папку с ВМ, которую будете реплицировать. Появится сообщение:

A file with the name ‘[<datastore>] <folder>/<filename> already exists. Press Yes to use file as an initial copy.

• Нажимайте Yes и репликация должна завестись.

Если вы не увеличите размер виртуального диска на резервной площадке, то получите вот такое сообщение об ошибке:

The capacity of the seed disk does not match the capacity of the replication source disk. Create a new seed copy or verify that you selected the correct seed to use for this replication

Поэтому не пропускайте этот шаг. Также о процедуре написано в KB 2052883.

В феврале мы писали о средстве IOInsight, которое позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.

На днях на сайте проекта VMware Labs появилось обновление этого виртуального модуля - IOInsight 1.1.

Давайте посмотрим на новые возможности последней версии:

• Утилита командной строки для установки статического IP-адреса или DHCP.
• Опция для установки NTP-севреров.
• Опция в интерфейсе, позволяющая настроить отсылку логов и результатов вывода IOInsight разработчикам для последующего решения проблем.

Вот какие ошибки были исправлены и улучшения добавлены:

• Устранены проблемы с логином к vCenter.
• Обработка спецсимволов в именах машин.
• Улучшенная гистограмма IO-size (данные отображаются корректно).
• Улучшенный мониторинг дисков VMDK с очень маленькими показателями по вводу-выводу.
• Улучшенные алерты в интерфейсе и логи продукта.
• Улучшенная визуализация графиков.

Скачать VMware IOInsight 1.1 можно по этой ссылке.

В среде VMware vSphere есть возможность использования одного виртуального диска VMDK на запись несколькими виртуальными машинами, размещенными на разных хостах VMware ESXi. Например, это необходимо для построения кластеров Oracle RAC, а также для работы технологии VMware Fault Tolerance.

Этот режим называется Multi-Writer VMDK, чтобы его включить, нужно (если у вас vSphere 6.0 Update 1 и выше) зайти в vSphere Web Client и выбрать пункт "Edit Settings" для витуальной машины. Далее идем в Virtual Hardware -> выбираем диск, для которого нужно включить multi-writer flag, и в поле Sharing выбираем режим Multi-Writer:

Если у вас более старая версия VMware ESXi, то чтобы включить Multi-Writer VMDK надо определить диск VMDK, например, "SCSI0:1" и в Configuration Parameters виртуальной машины (то есть в ее vmx-файл) внести поле с именем "scsi0:1.sharing" со значением "multi-writer":

Когда вы включаете кластер непрерывной доступности ВМ VMware Fault Tolerance, режим Multi-Writer VMDK включается автоматически.

У этого режима есть некоторые ограничения, связанные с одновременной работой с одним виртуальным диском нескольких машин (соответственно, такие же ограничения есть и у VMware FT, и у кластеров Oracle RAC на базе ВМ):

Действия или возможности	Поддерживается	Не поддерживается	Комментарий
Включение, выключение и перезагрузка ВМ
Приостановка ВМ (Suspend)
Горячее добавление виртуальных дисков (Hot add)			Только для уже существующих адаптеров
Горячее удаление устройств (Hot remove)
Горячее расширение виртуального диска
Присоединение и отсоединение устройств
Снапшоты			Решения для резервного копирования используют снапшоты через механизм vStorage APIs, соответственно такие решения (например, Veeam Backup and Replication) также не поддерживаются для этого режима.
Снапшоты ВМ с типом диска independent-persistent			Поддерживается в vSphere 5.1 update 2 и более поздних версиях
Клонирование ВМ
Горячая миграция хранилищ Storage vMotion			Не поддерживаются и shared, и non-shared диски, так как требуется приостановка ВМ во время миграции хранилищ.
Технология Changed Block Tracking (CBT)
Техника vSphere Flash Read Cache (vFRC)			Может привести к повреждению данных.
vMotion			Поддерживается только для Oracle RAC и ограничена 8 хостами ESXi.

На сайте проекта VMware Labs появилась действительно достойная внимания утилита - IOInsight, доступная в виде готового к развертыванию виртуального модуля на платформе vSphere. Она позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.

Все это позволит принимать решения о тюнинге производительности и планировании емкостей по пропускной способности на основе данных, выводимых в графиках и отчетах:

В решении каких проблем может помочь IOInsight:

• Самостоятельная оптимизация производительности и планирование хранилищ пользователями vSphere.
• Отчет из IOInsight может помочь при обращении в техподдержку VMware, что ускорит решение проблемы.
• Сотрудники VMware Engineering могут подсказать решения по оптимизации ваших продуктов.

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

Кроме того, предполагается, что администраторы и разработчики сами будут писать плагины к IOInsight, поскольку в состав решения включены SDK и development guide (как видите на картинке, два плагина уже есть). Руководство для обычных пользователей доступно вот тут.

Лучшие практики по использованию IOInsight:

• 2-4 виртуальных процессора на виртуальный модуль (vCPU)
• 2 ГБ и более оперативной памяти
• Желательно разместить IOInsight в той же сети, что и хосты, которые планируется мониторить
• Нужно выбирать не более 8 VMDK, чтобы не было слишком высокой нагрузки
• Рекомендуемый период анализа данных - 10-30 минут
• Cache Simulation analyzer создает нагрузку на процессор, поэтому его нужно запускать для 1 или 2 симулируемых конфигураций кэша (не более)

Утилита IOInsight работает, начиная с версии VMware vSphere 5.5, а скачать ее можно по этой ссылке.

Недавно компания VMware выпустила новую версию платформы vSphere 6.5, о новых возможностях которой мы писали вот тут. Между тем, в плане хранилищ было сделано несколько важных улучшений, которые заслуживают отдельного поста. Большинство из этого реализуемо только на базе файловой системы VMFS 6.0, которая также появилась в vSphere 6.5.

1. Возврат дискового пространства хранилищу (Storage UNMAP).

Эта возможность была еще в VMware ESXi 5.0, но пропала по некоторым техническим причинам в следующих версиях. Теперь она полноценно была реализована в двух вариантах:

• Automatic UNMAP
• Поддержка Linux-based In-Guest UNMAP

Automatic UNMAP - это возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически.

Для работы этой возможности вам понадобятся:

• ESXi 6.5+
• vCenter 6.5+
• VMFS 6
• Дисковый массив с поддержкой UNMAP

Если мы в настройках хранилища откроем вкладку Configure:

И далее нажмем Edit в разделе Space Reclamation Priority, то мы увидим вот такую настройку:

Здесь устанавливается приоритет, в соответствии с которым свободные блоки будут автоматически возвращены к LUN. Надо понимать, что UNMAP - это асинхронный процесс, который выполняет специальный crawler, потому и задается его приоритет. Понятное дело, что если задать высокий приоритет, то создастся дополнительная нагрузка на хранилища.

Кстати, для немедленного возврата дискового пространства можно воспользоваться командой esxcli storage vmfs unmap.

Поддержка Linux-based In-Guest UNMAP в vSphere 6.5 появилась впервые. Для ее работы нужна поддержка со стороны гостевой ОС Linux и ее файловой системы. Ну и работает это все только для тонких (thin) дисков.

Работает она не полностью автоматически, а запустить ее можно тремя способами:

1. Смонтировать файловую систему с опцией discard. Это будет возвращать простраство автоматически, когда будут удаляться файлы.
2. Выполнение команды sg_unmap. Это запустит механизм UNMAP для выбранных LBA.
3. Выполнение fstrim. Это вызовет команды trim, которые ESXi конвертирует в операции механизма UNMAP на уровне слоя vSCSI.

2. Функция Thin Hot Extend.

Это очень полезная штука была несколько ранее - она позволяла на горячую увеличить размер тонкого диска.

Вся загвоздка была в том, что диск можно было увеличить только до 2 ТБ, иначе возникала вот такая ошибка:

Теперь же можно задавать виртуальный диск любого размера.

3. Поддержка 4K-дисков в режиме 512e.

Теперь расширенный формат дисковых устройств 4K поддерживается со стороны vSphere 6.5, однако в режиме эмуляции 512e (то есть для 4к-девайсов эмулируются 512-байтные сектора). Такая же поддержка есть и в VMware Virtual SAN 6.5.

Полная поддержка 4k-устройств в нативном режиме ожидается в ближайшем будущем.

4. Поддержка до 512 устройств и 2000 путей.

Ранее платформа vSphere поддерживала 256 устройств и 1024 пути к одному хранилищу. И некоторые умудрялись упираться в лимиты, поэтому для таких клиентов и было сделано увеличение максимумов.

5. Увеличение лимита CBRC (он же View Storage Accelerator).

Про механизм кэширования Content Based Read Cache (CBRC) мы писали вот тут. Он позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК за счет кэширования в оперативной памяти хоста VMware ESXi.

Ранее он был ограничен объемом в 2 ГБ, а теперь увеличился до 32 ГБ:

6. Переподписка проблемных томов (unresolved volumes resignaturing).

Теперь в vSphere 6.5 есть механизм для переподписки так называемых unresolved volumes, то есть томов, которые отвязались от основного по каким-то причинам, и теперь их метаданные являются не соответствующими текущей структуре файловой системы. Так, например, бывает в процессе резервного копирования, когда остается какой-нибудь повисший на диске снапшот, который не видно из GUI клиента vSphere.

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

Это основные, но не все улучшения VMware vSphere 6.5 в плане хранилищ, а если хочется узнать обо всех, то почитайте документ "vSphere 6.5 Storage", где очень много всего интересного.

Как мы уже писали, в новой версии VMware vSphere 6.5 компания VMware существенно улучшила функции виртуального модуля VMware vCenter Server Appliance (vCSA). В частности, в него был добавлен VMware Update Manager (VUM), который по традиции также идет отдельным разделом и диском VMDK, как и остальные сервисы. Расскажем ниже об увеличении раздела диска vCSA, которое описано в статье Вильяма Лама.

Давайте взглянем на таблицу разделов vCSA 6.5, каждому из которых соответствует диск VMDK, в сравнении с vSphere 6.0:

Как мы видим, кое-где изменились размеры стандартных разделов, для Image Builder поменялась точка монтирования, а также добавился отдельный раздел VUM на 100 гигабайт, которого не было раньше.

Размер каждого из разделов можно менять на горячую в настройках ВМ, ну а потом нужно из гостевой ОС vCSA расширить раздел на образовавшееся свободное пространство диска. Вот какие изменения произошли в версии vSphere 6.5 на эту тему:

• Теперь вместо команды vpxd_servicecfg для расширения логического тома нужно использовать следующий скрипт:
  /usr/lib/applmgmt/support/scripts/autogrow.sh
• Помимо расширения раздела из SSH, это можно сделать через интерфейс Virtual Appliance Management Interface (VAMI) REST API, который можно вызвать удаленно методом POST /appliance/system/storage/resize.

Посмотрим на расширение раздела с Net Dumper (VMDK9) с помощью нового VAMI API.

Выполним команду df -h, чтобы вывести таблицу разделов на vCSA:

Теперь в vSphere Client идем в настройки виртуальной машины vCSA и переходим в раздел управления дисками, где увеличиваем размер девятого виртуального диска с 1 ГБ до 5 ГБ:

Затем идем в браузере по адресу https://[VCSA-HOSTNAME]/apiexplorer, где выбираем пункт "appliance" в разделе Select API и нажимаем кнопку Login, после чего вводим логин/пароль от vCenter Server:

Скроллим до операции POST /appliance/system/storage/resize и раскрываем ее, чтобы увидеть детали:

Теперь нажимаем кнопку "Try it out!" и, в случае успешного выполнения, код ответа (Response Code) будет 200. Также эту же операцию можно выполнить и через PowerCLI:

Connect-CisServer -Server 192.168.1.150 -User administrator@vghetto.local -Password VMware1!

$diskResize = Get-CisService -Name 'com.vmware.appliance.system.storage'

$diskResize.resize()

В итоге, результат будет виден в выводе команды df: раздел, как и виртуальный диск VMDK, увеличился до 5 ГБ:

Вы уверены, что знаете, что происходит на ваших датасторах? Где хранятся ваши ISO-образы? Сколько у вас «осиротевших» (orphaned) виртуальных дисков? Каков их размер, и как давно они там? И что ещё занимает совсем недешёвое пространство на вашей СХД? Функция Search-Datastore из моего PowerCLI модуля Vi-Module ответит вам на все эти и многие другие вопросы.

Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.

Недавно компания StarWind Software, известная своим продуктом номер 1 - Virtual SAN для создания отказоустойчивых кластеров хранилищ, обновила свое замечательное средство для преобразования виртуальных машин между платформами виртуализации - StarWind V2V Converter.

Напомним, что StarWind V2V Converter умеет преобразовывать виртуальные машины между форматами VHD/VHDX, VMDK и нативным форматом продуктов StarWind - IMG. Для большей надежности, перед конверсией StarWind V2V Converter создает резервную копию виртуальной машины. Сейчас это лучшее бесплатное средство двусторонней конверсии между Microsoft Hyper-V и VMware vSphere.

После начала конверсии V2V Converter активирует Windows Repair Mode. Это позволяет гостевой ОС на новой платформе виртуализации автоматически обнаружить виртуальные устройства и установить необходимые драйверы.

Новые возможности последней версии StarWind V2V Converter V8 Build 162:

• Поддержка образов виртуальных машин Red Hat KVM и QCOW2 (QEMU).
• Поддержка сжатого формата VMDK ("Stream-optimized"), который используется для виртуальных модулей VMware OVF.
• Автоматический апдейт виртуального аппаратного обеспечения при изменении формата дисков виртуальной машины.

Скачать обновленный StarWind V2V Converter V8 можно по этой ссылке.

Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.

Например, может быть вот такое сообщение об ошибке при включении машины:

Could not power on VM: Lock was not free

Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.

Делается это следующим образом:

1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.

Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:

#cd /bin

С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:

~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/vm1.vmdk -v 192.168.1.10 -u administrator@vsphere.local

Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.

Вывод будет примерно таким:

vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1

Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive

Total time taken : 0.27 seconds.

Из вывода можно понять 2 важные вещи:

• MAC-адрес хоста, залочившего VMDK
• IP-адрес хоста, залочившего VMDK
• Тип лока - Exclusive

Кстати, лок может быть нескольких типов:

• mode 0 - нет лока
• mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
• mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
• mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).

Более подробно об этом написано в KB 2110152.

2. Точно определяем хост, машина которого держит VMDK.

Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:

# vim-cmd hostsvc/net/info | grep "mac ="

3. Обнаруживаем процесс VMX, который держит VMDK.

Выполняем на найденном ESXi команду:

# lsof | egrep 'Cartel|vm1.vmdk'

Получаем что-то вроде этого:

Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk

Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:

# esxcli vm process list

Получаем такой вывод:

Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx


Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...

Видим, что World ID нашей машины - 36205.

4. Убиваем VMX-процесс, залочивший VMDK.

Ну и убиваем зависший процесс VMX следующей командой:

# esxcli vm process kill --type force --world-id <ID>

После этого с машиной и ее диском можно делать уже что требуется.

Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.

Если вы администратор платформы виртуализации VMware vSphere, то, наверное, часто замечали, что в некоторых случаях при операциях с виртуальными машинами и ее дисками происходит "подмораживание" ВМ (или "stun", он же "quiescence"). В этот момент виртуальная машина ничего не может делать - она недоступна для взаимодействия (в консоли и по сети), а также перестает на небольшое время производить операции ввода-вывода. То есть, ее исполнение ставится на паузу на уровне инструкций, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).

Cormac Hogan написал на эту тему интересный пост. Stun виртуальной машины нужен, как правило, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация снапшотов. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше.

Когда может возникать stun виртуальной машины? Есть несколько таких ситуаций.

1. Во время операции "suspend" (постановка ВМ на паузу). Тут происходит такое подмораживание, чтобы скинуть память ВМ на диск, после чего перевести ее в приостановленное состояние.

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

3. Консолидация снапшотов (удаление всех). Здесь тоже нужно "склеить" все VMDK-диски (предварительно закрыв) и начать работать с основным диском ВМ. А вот удаление снапшота в цепочке stun не вызывает, так как не затрагивает VMDK, в который сейчас непосредственно идет запись.

4. Горячая миграция vMotion. Сначала память передается от одной машины к целевой ВМ без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).

5. Горячая миграция хранилищ Storage vMotion. Здесь stun случается аж дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова переоткрыть диски уже на целевом хранилище.

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

В блоге компании VMware появился интересный пост с некоторыми подробностями о работе технологии репликации виртуальных машин vSphere Replication. Приведем здесь основные полезные моменты.

Во-первых, репликация с точки зрения синхронизации данных, бывает двух типов:

• Full sync - это когда требуется полная синхронизация виртуальной машины и всех ее дисков в целевое местоположение. Для этого в версии VMware vSphere 5.x использовалось сравнение контрольных сумм дисков на исходном и целевом хранилище. Если они не совпадают, и нужно делать Full sync, исходя из начальных условий - начинается процесс полной репликации ВМ. В первую очередь, основным подвидом этого типа является Initial full sync - первичная синхронизация работающей виртуальной машины, для которой репликация включается впервые.

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

• Delta sync - после того, как полная синхронизация закончена, начинается процесс передачи целевой ВМ только различий с момента полной репликации. Тут используется технология changed block tracking, чтобы понять, какие блоки надо отреплицировать с последнего Full sync. Периодичность дельта-репликации зависит от установленной политики Recovery Point Objective (RPO).

Чтобы политика RPO соблюдалась нужно, чтобы дельта-синхронизация полностью проходила за половину времени, установленного в RPO, иначе будут нарушения политики, сообщения о которых вы увидите в vSphere Client. Почему половину? Подробно мы писали об этом вот тут (почитайте, очень интересно). Также еще и в документации VMware есть информация о расписании репликации.

Если вы настроите репликацию для виртуальной машины, то автоматически работать она будет для включенной ВМ, а если она выключена, то сама работать не будет, о чем будет выдано соответствующее предупреждение:

Таким образом, репликация делится еще на 2 типа:

• Online sync - репликация включенной ВМ, проходящая автоматически.
• Offline sync - репликация выключенной ВМ, запускаемая вручную.

Вот так запускается репликация для выключенной ВМ:

Во время offline-репликации виртуальную машину нельзя включить, а ее диски будут залочены. Кроме того, вы не сможете отменить эту операцию. Поэтому при нажатии Sync Now будет выведено вот такое предупреждение:

Обычно offline-репликация используется для создания гарантированной копии ВМ на другой площадке (например, при переезде датацентра или частичном восстановлении инфраструктуры на другом оборудовании). Ну или если у вас была настроена online-репликация, а вы выключили ВМ, то в конце нужно сделать еще ручной Sync Now.

Также в VMware vSphere 6.0 было сделано существенное улучшение в производительности процесса репликации. Если раньше идентичность копий основного диска и реплики сверялась только на базе контрольных сумм (все данные диска надо прочитать - а это затратно по вводу-выводу и CPU), то теперь иногда используются данные о конфигурации виртуального диска на базе регионов. Например, если на исходном диске есть регионы, которые не были аллоцированы на целевом диске, то репликация это отслеживает и передает данные в эти регионы на целевое хранилище. Это работает значительно быстрее вычисления контрольных сумм.

Но такая оптимизация работает не для всех типов виртуальных дисков, а только для Lazy zeroed thick disks, thin disks и vSAN sparse disks и только на томах VMFS. Тома NFS, тома VVols, а также диски типа Eager zeroed thick не предоставляют информации об аллокации регионов, поэтому для них оптимизация работать не будет. Более подробно об этом написано тут.

Дункан опубликовал в своем блоге интересный пост про то, как кластер VMware Virtual SAN размещает данные больших VMDK-дисков на малых физических дисках. Напомним, что Virtual SAN оперирует понятием дисковых страйпов (disk stripes), на которые разбивается дисковый объект (в частности, виртуальный диск VMDK является дисковым объектом). Это как кирпичики Virtual SAN, на уровне которых работает кластер.

Давайте взглянем на картинку:

Здесь мы видим вот что: на уровне политики (VSAN Policy) задан параметр "Number of failures to tolerate" (подробнее об этом мы писали тут) равный 1. Это значит, что инфраструктура Virtual SAN может пережить отказ не более одного хоста.

Но также в рамках политики есть еще и параметр "Stripe Width" (он же "Number of Disk Stripes Per Object"), который позволяет разбить дисковый объект на два страйпа: stripe/a и stripe/b, причем обратите внимание, что реплика дискового объекта может храниться на разных хост-серверах (а может и на одном - это вы никак не сможете отрегулировать, гарантируется лишь, что это будут 2 разных hdd-диска). Так что, если у вас маленькие диски, а виртуальные машины с большими дисками VMDK, то задайте этот параметр вот здесь:

Кстати говоря, объекты разбиваются на страйпы не только при заданном Stripe Width, но и автоматически, когда размер VMDK превышает 256 ГБ.

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

Многие из вас знают следующий способ уменьшения тонкого диска (Thin disk): надо сначала почистить блоки утилитой sdelete, а потом сделать миграцию машины средствами Storage vMotion на другое хранилище. Тогда thin-диски и уменьшатся до реального размера данных в нем.

Но, во-первых, SVMotion есть не у всех (так как в начальные издания vSphere эта технология не входит), а, во-вторых, есть более простой способ. Итак:

1. Давайте сначала "раздуем" исходный тонкий диск с помощью утилиты sdelete.

Было (18,74 ГБ):

Запускаем в гостевой ОС Windows утилиту:

sdelete -c

Стало (41,8 ГБ):

2. Очищаем удаленные блоки в гостевой ОС, заполняя их нулями.

Для этого запустим команду:

sdelete -z

3. Уменьшаем размер виртуального диска с помощью утилиты vmkfstools.

Делается это с помощью ключа -K (можно также использовать ключ --punchzero) в консоли сервера ESXi:

vmkfstools -K Test.vmdk

Вот и все, смотрим на получившийся размер:

Надо отметить, что утилита vmkfstools, запущенная с ключом -K, еще и может преобразовать обычный диск (zeroedthick или eagerzeroedthick) в thin disk с вычищением нулевых блоков и, соответственно, уменьшением размера vmdk.

Некоторое время назад мы писали о средстве преобразования виртуальных машин между платформами StarWind V2V Converter, которое иногда помогает в случае необходимости конвертации виртуальных дисков VMDK->VHD и обратно.

Так вот на днях компания StarWind обновила свой V2V Converter, который обзавелся некоторыми новыми возможностями. Теперь вот что с ним можно делать:

• Свободно конвертировать диски виртуальных машин между форматами VMDK, VHD/VHDX и форматом StarWind IMG.
• При клонировании исходный диск сохраняется - и вы можете использовать его как бэкап на случай проблем с целевым виртуальным диском.
• При конвертировании в формат VHDX происходит автоматическая активация режима Windows Repair Mode, что позволяет подхватить изменения в виртуальном аппаратном обеспечении после конверсии.

Конверсия между форматами VMDK, IMG и VHD/VHDX возможна в любую сторону:

Продукт V2V Converter может понадобиться компаниям, которые используют обе платформы виртуализации от VMware и Microsoft одновременно, а также в специфических случаях. Например, когда администратор филиала сделал виртуальную машину с нужными сервисами на платформе Hyper-V, а вам ее потом нужно интегрировать в инфраструктуру VMware vSphere центрального датацентра.

Скачать последнюю версию StarWind V2V Converter можно по этой ссылке.

Как многие уже слышали, совсем недавно вышла первая версия продукта VMware VSAN, который был выпущен одновременно с релизом обновленной платформы VMware vSphere 5.5 Update 1. Многие уже принялись тестировать это решение, которое (что похвально) теперь работает производительнее своей же бета-версии и в то же время линейно масштабируется по количеству узлов ESXi с точки зрения производительности...

Интересный наброс произошел некоторое время назад в среде виртуализаторов. Оказывается, что Microsoft Exchange 2013 (который станет одним из главных почтовых серверов в ближайшем будущем) не поддерживается для размещения его в виде виртуальной машины на томах NAS / NFS. Вот такая штука - многие используют, а не знают, что это не поддерживается.

При этом NAS-хранилища SMB 3.0, появившиеся в Windows 8 и Windows Server 2012, вполне себе поддерживаются. Напомним, что NFS-протокол используют хранилища таких производителей, как Tintri, Maxta, NetApp и Nutanix.

Об этом всем можно прочитать в официальном документе "Exchange 2013 Virtualization" на TechNet:

All storage used by an Exchange guest machine for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support the use of network attached storage (NAS) volumes, other than in the SMB 3.0 scenario outlined later in this topic. 

То есть, данные Exchange (почтовые ящики, очереди и т.п.) должны храниться только на блочных хранилищах SCSI или iSCSI (block-level storage), а для файловых хранилищ, кроме SMB 3.0, поддержки нет.

В статье "NFS and Exchange - not a good combination" эксперт по инфраструктуре Microsoft Exchange Тони Рэдмонд раскрывает причину такого явления - дескать, все дело в механизме ESE (Extensible Storage database engine), используемом сервером Exchange. Блочное хранилище на базе протокола SCSI поддерживает обязательный сброс транзакции в случае сбоя, а вот файловое хранилище обеспечивает этот сброс "по мере возможности".

Для тех, кто недоволен ситуацией есть вот такая голосовалка "Support storing exchange data on VMDKs on file shares(nfs/smb)", где можно не только отдать свой голос за поддержку файловых хранилищ, но и пообщаться с экспертами на эту тему.

Роман, а вы что скажете? Когда у Exchange будет поддержка NFS, и не надо будет кастомерам рассказывать об использовании NetApp в блочном режиме?