Формат qcow2 что это

Русские Блоги

Управление дисками виртуальной машины KVM, управление снимками и клонирование виртуальных машин-04

Введение в формат KVM-диска

Типы виртуальных дисков, поддерживаемые KVM: raw, qcow2

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

Поддержка увеличения и уменьшения емкости диска

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

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

После разговора о форматах raw и qcow2 давайте разберемся с форматом диска vmdk

Создавать диски в формате raw и qcow2

Создать диск в формате raw, формат, используемый kvm по умолчанию

]# qemu-img create /kvm/data/rawtest-01.raw 5G
Formatting ‘/kvm/data/rawtest-01.raw’, fmt=raw size=5368709120
[[email protected]

]# qemu-img info /kvm/data/rawtest-01.raw
image: /kvm/data/rawtest-01.raw
file format: raw
virtual size: 5.0G (5368709120 bytes)
disk size: 0

Создать диск формата qcow2

]# qemu-img info /kvm/data/qcow2-test01.qcow2
image: /kvm/data/qcow2-test01.qcow2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false

Затем мы изменяем файл конфигурации виртуальной машины, и виртуальная машина вызывает файл диска qcow2

Запускаем виртуальную машину Centos7.4-01
В настоящее время мы можем удалить файлы в необработанном формате диска предыдущей виртуальной машины.

Управление снимками виртуальной машины

Создавайте снимки с использованием необработанного формата диска

[[email protected] data]# virsh snapshot-create vmtest02
Ошибка: неподдерживаемая конфигурация: внутренний моментальный снимок для диска vda не поддерживается для типа хранилища raw
При создании снимка это сообщение указывает на то, что формат текущей виртуальной машины является необработанным, и формат диска необходимо преобразовать в формат qcow2

Создайте снимок, используя формат диска qcow2
Следует отметить, что после создания снимка дисковое пространство станет больше, потому что снимок будет занимать дисковое пространство, поэтому это внутренний снимок. После завершения создания будет создано имя снимка, этот снимок Имя создается на основе метки времени Unix.
Формат синтаксиса: virsh snapshot-create

Посмотреть список снимков

Удалить указанный снимок

Источник

RAW, QCOW2, LVM — что выбрать?

Статья была написана 21 ноября 2010 г. Перенесена из старого блога.

На сегодняшний день технологии виртуализации способны решать широкий круг задач. Начиная от консолидации серверов заканчивая облочными вычислениями и виртуализацией рабочих мест.
Одним из преимуществ виртуализации является то, что виртуальные машины «отвязаны» от физического железа на котором они работают. Во многих статьях посвященных виртуализации можно встретить подобную фразу «Виртуальные машины — это обычные файлы которые можно просто скопировать на любой другой физический сервер и без проблем запустить!». В действительности, так и есть. Но у многих, как и у меня в свое время возник вопрос, какой же из форматов этих «обычных файлов» выбрать?

Краткое описание форматов

На мой взгляд, для машин работающих в KVM-окружении самыми популярными и практически востребованными форматами дисков, являются; RAW, QCOW2 и LVM-тома.

LVM(Logical Volume Manager) — LVM-тома представляют собой блочные устройства такие же как дисковае разделы или диски целиком и очень часто используются вместо образов дисков или совместно.
Основным преимуществом LVM-томов является производительность, большая чем у RAW-дисков, гибкость масштабирования, поддержка снапшотов без остановки гостевой системы. Размер LVM-тома можно легко увеличеть или уменьшить. С помощью снапшотов можно получить доступ к файловой системе виртуальной машины и делать бекап данных не останавливая гостевую систему. LVM-тома не подвержены фрагментации.
К минусам LVM-томов можно отнести затруднительность переноса LVM-тома между несколькими физическими машинами а так же не самая простая настройка для начинающих.

Практическое использование.

