Зберігання: iSCSI проти NFS проти NVMe-oF — що насправді перемагає і чому

Справжнє питання: що ви оптимізуєте?

«Що швидше?» — неправильне перше питання. Ви можете зробити будь-що швидким у лабораторії й зробити це жахливим у продакшн.
Правильне питання: яку відмову ви готові терпіти і яку роботу ви готові робити постійно?

Протоколи зберігання — це пакетна угода:

• Семантика: блочний пристрій проти спільної файлової системи, поведінка блокувань, операції з метаданими.
• Модель конкуренції: один хост записує свій блочний пристрій проти кількох клієнтів, що ділять неймспейс.
• Поведінка відновлення: що відбувається, коли шлях флапає, комутатор втрачає пакети або сервер перезавантажується під час I/O.
• Операційна ергономіка: провізіонування, зміна розміру, снапшоти, мультипатинг, спостережуваність.
• Позиція безпеки: authN/authZ, шифрування, радіус ураження, захист від «о, я зробив помилку».

Якщо ви працюєте з віртуалізацією, базами даних, аналітикою або Kubernetes, ви обираєте не лише протокол, а спосіб життя.
Оберіть той, яким ви зможете керувати о 3:00 ранку напівпрокинуті й з легкою неприязню.

Короткі висновки (суб’єктивна частина)

Обирайте NFS коли…

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

NFS — чемпіон «працює добре достатньо» — поки ви не зловживаєте ним метаданими або не вважаєте мережу безвтратною.

Обирайте iSCSI коли…

• Вам потрібне блочне сховище для одного хоста (або зверху — кластерна файлова система/volume manager).
• Вам потрібен зрілий мультипатинг і широка сумісність з ОС, гіпервізорами та масивами зберігання.
• Ви готові дотримуватися операційної гігієни: таймаути, політики шляхів і моніторинг.

iSCSI — надійний седан мережевого зберігання. Це не модно. Але зазвичай це не причина провалу SLO — якщо ви не налаштуєте його як лабораторну іграшку.

Обирайте NVMe-oF коли…

• Ваше навантаження чутливе до латентності й вже оптимізоване локально (бази даних, індексація з високою частотою, масштабний лог-інжест).
• У вас є чиста, низьковтратна мережа і ви можете виправдати операційну складність.
• Ви готові ставитися до fabric як до першокласної системи: телеметрія, контроль заторів і ретельне керування змінами.

NVMe-oF може бути приголомшливим. Він також може приголомшливо принизити, коли невелика втрата пакетів перетворює вашу мрію «майже локального NVMe» на генератор тікетів.

Якщо потрібне одне правило за замовчуванням: Обирайте NFS для спільних файлів, iSCSI для загального блоку, NVMe-oF — лише коли ви доведете потребу й готові його оперувати.

Цікавинки та історичний контекст (щоб ви не повторювали старі помилки)

1. NFS з’явився ще до вашого хмарного бюджету. NFS вперше з’явився в середині 1980-х у Sun Microsystems, створений щоб мережі відчувалися як локальні файлові системи.
2. NFSv3 здобув популярність завдяки простоті. Його безстанова архітектура допомогла серверам масштабуватися й відновлюватися, але перенесла складність на клієнти (і блокування до бічних протоколів).
3. NFSv4 взявся за стан серйозно. Він ввів інтегроване блокування і сильніші механізми безпеки, поступившись простотою заради коректності і кращої поведінки в WAN.
4. iSCSI народився, щоб вбити «спеціальні мережі». З’явився на початку 2000-х, щоб запускати SCSI поверх TCP/IP і дозволити SAN використовувати Ethernet замість FC.
5. Jumbo frames колись були символом статусу. Багато команд вмикали MTU 9000 без перевірки шляху; невідповідності досі викликають фрагментацію й падіння пакетів.
6. NVMe спроектовано для паралелізму. NVMe використовує множинні черги, щоб зменшити блокування і використовувати сучасні CPU — на відміну від старих стеків для обертальних дисків.
7. NVMe-oF — це не одне протокол. Це сімейство: транспорти RDMA (RoCE/iWARP/InfiniBand) та TCP. TCP часто простіше розгорнути; RDMA може дати нижчу латентність, але вимогливіший.
8. «NAS проти SAN» — здебільшого політична війна. Реальний поділ — семантика файлів проти блоку — і який шар контролює кешування, блокування та узгодженість.
9. Мультипатинг був ще до ваших контейнерів. Шаблони MPIO були відточені в епоху двоконтролерних масивів і ненадійних HBA; уроки залишаються актуальними.

Як це працює насправді (і де болить)

NFS: семантика віддаленої файлової системи

З NFS клієнти запитують сервер про файлові операції: open, read, write, getattr, readdir, lock (у v4) тощо.
Сервер керує авторитетним неймспейсом і метаданими. Клієнти агресивно кешують, щоб зменшити кількість кругових поїздок.

Великий плюс: спільний неймспейс і тривіальне провізіонування. Експортуєте директорію, монтуєте — готово.
Велика пастка: латентність метаданих і поведінка узгодження кешів стають проблемами продуктивності та коректності.
NFS може добре працювати на послідовній пропускній здатності й одночасно «розтанути» на сценаріях з мільйонами дрібних файлів.

iSCSI: блочний пристрій поверх TCP

iSCSI інкапсулює SCSI-команди поверх TCP. Клієнт (ініціатор) бачить віддалений LUN як локальний блочний пристрій.
Файлові системи, LVM, RAID, бази даних — все це лежить над ним, як на локальних дисках.

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

NVMe-oF: семантика NVMe через fabric

NVMe-oF переносить набір команд NVMe по мережі. Порівняно з iSCSI, він зазвичай зменшує накладні витрати протоколу і підтримує глибокий паралелізм.
На практиці ви можете наблизитися до локальної латентності NVMe — особливо з RDMA — але лише якщо мережа поводиться.

Біль не в «новизні» (вона вже не така нова). Біль у тому, що він піднімає очікування.
Коли латентність падає, стає помітним наступне вузьке місце: планування CPU, IRQ-affinity, TCP-конгестія, шумні сусіди, прошивка масивів — що завгодно.

Жарт №1: NVMe-oF обіцяє «локальну продуктивність». Так само, як кожне резюме, яке я коли-небудь бачив.

Реальність продуктивності: латентність, IOPS, пропускна спроможність

Латентність: єдина метрика, в яку справді вірить ваша база даних

Якщо ваше навантаження транзакційне, розподіл латентності важливіший за пікові IOPS. Медіана — недостатня; хвостова латентність вас погубить.
Накладні витрати протоколу, джиттер мережі, глибина черг і ретрансміти з’являються як спайки p95/p99.

• NFS: часто відмінний для великих послідовних читань/записів, але метадані та синхронні записи можуть бути дорогими залежно від сервера та опцій монтування.
• iSCSI: зазвичай стабільний і передбачуваний; мультипатинг більше допомагає доступності, аніж скорочує латентність.
• NVMe-oF: має найкращий потенціал по латентності; також найшвидший спосіб виявити, що ваша мережа не така чиста, як ви думали.

IOPS: що маркетинг любить, а SRE — підозрює

«IOPS» без розміру блоку, міксу чит/запис, глибини черги й розподілу латентності — марна інформація.
Протокол все ж формує те, наскільки ефективно транспортується дрібний I/O.

NVMe-oF краще працює з великими глибинами черг і паралелізмом. iSCSI теж може давати великі IOPS, але CPU-навантаження і обробка SCSI-команд можуть проявитися раніше.
Продуктивність NFS залежить сильно від кешування клієнтів, кількості потоків сервера та того, чи ваше навантаження більше про дані чи метадані.

Пропускна здатність: легка перемога з простими підводними каменями

Для масового throughput важливіше 10/25/40/100GbE, ніж вибір протоколу. Також: узгодженість MTU по всьому шляху, NIC offloads і неперетиснення uplink-ів у чорну діру.

Найпоширеніша причина провалу throughput — не «протокол повільний». Це «один порт комутатора помилково працює» або «одне посилання у LAG напівпомирає» або «масив робить фонова відбудову».

Вартість CPU: прихований податок

iSCSI і NFS обидва працюють поверх TCP, отже CPU стає частиною рахунку за зберігання. NVMe-oF поверх TCP — схоже; NVMe-oF поверх RDMA може знизити CPU-навантаження, але підвищити операційні вимоги.
Якщо ви на спільних обчислювальних вузлах, цей CPU-податок реальний: він відбирає ресурси у прикладних потоків і піднімає латентність.

«Надія — це не стратегія.» — перефразована ідея, яку часто цитують в інженерії та експлуатації

Режими відмов, з якими ви зіткнетесь у продакшн

NFS: коли сервер чхає — клієнти простуджуються

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

• Stale file handles: типово після змін експорту на сервері, відновлення файлової системи або фейловерів, які не зберегли ідентичність inode.
• «Завислий» I/O: клієнти чекають на відповіді сервера, часто через втрату мережі, виснаження потоків сервера або конкуренцію за блокування.
• Metadata storms: системи збірки, менеджери пакетів і «дай-складати-мільйони-дрібних-об’єктів-у-файли» рішення.

iSCSI: смерть від таймаутів і часткових відмов

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

• Path flapping: переривчасті проблеми посилання, що викликають часті переключення й стрибки латентності.
• Queueing collapse: I/O наростає за заблокованим шляхом; коли відбувається failover, ви вже в стані paging.
• Split-brain access: кілька ініціаторів пишуть на один LUN без координації (це не «можливо», це «коли»).

NVMe-oF: мережа тепер ваш бекплейн

NVMe-oF сяє, коли ви можете ставитися до fabric як до високоякісної внутрішньої шини. Але Ethernet — демократія пакетів; йому байдуже на ваші цілі латентності.
Конгестія, мікроберсти, налаштування ECN, поведінка буферів і прошивка NIC — все має значення.

• Чутливість до втрати пакетів: навіть невеликі рівні втрат можуть підняти хвостову латентність, особливо під навантаженням.
• Неправильний мультипатинг: асиметрія або невірні політики ведуть до «гарячих» шляхів і непередбачуваної продуктивності.
• Проміжок спостережуваності: команди розгортають NVMe-oF раніше, ніж можуть пояснити латентність по кожній черзі та ретрансміти.

Жарт №2: Люди, що працюють зі сховищами, люблять «п’ять дев’яток», поки команда мережі не спитає, які саме п’ять хвилин ви готові втратити.

Три корпоративні історії з окопів

Інцидент: неправильне припущення («То ж просто mount»)

Середня за розміром компанія запускала CI-збірки на флоті Linux-воркерів. Вони зберігали артефакти збірки на NFS-шарі, бо це було легко керувати й чистити.
Хтось помітив, що шар «недовантажений», і вирішив консолідувати: перемістити домашні директорії, кеші збірок і логи додатків на той самий експорт.

Неправильне припущення було тонке: вони вважали, що NFS поводиться як локальний диск під навантаженням метаданими. Це не так.
CI-навaнтаження створило бурю створень файлів, stat, перейменувань і видалень. Домашні директорії додали постійну фонoву активність дрібних читань і записів.
Логи додали синхронні додатки та сплески при ротації.

Симптоми були заплутаними. CPU на воркерах ріс, але не в стилі «активна компіляція» — скоріше «заблоковані в D стані».
Збірки почали тайм-аутити. SSH-логіни стали повільними, бо запуск шелу торкається багатьох файлів. Моніторинг показував, що мережа NFS-сервера не була насичена.

Корінь проблеми: потоки сервера NFS і підлегле сховище були насичені операціями з метаданими і синхронними записами, тоді як клієнтські кеші постійно інвалідувались.
«Але пропускна здатність в нормі» — невірна лінза. Справжнє вузьке місце — ops/sec на сервері і латентність RPC метаданих.

Виправлення було нудним і ефективним: розділити експорти за навантаженням, ізолювати CI-кеші на окремому сервері (або локальних дисках) і налаштувати опції монтування та кількість потоків сервера.
Вони також додали синтетичний бенчмарк метаданих до планування ємності. Сервіс відновився, і NFS-сервер перестав бути неофіційною спільною тривогою компанії.

Оптимізація, що відбилася: jumbo frames і тихе відкидання

Інша організація захотіла кращої пропускної здатності на iSCSI. Хтось вмикнув MTU 9000 на VLAN для зберігання і на iSCSI NIC.
Вікно змін було коротким, і вони не перевірили кожен хоп. «Це виділений VLAN, все ок».

Тиждень усе виглядало нормально — поки не з’явилися періодичні сплески латентності в пікові години. Не повні відмови. Просто той випадок випадкової повільності, що змушує команди звинувачувати «хмару», навіть якщо вони керують власними стійками.

Патерн був підлий: лише певні хости бачили це, і лише коли трафік проходив через пару конкретних комутаторів.
TCP-ретренсміти трохи зросли, але ніхто не дивився на ретрансміти на VLAN для зберігання, бо історично «storage VLAN чисті».

Справжня проблема: один інтерфейс комутатора на шляху ще був з MTU 1500 і відкидав занадто великі фрейми замість фрагментації.
iSCSI-трафік ретранслювався, черги наростали, і шар мультипатингу іноді переключався — додаючи ще більше турбуленції.
Графіки пропускної здатності були спокійні, бо втрачені пакети не показують використаний throughput.

Відкат — повернення до MTU 1500 по всьому шляху — стабілізував ситуацію негайно. Пізніше вони знову ввімкнули jumbo frames лише після впровадження перевірок сумісності MTU в автоматизації
і налаштування алертів на падіння інтерфейсів і TCP-ретренсміти. Урок: «оптимізації» продуктивності, які не енд-то-енд — це нові режими відмов.

Нудна, але правильна практика, що врятувала день: дисципліна мультипатингу

Платформа, що працює поруч із фінансами, тримала критичні бази даних на iSCSI LUN. Налаштування було неекзотичне: двоконтролерні масиви, дві fabric, мультипатинг на кожному хості.
Відмінність була в дисципліні команди. Кожен хост мав однаковий шаблон конфігурації мультипатингу, однакові таймаути та щоквартальний тест «витягни кабель» у staging.

Одного дня верхній комутатор почав логувати CRC-помилки на порті, підключеному до контролера зберігання.
Помилки були переривчасті настільки, що лінк залишався UP, але достатні для ретраїв і періодичних сесійних проблем iSCSI.

Бази даних не впали. Затримка додатку трохи піднялася, потім стабілізувалася.
Моніторинг зафіксував підвищену кількість перемикань шляхів і підвищену I/O-латентність на одній групі шляхів. On-call дрейннув трафік, навмисно відключив підозрілий лінк і відкрив заявку на апаратне обслуговування.

Постмортем не був драматичним. У цьому і суть. Мультипатинг з розумними таймаутами перетворив кволу фізичну проблему на подію обслуговування замість інциденту для клієнтів.
Вони не «виправили» фізику; вони запланували її і відпрацювали реакцію, доки вона не стала м’язовою пам’яттю.

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

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

1) Визначте, чи ви на NFS, iSCSI або NVMe-oF з хоста

cr0x@server:~$ findmnt -t nfs,nfs4
TARGET           SOURCE                 FSTYPE OPTIONS
/mnt/shared      nas01:/export/shared   nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
NAME   TYPE  SIZE MODEL             TRAN
sda    disk  200G Virtual Disk
sdb    disk  2.0T LIO-ORG   iscsi    iscsi
nvme0n1 disk  1.6T NVMeDisk          nvme

cr0x@server:~$ nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:...
\
 +- nvme0 tcp traddr=10.20.0.50 trsvcid=4420 live

Значення: findmnt показує активні NFS-монти; lsblk показує транспорт; nvme list-subsys підтверджує NVMe-oF-сесії.

Рішення: Виберіть правильний шлях діагностики. Не діагностуйте NFS як блочне сховище і навпаки.

2) NFS: підтвердіть опції монтування, що можуть вирішувати або ламати латентність

cr0x@server:~$ nfsstat -m
/mnt/shared from nas01:/export/shared
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.1.21

Значення: hard означає, що I/O повторюються нескінченно (безпечніше для даних, може «висіти» додатки); timeo і retrans впливають на поведінку зависання; rsize/wsize впливають на throughput.

Рішення: Для критичних даних зберігайте hard. Якщо користувацькі додатки не терплять довгих зависань, розгляньте архітектурні зміни (локальний кеш, асинхронні конвеєри), а не перемикання на soft.

3) NFS: виміряйте поведінку на рівні RPC (латентність і ретрансміти)

cr0x@server:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
2143098    153        2143120

Client nfs v4:
null         read         write        open         close        getattr
0            152340       91822        4311         4309         602111

Значення: ретрансміти вказують на втрату/конгестію мережі або перевантаження сервера. Навіть «маленькі» значення retrans можуть корелювати з хвостовою латентністю.

Рішення: Якщо retrans > 0 і зростає, ставте це як P1. Перевірте помилки мережі та навантаження сервера перед тим як налаштовувати додатки.

4) NFS: виявляйте затримки, спричинені сервером, у kernel логах

cr0x@server:~$ dmesg -T | tail -n 8
[Tue Feb  4 10:44:21 2026] nfs: server nas01 not responding, still trying
[Tue Feb  4 10:44:23 2026] nfs: server nas01 not responding, still trying
[Tue Feb  4 10:44:41 2026] nfs: server nas01 OK

Значення: Клієнти зазнали таймаутів; відновлення відбулося. Це часто найраніший сигнал на хості про гикавки сервера або мережеві мікро-відключення.

Рішення: Корелюйте з лічильниками інтерфейсів комутаторів і CPU/IO NFS-сервера. Якщо повторюється — плануйте міри (розділення навантажень, додавання HA, покращення мережі).

5) iSCSI: перевірте сесії та виявлення таргетів

cr0x@server:~$ sudo iscsiadm -m session
tcp: [1] 10.20.0.10:3260,1 iqn.2003-01.org.linux-iscsi.san01:storage.lun1 (non-flash)
tcp: [2] 10.20.0.11:3260,1 iqn.2003-01.org.linux-iscsi.san01:storage.lun1 (non-flash)

cr0x@server:~$ sudo iscsiadm -m node -o show | head
# BEGIN RECORD 2.1.8
node.name = iqn.2003-01.org.linux-iscsi.san01:storage.lun1
node.tpgt = 1
node.startup = automatic

Значення: Дві сесії зазвичай означають два шляхи (добре). Startup automatic означає, що вона перепідключається при завантаженні.

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

6) iSCSI: перевірте здоров’я мультипатингу і політику шляхів

cr0x@server:~$ sudo multipath -ll
mpatha (36001405a7c3d2a1b9c2d7f1a4e5b6c7d) dm-2 LIO-ORG,iscsi_disk
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Значення: Обидва шляхи active/ready. queue_if_no_path означає, що I/O ставляться в чергу при повній відсутності шляху (може викликати зупинки додатків).
Політика впливає на балансування навантаження.

Рішення: Якщо якийсь шлях faulty або failed, спочатку виправте фізичні/мережеві проблеми. Не «налаштовуйте» навколо зламаного шляху.

7) iSCSI: підтвердіть таймаути, щоб уникнути «висіти вічно» або «падати занадто швидко»

cr0x@server:~$ sudo iscsiadm -m node -T iqn.2003-01.org.linux-iscsi.san01:storage.lun1 -p 10.20.0.10:3260 -o show | egrep 'noop|replacement|timeout'
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.session.timeo.replacement_timeout = 120

Значення: Noops виявляють мертві шляхи; replacement timeout контролює поведінку failover. Надто велике = довгі зависання; надто мале = флапаючі сесії.

Рішення: Узгодьте ці значення з мультипатингом і толерантністю додатків. Тестуйте failover під навантаженням; не вгадуйте в продакшн.

8) NVMe-oF: перерахунок контролерів і деталей транспорту

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
/dev/nvme0n1     deadbeefdeadbeef     NVMeOF-Target                             1         2.00  TB / 2.00  TB       4 KiB +  0 B     1.3

cr0x@server:~$ sudo nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:3b8d...
\
 +- nvme0 tcp traddr=10.20.0.50 trsvcid=4420 live

Значення: Підтверджує NVMe-oF над TCP і який IP/порт таргету ви використовуєте.

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

9) NVMe-oF: перевірте мультипатинг і стан ANA (asymmetric access)

cr0x@server:~$ cat /sys/module/nvme_core/parameters/multipath
Y

cr0x@server:~$ sudo nvme list-ana /dev/nvme0
ANA Log for NVMe device:nvme0
ANA group ID: 1
  state: optimized
  NSIDs: 1
ANA group ID: 2
  state: non-optimized
  NSIDs: 1

Значення: Мультипатинг ввімкнено. Один шлях оптимізований, інший — non-optimized (звично для двоконтролерних систем).

Рішення: Переконайтеся, що хост використовує оптимізовані шляхи пріоритетно. Якщо трафік потрапляє на non-optimized шляхи — отримаєте зайву латентність.

10) Мережа: перевірте помилки інтерфейсу (непомітна правда)

cr0x@server:~$ ip -s link show dev ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210 1234567  0      12      0        0
    TX:  bytes packets errors dropped carrier collsns
    8765432109 1122334  0      0      0       0

Значення: Існують RX drops. Втрати на інтерфейсі зберігання — множник латентності.

Рішення: Діагностуйте фізичний рівень, несумісність MTU, конгестію. Не приймайте «кілька дропів» на storage-мережах.

11) Мережа: виміряйте TCP-ретренсміти (особливо для iSCSI/NFS/NVMe-TCP)

cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|TcpExtTCPSynRetrans|TcpTimeouts'
TcpRetransSegs            1842
TcpExtTCPSynRetrans       0
TcpTimeouts               21

Значення: Ретренсміти і таймаути вказують на втрати або сильну конгестію. Це часто корелює зі стрибками p99.

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

12) ОС: перевірте, чи kernel чекає на I/O (проблема зі сховищем vs CPU)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 812344  92124 933112    0    0   120   340  890 1200 12  4 80  4  0
 3  5      0 810120  92124 933900    0    0   110   500  910 1300 10  3 60 27  0
 1  6      0 808992  92124 934100    0    0   130   480  920 1290  9  3 58 30  0

Значення: Високий b (blocked processes) і високий wa (I/O wait) вказують, що вузьке місце — латентність зберігання.

Рішення: Переведіть діагностику з «дебагу додатку» на «діагностику I/O-шляху». Негайно збирайте iostat, статистику протоколу і мережеві лічильники.

13) Блочні пристрої: слідкуйте за латентністю по диску та глибиною черги

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   r_await   w_await   aqu-sz  %util
sdb              120.0   80.0     6.10    18.40      2.95   98.0
dm-2             240.0  160.0     7.50    21.30      6.10   99.0

Значення: await — середня латентність; aqu-sz показує черги I/O; високий %util на dm-пристрої свідчить про насичення десь у шляху.

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

14) NFS: виявте болі метаданих простим syscall-стресом

cr0x@server:~$ sudo strace -f -tt -T -e trace=file ls -l /mnt/shared >/dev/null
10:51:02.112345 statx(AT_FDCWD, "/mnt/shared", AT_STATX_SYNC_AS_STAT, STATX_BASIC_STATS, ...) = 0 <0.012341>
10:51:02.124910 openat(AT_FDCWD, "/mnt/shared", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 <0.020118>

Значення: Ці <0.02s> файлові операції повільні для тривіального листингу директорії. Це латентність метаданих.

Рішення: Якщо операції з метаданими повільні — перестаньте звинувачувати «пропускну здатність диска». Розділіть навантаження, налаштуйте потоки/кеш NFS-сервера або переробіть дизайн, щоб зменшити чати метаданих.

15) NVMe-oF: перевірте, чи хост бачить очікувану поведінку черг і переривань

cr0x@server:~$ cat /proc/interrupts | egrep 'nvme|ens192' | head
 42:  1234567  0  0  0  IR-PCI-MSI 524288-edge  nvme0q0
 43:  2345678  0  0  0  IR-PCI-MSI 524289-edge  nvme0q1
 58:  3456789  0  0  0  IR-PCI-MSI 393216-edge  ens192-TxRx-0

Значення: NVMe-черги існують; переривання спрацьовують. Якщо все застрягло на одному CPU, ви побачите дисбаланс і латентність.

Рішення: Якщо переривання концентруються на одному ядрі — налаштуйте IRQ-affinity / RSS і повторно протестуйте латентність під навантаженням. NVMe-oF винагороджує налаштування CPU/мережі; він карає за нехтування.

Швидкий план діагностики (знайти вузьке місце без тижневого war room)

Перше: класифікуйте відмову за 60 секунд

• Чи це латентність зберігання чи CPU додатку? Перевірте vmstat (blocked processes, iowait) і стани потоків додатку.
• Чи це специфічно для протоколу? Логи клієнта NFS проти подій сесії iSCSI проти ресетів контролера NVMe.
• Чи це ізольовано чи системно? Один хост, один rack, одна AZ або всі?

Друге: перевірте мережу як слід

1. Помилки/дропи інтерфейсу на клієнтах і портах сховища: ip -s link.
2. TCP ретрансми/таймаути для TCP-протоколів: nstat.
3. Консистентність шляху: MTU енд-то-енд, здоров’я LACP, правильність VLAN.

Якщо знаходите дропи/ретрансміти — зупиніться. Виправте це перед налаштуванням сховища. Трафік зберігання — не «просто трафік». Це кровоносна система ваших додатків.

Третє: перевірте pathing і поведінку failover

• iSCSI: iscsiadm -m session, multipath -ll, і kernel-логи на предмет ресетів сесій.
• NVMe-oF: nvme list-subsys, nvme list-ana, мультипатинг ввімкнено.
• NFS: шукайте «server not responding» і зростання retrans з nfsstat -rc.

Четверте: перевірте бекенд-систему зберігання (без вигадок)

• Чи масив виконує відбудову, скрабінг або тротлінг?
• Чи ви насичуєте CPU або кеш контролера?
• Чи один шлях/контролер «гарячіший» за інший (асиметрія)?

П’яте: міряйте, потім змініть одну річ

Зніміть базові показники латентності (p50/p95/p99), ретранс/дропи, розміри черг і стани шляхів. Зробіть одну зміну, пере-міряйте.
Якщо не можете виміряти — ви не налагоджуєте, ви граєте в рулетку.

Поширені помилки: симптом → причина → виправлення

1) Симптом: NFS-монти «зависають» і процеси переходять у D state

• Корінь: hard монти чекають на повільний/недоступний сервер або конкуренція за блокування на сервері.
• Виправлення: діагностувати здоров’я сервера і мережеві втрати; додати HA (active/active де можливо), розділити шумні навантаження і впевнитися, що таймаути клієнтів адекватні. Уникайте «вилікувати» перемиканням на soft для критичних даних.

2) Симптом: періодичні iSCSI-таймаути, помилки файлової системи, випадкові паузи VM

• Корінь: path flapping (поганий кабель/SFP/NIC), MTU-несумісність що викликає дропи, або неправильна конфігурація мультипатингу.
• Виправлення: забезпечити резервні шляхи, валідувати MTU енд-то-енд, моніторити ретранс і помилки інтерфейсів, стандартизувати політики multipath по хостах.

3) Симптом: «Чудовий throughput, жахлива латентність» на NFS

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

4) Симптом: NVMe-oF поверх TCP показує випадкові сплески p99 під навантаженням

• Корінь: втрата пакетів або мікроберсти конгестії; проблеми CPU/IRQ-affinity; недостатнє буферування/налаштування ECN у fabric.
• Виправлення: спочатку усуньте дропи; налаштуйте NIC RSS/IRQ affinity, перевірте стратегію ECN/aqm (якщо використовується), і переконайтеся, що мультипатинг/ANA віддає перевагу оптимізованим шляхам.

5) Симптом: корупція або «таємничі» неконсистентності файлової системи на iSCSI LUN

• Корінь: той самий LUN змонтовано для запису кількома хостами без кластерної координації; відсутнє fencing.
• Виправлення: забезпечити single-writer семантику або використовувати правильну кластерну файлову систему з fencing (або перейти на NFS, якщо вам справді потрібні спільні файли).

6) Симптом: NFS «stale file handle» після технічних робіт

• Корінь: серверна файлова система/експорт переміщено або замінено так, що змінилися файлові дескриптори/inode; фейловер не зберіг ідентичність.
• Виправлення: перемонтувати клієнти; виправити процедуру HA, щоб зберігати ідентичність файлової системи; уникати ручних свопів експорту без координації.

7) Симптом: iSCSI виглядає нормально, але латентність стрибає під час вікон бекапів

• Корінь: contention на бекенді масиву (снепшоти, реплікація, відбудова) або мережеве перепідписування, коли бекап-трафік ділить uplink-и.
• Виправлення: ізолювати бекап-трафік, планувати важкі операції масиву, застосувати QoS і моніторити латентності та показники кеш-хітів на масиві.

8) Симптом: «Ми оновили на 100GbE, але стало не швидше»

• Корінь: обмеження одиночного потоку, неправильні глибини черг, вузьке місце у CPU або обмеження медіа/контролера масиву.
• Виправлення: виміряти завантаження CPU та розподіл IRQ; паралелізувати навантаження; переконатися, що масив справді може віддати більше; обережно налаштувати глибини черг.

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

Чекліст прийняття рішення: оберіть протокол за навантаженням і реальністю команди

1. Потрібні спільні POSIX-подібні файли? Почніть з NFSv4.1+.
2. Потрібен сирий блочний пристрій? Почніть з iSCSI (якщо немає доведених вимог NVMe-oF).
3. Потрібна ультра-низька латентність і великий паралелізм? Розгляньте NVMe-oF, але вимагайте спочатку SLO мережі та спостережуваності.
4. Потрібен multi-writer? NFS для файлів, або кластерний блочний шар з fencing. Ніколи не «просто змонтуйте LUN на двох».
5. Чи є у вас операційна зрілість? Якщо команда не може надійно керувати MTU, LACP і моніторингом — не розгортайте протокол, який підсилює ці помилки (NVMe-oF).

Чекліст побудови: зробіть його витривалим до звичних відмов

1. Два незалежні мережеві шляхи (окремі комутатори) для трафіку зберігання.
2. Явна стратегія MTU, валідація енд-то-енд і автоматичні перевірки.
3. Хост-моніторинг: ретрансміти, дропи інтерфейсу, перцентилі латентності, глибина черг.
4. Документований і протестований failover: витягнути один лінк, перезавантажити контролер, підтвердити відновлення під навантаженням.
5. Управління змінами: зміни в мережі зберігання вимагають тієї ж серйозності, що і зміни схеми бази даних.

Операційний чекліст: що стандартизувати по хостах

1. NFS: консистентні опції монтування; використовувати NFSv4.1+ де доречно; алерти на «server not responding» і ретрансміти.
2. iSCSI: консистентні налаштування iscsiadm node; узгоджений multipath конфіг; періодичні тренування відмов шляхів.
3. NVMe-oF: мультипатинг ввімкнено; ANA-aware пріоритети шляхів; стандарти tuning IRQ/RSS; алерти на дропи/ретранс і ресети контролерів.

FAQ

1) Чи NFS «повільніший» за iSCSI?

Не за замовчуванням. NFS може бути надзвичайно швидким для великих послідовних I/O. Він часто програє на дрібних, синхронних і мета-операційних навантаженнях.
iSCSI, як правило, більш передбачуваний для блочно-орієнтованих шаблонів.

2) Чи можна запускати бази даних на NFS?

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

3) Чому NFS-клієнти «висять» замість того, щоб швидко падати?

Тому що hard монти віддають пріоритет цілісності даних: клієнт продовжує робити повторні спроби, щоб уникнути часткових записів і корупції.
Якщо ваш додаток не терпить цього, правильне виправлення зазвичай архітектурне (таймаути, повтори, черги), а не перехід на soft.

4) Чи безпечно iSCSI для спільного доступу з кількох хостів?

Лише з кластерним шаром і fencing (кластерна файлова система, кластерний volume manager тощо). Інакше ви ризикуєте корупцією.
Блочні пристрої за замовчуванням припускають одного записувача.

5) Чи має сенс NVMe-oF поверх TCP, чи RDMA обов’язковий?

NVMe-oF по TCP часто прагматичний вибір: простіше розгорнути на існуючому Ethernet, менше спеціалізованих налаштувань.
RDMA може дати нижчу латентність і менше CPU, але підвищує вимоги до конфігурації fabric і експертизи.

6) Яка найбільша прихована вартість NVMe-oF?

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

7) Чи завжди я маю вмикати jumbo frames для сховищ?

Лише якщо ви гарантуєте MTU енд-то-енд і моніторите дропи. Інакше ви міняєте теоретичну вигоду на реальний режим відмов.
MTU 1500, налаштований правильно, кращий за MTU 9000, який «майже налаштований».

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

Подивіться на дропи/помилки інтерфейсу (ip -s link) і TCP ретранс/таймаути (nstat) під час інциденту.
Якщо ці лічильники ростуть — ваша «проблема зі сховищем» принаймні частково мережева.

9) Для віртуалізаційних datastore-ів: NFS чи iSCSI?

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

Висновок: практичні кроки

Якщо ви обираєте сьогодні без особливих обмежень: використовуйте NFS для спільних файлів, iSCSI для загального блочного зберігання,
і залишайте NVMe-oF для навантажень, які можуть довести потребу в нижчій латентності, і для команд, що доведуть здатність оперувати fabric.

Зробіть це далі, у такому порядку:

1. Запишіть вашу ціль по латентності та толерантність до відмов (p95/p99, тривалість зависань, очікування відновлення).
2. Інструментуйте шлях: дропи, ретрансміти, статистика протоколу, бекенд-латентність.
3. Проведіть drill відмов: витягніть лінк, перезавантажте контролер, відмовте комутатор — виміряйте вплив на додаток.
4. Стандартизуйтесь конфіги (опції монтування, multipath, таймаути) і впровадьте їх через автоматизацію.
5. Розділіть несумісні навантаження перед тим, як ганятися за героїчною оптимізацією (metadata storms і логи не мають бути на одному NFS-експорті).

Переможний протокол — той, що відповідає вашим SLO та не вимагає щоденних подвигів. Ваше майбутнє «я» скаже вам дякую. Тихенько. Поки спить.