В основном я ищу "multipath nfs". Мне нужна классическая сетевая файловая система, но с несколькими серверами, установленными на клиентах к одной точке монтирования, и она должна обрабатывать сбой сервера с прозрачным переключением между серверами без каких-либо задержек. Балансировка нагрузки и производительность не являются проблемой. Синхронизация между серверами может выполняться вне этого решения, она может быть даже доступна только для чтения для обычных клиентов через этот интерфейс.
Я предпочитаю избегать GFS, Lustre, AFS, IP round robin и подобных «сложных» вещей.
Вы знаете простое решение этой проблемы?
Уловка будет заключаться в том, чтобы получить клиенты для поддержки такого рода нестандартных операций. Тем не менее, вы можете сделать сервер высокодоступный. Поместите два сервера NFS в кластер Heartbeat, и у вас, по крайней мере, будет аварийное переключение, хотя блокировка не передается. У вас будет некоторые время простоя, поскольку кластер определяет, что все не так, и инициирует аварийное переключение, но оно должно быть очень быстрым; менее 30 секунд.
РЕДАКТИРОВАТЬ: Я только что увидел, что вы хотите избежать Lustre. GlusterFS (для меня) находится в другом месте, поскольку не требует возиться с ядром. Это чисто пользовательское пространство.
GlusterFS делает это. Это реализация в пользовательском пространстве, поэтому она немного медленнее. Но лично я считаю, что в большинстве сетевых файловых систем узким местом является сеть.
Помимо личных вещей:
С кластером GlusterFS вы монтируете любой узлов. Если этот узел затем выходит из строя, реализация клиента достаточно умен, чтобы обнаружить это, и продолжает работать с другим узлом в кластере.
Я не совсем уверен в совместимости с POSIX, поэтому вы, возможно, не захотите запускать PostgreSQL / MySQL / Oracle из этого. Но обслуживание статических файлов из GlusterFS - это прекрасно. Обратите внимание: обслуживание статических файлов не обязательно означает, что это должен быть веб-сервер. :)
Обычно вы спрашиваете, для чего была разработана сеть хранения данных (SAN).
Ваше решение может использовать OCFS2: http://www.oracle.com/us/technologies/linux/025995.htm
Вы можете развернуть iSCSI LUN, совместно используемые в любом количестве систем, и настроить эти LUN с помощью OCFS2. Вы получите разделяемую файловую систему независимо от того, используете ли вы ее для кластеризации или для других целей, которые на самом деле не актуальны. С NFS вы ограничены в своих возможностях. Однако с помощью NFS вы можете повысить доступность, управляя избыточностью на сетевом уровне и развертывая агрегацию каналов в сочетании с межстековым эфирным каналом. Конечно, вы связаны одним IP-адресом с NFS, но с агрегацией на обоих концах теоретически вы можете получить довольно избыточное решение. Многие из наших клиентов в Nexenta используют подобные решения. Ясно, что вы можете сходить с ума и создать несколько агрегатов для повышения общей пропускной способности, и вы можете использовать решения, аналогичные IPMP, что мы предлагаем в наших системах NexentaStor.
Честно говоря, вы не найдете «простого» решения, потому что это не «простая» проблема. При этом для надежности и простоты наименее худший вариант, который я нашел, - это NFS поверх DRBD. Это все еще непросто, но намного лучше, чем GFS / OCFS2 / Lustre. Учитывая, что у вас уже есть эквивалент DRBD с вашим SAN (при условии, что вы хотите его использовать), контрольный сигнал NFS + действительно является тем местом, где вы собираетесь закончить, если хотите аварийное переключение.