Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Технический справочник. Хранилище

1. Обзор доменов хранения

Домен хранения - это набор образов, имеющих общий интерфейс хранения. Домен хранения содержит полные образы шаблонов и виртуальных машин (включая снимки), файлы ISO и их метаданные. Домен хранения может состоять либо из блочных устройств (SAN - iSCSI или FCP), либо из файловой системы (NAS - NFS, GlusterFS или иных POSIX-совместимых файловых систем).

В NAS все виртуальные диски, шаблоны и снимки являются файлами.

В SAN (iSCSI/FCP) каждый виртуальный диск, шаблон или снимок представляет собой логический том. Блочные устройства объединяются в логическую сущность, называемую группой томов, а затем с помощью Менеджера логических томов (Logical Volume Manager, LVM) делятся на логические тома для использования в качестве виртуальных жестких дисков.

Виртуальные диски могут иметь один из двух форматов: QCOW2 или raw. Возможные типы хранилищ: динамически расширяемые (sparse) или предварительно размеченные (preallocated). Снимки всегда имеют формат sparse , но могут создаваться для дисков любого из этих форматов.

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

2. Типы хранилищ, лежащие в основе доменов хранения

Домены хранения могут базироваться на блочном и файловом хранилищах.

Файловое хранилище

zVirt поддерживает файловые хранилища следующих типов: NFS, GlusterFS, другие POSIX-совместимые файловые системы и локальные хранилища хостов.

Управление файловым хранилищем производится извне среды zVirt. Хранилище NFS управляется NFS-сервером zVirt или другим сторонним сервером хранения, подключенным к сети.

Хосты могут управлять файловыми системами своих собственных локальных хранилищ.

Блочное хранилище

В блочном хранилище используются неформатированные блочные устройства. Блочные устройства объединяются в группы томов с помощью Менеджера логических томов (LVM). Экземпляр LVM работает на всех хостах и не знает об экземплярах, работающих на других хостах. VDSM добавляет логику кластеризации поверх LVM, сканируя группы томов на наличие изменений. Обнаружив изменения, VDSM обновляет отдельные хосты, давая им команду обновить их информацию о группе томов. Хосты делят группу томов на логические тома, записывая метаданные логических томов на диск. Если к существующему домену хранения добавляется дополнительная емкость, Менеджер управления дает команду VDSM на каждом хосте обновить информацию о группе томов.

LUN - это отдельное блочное устройство. Для подключения к LUN используется один из поддерживаемых протоколов блочных хранилищ: iSCSI или Fibre Channel. Менеджер управления управляет программными iSCSI-подключениями к LUN. Управление всеми остальными подключениями к блочному хранилищу производится извне среды zVirt. Любые изменения в блочной среде хранения (такие как создание, расширение или удаление логических томов и добавление нового LUN) обрабатываются Менеджером логических томов (LVM) на специально выбранном хосте, который называется Менеджером пула хранения (Storage Pool Manager, SPM). Затем изменения синхронизируются с помощью VDSM, метаданные хранилища которого обновляются на всех хостах в кластере.

3. Типы доменов хранения

zVirt поддерживает следующие типы доменов хранения, а также типы хранилищ, поддерживаемые каждым доменом хранения:

  • Домен данных хранит образы жестких дисков всех виртуальных машин в среде zVirt. Образы дисков могут содержать установленную операционную систему или данные, хранящиеся на виртуальной машине или сгенерированные ею. Домены хранения данных поддерживают хранилища NFS, iSCSI, FCP, GlusterFS и POSIX-совместимые хранилища. Домен данных не может использоваться несколькими центрами данных.

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

    Сущность домен экспорта считается устаревшей. Домен экспорта можно отключить от центра данных и импортировать в другой центр данных в той же или другой среде. Затем виртуальные машины, "плавающие" виртуальные диски и шаблоны можно выгрузить из импортированного домена хранения в подключенный центр данных.
  • Домен ISO ранее использовался для хранения файлов ISO. Файлы ISO - это представления физических CD или DVD. В среде zVirt используются в основном такие типы файлов ISO, как установочные диски операционных систем, приложений и гостевых агентов. Эти образы можно подключать к виртуальным машинам и загружать так же, как происходила бы загрузка при установке физического диска в дисковод.

    Домен хранения ISO является устаревшим и более не поддерживается.

4. Форматы хранения для виртуальных дисков

Хранилище виртуальной машины в формате QCOW2

QCOW2 - это формат хранения для виртуальных дисков. QCOW расшифровывается как QEMU с копированием при записи. Формат QCOW2 отделяет физический уровень хранения от виртуального уровня, добавляя сопоставление между логическими и физическими блоками. Каждому логическому блоку сопоставляется его физическое смещение, что делает возможным избыточное выделение пространства и создание снимков виртуальных машин, в которых каждый том QCOW представляет только изменения, внесенные в базовый виртуальный диск.

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

Raw

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

Формат RAW требует, чтобы все пространство заданного образа было выделено заранее, если только не используются управляемые извне LUN с динамическим выделением из массива хранения.

5. Политики выделения пространства для виртуальных дисков

Предварительно размеченное пространство

Все пространство, необходимое для виртуального диска, выделяется до создания виртуальной машины. Если для виртуальной машины создается образ диска размером 20 ГБ, то он использует 20 ГБ емкости домена хранения. Предварительно размеченный диск, как правило, обеспечивает более высокую скорость записи, поскольку не требует выполнения операции по выделению пространства, хотя это в свою очередь оборачивается потерей гибкости. Такая политика затрудняет для Менеджера управления избыточное выделение пространства. Предварительно размеченный диск рекомендуется для виртуальных машин, работающих с интенсивным вводом/выводом и чувствительных к задержкам при операциях чтения/записи. Обычно в эту категорию попадают виртуальные серверы.

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

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

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

6. Версии метаданных хранилища в zVirt

zVirt хранит информацию о доменах хранения в виде метаданных в самих доменах хранения. В каждый основной релиз zVirt входят улучшения реализации метаданных хранилища.

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

  • Мастер-домены дополнительно содержат метаданные для всех доменов и имен физических томов в пуле хранения. Общий размер этих метаданных не может превышать 2 КБ, что ограничивает количество доменов хранения в пуле.

  • Базовые образы шаблонов и виртуальных машин доступны только для чтения.

  • Метаданные V1 применимы к доменам хранения NFS, iSCSI и FC.

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

  • Имена физических томов больше не включаются в метаданные.

  • Базовые образы шаблонов и виртуальных машин доступны только для чтения.

  • Метаданные V2 применимы к доменам хранения iSCSI и FC.

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

  • Базовые образы виртуальных машин и шаблонов теперь доступны не только для чтения. Это изменение делает возможным создание снимков на лету, миграцию хранилища на лету и клонирование из снимка.

  • Добавлена поддержка метаданных Unicode для имен томов на языках, отличных от английского.

  • Метаданные V3 применимы к доменам хранения NFS, GlusterFS, POSIX, iSCSI и FC.

Метаданные V4
  • Поддержка уровней совместимости QCOW2 - формат образа QCOW включает в себя номер версии, что позволяет вводить новые функции, которые изменяют формат образа, делая его несовместимым с более ранними версиями. Более новые версии QEMU (1.7 и выше) поддерживают QCOW2 версии 3, у которой нет обратной совместимости, но есть улучшения, такие как нулевые кластеры и обеспечена повышенная производительность.

  • Новый том xleases для поддержки аренды ВМ - эта функция позволяет получать аренду для каждой виртуальной машины в общем хранилище без привязки аренды к диску виртуальной машины.

Аренда ВМ позволяет:

  • Избежать ситуации "split-brain".

  • Запустить ВМ на другом хосте, если исходный хост перестанет отвечать на запросы, тем самым повышается доступность ВМ с признаком высокой доступности.

