Тестирование производительности HP P2000 MSA G3
В одной из наших прошлых статей, посвященной производительности дисковых систем серверов, мы рассказали о методике тестирования и подборе инструмента.
Сейчас же, решили сравнить производительность СХД начального уровня и массива на контроллере P410. Напомню, что интересующие нас параметры: IOPS — количество дисковых операций в секунду (чем больше, тем лучше) и latency — время обработки операции (чем меньше, тем лучше).
Тестировали все той же утилитой fio под Debian GNU/Linux по методике, описанной в предыдущей статье, используя тот же самый инструментарий. Все так же обращаемся к raw-device через libaio.
Конфигурация следующая: объем LUN’ов равен объему Vdisk’a и во всех конфигурациях используется RAID10, включен multipathing, подключение через Fiber Channel.
Тестировали с наращиванием количества потоков от 16 до 256, дабы отловить, где начинаются нехватки производительности. Длительность каждого теста 40 минут.
Итак, рассмотрим результаты на примере профиля OLTP-DB, проиллюстрировав зависимость IOPS и отзывчивости системы от количества потоков:
Размер блока 4KB, 70%/30% чтение/запись, 100% случайный доступ
Глядя на верхний график, становится понятно, как можно оценить производительность системы в отрыве от latency: как только рост количества IOPS застопорился, мы получили результат и дальше расти будет только latency.
Неожиданным оказалось, что массив из восьми дисков показывает куда более высокую производительность чем СХД с тем же количеством носителей, и особенно хорошо это заметно с ростом нагрузки. MSA P2000 забуксовала на 64 потоках, тогда как рост количества IOPS’ов на контроллере P410 прекратился на 128.
Также прекрасно видна зависимость производительности системы от количества жестких дисков в массиве. Здесь, думаю комментарии излишни.
А вывод из этого можно сделать следующий: данную СХД имеет смысл использовать, когда требуется большая гибкость по распределению дискового пространства между виртуальными или физическими серверами и нужна возможность подключить большое количество жестких дисков, в том числе и через полки расширения. Однако, надеяться на то, что все это будет работать быстрее локального дискового массива сервера с тем же количеством дисков, увы, не приходится.
Конфигурируем дисковые системы HP StorageWorks MSA 2000sa
Виртуальный диск (vdisk) — это группа дисков, объединенных в RAID-группу, при этом отдельные виртуальные диски могут формироваться различным уровнем RAID. В состав виртуального диска могут входить либо устройства SATA, либо SAS. но смешивать их нельзя. В системе HP StorageWorks MSA2000 может быть до 16 виртуальных дисков на контроллер — максимум 32 виртуальных диска в двухконтроллерной конфигурации.
Создавая дисковые группы, виртуальные диски целесообразнее укрупнять, а не дробить. В RAID 3-конфигурациях с точки зрения эффективного использования пространства иметь много " мелких" виртуальных дисков неэффективно -если в группе из двенадцати дисков служебным (на нем хранятся контрольные суммы) является только один, а одиннадцать заняты данными, то в четырех группах, содержащих по три диска, служебных будет уже четыре, а «полезных» — восемь.
Объем виртуального диска может превышать 2 Гбайт, поэтому, создавая диски большого объема в массивах RAID с контролем четности, число служебных дисков можно сократить, однако в общем случае для работы с логическими томами объемом свыше 2 Тбайт могут потребоваться специальные версии операционных систем, адаптеров НВА и поддержка прикладных программ.
Кстати, устройство MSA2000sa поддерживает виртуальные диски объемом до 16 Тбайт. В RAID 0,3,5,6, 10 может быть до 16 дисков (1 Тбайт на устройство SATA, или всего 16 Тбайт). В RAID 50 может быть до 32 дисков (1 Тбайт на устройство SATA, или всего 32 Тбайт).
При организации больших объемов внешней памяти следует тщательно взвесить преимущества и недостатки нескольких укрупненных виртуальных дисков по сравнению с большим числом менее «емких» виртуальных дисков с меньшим количеством накопителей. Чтобы увеличить КПД дисковой памяти (но не производительность), можно создать виртуальные диски объемом больше 2 Тбайт и разделить их на несколько логических томов объемом до 2 Тбайт. Максимально поддерживаемый объем виртуального диска определяется произведением количества дисковых устройств в данной конфигурации RAID на наибольший объем одного устройства.
Лучше всего добавлять виртуальные диски, распределяя их равномерно по обоим контроллерам. Если к каждому контроллеру подсоединить хотя бы по одному виртуальному диску, контроллеры начинают работать по принципy «активный-активный» (active-active). Подобная конфигурация обеспечивает эффективность использования ресурсов в случае применения двух контроллеров в системе хранения MSA2000sa. Кроме того, для предотвращения потери данных при отказе дисковой полки (shelf enclosure) надо целиком сделать «страйпинг» (stripe) виртуальных дисков по нескольким дисковым полкам. Виртуальный диск с конфигурацией RAID 1,10,3,5,50 в зависимости от числа задействованных дисковых полок может противостоять угрозе потери данных при выходе из строя целой дисковой полки.
Создавая виртуальный диск, можно выбрать размер непрерывного фрагмента данных (chunk) по умолчанию или наилучшим образом подходящий для работы с приложением. Размер непрерывного фрагмента (stripe unit) — это количество расположенных друг за другом данных, записываемых на виртуальный диск, после создания которого эту характеристику уже изменить нельзя. Страйп — совокупность непрерывных фрагментов (stripe units), записываемых в одни и те же логические области каждого жесткого диска в составе виртуального. Параметры страйпинга определяются количеством физических жестких дисков в составе виртуального диска. Эти параметры могут меняться. Допустимы значения 16,32 и 64 Кбайт (значение по умолчанию). Например, если хост-сервер отдает данные порциями по 16 Кбайт, то такой размер страйпа при случайном доступе обеспечит равномерное распределение нагрузки по операциям чтения между всеми устройствами, что положительно скажется на производительности. Если же данные запрашиваются по 16 Кбайт, а размер блока данных равен 64 Кбайт, то некоторые операции доступа будут обращаться к одному и тому же жесткому диску — каждый фрагмент страйпа включает в себя четыре возможные группы размером 16 Кбайт, к которым может обратиться хост-сервер, что нельзя признать оптимальным. С другой стороны, если доступ осуществлялся порциями по 128 Кбайт, то при чтении хост-серверу потребуется обращаться к обоим устройствам, составляющим виртуальный диск.
Рекомендуется устанавливать размер непрерывного фрагмента равным размеру блока данных, которым оперирует приложение.
Выбор уровня RAID для массива зависит от цели оптимизации конфигурации: повышение отказоустойчивости или повышение производительности. Если не требуется отказоустойчивость или производительность, обеспечиваемые применением групп RAID, то разумно воспользоваться конфигурациями без избыточности.
media scrub vdisk что это
Что значит
Конфигурируем дисковые системы HP StorageWorks MSA 2000sa
Виртуальные диски
Объем виртуального диска может превышать 2 Гбайт, поэтому, создавая диски большого объема в массивах RAID с контролем четности, число служебных дисков можно сократить, однако в общем случае для работы с логическими томами объемом свыше 2 Тбайт могут потребоваться специальные версии операционных систем, адаптеров НВА и поддержка прикладных программ.
Кстати, устройство MSA2000sa поддерживает виртуальные диски объемом до 16 Тбайт. В RAID 0,3,5,6, 10 может быть до 16 дисков (1 Тбайт на устройство SATA, или всего 16 Тбайт). В RAID 50 может быть до 32 дисков (1 Тбайт на устройство SATA, или всего 32 Тбайт).
При организации больших объемов внешней памяти следует тщательно взвесить преимущества и недостатки нескольких укрупненных виртуальных дисков по сравнению с большим числом менее «емких» виртуальных дисков с меньшим количеством накопителей. Чтобы увеличить КПД дисковой памяти (но не производительность), можно создать виртуальные диски объемом больше 2 Тбайт и разделить их на несколько логических томов объемом до 2 Тбайт. Максимально поддерживаемый объем виртуального диска определяется произведением количества дисковых устройств в данной конфигурации RAID на наибольший объем одного устройства.
Лучше всего добавлять виртуальные диски, распределяя их равномерно по обоим контроллерам. Если к каждому контроллеру подсоединить хотя бы по одному виртуальному диску, контроллеры начинают работать по принципy «активный-активный» (active-active). Подобная конфигурация обеспечивает эффективность использования ресурсов в случае применения двух контроллеров в системе хранения MSA2000sa. Кроме того, для предотвращения потери данных при отказе дисковой полки (shelf enclosure) надо целиком сделать «страйпинг» (stripe) виртуальных дисков по нескольким дисковым полкам. Виртуальный диск с конфигурацией RAID 1,10,3,5,50 в зависимости от числа задействованных дисковых полок может противостоять угрозе потери данных при выходе из строя целой дисковой полки.
Рекомендуется устанавливать размер непрерывного фрагмента равным размеру блока данных, которым оперирует приложение.
Выбор уровня RAID для массива зависит от цели оптимизации конфигурации: повышение отказоустойчивости или повышение производительности. Если не требуется отказоустойчивость или производительность, обеспечиваемые применением групп RAID, то разумно воспользоваться конфигурациями без избыточности.
Тестирование производительности HP P2000 MSA G3
В одной из наших прошлых статей, посвященной производительности дисковых систем серверов, мы рассказали о методике тестирования и подборе инструмента.
Сейчас же, решили сравнить производительность СХД начального уровня и массива на контроллере P410. Напомню, что интересующие нас параметры: IOPS — количество дисковых операций в секунду (чем больше, тем лучше) и latency — время обработки операции (чем меньше, тем лучше).
Тестировали все той же утилитой fio под Debian GNU/Linux по методике, описанной в предыдущей статье, используя тот же самый инструментарий. Все так же обращаемся к raw-device через libaio.
Конфигурация следующая: объем LUN’ов равен объему Vdisk’a и во всех конфигурациях используется RAID10, включен multipathing, подключение через Fiber Channel.
Тестировали с наращиванием количества потоков от 16 до 256, дабы отловить, где начинаются нехватки производительности. Длительность каждого теста 40 минут.
Итак, рассмотрим результаты на примере профиля OLTP-DB, проиллюстрировав зависимость IOPS и отзывчивости системы от количества потоков:
Размер блока 4KB, 70%/30% чтение/запись, 100% случайный доступ
Глядя на верхний график, становится понятно, как можно оценить производительность системы в отрыве от latency: как только рост количества IOPS застопорился, мы получили результат и дальше расти будет только latency.
Неожиданным оказалось, что массив из восьми дисков показывает куда более высокую производительность чем СХД с тем же количеством носителей, и особенно хорошо это заметно с ростом нагрузки. MSA P2000 забуксовала на 64 потоках, тогда как рост количества IOPS’ов на контроллере P410 прекратился на 128.
Также прекрасно видна зависимость производительности системы от количества жестких дисков в массиве. Здесь, думаю комментарии излишни.
А вывод из этого можно сделать следующий: данную СХД имеет смысл использовать, когда требуется большая гибкость по распределению дискового пространства между виртуальными или физическими серверами и нужна возможность подключить большое количество жестких дисков, в том числе и через полки расширения. Однако, надеяться на то, что все это будет работать быстрее локального дискового массива сервера с тем же количеством дисков, увы, не приходится.
И, как всегда, выкладываем детальный файл с результатами.
Ceph: Настройка scrub и снижение его влияния на производительность
Обычно не пишу о том, что и так известно почти всем или если это хорошо освещено. Но недавно в одном популярном русскоязычном telegram-чате посвященном Ceph обсуждалась проблема scrubbing’а и я понял, что все таки знаю кое что, что еще не известно всем) Решил написать заметку посвященную данной теме.
Scrub — служебный механизм призванный проверять целостность копий данных в кластере RADOS. Процесс scrubbing’а идет фоном и циклически перебирает все данные сравнивая одну копию данных на одной OSD с другой копией на другой(или других) OSD.
Проверок бывает два типа: простая(scrubbing) и глубокая(scrubbing+deep)
В рамках простой проверки сверяются только атрибуты фалов и их размер, этот тип проверки безобиден и практически ни оказывает никакого влияния на работу кластера и по этому проводится с частотой в сутки.
При глубокой проверке(scrubbing+deep) проверяемые данные считываются с дисков, считается их контрольная сума и сверяется. Собственно чтение данных и есть проблема. Такие проверки идут с интервалом в неделю.
Естественно проверки не запускаются разом на все данные. В таком случае все вставало бы колом) Разные PG проверяются в разное время. Этот процесс идет не прерывно, сейчас одни проверяются, затем другие а через время опять первые и так без конца.
Так вот когда в кластере появляется нормальное количество данных и они активно используются то вы заметите влияние scrubbing’а даже без мониторинга)
Под нормальным объемом данных я подразумеваю не какой то общий объем данных в кластере а заполненность используемых дисков. Например если у вас диски размером в 2Tb и они заполнены на 50-60 или более процентов то у вас много данных в Ceph, даже если дисков всего шесть). Это моя субъективная метрика но по моему 3-х летнему опыту работы с Ceph в проде — это самый важный критерий.
Собственно когда наши диски достигли такой утилизации мы стали замечать просадки производительности и повышенные задержки во время идущего scrubbing’а. Возможно если бы у нас были SSD мы жили бы счастливо но у нас обычные SATA диски с журналами на SSD.
Так вот, scrubbing. Когда во время идущего скраббинга приходит пользовательская нагрузка на те же OSD что в процессе скраббирга, не заметить это сложно, особенно если у вас есть внешний мониторинг.
Изменение расписания scrubbing’а
Первое что можно сделать это задать расписание для scrubbing’а, отведя для него время где нибудь ночью, например с 00.00-08.00.
Задать в рантайме(без рестарта OSD):
Это сразу изменит ситуацию к лучшему но не надолго. Опять же если у вас много данных то они просто не будут успевать проходить scarbbing в отведенное время. Если какие то PG не успеют пройти scrubbing за 7 дней то он будет запущен принудительно в любое время. Так мы увидели идущий скраббинг в дневное время). Увеличивать установленное время без скраббинга нельзя т.к. он очень важен для сохранности данных. Так мы кстати еще раз получили подтверждение, что у нас много данных.
Раз скраббинг все же идет в итоге в дневное время и мешает нормальной работе сервиса то ничего не остается как искать пусти его ограничения.
Снижение приоритета с помощью CFQ
Необходимо сменить планировщик у всех OSD-дисков на CFQ:
и установить следующие параметры для всех OSD:
Задать в рантайме(без рестарта OSD):
Этот подход используют очень многие и кому то он помогает. Нам он не помог практически ни как. Мы довольно долго его тестировали но периодические просадки производительности и взлет летенси никуда не делись.
Уменьшение порции данных одного scrubbing’а
Это то ради чего написана эта заметка. Я нигде не видел статей или обсуждений на эту тему, но это то что избавило нас от проблем связанных со скраббингом.
Суть в том, что бы позволить scrubbing’у идти круглые сутки но читать данные очень мелкими порциями максимально снижая нагрузку на OSD в момент времени.
Задать в рантайме(без рестарта OSD):
При использовании этого подхода, на мой взгляд лучше сменить планировщик на deadline.
Данный подход представлен в этой статье как один из вариантов и возможно для вас окажется не таким эффективным как для нас. В общем попробуйте и решите сами.