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

Основная идея сети хранения (Storage Area Network, SAN) заключается в возможности отделения аппаратных средств хранения данных (т. е. дисководов и лентопротяжных устройств) от сервера и, главное, от сетевой операционной системы. Например, нередки случаи, когда сеть предприятия содержит в целом достаточное количество дискового пространства, но все свободные блоки оказываются в разделах, не доступных для использования. С помощью сети хранения эту проблему можно разрешить, объединив все пространство хранения независимо от конфигурации серверов и разделов и их состояния.

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

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

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

КОНФИГУРАЦИЯ WINCHESTER FLASHDISK

Один из подходов к организации хранения данных состоит в объединении нескольких дисков и адаптеров SCSI в одно устройство. Компания Winchester Systems выпустила дисковый массив Flashdisk, к которому с помощью ряда интерфейсов SCSI можно подключать одновременно разное количество серверов. Поскольку интерфейс с сервером относится к типу SCSI, поддерживается широкий спектр сетевых операционных систем различных версий, и для этого не требуются какие-либо специфические драйверы RAID. Я использовал конфигурацию в стойке Flashdisk OpenRAID Rackmount, включающую 12 дисков емкостью 36,4 Гбайт и два источника питания. Управление разделами RAID этого массива осуществляется независимо от интерфейсов SCSI, что обеспечивает весьма высокую гибкость конфигурации. Типичная схема развертывания оборудования показана на Рисунке 1.

В связи с тем, что с остальной частью среды устройство связано через интерфейс SCSI, достаточно, чтобы сетевая ОС поддерживала лишь одну из допустимых интерфейсных плат SCSI (например, Adaptec 2940U2W или 29160). Сначала это решение было установлено в среде, где активно работали системы Windows NT 4.0, NetWare 4.2 и всевозможные разновидности UNIX. Практически в каждом случае серверы, подсоединяемые к одному устройству Flashdisk, соответствовали разным типам ОС. На Flashdisk были размещены загрузочный раздел и разделы данных каждого сервера, благодаря чему восстановление после сбоев осуществлялось путем замены самого сервера, когда проблемы не были связаны с дисковой подсистемой. Все данные, касающиеся установки и настройки сервера, располагались на дисках массива. Кроме того, при высоких требованиях к уровню доступности резервную копию или кластерную дополняющую основного сервера можно было без особого труда подключить ко второму, отдельному устройству Flashdisk.

Серверы разрешается подключать и отключать от Flashdisk во время его работы — достаточно соблюдать аккуратность, чтобы не повредить контакты кабелей SCSI. В сущности, это устройство играет роль централизованно управляемого «виртуального» диска по отношению к каждому серверу и его сетевой ОС. Во время загрузки система BIOS адаптера SCSI опознает диск типа Flashdisk как подключенное устройство, и массив моделирует соответствующую геометрию такого псевдодиска. Сервер, сетевая ОС и плата SCSI определяют его как работающий дисковод, а не массив. Задачи резервирования и сопровождения существенно упрощаются, поскольку изучению подлежит только один интерфейс RAID, функционирует только один тип диска и шасси, и серверы не попадают в жесткую зависимость от разнообразных типов дисководов и контроллеров. В случае нестандартных дисков или массивов, когда возможности расширения памяти и ресурсов процессора какого-либо сервера уже исчерпаны, нередко приходится отказываться от каких-то дисков или компонентов массива вообще или от их повторного использования. Поскольку в случае объединения дисков пространство хранения отделяется от самого сервера, повторное использование дисков массива значительно облегчается, и общий срок его службы увеличивается.

ОПЫТ РАЗВЕРТЫВАНИЯ WINCHESTER FLASHDISK

