Archive for мая 2009

“Вы хочете скидок? Их есть у меня!”

Итак, некоторое руководство о том, как просить и получать скидки, при покупке “Enterprise-IT”.
Ранее я уже говорил, что “цена прайс-листа” в нашей области не означает, по сути, ничего, в лучшем случае обозначает некий предмет разговора, и только. Наш “турецкий базар”, как правило, никогда не торгует по “ценнику”, и это нормальная ситуация. У нас штучный товар, у нас штучные покупатели, и процветает “индивидуальный подход”.

Какие же аргументы бывают в разговоре покупателя с продавцом, чтобы стимулировать последнего на предложение скидки при продаже?

1. Объем покупки.
На один жесткий диск ну какая может быть скидка? Зато если вы берете “круто упакованную” систему, то тут уже есть о чем говорить.
Другой вариант: Если вы покупаете (условно) один диск в месяц, или покупаете 12 дисков на целый год (возможен вариант: заключаете договор на поставку 12 дисков в течении года, с помесячной оплатой). Казалось бы то же самое, а во втором случае те же диски вам обойдутся заметно дешевле.

2. Покупка со скидкой сейчас, или без скидки “когда-нибудь”.
Дайте скидку, и мы купим вот немедленно, потому что уложимся в бюджет, иначе придется ждать “у моря погоды” (у финдепартамента денег) неизвестно сколько. Вы не представляете насколько может быть податлив продавец, с невыполненным квартальным планом продаж, накануне конца квартала ;)

3. В проект “вошел” конкурирующий вендор.
Наиболее частый и безыскусный случай.

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

5. “Нужный человек” (выход на перспективный рынок).
Продажа “нужному человеку”, для захвата перспективного рынка, “вхождения в нужный аккаунт”, и так далее. Прессануть конкурентов, выбить их и захватить жирную “делянку”, с перспективой закрепиться и продавать на ней в дальнейшем, может подвигнуть вендора на совершенно беспрецедентные скидки. Если вам посчастливилось оказаться на таком участке рынка, то скидки будут весьма радостные. Но, возможно, вам удастся заинтересовать вендора своим рынком, если он до сих пор его не рассматривал, а вы видите перспективы? Попробуйте.

6. Предоплата.
Очень стимулирует размер скидки возможность предоплаты, даже частичной.

7. Покупка б.у, некомплекта, демо, распродажа склада.
Б.У. это не всегда плохо. Практически все партнеры, по условиям своего партнерского соглашения с вендором, закупают так называемый “демо-пул”, набор железа, который партнер обязан держать “на складе” или в качестве “демо-системы”. На такие системы партнеру, чтобы его не разорить вконец, дается очень большая скидка, они продаются практически по себестоимости. Иногда эти сервера или системы хранения, возятся на выставки, выдаются клиентам как подменные, ставятся как демо, и так далее. Спустя какой-то время (обычно полгода, год) они распродаются со скидкой, чтобы купить на их место более актуальные модели.
Купить, пусть и не “хрустяще-новый” аппарат, но с очень весомой скидкой, продленным сроком сервисного обслуживания, и с поставкой не “шесть-восемь недель”, а “завтра” может быть весьма выгодным ходом.

8. Покупка “плохо покупаемого” продукта.
“Плохо покупаемый” не значит “плохой”. В линейке продуктов любого вендора есть продукты или “нишевые”, или по каким-то причинам “плохо идущие”, но при этом на своем месте очень востребованные. Пример - судьба VTL в России. По моим наблюдениям, несмотря на свой оглушительный успех в мире, в России они почти не продаются.
И если вам понадобился, по условиям проекта, именно такой “редкий зверь”, то вполне разумно получить под него скидку побольше.

9. Для продвижения другого контракта.
Пример: продаем нечто со скидкой, чтобы заключить в дальнейшем сервисный контракт, который может быть выгоднее для продавца, чем продажа тупой железки. Продажа “пилотной инсталляции” под дальнейшие проекты.

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

Ну и, напоследок, немного о том, “как не получить скидок”.

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

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

2. Очень не любят продавцы, как я их называю, “ковыряющихся”, персонажей, подобных известной сцене с СеменСеменыч Горбунковым и “перламутровыми пуговицами”. То есть когда за интересом заведомо не стоит никакого проекта. Это означает для продавца интегратора потраченное время, усилия, с явным нулевым выхлопом. Это для вас сказать “А можно такое же, только с перламутровыми пуговицами диски не FC, а SATA, и не 50, а 25, и вот это вот выкинуть, а вон то добавить?” это примерно 30 секунд времени. На нашей стороне это, зачастую, несколько часов работы, в особенности если при этом переделывается множество сопутствующих документов, да и ту самую скидку рассчитывают на каждую конкретную конфигурацию. После нескольких таких итераций, когда продавец понимает, что вам просто любопытно, “как слоники бегают”, энтузиазм его угасает. И когда вы, наконец, дозреете, то не удивляйтесь отсутствию энтузиазма на нашей стороне.

3. Некрасиво выглядит откровенное прессование двух партнеров, с помощью “гонки скидок”.
“Компания А дала нам 34 процента скидки, дайте 35! Компания Б дала нам 35%, дайте 36!”
В какой-то момент Компания А созвонится с Компанией Б, и обсудит такого клиента между собой.
Мирок интеграторов тесен, и все мы тусуемся на одних и тех же фуршетах.

4. И совсем “не по джентльменски” выглядит, когда клиент получив запрошенную им скидку в оговоренном ранее размере, вдруг “передумывает” (читай: сходил к конкуренту, и получил от него на 1% больше). Тут как в шахматах: “взялся - ходи”. Попросил 60% скидки? Получил? Покупай. Иначе зачем просил?

“Покажь прайс!”

Часто приходится слышать сетования на то, что вот, мол, у NetApp (как и у большинства прочих вендоров, заметим) нигде не найти цен. Что за каждым чихом ходить к партнеру, просить его сгенерировать предложение - просилка отсохнет. Почему бы просто не выложить в свободный доступ прайс, и всем бы стало все ясно.

Ответ: не стало бы.
Хотя, в принципе, найти дамп прайса в интернете можно. Например блоггер storagemojo регулярно дампит прайс Нетаппа. Как по мне, так более бессмысленное занятие еще поискать, но давайте разберемся - почему.

Как вообще получается та спецификация, которую вы, как клиент, получаете от партнера NetApp, какого-то из системных интеграторов?

У NetApp есть онлайновый конфигуратор, в котором пресейл составляет систему, а на выходе генерируется спецификация с текущими ценами. После добавления скидок и накруток, эту спеку, с соответствующим технико-коммерческим предложением, вы в итоге и получаете.
Вы уже догадываетесь, что система хранения, как правило, включает в себя множество компонентов, зачастую связи между этими компонентами довольно запутаны, вида: “эта карта 4-port Ethernet не работает вот с этими системами, только вот с этими и этими, причем только с версией ONTAP не ниже вот такой. Причем, если у вас в конфигурации также есть вот такой компонент, то тогда вместо этой карты надо ставить вот такие две двухпортовые, потому что слот, в который можно поставить ту карту будет занят этим компонентом.”
И так далее и так далее. Тьма нюансов, которые даже нам, много лет занимающимся темой, не удержать в голове.
Могу вам с уверенностью сказать, что сгенерировать безошибочную и работоспособную такую систему вручную практически невозможно. Я еще застал времена, когда такое делалось вручную, правда не с системами NetApp, а у конкурентов, и это была “жесть, как она есть”, в виде многолистового XLS с формулами, дропбоксами и описаниями порядка составления. Но там хотя бы гораздо более крупноблочная конфигурация была.

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

Во вторых - не забудьте про скидки. На один диск никакой скидки скорее всего не положено. поэтому так шокированы бывают клиенты, впервые сталкивающиеся с “миром энтерпрайз-IT”, с их “дисками SATA по две тысячи евро в прайсе”. А на систему в целом, особенно при умении договариваться и аргументировать (кстати, а не написать ли мне соответствующий пост? ;) можно получить скидки весьма значительные, более того, в ряде случаев реально so-f*ing-unbelieveable-big скидки. У нас никто не торгует по прайс-листу. Торговля у нас, в энтерпрайзе, это скорее турецкий или египетский базар, в котором человек купивший по первой же названной цене воспринимается как крайний лох ;) Обсуждайте, предлагайте свои условия, свои цены, аргументируйте, просите скидок - “и дастся вам” (с). В конечном счете мы тут за этим на базаре и сидим. По прайсу вон, пускай санрайз торгует. У нас товар штучный, с подходом.

Так что даже и получив “цены прайс-листа” из подобных дампов, или, как они называются, “рекомендованные цены”, MSRP, вы все равно, скорее всего, не сможете составить из них представление о цене системы в целом.
Ну и, наконец, не забудьте о том, что цены рынка Америк во многих случаях отличаются от EMEA, не забудьте учесть “доставку-растаможку-инсталляцию-постановку на сервис”, которая тоже довольно существенно варьируется.

Вот почему вендоры энтерпрайз-систем не показывают своих прайсов. А вовсе не для того, чтобы интеграторам было проще заграбастать ваши “нажитые непосильным трудом” денежки. Интеграторы бывают разные, не спорю, но излишне демонизировать нас не стоит. ;о)

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

Использование команды config

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

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

filer01> config
Usage:
config clone
config diff [-o ] [ ]
config dump [-f] [-v]
config restore [-v]

Команда простая и понятная. Сперва вы сохраняете (dump) конфигурацию с системы хранения. Это проделывается с содержимым /etc/configs. Далее вы можете клонировать (clone) эту конфигурацию на другую систему, или сравнить ее (diff) с ранее сделанным дампом конфига. Запуск diff это отличный способ сравнить два конфига между двумя моментами времени, если вы не уверены или не помните что вы изменяли. И, наконец, вы можете воспользоваться средствами восстановления (restore), однако не забудьте, что это потребует перезапуска системы хранения.

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

Новые переводы документации.

В техбиблиотке компании Netwell - новинка: перевод документа TR-3369, “Руководство по наилучшим способам использования систем NetApp с Oracle”.
Переводил - я. Так как не являюсь специалистом по Oracle, то возможны переводческие недочеты, поэтому с благодарностью приму поправки.

Следующим будет TR-3428 “Руководство по наилучшим способам использования систем NetApp с VMware Virtual Infrastructure 3″, наиболее последней на сегодня версии 4.4 за декабрь прошлого года.

Проблемы и решения Usable Space. Часть 2.

Теперь давайте посмотрим как на всем этом, рассмотренном в прошлом посте, располагаются пользовательские данные.
Поверх “слоя виртуализации” - Aggregate - включающего в себя, как правило, все диски системы, и позволяющего нам распараллеливать ввод-вывод на все имеющиеся “физические шпиндели”, находятся собственно элементы доступные пользователю, “тома” типа FlexVol или Flexible Volumes.
Непосредственно на этих томах, которые, еще раз напомню, физически “тонким слоем размазаны” по всем входящим в aggregate дискам системы, уже можно хранить файлы для NAS-систем, или создавать LUN-ы для SAN.

Однако тут стоит вспомнить о том, что все это разнообразие и богатство обеспечивается нам своеобразной структурой данных, или “файловой системой” WAFL, которая и создает базовые структуры данных на дисках, являясь заодно и менеджером томов, и частью “RAID-контроллера” системы. Эта необычная “псевдо-файловая система” достойна отдельной серии постов, и я уже опубликовал тут мой перевод интереснейшей статьи инженера NetApp Костадиса Руссоса, о том, как устроена WAFL, и почему, по его мнению, не вполне корректно называть WAFL “файловой системой”, по крайней мере чтобы не смешивать ее в восприятии с другими файловыми системами.

Не буду вдаваться в детальные подробности ее устройства, тем более, что не далее как несколько постов назад я уже анонсировал подробное описание “внутренностей” WAFL от его непосредственных авторов. Интересующиеся могут попробовать углубиться в тему прочитав ту статью в техбиблиотеке на сайте одного из дистрибуторов NetApp в России, компании Netwell.
(см. ссылку в правом столбце)

Для нас же важно то, что же нам дает использование поверх raw data этой файловой системы? Будем уж так ее по традиции называть, хотя следует помнить, что это если и файловая система, то в чем-то единственная в своем роде.

Прежде всего, это возможность создавать и хранить снэпшоты, самая, пожалуй, известная особенность NetApp./p pСнэпшоты, кстати сказать придуманные и впервые реализованные в индустрии систем хранения именно NetApp, работают следующим образом:
Snapshots

Идея снэпшотов плодотворно питает множество “фич” систем хранения NetApp. Многие возможности, такие как SnapMirror (репликация) или FlexClone (виртуальное клонирование), прямо или косвенно выросли из этого свойства WAFL.

Как я уже писал ранее, особенностью реализации снэпшота в NetApp является его “некопированность”. При создании NetApp’s Snapshot ™ данные, уже попавшие на диски, не копируются, а только сохраняется дополнительная таблица inodes. Так как WAFL устроена таким образом, что данные на нее не перезаписываются, а всегда только дозаписываются, пока блок хоть где-то использован, это гарантирует нам то, что данные в снэпшоте при таком подходе, останутся неизменными.

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

Второй особенностью следует назвать необычный тип RAID, RAID-4 (”ONTAP RAID”), и необычный способ работы с ним. Почему я рассматриваю RAID на уровне файловой системы? Дело в том, что WAFL, по сути, “спускается” в своей работе на уровень RAID- и Volume-manager.
Этот вопрос уже рассматривался в упомянутой ранее статье Костадиса Руссоса. WAFL не имеет ряда принципиальных для других файловых систем средств, например по работе с файловыми и директорными структурами, поиска и извлечения файлов, зато она оперирует на “низком” уровне RAID. То есть можно себе представить, что, по сравнению с какой-нибудь NTFS или ext3, WAFL пропорционально смещена “вниз” по этой “иерархии”. В ней меньше “высокоуровневых” средств, которые отданы “на откуп” сетевым файловым системам, таким как NFS или CIFS, или средствам блочной работы с LUN-ами, зато она, в большем объеме, чем традиционные файловые системы, работает с уровнем RAID и Volumes, в которые традиционные файловые системы не вмешиваются.

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

Обычно производители систем хранения предлагают выбор между двумя-тремя типами RAID: RAID-10 (или RAID-0+1), и RAID-5 (а сейчас к ним добавился набирающий популярность RAID-6). Ранее я писал подробную статью о RAID, и разнице между ними, интересующимся предлагаю сходить туда.
Эти типы RAID, применяемые на подавляющем количестве систем хранения, выбираются для конкретной задачи и используются следующим образом: если нужно хорошее быстродействие на запись, то все рекомендации говорят о использовании RAID-10. Его преимущества - быстрота работы. Его недостаток - мы “дарим” системе за это половину всей емкости дисков, Usable Space равно 50% от Raw. Довольно бандитские условия. ;)

Если быстродействие на запись не важно, а важна емкость - RAID-5. При этом на каждую RAID-группу мы теряем один диск под данные “четности”, но заметно падает скорость записи (а также скорость восстановления при сбое диска). Такая организация дисков как правило используется для систем долговременного хранения, хранения резервных копий, и тому подобного.

RAID-6 применяется либо при повышенных требованиях к надежности, либо при использовании менее надежных дисков, таких как SATA. При его использовании еще сильнее снижается скорость записи (примерно на 15-20% от скорости RAID-5), так как увеличивается объем вычислений для второго диска “четности”

Против всего этого зоопарка NetApp выставляет всего два варианта, а именно: RAID-4 и RAID-DP (вариант RAID-6). Почему?
Очень просто. RAID-4 или RAID-DP, в их реализации у NetApp, практически не проигрывают по быстродействию RAID-10, но при этом столь же экономичны к usable space как RAID-5/6.
А раз так, то зачем другие типы RAID, если те, что есть, полностью удовлетворяют по всем нужным параметрам?

Вот почему NetApp не предлагает “привычные” типы RAID. Их многообразие у традиционных систем хранения просто маскирует принципиальную ущербность “классических” типов RAID, среди которых пользователю предлагается выбрать компромисс, либо пожертвовав usable-емкостью в пользу быстродействия (RAID-10), либо быстродействием в пользу емкости (RAID-5), либо и тем и другим в пользу надежности (RAID-6).

Теперь, вооруженные всеми этими знаниями, перейдем к разбору “классики говнилок” - тому, “куда у этого Нетаппа девается место на дисках”. Продолжим в следующий понедельник.

Проблемы (и решения) Usable Space. Часть 1. Основы.

В ближайшие несколько постов я бы хотел поговорить о некоторых аспектах usable space на системах хранения NetApp. Usable Space на NetApp, а также методы его образования из raw, это также источник бесчисленных спекуляций наших уважаемых конкурентов (в дальнейшем "Н.У.К." ;).
Я отдельно остановлюсь на "говнилках" на эту тему в отдельном посте, а пока давайте разберем фундаментальные основы того, как из Raw Space образуется Usable Space, чтобы подойти к разбору FUD уже теоретически подкованными.

Но начнем издалека.

Итак, из чего складывается пространство usable space?
Один из документов NetApp, на который я давал ссылку раньше, так и называется:
Trading Capacity for Data Protection – A Guide to Capacity Overhead on a StoreVault Storage System
Мы платим за надежность хранения raw-байтами, и получаем, в итоге, меньшее по размерам пространство, но с разнообразными "фичами". Это естественный процесс.

Простейший случай обмена "байтов на надежность" это RAID. Мы платим пространством одного диска (в случае RAID-5), двух (RAID-6), или половиной пространства (RAID-10 AKA RAID 0+1) за надежность и быстродействие.
Поверх RAID мы можем создать журналируемую файловую систему, и получаем "фичу" хранения и обработки "файлов", то есть огранизованных структур данных, со всем им присущим, и, вдобавок, защищаем целостность этих структур. Но, разумеется, партиции, загрузочные области, таблицы размещения файлов, ACL, структуры директориев, и прочее, все это также вычтется в свою очередь из пространства, дав нам взамен вышеописанные возможности, которых не было на простом и тупом raw-диске.
И так далее, и так далее.

Мы, несомненно теряем на этих процессах мегабайты за мегабайтами, но получаем взамен все новые и новые возможности.
Смешно возражать, что, мол, если бы вы не пользовались на вашей "венде" NTFS-ом, а работали бы прямо в адресации ATA, вы бы могли использовать больше места на диске, которые с ним заняты "непонятно чем".
Уже всем сегодня понятно - "чем".

Из чего же складывается, в свою очередь, usable space на NetApp?

Как вы уже знаете (по крайней мере те, кто давно читает этот блог;), NetApp, как "система хранения данных", довольно "высокоуровнева" по природе, если воспользоваться терминами из области языков программирования. Также как, например, какой-нибудь C# или Java позволяет пишущему полностью абстрагироваться в программе от, например, физической структуры регистров процессора и управления памятью, и заняться более продуктивными вещами, чем вычисления адресов, так и в случае использования пространства хранения на NetApp администратор системы хранения может абстрагироваться от "дисков" и "raw bytes".

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

Он также как и "обычные системы хранения" (тм) использует нижний уровень виртуализации, в виде RAID (RAID это, с точки зрения железа ведь тоже некий "виртуальный девайс"), но начиная с версии своей OS Data ONTAP версии 7 сделан еще один шаг в направлении "высокоуровневой" виртуализации - Aggregates и FlexVol-ы.

Aggregates это "слой дисковой виртуализации", структура (одна или несколько), в которую включены множество имеющихся у системы дисков, своеобразный disk pool, среди которых и распределяется нагрузка ввода-вывода.

Я уже писал раньше о важности такого параметра, как IOPS - Input-Output operations Per Second.
Для отдельного диска величина IOPS сравнительно невелика (в пределах двух, максимум трех сотен для SAS или FC, значительно меньше для SATA). Для того, чтобы увеличить производительность в IOPS, создатели дисковых систем хранения объединяют диски, например с помощью создания RAID-групп. Так, например, RAID-10 ("зеркало" с "чередованием") из 10 дисков будет иметь примерно вдесятеро большую производительность по IOPS, чем отдельный входящий в него диск. Это стало возможным за счет того, что, хотя для внешнего потребителя RAID это "один большой диск", внутри же он состоит из множества меньших, на каждый из которых мы можем писать свою порцию более-менее в параллельном режиме.

Однако бесконечно удлинять RAID тоже нельзя, так как снижается надежность и ухудшаются некоторые другие параметры. Кроме того далеко не всегда для данных, требующих высокой скорости, нужно так много места. А объединив 10 дисков по 300GB в RAID-10 мы получим "диск" размером полтора терабайта (300*10/2) под один только наш "скоростной файл". И так для каждой задачи.
Как правило производители "обычных систем хранения"(тм) выходят из положения путем возможности "конкатенации" (сложения A+B+C+D…) сравнительно небольших RAID-групп, и создании на получившемся пространстве так называемых LUN - логических устройств - "дисков".
Как видите, тут тоже своя "виртуализация" имеется.

Большим прорывом в свое время стала разработка уже покойной компанией DEC дисковых систем хранения, в которых появилась возможность объединить все "адресное пространство" жестких дисков, имеющихся в системе, в единый "пул байт", и уже поверх этого пула образовывать "виртуальные RAID" и разделы данных. Наследницы этих систем по сей день производятся компаний HP под названием EVA - Enterprise Virtual Array, и занимают до сих пор довольно значительную долю рынка, хотя нельзя закрывать глаза на тот факт, что системы эти постепенно (и все заметнее) морально устаревают, несмотря даже на столь прорывную и революционную идею в их основе.

Преимуществом объединения всех дисков в "общий пул" является возможность распределить входную нагрузку на все эти диски, работающие параллельно, нарезав на них нужное количество LUN нужных нам размеров, которые, свою очередь, также окажутся размазанными на все наши диски. При этом мы не платим за это "длинным RAID" и всеми его минусами, в виде, например, длительного ребилда и пониженной надежности. То есть, если мы имеем систему с 30 дисками, то, если мы сведем все эти диски в один aggregate, нарежем на нем нужное количество FlexVol, и насоздаем LUN (или будем использовать FlexVol под хранение файлов), то производительность каждого такого FlexVol, и LUN на нем, будет равна: 30*300 IOPS = ~ 9000 IOPS.
Все цифры, разумеется, условные и грубоприближенные, но с сохранением порядка.

Итак, начиная с Data ONTAP 7, структура хранения выглядит примерно так:

То есть - физические диски, над ними Aggregate, над ними RAID-ы в WAFL, на ней FlexVol-ы, на которых уже, в свою очередь, располагаются LUN-ы или "сетевые папки" NAS.
Каждый из этих уровней немножко отнимает от raw space, и добавляет за это каких-нибудь возможностей.

Продолжение в следующем посте.

18/0.156

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.