Какой сетевой протокол обмена файлами имеет лучшую производительность и надежность? [закрыто]

У нас есть настройка с несколькими веб-серверами с балансировкой нагрузки. Мы хотим иметь какое-то сетевое общее хранилище, к которому могут обращаться все веб-серверы. Он будет использоваться как место для хранения файлов, загруженных пользователями. Все работает под управлением Linux.

Должны ли мы использовать NFS, CIFS, SMB, fuse + sftp, fuse + ftp? Есть так много вариантов для сетевых протоколов обмена файлами, что очень трудно выбрать один. Мы просто хотим постоянно смонтировать этот общий ресурс на нескольких машинах. Функции безопасности не так важны, потому что сеть не будет доступна из других источников, кроме серверов, на которых она установлена. Мы просто хотим, чтобы он работал надежно и быстро.

Какой из них мы должны использовать?

Я голосую за NFS.

В NFSv4.1 добавлена ​​возможность Parallel NFS pNFS, которая делает возможным параллельный доступ к данным. Мне интересно, какие клиенты используют хранилище, если только в стиле Unix, тогда я бы остановился на NFS, основываясь на показателях производительности.

Краткий ответ - использование NFS. Согласно этой перестрелке и моему собственному опыту, это быстрее.

Но у вас есть больше вариантов! Вы должны рассмотреть кластерную FS как GFS, которая является файловой системой, к которой могут одновременно обращаться несколько компьютеров. По сути, вы разделяете блочное устройство через iSCSI, который является файловой системой GFS. Все клиенты (инициаторы на языке iSCSI) могут читать и писать в него. Redhat имеет официальный документ . Вы также можете использовать кластер Oracle OCFS для управления тем же.

Редхат хорошо справляется со списком плюсов и минусов кластера FS против NFS. В основном, если вы хотите масштабировать пространство, GFS, вероятно, стоит усилий. Кроме того, в примере GFS в качестве примера используется сеть Fibre Channel SAN, но это также может быть RAID, DAS или iSCSI SAN.

Наконец, обязательно изучите Jumbo Frames, и если целостность данных имеет решающее значение, используйте контрольную сумму CRC32, если вы используете iSCSI с Jumbo Frames.

У нас есть веб-кластер, ограничивающий нагрузку на 2 сервера. Мы попробовали следующие методы для синхронизации контента между серверами:

• Локальные диски на каждом сервере синхронизируются с RSYNC каждые 10 минут
• Центральный ресурс CIFS (SAMBA) для обоих серверов
• Центральный ресурс NFS для обоих серверов
• Общий диск SAN под управлением OCFS2 смонтировал оба сервера

Решение RSYNC было самым простым, но потребовалось 10 минут, чтобы изменения проявились, и RSYNC оказал такую ​​большую нагрузку на серверы, что пришлось задушить его с помощью специального сценария, чтобы останавливать его каждую секунду. Мы также были ограничены только записью на исходный диск.

Самым быстродействующим общим диском был кластерный диск OCFS2 вплоть до тех пор, пока он не сошел с ума и не сломал кластер. Мы не смогли поддерживать стабильность с OCFS2. Как только несколько серверов получают доступ к одним и тем же файлам, нагрузка поднимается через крышу и серверы начинают перезагружаться. Это может быть провал тренировки с нашей стороны.

Следующим лучшим был NFS . Это было чрезвычайно стабильно и отказоустойчиво. Это наша текущая настройка.

У SMB (CIFS) были некоторые проблемы с блокировкой. В частности, изменения в файлах на сервере SMB не были замечены веб-серверами. SMB также склонен зависать при сбое на SMB-сервере.

Мы пришли к выводу, что OCFS2 обладает наибольшим потенциалом, но требует много анализа, прежде чем использовать его в производстве. Если вы хотите что-то простое и надежное, я бы порекомендовал кластер NFS-сервера с Heartbeat для отработки отказа.

Я предлагаю вам POHMELFS - он создан русским программистом Евгением Поляковым и действительно очень быстрый.

С точки зрения надежности и безопасности, вероятно, CIFS (он же Samba), но NFS «кажется» гораздо более легковесным, и при тщательной настройке возможно не полностью предоставить ваши ценные данные любой другой машине в сети ;-)

Никаких оскорблений в FUSE, но все равно кажется ... свежим, если вы понимаете, о чем я. Я не знаю, доверяю ли я этому еще, но это может быть просто старый туман, но старый фугайизм иногда оправдан, когда дело доходит до ценных корпоративных данных.

Если вы хотите постоянно смонтировать один общий ресурс на нескольких машинах, и вы можете подыграть некоторым странностям (в основном, проблемам с UID / GID), тогда используйте NFS. Я им пользуюсь и уже много лет.

NFS. Это проверено и верно, и вы можете иметь твердую установку. Производительность GFS, как правило, ужасна, особенно в файловых системах с большим количеством маленьких файлов. Я не использовал OCFS, но я, как правило, не одобряю концепцию кластерной файловой системы. Тогда есть блеск, но это еще одна банка червей ...

Я бы посоветовал против NFS. Проще говоря - у нас была ферма веб-серверов, где JBoss, Apache, Tomcat и Oracle использовали общие ресурсы NFS для общих файлов конфигурации и ведения журналов.

Когда общий ресурс NFS исчез (по общему признанию, редкий случай), все это просто рухнуло (действительно, предсказуемо, и я посоветовал «devlopers» против этого ярлыка времени конфигурации).

Кажется, есть проблема с версией NFS, которую мы использовали, что, если цель исчезла во время записи, клиент упал бы в бесконечный цикл ожидания, ожидая возвращения цели NFS. Даже если поле NFS подключено - цикл все равно не закончился.

Мы использовали смесь RHEL 3,4,5. Хранилище было на RHEL4, серверы были на RHEL5, сеть хранения данных была отдельной локальной сетью и не работала на vlans.

Если есть интерфейс с балансировкой нагрузки, проверяющий единое хранилище - не станет ли это узким местом вашей системы?

Рассматривали ли вы подключение iSCSI только для чтения к вашему хранилищу с помощью сценария, управляемого событиями, для перемещения загруженного файла в хранилище через ftp / scp при загрузке файла?

Единственный раз, когда я реализовал успешное централизованное хранилище для нескольких головок чтения, находился в массиве хранения EMC ... Все другие экономически эффективные попытки имели свои недостатки.

Считается GFS? GFS является кластерной файловой системой и, по моему опыту, довольно надежна. Может иметь более одного журнала, хорошо масштабируется

Но вам нужно будет установить некоторые кластерные сервисы, а GFS точно не знает, насколько быстро они работают. Ото, это всегда было достаточно быстро для меня, но мммм.

Вы бы сошли с ума, рассматривая распределенную ФС, такую ​​как GFS, а iSCSI - это избыточно.

Если вы хотите просто пойти с NFS. Это просто и быстро, и с мягкими креплениями довольно прочными. Также рассмотрите возможность отключения всех ненужных блокировок. У меня есть рабочие столы Linux, которые берут все свои домашние каталоги и приложения из NFS, все работает нормально.

Если вам нужна невероятная скорость, используйте Luster, который значительно проще, чем GFS, и который очень похож на RAID NFS. Мы используем блеск для наших кластеров.

Возможно, я немного опоздал. Мы используем хранилище Dell MD3220, которое имеет кластерный двухпортовый порт. У нашего устройства 2 контроллера, один из которых отключается, второй будет работать до тех пор, пока мы не исправим эту проблему. Поскольку жесткие диски, вентиляторы, блоки питания и контроллеры - все это горячая замена, мы заменяем детали по частям. По формату мы используем NFS.

Если у вас уже есть веб-серверы повсюду, и вы хорошо умеете их запускать, почему бы не рассмотреть WebDAV?

Простой ответ +1 для NFS. У меня есть NFS-ресурсы, которые годами монтировались без проблем.

Если вам нужна сверхнадежность, рассмотрите возможность включения DRBD в микс и для распределенной, отказоустойчивой файловой системы NFS.

Единственный другой вариант (с которым я знаком) - это iSCSI, но при настройке может возникнуть проблема ...

У вас есть куча вариантов, с различными затратами. Совместное использование SAN с FC, iSCSI или одним из последних дополнений. В любом случае их установка может быть дорогостоящей, и вам все равно нужно запускать файловую систему с поддержкой кластеров. Кластерные файловые системы - это мир боли. Для любой надежды на успех вам нужны отдельные высокоскоростные сети с низкой задержкой для кластерной связи и передачи данных. Даже при этом вы можете получить глюки, которые приведут к тому, что узел будет огражден и убит кольцом.

Единственная кластерная файловая система, с которой я столкнулся, которая работает без проблем, - это VMFS. Но это настолько специализировано, что было бы бесполезно, даже если бы оно было доступно для общего пользования.

NFS, вероятно, способ для вашей настройки. Если вы беспокоитесь о спокойствии, вам нужно получить подходящую кластерную коробку NFS. Вы можете выполнить настройку доморощенного напитка, но столкнетесь с вышеуказанной проблемой. Лучшая ставка (если у вас есть деньги) - это кластеризованные файлеры NetApp. Это дорогой вариант, но кластеризация на самом деле работает без каких-либо хлопот. Мало того, они очень быстрые.

Я хотел бы повторить предупреждение, которое некоторые высказывают против NFS - хотя NFS, вероятно, является лучшим выбором (как это ни странно звучит).

У меня был клиент NFS, который мне пришлось отключить от сети переменного тока, чтобы отключить, потому что сервер NFS исчез, и клиент отказался (в ядре) разблокировать или завершить работу, потому что сервер NFS пропал.

Чтобы сделать это правильно, я бы настаивал на NFSv4, придерживался TCP-соединений, использовал большие кадры и использовал кластер NFS. Вы не можете позволить, чтобы ваш NFS-сервер исчез.

GFS - это серьезно черный вуду. Объем работы, необходимый для работы простого кластера с двумя клиентами, поразителен по сравнению с альтернативами. OCFS2 намного проще в развертывании, но очень требователен, когда дело касается версий модулей ядра на всех подключенных серверах - и это только начало.

Если вам действительно не нужен низкоуровневый доступ, предлагаемый файловой системой кластера, NFS или CIFS, вероятно, все, что вам нужно.

На большой ферме серверов у нас было несколько миллионов созданных пользователями HTML-страниц. NFS не работал так хорошо, поэтому мы поместили их в таблицу mysql. Затраты по сравнению с обходом дерева каталогов были примерно одинаковыми.

Я использовал SFTP, и он отлично работал для моих целей - NFS был моим первым средством, но забавность идентификаторов пользователей / групп заставила меня бросить его довольно быстро.

Просто настройте publickey auth, и вы будете в основном настроены. Для шифрования SSH может быть несколько более высокая загрузка ЦП, но, с другой стороны, у меня никогда не возникало проблем с повреждением данных.

FTP вполне может удовлетворить ваши цели, так как он более легкий. Предположительно, вы хотите, чтобы ваши веб-серверы выполняли веб-обслуживание, а не работу с ssh.