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

Что нам нужно

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, но это означает, что нам нужна настройка Samba высокой доступности для поддержки высокой доступности, что, вероятно, добавляет много дополнительных сложностей. Я смутно помню, как раньше пытался реализовать избыточность с помощью 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 / Lustre / еще чего-то - единственный вариант, но я надеюсь, что здесь я ошибаюсь. Как другие компании обеспечивают отказоустойчивый сетевой доступ к избыточному хранилищу в гетерогенной среде с Windows?