Почему загрузка файлов на VMFS такая медленная?

Мы все видели это множество раз - залить файл на VMFS датастор занимает слишком много времени. Например, ISO с образом Windows 7 заливается 10 минут на iSCSI, и менее минуты на NFS. Оба датастора не имеют проблем и достаточно быстрые, на обоих работают ВМ.

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

Один из путей подтверждения этого - статистика VAAI для дисковых массивов с поддержкой VAAI, или статистика SCSI reservation для массивов без. В качестве простейшего примера можно использовать gzip большого vmdk файла на VMFS датасторе (множество маленьких операций чтения и записи). Даже для VAAI будет видно множество запросов ATS и ZERO:

ATS ATSF ZERO ZERO_F MBZERO/s
42052 3 61370 0 5.72

Заключаем, что gzip блокирует ресурсный блок, заполняет нулями, а затем копирует содержание. То же самое происходит при загрузке файла на VMFS как из GUI, так и из командной строки.

Автор: Cormac Hogan

Производительность СХД. Часть третья

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

Физическая адресация

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

Размер блока и раздела VMFS

На днях к виртуальной машине (vCenter 4.1, ESX4.1) подключаю RDM-раздел и получаю ошибку "File[Name Datastore]nameVM.nameVM.vmdk is larger than the maximum size supported by datastore Name Datastore".
Ищу на http://kb.vmware.com/, получаю знание 1029697, где говорится правильно выбирайте VMFS block size. Вижу, где прокол (см. максимумы). Ограничение относится к VMFS.
Но самое интересное, что за год до этого на ESX 3.5 удалось подключить раздел размером 1TB, а виртуальная машина была на таком же VMFS-разделе, и после обновления на 4.1 прекрасно работает.. Возможно, дело в версии hardware виртуальной машины (как-нибудь проверю). Но вопрос не в этом. До этого случая я никогда не обращал внимание на вопрос выбора размера блока VMFS и создавал datastore по умолчанию (block size 1MB). Обозначилась необходимость понимать, на что влияют размер блока, размер раздела, и учитывать это при планировании хранилища.

VMFS: FC & iSCSI

Недавно задали вопрос: можно ли расшарить VMFS на хосты по разным протоколам? Т.е. к одному и тому же LUN'у один хост обращается по Fiber Channel, а второй по iSCSI.

Согласно официальному документу "EMC CLARiiON Integration with VMware ESX":

VMware VMotion is supported with Fibre Channel and iSCSI connectivity to CLARiiON storage systems. Furthermore, VMware VMotion is supported in configuration where both of the following occur:
* A single LUN is presented to two VMware ESX server nodes.
* The ESX server nodes are in a cluster in which one node accesses the LUN via FC and the other node accesses the LUN via iSCSI.
CLARiiON storage systems preserve the LUN HLU number across both protocols. Therefore, when a LUN is presented via FC to one host and iSCSI to another, a false snapshot is not detected.

Иными словами, при использовании систем EMC CLARiiON / VNX это возможно. Кстати, документ очень интересен с технической точки зрения и рекомендуется к прочтению, даже если у вас система не EMC.

Влияние различных размеров блока VMFS

На одном из форумов VMTN написали о неожиданном влиянии единого размера блока для всех томов VMFS. Пользователь произвел обнуление неиспользуемого пространства, чтобы диски скомпрессировались при Storage vMotion. Сюрпризом стало то, что диски остались того-же самого размера и после Storage vMotion.

После нескольких тестов было обнаружено, что при Storage vMotion между массивами, или между датасторами с различными размерами блока VMFS диски компрессировались. Почему?
Ответ прост: в этом случае используется другой datamover (модуль перемещения данных). Поскольку вам это мало о чем говорит, объясню какие бывают datamover'ы:

• fsdm - самый старый datamover, с минимумом функций и самый медленный, поскольку данные проходят по всему стеку.
• fs3dm - был включен в состав vSphere 4.0 и содержал некоторые значительные изменения, позволяющие данным проходить не все уровни стека.
• fs3dm – hardware offload – datamover с поддержкой VAAI, аппаратной интеграции операций ввода/вывода с массивом. Появился в vSphere 4.1, имеет максимальную производительность и минимальные накладные расходы.

Так в чем же проблема? А проблема в одной маленькой строке текста в VAAI FAQ:

• The source and destination VMFS volumes have different block sizes

Как только выбирается датастор с другим размером блока, или датастор на другом массиве - гипервизор переключается на fsdm. Одно из немногих преимуществ этого datamover'а в том, что он "съедает" нули. В то время как fs3dm, вне зависимости от software / hardware offload, этого не делает и копирует блоки целиком.

Источник: Duncan Epping (yellow-bricks.com)

Отказоустойчивое хранилище для vSphere на базе StarWind iSCSI

Ранее я уже писал о том, как сделать дешевое разделяемое хранилище для vSphere на базе Linux. Но что если вы хотите избавиться от единой точки отказа и сделать разделяемое хранилище отказоустойчивым? Можно поднять второй узел с Linux и прикручивать различные пакеты для отказоустойчивости, как например drbd и heartbeat. А можно обратить внимание на коммерческую разработку компании StarWind, и получить решение Enterprise класса.

Кстати, в марте при помощи StarWind iSCSI SAN был поставлен рекорд в 1 000 000 (!) IOPS.

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

Чтобы такого не случалось, появилась функция HA - непрерывная синхронная репликация данных между узлами и поддержка multipathing.

Итак, вы скачали StarWind iSCSI и что теперь с ним делать? Я расскажу.

Как устроен VMFS раздел

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

Подробности об устройстве VMFS - здесь.

ESX3.5 u4: пропал VMFS datastore

В некоторых случаях, как утверждают на форуме VMware, в основном если используются SATA контроллеры, может пропасть локальный VMFS datastore при обновлении до 3.5 u4.

В большинстве случаев пожет следующая программа действий

1. Откройте вкладку "Configuration" в VI Client
2. Advanced Settings
3. В разделе LVM, измените LVM.EnableResignature на 1 (по умолчанию 0)
4. Для локального контроллера сделайте "Rescan"
5. Он может появиться под иным "дружественным именем", но в остальном ничего не изменится.
6. Установите EnableResignature обратно в 0
7. Вручную добавьте VMX обратно в inventory.

Проблемы переезда VI

Перечень проблем при переезде VI в одной из компаний. Принимал непосредственное участие в решении.

• После включения VI, луны с VMFS оказались заблокированными.

Выглядит на практике это примерно так:

Nov 14 13:29:43 frasvmhst06 vmkernel: 0:00:03:34.249 cpu4:1045)WARNING: SCSI: 5519: Failing I/O due to too many reservation conflicts
Nov 14 13:29:43 frasvmhst06 vmkernel: 0:00:03:34.249 cpu4:1045)WARNING: SCSI: 5615: status SCSI reservation conflict, rstatus 0xc0de01 for vmhba2:0:0. residual R 919, CR 0, ER 3
Nov 14 13:29:43 frasvmhst06 vmkernel: 0:00:03:39.086 cpu4:1045)FSS: 343: Failed with status 0xbad0022 for f530 28 2 453782fc 6b8bc9e9 1700770d 1d624ca 4 4 1 0 0 0 0 0

Лечение:

[root@esx2 root]# vmkfstools -L lunreset /vmfs/devices/disks/vmhba2:0:0

• Не штатная проблема. После включения ESX хостов, у меня не оказалось DataStore's. LUN'ы видны, а DataStore нет. А точнее луны пустые.

Лечение описано в предыдущем посте.

Пропал VMFS раздел - что делать?

Бывает, случается непредвиденное. Скажем, глобальный переезд оборудования. Все выключили корректно, все сохранили. Поставили на новом месте, подключили, включаем, а VMFS разделы исчезли. И виртуальных машин соответственно тоже не видно. Хотя все LUN'ы видны.
Причем если начать создавать новый VMFS раздел на этих LUN'ах, будет указано, что они пустые и никакого VMFS там нет (только осторожнее с этим, не нажмите случайно "создать"). Если при переезде не были физически убиты диски и ничего страшного не случилось, то скорее всего немножко слетело разбиение разделов, которое можно быстро и просто поправить.

Уточним ситуацию (все манипуляции производятся с ESX сервера).
Определяем какой именно раздел надо править.

[root@esx2 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/cciss/c0d0
vmhba1:0:1 /dev/sda
vmhba1:0:15 /dev/sdb
vmhba1:0:16 /dev/sdc
vmhba1:0:23 /dev/sdd
vmhba1:0:26 /dev/sde
vmhba1:0:27 /dev/sdf

[root@esx2 root]# fdisk /dev/sda

The number of cylinders for this disk is set to 127482.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 1048.5 GB, 1048577048064 bytes
255 heads, 63 sectors/track, 127482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Система не видит ни одного раздела, значит ей надо помочь.

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-127482, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-127482, default 127482):
Using default value 127482

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fb
Changed system type of partition 1 to fb (Unknown)

Command (m for help): x

Expert command (m for help): b
Partition number (1-4): 1
New beginning of data (63-2047998329, default 63): 128

Expert command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

[root@esx2 root]# vmkfstools -V

Теперь проверяем, VMFS раздел должен появиться.

!!! Внимание !!!
Все манипуляции необходимо проводить на снапшоте LUN'а, если есть поддержка данной функциональности на вашей SAN.
Первое, что необходимо сделать после восстановления доступа к VMFS разделу со снапшота - полный бэкап всех виртуальных машин (ну или только особо нужных) путем простого копирования. И только после этого можно проводить операцию на "живом" LUN'е.

P.S. у вас до сих пор не настроены бэкапы?

Невозможность создать VMFS Datastore

Бывает, при переключении уже использовавшихся где-то LUN'ов на дисковом массиве к ESX'ам возникает ошибка: "Unable to read partition information from this disk"

Решение:
[root@esx2 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/cciss/c0d0
vmhba1:0:1 /dev/sda
...
vmhba2:2:13 /dev/sdt

[root@esx2 root]# fdisk /dev/sdt

Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 36643.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Теперь можно создавать VMFS Datastore.