Статья только в электронной версии журнала

Статья только в электронной версии журнала

ТЕХНИЧЕСКИЙ АНАЛИЗ    

Мосты между островками помогают ресурсам хранения общаться между собой

В ближайшие годы нам предстоит стать свидетелями эволюционных изменений в развитии сетей хранения (SAN). Маленькие разрозненные пулы хранения обещают превратиться в маршрутизируемые сети, способные создать общее пространство в масштабах всей компании.

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

Безусловно, какие-то уроки производители средств сетевого хранения из той истории извлекли, но SAN слишком уж сильно отличается от IP с технической точки зрения. К тому же в этой области предстоит решить несколько уникальных проблем, связанных с унаследованными технологиями Fibre Channel.

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

Тяжеловесы в этой области, включая Cisco Systems и Brocade Communications Systems, стремятся развивать новые технологии, не заставляя при этом пользователей проводить массовую модернизацию своих сетей. Но прежде чем вдаваться в детали маршрутизации SAN, давайте взглянем на некоторые причины, которые делают ее насущной необходимостью.

Нынешнее состояние сетей хранения

Даже в самых современных компаниях с богатыми технологическими бюджетами топологическая схема ресурсов хранения обычно состоит из отдельных островков со спорадическими взаимосвязями между собой (см. рис. 1).

Обособленность нынешних SAN

Первые SAN развертывались с учетом потребностей конкретного подразделения или нового приложения, в результате чего в большинстве компаний появилось по нескольку небольших сетей хранения (сеть PeopleSoft или Exchange, сеть бухгалтерии и т. д.), функционирующих независимо друг от друга. Тогда и речи не шло о создании единой SAN в масштабах всей компании, которая управлялась бы централизованно, открывая общий доступ ко всем ресурсам хранения.

"Островная" конфигурация не только невероятно усложняет процессы управления, но замыкает каждую SAN в собственном пространстве хранения. Когда, например, оказываются переполненными ресурсы сети PeopleSoft, менеджеру ИТ не остается ничего иного, как тратиться на новую систему хранения, пусть даже на соседнем островке все еще остается масса незадействованного пространства.

Эту проблему, казалось бы, можно решить простой прокладкой межкоммутаторной линии ISL, соединяющей между собой отдельные островки. Однако такой путь сразу же снижает общую производительность сети хранения.

К тому же он и опасен. В волоконно-оптических сетях Fibre Channel адаптеры серверных хост-шин и устройства хранения получают адреса от коммутатора Fibre Channel в момент первого подключения. Каждому такому коммутатору здесь присваивается собственный идентификатор домена (всего имеется 239 возможных вариантов), на основе которого и генерируются уникальные адреса соединенных с ним устройств. Если же в одной упряжке оказываются два коммутатора с одинаковыми идентификаторами, то начинается сложный процесс повторного конфигурирования связной инфраструктуры с массовой проверкой и переназначением адресов. Это требует, как правило, отключения всех компонентов инфраструктуры, что приводит к сбоям в работе приложений и незапланированным простоям SAN.

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

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

Решения для маршрутизации SAN

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

В своем решении SilkWorm Multiprotocol Router фирма Brocade разместила маршрутизатор между островками SAN, возложив на него роль виртуального коммутатора. Такие компоненты фирма называет "фантомными коммутаторами" (рис. 2). Каждый маршрутизатор связан здесь со всеми коммутаторами островков SAN, благодаря чему получает информацию об их конфигурации, которую использует для построения маршрутизирующих таблиц. Как только устройство одного островка получает разрешение на подключение к собрату с другого острова, маршрутизатор принимает данные отправителя, преобразует их с помощью операции NAT (Network Address Translation - трансляция сетевых адресов), а затем пересылает получателю. Благодаря такой схеме сети Brocade допускают использование одинаковых идентификаторов домена, а также полностью избавляют администратора SAN от необходимости заново конфигурировать всю инфраструктуру.    

Brocade поручает сбор данных фантому

Фирма Cisco вышла на рынок SAN сравнительно поздно, но именно поэтому она могла воспользоваться опытом первопроходцев. Вооружившись технологиями и идеями из мира IP-сетей, компания создала собственную технологию маршрутизации VSAN (Virtual SAN - виртуальная сеть хранения). Ее разработка под названием Inter-VSAN разделяет трафик на отдельные сегменты, что делает работу больших сетей хранения более эффективной.

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

Технология Cisco VSAN (рис. 3) предусматривает включение в заголовок кадров Fibre Channel дополнительной информации, которая привязывает их к конкретной сети хранения. Такое "тегирование" очень напоминает процесс, знакомый нам по сегодняшним виртуальным частным IP-сетям.

Cisco манипулирует тегами пакетов

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

Недавно технический комитет Т11 Международной комиссии стандартов на информационные технологии принял разработку Cisco VSAN за основу для создания отраслевого стандарта виртуальной связной архитектуры. Впоследствии, как ожидается, ее утвердит и Американский национальный институт стандартов - ANSI.

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

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

В феврале Cisco обещает представить очередную версию своей технологии маршрутизации Inter-VSAN, не требующую присваивать каждому коммутатору уникальный идентификатор. Судя по заявлению представителей фирмы, эта новинка позволит менеджерам ИТ самим выбирать, стоит ли применять в сетях хранения трансляцию адресов NAT или лучше воспользоваться маршрутизацией без такого преобразования.

Но как бы то ни было, а сети хранения растут и усложняются, и в таких условиях маршрутизаторы SAN становятся жизненно важным компонентом корпоративных сред ИТ.

Со старшим аналитиком Генри Балтазаром можно связаться по адресу: henry_baltazar@ziffdavis.com.

Версия для печати