На самом деле каждый из описанных форматов очень хорош а где то и лучше своих конкурентов. Я считаю, что нельзя отрекаясь от всех использовать только один единственный формат для решения всех поставленных задач.
Например для домашней тестовой лаборатории или для небольшой организации с 1,2-мя физическими серверами без общего хранилища, где не критична производительность идеально подойдет QCOW2. Здесь QCOW2 позволит с экономить дисковое пространство и позволит с легкостью и за меньшее время перемещать образы виртуальных машин между физическими. Например с сервера на сервер по витой паре, из дома на работу на флешке или даже по Интернету. Стоит добавить, что использование снапшотов очень полезно в домашней лаборатории.
Напротив, в условия где нужна максимальная производительность и высокая доступность виртуальных машин(24×7), гибкость управления ресурсами и «живой» бекап должны использоваться только LVM-тома. Будь то в рамках единого сервера или в сети из 10-ка серверов с единым сетевых хранилище типа NAS, SAN приимущества LVM-томов очевидны. В данном случае нет необходимость в перемещении образов дисков так как используется единое хранилище, бекап данных по средствам снапшотов или агентов в виртуальных машинах выполняется на выделенный сервер. Вся инфраструктура заточена на максимальную производительность.
Ну и RAW, как я уже говорил универсальный формат. На мой взгляд он наиболее подходит в относительно бюджетных системах, где в место высокопроизводительных сетевых хранилищ используют NFS-сервера, но при этом хотят выжать как можно больше из дисковой подсистемы.
Так же очень эффективно использование RAW-дисков в организациях использующих виртуальные рабочие столы и без дисковые клиенты вместо классических рабочих станций. В таких ситуациях используется большое количество различных образов, с различными операционными системами, и динамическое их перемещение.

В общем форматов много, и все они разработаны не зря!

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

Источник

VMmanager: Сравнение производительности локальных хранилищ

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

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

Компания ISPsystem еще в начале марта 2013 анонсировала выход нового программного продукта для управления виртуализацией — VMmanager. Решение адаптировано как для хостинга виртуальных машин, так и для построения облака.

Параметры fio были следующие:

Тестирование чтения:
[readtest]
blocksize=128k
filename=/dev/vdb
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=16

Тестирование записи:
[writetest]
blocksize=128k
size=100%
filename=/dev/vdb
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=16

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

Для тестирования создавался виртуальный диск размером 50000 МБ. Размер взят не случайно. Как наиболее ходовой размер диска для виртуальных серверов. Все диски к виртуальным машинами подключались с использование драйвера virtio. Паравиртуальные драйвера (virtio) используются при работе с основными устройствами в виртуальном окружении. Использование этих драйверов в общем случае повышает производительность виртуальной дисковой подсистемы. Эти драйвера присутствуют в ядре Linux начиная с 2.6.25 версии.

При первом способе тестирования использовался sda4 (на котором позже и создавался как LVM, так и диски для виртуальных машин) с добавлением в параметрах fio — size=50G.

Для тестирования при втором способе создавалась LVM группа томов, и в этой группе LVM раздел размером 500000 МБ, как для виртуальной машины.

При тестировании хранилища DIR c форматами RAW и Qcow2 сами образы дисков располагались в виде файлов в файловой системе ext4 в директории /vm.

В пятом способе тестирования делался один проход и заполнение диска “нулями” не проводилось. Так как интересовала производительность как раз сразу после создания снимка файловой системы.

Источник

Расширение файла QCOW2

QEMU Copy-On-Write

Что такое файл QCOW2?

QCOW2 суффикс имени файла в основном используется для QEMU Copy-On-Write файлов. David T Reynolds определил стандарт формата QEMU Copy-On-Write. QCOW2 файлы поддерживаются программными приложениями, доступными для устройств под управлением Linux, Windows. QCOW2 файл относится к категории Другие файлы так же, как #NUMEXTENSIONS # других расширений файлов, перечисленных в нашей базе данных. Qemu Manager поддерживает QCOW2 файлы и является наиболее часто используемой программой для обработки таких файлов, но 1 могут также использоваться другие инструменты. Программное обеспечение Qemu Manager было разработано David T Reynolds, и на его официальном веб-сайте вы можете найти дополнительную информацию о файлах QCOW2 или программном обеспечении Qemu Manager.

Программы, которые поддерживают QCOW2 расширение файла

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

Программы, обслуживающие файл QCOW2

Как открыть файл QCOW2?

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

Шаг 1. Установите Qemu Manager программное обеспечение

Шаг 2. Проверьте версию Qemu Manager и обновите при необходимости

Если проблемы с открытием файлов QCOW2 по-прежнему возникают даже после установки Qemu Manager, возможно, у вас устаревшая версия программного обеспечения. Проверьте веб-сайт разработчика, доступна ли более новая версия Qemu Manager. Может также случиться, что создатели программного обеспечения, обновляя свои приложения, добавляют совместимость с другими, более новыми форматами файлов. Это может быть одной из причин, по которой QCOW2 файлы не совместимы с Qemu Manager. Последняя версия Qemu Manager должна поддерживать все форматы файлов, которые совместимы со старыми версиями программного обеспечения.

Шаг 3. Назначьте Qemu Manager для QCOW2 файлов

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

Выбор приложения первого выбора в Windows

Выбор приложения первого выбора в Mac OS

Шаг 4. Проверьте QCOW2 на наличие ошибок

Если проблема по-прежнему возникает после выполнения шагов 1-3, проверьте, является ли файл QCOW2 действительным. Отсутствие доступа к файлу может быть связано с различными проблемами.

Если QCOW2 действительно заражен, возможно, вредоносное ПО блокирует его открытие. Немедленно просканируйте файл с помощью антивирусного инструмента или просмотрите всю систему, чтобы убедиться, что вся система безопасна. QCOW2 файл инфицирован вредоносным ПО? Следуйте инструкциям антивирусного программного обеспечения.

2. Убедитесь, что файл с расширением QCOW2 завершен и не содержит ошибок

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

3. Проверьте, есть ли у пользователя, вошедшего в систему, права администратора.

Некоторые файлы требуют повышенных прав доступа для их открытия. Переключитесь на учетную запись с необходимыми привилегиями и попробуйте снова открыть файл QEMU Copy-On-Write.

4. Убедитесь, что в системе достаточно ресурсов для запуска Qemu Manager

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

5. Убедитесь, что ваша операционная система и драйверы обновлены

Современная система и драйверы не только делают ваш компьютер более безопасным, но также могут решить проблемы с файлом QEMU Copy-On-Write. Возможно, файлы QCOW2 работают правильно с обновленным программным обеспечением, которое устраняет некоторые системные ошибки.

Вы хотите помочь?

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

Источник

Глава 4. Системы хранения

Содержание

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

Сопоставление локальных и совместно используемых хранилищ

Типы образов виртуального диска

Поддерживаемые Proxmox типы хранения

Варианты совместного хранения коммерческие и свободно распространяемые

FreeNAS как вариант совместного хранилища с низкой стоимостью

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

Сопоставление локального хранилища с совместно используемым

Совместное используемое хранилище не является чем- то абсолютно необходимым в Proxmox, однако несомненно, оно делает управление хранением более простой задачей. В какой- то небольшой бизнес- среде может быть вполне допустимым не иметь времени работы в режиме 24/7 со 100% надёжностью, поэтому какой- то локальной системы хранения может оказаться вполне достаточно. В большинстве корпоративных виртуальных сред с критически важными данными совместно используемые хранилища сегодня являются единственным логичным выбором благодаря тем преимущества, которые они привносят во всю работу кластера. Ниже перечислены общепризнанные преимущества применения совместного хранилища:

Миграция виртуальных машин в реальном времени

Бесшовное расширение пространства хранения со множеством узлов

Централизованное резервное копирование

Многоуровневое кэширование данных

Централизованное управление хранением

Миграция виртуальных машин в реальном времени

Вероятно, это одна из самых важных пользующихся спросом причин для перехода на совместно используемые системы хранения. Миграция в реальном времени ( Live migration ) это когда некая виртуальная машина может перемещаться на другой узел без её предварительного останова. Миграция в отключённом состоянии ( Offline migration ) это когда данная виртуальная машина выключается перед осуществлением её перемещения. Имеющиеся оборудование и операционные системы узлов Proxmox нуждаются в обновлениях, исправлениях, а также замене время от времени. Некоторые обновления требуют немедленной перезагрузки, в то время как прочие обходятся без неё. Основной задачей узлов Proxmox является исполнение виртуальных машин. Когда некий узел требует перезагрузки, все работающие в нём виртуальные машины должны быть остановлены либо осуществить миграцию на иные узлы. Затем, после того как первоначальный узе выполнит полный цикл отключения- включения, выполняется обратная миграция. В Proxmox некая включённая ВМ не может выполнить свою миграцию в реальном времени без её предварительного отключения если она расположена на локальном диске в запрашиваемом узле. Если вдруг по любой причине происходит полный отказ узла Proxmox, все те ВМ, которые хранятся на этом узле будут полностью недоступными пока этот узел не будет исправлен или заменён. Это происходит по той причине, что доступ к этим ВМ не может быть перемещён на другой узел пока не будет включён такой проблемный узел.

В большинстве случаев отключение всех имеющихся ВМ для простой перезагрузки их хоста не является допустимым вариантом. В таком случае слишком длительное время простоя зависит от общего числа обслуживаемых данным хостом ВМ. Для выполнения миграции локально хранимых ВМ они должны быть вначале остановлены и после этого миграция должна быть инициирована из GUI Proxmox. Миграция с одного локального хранилища на другое локальное хранилище отнимает много времени, которое зависит от общего размера самой ВМ, так как Proxmox перемещает файл образа целиком с применением rsync для размещения этой ВМ на другом узле. Давайте взглянем на следующую схему кластера с 40 локально хранимыми ВМ, с размещением по 10 на каждом из четырёх узлов Proxmox:

Рисунок 4-1

В приведённой выше чрезвычайно упрощённой схеме присутствуют четыре узла Proxmox с 10 виртуальными машинами в каждом из них. Если node 01 потребует перезагрузки для применения обновлений, все его 10 виртуальных машин должны быть остановлены, так как сам узел нуждается в перезагрузке, а затем все эти виртуальные машины должны быть выключены. Если же node 01 полностью отказал, все его 10 виртуальных машин будут недоступными пока node 01 не вернётся обратно вновь.

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

Рисунок 4-2

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

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

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

Следует обратить внимание, что совместное хранилище может стать единой точкой отказа в случае, когда установлено некое решение хранения с единственным узлом в основе, таким как FreeNAS или NAS4Free без настроек с высокой доступностью. Применение совместно используемых хранилищ со множеством узлов или распределённых, например, Ceph, Gluster или DRBD, может исключить единую точку отказа. При совместном хранении данных на единственном узле все виртуальные машины находятся на одном узле. Если возникает ситуация отказа этого узла, данное хранилище становится недоступным для кластера Proxmox, что приводит к невозможности использования всех исполняемых виртуальных машин.

В Proxmox VE 5.0, контейнеры LXC не могут выполнять миграцию в реальном времени. Они должны выключаться для фиксации миграции в выключенном состоянии. ВМ KVM могут выполнять миграцию в реальном времени.

Бесшовное расширение пространства хранения со множеством узлов

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

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

Централизованное резервное копирование

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

Для целей резервного копирования всегда применяйте отдельный узел. Хранения и самой виртуальной машины и её резервной копии не будет мудрым решением.

Многоуровневое кэширование данных

Многоуровневость данных является подходом, при котором различные файлы могут содержаться в различных пулах хранения на основе их требований к производительности. К примеру, виртуальный файловый сервер может предоставлять очень быстрое обслуживание если его ВМ содержатся в некотором пуле на SSD, в то время как виртуальный сервер резервных копий может располагаться на более медленных хранилищах HDD, так как файлы резервного копирования не часто подвержены доступу и, следовательно, не требуют очень быстрого I/O. Множество уровней может быть установлено с применением различных узлов совместного хранилища с различными уровнями производительности. Оно также может быть настроено в рамках одного и того же узла путём выделения томов или пулов в особые наборы дисков.

Централизованное управление хранением

Отделяя кластеры совместного хранения от основного кластера Proxmox, мы можем управлять двумя кластерами без их взаимного воздействия друг на друга. Поскольку совместно используемые системы хранения могут быть установлены с отдельными узлами и физическими коммутаторами, управление ими на основе различных авторизаций и полномочий становится более простой задачей. NAS, SAN и прочие типы решений совместного хранения поступают со своими собственными программами управления, в которых администратор или оператор может проверять жизнеспособность хранилищ кластера, состояние дисков, свободное пространство и тому подобное. Хранилище Ceph настраивается посредством CLI, однако Proxmox интегрировал большую часть опций управления Ceph вовнутрь GUI Proxmox, что делает более простым управление кластером Ceph. Применяя имеющийся API Proxmox может теперь собирать все данные кластера Ceph и отображать из с помощью GUI Proxmox, как это показано на приводимом ниже снимке экрана:

Рисунок 4-3

Другие решения NAS, такие как FreeNAS, OpenMediaVault и NAS4Free также имеют GUI, которые упрощают управление. Представленный ниже снимок экрана является примером отображения состояний жёстких дисков в окне GUI FreeNAS/

Рисунок 4-4

Сравнение локального и совместно используемого хранилищ

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

Таблица 4-1.

Миграция ВМ в реальном времени

Да, когда применяется в распределённой системе хранения

Производительность ввода/ вывода

Естественная скорость дисковых устройств

Медленнее чем скорость натуральных дисковых устройств

Не требуются никакие особые знания хранилищ

Необходим опыт использования опций совместных хранилищ

Ограничена доступными отсеками для дисков

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

Фактически не требует сопровождения

Узлы или кластеры хранения требуют постоянный мониторинг.

