У нас есть установка с несколькими веб-серверами с балансировкой нагрузки. Мы хотим иметь какое-то общее сетевое хранилище, к которому могут получить доступ все веб-серверы. Он будет использоваться как место для хранения файлов, загруженных пользователями. Все работает под управлением Linux.
Должны ли мы использовать NFS, CIFS, SMB, fuse + sftp, fuse + ftp? Существует так много вариантов сетевых протоколов обмена файлами, что выбрать один из них очень сложно. По сути, мы просто хотим навсегда подключить этот общий ресурс на нескольких машинах. Функции безопасности вызывают меньшее беспокойство, потому что он не будет доступен в сети из любого места, кроме серверов, на которых он установлен. Мы просто хотим, чтобы он работал надежно и быстро.
Какой из них использовать?
Голосую за NFS.
В NFSv4.1 добавлена возможность параллельного NFS pNFS, которая делает возможным параллельный доступ к данным. Мне интересно, какие клиенты используют хранилище, если только Unix-like, тогда я бы выбрал NFS, исходя из показателей производительности.
Короткий ответ - используйте NFS. Согласно этому перестрелка и по моему собственному опыту, это быстрее.
Но у вас есть больше возможностей! Вам следует рассмотреть кластерную FS, такую как GFS, которая представляет собой файловую систему, к которой могут обращаться сразу несколько компьютеров. По сути, вы делитесь блочным устройством через iSCSI, который является файловой системой GFS. Все клиенты (инициаторы на языке iSCSI) могут читать и писать в него. Redhat имеет белая бумага . Вы также можете использовать кластерную FS Oracle OCFS управлять тем же.
В документе redhat хорошо перечислены плюсы и минусы кластерной FS по сравнению с NFS. В принципе, если вам нужно много места для масштабирования, GFS, вероятно, того стоит. Кроме того, в примере GFS в качестве примера используется сеть Fibre Channel SAN, но это может быть также RAID, DAS или iSCSI SAN.
Наконец, не забудьте изучить Jumbo Frames, и если целостность данных имеет решающее значение, используйте контрольную сумму CRC32, если вы используете iSCSI с Jumbo Frames.
У нас есть веб-кластер с двумя серверами, снижающими нагрузку на сервер. Мы попробовали следующие методы синхронизации контента между серверами:
В RSYNC Решение было самым простым, но для отображения изменений потребовалось 10 минут, а RSYNC так сильно нагружал серверы, что нам приходилось ограничивать его с помощью специального скрипта, чтобы приостанавливать его каждую секунду. Мы также были ограничены только записью на исходный диск.
Самый быстрый общий диск был OCFS2 кластерный диск до тех пор, пока он не сошел с ума и не сломал кластер. Нам не удалось сохранить стабильность с OCFS2. Как только более одного сервера обращаются к одним и тем же файлам, нагрузка поднимается до предела, и серверы начинают перезагружаться. Это может быть наша тренировочная неудача.
Следующим лучшим было NFS. Он был чрезвычайно стабильным и отказоустойчивым. Это наша текущая установка.
SMB (CIFS) были проблемы с блокировкой. В частности, веб-серверы не видели изменения файлов на SMB-сервере. SMB также имел тенденцию зависать при отказе сервера SMB
Наш вывод заключалась в том, что OCFS2 имеет наибольший потенциал, но требует БОЛЬШОГО анализа перед использованием в производстве. Если вам нужно что-то прямолинейное и надежное, я бы порекомендовал кластер серверов NFS с Heartbeat для аварийного переключения.
Предлагаю Вам ПОХМЕЛФС - он создан российским программистом Евгением Поляковым и очень-очень быстрый.
С точки зрения надежности и безопасности, вероятно, CIFS (также известный как Samba), но NFS «кажется» намного более легким, и при тщательной настройке можно не полностью раскрывать ваши ценные данные для любой другой машины в сети ;-)
Никакого оскорбления материала FUSE, но он все еще кажется ... свежим, если вы понимаете, о чем я. Я не знаю, доверяю ли я ему, но это могло быть просто я старым фанатом, но старый туман иногда оправдан, когда дело касается ценных корпоративных данных.
Если вы хотите постоянно монтировать одну общую папку на нескольких машинах и можете подыгрывать некоторым странностям (в основном, проблемам с UID / GID), используйте NFS. Пользуюсь им уже много лет.
NFS. Это проверено и верно, и вы можете получить надежную настройку. Производительность GFS обычно ужасна, особенно в файловых системах с большим количеством маленьких файлов. Я не использовал OCFS, но обычно не одобряю концепцию кластерной файловой системы. Еще есть блеск, но это еще одна банка червей ...
Я могу немного опоздать. Мы используем MD3220 Dell Storage с двойным портом кластера. В нашем устройстве есть 2 контроллера, если один из них выйдет из строя, второй будет поддерживать его работоспособность, пока мы не исправим эту проблему. Поскольку жесткий диск, вентилятор, блок питания и контроллер - это горячая замена, мы заменяем детали как внутри, так и снаружи. Что касается формата, мы используем NFS.
Вы бы не в своем уме рассматривать распределенную FS, такую как GFS, а iSCSI - это излишество.
Если вы хотите простого, используйте NFS. Это просто и быстро, а с мягкими креплениями довольно надежно. Также рассмотрите возможность отключения всего связанного с ним блокирующего мусора. У меня есть рабочие столы Linux, которые захватывают все свои домашние каталоги и приложения из NFS, все работает нормально.
Если вам нужна невероятная скорость, выберите Lustre, который значительно проще настроить, чем GFS, и во многом похож на RAID NFS. Мы используем Lustre для наших кластеров.
Считали GFS? GFS - это кластерная файловая система, и, по моему опыту, она довольно надежна. Может иметь более одного журнала, хорошо масштабируется
Но вам нужно будет установить некоторые кластерные службы, а GFS точно не знает их скорости. Ото, для меня это всегда было достаточно быстро, но ymmv.
Если у вас уже есть веб-серверы повсюду и вы умеете их запускать, почему бы не подумать о WebDAV?
Я бы посоветовал не использовать NFS. Проще говоря, у нас была ферма веб-серверов с JBoss, Apache, Tomcat и Oracle, которые использовали общие ресурсы NFS для общих файлов конфигурации и ведения журналов.
Когда общий ресурс NFS исчез (по общему признанию, редкое явление), все просто рухнуло (на самом деле предсказуемо, и я посоветовал «разработчикам» не использовать этот ярлык времени конфигурации).
Похоже, есть проблема с версией NFS, которую мы использовали: если цель исчезла во время записи, клиент попадал в бесконечный цикл ожидания, ожидая возвращения цели NFS. Даже если NFS-ящик снова подключился - цикл все равно не закончился.
Мы использовали смесь RHEL 3,4,5. Хранилище было на RHEL4, серверы были на RHEL5, сеть хранения была отдельной LAN и не работала на vlan.
Если есть интерфейс с балансировкой нагрузки, проверка единого хранилища - не станет ли это узким местом для вашей системы?
Рассматривали ли вы подключение iSCSI только для чтения к вашему хранилищу со сценарием, управляемым событиями, для перемещения загруженного файла в хранилище через ftp / scp при загрузке файла?
Единственный раз, когда я реализовал успешное централизованное хранилище для нескольких считывающих головок, был на массиве хранения EMC ... Все другие рентабельные попытки имели свои недостатки.
GFS - это серьезное черное вуду. Объем работы, необходимой для работы простого двухклиентского кластера, ошеломляет по сравнению с альтернативами. OCFS2 намного проще развернуть, но он очень разборчив, когда дело касается версий модуля ядра, задействованных на всех подключенных серверах - и это только начало.
Если вам действительно не нужен тип низкоуровневого доступа, который предлагает файловая система кластера, вам, вероятно, будет достаточно NFS или CIFS.
Я бы повторил предупреждение, которое некоторые высказали против NFS - хотя NFS, вероятно, ваш лучший выбор (как бы странно это ни звучало).
У меня был клиент NFS, который мне пришлось отключить от AC, чтобы выключить, потому что сервер NFS исчез, а клиент отказался (в ядре) разблокировать или выключить, потому что сервер NFS исчез.
Чтобы сделать это правильно, я бы настаивал на NFSv4, придерживался TCP-соединений, использовал jumbo-кадры и использовал NFS-кластер. Вы не можете позволить, чтобы ваш сервер NFS исчез.
У вас есть множество вариантов с разными затратами. Общий SAN с FC, iSCSI или одним из последних дополнений. В любом случае их установка может быть дорогостоящей, и вам все равно придется запускать файловую систему с поддержкой кластеров. Кластерные файловые системы - это мир боли. Для любой надежды на успех вам нужны отдельные высокоскоростные сети с малой задержкой для кластерной связи и данных. Даже с этим вы, вероятно, получите глюки, которые приведут к тому, что узел будет изолирован и убит.
Единственная файловая система кластера, с которой я столкнулся, которая работает без проблем, - это VMFS. Но это настолько специализировано, что было бы бесполезно, даже если бы оно было доступно для общего пользования.
NFS, вероятно, лучший вариант для вашей установки. Если вас беспокоит отказоустойчивость, вам нужно получить надлежащий кластерный NFS-блок. Вы можете выполнить настройку домашнего пивоварения, но столкнетесь с указанной выше проблемой. Лучшая ставка (если у вас есть деньги) - это кластерные файловые системы NetApp. Это дорогой вариант, но кластеризация на самом деле работает без проблем. Мало того, они очень быстрые.
Простой ответ +1 для NFS. У меня есть общие ресурсы NFS, которые монтировались годами без проблем.
Если вы ищете сверхнадежность, подумайте о добавлении DRBD к распределенной файловой системе NFS с автоматическим переключением при отказе.
Единственный другой вариант (с которым я знаком) - это iSCSI, но его настройка может быть сложной задачей ...
На большой серверной ферме у нас было несколько миллионов HTML-страниц, созданных пользователями. NFS работал не так хорошо, поэтому мы поместили их в таблицу mysql. Накладные расходы по сравнению с обходом дерева каталогов были примерно такими же.
Я использовал SFTP, и он отлично работал для моих целей - NFS был моим первым средством, но забавные идентификаторы пользователей / групп заставили меня довольно быстро отказаться от него.
Просто настройте аутентификацию по публичному ключу, и все будет готово. Могут быть несколько более высокие накладные расходы ЦП для шифрования SSH, но с другой стороны, я никогда не сталкивался с какими-либо проблемами с повреждением данных.
Однако FTP вполне может соответствовать вашим целям, поскольку он более легкий. Предположительно вы хотите, чтобы ваши веб-серверы выполняли веб-обслуживание, а не работу ssh.