about NetApp

Сегодня очередной перевод одного из моих любимых авторов, инженера NetApp Dimitris Krekoukias, пишущего в блоге recoverymonkey.org. Текст крайне важный и заставляющий задуматься. Казалось бы, все мы знаем, что такое “IOPS”, но знаем ли мы это на самом деле, и не упускаем ли мы, говоря про IOPS-ы, нечто важное из виду? Насколько полнятие IOPS является однозначно идентифицируемым и можно ли показатели “в IOPS” трактовать однозначно, и сравнивать различные результаты, различных вендоров между собой?

IOPS: Возможно наиболее известный показатель производительности системы хранения.

IOPS означает Input/Output (operations) Per Second, "операций ввода-вывода в секунду". Смысл величины выглядит довольно очевидно. Он измеряет объем работы за определенный промежуток времени (и это не то же самое, что мегабайты в секунду, MB/s).

Кто из вас не видел вендоров, которые превозносят достоинства своих систем хранения, демонстрируя огромные величины IOPS ими достигнутые? Кто из вас не принимал решения покупки системы хранения, основываясь на обещаниях вендорами этих величин? Однако: как часто вендоры, приводя свои результаты, в действительности четко определяли то, что они понимали под аббревиатурой "IOPS", публикуя эти результаты?

Для нетерпеливых, скажу это с самого начала: Величина IOPS сама по себе бессмысленна, и именно так и должна рассматриваться. Без дополнительных метрик, таких как latency, процентное соотношение операций чтения и записи и размера блоков ввода-вывода, величина IOPS совершенно бесполезна.

А теперь подробнее…

Стотыщпицот миллионов IOPS…

Я не раз видел, что некоторые вендоры обещают пользователям высокие показатели по IOPS. На небольшой системе, с числом обычных жестких дисков 15KRPM менее сотни, некоторый трехбуквенный вендор обещает своим пользователям полмиллиона IOPS. Другой - аж миллион. Конечно, пользователи впечатлены, ведь это много, много больше, чем то, что можем предложить мы. Но как обстоят дела на самом деле?

Кое-что я могу объявить прямо вот сейчас: самый маленький нетапповский сторадж, например NetApp FAS2020 может дать миллион IOPS. А может быть даже и целых два миллиона.

Вот, и попробуй, докажи что это не так?

Опровергнуть это невозможно, по той простой причине, что не существует стандартного способа измерения IOPS, и официальное определение IOPS (operations per second, "операций в секунду") не определяет ряд крайне важных параметров. Выполняя любое измерение числа операций ввода-вывода вы автоматически принимаете то "определение IOPS", которым оперирует используемый вами тест.

Что такое "операция"? Какая из множества возможных операций использовалась?

Ответ на этот вопрос может стать довольно сложным и запутанным.

"Операция ввода-вывода" это просто некая часть работы дисковой подсистемы, которая совершается в ответ на запрос хост-сервера и/или некоторых внутренних процессов. Обычно это чтение или запись, с различными подкатегориями, например "чтение" (read), "повторное чтение"(re-read), "запись"(write), "перезапись" (re-write), "произвольный тип доступа" (random), "последовательный тип доступа" (sequential), и размер оперируемого блока данных.

В зависимости от вида операции, этот размер может варьироваться от байт до килобайт и даже нескольких мегабайт.

Давайте рассмотрим следующий список возможных операций, который, конечно же, не полон:

1. Операция random 4KB read
2. Операция random 4KB read следующая за другими операциями чтения 4KB-блоков, в логической связности с первой
3. Просмотр метаданных блоками по 512 байт, и последующее их обновление
4. Операция чтения блока 256KB, следующая за другими операциями чтения 256KB-блоков, в логической связности с первой
5. Чтение 64MB
6. Последовательность произвольных записей блоком 8KB, за которыми следует последовательное чтение блоком 256KB тех же данных, что были только что записаны
7. Random 8KB перезапись
8. Random 32KB чтение и запись
9. Комбинация всего вышеперечисленного в одном треде
10. Комбинация всего вышеперечисленного в нескольких тредах

…и так далее.

Как вы видите, существует множество типов ввода-вывода, и многозадачная и многохостовая система почти никогда не использует какой-то один. Виртуализация только добавляет разнообразия к паттернам ввода-вывода.

?? тут мы подобрались к самому важному месту (если вы хотите вынести из этого длинного поста какую-то одну единственную ценную мысль, то она тут):

Никакая система хранения не может показывать максимальные значения IOPS безотносительно к характеру операций ввода-вывода, значений latency и размеру блоков.

Я хочу это дополнительно подчеркнуть:

Невозможно для системы хранения удерживать одну достигнутую пиковую величину производительности в IOPS при различных типах операций ввода-вывода и требования по задержкам (latency).

Latency

