Proxmox ssd emulation что это
Расскажу про свой опыт установки панели в Proxmox в KVM и задействовании режима trim для дисков.
Как говорит документация по Proxmox нужно с дисках включать режим discard, делать тип контроллера -VirtIO SCSI, а диски не VirtIO Block, а SCSI !
Опция discard включается галочкой (в русской версии называется "Отклонить"!).
Также я на всякий случай включил галочку "SSD emulation".
1. Сделал 2 диска: 80 под систему, 300 под папку /home
2. Ставил с CentOS-7-x86_64-Minimal-1908.iso
Выбрал ручное разбиение. LVM, Автоматическое разбиение, потом руками подправлял. Сделал 2 VirtualGroup по каждому диску в группе.
Ставил на ext4.
Переходим к предварительной настройке ОС.
3. Обновил систему
4. Установить qemu-guest-agent
5. Включить trim
5.1 По инструкции
Далее по инструкции
5.2 Добавил опцию discard в каждый диск (включая swap) в /etc/crypttab (он у меня пустой, поскольку шифрование не включал) и /etc/fstab
по принципу:
/dev/sda1 /boot ext4 defaults,discard 1 2
5.3 Установил issue_discards = 1 в /etc/lvm/lvm.conf
5.4 Перестроил initramfs
ПЕРЕГРУЗИТЬСЯ.
Настройка trim завершена. Проверял - работает.
Вручную перед бекапом делать обязательно.
и будет вам счастье.
Можно включить почасово
6. Удалил старые ядра
2-е добавилось после начального обновления системы. Т.е. я старое удалил, новое оставил.
Установил в /etc/yum.conf installonly_limit=2 на будущее.
7. Удалить неиспользуемые локали, перестроить архив локалей
При этом консоли ssh закроются.
Подождать немного, что бы архив локалей перестроился и перегрузить.
Таким образом /usr/lib/locale/locale-archive уменьшается с 105мб до 5,5мб.
8. Я еще ставил себе ncdu - полезная утилита для просмотра размеров папок. Ну это кому нужно:
При желании вы можете удалить ncdu-1.14.2.tar.gz файл и каталог, в который были извлечены исходные файлы, так как они вам больше не нужны.
9. Установить brainycp
После установки всего-всего панель с системой у меня заняла 5,8Гб.
(правда я немного jail_skeleton подрезал)
Все.
Надеюсь, кому-то поможет.
Я с этим trim'ом день промучался и наэкспериментировался, но именно так все работает.
Добавлю еще свои фичи по настройке.
1) Со временем обнаружилось, что atop, как сервис, пишет много логов.
Отключил:
2) Далее возникла проблема с тем, что trim дисков делается, но на разделе swap все равно есть занятые блоки и он в бекап proxmox'a попадает, как занятое пространство.Для справки: proxmox считает блок на диске гостевой kvm пустым, если там записаны нули. Если не нули - блок занят.
trim на дисках работает, поэтому их не нужно забивать нулями, а со swap такое не проходит.
Поэтому перед бекапом я делал:
Почистил руками все архивные старые логи. Оставил только последние, без дат.
Не забываем проверить и удалить старые ядра. См. предыдущий пост. Если вы установили опцию installonly_limit=2 в /etc/yum.conf, то больше 2-х не будет.
Потом чистка неиспользуемых блоков на swap-разделе.
Соответственно подправьте для своих разделов /dev/dm-1 - у меня swap (узнать это можно через swapon -s)
Забивать нулями для swap нужно, поскольку я думаю, что swapoff только отключает и не очищает.
Раздел swap после забития нулями перестает быть разделом swap поэтому его нужно заново пересоздать mkswap.
После этого бекап в proxmox минимален.
Чаще всего «слабым звеном» в работе виртуальной машины Windows на Proxmox является дисковая подсистема. Ниже собран несколько советов, которые помогут приблизиться к максимально возможным скоростям.
Здесь собраны советы только по ускорению дисковой подсистемы программными методами. Использование SSD в single или raid — отдельная тема для обсуждения.
Рекомендуется использовать устройства virtio там, где это возможно. Это обеспечит лучшую производительность. К примеру, использование VirtIO Generic Disk Controller по сравнению с эмулируемым IDE -контроллером увеличит последовательную запись в 2 раза. Использование сетевого интерфейса VirtIO увеличит производительность сетевого интерфейса в 3 раза по сравнению с эмулируемой сетевой картой Intel E1000.
Начало работы
Хочется обратить внимание на то, что Proxmox готов к созданию новых машин сразу после установки. Тем не менее, рекомендуем выполнить предварительные настройки, чтобы в дальнейшем системой было легко управлять. Практика показывает, что гипервизор и виртуальные машины стоит разнести по разным физическим носителям. О том, как это сделать и пойдет речь ниже.
Как быстро развернуть гипервизор Proxmox VE
Установка чаще всего не вызывает никаких вопросов. Скачиваем актуальную версию образа с официального сайта и записываем его на любой внешний носитель с помощью утилиты Win32DiskImager (в Linux используется команда dd), после чего загружаем сервер непосредственно с этого носителя. Наши клиенты, арендующие у нас выделенные серверы, могут воспользоваться двумя еще более простыми путями – просто смонтировав нужный образ непосредственно из KVM-консоли, либо используя наш PXE-сервер.
Программа установки имеет графический интерфейс и задаст всего лишь несколько вопросов.
-
Выбираем диск, на который будет выполнена установка. В разделе Options можно также задать дополнительные параметры разметки.
Веб-интерфейс управления станет доступен по адресу
Отключение swap в Proxmox
Отключить swap достаточно просто. Узнаем название раздела swap:
В нашем примере это /dev/nvme0n1p3.
Далее отключаем swap:
Эта команда временно отключит swap. Чтобы отключить его навсегда, нужно в /etc/fstab закомментировать строку с его монтированием:
Настраиваем swap в Proxmox
Чтобы добиться максимального быстродействия дисковой подсистемы у сервера Proxmox стоит отключить swap или снизить процент его использования.
Часто на сервере Proxmox можно наблюдать картину:
Это все из-за того, что Debian по умолчанию при использовании более 40% ОЗУ , начинает пользоваться swap. Для рабочей станции с небольшим количеством ОЗУ – это нормально, но для сервера, где оперативной памяти в разы больше этот параметр не совсем подходит.
- отключить swap в Proxmox вообще;
- ограничить процент использования swap в Proxmox.
Ограничиваем работу swap
Узнаем при каком проценте занятости ОЗУ , наш Proxmox начинает скидывать в swap:
Это стандартное значение. При такой настройке от 40% занятой ОЗУ , начинается заполнение свопа.
Для сервера нужно установить это значение близким к нулю. При нуле область подкачки использоваться вообще не будет. Можно установить это значение в 10, что позволит Proxmox’у использовать до 90% оперативной памяти без задействования механизма своппинга. При загрузке ОЗУ более 90% часть данных будет переносится в swap. Можно поставить это значение и в 5 и в 1.
Чтобы установить это значение, выполняем команду:
Если запустить эту команду без -w , то команда примениться до первой перезагрузки. Удобно для тестов.
Если знаете еще способы увеличения скорости дисковой подсистемы, то прошу оставлять их в комментариях.
Если кому интересно, мы тут недавно потестили производительность чтение/запись внутри windows машины на ноде с Proxmox 4.3.
Хостовая система была установленна на raid10 реализованный двумя разными способами (zfs и mdadm+lvm)
Тесты проводились на Windows-госте, так-как в первую очередь интересовала производительность именно этой ОС.
Должен признать, это вторая версия статьи, в первой была допущена фатальная ошибка:
zfs тестировался на local storage, а не на zvol, т.к. я до последнего думал, что proxmox не поддерживает zvol.
Огромное спасибо winduzoid за то, что заметил данное недоразумение.
Мысль о написании данной статьи навели коментарии к недавней статье про Установку PROXMOX 4.3 на Soft-RAID 10 GPT от vasyakrg. Не холивара ради, но я решил опубликовать наши недавние результаты.
Добавить новое хранилище в Proxmox
Авторизуемся в панели управления и заходим в разделы Датацентр ➝ Хранилище ➝ Добавить ➝ Директория.
В открывшемся окне заполняем следующие поля:
- ID — название будущего хранилища;
- Директория — /mnt/storage;
- Содержимое — выделяем все варианты (поочередно щелкая на каждом варианте).
Настроить дисковые накопители
Следующим этапом следует настроить хранилище, которое можно будет использовать для сохранения данных виртуальных машин и резервных копий.
ВНИМАНИЕ! Приведенный ниже пример дисковой разметки можно использовать только для тестовых целей. Для эксплуатации в реальных условиях мы настоятельно рекомендуем использовать программный или аппаратный RAID-массив, чтобы исключить потерю данных при выходе дисков из строя. О том, как правильно приготовить дисковый массив к работе и как действовать в случае аварийной ситуации мы расскажем в одной из следующих статей
Предположим, что физический сервер имеет два диска — /dev/sda, на который установлен гипервизор и пустой диск /dev/sdb, который планируется использовать для хранения данных виртуальных машин. Чтобы система смогла увидеть новое хранилище, можно воспользоваться самым простым и эффективным методом — подключить его как обычную директорию. Но перед этим следует выполнить некоторые подготовительные действия. В качестве примера посмотрим, как подключить новый диск /dev/sdb, любого размера, отформатировав его в файловую систему ext4.
-
Размечаем диск, создавая новый раздел:
вторник, 5 ноября 2019 г.
Гиперконвергентная инфраструктура
Результаты:
Итак сами результаты:
Позже мы добавили в наш zfs-пул кэширующий SSD.
Ради интереса мы так же запустили тесты на одном SSD:
Заключение
В этой статье были изложены основы того, как можно начать работать с Proxmox VE и мы надеемся, что она поможет начинающим специалистам сделать первый шаг и попробовать виртуализацию в действии.
Proxmox VE — это действительно очень мощный и удобный инструмент для любого системного администратора; главное не бояться экспериментировать и понять, как это действительно работает.
Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.
Управление службами Ceph на узлах Proxmox VE
Proxmox VE объединяет ваши вычислительные системы и системы хранения, т.е. вы можете использовать одни и те же физические узлы в кластере как для вычислений (обработка виртуальных машин и контейнеров), так и для реплицированного хранилища. Традиционные хранилища вычислительных и запоминающих ресурсов могут быть объединены в одно гиперконвергентное устройство. Отдельные сети хранения (SANs) и подключения через сетевые хранилища (NAS) исчезают. Благодаря интеграции Ceph, программной платформы хранения с открытым исходным кодом, Proxmox VE имеет возможность запускать и управлять хранилищем Ceph непосредственно на узлах гипервизора.
Ceph - это распределенное хранилище объектов и файловая система, предназначенная для обеспечения отличной производительности, надежности и масштабируемости.
- Простая настройка и управление с поддержкой CLI и GUI
- Тонкая настройка
- Поддержка снапшотов
- Самовосстановление
- Масштабируемость до уровня эксабайт
- Настройка пулов с различными характеристиками производительности и резервирования
- Данные реплицируются, что делает их отказоустойчивыми
- Работает на бюджетном оборудовании
- Нет необходимости в аппаратных RAID контроллерах
- Открытый исходный код
- Ceph Monitor (ceph-mon)
- Ceph Manager (ceph-mgr)
- Ceph OSD (ceph-osd; Object Storage Daemon)
Предварительное условие
Для построения гиперконвергентного кластера Proxmox + Ceph должно быть как минимум три (желательно) одинаковых сервера для установки.
Проверьте также рекомендации с веб-сайта Ceph.
CPU
Более высокая частота ядра процессора уменьшает задержки и является предпочтительной. В качестве простого практического правила вы должны назначить ядро (или поток) процессора каждому сервису Ceph, чтобы обеспечить достаточно ресурсов для стабильной и надежной работы Ceph.
Память
Особенно в гиперконвергентной установке, потребление памяти необходимо тщательно контролировать. В дополнение к предполагаемой рабочей нагрузке от виртуальных машин и контейнера, Ceph требуется достаточно памяти, чтобы обеспечить хорошую и стабильную производительность. Как правило, для примерно 1 TiB данных, 1 GiB памяти будет использоваться OSD. Кэширование OSD будет использовать дополнительную память.
Сеть
Мы рекомендуем пропускную способность сети, которая используется исключительно для Ceph не менее 10 GbE или более. Ячеистая топология сети 2 также является выходом, если нет доступных коммутаторов 10 GbE. Объем трафика, особенно во время восстановления, будет мешать другим службам в той же сети и может даже разрушить стек кластера Proxmox VE. Кроме того, оцените свои потребности в пропускной способности. В то время как один жесткий диск может не насыщать канал 1 Гб, несколько жестких дисков на узле могут, а современные накопители SSD NVMe даже быстро насыщают пропускную способность 10 Gbps. Развертывание сети, способной к еще большей пропускной способности, гарантирует, что это не ваше узкое место и не будет в ближайшее время, возможно 25, 40 или даже 100 Gbps.
Диски
При планировании размера кластера Ceph важно учитывать время восстановления. Особенно с небольшими кластерами, восстановление может занять много времени. Рекомендуется использовать твердотельные накопители вместо жестких дисков в небольших установках, чтобы сократить время восстановления, минимизируя вероятность последующего сбоя во время восстановления.
В целом SSD накопители обеспечивают больше операций ввода-вывода, чем вращающиеся диски. Этот факт и более высокая стоимость могут сделать привлекательным разделение пулов на основе классов устройств (см раздел 4.2.9). Другая возможность ускорить OSD - использовать более быстрый диск для журнала или DB/Write-Ahead-Log устройства (см. раздел Ceph OSD.) Если для нескольких операционных систем используется более быстрый диск, необходимо выбрать правильный баланс между OSD и Wal/DB (или журнальным) диском, в противном случае более быстрый диск становится узким местом для всех связанных операционных систем. Помимо типа диска, Ceph лучше всего работает с равномерным распределением размеров и количества дисков на узел. Например, 4 х 500 ГБ дисков с в каждом узле лучше, чем смешанная установка с одним 1 ТБ и три 250 ГБ диска.
Также необходимо сбалансировать количество OSD и емкость одного OSD. Большая емкость позволяет увеличить плотность хранения, но это также означает, что сбой одного OSD сразу заставляет ceph восстанавливать большее количество данных.
Отказ от RAID
Поскольку Ceph самостоятельно обрабатывает избыточность объектов данных и распаралеливание операций записи на диски (OSD) , использование RAID - контроллера обычно не улучшает производительность или доступность. Напротив, Ceph предназначен для работы напрямую с дисками самостоятельно, без какой-либо абстракции между ними. RAID - контроллеры не предназначены для использования Ceph и могут усложнять ситуацию, а иногда даже снижать производительность, так как их алгоритмы записи и кэширования могут мешать работе Ceph.
Начальная установка и настройка Ceph
С Proxmox VE вы можете воспользоваться простым в использовании мастером установки Ceph. Щелкните на одном из узлов кластера и перейдите к разделу Ceph в дереве меню. Если пакет еще не установлен, вам будет предложено сделать это сейчас.
Мастер разделен на различные разделы, каждый из них должен быть успешно завершен, чтобы использовать Ceph. После запуска установки мастер загрузит и установит все необходимые пакеты из репозитория Ceph Proxmox VE.
После завершения первого шага, вам нужно будет создать конфигурацию. Этот шаг необходим только один раз для каждого кластера, поскольку эта конфигурация автоматически распространяется среди всех остальных узлов кластера через файловую систему конфигурации кластера Proxmox VE (pmxcfs), глава 7.
- Публичная сеть: Вы должны настроить выделенную сеть для Ceph, этот параметр является обязательным. Отделение вашего трафика Ceph настоятельно рекомендуется, потому что это может привести к проблемам с другими зависимыми от задержки службами, например, взаимодействие узлов кластера может снизить производительность Ceph, если этого не сделано.
- Сеть кластера: В качестве дополнительного шага вы можете пойти еще дальше и отделить трафик репликации разделов OSD (см. 4.2.7) и heartbeat трафик. Это облегчит работу общедоступной сети и может привести к значительному повышению производительности, особенно в больших кластерах.
У вас есть еще два варианта, которые считаются расширенными и поэтому должны изменяться только в том случае, если вы являетесь экспертом.
- Количество реплик: Определяет частоту репликации объекта.
- Минимальное количество реплик: Определяет минимальное количество требуемых реплик для I/O, помеченных как завершенные.
Установка пакетов Ceph
Создание начальной конфигурации Ceph
Создание Ceph мониторов
Ceph Monitor (MON) 3 поддерживает главную копию карты кластера. Для высокой доступности необходимо иметь не менее 3 мониторов. Один монитор уже был установлен, если вы использовали мастер установки. Вам не понадобится более 3 мониторов, пока ваш кластер мал до среднего размера, только действительно большие кластеры требуют большего количества.
Создание Ceph Manager
Создание Ceph OSD
Используя GUI или с помощью коммандной строки следующим образом: Совет Мы рекомендуем размер кластера Ceph, начиная с 12 OSD, равномерно распределенных между вашими, по крайней мере, тремя узлами (4 OSD на каждом узле). Если диск использовался ранее (например, ZFS/RAID/OSD), для удаления таблицы разделов, загрузочного сектора и всех оставшихся OSD должна быть достаточно следующей команды. Внимание! Приведенная выше команда уничтожит данные на диске! Ceph Bluestore
Начиная с выпуска Ceph Kraken, был представлен новый тип хранилища ceph OSD, так называемый Bluestore 5 . Это значение по умолчанию при создании OSD начиная с Ceph Luminous.
Block.db и block.wal
- bluestore_block__size from ceph configuration.
- . database, section osd
- . database, section global
- . file, section osd
- . file, section global
Создание Ceph Пулов
Пул-это логическая группа для хранения объектов. Он содержит группы размещения (PG, pg_num), набор объектов.
Если параметры не заданы, используется значение по умолчанию 128PG, size 3 реплики и min_size 2 реплики для обслуживания объектов в случае деградации пула. Примечание Количество PG по умолчанию подходит для 2-5 дисков. Ceph выдает предупреждение HEALTH_WARNING, если у вас слишком мало или слишком много PG в вашем кластере. Рекомендуется рассчитать число PG в зависимости от ваших настроек, в интернете вы можете найти формулу и онлайн PG калькулятор 6 . Количество PG может быть увеличено позже, но оно никогда не может быть уменьшено.
Ceph CRUSH и классы устройств
Фундамент Ceph - это его алгоритм "Controlled Replication Under Scalable Hashing" (CRUSH 8 ).
Классы устройств можно увидеть в выходных данных ceph osd tree. Эти классы представляют свои собственные корневые сегменты, которые можно увидеть с помощью приведенной ниже команды. Пример вывода формы приведенной выше команды:
Ceph Client
Затем можно настроить Proxmox VE для использования таких пулов для хранения образов виртуальных машин или контейнеров. Просто используйте графический интерфейс, чтобы добавить новое хранилище RBD (см. раздел Ceph RADOS Block Devices (RBD) раздел 8.14).
CephFS
Ceph также предоставляет файловую систему, работающую поверх того же хранилища объектов, что и блочные устройства RADOS. Сервер метаданных (MDS) используется для сопоставления объектов, поддерживаемых RADOS, с файлами и каталогами, что позволяет обеспечить реплицированную файловую систему, совместимую с POSIX. Это позволяет иметь кластерную высокодоступную общую файловую систему простым способом (если ceph уже настроен). Его серверы метаданных гарантируют, что файлы будут равномерно распределены по всему кластеру Ceph, таким образом, что даже высокая нагрузка не будет перегружать один хост, что может быть проблемой при использовании общих файловых систем с традиционным подходом, например таких, как NFS.
Proxmox VE поддерживает оба варианта, используя существующую CephFS в качестве хранилища (см. раздел 8.15) для сохранения резервных копий, ISO-файлов или шаблонов контейнеров и создавая гиперконвергентную CephFS.
Сервер метаданных (MDS)
Для функционирования CephFS необходим как минимум один сервер метаданных, который должен быть настроен и запущен. Можно просто создать его через узел Proxmox VE web GUI -> панель CephFS или в командной строке с помощью: В кластере можно создать несколько серверов метаданных. Но с настройками по умолчанию только один единовременно может быть активным. Если MDS или его узел перестает отвечать на запросы (или аварийно завершает работу), другой резервный MDS будет активирован. Можно ускорить передачу обслуживания между активным и резервным MDS помощью опции hotstandby при создании MDS, или если вы его уже создали его, вы можете установить/добавить: в соответствующем разделе MDS файла ceph.conf . Если этот параметр включен, этот конкретный MDS всегда будет опрашивать активный, так что он сможет приступить к обслуживанию быстрее, поскольку он находится в готовом к обслуживанию состоянии. Но, естественно, регулярный опрос вызовет некоторую дополнительную нагрузку на вашу систему и активный MDS.
Несколько активных MDS
Начиная с Ceph Luminous (12.2.x), вы также можете использовать несколько активных серверов метаданных, но это обычно полезно только для большого количества параллельных клиентов, так как в противном случае MDS редко является узким местом. Если вы все же хотите настроить их, пожалуйста, обратитесь к документации ceph 9 .
CephFS интегрирована в Proxmox VE и вы можете легко создавать CephFS через веб-интерфейс, интерфейс командной строки или внешний API. Для этого требуются некоторые предварительные условия:
- Установка пакетов Ceph (см. раздел 4.2.3), если это уже было сделано некоторое время назад, вы можете повторно запустить его в обновленной системе, чтобы убедиться, что также установлены все пакеты, связанные с CephFS.
- Установлены Мониторы. (см. Раздел 4.2.5)
- Настроены ваши OSD. (см. Раздел 4.2.7)
- Настроен хотябы один MDS. (см. Раздел 4.2.11)
Внимание! Уничтожение CephFS сделает все его данные непригодными для использования, и может быть отменено! Если вы действительно хотите уничтожить существующий CephFS, вам сначала нужно остановить или уничтожить все сервера метаданных (MDS). Вы можете уничтожить их либо через веб-интерфейс или интерфейс командной строки, с помощью: на каждом узле Proxmox VE, где размещается демон MDS.
Ceph Мониторинг и устранение неполадок
Хорошей практикой является непрерывный мониторинг работоспособности ceph с самого начала развертывания. Как через набор инструментов самого ceph, так и путем доступа к его статусу через API Proxmox VE.
Нижеследующие команды ceph могут использоваться, чтобы увидеть, является ли кластер исправным (HEALTH_OK), есть ли предупреждения (HEALTH_WARN), или ошибки (HEALTH_ERR). Если кластер находится в нерабочем состоянии, нижеприведенные команды состояния также дадут вам обзор текущих событий и действий.
Создание жесткого диска
При создании Hard Disk у виртуальной машины, выбираем SCSI (последний пункт), в не VirtIO Block. VirtIO blk — это предыдущий «этап» развития. Если сервер подключен к надежному источнику бесперебойного питания, то тип кэша ставим в — write back. Если ИБП нет, то покупаем ИБП и ставим Write Back.
Если образы виртуальных машин размещены на SSD , то обязательно ставим галки Discard и SSD emulation, чтобы правильно работала технология TRIM . Эмуляция SSD не поддерживается на дисках VirtIO Block.
Включаем IO thread. Опция IO Thread работает только если в качестве контроллера установлено значение VirtIO SCSI или VirtIO SCSI single. Если этот параметр включен, Proxmox будет создавать один поток ввода-вывода для каждого контроллера хранения, а не один поток для всех операций ввода-вывода. Это позволяет повысить производительность. Особенно виден прирост скорости при использовании нескольких дисков.
Водные данные:
CPU: Intel® Core(TM) i7-3820 CPU @ 3.60GHz
RAM: 20GB (1334 MHz)
HDD: 4x500GIB (ST500NM0011, ST500NM0011, ST3500418AS, WDC WD5000AAKX-22ERMA0)
SSD: 250GiB (PLEXTOR PX-256M5Pro)
OS: Proxmox Virtual Environment 4.3-10Виртуальная машина:
CPU: 8 (1 sockets, 8 cores)
RAM: 6.00 GiB
HDD: 60 GiB (virtio)
OS: Windows Server 2008 R2 Server Standard (full installation) SP1 [6.1 Build 7601] (x64)Все результаты получены с помощью утилиты CrystalDiskMark 5.2.0 x64.
Каждый тест проводился в 5 итераций по 32GB.
Никаких дополнительных твиков и изменений не указанных в статье не вносилось ни в конфигурацию гипервизора ни в конфигурацию виртуальной машины. То есть использовался просто свежеустановленный Proxmox и восстановленная из бэкапа виртуалка с Windows.Руководство администратора Proxmox VE R 6.0 Глава 4.
Что нужно сделать после установки
Есть несколько важных вещей, которые следует выполнить после установки Proxmox. Расскажем о каждой из них подробнее.
Создать виртуальную машину
Для создания виртуальной машины выполняем следующую последовательность действий:
- Определяемся с версией операционной системы.
- Заранее закачиваем ISO-образ.
- Выбираем в меню Хранилище только что созданное хранилище.
- Нажимаем Содержимое ➝ Загрузить.
- Выбираем из списка ISO-образ и подтверждаем выбор нажатием кнопки Загрузить.
Создаем нашу первую виртуальную машину:
- Нажимаем Создать VM.
- Заполняем поочередно параметры: Имя ➝ ISO-Image ➝ Размер и тип жесткого диска ➝ Количество процессоров ➝ Объем оперативной памяти ➝ Сетевой адаптер.
- Выбрав все желаемые параметры нажимаем Завершить. Созданная машина будет отображена в меню панели управления.
- Выбираем ее и нажимаем Запуск.
- Переходим в пункт Консоль и выполняем установку операционной системы точно таким же образом, как и на обычный физический сервер.
Позаботиться о безопасности
Мы можем порекомендовать установить популярнейшую утилиту Fail2Ban, защищающую от атак методом перебора паролей (брутфорс). Принцип ее работы заключается в том, что если злоумышленник превысит определенное количество попыток входа за указанное время с неверным логином/паролем, то его IP-адрес будет заблокирован. Срок блокировки и количество попыток можно указать в конфигурационном файле.Исходя из практического опыта, за неделю работы сервера с открытым ssh-портом 22 и внешним статическим IPv4-адресом, было более 5000 попыток подобрать пароль. И около 1500 адресов утилита успешно заблокировала.
Для выполнения установки приводим небольшую инструкцию:
- Открываем консоль сервера через веб-интерфейс или SSH.
- Обновляем источники пакетов:
Ответ утилиты будет выглядеть примерно так:
Аналогичным способом можно закрыть от подобных атак Web-интерфейс, создав соответствующее правило. Пример такого правила для Fail2Ban можно найти в официальном руководстве.Дисковый контроллер
В качестве SCSI Controller выбираем VirtIO SCSI . Далее качаем ISO -образ vitio-win.iso с последними драйверами, добавляем CD/DVD драйвер для машины. Монтируем скаченный образ. Загружаем ОС и устанавливаем необходимые драйвера. После всех манипуляций должно получиться вот так:
Преимущества гиперконвергентной инфраструктуры (HCI) с Proxmox VE
- Масштабируемость: плавное расширение вычислительных, сетевых и запоминающих устройств (т. е. быстрое и независимое масштабирование серверов и хранилищ).
- Низкая стоимость: Proxmox VE является ПО с открытым исходным кодом и объединяет все необходимые компоненты, такие как вычислительные ресурсы, хранилище, сеть, резервное копирование и Центр управления. Он может заменить дорогостоящую вычислительную инфраструктуру / инфраструктуру хранения данных.
- Защита данных и эффективность: интегрированы такие службы, как резервное копирование и аварийное восстановление.
- Простота: простота настройки и централизованное администрирование.
- Открытый исходный код: • Отсутствие блокировки со стороны поставщика
Графики:
Для наглядности я решил нарисовать несколько графиков
Скорость на последовательное чтение и запись:
Скорость на случайное чтение и запись:
Количество IOPS на случайное чтение и запись:
Формат образа жесткого диска
Используем образы машин только в формате raw. Есть мнение, что qcow2 только немного уступает в скорости raw, но нам важна максимальная скорость. Из минусов использования RAW — нет снапшотов для резервного копирования. Если это критично, то выбираем qcow2. Нужна скорость — выбираем RAW .
Выводы:
Не смотря на то, что результаты получились довольно необычные, а местами даже странные, можно заметить что raid10 собранный на zfs, с опцией cache=none для диска показал более хороший результат, нежели raid10 собранный на mdadm + lvm как на чтение, так и на запись.
Однако, с опцией cache=writeback raid10 собранный на mdadm + lvm заметно выходит вперед.you refer to an old post, newer kernels and newer qemu version are in place now. for zfs, cache=writeback is the recommended setting.
Кроме того IlyaEvseev в своей статье писал, что writeback кэш дает хорошие результаты для виртулок с Windows.
На этом пожалуй все, если у вас есть какие-либо предложения на тему того, как еще можно увеличить производительность дисковых операций на гостевой машине, с радостью их выслушаю.
Сегодня речь пойдет о том, как быстро и достаточно просто на одном физическом сервере развернуть несколько виртуальных серверов с разными операционными системами. Любому системному администратору это позволит централизованно управлять всей IT-инфраструктурой компании и экономить огромное количество ресурсов. Использование виртуализации помогает максимально абстрагироваться от физического серверного оборудования, защитить критичные сервисы и легко восстановить их работу даже в случае очень серьезных сбоев.
Без всякого сомнения, большинству системных администраторов знакомы приемы работы с виртуальной средой и для них эта статья не станет каким-либо открытием. Несмотря на это, есть компании, которые не используют гибкость и скорость работы виртуальных решений из-за недостатка точной информации о них. Мы надеемся, что наша статья поможет на примере понять, что гораздо проще один раз начать использовать виртуализацию, чем испытывать неудобства и недостатки физической инфраструктуры.
К счастью, попробовать как работает виртуализация достаточно просто. Мы покажем, как создать сервер в виртуальной среде, например, для переноса CRM-системы, используемой в компании. Практически любой физический сервер можно превратить в виртуальный, но вначале необходимо освоить базовые приемы работы. Об этом и пойдет речь ниже.Как это устроено
Когда речь идет о виртуализации, многим начинающим специалистам сложно разобраться в терминологии, поэтому поясним несколько базовых понятий:
- Гипервизор – специальное программное обеспечение, которое позволяет создавать виртуальные машины и управлять ими;
- Виртуальная машина (далее VM) – это система, представляющая собой логический сервер внутри физического со своим набором характеристик, накопителями и операционной системой;
- Хост виртуализации — физический сервер с запущенным на нем гипервизором.
Ключевой особенностью является то, что любые действия виртуальных машин исполняются напрямую на уровне оборудования. При этом они друг от друга изолированы, что достаточно легко позволяет управлять ими по отдельности. Сам же гипервизор играет роль контролирующего органа, распределяя ресурсы, роли и приоритеты между ними. Также гипервизор занимается эмуляцией той части аппаратного обеспечения, которая необходима для корректной работы операционной системы.
Внедрение виртуализации дает возможность иметь в наличии несколько запущенных копий одного сервера. Критический сбой или ошибка, в процессе внесения изменений в такую копию, никак не повлияет на работу текущего сервиса или приложения. При этом также снимаются две основные проблемы – масштабирование и возможность держать «зоопарк» разных операционных систем на одном оборудовании. Это идеальная возможность совмещения самых разных сервисов без необходимости приобретения отдельного оборудования для каждого из них.
Виртуализация повышает отказоустойчивость сервисов и развернутых приложений. Даже если физический сервер вышел из строя и его необходимо заменить на другой, то вся виртуальная инфраструктура останется полностью работоспособной, при условии сохранности дисковых носителей. При этом физический сервер может быть вообще другого производителя. Это особенно актуально для компаний, которые используют серверы, производство которых прекращено и потребуется осуществить переход на другие модели.
Теперь перечислим самые популярные гипервизоры, существующие на текущий день:
- VMware ESXi
- Microsoft Hyper-V
- Open Virtualization Alliance KVM
- Oracle VM VirtualBox
KVM же напротив, полностью бесплатен и достаточно прост в работе, особенно в составе готового решения на базе Debian Linux под названием Proxmox Virtual Environment. Именно эту систему мы можем порекомендовать для первоначального знакомства с миром виртуальной инфраструктуры.
Обновить систему до актуальной версии
Для этого зайдем в консоль нашего сервера и отключим платный репозиторий (доступен только тем, кто купил платную поддержку). Если этого не сделать — apt сообщит об ошибке при обновлении источников пакетов.
-
Открываем консоль и редактируем конфигурационный файл apt:
Настроить автозапуск
По умолчанию Proxmox автоматически не запускает машины, но это легко решается буквально двумя щелчками мыши:
- Щелкаем по названию нужной машины.
- Выбираем вкладку Опции ➝ Запуск при загрузке.
- Ставим галочку напротив одноименной надписи.
Для продвинутых администраторов имеется еще и возможность указать дополнительные параметры запуска в разделе Start/Shutdown order. Можно явным образом указать в каком порядке следует запускать машины. Также можно указать время, которое должно пройти до старта следующей VM и время задержки выключения (если операционная система не успеет завершить работу, гипервизор принудительно ее выключит через определенное количество секунд).
Читайте также: