Обмін файлами в Linux: NFS проти SMB — оберіть той, що не зависатиме випадково

Що зазвичай означає «випадкові зависання»

Коли люди кажуть «файловий шар зависає», вони зазвичай мають на увазі одне з трьох:

• Спалахи затримки: операції повертаються, але інколи займають секунди чи хвилини. Додатки таймаутяться, повторні спроби накопичуються, і виникає thundering herd.
• Сильні очікування вводу/виводу: процес блокується в просторі ядра (часто D-state), чекаючи на сервер або мережу. Ваш kill -9 нічого не робить. Це не впертість процесу; це ядро, що чекає на I/O.
• Семантичні дедлоки: блокування файлів або oplocks/leases взаємодіють з кешуванням клієнта та очікуваннями застосунків. Все «здається в мережі», але додаток не може просунутися вперед.

І NFS, і SMB можуть породжувати всі три варіанти. Різниця в тому, де проявляється збій, як швидко він стає очевидним і які ручки ви дійсно маєте, щоб зробити його нудним.

Корисна модель: мережеві файлові системи — це розподілені системи з різкими краями. А розподілені системи вміють двом речам: відмовляти новими способами та навчати вас таймаутів.

Кілька фактів і історія, що справді важливі

Трохи контексту допомагає, бо старі проєктні рішення проявляються сьогодні як «чому це за замовчуванням так?»

1. NFS розробили в Sun у 1980-х, у добу моделі «довірена LAN». Тому безпека прикручена шарами (AUTH_SYS, потім Kerberos через RPCSEC_GSS).
2. NFSv3 є безстанним (сервер не відслідковує стан сеансів клієнта так само). Це може бути добре для відновлення й погано для очікувань щодо блокувань без додаткових сервісів.
3. NFSv4 ввів стейтфул-режим (блокування, делегації, сесії), що покращує семантику, але додає режимів відмов, пов’язаних зі «заплутаним станом» при мережевих флапах.
4. SMB починався як протокол для DOS/Windows LAN і накопичив корпоративні фішки: багаті ACL, погодження, і припущення, що ідентичність має значення (користувачі, домени, каталоги).
5. SMB1 застарілий і небезпечний; у сучасних середовищах слід використовувати SMB3.x. SMB3 додав шифрування, multichannel, кращі поведінки продуктивності й менше археологічних артефактів.
6. Samba (SMB-сервер на Linux) десятиліттями була готовою до продакшену. Це не «суміснісний хак». Це серйозний движок для перетворення ідентичності й файлової семантики.
7. Підписування пакетів і шифрування стали типовими в багатьох корпоративних Windows-середовищах. Це добре для безпеки, але може стати випадковим податком на продуктивність.
8. NFS поверх TCP витіснив UDP для надійності в більшості серйозних розгортань. UDP ще інколи зустрічається у кутах, зазвичай там, де ви не хочете несподіванок.
9. «Stale file handle» — класична помилка NFS, пов’язана з тим, як NFS ідентифікує файли й директорії при змінах на сервері. Це не випадковість; це сервер/експорт, що змінився під активними клієнтами.

Одна корисна цитата, бо інженерам іноді потрібна поезія: Надія — це не стратегія. (парафразована ідея, часто згадується в операційних кругах)

Як NFS реально поводиться при збоях

NFS простий, поки не стає складним: проблема «блокування в ядрі»

Клієнти NFS оптимізовані так, щоб виглядати як локальні файлові виклики. У цьому весь сенс. VFS ядра робить RPC, чекає відповіді від сервера і повертає дані. Коли сервер повільний, недоступний, перевантажений або втрачає пакети, ці очікування в ядрі можуть перетворитися на зависання додатків.

Найважливіше розрізнення для NFS-монтувань у продакшені: hard проти soft. Другий за важливістю — таймаути й retrans, які роблять режим відмов явним замість невизначеного.

• hard-монти: клієнт повторює I/O безкінечно. Це захищає коректність даних для багатьох навантажень, але може зависати процеси довго. «Безкінечно» — це не настрій; це політика.
• soft-монти: клієнт здається і повертає помилку додатку після спроб. Це запобігає нескінченним зависанням, але ризикує корупцією даних для певних схем запису (додатки не очікують часткових невдач).

Більші серйозні Linux-команди використовують hard, але налаштовують таймаути й застосовують розумний automount, щоб зменшити радіус ураження. Якщо ви запускаєте бази даних поверх NFS, ви вже знаєте, що це особливий біль, який працює лише при дуже суворій дисципліні.

Блокування: NFSv3 vs NFSv4 і чому додаток це відчуває

Блокування файлів у NFSv3 історично включало окремі сервіси (lockd/statd). Якщо вони неправильно налаштовані, фільтруються фаєрволом або ламаються NAT, ви можете отримати поведінку «працює, але іноді ні», яка виглядає як випадкові зависання.

NFSv4 інтегрує блокування в протокол і зазвичай рекомендується для нових проєктів. Але NFSv4 — це stateful: сервер і клієнт відслідковують сесії та блокування. Якщо мережа флапає, ви можете отримати прострочення лізингів, шторми відновлення і додатки, що стоять у очікуванні, поки стан не звідновиться.

Кешування клієнта та узгодженість атрибутів

Клієнти NFS кешують дані та атрибути. Це добре; інакше ваш метадантажний сервер би «згорів». Але це означає, що «я створив файл, а інший хост його не бачить» може бути очікуваною поведінкою, якщо параметри кешування атрибутів агресивні.

На Linux опції монтування як actimeo, acregmin, acregmax і семантика v4 навколо делегацій впливають на те, чи отримаєте ви швидке читання чи консистентні читання. Оберіть неправильно — і ваші збірки поводитимуться як будинок з привидами.

Два сигнатури відмов NFS, що часто з’являються

• Stale file handle: серверні зміни в файловій системі (наприклад, переміщення експорту, повторне використання inode, відкат снапшоту, фейловер без стабільних file handles) інвалідують посилання клієнта.
• Recovery storms: після перезавантаження сервера або мережевого збою багато клієнтів одночасно відновлюють стан, роблячи сервер повільним, через що клієнти відступають, і ситуація погіршується. Вітаємо, ви створили трафік.

Як SMB реально поводиться при збоях

SMB за замовчуванням розмовний, але сучасний SMB розумніший, ніж ви думаєте

SMB має репутацію серед Linux-фахівців як «той Windows-протокол». Насправді SMB3 — це потужний протокол з фішками, яких NFS часто не має «з коробки»: багатша семантика ACL, зріла інтеграція з Active Directory, шифрування та деякі високопродуктивні опції як multichannel.

Але SMB також несе важку експлуатаційну плату: ідентичність, DNS, синхронізація часу, контролери домену й політики. Коли SMB зависає, це часто не «сховище». Це автентифікація, вирішення імен або функція безпеки, що робить саме те, для чого її налаштовано.

Типові шаблони зависань SMB на Linux-клієнтах

• Проблеми з оновленням облікових даних або квитків: Kerberos-квитки спливають, оновлення не проходять, і монтування дивно сповільнюється або видає помилки.
• Проблеми з DNS / SPN: ім’я сервера, яке використовують клієнти, не збігається з тим, що очікує Kerberos, що призводить до fallback-автентифікації або повторних невдач.
• Накладні витрати на підписування/шифрування: якщо підписування обов’язкове скрізь, а CPU слабкі або зайняті, SMB стає криптографічним бенчмарком, замаскованим під файловий I/O.
• Сюрпризи oplocks/leases: кешування клієнта SMB (oplocks/leases) може покращити швидкість, але також викликати моменти «чому цей файл заблокований», коли додатки очікують POSIX-подібну семантику.

Права доступу в SMB: прихований айсберг

Якщо вам потрібні ACL у стилі Windows і узгоджена поведінка з AD-ідентичностями, SMB зазвичай є найчистішим шляхом. NFS також може це робити з NFSv4 ACL і idmapping, але «може» і «приємно» — різні слова.

На Linux-клієнтах, що монтують SMB-шари через cifs, ви часто відображаєте Windows-ACL у POSIX-представлення дозволів. Це відображення може вводити в оману інструменти. Користувачі бачать, що chmod «вдалося» і припускають, що щось змінилося; можливо, ні. Ця плутанина породжує інциденти, ескалації і ваші дзвінки.

Жарт №1: SMB означає Server Message Block, але в чаті інцидентів іноді відчувається як «Seriously, My Build».

Вибір протоколу: правила, що працюють о 3:00

Якщо у вас Linux→Linux і ви хочете мінімум драми: за замовчуванням NFSv4.1+

Для Linux-клієнтів і Linux або корпоративного NAS-сервера NFSv4.1 (або новіший) зазвичай є найпростішим і надійним вибором. Він добре підтримується, продуктивний і не вимагає повного Windows-світу ідентичностей.

Використовуйте його коли:

• Вам потрібні прямі POSIX-семантики в більшості випадків.
• Ви можете керувати невеликим набором експортів і клієнтів.
• Вам важлива продуктивність на CPU і передбачувана поведінка під навантаженням.
• Ви можете впровадити Kerberos, якщо дані цього варті.

Якщо джерело ідентичності — Active Directory і головні клієнти — Windows: обирайте SMB3

Якщо бізнес живе в AD (життєвий цикл користувача, групові політики, Windows-клієнти), SMB — це шлях найменшого опору. Samba також може обслуговувати Linux-клієнти, але центр тяжіння залишається Windows-семантикою та інструментами.

Використовуйте його коли:

• Потрібна сумісність з NTFS-ACL і очікування аудиту.
• Потрібний узгоджений досвід між Windows і Linux-клієнтами на одному шарі.
• Потрібне шифрування SMB, бо ви не контролюєте шлях мережі.

Коли «випадкові зависання» неприйнятні, віддавайте перевагу протоколу, про відмови якого ви зможете повідомити додатку

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

Якщо ви запускаєте пакетні завдання, де краще швидко впасти, ніж зависнути, можна обґрунтовано вибрати SMB зі строгими таймаутами або NFS з обережно продуманими soft-поведінками (але будьте консервативні).

Не змішуйте протоколи на одному файломістеному бекенді, якщо не знаєте семантику

Подавання однієї директорії одночасно через NFS і SMB — класична пастка. Семантика блокувань і кешування може розходитись. Якщо мусите так робити, протестуйте саме ті поведінки додатків, що вам важливі (шаблони перейменувань, атомарні записи, блокування файлів і видимість змін у директорії).

Жарт №2: Єдине гірше, ніж завислий NFS-монтаж — це засідання під назвою «Давайте стандартизувати обмін файлами».

Швидкий плейбук діагностики

Немає часу милуватися проблемою. Потрібно локалізувати її: клієнт, мережа, сервер або ідентичність. Ось порядок, що мінімізує даремні рухи.

Перше: підтвердіть, що це мережевий файловий шар і який саме

• Знайдіть тип монтування та опції монтування. Підтвердіть, чи процеси заблоковані на цьому монтуванні.
• Перевірте, чи система має загальні очікування I/O або лише підмножину потоків.

Друге: визначте, чи ви заблоковані на I/O, DNS/auth чи серверному сховищі

• Для NFS: шукайте RPC-таймаути, «server not responding», retransmits і stale file handles.
• Для SMB: шукайте помилки автентифікації, спроби перепідключення, накладні витрати на підписування/шифрування і проблеми вирішення імен.

Третє: ізолюйте однією контрольованою операцією

• Прочитайте невеликий файл із шару.
• Зробіть stat директорії з великою кількістю записів (стрес метаданих).
• Створіть і fsync невеликий файл (стрес семантики запису).

Якщо метадані повільні, але читання в порядку, ймовірно, у вас інші вузькі місця, не «мережа повільна». Якщо читання повільні, а метадані в порядку, швидше за все ви насичуєте диски сервера або пропускну здатність мережі.

Четверте: перевірте точки насичення

• Клієнт: CPU, softirq і TCP retransmits.
• Мережа: втрати, помилки, невідповідність MTU, затори.
• Сервер: CPU, NIC, затримки дисків, пул потоків NFS/SMB, бекенди автентифікації.

П’яте: оберіть безпечну міру пом’якшення

• Якщо це тимчасова проблема сервера: зменшіть навантаження клієнтів, обмежте швидкість пакетних завдань або віддайте на фейловер, якщо є HA.
• Якщо це опція монтування на клієнті: змініть її на одному канарковому хості, а не на всьому флоті.
• Якщо це auth/DNS/час: виправте ідентичнісний ланцюг перед тим, як чіпати налаштування сховища.

Практичні завдання: команди, виводи, рішення

Це реальні завдання, які ви можете виконати на Linux-клієнті або сервері. Кожне містить, що означає вивід і яке рішення ухвалити.

1) Визначити тип файлової системи та опції монтування

cr0x@server:~$ findmnt -t nfs,nfs4,cifs -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET   SOURCE                FSTYPE OPTIONS
/mnt/fs  nas01:/export/builds  nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys
/mnt/hr  //files01/hr          cifs   rw,relatime,vers=3.1.1,cache=strict,username=svc-linux,seal,sign,uid=1000,gid=1000

Значення: Ви підтвердили, з яким протоколом маєте справу і яку поведінку обрали (наприклад, hard для NFS). Зверніть увагу на режим безпеки (sec=sys проти seal/sign).

Рішення: Якщо скарги на зависання і NFS змонтований як hard, трактуйте проблеми сервера/мережі як потенційну причину безстрокових блокувань. Для SMB пріоритетом будуть перевірки автентифікації/DNS/політик безпеки.

2) Побачити, хто застряг на монтуванні (і чи вони в D-state)

cr0x@server:~$ ps -eo pid,stat,comm,wchan:30,args | egrep ' D |nfs|cifs' | head
24817 D    tar            nfs_wait_on_request          tar -cf /mnt/fs/archive.tar /mnt/fs/work
25002 D    python3        cifs_writepages              python3 ingest.py
 1121 Ss   nfsiod         nfsiod                       [nfsiod]
 1124 Ss   cifsiod        cifsiod                      [cifsiod]

Значення: D означає незмінний сон (uninterruptible sleep), зазвичай очікування I/O. wchan підказує, яка підсистема блокує (NFS vs CIFS).

Рішення: Якщо багато процесів в D-state, не перезапускайте додаток спочатку. Ви лише створите більше заблокованих потоків. Виправляйте підлягаючу затримку.

3) Перевірити логи ядра на підказки щодо NFS/SMB

cr0x@server:~$ dmesg -T | egrep -i 'nfs:|cifs|smb|server not responding|stale|reconnect|rpc'
[Mon Feb  3 10:14:22 2026] NFS: server nas01 not responding, still trying
[Mon Feb  3 10:14:52 2026] NFS: server nas01 OK
[Mon Feb  3 10:18:06 2026] CIFS: VFS: \\files01 has not responded in 180 seconds. Reconnecting...

Значення: NFS і CIFS логують свій біль. «still trying» — це попередження: hard-монти чекатимуть. SMB reconnects можуть затримувати операції й підсилювати затримки.

Рішення: Якщо бачите повтори «not responding», переключайте увагу на здоров’я мережі/сервера. Якщо бачите цикли reconnect у SMB, перевіряйте вирішення імен, автентифікацію і доступність сервера.

4) Статистика клієнта NFS: retransmits і RPC-поведінка

cr0x@server:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
1839201    1843       0

Client nfs v4:
null             read             write            commit
0                923114           11822            11822
open             open_conf        close            setattr
224              0                214              19

Значення: Retransmits не завжди погані, але якщо вони різко зростають під час інциденту, ваш вузький місце часто — втрата пакетів, затори або перевантажений сервер, що не встигає відповісти вчасно.

Рішення: Якщо retrans швидко зростає — не «настройте rsize», а почніть розслідування втрат мережі, невідповідності MTU або насичення сервера.

5) Перегляд експорту NFS на сервері і відповідність клієнтів

cr0x@server:~$ showmount -e nas01
Export list for nas01:
/export/builds 10.20.0.0/16
/export/home   10.30.14.0/24

Значення: Підтверджує, що експорт існує і підмережа клієнта дозволена.

Рішення: Якщо інцидент почався після переміщення мережі, перевірте, чи IP клієнта все ще в дозволеному діапазоні. «Раніше працювало» — не конфігураційний стан.

6) Перевірити узгодження версії NFS і ідентичність сервера

cr0x@server:~$ rpcinfo -p nas01 | egrep 'nfs|mountd|nlockmgr'
100003    4   tcp   2049  nfs
100003    3   tcp   2049  nfs
100005    3   tcp  20048  mountd
100021    4   tcp  4045   nlockmgr

Значення: Показує, які версії протоколу доступні. Якщо ви очікували тільки v4, а бачите v3, клієнти можуть використовувати v3, якщо не зафіксовані явно.

Рішення: Зафіксуйте версію у опціях монтування для консистентності, особливо при змішаних клієнтах.

7) Перевірити «stale file handle» і вирішити, чи треба перемонтувати

cr0x@server:~$ ls -l /mnt/fs/work
ls: cannot access '/mnt/fs/work': Stale file handle

Значення: Клієнт має file handle, який більше не співпадає з об’єктом на сервері. Часта причина — відкат, переміщення експорту, відновлення або певні фейловери.

Рішення: Зазвичай потрібне перемонтування. Також дослідіть, що змінилося на сервері; stale handles — симптом операційних дій, а не випадковість.

8) Видимість SMB-сесій клієнта (що ми погодили?)

cr0x@server:~$ smbstatus -b
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption  Signing
26341   svc-linux    linux         10.20.4.18 (ipv4:10.20.4.18:51234)        SMB3_11           AES-128-GCM required   required

Значення: Підтверджує діалект SMB і чи активні шифрування/підписування. Якщо продуктивність погана, це скаже, чи платите ви криптовитрати.

Рішення: Якщо шифрування обов’язкове і CPU високе на сервері/клієнті, розгляньте виділені файлові сервери з AES-NI або обмежте шифрування до чутливих шарів (за політикою).

9) Перевірити вирішення імен і проблему «неправильного сервера»

cr0x@server:~$ getent hosts files01
10.40.2.10  files01.corp.example files01

Значення: Підтверджує, який IP використовуватиме ваш клієнт. Зсув DNS може направляти клієнтів на списаний вузол, DR-ціль або балансувальник, що не підтримує SMB sticky-поведінку.

Рішення: Якщо IP несподіваний — виправляйте DNS спочатку. Не чіпайте опції монтування, поки ви розмовляєте з неправильним сервером.

10) Перевірити TCP-retransmits і помилки NIC на клієнті

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8123456      0     120       0  12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109  7456789      0       0       0      0

Значення: Drop-и можуть корелювати із затримками NFS/SMB. Втрати не завжди фатальні, але постійні drop-и під навантаженням — це проблема надійності, а не «можливість для тонкої настройки».

Рішення: Якщо drop-и ростуть під час інцидентів, перевірте розміри кілець NIC, затори на комутаторі, softirq CPU і відповідність MTU по всьому шляху.

11) Виміряти MTU шляху (мовчазна фрагментація бреше)

cr0x@server:~$ ping -M do -s 1472 nas01 -c 2
PING nas01 (10.20.1.50) 1472(1500) bytes of data.
1472 bytes from 10.20.1.50: icmp_seq=1 ttl=63 time=0.621 ms
1472 bytes from 10.20.1.50: icmp_seq=2 ttl=63 time=0.608 ms

--- nas01 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Значення: Підтверджує, що MTU 1500 працює без фрагментації. Якщо застосовуються jumbo-кадри, тестуйте й більші розміри.

Рішення: Якщо більші payload-и падають — можлива невідповідність MTU, що проявляється як «випадкові зависання під навантаженням», особливо для великих I/O.

12) Швидка перевірка пропускної здатності (тест читання)

cr0x@server:~$ dd if=/mnt/fs/bigfile.bin of=/dev/null bs=8M count=64 status=progress
536870912 bytes (537 MB, 512 MiB) copied, 0.92 s, 583 MB/s
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0.92 s, 581 MB/s

Значення: Орієнтовна перевірка пропускної здатності читання. Якщо це швидко, але ваш додаток повільний, швидше за все проблема в метаданих, блокуваннях або дрібному I/O.

Рішення: Не «чініть сховище», якщо послідовний шлях читання в порядку. Профілюйте метадані й шаблони доступу додатку.

13) Стрес-тест метаданих (затримка переліку директорії)

cr0x@server:~$ time ls -U /mnt/fs/workdir > /dev/null

real    0m12.418s
user    0m0.012s
sys     0m0.824s

Значення: 12 секунд на перерахунок директорії вказує на вузьке місце метаданих: CPU сервера, дискові seek-и, забагато дрібних файлів або поведінка кешування атрибутів.

Рішення: Якщо метадані повільні, подумайте про реорганізацію навантажень, використання локального кешу, або масштабування метаданного шару (CPU, RAM, SSD для метаданих, кращий NAS). Налаштування rsize вас не врятує.

14) Підтвердити опції SMB-монту на клієнті (і чи консистентні семантики кешу)

cr0x@server:~$ grep -E 'cifs|smb3' /proc/mounts
//files01/hr /mnt/hr cifs rw,relatime,vers=3.1.1,cache=strict,username=svc-linux,uid=1000,gid=1000,seal,sign,soft,nounix,serverino 0 0

Значення: Ви бачите, чи використовуєте cache=strict (зазвичай безпечніше), діалект SMB і прапори безпеки як seal (шифрування).

Рішення: Якщо бачите старі діалекти або дозволяючі режими кеша, плануйте оновлення/затягування. Якщо шифрування увімкнене і продуктивність погана — виміряйте CPU і розгляньте зміну політики.

15) Перевірити iowait і softirq CPU (мережевий стек під навантаженням)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server)  02/03/2026  _x86_64_  (8 CPU)

12:02:11 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:02:12 PM  all   12.3  0.0  8.1   31.7    0.0  9.8    0.0  38.1
12:02:13 PM  all   11.8  0.0  7.9   33.0    0.0  10.2   0.0  37.1

Значення: Високий %iowait може означати очікування на сховище; високий %soft свідчить про навантаження мережевої обробки. Обидва можуть сприяти «зависанням».

Рішення: Якщо softirq високий під час шифрування SMB або інтенсивного NFS-трафіку, розгляньте масштабування CPU, налаштування RSS або offload NIC — обережно й після тестування.

16) Перевірити затримки диска на сервері (якщо контролюєте сервер)

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (nas01)  02/03/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.40    0.00    6.20   18.10    0.00   63.30

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0   180.0  8800.0  7200.0   2.1   0.4   16.0
sda              15.0    90.0   300.0  1800.0  48.7   2.5   85.0

Значення: await і %util вказують на дискову конкуренцію. Одна зайнята шпиндель може зіпсувати день усім, якщо на ній розміщені метадані або журнали.

Рішення: Якщо один пристрій завантажений, виправте розклад сховища (перемістіть метадані/журнали, додайте SSD, ребаланс, виправте RAID-проблеми) перед тим, як чіпати прапори протоколу.

Три міні-історії з корпоративного світу

Інцидент через хибне припущення: «NFS безстанний, тож фейловер тривіальний»

Середня компанія зберігала артефакти збірок на NFS-експорті, підживленому кластерним сховищем. Команда платформи припустила, що оскільки NFSv3 «безстанний», фейловер між контролерами буде безшовним. Вони протестували ручний фейловер за обідом. Здавалось, усе гаразд. Оголосили успіх і перейшли далі.

Через тижні справжній фейловер контролера стався під час релізу. Збірки почали висіти. Не падати — висіти. CI-агенти накопичувалися, черга часу зросла. На черговому перегляді побачили, що експорт все ще змонтований скрізь, тож вирішили, що сховище «вгору», і перезапустили агенти. Це лише породило більше заблокованих I/O.

Справжня причина: файлова система за експортом перемістилася так, що змінила відображення file handle для деяких директорій. Клієнти почали кидати stale file handle для деяких шляхів і безкінечні повтори для інших. Гірше, система збірок використовувала багато операцій перейменування й stat, що підсилювало метадані виклики. Клієнти застрягли в спробах і перевірках.

Виправлення було неефектним: стандартизували NFSv4.1 з правильними сесіями, увімкнули стабільні file handles на стороні сховища і — найважливіше — задокументували, що робить фейловер для клієнтських монтувань. Також додали канаркову задачу, яка навантажує метадані й попереджає, якщо латентність росте після фейловерів.

Урок: «безстанний» не означає «імунітет до проблем, пов’язаних зі станом». Ваш стан застосунку все одно існує, кеш клієнта існує, і сервер має співставляти handles з реальними об’єктами.

Оптимізація, що обернулася проти: «увімкнемо шифрування SMB всюди; безпека буде задоволена»

Глобальне підприємство вирішило вимагати шифрування SMB3 на всіх шарах, включно з шарами для масового розповсюдження ПЗ. Намір був добрий: чутливі дані існують, і вони не хотіли довіряти кожному сегменту мережі вічно. Політику змінили на боці Windows і оновили конфіги Samba.

За кілька днів Linux-хости, що монтували шари з seal, почали повідомляти про переривчасті затримки в пікові години. Копіювання, яке раніше займало хвилини, тепер тривало набагато довше, а інтерактивні завдання «липли». Нічого не було впавшим. Усе було просто… досить повільне, щоб звинуватити «мережу».

Вони шукали MTU, комутатори, навіть масиви зберігання. Підказка була на файлових серверах: CPU були завантажені, зокрема в крипто-шляхах, і softirq обробка зросла. Шифрування не просто додало накладні витрати; воно перемістило вузьке місце з дисків на CPU. Під навантаженням черги дали довгі хвости, які користувачі відчували як зависання.

Угоди були прагматичні: шифрування лишилося обов’язковим для чутливих шарів і опційним для масового розповсюдження всередині довірених зон мережі. Також оновили файлові сервери до CPU з кращим AES-прискоренням і налаштували multichannel SMB, де доречно.

Урок: функції безпеки не безкоштовні. Якщо не виміряти запас CPU і хвильові латентності, можна «зашифрувати» свої шари до невикористовності.

Нудна, але правильна практика, що врятувала день: «autofs з розумними таймаутами і канаркою»

Команда фінтех мала одночасно NFS (домашні каталоги Linux, інструменти) і SMB (міжплатформні командні шари). Раніше їх палили зависання монтів, тож вони ставилися до мережевих файлових систем як до залежностей, а не як до локальних дисків.

Використовували autofs для користувацьких монтувань і уникали монтування критичних шарів на завантаженні, якщо система не могла терпіти блокування. Також встановили явні версії NFS і консервативні таймаути, і тестували, що відбувається, коли сервер зникає. Тест не був теоретичним; вони фізично відключали шляхи в стажувальному середовищі.

Коли під час технічного обслуговування випадково впав нод сховища, більшість сервісів лишилися здоровими, бо вони не блокувалися під час завантаження або під час не пов’язаних операцій. Канарка спрацювала: латентність метаданих на шарі перейшла поріг, і черговий чітко побачив «це проблема залежності від сховища» негайно.

У них все ще були впливи на робочі потоки, що залежали від шару. Але інцидент залишився локалізованим. Ніяких каскадних відмов. Ніяких «перезапустіть усе». Лише чітке збійне повідомлення по залежності й зрозуміле відновлення.

Урок: нудні практики — automount, явні версії, канарки — не виглядають героїчними. Вони запобігають геройствам.

Поширені помилки (симптом → корінь → виправлення)

1) Симптом: процеси застрягли в D-state, kill -9 не допомагає

Корінь: Hard-монт NFS (або заблокований CIFS I/O), що чекає на сервер/мережу. Ядро чекає завершення I/O.

Виправлення: Відновіть підключення сервера/мережі. Якщо треба відновити хост, відмонтуйте безпечно (umount) після відновлення зв’язку, або використовуйте lazy-унмонт лише як останній засіб і очікуйте наслідків.

2) Симптом: «Stale file handle» після обслуговування

Корінь: Серверна файлова система/експорт змінився (відкат, відновлення снапшоту, переміщення експорту, фейловер без стабільних handles).

Виправлення: Перемонтуйте уражені клієнти. На боці сервера забезпечте стабільні file handles під час фейловеру і уникайте відкатів на живих експортованих даних без погодженого плану перемонтування клієнтів.

3) Симптом: SMB-монти періодично гальмують, особливо по годинах

Корінь: Оновлення Kerberos-квитків або зсув часу; повторні спроби автентифікації і перепідключення блокують операції.

Виправлення: Переконайтесь, що NTP налаштовано правильно. Перевірте конфігурацію Kerberos і SPN. Використовуйте Kerberos коректно з правильним DNS і сервісними іменами, а не крихкими обхідними шляхами.

4) Симптом: відмінна послідовна пропускна здатність, погане «ls» і «find»

Корінь: Вузьке місце метаданих: забагато дрібних файлів, CPU сервера, повільні диски для метаданих або недостатнє кешування.

Виправлення: Рефакторинг навантаження (збирайте артефакти в пакети, використовуйте локальний кеш), покращіть шар метаданих (SSD), або масштабування CPU/RAM сервера. Налаштування протоколу рідко вирішить проблему, пов’язану з метаданими.

5) Симптом: SMB-шар повільний лише при увімкненій політиці безпеки

Корінь: Підписування/шифрування або інспекція пакетів; CPU стає вузьким місцем.

Виправлення: Виміряйте CPU і хвостові латентності. Використовуйте обладнання з крипто-прискоренням, увімкніть multichannel де доречно і обмежте область застосування шифрування відповідно до чутливості даних та довіри до мережі.

6) Симптом: NFS працює з деяких підмереж, але не з інших

Корінь: Обмеження експорту, правила фаєрволу або блокування служб RPC (особливо для NFSv3 блокаючих сервісів).

Виправлення: Віддавайте перевагу NFSv4 (один відомий порт 2049) для зменшення складності фаєрволу. Вирівняйте правила експорту з реальними підмережами клієнтів і задокументуйте їх.

7) Симптом: Змішаний доступ Linux/Windows викликає «файл заблоковано» дивності

Корінь: Подача одного набору даних через NFS і SMB з різною семантикою блокувань/кешування.

Виправлення: Уникайте подвійного протоколу на тому ж живому наборі даних, якщо платформа зберігання явно не підтримує когерентні блокування між протоколами і ви не протестували саме ті шаблони додатків.

8) Симптом: випадкові зависання під навантаженням після «увімкнення jumbo frames»

Корінь: Невідповідність MTU десь на шляху; чорнорудні великі пакети викликають ретрансмісії і затримки.

Виправлення: Перевірте MTU по всьому шляху. Використовуйте ping -M do тести до сервера з клієнтів. Не вводьте jumbo frames частково.

Чеклісти / покроковий план

Чекліст вибору протоколу (обирайте з метою)

1. Клієнти: Більшість Linux? Схиляйтесь до NFSv4. Більшість Windows/AD? Схиляйтесь до SMB3.
2. Модель дозволів: Потрібна точна NTFS ACL-фіделіті і Windows-інструменти? SMB. Потрібні POSIX-перші семантики? NFS.
3. Толерантність до відмов: Що гірше — зависання чи падіння? Розгляньте таймаути і поведінку додатків; не припускайте, що за замовчуванням усе підходить.
4. Безпека: Якщо потрібне шифрування в каналі, SMB3 має це як «першокласну» опцію. NFS може робити Kerberos або тунелювання, але операційна складність зростає.
5. Мережева реальність: Нестабільні лінії і флапаючі мережі карають stateful-семантику. Віддавайте перевагу стабільності і інструментуйте шлях.
6. Операційна відповідальність: Хто буде дебажити о 3:00? Обирайте стек, яким ваша команда реально зможе оперувати.

NFS production hardening кроки

1. Стандартизуйте на NFSv4.1+, якщо немає специфічної потреби у v3.
2. Зафіксуйте версії та опції монтування, щоб поведінка не дрейфувала між дистрибутивами.
3. Використовуйте automount для користувацьких шарів, щоб уникнути зависань при завантаженні і зменшити радіус ураження.
4. Інструментуйте retransmits і латентність (клієнт nfsstat, метрики сервера).
5. Плануйте фейловери: тестуйте поведінку stale handle; документуйте процедури перемонтування; забезпечте стабільні file handles, якщо платформа підтримує.
6. Свідомо вирішуйте hard vs soft: hard для коректності; soft — лише коли додатки витримують помилки і ви приймаєте ризик.

SMB production hardening кроки

1. Вимагайте SMB3; відключіть застарілі діалекти.
2. Визначте область підписування/шифрування і перевірте запас CPU при пікових навантаженнях.
3. Переконайтесь у коректності DNS і синхронізації часу перед тим, як дорікати сховищу.
4. Використовуйте Kerberos правильно в AD: SPN, імена сервісів і стабільні імена хостів важливі.
5. Перевіряйте опції монтування клієнтів (cache=strict, діалект, прапори безпеки) і тримайте їх уніфікованими по флоту.
6. Тестуйте поведінку oplocks/leases з вашими додатками, якщо бачите проблеми з блокуваннями або застарілими читаннями.

План міграції (коли ви змінюєте протоколи)

1. Зробіть інвентар шаблонів доступу: послідовні, метадані-важкі, з блокуванням, редагування між платформами.
2. Виберіть канаркову групу (декілька хостів, декілька користувачів) і визначте метрики успіху (p95 латентність, рівень помилок, час збірки).
3. Робіть dual-write лише якщо справді треба, і якщо так — розумійте ризики консистентності.
4. Відключайте поетапно, тримайте просте відкат-варіант (DNS alias, зміни у mount maps) і документуйте оперативний плейбук.
5. Після cutover видаліть старі монти, щоб не дебажити дві системи вічно.

Питання й відповіді

1) Що більше «зависає»: NFS чи SMB?

Обидва можуть. NFS з hard-монтами зазвичай дає найяскравіший «залипати назавжди», бо ядро буде повторювати спроби безкінечно за замовчуванням. SMB зависання часто пов’язані з проблемами перепідключення/автентифікації/вирішення імен і можуть виглядати переривчастими.

2) Чи варто коли-небудь використовувати soft-монти для NFS?

Інколи, але ставтесь до цього як до роботи з вибухівкою: лише якщо додаток розроблений для коректної обробки помилок I/O і ви віддаєте перевагу падінню перед зависанням. Для багатьох write-heavy або критичних за коректністю навантажень soft може створити приховану корупцію чи часткові записи.

3) NFSv4 завжди кращий за NFSv3?

Для більшості сучасних середовищ — так, особливо для простоти налаштувань фаєрволу і інтегрованого блокування. Але stateful природа NFSv4 може ускладнити відновлення в нестабільних мережах. Якщо у вас є спадщина чи обмеження, v3 ще може бути життєздатним за суворої операційної дисципліни.

4) Чому «ls» по шару відчувається повільніше, ніж копіювання великого файлу?

Бо метадані — це безліч дрібних кругових викликів: lookup, stat, перевірки дозволів, ревалідація. Великі послідовні читання амортизують накладні витрати. Якщо ваше навантаження метадані-важке (дерева збірок, git-клони, мільйони дрібних файлів), потрібно планувати під продуктивність метаданих.

5) Чи можу я подавати ту саму директорію через NFS і SMB?

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

6) Чи гарантує шифрування SMB кращу безпеку, ніж NFS?

SMB3-шифрування просте й широко застосоване. Безпека NFS часто роблять через Kerberos (добре) або на рівні мережі (що може бути прийнятним, якщо ви контролюєте шлях). Кращий вибір залежить від вашого стеку ідентичності і моделі довіри мережі, а не від уподобань протоколу.

7) Який найшвидший спосіб довести, що проблема — мережа, а не диски сервера?

Дивіться на retransmits клієнта і drop-и NIC, і порівнюйте з затримками дисків сервера. Якщо retransmits стрибають, а диски виглядають здоровими — підозрюйте мережу. Якщо диски мають високий await/util і мережа чиста — підозрюйте сховище. Потім валідируйте контрольованим читанням і метаданим тестом.

8) Чому проблеми SMB іноді корелюють зі зміною пароля або оновленням політик?

Тому що SMB у корпоративних середовищах тісно пов’язаний із політикою ідентичності. Ротація облікових даних, зміни політик Kerberos або недоступність контролера домену можуть ламати монти або викликати цикли перепідключення, що проявляються як затримки.

9) Який «найменш поганий» вибір за замовчуванням для нового Linux-флоту?

NFSv4.1+ для Linux→Linux обміну файлами, з automount і явними опціями монтування. Якщо ваша організація AD-first і очікує Windows-ACL-поведінку, обирайте SMB3 і інвестуйте в коректність ідентичності та запас CPU.

Висновок: наступні кроки, які ви можете зробити сьогодні

Перестаньте ставитися до мережевих файлових систем як до локальних дисків із довшим кабелем. Оберіть протокол, що відповідає вашій моделі ідентичності та складу клієнтів, а потім спроєктуйте режим відмов, який ви зможете терпіти.

1. На одному ураженому клієнті, запустіть findmnt, dmesg і ps, щоб визначити, чи маєте ви справу з NFS чи SMB і чи заблоковані процеси в D-state.
2. Виміряйте retransmits і drop-и (NFS: nfsstat; мережа: ip -s link) перед тим, як чіпати налаштування тонкого тюнінгу.
3. Запустіть один тест читання і один тест метаданих, щоб визначити, чи ви впритул до пропускної здатності або до метаданих/блокувань.
4. Стандартизуйте конфігурації: зафіксуйте версії протоколів, опції монтувань і режими безпеки по всіх хостах. Дрейф — шлях, яким «випадковість» потрапляє у ваші постмортеми.
5. Зробіть зависання видимими: поставте канарки для p95/p99 латентності і рівнів помилок на шарах. Ви не зможете управляти тим, чого не бачите, і «скарги користувачів» — не моніторинг.

Якщо ви зробите ці п’ять речей, наступне «випадкове зависання» перетвориться на обмежене розслідування, а не на екзистенційну кризу.