« Rev
@ru_zfs   737
Fwd »


instant
Зачем mdadm, если ты мог просто собрать lvm raid1?...
наверное, но применяешь то что то знаешь. Спасибо за информацию. почитаю
instant
Зачем mdadm, если ты мог просто собрать lvm raid1?...
Я с Вами не соглашусь. Я не применял в практике, не тестировал, а только почитал. Но из прочитанного вынес. В предполагаемом Вами варианте с начало создается LVM, а поверх нее RAID. Это ограничивает в гибкости использования в системе виртуализации. мне нужно будет постоянно создавать lvm тома с raid масивами того размера, который мне нужно в тот или иной момент при создании ВМ. В восстановлении и замены физического диска в предлагаемом Вами варианте RAID нужно пройти больше шагов и он сложнее. А проблемы с диском и RAID массивом могут возникнуть в самый не подходящий момент и надо делать быстрые шаги для устранения ИТ инцидента. Да и LVM использует драйвер MD для работы с дисками на физическом уровне , т.к. mdamd утилита, которая добавляет поддержку RAID массивов в ОС Linux на уровне ядра. И последнее, массивы, созданные при помощи LVM RAID будут медленнее. YНо спасибо, расширил не много знания
Vladislav
Я с Вами не соглашусь. Я не применял в практике, не тестировал, а только почитал. Но из прочитанного вынес. В предполагаемом Вами варианте с начало создается LVM, а поверх нее RAID. Это ограничивает в гибкости использования в системе виртуализации. мне нужно будет постоянно создавать lvm тома с raid масивами того размера, который мне нужно в тот или иной момент при создании ВМ. В восстановлении и замены физического диска в предлагаемом Вами варианте RAID нужно пройти больше шагов и он сложнее. А проблемы с диском и RAID массивом могут возникнуть в самый не подходящий момент и надо делать быстрые шаги для устранения ИТ инцидента. Да и LVM использует драйвер MD для работы с дисками на физическом уровне , т.к. mdamd утилита, которая добавляет поддержку RAID массивов в ОС Linux на уровне ядра. И последнее, массивы, созданные при помощи LVM RAID будут медленнее. YНо спасибо, расширил не много знания
Не md, а dm Начнём с этого Дальше, что за херню Вы только что сказали? В восстановлении и замены физического диска в предлагаемом Вами варианте RAID нужно пройти больше шагов и он сложнее Вы всё равно ручками заменяете диск, что в одном, что в другом случае. Ну придётся выполнить не 1, а 3 команды из блокнота поменяв букву. КАКОЙ УЖАС. надо делать быстрые шаги для устранения ИТ инцидента. Действительно, лучше городить бутерброд. В предполагаемом Вами варианте с начало создается LVM, а поверх нее RAID. ...... pvcreate /dev/sda1 /dev/sdb1 vgcreate my_vg /dev/sda1 /dev/sdb1 lvcreate --type raid1 -m2 -L 100%FREE -n my_lv my_vg ВСЁ. Какой рейд поверх LVM???
instant
Не пылите. Я с Вами согласен, можно из записной книжки копировать и вставлять - это не сложно. Вы правы. Но я, как писал выше, использую массив для виртуализации. Proxmox-у я "скармливаю" только "my_vg" и он сам распределяет чего и сколько той или иной виртуалке нужно. Если использовать lvcreate --type raid1 -m2 -L 100%FREE -n my_lv my_vg, то созданный том с RAID можно будит использовать в качестве 100% блочного устройства и отдать ее одной "виртуалке" (что имеет право на жизнь) или создать файловую систему на нем и монтировать в Proxmox, а далее в виде директории на которой будут создаваться файлы qcow виртуальных машин. Это заметно снижает скорость по сравнению с raw . Можно конечно нарезать не 100%, а иначе, в соответствии с потребностью Proxmox и "прокидывать" на вновь создаваемую ВМ , но мне кажется это менее удобно. Извините если я Вас чем то обидел. Я не использовал Ваш вариант. Будет время протестирую. Но в теории мне кажется так...
Vladislav
Не пылите. Я с Вами согласен, можно из записной книжки копировать и вставлять - это не сложно. Вы правы. Но я, как писал выше, использую массив для виртуализации. Proxmox-у я "скармливаю" только "my_vg" и он сам распределяет чего и сколько той или иной виртуалке нужно. Если использовать lvcreate --type raid1 -m2 -L 100%FREE -n my_lv my_vg, то созданный том с RAID можно будит использовать в качестве 100% блочного устройства и отдать ее одной "виртуалке" (что имеет право на жизнь) или создать файловую систему на нем и монтировать в Proxmox, а далее в виде директории на которой будут создаваться файлы qcow виртуальных машин. Это заметно снижает скорость по сравнению с raw . Можно конечно нарезать не 100%, а иначе, в соответствии с потребностью Proxmox и "прокидывать" на вновь создаваемую ВМ , но мне кажется это менее удобно. Извините если я Вас чем то обидел. Я не использовал Ваш вариант. Будет время протестирую. Но в теории мне кажется так...
только "my_vg" Окей, тогда вопросов нет Это заметно снижает скорость по сравнению с raw По сравнению с lvm* raw это просто блочка будет Извините если я Вас чем то обидел. Я не использовал Ваш вариант. Будет время протестирую. Но в теории мне кажется так... Да нет, скорее я слабо знаком с проксом, считал, что он как и ovirt сам нарезает то, что ему хочется и имеет возможность собирать raid-lvm
George
удаление асинхронное, плюс если есть ещё снапшоты - удаление одного фактически может ничего не удалить (размер снапшота относителен)
Ivan
либо на это нужно время, либо ещё есть снапы жрущие место
Ivan
не скажу. точно не scrub.
George
zpool get freeing для начала посмотреть
George
оно асинхронное на фоне, в рамках каждого txg
Aleks
раз в какой-то период имеет смысл делать полный бекап, удалять инкременты от прошлого полного и потом от последнего снова плясать инкремент. Иначе можно однаждны заметить, что бекапа у тебя нет
Vladislav
https://github.com/psy0rz/zfs_autobackup
Vladislav
Не бывает инкрементального бэкапа без снапшота
Vladislav
Логично, Вы теряете точку синхронизации
Vladislav
Правда так должно быть один раз
Vladislav
На следующий снапшот после удаления старого
Vladislav
А вообще почитайте скрипт, там интересные вещи есть
Vladislav
Сперва попробуй
Okhsunrog
Можете в сторону zrepl посмотреть ещё
Vladislav
Не бывает утилиты, которая умеет больше чем zfs
Александр
Не бывает утилиты, которая умеет больше чем zfs
zfs не делает резервного копирования и ротации снапшотов. zrepl не работает с дисками
Александр
Это всё выполнимо средствами ZFS
Но автоматизацию zfs не делает. И не копирует, например)))
жюн
cron
Vladislav
В плане? ZFS send | recv оперирует ТОЛЬКО снапшотами
Vladislav
????
Vladislav
"Эту" это какую?
Vladislav
Стоп, а как Вы сейчас снапшоты передаёте?
Сергей
Странный вопрос. У вас есть некоторое количество файлов (данных, блоков). 5 созданы в первый день, пять во второй, пять в третий. Сделаны снимки. Снимок первого дня содержит эти 5 файлов. Снимок второго дня — все файлы первого дня и пять второго. Снимок третьего — все первого и второго плюс пять своих. Удаляете первый снимок, но файлы-то остались. Теперь снимок второго дня содержит прямые ссылки на все десять, вот и рост размера.
George
zrepl интересная штука, она закрывает вопросы аутентификации и транспорта, что очень удобно, главное осилить настроить
Сергей
Когда удалите эти файлы из рабочего набора и удалите последний снимок, в котором они были, место освободится.
central
И как потом после каждого удаления снепшота их мерджить между собой?
Vladislav
Ну так да Стоп, у Вас в этом был вопрос? Почему снапшоты после удаления корневого несут в себе инфу, которая раньше была в нём?
Ivan
такая же фигня. сначала замедляли до 5 мегабит, теперь еще ошибки соединений валятся до кучи.
Сергей
Грубо — на четвёртый день вы стёрли пять файлов первого дня. Получится — снимок вторго дня — 10 файлов (1-2 дни) — снимок третьего дня — 15 файлов (1-2-3 дни, видимый размер снимка при живом предыдущем — 5 файлов) Снимок четвёртого дня — десять файлов (2-3 дни), видимый размер - 0. После удаления снимков 2 и 3 дня ссылки на первые пять файлов исчезнут, видимый размер снимка 4 будет 10.
Vladislav
Я думал у Вас они бесконечно растут в арифметической прогрессии и снапшот в итоге весит х2,х3,х4,х5, и т.д. от изначального
Vladislav
Вы бы почитали что такое снапшоты тогда
Vladislav
11111111 Снапшот 1 - вес 1 байт 11110111 Снапшот 2 - вес 1 бит 11110011 Снапшот 3 - вес 1 бит 11110001 Удаляя снапшот 1 Вы получаете, что снапшот 4 будет весит - разницу между 3 и 1, ибо в 3 нет инфы про файлы из первого (вы же его удалили)
Vladislav
То что Вы ищите это merge/consolidate snapshot
Vladislav
А вообще, по идее, консолидация должна происходить, когда Вы делаете удаление, ибо удаляя снапшот 1 - теперь снапшот 2 является разницей в системе, но это я слишком к виму и Варя привык, надо почитать/проверить как это работает с zfs
Vladislav
Это концепт
жюн
https://www.bsdcan.org/2019/schedule/attachments/500_How%20ZFS%20Snapshots%20Really%20Work.pdf
Vladislav
А да, у zfs же работа ведётся с датасетом, а не с последним снапшотом тогда консолидация не совсем то, что Вам надо, скорее merge ближе И да это концепт, если он в zfs я не читал, дока в помощь
Vladislav
Судя по тому, что я не видел возможности смёрджить два снапшота - скорее такого нет, ну и да, если Вы мерджёте все снапшоты в один - он будет равен фулловому Идея скорее работать, как Вы догадались, через bookmark, чтобы zfs send | recv понимали, что надо ориентироваться на последний снап при копировании разницы
Vladislav
А ну и возможно https://github.com/jimsalterjrs/sanoid Решает это более автоматизировано
Xash
Syncoid отличный способ репликации. Сверху на него я накидываю zfs-prune-snapshot. Все работает прекрасно
Ivan
чтобы снапы много места не занимали достаточно старые снапы своевременно удалять.
Vladislav
Берёте 2 ВМ, ставите zfs Тестируете .... Profit
Nikita
блин, ну на датасетах же ж.
Nikita
вас что-то заставляет использовать только один метод экономии места?
Vladislav
...блять
жюн
Ivan
...блять
Или VM?
Vladislav
Vladislav
Vladislav
Или VM?
Вы как никогда близки
Vladislav
Александр
... ну да, и крон не делает ничего, чего нельзя сделать, встав в три часа ночи
Александр
Так и обвязка вокруг zfs тоже. Она просто автоматизирует создание-копирование-удаление
Александр
Если тебе нравится каждый день гонять руками пачку команд - то они тебе совершенно не нужны
Ivan
чем чаще делаешь снапы и пересылаешь данные а затем удаляешь снапы, тем меньше места тратится на снапшоты.
Vladislav
Тестировать решения на вм? Хуйня Думать над решением? Во идея
Александр
чем чаще делаешь снапы и пересылаешь данные а затем удаляешь снапы, тем меньше места тратится на снапшоты.
Не зависит. Чем дольше хранишь, тем больше места. Хотя зависит от многого, если ты часто делаешь снапшот, скажем, БД, то у тебя будет БОЛЬШЕ места занято.
Александр
А при чем тут это? Храним снапы за, допустим, неделю. Если у нас почтовая очередь загруженного сервера и мы делаем снапы раз в сутки - места занимается немного. А раз в минуту - вешайся
Ivan
А при чем тут это? Храним снапы за, допустим, неделю. Если у нас почтовая очередь загруженного сервера и мы делаем снапы раз в сутки - места занимается немного. А раз в минуту - вешайся
создал -> переслал -> удалил. в общих чератх. если не солить по сотне снапов при часто меняющихся данных, то не будет много места жраться.
Александр
создал -> переслал -> удалил. в общих чератх. если не солить по сотне снапов при часто меняющихся данных, то не будет много места жраться.
Короче, нет зависимости в общем виде между частотой снапшотов и объемом, занимаемом снапшотами за период времени
Александр
У нас же нет цели "хранить N копий", у нас цель "хранить копии за N суток, с указанными требованиями к интервалу между копиями"
Vladislav
Я сдаюсь с этим товарищем
Vladislav
Ему советуешь - он игнорит Ему рекомендуешь - он сразу говорит, что это никак не будет работать
Vladislav
Люблю таких ребят, зачем спрашивают? не понятно
Ivan
нет
Ivan
или я как-то неправильно пользуюсь снапшотами и у меня место освобождается 😃
Ivan
нет
Ivan
если б так всё и работало, у меня бы диск давным давно забился.
« Rev
@ru_zfs   737
Fwd »