Enable numa proxmox что это
Оптимизация виртуальных серверов.
С коллегой решили внедрить виртуализацию, чтобы идти в ногу со временем и упростить свои административные задачи. Из бесплатного и надёжного выбрали Proxmox VE. Debian под капотом вселяет уверенность и ближе по идеологии.
VirtIO.
Я себе явно усложнил ситуацию, получив этап «миграция с IDE на VirtIO в KVM». Но данный этап оказался не таким сложным. В Proxmox VE в папке /etc/pve/qemu-server/ лежат файлы conf по-одному на каждый виртуальный сервер. Виртуальная машина test, созданная сразу с VirtIO, показала какой должен быть в итоге conf.
Сетевые карты на использование VirtIO были выставлены через веб интерфейс Proxmox VE и вывод lspci |grep Virtio стал показывать использование VirtIO и для виртуального жёсткого диска и для виртуальных сетевых карт.
Что ещё было оптимизировано?
Я выбрал всё таки файловую систему ext4, хотя многие тесты упорно рекомендуют ext3. Журналирование в файловых системах, естественно, не прибавляет скорости в I/O, но с ним можно разобраться, а сама ext4, помимо журнала, тоже получила множество улучшений и жаль было бы их терять. Ведь Google не зря перешёл с ext3 на ext4 без журнала!
К этому времени мне уже было известно о благотворном влиянии отключения шлагбаумов barrier=0 (или nobarrier). Это давным давно было описано у меня в Ускорении файловой системы.
В одной из англоязычных статей, её автор приводил тесты для файловых систем для MySQL сервера и с barrier=0 ext4 была не хуже ext3.
Естественно, такие манипуляции проводятся, так как точно будет использоваться источник бесперебойного питания. То есть UPS это один из ускоряющих элементов сервера.
Планировщик.
Где-то в глубине души я знал, что с планировщиком CFQ нам не по пути, он сделан под углом честного дележа доступа к диску и пытается сортировать очередь к диску, зная про головки HDD и минимизацию их перемещения. Но имеет ли смысл что-то сортировать у виртуального диска?
Вначале я выставил планировщик noop, который является простейшим планировщиком и ничего не сортирует. Но статьи уважаемой IBM по лучшему использованию KVM утверждают, что лучше использовать планировщик deadline и что так поступает сама IBM. Да и Canonical вместо CFQ стала использовать deadline.
Пока решил довериться IBM и Canonical и выставить deadline по умолчанию.
Советы IBM по вопросам работы памяти.
IBM считает, и наверное не безосновательно, что для бо́льшой производительности нужно отключить zone_reclaim_mode и выставить swappiness=0.
NUMA (Non-Uniform Memory Access — неравномерный доступ к памяти или Non-Uniform Memory Architecture — Архитектура с неравномерной памятью) — схема реализации компьютерной памяти, используемая в мультипроцессорных системах, когда время доступа к памяти определяется её расположением по отношению к процессору.
Если NUMA penalty становится высокой, то операционная система осуществляет очистку (zone reclaim).
Для примера, операционная система выделяет память в ноде NUMA, но нода NUMA полна. В таком случае, операционная система начинает очистку памяти локальной ноды NUMA, а не выделяет немедленно память на удалённой ноде NUMA. Выигрыш в выделении памяти на локальной ноде перевешивает недостаток скорости при очистке памяти (reclaiming memory).
Однако, в некоторых ситуациях очистка памяти (reclaiming memory) снижает производительность до такой степени, что верно и обратное. Иными словами, выделение памяти на удалённой ноде NUMA будет быстрее, чем очищение памяти на локальной ноде.
Гостевые операционные системы могут вызывать zone reclaim в следующих случаях:
Настройка huge pages, использование KSM и отключение zone reclaim эти шаги IBM считает хорошей практикой при использовании виртуализации KVM.
zone_reclaim_mode.
Для отключения zone_reclaim_mode на KVM хосте, нужно убедиться в текущем состоянии дел.
Моя Proxmox VE нода выдала 0 и значит разработчики Proxmox VE уже решили нашу задачу. Если у вас не ноль, то в /etc/sysctl.conf нужно указать vm.zone_reclaim_mode=0 и рестарт.
swappiness.
Дефолтное значение swappiness = 60. Можно выставить от 0 до 100. Когда выставлен swappiness = 0 на системах Intel Nehalem, то менеджер виртуальной памяти удаляет страничный кеш (page cache) и кеш буфера (buffer cache), а не скидывает программу из памяти в swap.
Платформа Intel Nehalem использует расширенные таблицы страниц Extended Page Table (EPT). EPT не устанавливает бит доступа к страницам, которые используются гостевыми операционными системами. Таким образом, менеджер виртуальной памяти Linux не может использовать свой алгоритм LRU (least recently used), чтобы точно определить какие страницы не нужны. Точнее сказать, алгоритм LRU не может точно определить какие страницы в гостевых операционных системах являются лучшими кандидатами на вытеснение в swap. В это ситуации, во избежание ненужного своппинга лучше выставить swappiness=0.
Системы с процессорами Advanced Micro Devices (AMD) и с технологией Nested Page Table (NPT) не имеют описанной выше проблемы.
Узнайте текущее значение cat /proc/sys/vm/swappiness
Для KVM хоста в /etc/sysctl.conf нужно указать vm.swappiness=0.
huge pages.
Приложения, которые используют много непрерывных участков памяти, получат максимальную выгоду от huge pages, поскольку будет генерироваться меньше промахов Translation Lookaside Buffer (TLB).
Процессор чаще находит нужное отображение в TLB и реже сканирует таблицу страниц.
Таким образом, huge pages увеличивает производительность приложений, которые используют большие и непрерывные участки памяти.
Приложения, которые используют маленькие и непрерывные блоки памяти, не получат от huge pages выгоды.
Huge pages нужно настраивать в ручную и знать необходимость приложения в огромных блоках памяти. По этой причине, пока не стал связываться с ними.
Быстродействие MySQL сервера.
Тяжело вырваться из этого круга, но хотелось сделать единый MySQL сервер с единым Apache и местом обитания всех веб морд. Создал виртуальную машину mysqlserver, которая обладала сервером MySQL и веб сервером Apache.
Единый MySQL позволит легко манипулировать доступом к базам данным. Но с другой стороны, я опасался эффекта «все яйца в одной корзинке». Зависимость от отдельного MySQL сервера могла сделать неработоспособной какую-либо службу при недоступности MySQL сервера.
Частично негативный эффект от единой точки отказа был сглажен. Например, DHCP сервер берёт записи из базы MySQL и формирует свой dhcpd.conf при изменениях в записях MAC и IP адресов. При отказе MySQL физически не изменить базу данных через веб интерфейс и, следовательно, DHCP сервер не увидит изменений и будет работать с ранее сформированным dhcpd.conf.
Новый Squid 3 изменил представление о сохранении своих логов вместо файлов в базу данных MySQL.
logformat squid_mysql %ts.%03tu %6tr %>a %Ss %03Hs %
ALTER TABLE access_log
PARTITION BY RANGE( TO_DAYS(date_day) )
(
PARTITION y2013m01 VALUES LESS THAN( TO_DAYS(‘2013-01-01’) ),
PARTITION y2013m02 VALUES LESS THAN( TO_DAYS(‘2013-02-01’) ),
.
PARTITION y2020m11 VALUES LESS THAN( TO_DAYS(‘2020-11-01’) ),
PARTITION y2020m12 VALUES LESS THAN( TO_DAYS(‘2020-12-01’) ),
PARTITION pcatchall VALUES LESS THAN (MAXVALUE)
);
Но принявшись за сегментирование, меня ждал fail. Как я понял, банально попал под ограничения секционированных таблиц и запрос ALTER TABLE access_log PARTITION BY RANGE( TO_DAYS(date_day) ) выдал A PRIMARY KEY must include all columns in the table’s partitioning function.
Гуру SQL объяснили: ограничение, которое встретилось вам, звучит примерно так: каждый уникальный ключ (включая PK, который является UK NOT NULL) должен содержать все колонки, используемые в выражении, по которому идет секционирование. Вызвано это тем, что в MySQL отсутствуют глобальные индексы, так как поддержание подобных индексов достаточно дорогая операция. Иными словами, имея PK id и секционирование по полю ddate, MySQL бы пришлось каким-то образом гарантировать, что id уникален во всех партициях сразу. Для этого нужен индекс, проходящий сквозь все секции. MySQL такого не умеет. А вот если PKем станет пара id, ddate, то достаточно, чтобы внутри каждой секции эти значения были уникальными. Так как ddate в разных секциях будет разный, то это автоматически гарантирует уникальность пары id, ddate на всей таблице.
Получается или нужно сегментирование или детально разбираться в не в своей схеме таблицы и грамотно изменить индексы. Решил пока повременить с сегментацией таблицы.
Оптимизация запросов.
Решил в скриптах Perl и PHP, которые за многие годы до меня администраторы на создавали для упрощения администрирования, разобраться и оптимизировать запросы в них.
Начал с простого. Ищем все SELECT FROM WHERE и анализируем колонки таблиц, участвующие в запросе. Банальное создание индексов на такие поля и EXPLAIN SELECT показывает не множество задетых строк, а единицы. Вроде мелочь, а проектировщик в прошлом не удосужился сделать такую отличную вещь, как индекс для поля. Минус у индекса, если можно назвать это минусом, можно считать необходимость в дополнительном обновлении индекса при операциях INSERT, UPDATE в таблице. Но кроме access_log все остальные таблицы не испытывают мощных INSERT, UPDATE и можно смело навешивать index налево и направо.
В поиске столбцов, которые участвуют в запросах и не имеют индекса, очень помогает параметр log-queries-not-using-indexes в /etc/mysql/my.cnf. Чтение лога mysql помогает найти виновника и устранить недоразумение. В логе сразу видно кто, откуда и каким запросом умудряется цеплять множество строк таблиц, не используя индексы.
Из книги «MySQL. Оптимизация производительности» узнал, что поле с индексом в запросе с WHERE должен стоять левее и когда встречал сложное условие, то переписывал его так, чтобы сначала было поле, а потом уже больше-меньше и выражение.
Потом пошла оптимизация посложнее. Автор Squid2MySQL в веб админке постоянно использовал запросы к «тяжёлой» таблице squidlog, хотя часто нужные данные лежали в более «лёгкой» таблице rdnload, в которой уже лежали пред вычисленные значения скаченного трафика. Логику автора не понять. Как писал выше, данные по скачанному через Squid теперь заносились скриптом итальянца, а не родным скриптом проекта, поэтому squidlog стал представлением (VIEW) для таблицы access_log. Но скрипты веб интерфейса Squid2Mysql я всё равно изменил, чтобы запросы больше обращались к таблице rdnload, чем через представление squidlog к access_log.
Оптимизация Apache.
У нас не высоконагруженный проект, а сайт с вебмордами админок. В общем, параметры такие:
StartServers определяет количество процессов сервера, запускаемых изначально, сразу после его старта. MinSpareServers и MaxSpareServers определяют минимальное и максимальное количество дочерних «запасных» процессов Apache. Такие процессы находятся в состоянии ожидания входящих запросов и не выгружаются, что даёт возможность ускорить реакцию сервера на новые запросы. MaxClients определяет максимальное количество параллельных запросов, одновременно обрабатываемых сервером. Когда количество одновременных соединений превысит это количество, новые соединения будут поставлены в очередь на обработку. MaxClients определяет максимально-допустимое число дочерних процессов Apache, запущенных одновременно. MaxRequestsPerChild определяет количество запросов, которое должен обработать дочерний процесс Apache, прежде чем завершить своё существование. Когда обработанных запросов станет больше MaxRequestsPerChild, то дочерний процесс будет перезапущен и это помогает при возможных утечках кривых скриптов.
Магия виртуализации: вводный курс в Proxmox VE
Сегодня речь пойдет о том, как быстро и достаточно просто на одном физическом сервере развернуть несколько виртуальных серверов с разными операционными системами. Любому системному администратору это позволит централизованно управлять всей IT-инфраструктурой компании и экономить огромное количество ресурсов. Использование виртуализации помогает максимально абстрагироваться от физического серверного оборудования, защитить критичные сервисы и легко восстановить их работу даже в случае очень серьезных сбоев.
Без всякого сомнения, большинству системных администраторов знакомы приемы работы с виртуальной средой и для них эта статья не станет каким-либо открытием. Несмотря на это, есть компании, которые не используют гибкость и скорость работы виртуальных решений из-за недостатка точной информации о них. Мы надеемся, что наша статья поможет на примере понять, что гораздо проще один раз начать использовать виртуализацию, чем испытывать неудобства и недостатки физической инфраструктуры.
К счастью, попробовать как работает виртуализация достаточно просто. Мы покажем, как создать сервер в виртуальной среде, например, для переноса CRM-системы, используемой в компании. Практически любой физический сервер можно превратить в виртуальный, но вначале необходимо освоить базовые приемы работы. Об этом и пойдет речь ниже.
Как это устроено
Когда речь идет о виртуализации, многим начинающим специалистам сложно разобраться в терминологии, поэтому поясним несколько базовых понятий:
Ключевой особенностью является то, что любые действия виртуальных машин исполняются напрямую на уровне оборудования. При этом они друг от друга изолированы, что достаточно легко позволяет управлять ими по отдельности. Сам же гипервизор играет роль контролирующего органа, распределяя ресурсы, роли и приоритеты между ними. Также гипервизор занимается эмуляцией той части аппаратного обеспечения, которая необходима для корректной работы операционной системы.
Внедрение виртуализации дает возможность иметь в наличии несколько запущенных копий одного сервера. Критический сбой или ошибка, в процессе внесения изменений в такую копию, никак не повлияет на работу текущего сервиса или приложения. При этом также снимаются две основные проблемы – масштабирование и возможность держать «зоопарк» разных операционных систем на одном оборудовании. Это идеальная возможность совмещения самых разных сервисов без необходимости приобретения отдельного оборудования для каждого из них.
Виртуализация повышает отказоустойчивость сервисов и развернутых приложений. Даже если физический сервер вышел из строя и его необходимо заменить на другой, то вся виртуальная инфраструктура останется полностью работоспособной, при условии сохранности дисковых носителей. При этом физический сервер может быть вообще другого производителя. Это особенно актуально для компаний, которые используют серверы, производство которых прекращено и потребуется осуществить переход на другие модели.
Теперь перечислим самые популярные гипервизоры, существующие на текущий день:
KVM же напротив, полностью бесплатен и достаточно прост в работе, особенно в составе готового решения на базе Debian Linux под названием Proxmox Virtual Environment. Именно эту систему мы можем порекомендовать для первоначального знакомства с миром виртуальной инфраструктуры.
Как быстро развернуть гипервизор Proxmox VE
Установка чаще всего не вызывает никаких вопросов. Скачиваем актуальную версию образа с официального сайта и записываем его на любой внешний носитель с помощью утилиты Win32DiskImager (в Linux используется команда dd), после чего загружаем сервер непосредственно с этого носителя. Наши клиенты, арендующие у нас выделенные серверы, могут воспользоваться двумя еще более простыми путями – просто смонтировав нужный образ непосредственно из KVM-консоли, либо используя наш PXE-сервер.
Программа установки имеет графический интерфейс и задаст всего лишь несколько вопросов.
Веб-интерфейс управления станет доступен по адресу
Что нужно сделать после установки
Есть несколько важных вещей, которые следует выполнить после установки Proxmox. Расскажем о каждой из них подробнее.
Обновить систему до актуальной версии
Для этого зайдем в консоль нашего сервера и отключим платный репозиторий (доступен только тем, кто купил платную поддержку). Если этого не сделать — apt сообщит об ошибке при обновлении источников пакетов.
Позаботиться о безопасности
Исходя из практического опыта, за неделю работы сервера с открытым ssh-портом 22 и внешним статическим IPv4-адресом, было более 5000 попыток подобрать пароль. И около 1500 адресов утилита успешно заблокировала.
Для выполнения установки приводим небольшую инструкцию:
Проверить статус работы утилиты, например, снять статистику блокировок заблокированных IP-адресов с которых были попытки перебора паролей SSH, можно одной простой командой:
Ответ утилиты будет выглядеть примерно так:
Аналогичным способом можно закрыть от подобных атак Web-интерфейс, создав соответствующее правило. Пример такого правила для Fail2Ban можно найти в официальном руководстве.
Начало работы
Хочется обратить внимание на то, что Proxmox готов к созданию новых машин сразу после установки. Тем не менее, рекомендуем выполнить предварительные настройки, чтобы в дальнейшем системой было легко управлять. Практика показывает, что гипервизор и виртуальные машины стоит разнести по разным физическим носителям. О том, как это сделать и пойдет речь ниже.
Настроить дисковые накопители
ВНИМАНИЕ! Приведенный ниже пример дисковой разметки можно использовать только для тестовых целей. Для эксплуатации в реальных условиях мы настоятельно рекомендуем использовать программный или аппаратный RAID-массив, чтобы исключить потерю данных при выходе дисков из строя. О том, как правильно приготовить дисковый массив к работе и как действовать в случае аварийной ситуации мы расскажем в одной из следующих статей
Предположим, что физический сервер имеет два диска — /dev/sda, на который установлен гипервизор и пустой диск /dev/sdb, который планируется использовать для хранения данных виртуальных машин. Чтобы система смогла увидеть новое хранилище, можно воспользоваться самым простым и эффективным методом — подключить его как обычную директорию. Но перед этим следует выполнить некоторые подготовительные действия. В качестве примера посмотрим, как подключить новый диск /dev/sdb, любого размера, отформатировав его в файловую систему ext4.
Вывод команды должен показать, что /dev/sdb1 смонтирован в директорию /mnt/storage. Это значит, что наш накопитель готов к работе.
Добавить новое хранилище в Proxmox
Авторизуемся в панели управления и заходим в разделы Датацентр ➝ Хранилище ➝ Добавить ➝ Директория.
В открывшемся окне заполняем следующие поля:
После этого нажимаем кнопку Добавить. На этом настройка завершена.
Создать виртуальную машину
Для создания виртуальной машины выполняем следующую последовательность действий:
Создаем нашу первую виртуальную машину:
Настроить автозапуск
По умолчанию Proxmox автоматически не запускает машины, но это легко решается буквально двумя щелчками мыши:
Для продвинутых администраторов имеется еще и возможность указать дополнительные параметры запуска в разделе Start/Shutdown order. Можно явным образом указать в каком порядке следует запускать машины. Также можно указать время, которое должно пройти до старта следующей VM и время задержки выключения (если операционная система не успеет завершить работу, гипервизор принудительно ее выключит через определенное количество секунд).
Заключение
В этой статье были изложены основы того, как можно начать работать с Proxmox VE и мы надеемся, что она поможет начинающим специалистам сделать первый шаг и попробовать виртуализацию в действии.
Proxmox VE — это действительно очень мощный и удобный инструмент для любого системного администратора; главное не бояться экспериментировать и понять, как это действительно работает.
Если у вас появились вопросы, добро пожаловать в комментарии.
Глава 5. Виртуальные машины KVM
Содержание
На настоящий момент мы познакомились с графическим интерфейсом пользователя Proxmox, файлами настройки, а также структурой каталога. Мы также изучили различные типы поддерживаемых Proxmox хранилищ и то, как интегрировать их в кластер. В данной главе мы мы собираемся сделать шаг вперёд и рассмотреть KVM ( Kernel-based Virtual Machine ) и всё, что они должны предложить. Мы собираемся охватить следующие темы:
Встраиваемые виртуальные среды
Систему резервного копирования/ восстановления Proxmox
Моментальные снимки виртуальных машин
Обзор KVM
Как и подразумевает их название, KVM добавляют возможности гипервизора в ядро Linux. KVM позволяют вам создавать полностью изолированные виртуальные машины, которые не зависят от ядра хоста. Изолированность создаётся путём эмуляции определённых элементов оборудования, таких как ЦПУ, ОЗУ, звуковые/ видео/ сетевые карты, мосты PCI, а также устройства ввода клавиатура/ мышь. Так как KVM не зависит от ядра хоста, она способна виртуализировать широкий диапазон операционных систем, таких как Linux, BSD, Windows, OS X и тому подобные. Одно из основных отличий KVM и виртуальных машин на основе контейнеров заключается в том, что выделяемые для RVM ресурсы изолируются друг от друга, а также от хоста.
Таким образом, плотность числа ВМ KVM на узле намного меньше чем у контейнеров. KVM являются единственным выбором для не- Linux операционных систем и для ориентированных на выполнение определённой задачи операционных систем, таких как ClearOS, FreeNAS, Zentyal и тому подобные. Для получения дополнительной информации по KVM обратитесь к https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine < Прим. пер.: или к русскоязычной странице https://ru.wikipedia.org/wiki/KVM. >
Создание KVM
В Proxmox мы можем создавать ВМ KVM следующими двумя путями:
Из рабочей области
Создание ВМ из рабочей области
Данный процесс проведёт вас через весь процесс создания всей виртуальной машины при помощи диалогового блок на основе закладок. На протяжении этого процесса мы должны выделить ресурсы и ввести относящуюся к данной ВМ необходимую информацию. Следующий снимок экрана отображает блок диалога после того как вы кликните на Create VM в GUI Proxmox:
Рисунок 1
Закладка General
Закладка General блока диалога используется в основном для назначения идентификационной информации, такой как:
Node : Этот ниспадающий список служит для выбора того на каком узле Proxmox должна быть создана данная ВМ.
VM ID : Этот текстовый блок используется для ввода численного значения идентификатора создаваемой ВМ. Мы также можем увеличивать или уменьшать данное значение VM ID применяя стрелки. Если мы назначим идентификатор, который уже существует в нашем кластере, блок получит красную рамку вокруг себя, как это отображено на следующем экранном снимке:
Рисунок 2
Закладка OS
Рисунок 3
Для достижения максимальной производительности и стабильности вам настоятельно рекомендуется выбирать подходящий тип ОС.
Закладка CD/DVD
Так как ВМ KVM является полностью вложенной и эмулирует физическую машину, мы можем только выполнять загрузку этой ВМ или загружать операционную систему с помощью образов ISO, загружаемых в нашем виртуальном устройстве CD/DVD или из физического устройства, подключённого к узлу хоста Proxmox. В данной закладке мы можем выбрать будем ли мы использовать виртуальное или физическое устройство, или же отобрать образ ISO. Приводимый ниже снимок экрана отображает блок диалога для закладки CD/DVD :
Рисунок 4
Закладка Hard Disk
В этой закладке мы определяем настройки для нашего первого образа диска создаваемой ВМ. Следующий снимок экрана отображает блок диалога с настройкой для нашего примера ВМ:
Рисунок 5
Bus/Device
Для данного параметра представлены два ниспадающих меню: одно для выбора типа шины образа диска, а второе для выбора идентификатора устройства.
Для достижения максимальной производительности рекомендуется шина VIRTIO.
Для ВМ Windows необходимо выбирать IDE, поскольку Windows не имеет встроенного драйвера VIRTIO. В подобном случае мы можем воспользоваться следующими шагами для добавления возможности VIRTIO в ВМ Windows:
Создайте ВМ с IDE и установите Windows обычным образом.
Добавьте второй образ диска с шиной VIRTIO и перезагрузите Windows.
Скачайте самый последний ISO драйвера VIRTIO для Windows со следующих ссылок, а затем загрузите его через виртуальное CD устройство:
Обновите свой драйвер для нового оборудования найденного для вашего образа диска VIRTIO.
Остановите ВМ Windows и зарегистрируйтесь в инструментальной панели Proxmox.
Рисунок 6
Рисунок 7
В блоке диалога мы можем выбрать нужный тип Bus и прочие опции настройки в случае необходимости.
Кликните Add для добавления этого образа диска назад к данной ВМ.
Предыдущие шаги необходимы для предоставления ВМ Windows возможности использования образа диска VIRTIO. Когда данный драйвер загружен, нет необходимости перезагружаться для дополнительных образов дисков VIRTIO.
Storage
Это ниспадающее меню для выбора того, где должен храниться образ данного диска. Помимо самого имени выбираемого хранилища, ниспадающее меню также отображает общий объём и доступное пространство хранения подключаемого устройства.
Disk size
Это текстовый блок для определения размера вашего дискового хранилища в ГБ. Значение может быть только численным. Мы также можем применять стрелки вверх и вниз для определения данного размера.
Format
Рисунок 8
Если мы выберем не верный формат образа своего диска, или если мы позже решим использовать другой формат, мы можем просто воспользоваться параметром Move disk в закладке Hardware для изменения формата. Это также можно сделать в CLI применив следующую команду:
Эта команда хорошо работает для локальных хранилищ, а также для хранилищ NFS, ZFS и Gluster, однако не применима к RBD. Для изменения формата образа диска. хранимого в RBD используйте параметр Move в инструментальной панели Proxmox. Относительно хранимого в RBD образа диска, этот параметр Move может быть применён для перемещения любого образа диска сохранённого в любом хранилище при помощи GUI совсем без какой бы то ни было необходимости применения CLI. Этот параметр также полезен при перемещении образа диска с одного хранилища на другое без выключения данной ВМ. Хранилище может быть любым от локального до совместно используемого и наоборот. Для перемещения или изменения определённого формата диска выберите конкретный образ диска в закладке Hardware и кликните на Move disk для открытия блока диалога, как это показано на следующем рисунке:
Рисунок 9
Cache
Это ниспадающее меню позволяет нам выбирать метод кэширования используемый для данного образа диска. Мы изучили различные варианты кэширования в Главе 4, Системы хранения в разделе Кэширование виртуального диска. Мы можем изменять опции кэширования в любое время, даже после того, как ВМ полностью создана и функционирует. После каждого изменения опций кэширования нам будет необходимо выполнить цикл перезагрузки данной ВМ для того, чтобы новые опции кэширования вступили в силу.
No backup
Если данная опция включена, образ данного виртуального диска никогда не будет включаться в резервную копию. По умолчанию эта опция запрещена.
Discard
Образ диска в Proxmox разряжён в зависимости от типа образа. Это означает, что образ определённого диска медленно растёт по мере сохранения в нём данных. Со временем данные создаются и удаляются в пределах файловой системы данного образа диска. Однако при разряженном образе диска даже после удаления данных он никогда не восстанавливает свободное пространство. ВМ может сообщать верное доступное пространство, однако хранилище Proxmox будет показывать более высокое использование пространства. Опция сброса (discard) позволяет узлу восстановить свободное пространство, которое не используется какими бы то ни было данными. Это эквивалентно опции TRIM, которая была введена в устройствах SSD в точности для тех же целей. Перед тем как эта опция может быть использована, мы должны убедится, что данная ВМ использует контроллер SCSI VISIO. Мы можем установить тип SCSI в закладке Option данной виртуальной машины, как это отображено на следующем рисунке:
Рисунок 10
По умолчанию Proxmox настраивает все ВМ с контроллером LSI 53C895A. Опция Discard может не соответствовать всем средам, хранилищам и операционным системам. Выполните достаточное тестирование перед её реализацией в своём окружении.
В некоторых случаях опция Discard может вызывать блокировку ВМ, требующую цикла перезагрузки. ВМ нуждается в цикле перезагрузки если данная опция включена после запуска этой ВМ.
Iothread
Существует две опции для образов диска KVM:
По умолчанию Proxmox использует ionative для всех образов диска, в то время как опция iothread помечается специальным образом для нуждающихся в ней образах дисков.
Опция iothread позволяет каждому образу диска иметь свой собственный поток вместо ожидания очереди с кем- нибудь ещё. Поскольку дисковый воод/ вывод больше не ожидает благодаря наличию своего собственного треда, он не сдерживает другие задачи или связанные с ним очереди, относящиеся к данной ВМ, что в конечном итоге ускоряет производительность данной ВМ помимо увеличения производительности дискового обмена. Опция iothread достаточно новая для Proxmox. Существует несколько сообщений источников в которых ВМ были заблокированы из- за этой опции, поэтому выполняйте достаточное тестирование прежде чем реализуете эту функциональность в промышленном окружении.
Закладка CPU
Данная закладка делает возможной настройку вами необходимых виртуальных WGE для создаваемой виртуальной машины. Следующий рисунок отображает блок диалога с доступными опциями ЦПУ:
Рисунок 11
Sockets
Эта опция служит определению числа сокетов, которое может использовать создаваемая ВМ. Мы можем применять более 1 сокета для данной ВМ, даже если физический узел не имеет достаточного количества разъёмов. Это может быть полезно в случае, когда какое- либо приложение в вашей ВМ требует более 1 сокета. Однако не будет полезным совсем для увеличения производительности в узле Proxmox с единственным сокетом.
Cores
Эта опция служит определению числа ядер, которые может использовать создаваемая ВМ. Хорошим подходом будет начало применения ВМ с меньшим количеством ядер с последующим увеличением их числа по мере необходимости, в зависимости от нагрузки. Выделение большого количества ядер ВМ вызовет ненужное давление на доступные ресурсы в вашем узле. Обычно ВМ может предоставлять хорошую производительность с 2 или 4 ядрами только если они не находятся под высокой нагрузкой, такой как сервер удалённых рабочих мест или сервер SQL/ обмена сообщениями.
Enabling NUMA
Любой узел с более чем одним разъёмом ЦПУ обычно осведомлён о NUMA. Поэтому включение NUMA для ВМ на таком узле предоставит преимущество производительности создаваемой ВМ. NUMA всегда будет пытаться оставлять такую ВМ на одном и том же пакете ЦПУ. Мы можем проверить состояние NUMA в кластере Proxmox воспользовавшись командой:
Эта команда отобразит все ваши узлы в кластере, которые осведомлены о NUMA, а также их стсатистики производительности.
Type
Закладка Memory
Эта закладка делает возможной настройку выделения оперативной памяти создаваемой ВМ. Следующий рисунок отображает блок диалога для нашего примера ВМ:
Рисунок 12
В Proxmox мы можем устанавливать для ВМ фиксированную или динамично выделяемую оперативную память. Автоматический диапазон также называется надуванием памяти (memory ballooning). При фиксированных опциях вся память выделяется в одно и то же время. При опциях динамичного выделения оперативная память выделяется на основании запросов ВМ в пределах предварительно установленного диапазона. Автоматическое выделение памяти хорошо работает для гостевых ВМ на основе Linux, однако для ВМ Windows надувание памяти потребляет более высокие значения ресурсов ЦПУ, вызывающие замедление такой ВМ. Поэтому для ВМ Windows лучше применять фиксированную память, где это возможно.
Закладка Network
Эта закладка позволяет настраивать необходимые виртуальные сетевые интерфейсы для создаваемой ВМ. Следующий рисунок показывает блок диалога для настройки сетевой среды нашего примера ВМ:
Рисунок 13
Bridged mode
Данный режим позволяет создаваемой ВМ подключаться к сетевой среде с применением моста. Создаваемая ВМ не получает прямого доступа к внешней сетевой среде. Мы можем установить идентификатор VLAN на уровне данного узла, что сделает необязательной её настройку внутри данной ВМ. Режим моста также предоставляет для данной ВМ опции межсетевого экрана.
Firewall
Чтобы включить Межсетевой экран Proxmox для данного сетевого интерфейса, необходимо отметить эту опцию. без этого параметра никакие правила межсетевого экрана не будут применяться к данному интерфейсу. Мы рассмотрим Межсетевой экран Proxmox максимально подробно в Главе 8, Межсетевой экран Proxmox.
NAT mode
Данный режим предоставляет ВМ прямой доступ к внешней сетевой среде. Сетевой обмен не проходит ни через какие мосты. Если в этой сетевой среде используется VLAN, он должен быть настроен внутри создаваемой ВМ. При использовании режима NAT опция межсетевого экрана Proxmox недоступна.
No network device
Эта опция создаёт вашу ВМ без какого бы то ни было настроенного сетевого интерфейса.
Model
MAC address
По умолчанию все MAC адреса для виртуальных сетевых интерфейсов назначаются автоматически. Набрав MAC адрес в текстовом блоке мы можем задать определённый MAC адрес для данного интерфейса. Это может быть необходимо, когда приложению в вашей гостевой ВМ требуется определённый MAC адрес.
Rate limit
Данный текстовый блок служит определению максимально допустимой скорости создаваемого сетевого интерфейса в МегаБайтах в секунду. Это очень полезная опция для ограничения сетевой среды на основе ВМ. Если не определено никакое значение, данная ВМ попытается использовать такую полосу пропускания, какая будет доступна.
Multiqueues
Обычно ВМ KVM имеют единственную очередь в которую попадают отправляемые и получаемые сообщения по одному за раз без какой- либо одновременности. Множественные очереди удаляют это узкое место делая возможными одновременные отсылку и приём путём усиления от виртуальных ядер ЦПУ для параллельных очередей. Множественные очереди в особенности полезны для ВМ, которые проявляют активность для большого числа клиентов, например, для веб- серверов. В закладке Proxmox Network для блока диалога создания ВМ мы можем ввести численное значение для определения числа параллельных очередей, которое должна использовать данная ВМ. Это значение не должно быть больше чем число выделенных данной ВМ vCPU. Например, если данная ВМ имеет 4 виртуальных ядра, мы можем установит значение для множественных очередей равное 4. Множественность очередей серьёзно увеличивает производительность сетевой среды ВМ, так как и отправка, и приём могут осуществляться одновременно.
Имейте в виду, что включение множественных очередей также увеличивает использование ЦПУ данной ВМ, так как каждая очередь зависит от своего vCPU.
Disconnect
Если данная опция включена, виртуальный сетевой интерфейс будет создан для данной ВМ, однако не будет активирован.
Создание ВМ клонированием
Рисунок 14
После того, как ВМ конвертирована в шаблон, эта ВМ сама по себе больше не используется. Однако мы можем изменять аппаратные ресурсы. Другой разницей, которую нужно отметить, заключается в том, что получаемая иконка в инструментальной панели Proxmox уникальна для шаблонов KVM, что отображено на снимке экрана ниже:
Рисунок 15
Рисунок 16
Режим
В Proxmox существует два режима клонирования:
Полное клонирование (Full Clone)/p>
Связанное клонирование (Linked Clone)
При полном клонировании создаётся идентичная копия выбранной ВМ, включая образы виртуальных дисков. Это на самом деле изолированная система, поскольку она никоим образом не зависит от исходного шаблона или ВМ. Даже если мы удалим такой исходный шаблон или ВМ, вновь развёрнутая ВМ всё ещё продолжит работать без каких- бы то ни было проблем. Полный клон потребляет столько же пространства хранения, сколько и оригинальная ВМ, так как виртуальный диск тоже клонируется. Полные клоны полезны в случае, когда выделяемые ресурсы идентичны для всех развёртываемых ВМ, однако гостевые операционные системы могут различаться, или нет.
Связанный клон создаёт дубликат первоначальной ВМ за вычетом первоначального образа виртуального диска. Это создаёт дополнительный чистый образ диска, который ссылается на свой прообраз виртуального диска, а в связанный образ клонированного диска помещаются только новые данные. Все запросы на чтение данных, за исключением запросов к новым данным, автоматически перенаправляются к первоначальному образу диска. Связанный клон сильно зависит от исходного шаблона или ВМ. Данный режим клона полезен в случае, когда все клонированные ВМ имеют в точности одни и те же настройки оборудования и программных средств, включая гостевые операционные системы. Связанные клоны потребляют намного меньше пространства хранения, поскольку первоначальный ил базовый образ никогда не дублируется, а просто применяется ссылка на него со стороны нового привязанного клона ВМ. Такой образ диска связанного клона выглядит так, как это показано на следующем экранном снимке:
Рисунок 17
Как мы можем видеть из предыдущего снимка экрана, связанный образ диска создаётся в подкаталоге каталога своего первоначального образа диска исключительно для хранения новых данных. Так как связанные клоны ВМ сильно зависят от своих исходных шаблонов, очень важно гарантировать, что первоначальный шаблон или ВМ не будут нарушены никаким образом. Любые нарушения в шаблоне вызовут отказ всех связанных клонов.
Создание ВМ из шаблона
В Proxmox мы можем также клонировать ВМ из шаблонов. Шаблоны KVM создаются путём преобразования ВМ KVM. Единственная разница между ВМ KVM и шаблоном состоит в том, что будучи единожды преобразованными, шаблоны не могут включаться как ВМ. Это предотвращает дальнейшие изменения в его образе виртуального диска, обеспечивая идентичность клона его оригинальной ВМ.
Хотя мы и не можем включать свой шаблон, мы всё ещё можем делать изменения ресурсов, таких как ЦПУ, ОЗУ и тому подобных, однако это не рекомендуется практиковать, так как любые изменения в аппаратных средствах могут вызывать проблемы при включении клонированной ВМ.
Рисунок 18
Чтобы создать новый клон, кликните правой кнопкой мыши по шаблону, а затем выберите Clone для открытия блока диалога создания клона шаблона, как это показано на следующем снимке экрана:
Рисунок 19
Параметры в окне диалога идентичны параметрам процесса создания ВМ, клонируемой без какого- либо шаблона.
Расширенные параметры настройки для ВМ
Теперь мы рассмотрим некоторые расширенные опции настройки, которые мы можем использовать для расширения возможностей виртуальных машин KVM.
Настройка звуковых устройств
В данном разделе мы собираемся рассмотреть как добавлять поддержку звука в ВМ. По умолчанию Proxmox не добавляет аудио оборудование к ВМ. Чтобы операционная система ВМ могла запустить звуковую службу, в файл настройки такой ВМ должны быть добавлены некотороые аргументы при помощи CLI. В Proxmox VE 4.1 нет возможности добавлять звуковой интерфейс через его GUI. Последующие шаги добавят в ВМ звуковое устройство:
Зарегистрируйтесь в узле Proxmox через SSH или напрямую в его консоли.
Откройте файл настройки данной ВМ текстовым редактором, в котором вы предпочитаете работать, и добавьте следующие параметры:
Для ВМ Windows 10 и более поздних версий:
Для ВМ основе Windows XP:
Сохраните файл настройки и выйдите из редактора.
Выполните цикл перезагрузки этой ВМ для активации звукового устройства.
Настройка проброса PCI
В Proxmox присутствует возможность проброса (passthrough) устройств PCI напрямую в ВМ. В данном разделе мы собираемся рассмотреть как настроить и осуществить проверку проброса PCI. Для включения и настройки проброса PCI в Proxmox необходимо выполнить следующие шаги:
Зарегистрируйтесь в узле Proxmox через SSH или напрямую в его консоли.
Откройте файл настройки grub с помощью текстового редактора:
Измените GRUB_CMDLINE_LINUX_DEFAULT=&quiet& на следующее:
Сохраните изменения и выйдите из редактора.
Для обновления grub выполните следующую команду:
Только в случае, если используете ЦПУ AMD добавьте следующую строку в файл настройки /etc/modprobe.d/kvm_iommu_map_guest.conf :
Перезагрузите данный узел Proxmox.
Определите адрес нужного вам устройства PCI в виде xx:xx.x при помощи следующей команды:
Введите следующую строку идентификатором устройства PCI в файл настройки ВМ: hostpci0: xx:xx.x при помощи следующей команды:
Выполните цикл перезагрузки этой ВМ для активации звукового устройства.
Установите необходимые драйверы для данного устройства PCI в операционной системе выбронной ВМ.
Настройка проброса GPU
В данном разделе мы собираемся рассмотреть как настроить видеоадаптер на применение напрямую в ВМ. Поддержка устройств PCI Express, таких как карты видео адаптеров, была добавлена в Proxmox начиная с версии 3.3. Для включения подобного проброса узел Proxmox должен иметь ядро PVE 3.10. Если вы используете Proxmox VE 4.1, вы, скорее всего, имеете самое последнее ядро. Мы можем добавить PXI Express и выполнить проброс GPU в ВМ из CLI путём добавления параметров в файл настройки ВМ.
Следующие шаги покажут как включать стандартные не-GPU PCI Express устройства, устройства нп основе GPU, а также устройства GPU со встроенными аудио- устройствами в ВМ:
Откройте файл настройки ВМ в текстовом редакторе:
Определите идентификатор нужного вам устройства PCI следуя шагам из предыдущего раздела при помощи следующей команды:
Введите следующую строку идентификатором устройства PCI в файл настройки ВМ: hostpci0: xx:xx.x при помощи следующей команды:
Добавьте следующие строки в зависимости от типа добавляемого устройства PCI Express:
Для стандартного не-GPU устройства PCI Express:
Для видео адаптеров GPU PCI Express:
Сохраните файл настройки и выполните цикл перезагрузки этой ВМ.
Установите необходимые драйверы внутри операционной системы выбранной ВМ.
Настройка подключения во время работы
В данном разделе мы собираемся рассмотреть как настраивать подключаемые во время работы опции в виртуальных машинах Proxmox. Применяя функцию подключения во время работы, мы можем добавлять и удалять устройства или ресурсы в ВМ без перезапуска или цикла включения данной ВМ. В Proxmox VE 4.1 мы можем применять опции подключения во время работы (hotplug) для следующих ресурсов:
S Proxmox 4.1 мы можем только увеличивать ЦПУ и оперативную память, но не можем уменьшать их. И диски, и сетевые интерфейсы могут в равной степени подключаться и отключаться во время работы. Следующая таблица отображает какие типы устройств поддерживаются в различных операционных системах: