Показать IO на Netapp
Я думаю, что я мог бы достичь пределов IO того, что может обеспечить мой Netapp, так как я добавлял больше серверов в свой кластер, и iowait вырос на каждом сервере.
Тем не менее, как я могу определить это? Как я могу использовать инструменты Netapp CLI для просмотра текущей статистики ввода-вывода? Мне известно о "показе статистики", но я не вижу объекта "io" или подобного. Как мне узнать, что должен доставить Netapp?
Если у кого-то есть больше опыта с Netapp, чем у меня, я был бы очень признателен за помощь.
Спасибо!
6 ответов
Ознакомьтесь с разделом My AutoSupport на сайте поддержки netapp. Он содержит данные о производительности, которые вы можете проанализировать, а также некоторые проверки работоспособности.
Этот ответ относится только к 7-режиму - у меня нет опыта работы в режиме кластера.
С проблемами производительности просто нет простых ответов.
У вас есть счетчики для iops, которые вы можете показать с sysstat -x,
stats show system даст вам что-то похожее - список операций NFS/FCP/CIFS и т. д.
Хотя сами по себе эти вещи довольно произвольны - откуда вы знаете, сколько IOP'ов "слишком много"?
То, что я нахожу наиболее полезным индикатором, - это просмотр точек согласованности. Опять вернемся к 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.
Это почти полностью о записи IO, хотя. Другая причина, по которой ваша система может испытывать трудности - это чтение ввода-вывода. Записи могут быть легко кэшированы; чтения должны быть получены немедленно - и только в некоторых случаях они могут быть кэшированы.
Ваш счетчик показа статистики даст вам disk_data_read а также disk_data_written, sysstat -x даст вам то же самое и понятие об использовании диска. (Но имейте в виду, что использование является "кросс-системой", поэтому не покажет вам, если у вас есть один действительно горячий агрегат, усредненный с "холодным").
Вы также можете запустить stats show volume чтобы получить статистику ввода-вывода по объему. Это даст вам представление об общем количестве операций чтения / записи и том, к какому объему они будут. Он также различает "читать", "писать" и "прочее". "другое" может быть довольно значительным и проблематичным.
Есть несколько вариантов для мониторинга производительности NetApp Filer. Это зависит от версии DataOntap. Просто выполните sysconfig, и вы увидите версию. Вы можете использовать диспетчер производительности OnCommand в качестве инструмента с графическим интерфейсом для кластерного Ontap. Другой вариант для кластеризованного Ontap - QoS в качестве монитора производительности. В 7-режиме вы можете использовать консольные команды systat или statit.
Инструмент Performance Advisor, который поставляется с OnCommand Unified Manager, - это то, что вам нужно. Это программное обеспечение бесплатно для всех клиентов NetApp. Он будет контролировать информацию IOPS на уровне контроллера, агрегата, громкости и LUN.
Ну, я полагаю, вы выполнили io-stats и увидели "iowait" на стороне сервера и сделали такой вывод: "Netapp может быть медленным". Если вы теперь посмотрите на Netapp, вы найдете все и ничего, чтобы доказать свою теорию. Я обещаю вам.
Не из-за недостатка информации из хранилища Netapp. Но если вы не знаете, что ищете, вы не решите проблему (если есть проблема с производительностью, связанная с хранилищем)
Поэтому я бы предложил другой подход: посмотреть с сервера на хранилище - определить поток ввода-вывода. Во-первых, как подключен сервер? Fibre-Channel SAN? NFS/iSCSI (на основе IP)?
Проверьте, в какое время вы видите "iowait" и видите ли вы "iowait" без / или небольшого io-busy? а с низким LUN-использованием? -> это может быть связано с выполнением резервного копирования?
К какому серверу подключены? Большинство VMWare?
Как соотносятся характеристики ввода / вывода (чтение / запись)?
Может ли быть проблема с невыровненным вводом / выводом?
Как настроена очередь ввода / вывода на стороне сервера?
Вы должны анализировать с сервера на хранилище, а не наоборот. Начните с четкой картины вашей конфигурации / топологии хранилища. Это также поможет нам дать вам больше идей для проверки, есть ли проблемы с (хранилищем) и где они находятся.
Netapp также предоставляет инструмент под названием perfstat, который может собирать данные для устранения проблем производительности и проблем ввода-вывода: