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

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

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

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

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

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

В приведённой выше схеме все наши 40 виртуальных машин находятся в какой- то совместно используемой системе хранения. Сам узел Proxmox содержит только необходимые файлы настроек для каждой виртуальной машины. В таком сценарии в случае, когда node 01 будет нуждаться в перезагрузке из- за исправлений безопасности или обновлений, все его виртуальные машины могут просто мигрировать на другой узел без выключения отдельной виртуальной машины. Пользователь виртуальной машины никогда не заметит что его виртуальная машина на самом деле перемещена на другой узел. При полном отказе некоторого узла Proxmox все файлы настроек его виртуальных машин могут быть просто вручную перенесены из /etc/pve/nodes/node01/qemu-server/<vmid>.conf в /etc/pve/nodes/node02/qemu-server/<vmid>.conf.

Так как все файлы настроек виртуальных машин расположены в pmxcfs (Proxmox clustered file system, Кластеризованной файловой системе Proxmox), доступ к ним может осуществляться с любого другого узла. Для ознакомления с подробностями pmxcfs обратитесь к Главе 3, Под капотом Proxmox. При расположении файлов образов виртуальных машин на совместно используемом хранилище нет необходимости перемещать все образы файлов с применением rsync с одного узла на другой, что делает миграцию виртуальных машин существенно более быстрой.

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

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

Цифровые данные в нашем сегодняшнем подключённом в режиме 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, как это показано на приводимом ниже снимке экрана:

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

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

Таблица 4-1.

Свойство	Локальное хранилище	Разделяемое хранилище
Миграция ВМ в реальном времени	Нет	Да
Высокая доступность	Нет	Да, когда применяется в распределённой системе хранения
Стоимость	Низкая	Существенно выше
Производительность ввода/ вывода	Естественная скорость дисковых устройств	Медленнее чем скорость натуральных дисковых устройств
Требования навыков	Не требуются никакие особые знания хранилищ	Необходим опыт использования опций совместных хранилищ
Расширяемость	Ограничена доступными отсеками для дисков	При применении множества узлов или распределённых хранилищ расширяется добавлением узлов или стоек.
Сложность сопровождения	Фактически не требует сопровождения	Узлы или кластеры хранения требуют постоянный мониторинг.

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

Proxmox поддерживает форматы виртуальных дисков .raw, .qcow2 и .vmdk. Каждый из форматов имеет свои сильные и слабые стороны. Необходимый формат образа обычно выбирается исходя из самого назначения виртуальной машины, применяемой системы хранения, требований производительности и доступного бюджета. Приводимый ниже снимок экрана приводит то меню, в котором мы можем делать выбор типа образа в процессе создания диска с помощью GUI:

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

Таблица 4-2.

Тип образа	Поддерживаемые хранилища	Сильные стороны	Слабые стороны
.qcow2	NFS и каталоги	Допускает динамичное виртуальное хранение файлов образов. Стабильное и безопасное. Совместно с типами образа присутствует большинство функций.	Сложные форматы файлов с дополнительными программными уровнями. Высокие накладные расходы ввода/ вывода.
.raw	LVM, RBD, iSCSI и каталоги	Не требуется дополнительный программный уровень. Прямой доступ к файлам образов. Стабильный, безопасный и самый быстрый.	Только фиксированные файла образов. Не может применяться для хранения динамичных образов. ВМ требуется более длительное резервное копирование из- за больших размеров файлов образов.
.vmdk	NFS и каталоги	Ожидаемо хорошо работает с инфраструктурой VMware. Допускает динамичное хранение файлов виртуальных образов.	Только фиксированные файлы образов. Дополнительный программный уровень, который уменьшает производительность. Не окончательно протестирован с Proxmox.

Тип образа .qcow2

Тип .qcow2 является очень стабильным форматом образа ВМ. Proxmox целиком поддерживает этот формат. Создаваемый с .qcow2 диск ВМ намного меньше поскольку по умолчанию он создаётся с образами диска динамичного выделения (thin- provisioning). Для примера, некая ВМ Ubuntu, создаваемая с 50 ГБ пространством хранения может иметь файл образа размером около 1 ГБ. Пот мере сохранения пользователем данных в этой ВМ такой файл постепенно растёт в размере. Данный формат образа .qcow2 делает возможным для администратора с помощью такого формата .qcow2 снабжать ВМ с избытком. Если не выполнять мониторинг на постоянной основе, имеющееся совместно используемое хранилище превысит имеющееся пространство, выделяя все имеющиеся растущие файлы образов. Хорошим практическим приёмом является добавлять дополнительное пространство хранения когда потребление общего пространства хранения достигает примерно 80%.

Данный формат .qcow2 также имеет очень высокие накладные расходы ввода/ вывода, обусловленных его дополнительным программным уровнем. Тем самым, это достаточно плохой выбор формата образа для такой ВМ, как сервер базы данных. Все подлежащие чтению или записи в этом формате образа данные проходят сквозь программный уровень .qcow2, который увеличивает общий ввод/ вывод, что делает его более медленным. Создаваемая для .qcow2 резервная копия может быть восстановлена только в NFS или локальный каталог.

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

Тип образа .raw

Тип образа .raw также является очень стабильным и зрелым форматом образа ВМ. Его основная мощность состоит в производительности. Нет никакого дополнительного программного уровня для его прохода данными. ВМ осуществляет прямой проброс доступа в свой файл .raw, что делает его намного более быстрым. Помимо этого, не существует никаких подключённых к нему программных компонентов, следовательно он намного менее склонен к проблематичности. Данный формат .raw может создавать только файл образа ВМ с фиксированным размером или с полным выделением. Например, ВМ Ubuntu, созданная с 50 ГБ пространством хранения получит файл образа с размеров в 50 ГБ. Это помогает администратору в точности знать сколько пространства используется, следовательно отсутствует вероятность неконтролируемого выхода за пределы имеющегося пространства.

Данный тип формата .raw является предпочтительным для всех ВМ Proxmox. Формат файла образа ВМ .raw может быть восстановлен практически в любом виде хранилища. В виртуальной среде дополнительные файлы образа виртуального диска могут добавляться к виртуальным машинам в любой момент времени. Следовательно нет нужды изначально выделять файл образа виртуального диска .raw большего размера с предполагаемым возможным ростом в дальнейшем. Конкретная ВМ может начать с неким небольшим файлом образа .raw и добавлять дополнительные образы дисков по мере необходимости. В качестве примера, некая ВМ с 50 ГБ данных начинает с каким- то файлом образа .raw 80 ГБ. Затем, если возникает такая потребность, увеличивает этот размер своего образа диска или добавляет дополнительные образы виртуальных дисков. Данная концепция во многом аналогична добавлению новых жёстких дисков в некий сервер для увеличения общего пространства.

Так как все файлы образа диска .raw выделяются заранее, не существует риска выделения пространства более имеющегося. Моментальные снимки KVM в реальном времени также поддерживаются данным форматом образа .raw. Существует ряд решений совместного хранения, которые поддерживают только данный образ диска .raw. Одним из таких примеров является Ceph RBD. Что касается Proxmox VE 4.1, мы имели возможность сохранять только образы виртуальных дисков .raw в блочных устройствах Ceph. Однако Ceph FileSystem (CephFS) поддерживает все имеющиеся образы виртуальных дисков. CephFS является одним из трёх типов хранения, поддерживаемых платформой Ceph. В настоящее время не имеется прямых подключаемых модулей для CephFS, они имеются только для RBD. Однако мы можем подключать к Proxmox CephFS в качестве совместного ресурса NFS.

Тип образа .vmdk

Формат образа .vmdk является очень распространённым в инфраструктуре VMware. Одним из основных преимуществ поддержки .vmdk со стороны Proxmox является простота миграции ВМ с VMware в кластер Proxmox. Некая созданная с форматом .vmdk в VMware ВМ запросто может быть настроена для её применения в кластере Proxmox и преобразовться. Больше нет дополнительных преимуществ сохранения файла образа виртуального диска в таком формате .vmdk, кроме как на протяжении процесса перехода, такого как преобразование виртуальных машин из инфраструктуры VMware.

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

Таблица 4-3.

Тип шины/ устройства	Максимум допустимых
IDE	3
SATA	5
VirtIO	15
SCSI	13

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

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

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

Таблица 4-4.

Команда	Функция
#qemu-img create -f <type> -o <filename> <size> #qemu-img create -f raw -o test.raw size=1024M	Создаёт файл образа
#qemu-img convert <source> -O <type> <destination> #qemu-img convert test.vmdk -O qcow2 test.qcow2	Преобразовывает файл образа
#qemu-img resize <filename> <+|-><size> #qemu-img resize test.qcow2 +1024M	Изменяет размер файла образа

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

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

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

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

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

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

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

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