Метаданные V5
  • Поддержка переменного выравнивания SANLOCK.

  • Поддержка новых свойств:

    • BLOCK_SIZE - хранит размер блока домена хранения в байтах.

    • ALIGNMENT - задает форматирование и размер тома xlease. (1-8 МБ). Определяется максимальным числом поддерживаемых хостов (значение указывается пользователем) и размером блока диска.

      Например, для блока в 512 байт и 2 000 хостов том xlease имеет размер 1 МБ. Для 4 КБ и 2 000 хостов - 8 МБ.

      По умолчанию максимальное количество хостов равно 250, поэтому том xlease имеет размер 1 МБ для дисков с 4-килобайтным блоком.

  • Устаревшие свойства:

    • Поля LOGBLKSIZE, PHYBLKSIZE, MTIME и POOL_UUID были удалены из метаданных домена хранения.

    • Поле SIZE (размер в блоках) было заменено полем CAP (размер в байтах).

  • Невозможно загрузиться с диска в формате 4КБ, так как загрузочный диск всегда использует эмуляцию 512 байт.

  • Формат NFS всегда использует 512 байт.

7. Автоматическое восстановление домена хранения в zVirt

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

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

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

8. Storage Pool Manager (SPM)

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

Хост, который может вносить изменения в структуру домена данных, называется Менеджером пула хранения (Storage Pool Manager, SPM). SPM координирует все изменения метаданных в центре данных, такие как создание и удаление образов дисков, создание и объединение снимков, копирование образов между доменами хранения, создание шаблонов и выделение пространства для блочных устройств. На каждый центр данных имеется один SPM. Все остальные хосты могут только читать структурные метаданные домена хранения.

Хост можно задать в качестве SPM вручную или назначить с помощью Менеджера управления. Менеджер управления назначает роль SPM, инициируя попытку потенциального хоста SPM взять на себя аренду конкретного хранилища. Аренда позволяет хосту SPM писать метаданные хранилища. Словосочетание "конкретного хранилища" означает, что факт аренды записывается в домен хранения, а не отслеживается Менеджером управления или хостами. Факт аренды конкретного хранилища записывается в специальный логический том с именем leases в домене хранения master. Метаданные о структуре домена данных записываются в специальный логический том с именем metadata. Логический том leases защищает логический том metadata от изменений.

Менеджер управления использует VDSM для выдачи команды spmStart хосту, инициируя попытку VDSM на этом хосте взять на себя аренду конкретного хранилища. В случае успеха хост получает роль SPM и сохраняет аренду конкретного хранилища до тех пор, пока Менеджер управления не потребует, чтобы роль SPM взял на себя новый хост.

Менеджер управления переносит роль SPM на другой хост в следующих случаях:

  • Хост SPM не может получить доступ ко всем доменам хранения, но может получить доступ к домену хранения master

  • Хост SPM не может продлить аренду из-за потери подключения к хранилищу или из-за того, что том аренды заполнен и операцию записи не удается выполнить

  • Хост SPM аварийно завершает работу

2.1
Рисунок 1. Эксклюзивная запись метаданных хостом SPM

9. Процесс выбора Менеджера пула хранения

Если хосту не была назначена роль Менеджера пула хранения (SPM) вручную, то процесс выбора SPM инициируется и управляется Менеджером управления.

Первым делом Менеджер управления запрашивает у VDSM подтверждение того, какой хост взял на себя аренду конкретного хранилища.

Менеджер управления отслеживает историю назначений SPM, начиная с первоначального создания домена хранения. Доступность роли SPM подтверждается тремя способами:

  • Команда getSPMstatus: Менеджер управления использует VDSM для проверки хоста, который последним имел статус SPM, и получает один из вариантов ответа: "SPM", "Состязающийся (Contending)" или "Свободный (Free)".

  • В томе метаданных для домена хранения содержится последний хост со статусом SPM.

  • Том метаданных для домена хранения содержит версию последнего хоста со статусом SPM.

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

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

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

