Мы сталкиваемся с проблемой проектирования, когда нам необходимо настроить решение для хранения со следующими свойствами:

То, что нам нужно

1. HA
   • масштабируемое хранилище данных
   • автономная / отключенная операция на клиенте для учета отключений сети
2. кроссплатформенный доступ
   • доступ на стороне клиента, конечно, из Windows (возможно, XP и выше), возможно, из Linux
   • серверная часть интегрируется с AD/LDAP (управление разрешениями (управление пользователями / группами, ...))
3. должен работать достаточно хорошо по медленным WAN-каналам

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

Эти два года постов в блоге подводят итог впечатления, которое у меня сложилось за последние пару дней исследований, что существует множество текущих проектов übercool, реализующих кластерные (не Windows) решения с поддержкой петабайтных хранилищ больших двоичных объектов, но есть ни один, который поддерживает отключенную работу красиво и естественно, но я надеюсь, что мы упустили очевидное решение.

Что мы пробовали

OpenAFS

Мы решили, что нам нужна распределенная сетевая файловая система с локальным кешем, и протестировали OpenAFS (которая, как единственная в настоящее время "стабильная" DFS, поддерживающая отключенную операцию, казалось, была подходящей) в течение недели, но с этим есть несколько проблем:

• это настоящая боль в настройке
• нет официальных пакетов RHEL/CentOS
• пакет текущей стабильной версии 1.6.5.1 от elrepo случайным образом паникует в ядре при новой установке, это абсолютный запрет
• Поддержка Windows (включая необходимые пакеты Kerberos) мистическая. Текущий клиент для ветки 1.6 не работает в Windows 8, текущий клиент для 1.7 работает, но он просто случайно падает. После этого опыта мы даже не потрудились провести тестирование на XP и Windows 7. Достаточно сказать, что мы не смогли заставить его работать, и вся установка была настолько нестабильной и сложной для установки, что просто не использовалась для производства.

Самба + Унисон

Поскольку OpenAFS была полной катастрофой, и никакая другая DFS, похоже, не поддерживала отключенную работу, мы пошли на более простую идею, которая синхронизировала бы файлы с сервером Samba с использованием Unison. Это имеет следующие преимущества:

1. Samba интегрируется с AD; это боль, но можно сделать.
2. Samba решает проблему удаленного доступа к хранилищу из Windows, но вводит другую функцию SPOF и не решает реальную проблему хранилища. Вероятно, мы могли бы прикрепить любую кластеризованную FS под Samba, но это означает, что нам нужна установка HA Samba поверх этой, чтобы поддерживать HA, что, вероятно, добавляет много дополнительной сложности. Я смутно помню, как пытался реализовать избыточность в Samba раньше, и я не мог тихо переключаться между серверами.
3. Даже в режиме онлайн вы работаете с локальными файлами, что приведет к большему количеству конфликтов, чем было бы необходимо, если бы локальный кэш был затронут только при отключении
4. Это не автоматически. Мы не можем ожидать, что пользователи будут вручную синхронизировать свои файлы с помощью (функционального, но не очень приятного) графического интерфейса GTK на регулярной основе. Я попытался полуавтоматизировать процесс с помощью планировщика задач Windows, но вы не можете сделать это удовлетворительным образом.
5. Вдобавок ко всему, работа Unison делает синхронизацию с Samba дорогостоящей операцией, поэтому я боюсь, что она просто не очень хорошо масштабируется или вообще не масштабируется.

Samba + "Автономные файлы"

После этого мы немного расстроились и дали шанс "автономным файлам" Windows. Мы полагали, что наличие чего-то, встроенного в ОС, уменьшит административные усилия, поможет обвинить кого-то другого в том, что оно не работает должным образом, и должно работать, поскольку люди используют это годами. Правильно? Неправильно. Мы действительно хотели, чтобы это сработало, но это не так. 30 минут копирования файлов и отключения сетевых кабелей / отключения сетевых интерфейсов оставили нам

• (молчать! в проводнике Windows есть только крошечное уведомление в строке состояния, которое даже не открывает Центр синхронизации, если вы щелкнете по нему!) для удаления файлов на сервере (!) и
• конфликты, которые не должны быть даже конфликтами.

В конце у нас была одна успешная синхронизация крошечного текстового файла, все остальное просто ужасно взорвалось.

Помимо этого, есть другие проблемы:

• Microsoft признает, что "автономные файлы" в Windows XP не могут справиться с "большими файлами" и, следовательно, не кэшируют / не синхронизируют их вообще, что может означать, что эти файлы станут недоступными в случае разрыва соединения
• В Windows 7 эта функция доступна только в выпусках Professional/Ultimate/Enterprise.

Резюме

Если нет другой отказоустойчивой DFS, которая изначально поддерживает Windows, я предполагаю, что размещение кластера HA Samba поверх чего-то вроде GlusterFS/Luster /whatnot - единственный вариант, но я надеюсь, что здесь я ошибаюсь. Как другие компании разрешают отказоустойчивый сетевой доступ к избыточному хранилищу в гетерогенной среде с Windows?