image

Как понять, что СХД плохо? Как определить что запас производительности исчерпан? Какие параметры об этом свидетельствуют? В этой статье речь пойдет об анализе утилизации СХД, а также выявлении и прогнозировании проблем связанных с производительностью. Материал может быть не интересен опытным storage администраторам, поскольку будут рассмотрены только общие моменты, без углубления в логику работы хитрых механизмов оптимизации производительности.

Для начала определимся с терминологией. Есть несколько терминов и аббревиатур близких по смыслу: СХД, дисковый массив, SAN, Storage Array или просто Storage. Попробую внести ясность.

SAN — Storage Area Network или сеть хранения данных, это совокупность оборудования осуществляющая передачу трафика между сервером и системой хранения данных.

СХД — система хранения данных или дисковый массив, оборудование на котором хранятся данные с возможностью оперативного доступа. Есть еще архивные хранилища, но здесь мы их рассматривать не будем. Аббревиатура СХД так же может употребляться как сокращение от сеть хранения данных, но среди русскоговорящих специалистов термин СХД закрепился именно за системой хранения данных.

СХД могут обеспечивать два способа доступа к данным:

  • Блочный доступ, операционная система сервера работает с СХД как с SCSI жестким диском (упрощенно).
  • Файловый доступ, операционная система сервера работает с СХД как с файловым хранилищем по протоколу NFS, SMB и тд.

Обычно к СХД обеспечивающим блочный доступ предъявляют более высокие требования к производительности, нежели к системам обеспечивающим файловый доступ, это обусловлено спецификой решаемых задач. Далее речь пойдет о СХД c блочным доступом, работающим по протоколу Fiber Channel.

Для оценки производительности СХД используют три основные метрики


  1. Service Time, часто именуемый latency или responce time, измеряется в миллисекундах и обозначает:
    • при чтении: время с момента получения СХД задания на чтение блока информации до отправки запрошенной информации.
    • при записи: время с момента получения записываемого блока информации до подтверждения о его успешной записи.
  2. IO/s — количество операций ввода вывода в секунду.
  3. MB/s — количество переданных мегабайт в секунду.

Параметры IO/s и MB/s тесно связаны между собой размером блока данных, т.е. один мегабайт информации можно записать блоками по 4k и получить 256 операций ввода-вывода, или блоками 64k и получить 16 IO.

Рассмотрим наиболее типичные проявления проблем производительности СХД по показателям Service Time, IO/s и MB/s.

Повышенный Service Time


image

Для каждого СХД есть крайнее значение Service Time которое соответствует максимальной производительности, другими словами, незначительное увеличение нагрузки приведет к существенному повышению Service Time, вызвав тем самым деградацию требовательных к задержкам приложений.

Для примера, ниже графики зависимости Service Time от IOPS для двух конфигураций СХД.

ST для All flash СХД, 2 Node, 24x1.9 TB SSD, RAID 5, Random 32k, 50/50 Read/Write.

image

ST для классического СХД, 2 Node, 24x1.8 TB HDD, RAID 5, Random 32k, 50/50 Read/Write.

image

В общих случаях для All Flash СХД приемлемым считается Service time меньше 1ms, а для классических СХД до 20ms. Порог приемлемого Service time зависит от числа контроллеров, скорости дисков и конечно модели самой СХД, и может отличаться от приведенных значений.
Также нужно учитывать до какого уровня задержек дисковой подсистемы сохраняется нормальная работоспособность приложения, и всегда иметь необходимый запас.

Планка по MB/s


image

Чаще всего свидетельствует об исчерпании пропускной способности канала или FC адаптера.

Конкурирующие значения по MB/s или IO/s


image

Сумма (оранжевый график) двух или более параметров на отрезке времени имеет константу и не превышает ее в какой-либо момент. Такая ситуация может наблюдаться в случае конкуренции за пропускную способность канала или порта СХД.

Понижение IO при возрастании ST


image

image

В случае если процентное распределение размеров блока не изменилось, но при этом ST начинает повышаться, а IO падать, это может свидетельствовать об аппаратных проблемах с СХД, деградации одного из контроллеров или высокой утилизации CPU.

Утилизация CPU


Утилизация CPU контроллеров СХД в общих случаях не должна превышать 70%, если она постоянно выше 70%, то это свидетельствует об отсутствии запаса производительности СХД.
Тут нужно отметить, что СХД можно разделить на две большие группы:

  • С использованием ASIC, в таких СХД передача данных внутри массива обрабатывается отдельным высокопроизводительным чипом, а CPU остаются сервисные задачи, такие как создание и удаление дисков и снапшотов, сбор статистики и тд.
  • Без использования ASIC, в таких СХД все задачи выполняет CPU.

Утилизацию CPU нужно трактовать по-разному для СХД с ASIC и без, но в любом случае она не должна быть выше 70% при отсутствии запущенных сервисных задач.

Медленный рост IO на чтение


image

Такая проблема может наблюдаться в случае если СХД использует тиринг размещения данных между носителями разной скорости (например, SSD и NL SATA).

К примеру: некая БД работает с высокой нагрузкой один день в неделю, а остальное время простаивает, в таком случае данные к которым давно не было обращений перейдут на носители с малой скоростью, и скорость чтения будет постепенно расти при переходе (так называемом прогреве данных) на быстрые носители.

Какой характер нагрузки не свидетельствует о проблемах?


Пилообразный график IO

image

Скачки по MB

image

Прыгающие значения IO

image

Все перечисленные примеры нагрузки не свидетельствуют о каких-либо проблемах на стороне СХД. Нагрузка создается хостом подключенным к СХД и зависит от логики процессов использующих дисковое пространство.

Как определить трешхолды для Service Time, IO/s и MB/s?


Данные параметры можно рассчитать теоретически, складывая производительность дисков и считая пенальти выбранного уровня RAID, также можно воспользоваться сайзерами при наличие оных, но расчет будет очень приблизительным, поскольку не будет учитываться реальный профиль нагрузки. Для определения точных пороговых значений, свидетельствующих например о 90% загрузке СХД, необходимо провести нагрузочное тестирование при помощи специального ПО, сформировав профиль нагрузки близкий к реальному и замерить максимальные значения IO/s и MB/s. Но как быть с Service Time? Тут зависимость нелинейная. Для определения Service Time соответствующего 90% загрузке нужно просто сгенерировать 90% от максимально достигнутого значения по IO. Полученные результаты можно экстраполировать на близкие по конфигурации СХД.

Вместо заключения


Анализ и интерпретация параметров производительности СХД в большинстве случаев задача не тривиальная, нужно понимать архитектуру и принцип работы конкретной СХД, иметь схему портов SAN и знать нюансы работы используемых FC адаптеров. Я не рассматривал влияние репликации и использование конвергентных решений, поскольку применение данных технологий существенно усложняет описание процессов влияющих на производительность и сужает перечень общих рекомендаций. В статье не разбирались параметры использования кеша контроллеров, загрузки дисков и утилизации портов внутренней коммутации СХД, поскольку интерпретация этих данных сильно зависит от конкретной модели СХД и применяемых технологий.

Комментарии (2)


  1. grims
    26.09.2017 09:57

    А чем, чем мониторить то?


    1. ESergey Автор
      26.09.2017 10:03

      Можно использовать встроенные репортеры или ПО предлагаемое вендором, мы же используем продукт собственной разработки.