Сегодня рост объема данных на человека растет в геометрической прогрессии, а компании, предлагающие решения для хранения этих данных, стремятся сделать все возможное, чтобы увеличить доступную емкость своих устройств. Технология черепичной магнитной записи Seagate SMR (Shingled Magnetic Recording) позволяет повысить плотность записи, за счет чего емкость диска увеличивается на 25%. Это возможно благодаря увеличению количества дорожек на каждой пластине и сокращению расстояния между ними. Дорожки размещаются друг над другом (как черепица на крыше), что позволяет записать больше данных, не увеличивая площади пластины. При записи новых данных дорожки частично накладываются друг на друга, или «усекаются». Ввиду того, что считывающий элемент на дисковой головке меньше записывающего, он может считывать данные даже с усеченной дорожки, не нарушая их целостности и достоверности.
Однако с технологией SMR связана следующая проблема: чтобы перезаписать или обновить информацию, необходимо переписать не только требуемый фрагмент, но и данные на последних дорожках. Из-за того, что записывающий элемент шире, он захватывает данные на граничащих дорожках, поэтому необходимо перезаписать и их. Таким образом, при изменении данных на нижней дорожке нужно скорректировать данные на ближайшей наложенной дорожке, потом на следующей, и так далее, пока не будет переписана вся пластина.
По этой причине дорожки SMR-диска объединены в небольшие группы, называемые лентами. Накладываются друг на друга, соответственно, только дорожки в пределах одной ленты. Благодаря такому группированию в случае обновления некоторых данных перезаписывать придется не всю пластину, а лишь ограниченное количество дорожек, что существенно упрощает и ускоряет процесс. Для каждого типа дисков разрабатывается своя архитектура ленты с учетом сферы его применения. Каждая линейка продуктов Seagate рассчитана на определенную сферу применения и конкретные условия работы, и технология SMR позволяет достичь при правильном использовании наилучших результатов.
Seagate SMR — это технология, позволяющая удовлетворить постоянно растущий спрос на дополнительную емкость. На сегодняшний день она активно совершенствуется и в сочетании с другими инновационными методами может быть использована для повышения плотности записи на жестких дисках следующих поколений.
Но прежде всего, необходимо разобраться в некоторых нюансах ее применения.
Выделяют три типа устройств, поддерживающих черепичную запись:
Автономные (Drive Managed)
Работа с этими устройствами не требует никаких изменений в программном обеспечении хоста. Вся логика записи/чтения организована самим устройством. Значит ли, что мы можем просто установить их и расслабиться? Нет.
Диски, в которых реализована Drive Managed технология записи, обычно обладают большим объемом write-back кэша (от 128МБ на диск). При этом последовательные запросы обрабатываются в режиме write-around. Основные сложности, c которыми сталкиваются разработчики устройств и СХД, основанных на данной технологии записи, следующие:
1. Размер кэша лимитирован и по мере его заполнения мы можем получить непредсказуемую производительность устройств.
2. Иногда возникают значительные уровни задержек при интенсивном сбросе кэша.
3. Определение последовательностей — далеко не всегда тривиальная задача, и в сложных случаях мы можем ожидать деградацию производительности.
Основным достоинством данного подхода является полная обратная совместимость устройств с существующими ОС и приложениями. Хорошо понимая вашу задачу, вы можете уже сейчас покупать Drive Managed устройства и получать преимущества от использования технологии. Дальше в статье вы увидите результаты тестирования подобных устройств и сможете определиться, насколько они вам подходят.
Управляемые хостом (Host Managed)
В данных устройствах используется набор расширений к ATA и SCSI для взаимодействия с дисками. Это устройство другого типа (14h), которое требует серьезных изменений во всем Storage Stack и несовместимо с классическими технологиями, то есть без специальной адаптации приложений и операционных систем вы не сможете использовать эти диски. Хост должен выполнять запись на устройства строго последовательно. При этом производительность устройств на 100% предсказуема. Но необходима корректность работы более высокоуровневого ПО для того, чтобы производительность подсистемы хранения была действительно предсказуемой.
Поддерживаемые хостом (Host Aware)
Это гибридные решения, объединяющие преимущества Device Managed и Host Managed технологий. Приобретая такие диски, мы получаем поддержку обратной совместимости с возможностью использования специальных расширений ATA и SCSI для оптимальной работы с SMR-устройствами. То есть мы можем, как просто выполнять запись на устройства, как делали это раньше, так и делать это наиболее оптимальным образом.
Для того, чтобы обеспечить работу с Host Managed и Host Aware устройствами, разрабатывается пара новых стандартов: ZBC и ZAC, которые входят в T10/T13. ZBC является расширение SCSI и ратифицируется T10. Стандарты разрабатываются для SMR дисков, но в будущем могут быть применены и для других устройств.
ZBC/ZAC определяют логическую модель устройств, где основным элементом является зона, которая отображается как диапазон LBA.
Стандарты задают три типа логических зон, на которые разбиты устройства:
1. Conventional zone — зона, с которой мы можем работать традиционным образом, как с обычными жесткими дисками. То есть, можем писать последовательно и случайно.
2. Два типа Write Pointer Zone:
2.1. Sequential write preferred — основной тип зон для Host Aware устройств, отдается предпочтение последовательной записи. Случайная запись на устройства обрабатывается как в Device Managed устройствах и может стать причиной потери производительности.
2.2. Sequential write only — основной тип зон для Host Manged устройств, возможна только последовательная запись. Случайная запись недопустима, при попытках её произвести будет возвращена ошибка.
Каждая зона обладает своим Write Pointer и своим статусом. Для всех устройств, поддерживающих HM тип записи, первый LBA следующей команды записи обязательно должен соответствовать положению Write Pointer. Для HA устройств Write Pointer является информационным и служит для оптимизации работы с диском.
Кроме новой логической структуры в стандартах появляются и новые команды:
REPORT_ZONES является основным методом, благодаря которому можно получить информацию о существующих зонах на устройстве и их статусе. Диск в ответ на эту команду сообщает о существующих зонах, их типах (Conventional, Sequential Write Required, Sequential Write Preferred), состоянии зон, размере, информацию о нахождении Write Pointer.
RESET_WRITE_POINTER является преемником команды TRIM для ZBC устройств. При ее вызове происходит стирание зоны и перемещение Write Pointer на начало зоны.
Для управления статусом зоны используются 3 опциональные команды:
OPEN_ZONE
CLOSE_ZONE
FINISH_ZONE
В VPD страницах появилась новая информация, включая максимальное количество открытых зон, обеспечивающее лучшую производительность и максимальное количество зон, доступных для случайной записи с лучшей производительностью.
Производителям СХД необходимо позаботиться о поддержке устройств HA/HM, внося изменения на всех уровнях стека: библиотеки, планировщики, RAID engine, логические тома, файловые системы.
Кроме того, нужно обеспечить два типа интерфейсов для работы приложений: традиционный интерфейс, организовав массив как device managed устройство, а также реализацию виртуального тома как HOST AWARE устройства. Это необходимо, так как ожидается появление приложений, работающих с HM/HA устройствами напрямую.
В общем виде алгоритм работы с HA устройствами выглядит следующим образом:
1. Определите конфигурацию устройства, использую REPORT_ZONES
2. Определите зоны для случайной записи
2.1. Количество ограничено возможностями устройства
2.2. В этих зонах нет необходимости отслеживать положение Write Pointer
3. Используйте остальные зоны для последовательной записи и используя информацию о положении Write-Pointer и выполняя только последовательную запись
4. Контролируйте количество открытых зон
5. Используйте сборку мусора для высвобождения пула зон
Некоторые техники записи можно применять из имеющихся all-flash СХД, для которых решались проблемы предстательной последовательной записи и сборки мусора.
Компания RAIDIX провела тестирование SMR дисков Seagate у себя в лаборатории и дает несколько рекомендаций по их использованию. Эти диски отличаются тем, что являются Device Managed и не требуют никаких серьезных изменений в работе приложений.
При тестировании была сделана попытка проверить ожидания производительности таких дисков и понять, для чего мы можем их использовать.
В тестах участвовали два диска Seagate Archive HDD объемом 8000GB.
Тестирование выполнялось на операционной системе Debian версии 8.1
CPU Intel i7 c частотой 2,67 MHz
16 GB RAM
Диски имеют интерфейс SATA 3, мы включили контроллер в режим AHCI.
Для начала мы приводим информацию об устройствах, выполнив Inquiry запрос.
Ничего особенного мы не увидели. Попытки прочитать информацию о зонах обернулись неудачей.
RAIDIX делает ПО для СХД, работающих в различных индустриях, и мы стремились не использовать специализированные или платные бенчмарки.
Начинаем с того, что проверяем потоковую производительность дисков на внутренних и внешних дорожках. Результаты тестов дадут максимальную ожидаемую производительность устройства и соответствуют в первую очередь таким задачам, как архивирование данных.
Настройки блочной подсистемы мы не трогали. Выполняем тестирование, записывая на диски данные блоками 1 мегабайт. Для этого мы используем бенчмарк fio v.2.1.11.
Джобы (Jobs) отличаются друг от друга только смещением от начала устройства и запускаются один за другим. В качестве библиотеки ввода-вывода выбрана libaio.
Результаты представляются неплохими:
Производительность на внешних и внутренних дорожках отличается практически в 2 раза.
Мы видим периодические провалы производительности. Они не критичны для архивирования, но могут стать проблемой для других задач. При корректной работе write-back кэша СХД мы предполагаем, что не будем наблюдать подобной ситуации. Мы провели схожий опыт, создав массив RAID 0 из обоих дисков, выделив 2ГБ RAM кэша на каждый диск, и не увидели провалов производительности.
При чтении провалов не видно. И последующие тесты покажут, что на операциях чтения SMR диски по производительности ничем не отличаются от обычных.
Теперь мы проведем более интересные тесты. Запустим 10 потоков c разными offset одновременно. Это мы делаем для того, чтобы проверить корректность буферизации и посмотреть, как диски будут работать на задачах CCTV, Video Ingest и подобных.
На графиках приведена суммарная производительность по всем работам:
Диск неплохо справился с нагрузкой!
Производительность держится на уровне 90 МБ/с, равномерно распределена по потокам, и не наблюдается серьезных провалов. График на чтение абсолютно аналогичен, только приподнят на 20 МБ. Для хранения и раздачи видеоконтента, обмена большими файлами производительность подходящая и практически не отличается от производительности обычных дисков.
Как и ожидалось, диски неплохо показали себя на операциях потоковых чтения и записи, а работа в несколько потоков стала для нас приятным сюрпризом.
Переходим к «случайным» чтению и записи. Посмотрим, как диски поведут себя в классических задачах предприятий: хранение файлов СУБД, виртуализация и пр. Кроме того, в «случайные» операции подпадают частая работа с метаданными и, например, включённая дедупликация на массиве.
Тестирование мы проводим блоками 16 килобайт и по-прежнему верны fio.
В тесте мы настроили несколько джобов с разной глубиной очереди, но полностью результаты приводить не будем. Показательно только начало теста.
Первые 70,5 секунд мы видим нереальные для жесткого диска 2500 IOps. При этом происходят частые провалы. Видимо, в этот момент происходит запись в буфер и его периодический сброс. Потом происходит резкое падение до 3 IOps, которые держатся до конца теста.
Если подождать несколько минут, то после того, как сбросится кэш, ситуация повторится.
Можно ожидать, что при наличии небольшого числа случайных операций диск будет вести себя неплохо. Но если мы ожидаем интенсивную нагрузку на устройство, лучше воздержаться от использования SMR дисков. RAIDIX рекомендует при возможности выносить всю работу с метаданными на внешние устройства.
А что же со случайным чтением?
В этом тесте мы ограничили время отклика 50 мс. Наши устройства справляются неплохо.
Чтение оказывается в промежутке 144-165 IOPs. Сами числа неплохи, но немного пугает разброс в 20 IOPs. Ориентируйтесь на нижнюю границу. Результат неплохой, на уровне классических дисков.
Несколько изменим подход. Давайте еще взглянем на работу с большим количеством файлов.
С этим нам поможет утилита frametest от SGI. Этот бенчмарк создан для проверки производительности СХД при выполнении монтажа несжатого видео. Каждый фрейм является отдельным файлом.
Мы создали файловую систему xfs и смонтировали ее со следующими параметрами:
-o noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,allocsize=131072k,nobarrier
Запускаем frametest со следующими параметрами:
./frametest -w hd -n 2000 /test1/
Бенчмарк создает 2000 файлов размером 8МБ.
Начало теста проходит неплохо:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.028 ms 79.40 ms 79.43 ms 100.37 MB/s 12.6 fps
5s: 0.156 ms 83.37 ms 83.53 ms 95.44 MB/s 12.0 fps
Но после записи 1500 фреймов ситуация значительно ухудшается:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.035 ms 121.88 ms 121.92 ms 65.39 MB/s 8.2 fps
5s: 0.036 ms 120.78 ms 120.83 ms 65.98 MB/s 8.3 fps
Дальше все хуже:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.036 ms 438.90 ms 438.94 ms 18.16 MB/s 2.3 fps
5s: 0.035 ms 393.50 ms 393.55 ms 20.26 MB/s 2.5 fps
Проведем тест на чтение:
./frametest -r hd -n 2000 /test1/
В течение всего теста производительность отличная:
Averaged details:
Last 1s: 0.004 ms 41.09 ms 41.10 ms 193.98 MB/s 24.3 fps
5s: 0.004 ms 41.09 ms 41.10 ms 193.98 MB/s 24.3 fps
Сейчас ведется работа над специализированными файловыми системами для SMR дисков.
Seagate разрабатывает основанную на ext4 SMR_FS-EXT4. Можно обнаружить несколько log-structured файловых систем, спроектированных специально для Device Managed SMR дисков, но ни одну из них нельзя назвать зрелым, рекомендуемым к внедрению продуктом. Также Seagate ведется разработка поддерживаемой хостом (Host Aware) версии SMR диска, которая должна быть завершена до конца года.
Какие мы можем сделать выводы по результатам замеров производительности?
Device Managed устройства можно смело использовать для задач, не отличающихся интенсивной записью. Они очень неплохо справляются с задачами однопоточной и многопоточной записи. Для чтения данных они подходят отлично. Периодические “случайные” запросы к дискам при обновлении метаданных поглощаются большим кэшем.
Для решения задач, отличающихся интенсивной “случайной” записью или обновлением большого количества файлов такие устройства не очень подходят, как минимум, без использования дополнительных технических средств.
Параметр MTBF протестированных дисков составляет 800 000 часов, что в 1,5 раза ниже, чем у, например, NAS-дисков. Большой объем дисков значительно увеличивает время восстановления и делает практически невозможным регулярный media-скан. Мы рекомендуем при проектировании хранилища с такими дисками полагаться на RAID с количеством parity, большим чем 2 и/или подходах позволяющих сократить время восстановления (Например, Parity Declustering).
Однако с технологией SMR связана следующая проблема: чтобы перезаписать или обновить информацию, необходимо переписать не только требуемый фрагмент, но и данные на последних дорожках. Из-за того, что записывающий элемент шире, он захватывает данные на граничащих дорожках, поэтому необходимо перезаписать и их. Таким образом, при изменении данных на нижней дорожке нужно скорректировать данные на ближайшей наложенной дорожке, потом на следующей, и так далее, пока не будет переписана вся пластина.
По этой причине дорожки SMR-диска объединены в небольшие группы, называемые лентами. Накладываются друг на друга, соответственно, только дорожки в пределах одной ленты. Благодаря такому группированию в случае обновления некоторых данных перезаписывать придется не всю пластину, а лишь ограниченное количество дорожек, что существенно упрощает и ускоряет процесс. Для каждого типа дисков разрабатывается своя архитектура ленты с учетом сферы его применения. Каждая линейка продуктов Seagate рассчитана на определенную сферу применения и конкретные условия работы, и технология SMR позволяет достичь при правильном использовании наилучших результатов.
Seagate SMR — это технология, позволяющая удовлетворить постоянно растущий спрос на дополнительную емкость. На сегодняшний день она активно совершенствуется и в сочетании с другими инновационными методами может быть использована для повышения плотности записи на жестких дисках следующих поколений.
Но прежде всего, необходимо разобраться в некоторых нюансах ее применения.
Выделяют три типа устройств, поддерживающих черепичную запись:
Автономные (Drive Managed)
Работа с этими устройствами не требует никаких изменений в программном обеспечении хоста. Вся логика записи/чтения организована самим устройством. Значит ли, что мы можем просто установить их и расслабиться? Нет.
Диски, в которых реализована Drive Managed технология записи, обычно обладают большим объемом write-back кэша (от 128МБ на диск). При этом последовательные запросы обрабатываются в режиме write-around. Основные сложности, c которыми сталкиваются разработчики устройств и СХД, основанных на данной технологии записи, следующие:
1. Размер кэша лимитирован и по мере его заполнения мы можем получить непредсказуемую производительность устройств.
2. Иногда возникают значительные уровни задержек при интенсивном сбросе кэша.
3. Определение последовательностей — далеко не всегда тривиальная задача, и в сложных случаях мы можем ожидать деградацию производительности.
Основным достоинством данного подхода является полная обратная совместимость устройств с существующими ОС и приложениями. Хорошо понимая вашу задачу, вы можете уже сейчас покупать Drive Managed устройства и получать преимущества от использования технологии. Дальше в статье вы увидите результаты тестирования подобных устройств и сможете определиться, насколько они вам подходят.
Управляемые хостом (Host Managed)
В данных устройствах используется набор расширений к ATA и SCSI для взаимодействия с дисками. Это устройство другого типа (14h), которое требует серьезных изменений во всем Storage Stack и несовместимо с классическими технологиями, то есть без специальной адаптации приложений и операционных систем вы не сможете использовать эти диски. Хост должен выполнять запись на устройства строго последовательно. При этом производительность устройств на 100% предсказуема. Но необходима корректность работы более высокоуровневого ПО для того, чтобы производительность подсистемы хранения была действительно предсказуемой.
Поддерживаемые хостом (Host Aware)
Это гибридные решения, объединяющие преимущества Device Managed и Host Managed технологий. Приобретая такие диски, мы получаем поддержку обратной совместимости с возможностью использования специальных расширений ATA и SCSI для оптимальной работы с SMR-устройствами. То есть мы можем, как просто выполнять запись на устройства, как делали это раньше, так и делать это наиболее оптимальным образом.
Для того, чтобы обеспечить работу с Host Managed и Host Aware устройствами, разрабатывается пара новых стандартов: ZBC и ZAC, которые входят в T10/T13. ZBC является расширение SCSI и ратифицируется T10. Стандарты разрабатываются для SMR дисков, но в будущем могут быть применены и для других устройств.
ZBC/ZAC определяют логическую модель устройств, где основным элементом является зона, которая отображается как диапазон LBA.
Стандарты задают три типа логических зон, на которые разбиты устройства:
1. Conventional zone — зона, с которой мы можем работать традиционным образом, как с обычными жесткими дисками. То есть, можем писать последовательно и случайно.
2. Два типа Write Pointer Zone:
2.1. Sequential write preferred — основной тип зон для Host Aware устройств, отдается предпочтение последовательной записи. Случайная запись на устройства обрабатывается как в Device Managed устройствах и может стать причиной потери производительности.
2.2. Sequential write only — основной тип зон для Host Manged устройств, возможна только последовательная запись. Случайная запись недопустима, при попытках её произвести будет возвращена ошибка.
Каждая зона обладает своим Write Pointer и своим статусом. Для всех устройств, поддерживающих HM тип записи, первый LBA следующей команды записи обязательно должен соответствовать положению Write Pointer. Для HA устройств Write Pointer является информационным и служит для оптимизации работы с диском.
Кроме новой логической структуры в стандартах появляются и новые команды:
REPORT_ZONES является основным методом, благодаря которому можно получить информацию о существующих зонах на устройстве и их статусе. Диск в ответ на эту команду сообщает о существующих зонах, их типах (Conventional, Sequential Write Required, Sequential Write Preferred), состоянии зон, размере, информацию о нахождении Write Pointer.
RESET_WRITE_POINTER является преемником команды TRIM для ZBC устройств. При ее вызове происходит стирание зоны и перемещение Write Pointer на начало зоны.
Для управления статусом зоны используются 3 опциональные команды:
OPEN_ZONE
CLOSE_ZONE
FINISH_ZONE
В VPD страницах появилась новая информация, включая максимальное количество открытых зон, обеспечивающее лучшую производительность и максимальное количество зон, доступных для случайной записи с лучшей производительностью.
Производителям СХД необходимо позаботиться о поддержке устройств HA/HM, внося изменения на всех уровнях стека: библиотеки, планировщики, RAID engine, логические тома, файловые системы.
Кроме того, нужно обеспечить два типа интерфейсов для работы приложений: традиционный интерфейс, организовав массив как device managed устройство, а также реализацию виртуального тома как HOST AWARE устройства. Это необходимо, так как ожидается появление приложений, работающих с HM/HA устройствами напрямую.
В общем виде алгоритм работы с HA устройствами выглядит следующим образом:
1. Определите конфигурацию устройства, использую REPORT_ZONES
2. Определите зоны для случайной записи
2.1. Количество ограничено возможностями устройства
2.2. В этих зонах нет необходимости отслеживать положение Write Pointer
3. Используйте остальные зоны для последовательной записи и используя информацию о положении Write-Pointer и выполняя только последовательную запись
4. Контролируйте количество открытых зон
5. Используйте сборку мусора для высвобождения пула зон
Некоторые техники записи можно применять из имеющихся all-flash СХД, для которых решались проблемы предстательной последовательной записи и сборки мусора.
Компания RAIDIX провела тестирование SMR дисков Seagate у себя в лаборатории и дает несколько рекомендаций по их использованию. Эти диски отличаются тем, что являются Device Managed и не требуют никаких серьезных изменений в работе приложений.
При тестировании была сделана попытка проверить ожидания производительности таких дисков и понять, для чего мы можем их использовать.
В тестах участвовали два диска Seagate Archive HDD объемом 8000GB.
Тестирование выполнялось на операционной системе Debian версии 8.1
CPU Intel i7 c частотой 2,67 MHz
16 GB RAM
Диски имеют интерфейс SATA 3, мы включили контроллер в режим AHCI.
Для начала мы приводим информацию об устройствах, выполнив Inquiry запрос.
Для этого мы использовали набор утилит sg3-utils.
sg_inq /dev/sdb
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=0
[SPI: Clocking=0x0 QAS=0 IUS=0]
length=96 (0x60) Peripheral device type: disk
Vendor identification: ATA
Product identification: ST8000AS0002-1NA
Product revision level: AR13
Unit serial number: Z84011LQ
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=0
[SPI: Clocking=0x0 QAS=0 IUS=0]
length=96 (0x60) Peripheral device type: disk
Vendor identification: ATA
Product identification: ST8000AS0002-1NA
Product revision level: AR13
Unit serial number: Z84011LQ
На 83 странице находится VPD.
sg_inq /dev/sdb -p 0x83
VPD INQUIRY: Device Identification page
Designation descriptor number 1, descriptor length: 24
designator_type: vendor specific [0x0], code_set: ASCII
associated with the addressed logical unit
vendor specific: Z84011LQ
Designation descriptor number 2, descriptor length: 72
designator_type: T10 vendor identification, code_set: ASCII
associated with the addressed logical unit
vendor id: ATA
vendor specific: ST8000AS0002-1NA17Z Z84011LQ
VPD INQUIRY: Device Identification page
Designation descriptor number 1, descriptor length: 24
designator_type: vendor specific [0x0], code_set: ASCII
associated with the addressed logical unit
vendor specific: Z84011LQ
Designation descriptor number 2, descriptor length: 72
designator_type: T10 vendor identification, code_set: ASCII
associated with the addressed logical unit
vendor id: ATA
vendor specific: ST8000AS0002-1NA17Z Z84011LQ
Ничего особенного мы не увидели. Попытки прочитать информацию о зонах обернулись неудачей.
RAIDIX делает ПО для СХД, работающих в различных индустриях, и мы стремились не использовать специализированные или платные бенчмарки.
Начинаем с того, что проверяем потоковую производительность дисков на внутренних и внешних дорожках. Результаты тестов дадут максимальную ожидаемую производительность устройства и соответствуют в первую очередь таким задачам, как архивирование данных.
Настройки блочной подсистемы мы не трогали. Выполняем тестирование, записывая на диски данные блоками 1 мегабайт. Для этого мы используем бенчмарк fio v.2.1.11.
Джобы (Jobs) отличаются друг от друга только смещением от начала устройства и запускаются один за другим. В качестве библиотеки ввода-вывода выбрана libaio.
Результаты представляются неплохими:
Производительность на внешних и внутренних дорожках отличается практически в 2 раза.
Мы видим периодические провалы производительности. Они не критичны для архивирования, но могут стать проблемой для других задач. При корректной работе write-back кэша СХД мы предполагаем, что не будем наблюдать подобной ситуации. Мы провели схожий опыт, создав массив RAID 0 из обоих дисков, выделив 2ГБ RAM кэша на каждый диск, и не увидели провалов производительности.
При чтении провалов не видно. И последующие тесты покажут, что на операциях чтения SMR диски по производительности ничем не отличаются от обычных.
Теперь мы проведем более интересные тесты. Запустим 10 потоков c разными offset одновременно. Это мы делаем для того, чтобы проверить корректность буферизации и посмотреть, как диски будут работать на задачах CCTV, Video Ingest и подобных.
На графиках приведена суммарная производительность по всем работам:
Диск неплохо справился с нагрузкой!
Производительность держится на уровне 90 МБ/с, равномерно распределена по потокам, и не наблюдается серьезных провалов. График на чтение абсолютно аналогичен, только приподнят на 20 МБ. Для хранения и раздачи видеоконтента, обмена большими файлами производительность подходящая и практически не отличается от производительности обычных дисков.
Как и ожидалось, диски неплохо показали себя на операциях потоковых чтения и записи, а работа в несколько потоков стала для нас приятным сюрпризом.
Переходим к «случайным» чтению и записи. Посмотрим, как диски поведут себя в классических задачах предприятий: хранение файлов СУБД, виртуализация и пр. Кроме того, в «случайные» операции подпадают частая работа с метаданными и, например, включённая дедупликация на массиве.
Тестирование мы проводим блоками 16 килобайт и по-прежнему верны fio.
В тесте мы настроили несколько джобов с разной глубиной очереди, но полностью результаты приводить не будем. Показательно только начало теста.
Первые 70,5 секунд мы видим нереальные для жесткого диска 2500 IOps. При этом происходят частые провалы. Видимо, в этот момент происходит запись в буфер и его периодический сброс. Потом происходит резкое падение до 3 IOps, которые держатся до конца теста.
Если подождать несколько минут, то после того, как сбросится кэш, ситуация повторится.
Можно ожидать, что при наличии небольшого числа случайных операций диск будет вести себя неплохо. Но если мы ожидаем интенсивную нагрузку на устройство, лучше воздержаться от использования SMR дисков. RAIDIX рекомендует при возможности выносить всю работу с метаданными на внешние устройства.
А что же со случайным чтением?
В этом тесте мы ограничили время отклика 50 мс. Наши устройства справляются неплохо.
Чтение оказывается в промежутке 144-165 IOPs. Сами числа неплохи, но немного пугает разброс в 20 IOPs. Ориентируйтесь на нижнюю границу. Результат неплохой, на уровне классических дисков.
Несколько изменим подход. Давайте еще взглянем на работу с большим количеством файлов.
С этим нам поможет утилита frametest от SGI. Этот бенчмарк создан для проверки производительности СХД при выполнении монтажа несжатого видео. Каждый фрейм является отдельным файлом.
Мы создали файловую систему xfs и смонтировали ее со следующими параметрами:
-o noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,allocsize=131072k,nobarrier
Запускаем frametest со следующими параметрами:
./frametest -w hd -n 2000 /test1/
Бенчмарк создает 2000 файлов размером 8МБ.
Начало теста проходит неплохо:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.028 ms 79.40 ms 79.43 ms 100.37 MB/s 12.6 fps
5s: 0.156 ms 83.37 ms 83.53 ms 95.44 MB/s 12.0 fps
Но после записи 1500 фреймов ситуация значительно ухудшается:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.035 ms 121.88 ms 121.92 ms 65.39 MB/s 8.2 fps
5s: 0.036 ms 120.78 ms 120.83 ms 65.98 MB/s 8.3 fps
Дальше все хуже:
Averaged details:
Open I/O Frame Data rate Frame rate
Last 1s: 0.036 ms 438.90 ms 438.94 ms 18.16 MB/s 2.3 fps
5s: 0.035 ms 393.50 ms 393.55 ms 20.26 MB/s 2.5 fps
Проведем тест на чтение:
./frametest -r hd -n 2000 /test1/
В течение всего теста производительность отличная:
Averaged details:
Last 1s: 0.004 ms 41.09 ms 41.10 ms 193.98 MB/s 24.3 fps
5s: 0.004 ms 41.09 ms 41.10 ms 193.98 MB/s 24.3 fps
Сейчас ведется работа над специализированными файловыми системами для SMR дисков.
Seagate разрабатывает основанную на ext4 SMR_FS-EXT4. Можно обнаружить несколько log-structured файловых систем, спроектированных специально для Device Managed SMR дисков, но ни одну из них нельзя назвать зрелым, рекомендуемым к внедрению продуктом. Также Seagate ведется разработка поддерживаемой хостом (Host Aware) версии SMR диска, которая должна быть завершена до конца года.
Какие мы можем сделать выводы по результатам замеров производительности?
Device Managed устройства можно смело использовать для задач, не отличающихся интенсивной записью. Они очень неплохо справляются с задачами однопоточной и многопоточной записи. Для чтения данных они подходят отлично. Периодические “случайные” запросы к дискам при обновлении метаданных поглощаются большим кэшем.
Для решения задач, отличающихся интенсивной “случайной” записью или обновлением большого количества файлов такие устройства не очень подходят, как минимум, без использования дополнительных технических средств.
Параметр MTBF протестированных дисков составляет 800 000 часов, что в 1,5 раза ниже, чем у, например, NAS-дисков. Большой объем дисков значительно увеличивает время восстановления и делает практически невозможным регулярный media-скан. Мы рекомендуем при проектировании хранилища с такими дисками полагаться на RAID с количеством parity, большим чем 2 и/или подходах позволяющих сократить время восстановления (Например, Parity Declustering).
