+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

ashift, volblocksize, clustersize, blocksize, Proxmox Виртуальная Среда

Dunuin

Guest

19.09.2020 21:05:00

Привет, я использовал эту конфигурацию... пул (ashift=12) -> zvol (volblocksize=8k, raw) -> ext4 (blocksize=512, без clustersize)... и у меня получилось, что усиление записи составляет около 10 от записей виртуального диска на госте до физических записей на хосте. Я провел исследование и нашел эту диаграмму, показывающую накладные расходы на четность/наполнение в процентах при использовании разного количества дисков в raidz1 и разных volblocksize. Диаграмма показывает, что использование raidz1 из 5 дисков (при ashift=12) и стандартного 8k volblocksize Proxmox (как в моей текущей конфигурации) вызывает накладные расходы более 100%. Так что в этом случае использование raidz1 не экономит место по сравнению с использованием zfs mirror. При volblocksize 32K накладные расходы минимальны для 5 дисков (при ashift=12), с накладными расходами всего 25%. Поэтому мне следует пересоздать zvols с volblocksize 32k вместо 8k. Я сделал это следующим образом: 1.) Proxmox GUI -> датацентр -> хранилище -> MyPool -> изменил "Размер блока" с "8k" на "32k" 2.) Это работает только для новосозданных zvols, поэтому я сделал резервную копию своей VM и добавил новый виртуальный жесткий диск того же размера 3.) Изменил порядок загрузки на CD сначала, примонтировал ISO-диск Debian Live CD и загрузил этот Live Debian 4.) Использовал "sudo lsblk", чтобы выяснить старый (sda) и новый (sdb) виртуальные жесткие диски 5.) Использовал "sudo dd conv=sparse if=/dev/sda of=/dev/sdb bs=32K status=progress", чтобы скопировать все содержимое (включая таблицы разделов, загрузчик и т.д.) со старого виртуального жесткого диска с blocksize 8k на новый виртуальный жесткий диск с blocksize 32k. 6.) Я отключил старый виртуальный жесткий диск от VM (поскольку UUID на обоих дисках теперь одинаковы) и установил порядок загрузки, чтобы сначала загружаться с нового виртуального жесткого диска. Похоже, все работает отлично, и если я использую "zfs list", новый zvol занимает только 1/3 от размера в "USED" и 1/2 от размера в "REFER". Также усиление записи, похоже, немного (на 10%) ниже. Нужно ли менять blocksize и/или clustersize разделов ext4 внутри VMs тоже? Или это не проблема, что VM записывает блоки по 512B, если zvol использует 32K, а физические жесткие диски 4K, потому что KVM делает магию виртуализации и как-то это конвертирует? Какой правильный blocksize/clustersize для виртуального ext4-раздела? Также диаграмма не упоминает использование встроенного шифрования или сжатия lz4, которое я оба использую. Следует ли использовать еще больший volblocksize, например, 64k вместо 32k, чтобы шифрование/сжатие работало лучше, или 32k тоже вполне нормально?

kwinz

Guest

24.07.2021 06:51:00

У меня была похожая проблема. Я писал об этом здесь: https://www.reddit.com/r/zfs/comments/opu43n/zvol_used_size_far_greater_than_volsize/. Я описывал это с точки зрения экспорта ZVOL с файловой системой NTFS через iSCSI с сервера Ubuntu. Но те же мысли применимы, если у вас есть том ext4 для гостевой VM в Proxmox. Надеюсь, это будет полезно! Также этот парень протестировал виртуальные машины с файловым бэкапом: https://www.reddit.com/r/zfs/comments/bz5ya2/zfs_kvm_ntfs_benchmarking_various_record_sizes/. Снова с NTFS, но те же выводы должны быть применимы. Но, хотя это основано на файлах, в то время как Proxmox хранит на ZVOL, я читал, что размер записи для наборов данных почти эквивалентен volblocksize ZVOL. Так что, возможно, это тоже будет вам полезно. В общем, значение по умолчанию 8k volblocksize довольно субоптимально для raidz и, вероятно, удивляет многих. Я читал здесь, что значение будет изменено с 8k на 16k в будущем: https://www.reddit.com/r/zfs/comments/opu43n/zvol_used_size_far_greater_than_volsize/h68208o/. Стоит подумать, может ли Proxmox изменить значение по умолчанию раньше или предоставить лучший интерфейс для этого? Мой текущий план - перенести мои виртуалки на 16k volblocksize (это 4 сектора по 4k с ashift=12) и мои iSCSI-шары, хранящие большие файлы, на volblocksize 128k (это 32 сектора по 4k с моим пулом ashift=12). У меня вопрос: как вы контролируете коэффициент записи?

Dunuin

Guest

24.07.2021 12:43:00

Вот почему я вижу как минимум одного человека каждую неделю, который начинает новую тему вроде "У меня слишком мало места" и не понимает, что просто создавая виртуальные машины без предварительной оптимизации volblocksize, они обычно теряют терабайты или десятки терабайт пространства для хранения. Особенно если используется какой-то raidz, где 8K всегда слишком мало, если не используется ashift=9. Что касается зеркала/полосатого зеркала, я не уверен, какой лучший volblocksize. Я полностью понимаю расчёты, связанные с raidz1/2/3, и как создаётся накладные расходы на уровне блоков (есть отличная статья на эту тему от главного инженера OpenZFS). Но я не смог найти информацию о том, как это работает с зеркалами или полосатыми зеркалами. Моё предположение таково: 4K является оптимальным, если использовать обычное зеркало с ashift=12. 4K ext4 в гостевой системе, 4K контроллер virtio SCSI (если изменить его с умолчания 512B), 4K volblocksize для zvol, 4K для пула и 4K для физических дисков звучит как оптимум, потому что размеры блоков совсем не смешиваются. Но в таком случае любая компрессия ZFS не должна работать, так как нет меньшей единицы, и компрессия была бы бесполезной. Меня больше интересует, что происходит, если использовать полосу из 2, 3 или 4 зеркал. В ZFS нет фиксированной ширины полосы, как в традиционном RAID.

DerDanilo

Guest

24.07.2021 18:54:00

У меня ровно те же вопросы по поводу (полосатых) зеркал в ZFS. 8k, похоже, работает нормально с недавним флеш-оборудованием и настройкой зеркала, но я не знаю, как это оптимизировать, потому что не смог найти полезные ссылки.

tunhube

Guest

26.02.2023 11:39:00

Есть ли причина, по которой Proxmox не может автоматически определить лучшие настройки, как это делают Ubuntu и другие ОС? Никогда не приходилось настраивать эти параметры на других системах ZFS. Видеть, как 4TB образ занимает 7TB+ — это действительно, действительно раздражает, особенно после того, как ты поработал с этим довольно долго и понял это слишком поздно. Я также вижу, что существует несколько сотен тем с той же проблемой, самую новую открыли в этом месяце. Так что еще раз, почему это не может быть исправлено или правильно определено PVE?

Dunuin

Guest

26.02.2023 12:02:00

Проблема в том, что это не так просто. Существует миллионы комбинаций, требующих других значений. Имейте в виду, что можно сделать, например, RAIDZ1 из 20 дисков с RAIDZ2 из 4 дисков и зеркалом на 4 диска. Сложно угадать, какой будет хороший volblocksize для такого пула. Но да, для простого зеркала, стертого зеркала, RAIDZ1/2/3, созданных через веб-интерфейс, было бы возможно установить какое-то подходящее значение volblocksize по умолчанию. Ashift снова представляет трудность, так как это зависит от используемых дисков, и все SSD обманывают нас по поводу того размера сектора, который они используют внутри. Вы не можете выбрать хороший ashift, если работаете с неправильными данными. А потом все зависит от вашей нагрузки. Давайте, к примеру, предположим, что у вас есть простой RAIDZ3 из 9 дисков с ashift=12. С использованием по умолчанию 8K volblocksize вы потеряете 75% емкости. Вам потребуется 128K volblocksize, чтобы потерять только 38% емкости. Но 128K будет абсолютно ужасным, если вы работаете с базами данных. Для PostgreSQL базы данных вы все равно захотите использовать 8K volblocksize, даже если это будет означать значительные потери емкости, так как в противном случае накладные расходы и производительность будут неприемлемыми.

chrcoluk

Guest

31.05.2023 19:51:00

Все мои тесты проводились на одной дисковой системе ZFS или на зеркалах. Увеличение volblocksize уменьшает метаданные и увеличивает сжатие, но также увеличивает потери при использовании небольших размеров файлов. Всего несколько дней назад я внес изменения на гостевой Windows-системе. При использовании 4k NTFS и 64k volblocksize не удавалось достичь скорости записи, как на физическом носителе, на SSD. Использование без учета снимков было следующим. Сжатие LZ4: 30.7G ссылается на 23.6G записанных. С coefficient сжатия 1.33x. После увеличения NTFS до 64k скорость записи заметно возросла: 38.5G ссылается на 21.7G записанных. С coefficient сжатия 1.76x. Не ожидал, что использование гостевой системы увеличится на целых 8 Гб, но экономия на метаданных и сжатии перевесила это, и фактически было записано меньше данных. Плюс теперь размеры гостевой и хостовой систем совпадают. Я обнаружил, что SSD DC P4600 быстрее всего работает на 16k bare metal (внутри имеет размер страницы 16k). Поэтому для этого я буду использовать как минимум 16k на NTFS и volblocksize. Думаю, причина, по которой NTFS потерял 8 Гб, в том, что это системный диск, а SxS создает тысячи маленьких ASCII-файлов. Но это также означает, что они хорошо сжимаются.

DerDanilo

Guest

24.07.2021 12:29:00

Так что если рекомендованный размер блока для конфигурации хранения с DC nvme в зеркальных настройках? ashift=12, volblocksize 4k, ext4 с тем, что по умолчанию в системах. Большинство пользователей не имеют времени или знаний, чтобы возиться с размером блока.

Dunuin Guest	#9 0 24.07.2021 10:13:00 Тем временем я создал около 9 пулов ZFS. Самый простой способ изменить volblocksize — это сделать резервные копии виртуальных машин, уничтожить их и импортировать обратно из резервных копий после установки нового volblocksize для этого пула (Центр обработки данных -> Хранилище -> ВашZFSХранилище -> Редактировать -> Размер блока). Таким образом, все zvol будут заново созданы из резервной копии с новым volblocksize. Существует 2 типа увеличения записи, которые вы можете измерить. Во-первых, это увеличение записи от гостя к хосту, вызванное виртуализацией дисков, смешанными размерами блоков и ZFS. Чтобы это измерить, я запускаю iostat 600 2 (из пакета "sysstat") на хосте и одновременно внутри гостя. Второй вывод этой команды через 10 минут (нужно просто набраться терпения для второго вывода, он может показаться пустым) покажет, сколько данных было записано на каждый диск за последние 10 минут. Внутри ВМ вы можете подвести итог всем данным, записанным на виртуальные диски этой ВМ. На хосте вы делаете то же самое и суммируете все данные, которые были записаны на диски, входящие в ваш пул. Теперь вы можете их сравнить. Если ВМ записала всего 1 ГБ на виртуальный диск внутри ВМ, но ZFS на хосте записал 10 ГБ на физические диски, то у вас увеличение записи в 10 раз. Чтобы это работало лучше всего, нужно остановить все другие ВМ и выполнить какие-то объемные записи внутри ВМ, которую вы измеряете (например, создайте файл на 20 ГБ с случайными числами, так чтобы ZFS не смог их хорошо сжать: dd if=/dev/urandom of=/var/tmp/writetest.txt bs=20G count=1). Более сложной частью является увеличение записи внутри ваших SSD. Из-за того, как работают SSD, они всегда создают увеличение записи. Особенно если у них нет защиты от потери питания, потому что без нее они не могут кэшировать синхронные записи и должны записывать данные по мере поступления без каких-либо оптимизаций записи, которые могли бы уменьшить износ. Это происходит в прошивке SDD, поэтому единственный способ увидеть, что происходит, — это проверить статистику SMART. Мои SSD Intel S3710, например, имеют эти 2 статистики SMART (smartctl -a /dev/sdX для проверки статистики SMART): Код: ID# НАЗВАНИЕ_АТРИБУТА ФЛАГ ЗНАЧЕНИЕ ХУЖШЕ МИНИМУМ ТИП ОБНОВЛЕНО ПРИ_НЕУДАЧЕ СЫРОЕ_ЗНАЧЕНИЕ 241 Записи_Хоста_32МиБ 0x0032 100 100 000 Старый_возраст Всегда - 1371216 243 Записи_NAND_32МиБ 0x0032 100 100 000 Старый_возраст Всегда - 2735478 "Записи_Хоста_32МиБ = 1371216" — это количество данных, которые хост отправил (за весь срок службы) на SSD для записи. Это считается в единицах 32МиБ, так что в сумме это 32МиБ * 1371216 = 43878912 МиБ = 41.84 ТиБ. Для "Записи_NAND_32МиБ = 2735478" аналогично, но это подсчитывает, сколько данных было записано на фактические NAND-флеш-чипы SSD. Таким образом, 32МиБ * 2735478 = 87535296 МиБ = 83.48 ТиБ записано на NAND-флеш. Если вы сравните 42 ТиБ данных, которые должны быть записаны, и 83 ТиБ данных, которые фактически были записаны, вы увидите, что есть увеличение записи примерно в 2 раза за весь срок службы SSD. Если вам нужны более свежие значения, вы можете записывать значения Записей_Хоста_32МиБ и Записей_NAND_32МиБ и повторить это через неделю. Вычтите первое измерение из второго, и вы узнаете, сколько данных было записано за неделю. Здесь я вижу увеличение записи примерно в 3 раза. Но SMART не стандартизирован, так что вам нужно повезти, чтобы производитель вашего SSD реализовал какой-то атрибут SMART, подобный "Записям_NAND_32МиБ". Например, мои другие SSD Intel S3700 имеют только Записи_Хоста_32МиБ, но не имеют Записей_NAND_32МиБ, поэтому нет возможности увидеть, насколько велико их увеличение записи. А увеличение записи всегда умножается. Так что если есть увеличение записи в 10 раз от гостя к хосту и в 3 раза от хоста к NAND SSD, это 10 * 3, а не 10+3. Таким образом, общее увеличение записи составит 30, и каждые 1 ГБ данных, записанных внутри ВМ, приведут к записи 30 ГБ данных на NAND-флеш SSD.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры