Почему загрузка файлов на 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

Nicira Virtualization Platform. NVP Manager

В третьей части мы обратим всё свое внимание на NVP Manager, который позволит провести дальнейшую настройку NVP.

Роль NVP Manager
NVP была разработана так чтобы интегрироваться с самыми разнообразными платформами управления облаком (CMP) с помощью набора «северных» API. Фактически эти REST API реализованы в контроллерах NVP, а не NVP Manager. Менеджер предоставляет вэб интерфейс, используемый для следующих задач:

Добавление гипервизоров
Добавление транспортных нод (шлюзы и сервисные ноды)
Настройку транспортных зон
Сбор информации и отладка

NVP Manager ориентирован на настройку, а не обеспечение работоспособности NVP. Другими словами – данный компонент вы будете использовать для управления компонентами платформы NVP – шлюзами, гипервизорами, но фактическое использование возможностей NVP, создание логических сетей, логических маршрутизаторов и тому подобное, будет происходить из CMP через вызовы к REST API к контроллерам. Таким образом, я буду использовать NVP Manager для выполнения некоторых задач, которые должны выполняться в CMP, но просто потому что под рукой у меня нету CMP.

Итак, разобравшись с ролью данного компонента перед к процессу установки и настройки.

Corrupt дисковой системы. Что делать?

Рассмотрим ситуацию: достоверно известно, что случился corrupt на уровне дисковой системы. Битые сектора или что-то еще - не столь важно. Сверху живет VMFS и виртуальные машины, но в ВМ вроде ничего не случилось, они продолжают работать.
В этой ситуации вполне может быть, что битая область вообще не затрагивает ВМ и все данные остались целыми. Так что же сделать, чтобы свести риски к минимуму?

1. Выключаем затронутые ВМ.
2. Клонируем ВМ на заведомо исправный датастор.
3. Включаем клоны, запускаем проверку целостности файловой системы в каждой ВМ. Можно использовать встроенные средства ОС или использовать любой Rescue CD.

Зачем выключать? При дальнейшей работе, в особенности в случае машин с тонкими дисками и снапшотами, можем затронуть битую область и соотв. ВМ приходит в негодность.
Обратите внимание, что ВМ именно клонируем, а не перемещаем. И тем более не делаем Storage vMotion, иначе есть риск остаться наедине с резервной копией. В случае если она вообще есть.

Nicira Virtualization Platrform. Контроллеры NVP

Во второй части цикла о платформе виртуализации сети от VMware я расскажу о контроллерах. Напомню, что они нужны для расчёта сетевой топологии, распространения настроек и создания логических сетей и логики распространения трафика внутри неё. Для этого контроллеры на «южную» сторону, Open vSwitch (OVS) устройства, распространяют необходимую информацию, полученную с «северного» NVP API, чем обеспечивают соответствие между логическими сетями, согласно данным полученным NVP API и транспортной сетью, обеспечиваемой программируемыми виртуальными пограничными устройствами.

Детальнее это выглядит так:

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

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

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

Итак, разобравшись с ролью контроллеров перейдём к процессу сборки контроллеров.