File Area Networks, или Управление файлами в сетевой среде

Принимая во внимание рост количества файлов, которыми необходимо управлять IT-департаментам крупных предприятий, увеличивающуюся сложность файловых систем и масштабность приложений, использующих файлы, становится понятным, почему указанная в заголовке статьи проблема выходит на первый план. Эти и ряд других причин, в числе которых – управление жизненным циклом информации (ILM) и послеаварийное восстановление, вызвали необходимость создания нового типа управления файлами – File Area Networks (FAN).

Рис. 1. Отображение сетевой файловой системы

За многие годы системы хранения данных эволюционировали от модели непосредственного подсоединения дисковых массивов подключаемых устройств к серверам (DAS) до сети (NAS) и сетей хранения (SAN). Поскольку различия между этими тремя технологиями начинаются только после уровня API файловой системы, то переходы между этими моделями хранения возможны с нулевым или минимальным воздействием на само приложение и без необходимости его переписывать, если только оно не обменивается данными с устройствами хранения напрямую, а не с помощью стандартного интерфейса, поддерживаемого операционной системой.

Цель FAN заключается в том, чтобы предоставить гибкий и интеллектуальный набор методов управления файлами данных в сетевой среде. Чтобы выполнить это, FAN обеспечивает ряд ключевых функций, среди которых:

• управление файловой информацией, в том числе атрибутами файлов, в масштабах корпорации;
• возможность устанавливать «видимость» файлов и права доступа независимо от физического размещения устройства;
• неразрушающее прозрачное перемещение файлов по платформам и/или через географические границы;
• консолидация избыточных файловых ресурсов и задач управления;
• возможность управления файлами как в центрах данных, так и в филиалах.

Сетевой составляющей FAN служит предустановленная корпоративная IP-сеть. Вдобавок оно использует один или более высокоуровневых протоколов сетевых файловых систем, таких как Network File System (NFS) и Common Internet File System (CIFS). Однако следует помнить, что FAN отличается от лежащей в ее основе сети, которая транспортирует файлы: этот термин применяется для описания целостного подхода к реализации базированного на файлах обмена данными, их хранения и управления.

Необходимо также отметить, что FAN не конкурирует с SAN. Наоборот, они не только дополняют, но и усиливают друг друга, являясь симбиотическими. Для самых надежных FAN-решений требуются SAN, в свою очередь, такие решения предоставляют инструменты, которые SAN просто не может обеспечить. В конце концов, все файлы данных хранятся в формате блоков, и блоки данных хранятся наиболее эффективно в SAN.

Сетевые файловые системы

Как уже упоминалось, среди сетевых файловых систем доминируют две – NFS и CIFS. Рассмотрим кратко некоторые их особенности.

NFS была разработана компанией Sun Microsystems в 80-х годах XX в. Это была первая широко используемая сетевая файловая система. Сегодня она является стандартом де-факто для UNIX-систем, хотя может применяться и для ПК-платформ с ПО третьих компаний.

Рис. 2. Глобальное пространство имен

В среде NFS одна машина (клиент) требует доступа к данным, хранящимся на другой машине (сервере). Таковым может служить UNIX-хост, Windows-сервер, работающий с ПО третьих компаний, или другое устройство. Сервер запускает NFS-процессы или как чисто программный пакет (например, демон в UNIX), или с аппаратной поддержкой (скажем, чип в устройстве). Доступность каталога определяется конфигурацией сервера, а политики безопасности отвечают за идентификацию и авторизацию клиента. Если клиентом выступает UNIX-машина, то для доступа к экспортируемым данным применяется команда <mount>. Если удаленная файловая система однажды смонтирована, то пользователи могут иметь к ней доступ так, будто она располагается на клиентской машине.

CIFS была первоначально известна как протокол Server Message Block (SMB). Этот проприетарный протокол, разработанный Microsoft, предназначен в основном для коммуникаций между платформами Microsoft и сетевыми устройствами хранения. Он также может служить для разделения принтеров, последовательных портов и других коммуникаций, но для целей FAN важна только возможность разделения файлов. Доступ к файловым системам CIFS с платформы UNIX может выполняться с использованием ПО третьих производителей.

Подобно NFS, CIFS изначально не была создана для TCP/IP. Фактически она не была разработана даже для IP – она написана для NetBIOS, которая работала на верхушке протоколов NetBEUI, IPX/SPX и TCP/IP. В приложениях корпоративного класса CIFS почти всегда отображается прямо на верхушку TCP/IP, и для большинства решений FAN такой подход оптимален.

Однако применение как одной, так и другой файловой системы связано с рядом трудностей. К примеру, ни одна из них не функционирует хорошо в WAN-окружении. Большая задержка в каналах связи между клиентами и серверами снижает производительность и надежность. Это требует определенной оптимизации в децентрализации ресурсов в крупномасштабных проектах. Правда, в FAN разрабатываются отдельные компоненты для решения этой проблемы.

Далее, оба протокола создаются с целью привязки точки монтирования удаленной файловой системы (т. е. локализации на клиенте, на котором пользователь видит удаленные файлы) к физической машине, служащей в данном случае файл-сервером. Это хорошо работает в небольших сетях, однако когда имеются сотни серверов, и каждый из них должен периодически подвергаться своппингу, управление отображениями точек монтирования может оказаться крайне трудным. Решение этих и сопутствующих проблем – основная задача модели FAN.

Глобальное пространство имен

Все системы FAN базируются на файловых системах со способностью организовать, представить и сохранить содержимое файла для авторизованных конечных пользователей. Такая возможность опирается на «пространство имен» (namespace) файловой системы. Использование глобального пространства имен (Global Namespace, GNS) является краеугольным камнем подхода FAN к виртуализации визуального представления серверов хранения. Если говорить кратко, то GNS для файловой системы – это то же самое, что и DNS для интернет-сервисов, таких как www. Большинство людей не знает численного IP-адреса www.google.com, но миллионы обращаются к нему каждый день. Механизм GNS делает инфраструктуру систем хранения подобной Интернету, т. е. клиенты получают доступ к файлам способом, во многом похожим на доступ к веб-сайтам.

Чтобы понять, как GNS это делает, полезно сначала рассмотреть, что происходит без него. На рис. 1 показан традиционный подход к отображению точек монтирования и имен дисководов через сеть. Каждая такая точка привязывается к физическому файл-серверу. Эти отношения обычно создаются и поддерживаются IT-отделом. Если файлы переносятся, на клиентских машинах отображение необходимо изменить. Существующие для этого методы автоматизации не свободны от проблем. В типичном случае пользователям необходимо выйти из системы и перегрузиться. Далее, в больших сетях дисков больше, чем букв в алфавите. Это создает трудности для администраторов Windows, поскольку невозможно, чтобы все получили одинаковые отображения дисковых устройств. Например, для разных групп пользователей накопитель Е: может относиться к разным файл-серверам. Когда клиент звонит администратору и говорит, что он не видит диск Е:, то ему трудно помочь, так как маловероятно, что сотрудник знает, где располагается этот диск.

Что же делает GNS? Взамен связывания точек монтирования с физическими дисками NAS и файл-серверами оно создает структуру каталогов на логическом уровне, понятном и пользователям, и администраторам, и для получения данных отображает запросы клиентов на соответствующие физические устройства. GNS создает уровень абстракции между клиентом восприятием файловой системы и физическим расположением файлов. Оно виртуализует файловые системы.

На рис. 2 показано, как может выглядеть отображающая файловую сетевую систему среда, если GNS реализовано. В не-GNS парадигме пользователь должен был бы знать (или предполагать), какие имена дисководов отображаются на сервер с необходимыми ему данными. Если со стороны сервера что-либо менялось, пользователям следовало перенастроиться – скажем, выйти из системы, перезагрузиться и, возможно, реконфигурировать приложения. В GNS-парадигме они могут видеть интуитивно понятную структуру каталогов, связанную с данным именем диска. Таким образом, при каких-либо изменениях на сервере уровень абстракции GNS позволяет IT-отделу сохранить единообразное представление файловой системы пользователю.

Это во многом подобно тому, как DNS обеспечивает уровень абстракции для Интернета. Веб-сайт www.google.com может изменить IP-адрес или физическое положение, однако пользователю нет нужды знать, что случилось.

Администраторы могут сгруппировать несколько файловых систем и управлять ими как единой структурой безотносительно к их реальному местонахождению.

Подытожим вкратце вышеизложенное.

Приложения FAN работают поверх NFS и CIFS, а те, в свою очередь, – сверху TCP/IP over Ethernet. По этому соединению приложения выполняют доступ к файлам, в то время как сами данные располагаются на серверах или устройствах хранения. Это соединение, в общем, управляется некоторой формой отображения SCSI, такой как SCSI over Fibre Channel.

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

Данные приложения разрабатываются с целью помочь IT-профессионалам устранить или, по крайней мере, упростить управление растущим количеством файлов данных. Они могут сделать локализацию файлов и их перемещения прозрачными, централизовать ресурсы, консолидировать функции управления, уменьшить стоимость резервирования и восстановления.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365