По ряду причин мы с коллегой ещё не перешли на виртуализированные сервера. В целом всё готово, но нужно желание и смелость перейти со старой модели, где на каждую задачу свой физический сервер, на новую схему в виде маленького кластера, с крутящимися в нём виртуальными серверами.
Чтобы не терять времени, хостовая часть 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.
Немає коментарів:
Дописати коментар