Назад | Перейти на главную страницу

Показать ввод-вывод в NetApp

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

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

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

Спасибо!

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

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

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

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

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

Однако сами по себе эти вещи довольно условны - как узнать, сколько ВГД «слишком много»?

Я считаю наиболее полезным индикатором анализ точек согласованности. Снова вернемся к sysstat -x. Способ записи ввода-вывода файловыми системами заключается в том, что они заполняют кеш 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.

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

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

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

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

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

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

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

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