Если назначить роль SPM на новом хосте не удастся, то Менеджер управления добавит хост в список хостов, на которых эта операция не удалась, отмечая эти хосты как неподходящие на роль SPM. Этот список очищается в начале следующего процесса выбора SPM, чтобы все хосты снова подходили на роль SPM.

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

Каждый раз, когда текущий SPM перестает реагировать на запросы или оказывается неспособен выполнять свои обязанности, Менеджер управления инициирует процесс выбора SPM.

10. Эксклюзивные ресурсы и Sanlock в zVirt

Доступ к некоторым ресурсам в среде zVirt должен предоставляться на эксклюзивной основе.

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

Ранее эксклюзивность SPM поддерживалась и отслеживалась с помощью функции VDSM, называемой safelease. Факт аренды записывался в специальную область во всех доменах хранения в центре данных. Все хосты в среде могли отслеживать статус SPM независимо от сети. Безопасная аренда VDSM поддерживала эксклюзивность только одного ресурса: роли SPM.

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

Приложения, требующие блокировки ресурсов, могут регистрироваться в Sanlock. Зарегистрированные приложения могут затем запросить у Sanlock блокировку ресурса от их имени, чтобы больше никакое приложение не смогло получить к нему доступ. Например, вместо того, чтобы блокировать статус SPM самостоятельно, VDSM теперь требует, чтобы это сделал Sanlock.

Блокировки отслеживаются в пространстве блокировки lockspace диска. Для каждого домена хранения есть одно пространство блокировки. В случае блокировки ресурса SPM работоспособность каждого хоста отслеживается в пространстве блокировки. Индикатором работоспособности хоста служит его способность обновлять свой hostid , полученный от Менеджера управления при подключении к хранилищу, и записывать через регулярные промежутки времени временную метку в пространство блокировки. Логический том ids отслеживает уникальные идентификаторы каждого хоста и обновляет свое содержимое всякий раз, когда хост обновляет свой hostid. Ресурс SPM может удерживаться только работоспособным хостом.

Ресурсы отслеживаются в логическом томе leases диска. Ресурс считается занятым, когда в его представление на диске добавлен уникальный идентификатор процесса, который его занял. В случае роли SPM ресурс SPM обновляется идентификатором хоста (hostid), который его занял.

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

Sanlock ведет мониторинг приложений, которые используют ресурсы: например, мониторинг VDSM в части статуса SPM и hostid. Если хост не может обновить свой hostid из Менеджера управления, то он теряет эксклюзивность по отношению ко всем ресурсам в пространстве блокировки. Sanlock обновляет состояние ресурса, чтобы показать, что он более не занят.

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

Если VDSM на хосте SPM не отвечает на запросы на освобождение ресурсов, то Sanlock на хосте останавливает процесс VDSM. Если остановить процесс командой kill не удается, Sanlock прибегает к эскалации, пытаясь остановить VDSM командой sigkill. Если команда sigkill не дает результата, Sanlock ждет, пока демон watchdog перезагрузит хост.

Всякий раз, когда VDSM на хосте обновляет свой hostid и записывает временную метку в пространство блокировки, демон watchdog получает pet-метку. Когда VDSM не может этого сделать, демон watchdog перестаёт получать pet-метку. Если в течение заданного периода времени демон watchdog не получил pet-метку, он перезагружает хост. Применение этого последнего уровня эскалации гарантирует, что ресурс SPM освобождается и может быть занят другим хостом.

11. Динамическое выделение и избыточное выделение пространства

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

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

Несмотря на то, что в Менеджере управления есть своя функция динамического выделения пространства, следует использовать ту функциональность динамического выделения, которую предоставляет (если предоставляет) серверная часть хранилища.

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

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

12. Расширение логического тома

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