??так, мы определили, что не все IOPS одинаковы, но еще более важным параметром для системы хранения является latency, и то, как именно она связана с IOPS.

Если вы не намерены читать оставшийся текст, резюмирую вкратце - никогда не рассматривайте результаты в IOPS если с ними не указывается величина latency, при которых они получены, а также размер блока операции ввода-вывода и соотношение операций чтения и записи.

Проще говоря, latency это мера того, сколько времени занимает выполнение одного запроса ввода-вывода, с точки зрения приложения.

В общем случае, когда мы говорим о системе хранения, высокая latency - это наименее желательная ее черта, наряду, например, с низкой надежностью хранения.

Базы данных в особенности являются чувствительными к значению latency – они работают таким образом, что формируемые запросы к базе должны быть выполнены максимально быстро (в идеальном случае менее чем за 10ms, записи менее чем 5ms). Обычно записи redo должны выполняться почти мгновенно для высоконагруженной на запись базы, предпочтительно менее чем за 1ms.

Стабильно высокий уровень latency в случае mission-critical приложения может дать крайне неприятный эффект - если база данных не может записать в redo log свою запись, то все встает до тех пор, пока эта запись не будет произведена, и только тогда двинется дальше. Однако, если она постоянно не может записать в redo log достаточно быстро, то ощущения конечного пользователя будут неприемлемы, и запросы к базе начнут массово тормозиться, а база данных может при этом быть бэкэндом к, например, web-фронтэнду для интернет-продаж. Задержки в работе БД в бэкэнде затормозят операции на фронтэнде, и компания может начать терять тысячи пользователей и миллионы долларов продаж из за этих тормозов. Некоторые компании также могут столкнуться с проблемами, более существенными, чем просто невовремя обработанные запросы, если их работа нарушит SLA.

С другой стороны, приложения, имеющие характер доступа преимущественно секвентальный, ориентированный на максимальную пропускную способность в MB/s (это, например, резервное копирование, архивация, или DSS) обычно не являются столь уж чувствительными к значению latency (и, обычно, не нуждаются в высоких показателях по IOPS, а вместо этого требуют высоких показателей по MB/s).

Вот пример с Oracle DB – система показывает около 15.000 IOPS при 25ms latency. Сделать больше IOPS было бы неплохо, но базе гораздо нужнее улучшение результатов по latency, чтобы увидеть значительное улучшение результатов производительности - отметьте, что значения IO waits и latency довольно велики, и что больше всего времени система просто ожидает ввода-вывода (колонка waits):

А теперь сравним с этой системой (формат вывода разный, но это несущественно):

Отметьте, что в данном случае система ожидала, в основном, процессора, а не стораджа.

Значительные объемы I/O wait это признак того, что источник проблем - сторадж (существуют и другие источники задержек, CPU и сеть - это обычные примеры). Даже в случае хороших показателей latency, если вы видите много I/O waits, это значит, что приложение хотело бы больше скорости от системы хранения.

Но в этом посте у меня нет цели учить делать сайзинг для базы данных. Я думаю вот что путает и смущает большинство людей, и что позволяет вендорам демонстрировать нереалистичные показатели производительности:

Это возможно (но нежелательно) получить одновременно высокие значения IOPS и высокие значения latency.

Как? Вот снова сверх-упрощенный пример:

Представим себе два разных автомобиля, оба они имеют максимальную скорость 150 км/ч.

• Автомобиль #1 затрачивает 50 секунд на достижение скорости 150 км/ч километров в час
• Автомобиль #2 затрачивает 200 секунд на достижение скорости 150 км/ч

Максимальная скорость этих двух автомобилей одинакова.

У кого-нибудь есть сомнения в том, какой автомобиль на практике будет считаться быстрее? Конечно же автомобиль #1 будет ощущаться в четыре раза быстрее, чем автомобиль #2, даже несмотря на то, что они оба в конечном счете достигают одной максимальной скорости.

Теперь давайте сделаем еще один важный шаг, продолжая автомобильную аналогию, так как она довольно понятна большинству людей (но прежде всего потому, что мне нравятся автомобили):

• Автомобиль #1 имеет максимальную скорость 120 км/ч и затрачивает 30 секунда на достижение скорости 120 км/ч
• Автомобиль #2 имеет максимальную скорость 180 км/ч, затрачивает 50 секунд на достижение 120 км/ч, и затем 200 секунд на достижение 180 км/ч

В этом примере автомобиль #2, фактически, имеет гораздо большую максимальную скорость, чем автомобиль #1. Многие люди смотрят только на максимальную скорость, когда определяют быстрейший автомобиль.

Однако автомобиль #1 достигает своей максимальной скорости (120 км/ч) гораздо быстрее, чем автомобиль #2 достигает той же скорости, что и автомобиль #1 (120 км/ч).

