NFS: как протокол из 1984 года стал двигателем современных СХД

Андрей Кучинский, генеральный директор ARGO.TECH, - об истории NFS, нативной интеграции в ядро и о том, почему «крепость в горе» надёжнее «крепости рядом с горой».

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

Три эпохи хранения: зачем понадобился NFS

- Андрей, как развивалось хранение данных и какую задачу решал NFS?

Андрей Кучинский: История хранения делится на три эпохи. Первая - мейнфреймы. Один огромный компьютер, все пользователи подключены через терминалы, данные лежат в одном месте.

Вторая эпоха - персональные рабочие станции. В начале 80-х компьютеры подешевели, и у каждого инженера появилась своя машина. Возникла фундаментальная проблема: данные разбежались. Раньше ты заходил на терминал и видел все файлы. Теперь у тебя свой компьютер, у коллеги свой - чтобы поделиться файлом, нужно было копировать его на дискету и идти к соседу.

Именно эту задачу - вернуть прозрачность доступа к данным в распределённой среде - и решал NFS. Sun Microsystems разработала его в 1984 году для операционной системы SunOS.

Четыре требования, определившие архитектуру NFS

Андрей Кучинский: Перед разработчиками стояло четыре ключевых требования.

1. Совместимость с существующими приложениями. Программа не должна знать, работает она с локальным файлом или с удалённым.
2. Простота внедрения. NFS должен был встроиться в существующие UNIX-системы без переписывания ядра.
3. Кроссплатформенность. Sun понимала, что в сети будут не только их машины. Поэтому данные передавались в универсальном формате XDR (External Data Representation).
4. Производительность, достаточная для комфортной работы. Не как у локального диска, но чтобы пользователь не замечал разницы.

Именно эти четыре цели определили архитектуру NFS.

Две главные архитектурные находки

Андрей Кучинский: Первое решение - протокол без сохранения состояния (stateless). Каждый запрос к серверу содержит всю информацию для его выполнения. Сервер не помнит, что было раньше. Если сервер упал и перезагрузился - клиент просто повторяет запрос, и всё работает.

Второе - уровень VFS (Virtual File System). Sun реализовала в 4.2BSD UNIX специальный слой абстракции, который скрывал от приложений разницу между локальными и удалёнными файлами. Приложение работает с файлом через VFS, а VFS решает, куда направить запрос - на локальный диск или по сети на NFS-сервер.

Именно VFS стал тем «клеем», который позволил NFS стать прозрачным для пользователя.

Экономический эффект: один сервер вместо сотен дисков

- То есть NFS решил проблему «разбежавшихся данных»?

Андрей Кучинский: Да, и не только. Он решил экономическую задачу. Представьте университет или корпорацию с сотнями рабочих станций. Если у каждой свой диск - нужно бэкапить каждую, обслуживать, менять диски, когда они умирают.

С NFS вы храните данные централизованно на одном сервере. Рабочие станции могут быть даже бездисковыми - они загружаются по сети и монтируют свои файловые системы с NFS-сервера.

Это была революция. Компания могла купить один мощный сервер хранения и десятки дешёвых рабочих станций. Данные централизованы, бэкап один, администрирование одно.

Где NFS используется сегодня

Андрей Кучинский: Везде, где нужно разделить файлы между машинами. Основная задача не изменилась - дать нескольким машинам доступ к одному набору файлов. Но масштаб и контекст другие.

В современной инфраструктуре NFS - это:

• Хранилище для виртуализации. Когда у вас кластер из десятков гипервизоров, образы виртуальных машин должны лежать в одном месте, доступном всем узлам. NFS здесь - стандартный и самый простой путь.

• Домашние каталоги пользователей. В корпоративной среде с тысячами сотрудников никто не хранит данные на локальных дисках рабочих станций.

• Кластеры HPC и базы данных. Там, где десятки вычислительных узлов должны видеть одни и те же данные.

• Кроссплатформенный обмен. NFS одинаково хорошо работает между Linux, UNIX и Windows. Если у вас смешанная среда - это «клей», который её держит.

Нативность: почему NFS в ядре - это принципиально

- Ходят разговоры о «нативности». Что это значит?

Андрей Кучинский: Это ключевой момент. NFS бывает разным. Есть пользовательские реализации - когда сервер NFS работает как приложение в пространстве пользователя. Есть ядерные - когда код NFS встроен в ядро операционной системы.

Разница фундаментальная. Когда NFS работает в пространстве пользователя, каждый запрос проходит через системные вызовы, переключения контекста, копирование данных между ядром и пользовательским процессом. Это оверхед. Для высоконагруженных сред это критично.

Когда NFS нативен на уровне ядра - операции с файлами обрабатываются напрямую. Нет переключений контекста. Нет лишнего копирования. Ядро «знает» о NFS так же, как о локальной файловой системе.

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

«Крепость в горе»: метафора нативной интеграции

Андрей Кучинский: Вспомните «Властелин колец». Хельмова Падь - не просто крепость. Это гора, в которой вырублены залы, стены и башни. Она стоит на монолитной скале, которую невозможно подкопать, сдвинуть или обойти. Стены - продолжение скалы, а не отдельная постройка.

NFS в пользовательском пространстве - это как построить крепость рядом с горой, а не внутри неё. Стены стоят, но они не часть скалы. Их можно обойти, подкопнуть, отрезать от источника.

Хельмова Падь держится не благодаря тому, что помнит атаки. Она держится архитектурно - скала, стены, врата. Даже если защитники устали, крепость стоит.

- Интересное сравнение, неожиданное.

Андрей Кучинский: Главное - в точку! Для нашего решения NFS - это крепость в горе. Её нельзя отрезать от фундамента, потому что фундамент - это она сама.