Я уже писал, что в разделе Toolchest на NOW можно, порой, найти какие-нибудь интересные и полезные утилитки, про которых, часто, никто не знает. Вот и в этот раз там обнаружилась любопытная утилита SnapMirror Progress Monitor Tool.
Это, что явствует из названия, инструмент для слежения за процессом репликации SnapMirror.
Если в вашей системе хранения используется SnapMirror, а в особенности, если SnapMirror передает достаточно объемные репликации по сравнительно узким WAN-каналам, то, безусловно, такая утилитка будет в вашей практике весьма применима и полезна.
Среди прочего, она, например, позволяет оценить время на репликацию в текущих условиях и для имеющегося объема данных, без фактической репликации.
Основной лог в Data ONTAP, как у “правильной юниксподобной OS”, ведется в виде syslog. ??, как правильный syslog, он может передаваться на удаленную машину для сборки-разборки его в спциализированных программах.
Для того, чтобы настроить логи на передачу их на удаленную машину, надо изменить настройки в /etc/syslog.conf Его синтаксис идентичен таковому в Linux/UNIX.
# Log all kernel messages, and anything of level err or higher to the console. *.err;kern.* /dev/console # Also log console messages to a remote loghost system called adminhost. *.err;kern.* @adminhost
То есть: выводим все сообщения уровня ядра, а также все сообщения с уровнем err и выше в системную консоль, а также передаем их на систему adminhost (где его должен принимать syslog-сервер).
На указанной машине запустим сервер syslog (например Kiwi Syslog Server), и будем получать и обрабатывать эти логи, настроив по ним желаемые алерты и репорты.
Смотрите также статью: Swatch and Kiwi Syslog Daemon. К сожалению, за время, прошедшее с ее публикации, компанию-производителя Kiwi Syslog Daemon купили, и теперь их продукт платный, что, впрочем, не может помешать найти множество бесплатных вариатов той или иной степени удобности.
Малоизвестная, но полезная команда консоли environment позволит наблюдать за различными показателями “среды обитания” системы хранения, таких как, например, температура, скорости вращения вентиляторов охлаждения, или состояние блоков питания.
fas> environment status – показывает всю доступную информацию fas> environment shelf – показывает информацию, относящуюся к дисковым полкам fas> environment chassis all – показывает информацию о шасси контроллера fas> environment chassis list-sensors – показыват все датчики шасси, их состояния и пороги
Пример вывода команды environment status shelf:
Environment for adapter 3:
Shelves monitored: 1 enabled: yes
Swap in progress? no Environmental failure? no
EDM 1 (active):
SES Configuration, via loop id 3 in shelf 0x0:
logical identifier=0x3003040000000000
vendor identification=EuroLogc
product identification=Eurologic EDM
product revision level=0x01000101
Vendor-specific information:
backplane byte=0x1e cabinet id=0x0
Backplane Type : Single Fibre Channel Backplane
Backplane Function : Storage System
Kernel Version : 1.0.A App. Version : 1.1.A
Shelf:0 SES path:3.3 Device mask: 0x7f
Power Supply present: 0x3; with error: 0x0
Fans present: 0x3; with error: 0x0
Temperature Sensor present: 0x1; with error: 0x0
SES Electronics present: 0x1; with error: 0x0
Shelf temperature: 29C (84F)
High thresholds: critical: 55C (131F); warning 50C (122F)
Low thresholds: critical: 0C (32F); warning 10C (50F)
Disks physically present on adapter 3
Devices 0x1f-0x00: 0000007f
Devices 0x3f-0x20: 00000000
Devices 0x5f-0x40: 00000000
Devices 0x7f-0x60: 00000000
Если вам приелся довольно таки спартанский и непритязательный вид штатного мониторинга FilerView, то по адресу unnoc.org находится опенсорсный пакет мониторинга с веб-мордой, для множества разного железа, включая специальные модули под NetApp, а также под множество другого разнообразного железа и софта.
Популярное среди сетевых админов средство визуализации 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 от объемов чтения.
Таким образом, используя даже штатные средства контроля и анализа системы, имеющиеся в административной консоли, можно увидеть много интересного.
Оригинал тут:
А вообще это, за исключением моего разбора примера вывода, практически перевод манов к команде из встроенного хелпа.
