Сети хранения в ретроспективе и перспективе

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

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

ИЗМЕНЕНИЯ ЗАДАЧ ИНФРАСТРУКТУРЫ ИТ

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

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

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

Хранимые в электронном виде данные приобретают критическое значение для предприятия: потеря оборудования — еще не потеря бизнеса, потеря данных — реальная угроза потери бизнеса. Если раньше электронные таблицы часто дублировали бухгалтерские книги и всю информацию можно было восстановить с бумажной копии, то сегодня приложения ERP и CRM не имеют «твердых копий», поэтому их остановка, а тем более полная неработоспособность принципиально не могут быть компенсированы увеличением числа исполнителей и обработкой заказов «вручную». Причем данные не просто необходимо «где-то хранить», они должны быть своевременно доступны и иметь многолетнюю гарантию абсолютной сохранности — это требование не только логики бизнес-процессов, но и законодательства. Таким образом, вместо термина «хранение информации» и даже более современного «управление информацией» все чаще используется более емкое понятие «управление жизненным циклом информации».

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

Приложения становятся все более диверсифицированными. Тем не менее все более сложная функциональность решений должна быть предложена конечным пользователям в доступном виде. Разрешить дилемму можно путем консолидации и централизации аппаратных ресурсов и логики приложения/функционала системы. (Недаром число инсталляций мэйнфреймов, этих «динозавров» рынка ИТ, постоянно возрастает, поскольку они идеально удовлетворяют условию консолидации ресурсов.) Как следствие, требование сквозной управляемости — «прозрачности» системы для управляющего приложения — из красивой идеи превратилось в насущную необходимость.

«Цена вопроса» переместилась от оценки первоначальных инвестиций в оборудование к анализу средней стоимости владения. Несмотря на провозглашаемые лозунги «сокращения затрат на ИТ», налицо тенденция удорожания систем в целом, а удешевление устаревших компонентов или ПК начального уровня погоды не делает. Где же выход? Выбрать такое решение, чтобы оно прослужило как можно дольше и чтобы от него не пришлось отказаться завтра из-за неверно предсказанного пути развития технологий. Для этого оно должно основываться на стандартах и поддерживать наращивание с минимальным выбыванием устаревших компонентов, допускать бесшовную интеграцию небольших систем в состав крупных и их работу внутри гетерогенных инсталляций.

РОЛЬ СИСТЕМ ХРАНЕНИЯ В ИНФРАСТРУКТУРЕ ИТ

Если методы обработки данных меняются достаточно быстро — синхронно со сменой серверного парка, т. е. примерно раз в пять лет, то методы хранения данных должны обеспечивать обратную совместимость на срок, равный времени жизни основной части информации, а это уже периоды порядка 25—250 лет и более. Откладывать выбор системы хранения «на потом» уже нельзя, так как это существенно снизит эффективность инфраструктуры ИТ и бизнеса компании в целом.

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

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

СЕТИ ХРАНЕНИЯ ВЧЕРА

В решениях по хранению принято разделять непосредственно подключаемые хранилища по принципу «один к одному» (Direct Attached Storage, DAS), например внутренние диски сервера, внешние дисковые массивы или другие накопители, сетевые файловые системы (Network Attached Storage, NAS) и сети хранения (Storage Area Network, SAN).

По оценкам аналитиков, около 80% всех хранилищ относятся к типу DAS, из оставшихся большая часть приходится на SAN. Однако в связи с наметившимися тенденциями в ближайшие годы доля DAS должна уменьшиться до 60%, в основном за счет роста сегмента SAN. Темпы роста бюджетов на внедрение оборудования для сетей хранения, как правило, в два и более раз выше темпов роста сектора ИТ в целом. Что касается систем NAS, то это тема отдельной статьи, многогранная и интересная, но относящаяся к другому классу задач. Для облегчения выбора решения и снижения затрат при его последующем расширении многие производители предлагают комбинированные системы хранения, которые способны работать (причем параллельно) в составе систем SAN и NAS.

