Технический справочник

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

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

К среде zVirt подключены один или несколько хостов. Хост — это сервер, который предоставляет физическое оборудование, используемое виртуальными машинами.

На хосте работает оптимизированная среда исполнения zVirt Node, предназначенная для создания хостов виртуализации.

В zVirt используется централизованная СХД для виртуальных дисков, шаблонов, снимков и файлов ISO. Хранилище логически сгруппировано в пулы хранения, которые состоят из доменов хранения. Домен хранения объединяет в себе емкость хранилища и метаданные, которые описывают внутреннюю структуру хранилища (См. раздел Типы доменов хранения):

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

Сетевая архитектура zVirt обеспечивает связь между разными элементами среды zVirt. Сетевая архитектура не только поддерживает сетевое подключение, но и позволяет разделять сети.

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

Центр данных — это высший уровень абстракции в zVirt. В центре данных содержится три вида информации:

У центров данных и кластеров zVirt есть версия совместимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступ к некоторым ресурсам в среде 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 освобождается и может быть занят другим хостом.

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

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

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

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

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

В 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, Менеджер пула хранения автоматически распределяет дополнительное пространство между логическими томами, которые в нем нуждаются. Автоматическое выделение дополнительных ресурсов позволяет соответствующим виртуальным машинам автоматически продолжать работу без перерыва либо возобновить работу после остановки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На канальном уровне (уровень 2) zVirt позволяет конфигурировать bond-интерфейсы Linux, чтобы подключаться к сетям VLAN и задавать MTU для сетевых интерфейсов. Эти сети могут быть доступны сразу нескольким виртуальным машинам через мосты Linux.

В случае SR-IOV можно настроить количество виртуальных функций и их сопоставление с логическими сетями.

Протокол FCoE управляет своими собственными сетями VLAN. Сети VLAN, управляемые протоколом FCoE, используются исключительно для доступа к хранилищу. Они невидимы для Менеджера управления и всех виртуальных машин.

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

Можно настроить DNS-резолвер, который используется хостом.

Можно также управлять ролями сети и QoS.

В zVirt виртуальные сетевые карты виртуальных машин могут подключаться к следующим типам сетей:

На следующей схеме представлена структура этих трех подходов, где:

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

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

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

Сетевые карты, мосты Linux и виртуальные сетевые карты обеспечивают сетевое взаимодействие между хостами, виртуальными машинами, локальными сетями и сетью Интернет. При желании можно реализовать bond-интерфейсы и сети VLAN для повышения безопасности, отказоустойчивости и пропускной способности сети.

Сетевая карта (NIC) - это сетевой адаптер или адаптер LAN, который подключает компьютер к компьютерной сети. Сетевая карта работает как на физическом, так и на канальном уровне машины и обеспечивает сетевое подключение. На каждом хосте виртуализации в среде zVirt есть как минимум одна сетевая карта, хотя чаще их две или больше.

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

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

Пользовательские свойства могут задаваться для подключения как по мосту, так и по Ethernet. VDSM передает определение настроек сети и пользовательские свойства хуку скрипта настройки сети.

Виртуальные сетевые карты (vNIC) — это виртуальные сетевые интерфейсы, основанные на физических сетевых картах хоста. У каждого хоста может быть несколько сетевых карт, и каждая сетевая карта может быть базой для нескольких vNIC.

При подключении vNIC к виртуальной машине Менеджер управления создает несколько ассоциаций между виртуальной машиной, к которой подключена vNIC, самой vNIC и сетевой картой физического хоста, на которой базируется vNIC. Так, когда vNIC подключена к виртуальной машине, новая vNIC и MAC-адрес создаются на сетевой карте физического хоста, на которой базируется vNIC. Как только виртуальная машина запускается первый раз после подключения этой vNIC, libvirt назначает PCI-адрес для vNIC. Затем MAC-адрес и PCI-адрес используются для получения имени vNIC (например, eth0) на виртуальной машине.

Процесс назначения MAC-адресов и ассоциирования этих MAC-адресов с PCI-адресами несколько отличается при создании виртуальных машин на основе шаблонов или снимков:

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

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

Консольный вывод команды отображает несколько устройств: одно loopback-устройство (lo), одно Ethernet-устройство (eth0), одно беспроводное устройство (wlan0), одно фиктивное устройство VDSM (;vdsmdummy;), пять bond-устройств (bond0, bond4, bond1, bond2, bond3) и один сетевой мост (ovirtmgmt).

Все vNIC входят в устройство сетевого моста и логическую сеть. Членство в мосте может быть отображено с помощью команды brctl show:

Консольный вывод команды brctl show показывает, что vNIC virtio - члены моста ovirtmgmt. Все виртуальные машины, с которыми ассоциированы vNIC, подключены к логической сети ovirtmgmt. Сетевая карта eth0 также является членом моста ovirtmgmt. Устройство eth0 подключено к коммутатору, который обеспечивает подключение за пределами хоста.

VLAN (виртуальная локальная сеть) - это атрибут, применимый к сетевым пакетам. Сетевые пакеты могут быть "тегированы" в пронумерованную сеть VLAN. VLAN - функция безопасности, используемая для изоляции сетевого трафика на уровне коммутатора. Сети VLAN отделены друг от друга и являются взаимоисключающими. Менеджер управления знает о VLAN и может тегировать и перенаправлять трафик, но для реализации VLAN требуется коммутатор, поддерживающий VLAN.

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

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

Метка сети — это метка в виде читаемого текста, которую можно подключить к логической сети или сетевому интерфейсу физического хоста. При создании метки руководствуйтесь следующими правилами:

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

Сетевые объекты на уровне кластера включают в себя:

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

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

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

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

zVirt поддерживает следующие типы логических сетей:

Логические сети определяются на уровне центра данных.

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

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

Опциональная сеть - это логическая сеть, которая не была явно обозначена как Обязательная (Required). Опциональные сети можно реализовать только на использующих их хостах. Наличие или отсутствие опциональных сетей не влияет на статус работоспособности (Operational status) хоста. Когда необязательная сеть становиться неработоспособной, виртуальные машины, работающие в этой сети, не переносятся на другой хост, что позволяет избежать избыточных операций ввода/вывода, связанных с массовой миграцией. Обратите внимание, что при создании логической сети и добавлении ее в кластеры флажок Обязательная (Required) стоит по умолчанию.

Чтобы изменить обозначение сети как Обязательной (Required), на Портале администрирования в разделе Сеть перейдите в подраздел Сети, выберите нужную сеть, откройте вкладку Кластеры (Clusters) и нажмите кнопку Управление сетью (Manage Network).

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

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

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

Зеркалирование портов включается или выключается в профилях vNIC логических сетей и имеет следующие ограничения:

Учитывая вышеуказанные ограничения, рекомендуется включить зеркалирование портов на дополнительном выделенном профиле vNIC .

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

К основным типам сетевых конфигураций относятся:

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

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

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

Варианты выбора:

Работоспособный изолирующий прокси-хост имеет статус либо Включен (UP) , либо Обслуживание (Maintenance) .

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

Серверы HP должны использовать ilo3 или ilo4, серверы Dell — drac5 или интегрированные контроллеры удаленного доступа Dell (Integrated Dell Remote Access Controllers) (idrac), а серверы IBM — ipmilan. Интегрированный модуль управления IMM использует протокол IPMI, следовательно пользователям этого модуля доступно ipmilan.

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

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

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

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

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

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

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

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

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

SSH Soft Fencing - это процесс, когда Менеджер управления пытается по SSH перезапустить VDSM на хостах, не реагирующих на запросы. Если Менеджеру управления не удается перезапустить VDSM по SSH, то задача изоляции возлагается на внешний агент изоляции, если он настроен.

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

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

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

Если на хосте определены два агента изоляции, их можно настроить на параллельное или последовательное использование.

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

Проверка доступных ресурсов происходит в трех случаях:

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

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

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

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

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

У подходящего хоста должно быть достаточно свободной памяти и ресурсов ЦП, чтобы удовлетворить требования виртуальной машины, которая будет запущена на нем или перемещена на него. Виртуальная машина не запустится на хосте с перегруженным ЦП. По умолчанию ЦП хоста считается перегруженным, если нагрузка на него превышает 80% в течение 5 минут, но эти значения можно изменить с помощью политик планирования. Если подходит несколько хостов, то один из них будет выбран согласно политике балансировки нагрузки для кластера. Например, если действует политика "Равномерное распределение" (Evenly_Distributed), то Менеджер управления выбирает хост с наименьшей загрузкой ЦП. Если действует политика "Энергосбережение" (Power_Saving), то будет выбран хост с наименьшей загрузкой ЦП и попадающий в диапазон между максимальным и минимальным уровнями обслуживания. Статус SPM конкретного хоста также влияет на то, насколько хост подходит для запуска новых или приема перемещаемых виртуальных машин. В качестве приемника предпочтительнее хост без статуса SPM, например, первая виртуальная машина, запущенная в кластере, не будет запускаться на хосте SPM, если роль SPM принадлежит хосту в этом кластере.

Дополнительную информацию см. в разделе Политики планирования руководства администратора.

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

По умолчанию при миграции виртуальных машин действуют следующие ограничения:

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