Образ виртуального диска

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

Поддерживаемые форматы образов

Рисунок 4-5

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

Свойство	Локальное хранилище	Разделяемое хранилище

Таблица 4-2.

Допускает динамичное виртуальное хранение файлов образов.

Стабильное и безопасное.

Совместно с типами образа присутствует большинство функций.

Сложные форматы файлов с дополнительными программными уровнями.

Высокие накладные расходы ввода/ вывода.

LVM, RBD, iSCSI и каталоги

Не требуется дополнительный программный уровень. Прямой доступ к файлам образов.

Стабильный, безопасный и самый быстрый.

Только фиксированные файла образов.

Не может применяться для хранения динамичных образов.

ВМ требуется более длительное резервное копирование из- за больших размеров файлов образов.

Ожидаемо хорошо работает с инфраструктурой VMware.

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

Только фиксированные файлы образов.

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

Не окончательно протестирован с Proxmox.

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

Динамичное выделение осуществляется когда имеющийся файл образа виртуального диска не выделяет предварительно все требуемые блоки, тем самым сдерживая общий размер такого файла образа только тем, что требуется. По мере того, как дополнительные данные сохраняются в этой виртуальной машине, файл образа с динамическим выделением растёт пока не достигает установленного максимума выделяемого размера. С другой стороны полное выделение (thick provisioning) выполняется таким образом, что при предварительном размещении данного файла образа виртуального диска выделяются все требуемые блоки, тем самым создавая некий файл образа, который имеет в точности установленным свой размер при его создании.

Типы виртуальных устройств

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

Тип образа	Поддерживаемые хранилища	Сильные стороны	Слабые стороны

Таблица 4-3.

Из всех четырёх поддерживаемых типов шин, именно шина VirtIO предоставляет самую максимальную производительность почти во всех случаях. Образы диска VirtIO распознаются Linux без какой- либо дополнительной работы во время установки ОС. Однако, при установке в ВМ Windows устройства VirtIO не распознаются. Необходимо добавлять дополнительное устройство VirtIO во время установки Windows. Позже в этой главе мы рассмотрим практические приёмы применения шины VirtIO с ОС Windows.

Управление образами дисков

Файл виртуального образа Proxmox может управляться как из WebGUI, так и через CLI. WebGUI позволяет своему администратору применять опции добавления, изменения размера (только в сторону увеличения), перемещения, дросселирования и удаления, как это отображено на снимке экрана ниже:

Рисунок 4-6

Тип шины/ устройства	Максимум допустимых

Таблица 4-4.

Создаёт файл образа

Преобразовывает файл образа

#qemu-img resize test.qcow2 +1024M

Изменяет размер файла образа

Изменение размера виртуального диска

