Глобальное пространство имен файлов (1/4)

Сегодня начну небольшую серию сообщений о том как можно облегчить управление неструктурированными данными (файловыми ресурсами). Вступление скорее лирическо-историческое для того, чтобы создать базу для рассказа.

Файловые серверы - казалось бы, что может быть проще? Уже давным давно все привыкли - пишем в адресной строке \\fileserver\mydir\mydoc.doc (то, что заумно называют "UNC имя файла") и открывается нужный нам документ. Если не помним название файла, можно открыть весь список, полазить по папкам. В конце концов, есть ведь и поиск (вплоть до содержимого самих файлов)! А что происходит если вчера этот самый "fileserver" сломался и IT отдел быстро заменил его сервером \\fserver28 (даже все данные удалось вовремя восстановить из резервной копии за ночь)? Тогда мы, в душе поругавшись на айтишников, которые только жить мешают, пойдем открывать файл на этом новом сервере, запомнив новое название на будущее.

Конечно, сейчас опытные админы скажут, что так дела не делаются и можно было несколькими способами оставить UNC имя без изменений! Конечно можно. Можно было и через DNS перенаправить запросы со старого сервера на новый, а можно было задействовать DFS, а можно... Да много чего конечно можно, но это каждый раз требует ручного вмешательства и с каждой такой модификацией шансов запутаться и не найти уже никогда концов становится гораздо больше.  Со своими файлами-то разберемся - поворчим, но найдем - никуда они не денутся. А вот если активно используются ссылки в документах? Кто будет следить за целостностью ссылок во всех документах? Изменилось UNC имя - нужно найти и поменять все ссылки. Кропотливая задачка, может быть можно как-то проще?

К счастью, уже давно известен путь решения проблемы - использовать глобальную систему имен файлов. Ссылки неизменны и всегда работают (пока можно "достучаться" до того сервера, где файл фактически хранится, и пока доступен сервер, отвечающий за эту самую глобальную систему имен). Если файл перенесли с одного сервера на другой, то просто подменяется указатель, а UNC имя остается постоянным.

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

Наиболее яркий пример - Microsoft DFS (Distributed File System). Система очень проста (так как имеет очень ограниченные дополнительные возможности), но зачастую требует кропотливой ручной работы администратора. Главный плюс - продукт совершенно бесплатен (а если точнее, то входит в базовый функционал Windows Server) и за счет этого довольно популярен. Однако, внедрение DFS в существующую инфраструктуру - самая большая головная боль (причем не только для администратора). Разом потребуется заменить все unc имена файлов на новые. Т.е. если раньше мы обращались к файлу \\fileserver1\share2\accounting\nds2010.xls, то теперь это будет что-то типа \\Acme\accounting\nds2010.xls Разумеется, потребуется поменять и все ссылки на внутренние файловые ресурсы внутри документов. А главное, этот процесс нельзя делать постепенно - иначе проблем возникнет еще больше. Поэтому все пользователи начиная с момента внедрения DFS должны начать пользоваться только DFS для доступа к файлам. Хотя от версии к версии DFS становится все более и более удобным, для достижения идеала еще предстоит сделать очень много. Тем временем объем неструктурированных данных растет очень быстро (по ряду оценок рост достигает 100% в год).

Существуют удобные альтернативы (и дополнения) для DFS. В частности, до недавнего времени компания Brocade выпускала такой замечательный продукт как Tapestry StorageX - это была "надстройка" над DFS, существенно упрощающая работу администратора. Помимо удобной консоли для управления, StorageX имел и встроенные возможности по репликации. Репликация могла быть довольно просто интегрирована с NetApp SnapMirror - в случае сбоя на одной из площадок, автоматически активировался том на "зеркальном" файлере и пользователь практически мгновенно получал доступ ко всем файловым ресурсам так, как будто бы ничего и не произошло. Данное решение активно продавалось под именем VFM (Virtual File Manager) вместе с файлерами NetApp (а заодно и с системами IBM N-Series) и действительно многим помогло в развертывании DFS.

Впрочем, и этот продукт не был лишен ряда недостатков:

• Пользователю необходимо помнить о том, что от доступности сервера StorageX напрямую зависит весь функционал (встроенная репликация, failover и т.п). В случае если сервер StorageX "встанет", все политики перестанут работать и не будет происходить автоматического переключения между системами хранения при сбоях.
• Помимо обеспечения высокой доступности сервера StorageX необходимо помнить и про доступность самой DFS - ведь вся работа с файлами происходит непосредственно через DFS, а StorageX - только надстройка. Отказоустойчивость DFS тоже требует определенной настройки и внимания, а следовательно добавляет некоторую головную боль администратору при внедрении и поддержке.
• Отсутствует интеграция с DFS-R (Distributed File System Replication). При этом , непосредственно в самом StorageX нет возможности делать "multi-master" репликацию (т.е. двунаправленную синхронизацию между серверами), а это во многих случаях бывает необходимо для заказчика.

Однако еще летом 2009года в Brocade "закрыли" этот продукт окончательно и бесповоротно. В причины такого решения мы вдаваться не будем - возможно недостаточный спрос или смещение интересов от изрядно нашумевшей концепции File Area Network, а может что-то еще - сейчас это уже не так важно. Однако всем, кто успел приобрести StorageX/VFM, пора бы уже задуматься об адекватной замене, так как оплаченная поддержка уже либо  закончилась, либо подходит к концу.

Мир, тем временем, не стоит на месте и о том, какой продукт можно успешно использовать  для того, чтобы упростить работу с неструктурированными данными, я расскажу в следующий раз.