VMFS, Virtual Machine File System

Дисковые ресурсы, к которым осуществляется блочный доступ, – а это локальные диски (или  другие DAS)  и LUN на системах хранения  FC и iSCSI  – ESX(i) может отформатировать в файловую  систему VMFS. Это проприетарная, закрытая файловая система от VMware, обладающая полезным под нужды виртуализации функционалом:

Q  кластерность.  VMFS  является кластерной  файловой системой.  Это озна-

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

Q  поддержка файлов  больших размеров. В разделе VMFS  могут быть расположены файлы размером до 2 Тб. Это, кстати, ограничение на размер одного диска ВМ – не больше 2 Тб минус 512 байт;

Q  VMFS является журналируемой файловой системой;

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

Создать  раздел  VMFS  достаточно  просто. Если  у нас есть видимые ESX(i)диски  (LUN) и на каком-то  из них мы хотим создать  VMFS,  то для этого идем

Configuration ? Storage ? Add Storage.

Запустится мастер. По шагам:

Мы хотим отформатировать в VMFS  какой-то  диск/LUN, а не подмонтировать NFS. Оставляем вариант «Disk/LUN» (рис. 3.23).

Затем  выбираем, на каком из LUN мы хотим создать VMFS. Нам будут пред-

ложены только те, на которых раздела VMFS еще не создано, потому что на одном LUN мы можем создать только один раздел VMFS (рис. 3.24).

Рис. 3.23. Добавление хранилища VMFS

Рис. 3.24. Выбор LUN для создания раздела VMFS

Обратите  внимание:  на этом этапе мы можем попасть в крупные неприятности, потому что в пустых незадействованных LUN в этом списке могут находиться LUN’ы с данными, но подключенные как RDM. Если мы выберем такой LUN и создадим  на нем VMFS,  то данные гостевой  ОС  будут уничтожены.  Поэтому очень важно наверняка знать адрес LUN, который  мы создали под VMFS. Идентификатором может служить номер LUN в первую очередь. Путь к LUN – так как из него можно понять, через какой контроллер ESX(i) этот LUN видит. Наконец, косвенным идентификатором может служить размер. В общем, будьте вниматель ны. К счастью, для каждого LUN мы можем указать произвольный, легкий в восприятии идентификатор – см. раздел 3.9 «Адресация SCSI».

На следующем шаге нам покажут информацию о выбранном диске.

Затем предложат ввести «Datastore Name», имя хранилища. По сути, это метка тома, которую мы затем будем видеть в интерфейсе  vSphere  Client. В ваших интересах сделать ее максимально информативной, это опять же сведет к минимуму  вероятность ошибок в будущем. Имеет смысл указать тип СХД, задачу, если LUN выделен под конкретные цели. Например, «fc_lun_db_ production». В этом имени также имеет смысл избегать пробелов и спецсимволов.

Рис. 3.25. Выбор размера блока для создаваемого раздела VMFS

Шаг Formatting – самый интересный,  см. рис. 3.25.

Здесь мы указываем  размер блока создаваемого VMFS, от этого зависит максимальный  размер  одного  файла  на этом  разделе.  По  умолчанию  предлагается размер блока в 1 Мб. При таком блоке максимальный размер файла  может быть 256 Гб. Это означает, что в таком разделе VMFS не получится расположить виртуальный диск для ВМ (файл  vmdk) размером, например, 300 Гб.

Рекомендация простая  – выбирайте  такой размер блока, чтобы диски ваших ВМ помещались.  Какого размера будут диски ваших ВМ? А это зависит от задач и нагрузки,  в общем случае сказать нельзя, это вопрос планирования. Некоторые соображения приведены  в первой главе в разделе, посвященном сайзингу.

С появлением ESX(i) версии  4.1 и функции VAAI (см. раздел  3.10)  для вас может быть важно все или некоторые  разделы VMFS  создать с одинаковым размером блока – чтобы работал механизм VAAI.

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

Обратите внимание. Несмотря на размер блока от мегабайта, при операциях чтения-записи VMFS оперирует «субблоками» размером в 64 Кб.

Если  вам нужно  удалить  раздел  VMFS,  то в этом поможет  ссылка Remove, расположенная рядом с описанной  выше Add Storage. Нажатие Remove для раздела VMFS  именно удалит раздел и все данные на нем. Если необходимо не удалять раздел, а сделать его недоступным конкретному серверу, то это делается с помощью операции LUN Masking, выполняемой на системе хранения или на сервере ESX(i).

Технические особенности VMFS

Если  посмотреть  свойства  только  что созданного  хранилища  VMFS,  то мы увидим, что несколько  сотен мегабайт  на нем сразу заняты.  Заняты они под так называемые метаданные, «metadata», описание раздела.

Сами файлы метаданных расположены в корне раздела:

Q  .fdc.sf – file descriptor system file;

Q  .sbc.sf – sub-block system file;

Q  .fbb.sf – file block system file;

Q  .pbc.sf – pointer  block system file;

Q  .vh.sf – volume header system file.

В этих метаданных хранится  информация о самом разделе:

Q  Block Size – размер блока;

Q  Number  of Extents – количество  расширений раздела  VMFS  (extent), то есть на какие еще LUN распространен этот том VMFS;