Опция Resize disk поддерживает только увеличение имеющегося размера файла образа виртуального диска. Она не имеет никакой функции усечения. Данная опция Proxmox Resize disk регулирует только имеющийся размер файла образа виртуального диска. После любого изменения размера сам раздел должен быть отрегулирован внутри данной ВМ. Самый безопасный способ изменения размера раздела состоит в загрузке виртуальной машины на основе Linux с неким образом ISO с определёнными разделами, например, GParted (http://gparted.org/download.php), с последующим изменением имеющихся разделов с применением графического интерфейса GParted. Также имеется возможность осуществления изменения размера раздела в реальном времени при его включённой виртуальной машине. Изменение размера файла образа виртуального диска заключается в следующих трёх этапах:

Изменение размера файла образа виртуального диска в Proxmox:

Из CLI : Исполните следующую команду:

Измените размер раздела своего файла образа виртуального диска изнутри данной ВМ:

Для ВМ Linux с разделами RAW : Исполните следующую команду:

Для ВМ Linux с разделами LVM : Исполните следующую команду:

Для ВМ Linux с разделами QCOW2 : Исполните следующие команды:

Измените размер файловой системы в данном разделе своего файла образа виртуального диска:

Для клиентов Linux с разделами LVM : Исполните следующие команды:

Для использования 100% свободного пространства : Исполните следующие команды:

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

Перемещение образа виртуального диска

Move disk делает возможным перемещение определённого файла образа в другое хранилище или преобразование в другой тип образа:

Рисунок 4-7

Кликнув по Delete source вы удалите соответствующий исходный файл образа после завершения его перемещения.

Рисунок 4-8

Дросселирование образа виртуального диска

Рисунок 4-9

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

Как уже упоминалось ранее, мы можем устанавливать предел на основе МБ/с или IOPS. Установка предела в МБ/с является намного более простой, так ака нам гораздо легче оценивать скорость чтения/ записи дискового устройства или сети в Мегабайтах. К примеру, стандартное дисковое устройство SATA может достигать теоретической скорости в 115 МБ/с, в то время как гигабитная сетевая среда может достигать порядка 100 МБ/с. Знание производительности IOPS, или ОП/с потребует неких дополнительных этапов. В ряде систем хранения мы можем встраивать некий виды мониторинга, которые могут снабжать нас данными IOPS в реальном масштабе времени. Для прочих нам придётся вычислять необходимые данные IOPS чтобы узнать соответствующую матрицу производительностей применяемых системой хранилищ. Все подробности вычисления значений IOPS выходят за рамки данной книги. Однако приводимое далее руководство должно послужить нам отправной точкой для вычисления ОП/с различных устройств хранения:

ОП/с для отдельного диска SATA 7200 rpm:

Приводимый ниже снимок экрана показывает, что результатом ioping для усреднённой латентности является 1.79 миллисекунд, или 0.00179 секунд:

Рисунок 4-10

Чтобы определить среднее время позиционирования, нам следует выполнить такую команду ioping :

Приводимый далее снимок экрана показывает, что результатом ioping для усреднённого значения позиционирования является время 133 микросекунд или 0.000133 секунды:

Рисунок 4-11

Воспользовавшись достигнутыми результатами мы можем вычислить IOPS или ОП/с для своего устройства SSD следующим образом:

Если нам известно сколько IOPS может предоставлять носитель хранения, мы можем настраивать каждую ВМ дросселированием ОП/с для предотвращения возможных проблем в своём кластере. В Proxmox VE 4.1 у нас не было возможности устанавливать пределы дросселирования по всему кластеру. Каждый диск требует отдельного дросселирования вручную.

Кэширование образа виртуального диска

Рисунок 4-12

В Proxmox VE 5.0 доступны следующие опции кэширования:

Команда	Функция

Таблица 4-5.

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

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

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

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

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

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

Тип шины VirtIO для ВМ Windows

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

Вначале, выгрузите необходимые драйверы VirtIO для Windows в формате ISO со следующей ссылки: https:/​/​fedoraproject.​org/​wiki/​Windows_​Virtio_​Drivers.

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

Установка драйверов VirtIO в процессе установки Windows

В своём первом методе мы можем загрузить драйверы VirtIO в процессе загрузки Windows, воспользовавшись следующими шагами:

При создании своей ВМ Windows добавьте два CD/ DVD устройства. Первое из них должно загружать установщик Windows, а второе служит для загрузки соответствующего образа ISO VirtIO.

Запустите установку Windows и кликните по Load driver как это показано в следующем снимке экрана:

Рисунок 4-13

Рисунок 4-14

Выберите нужный вам драйвер и продолжите обычную установку Windows.

Установка драйверов VirtIO после установки Windows

Данный метод полезен когда Windows уже установлена в ВМ и вам требуется преобразовать имеющиеся образы дисков IDE/ SATA в VirtIO вид. В данном подходе драйвер VirtIO необходимо загрузить прежде чем сам основной образ диска ОС преобразовывается в такой тип шины VirtIO. приводимые ниже шаги показывают как изменить имеющийся тип шины основного образа диска ОС Windows после того, как Windows уже была установлена в диск, не являющийся VirtIO:

Создайте небольшой дополнительный образ диска.

Зарегистрируйтесь в Windows и загрузите соответствующий образ ISO диска VirtIO.

Установите драйверы с тем, чтобы этот дополнительный образ диска VirtIO распознался и был настроен Windows.

Остановите Windows, измените тип основного образа диска ОС на тип VirtIO и удалите дополнительный образ диска.

Типы хранилищ в Proxmox

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

Каталог

Рисунок 4-15

Для монтируемого локально хранилища выбор флага Shared не является обязательным. Данный вариант относится только к совместно используемым хранилищам, таким как NFS и RBD.

iSCSI

Для получения дополнительных сведений по iSCSI воспользуйтесь следующей ссылкой: http://en.wikipedia.org/wiki/ISCSI

Рисунок 4-16

Отметим, что непосредственное использование LUN не рекомендуется, хотя и имеется вариант их разрешения. Известны варианты, вызывающие ошибки iSCSI при прямом подключении.

Logical Volume Management ( LVM ) предоставляют метод выделения пространства хранения путём применения одного или более разделов или устройств в качестве лежащих в основе хранилищ. Хранилище LVM требует наличия установки и надлежащей работы некоторого лежащего в его основе хранилища.Мы можем создать хранилище LVM с помощью локального устройства в качестве основополагающего, либо сетевого устройства, расположенного на устройствах iSCSI. LVM делает возможным масштабирование пространства хранения, так как само базовое хранилище может находиться на самом том же самом узле, либо на некотором отличном от него. Хранилище LVM поддерживает только формат образов виртуальных дисков RAW. В LVM хранилище мы можем размещать только образы виртуальных дисков или контейнеры.

Для получения дополнительных подробностей об LVM воспользуйтесь ссылкой: http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux).

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

