Comments 40
Хотя внешний-то можно — например, подключить USB HDD/SSD, или хранилище какое по iSCSI или NFS.
Второй момент — я и в первой статье не увидел, в чем была причина и необходимость перехода с ESXi на Proxmox/Debian?
Не представляю как диск с метаданными расширить на сетевом хранилище… во-первых, lvm нужны физические диски, а во-вторых, при потере связи метаданные повредили бы и сами диски с виртуалками.
Переход был вызван тем, что Esxi не видит программный raid. А на дебиан был поднят и soft-raid и lvm
lvm, насколько я знаю, прекрасно прожует и подключенные по iscsi диски (сам пробовал только ради экспериментов, не в продакшне под нагрузкой, разумеется).
по аппаратному — да, можно купить. но 12-14к — это треть стоимости этого сервера. уже не рентабельно.
Прекрасно на прод кластера у меня 5 лет работало. Один из рекомендованных проксмоксом вариантов. LVM in iSCSI
Да и харды особо не наменять — сервер весьма не новый, и если с >2TB дисками еще проблема как-то решается, то вот гарантированно совместимые харды (Seagate Constellation ES всех серий, HGST A7K2000 серии и пр. подобные) найти будет уже не просто, а современные очень не всегда в старье заводятся (разумеется, речь даже не о дисках с 4К блоком, а о 512e/512n).
Ваши сервисы стоят дешевле 12к рублей?
Может попробовать по этой доке — https://www.systutorials.com/docs/linux/man/7-lvmthin/ — увеличить место под metadata-pool?
Если в volume group место еще есть, конечно.
Конкретные инструкции в разделе "Metadata space exhaustion".
И посмотрите, не осталось ли snapshot-ов виртуалок в LV.
Promox мог оставить после бекапов. Или может вы сами делали.
Тогда разве что забекапить ВМ по одной. Удалить вместе с LV. И разбекапить обратно.
1) удалить диски виртуалок не получится. потому как, даже процедура удаления требует изменения меты, у которой нет места.
2) забекапить надо куда то. выше ребята в комментах подсказали отличную идею с цеплянием по сети репозитория и переноса дисков туда. идея отличная (в моем случае репы не было и пришлось бы все равно нести в ДЦ USB-диск большой).
Возможно потому, что ZoL из коробки всё ещё не умеет отлично работать.
К сожалению не всё так радужно.
При высокой I/O нагрузке на zfs, даже только на чтение, система начинает залипаться и тупить.
Конкретно Proxmox 5.0 + последний ZoL 0.6.5.11 при работе бекапов.
И это не рабочий сервер под нагрузкой, а тестовый.
Диски правда не SSD.
Если использовать хранилище на LVM / Dir + (ext|x)FS — таких диких лагов не наблюдается.
Вообще имея zfs можно вместо бэкапов делать реплики на уровне файловой системы. Это вообще не нагружает систему, т.к. Zfs не нужно сравнивать файлы и совершать какую либо работу, что бы получить разницу между 2 снимками.
- используем контейнеры, данные — в датасетах
- recordsize = 32k
- без дедупликации
- включено сжатие lz4
- arc_max_size = 4G
- logbias оставлен на latency, на throughput еще хуже лагает
- swap на отдельном разделе, не на zfs. да и почти не используется.
/etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=8299967296 # (по умолчанию 50% от общего объема памяти)
# arc_sys_free — количество памяти которое нужно оставлять свободным. По умолчанию 1\64 от общего объема :)
options zfs zfs_arc_sys_free=6442450944 # (оставлять 6 гб свободной памяти)
- Нужно использовать trim
описано в разделе Using fstrim to increase free space in a thin pool LV При этом уменьшается использование не только Data, но Меtadataman lvmthin
- Обязательно использовать мониторинг lvm thin томов, например, через zabbix
lvs -aЯ мониторинг lvm пока только так себе вижу
Решил изучит вопрос, т.к. использую LVM-Thin и вот что нашел. Может кому пригодиться
http://manpages.ubuntu.com/manpages/xenial/man7/lvmthin.7.html
Manually manage free metadata space of a thin pool LV
lvextend --poolmetadatasize +100M pve/data
Пример:
#lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- 811,26g 2,51 11,67
[data_tdata] pve Twi-ao---- 811,26g
[data_tmeta] pve ewi-ao---- 104,00m #lvextend --poolmetadatasize +104M pve/data#lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- 811,26g 2,51 8,53
[data_tdata] pve Twi-ao---- 811,26g
[data_tmeta] pve ewi-ao---- 208,00m vasyakrg Спасибо за лекции по Proxmox!!!
Сори что поднимаю такой старый пост.
По поводу ZFS, как только ZFS ограничить по оперативке (в мое случае я нарадоваться не мог, какой ZFS молодец, какая у него чудесная скорость, пока он не сожрал 100 гигов, я ограничил zfs_arc_max 32), подсистема начинает жестко тупить, скажем виртуалки не могут прокачать да же 5 мегабит, хоть с "Write back" хоть "No cache".
Так же из за arc кеша не всегда понятно, то ли диск умирает, то ли ограничение по кешу в оперативку.
То есть мало того что виртуалка кеширует так еще и zfs со своими уровнями.
И да, прокс с zfs еще не до конца дружит. К примеру при создании zfs на чистых дисках пишет "failed: exit code 1" а в лог, незаметно "contains a corrupt primary EFI label" а? Чо??
А надо использовать -f, но это в консоль надо лезть и в ручную делать. А при некоторых смешных случаях диск с виртуалкой может и не удалиться и в логи капнет "TASK ERROR: zfs error: cannot destroy 'zfs_raid/vm-100-disk-0': dataset is busy". Но узнаете Вы об этом потом, потому что сам proxmox отрапортует что всё удалилось. И опять в ручную lsof и кто там безобразничает.
К чему я?.. А, да. Ну вообщем интеграция proxmox и zfs пока на начальном уровне и может надежнее старый добрый mdadm с ext4.
для продолжения дискуссии приглашаю вас в наш клуб любителей ИТ (в том числе и прокса) — t.me/realmanual_group
мы там часто тележим за такие вопросы.
Proxmox 4. День второй. Thin-LVM