Первые сети хранения появились одновременно с дисками, оснащенными интерфейсом FC-AL. Такие диски не подключались к общей шине, а объединялись в кольцо (Private Loop) с функциями арбитража. При разделяемой пропускной способности 200 Мбит/с оно позволяло адресовать до 126 оконечных устройств (используя 8-разрядный физический адрес устройства Arbitrated Loop Physical Address, AL_PA) и реально поддерживало десятки дисков, т. е. топология имела немало черт, характерных для локальной сети. К кольцу можно было подключать не только диски, но и сами хосты.

Из-за своих размеров, энергопотребления и тепловыделения наборы дисков начала 90-х гг. чаще размещались в отдельных кабинетах, число которых увеличивалось по мере наращивания емкости хранилища. К тому же во многих инсталляциях требовалось подключать два и более хоста (сервера) к кабинетам с дисками. Использовать частное кольцо Private Loop было не очень удобно из-за ограничений по масштабируемости, и задача решалась путем применения специальных концентраторов Fibre Channel. С их помощью несколько колец с «гирляндами» дисков Fibre Channel сопрягались в общее кольцо (Public Loop), куда включались и хосты.

Такая топология позволяла адресовать до десятков тысяч устройств в одном домене (в качестве старших разрядов к AL_PA добавлялся 8-разрядный идентификатор Area, а восемь самых старших разрядов адреса занимал фиксированный для данного домена Switch Domain ID — уникальный идентификатор концентратора), реально обеспечивая соединение многих хостов со многими целями (к тому времени уже появились соответствующие системы хранения, и хост, как правило, «видел» не физические диски, а логические тома). Решение доказало свою жизнеспособность, и небольшие сети из концентраторов получили широкое распространение в Америке и Европе, а последние модели были сняты с производства буквально два-три года назад.

Однако задачи постоянно усложняются, требуя большей производительности (вместо типичной — в десятки Мбит/с — уже стала нужна производительность в сотни Мбит/с, т. е. на порядок больше) и функциональности (для решения задач консолидации и виртуализации). Разделяемое между устройствами кольцо и неинтеллектуальные концентраторы не могли обеспечить адекватного ответа.

Несколько раньше те же проблемы роста возникли в локальных сетях, и решение для обоих типов сетей было одинаковым — использование коммутаторов. Сеть с коммутаторами Fibre Channel стали называть «структура» (fabric), чтобы отличать от сетей, где организуются кольца Private Loop и применяются концентраторы FC-AL. Помимо базовой функции передачи соответствующих кадров коммутаторы Fibre Channel реализуют и функции предоставления «встроенных» (в смысле стека протоколов Fibre Channel) сервисов широковещания (broadcast server), регистрации (fabric login, FLOGI), контроллера (fabric controller), службу каталога/имен (directory/name server), времени (time server), управления (management server), переименования (alias server), многоадресной рассылки (multicast server). Без некоторых из этих сервисов функционирование сети невозможно (например, без регистрации в коммутирующей структуре хост не получит доступа к целям), другие — опциональны.

В моделях коммутаторов старшего класса применяются специальные сервисные модули, отвечающие за продвинутую функциональность виртуализации. По сути это специализированные серверы, на которых выполняется прикладное ПО (например, от Veritas или IBM). Как показывают тесты, такой подход по сравнению с отдельным сервисом программной виртуализации не снижает производительности, но повышает масштабируемость и надежность сети. Кроме того, среди коммутаторов Fibre Channel принято выделять так называемые директора (Director-Class Switches) — модели старшего класса (обычно шасси, вмещающие до 10 модулей с избыточностью) с возможностью одновременной работы через все порты. «Остальные» коммутаторы называют просто структурными коммутаторами (fabric switches).

КАК РАБОТАЮТ КОММУТАТОРЫ

Многие производители представляют свои коммутаторы как «полностью неблокирующие», в то же время наличие блокировок трафика выявляют простые тесты. Секрет кроется в адекватном понимании термина «блокировка», под которой подразумевается отсутствие у кадра возможности продвигаться далее по сети. Причины могут быть различными, и применение супербыстрой матрицы коммутации устраняет лишь часть из них, но неспособно бороться, в частности, с проблемой «закупорки линии» (Head Of Line Bloсking), когда, например, в сети имеются устройства с принципиально разным быстродействием. В результате передача кадров с выходного порта в сторону более медленного устройства может заблокировать на входном порту последовательность кадров от быстрого устройства. Матрица в этом случае бессильна, да и увеличение размера буфера не поможет. Кадр не может быть сброшен, но долгое ожидание в буфере коммутатора будет восприниматься конечным устройством точно так же, как если бы кадр «потерялся» где-то в сети.

Предсказать реальную картину потоков кадров достаточно сложно, поэтому противодействие таким типам блокировок следует осуществлять при помощи автоматизированных, по возможности, инструментов. Именно для этой цели разработана виртуальная исходящая очередь (Virtual Output Queueing) — кадры из разных потоков на входном порту сортируются в целях устранения зависимости с наполнением буферов на выходных портах. Подобная проблема (так называемая «мгновенная блокировка») стала часто встречаться в локальных сетях с распространением Gigabit Ethernet — с ней не могут эффективно справиться недорогие коммутаторы, даже при заявленной обработке пакетов со скоростью поступления (wire speed) лишь очень немногие из производителей реализовали очереди на входе и механизмы их «автоматической настройки» в целях ее предотвращения.

Для оптимизации стоимости решения порты в коммутаторах иногда разделяют на две группы: для подключения устройств хранения (storage-optimized) и для подключения хостов (host-optimized). Первый тип портов всегда имеет доступ к коммутирующей схеме со скоростью поступления пакетов, группа портов второго типа (обычно из четырех портов) разделяет доступ к коммутационному полю с суммарной скоростью, равной номинальной. Производители вовсе не хотят обмануть заказчика. Просто грамотный дизайн сети хранения всегда подразумевает определенное избыточное бронирование (oversubscription). При этом порты коммутатора для подключения устройств хранения или других коммутаторов более или менее постоянно загружены трафиком, в то время как порты коммутатора для подключения серверов заняты время от времени. Таким образом обеспечиваются сбор трафика с нескольких портов для серверов и отправка его на один порт для системы хранения. Фокус в том, что коммутатор не обязан поддерживать какую-то конкретную скорость передачи «здесь и сейчас», но он обязан не допустить потери ни одного кадра. Если этого можно добиться за меньшие деньги, то почему бы и нет?

При построении распределенных сетей хранения нужно учитывать еще один важный факт, который нередко игнорируется производителями коммутаторов, — возможность перераспределения между портами межбуферных кредитов (сокращенно Buffer-to-Buffer, ВВ). Дело в том, что в стеке протоколов Fibre Channel предусмотрено несколько протоколов транспортного уровня, так называемых классов FC (Классы 1—3 предназначены для пользовательских данных, а Класс F — специальный), они различаются по поддержке соединений и наличию подтверждений (выбор вариантов даже более широк, чем в TCP/IP). Однако на практике используется Класс 3, примерно соответствующий UDP в стеке TCP/IP. Транспортный уровень не предусматривает механизма подтверждений отправителю со стороны конечного адресата, однако подтверждения между каждой парой соседних устройств обязательны (хост—коммутатор, коммутатор—коммутатор, коммутатор—система хранения). Одновременно должны выполняться требования недопустимости потери кадров и оптимального наполнения канала кадрами, для чего нужен механизм контроля потока (flow control). Он реализуется с помощью межбуферных кредитов, величины которых задаются на этапе настройки коммутатора, а на этапе регистрации порты соседних устройств обмениваются «своими» значениями.

Для территориально распределенных сетей хранения расстояния могут измеряться сотнями километров, поэтому «в пути» между конечными устройствами находятся одновременно десятки кадров. Например, при скорости канала в 1 Гбит/с типичный кадр Fibre Channel длиной 2148 байт имеет пространственную протяженность около 4 км. Каждому кадру соответствует один кредит, причем буфер принимающей стороны уменьшается на размер кадра. Как только буфер обнуляется (все кредиты использованы), принимающая сторона посылает сигнал неготовности своему соседу, чтобы он приостановил передачу (сохраняя кадры в выходном буфере) до освобождения у нее хотя бы одного кредита.

По умолчанию значения межбуферных кредитов на портах большинства коммутаторов лежат в пределах от 2 до 8. В территориальной сети SAN обычно этого достаточно, однако при ее протяженности свыше 10 км необходимо иметь возможность варьировать значения кредита при настройке, особенно на портах между коммутаторами (к тому же отнюдь не все кадры имеют максимальную длину и для «укладывания в канал» одинакового объема полезной информации может понадобиться больше кредитов). Современное оборудование позволяет настроить на порту от 16 до 255 кредитов, в то время как «недорогие» коммутаторы ограничены значениями по умолчанию. Если в небольшой сети оба устройства покажут сопоставимую производительность, то в распределенной топологии производительность вторых упадет в 10—20 раз, а это означает неработоспособность всей сети!

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

ВСТРОЕННЫЕ СРЕДСТВА БЕЗОПАСНОСТИ SAN

В мире решений DAS защита информации опиралась на возможности ОС по разграничению прав доступа к объектам и возможности специализированного ПО (антивирусные системы, криптографические инструменты). Это накладывало существенные ограничения по гибкости, масштабируемости, управляемости, производительности и надежности. Благодаря модульной структуре стека Fibre Channel в полноценных решениях SAN удалось добиться максимальной гибкости функций защиты данных.

Первые решения SAN внедрялись в крупных производственных или финансовых холдингах, поэтому к вопросу защиты информации относились с максимальной серьезностью. В результате арсенал встроенных в SAN инструментов включает аутентификацию хостов путем процедур Fabric Login и Process Login, управление доступом хостов к целям с помощью разбиения на зоны (zoning) и списков доступа, а также новейшее достижение виртуализации — технологию VSAN, с помощью которой физическую сеть SAN можно «разрезать» на множество (теоретически — до 1000) виртуальных коммутирующих структур. Криптографические модули позволяют осуществлять аппаратное шифрование каналов по технологии FC-ESP, сервисные модули iSCSI/FCIP используют технологию IPSec, сеансы удаленного управления защищаются с применением протоколов SSH, SSL, SMNPv3 и т. п.

По сравнению с традиционными серверными инструментами SAN имеют следующие преимущества в обеспечении безопасности:

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

ГЛОБАЛЬНЫЕ СЕТИ SAN

Необходимость в глобальных решениях SAN обусловлена, во-первых, тенденцией укрупнения/слияния компаний, а во-вторых, возрастающим интересом к катастрофоустойчивым решениям. В первом случае необходимо объединять изолированные участки SAN (так называемые «островки» SAN), во втором — создавать дублированные территориально распределенные центры обработки данных, но варианты решений примерно одинаковы:

• в масштабах здания, небольшой группы зданий - Fibre Channel поверх выделенных оптических волокон (dark fiber);
• в масштабах небольшого города - транспорт Fibre Channel поверх систем CWDM;
• в масштабах мегаполиса, региона - транспорт Fibre Channel поверх систем DWDM/SDH;
• в масштабах страны - транспорт Fibre Channel поверх IP (FCIP). Как показывает практика, работоспособность основных приложений сохраняется при разнесении основного и резервного узлов на расстояние более 5000 км.

В этой связи полезно выделить факторы, ограничивающие масштабируемость. Для первых двух вариантов — это, как правило, суммарный оптический бюджет (так как данные схемы не предполагают дополнительных усилителей), для двух последних — оптимизация настроек на уровне Fibre Channel (вышеописанная процедура с выделением межбуферных кредитов), приспособленность специализированного ПО к задержкам, возможность тонкой настройки инфраструктуры IP (она реально ограничивается звеном с минимальным интеллектом — устройствами, приложениями или непрофессионализмом системных инженеров).

В FCIP оптимально сочетаются такие преимущества, как повсеместность транспорта IP и функциональность Fibre Channel. Часто технологии FCIP и iSCSI называют конкурирующими, не понимая принципиальной разницы в их идеологии и области применения. FCIP используется для создания туннелей между двумя коммутаторами Fibre Channel (или системами хранения со специальными сервисными модулями) в целях соединения островов SAN через магистральные (глобальные) сети IP (в случаях, когда варианты с DWDM/SDH недоступны либо слишком дороги). FCIP не применяется для соединения хостов и целей между собой или с коммутаторами. Эти объекты подключаются по «обычному» Fibre Channel и не имеют никакого отношения к сети IP.

Главная цель FCIP — обеспечить максимальную производительность при полной прозрачности для конечных узлов (а это не так-то просто — вспомним, что сети IP теряют пакеты, и проблема обеспечения в них сквозного качества обслуживания решена пока, в основном, лишь в локальных сетях).

С появлением систем и сетей хранения Fibre Channel встала задача осуществления экономичной интеграции в SAN небольших хостов с ограниченными требованиями к производительности и отказоустойчивости. Разумное решение в этом случае представляет отказ от внутренних дисков и обеспечение доступа хостов к централизованному хранилищу с использованием SCSI поверх IP (iSCSI). Соответствующая функциональность на хосте реализуется в драйвере, работающем «между» стеком TCP/IP и уровнем файловой системы. В системе хранения или коммутаторе устанавливается специальный программно-аппаратный шлюз в виде модуля для преобразования команд SCSI между транспортом IP и Fibre Channel.

Логичным развитием идеи стала загрузка серверов, в особенности рабочих станций, по сети посредством iSCSI. Экономия достигается не столько за счет отказа от встроенных дисков (прежде всего, в случае для рабочих станций), сколько благодаря централизации управления всем ПО в организации, заметного упрощения процедур обновления/восстановления ОС и прикладных программ. Для перевода пользователя на новую версию ОС достаточно подать ряд команд на шлюзе («подключить» другой логический том под прежним именем) и перезагрузить рабочую станцию. Это займет несколько минут по сравнению с многочасовой переустановкой на локальных дисках на каждой станции. Кроме того, технология iSCSI удобна для модульных серверов (blade), в которые невозможно установить много дисков, но для них достаточно часто требуется загрузка другой копии ОС (например, в приложениях ASP).

Цели (targets) никогда не используют iSCSI непосредственно, поэтому можно сказать, что iSCSI применяет несимметричную схему работы (инициатор iSCSI/шлюз между iSCSI и Fibre Channel/цель Fibre Channel), а FCIP — симметричную (инициатор Fibre Channel/шлюз FCIP/шлюз FCIP/цель Fibre Channel). Различия в том, что iSCSI наиболее подходит для локальных сетей и ограниченного числа хостов (иначе управление системой превратится в кошмар, из-за отсутствия ряда важных инструментов в области гарантированной производительности и безопасности). Каждая из двух технологий успешно решает свои специализированные задачи, но нельзя утверждать, что они универсальны, конкурируют друг с другом и рано или поздно заменят Fibre Channel. Ключ к успеху — это грамотный дизайн решения.

Резюмируя рассказ о построении распределенных сетей SAN, отметим, что подобная задача всегда предполагает нетривиальное сравнение возможностей сетей Fibre Channel и IP и поиск разумного компромисса. Отдельный интерес представляет анализ пути развития решений, опирающихся на стандарты де-юре (разработанные ANSI) и де-факто (созданные в рамках IETF). По нашему мнению, вопрос «какой из подходов лучше» абсолютно некорректен, поскольку практика подтвердила жизнеспособность обоих вариантов развития. Однако из анализа недавней истории и текущего состояния можно сделать выводы о том, какая из технологий получит наибольшее распространение в обозримом будущем, и тем самым повысить степень защиты инвестиций.

ВМЕСТО ЭПИЛОГА

Нам хотелось показать место решений SAN на рынке, а не просто рассказать о еще одной «модной новинке». Достаточно много специалистов по ИТ и руководителей бизнеса слышали об этом, но пока мало кто из них имеет систематизированное представление о сетях и системах хранения, поэтому мы сознательно сделали акцент на анализе реальных задач и их воздействии на основной бизнес заказчика. Мы не собирались предлагать набор готовых ответов, поскольку всегда необходимо учитывать специфику компании, но вместо этого постарались описать основные технологические идеи и возможности реально существующих инструментов.