Який протокол обміну мережевими файлами має найкращі показники та надійність? [зачинено]

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

Чи варто використовувати NFS, CIFS, SMB, запобіжник + sftp, запобіжник + ftp? Існує так багато варіантів для протоколів обміну мережевими файлами, що вибрати її дуже важко. Ми в основному просто хочемо постійно встановити цю частину на декількох машинах. Функції безпеки викликають менше занепокоєння, оскільки це мережа не буде доступна з будь-якого місця, окрім серверів, на яких вона монтується. Ми просто хочемо, щоб це надійно та швидко працювало.

Який з них нам використовувати?

Я голосую за НФС.

NFSv4.1 додав можливість паралельного NFS pNFS, що робить можливим паралельний доступ до даних. Мені цікаво, які саме клієнти використовують сховище, якби тільки Unix-подібний, то я б пішов на NFS на основі даних про ефективність.

Коротка відповідь - використовувати NFS. Відповідно до цієї перестрілки та мого власного досвіду, це швидше.

Але, у вас є більше варіантів! Вам слід розглянути кластер FS типу GFS, який є файловою системою, до якої можуть отримати доступ декілька комп'ютерів одночасно. В основному, ви ділитесь блочним пристроєм через iSCSI, який є файловою системою GFS. Усі клієнти (ініціатори на мові iSCSI) можуть читати та писати на ньому. Redhat має Whitepaper . Ви також можете використовувати кластер Oracle FS OCFS для управління тим же самим.

Документ redhat робить хорошу роботу з переліком плюсів і мінусів кластера FS проти NFS. В основному, якщо ви хочете багато місця для масштабування, GFS, ймовірно, варто докласти зусиль. Також приклад GFS використовує Fiber Channel SAN як приклад, але це так само легко може бути RAID, DAS або iSCSI SAN.

Нарешті, переконайтеся, що вивчаєте рамки Jumbo, і якщо цілісність даних є критичною, використовуйте контрольну суму 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 "здається" набагато легшим, і при ретельному налаштуванні неможливо повністю виставити ваші цінні дані будь-якій іншій машині в мережі ;-)

Жодної образи на ФУЗЕ, але все ще здається… свіжою, якщо ви знаєте, що я маю на увазі. Я не знаю, чи довіряю я цьому, але це міг бути я просто старим фоґієм, але старий фогеїзм іноді є гарантованим, коли мова йде про цінні дані підприємств.

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

NFS. Це випробувано і правда, і ви можете мати суцільну настройку. Продуктивність GFS, як правило, жахлива, особливо у файлових системах з великою кількістю невеликих файлів. Я не використовував OCFS, але я, як правило, нахмурився на концепцію файлової системи кластера. Потім є блиск, але це ще одна банка глистів ...

Я б радив проти НФС. Простіше кажучи - у нас була ферма веб-серверів, в якій JBoss, Apache, Tomcat і Oracle усі використовували NFS-спільні файли для загальних файлів конфігурації та ведення журналів.

Коли частка NFS зникла (правда, рідкісне явище), ця річ просто згорнулася (насправді передбачувано, і я порадив "devlopers" проти цього ярлика часу конфігурації).

Здається, виникла проблема з версією NFS, яку ми використовували, якщо ціль зникла під час запису, клієнт потрапить у нескінченний цикл очікування, очікуючи повернення цілі NFS. Навіть якщо поле NFS повторно встановлено - цикл все одно не закінчився.

Ми використовували суміш RHEL 3,4,5. Зберігання було на RHEL4, сервери - на RHEL5, мережа зберігання - окремий лан, і не працює на vlans.

Якщо передній кінець є збалансованим навантаженням, перевіряючи єдине сховище - це не буде вузьким місцем вашої системи?

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

Єдиний раз, коли я здійснив успішне централізоване сховище для декількох зчитуваних головок, був на масиві зберігання ЕМС ... Усі інші спроби, що займаються економією, мали свої недоліки.

Вважається GFS? GFS - це файлова система кластерів, і, на мій досвід, досить надійна. У ньому може бути більше одного журналу, він досить масштабний

Але вам потрібно буде встановити деякі кластерні служби, і GFS точно не знає про його швидкість. Ото, це завжди було досить швидко для мене, але ymmv.

Вам буде не до душі розглянути розподілений FS, як GFS, і iSCSI є надмірним.

Якщо ви хочете, просто перейдіть з NFS. Це просто і швидко, а з м'якими кріпленнями досить надійними. Також слід розглянути можливість вимкнення всіх блокуючих сміття, які йдуть разом із цим. У мене є настільні комп’ютери Linux, які захоплюють усі їх домашні каталоги та програми з NFS, це працює чудово.

Якщо ви хочете, щоб скасувати швидкість, перейдіть за допомогою Luster, що налаштувати значно простіше, ніж GFS, і це дуже схоже на RAID NFS. Ми використовуємо Luster для своїх кластерів.

Я, можливо, запізнюється, ми використовуємо Dell Storage MD3220, у якого є кластерний подвійний порт. У нашому пристрої є 2 контролера, якщо один знижується, другий буде тримати його, поки ми не вирішимо цю проблему. Оскільки жорсткий диск, вентилятор, джерело живлення та контролер - це все гаряча заміна, ми замінюємо деталі назовні. Щодо формату, ми використовуємо NFS.

Якщо у вас вже є веб-сервери скрізь і ви добре працюєте з ними, чому б не розглянути WebDAV?

Проста відповідь +1 для NFS. У мене є акції NFS, які роками встановлювались без проблем.

Якщо ви шукаєте надзвичайну надійність, тоді подумайте про те, щоб перекинути DRBD в суміш, а також для розподіленої файлової системи NFS з автоматичним відключенням.

Єдиний інший варіант (який я знайомий) - iSCSI, але це може бути біль в тилу, щоб налаштувати ...

У вас є купа варіантів, з різними витратами. Ділився SAN з FC, iSCSI або одним із останніх доповнень. У будь-якому випадку їх налаштування може бути дорогим, і вам все одно потрібно запустити файлову систему, відому кластеру. Кластеризовані файлові системи - це біль болю. Для будь-якої надії на успіх потрібні окремі високошвидкісні та низькі затримки для кластерної комунікації та даних. Навіть при цьому ви, ймовірно, отримаєте глюки, в результаті яких вузол буде обгороджений і вбитий.

Єдина файлова система кластерів, на яку я стикався, і яка працює без клопоту, - це VMFS. Але це настільки спеціально, що було б не корисно, навіть якби воно було доступне для загального користування.

NFS - це, мабуть, шлях для вашої установки. Якщо ви переживаєте за стійкість, вам потрібно отримати належне кластеризоване поле NFS. Ви можете зробити налаштування домашньої кави, але вдарило б за вказаною вище проблемою. Найкраща ставка (якщо у вас є гроші) - це кластеризовані файли NetApp. Це дорогий варіант, але кластеринг насправді працює без зайвих клопотів. Мало того, вони дуже швидкі.

Я б повторив попередження, яке деякі висловили проти NFS - хоча, мабуть, найкраща ставка на NFS (як це не дивно звучить).

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

Щоб зробити це правильно, я б наполягав на NFSv4 протягом усього часу, дотримувався TCP-з'єднань, використовував jumbo фрейми та використовував кластер NFS. Ви не можете дозволити собі зникнення вашого сервера NFS.

GFS - це якийсь серйозно чорний вуду. Обсяг роботи, необхідний для роботи простого двох клієнтських кластерів, є приголомшливим порівняно з альтернативами. OCFS2 набагато простіше розгортати, але дуже прискіпливий, коли мова йде про версії модуля ядра, що беруть участь на всіх підключених серверах - і це лише початок.

Якщо вам справді не потрібен тип низькорівневого доступу, який пропонує файлова система кластера, NFS або CIFS - це, мабуть, все, що вам потрібно.

На великій фермі серверів у нас було кілька мільйонів створених користувачем html-сторінок. NFS не працював так добре, тому ми в кінцевому підсумку помістили їх у таблицю mysql. Накладні витрати порівняно з переходом до дерева каталогів були приблизно однаковими.

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

Просто встановіть publickey auth, і ви багато в чому будете налаштовані. Можливо, для шифрування SSH може бути дещо важчий накладний процесор, але з іншого боку я ніколи не стикався з проблемами з корупцією даних.

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