about NetApp

Недавняя моя заметка о выходе Data ONTAP 8.1 и некоторых особенностях новой версии, вызвала довольно широкий отклик, поэтому, для уменьшения количества панических слухов, я решил написать это дополнение и разъяснение.

Проблема, как вы уже знаете, в том, что, согласно Release Notes, в новой версии Data ONTAP, не поддерживается устройство Flash Cache на младших моделях линейки midrange, то есть на 3140, и даже на сравнительно недавно вышедшей 3210, несмотря на то, что Flash Cache можно физически в эти системы поставить, и ранее такая конфигурация поддерживалась.

По этому поводу ТАСС уполномочен сообщить мой источник в NetApp сообщает:

1. Да, действительно, это так. Поддержка Flash Cache для 3210/3140 сохраняется для ранее выпущенных версий Data ONTAP, то есть для линейки 7.3.х, и для v8 вплоть до версии 8.0.3 (и далее, если линейка 8.0.х будет продолжена).
2. Ситуация связана с некими сложностями на системном уровне. Дабы не задерживать выпуск 8.1, было решено подготовить фиксы для этой проблемы к следующей версии, 8.1.1, которая запланирована к выпуску в начале лета.
3. В версии 8.1.1 вновь ожидается поддержка Flash Cache для 3210 в объеме 256GB на контроллер (полный объем одной платы на 256GB), и для 3140 – в половинном объеме от объема установленной платы 256GB (доступный объем для Flash Cache 256GB для 3140 будет виден размером 128GB).
4. Flash Cache для FAS/V3210 или FAS/V3140 более недоступен к заказу, соответствующая конфигурация недоступна в конфигураторе с декабря 2011 года, вне зависимости от версии OS.
5. Установка Flash Cache на купленные после этой даты FAS/V3210 или FAS/V3140 не разрешена и не поддерживается, вне зависимости от использованной версии DOT.
6. Версия 8.2, и далее, также не будет поддерживать Flash Cache на системах FAS/V3210 и FAS/V3140.

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

UPD: Я говорю тут ТОЛЬКО о поддержке Flash Cache на 3210 и 3140, на всех остальных системах 3200/6200, а также 3100, Flash Cache по прежнему ПОДДЕРЖИВАЕТСЯ и работает как и раньше.

В качестве варианта замены стоит обдумать вариант с Hybrid Aggregate (использование SSD в составе обычного aggregate из HDD), который появится начиная с 8.1.1, и о котором подробнее позже.

Нам пишут наши читатели:

Оригнал здесь, перепечатывается оттуда по согласию с автором: http://ua9uqb.livejournal.com/79872.html

Не так давно довелось мне протестировать две системы хранения данных, делюсь результатами. В тесте принимали участие системы начального уровня NetApp FAS2240 и Hitachi AMS2100.
Надо понимать, что системы эти сравнимы довольно условно, так как AMS - обычное, бедное по функционалу блочное хранилище, в отличии от сильно мозговитого, "всё-всё умеющего" NetApp-а. Конфигурации системы, методики тестирования, и прочие тюнинги, были согласованны со специалистами вендоров.

Немного подробностей по методике:
1. Тестирование проводилось программой IOMeter версии 2006.07.27 для Windows.

2. Подключение СХД Hitachi AMS2100 производится посредством FC4G, протокол FC
Cостав LUN и томов СХД
Raid10 8 x 450gb 15k 3.5’ Usable: 1.5Tb Lun: 700Gb
Raid6 8+2 450gb 15k 3.5’ Usable: 3.1Tb Lun: 700Gb

3. Подключение СХД NetApp FAS2240 производится посредством 10Ge, протокол iscsi
Состав LUN и томов СХД
RaidDP 9+2 x 600gb 10k 2.5’ Usable: 4.33Tb Lun: 700Gb

4. Тесты проводится в режиме файловой системы NTFS 4к, выравнивание партишина 64к;

5. Настройки программы IOMeter:
• Worker’s – 4
• Target – 16 (в каждом из Worker’s)
• Disk Size – 200000000 (100Gb)
• Ramp Up Time – 600 сек
• Run Time – 30 мин

6. Фиксация результатов каждого теста для IOMeter длиться 30 минут начиная с 10-й и заканчивая 40-й минутой теста;

7. Профили нагрузок(название профилей условное), используемые для тестирования IOMeter следующие: 
Нагрузка характерная для приложений ORACLE 
• размер блока 8КБ;
• соотношение количества операций чтения/запись 30/70;
• характер нагрузки – 100% случайный доступ;

Нагрузка характерная для VMware:
• размер блока 4КБ;
• соотношение количества операций чтения/запись 40/60;
• характер нагрузки – 45% линейный и 55% случайный доступ;

Нагрузка характерная для операций Backup:
• размер блока 64КБ;
• 100% последовательное чтение;

Итог:

Табличка довольно прозрачная, поэтому никаких выводов делать не буду.
NetApp FAS2240(в центре, где куча вертикальных планочек, и жёлтая наклейка сверху):

Hitachi AMS2100

PS. Дополнительно проводилось тестирование программой IOZone, порядок цифр примерно тот же, если будут интересующиеся, выложу результаты.

PPS. Пост навеян коментом френдессы balorus к посту про сервер Sun T4-4 :-)

PPPS. Мой выбор был бы NetApp, если бы Хитача в те же деньги не уложила сильно больше шпинделей. А так же не ещё один сильно политический нюанс, который очень сложно перебить даже теми волшебными, и крайне необходимыми нам штуками, которые NetApp умеет делать очень хорошо, а AMS не умеет в принципе.

В воскресенье, 22 апреля, в истории NetApp случился юбилей – ровно 20 лет назад она стала компанией, официально зарегистрировавшись под названием Network Appliance Inc., в штате Калифорния, США. Хотя как концепция она возникла 2 декабря 1991 года, что было, так сказать, “зачатием”, но официальной датой “рождения” принято считать именно 22 апреля.

Некоторые интересные факты из жизни компании:

• Название 1-800-SERVERS одно время всерьез рассматривалось в качестве имени компании
• Первый продукт компании, устройство FAServer400, имел всего 30 команд и 70-страничный мануал. Он был построен на базе процессора i486/50MHz и имел максимальную raw-емкость 14GB.
• Он продавался по цене 12.000$ реселлерам, и имел листпрайс для конечных пользователей в 16.000$
• Все трое основателей компании – Дэвид Хитц, Майкл Малколм и Джеймс Лау работали в компании Auspex Systems, одной из первых начавшей продавать Enterprise NAS. Компания обанкротилась и закрылась в 2003 году, а ее патентный пул был выкуплен NetApp.
• Двое из троих основателей компании, Хитц и Лау, до сих пор работают в ней. Майкл Малколм, сыгравший большую роль в становлении компании и занимавший пост ее CEO, был вынужден покинуть компанию в ее ранние годы, в результате конфликта с советом директоров, и с тех пор занимался несколькими различными проектами в области компьютерного “железа” в компаниях в Кремниевой Долине. Подробно эта история рассказывается в книге “How to Castrate a Bull: Unexpected Lessons on Risk, Growth, and Success in Business"

Интересный источник о первых годах компании также документы: Establishing Network Appliance и Oral History of Dave Hitz.

В практике построения высокодоступных систем, прежде всего IT, существует понятие “единой точки отказа” (SPOF, Single Point Of Failure). Любая система высокой доступности данных стремится не иметь в своей архитектуре узла, линии связи или объекта, отказ которого может вывести из строя всю систему, или вызвать недоступность данных.

Все это так. Однако я обратил внимание, что в последнее время, в особенности в IT-шной среде возникло своеобразное “фетиширование” вот этого вот “отсутствия единой точки отказа”. Широко распространилось мнение, что “отсутствие единой точки отказа” это синоним “хорошо” и “система правильная”, а ее присутствие – “плохо” и “система неправильная”. И на этом исследование вопроса архитектурной правильности заканчивается. Однако, как и в любом другом деле, суть, на самом деле, лежит несколько глубже.

Дело в том, что “отсутствие единой точки отказа” это “инструмент” для достижения высокой доступности, но не “цель”. “No SPOF” это одно из средств достижения доступности, но не сама доступность как таковая, средство, одно из, а не цель, часто необходимое, но не достаточное условие.

Что же, в таком случае, на самом деле определяет годность решения?

Мне представляется, что это удовлетворение требованиям по RPO/RTO для данной конкретной бизнес-задачи.

Термины RPO/RTO хорошо известны специалистам в области защиты данных и резервного копирования. RPO, Return Point Objective – это “точка доступности данных”, в случае их потери. RTO, Return Time Objective – это время, которое неоьходимо системе для восстановления своей работы, и возобновления обслуживания.

Например, если вы делаете резервное копирование вашей базы данных раз в сутки по вечерам, после окончания рабочего дня, в 21:00, то RPO для вашей системы будет 21:00 вечера предыдущего дня, то есть момент начала создания резервной копии.

Допустим, вы потеряли данные, восстановили их из бэкапа по состоянию на 21 час прошлого дня. Восстановление базы заняло 40 минут. Если у вас работает база данных, то вам еще надо актуализировать ее состояние из archive logs, накатив изменения, записанные с 21:00 по текущее время. Допустим, это заняло 15 минут. Итого, RTO, в вашем случае – 55 минут.

Плохо это или хорошо? Невозможно ответить с точки зрения IT. Ответ должен дать бизнес, которому вы служите. Для какой-то задачи даже 10 минут простоя это много. Какая-то вполне готова подождать пару часов, а какие-то задачи вполне могут и сутки постоять, ничего страшного не случится. Падение биржи NYSE может быть чревато паникой в масштабах глобальной экономики. Падение сети обслуживания банкоматов крупного банка, который за 10 минут периода простоя мог бы обработать десятки тысяч обращений “физиков”, это еще не паника, но все еще очень неприятно. А хостинг домашних страничек вполне может и сутки полежать с сообщением “Извините, ведутся работы”, в лучшем случае выплатив клиентам неустойку за сутки простоя.

Разумеется, бизнес будет требовать нулевого RPO/RTO, это всегда так, они всегда это требуют. :) Однако следует помнить, что все стоит денег, и каждое улучшение ситуации с временем недоступности стоит денег, причем часто растет по экспоненте, каждое следующее улучшение этих параметров обойдется бизнесу все дороже и дороже.

Поэтому, как правило, бизнес и IT обычно приходят к некоему компромиссу. Компромисс этот, как правило, сегментирован по задачам. Но в конечном счете бизнес и IT, совместно вырабатывают какие-то требования по RPO/RTO.

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

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

Может ли быть хорошей, то есть удовлетворять требованиям бизнеса по RPO/RTO, система с наличием “единой точки отказа”? Да запросто. Если период восстановления работоспособности системы укладывается в заданные рамки – да пусть сколько угодно там будет точек отказа. В особенности, если ликвидация в решении всех “единых точек отказа” экономически нецелесообразна, потому что чрезмерно дорога для решаемой бизнесом задачи.

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

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

А не просто фетишировать на один из множества инструментов для достижения этой цели.

Некоторое время назад по IT-новостям прокатилось сообщение что “Система хранения Oracle 7320 победила в тестах NetApp FAS3270!! адинадин”. На прошлой неделе у меня дошли руки посмотреть все же что там, как, кто, и кого победил. О результатах рассказываю.

Тема “тестирований производительности” (кавычки мои, romx) есть любимая тема любого сисадмина.

Допустим, вы читаете в новостях сообщение, что “Мотоцикл Honda CBR150 обошел на стометровке с места болид Formula1 Ferrari!”. “Ну, круто” – подумаете вы, “но кому интересно соревнование с формульным болидом на стометровке с места? Они бы еще соревновались по параметру “экономия бензина” с велосипедом!” А вот нет, оказывается, прекрасная новость и информационный повод проспамить прессрелизом IT-издания.

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

Но, для начала, несколько вводных слов.

Тестирование – тема очень непростая. Очень важный аспект в любом бенчмарке это создание повторяемой среды, отражающей реальные условия использования тестируемого предмета. Результаты процесса “копирования ISO в тотал коммандере”  совершенно неприменимы для оценки быстродействия системы хранения на задаче OLTP database, а данные чисто “синтетического” теста могут не отражать адекватно ваши реальные рабочие результаты, на вашей реальной рабочей задаче, в жизни.

Но если в том что касается бенчмарка, то есть создания повторяемой среды тестирования идентичной для всех тестирующихся систем, можно положиться на авторитет общепризнанных тестов, каковыми на сегодня являются, например SPECsfs2008 для файловых протоколов (NFS и CIFS), и SPC-1 для блочных протоколов (FC и iSCSI), то вот в подготовке тестируемой системы есть некоторая свобода, которой иногда (довольно часто, к сожалению) пользуются некоторые производители с целью создать “систему хранения”, единственная цель которой – победа в тестировании. В англоязычном сегменте такое называется lab queen, по-русски я слышал название “звездолет”.

Вариантов как построить звездолет есть масса. Например можно взять хай-энд систему и набить ее SSD, получив систему за шесть миллионов долларов на 19TB usable . Можно поставить вместе четыре стораджа, и в результатах тупо просуммировать показанные ими по отдельности результаты. Можно, наконец, тестировать систему на голых дисках без RAID или на RAID-0. Использовать множество дисков малого объема. Разбить пространство тестирование на большое количество мелких разделов, снижая “разбег” random access seek, и так далее. Полученные таким образом результаты окажутся неприменимыми в реальной жизни и в реальной эксплуатации того, что вы можете купить, однако очень эффектно смотрятся в пресс-релизах об очередной победе.

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

А теперь перейдем собственно к теме. Что же скрывает за собой барабанная дробь прессрелиза?

Согласно требованиям проведения тестирования SPECsfs2008, протестированная конфгурация должна быть хорошо и детально документирована и описана. Эти данные доступны на сайте SPEC.org всем желающим. Пожелаем и мы проверить, какую же в точности конфигурацию тестировали в Oracle.

Вот как описывает протестированную конфигурацию сайт SPEC.org:
http://www.spec.org/sfs2008/results/res2012q1/sfs2008-20120206-00207.html

Система Oracle Sun ZFS storage 7320

136 дисков SAS 15K на 300GB в 6 дисковых полках, обшим usable space емкостью 37,1TB и общей экспортируемой емкостью в 36,96TB были поделены на 32 файловые системы, по 16 на каждый из двух контроллеров (каждая экспортируемая FS имела размер примерно 1,1TB), доступ к которым осуществлялся с трех loadgenerator Sun Fire X4270 M2, подключенных по 10G Ethernet.

Также тестированный сторадж оснащен 8 дисками SSD по 512GB каждый, для кэширования чтения, (так называемый L2ARC), общей емкостью 4TB, пополам на каждом из двух контроллеров, и 8 дисками SSD 73GB в качестве кэша записи (ZIL), суммарно 584GB, без RAID в обоих случаях. Кроме этого, два контроллера системы хранения имели RAM емкостью 288GB (ARC, по 144GB на контроллер), что дает 4968GB суммарной емкости кэша (SSD и RAM).

Суммарная, участвующая в тестировании емкость (fileset) составила 15587,3 GB, то есть емкость кэша составила примерно треть от используемого файлсета.

Далее цитата:
The storage configuration consists of 6 shelves, 4 with 24 disk drives, 2 with 20 disk drives and 4 write flash devices. Each controller head has 4 read flash accelerators. Each controller is configured to use 68 disk drives, 4 write flash accelerator devices and 4 read flash accelerator devices. The controller is then set up with pools by dividing the disk drives, write flash accelerators and read flash accelerators into 4 pools. Each of the controller’s pools is configured with 17 disk drives, 1 write flash accelerator and 1 read flash accelerator. The pools are then set up to stripe the data (RAID0) across all 17 drives. The write flash accelerator in each pool is used for the ZFS Intent Log (ZIL) and the read flash accelerator is used as a level 2 cache (L2ARC) for the pool. All pools are configured with 4 ZFS filesystems each.

“Конфигурация системы хранения содержала 6 дисковых полок, 4 полки на 24 диска и 2 полки на 20 дисков, плюс 4 SSD-кэша на запись. Каждый контроллер использовал 4 SSD-диска в качестве кэша чтения. Каждый контроллер был сконфигурирован на работу с 68 дисками, 4 SSD кэша на запись и 4 SSD кэша на чтение. Каждый контроллер использовал пулы дисков, между которыми были разделены диски, по одному SSD-кэшу на чтение и на запись на каждый пул. Пулы были настроены таким образом, чтобы данные страйпились на все входящие в него 17 дисков (RAID-0). Write flash accelerator (SSD емкостью 73GB) в каждом пуле использовался в качестве ZFS Intent Log (ZIL), а read flash accelerator (SSD емкостью 512GB) как level 2 cache (L2ARC). На каждом из пулов было создано по 4 файловые системы.”

Как мы видим, несмотря на использование ZFS, для организации дисков в пулах был выбран простой stripe, без RAID (фактически RAID-0!). Кроме того стоит отметить, что общая тестируемая емкость дисков была поделена на сравнительно маленькие файловые системы, всего около 1,1TB каждая, числом 32 (зачем такой финт – см. выше).

Очевидно, что такая конфигурация довольно далека от реально эксплуатируемой на такого рода системах. Кто в здравом уме будет класть данные на 17-дисковую группу в RAID-0?! А как планируется использовать пространство, разбитое на 32 отдельных FS для хранения, например, больших объемов? А каковы 512GB write cache на SSD, без малейшей защиты от сбоя?

Кстати интересный вопрос: Если ZFS так хороша и производительна, и так хорош RAID-Z и RAID-Z2, то почему его не использует при выкатке систем на тестирование даже сам Oracle? Что за засада с ним, господа из Oracle? Вот NetApp показывает свой результат на реальных, эксплуатируемых конфигурациях, с RAID-DP и даже со включенным thin provisioning, а в результатах Oracle в SFS2008 – Stripe (RAID-0), а в SPC-1 – mirror (RAID-1). Почему не RAID-Z(2)? Почему бы не показать результаты с ними? Может быть они совсем не так хороши?

Для сравнения давайте посмотрим на упомянутую конфигурацию NetApp FAS3270, которую “побеждали”.

FAS3270 в конфигурации с SAS-дисками и без Flash Cache, поставки таких систем начались в ноябре 2010 года, около полутора лет назад.

360 дисков 450GB 15K, общая usable емкость дисков 125,7TB (в RAID-DP), экспортированная емкость равна 110,08TB (88% от usable) в 2 файловых системах (по одной на контроллер). Диски организованы в два aggregate из 11 RAID-групп 14d+2p в RAID-DP (RAID-6),  тестовая нагрузка генерировалась с помощью 12 Loadgenerators типа IBM 3650M2.

Exported capacity равна 110TB, файлсет, на котором проводилос тестирование - 11749.7 GB  Размер RAM, используемого как кэш на системе хранения, равен 36GB, что составляет 1/326 от fileset.

SPECsfs2008_nfs.v3=101183 Ops/Sec (Overall Response Time = 1.66 msec)

У “победившей” его полтора года спустя системы с RAID-0, с кэшами разного уровня, составляющими суммарно до трети тестируемого файлсета, включая около 4,5TB на SSD, с в шесть раз большим RAM контроллера и с тестируемым пространством побитым на 32 кусочка-FS:

SPECsfs2008_nfs.v3=134140 Ops/Sec (Overall Response Time = 1.51 msec)

На 32,5% больше IOPS и на 8,5% лучше latency.

Ребята из Oracle, что называется "при всем уважени”, но вы правда считаете, что таким результатом, при описанном выше устройстве тестируемой системы, и способе проведения тестирования, это победа и этим стоит гордиться? Нет, ну правда?

Оно дешевле стоит? Ну, согласен, дешевле. Мотоцикл порвал Феррари на стометровке. Но кто гоняет на Феррари на стометровке? Какой смысл сравнивать по цене лоу-мидрендж (“Entry-level cluster option for high availability”, цитата из техспеков на 7320), ZFS-сервер, со стораджем, в максимуме тянущем в 6,6 раз большую чем 7320 емкость, используещем RAID-6, и демонстрируемом даже близко не на пределе своих возможностей по тестируемой емкости?

Впрочем, несколько слов и о цене. В тесте SPECsfs2008 условия тестирования не требуют называния цены тестируемой системы, поэтому спекуляции о цене делаются на довольно мутном базисе “нашли гуглом какой-то прайс нетаппа, где-то в интернете, и прикинули”. Однако в случае SPC-1 требуется указывать такой параметр, как IOPS/$ и цена всей тестируемой конфигурации называется. Тут, однако, тоже есть поле для… ну-у… скажем так, для “оптимизации” :). Например на тестировании SPC-1 NetApp называет цену листпрайса (см стр. 18 отчета), а Oracle, ничуть не смущаясь приводит цену с “вшитой” 30% скидкой по всем позициям (см. стр. 14 отчета) и именно ее берет в расчете IOPS/$ в SPC-1.

Так что, повторю сказанное мной в начале поста: Читайте мелкий шрифт, не ленитесь разбираться в конфигурациях и их деталях, и оставьте пресс-релизы (и выводы только на их основании) для С*O-менеджеров. :)

Если вы внимательно читаете директорию блоггеров NetApp на их сайте, то, скорее сего, уже знакомы с Дейвом Хитцем, “первым блоггером NetApp”, сооснователем и вице-президентом компании, много лет (пусть и не слишком часто) пишущим свою “колонку”-блог. Дейв также автор интереснейшей книги “How to Castrate a Bull: Unexpected Lessons on Risk, Growth, and Success in Business”, вышедшей несколько лет назад, в которой он рассказывает о ранних годах и развитии своей компании, и тех уроках, которые он получил за эти годы от жизни, бизнеса и других людей. Я также изредка упоминаю его и цитирую некоторые его записи в этом блоге. А сегодня я вспомнил и нашел его, на мой взгляд, очень важную заметку, с, на первый взгляд, шокирующим названием.

Покупатели - лжецы.

Источник:
<https://communities.netapp.com/community/netapp-blogs/dave/blog/2006/09/22/buyers-are-liars>

Потребитель всегда прав, конечно, но делать так, как хотят пользователи, с этим всегда проблемы, потому что они лгут. Я впервые услышал фразу"покупатели - лжецы" от раздраженного продавца. Многие продавцы знают покупателей, которые говорят: "Когда вы сделаете X, то я определенно куплю!", но когда сделан этот X - клиент не покупает.

Наш CTO, Steve Kleiman, привел мне отличный "нетехнический" пример такой ситуации. Он искал дом, и он говорил риэлтерам и агентам, что он хочет дом без лужайки и без высаженных вокруг растений, потому что он ненавидит возню со всем этим. Агенты показывали ему один за другим дома с замощенным кирпичом или залитым цементом дворами, но ему казалось, что все они какие-то холодные и стерильные. Наконец одна женщина-агент показала ему дом, полностью нарушающий все его требования до сих пор, трава и садовые растения повсюду. И когда он недоуменно спросил об этом, она сказала: "Не беспокойтесь, я найду вам садовника" . Нетрудно догадаться, что именно этот дом он в результате и купил.

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

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

Как быть в ситуации, когда у нас с одной стороны "Покупатель всегда прав", а с другой в то же самое время - "Покупатели - лжецы"? Мой компромисс тут в том, что они правы в части своих проблем, но я не считаю, что их вариант решения, предложенный нам, есть лучшее возможное решение данной проблемы.

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

Мне приходится сталкиваться с подобной ситуацией очень и очень часто, когда я слушаю просьбы, а, зачастую, и требования пользователей и потенциальных клиентов NetApp.

Диапазон требований самый разный, от: "сделайте нам Infiniband до хостов" и "сделайте интерфейс FC 8Gb на системе entry-level", до: "продавайте SSD поштучно" и "выложите в интернет полный прайс, чтобы мы могли сами конфигурировать себе системы", завершая все это магической, на их взгляд, формулой: "И вот тогда мы точно купим".

Увы. И вот в заметке Дейва выше хорошо показано почему "увы", и почему NetApp не делает что-то немедленно, по требованиям пользователей, несмотря на то, что "покупатель, безусловно, всегда прав".

А тем временем, в выходные, выкатилась, наконец, Phase 2 обновления самого важного для пользователя сайта NetApp – NetApp Support Site (http://support.netapp.com/), бывшего “NetApp on Web”, NOW (http://now.netapp.com/).

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

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

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

На днях увидел в блогах, которые я читаю, интересную статью специалиста Microsoft, о использовании SMI-S провайдера. SMI-S поддерживается системами NetApp FAS уже несколько лет, и я уже очень давно собираюсь написать на эту тему пост. Но как-то он все отодвигается и отодвигается более актуальными темами, я просто приведу вам “для затравки” цитату из той статьи, и предлагаю идти читать остальное уже там:

Storage Management Initiative – Specification или SMI-S, это стандарт управления дисковыми хранилищами, разрабатываемый с 2002 года Storage Networking Industry Association. SMI-S является ANSI и ISO стандартом. Актуальная версия SMI-S 1.5. Более 800 различных аппаратных и 75 программных решений поддерживают данный стандарт. Основная идея стандарта – унификация управления дисковыми хранилищами через веб-запросы.

System Center Virtual Machine Manager 2012 позволяет подключить SMI-S хранилища, так чтобы администратор имел возможность из консоли VMM получать информацию о LUN, группах RAID, свободном месте на хранилище и так далее.

Подробнее – там:

http://blogs.technet.com/b/vm/archive/2012/02/15/smi_2d00_s-support-in-vmm2012.aspx

Несмотря на то, что в оригинальной статье рассматриваются системы EMC, напомню, что SMI-S для NetApp FAS есть, совместим c VMM2012, поддерживаем в MS и NetApp , и работает. Берут SMI-S provider на NetApp Support, где он доступен бесплатно (нужен логин на NOW).

Вид EMC Clariion CX4 из VMM2012 через SMI-S:

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

Для начала же несколько слов о том, что такое Data ONTAP Cluster-mode, и чем он отличается от привычного Data ONTAP 7-mode в HA-кластере.

Еще в 2003 году NetApp купила стартап Spinnaker, занимавшийся разработками в области кластерных файловых систем и системы Global Namespace, и несколько лет спустя выпустила на рынок специальную OS, под названием Data ONTAP 10. Это была специальная OS для систем NetApp, позволявшая строить многоузловые кластеры хранения данных. К сожалению, она имела множество ограничений, в частности, работала только как NFS-сервер, и не имела множества важных и привычных возможностей “классической” Data ONTAP 7.x, поэтому особой популярности не завоевала, была дорогой, ограниченной, требовавшей значительных специальных знаний для запуска и использования, и, в результате, ее использование было ограничено рынком высокопроизводительных файловых серверов для HPC (High-performance Computing) и систем хранения научной и аудио-видео информации. Общее число клиентов в мире, использовавших Data ONTAP 10, не превышало пары сотен.

Следующим шагом NetApp, стала попытка объединить, “слить” две эти OS в одну. Однако объявленное в 2008 году “слияние” оказалось в значительной степени “фиктивным”, просто из одного дистрибутива OS, получившей название Data ONTAP 8.x стало возможным установить две OS: либо в режиме 7-mode, то есть “классической” Data ONTAP, либо в режиме, получившем название “Cluster-mode”, и явившемся развитием Data ONTAP 10. К сожалению это были, как я сказал выше, просто две OS, ставившихся из одного дистрибутива, и только. В Cluster-mode не появились привычные возможности Data ONTAP Classic, и по-прежнему это были две несовместимые OS, не имевшие возможности миграции данных или взаимодействия, полностью отличавшихся по структурам хранения данных и работе с ними.

Вследствие этого, имеющиеся пара сотен клиентов DOT10 были переведены на 8.x Cluster-mode, а основная масса пользователей систем NetApp по прежнему продолжала пользоваться “7-mode”. Значительным барьером, кроме функциональных ограничений, была и цена, а также сложность реализации.

Однако работы продолжались, и, постепенно, в 8.x Cluster-mode стали появляться привычные для 7-mode возможности, такие как репликация, блочная дедупликация, а также, что более всего важно, работа с блочными протоколами – FC, iSCSI и FCoE. Напомню, что, до версии 8.1, Cluster-mode была чисто “файловым хранилищем”, работающем по протоколам NFS и CIFS, что устраивало не всех.

Тем временем, как NetApp “переваривала” наследство Spinnaker, на рынке стали появляться конкуренты в данной области, так активно стал продаваться (и в итоге продался целиком EMC) продукт компании Isilon, а растущий интерес к “облачным” IT-системам естественным образом стал “локомотивом” развития и “облаков” хранения - многоузловых кластеров.

Итак, начиная с версии Data ONTAP 8.1 версия Cluster-mode стала уметь работать с блочными SAN-протоколами, стала уметь асинхронную репликацию и снэпшоты, привычные для Data ONTAP Classic, дедупликацию и компрессию, наконец, были снижены цены, и использование Cluster-mode стало несколько более доступным для пользователей.

Настала пора и в этом блоге поподробнее поговорить о том, что же такое Cluster-mode, как его можно использовать, и чем он может вам пригодиться. В этом году, я надеюсь, я буду говорить о Data ONTAP 8.x Cluster-mode куда чаще. В ближайшие несколько постов я намерен рассказать подробнее о том, что сегодня представляет собой Cluster-mode, и как это выглядит на практике.

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

Помогает взглянуть с большим интересом на понятие “эффективность” и на его важность в практической жизни, не так-ли?

Если вы, к примеру, купили сторадж на 20TB raw data за, допустим, 100 тысяч $, и, в результате, используете на нем 12,5% его raw-емкости для хранения данных ваших приложений, это значит, что вы заплатили сто тысяч долларов за емкость 2,5TB. Жестокая правда.

PS. Обратите внимание, что я снова ни разу не сказал в этом посте слова “NetApp” ;)