Массив дисков, монтируемый в стойку, был размещен в корпусе высотой 5U, в котором расположены 8 стандартных слотов или 12 слотов половинной высоты, два источника питания, аппаратный кэш (объем может варьироваться) и набор контроллеров с той или иной степенью избыточности. В варианте с конфигурацией RAID 1+0 получилось примерно 180 Гбайт пригодного к использованию пространства, причем двум дискам была отведена роль встроенного «горячего» резерва. В конфигурации RAID 5 резерва не предусмотрено, и объем доступного пространства составляет около 400 Гбайт. В приложениях использовались две реляционные СУБД — файловая и клиент-серверная, причем файловая база данных собственной разработки. У технологии RAID 1+0 много достоинств и лишь один недостаток: используемое пространство составляет 50% от общей емкости дисков. Быстродействие на длительных операциях чтения превосходит показатели RAID 5, общая отказоустойчивость высока благодаря полной избыточности структуры с зеркалами и чередованием дисков. Кроме того, чтобы заменить вышедший из строя диск, в RAID 1+0 требуется выполнить процедуры ввода/вывода с участием только зеркала этого диска, а в RAID 5 для этого приходится привлекать все остальные диски.

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

В одном случае так и было сделано — новый раздел был добавлен для одного из существующих и функционирующих интерфейсов SCSI. После перезагрузки и быстрого форматирования пространство стало доступным. Поскольку оно понадобилось лишь на время, спустя несколько недель раздел был возвращен в пул неиспользуемого пространства. Если бы пришлось приобретать новый блок дисков и плату RAID, а затем развертывать и настраивать их, это потребовало бы значительных затрат рабочего времени. К тому же на одной из платформ остались бы излишки дискового пространства, которым вряд ли нашлось бы применение. Представленное решение по сути эквивалентно сети хранения, правда, с ограниченными возможностями расширения и настройки. Оно выгодно отличается от «высокотехнологичных» сетей хранения отсутствием экзотических средств коммутации SCSI и Fibre Channel, а также дорогостоящей лицензии на программное обеспечение. Все используемые технологии должны быть хорошо знакомы администраторам и инженерам, поскольку межсоединения выполнены на базе SCSI, а контроллер RAID представляет каждый раздел системе BIOS и сетевой ОС как один диск SCSI.

ПРОИЗВОДИТЕЛЬНОСТЬ WINCHESTER FLASHDISK

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

До развертывания массивов Flashdisk серверы содержали, как правило, по три-четыре диска и по одному маленькому кэшу на контроллере RAID (так было сделано из экономии). Предполагалось, что объединенный массив смог бы эффективнее использовать большой кэш и 12 дисков в случае RAID 1+0, чем четыре отдельных массива меньшего размера в случае RAID 5. Баланс ожидаемой нагрузки каждого сервера и приложения была тщательно продумана в соответствии с планом развертывания массивов, чтобы избежать перегрузок. Как было установлено, нагрузки ввода/вывода носили ярко выраженный нерегулярный характер и позволяли обеспечить высокоэффективное совместное использование массива серверами. После предоставления серверам в общий доступ 12 больших дисков, объединенных в массив, производительность резко улучшилась по сравнению с конфигурацией, в которой к каждому серверу в отдельности подключалось несколько дисков. Решающее преимущество Flashdisk выражается в том, что стоимость 12 дисков и одного шасси с мощным контроллером примерно сопоставима со стоимостью 12 дисков и четырех более простых контроллеров и дисковых блоков для отдельных серверов. Во многих случаях цена 1 Гбайт для Flashdisk оказывалась фактически ниже, чем в ранее использовавшихся на серверах дисковых массивах.

Во время тестирования, которое заключалось в копировании каталога объемом 4,5 Гбайт с одного сервера одновременно на пять других, среднестатистическое значение производительности чуть превысило 12 Мбайт/с, т. е. коммутируемый канал Fast Ethernet с пропускной способностью 100 Мбит/с был фактически полностью загружен. Файлы повторно копировались для замещения содержимого кэша размером 256 Мбайт и полного задействования ресурсов самого массива. На более простых процедурах копирования (в другой раздел того же устройства, между двумя серверами с адаптерами гигабитных сетей) зафиксированные показатели составляли 15-16 Мбайт/с.