Автомобиль #2 продолжает разгоняться (и, конечно, обходит по скорости автомобиль #1), но процесс разгона до максимальной скорости в 180 км/ч занимает непомерно большой интервал времени.

Снова – какой из этих двух автомобилей, как вам кажется, будет ощущаться более быстрым с точки зрения его водителя?

Наверняка вам знакомо это ощущение, когда вы давите педаль газа, и автомобиль немедленно отзывается, прибавляя скорость, которую вы немедленно ощущаете, при этом без большой задержки в том, как это происходит?

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

??менно поэтому и были придуманы популярные автомобильные бенчмарки, типа "гонки на четверть мили": сколько секунд понадобится для прохождения четверти мили (402 м), в нашем случае это "рабочая нагрузка", "workload", и какая скорость на финише дистанции будет достигнута?

(Я искренне надеюсь, что мои читатели, по совместительству являющиеся фанатами автоспорта, не начнут в этом месте спорить о деталях: подвесках, двигателях, направлении и силе ветра, силе сцепления, трения, и так далее, это просто пример, который иллюстрирует разницу между throughput и latency, я не имел выше ввиду никаких конкретных автомобилей, правда).

Ну и, наконец, несколько примеров…

Вендоры обещают… и некоторые примечания мелким шрифтом по каждому утверждению:

“Наша система делает миллион IOPS!”
…блоками по 512 байт, последовательного чтения из кэша.

“Наша система делает четверть миллиона random 4K IOPS – не из кэша!”
…при 50ms latency.

“Наша система делает четверть миллиона 8K IOPS, не из кэша, при 20ms latency!”
…но только при работе 1000 параллельных тредов.

“Наша система делает сто тысяч 4K IOPS, при менее 20ms latency!”
…но только если к данным обращается один хост, так что дисковая система не отвлекается на ввод-вывод других хостов.

Отметьте, что ни одно из этих утверждений выше не говорит об процентном объеме записей и о рабочем объеме данных… А также не определяет конфигурацию, на которой данные показатели были продемонстрированы.

На что обратить внимание, когда кто-то обещает грандиозные результаты по IOPS

Аудированная, то есть авторитетно, публично и внимательно проверенная на соответствие, верификация опубликованных данных и строго определенная рабочая нагрузка в тесте (включающая в себя определение величины latency как одной из критичных метрик) может помочь вам. Я возьму как пример HDS, так как они постоянно демонстрируют безумные цифры в маркетинговых материалах.

Например, возьмем информацию с вебсайта:

Весьма часто в описаниях встречаются такие ничем не подтвержденные обещания по IOPS. Никакой информации о том, какой блок ввода-вывода использовался, соотношении операций чтения и записи, sequential или random, какой тип дисков такое значение IOPS показал, ну и, конечно, значения latency…

Однако, очень похожая система честно достигла 200.000 SPC-1 IOPS с хорошими показателями по latency в аудированном тесте SPC-1:

На момент, когда я это проверил, 200.000 это в 20 раз меньше, чем 4.000.000. Не поймите меня неправильно, 200.000 IOPS с низкой latency это отличный результат для SPC-1, но это НЕ 4 миллиона SPC-1 IOPS.

Посмотрите мою предыдущую статью про SPC-1, и то как правильно читать его результаты. ?? если вендор не публикует результаты своей платформы - спросите его почему он их не хочет опубликовать.

Откуда вообще берутся эти IOPS?

??так, когда вы слышите про эти фантастические результаты, откуда они на самом деле берутся? Они полностью вымышлены? Не обязательно. Существует несколько способов, с помощью которых вендоры, публикующие такие утверждения, могут обеспечить свои результаты. Например, они могут предположить:

1. Что контроллер будет иметь теоретически неограниченные бэкэнд-ресурсы.
2. Что контроллер будет работать исключительно с данными из кэша.
3. Что контроллер будет иметь данные непосредственно в буферах порта FC (“Чоа? 8-/” это правильная реакция, только один трехбуквенный вендор таким промышляет, так что это не широкораспространенная практика).
4. Что контроллер будет настроен под одну специально сформированную конфигурацию рабочей нагрузки, с определенным порогом latency.

Полученные в результате такого подхода величины IOPS могут существовать на самом деле, в контексте того, как проведен тест тем или иным вендором, и как именно он трактует понятие "IOPS". Однако можно ли трактовать такие результаты, как отражающие реальную производительность системы хранения на данных вашего приложения?

Что если кто-то показывает вам большие величины IOPS на Proof-of-Concept или демосистеме?

Proof-of-Concept или демо-инсталляция это отличный способ доказать реальность заявленных показателей. Но помните, что, как всегда: "garbage in – garbage out", на "входе мусор - на выходе мусор".

