Диагностика raid массивов утилита
Тестирование «настоящих» аппаратных RAID-контроллеров является очень непростым занятием. Основных причин тому несколько. Первая – сложность сбора тестового стенда соответствующего уровня. Если делать все «правильно», то потребуется много жестких дисков, соответствующий корпус и достаточно мощная серверная платформа, в некоторых случаях – еще и быстрая сеть и клиенты. Вторая проблема заключается в том, что в большинстве случаев подбор конфигурации СХД – задача под конкретного заказчика и конкретные приложения. При этом вариантов существует слишком много, что бы можно было за разумное время охватить их все. Третий вопрос касается выбора тестовых приложений и сценариев. На практике потребителя интересуют именно его задачи с определенной нагрузкой, тогда как в лаборатории в данном случае обычно удобнее использовать синтетику.
Тем не менее, когда появилась возможность в некотором приближении разобраться с первой проблемой, захотелось вернуться к этому вопросу и попробовать провести для начала несколько тестов. Безусловно, выбранные конфигурации и бенчмарки, вызовут множество вопросов у читателей, особенно если они являются профессионалами в данной области. Но просьба отнестись к этому материалу как попытке возрождения обсуждения темы и в комментариях предложить идеи (желательно конструктивные), как, что и почему было бы интересно исследовать в рамках данного направления. Двигаться есть куда, но направлений слишком много и выбрать интересные можно только с вашей помощью.
Напомним, как и для чего используются RAID-массивы и контроллеры на традиционных винчестерах. Ключевых причин три. Первая – необходимость создания дисковых томов большого объема. Одиночные диски сейчас есть на 12 ТБ, так что если нужно больше – придется использовать несколько дисков. Вторая – требование высокой скорости чтения и записи. Один винчестер способен показать максимально около 200 МБ/с, так что если нужно больше – тоже требуется подключить несколько дисков и обеспечить возможность одновременной работы с ними. Третий момент, непосредственно связанный с первыми двумя, – реализация отказоустойчивого массива. Обратите внимание, что речь идет исключительно о сохранении данных при выходе из строя диска (или дисков), что конечно связано с общим понятием «надежность хранения», но не заменяет такой операции, как создание резервных копий. Именно последняя позволяет обеспечить восстановление в случае таких неприятностей, как удаление или изменение файлов.
Данное тестирование проводилось на сервере с платформой Supermicro X8SIL, процессором Intel Xeon X3430 и 8 ГБ оперативной памяти. Ему уже около десяти лет и конечно он как минимум морально устарел. Но, пожалуй, единственной серьезной претензией здесь может быть отсутствие поддержки PCIe 3.0. С другой стороны, 8 линий PCIe 2.0 – это тоже неплохо для массива из нескольких жестких дисков.
Конфигурация массива – RAID6, размер блока 256 КБ. Все кэши для тома на контроллерах включены, остальные параметры по умолчанию, все контроллеры использовали батареи для резервного питания. Напомним, что для данных поколений адаптеров Adaptec можно переносить массивы без потери конфигурации и данных (причем не только «вверх», но и «вниз»), что, безусловно, очень удобно.
Для операционной системы в сервере был выбран Debian 9. Как обычно, со всеми обновлениями на момент проведения тестирования. Драйвера для контроллеров из состава дистрибутива, BIOS обновлены, для удобства управления установлен последний MaxView Storage Manager.
Тесты проводились на «сыром» томе, что еще больше уводит нас в сторону синтетики, однако позволяет более точно оценить возможности аппаратной конфигурации. В реальности же приложения и пользователи обычно работают с файлами, которые размещены на какой-то файловой системе, а доступ к ним может осуществляться не только локально, но и по сети с использованием определенных протоколов. И конечно все это заслуживает отдельного изучения.
В роли тестового пакета выступала утилита fio, в некоторой степени аналогичная известному пакету iometer. В отличие от него, она корректно работает в современных Linux и позволяет оценить сразу несколько параметров.
Файлы конфигурации утилиты имели следующий вид:
[test]
blocksize=256k | 4k
filename=/dev/sda
rw=read | write | randread | randwrite
direct=1
ioengine=libaio
iodepth=1 | 2 | 4 | 8 | 16 | 32 | 64
runtime=180
Где «|» подразумевает выбор одного из значений. Таким образом, исследовались операции последовательного чтения и записи с блоками размером 256 КБ и случайного чтения и записи с блоками по 4 КБ. Все тесты прогонялись с глубиной очереди от 1 до 64 и каждый занимал три минуты. По результатам смотрим на скорости в МБ/с, IOPS и задержки (clat avg в мс). При повторении обязательно перепроверьте имя устройства (filename=/dev/sda). Неверное указание этого параметра на тестах записи может привести к потере данных.
Как мы видим, опций у теста много. Кроме того, можно запустить и одновременно несколько операций. Так что все сочетания проверить просто невозможно и при выборе параметров стоит ориентироваться на характерные для требуемого варианта использования схемы. Ну и не будем забывать, что при особом старании (или везении) можно «положить» любую систему
Учитывая, что в массиве только восемь дисков, скорее всего, некоторые из характеристик будут ограничиваться именно возможностями диска, а не использованного контроллера. Последние, напомним, отличаются производительностью процессора, объемом памяти и некоторыми другими характеристиками.
Сначала стоит сделать замечание об использованном формате диаграмм. На каждом графике приводятся сразу два показателя – производительности и средней задержки в зависимости от параметра iodepth теста. При этом для последовательных операций мы выбрали более привычный показатель в мегабайтах в секунду, а для случайных – iops. В данном конкретном случае с фиксированным размером блока они прямо пропорциональны и равноценны с точки зрения оценки результата.
Начнем с наименее быстрого контроллера Adaptec ASR-6805, который появился на рынке более семи лет назад. Интересно, что, несмотря на его возраст, данная линейка все еще востребована потребителями, как бы странно это не звучало.
Кстати, заодно опишем схему именований – первая цифра показывает поколение, вторая (точнее одна или две – встречается и вариант 16) – число внутренних физических портов (объединенных по четыре в разъёмы SAS различных форматов), третья – число внешних портов, пятая указывает на тип шины (5 – это PCI Express). Дополнительно могут присутствовать суффиксы, указывающие на тип разъемов, сокращенный объем кэшпамяти, наличие дополнительных функций.
Итак, последовательные операции.
На чтении с нашего массива контроллер может обеспечить до 900 МБ/с. Судя по близости последней пары показателей и резкому росту задержек в последней точке, дальнейшего увеличения скорости можно не ждать. Очевидно, что при повышении глубины очереди будут только повышаться задержки, при этом общая скорость останется на указанном уровне.
На операциях записи картина немного иная – максимальное значение в 500 МБ/с достигается сразу на минимальной нагрузке. В дальнейшем мы видим только рост задержек при увеличении глубины очереди.
Таким образом, поставив целью допустимое время отклика массива, вы можете оценить возможную нагрузку по максимальному числу обращений.
Безусловно, если задача требует исключительно случайных операций доступа к данным, то сразу на ум приходит использование SSD, обеспечивающих просто совершенно другой уровень производительности. И проводимые на массиве тесты этого сценария являются в скорее иллюстрацией «самой плохой ситуации», чем отражением реального положения дел на практических задачах.
На чтении массив не вносит никаких «скрытых» расходов и мы видим рост IOPS при увеличении глубины очереди с одновременным ростом задержек. С этим контроллером я не проверял следующие значения iodepth, но как будет показано далее, IOPS имеют свой предел, после которого будет только расти время отклика с сохранением общей скорости. На график записи лучше не смотреть. Все очень и очень грустно. Накладные расходы RAID6 на операциях записи часто оцениваются как число дисков*IOPS одного диска/6. То есть на одну операцию записи контроллеру требуется по факту провести шесть операций (не считая математических расчетов) – чтение исходного блока, чтение двух блоков четности, пересчет, запись трех измененных блоков.
При случайной записи при любой глубине очереди производительность ограничена на уровне 300 IOPS (примерно 1 МБ/с) и сделать здесь почти ничего нельзя. К счастью, в реальной жизни ситуация необходимости 100% случайного доступа к десяткам терабайт данных случается редко, а кроме того, на помощь приходит кэш операционной системы.
Итак, для ASR-6805 на наших шаблонах мы получили – последовательное чтение и запись на уровне 900 и 500 МБ/с соответственно, случайное чтение и запись – примерно 1000 и 300 IOPS.
Переходим к следующему участнику. Модели ASR-7805 около четырех лет. Ключевые отличия этого поколения от прошлого – увеличение производительности процессора, в два раза больше объем кэшпамяти, шина PCIe 3.0, поддержка режима HBA, работа с ленточными библиотеками.
В целом, зависимость производительности от нагрузки сохраняется, но есть и некоторые отличия. На последовательном чтении можно получить более 900 МБ/с, но только при относительно небольшой глубине очереди, тогда как значения для последних строк существенно ниже. Аналогичная ситуация и с последовательной записью – если нагрузка невелика, то скорость близка к 700 МБ/с, но при росте глубины очереди она падает до 630 МБ/с.
На случайном чтении мы видим те же 1000 IOPS, а вот с записью данный контроллер справляется лучше – он способен обеспечить почти 400 IOPS.
Дополнительно с этим контроллером я протестировал случайное чтение с существенным увеличением глубины очереди.
Как и говорилось выше, на этом шаблоне можно получить и более высокие значения производительности, но цена (рост задержек) все-таки слишком высока. Итого для этой модели максимальные показатели составили – 960 и 680 МБ/с на последовательном чтении и записи, 1100 и 400 IOPS на случайном чтении и записи.
Последняя протестированная модель контроллера – ASR-81605ZQ. В данном материале ее дополнительные возможности (в частности, MaxCache) не использовались, так что результаты будут применимы и к «обычному» представителю серии. Эта линейка является последней актуальной из традиционных продуктов со стеком Adaptec. Более новые решения серии SmartRAID – это уже совершенно другая история. В восьмой серии появилась поддержка 12 Гбит/с SAS, накопителей с секторами 4kn, UEFI BIOS. Все это для данного теста не актуально.
На последовательном чтении уже нет такого эффекта, как у седьмой серии и при любой нагрузке можно получить около 1000 МБ/с. Запись также дает более стабильные результаты на уровне 700 МБ/с. Обратим также внимание на то, что задержки при той же нагрузке меньше, чем у прошлой модели.
На операциях случайного чтения все упирается в диски и мы снова видим те же 1100 IOPS в сочетании с 60 мс откликом. Да и запись тоже мало отличается от прошлой модели – около 400 IOPS.
По итогам тестирования можно сделать несколько выводов. Прежде всего, напомним, что касаются они исключительно протестированной конфигурации дискового массива. Во-первых, 6-я серия все еще может быть интересна для реальной работы. Во-вторых, более современные поколения хотя и показывают результаты выше, говорить о каком-то существенном их превосходстве пожалуй не стоит. Особенно это заметно на сравнении серий 7 и 8. Так что если в вашем сервере или СХД применяются массивы из относительно небольшого количества SATA винчестеров, можно обеспечить их эффективное (насколько это возможно) использование на любом из данных контроллеров. Но если встают вопросы производительности на случайных операциях в сочетании с томом большого объема, то к ним нужно подходить более внимательно. Привычный RAID6 на базе жестких дисков не способен здесь показать высокие результаты даже на современных аппаратных контроллерах. Да и случайное чтение тоже является непростой задачей для такой конфигурации.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
в бухгалтерии стоит старенький depo сервер, на нем крутится терминальная служба и 1с, в одной из баз исчезли некоторые данные из справочников. 1с ники кричат, что системный сбой и типа скорее всего диск посыпался. на морде есть индикация, но она не отображает работу рейда. башенное исполнение, какой контролер не знаю, надо перезагружать, корзины нет.
А посмотреть в Диспетчере Устройств?
Возможно что CrystalDiskInfo сможет показать состояние SMART винчестеров, входящих в ваш RAID: при контроллерах Intel он это уже несколько лет позволяет.
Ну а утилита контроля и обслуживания RAID (или у вас такая не установлена?) позволяет хотя бы качественно оценить состояние дисков, а также произвести анализ и исправление ошибок, связанных с проблемами самого RAID (у них бывают собственные проблемы, не зависящие от входящих в них дисков и их состояния).
SCSI и RAID контроллеры: Intel Embedded Server RAID Technology II
Дисковые устройства: Intel MegaSR SCSI Disk Device Intel MegaSR SCSI Disk Device
RAID Virtual Device
PCI-устройство: Intel 631xESB/6321ESB - SATA RAID Controller
4 диска, но видно только 2
Физические данные устройства ATA: Barracuda 7200.12 320418 320 ГБ
Тип устройства: SAS
Интерфейс: SATA-II
SMART не виден в CrystalDiskInfo и подобных утилитах, использовал Hirens.BootCD.15.2
Victoria пишет:
Подскажите где утилиту взять о которой вы говорите, я так понял есть утилита контроля RAID, она же позволяет и состояние дисков посмотреть, а так же есть утилиты состояния дисков от самих производителей.
Видимо у вас там два RAID-1 по два диска. И вы видите не физические диски, а фиктивные, которыми и являются RAID (видимо те самые два "Intel MegaSR SCSI Disk Device" – и пускай вас не смущают слова SCSI и SAS).
По поводу утилит – посмотреть Поиском, например запросом (скопировал в запрос вашу информацию без изменений, лишь добавив "utility"): Inte 631xESB/6321ESB - SATA RAID Controller utility. Я знаю, что такая обязана быть – но не знаю, как она звучит конкретно; скорее всего Raid Web Console – и она уже должна бы стоять на вашем сервере, ежели там фабричная установка.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
в бухгалтерии стоит старенький depo сервер, на нем крутится терминальная служба и 1с, в одной из баз исчезли некоторые данные из справочников. 1с ники кричат, что системный сбой и типа скорее всего диск посыпался. на морде есть индикация, но она не отображает работу рейда. башенное исполнение, какой контролер не знаю, надо перезагружать, корзины нет.
А посмотреть в Диспетчере Устройств?
Возможно что CrystalDiskInfo сможет показать состояние SMART винчестеров, входящих в ваш RAID: при контроллерах Intel он это уже несколько лет позволяет.
Ну а утилита контроля и обслуживания RAID (или у вас такая не установлена?) позволяет хотя бы качественно оценить состояние дисков, а также произвести анализ и исправление ошибок, связанных с проблемами самого RAID (у них бывают собственные проблемы, не зависящие от входящих в них дисков и их состояния).
SCSI и RAID контроллеры: Intel Embedded Server RAID Technology II
Дисковые устройства: Intel MegaSR SCSI Disk Device Intel MegaSR SCSI Disk Device
RAID Virtual Device
PCI-устройство: Intel 631xESB/6321ESB - SATA RAID Controller
4 диска, но видно только 2
Физические данные устройства ATA: Barracuda 7200.12 320418 320 ГБ
Тип устройства: SAS
Интерфейс: SATA-II
SMART не виден в CrystalDiskInfo и подобных утилитах, использовал Hirens.BootCD.15.2
Victoria пишет:
Подскажите где утилиту взять о которой вы говорите, я так понял есть утилита контроля RAID, она же позволяет и состояние дисков посмотреть, а так же есть утилиты состояния дисков от самих производителей.
Видимо у вас там два RAID-1 по два диска. И вы видите не физические диски, а фиктивные, которыми и являются RAID (видимо те самые два "Intel MegaSR SCSI Disk Device" – и пускай вас не смущают слова SCSI и SAS).
По поводу утилит – посмотреть Поиском, например запросом (скопировал в запрос вашу информацию без изменений, лишь добавив "utility"): Inte 631xESB/6321ESB - SATA RAID Controller utility. Я знаю, что такая обязана быть – но не знаю, как она звучит конкретно; скорее всего Raid Web Console – и она уже должна бы стоять на вашем сервере, ежели там фабричная установка.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
в бухгалтерии стоит старенький depo сервер, на нем крутится терминальная служба и 1с, в одной из баз исчезли некоторые данные из справочников. 1с ники кричат, что системный сбой и типа скорее всего диск посыпался. на морде есть индикация, но она не отображает работу рейда. башенное исполнение, какой контролер не знаю, надо перезагружать, корзины нет.
А посмотреть в Диспетчере Устройств?
Возможно что CrystalDiskInfo сможет показать состояние SMART винчестеров, входящих в ваш RAID: при контроллерах Intel он это уже несколько лет позволяет.
Ну а утилита контроля и обслуживания RAID (или у вас такая не установлена?) позволяет хотя бы качественно оценить состояние дисков, а также произвести анализ и исправление ошибок, связанных с проблемами самого RAID (у них бывают собственные проблемы, не зависящие от входящих в них дисков и их состояния).
SCSI и RAID контроллеры: Intel Embedded Server RAID Technology II
Дисковые устройства: Intel MegaSR SCSI Disk Device Intel MegaSR SCSI Disk Device
RAID Virtual Device
PCI-устройство: Intel 631xESB/6321ESB - SATA RAID Controller
4 диска, но видно только 2
Физические данные устройства ATA: Barracuda 7200.12 320418 320 ГБ
Тип устройства: SAS
Интерфейс: SATA-II
SMART не виден в CrystalDiskInfo и подобных утилитах, использовал Hirens.BootCD.15.2
Victoria пишет:
Подскажите где утилиту взять о которой вы говорите, я так понял есть утилита контроля RAID, она же позволяет и состояние дисков посмотреть, а так же есть утилиты состояния дисков от самих производителей.
Видимо у вас там два RAID-1 по два диска. И вы видите не физические диски, а фиктивные, которыми и являются RAID (видимо те самые два "Intel MegaSR SCSI Disk Device" – и пускай вас не смущают слова SCSI и SAS).
По поводу утилит – посмотреть Поиском, например запросом (скопировал в запрос вашу информацию без изменений, лишь добавив "utility"): Inte 631xESB/6321ESB - SATA RAID Controller utility. Я знаю, что такая обязана быть – но не знаю, как она звучит конкретно; скорее всего Raid Web Console – и она уже должна бы стоять на вашем сервере, ежели там фабричная установка.
За последние годы мы привыкли что можно и нужно все мониторить, множество инструментов начиная от простых логов, заканчивая Zabbix и все можно связать. Microsoft в свою очередь тоже дала нам отличный инструмент WinRM, с помощью которого мы можем отслеживать состояние операционных систем и не только. Но как всегда есть ложка дегтя, собственно об «обходе» этой ложки дегтя и пойдет речь.
Как выше было сказано, мы имеем все необходимые инструменты для мониторинга IT структуры, но так сложилось что мы не имеем «автоматизированный» инструмент для мониторинга состояния Intel raid массивов в Windows core. Обращаю Ваше внимание на то, что речь идет об обычном «желтом железе».
Все мы знаем что есть софт от Intel, rapid и matrix storage, но к сожалению на стандартном Windows core он не работает, также есть утилита raidcfg32, она работает в режиме командной строки, умеет обслуживать в ручном режиме и показывать статус, тоже в ручном режиме. Думаю Америку не для кого не открыл.
Постоянно в ручном режиме проверять состояние raid или ждать выхода из строя сервера виртуализации не самый лучший выбор.
Для реализации коварного плана по автоматизации мониторинга Intel raid мы используем
основные инструменты:
- Powershell
- EventLog
- Raidcfg32.exe
- Вспомогательные:
- WinRM
- Rsyslog
- LogAnalyzer
Копируем raidcfg32.exe в c:\raidcfg32\
Проверяем корректно ли установлен драйвер:
cmd.exe C:\raidcfg32\raidcfg32.exe /stv
Если получаем состояние raid и дисков, то все ок.
Создаем источник в журнале application:
*Дальше все выполняется в powershell
Выполняем запрос состояния raid, удаляем кавычки для упрощения парсинга, подключаем содержимое файла.
Ищем ключевые слова, если одно из слов ниже будет найдено, то в файле errorRAID.txt появится значение true, это будет говорить о наличии ошибки, если совпадений не найдено, то будет записано значение false.
Подключаем файл с записаными true и false, ищем в файле true, если true найдено то заменяем его на Error, заменяем false на Information.
Записывам результат в EntryType.txt
Сохраняем код в *.ps1
Создаем в планировщике задание на запуск скрипта, я запускаю задание 1 раз в сутки и при каждой загрузке.
Если будет производится сбор логов другой Windows ОС в Eventlog, то на коллекторе логов необходимо создать источник «RAID», пример есть выше.
Мы транспортируем логи в rsyslog через Adison rsyslog для Windows.
На выходе получается вот такая картинка:
UPD.
По поводу использования store space, все сервера с windows core на борту используются в филиалах, в филиале установлен только 1 сервер и для получения «бесплатного» гипервизора и уменьшения стоимости лицензии используется именно core.
UPD2.
В zabbix конфиг на клиенте вносим:
UserParameter=raid.status,powershell c:\raidcfg32\raidstatusZabbix.ps1
В zabbix добавляем новый элемент данных raid.status, числовой. Создаём триггер — если 0 то всё хорошо, если 1 то беда.
Скрипт ps2 немного меняется:
Читайте также: