Linux samba или nfs

NFS vs Samba vs SFTP

Хотелось бы чем нибудь заменить самбу, и вот возникли вопросы по поводу вариантов замены. HTTP и FTP сразу отпадают. Первый, потому что сложная настройка для достаточно простой задачи доступа к файлам в пределах локальной сети; второй, потому что излишен, ввиду присутсвия SFTP/SCP/SSH почти в любом дистрибутиве, уже настроенного.

Какие основные отличия между NFS и Samba?
Я так думаю что основное, это то, что NFS клиент, в отличие от Samba не сканирует подсеть на наличие серверов и нужно указывать ip вручную.
И тогда в чем отличия между NFS и SFTP?
И есть ли смысл настраивать NFS, если SFTP уже настроен?

Re: NFS vs Samba vs SFTP

При использовании NFS должна быть общая база пользователей с уникальными UID, ну или будет шара одна на всех, без разбора, кроме как по IP-шникам

Re: NFS vs Samba vs SFTP

Можно поподробнее? ТО что надо будет настроить пользователей это ладно, а «будет шара одна на всех, без разбора, кроме как по IP-шникам» — не совсем ясно. То есть как в samba?

Re: NFS vs Samba vs SFTP

В самбе как раз с авторизацией всё просто: логин, пароль и вперёд. А про NFS спроси лучше man exports 🙂 Лично я сделал дома общую анонимную шару, но если надо, можно менять права монтирования в зависимости от IP

Re: NFS vs Samba vs SFTP

Да, как раз читаю всякие доки. И чем тогда NFS лучше SFTP? NFS нужно настраивать, при монтировании если сеть упадет комп может повиснуть (если hard режим), небезопасно (нет шифрования, только как вариант через ssh-туннель). Как то слишком много проблем по сравнению с SFTP, может есть преимущества? 🙂

Re: NFS vs Samba vs SFTP

Лучше тем, что процессор скромнее кушает

Re: NFS vs Samba vs SFTP

Хотя если сервер -> десктоп уже не так актуально, я просто ресурсы маршрутизатора-сервера экономил 🙂

Re: NFS vs Samba vs SFTP

>Да, как раз читаю всякие доки. И чем тогда NFS лучше SFTP? NFS нужно настраивать, при монтировании если сеть упадет комп может повиснуть (если hard режим), небезопасно (нет шифрования, только как вариант через ssh-туннель). Как то слишком много проблем по сравнению с SFTP, может есть преимущества? 🙂

1. не упадет всямашина. даже если хард режим. Максимум — завязанные на этом разделе процессы в I/O lock упадут.

по сравнению с sftp есть преимущества. Хотя бы потому, что sftp — это FTP сервер. А NFS — это сетевая файловая система, которая встраивается в корневую ФС; со всеми вытекающими отсюда удобствами.

И наконец — а зачем тебе шифрование?

Re: NFS vs Samba vs SFTP

Встраивание через /etc/fstab? Можно также сделать через sshfs.

Re: NFS vs Samba vs SFTP

>Лучше тем, что процессор скромнее кушает

И в разы быстрее.

Re: NFS vs Samba vs SFTP

Думаю, что речь идет о NFS-root, когда при загрузке ядру передаются параметры и корневая файловая система монтируется по NFS с сервера.

И вроде sshfs не поддерживала блокировки.

Re: NFS vs Samba vs SFTP

>И в разы быстрее.

Вот это уже интересно, скорость передачи данных значительно отличается?
Если да, то этого аргумента достаточно чтобы переходить на NFS.
PS: шифрование не нужно, было просто как аргумент.

Re: NFS vs Samba vs SFTP

NFS не умеет разрешать симлинки на стороне клиента.

samba умеет, без проблем.

Re: NFS vs Samba vs SFTP

> Вот это уже интересно, скорость передачи данных значительно отличается?

В пару раз, и более — при уменьшении размера файла.

Re: NFS vs Samba vs SFTP

> без разбора, кроме как по IP-шникам

Источник

Какой использовать NFS или Samba?

Я устанавливаю коробку, чтобы быть файловым сервером в доме. Он будет в основном использоваться для обмена музыкой, фотографиями, фильмами с другими Linux-сетями в сети и одним компьютером с OS X. Из того, что я прочитал, NFS и Samba будет работать в моей ситуации, и поэтому я не уверен, какой выбрать. Для меня важна скорость передачи между коробками и сложность настройки.

Что бы вы порекомендовали и почему?

В закрытой сети (где вы знаете каждое устройство) NFS — прекрасный выбор. При хорошей сети пропускная способность отвратительно быстрая и в то же время менее ресурсоемкая на сервере. Это очень просто настроить, и вы можете переключаться readonly на общие ресурсы, которые вам не нужны для записи.

Я не согласен с Андерсом. v4 может быть таким же простым, как v3. Это только усложняется, если вы хотите начать многоуровневую защиту через LDAP / gssd. Он способен на очень сложные и законченные механизмы безопасности . Но они вам не нужны. Они фактически отключены по умолчанию.

Затем отредактируйте, /etc/exports чтобы настроить ваши акции. Вот строка из моей живой версии, которая делится моей музыкой:

Это разделяет этот путь с кем-либо на 192.168.0. * readonly (Обратите внимание ro ).

Когда вы закончите редактирование, перезапустите NFS:

Для подключения клиента вам понадобятся NFS gubbins (по умолчанию не установлено):

А затем добавить строку в /etc/fstab

На самом деле это клиент NVSv3, потому что я ленивый, но он совместим в этом сценарии. 192.168.0.4 это сервер NFS (мой рабочий стол в данном случае). И вам нужно убедиться, что путь монтирования ( /media/music здесь) существует.

Это гораздо проще, чем некоторые старые уроки могли бы заставить вас поверить.

Это может выглядеть сложнее, чем на самом деле, но оно надежное, предсказуемое и быстрое. То, что вы не можете сравниться с Самбой . По крайней мере, по моему опыту.

Источник

🐧 NFS, SAMBA или CIFS

NFS, SAMBA и CIFS – это три разных термина, которые часто упоминаются, когда кто-то говорит об обмене файлами между двумя или более системами.

Но знаете ли вы, что делают эти три реализации, и чем они отличаются друг от друга? По какой-то причине эти технологии остаются загадкой даже для опытных системных администраторов.

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

В этой статье мы подробно рассмотрим NFS, SAMBA и CIFS, а также поговорим об их реализации в контексте системы Linux.

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

Что выбрать NFS, SAMBA, CIFS?

Начнем с Samba и CIFS.

Оба реализуют протокол SMB (Server Message Block), который был создан компанией Microsoft. Samba и CIFS могут взаимодействовать друг с другом, поскольку они делают одно и то же, только разными способами.

Если вы не работаете с устаревшими системами, вам следует придерживаться Samba.

amba более современна, надежна и быстра.

Таким образом, решение здесь очень простое.

Если вам нужно поддерживать совместимость с компьютерами Windows, используйте Samba.

Если она не подходит для вашей среды, потому что вы используете устаревшие системы, то вы можете остаться с CIFS. И это может вызвать у вас некоторые головные боли, поскольку серверы Samba могут выступать в качестве контроллера домена, а серверы CIFS – нет.

то позволяет пользователям Windows использовать свои учетные данные на сервере Samba, а не дублировать весь набор пользователей с Windows на Linux в случае с CIFS.

NFS работает совершенно аналогично Samba – они оба позволяют одному или нескольким клиентам обмениваться файлами с сервером.

Но есть одна существенная оговорка: NFS и SMB не являются совместимыми протоколами.

Это означает, что сервер Samba не сможет взаимодействовать с сервером NFS, по крайней мере, без некоторых доработок. NFS был разработан компанией Sun Microsystems, но Windows Server способен размещать общие ресурсы NFS, и другие операционные системы Windows могут подключаться к нему. Конечно, системы Linux также могут размещать или подключаться к общим ресурсам NFS.

Из этого можно сделать очевидный вывод: NFS отлично подходит для сред Linux, а Samba – для сред Windows или смешанных сред (Linux + Windows).

Если ваш сервер хранения работает под Linux, выбирайте NFS.

Если это Windows, выбирайте Samba.

Это даст вам наиболее идеальную настройку и наилучшую производительность, хотя, безусловно, можно использовать любой из этих вариантов.

Установка Samba на Linux

Чтобы начать использовать Samba в систеамх Linux, используйте соответствующую команду для установки программного обеспечения в вашей системе.

В Ubuntu, Linux Mint и других дистрибутивах на базе Debian:

Установка NFS в Linux

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

В Ubuntu, Linux Mint и других дистрибутивах на базе Debian:

На Fedora, CentOS, AlmaLinux и других дистрибутивах на базе RHEL:

Заключение

В этом руководстве мы рассмотрели основы NFS, SAMBA и CIFS.

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

Как только вы будете готовы приступить к работе, мы дадим вам соответствующие команды для установки программного обеспечения на вашу систему.

После этого вам нужно будет настроить NFS или SAMBA, чтобы завершить установку и начать совместное использование файлов.

Источник

Что использовать NFS или Samba?

Я устанавливаю ящик для файлового сервера в доме. В основном это будет использоваться для обмена музыкой, изображениями, фильмами с другими ящиками Linux в сети и одной машиной OS X. Из того, что я прочитал, NFS и самба будут работать в моей ситуации, и поэтому я не уверен, что выбрать. Для меня важны скорости передачи между ящиками и сложность настройки.

Что бы вы порекомендовали и почему?

5 ответов

В закрытой сети (где вы знаете каждое устройство) NFS — прекрасный выбор. С хорошей сетью пропускная способность отвратительно быстрая и в то же время меньшая интенсивность процессора на сервере. Это очень просто настроить, и вы можете переключать readonly на общие ресурсы, которые вам не нужно записывать.

Я не согласен с Андерсом. v4 может быть таким же простым, как v3. Это только усложняется, если вы хотите начать расслоение безопасности через LDAP /gssd. Он способен на очень сложные и полные механизмы безопасности . Но они вам не нужны. По умолчанию они отключены.

Затем отредактируйте /etc/exports , чтобы настроить свои ресурсы. Вот строка из моей живой версии, которая разделяет мою музыку:

Это разделяет этот путь с кем-либо на 192.168.0. * в readonly (обратите внимание на способ ro ).

Когда вы закончили редактирование, перезапустите NFS:

Чтобы подключиться к клиенту, вам нужны Gubbins NFS (не установлены по умолчанию):

Затем добавьте строку в /etc/fstab

На самом деле это клиент NVSv3, потому что я ленив, но он совместим в этом сценарии. 192.168.0.4 — это сервер NFS (в этом случае мой рабочий стол). И вам нужно убедиться, что существует путь монтирования ( /media/music ).

Это намного проще, чем некоторые старые учебники, которые вы считаете.

Это может выглядеть сложнее, чем есть на самом деле, но оно прочное, предсказуемое и быстрое. То, что вы не можете выровнять против Samba . По крайней мере, по моему опыту.

Недавно я проверил подключение через SMB и NFS к моей станции NAS Synology. Для меня соединение NFS работает в два раза быстрее, чем SMB-соединение. Особенно, если вам нужно иметь дело с 100 GByte фотографий и музыкальных файлов в 1000 каталогах, вам понравится скорость NFS.

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

NFS (версия 4) обеспечивает безопасность, но практически невозможно настроить.

Samba, вероятно, будет немного медленнее, но прост в использовании, а также будет работать с клиентами Windows.

Недавно я установил локальный сервер NFS на сервере Ubuntu 10.04, но мой MacBook Pro (OS X 10.6.X) не смог подключиться. Для того чтобы Mac мог подключиться, мне пришлось добавить небезопасный код /etc/exports .

Мой /etc /exports:

Запустите тесты реального мира, прежде чем посвящать следующие X лет и Y TB конкретному протоколу, никогда не понимая, что существует лучший вариант.

Вы найдете мнения, по поводу которых быстрее, когда люди Samba утверждают, что они находятся на одном уровне с NFS. В зависимости от ваших потребностей лучше всего настроить общий ресурс Samba и общий сетевой ресурс NFS и выполнить различные тесты чтения /записи /тестирования в реальном времени в сети. Если у вас есть аналогичные потребности, как и я (машины Windows), вы можете быть удивлены, узнав, что Samba на 20% быстрее, чем NFS.

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

Источник

NAS Performance: NFS vs. SMB vs. SSHFS

updated: Apr 2, 2020

This is a performance comparison of the the three most useful protocols for networks file shares on Linux with the latest software. I have run sequential and random benchmarks and tests with rsync. The main reason for this post is that i could not find a proper test that includes SSHFS.

NAS Setup

The hardware side of the server is based on an Dell mainboard with an Intel i3-3220, so a fairly old 2 core / 4 threads CPU. It also does not support the AES-NI extensions (which would increase the AES performance noticeably) the encryption happens completely in software.

As storage two HDDs in BTRFS RAID1 were used, it does not make a difference though, because the tests are staged to hit almost always the cache on the server, so only the protocol performance counts.

I installed Fedora 30 Server on it and updated it to the latest software versions.

Everything was tested over a local Gigabit Ethernet Network. The client is a quadcore desktop machine running Arch Linux, so this should not be a bottleneck.

SSHFS (also known as SFTP)

Relevant package/version: OpenSSH_8.0p1, OpenSSL 1.1.1c, sshfs 3.5.2

OpenSSH is probably running anyway on all servers, so this is by far the simplest setup: just install sshfs (fuse based) on the clients and mount it. Also it is per default encrypted with ChaCha20-Poly1305. As second test i did choose AES128, because it is the most popular cipher, disabling encryption is not possible (without patching ssh). Then i added some mount options (suggested here) for convenience and ended with:

sshfs -o Ciphers=aes128-ctr -o Compression=no -o ServerAliveCountMax=2 -o ServerAliveInterval=15 remoteuser@server:/mnt/share/ /media/mountpoint

NFSv4

Relevant package/version: Linux Kernel 5.2.8

The plaintext setup is also easy, specify the exports, start the server and open the ports. I used these options on the server: (rw,async,all_squash,anonuid=1000,anongid=1000)

And mounted with: mount.nfs4 -v nas-server:/mnt/share /media/mountpoint

But getting encryption to work can be a nightmare, first setting up kerberos is more complicated than other solutions and then dealing with idmap on both server an client(s)… After that you can choose from different levels, i set sec=krb5p to encrypt all traffic for this test (most secure, slowest).

Relevant package/version: Samba 4.10.6

The setup is mostly done with installing, creating the user DB, adding a share to smb.conf and starting the smb service. Encryption is disabled by default, for the encrypted test i set smb encrypt = required on the server globally. It uses AES128-CCM then (visible in smbstatus ).

IDmapping on the client can be simply done as mount option, i used as complete mount command:

mount -t cifs -o username=jk,password=xyz,uid=jk,gid=jk //nas-server/media /media/mountpoint

Test Methodology

The main test block was done with the flexible I/O tester (fio), written by Jens Axboe (current maintainer of the Linux block layer). It has many options, so i made a short script to run reproducible tests:

First two are classic read/write sequential tests, with 128 KB block size an a queue depth of 4. The last are small 4 KB random read/writes, but with are 32 deep queue. The direct flag means direct IO, to make sure that no caching happens on the client.

For the real world tests i used rsync in archive mode ( -rlptgoD ) and the included measurements:

rsync —info=progress2 -a sshfs/TMU /tmp/TMU

Synthetic Performance

Sequential

Most are maxing out the network, the only one falling behind in the read test is SMB with encryption enabled, looking at the CPU utilization reveals that it uses only one core/thread, which causes a bottleneck here.

NFS handles the compute intensive encryption better with multiple threads, but using almost 200% CPU and getting a bit weaker on the write test.

SSHFS provides a surprisingly good performance with both encryption options, almost the same as NFS or SMB in plaintext! It also put less stress on the CPU, with up to 75% for the ssh process and 15% for sftp.

Random

On small random accesses NFS is the clear winner, even with encryption enabled very good. SMB almost the same, but only without encryption. SSHFS quite a bit behind.

NFS still the fastest in plaintext, but has a problem again when combining writes with encryption. SSHFS is getting more competitive, even the fastest from the encrypted options, overall in the mid.

The latency mostly resembles the inverse IOPS/bandwith. Only notable point is the pretty good(low) write latency with encrypted NFS, getting most requests a bit faster done than SSHFS in this case.

Real World Performance

This test consists of transfering a folder with rsync from/to the mounted share and a local tmpfs (RAM backed). It contains the installation of a game (Trackmania United Forever) and is about 1,7 GB in size with 2929 files total, so a average file size of 600 KB, but not evenly distributed.

After all no big surprises here, NFS fastest in plaintext, SSHFS fastest in encryption. SMB always somewhat behind NFS.

Conclusion

In trusted home networks NFS without encryption is the best choice on Linux for maximum performance. If you want encryption i would recommend SSHFS, it is a much simpler setup (compared to Kerberos), more cpu efficient and often only slightly slower than plaintext NFS. Samba/SMB is also not too far behind, but only really makes sense in a mixed (Windows/Linux) environment.

Источник