Если кто-нибудь показывает вам то, как IOmeter показывает сумасшедшую производительность в IOPS, используйте информацию в этом посте для того, чтобы понять в точности то, как сконфигурирован бенчмарк. Каков выбран размер блока, каково соотношение рандомных операций и секвентальных, сколько хостов выполняют ввод-вывод, и так далее. Не настроена ли система при тестировании так, чтобы использовался "короткоходовый" (short-stroked) доступ к тестируемым данным? Не идет ли доступ к данным преимущественно в кэш?

Обычно такое средство, как IОmeter может быть хорошим способом продемонстрировать возможности системы, но это не значит, что комбинированный ввод-вывод всех ваших приложений будет характеризоваться одинаковыми параметрами, ни то, что несколько серверов, демонстрирующих производительность в тесте, адекватно отражают ситуацию, когда к стораджу будут обращаться сотни серверов вашей основной серверной фермы. Желательно проводить тестирование настолько близко к вашим реальными приложениям, насколько это возможно. Не рассчитывайте, что вы можете экстраполировать результаты - системы не всегда масштабируются линейно.

Факторы, влияющие на производительность системы

В реальной жизни у вас не будет одного единственного хоста, который гонит данные на систему хранения. Скорее всего у вас будет несколько хостов, работающих на ввод-вывод параллельно. Вот только некоторые факторы, оказывающие заметное влияние на производительность системы хранения:

1. Контроллер, CPU, память, число внешних соединений с хостами, их скорость и тип.
2. Число random-записей. Это наибольший влияющий фактор так как, в зависимости от типа RAID, операции ввода-вывода на бэкэнде составляют от 2 (RAID-10) до 6 (RAID-6) операций ввода-вывода на одну операцию записи с хоста, исключая случаи, когда используются определенные способы оптимизации записей, как, например, используемые в WAFL. (advanced form of write management).
3. Строгие требования по времени задержек – отдельные системы демонстрируют периодические скачки latency, происходящие время от времени, даже если они используют SSD (а иногда в особенности, если они используют SSD).
4. Множество перезаписей одной и той же логической области дисков. Это, даже при использовании средств autotiering или megacashing (во flash) все еще приводит к значительной перегрузке ограниченного набора дисков (неважно, вращающихся, или SSD).
5. Тип и количество используемых устройств хранения – различные типы устройств хранения имеют крайне разнообразные характеристики производительности, даже в пределах одного семейства (например, производительность разных моделей SSD может отличаться чудовищно).
6. Средства CDP (Continuous Data Protection) – иногда они приводят к трехкратному увеличению числа операций записи на бэкэнде.
7. Снэпшоты по алгоритму Copy on First Write при высокой рабочей нагрузке на запись.
8. Неверное выравнивание партиций данных.
9. ??нтенсивное использование техник повышения эффективности хранения, таких как компрессия и дедупликация.
10. Сильная зависимость от возможностей autotiering (в результате вы можете начать использовать слишком мало дисков и/или слишком много медленных дисков в попытке сэкономить деньги).
11. Недостаточный для данного рабочего набора данных объем кэша, вкупе с неэффективным алгоритмом кэширования, слишком крупный размер блока и низкая утилизация.
12. Малая глубина очереди порта.
13. Невозможность правильной работы с различными видами ввода-вывода от нескольких различных хостов.
14. Невозможность распознать паттерны поведения в потоке ввода-вывода (например множественные параллельные табличные сканы в базе данных).
15. Невозможность интеллектуальной пред-выборки данных.

Что вы можете сделать, для того, чтобы получить решение, которое будет работать…

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

Предоставьте вендору для сайзинга следующую информацию:

1. ??спользуемые приложения, объемы данных для каждого из них (и, идеально, логи производительности для каждого приложения)
2. Число подключаемых серверов
3. Желаемые методы резервного копирования и репликации
4. Размер блока random ввода-вывода приложения по чтению и записи
5. Размер блока sequential ввода-вывода приложения по чтению и записи
6. Определите процентное соотношение по операциям чтения и записи для каждого приложения и каждого типа ввода-вывода
7. Рабочий объем данных (working set), то есть объем данных, с которым активно работает приложение
8. Определите, какие дополнительные возможности системы хранения, такие как thin provisioning, pools, CDP, autotiering, компрессия, дедупликация, снэпшоты и репликация, будут использованы, и какой оверхед они добавят к производительности
9. Определите тип RAID (RAID-10 требует совершить 2 дисковых операции ввода-вывода на каждую операцию random write с хоста, RAID-5 - 4 операции, RAID-6 - 6 операций, это то, что должно быть учтено)
10. Поймите влияние всего вышеперечисленного на общую производительность системы хранения.

Если ваш вендор не желает или не может сделать все эту работу, или, в особенности, если они говорят, что все это неважно, ведь их сторадж сделает вам стотыщпицот миллионов IOPS – ну, теперь вы хотя бы знаете чего такие слова стоят.

D.