Файловые серверы - казалось бы, что может быть проще? Уже давным давно все привыкли - пишем в адресной строке \\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, позволяющие удобно, просто и по возможности прозрачно для существующей инфраструктуры получить глобальное пространство имен. Компании AutoVirt предлагает пользователям именно такой продукт. AutoVirt это не надстройка и не дополнение к Microsoft DFS. AutoVirt является совершенно самостоятельным решением и для его работы не требуется ни DFS, ни DFS-R - нужен только домен и конечно сами файловые серверы. Какие же положительные качества решения можно выделить:
- отказоустойчивость "из коробки"
- прозрачное внедрение в инфраструктуру без необходимости что либо менять у пользователей
- поддержка DFS
- различные политики, обеспечивающие управление данными (миграция, репликация, архивирование и т.п.)
Реализация глобальной системы имен AutoVirt основана на перенаправлении DNS запросов. Обычно, при обращении к папке на сервере, когда мы набираем \\A\myshare, сначала идет запрос к серверу DNS, который нам возвращает IP адрес сервера "A". А уже потом мы с этого файл-сервера получаем необходимые нам данные:
Глобальная система имен в AutoVirt работает почти также, только теперь разрешением имен занимается не DNS, а сервер AutoVirt, на который DNS сервер и перенаправляет все запросы:
Благодаря такому подходу, становится возможным динамически менять ссылки на ресурсы без каких-либо видимых последствий у пользователей - если все данные были перенесены на сервер "B", то достаточно изменить ссылку на уровне сервера AutoVirt и пользователи будут уже обращаться к новому серверу, а старый можно выводить из обслуживания. На первый взгляд, все точно так же, как и в случае Microsoft DFS, однако основные преимущества AutoVirt в тех возможностях, которые получает пользователь по управлению файловыми ресурсами.
Отказоустойчивость и схема работы.
Совершенно очевидно, что для обеспечения нормальной работы пользователей необходима высокая доступность Global Namespace (глобального пространства имен). AutoVirt имеет встроенные возможности кластеризации (т.е. нет никакой необходимости ни настраивать Microsoft Cluster Services, ни платить за Enterprise лицензию Windows Server). Более того, настоятельно рекомендуется развернуть сразу два сервера AutoVirt в кластере. Настройка кластеризации происходит автоматически, при установке ПО - ничего для этого делать дополнительно не нужно. Полностью поддерживается установка в виртуальную инфраструктуру, более того, в большинстве случаев рекомендуется изначально идти именно по такому пути (по крайней мере на сравнительно небольших инсталляциях).
Концептуально схема AutiVirt выглядит так:
Политиками (Policy Engine) в каждый момент времени управляет только один сервер, но в случае его сбоя, управление будет передано на вторую машину. Policy Engine фактически управляет всей работой комплекса. Data Engine (DE) - это процессы, обеспечивающие всю "грязную работу" - миграцию и репликацию данных, т.е. все действия связанные с физическим передвижением файлов между системами. DE работают на обеих машинах одновременно. Более того, если производительности для какой-то глобальной миграции данных недостаточно, то число серверов DE можно увеличить. Скажем, для ускорения миграции файлов на только что закупленный новый NAS, можно на время увеличить число Data Engine, тем самым практически пропорционально сократив время миграции. Процесс Client Referrals, в свою очередь, отвечает на запросы клиентов. Процесс работает параллельно на нескольких серверах. Если в компании есть удаленные офисы, где работает свой сервер AD, то рекомендуется в них разместить дополнительные серверы AutoVirt, чтобы обеспечить бесперебойную работу клиентов в случае обрыва каналов связи.
Управление AutoVirt'ом осуществляется через простую и интуитивно понятную WEB-консоль, никакого дополнительного ПО (кроме браузера с поддержкой Microsoft SilverLight) администратору не требуется:
На главной странице представлен весь спектр возможностей, а также последовательность действий для достижения необходимого результата, так что даже не читая документацию можно быстро разобраться что к чему.
"Прозрачное" внедрение в инфраструктуру.
Добавление файлового сервера под управление AutoVirt делается в два этапа:
- На первом происходит просто сканирование файловых ресурсов, а самому серверу присваивается новое, "виртуальное" имя. При этом, никаких изменений в инфраструктуре в этот момент вообще не происходит - сервер остается доступен всем клиентам. Все файлы на нем также доступны со своими привычными UNC именами. По-умолчанию, виртуальное имя сервера отличается от "настоящего" приставкой "av-", впрочем, его можно задать и совершенно произвольно (главное, чтобы другого сервера с таким именем не было).
- Для того, чтобы полностью виртуализировать файловый ресурс (например \\fileserver) и "отвязать" его имя от "железного воплощения", необходимо запустить так называемый процесс "Cutover". Физически он сводится к тому, что мы (под руководством AutoVirt) меняем имя сервера на новое, а запросы к изначальному имени перенаправляются с этого момента на сервер AutoVirt. Собственно это и есть единственный перерыв в обслуживании - смена имени сервера требует его обязательной перезагрузки. Все остальное время все ресурсы сервера доступны пользователям в полном объеме! Т.е. время простоя сервиса составляет всего несколько минут! Теперь любой запрос к \\fileserver будет происходить через AutoVirt, который переадресует его на нужный сервер (либо на оригинальный, либо же на любой другой сервер, если была осуществлена миграция данных).
После такой несложной процедуры администраторам системы становятся доступны все прелести глобального пространства имен. Можно запустить процесс миграции данных на другой сервер, можно настроить репликацию данных между серверами, архивацию редкоиспользуемых данных.
А как быть, если вдруг потребуется отказаться от AutoVirt? И это тоже очень просто - достаточно произвести еще один Cutover, чтобы вернуть все на круги своя. Правда здесь уже нужно быть осторожнее - если была осуществлена миграция данных, процедура не столь тривиальна (иначе данные перестанут быть доступны по привычным UNC именам).
Поддержка DFS.
В AutoVirt есть также и поддержка Microsoft DFS. Реализована она полностью аналогичным образом, что и виртуализация файловых серверов. Сначала дерево DFS импортируется, а потом необходимо произвести переключение на AutoVirt. После этого DFS уже больше не используется, а весь функционал глобальной системы имен ложится на плечи AutoVirt. Важно помнить, что состояние DFS отображается на момент импорта и не синхронизируется повторно, в случае внесения каких-либо изменений в DFS. Поэтому если стоит задача перейти от DFS к AutoVirt, не следует это делать параллельно с активным редактированием DFS - либо одно, либо другое.
Добавление новых ресурсов в независимый Namespace делается очень просто - перетаскиванием нужных ресурсов мышкой. Миграция на AutoVirt может быть проведена довольно быстро (и разумеется совершенно прозрачно для пользователей). Сама служба DFS для функционирования AutoVirt не нужна, да и AutoVirt предоставляет гораздо больше возможностей:
Политики управления данными.
Основной плюс AutoVirt - это возможность не просто создать глобальное пространство имен, но и обеспечить управление неструктурированными данными на основе предопределенных администратором политик.
Представьте, что стоит задача перенести все файловые ресурсы с нескольких старых серверов на новый. А если все эти ресурсы активно используются? А если, помимо этого, нужно сохранить ссылки на ресурсы неизменными, а DFS не используется? А если нужно не только перенести данные, но старые серверы вообще вывести из обслуживания, либо использовать для других нужд? Любое из этих "если" добавляет головную боль. Вот здесь преимущества от использования AutoVirt и глобальной системы имен файлов выходит на первый план. Администратору достаточно добавить новую политику (Migration) через web-интерфейс, выбрать что и куда мы хотим перенести, задать время и подождать окончания процесса. Все! Больше ничего делать не нужно. Пользователи не заметят вообще ничего. Более того, если исходный файловый ресурс имеет громадный объем и сильно нагружен, мы можем задать предварительное копирование данных в удобный нам интервал времени (вероятно это будет ночь). В это время файлы будут постепенно копироваться на новый ресурс и в момент фактической миграции потребуется скопировать только изменившиеся с момента предварительной синхронизации файлы и переключить пользователей на новый сервер (еще раз отметим, что все это делается без участия администратора). Важно, что корректно будет произведена не только миграция самих файлов, но и всех прав доступа (ACL). Если необходимо осуществить миграцию настолько большого объема данных, что два стандартных Data Engine (про них подробнее написано выше) не справляются с поставленной задачей за приемлемое время, то достаточно просто добавить нужное количество серверов на время миграции (никаких дополнительных лицензий для этого не потребуется). Так как DataEngine работают независимо, то рост их числа практически линейно увеличит скорость миграции (если конечно сам файловый сервер справляется с такой нагрузкой).
Но миграцией возможности AutoVirt не ограничиваются - список политик включает в себя:
- Measure - это просто отчет о том как используется дисковое пространство (число файлов, их объем и т.п.). Позволяет оценить требования к ресурсам для дальнейших операций по миграции/репликации.
- Copy - копирование данных. Отличается от миграции тем, что не происходит переключение пользователей на новый ресурс. Зато можно отфильтровывать файлы по типу. Это довольно ограниченная по возможностям политика, так что если нужны дополнительные функции следует использовать Replication. Однако именно она замечательно подходит для сохранения данных в рамках следования требованиям законодательства (compliance).
- Replication - пожалуй, самая "продвинутая" по возможностям опция. Именно она при миграции с DFS будет альтернативой использованию DFS-R.
Несколько слов подробнее про каждый из типов репликации:
Клонирование "один источник - один клон" предназначено для обеспечения отказоустойчивости. Данные "мастера" реплицируются на удаленную площадку, а в случае сбоя происходит перенаправление клиентов на реплику.
Отношение "один источник - много клонов" удобно для организации с множеством филиалов, в каждым из которых необходимо обеспечить доступность однотипных материалов в режиме чтения. Это позволит сократить расходы и снизить загрузку каналов связи. В случае сбоя, запросы будут перенаправлены на ближайший к клиенту сервер.
Если в организации много филиалов и стоит задача централизованно хранить данные, то замечательно подойдет третий вариант - "много источников - один клон". В случае сбоя на удаленной площадке, failover будет индивидуальным для каждого филиала (т.е. отсутствует влияние на остальных - они продолжат работу в обычном режиме).
Во всех описанных вариантах, для восстановления после сбоя следует использовать миграцию, чтобы произвести обратную синхронизацию данных и осуществить переключение пользователей на исходный ресурс.
- Archive - очень простое и удобное средство реализации системы двухуровнего хранения. Зачастую пользователи хранят множество файлов, независимо от актуальности этих данных. Данная политика позволяет перемещать редкоиспользуемые файлы на медленные (более бюджетные) системы хранения, оставляя пользователям полный и совершенно прозрачный доступ к самим данным:
- И, наконец, последняя политика Deletion - удаляет все исходные данные после успешной миграции. Политика простая, но применяется крайне редко (ввиду очевидного риска).
Для всех политик можно задать так называемый "тихий час", когда никакие действия производиться не могут - например в периоды максимальной загрузки системы. Это позволяет избежать излишней нагрузки и обеспечить максимально комфортную работу пользователей.
Простая интеграция в инфраструктуру, весьма продвинутые возможности по обеспечению высокой доступности (как самой глобальной системы имен, так и непосредственно файловых ресурсов), набор удобных политик для управлению ресурсами, полная поддержка ACL при любых миграциях/репликациях, а также интуитивно понятный интерфейс - все это делает продукт по настоящему уникальным.
