у нас есть распределенное приложение, которое использует большие объемы контента (все типы файлов). Есть несколько серверов, которым нужен доступ к контенту. Прямо сейчас контент хранится на каждом сервере избыточно. Но это становится некрасивым.
Мы хотим хранить контент в одном экземпляре хранилища с большими жесткими дисками. Затем мы хотим смонтировать файловую систему этого экземпляра хранилища с каждого из наших серверов.
Я думал об использовании NFS, но схема безопасности мне не подходит. Сейчас я смотрю на Samba, но не уверен, что это правильный выбор. Все серверы работают под управлением Linux, а основное назначение Samba - среда Windows / Linux. Что делает Samba интересным для меня, так это безопасность на уровне пользователя.
Помимо безопасности, еще одним важным требованием является производительность. Нашим серверам нужен быстрый доступ к контенту. Это максимально быстро по локальной сети.
Samba - хороший выбор? Какие еще есть варианты? А как насчет WebDAV?
РЕДАКТИРОВАТЬ: Что мне нужно сделать: у нас есть разное количество серверов, которым требуется доступ к растущему количеству файлов. Ожидаем, что станет несколько ТБ. Мы называем эти файлы «контентом». Все серверы должны использовать одну и ту же версию контента. Серверы нужны одновременный доступ только для чтения к содержанию. Контент обновляется относительно редко. Примерно от одного раза в неделю до одного раза в месяц, но, вероятно, станет намного чаще. Прямо сейчас можно было бы синхронизировать контент на каждом сервере, но в ближайшем будущем это станет проблемой. Обновление должно быть достаточно быстрым. Мы думаем, что было бы удобно обновлять / синхронизировать контент только на одном сервере (сервере хранения) и позволить всем остальным серверам монтировать контент как удаленную файловую систему.
Всего наилучшего
Янв
Samba почти наверняка сделает то, что вы хотите, и с довольно разумной производительностью. Он должен иметь необходимые элементы управления безопасностью для обработки любых вариантов использования, которые вы задумали (в вашем вопросе немного подробностей).
Трудно дать другие рекомендации, поскольку вы не даете действительно хорошего описания того, что вам нужно делать, и каковы ваши ограничения. WebDAV, вероятно, бесполезен; это ничего лайк файловая система POSIX, и если вы думаете, что вам нужна невероятно высокая производительность, то вы, вероятно, захотите что-то, что будет работать как полная файловая система (произвольные поиски и тому подобное), что будет болезненно для WebDAV.
Вы также не говорили о параллельном доступе к отдельным файлам, который сильно влияет на ваше возможное пространство решений. Если только один клиент обращается к данному файлу одновременно, и особенно если только один клиент будет Когда-либо обновлять данный файл, то не обязательно отказываться от решений для периодической синхронизации - они могут хорошо выполнять свою работу в правильных условиях.
Наконец, если он в основном (или полностью) только для чтения, подумайте о том, чтобы сделать доступ к вашим данным более высокоуровневым. Вместо того, чтобы думать, что ты иметь Чтобы иметь файлы, почему бы не подумать о полезных абстракциях для конкретных приложений? Типичным примером этого является скромная база данных SQL - вместо того, чтобы хранить данные в плоских файлах и копаться в них с помощью специального кода, некоторые умные комья пришли к идее более специализированного механизма хранения и необходимого словоблудия для интеллектуального доступа к нему. Он не такой гибкий, как файловая система, но (в своей узкой нише) это проклятый зрение быстрее. Может быть, проявив немного воображения, вы сможете придумать аналогичную абстракцию для своих данных, которая избавит вас от многих проблем?
NFS - Ваш экземпляр хранилища - это сервер NFS. То, что вы называете своими серверами, которые хотят смонтировать файловые системы NFS вне экземпляра хранилища, - это ваши клиенты NFS. Ваш экземпляр хранилища NFS должен знать IP-адреса ваших клиентов NFS, то есть ваших серверов, но вы уже знаете эти адреса. Для этих адресов вы можете разрешить целую подсеть одновременно, и вы, по крайней мере, будете знать, в какой подсети живут ваши серверы. Обратите внимание, что такие компании, как NetApp, продают именно такие вещи, и они работают очень хорошо.
Samba - Мой опыт немного отличается от того, как вы хотите ее использовать (например, пользователь предоставляет комбинации имени пользователя и пароля при подключении общих ресурсов), поэтому я не могу комментировать ваше предлагаемое использование.
Оба должны работать нормально, и оба должны без проблем насыщать интерфейс Ethernet 1 Гб. Я подозреваю, что это будет ваша верхняя граница с точки зрения того, сколько данных вы можете получить из своего экземпляра хранилища. Вы, конечно, можете использовать несколько интерфейсов Ethernet, чтобы обойти это, и тогда вы, вероятно, будете ограничены тем, насколько быстро вы сможете перемещать данные с того, что вы когда-либо покупаете для дисков.
Я думаю, что один из ключевых моментов, который вам нужно знать перед тем, как начать, это то, сколько данных каждый из ваших серверов должен читать в секунду? Затем вам нужно знать, какое максимальное количество серверов у вас будет. Предлагаемое вами централизованное решение предоставляет столько данных в секунду? Прямо сейчас вы решили эту проблему, сделав каждый сервер независимым и имея копию данных.
Консолидация на сервере может облегчить жизнь, но как обеспечить доступность дублирующих сетевых карт? Рейд? Иногда репликация может быть хорошей вещью.
Раз уж мы говорим о взаимодействии сервер-сервер, является ли безопасность на уровне пользователя таким большим требованием? Конечно, аутентификация пользователей в NFS является слабой, но как насчет использования аутентификации NFS + на более низком уровне в сети, таком как IPSEC? Или общая файловая система поверх iSCSI поверх VPN?
В зависимости от схемы доступа и если доступность локального хранилища не является проблемой, самым быстрым решением может быть что-то вроде AFS - где вы фактически получаете очень большой локальный кеш, который имеет дополнительное преимущество, заключающееся в том, что его можно использовать, когда сервер выходит из строя.
Что касается ваших конкретных требований к производительности и скорости, SSH подойдет идеально. SSH использует протокол sftp для обмена файлами и использует собственный контроль разрешений пользователей Linux. Вы можете использовать компьютерную систему с большими объемами хранения (возможно, с аппаратным или программным RAID или шифрованием, файловая система EXT4 идеальна, поскольку работает волшебно быстро) в качестве выделенного подключенного хранилища (DAS). Настройте на нем SSH-сервер и определите различные уровни доступа пользователей к вашим данным точно так же, как вы это делаете на каждой компьютерной системе, которая у вас есть. Тогда доступ к контенту на этом сервере так же прост, как доступ к локальным данным. Настройка связок ключей на каждом компьютере необходима для обеспечения безопасности аутентификации на сервере.