Авторские статьи

Оптимизация гостевых операционных систем KVM.


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

Чтобы не терять времени, хостовая часть Proxmox VE и виртуальные, гостевые операционные системы KVM были оптимизированы. Но прошло не много времени и шаловливые ручки хотели ещё что-нибудь подкрутить.

Невращабельный диск.

На просторах Интернета многие гуру советуют выставлять планировщик I/O noop в линуксовых, гостевых KVM системах. NOOP не занимается вообще никакими оптимизациями при операциях чтения, записи. Так как жёсткий диск у гостевых, виртуальных серверов это файл в хостовой Proxmox VE системе, то самому Proxmox VE виднее и лучше знать что и как записывать на реальный жёсткий диск.

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

rotational
SSD (и виртуальные) диски не используют вращающиеся пластины в отличие от традиционных жестких дисков. Нулевое значение отключает использование алгоритмов снижения времени поиска данных, так как SSD (и виртуальные) диски в этом не нуждаются.

rq_affinity
Значение 1 принуждает обработку операций на том же процессоре, где они были сгенерированы. Это может повысить эффективность кэширования данных. Значение 0 разрешает обработку операций на любом процессоре.

В /etc/rc.local всех виртуальных гостей были прописаны до exit 0 строки:
echo 0 > /sys/block/vda/queue/rotational
echo 0 > /sys/block/vda/queue/rq_affinity

Где vda - это жёсткий диск при использовании VirtIO в гостевой системе. Без использования VirtIO виртуальный жёсткий диск, скорее всего, будет называться sda.

Обнуление незанятого пространства.

Некоторые гуру напоминают, что во время работы виртуального сервера будут создаваться и удаляться файлы. Занятое место не будет после удаления файлов автоматически заполняться нулями и ваше резервное копирование виртуальных машин будет показывать постепенное увеличение размера архивных файлов. То есть если у вашей виртуальной машины виртуальный диск на 100 Гб, то резервная копия НЕ будет такого размера, размер будет приблизительно равен занятому месту плюс-минус как хорошо всё это сожмётся. Другими словами, размер резервной копии ~= ( размер виртуального диска - размер свободного места заполненного нулями ) - на сколько всё это можно сжать.

Есть такая утилита sfill из пакета secure-delete, чья задача безопасно очистить место, чтобы вероятный злоумышленник не восстановил данные с диска. Sfill делает несколько раундов перезаписи для надёжного стирания данных.

Можно поручить sfill сделать нужную работу, но без лишней нагрузки. Нам нужно обнулённое свободное дисковое пространство, а не затёртое случайными данными в несколько раундов за много-много часов.

Sfill понимает указание цели в виде папка или устройство.

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

sudo sfill -v -f -l -z /var/

  • -v - выводить ход работы.
  • -f - быстрый режим без использования /dev/urandom и без режима синхронизации.
  • -l - уменьшение безопасности, за счёт перехода на 2 прохода. Первый проход пишет 0xff и второй проход пишет случайные данные.
  • -z - заставляет последний проход делать не случайными данными, а нулями.

И так мы ускорили процедуру с помощью ключа -f, -l сделает два прохода проход и -z заставит делать 0 в последнем раунде. Многие советуют удвоить ключ -l и сделать один раунд, но мои опыты показывают, что очистка не происходит. Более подробно об данной проблеме в статье Не работает в Linux chattr.

Нужно обязательно протестировать и убедиться, что утилита sfill отрабатывает так как нужно.

Создаём тестовый файл.
for i in {10001..10200}; do echo "$i test line" >> testfile.txt; done

Получаем информацию о файле, точнее о стартовом LBA адресе (begin_LBA).
sync && sudo hdparm --fibmap testfile.txt

Вы должны получить что-то типа (это пример).

testfile.txt:
 filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    4469976    4469983          8

Запомните значение begin_LBA.

Удалите файл testfile.txt и сбросьте буфера sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

Чистим свободное место с помощью sfill.
sudo sfill -v -f -l -z /var/

Сбросьте буфера sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

Читаем данные со стартового LBA адреса файла, замените [begin_LBA] на свой из вывода hdparm --fibmap и /dev/vda на своё устройство:
sync && sudo hdparm --read-sector [begin_LBA] /dev/vda

Если у вас LVM или RAID и hdparm --read-sector вызывает ошибку reading sector [begin_LBA]: FAILED: Inappropriate ioctl for device, то попробуйте прочесть другим способом:
dd if=/dev/vda of=~/sec1 bs=512 skip=[begin_LBA] count=32

До удаления файла testfile.txt, мы записывали в него фразу test line. При чтении hdparm --read-sector вы должны видеть нули, а не отличные от нуля значения. При чтении dd в файле ~/sec1 не должны быть видны слова test line.

Мои эксперименты над тестовой, виртуальной машиной показали, что внутри гостя после смены ядер с generic на virtual произошли массовые изменения файловой системе и очистка с помощью sfill позволила резервному копированию через веб-интерфейс Proxmox VE сжимать лучше.

-rw-r--r-- 1 root root 679M Jul 26 08:55 vzdump-qemu-105-2013_07_26-08_54_09.vma.lzo
-rw-r--r-- 1 root root 402M Jul 26 10:25 vzdump-qemu-105-2013_07_26-10_23_48.vma.lzo

Вместо 679 Мб архив данной тестовой машины стал занимать 402 Мб и разница составила 270 Мб. Реальные виртуальные машины, используемые в производстве, могут показать другие результаты.

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

Дополнительные материалы:
Proxmox VE. Начало пути.
Оптимизация виртуальных серверов KVM.
Ускорение Убунту.
Монтирование VirtualBox образов vdi в Ubuntu.

Дата последней правки: 2023-11-11 11:18:51

RSS vasilisc.com   


Разделы

Главная
Новости
Ворох бумаг
Видео Linux
Игры в Linux
Безопасность
Статьи об Astra Linux
Статьи о FreeBSD
Статьи об Ubuntu
Статьи о Snappy
Статьи об Ubuntu Phone
Статьи о Kubuntu
Статьи о Xubuntu
Статьи о Lubuntu
Статьи об Open Source
Карта сайта