Експорти та монтування NFS, що відмовляють безпечно

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

Чому спільні файли йдуть шкереберть

Звичайна причина для NFS: група веб- або прикладних серверів, які мають бачити одні й ті самі файли: завантажені медіа, згенеровані ресурси, спільне дерево документів. Його налаштовують швидко, часто копіюючи приклад, і воно працює з першого разу. Проблеми з’являються пізніше. Експорт, відкритий для цілої мережі, дозволяє забутій тестовій машині писати у продуктивний контент. Клієнт, змонтований з опціями, які здаються при помилках, мовчки втрачає записи. Сервер, який не може дістатися до свого файлера під час завантаження, зависає на хвилини замість того, щоб стартувати без ресурсу. Жодне з цього не видно в день налаштування.

На файлері: експортуйте за іменами, стискайте root

Експортуйте кожен ресурс тим хостам, яким він потрібен, за іменем, з найвужчими правами, що працюють:

# /etc/exports
/export/web   web1.example.internal(rw,sync,root_squash,no_subtree_check) \
              web2.example.internal(rw,sync,root_squash,no_subtree_check)
/export/media media-reader.example.internal(ro,sync,root_squash,no_subtree_check)

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

root_squash. Root на клієнті стає непривілейованим користувачем на файлері. Без нього будь-хто з root на будь-якому клієнті володіє кожним файлом на ресурсі.

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

Застосуйте і перевірте, що насправді експортовано, а це не завжди те, що ви думаєте, що написали:

exportfs -ra
exportfs -v

Потім обмежте сервіс на firewall хоста до тих самих клієнтів. З firewalld окрема зона тримає це читабельним:

firewall-cmd --permanent --new-zone=nfsclients
firewall-cmd --permanent --zone=nfsclients --add-source=<client address>
firewall-cmd --permanent --zone=nfsclients --add-service=nfs
firewall-cmd --reload

Експорти і правила firewall є двома незалежними замками. Використовуйте обидва.

На клієнті: hard-монтування, які не підвішують завантаження

Сторона клієнта вирішує, що станеться, коли файлер повільний або ненадовго недоступний:

# /etc/fstab
filer.example.internal:/export/web  /srv/web  nfs  hard,proto=tcp,timeo=600,retrans=2,_netdev,nofail,x-systemd.mount-timeout=30  0 0

hard, а не soft. Hard-монтування повторює спроби, доки сервер не відповість. Soft-монтування повертає помилку після певної кількості спроб, а багато застосунків не перевіряють цю помилку під час запису, тож дані можуть бути втрачені без того, щоб хтось про це дізнався. Якщо ресурс містить щось, що вам дороге, монтуйте його hard. Ціна в тому, що процес, який торкається ресурсу, чекає, поки файлера немає, і це чесна поведінка.

_netdev і nofail. Монтування чекає на мережу, а відсутній файлер не заважає серверу завантажитися. У поєднанні з тайм-аутом монтування машина піднімається, застосунок може чітко повідомити про відсутній ресурс, а монтування завершується, коли файлер повертається.

Зафіксуйте протокол, який ви протестували. Клієнти і сервери домовляються про версію протоколу. Встановіть ту, яку ви протестували, явно (nfsvers= або vers=), щоб оновлення з будь-якого боку не могло тихо змінити поведінку блокування і кешування у вас під ногами.

Перевіряйте, про що насправді домовилися, а не що ви просили:

nfsstat -m
findmnt -t nfs,nfs4
mountstats /srv/web

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

Резервування на дроті, snapshots на диску

Файлер доступний рівно настільки, наскільки доступні його мережеві лінки. Під’єднайте його агрегованими (bonded) лінками до пари комутаторів, хешуйте bond за адресами і портами, щоб обидва лінки несли трафік, і тримайте файлер і клієнтів в одному сегменті Layer 2, де можете. Комутований шлях має менше рухомих частин, ніж маршрутизований, і тримає файловий трафік усередині приватної мережі.

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

zfs snapshot tank/web@before-deploy
zfs list -t snapshot
ls /export/web/.zfs/snapshot/before-deploy/

Snapshot перед кожним розгортанням або масовою зміною робить невдалу зміну оборотною за секунди, а прихований каталог snapshot дозволяє адміністратору скопіювати назад один файл без завдання відновлення.

Коли файловий ресурс є неправильною відповіддю

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

Короткий контрольний список для ваших власних ресурсів

• exportfs -v перелічує лише іменовані хости, з root_squash і sync.
• Firewall дозволяє NFS лише з цих хостів.
• Кожне клієнтське монтування є hard, з _netdev, nofail і зафіксованою версією протоколу.
• nfsstat -m на кожному клієнті показує опції, які ви задумали.
• Повторні передачі в mountstats близькі до нуля і не зростають.
• Файлер має резервні лінки, і ви протестували втрату одного.
• Snapshots існують, а резервні копії забираються окремо.

Як це робимо ми

Наші файлові сервіси працюють на ZFS поверх томів з нашого all-flash SAN, під’єднані агрегованими лінками до пари комутаторів у тому самому приватному сегменті, що й їхні клієнти, і оновлюються в нове boot environment, тож попереднє залишається завантажуваним, доки оновлення не доведе себе.

Якщо ваше спільне сховище налаштували швидко і відтоді на нього ніхто не дивився, ми радо переглянемо його разом з вами.

cta: Поговоріть з інженером

Related

• /what-we-do/storage-compute/network-attached-storage/
• /what-we-do/storage-compute/enterprise-san-storage/
• /what-we-do/storage-compute/disaster-recovery/