Внутри 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, и приступим к знакомому процессу разбора в этом замечательном инструменте.
VSC это основной инструмент для управления и использования стораджами NetApp в среде VMware vCenter, он позволяет управлять системой хранения “с точки зрения” администратора виртуальной инфраструктуры, создавать и удалять датасторы, настраивать их, управлять доступом, создавать резервные копии и клоны, и так далее.
К сожалению пока не поддерживается vCenter Web Client, поворот к которому уже окончательно наметился, VSC 4.2 все еще работает как плагин к “толстому клиенту” vCenter, но работа над новым VSC (вероятно он будет 5.0) уже идут, и близки к финишу. Он будет работать с vCenter Web Client, и использовать платформу Adobe FLEX. Но пока – про VSC 4.2 beta.
??з нового – полноценно поддерживается RBAC (Role-bsed Access Control). В VSC 4.1 RBAC использовать было тоже можно (нужно), и работать под специальным пользователем, а не “под рутом”, но это требовало довольно хлопотных и трудоемких операций по настройке прав такого пользователя. В VSC 4.2 в этом направлении сделаны большие подвижки, настроены templates и настройку можно проводить уже непосредственно из VSC. Вы можете создать отдельно Главного Администратора, отдельно Администратора с правами бэкапа и клонирования, например, отдельного админа для создания датасторов, отдельно юзера с правами readonly, и так далее. Это крайне востребовано в больших инфраструктурах, где, зачастую, на ферме виртуальных машин работает множество разных админов, с разными правами доступа и должностными обязанностями.
Переработана разбивка функций по модулям VSC. Когда-то VSC был надстройкой над разными продуктами, в частности отдельно существовал SnapManager for Virtual Infrastructure для бэкапов и восстановления из них, и утилита RCU – Rapid Cloning Utility, для клонирования датасторов и их провижнинга. Так как уже давно все эти продукты встроены внутрь VSC, давно назрела необходимость перетрясти организацию пользовательского интерфейса VSC.
Ну и, как всегда, поправлены баги (около 150), и добавлена поддержка новых систем в VDDK (например Windows Server 2012).
Я уже писал, что в разделе Toolchest на NOW можно, порой, найти какие-нибудь интересные и полезные утилитки, про которых, часто, никто не знает. Вот и в этот раз там обнаружилась любопытная утилита SnapMirror Progress Monitor Tool.
Это, что явствует из названия, инструмент для слежения за процессом репликации SnapMirror.
Если в вашей системе хранения используется SnapMirror, а в особенности, если SnapMirror передает достаточно объемные репликации по сравнительно узким WAN-каналам, то, безусловно, такая утилитка будет в вашей практике весьма применима и полезна.
Среди прочего, она, например, позволяет оценить время на репликацию в текущих условиях и для имеющегося объема данных, без фактической репликации.
Я уже упоминал этот инструмент в своей длинной и еще незаконченной серии про оптимизацию производительности систем NetApp. Правда там вкралась ошибка, perfviewer берут не в NOW, он лежит на внутреннем “партнерском” ресурсе fieldportal.netapp.com, но статус у него там свободный, а раз так, то я намерен вам его показать.
Perfviewer это java-приложение, которое запускается и берет на вход файл, сформированный скриптом perfstat, который собирает данные производительности и разнообразную статистику с работающей системы для задач поддержки. Файл из perfstat получается огромный (например пробный вывод на пять получасовых итераций получился размером в 29 мегабайт) и при этом практически нечитаемый из за своего размера. Это просто сконкатенированный последовательный вывод пары десятков команд Data ONTAP. Вот для того, чтобы распарсить этот огромный файл, и получить какую-то визуализацию и используется PerfViewer. Текущая версия 1.5.1, не обновлялась она довольно давно, так что можно считать ее стабильной.
UPD: Как совешенно справедливо указывают мне в коментариях читатели, Perfviewer v1.5.1 давно не обновлялся, и не работает с выводом perfstat для версий 7.3.x, что очень печально, и, к сожалению, лишает эту утилиту большей части полезности на сегодня. :(
Продолжая тему контроля пользователей NAS, начатую постом про команду cifs top, хочу отметить любопытную утилиту, доступную на сайте NOW: NetApp System Analyser for CIFS
Это автономная утилита под x32 и x64 Windows, помогает контролировать и анализировать загрузку NAS-системы пользователями по протоколу CIFS.
Утилита состоит из четырех компонент:
Dashboard: основная панель, показывающая обзор состояния контроллера системы хранения, таких его параметров, как CPU utilization, объемы трафика, счетчики производительности CIFS и общую информацию по системе.
Analyzer: Создает отчеты и делает рекомендации по вашей ситуации, определяя возможные источники проблем.
User Statistics: Показывает статистику по пользователям, позволяет оценить кто из пользователей (а также серверов или приложений) и сколько использует ресурсов CIFS.
Support Report: Собирает данные, необходимые для работы NetApp Support, для анализа и устранения проблем, связанных с CIFS. Вывод может быть послан непосредственно в NetApp из самой утилиты, или записан и отослан отдельно.
Несмотря на то, что в целом ONTAP стремится быть понятной и “самоописательной”, как в своих командах, так и в сообщениях в логах, в них нередко встречаются сообщения довольно “загадочные”.
Для того, чтобы лучше разобраться в сообщениях syslog, на сайте NOW (NetApp on Web) есть полезная служба: System Log Translator ниже – скриншот:
Например, мы видим в логе сообщение:
[scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured - Host I/O access through a non-primary and non-optimal path was detected.
Введенное в Syslog Translator оно покажет следующее:
??сторически первым интерфейсом администрирования систем хранения NetApp была командная строка в консоли администратора, доступная по телнету или ssh для любой системы NetApp. Так как, исторически, главной "целевой аудиторией" для первых систем хранения NetApp были системные администраторы UNIX, было решено сделать консоль администрирования настолько похожей на стандартную UNIX-консоль, насколько это возможно. ??менно потому, что консоль NetApp настолько "юниксподобна", это год за годом порождает слухи в "хитро спрятанном линуксе инсайд" хотя внутри NetApp и совершенно не UNIX, или по крайней мере нечто, совсем отличное от известных большинству UNIX-систем. Давным-давно я уже писал, что именно находится внутри, интересующиеся могут сходить в тот пост.
С расширением "аудитории" NetApp возникла потребность в создании чего-то более GUI-образного и "интуитивно-понятного", и в 1996 году, 13 лет назад, появился веб-интерфейс FilerView, на тот момент один из первых такого рода на рынке систем хранения.
В тот момент это была прорывная технология, так как позволяла управлять системой хранения, наряду с традиционным методом из командной строки, который по прежнему существует и поныне, и из окна веб-браузера, что облегчило работу для нового поколения сисадминов, не проходивших суровую спартанскую школу командной строки Юникс. Важной особенностью веб-интерфейса было то, что в отличие от других аналогичных разработок, она почти полностью позволяла выполнять задачи администрирования системы хранения, не прибегая к командной строке.
Повторюсь, для 96 года это был прорыв. Однако с той поры прошло уже, страшно подумать, 13 лет, выросло уже, по сути, новое поколение "сисадминов". Веб-технологии развивались стремительными шагами, и интерфейс FilerView стал выглядеть, деликатно выражаясь, несколько архаично. Да он по прежнему прост и функционален, по прежнему делает все, что необходимо, но уже совсем не "радует глаз". Зачастую это даже стало вызывать определенное отторжение у новичков. Встречают в мире по прежнему по одежке.
В недрах NetApp довольно давно велись работы в этом направлении, так, standalone GUI под названием StorVault Manager получило семейство StorVault (S-Series), выходили специальные "мастера" начальной устрановки систем FAS под Windows (QuickSetup Wizard и FAS Easy Start Wizard), а также продукты Protection/Provisioning Manager, "гуизирующие" определенные фрагменты общего процесса.
?? вот, наконец, все вместе, в новом продукте для управления вашими системами FAS: NetApp System Manager.
Многие админы Windows Servers уже знают и используют новые возможности “коммандлайнового интерфейса Windows” - PowerShell.
Кто еще не вникал - самое время вникнуть: , , .
Для уже знакомых с PowerShell укажу интересную разработку, позволяющую управлять системами хранения NetApp через PowerShell, с использованием ONTAP Management SDK.
Найдено тут:
Просмотрите также и прочие темы этого автора в блоге, можно найти любопытного.
Популярное среди сетевых админов средство визуализации SNMP-данных - MRTG (Multi Router Traffic Grapher) можно использовать и для наблюдения за системами хранения NetApp.
На в ToolChest лежит , пакет, настроенный под использование с системами NetApp.
Команда консоли sysstat похожа на vmstat и iostat свернутые в одну команду. Она сообщает данные производительности систем хранения, такие как CPU utilization, размеры дискового трафика, объемы ввода-вывода, как сетевого, так и по FC, а также трафик передачи данных на ленту, если она используется. При запуске без опций, sysstat печатает новую строку каждые 15 секунд, с базовым набором информации. Вы можете прервать вывод нажав control-C (^c) или установить при запуске определенный интервал работы (-c count ) для автоматической остановки через заданное время.
Список ключей команды:
-f статистика FCP -i статистика iSCSI -b расширенная статистика SAN (’blocks’) -u расширенная статистика загрузки системы (’utilization’) -x расширенный (’extended’) формат вывода. Включает в себя все доступные поля вывода.
Обратите внимание, что вывод производится в формате шире чем 80 символов, и предназначен скорее для “off-line” анализа, чем для непосредственного чтения с экрана.
-m отображает статистику по загрузке CPU на многопроцессорных системах. Применимо только на многопроцессорных системах, не работает на однопроцессорных.
Описания некоторых колонок вывода команды sysstat.
Cache age : возраст в минутах старейшего read-only блока в кэше. Значение в этой колонке показывает, насколько быстро операции чтения проходят через память системы; когда система читает очень большие файлы, значение buffer cache age будет низким. Кроме этого, если чтение преимущественно случайное, то cache age также будет низок. Если вы столкнулись с проблемой низкой производительности на чтении, то значение этого поля сможет помочь определить что вам нужно больше кэша, или нужно проанализировать работу приложения, чтобы снизить уровень “случайности” его запросов.
Cache hit : Величина в процентах для WAFL cache hit rate. Показывает, в скольки процентах читаемых с WAFL блоков они оказывались при этом уже в кэше. Прочерк в этой колонке, означает, что в измеряемый период данные не читались.
CP Ty : Тип (’type’) Consistency Point (CP). Показывает, что было причиной создания CP в рассматриваемом интервале. Тип CP может быть:
- не было CP в заданный интервал (не было записей на диск в указанный период времени)
(число) число CP, созданных в заданном интервале
B : Back to back CPs (CP generated CP) (система настолько загружена, что она начинает писать новую CP сразу за окончанием записи предыдущей)
b : задержанные back to back CPs (CP generated CP) (условия, вызвавшие состояние back to back стали хуже)
F : CP вызван заполнением NVLog (половина nvram log была заполнена, и он был сброшен на диск)
H : CP вызван high water mark (редко встречается. Система полностью заполнила одну половину nvram logs, и решила сбросить данные на диск).
L : CP вызван low water mark
S : CP вызван операцией создания snapshot
T : CP вызван таймером (каждые 10 секунд система хранения сбрасывает данные кэша на диск (flush))
U : CP вызван сбросом данных на диск (flush)
: продолжение CP с предыдущего интервала (означает, что CP все еще создается, например во время 1-секундного интервала)
Символ, следующий далее, показывает проходящую фазу создания CP на момент окончания интервала замера. Если CP завершился полностью во время интервала измерения, то второй символ будет пустой. Фазы могут быть следующие:
0 ??нициализация n обработка обычных файлов s обработка специальных файлов f сброс измененных данных на диск v сброс измененного суперблока на диск
Большинство перечисленных выше значений можно увидеть только в случае предельно малых интервалов замеров, или на сильно загруженных системах, так как сброс CP происходит очень быстро. Обычно в поле CP ty вы будете видеть ‘T’, штатный сброс Consistency Point по таймеру.
Давайте разберем пример.
sysstat.txt (для более удобного вида отключите в нотепаде word wrap и расширьте окно)
Что мы можем сказать о данной системе?
Это малозагруженная, практичеси находящаяся в покое система (параметры CPU, Disk Usage и Total), использующая CIFS и FCP (небольшие ненулевые значения показывают фоновые операции по этим протоколам). Большиство операций в этой покоящейся системе совершается в виде чтения содержимого кэша (значение Cache hit). Кэш практически пуст, на что указывает монотонное возрастание значения Cache age, данные лежат, и ничто их не вытесняет. Consistency Points создаются исключительно сбросом по таймеру, что нормальное поведение для незагруженной системы.
Довольно высокие значения Disk read write при малой загрузке CPU, практически нулевом сетевом траффике и операциях ввода-вывода по блочным протоколам указывает на работу процесса Disk Scrubbing, фонового процесса контроля целостности данных и дисков, при котором система перечитывает и перезаписывает данные на дисках, возможно также что работает дедупликация, хотя она обычно дает повыше чем 1-3% загрузку, также, возможно, это признак работы дефрагментации WAFL (wafl reallocate).
Так выглядит типичный вывод sysstat малонагруженной типовой системы NetApp FAS.
А вот так выглядит система под рабочей нагрузкой: sysstat3.txt
Как видите, уже заметно нагружен процессор (это FAS6070, поэтому запас еще весьма существеннен ;), около 20%. Так как система используется как SAN, то весь трафик идет по колонке FCP. Несмотря на заметную нагрузку, ниже приведенный отчет по utilization показывает производительность около 15000 IOPS, и около 23 MB/s чтения с дисков ( и 70-90MB/s по интерфейсам FC), это не перегрузило систему. Большой объем кэша на чтение позволяет 90% операций читаться из кэша, а не с дисков.
Возраст самого старого блока в кэше составляет примерно 10-12 минут, то есть кэш еще далек от заполнения.
Здесь уже периодически проскакивают символы, показывающие фазу сброса CP, и само время записи CP увеличилось, так как вырос объем записи, хотя он и составляет всего около 1/10 от объемов чтения.
Таким образом, используя даже штатные средства контроля и анализа системы, имеющиеся в административной консоли, можно увидеть много интересного.
Оригинал тут:
А вообще это, за исключением моего разбора примера вывода, практически перевод манов к команде из встроенного хелпа.
