Vladislav
riv
Он прекрасно описан у Вима
Не сработает, веем востановит где, ещё 100ТБ места ему подавай?
Vladislav
Не сработает, веем востановит где, ещё 100ТБ места ему подавай?
? Если у Вас навернулось хранилище, то да, ему же надо куда-то восстановить
riv
Видимо я что-то не понятно объясняю.
Vladislav
А если хранилище цело - он просто туда и восстановит
Vladislav
Видимо я что-то не понятно объясняю.
Ты описываешь отдельные куски не рассказывая целиком задачу
Vladislav
Во-первых, логично, что Виму понадобится отдельный сторадж на 100ТБ+(retention days*data change rate per day), если система 100ТБ
riv
? Если у Вас навернулось хранилище, то да, ему же надо куда-то восстановить
Если навернулось тоинужно новое. У вас часто такое происходит? На проде у меня ни разу не было такого. А доступ к бекапу гиганских виртуалок нужен часто. Иногда их невозможно на бекапе запустить и не удобно, т.к. к бекапу доступа не должно у всех быть. Удобно вернуть снимок на прод в область ответсвенности хозяина вм
Vladislav
Во-вторых, если у тебя файловая шара на 100ТБ это один файл, то ахуеть
Fedor
Да само собой так и делается. Речь не о бекапе. Zgs оптимален для бекапа. Речь о небольшой недоработке функционала утилиты zfs-receive, а именно, не возможности принять с бекапа старый снимок в инкрементальном режиме. А это было бы очень полезно. И раз уж решь зашла про соавнение с btrfs я поинтересовался, в контексте соавнения с zfs, нет ли там такого. Ещё раз попробую объяснить. Речь идет о возможности сделать инкрементальную пересвлку не новый минус старый, а наоборот, старый минус новый, т.е. вернуть старый снимок и необходимые доя его существования блоки, когда в целевом датасете есть более новый но уже переданеый в бекап снимок. Нужно это чтобы клонировать сатрый снимок в целях получения доступа к бекапу не на бекапном сервере, а на основном. Речь идет о случае с гиганскими датасетами: 10ТБ, 100ТБ которые бекапятся ингрементально через узкий канал, условноо 300мегабит.
Всегда есть возможность запросить какой-то функционал у коммьюнити, либо сделать его самому. Это не недоработка, утилита прекрасно делает то, что должна. Теоретически, могут быть архитектурные ограничения в сторадже в зфс, которые могут этому помешать. Но этого не выяснить, пока не будет сформирован запрос в сторону коммьюнити.
Vladislav
А теперь ты ещё расскажешь про систему виртуализации
Fedor
гигантские виртуалки всегда зло
Vladislav
Когда речь идёт про 100ТБ - стоит оценить их стоимость со стороны бизнеса если на то пошло
riv
Во-первых, логично, что Виму понадобится отдельный сторадж на 100ТБ+(retention days*data change rate per day), если система 100ТБ
Смотрите прод 200Тб, иам вм 10..100Тб, бекап далеко, там пусть 1000ТБ и там истопия за год всег изменений. Мы туда посылаем снимки и удаляем их на проде. Но часто нужно вернуть снимок на прод. Сейчас для этих случаев мы просто не удаляем снимки сразу, они лежат занимая место месяц-два. Но всеравно, иногда надо поднять клон полугодовой давности - это то в чем zfs силен. К сожалению нес способа передать старый снимок назад на прод с бекапа в инкрементальном режиме.
riv
гигантские виртуалки всегда зло
Всё же работает, почему зло?
riv
Снимок всё ещё должен кто-то вернуть, а рестор бэкап кто-то запустить
Да но есть разница: возвращать 100ТБ или условные 50Гб инкрементов
riv
Да я про 100ТБ привел пример для ясности разницы масштабов. В реальности речь илет о десятках ТБ в максимуме, но это ничего не меняет. 10ТБ дополнительных ssd да ещё на все хранилищах (вы же не знаете куда восстанавливать придется) - это не правильно. Прямо сейчас выход в том что восстанавливается путем клонирования снимков и заускается на бекапе. Но часто это приходится назад на прод передавать и тогда происходит полная пересылка. Очень не удобно. При том что в zfs технически есть все чтобы вернуть старый снимок, просто утмлиты отказываются этотделать, предполагая что это ошибка.
riv
Но может быть подобное есть в btrfs, раз уж тут есть люди которые её эксплуатируют? Это был бы ещё один пунк в сравнении btrfs и zfs кроме скорости и надёжности. И если бы там такое было и так использовалось, можно было бы поднять вопрос о необходимости такой фичи в zfs намного более аргументировано.
Vladislav
Всё же работает, почему зло?
Потому что если нужны 10ТБ ВМ и это не пустое место, то значит что-то сделано не так, либо для таких объёмов стоит смотреть на enterprise оборудование
Vladislav
Либо делать так, чтобы даже если эта ВМ наебнулась было МНОГО времени на восстановление в силу наличия второй реплики
riv
Потому что если нужны 10ТБ ВМ и это не пустое место, то значит что-то сделано не так, либо для таких объёмов стоит смотреть на enterprise оборудование
Я вас не понимаю. Чем вам zfs хуже энтерпрайс, если работает и работает хорошо и не один год? Вы просто, вместо того чтобы вникнуть в суть задачи, решили что zfs-у не место в проде.
riv
Либо делать так, чтобы даже если эта ВМ наебнулась было МНОГО времени на восстановление в силу наличия второй реплики
И зачем это нужно, если есть путь сделать это проще, быстрее, надёжнее и дешевле?
Vladislav
И зачем это нужно, если есть путь сделать это проще, быстрее, надёжнее и дешевле?
Ну так зачем тебе тогда Reverse Incremental раз всё надёжнее так?
riv
Потому что если нужны 10ТБ ВМ и это не пустое место, то значит что-то сделано не так, либо для таких объёмов стоит смотреть на enterprise оборудование
А если вм только 100ГБ, сто меняется? Или 10Гб - уже ок, чтоли? Почему 100ТБ хуже чем 100ГБ? Я вообще не понимаю. При том "на энтерпрайс оборудовпнии", мало того что будет в 30 раз дороже, так ещё и медоеннее и 100% пересылка никуда не денется. Обычно там всё максимально тупо
Vladislav
Начнём с простого. ВМ на 10ТБ это головная боль по восстановлению. Если у тебя ни разу не отъёбывал сервер-хранилка целиком по CPU\адаптерам\материнке - рад за тебя, но в реальном мире это немного не так
riv
Ты серьёзно или рофлишь?
Значит обсуждать отичаи zfs от btrfs - это офтоп идите в личку, а обсуждение типа, весь ваш подход на zfs - это ге энтерпрайс, купите веем и не ебите мозг - это не офтоп? Впечатление что мы из разных чатов и на разном чзыке говорим
Vladislav
Без сравнения
Vladislav
И с этим вопросом тебя попросили сходить в чат BTRFS
riv
Без сравнения
А ьап пошлют в чат zfs - хаха. Я задал вопрос по тому что увидил что кто-то сравнивпет zfs и byrfs у себя, а значит вероятно юзает их и знает слабые и сильные места. Но я уже вижу что тут лучше всего знают про веем, в чате zfs 🤦‍♂
Vladislav
Значит обсуждать отичаи zfs от btrfs - это офтоп идите в личку, а обсуждение типа, весь ваш подход на zfs - это ге энтерпрайс, купите веем и не ебите мозг - это не офтоп? Впечатление что мы из разных чатов и на разном чзыке говорим
Ну, да. Я выражаю своё мнение про ZFS в ZFS чатике и рекомендую не пытаться натянуть ежа на носорога, а использовать средства предназначенные для описанной задачи
riv
Ну, да. Я выражаю своё мнение про ZFS в ZFS чатике и рекомендую не пытаться натянуть ежа на носорога, а использовать средства предназначенные для описанной задачи
Это мнение, как я вижу, человнка плохо владеющего zfs и ничего ответвенного на нем не делающего. Не надо слушать такое мнение.
Vladislav
Это мнение, как я вижу, человнка плохо владеющего zfs и ничего ответвенного на нем не делающего. Не надо слушать такое мнение.
Ну. Да? Если речь про прод я предпочитаю отказоустойчивые системы Но это уже оффтоп
Vladislav
Ибо у ZFS нет синхронной реплики
Roman
От большой вм, что и бэкапить, так это системный диск где всё установлено и настроено.
riv
Вм на 10 ТБ - говно для бэкапа. Сохраняйте данные отдельно и к ним, различными методами, можно прикрутить (чаще всего) обратные инкременты.
Все эти методы будут заведомо хуже того как это может работать на zfs в силу логических причин.
riv
Нет, просто ты фиксируешься на zfs, как на чём-то волшебном.
Для указанной ситуации это и есть волшебная пилюля. По тому что, иначе вам придётся из говна и палок сделать... Тадам, аналог zfs! Но это уже надо голосом. Я устал писать со смартфона
Vladislav
Когда СРК надо насаживать на proxmox
riv
Нет, ты пытаешься насадить ежа (СРК) на носорога (ZFS) и удивляешься, почему так плохо насаживается
Я вам привел массу аргументов, давайте теперь вы приведете. И так веем не подлерживаеттонкие клоны, вы скадете, тонкие клоны не нужны, толстую копию веем делает долго, большие вм не нужны, и вообще ничего не нужно, оставьте веем и тру энтерпрайс, а если он работает медленно, значит ваша задача не нужна. И кто тут фиксируется?
riv
я сравниваю в условиях локалхостовой файлопомойки, а не 'ынтерпрайза'
У меня-то всё работает, кроме досадного нюанса с обратной передачей сников, а вы мне тут рассказываете что zfs ненужОн 🤷‍♂
Vladislav
Я вам привел массу аргументов, давайте теперь вы приведете. И так веем не подлерживаеттонкие клоны, вы скадете, тонкие клоны не нужны, толстую копию веем делает долго, большие вм не нужны, и вообще ничего не нужно, оставьте веем и тру энтерпрайс, а если он работает медленно, значит ваша задача не нужна. И кто тут фиксируется?
????????? Ты мало того, что переврал все мои аргументы, так ещё и Т9 включи обратно (и Veeam пишется как Вим на русском) Тебе уже сказали, что не надо делать один большой диск на 10ТБ. Это больно для СРК. Ты просто проигнорировал. Начал говорить про медленно. При том, что изначально ты вообще говорил про административную задачу разграничения прав. Теперь ты продолжаешь гнуть про попытку сделать СРК из ZFS, когда у тебя уже есть виртуализация к которой есть ОТДЕЛЬНАЯ СРК
Fedor
Продолжите это обсуждение во флуде, плз.
Fedor
Что за срк, я не понимаю, и почему ему больно от 10ТБ?
предлагаю в другом месте обсуждать, уже оффтоп.
Vladislav
Кстати, я всё жду sync replication ZFS
Roman
А ьап пошлют в чат zfs - хаха. Я задал вопрос по тому что увидил что кто-то сравнивпет zfs и byrfs у себя, а значит вероятно юзает их и знает слабые и сильные места. Но я уже вижу что тут лучше всего знают про веем, в чате zfs 🤦‍♂
Интересно, если ты подумаешь, то поймёшь или нет, почему нельзя из реплики вернуть (без доп приседаний) снапшот на исходную фс, на которой не осталось снапшотов?
Roman
Кстати, я всё жду sync replication ZFS
В потоке на другой сервер?
Vladislav
В потоке на другой сервер?
Даже если с условным требованием в интерконнект на 100Г, при входе 2x25 к примеру
Vladislav
Агент зфс не умеет
Файлово умеет
Алексей
Vladislav
Пфф
Дальше читай, я про файловый бэкап говорил, там человек уже потом дошёл до того, чтобы описать свою задачу
Станислав
хороший продукт, кстати
Я же не спорю, но Владислав часто его упоминает не к месту)
Vladislav
Я же не спорю, но Владислав часто его упоминает не к месту)
Человек хотел Reverse Incremental, который является частью стандартных возможностей бесплатного Вима не упоминая ничего дополнительного, какой запрос был такой и ответ Это потом уже выяснилось, что он насаживает ежа на носорога
Ivan
Скопировал то что удалил бот: Всем привет, есть вопрос по дедупликации, подскажите пожалуйста. ОС - Ubuntu 20.04.6 LTS x86_64, ядро - 6.1.45, zfs - zfs-2.1.12. Создал пул raid-z1 на HDD дисках со special vdev на SAS SSD. На этом пуле создал тонкий том с блоком 32K и отформатировал в ext4. Примонтировал том и нагрузил с помощью fio, при этом rw=write (Sequential writes), а bs=1M. Во время тестирования нагрузка пульсирует c ~ 1300MiB/s до нуля. При этом zpool iostat -yv показывает, что ввод/вывод на special vdev происходит только переодически, небольшими промежутками времени. Заменил SAS SSD на NVME SSD для special vdev, пересоздал пул и повторил описанные выше шаги - результат аналогичный. Нашёл несколько источников источник-1 источник-2 , где говорится что, ввод/вывод с дедупликацией представляет собой смешанный read/write блоками по 4K. При этом только на SSD моделей Intel Optane 900p, 905p, P48xx данная нагрузка (смешанный read/write 4K блоками) будет нормально работать, а на большинстве остальных SSD будет сильная просадка. Так же повторил тест, когда fio bs=128K и для созданного тома -b 128K . Нагрузка так же пульсировала c ~ 1300MiB/s, но уже не падала до нуля, минимальная скорость была 25MiB/s. Может быть есть ещё какие либо способы повысить производительность подобного пула без замены железа? Заранее благодарен.
Daniil
Скопировал то что удалил бот: Всем привет, есть вопрос по дедупликации, подскажите пожалуйста. ОС - Ubuntu 20.04.6 LTS x86_64, ядро - 6.1.45, zfs - zfs-2.1.12. Создал пул raid-z1 на HDD дисках со special vdev на SAS SSD. На этом пуле создал тонкий том с блоком 32K и отформатировал в ext4. Примонтировал том и нагрузил с помощью fio, при этом rw=write (Sequential writes), а bs=1M. Во время тестирования нагрузка пульсирует c ~ 1300MiB/s до нуля. При этом zpool iostat -yv показывает, что ввод/вывод на special vdev происходит только переодически, небольшими промежутками времени. Заменил SAS SSD на NVME SSD для special vdev, пересоздал пул и повторил описанные выше шаги - результат аналогичный. Нашёл несколько источников источник-1 источник-2 , где говорится что, ввод/вывод с дедупликацией представляет собой смешанный read/write блоками по 4K. При этом только на SSD моделей Intel Optane 900p, 905p, P48xx данная нагрузка (смешанный read/write 4K блоками) будет нормально работать, а на большинстве остальных SSD будет сильная просадка. Так же повторил тест, когда fio bs=128K и для созданного тома -b 128K . Нагрузка так же пульсировала c ~ 1300MiB/s, но уже не падала до нуля, минимальная скорость была 25MiB/s. Может быть есть ещё какие либо способы повысить производительность подобного пула без замены железа? Заранее благодарен.
Спасибо
Vladislav
Спасибо
Для начала зачем Вам нужна дедупликация?
Vladislav
Скопировал то что удалил бот: Всем привет, есть вопрос по дедупликации, подскажите пожалуйста. ОС - Ubuntu 20.04.6 LTS x86_64, ядро - 6.1.45, zfs - zfs-2.1.12. Создал пул raid-z1 на HDD дисках со special vdev на SAS SSD. На этом пуле создал тонкий том с блоком 32K и отформатировал в ext4. Примонтировал том и нагрузил с помощью fio, при этом rw=write (Sequential writes), а bs=1M. Во время тестирования нагрузка пульсирует c ~ 1300MiB/s до нуля. При этом zpool iostat -yv показывает, что ввод/вывод на special vdev происходит только переодически, небольшими промежутками времени. Заменил SAS SSD на NVME SSD для special vdev, пересоздал пул и повторил описанные выше шаги - результат аналогичный. Нашёл несколько источников источник-1 источник-2 , где говорится что, ввод/вывод с дедупликацией представляет собой смешанный read/write блоками по 4K. При этом только на SSD моделей Intel Optane 900p, 905p, P48xx данная нагрузка (смешанный read/write 4K блоками) будет нормально работать, а на большинстве остальных SSD будет сильная просадка. Так же повторил тест, когда fio bs=128K и для созданного тома -b 128K . Нагрузка так же пульсировала c ~ 1300MiB/s, но уже не падала до нуля, минимальная скорость была 25MiB/s. Может быть есть ещё какие либо способы повысить производительность подобного пула без замены железа? Заранее благодарен.
Особенно с таким блоком
Ivan
дедуп это билет в один конец. гроб-гроб-кладбище-..
Daniil
Для начала зачем Вам нужна дедупликация?
система резервного копирования
Daniil
Особенно с таким блоком
просто обнаружил такое поведение
Vladislav
система резервного копирования
Во-первых, у СРК (какая у Вас?) обычно есть встроенный дедуп Во-вторых, СРК обычно пишет большими блоками 128к-1024к