или если не minio, то что хорошо работает, когда серверы в разных дц?

Ну что значит хорошо

Конкретизируйте вопрос!

ничего не потеряется из-за высоких задержек сети?)

Вообще такой сторадж, который что-то ТЕРЯЕТ из-за пинга в 50мс это пиздец и выкинуть

Если его вообще юзают, такого не должно быть

ну, glusterfs что-то там ведь теряет?

при таких инсталляциях

А гластер кто-то всерьез использует?

не знаю) но иногда мелькает это название

Он, по моему опыту, при малейших проблемах в сети начинает капризничать

А гластер кто-то всерьез использует?

тут есть один не заслуживающий доверия товарищ, утверждающий, что используют массово.

В итоге куча времени уходит на его поддержку

вот кстати чтоб прям терял не было

А вот брики пересинкать приходилось иногда

воот) ему важна сеть) а кто к проблемам сети относится спокойно?

Там еще очень веселая штука с записью прямо в брик. Если такое случилось, то АВАРИЯ АВАРИЯ. Но такого просто не нужно допускать.

Но вообще да, отвратительный опыт работы с ним.

Внутренний садист предлагает NFS :D

Но это не решение, надо над ним писать

(собственно гластер над nfs работает)

допустим, берём 1 сервер с OVH, один сервер с Hetzner'а, 1 сервер с Online.net и 1 сервер у себя дома под кроватью ставим) и делаем хранилище) на чём?)

Вопрос: нужна ли моментальная синхронизация

Если нет, то вариантов тонна

Причем лаже если да, то inotify и rsync на коленке

Вопрос: нужна ли моментальная синхронизация

дефайн моментальная :) s3 например обещает всегда read-after-write, но допускает read-after-deletion

Допустимо ли, что объект не всегда синхронно доступен с любой ноды.

Ну то есть даже так: нужно распределенное хранилище или просто синхронизация данных.

Потому что это серьезно разные юзкейсы, которые друг с другом путают

ну если просто синхронизация - то ведь можно просто rsync?

по крону, угу

ну да

Вообще я гонял тучу данных по syncthing (миллионы файлов), ничего не терялось :3

Так что наверное, если синкать просто, то можно его попробовать

вариант с inotify и rsync я понимаю) а что ещё есть?

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

ну и да, у меня тестбенч — пачка машин в разных дц именно

Это не тестбенч специально, просто личная инфраструктура

Но так вышло, что это hetzner, Москва и DO

выглядит интересно) а если мне нужна событийная консистентность?

вот эти все read-after-write и прочее

вариант с inotify и rsync я понимаю) а что ещё есть?

lsyncd есть, если нужно готовое.

если тебе нужно обязательно, чтобы не было read-after-delete или read-stale, то тебе фактически нужно CP-хранилище.

если тебе нужно обязательно, чтобы не было read-after-delete или read-stale, то тебе фактически нужно CP-хранилище.

cp = consistency point , верно?

consistency + partitioning

https://ru.wikipedia.org/wiki/Теорема_CAP

а, тот треугольник) помню)

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

ну, glusterfs что-то там ведь теряет?

так разная реализация совсем

если цеф OSD раскидать по всему миру, тоже хуйня получится

если цеф OSD раскидать по всему миру, тоже хуйня получится

ну работать-то оно будет...

ну работать-то оно будет...

главное туда ничего не копировать? )

да нет, даже копировать можно. но медленно.

Проблема в том, что gluster еще и развалится скорее всего

Будет лежать на спине и ныть

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

например, Swift: AP

@vdrandom вот ты должен помнить веселье с гластером кстати

Можешь авторитетно сказать, это мы нахуевертили или гластер говно?

Из моего опыта - говно. При большом количестве дисковой активности на кластере разеъзжается, тупит и теряет ноды.

Это все, на секундочку, внутри одного дц.

да ещё и оверхед мощный.

Так, для конь текста.

Я боюсь представить, что с ним будет, размазанным по миру

При чём как распределённый, так и зеркало. Зеркало чуть меньше тупило емнип, но там и активности было меньше.

Вы всеръез сравнивали выше гласетер и минио ?

lsyncd есть, если нужно готовое.

Оно говно

В зависимости от задач, они могут решать одну и ту же.

ERROR: S client not available

Но вообще нет, не сравнивали

Там была цепочка - Теряет ли minio - Если теряет, то это говно выкинуть нахуй, и скорее всего никто не пользуется. - Но гластер же пользуют - Ааааа ну глааааааастер

Блядь

Есть какие-либо чаты без говна?

Есть. Приват с самим собой.

Оно говно

it depends. у меня оно стало говном примерно на 200М файлов.

зря я сказал про gluster) разговор ушел немного в другую тему)

мне хочется понять, каким проектам пофиг на плохую сеть

а каким не пофиг

вот есть Swift, ему вроде пофиг на сеть) но он AP, а какие есть PC, которым было бы пофиг на сеть?

вот есть Swift, ему вроде пофиг на сеть) но он AP, а какие есть PC, которым было бы пофиг на сеть?

оксюморон

я нуб в этом) поясни, плиз

CP на то и CP, что оно должно _синхронно_ записать.

как локальную копию, так и нелокальную.

или асинхронно, но не давать читать пока везде не запишет

разве нет?

оксюморон

чойта ?

или асинхронно, но не давать читать пока везде не запишет

да. только нелокальная копия должна узнать о том, что ее нельзя читать.

:)

чойта ?

у тебя есть ключ. он отреплицирован в другой датацентр. ты удаляешь ключ в своем датацентре. репликация удаления в другой датацентр - асинхронная. ты читаешь этот ключ после удаления. балансировщик отправляет тебя в удаленный датацентр. ты получил read-after-delete.

так. и что ? почему это не бьётся с AP ?

оксюмороном я назвал вот эту часть "какие есть PC, которым было бы пофиг на сеть"

А. сорян.

так. и что ? почему это не бьётся с AP ?

c AP все будет точно так же, только это будет ожидаемым поведением. и это норм, собственно, в огромном количестве кейсов.

ну вот и мне так кажется.

да. только нелокальная копия должна узнать о том, что ее нельзя читать.

допустим, передаём указание "сделать доступным в такое-то время", время заведомо большее, чем время загрузки на самую медленную ноду

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

>время заведомо большее, чем время загрузки на самую медленную ноду может случиться печаль, если у тебя будет partitioning в это время.

допустим, передаём указание "сделать доступным в такое-то время", время заведомо большее, чем время загрузки на самую медленную ноду

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

а то что ты пытаешься придумать, это RAMP

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

а можно поподробнее?

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