master/master по сети.

Заходит мужик к доктору и говорит: Доктор, у меня не стоит.
Доктор, оглядываясь: а кого ты тут иб#ть собрался?

А что ты писать собрался, ты не скажешь?

писать на машину А

Не рекомендую. Током может ударить.

Извини, не удержался.

Небольшие файлы. Скорость не нужна. Это всё хомячковое. То есть ничего сурьёзного.

Короче: хочу Raid1, по сети, с master/master. И со снепшотами... drbd + lvm не предлагать. :) dropbox тоже не предлагать. У меня большой объём. Сейчас пользую для этих целей mail.ru, но синхронизация там хромает.... :(

Нужна репликация именно на уровне ФС? Попробуй glusterfs, я через него проворачивал мастер-мастер.

Да в общем то просто хочется dropbox, только без третей точки по середине, при условии прямого соединения двух узлов. Но ещё хочется снепшоты, чтобы в случае чего, можно было бы поднять файлы.

На медленных, и не всегда стабильных коннектах как оно?

На медленных ок, а нестабильный коннект раньше (год назад) грозил частыми split-brain'ами. Сейчас хз, может поправили.

У glusterfs есть georeplication. Сам не пробовал, не скажу, как оно работает на практике.
А вообще, rsync тебе в помощь, для такой задачи самое оно.

Да мне тоже хочется rsync. Только вот не очень пока мест понимаю на тему сплит брейна... Что я буду делать, если будет конфликт, и тому подобное. Например из одного места удалю...

Тьфуй, не закончил мысль. В общем не очень понятно, как пользоваться rsync. Надо постоянно будет решать кто есть master, а кто slave, что не есть удобно. :( Можно конечно замутиться проще, смонтировать директорию с удалённого ПК, и писать строго в неё, с двух мест, а читать с локальной копии rsync. - В принцип, очень просто, надёжно. Но не очень удобно.

mdadm network raid + nfs

ceph, hdfs, gridfs, glusterfs ?

C rsync только одна проблема, если втупую делать: если ты удалишь в одном месте, надо будет одновременно удалить в другом. Просто если у тебя сломается тот же гластер, или ещё какая-нибудь распределенная ФС чинить тебе будет намного сложнее её, чем тупой rsync.
Ну и ваще советую тебе один сервер таки держать в качестве основного, и писать на него всегда, а во второй писать только тогда, когда основной упадёт. Делается это через тот же haproxy очень легко, с помощью опции backup. При этом ты вероятность косяков сведёшь почти к нулю, т.к. падение основного сервера - это обычно редкая ситуация.

У нас для подобной задачи, кстати, используются опции rsync -au, если вдруг решишь делать. С гластером реплицированным как-то жили, но его во-первых мониторить сложно, во-вторых неочевидно его поведение, когда он сплитбрейн словит, да и в нём баг на баге, и багом погоняет.

BTSync, а снапшоты как-нибудь сами..

C rsync только одна проблема, если втупую делать: если ты удалишь в одном месте, надо будет одновременно удалить в другом. Просто если у тебя сломается тот же гластер, или ещё какая-нибудь распределенная ФС чинить тебе будет намного сложнее её, чем тупой rsync.

Вот и у меня есть стойкое понимание этого... Всё бы ок, с rsync, то тогда, таки да: писать надо будет строго в одно место. Но при этом читать то я хочу локально... Если я с дома для работы вытянул дистрибутив на 10 гб. Oracle, очевидно, что мне никак не понравится идея читать его из дома... - И наобарот.

BTSync, ИМХО всё ещё не очень готов для linux. Я думал, может есть что-то тупое аля rsync, или даже может мне он тоже подойдёт как-то...

по моему личному опыту в кластере из двух нод проблема сплит брейна автоматически не разрешима. Я сейчас использую lsyncd. Мастера выбирает pacemaker

Блин, очень гемморно конечно... :(

OwnCloud - не ?

Да вроде простая у меня задача... Ну таких монстров городить..? Да и глючное оно... Не?

Да не, не глючное, для хомяков самое то.
Удобно так то. Да и не особый монстр, который ты можешь контролировать в отличии от mail.ru.