Анализ утилизации СХД

    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 адаптеров. Я не рассматривал влияние репликации и использование конвергентных решений, поскольку применение данных технологий существенно усложняет описание процессов влияющих на производительность и сужает перечень общих рекомендаций. В статье не разбирались параметры использования кеша контроллеров, загрузки дисков и утилизации портов внутренней коммутации СХД, поскольку интерпретация этих данных сильно зависит от конкретной модели СХД и применяемых технологий.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 13

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

        Всю жизнь считал, что Service Time и Response Time это не одно и то же. В моем понимании Service Time это время, которое тратит конкретный HDD на обслуживание операции ввода/вывода. А значение Response Time = Service Time / (1 — процент утилизации контроллера), где Service Time = средне время поиска дорожки пишущей головкой HDD (Seek time) + время ожидания пока нужные блоки "довернутся" под пишущую головку HDD (Rotational latency) + время передачи данных от пишущей головки HDD к контроллеру HDD или в обратном направлении (transfer time). Исходя из соотношения выше, чем больше нагружен контроллер и чем выше значение Service Time, тем больше будет значение Response Time (вплоть до бесконечности). Так же из описанного выше понятно, что при использовании дисков с низкой скоростью вращения, время отклика будет выше, чем на дисках с высокими скоростями вращения. Косвенно отсюда же вытекает, то что задержки на SSD дисках многократно ниже, так как из уравнения исключаются Seek time и Rotational latency.


        Картинки для наглядности под спойлером...

        image

          0
          Зависимость задержек чтения/записи от процента утилизации контроллера очень нелинейна, например задержки при 1% и при 50% могут быть одинаковые, а при 70% и 80% различаться в два раза.
            0
            Service Time это время, которое тратит конкретный HDD на обслуживание операции ввода/вывода
            Если говорить конкретно об СХД, то ситуация намного более комплексная и одним диском там не обойтись.

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

            Нередко после долгого ручного анализа требуется писать кастомный софт под конкретную задачу, т.к. методики хранения тоже проприетарные и не документированы. Собственно поэтому восстановление данных с SAN традиционно является одной из наиболее сложных задач в отрасли.
              0
              Наверное, имелось ввиду: «чаще имеем дело с живыми СХД», ну по крайней мере я на это надеюсь) Проблемы производительности на back-end СХД самые простые по диагностике, ну если конечно конфигурация самого СХД корректна и есть механизм мониторинга. А восстановление данных это дело не простое и не дешевое, при этом у каждого вендора есть спец софт, которым они обычно не делятся, а потом как договоришься, если оборудование на поддержке и данные попортились не по вине админов, то могут и бесплатно сделать.
            0
            Зависимость задержек чтения/записи от процента утилизации контроллера очень нелинейна, например задержки при 1% и при 50% могут быть одинаковые, а при 70% и 80% различаться в два раза.
              0
              Глобально, service time = response time = latency, но могут быть нюансы, т.к. разные производители считают их по разному :-)
                0

                Вы настолько путаете "теплое с мягким", что даже спорить желания не возникает.

                  0

                  Сильная аргументация, можете остаться при своем мнении.

                    0

                    Ну судя по тому что контраргуменов у вас не возникло, то ваше последнее утверждение близко к истине.

                      0

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

                        0

                        А простите, вы первый мой комментарий читали? Или проигнорировали?
                        А если взять в работу ваше последнее утверждение, то СХД должна просто состоять из кэша в оперативной памяти и видимо CPU. А это почему-то все еще не так, хотя к этому постепенно идет. А значит service time диска в принципе по физическим причинам не может равняться response time на сервере, где работает приложение, так то SAN тоже ни куда пока не делась со всеми ее компонентами. Но вы можете и дальше продолжать заново изобретать теорию построения своего велосипеда, игнорируя давно придуманное и устоявшееся. Прежде чем о чем-то спорить вы хотя бы с основами, теорией и устоявшейся в отрасли терминологией разберитесь.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое