Я не специалист по хранению. Я знаю, как пишется SAN, и еще несколько основ, но не более того.
Надежны ли счетчики std disk при измерении в сравнении с хранилищем SAN? У нас есть 2 сервера MS SQL (2005), оба подключены к одному и тому же SAN, и вчера у них начались проблемы. Мы не контролируем оборудование, поэтому у меня нет большой информации о том, как настроено хранилище, кроме того, что я вижу вплоть до LUN через Veritas Enterprise Admin (т. е. только базовую конфигурацию тома). У меня нет доступа к инструментам для мониторинга пропускной способности на контроллерах или коммутаторах.
Вместо этого я запускал счетчики perfmon (% дискового времени для физических и логических, длина очереди диска для физических и логических). Цифры для % дискового времени для физического диска кажутся просто сумасшедшими - до 32000% (да, 32K).
Это так, или я прав, полагая, что для создания этой метрики что-то агрегируется снизу, снизу, на уровне LUN, и этот счетчик не следует использовать для хранилища SAN?
РЕДАКТИРОВАТЬ:
Стоит добавить, что недавно мы обнаружили, что один из 32 модулей кэша имеет проблемы и был удален из микса. Я знаю, что это Hitachi, но я не знаю никаких подробностей о модели.
ОБНОВЛЯТЬ:
Hitachi только что закончила замену неисправного модуля памяти и повторную инициализацию карты оптоволоконного порта, теперь все, похоже, вернулось к норме. Спасибо за информацию, ребята!
решение1
Явно безумные цифры %Disk Time действительно о чем-то говорят, но способ, которым %Disk Time выводится Perfmon, означает, что цифры >100% не являются невозможными.
%Время диска на самом деле является вычисляемым счетчиком и рассчитывается следующим образом:
Avg Disk Sec/Transfer * Disk Transfers/sec.
Avg Disk Sec/transfer берет сумму времени завершения для всех IO в текущем интервале и делит на количество IO, что дает среднее время завершения от начала до конца. Disk Transfers per second — это просто общее количество завершенных IO, деленное на интервал.
Многие из этих операций ввода-вывода могли быть инициированы за пределами текущего интервала, поэтому их произведение может быть >100%. Это может произойти в любой системе, но оно будет превышать 100% чаще в сложных дисковых массивах, таких как SAN.
Из-за способа расчета %Disk Time на самом деле не говорит вам многого, хотя в этом случае он говорит вам, что что-то не так. Расчет использования с использованием (100-%время простоя) — лучшая идея, поскольку %время простоя на самом деле измеряется напрямую.
Длина очереди диска может быть намного больше, чем при простой локальной настройке хранилища, но в целом, если длина очереди >> количеству шпинделей, поддерживающих LUN, то все резервируется, особенно если длина очереди постоянно растет в течение значительного периода времени. Значение 10 или даже 20 на LUN с 10-15 дисками вообще не будет проблемой, но 350 определенно говорит о том, что что-то не так. Неисправный или плохо настроенный кэш, безусловно, может вызывать такие проблемы, но могут быть и другие причины.
Тем не менее, если вы хотите знать, что на самом деле, вам нужно посмотреть на мониторинг производительности на уровне SAN, и вам придется получить это от ваших людей, занимающихся SAN. Проблема может быть в дисках на LUN (возможно, диск вышел из строя и происходит перестроение RAID, возможно, кэш отключен по какой-то причине, возможно, другие LUN, отделенные от тех же дисков, имеют более высокий приоритет и заняты), возможно, кэш отключен/отказан в работе на этом конкретном массиве, возможно, проблема в структуре SAN или коммутаторах.
Есть старая, но очень хорошая статья на темуСчетчики диска в Windows здесь.
решение2
Каковы значения параметров «Средняя длина очереди чтения с диска» и «Средняя длина очереди записи с диска» в системном мониторе для этих LUN, как каждый сервер сравнивается друг с другом.
Если вы сможете договориться с ребятами из SAN о тихом времени, то вы можете бежать.IOZoneна обеих машинах и сравните результаты.
решение3
Некоторые счетчики вам полезны, а некоторые нет. Такие вещи, как текущая очередь диска, покажут вам очередь, которую видит хост Windows между отправкой команды чтения/записи и обработкой этой команды в кэше в SAN. Но если диски работают нормально, вы все равно можете увидеть очередь на хосте из-за проблем с кэшем, коммутатором или волокном.
Такие показатели, как количество секунд на чтение и количество секунд на запись, будут работать одинаково: они сообщат вам, сколько времени заняла запись в кэш.
Цифры вроде IO writes per second немного более полезны. Опять же, это IO в кэш SAN, но этот IO должен попасть на диск в какой-то момент. То же самое касается IO reads per second. Это чтение с диска и кэша, но если он находится в кэше чтения, то он в какой-то момент ушел с диска.