about NetApp

На днях на глаза попался очередной quarterly отчет по market share и изменениям долей в сегменте Западной Европы, наверное наиболее интересного и влиятельного в России участка мировых рынков. В виде публичного “пересказа” его результаты можно посмотреть тут: http://www.storagenewsletter.com/news/marketreport/western-european-external-disk-idc-1q12

Первая “шестерка” брендов, с изменениями Year-to-Year и Quarter-to-Quarter в данном отчете за первый квартал 2012 по Западной Европе выглядит сейчас так:

Следует также отметить, что за прошедший год рынок Enterprise External Storage Systems (EESS) в целом практически не рос, в отчете показан рост всего в 1,4% за год, с учетом курсовых колебаний (3,2% quarterly). На фоне такой общей неактивной картины (связанной отчасти с финансовым кризисом Европы, отчасти с повышением цен на HDD) очень эффектен рост NetApp более чем на 12%. ??, конечно, ужасно выглядит катастрофическое падение IBM. Ну, IBM не умрет, понятное дело, они не только стораджами живы, а вот для NetApp, у которого продажа стораджей есть основной бизнес, это очень хорошие темпы, просто выдающиеся. ??, в общем, в таблице хорошо видно, за счет кого именно этот рост стал возможен.

На днях, NetApp официально опубликовал результаты бенчмарка SPC-1, главного бенчмарка по демонстрации производительности на блочном (SAN) доступе.

Как вы знаете, в Data ONTAP 8.1.x Cluster-mode появилась новая возможность – кроме доступа к системе хранения как к NAS, по протоколу NFS или CIFS/SMB, теперь возможна и работа с блочным стораджем, то есть как SAN-утройства. В версии 8.1 кластер SAN был ограничен 4 узлами (2 HA-парами), но, как я и предполагал, этот размер будет постепенно увеличиваться, и вот уже в 8.1.1 он был увеличен до 6 узлов (нод) в кластере. Напомню, что для NAS (NFS) максмальный размер кластера составляет 24 узла.

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

?? если для NAS NetApp достаточно давно показывал свои результаты в бенчмарке SPEC sfs2008, в том числе и для Cluster-mode, то для блочных протоколов, таких как FC или iSCSI, или FCoE, таких данных не было. А отсутствие результатов бенчмарков всегда тревожит, как же оно там, на самом деле, не на бумаге маркетинговых буклетов?

Наконец, на прошлой неделе, NetApp показал свои (почти)топовые результаты, для 6-узлового кластера, с использованием контроллеров FAS6240, под управлением Data ONTAP 8.1.1.

??нтересно, что бенчмарк SPC-1 требует публиковать цену тестируемой конфигурации (в терминах SPC-1 – TSC, Tested Storage Configuration), и, следовательно, вычислять параметр $/IOPS, “цену транзакции”. Но тут следует обратить внимание, что не запрещается искусственно занижать “листовую” цену продукта (например указав в цене уже некий “дисконт” относительно листпрайса), получая более “выгодно выглядящие” $/IOPS. Показатель $/IOPS приводится вместе с показателем IOPS, достигнутым на тестировании, даже в короткой версии результата, так называемом executive summary, в то время, как за полной конфигурацией тестируемой системы и за опубликованными на нее ценами, надо идти в full disclosure report.

NetApp на тестировании SPC-1 всегда приводит в качестве цены на систему полный, официальный листпрайс на момент тестирования, без дисконтов, и, что интересно, со включенным SupportEdge 24×7х4h на 3 года. Специально хочу напомнить, что листпрайс в реальной жизни не является реальной ценой продажи, так как в подавляющем числе случаев при продаже для конечного пользователя из цены вычитаются разнообразные, порой значительные, в десятки процентов, дисконты (скидки).

Поэтому если вы хотите просто тупо сравнить циферку $/IOPS системы одного вендора, с опубликованным $/IOPS у NetApp, обязательно посмотрите, исходя из какой цены было это значение вычислено, и, соответствующим образом, скорректируйте результаты.

18 июня 2012 года NetApp опубликовал официальный отчет о тестировании 6-узлового кластера в SAN, на протоколе доступа FC 8Gb/s и тестируемом объеме ~72TB (~193TB raw, 36% от raw), 432 диска SAS 450GB в 18 полках, показав результат 250 039,67 IOPS, и, при листпрайсе $1 672 602, показатель $/IOPS составил 6,69$/IOPS SPC-1.

За подробностями – в executive summary и в full disclosure report.

Третья часть серии постов в блоге Wahl Network, посвященных вариантам использования NFS в Vmware и организаци балансировки трафика по нескольким физическим путям.

NFS в vSphere – погружение в детали: часть 3, VMware Load Balancing Teaming

В предшествующих трех постах этой серии мы рассмотрели основные ошибки и заблуждения, связанные с использованием NFS в VMware, а также рассмотрели два варианта построения сети хранерия с использованием NFS - с единой подсетью, и с множественными подсетями. Если вы не слишком хорошо знакомы с тем, как NFS работает в vSphere, рекомендую вам начать с чтения этих статей. Выводы, к которым мы пришли, состоят в том, что NFS в vSphere требует использовать множественные подсети, чтобы использовать множественные физические линки к системе хранения, за исключением, когда EtherChannel правильно настроен правильно используется на одной подсети. Однако, даже при использовании static EtherChannel, множественные таргеты на стороне стораджа, и правильно спланированные least significant bits в адресе необходимы для использования более одного физического пути к системе хранения.

Continue reading ‘VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming’ »

Я попросил одного пользователя NetApp, расположенного вне Москвы (с Москвой как раз все просто, и не слишком интересно  да?) поделиться информацией об оперативности работы службы сервиса NetApp. Как вы помните, стандартный сервисный уровень по доставке вышедших из строя запчастей у NetApp, это Next Business Day (NBD), что в условиях страны, растянутой на 9 часовых поясов и с отдаленными точками, куда “только вертолетом можно долететь”, представляет собой известный челлендж для любого сервиса.

Городок с населением 250 000 чел, 660 км Москвы, пользователь - крупное промпредприятие.

Вылетало за время эксплуатации системы три диска.

Далее выдержки из логов кейсовой системы NetApp по этому стораджу (форматирование потерялось, но не суть), я выделил даты событий, дата и время даны по калифорнийскому (PST) времени, в котором работает саппорт NetApp. Первая – регистрация события по отчету autosupport, второе – реакция человека в саппорте, командующего складу на отгрузку. Далее – когда запчасть доставлена на сайт фактически. Доставка производится со склада в Москве (и Петербурге).

1) Case #: 2xxxx Status:
Closed
Priority:
Occasional disruption or problem (P3)
Symptom:
DSKFLT:Disk /aggrsata/plex0/rg0/0a.19 Shelf 1 Bay 3 [NETAPP X269_SMOOS01TSSX NA01] S/N [9QJ7W7V4]
System Name: NETAPP2040-2 Bug #: Reference #:
Serial Number: 200000xxxxx Part Number: FAS2040-R5 System ID: 135xxxx OS Version: 8.0.1RC1 7-MODE AutoSupport: ON
Case text : Customer Input - 03/10/2012 12:52:00 PST
Visibility  : PUBLIC     Note :
I need help. My disk drive has failed. Help me. Send me new disk.
RMA  DSKFLT:Disk /aggrsata/plex0/rg0/0a.19 Sh - 03/10/2012 18:27:30 PST : WF_BATCH   Status: Delivered    Assigned To:  Ahamed Hussain
Update : ‘Return Order from PR ‘80009xxxx - 03/10/2012 22:15:59 PST : TPL_APL   Status: Closed    Assigned To:  Ahamed Hussain
1. We will ship one
SP-269A-R5
to replace the failed part. This part w ill be shipped to the following address and contact:

12 марта – диск у нас

2) Case #: 20027xxxx Status:
Closed
Priority:
Occasional disruption or problem (P3)
Symptom:
DSKFLT:Disk /aggrsas2/plex0/rg0/0d.01.10 Shelf 1 Bay 10 [NETAPP X410_S15K7288A15 NA00] S/N [3SJ0VS340000xxxxx]
System Name: NETAPP2040-2 Bug #: Reference #:
Serial Number: 200000xxxx Part Number: FAS2040-R5 System ID: 135xxx OS Version: 8.0.1RC1 7-MODE AutoSupport: ON
Update : Case text : Symptom - 12/24/2011 18:23:47 PST : ASUP_PP   Status: Assigned To:  RAI Ranjit Visibility  : PUBLIC     Note :
DSKFLT:Disk /aggrsas2/plex0/rg0/0d.01.10 Shelf 1 Bay 10 [NETAPP X410_S15K7288A15 NA00] S/N [3SJ0VS3400009034xxxx]
Update : ‘Return Order from PR ‘8000869583 - 12/26/2011 00:50:51 PST : TPL_APL   Status: Closed    Assigned To:  Kabra Mitesh Visibility  : PUBLIC

28 декабря – диск у нас.

3) Case #: 200275xxxx Status:
Closed
Priority:
Occasional disruption or problem (P3)
Symptom:
DSKFLT:File system Disk /aggrsata/plex0/rg0/0a.24 Shelf 1 Bay 8 [NETAPP X269_SMOOS01TSSX NA01] S/N [9QJ7WHD6] failed.
System Name: NETAPP2040-2 Bug #: Reference #:
Serial Number: 20000xxxx Part Number: FAS2040-R5 System ID: 13509xxxxOS Version: 8.0.1RC1 7-MODE AutoSupport: ON
Update : Case text : Symptom - 12/17/2011 14:33:21 PST : ASUP_PP   Status: Assigned To:  Dey Tanmoy Visibility  : PUBLIC     Note :
DSKFLT:File system Disk /aggrsata/plex0/rg0/0a.24 Shelf 1 Bay 8 [NETAPP X269_SMOOS01TSSX NA01xxx] S/N [9QJ7WHD6xxx] failed.
Update : ‘Return Order from PR ‘8000865813 - 12/19/2011 01:36:21 PST : TPL_APL   Status: Closed    Assigned To:  Rao Sandeep Visibility  : PUBLIC

21 декабря – диск у нас.

Отмечу –что все три диска вылетали на выходных, а NBD начинался в понедельник.

С батарейкой (питание для NVMEM, другой кейс. прим. romx) все печальнее – пришлось 2 дня сильно пинать саппорт (пороли чушь) через русский netapp, огромное спасибо Роману Ройфману и Денису Атаманенко за оперативную помощь и участие - короче, супер саппорт!

Вот такие результаты, по моему вполне неплохие, и приятный отзыв.

Отдельно хочу объяснить лишний раз то, как исчисляется в сервисе Next Business Day.

Во-первых, как я уже сказал выше, в стране российских размеров любая ограниченная временем доставка вынуждена учитывать самолетные расписания. Поэтому Next Business Day трактуется как Best Available Flight (ближайший самолет), это нормально, у UPS нет штата гарипоттеров на метлах, они вынуждены работать с рейсами гражданской авиации. Если на Краснодар есть 10 рейсов в день, а на, допустим, Салехард, только один рейс “Когалымавиа” в два дня, то это также накладывает свои возможности на сроки доставки, ничего тут не поделать. Смотрим реалистично на окружающий мир, да?

Во-вторых о том, когда начинается и когда заканчивается Business Day. Бизнес день начинается утром, в 8 утра, и заканчивается в 5 вечера. Если гарантийный эвент происходит после окончания рабочего дня (или не успевает  попасть в отгрузку в российский UPS до конца этого рабочего дня) , то он обрабатываетя, как произошедший в рабочее время следующего рабочего дня. Если поломка происходит в выходные, или, допустим, в 8 вечера в пятницу, то бизнес-день, которым будет начата реакция на данное событие, будет понедельник. Что, собственно, вытекает из названия Business Day. Соответственно Next Business Day для события, случившегося вечером в пятницу, будет вторник.

Также следует учитывать разницу в часовых поясах, время в кейсах саппорта NetApp дается по Стандартному Тихоокеанскому американскому времени (PST, GMT-8:00), так как головной офис расположен в Калифорнии. Однако поддержка для EMEA это Бангалор, ??ндия (GMT+5:30). Это смещение таже следует учитывать при исчислении Business Day, потому что если у нас рабочий день еще в разгаре, в Калифорнии (или ??ндии) он мог еще не начаться или уже закончиться, и они прочитают ваш кейс (и отдадут команду на отгрузку со склада) только когда наступит  рабочий день. Может повезти, но общее правило таково.

Если такой режим не устраивает – есть круглосуточный вариант (SupportEdge Standard и Premium, за деньги), но при этом помните, что и вы, в свою очередь, должны иметь круглосуточную службу, например, если запчасть приезжает в 4 утра в субботу, курьера надо встретить и запчасть у него принять, что логично, то есть 24х7 сервис требует такого же участия и вас. Оно логично, как мне кажется. Просто это надо хорошо осознавать заказывая такой уровень поддержки. ??ли же каждый раз договариваться с курьером службы доставки о переносе сроков. ?? нельзя, если у вас по кейсу выставлен priority – high, и индусы работники техподдержки сели решать вашу проблему, сказать им вечером пятницы, “чуваки, давайте, пока, у меня, там пиво, девки, рокенрол сегодня, давайте там, до встречи в понедельник”. В этом случае ваш кейс просто бросят, и вы будете его всю следующую неделю поднимать и требовать к себе внимания. Круглосуточная поддержка она с обеих сторон круглосуточная.

В общем, вот такие вот “вести с мест”. Спасибо пользователю за предоставленные материалы и возможность написать этот пост.

Ранее я уже интересовался темой, и писал аналгичный пост в 2010 году, с другими похожими примерами, и сходными результатами.

Недавняя моя заметка о выходе 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 не делает что-то немедленно, по требованиям пользователей, несмотря на то, что "покупатель, безусловно, всегда прав".