about NetApp

Flash Pool - это способ использовать установленные в систему хранения SSD в качестве кэша для операций записи и чтения. При этом они составляют с обычными жесткими дисками так называемый hybrid aggregate, и активные операции, как записи, так и чтения, могут эффективно кэшироваться на пространстве этих SSD, позволяя использовать все преимущества flash на обычных дисковых системах хранения.
Об этой технологии я писал в блоге не раз, однако за эти несколько лет, что Flash Pool доступен к использованию на системах хранения NetApp, у некоторых потенциальных клиентов NetApp Flash Pool сложилось мнение, что для полноценного, эффективного использования возможностей Flash Pool нужно иметь достаточно мощный контроллер сам по себе, и что широко распространенные и очень популярные контроллеры класса FAS2200 не дают существенной выгоды от использования Flash Pool, просто потому что “силенок у них его раскачать не хватает”.
Для того, чтобы раз и навсегда ответить на этот вопрос, аналитическая компания ESG провела по просьбе NetApp сравнительное тестирование двух систем:

1. FAS2240-2, c 48 2.5″ 900GB 10Krpm дисками SAS, с общей емкостью 42TB raw
2. FAS2240-4, c 32 3.5″ 2TB 7.2Krpm дисками SATA, плюс 4 дисками SSD 200GB, и общей емкостью 64TB raw

В качестве нагрузки были протестированы типовые нагрузки, характерные для:

1. OLTP database (100% random, 66/33 read/write, мелкими блоками, чувствительный к responce time) MS SQL Server 2010.
2. Нагрузка, характерная для Exchange Server (2010).
3. Нагрузка файлового сервера (переменные размеры блоков, большой объем работы с метаданными)

Физический сервер, на котором под VMware vSphere 5.1 были развернуты две тестовые VM (Windows Server 2008R2), и которые были подключены одним каналом 10G Ethernet к системе хранения по протоколам iSCSI и NFS. Все три рабочих нагрузки генерировались с помощью IOmeter на тестовых VM вперемешку, одновременно.

Результат (слева - all-SAS FAS2240-2, справа - FAS2240-4 (SATA +4xSSD):

Резюмируя же “в цифрах”:

Система с Flash Pool вида SATA+SSD, показала существенно лучшую производительность, чем точно такой же контроллер, но работающий с 48 SAS-дисками. Величина выигрыша была различной для разных профилей, но выигрыш был всегда. (максимально - 48% - на OLTP, минимально - 15% - на fileserver). Одновременно с этим на 31% улучшился responce time.
При этом система с Flash Pool имела на 48% больше емкости хранения, и, одновременно, была на 18% дешевле, чем система с SAS-дисками.

Цена за GB и на IOPS улучшилась, соответственно, на 45 и 40 процентов, а общая пропускная способность улучшилась на 34%, причем при использовании более медленных “по природе” дисков SATA.

Как вы видите, даже на таком, сравнительно слабом контроллере, как контроллер самой младшей не сегодня системы хранения NetApp FAS, результат использования Flash Pool является более чем впечатляющим.

Подробно о методике тестирования и деталях можно прочитать тут: http://www.esg-global.com/lab-reports/netapp-fas2200-series-with-flash-pool/

Внутри Data ONTAP зачастую находится много полезных штук, к сожалению, часто малоизвестных “рядовому админу”, особенное если “все и так работает”.
Одна из таких архиполезных для траблшутинга сети штук - встроенный сборщик дампа пакетов на сетевом интерфейсе. Особенно полезно то, что формат собираемого дампа позволяет напрямую открывать его в популярнейшем инструменте анализа дампов - Wireshark.
Если вы настроили CHAP authentification в iSCSI, и что-то пошло не так, или что-то странное творится при доступе к файлам по SMB, то лучший способ - собрать дамп и посмотреть что происходит в сети на стороне стораджа.

Для этого выясним сперва, на каком интерфейсе нас будет интересовать ethernet-трафик.

netapp> ifconfig -a

e0a: flags=0xe48867 mtu 1500
inet 10.10.10.140 netmask 0xffffff00 broadcast 10.10.10.255
ether 00:0c:29:89:3f:3c (auto-1000t-fd-up) flowcontrol full
e0b: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:46 (auto-1000t-fd-up) flowcontrol full
e0c: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:50 (auto-1000t-fd-up) flowcontrol full
e0d: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:5a (auto-1000t-fd-up) flowcontrol full
lo: flags=0×1b48049 mtu 9188
inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1
losk: flags=0×40a400c9 mtu 9188
inet 127.0.20.1 netmask 0xff000000 broadcast 127.0.20.1

Запустим команду pktt, указав ей собирать дамп на заданном интерфейсе, и маркировать файл дампа датой сбора.

netapp> pktt start e0a -d /etc/log
e0a: started packet trace

netapp> pktt status
e0a: Packet tracing enabled; packets truncated at 1514 bytes.
e0a: Trace buffer utilization = 2% of 1048320 bytes, 258 packets
e0a: 0 bytes written to file /etc/log/e0a_20131108_173928.trc
e0a: Currently tracing to file /etc/log/e0a_20131108_173928.trc
e0a: 258 packets seen; 0 packets dropped; 24936 total bytes seen

lo: Packet tracing enabled; packets truncated at 1514 bytes.
lo: Trace buffer utilization = 99% of 130816 bytes, 1011 packets
lo: 1387 packets seen; 0 packets dropped; 160568 total bytes seen

losk: Packet tracing enabled; packets truncated at 1514 bytes.
losk: Trace buffer utilization = 99% of 130816 bytes, 282 packets
losk: 40901 packets seen; 0 packets dropped; 21761277 total bytes seen

Когда нужный интервал сбора пройден, остановим pktt.

netapp> pktt stop e0a
e0a: Tracing stopped and packet trace buffers released.
Fri Nov 8 17:42:25 EST [sim81:cmds.pktt.write.info:info]: pktt: 280 packets seen, 0 dropped, 32046 bytes written to /etc/log/e0a_20131108_173928.trc.

У нас по заданному пути окажется файл с дампом, который мы можем скопировать на машину с Wireshark.

Теперь откроем файл .trc, прямо в Wirrshark, и приступим к знакомому процессу разбора в этом замечательном инструменте.

Я тут уже, было дело, бухтел, что, видимо вследствие того, что у NetApp в компании большой вес имеют “инженеры”, довольно часто в продукт попадают какие-нибудь функциональные, но маловыразительные, или, того хуже, запутывающие термины.
Вот кто знает, почему управление (включение, выключение, и прочая настройка) дедупликацией скрывается за командой консоли asis? Что это за “асис” такой, что он значит, и как связан с дедупликацией?
А вот, оказывается, когда-то, в самом начале, еще, фактически, до релиза, функция дедупликации у NetApp называлась Advanced Single Instance Store, или ASIS (что такое был не-адвансед, а простой single instance store, не помнит уже никто, наверное). Потом аббревиатуру заменили на самоописывающий термин “deduplication”, а команда осталась.

Ранее, осенью, я писал несколько статей на тему, “Что такое Reallocation, как она работает, и как ей пользоваться правильно?”, и, соответственно, в консоли есть команда reallocate.
Но теперь, с 8.2, в Cluster-mode, появилась новая функция, называющаяся очень похоже - relocate. Путаница со всем этим нам, очевидно, еще предстоит. :-/

Relocate - “перемещение” - это новая возможность Cluster-mode, доступная с версии 8.2, которая позволяет не прерывая работы системы, “на ходу”, передать aggregate, то есть, по сути, disk ownership дисков этого аггрегейта, вместе со всеми томами и данными на них, другому контроллеру в той же HA-паре.

В “Семерке” и 7-mode это делается с остановкой работы контроллера, из boot menu, а вот теперь, использующие Cluster-mode, это могут сделать “на ходу”. Ясно, что для Cluster-mode такая возможность куда более важна, так как в кластере задачи “перекинуть данные”, и, например, полностью вывести контроллер из кластера, допустим для его обновления или замены, это достаточно рядовая задача.

Посмотреть, кому и как назначены aggregates можно командой:
storage aggregate show [-node source-node]

node1::> storage aggregate show
Aggregate Size Available Used% State #Vols Nodes RAID Status
——— ——– ——— —– ——- —— —— ———–
aggr_0 239.0GB 11.13GB 95% online 1 node1 raid_dp, normal
aggr_1 239.0GB 11.13GB 95% online 1 node1 raid_dp, normal
aggr_2 239.0GB 11.13GB 95% online 1 node2 raid_dp, normal
aggr_3 239.0GB 11.13GB 95% online 1 node2 raid_dp, normal
aggr_4 239.0GB 238.9GB 0% online 5 node3 raid_dp, normal
aggr_5 239.0GB 239.0GB 0% online 4 node4 raid_dp, normal
6 entries were displayed.


Собственно процесс релокации аггрегейтов запускается командой:
storage aggregate relocation start -aggregate-list aggregate-1, aggregate-2… -node source-node -destination destination-node

node1::> storage aggregate relocation start -aggregate-list aggr_1,
aggr_2 -node node1 -destination node3
Run the storage aggregate relocation show command to check relocation status.
node1::storage aggregate>

А посмотреть как все идет можно командой:
storage aggregate reloaction show [-node ]

node1::> storage aggregate relocation show -node node1
Source Aggregate Destination Relocation Status
—— ———– ————- ————————
node1
aggr_1 node3 In progress, module: wafl
aggr_2 node3 Not attempted yet
2 entries were displayed.
node1::storage aggregate>

Обратите внимание, что использовать в Cluster-mode старую, disruptive схему, с выключением контроллера, загрузкой в boot menu, снятием там текущего disk ownership с дисков и назначением их новому контроллеру - нельзя. Новые механизмы “по капотом” Cluster-mode, в частности внутренние, реплицируемые между членами кластера базы конфигураций, будут если не повреждены, то уж точно не позволят вам таким образом “релоцированный” мимо штатных механизмов aggregate (и, прежде всего, тома на нем) подключить и увидеть.
Подробно, включая и разнообразный траблшутинг, механизм релокейта рассматривается в документе Clustered Data ONTAP® 8.2 High-Availability Configuration Guide
(https://library.netapp.com/ecm/ecm_download_file/ECMP1196905)

Недавно в одном блоге(внезапно блог этот умер буквально на неделе, поэтому мне пришлось сохраненный текст того поста перенести в документ Google Docs, смотрите содержимое цитируемого поста там) увидел результаты эксперимента, в котором пользователь тестировал FAS3210 на эффект от включенной и выключенной поддержки VAAI, на таких операциях, как создание нового thick eager zeroed диска, клонирование VM, и Storage VMotion.
Я часто встречал какие-то завышенные ожидания от использования VAAI. ?? очень часто люди, не получая ожидаемого ими сногсшибательного результата, начинают думать, что делают что-то не так. А на самом деле этот эффект и правда, по видимому, не слишком велик (по крайней мере не так велик, как о нем думают, и чего ожидают, начитавшись маркетинговых материалов VMware).
Так, например, в рассматриваемом эксперименте, максимальный эффект от поддержки VAAI был на операции Storage VMotion, и представлял собой всего лишь тридцатипроцентное улучшение по времени операции, при пропорциональном увеличении загрузки CPU контроллера.
Сравнивая со сделанными ранее тестами FAS2040, автор вполне резонно делает вывод, что эффект от VAAI, по видимому, тем больше, чем мощнее контроллер, и упирается в контроллер и его процессор. Отсюда вывод, что на entry-level стораджах (любого производителя), эффект от поддержки VAAI в его контроллере, скорее всего незначителен, и нет особого смысла бороться за него, или надеяться на его чудодейственность.