В zVirt используется механизм динамического выделения через LVM. В случае хранилища в формате QCOW2 zVirt использует системный процесс хоста qemu-kvm для последовательного сопоставления блоков хранилища на диске с логическими блоками. Это позволяет, например, задать логический диск объемом 100 ГБ, базирующийся на логическом томе объемом 1 ГБ. Когда qemu-kvm превышает порог использования, установленный VDSM, локальный экземпляр VDSM отправляет Менеджеру пула хранения запрос на расширение логического тома еще на один гигабайт. VDSM на хосте, где запущена виртуальная машина, нуждающаяся в расширении тома, уведомляет VDSM Менеджера пула хранения о том, что ей требуется больше места. SPM расширяет логический том, а его экземпляр VDSM заставляет VDSM хоста обновлять информацию о группе томов и подтвердить, что операция расширения завершена. Хост может продолжать работу.

Для расширения логического тома не нужно, чтобы хост знал, какой другой хост выполняет роль SPM; это может быть даже сам SPM. Для обмена сообщениями о необходимости расширения хранилища используются логические тома inbox и outbox. Inbox и outbox - это выделенные логические тома в домене хранения данных. Хост, которому нужно, чтобы SPM расширил логический том, пишет сообщение в пространство inbox, выделенное для этого конкретного хоста. SPM периодически читает inbox, выполняет запрошенные расширения логических томов и пишет ответ в outbox. После отправки запроса хост проверяет входящие сообщения на наличие ответов каждые две секунды. Получив ответ об успешном выполнении его запроса на расширение логического тома, хост обновляет карту логического тома в инструменте сопоставления устройств, чтобы увидеть вновь выделенное пространство.

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

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

13. Влияние действий в домене хранения на емкость хранилища

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

Эти три процесса влияют на слой копирования при записи (COW) в виртуальной машине без запоминания состояния. Дополнительные сведения см. в строке Без запоминания состояния (Stateless) таблицы Виртуальная машина: общие настройки в описании настроек виртуальных машин.

Создание домена хранения

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

ids              64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-ao---- 128.00m
inbox            64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 128.00m
leases           64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a-----   2.00g
master           64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-ao----   1.00g
metadata         64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 512.00m
outbox           64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a----- 128.00m
xleases          64f87b0f-88d6-49e9-b797-60d36c9df497 -wi-a-----   1.00g

Удаление домена хранения

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

Миграция домена хранения

При миграции домена хранения дополнительная емкость хранилища не используется. Дополнительную информацию о миграции доменов хранения см. в разделе Миграция доменов хранения между центрами данных в одной среде в Руководстве по администрированию.

Перемещение виртуального диска в другой домен хранения

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

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

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

Приостановка работы домена хранения

При приостановке работы домена хранения дополнительная емкость хранилища не используется.

Создание снимка виртуальной машины

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

  • При создании снимка на лету по умолчанию используются снимки памяти и создаются два дополнительных тома для каждой виртуальной машины. Первый том - это сумма памяти, видеопамяти и 200-мегабайтного буфера. Второй том содержит конфигурацию виртуальной машины размером в несколько мегабайт. При использовании блочного хранилища округление происходит до ближайшей единицы хранения (unit), которую может обеспечить zVirt.

  • При создании снимка оффлайн он изначально занимает 1 ГБ блочного хранилища и динамически расширяется вплоть до размера диска.

  • Клонирование снимка создает новый диск того же размера, что и исходный.

  • Фиксация снимка удаляет все дочерние тома в зависимости от того, где в цепочке происходит фиксация.

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

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

  • Отмена предварительного просмотра снимка удаляет временный том, созданный инструментом предварительного просмотра.

Подключение и удаление прямых LUN

Подключение и удаление прямых LUN не влияет на домен хранения, поскольку они не являются компонентом домена хранения. Дополнительные сведения см. в разделе Общие сведения о миграции между хранилищами "на лету" в Руководстве по администрированию.