Рисунок 4-17

Следует с осторожностью применять в Proxmox версию 4 NFS вместо версии 3. Всё ещё имеются некоторые ошибки из NFSv4, такие как тревога ядра при запуске системы при монтировании соответствующего совместного ресурса NFSv4.

Конкретный сервер NFS может быть настроен просто поверх дюбого дистрибутива Linux с последующим его подключением к кластеру Proxmox. Совместный ресурс NFS является ни чем иным, как просто точкой монтирования в вашем сервере NFS, которая считывается подключаемым модулем NFS Proxmox. Также вы можем применять FreeNAS для работы в качестве такого сервера NFS и тем самым предоставляя все преимущества FreeNAS и его GUI для более простого мониторинга и совместного использования хранилища. Благодаря простоте настройки NFS, это вероятно наиболее широко применяемый вариант хранения в сегодняшнем мире виртуализации. Почти все сетевые администраторы применяли какой- нибудь сервер NFS хотя бы раз в своей карьере.

На следующем снимке экрана мы подключаем некое хранилище NFS с названием nfs-01 172.16.2.10 :

Рисунок 4-18

В Proxmox VE 4.1 встраиваемый модуль хранилища ZFS уже включён, что существенно усилило применение ZFS естественным образом в узлах кластера Proxmox. Пул ZFS поддерживает следующие типы RAID:

Пул RAID-0 : требует по крайней мере один диск.

Пул RAID-1 : требует по крайней мере двух дисков.

Пул RAID-10 : требует по крайней мере четыре диска.

Пул RAIDZ-1 : требует по крайней мере три диска.

Пул RAIDZ-2 : требует по крайней мере четыре диска.

Для определения хранилища ZFS применяет пулы. Пулы могут быть созданы только через CLI. В Proxmox VE 5.0 не существует опций управления ZFS через GUI. Все операции создания и управления ZFS следует осуществлять через CLI. После того как необходимые пулы создан, они могут подключаться к proxmox через GUI Proxmox. Для нашего примера мы намереваемся создать пул зеркала RAID1 с названием zfspool1 и подключить его к Proxmox. Для создания такого пула ZFS применяется следующая команда:

Следовательно, для создаваемого нами определённого пула команды выглядит так:

Для допустимых типов RAID доступны следующие опции:

Опция кэшировнаия	Описание

Таблица 4-6.

Для проверки того, что наш пул создан, исполните следующую команду:

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

Рисунок 4-19

Мы можем применять этот пул напрямую или мы можем создать некий набор данных (dataset) внутри такого пула и подключить такой набор данных к Proxmox отдельно как некоторое индивидуальное хранилище. Преимущество такого подхода состоит в изоляции отдельных типов хранимых данных в своих наборах данных. Например, если мы создаём некий набор данных для размещения образов данных и другой набор данных для сохранения файлов резервных копий, мы можем включить сжатие для своего набора данных образов ВМ и в то же самое время воздерживаться от сжатия своего набора данных, содержащего резервные копии, поскольку сами файлы резервных копий уже сжаты, и тем самым сбережём значительные ресурсы. Всякий набор данных ZFS может настраиваться индивидуально, со своим собственным набором опций настроек. Если мы сравним zpool с неким каталогом, наборы данных будут сродни подкаталогам внутри своего основного каталога. Для создания некоего набора данных внутри пула ZFS применяется следующая команда:

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

Для осуществления сжатия в этом наборе данных мы можем выполнить следующую команду:

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

Такой процесс монтирования и издания в совместное использование необходимо осуществлять исключительно через CLI. Из GUI Proxmox мы можем только подключать имеющийся совместный ресурс NFS с лежащим в его основе пулом ZFS. Для того, чтобы выполнять обслуживание такого совместного ресурса NFS нам следует установить требуемый сервер NFS в этом узле Proxmox воспользовавшись такой командой:

В код /etc/exports введите следующую строку:

Запустите полученную службу NFS применив следующую команду:

Рисунок 4-20

Комбинируя создаваемые пулы ZFS с неким совместным ресурсом NFS мы можем создавать некий разделяемый ресурс, хранения с полным набором свойств ZFS, тем самым создавая достаточно гибкое совместное хранилище для его применения во всех имеющихся в данном кластере узлах Proxmxox. Применяя данную технику, мы можем создать некий узел резервного копирования, который также управляется через GUI Proxmox. Таким образом, при возникновении кризиса узлов, мы сможем также выполнить временную миграцию ВМ в имеющийся узел резервных копий. Все предыдущие шаги применимы к к любому дистрибутиву Linux, а не только к некоторому узлу Proxmox. Например, мы можем установить некий сервер ZFS+NFS при помощи Linux Ubuntu или CentOS для хранения образов или шаблонов виртуальных дисков. Если вы применяете FreeNAS или аналогичную систему хранения, тогда все приводимые в данном разделе шаги по сопровождению ZFS вам не потребуются. Весь процесс создания ZFS выполняется при помощи GUI FreeNAS/

Ceph RBD

В версии 4.1 Proxmox сервер Ceph был интегрирован в Proxmox для совместного существования в одном и том же узле. Также была добавлена возможность управления кластерами Ceph через GUI Proxmxox. Позднее, в следующей главе, мы изучим как создавать кластер Ceph и интегрировать его с Proxmox. Ceph является истинной системой хранения корпоративного уровня с некоторой зависимостью от обучения. Когда механика Ceph становится понятной, его сопровождение будет более простым. Для получения дополнительных сведений по Ceph отсылаем вас к http://ceph.com/docs/master/start/intro/. Некоторые сведения приводятся в Главе 5, Установка и настройка Ceph. < Прим. пер.: также рекомендуем наши переводы Книга рецептов Ceph, 2е издание, Изучаем Ceph, 2е издание, Полное руководство Ceph, Книга рецептов Ceph, Изучаем Ceph. >

GlusterFS

GlusterFS является мощной распределённой файловой системой, которая может масштабироваться до нескольких Петабайт в единой точке монтирования. Glustar является сравнительно новым добавлением в Proxmox, которое позволило пользователям GlusterFS воспринять все преимущества кластера Proxmox. GlustarFS применяет для хранения файлов чередование, репликацию или распределённый режим. Хотя распределённый режим и предлагает наличие опции масштабирования, отметим, что в режиме с чередованием при выходе из строя какого- то узла GlusterFS все файлы в таком сервере становятся недоступными. Это означает, что если определённый файл сохраняется транслятором GlusterFS в данном сервере, только этот узел хранит все данные такого файла. Даже несмотря на то, что все прочие узлы будут продолжать работать, этот определённый файл больше не будет доступен. GlusterFS может масштабироваться до Петабайт внутри единой точки монтирования. Данное хранилище GlusterFS может быть установлено всего на двух узлах и поддерживать NFS, тем самым позволяя нам сохранять любые форматы файлов образов.

Для получения дополнительных сведений по GlusterFS посетите следующую ссылку: http:/​/​docs.​gluster.​org/​en/​latest/.

Мы можем установить GlusterFS в том же самом узле, что и Proxmox, либо в некотором удалённом узле, применив только дистрибутив Linux для создания некоего совместного хранилища. Gluster является великолепным вариантом для некоторой стабильной системы хранения из двух узлов, такой как DRBD. Самое основное отличие состоит в том, что он может выполнять горизонтальное масштабирование для увеличения общего пространства [хранения. Gluster может быть исключительным выбором для виртуальной среды со скромным бюджетом и требованиями избыточности. При установке с двумя узлами оба узла осуществляют синхронизацию друг с другом и, в случае если один из узлов становится недоступным, другой узел просто принимает всё на себя. Сама установка Gluster достаточно сложна.

Для информации о том, как устанавливать кластер GlusterFS посетите следующую ссылку: http://gluster.readthedocs.org/en/latest/Quick-Start-Guide/Quickstart/.

Рисунок 4-21

Следующая таблица отображает те типы информации, которые нам понадобятся и значения, применяемые для нашего примера подключения GlusterFS:

Источник

• ← Шотландия что нужно для поездки
• Уборка на кухне закончилась семья села ужинать что значит →

Тип RAID	Применяемая строка опции