Autovirt – новые возможности

К уже и без того впечатляющему функционалу AutoVirt появилось прибавление!

• Стала поддерживаться интеграция с NetApp SnapMirror: 
  можно как импортировать существующие настройки, так и создавать новые “зеркальные” пары. Кроме того, можно обеспечить автоматизированный или ручной failover через глобальное пространство имен AutoVirt.
  
• Управление NetApp SnapLock:
  - через функционал архивирования можно перемещать (на основе фильтров) файлы из любой файловой  “шары” на том с включенным SnapLock.
  - можно также импортировать настройки SnapLock и управлять опциями через GUI AutoVirt

Обе возможности должны быть весьма интересны владельцам систем хранения NetApp. Причем политики миграции данных на SnapLock том могут заметно упростить жизнь при планировании инфраструктуры. Далеко не все данные необходимо хранить неизменными, поэтому нужно каким-либо образом отправить на SnapLock том только определенные файлы и здесь серьезным подспорьем будет AutoVirt.

Читать дальше ...

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

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

Политики управления данными.

Основной плюс AutoVirt - это возможность не просто создать глобальное пространство имен, но и обеспечить управление неструктурированными данными на основе предопределенных администратором политик. 
Представьте, что Вам нужно перенести все файловые ресурсы с нескольких старых серверов на новый. А если все эти ресурсы активно используются? А если нужно сохранить ссылки на ресурсы неизменными, а DFS не используется? А если нужно не только перенести данные, но старые серверы вообще вывести из обслуживания, либо использовать для других нужд? Любое из этих "если" добавляет головную боль. Вот здесь преимущества от использования AutoVirt и глобальной системы имен файлов выходит на первый план! Нам достаточно добавить новую политику (Migration) через web-интерфейс, выбрать что и куда мы хотим перенести, задать время и подождать окончания процесса. Все! Больше ничего делать не нужно. Пользователи не заметят вообще ничего. Более того, если исходный файловый ресурс имеет громадный объем и сильно нагружен, мы можем задать предварительное копирование данных в удобный нам интервал времени (вероятно это будет ночь). В это время файлы будут постепенно копироваться на новый ресурс, тогда в момент фактической миграции потребуется скопировать только изменившиеся с момента предварительной синхронизации файлы и переключить пользователей на новый сервер (еще раз отмечу, что все это делается без участия администратора). Важно, что корректно будет произведена не только миграция самих файлов, но и всех прав доступа (ACL). Если необходимо осуществить миграцию настолько большого объема данных, что два стандартных Data Engine (про них подробнее написано во второй части) не справляются с поставленной задачей за приемлемое время, то достаточно просто добавить нужное количество серверов на время миграции (никаких дополнительных лицензий для этого не потребуется). Так как DataEngine работают независимо, то рост их числа практически линейно увеличит скорость миграции (если конечно сам файловый сервер справляется с такой нагрузкой).

Но миграцией возможности AutoVirt не ограничиваются - список политик включает в себя:

• Measure - это просто отчет о том как используется дисковое пространство (число файлов, их объем и т.п.). Позволяет оценить требования к ресурсам для дальнейших операций по миграции/репликации.
• Copy - копирование данных. Отличается от миграции тем, что не происходит переключение пользователей на новый ресурс. Зато можно отфильтровывать файлы по типу. Это довольно ограниченная по возможностям политика, так что если нужны дополнительные функции следует использовать Replication.
• Replication - пожалуй, самая "продвинутая" по возможностям опция. Именно она при миграции с DFS будет альтернативой использованию DFS-R.
  

  

  Несколько слов подробнее про каждый из типов репликации: 
  Клонирование "один источник - один клон" предназначено для обеспечения отказоустойчивости. Данные "мастера" реплицируются на удаленную площадку, а в случае сбоя происходит перенаправление клиентов на реплику. 
  Отношение "один источник - много клонов" удобно для организации с множеством филиалов, в каждым из которых необходимо обеспечить доступность однотипных материалов в режиме чтения. Это позволит сократить расходы и снизить загрузку каналов связи. В случае сбоя, запросы будут перенаправлены на ближайший к клиенту сервер.
  Если в организации много филиалов и стоит задача централизованно хранить данные, то замечательно подойдет третий вариант - "много источников - один клон". В случае сбоя на удаленной площадке, failover будет индивидуальным для каждого филиала (т.е. отсутствует влияние на остальных - они продолжат работу в обычном режиме).
  Во всех описанных вариантах, для восстановления после сбоя следует использовать миграцию, чтобы произвести обратную синхронизацию данных и осуществить переключение пользователей на исходный ресурс.

• И, наконец, последняя политика Deletion - удаляет все исходные данные после успешной миграции. Политика простая, но применяется крайне редко (ввиду очевидного риска).

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

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

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

А для тех, кто продолжает использовать в своей инфраструктуре Brocade StorageX (и имеет оплаченную поддержку), есть очень заманчивое предложение – до 30 июня 2010г. действует специальная акция со скидками при замене лицензий StorageX на AutoVirt.

Читать дальше ...

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

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

"Прозрачное" внедрение в инфраструктуру.

Добавление файлового сервера под управление AutoVirt делается в два этапа:

1. На первом происходит просто сканирование файловых ресурсов, а самому серверу присваивается новое, "виртуальное" имя. При этом, никаких изменений в инфраструктуре в этот момент вообще не происходит - сервер остается доступен всем клиентам. Все файлы на нем также доступны со своими привычными UNC именами. По-умолчанию, виртуальное имя сервера отличается от “настоящего” приставкой "av-", впрочем, его можно задать и совершенно произвольно (главное, чтобы другого сервера с таким именем не было).
   Теперь ко всем ресурсам файлера можно также обращаться, используя не только привычное UNC имя, но и виртуальное имя сервера. На практике это конечно не нужно, но зато дает возможность убедиться в том, что сервер AutoVirt нормально функционирует и можно приступать ко второму этапу. На картинке видно, что у нас есть Dependent (зависимое) пространство имен - это означает, то ресурсы хотя и доступны через сервер AutoVirt, но они "привязаны" к физическому серверу и пока еще не могут быть перенесены с него на другой файлер.
2. Для того, чтобы полностью виртуализировать файловый ресурс (например \\fileserver) и "отвязать" его от "железа", необходимо запустить так называемый процесс "Cutover". Физически он сводится к тому, что мы (под руководством AutoVirt) меняем имя сервера на новое, а запросы к изначальному имени перенаправляются с этого момента на сервер AutoVirt. Собственно это и есть единственный перерыв в обслуживании - смена имени сервера требует его обязательной перезагрузки. Все остальное время все ресурсы сервера доступны пользователям в полном объеме! Т.е. время простоя сервиса составляет всего несколько минут! Теперь любой запрос к \\fileserver будет происходить через AutoVirt, который переадресует его на нужный сервер (либо на оригинальный, либо же на любой другой сервер, если была осуществлена миграция данных).

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

А как быть, если нам потребуется отказаться от AutoVirt (всем система хороша, но бюджет на нее выделили только на следующий год)? И это тоже очень просто - достаточно произвести еще один Cutover, чтобы вернуть все на круги своя. Правда здесь уже нужно быть осторожнее - если была осуществлена миграция данных, процедура не столь тривиальна (иначе данные перестанут быть доступны по привычным UNC именам).

Поддержка DFS.

В AutoVirt есть также и поддержка Microsoft DFS. Реализована она полностью аналогичным образом, что и виртуализация файловых серверов. Сначала DFS испортируется, а потом необходимо произвести переключение на AutoVirt. После этого DFS уже больше не используется, а весь функционал глобальной системы имен ложится на плечи AutoVirt. Важно помнить, что состояние DFS отображается на момент импорта и не синхронизируется повторно, в случае внесения каких-либо изменений в DFS. Поэтому если стоит задача перейти от DFS к AutoVirt, не следует это делать параллельно с активным редактированием DFS - либо одно, либо другое. 
Добавление новых ресурсов в независимый Namespace делается очень просто  - перетаскиванием нужных ресурсов мышкой. DFS для функционирования AutoVirt не нужна (благо AutoVirt предоставляет гораздо больше возможностей), а миграция может быть осуществлена предельно просто и быстро.

Подробный рассказ о главных преимуществах AutoVirt ждите в заключительной части. А пока (для затравки) сравнение возможностей с DFS:

Читать дальше ...

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

Это продолжение ранее начатой короткой серии заметок про управление файловыми серверами.

Так какие же есть альтернативные (предлагаемому Microsoft DFS) решения, чтобы удобно, просто и по возможности прозрачно для существующей инфраструктуры получить глобальное пространство имен? Рассказ пойдет о продукте компании AutoVirt. Первое, что бросается в глаза, - это не надстройка и не дополнение к Microsoft DFS. AutoVirt является совершенно самостоятельным решением и для его работы не требуется ни DFS, ни DFS-R - нужен только домен и конечно сами файловые серверы. Какие положительные качества решения можно выделить:

• отказоустойчивость "by design"
• прозрачное внедрение в инфраструктуру без необходимости что либо менять у пользователей
• поддержка DFS
• различные политики, обеспечивающие управление данными (миграция, репликация и т.п.)

Сначала немного остановимся на принципах работы, а затем я постараюсь подробнее описать каждую из "особенностей" AutoVirt.
Реализация глобальной системы имен основана на перенаправлении DNS запросов. Обычно, при обращении к папке на сервере, когда мы набираем \\A\myshare, сначала идет запрос к серверу DNS, который нам возвращает IP адрес сервера "A". А уже потом мы с этого файл-сервера получаем необходимые нам данные:

Глобальная система имен в AutoVirt работает почти также, только теперь разрешением имен занимается не DNS, а сервер AutoVirt, на который DNS сервер и перенаправляет все запросы:

Благодаря такому подходу, становится возможным динамически менять ссылки на ресурсы без каких-либо видимых последствий у пользователей - если все данные были перенесены на сервер "B", то достаточно изменить ссылку на уровне сервера AutoVirt и пользователи будут уже обращаться к новому серверу, а старый можно выводить из обслуживания. Так ведь и Microsoft DFS работает точно также, скажете Вы! Где научная новизна?! Где преимущества? За что деньги-то платить? И будете правы (но лишь отчасти) - сама по себе глобальная система имен работает примерно одинаково у всех производителей. Дьявол кроется, как обычно, в деталях. Давайте к ним и обратимся!

Отказоустойчивость и схема работы.

Совершенно очевидно, что для обеспечения нормальной работы пользователей необходима высокая доступность Global Namespace (глобального пространства имен). AutoVirt имеет встроенные возможности кластеризации (т.е. нет никакой необходимости ни настраивать Microsoft Cluster, ни платить за Enterprise лицензию Windows Server). Более того, настоятельно рекомендуется развернуть сразу два сервера AutoVirt в кластере. Настройка кластеризации происходит автоматически, при установке ПО - ничего для этого делать дополнительно не нужно. Полностью поддерживается установка в виртуальной инфраструктуре, более того, в большинстве случаев рекомендуется изначально идти именно по такому пути (по крайней мере на сравнительно небольших инсталляциях).

Концептуально схема AutiVirt выглядит так:

Политиками (Policy Engine)  в каждый момент времени управляет только один сервер, но в случае его сбоя, управление будет передано на вторую машину. Policy Engine фактически управляет всей работой комплекса. Data Engine (DE) - это процессы, обеспечивающие всю "грязную работу" - миграцию и репликацию данных, т.е. все действия связанные с физическим передвижением файлов между системами. DE работают на обеих машинах одновременно. Более того, если производительности для какой-то глобальной миграции данных недостаточно, то число серверов DE можно увеличить. Скажем, для ускорения миграции файлов на только что закупленный NAS, можно на время увеличить число Data Engine, тем самым практически пропорционально сократив время миграции. Client Referrals, в свою очередь, отвечает на запросы клиентов. Процесс работает параллельно на нескольких серверах. Если в компании есть удаленные офисы, где работает свой сервер AD, то рекомендуется в них  разместить дополнительные серверы AutoVirt, чтобы обеспечить бесперебойную работу клиентов в случае обрыва каналов связи.

Управление AutoVirt'ом осуществляется через простую и интуитивно понятную WEB-консоль, никакого дополнительного ПО (кроме браузера с поддержкой SilverLight) администратору не требуется:

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

Про остальные преимущества и возможности AutoVirt в плане прозрачной интеграции в уже имеющуюся инфраструктуру рассказ будет продолжен завтра.

Читать дальше ...

Глобальное пространство имен файлов (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, пора бы уже задуматься об адекватной замене, так как оплаченная поддержка уже либо  закончилась, либо подходит к концу.

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

Читать дальше ...