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

---

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

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



Также 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.





Следующая компания, которую мне бы хотелось упомянуть, – это HDS (Hitachi Data Systems), являющаяся подразделением компании Hitachi и занимающаяся разработкой и продажами систем хранения данных. Системы среднего уровня представлены оборудованием HDS Thunder 9500V (9530, 9570, 9585, 9520). Системы старшего уровня можно разделить на две линейки (хотя некоторые компании, поставляющие продукцию HDS, объединяют их в одну): Lightning 9900 V Series (модели 9970 и 9980) и TagmaStore Universal Storage Platform (модели HDS USP 100, 600 и 1100). Также у HDS существуют продукты NAS и специализированное программное обеспечение. Сразу в продолжение хочется упомянуть две компании, которые поставляют под своей торговой маркой оборудование HDS – это Sun Microsystems (SUN) и Hewlett-Packard (HP). Системы хранения данных компании SUN также можно разделить на три линейки – младшая линейка состоит из OEM-систем компании DotHill, старшая же – из OEM-систем компании HDS. Системы хранения данных среднего уровня можно разделить ещё на две линейки: продукты, самостоятельно разработанные компанией SUN, – это системы SUN StorEdge 6120, 6320, 6920 и OEM-системы от компании Engenio (Sun StorEdge 6130). Получилось немного запутанно, но так уж один из столпов серверостроения выстраивает свой модельный ряд. К слову упомяну, что компания SUN выпускает также свою операционную систему SUN Solaris (под несколько платформ) и всем известный продукт Java. Теперь перейдём ко второму месту чарта продаж – к Hewlett-Packard. Системы хранения данных компании HP можно условно разделить на три группы: системы начального уровня HP MSA (MSA1000, 1500 и другие), системы среднего уровня HP StorageWorks Enterprise Virtual Array (HP EVA 3000, 4000, 6000, 8000) и системы старшего звена, являющиеся OEM-продуктами компании HDS и поставляемые под маркой HP XP (модели XP1000 и XP12000).





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





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

Как мы уже говорили, 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.





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



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

Страница
1 > : обзор
2 : обзор-2