Я работаю над тем, чтобы все больше и больше сервисов не полагались на NFS, и мне интересно, что другие сделали с этой проблемой. Я знаю, что существуют распределенные файловые системы, и у меня есть некоторый опыт использования одной из них (mogilefs). Мне любопытно узнать, что другие люди использовали для отхода от NFS, особенно в отношении загружаемого пользователями контента. В частности, в веб-домене, если пользователь загружает контент на определенный веб-сервер - что вы делаете, чтобы сделать этот контент доступным в ваших кластерах? Я рассмотрел rsync с остальными машинами в кластере или просто с одним сервером содержимого, но мне любопытно, что другие сделали для решения этой проблемы.
Базы данных (традиционный SQL или NoSQL, например MongoDB) являются обычным решением этой проблемы.
Храните в базе данных контент, которым необходимо поделиться, и извлекайте его со своих интерфейсных веб-серверов.
Еще одно довольно распространенное решение - это SAN с общим доступом.
Хотя я не являюсь поклонником NFS, я скажу, что если он работает для вас, хорошо спроектирован и реализован и относительно безотказен, вы, вероятно, сможете продолжать использовать его почти бесконечно. Уйти от этого - здорово, но если нет веской причины, кроме "Фу, это NFS! "не убивайте себя, пытаясь избавиться от него ...
Если вы ищете кластерные файловые системы, существует множество открытых / закрытых решений. Просто назвать несколько: GFS, Блеск, GlusterFS, OCFS2, Veritas Cluster FS. Последний из них - коммерческое предприятие FS, но, по опыту, лучший.
Изменить: забыл упомянуть, что любой из них должен сопротивляться на устройстве SAN, совместно используемом всеми узлами кластера. Это также требование для Veritas CFS.
Я держусь подальше от какой-либо кластерной файловой системы, потратив год на попытки (и безуспешные) поддерживать работу GFS любым разумным способом. Это до смешного сложно и не работает под нагрузкой. Эта оценка распространяется по ассоциации на любую другую кластерную файловую систему, которую я изучал - количество движущихся частей, отсутствие эффективной документации и общая хрупкость всей хитрости Руба Голдберга заставляют каждую часть меня идти "аииеееее!"
С другой стороны, я добился большого успеха в использовании высокоуровневых абстракций, специфичных для приложения, - размышляя о том, что именно приложение потребности чтобы сделать с задействованными данными, а затем предоставить средства для этого. Довольно редко данные в веб-приложении на самом деле потребности полная абстракция файловой системы POSIX к данным в приложении; вместо этого можно использовать более функциональные глаголы. Который это уровень доступа между вашим веб-уровнем и данными.
Например, возьмите изображения. Если они у вас есть, вы, вероятно, сейчас засовываете их на свой NFS-сервер, а веб-серверы снимают их и манипулируют ими по мере необходимости. Но что вы на самом деле с ними делаете? Каждый из них идентифицируется уникальным ключом, вы сохраняете их (запрос PUT), извлекаете их (запрос GET), удаляете их (запрос DELETE) и, возможно, получаете их в разных размерах (запрос GET с несколькими параметры) - привет, для этого есть REST API. Не нравится ОТДЫХ? SOAP, XML-RPC, все, что плавает ваша лодка. Черт, вам даже не нужно использовать HTTP (хотя это естественный выбор для веб-приложений, потому что ваши GET-запросы могут быть отправлены непосредственно на файловые серверы). Какие бы средства изменения размера вы ни использовали (и кеширование этих изменений размера), можно обрабатывать на сервере хранения, что экономит пропускную способность сети, локализует логику, участвующую в работе с ними, и сохраняет хранимые изображения близко к вычислительной мощности, которая ими манипулирует. (ближе == быстрее == круто).
Масштабировать эти системы хранения обычно проще, чем масштабировать общий файловый сервер. Они не нуждаются в таком быстром масштабировании, потому что они более эффективны, но когда они нужны, достаточно просто определить алгоритм сегментирования и реализовать его в нескольких ключевых местах. Мне нравится простота определения того, сколько (например) изображений может поддерживать один сервер, а затем использовать id / capacity чтобы получить номер сервера, который будет использоваться для любого запроса изображения.
Это не первый раз, когда я пишу этот ответ; видеть этот вопрос для немного другого взгляда на этот вопрос.