Proxmox допускает для каждого образа виртуального диска дросселирование или установку некоего предела для IOPS (input/output operations per second, числа операций ввода/ вывода в секунду). По умолчанию такие пределы не установлены. Каждый образ диска будет предпринимать попытку чтения и записи на максимальной скорости, достижимой в том хранилище, в котором этот образ диска расположен. К примеру, если некий образ диска содержится в локальном хранилище, он попытается выполнять операции чтения и записи со скоростью примерно равной 110 МБ/с, так как это теоретический предел для диска SATA. Эта скорость будет отличаться для различных вариантов хранения. В среде со множеством арендаторов или крупного масштаба, если все имеющиеся образы дисков не дросселированы ни какими пределами, это может оказывать давление на полосу пропускания имеющейся сетевой среды и/ или хранилища. Выполняя дросселирование мы можем управлять той полосой пропускания, которую может применять каждый образ диска. Опция Disk Throttle доступна в закладке Hardware виртуальной машины. Следующий снимок экрана демонстрирует блок диалога Disk Throttle с вариантами установленных пределов:

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

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

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

        IOPS = 1/(средняя задержка в секундах + среднее время позиционирования в секундах)
		

Основываясь на предыдущей формуле мы можем вычислять IOPS стандартных устройство SSD. Для получения времён средних задержки и позиционирования мы можем воспользоваться инструментарием Linux ioping. По умолчанию он не установлен в Proxmox. Мы можем установить его применив следующую команду:

# apt-get install ioping
		

Инструмент ioping аналогичен команде iperf, которая однако применима к дисковым устройствам. Следующая команда отобразит латентность IO для SSD устройства нашего примера:

# ioping /dev/sda
		

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

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

# ioping -R /dev/sda
		

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

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

        IOPS = 1 / (0.00179 + 0.000133) = 520
		

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

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

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

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

Таблица 4-5.

Опция кэшировнаия	Описание
Direct sync	При данном варианте кэширования хост Proxmox не выполняет никакого кэширования, однако диск образа ВМ применяет кэширование сквозной записи. При таком виде кэширования записи принимаются только когда данные фиксируются в устройстве хранения. Direct sync рекомендуется для ВМ, которые не отправляют сбросы по необходимости. Это наиболее безопасное кэширование, поскольку данные не утрачиваются при пропадании питания, однако он и самый медленный.
Write through	В этом случае включена страница кэширования самого хоста Proxmox, в то время как кэширование записи его ВМ отключено. Такое кэширование предоставляет хорошую производительность чтения при более медленной производительности записи, так как кэширование записи отключено. Это более безопасный вид кэширования, так как он гарантирует целостность данных. Данное кэширование рекомендуется для локальных и непосредственно подключаемых хранилищ.
Write back	При данном виде кэширования и кэширование чтения, и кэширование записи осуществляются самим хостом. Записи принимаются как выполненные самим диском ВМ как только они зафиксированы в кэше своего хоста, вне зависимости от того зафиксированы они в хранилище или нет. При таком кэшировании могут возникать потери данных.
Write back (unsafe)	Это в точности такое же кэширование Write back, кроме того, что все сбросы полностью игнорируются имеющейся гостевой виртуальной машиной. Это самый быстрый вид кэширования, хотя и самый опасный. Данное кэширование никогда не следует применять в промышленных кластерах. Как правило, такой вид кэширования применяется для ускорения установки операционной системы в ВМ. По окончанию установки ВМ, данный вид кэширования следует отключить и перейти к более безопасному виду кэширования.
No cache	Эта опция кэширования применяется в Proxmox по умолчанию. В данном случае на уровне хоста не применяется никакое кэширование, однако сама гостевая виртуальная машина осуществляет кэширование с отложенной записью (Write back). Имеющийся диск виртуальной машины пр данном виде кэширования принимает подтверждения записи со стороны устройства хранения.при данном кэшировании данные могут быть утрачены при внезапном отключении хоста из- за сбоя питания.

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

Образы дисков 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, воспользовавшись следующими шагами:

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

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

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

Хранилище Directory является обычной папкой локального узла, монтируемой в Proxmox. Она в основном применяется как локальное хранилище. Однако мы также можем смонтировать и некую удалённую папку из другого узла и применять её как точку монтирования для создания какого- то нового хранилища Directory. По умолчанию, его местоположением является /var/lib/vz.

