У нас есть настройка с несколькими веб-серверами с балансировкой нагрузки. Мы хотим иметь некое сетевое общее хранилище, к которому смогут обращаться все веб-серверы. Оно будет использоваться как место для хранения файлов, загруженных пользователями. Все работает под управлением Linux.
Должны ли мы использовать NFS, CIFS, SMB, fuse+sftp, fuse+ftp? Существует так много вариантов сетевых протоколов обмена файлами, что очень трудно выбрать один. По сути, мы просто хотим постоянно монтировать один общий ресурс на нескольких машинах. Функции безопасности не так важны, поскольку он не будет доступен по сети ниоткуда, кроме как с монтирующих его серверов. Мы просто хотим, чтобы он работал надежно и быстро.
Какой из них нам следует использовать?
Ответ 1
Быстрый ответ — используйте NFS. Согласно моему собственному опыту, он быстрее и надежнее.
Вам следует рассмотреть кластерную FS, например GFS, которая представляет собой файловую систему, доступную нескольким компьютерам одновременно. По сути, вы совместно используете блочное устройство через iSCSI, которое является файловой системой GFS. Все клиенты (инициаторы на языке iSCSI) могут читать и записывать в нее. В Redhat есть технический документ. Вы также можете использовать кластерную ФС OCFS от oracle для управления тем же самым.
В документе Redhat доступно перечислены плюсы и минусы кластерной FS по сравнению с NFS. В основном, если вы хотите иметь большой простор для масштабирования, GFS, вероятно, стоит того. Кроме того, в примере GFS используется сеть Fibre Channel SAN, но это может быть и сеть RAID, DAS или iSCSI SAN.
Наконец, обязательно изучите Jumbo Frames, и, если целостность данных критична, используйте контрольное суммирование CRC32, если вы используете iSCSI с Jumbo Frames.
Ответ 2
У нас есть веб-кластер с 2 серверами, обеспечивающий балансирование нагрузки. Мы пробовали следующие методы синхронизации содержимого между серверами:
Локальные диски на каждом сервере синхронизируются с помощью RSYNC каждые 10 минут.
Центральный ресурс CIFS (SAMBA) на обоих серверах.
Центральный ресурс NFS на обоих серверах.
Общий диск SAN под управлением OCFS2, смонтированный на обоих серверах.
Решение с RSYNC было самым простым, но для появления изменений требовалось 10 минут, а RSYNC создавал настолько большую нагрузку на серверы, что нам пришлось пробрасывать его с помощью пользовательского скрипта, чтобы приостанавливать его каждую секунду. Мы также были ограничены возможностью записи только на исходный диск.
Самым быстродействующим общим диском был кластерный диск OCFS2 до тех пор, пока он не вышел из строя и не разрушил кластер. Нам не удалось сохранить стабильность с OCFS2. Как только более одного сервера обращаются к одним и тем же файлам, нагрузка возрастает до предела и серверы начинают перезагружаться.
Следующим лучшим был NFS. Она была чрезвычайно стабильной и отказоустойчивой. Это наша текущая установка.
SMB (CIFS) имел некоторые проблемы с блокировкой, в частности изменения файлов на сервере SMB не были видны веб-серверам. SMB также имел тенденцию зависать при отказе сервера SMB.
Мы пришли к выводу, что OCFS2 имеет наибольший потенциал, но требует большого анализа, прежде чем использовать его в производстве. Если вам нужно что-то простое и надежное, я бы рекомендовал кластер серверов NFS с Heartbeat для минимизации отказов сервера.
Ответ 3
С точки зрения надежности и безопасности, вероятно, CIFS (т. е. Samba), но NFS «кажется» гораздо более легким решением, и при тщательной настройке можно не полностью подвергать ценные данные воздействию каждой другой машины в сети ;-)
Если вы хотите постоянно монтировать один ресурс на нескольких машинах и вы можете смириться с некоторыми странностями (в основном с проблемами UID/GID), то используйте NFS. Я использую его уже много лет.
Ответ 4
Я бы не советовал использовать NFS. Проще говоря, у нас была ферма веб-серверов, где JBoss, Apache, Tomcat и Oracle использовали общие ресурсы NFS для общих конфигурационных файлов и протоколирования.
Похоже, что в версии NFS, которую мы использовали, была проблема: если цель исчезала во время записи, клиент попадал в бесконечный цикл ожидания, ожидая, пока цель NFS вернется. Даже если система NFS снова подключалась — цикл все равно не заканчивался.
Мы использовали смесь RHEL 3, 4, 5. Хранилище было на RHEL4, серверы были на RHEL5, сеть хранения была отдельным каналом и не работала на vlans.
Если есть фронтенд с балансировкой нагрузки, проверяющий одно хранилище — не будет ли это узким местом в вашей системе?
Рассматривали ли вы возможность подключения iSCSI к хранилищу только для чтения с управляемым событиями сценарием для перемещения загруженного файла в хранилище через ftp/scp, когда файл загружен?
Ответ 5
У вас есть несколько вариантов с различной стоимостью. Общая сеть SAN с FC, iSCSI или одним из последних дополнений. В любом случае они могут быть дорогими в настройке, и вам все равно придется запускать файловую систему с поддержкой кластеров. Кластерные файловые системы — это сплошная проблема. Чтобы надеяться на успех, вам нужны отдельные высокоскоростные сети с низкой задержкой для связи между кластером и данными. Даже при этом вы можете получить сбои, в результате которых узел будет постоянно недоступен.
Единственная файловая система кластера, с которой я сталкивался и которая работает без проблем, — это VMFS. Но она настолько специализированная, что даже если бы была доступна для общего использования, от нее не было бы никакого толку.
Вероятно, для вашей системы лучше всего подойдет NFS. Если вы беспокоитесь об отказоустойчивости, вам нужно приобрести подходящий кластерный NFS-бокс. Вы можете сделать домашнюю установку, но столкнетесь с вышеупомянутой проблемой. Лучший вариант (если у вас есть деньги) — кластеризованные филеры NetApp. Это дорогой вариант, но кластеризация действительно работает без каких-либо проблем. Мало того, они очень быстрые.
Linux