Почему была выбрана именно OCFS2? Прежде всего, из-за простоты установки и конфигурации. Так же, к её преимуществам относятся: (не стал переводить, т.к. некоторые вещи и не переведешь :) )

Optimized Allocations (extents, reservations, sparse, unwritten extents, punch holes)
REFLINKs (inode-based writeable snapshots)
Indexed Directories
Metadata Checksums
Extended Attributes (unlimited number of attributes per inode)
Advanced Security (POSIX ACLs and SELinux)
User and Group Quotas
Variable Block and Cluster sizes
Journaling (Ordered and Writeback data journaling modes)
Endian and Architecture Neutral (x86, x86_64, ia64 and ppc64)
Buffered, Direct, Asynchronous, Splice and Memory Mapped I/Os
In-built Clusterstack with a Distributed Lock Manager
Cluster-aware Tools (mkfs, fsck, tunefs, etc.)

   Довольно подробное руководство по версии 1.6 в формате PDF можно найти на сайте Oracle (ссылка).

   Т.к. это полноценная кластерная ФС, расчитанная на одновременное обращение множества нод к одним  и тем же данным, она требует выделенное хранилище. Конечно, идеальным в таком случае является какое-либо аппаратное решение, но его стоимость...

   В общем, для экспериментов было создано простейшее зеркало на DRBD в режиме Active/Active. Помимо естественных недостатков такого решения, из-за самой архитектуры DRBD выходило еще одно ограничение - количество узлов кластера - только два. Есть, правда, способы каскадного наложения DRBD, позволяющие увеличить число нод кластера, но это уже совсем другая тема... 

   Итак, результат - две одновременно активных ноды кластера, с подмонтированным общим ресурсом. Т.е. можно запускать одновременно на обоих нодах приложения, поддерживающие работу с разделяемыми данными, например, IMAP/POP3 почтовый сервер dovecot.

   Для уменьшения времени репликации и во избежание лишней залочки файлов, желательно монтирование ФС с параметром noatime.

   К сожалению, проявилась одна особенность реализации OCFS2 - при тестовых выключениях вторая нода может на минуту-полторы потерять подмонтированную ФС. Происходит это, видимо, из-за того, что, хотя ноды и являются "автономными", без выделенного сервера управления кластером, одна из них все же объявляется мастером репликации/залочек/восстановления/журнала. Без этого, увы, кластерную файловую систему не построишь - при множественном одновременном доступе к одним и тем же данным, кто-то должен хранить глобальную информацию об открытых/заблокированных файлах/блоках данных. Соответственно,  если выключенная нода являлась т.н. recovery master, происходит перенос этой роли на оставшуюся ноду, что занимает время. При этом, во избежание повреждения данных, ФС на оставшейся ноде отмонтируется. По окончании процесса, ФС монтируется снова (средствами corosync).

   Таким образом,  полная отказоустойчивость может не получиться, т.к. при падении  "мастер"-ноды, на которой были роли управления ФС, вторая так же становится недоступной (точнее, кластерная ФС на ней) на время прохождения тайм-аутов определения присутствия второй ноды, переноса необходимых ролей и монтирования ФС. Если из строя вышла "слейв"-нода, ФС остается доступной без перерывов.

   Итог

   В общем, работа системы понравилась. Замедление дисковых операций, разумеется, присутствует, но не является драматичным. Однако, из-за возможного перерыва в работе при падении мастер-ноды, пока остается открытым вопрос о преимуществах данного решения перед обычным мастер-слейв DRBD с подключением мастер-ресурса на слейв ноду по NFS.