Менеджер управления взаимодействует с сервером каталогов для:

Аутентификация - это проверка и идентификация стороны, которая сгенерировала те или иные данные, и целостности этих данных.

Принципал - сторона, чья личность проверяется.

Верификатор - сторона, требующая подтверждения личности принципала. В случае zVirt Менеджер управления - это верификатор, а пользователь - принципал.

Целостность данных - это гарантия того, что полученные данные совпадают с данными, сгенерированными принципалом.

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

В процессе установки локальный внутренний домен автоматически настраивается на администрирование среды zVirt. После завершения установки можно добавить еще домены.

В процессе установки Менеджер управления создает ограниченный внутренний домен администрирования. Этот домен отличается от домена AD или IdM, поскольку он существует на основе ключа в БД PostgreSQL, входящей в zVirt, а не как пользователь службы каталогов на сервере каталогов. Внутренний домен отличается и от внешнего тем, что в нем будет только один пользователь: admin@internal. Такой подход к первоначальной аутентификации позволяет попробовать zVirt без использования полнофункционального сервера каталогов и обеспечивает наличие административной учетной записи, необходимой для устранения любых проблем с внешними службами каталогов.

Пользователь admin@internal предназначен для начального конфигурирования среды, в которое входит установка хостов и включение их в домен, добавление внешних доменов аутентификации AD или IdM и делегирование разрешений пользователям из внешних доменов.

В zVirt под удаленной аутентификацией понимается аутентификация, обрабатываемая удаленной службой, а не Менеджером управления. Удаленная аутентификация используется для подключения пользователей или API к Менеджеру управления, инициируемых из домена AD, IdM или RHDS.

Администратор должен настроить Менеджер управления с помощью инструмента ovirt-engine-extension-aaa-ldap-setup, чтобы сделать его частью домена RHDS, AD или IdM. Для этого нужно, чтобы Менеджеру управления были выданы учетные данные для учетной записи из сервера каталогов RHDS, AD или IdM для домена с достаточными привилегиями для включения системы в домен. После добавления доменов Менеджер управления может аутентифицировать пользователей домена на сервере каталогов по паролю. Менеджер управления использует фреймворк "Уровень простой аутентификации и безопасности (Simple Authentication and Security Layer, SASL)", который, в свою очередь, использует Общий API сервисов безопасности (Generic Security Services Application Program Interface, GSSAPI) для безопасной проверки личности пользователя и определения доступного ему уровня авторизации.

Среда zVirt предлагает администраторам инструменты, упрощающие предоставление виртуальных машин пользователям, а именно шаблоны и пулы. Шаблон - это ярлык, который позволяет администратору быстро создать новую виртуальную машину на основе существующей и уже настроенной виртуальной машины, минуя установку и настройку операционной системы. Это особенно полезно для виртуальных машин, которые будут использоваться как прикладное решение (например, для виртуальных веб-серверов). Если в организации используется много экземпляров конкретного веб-сервера, администратор может создать виртуальную машину для использования в качестве шаблона, установив операционную систему, веб-сервер, любые вспомогательные пакеты и применив уникальные изменения конфигурации. Затем администратор может создать на основе работающей виртуальной машины шаблон, который будет использоваться для создания новых идентичных виртуальных машин по мере необходимости.

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

Чтобы создать шаблон, администратор создает виртуальную машину и выполняет ее индивидуальную настройку. Устанавливаются нужные пакеты, применяются индивидуальные настройки, и виртуальная машина подготавливается к целевому использованию, чтобы минимизировать изменения, которые придется вносить в нее после развертывания. Необязательным (но рекомендуемым) шагом перед созданием шаблона из виртуальной машины является генерализация. Генерализация призвана удалить такие сведения, как имена пользователей системы, пароли и информацию о часовом поясе, которые изменятся при развертывании. Генерализация не влияет на индивидуальные настройки. Генерализация гостевых машин Windows и Linux в среде zVirt обсуждается в статье Шаблоны в Руководстве пользователя. Для генерализации гостевых машин Linux используется virt-sysprep. Для генерализации гостевых машин Windows используется sys-prep.

Когда виртуальная машина, являющаяся основой для шаблона, удовлетворительно настроена, генерализирована (если нужно) и остановлена, администратор может создать из нее шаблон. При создании шаблона из виртуальной машины создается доступная только для чтения копия специально настроенного виртуального диска. Образ, доступный только для чтения, выступает в качестве базового для всех создаваемых впоследствии виртуальных машин, основанных на этом шаблоне. Иными словами, шаблон - это по сути индивидуально настроенный виртуальный диск, доступный только для чтения, с соответствующей конфигурацией виртуального оборудования. Оборудование виртуальных машин, созданных из шаблона, можно менять (например, выделить 2 ГБ ОЗУ виртуальной машине, созданной из шаблона с 1 ГБ ОЗУ). Однако виртуальный диск шаблона нельзя изменить, так как это приведет к изменению всех виртуальных машин на основе этого шаблона.

