Размер раздела метадата для LVM-thin

Ты слаб умом?

Thin pool volume with chunk size 64.00 KiB can address at most 15.81 TiB of data.

В одном предложении есть два числа и явная связь между ними.

Под метаданные можно было и 4Гб, но здесь что 4Г, что 16Г – это мелочь для 3ТБ диска

Чего столько агрессии?

Вопрос-то был не в связи между чанком и пределом хранилища, а в том, что делать, когда он будет достигнут?

По моему, в lvm размер чанка не меняется, так что кроме как импорт-экспорт или пересоздания lvm с переносом данных через dd предложить то и нечего.

Что делать? Не ждать будущего, когда система обрастет мясом, действовать сейчас – переделать все.

Вообще не факт.

В принципе, если вероятность события превышения туманна, то можно и оставить. Во первых, четыре диска и ни одного рейда, это глупо само по себе. Если же появятся диски, то проще будет уже из них организовать рейд, создать новый lvm и скопировать данные.

Ты слаб умом? Зачем ты сам себе противоречишь?

Да в чем? Нельзя все сразу сделать на века. Это идиотизм. Есть короткая, средняя и длинная дистанции. Все, кто сразу ориентируются на длинную, дохнут уже на короткой…

Переделать - как? Увеличить chunk size?

Но я не знаю, что получится в итоге… Это пока стартап. Может быть надо будет увеличить хранилище до 10 Тб, а может - в благоприятном случае - до 50 Тб.

Вы с zfs сравнивали?

Он кушает больше памяти (есть тюнинг), тормознее, но лучше масштабируется и более предсказуем.

Не знаешь – плыви по течению. Встретишь водоворот, может выгребешь. А может и не встретишь. А может и не выгребешь.

)))

да, как вариант рассматриваю zfs… у меня на сервере Proxmox, там zfs вподе работает «из коробки».

С одной стороны, складывается впечатление, что том zfs можно организовать на proxmox в 3 клика мышкой (всё в GUI).

С другой стороны -

1. пользователи пишут о «подводных камнях», сложности администрирования и т.п. Я в linux новичёк, пока с lvm до конца не разобрался)))

2. я нормальной работы zfs нужно много памяти (тем более, что в итоге хранилище может значительно расшириться). У меня сейчас на сервере 16Гб ОЗУ, как я понимаю - это вообще самый минимум для zfs

Не лезь в ZFS.

Переделай lvm увеличь chunk и забудь об ограничении размера. Я как-то нарвался на старом РедХате на ограничение 16Тб для ext4, пришлось мигрировать на xfs, а это не только время, но и еще доп. «диск» на 16ТБ нужен был

А зачем Вам thin pool? В смысле, зачем thin pool такого размера?

Если Вы планируете много виртуалок, использующих thin provisioning (и утилизирующих 15+ Тб), то 16 Гб RAM будет явно мало.

Если виртуалок мало, то зачем столько места именно в thin pool’e? Если Вы планируете на thin pool’e хранить обычные данные — то это плохая идея (возьмите обычный, не ‘thin’ lvm и используйте его).

Или есть какие-то специфические функциональные требования?

Для понимания, thin pool хорош, когда Вам нужно создавать много доступных на запись копий крупных объектов (системный диск VM, например). Если, например, у Вас есть студенты в компьютерном классе, которые должны выполнять лабораторные работы - то thin pool отлично подходит: Вы делаете несколько шаблонов VM (по одному для каждой лабораторной работы), когда приходят студенты - запускаете им 10-20 VM. Для каждой VM используется один набор данных, к которому, пока VM работает, пишется дельта. Когда потребность в VM отпадает (студент показал результат) - Вы удаляете VM вместе с накопившейся дельтой.

А если Вы хотите, например, запускать там сервер AD + файловый сервер + сервер СУБД + сервер приложений (1С, например) + терминальный сервер и т.п. - то thin provisioning для этого подходит плохо.

я нормальной работы zfs нужно много памяти (тем более, что в итоге хранилище может значительно расшириться). У меня сейчас на сервере 16Гб ОЗУ, как я понимаю - это вообще самый минимум для zfs

Если что, вот обсуждение этого вопроса: https://www.reddit.com/r/homelab/comments/7x8ijh/zfs_on_proxmox_ram_requirements/

Если лень читать: использовать zfs на 16 Гб можно (по умолчанию, zfs берёт под кэш 50% ОЗУ; можно ограничить меньшим объемом). От объема ОЗУ, выделенного под кэш, зависит быстродействие.

Не лезь в ZFS.

Автору топика: я не знаю всех вводных (что у Вас за данные, насколько Вам важны данные, в каком режиме они будут использоваться и т.д.), поэтому мое мнение субъективно. Для хранения важных данных - ZFS имеет плюсы: чексуммы, прозрачную компрессию, возможность делать снимки и отправлять их в удалённое хранилище (zfs) для резервного копирования и синхронизации.

В эксплуатации ZFS есть свои нюансы (нужно управлять памятью, чтобы не получать OOM, не следует использовать дедупликацию, на очень быстрых ssd/nvme, латентность выше, чем у LVM и т.д.), но для больших хранилищ, польза от ZFS значительная.

правильно ли я понимаю

• если при chunk size 64.00 KiB максимаьно млжет быть том 16 Тб, то, чтобы в последствии иметь возможность расширить том до 48Тб, надо изначально создать том с chunk size 192 Кб?

ситуация у меня следующая:

1. задача проекта - организовать большой сток видкоконтента (уточняю на всякий случай - 6+). есть уже готовый скрипт, который работает на apache Общий объём контента пока не понятен, но может быть (по оценкам) - ориентировочно до 50Гб.

2. реализуем прокт на свои деньги, поэтому на старте пока купили железа по минимуму: на сервере 16 ГБ ОЗУ, 128 Гб NVMe, 3 Тб hdd (хранилище пока без зеркал и т.п.)

3. для гибкости мы инсталировали на сервер гипервизор proxmox. frontend/backend проекта - ВМ на proxmox

4. задача, которую я обсуждаю в этой теме - понять как лучше организовать расширяемое хранилище для контента.

Расширение хранилища я вижу следующим образом а) сейчас есть диск 3Тб - организуем хранилище на нём б) появится возможность докупить ещё диск 3Тб - организуем зеркало в) если проект будет развиваться - докупить ещё диски и увеличить объем хранилища г) в дальнейшем, по мере роста объема контента - докупать диски и ещё увеличивать объём хранилища. д) преобразоваит RAID1 в RAID5 или 6 или т.п.

6. в proxmox есть несколько вариаетов подключения диска а) директория б) LVM в) LVM-thin г) ZFS

LVM-thin был выбран из-за возможности делать снапшоты ВМ встроенными средствами.

на обычном LVM снимки делать нельзя(

the proxmox installer by default create Chunk 256,00k in version 5.X, and 64,00k in version 6.X
you can change the Chunk size with the -c option.

for example: Code:

lvconvert --type thin-pool -c 256K pve/data

А как мне вычислить правильный Chunk для моей ситуации?

как лучше организовать расширяемое хранилище для контента.

На текущей стадии проекта, я бы разделял хранилище на 2 части:

• данные размещать на ZFS.
• виртуалки размещать на чём хотите (lvm/lvm thin/zfs), учитывая особенности каждого хранилища:
  • lvm (обычный):
    • + быстро работает
    • + предсказуем
    • - снепшоты «дорогие» и подходят только как источник для бэкапов
  • lvm thin:
    • + есть thin provisioning
    • + работает, в целом, быстрее ZFS
    • - нужно уметь с ней обращаться, иначе I/O может встать колом
  • zfs:
    • - из коробки работает медленнее, чем lvm thin
    • + неплохо тюнится (можно подключить кеширование чтение/записи на SSD, перенос мелких файлов на SSD и т.д.)
    • + имеет кучу полнезных функций (обратите внимание на чексуммы и send-receive)

Потом (когда выйдите из стадии «proof of concept») смотреть на облака (IaaS/PaaS) или на решения типа ceph для хранения данных.

на обычном LVM снимки делать нельзя(

А Вам точно снимки VM нужны (а, например, не бэкапы VM)? Proxmox backup server отлично делает инкрементальные бэкапы VM (бэкапит только дельту).

Самое важное забыл: в виртуалку файлы с хранилища пробрасывайте через NFS/p9fs. То есть, не храните на виртуалке с апачем сами данные (видео).

До Proxmox backup server ещё руки не дошли. Поэтому пока думал снимки использовать

Сейчас диск для хранения контента передаётся ВМ, где запущен Apache, просто как виртуальный диск.

Вернее в эту ВМ передаётся два диска:

scsi0   local-lvm:vm-100-disk-0,size=32G
scsi1   vmdata:vm-100-disk-0,size=1T

При этом, local-lvm - это пул типа LVM-thin, который Proxmox создал при установке по умолчанию на системном диске (он NVMe типа) для хранения образов виртуальных машин.

А vmdata - это тоже пул типа LVM-thin, но его уже я создал сам на HDD диске 3Тб (хранилище для контента, которое впоследствии должно расширяться).

При этом на scsi0 (sda) внутри ВМ находтся вся ОС и Apache, а scsi1 (sdb) - внутри ВМ просто смонтирован как директория, предназначенная для хранения видеоконтента.

Скрипт, запущенный на Apache, перемещает загруженный пользователем контент из временной директории сайта на диск хранилища (sdb1).

@:~$ sudo lsblk
NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0                       7:0    0 55.4M  1 loop /snap/core18/2128
loop1                       7:1    0 55.5M  1 loop /snap/core18/2284
loop2                       7:2    0 70.3M  1 loop /snap/lxd/21029
loop3                       7:3    0 67.2M  1 loop /snap/lxd/21835
loop4                       7:4    0 32.3M  1 loop /snap/snapd/12704
loop5                       7:5    0 61.9M  1 loop /snap/core20/1270
loop6                       7:6    0 43.3M  1 loop /snap/snapd/14295
sda                         8:0    0   32G  0 disk
├─sda1                      8:1    0    1M  0 part
├─sda2                      8:2    0    1G  0 part /boot
└─sda3                      8:3    0   31G  0 part
  └─ubuntu--vg-ubuntu--lv 253:0    0 15.5G  0 lvm  /
sdb                         8:16   0    1T  0 disk
└─sdb1                      8:17   0 1024G  0 part /var/www/mydomen.ru/data/www/storage
sr0                        11:0    1  1.2G  0 rom

Как я написал в предыдущем посте, сейчас образ хранилища хранится как виртуальный диск, но на отдельном от всех других виртуалок диске (образ виртуального диска с системой и программами виртуальной машины хранится на другом диске).

виртуалку файлы с хранилища пробрасывайте через NFS/p9fs. То есть, не храните на виртуалке с апачем сами данные (видео).

1. А в чём преимущество этого варианта? Сейчас данные перемещаются путём копирования с одного диска на другой диск внутри одного физического сервера.

А так они будут гоняться через сетевой адаптер - скорость перемещения файлов в этом случае вероятно будет гораздо ниже.

2. Как лучше реализовать этот вариант? Запустить ещё одну ВМ, а на ней что-то вроде NAS?

А vmdata - это тоже пул типа LVM-thin

А данные вы снепшотить будете? Для чего именно?

Делать снепшоты данных - это нормально, просто я хочу понять, как именно Вы их предполагаете использовать.

Сейчас диск для хранения контента передаётся ВМ, где запущен Apache, просто как виртуальный диск.

Я тоже так делаю, цепочка ZFS Volume -> VM -> XFS -> SMB работала быстрее, чем ZFS FS -> SMB. Это было на proxmox 4.4, в более новых версиях ZFS FS может уже лучше работать (не проверял).

Если что, zfs в этом «бутерброде» обеспечивал raid/snapshots/send-receive.

А в чём преимущество этого варианта?

В том, что когда у Вас будет не одна VM с апачем, а несколько, то все они смогут использовать эти данные. Если сделать такую схему сразу, то будет проще мигрировать.

А так они будут гоняться через сетевой адаптер - скорость перемещения файлов в этом случае вероятно будет гораздо ниже.

У Вас скорость сети внутри сервера (между VM, между vm и хостом) должна быть 10 Гбит (на virtio адаптерах). Вам хватит.

Как лучше реализовать этот вариант? Запустить ещё одну ВМ, а на ней что-то вроде NAS?

На хосте поднять NFS-server, на VM - клиента NFS. Или на на p9fs посмотреть.

Хотя, наверное, для старта Вам лучше использовать имеющуюся схему:

Сейчас диск для хранения контента передаётся ВМ, где запущен Apache, просто как виртуальный диск.

А уже потом заниматься масштабированием.

Только с lvm thin будьте аккуратнее.

А данные вы снепшотить будете? Для чего именно?

для бэкапа

Только с lvm thin будьте аккуратнее.

Т.е. вместо LVM рекомендуете диск хранилища перевести в ZFS?

На хосте поднять NFS-server, на VM - клиента NFS.

А диск хранилища на хосте при этом использовать как ZFS пул?

Или на на p9fs посмотреть.

это вообще не понятно, где смотреть. Кейсов на эту тему в рускоязычном Интернете я не нашёл

Harliff, я пошёл по этому пути:

На текущей стадии проекта, я бы разделял хранилище на 2 части:

-данные размещать на ZFS.

-виртуалки размещать на чём хотите (lvm/lvm thin/zfs),

У меня был HDD 3Tb, я сделал на нём ZFS-пул, и использовал его для хранения медиа-данных.

Сейчас появилась возможность получить для этого проекта 6Тб диск. Но для расширения существующего ZFS-пула, как я понимаю, он не годиться?

Что посоветуете - как имея два диска: один 3 ТБ, другой 6 Тб, организовать единое пространство для хранения файлов на 9 Тб?

Похоже надо переходить на LVM?

Здравствуйте!

У меня был HDD 3Tb, я сделал на нём ZFS-пул, и использовал его для хранения медиа-данных.

Отлично!

Сейчас появилась возможность получить для этого проекта 6Тб диск. Но для расширения существующего ZFS-пула, как я понимаю, он не годиться?

Годится!

Технически это делается так (привожу пример с файлами вместо дисков):

# fallocate /tmp/test1.img -l 300M
# zpool create testpool /tmp/test1.img
# zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
testpool   288M   132K   288M        -         -     0%     0%  1.00x    ONLINE  -

# zpool status
  pool: testpool
 state: ONLINE
config:

        NAME              STATE     READ WRITE CKSUM
        testpool          ONLINE       0     0     0
          /tmp/test1.img  ONLINE       0     0     0

errors: No known data errors

# fallocate /tmp/test2.img -l 600M
# zpool add testpool /tmp/test2.img
# zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
testpool   864M   178K   864M        -         -     0%     0%  1.00x    ONLINE  -

# zpool status
  pool: testpool
 state: ONLINE
config:

        NAME              STATE     READ WRITE CKSUM
        testpool          ONLINE       0     0     0
          /tmp/test1.img  ONLINE       0     0     0
          /tmp/test2.img  ONLINE       0     0     0

errors: No known data errors

fallocate здесь использован для создания временных файлов. У Вас это будут не временные файлы, а физические устройства (типа /dev/sdb) или разделы на них (типа /dev/sdb1).

Что посоветуете - как имея два диска: один 3 ТБ, другой 6 Тб, организовать единое пространство для хранения файлов на 9 Тб?

Как технически использовать 2 диска под один пул - см пример выше.

Так же я рекомендую подумать про два момента:

• избыточность при хранении (размещать данные на зеркальных дисках, то есть, вместо схемы 3*1+6*1 (=9Тб, без устойчивости к сбоям) использовать схему 3*2+6*2 (=9Тб с устойчивостью к сбоям).
• резервное копирование данных