Самого заметного улучшения удалось добиться в скорости резервного копирования: общее время процедуры сократилось почти вдвое. Один из серверов, со средней пропускной способностью 50 Мбайт/с, после обновления вышел на уровень свыше 200 Мбайт/с. Эти цифры, безусловно, зависят от особенностей конкретной методологии и используемого тестового пакета. Однако они дают представление о том, насколько быстрее начинают работать приложения, и особенно резервное копирование, в результате перехода на выделенную высокопроизводительную платформу хранения.

КОНФИГУРАЦИЯ NETWORK APPLIANCE FILER

Другой подход к консолидации пространства хранения состоит в том, чтобы вообще исключить сервер. Вместо массивов дисков SCSI применяется набор подключаемых к сети устройств хранения (NAS), или «файлеров» (filer), с урезанной программной версией для поддержки протокола, с помощью которого предоставляются файловые сервисы. Многие из этих устройств допускают монтирование у себя раздела или каталога, так что они могут служить в качестве аппаратного хоста с базой данных какой-либо реляционной СУБД. Самое главное, чтобы выбранное оборудование поддерживало все требуемые протоколы файловых служб: CIFS (использующий NETBIOS поверх TCP), NFS и HTTP. Примером такого подхода может служить система Filer компании Network Appliance — она «понимает» все перечисленные протоколы. CIFS предназначается для интеграции в домен Windows NT/2000 и позволяет устройству выступать по отношению к другим клиентам и серверам в качестве сервера. Поддержка NFS, разумеется, рассчитана на системы UNIX, а средства HTTP дают возможность интеграции в крупномасштабные среды хостинга Web и электронной коммерции.

Поскольку Filer встраивается в действующую среду сетевой операционной системы в качестве своего рода двойника, развертывать его не так просто, как систему с объединенными дисковыми хранилищами на базе интерфейса SCSI. Еще одно отличие состоит в том, что Filer включает службу тиражирования SnapMirror для отображения его содержимого на второе аналогичное устройство в режиме реального времени и программу резервного копирования Snapshots для создания нескольких ежедневных копий текущих данных (они предназначены только для чтения, что позволяет ускорить восстановление файлов). Кроме того, ресурсы доступного пространства можно легко наращивать, добавляя новые диски; причем обращение к дискам производится без прерывания работы системы. Сетевая ОС, которую использует Filer, обеспечивает уровень абстрагирования между интерфейсами CIFS, NFS и HTTP, поэтому многие операции, требующие переформатирования какого-либо раздела или перезагрузки сервера, можно выполнять прозрачным образом.

Все эти средства обходятся дороже примерно вдвое или более (в расчете на 1 Гбайт) по сравнению с описанным выше решением с прямым подключением к серверу. Другими важными факторами являются наличие и качество поддержки требуемых протоколов файловых служб сетевой ОС. В случае платформы NetWare такой тип хранилища может оказаться бесполезным: мне не известен ни один производитель, который выпускал бы устройства хранения, подключаемые к сети по протоколу NCP. Кроме того, развертывание крупного хранилища данных на базе Filer фактически требует применения высокоскоростного (гигабитного или ATM) интерфейса, чтобы вся эта мощь ввода/вывода была доступна и другим клиентам и серверам. Пример схемы развертывания показан на Рисунке 2.

ОПЫТ РАЗВЕРТЫВАНИЯ NETWORK APPLIANCE FILER

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

В среде CIFS/Windows устройству назначается учетная запись домена с целью его последующей интеграции в систему безопасности и управления средствами домена. В модели файловой службы CIFS/SMB сервер аутентифицирует пользователей и отслеживает их полномочия, поэтому учетная запись домена необходима для доступа к данным аутентификации и авторизации на уровне домена. В среде NFS Filer поддерживает службу NIS как клиент, что обеспечивает централизованное администрирование файлов, контролирующих разрешения на доступ. В этом случае, в отличие от CIFS, Filer экспортирует каталоги NFS и возлагает на клиента ответственность за аутентификацию пользователей, обращающихся к этим каталогам с клиентского компьютера. Кроме того, если используется несколько протоколов, необходимо учесть особенности каждого из них — как они трактуют даты файловой системы, распознают регистр символов, обрабатывают доступ к файлам и т. п.

В рассматриваемой среде применяется только протокол CIFS, и основная функция Filer заключается в поддержке платформы хранения для приложений, доступ к которым мы предоставляем своим клиентам. Каждый сервер Web размещает на Filer свои корневые каталоги; в результате обеспечивается синхронизация данных и приложений и балансировка нагрузки между всеми серверами Web. Наконец, средство тиражирования данных SnapMirror позволяет создать во втором центре данных резервную копию всего информационного наполнения Web и данных. Эта конфигурация изображена на Рисунке 3.

ПРОИЗВОДИТЕЛЬНОСТЬ NETWORK APPLIANCE FILER

Функции и командной строки, и управления производительностью SNMP работают превосходно. В среде Filer инструмент командной строки systat обеспечивает выдачу на консоль (с интервалом, определяемым пользователем) информации о процессоре, операциях дискового и сетевого ввода/вывода и степени устаревания содержимого кэша. Все это также доступно (причем в более детализированном виде) в специализированных базах данных SNMP MIB, созданных в рамках общей структуры сетевого управления.

Наш Filer обеспечивает хранение данных и информационного наполнения Web для интерактивных банковских приложений в центре данных, обслуживающем наших клиентов. На момент написания этой статьи услугами доступа к главному центру данных пользовались 186 клиентов; их информация располагалась на сервере Filer и в виде зеркальной копии (созданной с помощью SnapMirror) — на втором устройстве Filer в резервном центре данных. Анализ показателей производительности за период с 13:00 до 17:00 обычного рабочего дня показал, что центральный процессор был загружен на 30—50% и выполнял в среднем 2526 операций CIFS в секунду. Средние показатели загруженности дискового канала и сетевого интерфейса составили соответственно 1,13 Мбайт/с и 0,62 Мбайт/с. Таким образом, за одну операцию CIFS в среднем обрабатывалось примерно 256 байт, что как раз соответствовало возможностям нашего приложения. Коэффициент использования процессора следует признать высоким, учитывая сравнительно низкую общую пропускную способность диска, а оценка данных производительности показывает весьма сильную корреляцию между загруженностью процессора и частотой операций CIFS.

Когда период пиковых нагрузок миновал, коэффициент использования процессора уменьшился вместе с числом операций CIFS, а среднее время пребывания в кэше резко возросло — оно почти удвоилось, при том что общая нагрузка на Filer снизилась примерно на 33%. Еще один любопытный факт: в то время как показатели загруженности сети и счетчики дисковых операций чтения/записи практически идеально коррелировали между собой (что неудивительно), пропускная способность сетевого интерфейса оказалась почти вдвое выше пропускной способности дисковой подсистемы ввода/вывода. Я рассчитывал, что инкапсуляция и неэффективность CIFS найдет свое отражение в несовпадении объемов трафика, однако результат (перевес сетевого трафика над дисковым вводом/выводом в соотношении 2:1) превзошел мои ожидания. Причиной этого наверняка был невысокий средний объем данных чтения/записи. Поскольку каждая среда уникальна, приведенные рассуждения о производительности призваны скорее продемонстрировать качество инструментария Filer, чем дать сколько-нибудь полезную информацию о рабочих характеристиках для потенциального пользователя. И у компании Network Appliance, и у Winchester Systems имеются прекрасные узлы Web, где можно найти обширную информацию о производительности их продуктов, куда я и отсылаю всех интересующихся: читайте и делайте выводы сами.

ЗАКЛЮЧЕНИЕ

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

Адам Андерсон — специалист по ИТ. С ним можно связаться по адресу: adam_d_Anderson@hotmail.com.