Веб-приложение должно быть независимым от основного хранилища, если мы говорим о хранилище файлов;Разделение проблем.
(S) FTP (S), с другой стороны, не является методом хранения. Это протокол связи. Это не мешает вам иметь общее хранилище. См. Выше.
ZFS не включает в себя возможность общего хранилища, поэтому вы в основном выбираете следующие варианты:
- Какая базовая файловая система?
- Хочу ли я предложить дополнительный режим доступа через (S) FTP (S)?
- Как сделать мою файловую систему доступной на нескольких серверах? GlusterFS, CIFS или NFS?
Итак, давайте разберемся с этим.
Файловая система
Я знаю, что ZFS интригует, но вот что: xfs дляпример уже имеет максимальный размер файловой системы 8 exbibytes минус один байт. Специалист термин для этого "s ... нагрузка". Чтобы дать вам связь: в Библиотеке конгресса хранится около 20 ТБ цифровых носителей - и она поместится примерно в 400 000 раз. Даже хороший старый ext4 может содержать 50 тыс. Локов. И если вы храните столько данных, ваша FS - ваша самая маленькая проблема. Построить следующую пару электростанций, чтобы ваши вещи продолжали работать, по-видимому.
Суть Приятно думать, но используйте все, что вам удобно. Лично я использую xfs (в LVM) практически для всего.
Дополнительные методы доступа
Конечно, почему бы и нет? Помимо кошмара безопасности (повышение привилегий, кто-нибудь?). А ProFTPd с встроенной кофемашиной и кухонной раковиной - это последний FTP-сервер, который я бы использовал для чего угодно. У него огромная кодовая база, которая позволяет случайно вводить уязвимости .
В основном все сводится к навыкам, присутствующим в проекте. Можете ли вы, ребята, правильно укрепить систему и FTP-сервер и контролировать это для инцидентов безопасности? Если ваш ответ не является уверенным "Да, конечно, много с опытом!"Вы должны минимизировать поверхность атаки, которую вы представляете.
Суть Не делайте этого, если вы действительно не знаете, что делаете. И если вам нужно спросить, вы, вероятно, нет. Без обид, просто констатация фактов.
Общая файловая система
Лично я сделал ... менее совершенный опыт работы с GlusterFS. Репликация имеет довольно много требований, когда речь идет о задержке в сети и прочем. В двух словах: если мы говорим о нескольких зонах доступности, скажем, EMEA, APAC и NCSA, это почти невозможно. Вы застряли бы в георепликации , что не идеально для описанного вами варианта использования.
С другой стороны, у NFS и CIFS есть проблема, что вообще нет репликации,и всем клиентам необходим доступ к одному и тому же экземпляру сервера, чтобы получить доступ к данным - вряд ли это хорошая идея, если вы считаете, что вам нужен базовый ZFS, чтобы ладить.
Gist Общие файловые системы наГлобальный масштаб с половинными приличными задержками репликации и временем доступа составляет очень трудно сделать и может стоить очень дорого.
Ха-ха, Smartypants, так что бы вы предложили?
Масштаб. Медленно. В начале вы должны быть в состоянии ладить с простым репозиторием на основе FS для ваших файлов. А затем проверьте различные другие средства для крупномасштабного общего хранилища и перейдите на него.
Повернувшись к реализации, я бы даже пошел дальше, вы должны сделать свое хранилище интерфейсом:
// Storer takes the source and stores its contents under path for further reading via
// Retriever.
type Storer interface {
StreamTo(path string, source io.Reader) (err error)
}
// Retriever takes a path and streams the file it has stored under path to w.
type Retriever interface {
StreamFrom(path string, w io.Writer) (err error)
}
// Repository is a composite interface. It requires a
// repository to accept andf provide streams of files
type Repository interface {
Storer
Retriever
Close() error
}
Теперь вы можете довольно легко реализовать различные методы хранения:
// FileStore represents a filesystem based file Repository.
type FileStore struct {
basepath string
}
// StreamFrom statisfies the Retriever interface.
func (s *FileStore) StreamFrom(path string, w io.Writer) (err error) {
f, err := os.OpenFile(filepath.Join(s.basepath, path), os.O_RDONLY|os.O_EXCL, 0640)
if err != nil {
return handleErr(path, err)
}
defer f.Close()
_, err = io.Copy(w, f)
return err
}
Лично я думаю, что это был бы отличный вариант использования для GridFS , который, несмотря на его название, не являетсяфайловая система, но особенность MongoDB. Что касается причин:
- MongoDB поставляется с концепцией, называемой наборами реплик, для обеспечения доступности с прозрачным автоматическим переключением при сбое между серверами
- Он поставляется с довольно простым механизмом автоматического разделения данных, называемым сегментированным кластером
- Он поставляется с неопределенным числом шлюзов доступа, называемых
mongos маршрутизаторами запросов для доступа к вашим защищенным данным. - Для клиента, кроме URL-адреса соединения, все это прозрачно. Таким образом, не имеет значения (почти, кроме предпочтений чтения и записи ), является ли его серверная часть хранилища отдельным сервером или глобально реплицированным сегментированным кластером с 600 узлами.
- Если все сделано правильно, нет ни одной точки отказа, вы можете реплицировать по зонам доступности, сохраняя «горячие» данные рядом с соответствующими пользователями.
Я создал репозиторий на GitHub , который содержит пример предложения интерфейса и реализует репозиторий на основе файловой системы, а также репозиторий MongoDB. Возможно, вы захотите взглянуть на это. На данный момент не хватает кеширования. Если вы хотите, чтобы это было реализовано, откройте вопрос там.