Q  Volume Capacity – размер раздела;

Q  VMFS Version – версия VMFS;

Q  Volume Label – метка раздела VMFS;

Q  VMFS UUID – уникальный идентификатор раздела VMFS. Просмотреть эту информацию можно командой

vmkfstools  -P  -h  /vmfs/volumes/<метка  тома  VMFS>

Обратите внимание. Метаданные раздела VMFS занимают  тем больше, чем больше сам раздел. Как максимум метаданные могут занимать до 1200 Мб на разделе.

Еще в метаданных  хранится  информация о файлах на разделе. О том, что они существуют, о том, какие блоки под них выделены, о том, с какого сервера они открыты.

Важный момент здесь в следующем.

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

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

Но если необходимо внести изменения в метаданные, то для внесения изменений LUN отдается в монопольное пользование серверу, который вносит изменения.  Делается это с помощью команды Reservation (блокировка) протокола SCSI 2.

SCSI Reservation происходит при:

Q  включении  и выключении ВМ – потому что в метаданных надо прописать, что файлы этой ВМ теперь открыты или закрыты;

Q  создании файлов. Это такие операции, как создание виртуальной машины

или шаблона, клонирование ВМ, Storage  VMotion и миграция выключенной виртуальной машины на другое хранилище, добавление диска ВМ, создание снимков состояния;

Q  удалении файла;

Q  смене владельца файла;

Q  установке метки времени последнего обращения/изменения;

Q  увеличении  раздела VMFS;

Q  изменении размера  файлов  – а это происходит  регулярно при работе ВМ со снимков состояния и если ее диски (файлы vmdk) находятся  в формате thin.

Файлы  изменений (*-delta.vmdk)  снимков   состояния  растут  блоками  по 16 Мб. Тонкие диски увеличиваются по одному блоку VMFS. Мы записали внутрь ВМ еще сколько-то  мегабайт, файл  vmdk стало необходимо  увеличить, для указания  нового размера  файла  в метаданных  раздела  произошел  SCSI reservation. Затем vmdk-файл еще увеличился, SCSI reservation повторился. И так далее.

И что может получиться: на одном VMFS расположен десяток ВМ, все работают на разных серверах, у всех снимки состояния.  И каждый раз, когда у какой-то  ВМ надо увеличить размер файла-дельты, происходит SCSI reservation, и какое-то маленькое  время (обычно  ~10 миллисекунд) девять других серверов с этим LUN не работают, потому что десятый вносит изменения в метаданные. Разово эта операция вообще нестрашна и нормальна. По данным VMware, и при средней нагрузке негативный эффект  на производительность от этих блокировок  нулевой.  Но в граничных случаях, когда на одном хранилище много ВМ, у всех диски растущие и эти ВМ работают  на многих  разных  серверах,  мы можем  недополучить  часть производительности LUN.

Вывод: лучше стараться избегать постоянной работы при существующих снимках состояния (snapshot) для производственных ВМ, а если для каких-то из них это необходимо – стараться держать их на отдельных LUN от тех производственных ВМ, которым особенно важна производительность дисковой подсистемы.

Отследить потери производительности из-за регулярных блокировок  мы можем, проанализировав соответствующий журнал. Это файл /var/log/vmkernel, где мы можем отследить произошедший «reservation conflict»:

Apr 24 15:59:53  esx35-1  vmkernel:  5:14:57:01.939  cpu0:1083)StorageMonitor: 196: vmhba1:0:3:0  status = 24/0  0x0 0x0 0x0

Apr 24 15:59:53  esx35-1  vmkernel:  5:14:57:01.939 cpu0:1041)SCSI:  vm  1041:  109:  Sync CR at 64

Apr 24 15:59:56  esx35-1  vmkernel:  5:14:57:04.982  cpu0:1151)StorageMonitor: 196: vmhba1:0:3:0  status = 24/0  0x0 0x0 0x0

Apr 24 15:59:56  esx35-1  vmkernel:  5:14:57:04.982 cpu3:1041)SCSI:  vm  1041:  109:  Sync CR at 16

Apr 24 15:59:56  mel-esx-02  vmkernel:  5:14:57:05.050  cpu0:1161)StorageMonitor: 196: vmhba1:0:3:0  status = 24/0  0x0 0x0 0x0

Apr 24 15:59:57  esx35-1  vmkernel:  5:14:57:06.047 cpu3:1041)SCSI:  vm  1041:  109:  Sync CR at 0

Apr 24 15:59:57  esx35-1  vmkernel:  5:14:57:06.047 cpu3:1041)WARNING:  SCSI: 119:  Failing I/O  due to  too  many  reservation conflicts

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

Сделать  расширение раздела  (extent) из нескольких  LUN, где первый LUN будет небольшим,  порядка  2 Гб. Тогда  на нем не будет  файлов-дисков ВМ  (не влезут),  а останутся  только метаданные. И блокировки SCSI не будут оказывать  влияния на скорость работы виртуальных машин на прочих LUN.

Также на VMFS есть так называемый «Heartbeat Region». В этой области серверы периодически обновляют  записи с целью сообщить о своей работоспособно сти. Если сервер вышел из строя или потерял связь с хранилищем и своевременно  не обновил свою запись, блокировки файлов этим сервером считаются недействи тельными.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий