товарищи, а кто-нибудь работал плотно с protobuf/msgpack? знаете разницу между ними?

Я

Обрисуй задачу)

Как по мне, единственная причина юзать оверинжиниреный протобаф - это gRPC

Также рекомендую capnp

Оч круто и оч быстро)

Также рекомендую capnp

А capnp он о чем?

Я

мне надо примерно 50к в секунду бинарных сериализованных структур довольно четкого формата пересылать

Как по мне, единственная причина юзать оверинжиниреный протобаф - это gRPC

Нууу... Он еще и эффективный

мне надо примерно 50к в секунду бинарных сериализованных структур довольно четкого формата пересылать

Если у тебя четкий формат - лучше какой-то protobuf или cbor

Хотя, вру

Не cbor

Если у тебя четкий формат - лучше какой-то protobuf или cbor

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

по сути, это сетевой траффик

то есть структуры - это блоки дампов бинарных сетевых пакетов

@Enchantner протобуф от сериализатора сильно зависит. Есть гугловый, он работает, совместимый, но средненький. Например для го есть gogoprotobuf и он очень сильно интереснее

мне надо для C++ и Scala

и для других языков тоже есть альтернативные реализации которые веселее

@pavel_odintsov кстати, ты для Го на этот самый gogo/protobuf смотрел же?

Grpc я юзаю на го и плюсах

сетевой трафик - это ко мне :)

capnp тебе товарищ :)

читаю хабр, а там алексу чистякову респекты высказывают.

Он правда вездесущ.

Because I care

patroni кажется прекрасной штукой

надо будет заюзать и попробовать собрать кластер постгресов

Здравствуйте, подскажите пожалуйста по поводу borgbackup #borg, я правильно понимаю что для бекапа данных с хоста X на хост Y у меня имеются два варианта: 1. На хосте Х установить Borg, создать пользователя , сгенерировать ключи, закинуть публичный на Y (где также необходимо создать пользователя) и далее уже на хосте Х borg init user@Y:/path/to/repo , и далее кроном переодически бекапить. 2. Не устанавливать borg на хост X , а с хоста Y монтировать через sshfs необходимые директории и бекапить уже как локальные Получается в первом случае мы должны полностью доверять хосту X , во втором случае сжатие будет происходить уже на хосте Y . Поправьте меня если я где-то не прав и возможно у кого нибудь имеются примеры или best practice, тоже не откажусь.

Здравствуйте, подскажите пожалуйста по поводу borgbackup #borg, я правильно понимаю что для бекапа данных с хоста X на хост Y у меня имеются два варианта: 1. На хосте Х установить Borg, создать пользователя , сгенерировать ключи, закинуть публичный на Y (где также необходимо создать пользователя) и далее уже на хосте Х borg init user@Y:/path/to/repo , и далее кроном переодически бекапить. 2. Не устанавливать borg на хост X , а с хоста Y монтировать через sshfs необходимые директории и бекапить уже как локальные Получается в первом случае мы должны полностью доверять хосту X , во втором случае сжатие будет происходить уже на хосте Y . Поправьте меня если я где-то не прав и возможно у кого нибудь имеются примеры или best practice, тоже не откажусь.

1 и 2 правильное, выводы неправильные.

1 - можно ограничить возможность запуска до borg serve (в документации про это написано) 2 - сжатие всегда происходит на стороне клиента

и я поленился попробовать, но сдается мне что поверх sshfs будет медленно.

Всем добрый день. Может кто-нибудь подскажет, есть ли у glusterfs авторизация клиентов?

1 - можно ограничить возможность запуска до borg serve (в документации про это написано) 2 - сжатие всегда происходит на стороне клиента

спасибо, прочитаю ещё раз документацию

Рад, мы рады тебя видеть здесь)

Всем добрый день. Может кто-нибудь подскажет, есть ли у glusterfs авторизация клиентов?

Лучше просто не использовать glusterfs

Всем добрый день. Может кто-нибудь подскажет, есть ли у glusterfs авторизация клиентов?

https://gluster.readthedocs.io/en/latest/Administrator%20Guide/SSL/

Всем добрый день. Может кто-нибудь подскажет, есть ли у glusterfs авторизация клиентов?

нет, начиная с 3.2, кажется, нету (а раньше вроде была). и глюстерфс - это очень, очень медленно. Если все данные фактически не рид онли, которые надо гарантированно раскидать по десятку ДЦ, то лучше им не пользоваться

нет, начиная с 3.2, кажется, нету (а раньше вроде была). и глюстерфс - это очень, очень медленно. Если все данные фактически не рид онли, которые надо гарантированно раскидать по десятку ДЦ, то лучше им не пользоваться

Им лучше а любом случае не пользоваться

а чем пользоваться?

а чем пользоваться?

а для какой задачи?

например в случае когда есть какой нибудь бложик на php и нужно как то реплицировать загружаемые пользователями аватарки и прочие картинки на несколько нод

пишут их не часто, а читают постоянно

а чем пользоваться?

кто первый расскажет про ceph?

кто первый расскажет про ceph?

Dreamhost :))))))))))

например в случае когда есть какой нибудь бложик на php и нужно как то реплицировать загружаемые пользователями аватарки и прочие картинки на несколько нод

рсинк

и если это бложик то файлов мало

а если файлов мало, то была какая-то штука на питоне, которая вешалась на инотифай и рсинкала при добавлении

Rsync

Lsync

вот даже готовая статья - https://habrahabr.ru/post/132098/

с альтеративами в тексте

а вот если не бложик и файлов миллионы то всё куда интереснее

у lsyncd очень не хватает в базовой поставке нормального конфига, вот такого плана: https://github.com/axkibe/lsyncd/issues/376#issuecomment-218974606

а то там чтобы сделать conf.d - нужно изучить камасутру.

у lsyncd очень не хватает в базовой поставке нормального конфига, вот такого плана: https://github.com/axkibe/lsyncd/issues/376#issuecomment-218974606

У меня знакомые форкнули lsync и что то там переделали под себя

https://github.com/xaionaro/clsync

И они там у себя его где то используют

Но я не тыкал никогда

круто. они его не форкнули, а написали lsync but on c" due to "lsyncd" that written on "LUA"

thanks! я это изучу, как раз есть кейс.

как раз мой кейс. It really eats 100% CPU sometimes.

оно при любом случае будет есть проц

потому что в винде можно просто повесить инотифай на фс, а в линуксе - надо на каждый каталог

и когда каталогов много - приехали

хмм можно попробовать обходить через помещение многих каталогов в один каталог, на котором будет inotify. если гора не идет к магомету, то магомет идет к горе.

нет, так работать не будет )

ERROR: S client not available

круто. они его не форкнули, а написали lsync but on c" due to "lsyncd" that written on "LUA"

помоему изначально был форк где по кускам луа на си переписывали, могу ошибаться. Автор есть в IRC и физически в Москве, если что

@lastsky ну Ник частично прав, в inotify нет рекурсивных уведомлений и это некоторая проблема.

1 inotify fd на каждый каталог в дереве

чем больше каталогов тем больше сама подсистема ест, хотя тысячи каталогов все еще обрабатываются сносно

то есть если у тебя структура: foo/ foo/bar/ foo/baz/ то тебе надо 3 fd на эту структуру

один на foo, один на bar, один на baz

и веселости в том что когда кто-то делает mkdir -p foo/bar/bam/bom то тебе надо вешать нотифай на foo/bar/bam, сканить его, вешать нотифай на foo/bar/bam/bom

потому что вероятно второй эвент придет до того как ты повесишь свой notify

Спасибо большое, да уже почитал доку и все понял про авторизацию. У нас ТЗ, приходится тащить сие поделие?

вот даже готовая статья - https://habrahabr.ru/post/132098/

Работает он как говно

FreeNAS Corral supports Docker, an open source software for automating the deployment of applications inside software containers. Docker containers provide a complete file system, runtime, system tools, and system libraries. This guarantees that the application will always run the same, regardless if it is running on FreeNAS Corral or in a different environment. Deploy applications inside software containers using Docker. Applications use the self-healing file system provided by FreeNAS Corral.

Ждем не дождемся пока в проксмокс сунут докер ?

Странно что так долго не реализовывали. Netapp уже давно так делает в своих устройствах. Даже одни из ведущих комитеров в бсдю стали.

а кто с гугло клаудом работал ?

есть интересный баг, в стартап скрипте в одной зоне ломаеться yum install, после ребута и в других зонах все ок

потому что в винде можно просто повесить инотифай на фс, а в линуксе - надо на каждый каталог

Это один раз.

в реальной жизни это может занимать часы на больших объемах

1 inotify fd на каждый каталог в дереве

Эээ... Зачем?

== zfs send/recive по крону раз в минуту работает лучше

Ник, а ты патч для ядра от Фаста юзал под зфс?

это был мой последний проект, его закончили как я уже уволился

ну и вот то что тут выше написали что при добавлении нового каталога надо его обходить потому что новый нотифай приедет до того, как на него будет что-то висеть - это тоже проблема

https://www.stableit.ru/2017/01/openvz-zfs.html

этот вот

Ник, а ты патч для ядра от Фаста юзал под зфс?

если это про трансляцию вызова квот для зфс на стороне ноды, то я начал читать, но не понял как это запустить

про квоты, да

транслятор с квот зфс в квоты линукса

+ квоты на файле в самой зфс, их тоже недавно замутили

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

+ квоты на файле в самой зфс, их тоже недавно замутили

это не понял

квота на число файлов в зфс вольюме

а зачем?