> 1. lustre_rsync (который rsync для изменений по changelog) не подходил?

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

Второй вопрос с реализацией клиента - он не должен заметить переключения между двумя фс, по сути можно попробовать использовать обычный iscsi multipathing, думаю это может сработать. Спасибо классную идею!

> 2. что вы понимаете под репликаций между физически разными серверами?

Была идея иметь большое количество OSS-серверов поделеные на отказоустойчивые пары,
а на каждой паре держать только один OST (блочное устройство реплицируемое по сети).

В случае отказа одного OSS, то OST перезапускался бы на другом.
Идея в том, чтобы отдельно взятые OSS всегда можно было перезагружать без видимых задержек для клиента, и в то же иметь зеркалирование данных.
Как я понял FLR сейчас решает эту задачу и без общего OST.

> 3. предложите другой метод (кроме FC, ISCSI) что бы раздать кучу дисков
> в 2 физических сервера одновременно.

Есть еще nbd, AoE, но не совсем понял зачем, iscsi работает отлично.