После создания шаблона его можно использовать как основу для множества виртуальных машин. При создании виртуальной машины из заданного шаблона можно выбрать тип выделяемого диска - тонкий (thin) или клонированный (clone). Виртуальные машины, клонируемые из шаблонов, используют полную копию базового образа шаблона, допускающую запись. Хотя они и не экономят место (в отличие от динамического выделения), зато не зависят от наличия шаблона. Виртуальные машины, создаваемые из шаблона способом динамического выделения, используют образ из шаблона, доступный только для чтения, в качестве базового образа. При этом требуется, чтобы шаблон и все созданные на его основе виртуальные машины хранились в одном домене хранения. Изменения данных и вновь сгенерированные данные сохраняются в образе с возможностью копирования при записи. Каждая виртуальная машина на основе шаблона использует один и тот же базовый образ, доступный только для чтения, а также уникальный для виртуальной машины образ с возможностью копирования при записи. Это экономит пространство за счет ограничения числа копий идентичных данных, хранящихся в хранилище. Кроме того, при частом использовании базового образа, доступного только для чтения, данные, к которым производится обращение, могут начать кэшироваться, что выльется в чистый рост производительности.

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

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

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

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

Термины "том COW" и "слой COW" используются взаимозаменяемо, однако "слой" точнее отражает временный характер снимков. Каждый снимок создается для того, чтобы администратор смог отменить неудовлетворительные изменения, внесенные в данные после его создания. Снимки обеспечивают функциональность, аналогичную функции Отменить (Undo), присутствующей во многих текстовых процессорах.

Три основные операции с снимками:

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

Снимки жестких дисков виртуальных машин, помеченных как общие (shareable), а также тех, которые основаны на подключении Прямых LUN (Direct LUN), нельзя сделать ни "на лету", ни как-либо иначе.

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

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

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

Виртуальные машины с установленным гостевым агентом, поддерживающим "заморозку", могут обеспечить согласованность файловой системы по всем снимкам. Зарегистрированные гостевые машины Linux могут устанавливать qemu-guest-agent, чтобы включить "заморозку" перед созданием снимков.

Если во время создания снимка на виртуальной машине присутствует гостевой агент, совместимый с "заморозкой", то VDSM использует libvirt для связи с агентом, чтобы подготовиться к созданию снимка. Незавершенные операции записи завершаются, после чего файловые системы "замораживаются" перед созданием снимка. Когда создание снимка завершено и libvirt переключает виртуальную машину на новый том для выполнения операций записи на диск, файловая система "размораживается" и запись на диск возобновляется.

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

В zVirt первоначальный снимок виртуальной машины отличается от последующих снимков тем, что первоначальный снимок сохраняет свой формат: либо QCOW2, либо RAW. Первый снимок виртуальной машины использует существующие тома в качестве базового образа. Дополнительные снимки - это дополнительные слои COW, отслеживающие изменения, которые после создания предыдущего снимка были внесены в данные, хранящиеся в образе.

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

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

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

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

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

Завершив предварительный просмотр снимка, администратор может выбрать Отменить (Undo), чтобы удалить слой предварительного просмотра снимка. Слой, содержащий сам снимок, сохраняется, несмотря на удаление слоя предварительного просмотра.

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

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

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

Назначенные виртуальному оборудованию PCI-адреса сохраняются в базе данных ovirt-engine.

QEMU назначает PCI-адреса при создании виртуальной машины, а libvirt передает их в VDSM. VDSM передает их обратно Менеджеру управления, где они и хранятся в базе данных ovirt-engine.

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

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

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

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

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

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

Одна гостевая машина может иметь несколько сетевых карт. Каждая добавляемая сетевая карта занимает свободный PCI-слот гостевой машины.

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

На Портале администрирования можно выбрать Тип видео (Video Type):

Выбор типа видео влияет на доступность соответствующих графических протоколов. В zVirt 4.X сопоставление видео - протокол следующее:

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

Доступны два эмулируемых звуковых устройства:

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

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

Гостевые машины, использующие драйвер балунинга, могут помечать разделы ОЗУ гостевой машины как неиспользуемые (уменьшение выделяемой области). Гипервизор может освобождать память и использовать ее для других процессов хоста или других гостевых машин на этом хосте. Когда гостевой машине снова потребуется освобожденная память, гипервизор может снова выделить ОЗУ гостевой машине (увеличение выделяемой области).

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