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

<p>у нас есть настройка с несколькими веб-серверами с балансировкой нагрузки. мы хотим иметь какое-то сетевое общее хранилище, к которому могут обращаться все веб-серверы. он будет использоваться как место для хранения файлов, загруженных пользователями. все работает под управлением linux.</p><p>должны ли мы использовать nfs, cifs, smb, fuse + sftp, fuse + ftp? есть так много вариантов для сетевых протоколов обмена файлами, что очень трудно выбрать один. мы просто хотим постоянно смонтировать этот общий ресурс на нескольких машинах. функции безопасности не так важны, потому что сеть не будет доступна из других источников, кроме серверов, на которых она установлена. мы просто хотим, чтобы он работал надежно и быстро.</p><p>какой из них мы должны использовать?</p>

<p>я голосую за nfs.</p><p>в nfsv4.1 добавлена возможность parallel nfs pnfs, которая делает возможным параллельный доступ к данным. мне интересно, какие клиенты используют хранилище, если только unix-как, тогда я бы пошел на nfs на основе показателей производительности.</p>

<p>краткий ответ - использование nfs. согласно этому <a href="http://www.brighthub.com/computing/linux/articles/10839.aspx">перестрелке</a> и моему собственному опыту, это быстрее.</p><p>но у вас есть больше вариантов! вы должны рассмотреть кластер fs как gfs, который является файловой системой, к которой могут одновременно обращаться несколько компьютеров. по сути, вы разделяете блочное устройство через iscsi, который является файловой системой gfs. все клиенты (инициаторы в iscsi). может читать и писать в него. redhat имеет <a href="http://www.redhat.com/magazine/008jun05/features/gfs\_nfs/">технический документ</a> . вы также можете использовать кластер oracle fs <a href="http://oss.oracle.com/projects/ocfs/">[~ # ~] ocfs [~ #] ~]</a> чтобы управлять тем же.</p><p>redhat хорошо справляется со списком плюсов и минусов кластера fs против nfs. в основном, если вы хотите много места для масштабирования, gfs, вероятно, стоит усилий. кроме того, gfs в примере используется fibre channel san в качестве примера, но это может быть также raid, das или iscsi san.</p><p>наконец, обязательно изучите jumbo frames, и если целостность данных имеет решающее значение, используйте контрольную сумму crc32, если вы используете iscsi с jumbo frames.</p>

<p>у нас есть веб-кластер, ограничивающий нагрузку на 2 сервера. мы попробовали следующие методы для синхронизации контента между серверами:</p><ul> <li>локальные диски на каждом сервере синхронизируются с <strong> rsync </strong> каждые 10 минут</li> <li>центральный <strong>cifs (samba)</strong> общий доступ к обоим серверам</li> <li>центральный <strong> nfs </strong> общий ресурс для обоих серверов</li> <li>общий san работает <strong>ocfs2</strong> смонтировал оба сервера</li> </ul><p>решение <strong> rsync </strong> было самым простым, но потребовалось 10 минут, чтобы изменения проявились, и rsync оказал такую большую нагрузку на серверы, что пришлось настраивать его с помощью пользовательских сценарий, чтобы приостановить его каждую секунду. мы также были ограничены только записью на исходный диск.</p><p>самым быстродействующим общим диском был кластерный диск <strong>ocfs2</strong> вплоть до тех пор, пока он не сошел с ума и не сломал кластер. мы не смогли сохранить стабильность с ocfs2. как только несколько серверов получают доступ к одним и тем же файлам, нагрузка поднимается через крышу и серверы начинают перезагружаться. это может быть провал тренировки с нашей стороны.</p><p>следующим лучшим был <strong> nfs </strong>. это было чрезвычайно стабильно и отказоустойчиво. это наша текущая настройка.</p><p><strong>smb (cifs)</strong> возникли проблемы с блокировкой. в частности, изменения в файлах на сервере smb не были замечены веб-серверами. smb также имел тенденцию зависать при сбое из-за smb сервер</p><p><strong>наш вывод</strong> было то, что ocfs2 обладает наибольшим потенциалом, но требует много анализа, прежде чем использовать его в производстве. если вы хотите что-то простое и надежное, я бы порекомендовал кластер nfs-сервера с heartbeat для отработки отказа.</p>

<p>я предлагаю вам pohmelfs - он создан русским программистом евгением поляковым и очень, очень быстрый.</p>

<p>с точки зрения надежности и безопасности, вероятно, cifs (он же samba), но nfs "кажется" гораздо более легковесным, и при тщательной настройке возможно не полностью предоставить ваши ценные данные любой другой машине в сети ;-)</p><p>никаких оскорблений в fuse, но все равно кажется ... свежим, если вы понимаете, о чем я. я не знаю, доверяю ли я этому еще, но это может быть просто старый туман, но старый фугайизм иногда оправдан, когда дело доходит до ценных корпоративных данных.</p><p>если вы хотите постоянно смонтировать один общий ресурс на нескольких машинах, и вы можете подыграть некоторым странностям (в основном, проблемам с uid/gid), тогда используйте nfs. я им пользуюсь и уже много лет.</p>

<p>nfs. это проверено и верно, и вы можете иметь твердую установку. производительность gfs, как правило, ужасна, особенно в файловых системах с большим количеством маленьких файлов. я не использовал ocfs, но я, как правило, не одобряю концепцию кластерной файловой системы. тогда есть блеск, но это еще одна банка червей ...</p>

<p>возможно, я немного опоздал. мы используем хранилище dell md3220, которое имеет кластерный двухпортовый порт. у нашего устройства 2 контроллера, если один отключается, второй будет работать до тех пор, пока мы не исправим эту проблему. поскольку жесткие диски, вентиляторы, блоки питания и контроллеры - все это горячая замена, мы заменяем детали по частям. по формату мы используем nfs.</p>

<p>я бы посоветовал против nfs. проще говоря - у нас была ферма веб-серверов, где jboss, apache, tomcat и oracle использовали общие ресурсы nfs для общих файлов конфигурации и ведения журналов.</p><p>когда общий ресурс nfs исчез (по общему признанию, редкий случай), все это просто рухнуло (действительно, предсказуемо, и я посоветовал "devlopers" против этого сокращения времени конфигурации).</p><p>кажется, есть проблема с версией nfs, которую мы использовали, что, если цель исчезла во время записи, клиент упал бы в бесконечный цикл ожидания, ожидая возвращения цели nfs. даже если поле nfs подключено - цикл все равно не закончился.</p><p>мы использовали смесь rhel 3,4,5. хранилище было на rhel4, серверы были на rhel5, сеть хранения данных была отдельной локальной сетью и не работала на vlans.</p><p>если есть интерфейс с балансировкой нагрузки, проверяющий одно хранилище - не станет ли это узким местом вашей системы?</p><p>рассматривали ли вы подключение iscsi только для чтения к вашему хранилищу с помощью сценария, управляемого событиями, для перемещения загруженного файла в хранилище через ftp/scp при загрузке файла?</p><p>единственный раз, когда я реализовал успешное централизованное хранилище для нескольких головок чтения, находился в массиве хранения emc ... все другие экономически эффективные попытки имели свои недостатки.</p>

<p>считается gfs? gfs является кластерной файловой системой и, по моему опыту, довольно надежна. может иметь более одного журнала, хорошо масштабируется</p><p>но вам нужно будет установить некоторые кластерные сервисы, а gfs точно не знает, насколько быстро они работают. ото, это всегда было достаточно быстро для меня, но мммм.</p>

<p>вы бы сошли с ума, считая распределенную fs подобную gfs, а iscsi излишним.</p><p>если вы хотите просто пойти с nfs. это просто и быстро, и с мягкими креплениями довольно прочными. также рассмотрите возможность отключения всех ненужных блокировок. у меня есть рабочие столы linux, которые берут все свои домашние каталоги и приложения из nfs, все работает нормально.</p><p>если вам нужна невероятная скорость, используйте luster, который значительно проще, чем gfs, и который очень похож на raid nfs. мы используем блеск для наших кластеров.</p>

<p>простой ответ +1 для nfs. у меня есть nfs-ресурсы, которые годами монтировались без проблем.</p><p>если вам нужна сверхнадежность, рассмотрите возможность включения drbd в микс и для распределенной, отказоустойчивой файловой системы nfs.</p><p>единственный другой вариант (с которым я знаком) - это iscsi, но при настройке может возникнуть проблема ...</p>

<p>на большой ферме серверов у нас было несколько миллионов созданных пользователями html-страниц. nfs не работал так хорошо, поэтому мы поместили их в таблицу mysql. затраты по сравнению с обходом дерева каталогов были примерно одинаковыми.</p>

<p>я хотел бы повторить предупреждение, которое некоторые высказывают против nfs - хотя nfs, вероятно, является лучшим выбором (как это ни странно звучит).</p><p>у меня был клиент nfs, который мне пришлось отключить от сети переменного тока, чтобы отключить, поскольку сервер nfs исчез, и клиент отказался (в ядре) разблокировать или завершить работу, поскольку сервер nfs пропал.</p><p>чтобы сделать это правильно, я бы настаивал на nfsv4, придерживался tcp соединений, использовал jumbo-кадры и использовал кластер nfs. вы не можете позволить, чтобы ваш сервер nfs исчезал.</p>

<p>у вас есть куча вариантов, с различными затратами. совместно san с fc, iscsi или одним из последних дополнений. в любом случае их установка может быть дорогой, и вам все равно нужно запускать файловую систему с поддержкой кластеров. кластерные файловые системы - это мир боли. для любой надежды на успех вам нужны отдельные высокоскоростные сети с низкой задержкой для кластерной связи и передачи данных. даже при этом вы, вероятно, получите глюки, которые приведут к тому, что узел будет огражден и убит кольцом.</p><p>единственная кластерная файловая система, с которой я столкнулся, которая работает без проблем - это vmfs. но это настолько специализировано, что было бы бесполезно, даже если бы оно было доступно для общего пользования.</p><p>nfs, вероятно, способ для вашей настройки. если вы беспокоитесь о спокойствии, вам нужно получить подходящую кластерную коробку nfs. вы можете выполнить настройку доморощенного напитка, но столкнетесь с вышеуказанной проблемой. лучшая ставка (если у вас есть деньги) - это кластеризованные файлеры netapp. это дорогой вариант, но кластеризация на самом деле работает без каких-либо хлопот. мало того, они очень быстрые.</p>

<p>gfs - это серьезно черный вуду. объем работы, необходимый для работы простого кластера с двумя клиентами, поразителен по сравнению с альтернативами. ocfs2 намного проще в развертывании, но очень требователен, когда дело касается версий модулей ядра на всех подключенных серверах - и это только начало.</p><p>если вам действительно не нужен низкоуровневый доступ, предлагаемый файловой системой кластера, nfs или cifs, вероятно, все, что вам нужно.</p>

<p>если у вас уже есть веб-серверы повсюду, и вы хорошо умеете их запускать, почему бы не рассмотреть webdav?</p>