Подсистемы хранения данных

         

Современные системы хранения данных Часть 3.


Игорь Сюртуков

Тестовая лаборатория Ferra

Часть 2Часть 1

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

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

Корпорация ЕМС предлагает две линейки систем хранения данных SAN – системы высшего уровня Symmetrix и системы среднего уровня CLARiiON. Модель DMX-3 линейки EMC Symmetrix на данный момент является самой мощной и масштабируемой системой хранения данных в мире – сконфигурированная система поддерживает более 1920 жёстких дисков, а сертифицированная ёмкость достигает 1 PB (1 петабайт = 1024 терабайт) данных.

Структурная схема EMC Symmetrix DMX-3

Также EMC поставляет NAS-системы – EMC Celerra, а также система, предназначенная для хранения неизменяемых данных (CAS) EMC Centera. В настоящее время выпускается уже седьмое поколение midrange-систем EMC CLARiiON, представленных моделями CX300/CX300i, CX500/CX500i и CX700, а также модель начального уровня с SATA-дисками – EMC Clariion AX100/AX100i. Кроме аппаратных решений, у компании ЕМС существует множество программных продуктов для управления как самими системами хранения, так и сетями хранения данных, а также ПО для защиты данных, перемещения данных между различными системами и прочее. Компания ЕМС является седьмой в мире компанией по выпуску программного обеспечения. Также системы хранения данных EMC поставляют под своей торговой маркой несколько известных сторонних компаний – Dell, Fujitsu-Siemens, Bull.

Президент EMC Joseph M. Tucci (слева) представляет EMC Symmetrix DMX-3




Итак, старшие модели систем хранения от IBM являются разработкой самой компании IBM – это линейки Total Storage серий DS6000 и DS8000. Уровень entry-level и midrange – это OEM-продукция компаний Adaptec и Engenio, сюда входят IBM Total Storage DS300/DS400, DS4100, DS4300, DS4500 и DS4800.



IBM Total Storage серии DS8000

Ну и кратко упомянем некоторые другие значимые компании.

Как мы уже говорили, DELL поставляет в качестве своих систем хранения решения EMC, а также простые решения без интеллектуальной начинки, как упомянутая в первой части статьи дисковая полка DELL PowerVault 220s. Известная узкому кругу Network Appliance разделяет свои продукты на четыре неравнофункциональные линейки – это системы NetApp FAS (серии FAS900, FAS3000 и FAS200), а также ещё три группы аппаратных решений – V-Series, NearStore и NetCache. Отпрыск LSI, компания Engenio выпускает свои продукты под бесхитростными цифровыми обозначениями – это модели Engenio Storage System 2822, 2882, 5884, 6498 и 6998. К примеру, модель Engenio 6998 поставляется по OEM-контракту компанией IBM как IBM DS4800. Компания DotHill предлагает системы хранения старшего уровня DotHill SANnet II (с дисками SATA или FibreChannel), а также системы среднего и нижнего уровня DotHill RIVA и DotHill StratisRAID (это системы компании Chaparral, не так давно купленной компанией DotHill). Системы всем известной своими контроллерами Adaptec представлены старшими системами с интерфейсом FibreChannel – Adaptec FS4500/FS4100 и Adaptec SANbloc, а также SCSI DAS-системами (например Adaptec SC4100), iSCSI-хранилищами (Adaptec iSA1500 Storage Array) и NAS-системами Adaptec Snap Server. Компания Raidtec, в данный момент приобретённая компанией Plasmon, поставляет несколько линеек продукции – Raidtec FS/CS 3102 с интерфейсами FC и SCSI, соответственно, Raidtec FibreArray (FC-FC), а также NAS-системы Raidtec SNAZ. Дисковые системы хранения от Overland на рынке представлены линейками Overland REO 1000, 4000 и 9000 (отличающиеся возможностью эмуляции ленточных накопителей) и серией более производительных и надёжных массивов Overland ULTAMUS.


Упомяну ещё распространённые у нас системы начального уровня от AXUS – серии Yotta и Yotta Mini, которые заменили собой AXUS DemonRAID, уже снятые с производства.

Конечно, этот маленький обзор является далеко не полным – как по производителям, так и по перечисленным продуктам и по взаимоотношениям различных вендоров – в основном это касается OEM-партнёрства. Мы перечислили лишь самые популярные решения и самые известные компании.

Естественно, аппаратная мощь систем хранения должна как-то управляться, а сами СХД просто обязаны предоставлять уровень сервиса и функциональность, недоступную в обычных схемах «сервер-клиент». Самое первое, что мы уже рассмотрели, – это возможность подключать к СХД несколько хостов (вплоть до сотен, в теории). Второе – система хранения, обычно она обеспечивает 100%-ное дублирование всех своих компонент – нет элементов, выход из строя которых способен вызвать аварийную остановку системы хранения. Также дублированы каналы доступа (пути доступа) к стойке от сервера – в сервер устанавливается несколько HBA (так называемый режим «multipathing»), который позволяют решить сразу несколько проблем:

  • Обеспечивается резервирование путей доступа (failover) – при аварийной ситуации с одним каналом (повреждение кабеля, поломка адаптера HBA) все данные благополучно транслируются по второму пути.


  • Балансировка нагрузки (load balancing) – несколько каналов используются, как один общий, увеличивая пропускную способность и одновременно распределяя нагрузку равномерно по всем путям.


  • Если рассмотреть рисунок «Структурная схема системы хранения данных», становится понятно, что при прямом подключении сервера к стойке двумя путями они должны быть подключены к FC-портам различных процессорных модулей, для того чтобы сервер продолжал работать при выходе из строя сразу всего процессорного модуля. Естественно, для использования multipathing должна быть обеспечена поддержка этой функциональности аппаратными и программными средствами всех уровней, участвующих в передаче данных.


    Конечно же, полное резервирование без средств мониторинга и оповещения не имеет смысла – поэтому все серьёзные системы хранения имеют такие возможности. К примеру, оповещение о каких-либо критических событиях может происходить различными средствами – это оповещение по e-mail, автоматический модемный звонок в центр техподдержки, сообщение на пейджер (сейчас актуальнее SMS), SNMP-механизмы и прочее. О защите целостности данных средствами RAID мы уже говорили – это неотъемлемая часть любой системы хранения. При этом используется механизм дисков HotSpare – когда на группу дисков (RAID) или на всю систему целиком (global HotSpare) логически «выделяются» жёсткие диски, которые не участвуют в работе, а просто находятся в «незадействованном» состоянии. При выходе из строя рабочих дисков HotSpare-диски сразу подменяют их – система автоматически отключает сбойный диск и перестраивает RAID-группу, используя свободный диск HotSpare. Такой механизм необходим для снижения времени восстановления RAID’а, ведь если у нас RAID уровня 5, в котором из строя вышел один-единственный жёсткий диск, все данные находятся под угрозой: отказ ещё одного диска – это безвозвратная потеря данных, что недопустимо. Альтернатива этому – замена вышедшего из строя диска системным администратором вручную – это может занять часы и даже дни, а ведь данные в это время находятся под угрозой! Следующая особенность, характерная именно для систем хранения, – это возможность модернизации (апгрейда) оборудования и ПО без остановки системы. Например, при правильном подключении серверов и использовании multipathing ничто не мешает нам на работающей системе менять один из процессорных модулей. Или блоков питания. Или модернизировать внутреннее ПО стойки… Конечно, СХД должна поддерживать такую возможность – обычно это прерогатива систем хранения среднего и высшего уровня. Но вся концепция высоконадёжного хранилища и состоит в круглосуточной и круглогодичной работе – в идеале от запуска системы в работу и до остановки и списания в утиль, через годы, центральное хранилище данных должно функционировать всегда!



    Ну и как мы уже упоминали, существуют мощные средства управления всем этим великолепием. Обычно это web-интерфейс, консоль, возможность писать скрипты и встраивать управление во внешние программные пакеты. Про механизмы, обеспечивающие высокую производительность СХД, упомянем лишь вкратце – неблокируемая архитектура с несколькими внутренними шинами и большим количеством жёстких дисков, мощные центральные процессоры, специализированная система управления (ОС), большой объём кэш-памяти, множество внешних интерфейсов ввода-вывода.

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

    Следующее по популярности решение – ПО для создания мгновенных и полных копий данных. Различные производители по-разному называют свои программные продукты и механизмы создания этих копий. Мы для обобщения можем манипулировать словами снапшот (snapshot) и клон (clone). К примеру, для уже упоминавшихся систем хранения EMC программное обеспечение для создания клонов и снапшотов называется EMC SnapView.



    Увеличить

    Создание копий с помощью EMC SnapView (web-интерфейс)

    Клон делается средствами дисковой стойки внутри самой стойки – это полная внутренняя копия данных. Сфера применения довольно широка – от бэкапа (backup) до создания «тестовой версии» исходных данных, к примеру, для рискованных модернизаций, в которых нет уверенности и применять которые на актуальных данных небезопасно. Тот, кто внимательно следил за всеми прелестями СХД, которые мы тут разбирали, спросит – для чего же нужен бэкап данных внутри стойки, если она обладает такой высокой надёжностью? Ответ на этот вопрос на поверхности – никто не застрахован от человеческих ошибок. Данные сохранены надёжно, но если сам оператор сделал что-то не так, к примеру, удалил нужную таблицу в базе данных, от этого не спасут никакие аппаратные ухищрения.


    Клонирование данных обычно выполняется на уровне LUN. Более интересная функциональность обеспечивается механизмом снапшотов. В какой-то мере мы получаем все прелести полной внутренней копии данных (клона), при этом не занимая 100% объёма копируемых данных внутри самой стойки, ведь такой объём нам не всегда доступен. По сути снапшот – мгновенный «снимок» данных, который не занимает времени и процессорных ресурсов СХД. Объём же дискового пространства для хранения снапшота определяется объёмом модернизированных данных, которые появились с момента создания снапшота. К примеру, если в 8 часов утра мы создали снапшот с LUN объёмом 1Tбайт, при этом к 18 часам вечера в исходных данных поменялось 20% информации, наш снапшот станет занимать 200 Гбайт, что, конечно же, значительно меньший объём, чем при создании клона. Оба механизма (снапшот и клон) позволяют восстановить исходные данные, т.е. сделать rollback. Если, к примеру, обнаружилось, что после создания нашего снапшота в 12.30 система дала сбой и все вновь накапливаемые данные оказались повреждены, нам ничего не стоит сделать rollback с нашего снапшота, и все данные на исходном LUN будут возвращены в состояние на момент точки создания снапшота – то есть на момент 8 часов утра. При этом корректные данные, которые были накоплены с 8 утра до 12.30, будут потеряны. Если же делать снапшот каждый час рабочего дня, мы сможем «откатить» назад изменения до нужного момента, то есть мы бы могли откатиться до точки создания снапшота в 12.00 – тогда бы мы потеряли данные только за промежуток 12.00-12.30, то есть за полчаса.



    Rollback: восстановление состояния LUN

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


    Это может занять много часов, в этот момент с базой работать нельзя. Часто такой механизм неприемлем, система не должна так долго простаивать. В этом случае очень просто обходиться созданием снапшотов, если БД хранится на СХД – база останавливается, с неё делается мгновенный снимок (снапшот), после чего работа с базой возобновляется. При автоматизации такой процесс может занимать всего лишь минуты. Полученный на системе хранения снапшот может быть подключён к любому серверу, который и будет осуществлять резервное копирование базы на ленту сколь угодно долго – при этом основная БД будет находиться в рабочем состоянии. Однако тут следует учесть следующее – хотя логически исходная БД и снапшот – это два разных LUN (подключённых к двум или более серверам), физически все те данные, которые не успели измениться в исходном LUN с момента создания снапшота, так и находятся на исходном LUN, и доступ к ним уже будут осуществлять не только серверы СУБД, но и сервер, осуществляющий backup – что может в какой-то мере снизить производительность.

    Конечно нельзя не упомянуть ПО для репликации (replication) данных, которое часто называют зеркалированием (mirroring). Это механизм синхронного или асинхронного реплицирования (дублирования) информации с одной системы хранения на одну или несколько удалённых систем хранения. Репликация возможна по различных каналам – к примеру, стойки с интерфейсами FibreChannel могут асинхронно, через Интернет и на большие расстояния, реплицироваться на другую СХД. Такое решение обеспечивает надёжность хранения информации и защиту от катастроф. Все мы помним 11 сентября в США, когда были полностью разрушены два здания Всемирной Торговой Организации (WTC) – при этом были безвозвратно утеряны огромные объёмы данных. Реплицирование на удалённые площадки, создание резервных ВЦ позволяет избежать потери данных при катастрофах, они ведь не так редки, как кажется – обычный пожар может уничтожить все данные в любой самой совершенной системе хранения. Ну конечно, не стоит забывать и про обычное резервное копирование, даже реплицирование – не панацея от всех бед.



    Кроме всех перечисленных механизмов, существует большое число других возможностей манипуляций данными, которые зачастую невозможно осуществить вне дисковой стойки. К примеру, миграция данных с одной LUN на другой без остановки системы и без прерывания работы. Например, администратора перестала устраивать скорость работы LUN, находящегося на RAID уровня 5, и он решил переместить все данные на RAID 10, состоящий из большего числа дисков. Задача в обычных условиях нетривиальная, однако некоторое оборудование позволяет осуществить такую операцию незаметно для хостов – постепенно, с заданным приоритетом, данные внутри системы хранения копируются (мигрируют) с одного LUN на другой (с RAID5 на RAID10), после полной синхронизации и незаметно для пользователей сама система переключает все хосты, работающие с первым LUN на второй, то есть самостоятельно производит нужную переконфигурацию системы. Администратору остаётся только перераспределить место, занимаемое первым LUN – теперь он неактуален. Также хочется упомянуть о возможности динамического изменения размера LUN без остановки системы – тут уже всё упирается в операционную систему хост-машины, которая должна правильно отработать такое событие.

    Кратко хочется упомянуть о средствах коммутации в среде FibreChannel – о коммутаторах (switches). Основные игроки на этом рынке Cisco, McData, Brocade, QLogic. Практически все коммутаторы, поставляемые крупнейшими производителями СХД под своей торговой маркой – это OEM от Cisco, McData или Brocade.



    Коммутаторы Cisco для SAN

    Коммутаторы, обладающие большим числом портов, внутренним резервированием управляющих модулей и шин, часто называют «директор» (director). Обычно надёжность директоров составляет т.н. «пять девяток» – 99,999%, они предназначены для работы в качестве ядра (core) сетевой инфраструктуры FibreChannel (или FICON, к примеру) и зачастую строятся по модульному принципу, позволяя создавать нужные конфигурации портов с требуемыми возможностями. К примеру, это может быть большое количество неблокируемых портов, когда все порты могут одновременно функционировать на полной заявленной скорости – в данный момент это 2 Gb и полным ходом идем переход на 4 Gb, таких устройств уже немало.


    Скорости выше, вплоть до 10 Gb, используются обычно для организации связей между самими коммутаторами (ISL). Коммутаторы для сетей SAN обладают широкими возможностями, позволяя выстраивать подключение устройств по разным схемам, без изменения физической топологии. Управление осуществляется, как и у СХД – web-интерфейс, командная строка, также широки возможности оповещения о критических событиях. Некоторые устройства позволяют обновлять внутреннее программное обеспечение (firmware) без остановки работы, что также немаловажно – например, фирменная технология HotCAT от McData. Одна из основных функций коммутаторов – организация зонного разделения устройств SAN, так называемый zoning (зонирование). Зонирование позволяет создавать зоны, которые ограничивают возможность взаимодействия FC-устройств в SAN – ведь абсолютно не нужно (за редким исключением), чтобы два сервера сети «видели» друг друга – это некорректно с точки зрения безопасности и излишне нагружает сеть. Коммутаторы в единой фабрике функционируют как единое целое, позволяя также управлять безопасностью сети – возможно ограничивать подключение новых устройств в конкретный коммутатор или в фабрику в целом, а также ограничивать подключение неавторизованных устройств в активные порты (контролируется по WWN) и так далее. Коммутатор сетей SAN – это сложное и недешёвое устройство, которое требует конфигурирования специалистом и является ядром коммутации всей сети, при нарушении конфигурации вся работа может в мгновение остановиться. Чтобы избежать таких проблем и повысить надежность, в SAN используют несколько коммутаторов в различных фабриках (что будет рассмотрено ниже).

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

    Устройства DAS (Direct Attached Storage) – системы хранения, подключаемые напрямую к серверу.


    Сюда относятся как самые простые SCSI-системы, подключаемые к SCSI/RAID-контроллеру сервера, так и устройства FibreChannel, подключенные прямо к серверу, хотя и предназначены они для сетей SAN. В этом случае топология DAS является вырожденной SAN (сетью хранения данных):



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

  • Низкая надежность – при проблемах сети или аварии сервера данные становятся недоступны всем сразу.


  • Высокая латентность, обусловленная обработкой всех запросов одним сервером и использующимся транспортом (чаще всего – IP).


  • Высокая загрузка сети, часто определяющая пределы масштабируемости путём добавления клиентов.


  • Плохая управляемость – вся ёмкость доступна одному серверу, что снижает гибкость распределения данных.


  • Низкая утилизация ресурсов – трудно предсказать требуемые объёмы данных, у одних устройств DAS в организации может быть избыток ёмкости (дисков), у других её может не хватать – перераспределение часто невозможно или трудоёмко.


  • Устройства NAS (Network Attached Storage) – устройства хранения, подключённые напрямую в сеть. В отличие от других систем NAS обеспечивает файловый доступ к данным и никак иначе. NAS-устройства представляют из себя комбинацию системы хранения данных и сервера, к которому она подключена. В простейшем варианте обычный сетевой сервер, предоставляющий файловые ресурсы, является устройством NAS:



    Все минусы такой схемы аналогичны DAS-топологии, за некоторым исключением. Из добавившихся минусов отметим возросшую, и часто значительно, стоимость – правда, стоимость пропорциональна функциональности, а тут уже часто «есть за что платить». NAS-устройства могут быть простейшими «коробочками» с одним портом ethernet и двумя жёсткими дисками в RAID1, позволяющими доступ к файлам по лишь одному протоколу CIFS (Common Internet File System) до огромных систем в которых могут быть установлены сотни жёстких дисков, а файловый доступ обеспечивается десятком специализированных серверов внутри NAS-системы.


    Число внешних Ethernet- портов может достигать многих десятков, а ёмкость хранимых данных – несколько сотен терабайт (например EMC Celerra CNS). Такие модели по надёжности и производительности могут далеко обходить многие midrange-устройства SAN. Что интересно, NAS-устройства могут быть частью SAN-сети и не иметь собственных накопителей, а лишь предоставлять файловый доступ к данным, находящимся на блочных устройствах хранения. В таком случае NAS берёт на себя функцию мощного специализированного сервера, а SAN – устройства хранения данных, то есть мы получаем топологию DAS, скомпонованную из NAS- и SAN-компонентов.

    NAS-устройства очень хороши в гетерогенной среде, где необходим быстрый файловый доступ к данным для многих клиентов одновременно. Также обеспечивается отличная надёжность хранения и гибкость управления системой вкупе с простотой обслуживания. На надёжности особо останавливаться не будем – этот аспект СХД рассмотрен выше. Что касается гетерогенной среды, доступ к файлам в рамках единой NAS-системы может быть получен по протоколам TCP/IP, CIFS, NFS, FTP, TFTP и другим, включая возможность работы NAS, как iSCSI-target, что обеспечивает функционирование с различным ОС, установленными на хостах. Что касается лёгкости обслуживания и гибкости управления, то эти возможности обеспечиваются специализированной ОС, которую трудно вывести из строя и не нужно обслуживать, а также простотой разграничения прав доступа к файлам. К примеру, возможна работа в среде Windows Active Directory с поддержкой требуемой функциональности – это может быть LDAP, Kerberos Authentication, Dynamic DNS, ACLs, назначение квот (quotas), Group Policy Objects и SID-истории. Так как доступ обеспечивается к файлам, а их имена могут содержать символы различных языков, многие NAS обеспечивают поддержку кодировок UTF-8, Unicode. К выбору NAS стоит подходить даже тщательнее, чем к DAS-устройствам, ведь такое оборудование может не поддерживать необходимые вам сервисы, например, Encrypting File Systems (EFS) от Microsoft и IPSec.


    К слову можно заметить, что NAS распространены намного меньше, чем устройства SAN, но процент таких систем всё же постоянно, хотя и медленно, растёт – в основном за счёт вытеснения DAS.

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



    После довольно детального рассмотрения устройств и принципов их функционирования нам будет довольно легко понять топологию SAN. На рисунке мы видим единую для всей инфраструктуры СХД, к которой подключены два сервера. Серверы имеют резервированные пути доступа – в каждом установлено по два HBA (или один двухпортовый, что снижает отказоустойчивость). Устройство хранения имеет 4 порта, которыми оно подключено в 2 коммутатора. Предполагая, что внутри имеется два резервируемых процессорных модуля, легко догадаться, что лучшая схема подключения – когда каждый коммутатор подключён и в первый, и во второй процессорный модуль. Такая схема обеспечивает доступ к любым данным, находящимся на СХД, при выходе из строя любого процессорного модуля, коммутатора или пути доступа. Надёжность СХД нами уже изучена, два коммутатора и две фабрики ещё более увеличивают доступность топологии, так что если из-за сбоя или ошибки администратора один из коммутационных блоков вдруг отказал, второй будет функционировать нормально, ведь эти два устройства не связаны между собой.

    Показанное подключение серверов называется подключением с высокой доступностью (high availability), хотя в сервере при необходимости может быть установлено ещё большее число HBA. Физически каждый сервер имеет только два подключения в SAN, однако логически система хранения доступна через четыре пути – каждая HBA предоставляет доступ к двум точкам подключения на СХД, к каждому процессорному модулю раздельно (эту возможность обеспечивает двойное подключение коммутатора к СХД).


    На данной схеме самое ненадежной устройство – это сервер. Два коммутатора обеспечивают надежность порядка 99,99%, а вот сервер может отказать по разным причинам. Если необходима высоконадёжная работа всей системы, серверы объединяются в кластер, приведённая схема не требует никакого аппаратного дополнения для организации такой работы и считается эталонной схемой организации SAN. Простейший же случай – серверы, подключённые единственным путем через один свитч к системе хранения. Однако система хранения при наличии двух процессорных модулей должна подключаться в коммутатор как минимум одним каналом на каждый модуль – остальные порты могут быть использованы для прямого подключения серверов к СХД, что иногда необходимо. И не стоит забывать, что SAN возможно построить не только на базе FibreChannel, но и на базе протокола iSCSI – при этом можно использовать только стандартные ethernet-устройства для коммутации, что удешевляет систему, но имеет ряд дополнительных минусов (оговоренных в разделе, рассматривающем iSCSI). Также интересна возможность загрузки серверов с системы хранения – не обязательно даже наличие внутренних жёстких дисков в сервере. Таким образом, с серверов окончательно снимается задача хранения каких-либо данных. В теории специализированный сервер может быть превращён в обычную числодробилку без каких-либо накопителей, определяющими блоками которого являются центральные процессоры, память, а так же интерфейсы взаимодействия с внешним миром, например порты Ethernet и FibreChannel. Какое-то подобие таких устройств являют собой современные blade-серверы.

    Хочется отметить, что устройства, которые возможно подключить в SAN, не ограничены только дисковыми СХД – это могут быть дисковые библиотеки, ленточные библиотеки (стримеры), устройства для хранения данных на оптических дисках (CD/DVD и прочие) и многие другие.

    Из минусов SAN отметим лишь высокую стоимость её компонент, однако плюсы неоспоримы:

  • Высокая надёжность доступа к данным, находящимся на внешних системах хранения.


    Независимость топологии SAN от используемых СХД и серверов.


  • Централизованное хранение данных (надёжность, безопасность).


  • Удобное централизованное управление коммутацией и данными.


  • Перенос интенсивного трафика ввода-вывода в отдельную сеть, разгружая LAN.


  • Высокое быстродействие и низкая латентность.


  • Масштабируемость и гибкость логической структуры SAN


  • Географически размеры SAN, в отличие от классических DAS, практически не ограничены.


  • Возможность оперативно распределять ресурсы между серверами.


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


  • Простая схема резервного копирования – все данные находятся в одном месте.


  • Наличие дополнительных возможностей и сервисов (снапшоты, удаленная репликация).


  • Высокая степень безопасности SAN.


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

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

    По оценкам IDC за 2004 год рынок дисковых систем хранения составил почти $21 млрд., из которых более $14 млрд. составляют именно внешние дисковые системы хранения. Если учитывать, что рост рынка в денежном выражении прогнозируется порядка 10% в год, а оборудование и особенно носители постоянно дешевеют – несложно предположить, как стремительно развивается сектор индустрии, ориентированный именно на работу с данными. Любые данные предстают перед нами в виде информации. Смысл работы любых вычислительных устройств – обработка информации. В последнее время объёмы её роста порой пугают, поэтому системы хранения данных и специализированное программное обеспечение, несомненно, будут самым востребованными продуктами IT-рыка в ближайшие годы

    Оригинал статьи на

    www.ferra.ru"


    Часть 2Часть 1

    Содержание раздела