Ни для каких хранимых в таком хранилище Directory ВМ не допустима миграция в реальном масштабе времени. Такая ВМ должна быть вначале остановлена, прежде чем выполнить её миграцию на другой узел. Внутри данного хранилища Directory могут располагаться любые типы файлов образов виртуальных дисков. Чтобы создать некое новое хранилище с какой- то точкой монтирования перейдите в Datacenter | Storage и кликните по Add для выбора соответствующего встраиваемого модуля Directory. Приводимый ниже моментальный снимок отображает такой блок диалога хранилища Add: Directory, в котором мы можем добавить хранилище с названием local-iso, с тем чтобы смонтировать его в /mnt/iso для хранения необходимых ISO и шаблонов контейнеров:

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

Internet Small Computer Systems Interface, который сокращается до iSCSI, основывается на протоколе IP, что делает возможным передачу команд SCSI в стандартных сетевых средах на основе IP. Устройства iSCSI могут устанавливаться локально или на значительных расстояниях для предоставления возможностей хранения. Мы не можем непосредственно хранить образы виртуальных дисков в некотором устройстве iSCSI, однако мы модем настраивать хранилища LVM поверх таких устройств iSCSI и затем сохранять образы дисков. Подключаемое устройство iSCSI появляется как если бы оно было физически подключено, даже если оно хранится в другом удалённом узле.

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

Мы предположим, что у нас уже имеется устройство iSCSI, созданное в некотором удалённом узлепри помощи FreeNAS или любого прочего дистрибутива Linux. Для добавления такого устройства в Proxmox мы собираемся применить имеющийся встраиваемый модуль iSCSI, который мы можем обнаружить, переместившись в меню Datacenter | Storage | Add. Как это показано на приводимом далее снимке экрана, мы можем добавить некий таргет iSCSI с названием test1-iSCSI, который настроен в удалённом узле 172.16.2.10:

Отметим, что непосредственное использование 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.

Чтобы добавить хранилище LVM проследуйте в Datacenter | Storage | Add и выберите подключаемый модуль хранения LVM. Приводимый далее снимок экрана отображает блок диалога такого LVM, в котором для создания хранилища LVM применяется устройство iSCSI test1-iscsi, которое мы добавили в своём предыдущем разделе:

Network File System (NFS), если говорить кратко, является достаточно зрелым протоколом файловой системы, первоначально разработанным Sun Microsystems в 1984. В настоящее время действует версия 4 данного протокола NFS. Однако она не настолько широко применяется, как версия 3 из- за проблем совместимости. Однако, этот пробел между версиями 3 и 4 закрывается достаточно быстро. По умолчанию Proxmox применяет версию 3 данного протокола NFS, хотя администраторы могут изменить его на версию 4, воспользовавшись опцией в storage.cfg. Хранилище NFS может содержать все форматы образов .qcow2, .raw и .vmdk, предоставляя в кластерной среде разнообразие и гибкость. NFS к тому же является самым простым способом установки и требует самых низких затрат в оборудовании, что делает возможными бюджетные решения для малого бизнеса или домашних пользователей с тем, чтобы они своими руками попробовали стабильную совместно используемую систему хранения в своём кластере Proxmox.

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

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

После введения соответствующего IP адреса вашего удалённого сервера, ваше ниспадающее меню Export просканирует этот удалённый сервер на наличие всех его совместных ресурсов NFS и отобразит их в своём списке. В нашем примере соответствующей точкой монтирования, найденной в этом блоке диалога является /nfs-vol/nfs-01.

ZFS изначально разрабатывалась Sun Microsystems. Хранилище ZFS является комбинацией файловой системы и LVM, которое предоставляет хранилище высокой ёмкости с важными функциями, такими как защищённость данных, сжатие данных, самостоятельное восстановление, а также моментальные снимки. ZFS имеет встроенный программно определяемый RAID, что устраняет необходимость использования RAID с аппаратной поддержкой. Массив дисков с RAID ZFS может выполнять миграцию на полностью другой узел с последующим импортом без перестроения всего имеющегося массива целиком. В подобном хранилище ZFS мы можем располагать только образы виртуального диска в формате .raw. Для получения дополнительных сведений по хранилищу ZFS обратитесь к http://en.wikipedia.org/wiki/ZFS. {Прим. пер.: а также к нашим переводам Мастерство FreeBSD: ZFS для профессионалов, Мастерство FreeBSD: ZFS, Полная виртуализация. Базовая коммерческая редакция: Proxmox-freeNAS-Zentyal-pfSense, Введение в ZFS для Linux..}

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

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

