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

Последующая компания, которую мне бы хотелось упомянуть, – это 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-партнёрства. Мы перечислили только самые знаменитые решения и самые знаменитые компании.

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

Ежели осмотреть набросок «Структурная схема системы хранения данных», становится понятно, что при прямом подключении сервера к стойке 2-мя маршрутами они обязаны быть подключены к FC-портам разных процессорных модулей, для того чтоб сервер продолжал работать при выходе из строя сходу всего процессорного модуля. Природно, для применения multipathing обязана быть обеспечена поддержка данной функциональности аппаратными и программными средствами всех уровней, участвующих в передаче данных. Окончательно же, полное резервирование без средств мониторинга и извещения не имеет смысла – потому все серьёзные системы хранения имеют такие способности. К образцу, извещение о каких-либо критических событиях может происходить разными средствами – это извещение по e-mail, автоматический модемный звонок в центр техподдержки, известие на пейджер(на данный момент актуальнее SMS), SNMP-механизмы и прочее. О охране целостности данных средствами RAID мы теснее разговаривали – это неотъемлемая часть хоть какой системы хранения. При этом употребляется механизм дисков HotSpare – когда на группу дисков(RAID)либо на всю систему полностью(global HotSpare)логически «выделяются» жёсткие диски, которые не участвуют в работе, а просто находятся в «незадействованном» состоянии. При выходе из строя рабочих дисков HotSpare-диски сходу заменяют их – система автоматом отключает сбойный диск и перестраивает RAID-группу, используя вольный диск HotSpare. Таковой механизм нужен для понижения медли возобновления RAID’а, ведь ежели у нас RAID уровня 5, в котором из строя вышел один-единственный жёсткий диск, все данные находятся под опасностью: отказ ещё 1-го диска – это бесповоротная утрата данных, что неприемлимо. Кандидатура этому – подмена вышедшего из строя диска системным админом вручную – это может занять часы и даже дни, а ведь данные в это время находятся под опасностью!Последующая необыкновенность, отличительная конкретно для систем хранения, – это возможность модернизации(апгрейда)оборудования и ПО без остановки системы. К примеру, при правильном подключении серверов и использовании 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 – что может в какой-то мере понизить производительность.

-Дама, читающая "Плейбой", ощущает себя практически как еврей, читающий пособие для нацистов.(Глория Стайнем)