- PVSM.RU - https://www.pvsm.ru -
Символика эта и так на слуху, потому нет смысла подробно объяснять, что это [1] за зверь [2].
Здесь не будет сравнения [3] с LVM [4], ибо сравнивать muscle-car с jet-truck'ом хоть и можно, но бессмысленно.
Графиков и комиксов так же не завезли.
Это, скажем так, незавершенная история успеха, потому что апгрейд, которым она была вызвана, можно лишь прекратить, но не завершить.
Практически в каждой айтишной семье присутствует несколько ПК и/или ноутбуков, наверняка имеется перероутер-HTPC, а то и вовсе какой-нибудь NAS. Вот и у нас было два ПК, потом добавился большой настенный монитор, а при таком раскладе рождение HTPC — вопрос времени. Когда он появился на свет, тут же был наречен гордым именем — Сервер. Позже выяснилось, что чаcть любимых игр умеет в Linux — и Сервер тут же обзавелся аккаунтом Steam.
Так прошло несколько лет, в течение которых Сервер получил 16ГБ памяти, на нем появились виртуалки с gitlab и проектами...
А потом пришло понимание, что назревает апгрейд, и апгрейдить сразу 3 ПК слишком накладно; в то же время, уже был успешный опыт с PCIE-passthrough и игровой виртуалкой.
Подходящим решением стала поэтапная миграция игровых машин в виртуалки. Пока смигрирована только одна, в дальнейшем под гостем я буду подразумевать именно её.
Из трех процессоров (i3-3220, i5-3470, i5- 3470K) VT-d поддерживал только второй, он и ушел в Сервер вместо i3. Была куплена низкопрофильная 1050Ti на замену 7970, а старое железо продано по частям.
Сервер получил последнюю UEFI-прошивку, Ubuntu 16.04 и самый большой из имевшихся SSD — Crucial M4, на 256 ГБ, под корневой пул. Установка проводилась по этому манулу [5], из которого был накопипащен в live-системе установочный скрипт. Потом, уже после успешной загрузки, были доустановлены virt-manager
, libvirt-bin
, ovmf
и xubuntu-desktop
. Разумеется, были включены VT-x и VT-d.
Кстати, отделение бинарной части системы от логов, кешей и прочих хомяков не раз помогало в процессе вивисекции системы экспериментов, позволяя вернуть рабочее состояние простым zfs rollback
, доступным даже из initrd (но есть особенность: если вы используете отдельный датасет для /root
— используйте параметр ядра init=/bin/sh
для аварийной загрузки; sh, в отличие от bash, не будет создавать мусор в точке монтирования /root
).
Чтобы в случае проблем с загрузкой не гадать, что же случилось, в /etc/default/grub
закомментируйте все, что касается HIDDEN_TIMEOUT
, установите явно таймаут отличный от 0 (у меня 10), раскомментируйте/добавьте GRUB_TERMINAL=console
и обязательно уберите quiet splash
из GRUB_CMDLINE
.
vfio-pci.ids=10de:1c82,10de:0fb9,8086:1e31
(у меня проброшены сама видеокарта, ее звук и четырехпортовый USB3-контроллер) и разрешить использование iommu intel_iommu=on
(на AMD прописываются другие параметры, но за неимением врать не буду). Также для проброса видеокарты понадобится явно запретить ее использование видеодрайвером, так как пробрасывалась nvidia и проприетарный драйвер установлен не был, то у меня это выглядит так: modprobe.blacklist=nouveau nouveau.modeset=0
. Все эти параметры прописываются в файле /etc/default/grub
, в строке GRUB_CMDLINE
. Не забудьте выполнить update-grub
и перезапуститься перед добавлением подготовленных к пробросу устройств в гостя.cpu=host
хоть и полезен, но не помог. К счастью, оказалось достаточно воспользоваться virsh edit <guestname>
, и в секции <features>/<hyperv>
добавить строчку <vendor_id state='on' value='ASUS'/>
. Но в свою очередь, libvirt из репозитория (включая backports) слишком протух и не понимал этого параметра. После нескольких неудачных попыток собрать и установить более свежую версию, я обратился к ppa, и у Jacob Zimmermann [6] нашелся подходящий пакет. Рекомендую, найдя стабильную версию, не обновлять драйвера на видеркарту в госте, ввиду постоянной мутации бизнес-бага с пробросом.zfs create rpool/lxc
), запускаем lxc init
, выбираем тип хранилища ZFS, отказываемся от создания пула, соглашаемся на использование датасета, вводим имя созданого чуть ранее датасета. Сейчас там живут gitlab, samba-dc (с ключем --usentvfs, на самбе старше 4.3 не заведется), пара мелких проектов.-s
при создании), то снимок будет занимать столько же места, сколько и оригинал.
При использовании ZFS есть два способа сэкономить место на диске — это сжатие и дедупликация. И если со сжатием все понятно, то дедупликацию стоит разобрать поподробнее.
Накладные расходы на дедупликацию составляют от ~200 до ~700 байт в памяти на реальных системах (подробнее можно посмотреть в выводе zdb -D <poolname>
), а DDT (таблица дедупликации), размер которой зависит напрямую от количества уникальных блоков, должна храниться в памяти целиком; и это значит, что использовать дедупликацию с маленьким размером блока попросту невыгодно (кроме, разве что, фермы виртуалок с dedup_ratio намного большим единицы и титаническим количеством оперативной памяти). Кроме того, с маленьким размером блока (это касается в первую очередь zvol) невозможно использовать сжатие, отличное от zle.
Стоит ли говорить, что размер блока zvol должен совпадать с размером кластера расположенной на нем ФС, а сама она должна быть выровнена по размеру блока (современные утилиты давно выранивают по границе 1МБ, чего более чем достаточно)?
Получается, использование больших блоков благоприятно сказывается на сжатии, дедупликации и накладных расходах по памяти, при этом сжатие еще и позволяет минимизировать оверхэд от больших блоков в ФС гостя.
Так что, все zvol я создаю командой zfs create -V <size> -s -b 64K <zfs path>
, добавляя -o dedup=on
и -o compression=lz4
по необходимости.
В случае с NTFS все хитрее и проще одновременно: Windows создает служебные разделы, содержимое которых меняется крайне редко, поэтому на размер их кластера можно не обращать внимания (а у загрузочного раздела еще и не удастся поменять — ни bootmgr ни ntldr не понимают размер кластера больше 4КБ). Если после выбора нераспределенного места нажать не кнопку "Установить", а "Создать", то установщик создаст и отформатирует все нужные разделы, а у вас появится номер диска и номер раздела, в который будет установлена гостевая система.
Далее понадобится немного черной магии:
cmd
(нажимаем Shift-F10
)diskpart
, и далее в немselect disk <номер диска>
select partition <номер раздела>
format FS=NTFS UNIT=64K QUICK
assign LETTER=S
mkdir s:windows
.Возвращаемся к мастеру установки, обновляем конфигурацию дисков, выбираем самый большой раздел из созданых (с которым совершалась магия) и продолжаем установку как обычно.
Ну, системный диск отформатирован с размером кластера 64КБ, и Windows внушено, что на диске уже есть ее инсталляция, поэтому форматировать его с настройками по умолчанию - не нужно. Грязный хак? Ну да, так в этом же суть построения Windows-систем: заставить ее делать то, что нужно, а не то, что ей хочется.
Самый простой способ был завести smb или nfs шары и создать на них библиотеки Steam. Обычные файлы легко и естественно дедуплицируются, включая как экспортированные библиотеки, так и библиотеку Linux-клиента, без лишних телодвижений. Как и всегда, самое очевидное решение оказалось в принципе рабочим, но неправильным. SMB в таком режиме шевелится со скоростью ноутбучного жесткого диска, несмотря на то, что файлы лежат на SSD. NFS (а Windows 8.1 поддерживает NFS v3, не 4) шевелился чуть шустрее, по ощущениям как какой-нибудь "зеленый" десктопный диск, но этого все равно было слишком мало для комфортной игры. К тому же, все ОС от M$ обожают терять сетевые диски, автоматически подключаемые при логоне, и каждый раз указывать Steam на местоположение библиотеки быстро надоест.
Подходящим решением стало iSCSI. На Сервер был установлен targetcli
, настроен по этому манулу [9] с поправкой на использование blockio и путем вида /dev/zvols/<zfs path>
. Для правильной работы unmap нужно использовать Windows 8+ (начиная с 8 реализована поддержка unmap для iSCSI-инициатора), а для каждого блочного устройства прописать set attributes emulate_3pc=1,emulate_tpu=1,emulate_caw=1,emulate_tpws=1,emulate_tas=1
. Если все сделано правильно, то и удаление файлов и форматирование должно освобождать место и сокращать размер zvol.
Теперь одинаковые файлы в экспортируемых под библиотеки томах занимают место лишь однажды, однако библиотека Steam для Linux все равно занимает отдельное место. Создадим отдельный датасет под эту библиотеку с опциями -o dedup=on -o recordsize=64K
. Если разделы в zvol выровнены по границе 1МБ, и размер кластера установлен в 64КБ, то логично, что делить файлы на хосте надо с той же гранулярностью, чтобы дедупликация могла найти одинаковые блоки.
zfs set logbias=throughput <pool>
значительно влияет на производительность, особенно при использовании дедупликации. Мало того, что при этом исключается дополнительный цикл запись-в-лог/стирание-лога, так еще и перестает вымываться кеш записи накопителя.Что ж, мой маленький эксперимент завершился несомненным успехом, хотя на пути возникли трудности. Далее хотелось бы апгрейд на Zen2, 32-64ГБ памяти, NVME SSD, перенос второго ПК на Сервер… но это уже будет совсем иное колдунство.
Автор: khajiit
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/ubuntu-2/265022
Ссылки в тексте:
[1] что это: http://xgu.ru/wiki/ZFS
[2] за зверь: https://ru.wikipedia.org/wiki/ZFS
[3] сравнения: http://xgu.ru/wiki/ZFSvsLVM
[4] LVM: http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html?limitstart=0
[5] этому манулу: https://github.com/zfsonlinux/zfs/wiki/Ubuntu%2016.04%20Root%20on%20ZFS
[6] Jacob Zimmermann: https://launchpad.net/~jacob/+archive/ubuntu/virtualisation?field.series_filter=xenial
[7] манипулируя: https://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/
[8] параметрами: https://gryzli.info/2015/02/26/calculating-filesystem-stride_size-and-stripe_width-for-best-performance-under-raid/
[9] этому манулу: https://www.server-world.info/en/note?os=Ubuntu_16.04&p=iscsi
[10] Источник: https://habrahabr.ru/post/339456/
Нажмите здесь для печати.