Покажите IO на NetApp

Я думаю, что мог бы поражать пределы IO того, что может поставить мой NetApp, поскольку я добавлял больше серверов к своему кластеру, и iowait повысился на каждом сервере.

Однако, как я определяю количество этого? Как я могу использовать инструменты Netapp CLI для просмотра текущей статистики IO? Я знаю "о шоу статистики", но не вижу объект "io" или подобный. Как я знаю то, что NetApp, как предполагается, может поставить?

Если бы у кого-либо есть больше опыта с NetApp, чем я, я был бы очень признателен за справку.

Спасибо!

3
задан 25 August 2016 в 17:52
6 ответов

Есть несколько вариантов для мониторинга производительности NetApp файлер. Это зависит от версии DataOntap. Просто выполните sysconfig, и вы увидите версию. Вы можете использовать OnCommand Performance manager в качестве инструмента графического интерфейса для кластеризованного Ontap. Другой вариант кластеризованного Ontap - это QoS в качестве монитора производительности. Для 7-режима вы можете использовать консольные команды systat или statit.

1
ответ дан 3 December 2019 в 06:32

Посетите раздел My AutoSupport на сайте поддержки netapp. В нем есть данные о производительности, которые вы можете анализировать, а также некоторые проверки работоспособности.

1
ответ дан 3 December 2019 в 06:32

Этот ответ применим только к 7-режиму - у меня нет опыта работы в кластерном режиме.

С проблемами производительности, просто нет простых ответов.

У вас есть счетчики для iops, которые вы можете показать с помощью sysstat -x.

stats show system даст вам что-то похожее - список NFS/FCP/CIFS операторов и т.д.

Само собой, Эти вещи достаточно произвольны - откуда вы знаете, сколько IOPов это "слишком много"?

Самое полезное, что я нахожу в индикаторе - это смотреть на точки согласованности. Опять же, вернемся к sysstat -x. Способ, которым фильтры пишут IO - это заполнение кэша NVRAM. Этот кэш периодически очищается, и данные записываются на диск в виде всплесков.

То, что тип точки консистенции произошел, является хорошим индикатором того, 'счастлива ли' Ваша система. https://kb.netapp.com/support/index?page=content&id=3014024

T means your system is idle. (triggered by timer - not much happened for 10s, so it thought it better destage anyway)
S or Z is a 'forced' cp because of a snapshot/snapmirror op. (and usually isn't a problem)
F or H or L means your system is getting busy.  (F is nvram filling with write data, H/L represent high and low watermarks for memory)
B or b means your system is struggling. (Back to back CPs, which means your hitting the limits of your ability to write to disk.

Это почти полностью относится к записи ввода-вывода. Другая причина, по которой ваша система может испытывать трудности - это чтение IO. Записи можно легко кэшировать; чтение должно быть извлечено немедленно - и только в некоторых случаях они могут быть кэшированы.

Счетчик статистики выдаст вам disk_data_read и disk_data_written. sysstat -x даст вам то же самое и понятие об использовании диска. (Но учтите, что использование - это "кросс-система", поэтому не будет показывать, есть ли у вас один действительно горячий агрегат, усредненный с "холодным").

Вы также можете запустить stats show volume[11111902], чтобы получить статистику ввода-вывода на каждый объем. Это даст вам представление об общем количестве прочитанных/писанных и о том, какой объем они собираются получить. Он также различает "читать" "писать" и "другое". "другое" может быть довольно значительным и проблематичным.

1
ответ дан 3 December 2019 в 06:32

Netapp также предоставляет инструмент под названием perfstat, который может собирать данные для устранения проблем производительности и ввода-вывода:

https://kb.netapp.com/support/index?page = content & id = 1013882

0
ответ дан 3 December 2019 в 06:32

Ну, я полагаю, вы выполнили io-stats и увидели «iowait» на стороне сервера и сделали такой вывод: «Netapp может работать медленно». Если вы теперь посмотрите на NetApp, вы найдете все и ничего, чтобы доказать свою теорию. Я обещаю вам.
Не из-за недостатка информации в хранилище NetApp. Но если вы не знаете, что ищете, вы не дойдете до точки проблемы (если есть проблема / проблема производительности, связанная с хранилищем)
Поэтому я бы предложил другой подход: посмотрите с сервера на хранилище -обмануть поток ввода-вывода Прежде всего, как сервер подключен? Fibre-Channel SAN? NFS / iSCSI (на основе IP)?
Проверьте, в какое время вы видите «iowait» и видите ли вы «iowait» без / или с небольшим io-busy? а с низкой LUN-утилизацией? -> может это быть связано с запуском резервного копирования?
Какой сервер подключен? Большая часть VMWare?
Каково соотношение характеристик ввода-вывода (чтение / запись)?
Может быть проблема с невыровненным вводом-выводом?
Как настраивается очередь ввода-вывода на стороне сервера?
Вы должны анализировать от сервера к хранилищу, а не наоборот. Начните с четкого представления о вашей конфигурации / топологии хранилища. Это также поможет нам дать вам больше идей для проверки наличия проблем с (хранилищем) и их местонахождения.

0
ответ дан 3 December 2019 в 06:32

Инструмент Performance Advisor, поставляемый с OnCommand Unified Manager, - это то, что вам нужно. Это программное обеспечение бесплатно для всех клиентов NetApp. Он будет отслеживать информацию об IOPS на уровне контроллера, агрегата, тома и LUN.

0
ответ дан 3 December 2019 в 06:32

Теги

Похожие вопросы