Evgenii
инфа будет обновлена
Evgenii
в новом снимке прилетит
Evgenii
1) создаем remote_gold + клон main_gold (снимок1, снимок2, снимок3) -> remote_gold (снимок3) —> clon1 (снимок3)
Evgenii
2) изменяем main_gold, делаем снимок, отправляем main_gold (снимок1, снимок2, снимок3, снимок4) -> remote_gold (снимок3, снимок4) —> clon1 (снимок3)
Evgenii
3) перезагрузка клиента, скрипт уничтожает файловую систему и клонирует с последнего remote_gold снимка main_gold (снимок1, снимок2, снимок3, снимок4) -> remote_gold (снимок3, снимок4) —> clon1 (снимок4)
Evgenii
4) другой скрипт очищает старые remote_gold снимки, которые больше не нужны main_gold (снимок1, снимок2, снимок3, снимок4) -> remote_gold (снимок4) —> clon1 (снимок4)
Evgenii
вопросы?
Eugen
Все равно что то не вкурю, почему снимок/клон с золотого образа, можно заменить на новый на удаленном сервере, имея с него дерево потомков
Evgenii
можно создать снимок. можно удалить снимок. можно отправить РАЗНИЦУ между 2мя снимками, тогда на приемнике появится последний снимок (но чтобы это работало на нем уже должен быть 1й снимок)
Evgenii
мне кажется ты просто не вкуриваешь что такое снимок
Evgenii
проще думать о снимке как о метке, которой будут помечены все блоки, которые используются на момент создания снимка
Evgenii
если ты очистил блок (удалил файл), но у него есть метка снимка, он по факту не будет удален.
Evgenii
Пока блок связан хотя бы с 1м снимком, он не будет считаться свободным (это будет занятое пространство)
Evgenii
удаляя снимок, ты снимаешь метку снимка со всех блоков, в которых эта метка была
Evgenii
Все равно что то не вкурю, почему снимок/клон с золотого образа, можно заменить на новый на удаленном сервере, имея с него дерево потомков
Если remote_gold не изменяется (а это так, судя по твоей задумке) - он сможет принять новые снимки от main_gold в любой момент времени.
Evgenii
если случайно изменишь remote_gold (примонтируешь и запишешь туда файл), тогда remote_gold будет уже не в точке последнего снимка. Во время репликации нового снимка, будет ошибка - тебе напишут что со времени последнего снимка были изменения. надо будет делать rollback - откатиться на последний снимок и все пойдет
Evgenii
Ты лучше собери лабу и потестируй это все. Создай документ в гугле, и записывай наблюдения. В 100 раз надежнее и точнее будет, пока железно не разберешься, не используй в проде
Eugen
Единственное что вижу как рабочее, это скидывать навый снимок$day на сервер, и делать клоны пока не прилетит новый снимок$day, а старые удалять как только у них исчезнут все клоны
Evgenii
1) клон можно делать из любого снимка, не обязательно из последнего 2) снимок с main_gold на remote_gold можно отправлять в любое время и в любом количестве. 1 и 2 - не зависят друг от друга. Не пойму в чем твой вопрос в данный момент? с чем помочь
George
Народ, или руки кривые или одно из двух. Что я делаю не так?
на стороне сервера с которого send делаете что-то не так с командой, которую ему передали. Я бы смотрел её корректность. Ну и какой shell, почему это вдруг он 2> не так воспринял
George
Стандартный фряшный
кек, на маке g-melikov:~ g.melikov$ echo 1 2> /tmp/out 1 g-melikov:~ g.melikov$ cat /tmp/out g-melikov:~ g.melikov$ tcsh [g-melikov:~] g.melikov% echo 1 2> /tmp/out [g-melikov:~] g.melikov% cat /tmp/out 1 2
George
Стандартный фряшный
похоже syncoid для tcsh не умеет правильно команду формировать
Eugen
csh
George
csh
тоже самое g-melikov:~ g.melikov$ csh [g-melikov:~] g.melikov% rm /tmp/out [g-melikov:~] g.melikov% cat /tmp/out cat: /tmp/out: No such file or directory [g-melikov:~] g.melikov% echo 1 2> /tmp/out [g-melikov:~] g.melikov% cat /tmp/out 1 2
Evgenii
1 да 2 да В идеале я хочу отправить снимок с голд образа на удаленный сервер, заменив снимок что там уже есть. Но так не выйдет, это я уже понял.
ну заменить не выйдет, если есть клоны.. они используют те же блоки (т.е. пока есть клоны, удаление родительского снимка бессмысленно, место бы все равно не освободилось) отправляйте новые, а потом удаляйте старые. Это правильный способ
Eugen
Ну можно баш прикрутить, не проблема, но зачем если это тот же zfs send recv)
George
csh
надо смотреть свежая ли версия syncoid и почему вдруг такое счастье. Мб банальный баг
Evgenii
Ну можно баш прикрутить, не проблема, но зачем если это тот же zfs send recv)
Все верно, тут проще напрямую, если не стоит задача послать изменения сразу для дерева датасетов, то там все просто будет
Eugen
/usr/local/bin/syncoid version 2.0.3 FreeBSD bsd 13.0-RC5
Evgenii
возможно на удаленной стороне не стоит одна из утилит, через которую прогоняется поток? mbuffer
George
а тут явно в mbuffer двойка прилетела
George
как аргумент
Eugen
в общем буду придумывать скрипт как завязать на днях недели в названиях снимков, и в создании удалении на другой стороне. Видимо других вариантов нет
Eugen
За помощь спасибо)
Eugen
та нет, не покатит. Противоположная сторона должна пересоздавать 24\7 по конкретным именам, а спустя 2 дня можно смело удалять старый снимок
Evgenii
та нет, не покатит. Противоположная сторона должна пересоздавать 24\7 по конкретным именам, а спустя 2 дня можно смело удалять старый снимок
Главное оставляйте хотя бы 1 последний снимок на remote_gold Если связь с main_gold пропадет надолго, то новых снимков передано не будет, а старые все удалите. И все.. больше вы продолжить не сможете. Придется удалять remote_gold и пересылать заново целиком с main_gold Можно решить эту проблему через bookmark (относительно новая фишка), но проще так как я написал
Eugen
Буду экспериментировать, как дойдет до рабочей модели могу поделится, если интересно конечно. А пока спать)
Evgenii
Хотя.. можете забыть об этом, т.к. у вас будет защита от удаления последнего снимка :)
Evgenii
т.к. у вас будут клоны с которых будут работать виртуалки
Evgenii
пойду я спать, доброй ночи
Eugen
доброй ночи!
Δαρθ
если у файла больше чем 1 блок - то да. Но сжатие позволяет последний блок сжать
я даже проверил эту штуку, действительно, если при recordsize=1M сначала создать тыщи файлов по 1M, потом в каждый добавить по 64k, то при compression=off это дело займёт по 2М на файл, а при compression=любое -- как и положено по 1M+64k на файл (примерно). в файлы я писал полный несжимающийся рандом получается что когда нет сжатия, то файлы СТРОГО по размеру recordsize нарезаются, а когда сжатие есть -- как надо нарезаются. и получается что если нет сжатия то при recordsize=1M будет теряться примерно полмега на каждом файле (а если много файлов меньше 0.5М то и того больше)
Δαρθ
кстати я походу багу поймал в 2.0.4 если создать зашифрованный сет, записать в него файлы, потом записать пару файлов в то место где примаунчен сам пул, потом export/import -- то 1 раз не нашло пула, 2ой раз тот сет потерял все файлы интересно комунить тут поподробнее инфа? или сразу в багтрекер на гитхабе мне идти?
Δαρθ
Что значит потерял файлы? Вы точно расшифровали и примаунтили после импорта датасет? Звучит именно так
первый раз вообще пулов не нашлось при импорте во 2 раз сет примаунтился пустым, load-key ничего не изменил (остался пустым)
Δαρθ
Для простоты формируйте список всех команд для воспроизведения в таких случаях, можете сюда и прикладывать. Если что странное будет - уже потом в виде тикета на баг трекер поможем оформить
для начала вот так: после реимпорта сет как бы есть, но файлов в нём нет. возможно я что-то делаю не так при импорте. amd64, ядро 5.10.32, zfs 2.0.4, gentoo
George
для начала вот так: после реимпорта сет как бы есть, но файлов в нём нет. возможно я что-то делаю не так при импорте. amd64, ядро 5.10.32, zfs 2.0.4, gentoo
т.е. при создании зашифрованного датасета он автоматически загружает ключ и маунтит, а при импорте пула - он этого автоматически не делает
Δαρθ
я тоже еще потыкался -- пропажа пула не повторялась так что видимо ложная тревога
George
для начала вот так: после реимпорта сет как бы есть, но файлов в нём нет. возможно я что-то делаю не так при импорте. amd64, ядро 5.10.32, zfs 2.0.4, gentoo
скрипт воспроизведения можете проще даже делать, просто набор сырых команд что делали на своей стороне
George
чтобы время не терять в будущем на вылизывание скрипта :)
Δαρθ
в логе баша кстати посмотрю, спс )
central
такой себе показатель, что по fio
central
fio Это утилита для тестирования скорости накопителей, стоит смотреть на ее результаты
nikolay
а какую вы ожидаете? судя по выводу у вас в основном идет запись в пул. чтения очень мало.
nikolay
смотрите latency на чтение
George
потому что slog используется только для синхронной записи, и то эти же данные в следующем txg приедут на hdd
George
zpool iostat показывает только запросы, которые долетели до устройств, он ничего не говорит про загруженность дисков
George
Оно так не работает, вам tiered storage решения для этого нужно смотреть
George
iostat, например iostat -x 1 будет показывать нагрузку непосредственно на диски за секунду
George
Но там подвижных частей много, для всего свои команды
George
Одной кнопкой - нет. Только если несколько пулов и чем-то данные перекладывать
George
В общем то tiered storage так любой и работает