Консолидация средств хранения

Внедрение новых технологий обещает снизить потребности в средствах хранения, но в действительности необходимость в них только нарастает.

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

К большому огорчению руководителей подразделений, но к радости поставщиков технологий, системы хранения продолжают развиваться, а их сложность возрастает. До недавнего времени компании ограничивались лишь комбинацией непосредственно подключаемых систем хранения (Direct-Attached Storage, DAS) и сетевых файловых служб (Network File Services, NFS или CIFS). Иногда для поддержки кластеров высокой готовности реализовывалась система хранения с двойным подключением. Всякий раз, когда приходилось увеличивать число соединений, как правило, устанавливался специализированный блок центрального хранения (например, EMC Symmetrix). Рабочие дисководы располагались на самых разных устройствах, в силу чего каждому из них требовалось отдельное управление и планирование емкости. В результате они использовались неэффективно, поскольку каждому из наборов средств хранения была необходима некоторая избыточная емкость.

ОЦЕНКА СРЕДСТВ ХРАНЕНИЯ

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

Такие инструментальные средства, как Sun HighGround, предназначены для всех ориентированных на хранение систем. Они позволяют установить объем занятой и свободной памяти в подразделении, а также выяснить размеры «старой» и «новой» информации, чтобы определить, где можно применять иерархическое управление памятью (HSM).

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

АНАЛИЗ ТРЕБОВАНИЙ

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

• Решение SAN для систем, которым требуется "выделенная" память. Для каждого удаленного офиса понадобится отдельная SAN. Кроме того, в некоторых помещениях реализуются разные SAN для производства и для разработки.
• NAS по-прежнему представляет собой неплохой выход из ситуации, когда многим машинам необходим доступ к одним и тем же логическим модулям или точкам монтирования (Logical Unit Number, LUN). Например, несколько серверов Web могут монтировать свое информационное наполнение HTML из одной точки монтирования NAS, поэтому изменения нужно произвести только в одном месте.
• DAS - полезное решение для небольших офисов, где определяющими факторами являются невысокая стоимость и низкая емкость. Однако при выборе следует проявлять осторожность, иначе подразделению, в конце концов, опять потребуется консолидация!

Требования для каждого сервера в подразделении следует проанализировать отдельно.

• Нужное число LUN на конкретный сервер.
• Емкость, необходимая каждому LUN.
• Уровень RAID каждого LUN (RAID 1, 0+1, 1+0 или 5). Помните, что выбор зависит от требований к производительности и восстановлению после сбоев. Безусловно, большинство офисов работает с разными уровнями RAID.
• Степень кэширования, особенно если LUN должен обеспечивать высокую производительность и поддерживать произвольные операции записи. Возможно, если LUN небольшой, то в целях увеличения производительности имеет смысл полностью поместить его в память (либо в кэш, либо на виртуальный диск).
• Необходимость в дальнейшей защите данных за счет создания "мгновенных снимков", либо с помощью полного зеркалирования, либо путем копирования блоков при записи. "Мгновенные снимки" могут использоваться для резервного копирования, либо для сохранения последних данных о работе LUN в целях быстрого восстановления или тестирования.
• Потребность в одном или избыточных путях от хоста к LUN. Как правило, производственным LUN нужны избыточные пути доступа (для SAN или для DAS) либо поддержка сетевых соединений высокой готовности (для NAS).
• Принципиальная значимость динамического формирования обходных путей, при которой дополнительные пути задействуются до тех пор, пока на одном из них не возникнет сбой, а затем все данные бесконфликтно переводятся на оставшиеся. Отметим, что одни решения с поддержкой избыточных путей будут динамически повторно использовать первый путь, когда он снова станет доступен, в то время как другим, чтобы полностью восстановить все избыточные пути, необходима перезагрузка.
• Величина пропускной способности между хостом и LUN как в момент пиковой нагрузки, так и в среднем. Если нагрузка "пиковая", когда она будет возникать для каждого LUN?
• Обязательность тиражирования (для зеркалирования данных за пределами офиса) с целью восстановления после сбоя. Тиражирование имеет свои сложности. Прежде всего, сколько данных необходимо тиражировать в секунду при пиковой нагрузке и в общем случае?
• Требования к резервному копированию могут стать предметом отдельного анализа. Здесь интересны такие параметры: допустимое время простоя; тип данных, подлежащих резервному копированию; ограничения на время восстановления; объем данных, резервные копии которых следует создать в отведенное для этого время; пропускная способность каналов связи, необходимых для выполнения указанной операции. SAN может использоваться для выполнения резервного копирования без привлечения ресурсов локальной сети. Это можно воспринимать и как проект консолидации ленточных накопителей.
• Следует ли реализовать HSM для LUN или для сервера? HSM может решить проблемы, но, опять-таки, добавляет собственные сложности. Если однажды записанные данные хранятся долго и редко читаются, то, возможно, выбор HSM будет оправданным.
• Насколько серьезно нужно подходить к защите информационного наполнения? Поскольку NAS предусматривает доступ по сети, а SAN может иметь управление на базе сети, при планировании консолидации средств хранения необходимо рассмотреть вопрос безопасности хранения данных.
• Что касается использования NAS, следует продумать, какие протоколы NAS и средства контроля доступа к файлам необходимы. Например, если доступ к то/му будет выполняться через NFS и CIFS, нужны ли списки контроля доступа для работы по двум протоколам с одним и тем же файлом?

Результаты этого анализа станут основой для проектирования архитектуры системы хранения.

ПРОЕКТИРОВАНИЕ

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

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

На Рисунке 1 представлен пример архитектуры консолидированной системы хранения. В производственном офисе установлены избыточные коммутаторы для серверов, у которых ранее имелись средства хранения DAS для подключения к пулу дисковых массивов. Этот пул состоит из двух массивов хранения (совсем не обязательно одного и того же производителя). При наличии у серверов избыточных соединений с коммутаторами сети, а у коммутаторов — с массивами хранения, вся SAN является отказоустойчивой. Головной компонент NAS обеспечивает сетевой доступ к файлам, хранящимся на любом LUN, смонтированном на устройстве NAS. К примеру, всем клиентам можно обеспечить доступ к файлам пользователя через сеть.

Кроме того, к коммутатору SAN присоединена библиотека магнитных лент (см. Рисунок 1). Программное обеспечение резервного копирования и HSM могут передавать файлы между системой хранения, серверами и накопителями для магнитных лент, не задействуя какую-либо сеть. Разделение конкретного накопителя между серверами достигается с помощью специального программного обеспечения, например Veritas NetBackup. Вместо того чтобы поддерживать соединение каждого сервера с конкретным накопителем для магнитных лент через SAN, ленты объединены в пул, а программное обеспечение динамически выделяет накопитель серверу, выполняет резервное копирование и освобождает его для выполнения резервирования данных другими серверами. Такого рода консолидация магнитных лент очень полезна для восстановления, поскольку все накопители могут быть динамически подключены к одному серверу, в результате диски будут восстанавливаться с максимальной пропускной способностью.

В этом примере у резервного офиса для восстановления после катастрофы нет избыточных серверов или коммутаторов. Впрочем, диски могут быть защищены с помощью RAID. Тиражирование между двумя офисами будет выполняться из массива в массив (посредством внутренних протоколов по таким каналам хранения, как ESCON или Fibre Channel) или с помощью программного обеспечения хоста. Размещаемое на хосте программное обеспечение тиражирования может функционировать на уровне блоков или приложения. К примеру, SNDR компании Sun копирует любые измененные блоки по глобальной сети на зеркальный диск. При подобном подходе диски в удаленном офисе выглядят так же, как и исходные, но с задержкой по времени, величина которой зависит от пропускной способности канала глобальной сети и задержки на преодоление битами существующего расстояния. Тиражирование на уровне приложения (к примеру, Oracle Advanced Data Replication) фиксирует транзакции внутри приложения и дублирует их аналогичному продукту, работающему в удаленном офисе. Все названные виды тиражирования имеют свои достоинства и недостатки, в зависимости от потребностей компании.

ВЫБОР ПРОДУКТОВ

Рассмотренная архитектура предусматривает использование SAN вместе с интерфейсами NAS. Они позволяют подключать к системе хранения через коммутаторы SAN те серверы, которым нужна максимальная пропускная способность и выделенные средства хранения. Хосты, нуждающиеся в разделении файловых систем или не имеющие возможности подключения к SAN, могут воспользоваться функциями SAN при посредничестве головных компонентов NAS. Вся система хранения, таким образом, консолидируется в набор массивов RAID, каждый из которых может быть выделен как подключенному к SAN серверу, так и работающему с NAS. В дальнейшем коммутирующая инфраструктура SAN может быть задействована для резервного копирования, чтобы хосты копировали свои данные из выделенных им систем хранения на библиотеки магнитных лент, не обращаясь к сети TCP/IP для передачи данных. Наконец, тиражирование данных из производственного офиса в резервный выполняется посредством тиражирования на базе массива хранения или хоста.

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

ВЫБОР МАССИВА

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

Анализ производительности возможных вариантов создает новые трудности. В отрасли отсутствуют стандартные тесты на производительность для систем хранения. Некоторые компании довольствуются информацией, предоставляемой производителями, но, как правило, она противоречит утверждениям их конкурентов. Однако кое-что можно понять, изучив детали архитектуры массива хранения. В Таблице 1 показаны некоторые технические критерии выбора массивов в порядке приоритета.

Выбрать размер диска и уровень RAID достаточно сложно, но чем многочисленнее варианты, предоставляемые массивом, тем в большей степени вы можете адаптировать массив к своим требованиям. Например, для максимального увеличения производительности баз данных наиболее подойдут диски емкостью 36 Гбайт с RAID 1+0 или 0+1. Что касается складов данных, возможно, самыми удобными окажутся диски емкостью 144 Гбайт с RAID 5. Лучше всего, если массив позволяет выбирать размер дисков и уровней RAID и допускает использование элементов с различными характеристиками в одном массиве. Заметим, что диски отличаются не только по размеру. Время поиска, задержки, скорость передачи, интерфейс (например, передача осуществляется по обоим волокнам или только одному из двух), затраты и даже средняя наработка на отказ (MTBF) могут меняться наравне с размером дисков в рамках одного массива. Все эти аспекты при сопоставлении массивов необходимо проанализировать для каждого варианта.

Сравнение на основе документации полезно, но оно отвечает только на те вопросы, на которые отвечает. Насколько управляем такой массив? Хорошо ли работает программное обеспечение? В какой степени реальная производительность соответствует той, что указана в документации? Это можно будет узнать, увы, только на практике. Если выбор ограничен двумя-тремя конкурирующими технологиями, а у вас есть время, силы и средства, то их лучше сопоставить непосредственно. «Конкурс» поможет эффективно оценить не только производительность, но и управляемость, и позволит понять, насколько рассматриваемое решение вам подходит в целом.

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

Что касается финансовой стороны, то затраты на массив (и другие технологии) не ограничиваются стоимостью его приобретения. Какова цена поддержки? Во сколько обойдется программное обеспечение, которое вы, вероятно, захотите установить в дальнейшем? А дополнительный кэш? Не забудьте также и о масштабируемости. Если массив может поддерживать «только» диски емкостью 72 Гбайт, долго ли он будет полезен для вашей среды? Конечно, нельзя обойти вниманием и ущерб от простоя. Сбой каких компонентов может привести к отказу всей сети? Какую среднюю надежность устройства обещает производитель? Плановые простои предполагают затраты времени и сил системного администратора, а возможно, и потерянные для компании деньги из-за прерывания работы или сокращения ее эффективности. Когда будут происходить плановые простои (например, для создания LUN, изменения конфигурации, модернизации микропрограммного обеспечения)? Насколько часто они необходимы и как влияют на деятельность компании?

ВЫБОР NAS

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

Сейчас большинство решений NAS содержит вычислительный компонент и дисковый компонент. Эти комплексные устройства отличаются превосходной функциональностью и просты в управлении, но противоречат идее консолидации системы хранения. Установка в подразделении отдельных серверов NAS означает появление еще одного набора дисководов, на проектирование, конфигурирование, управление, планирование емкости и обслуживание которого потребуется время. И что делать в том случае, когда будет достигнута предельная емкость для дисков такой системы NAS, как «все в одном»? Со временем придется добавлять еще одно устройство NAS, в результате фрагментация системы хранения увеличится еще больше. В последнее время все чаще используют головные компоненты NAS с подключением к SAN вместо установки внутренних дисководов. Эти устройства с одной стороны подключаются к сети, а с другой — к сети SAN.

Далее приводятся некоторые вопросы, на которые следует получить ответы при выборе решения NAS.

• Насколько высокий уровень готовности поддерживается (в том числе при обращении к диску и на уровне кэшa)?
• Какова производительность? Хорошей исходной точкой могут служить тесты на производительность SPECSFS, расположенные по адресу: http://www.spec.org.
• Сколько сетевых интерфейсов имеется и какого они типа?
• Количество волоконных интерфейсов?
• Какие сетевые файловые системы поддерживаются (как минимум SMB и NFS)?
• Какие службы имен поддерживаются (LDAP, NIS, NIS+, DNS, Active Directory и т. д.)?

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

Коммутаторы — это главный компонент SAN. Хотя некоторые из их возможностей можно оценить, остальные не имеют четко выраженных количественных характеристик.

Совершенно очевидно, что необходимо обратить внимание на то, сколько портов имеется в рассматриваемой модели. Для компонентов инфраструктуры SAN интерфейсы на 2 Гбит/с становятся нормой, поэтому коммутатор должен иметь порты на 2 Гбит/с, автоматически распознавать подключение на 1 и 2 Гбит/с и быть легко модернизируемым. Важный фактор — возможность поддержки (а также поддержка со стороны производителей других продуктов, которые вы оцениваете), но подробнее об этом в одном из следующих разделов.

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

ВЫБОР ЛЕНТОЧНОГО НАКОПИТЕЛЯ И БИБЛИОТЕКИ МАГНИТНЫХ ЛЕНТ

Библиотеки магнитных лент могут использоваться для резервного копирования, обмена данными и иерархического хранения (HSM). Ленточные накопители и библиотеки магнитных лент выпускаются в самых разных вариантах. Некоторые производители создают бланки спецификаций, где заказчик указывает параметры резервного копирования, и на основании которых формируются предложения по накопителям и библиотекам.

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

Что касается разделяемых библиотек, то важно помнить, что каждая имеет только один порт управления механизмом подачи и только одной программе разрешается управлять им. Если вы хотите разделять библиотеку между двумя программами (скажем, для резервного копирования и HSM), в роли посредника в обязательном порядке должно выступать программное обеспечение. Убедитесь, что это обстоятельство учтено в плане проектирования SAN.

Выбор накопителей предполагает оценку скорости воспроизведения и подачи, емкости ленты, возможностей и эффективности сжатия, а также размеров накопителя и лент (какое количество можно установить в библиотеку). Сейчас чаще всего используются LTO, SDTL и ADIC. Ряд накопителей имеет специальные функции, которые могут повлиять на выбор (например, накопители 9840 имеют режим WORM). Большинство библиотек позволяет установить несколько типов накопителей и картриджей, поэтому смешанный подход вполне реален.

Еще один важный аспект — интерфейс накопителя. Некоторые библиотеки включают в себя мосты, поэтому вовне для связи с хостами может применяться волокно (или коммутатором SAN), а внутри для связи с накопителями — SCSI. Использование мостов — вполне практичное решение, но выбор оптических кабелей и для внутренних, и для внешних соединений сокращает вероятные ошибки. О том, как накопители подключаются к хостам, можно узнать из рекомендации производителей. Например, в случае соединений SCSI каждому хосту может быть выделено по три накопителя, а для соединений по волокну — только один.

С появлением SAN возникли новые решения задачи резервного копирования/иерархического управления. Точно так же, как коммутаторы SAN позволяют хостам подключаться к массивам, те же самые (или выделенные) коммутаторы могут обеспечить подключение хостов к ленточным накопителям внутри библиотек. Данные резервного копирования/ иерархического управления можно переносить из хранилищ SAN через хост в библиотеку, при этом корпоративная сеть никогда не будет задействоваться. Наличие выделенных серверов резервного копирования теперь не обязательно. Такое программное обеспечение, как Veritas NetBackup, способно управлять не только операциями резервного копирования, но и выделением накопителей для магнитных лент. Например, два хоста могут подключаться к библиотеке через коммутатор SAN, а программное обеспечение резервного копирования зарезервирует определенное количество накопителей для одного сервера, выполнит резервное копирование, освободит накопители и выделит их другому серверу. Либо оба сервера выполнят резервное копирование одновременно на половину накопителей каждый. При восстановлении все дисководы могут быть предоставлены одному хосту, чтобы минимизировать время этой процедуры.

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

ТИРАЖИРОВАНИЕ

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

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

• Требуемая дальность передачи данных. Некоторые решения работают на ограниченном расстоянии или нуждаются в дорогостоящих и сложных изменениях для преодоления подобных ограничений.
• Объем передаваемых данных в периоды пиковой нагрузки. Пропускная способность оказывает огромное влияние на архитектуру тиражирования.
• Способ тиражирования - по выделенным соединениям (с системой хранения либо глобальной сетью) или с использованием Internet.
• Способ выполнения тиражирования - синхронный или асинхронный. Синхронное тиражирование гарантирует, что данные поступят в удаленный офис до того, как приложение получит подтверждение выполнения транзакции. Асинхронное можно выполнять на больших расстояниях, но часть данных, в зависимости от исполняемого приложения, может быть утеряна.
• Возможность реализации "порядка записи". Когда порядок записи поддерживается, при использовании асинхронного режима данные могут быть по-прежнему утрачены в случае сбоя в основном офисе, но останутся согласованными. Например, база данных может получать свои транзакции по порядку, но возможна потеря некоторых транзакций. Это лучше, чем неупорядоченная запись, при которой состояние тиражированных данных оказывается неудовлетворительным.

ЗАВЕРШЕНИЕ ПРОЕКТИРОВАНИЯ

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

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

Первое решение касается выбора местонахождения данных и приложений. Самое время выяснить, на какие компромиссы предстоит пойти вашему подразделению в дальнейшем. Грех не воспользоваться этой возможностью, чтобы не придать своей среде элегантность и стиль в целях упрощения управления и улучшения функциональности. В качестве практического примера рассмотрим перенос всех приложений с внутренних, непосредственно подключенных дисков на подключенные к SAN и NAS. После того как это сделано, даже самые крупные из имеющихся у вас серверов можно будет рассматривать как обычные сменные блоки (Field Replaceable Unit). Например, пусть некий сервер баз данных исчерпал свои возможности. Если приложения и данные были размещены в SAN, то перенос данных на более мощную машину больше не будет казаться трудноразрешимой задачей. Вместо этого, вы могли бы просто размонтировать файловую систему с текущей машины, смонтировать ее на новой, изменить файлы начальной загрузки, функции планирования выполнения заданий и системные переменные, после чего модернизация будет завершена. При возникновении каких-либо проблем, все можно вернуть назад, и у вас будет работоспособная система. Конечно же, это не так просто, но, безусловно, лучше, чем возможные альтернативы.

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

ВОПРОСЫ, КАСАЮЩИЕСЯ ХОСТОВ

Второе решение необходимо принять в отношении подключения хостов к SAN и NAS. Что касается NAS, то практический вопрос заключается в том, использовать сетевое соединение с пропускной способностью 100 Мбит/с или 1 Гбит/с? Выбор определяется требованиями производительности и имеющейся сетевой средой. Иногда наилучшее решение — смешанный подход, где одни хосты поддерживают 100 Мбит/с, а другие — 1 Гбит/с, при этом NAS имеет несколько соединений на 1 Гбит/с. При работе с серверами, где установлены Solaris 8 или 9, поддержка избыточных путей IP теперь позволяет одновременно и согласованно задействовать несколько сетевых каналов между сервером и машиной NAS.

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

Определить, что предпочтительнее, — намного сложнее. Для серверов Sun выпускаются HBA на 1 и 2 Гбит/с, и выбор, как и в примере с NAS, заключается в том, сможет ли коммутатор работать на обеих скоростях и автоматически определять нужную. Функционирование нескольких HBA внутри сервера также требует тщательного анализа. В лучшем случае поддерживается несколько экземпляров HBA, и между ними выполняется балансировка трафика (иногда называемая «множественность путей»). Трафик переводится на другие HBA, если один выходит из строя, и передается через оставшиеся до тех пор, пока неисправный не будет «отремонтирован». На самом деле, иногда трудно добиться полномасштабной реализации заявленных возможностей. Например, HBA (и его драйверы) в состоянии поддерживать множественность путей, но при этом, вполне вероятно, что после устранения неполадки систему придется перезагрузить для восстановления всех каналов.

Программное обеспечение для балансировки нагрузки может предоставляться вместе с управлением томами (как в случае Veritas Volume Manager) либо предлагаться производителем массива хранения (как правило, за дополнительную плату). Одни утверждают, что первый вариант лучше, поскольку на хосте не нужно устанавливать, поддерживать или отлаживать никакого программного обеспечения от производителей массивов. Другие считают, что если производитель поддерживает множественность путей — от программного обеспечения до массива, то стоит на это раскошелиться. Еще одна альтернатива множественности путей — Solaris 8 MPXIO (в версии 07/01 или более поздней), называемый Sun StorEdge Traffic Manager в Solaris 9. Это решение базируется на ядре и способствует тому, чтобы каждое устройство было представлено в дереве устройств только один раз, даже если оно доступно системе по нескольким путям.

Многоуровневые продукты также могут усложнить поддержку. Например, поддерживается ли Sun Cluster с Oracle 9i RAC с помощью Traffic Manager? Как насчет того, чтобы использовать менеджер Veritas Volume вместе с Traffic Manager, а не DMP? Для каждого хоста поддержка должна рассматриваться во всех аспектах, от стека программного обеспечения до аппаратных устройств.

АНАЛИЗ ПЕРЕХОДА

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

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

Вероятно, лучший способ перенести данные между устройствами хранения — сделать это с помощью программного зеркалирования. Например, если существующая система использует Veritas Volume Manager, а хост в состоянии одновременно поддерживать соединение с новой системой хранения, тогда менеджер томов можно сконфигурировать так, чтобы он рассматривал ее как зеркало старой. Такая «чистая» копия по-прежнему требует тестирования, но этот метод значительно проще, чем альтернативные варианты.

Еще одна потенциальная проблема, связанная с переходом, — модернизация операционной системы. Она может понадобиться в целях поддержки HBA, драйверов устройств, множественности путей и других компонентов системы хранения.

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

СЛОЖНОСТИ ПРИ РЕАЛИЗАЦИИ КОММУТАЦИИ SAN

План реализации коммутации SAN должен четко описывать, что к какому порту подключается. Вопросы могут быть и менее очевидными. Большинство массивов хранения позволяет взаимодействовать с каждым портом массива операционной системе лишь одного типа. Коммутатор должен учитывать это, помещая в зону коммутации только хосты конкретного типа для конкретного порта массива (можно рассматривать это как виртуальную локальную сеть). Таким образом, машины с Windows NT будут находиться в одной зоне, машины с Solaris — в другой, а системы HP-UX — в третьей. Четвертая зона может быть создана для взаимодействия хоста с библиотекой магнитных лент (в случае резервного копирования без использования локальной сети).

Некоторые офисы для простоты предпочитают отдельные коммутаторы и HBA для резервного копирования по SAN. Кроме того, обычные решения резервного копирования не поддерживают автоматическое переключение при сбое, когда хост и массив магнитных лент связывает несколько путей. В силу вышесказанного, необходимо уделять пристальное внимание тому, какой путь используется для связи с ленточными накопителями. Пути не будут автоматически переводиться с одной ленты на другую. Однако при корректном планировании сбой на одном коммутаторе может прервать доступ только к половине накопителей для магнитных лент. Конфигурацию можно легко изменить вручную, чтобы возобновить доступ к другим накопителям. Конечно, избыточные коммутаторы нужно сконфигурировать при использовании SAN для хранения. Они должны быть подключены друг к другу, поскольку такая «структура» повышает управляемость SAN (каждое устройство может «видеть» все остальные). Однако это может снизить уровень готовности, если проблема на одном коммутаторе транслируется по каналу на другой.

Маскирование LUN (это можно рассматривать как фильтрацию IP, но в Fibre Channel вместо IP-адресов используются уникальные имена WWN) — метод, гарантирующий, что хост видит только те LUN, которые должны быть смонтированы на нем. И опять-таки, задача имеет множество решений. Многие драйверы HBA можно сконфигурировать так, чтобы они показывали операционной системе хоста только предназначенные ей LUN, для чего требуются специальное конфигурирование каждого HBA и передача ответственности хосту. Решение с возможностью централизованного контроля — реализация маскирования LUN в массиве хранения. Недостаток такого подхода заключается в том, что при замене HBA на массиве хранения придется изменить конфигурацию.

Защиту LUN можно усилить путем создания зон коммутации. В зависимости от выбора производителя коммутатора зоны могут быть аппаратные (куда входят физические порты коммутатора) или программные (на основе имен WWN). При их реализации, скомпрометированный хост не сможет получить доступ к средствам хранения других хостов. Использование зон коммутатора позволяет также не допустить попытки системы Windows захватить все LUN на каждом массиве хранения. Если система будет находиться в зоне только со своими LUN, то она не сможет увидеть (или захватить) LUN, для нее не предназначенные.

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

Например, для каждого хоста необходимо указать:

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

Для каждого HBA следует знать: каждый из назначенных LUN и детальное его описание (размер, уровень RAID и т. д.).

СЛОЖНОСТИ РЕАЛИЗАЦИИ МАССИВОВ ДИСКОВ И МАГНИТНЫХ ЛЕНТ

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

ТРУДНОСТИ УПРАВЛЕНИЯ И МОНИТОРИНГА

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

ЗАКЛЮЧЕНИЕ

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