# zpool create <pool_name> <raid_type> <dev1_name> <dev2_name> ...
		

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

# zpool create zfspool1 mirror /dev/vdd /dev/vde
		

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

Таблица 4-6.

Тип RAID	Применяемая строка опции
RAID0	нет строки
RAID1	mirror
RAIDZ-1	raidz1
RAIDZ-2	raidz2

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

# zpool list
		

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

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

# zfs create <zpool_name>/<zfs_dataset_name>
		

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

# zfs set mountpoint=/mnt/zfs-vm zfspool1/zfs-vm
		

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

# zfs set compression=on zfspool1/zfs-vm
		

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

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

# apt-get install nfs-kernel-server
		

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

/mnt/zfs/ 172.16.0.71/24(rw,nohide,async,no_root_squash)
		

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

# service nfs-kernel-server start
		

Для совместного использования пула ZFS с включённым в NFS GUI Proxmox, мы можем просто повторить все те шаги, которые мы выполнили для своего хранилища NFS в предыдущем разделе. Чтобы добавить пул или набор данных ZFS в свой кластер Proxmox c помощью GUI, нам потребуется зарегистрироваться в этом GUI в том узле, в котором создан наш пул ZFS. В нашем примере кластера с двумя узлами у нас имеются пулы ZFS в узле #1, поэтому нам придётся выполнить доступ к своему GUI в этом узле. В противном случае эти пулы или наборы данных ZFS не смогут быть добавлены из GUI другого узла. Мы можем обнаружить опцию подключаемого модуля своего хранилища ZFS переместившись в меню Datacenter | Storage | Add. Кликните по подключаемому модулю ZFS чтобы открыть требуемый блок диалога. На снимке внизу представлен соответствующий блок диалога хранилища ZFS с нашим примером пула zfs и набором данных в отобразившемся ниспадающем меню:

 

Рисунок 4-20

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

Ceph RBD

Хранилище RBD (RADOS Block Device) предоставляется распределённой системой хранения Ceph. Это наиболее сложная система хранения, которая требует установки множества узлов. По своей архитектуре Ceph является распределённой системой хранения и может быть распространена на несколько десятков узлов. Хранилище RBD может размещать только образы формата .raw. Для расширения кластера Ceph мы просто добавляем новый жёсткий диск или узел и извещаем Ceph об этом новом добавлении. Ceph автоматически выполнит балансировку данных для размещения такого нового жёсткого диска или узла. Ceph может масштабироваться до размеров нескольких Петабайт и даже больше. Ceph также допускает создание множества пулов для различных дисковых устройств. Например, образы ВМ серверов баз данных в пулах на основе SSD, а образы сервера резервного копирования в дисковом пуле более медленных шпиндельных дисков. Ceph рекомендуется применять для кластерных сред в диапазоне от средних до крупных благодаря его устойчивости к потере данных и простоте в расширяемости хранения.

В версии 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/.

В этом разделе мы рассмотрим как подключать некий кластер GlusterFS к Proxmox при помощи имеющегося встраиваемого модуля Gluster. Мы можем отыскать этот подключаемый модуль переместившись в Datacenter | Storage | Add. Кликните по подключаемому модулю GlusterFS чтобы открыть необходимый блок диалога создания требуемого хранилища, как это показано на снимке экрана внизу:

 

Рисунок 4-21

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

Таблица 4-7.

Элементы	Тип значения	Пример значения
ID	Новое название хранилища	gluster
Server	IP адрес первого узла Gluster	172.16.0.171
Second Server	IP адрес второго узла Gluster	172.16.0.172
Volume name	Ниспадающее меню для выбора доступных томов в данном узле Gluster	gfsvol11
Content	Выбор типа подлежащих ранению файлов	VZDump backup file
Nodes	Выбор узлов, которые могут осуществлять доступ к данному хранилищу.	All (No restrictions)
Enable	Включить или выключить данное хранилище	Enabled
Max Backups	Максимальное число хранимых последних файлов резервных копий. Более старые резервные копии будут удалены автоматически в новом процессе резервного копирования.	2

Так как Gluster не имеет встроенных опций программно определяемого RAID, каждый узел Glustar нуждается в некотором виде RAID для создания избыточности дисков в узле. Как и со случаем NFS поверх ZFS, который мы изучили ранее в этой главе, мы также можем поместить Gluster поверх ZFS и предоставить избыточность дисков таким образом. Отметим, однако, что это создаст некие дополнительные накладные расходы, поскольку ZFS будет потреблять некие ресурсы.