Что такое IOPS?

Сегодня очередной перевод одного из моих любимых авторов, инженера 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):

clip_image001

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

clip_image002

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

Значительные объемы 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, так как они постоянно демонстрируют безумные цифры в маркетинговых материалах.

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

clip_image003

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

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

clip_image004

На момент, когда я это проверил, 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.

15 комментариев

  1. Kernel Panic:

    Главной проблемой IOMeter является плохая работа его linux-части. В тестах я наблюдал какие-то ужасные цифры порядка сотни iops’ов с подключенного по ISCSI ramdisk’а (и это была не вина iscsi или рамдиска, т.к. всеми другими методами попугаи получались сообразные рамдиску).

    Альтернативой я вижу fio (штатно во многих линуксах).

    В процессе поиска методики тестирования (в частности, при тюнинге tcp-стека для работы NFS) я пришёл к простой методике “худшей оценки” (т.е. создания самой плохой нагрузки, заведомо худшей, чем продакт-нагрузка). Выглядит она так: на блочное устройство запускается два процесса (один - random read, 100% span, 4k block, второй - аналогично запись). Количество одновременных обращений подбирается так, чтобы подойти к ожидаемой границе latency (обычно 10 или 20мс). Полученный результат представляет из себя два попугая: число IO на чтение и на запись, причём операции независимы друг от друга. Latency фиксирована.

    Данная конфигурация, разумеется, оценивает производительность в пределах одного хоста (т.е. в случае быстрого СХД, скорее, оценивает скорость сетевого стека хост системы в пределах одного TCP-соединения), но её легко распределить на несколько хостов.

    Тонким моментом, конечно, является подборка глубины IO, дающую заданную latency. Но мне представляется, что фиксация latency при меняющейся глубине очереди (оно же outstanding IO, concurent IO и т.д.) даёт наиболее объективную цифру: мы говорим максимальную ожидаемую latency, на выходе имеем “сколько IOPS мы при этом можем иметь в максимуме”, а как побочное число - суммарное число хостов и тредов, которые могут обслуживаться с заданным качеством.

  2. Aleksey Sychev:

    Отменный текст и качественный TrollFace :-)

  3. Статья на злобу дня :) Уже много лет приходится доказывать на право и налево, что для понимания возможностей СХД нужно знать обслуживаемую ей нагрузку. По ссылке вариант методики тестирования нагрузки, порождаемой SQL Server: http://msmvps.com/blogs/gladchenko/archive/2009/06/09/1694801.aspx

  4. Роман, привет.
    Пытаюсь вчитаться и понять, как IBM STORWIZE® V7000 (SSDS) на 18 SSD в SPC-1 выжал 120к IOPS.
    То ли у них SSD какие-то особенные, то ли я чего-то в описании теста не вижу. Но HP P6500 на 8 SSD выжал “всего” 20k IOPS.
    Как так-то?
    P.S. Пруфлинк - http://www.storageperformance.org/benchmark_results_files/SPC-1/IBM/A00116_IBM_Storwize-V7000-SSDs/a00116_IBM_V7000-SSDs_SPC-1-full-disclosure.pdf

  5. Pavel Kosachev:

    To Андрей Вахитов:
    ну вы загляните в Product Bulletin: заявленный максимум по Read I/O per Sec для 6500 - 55000 iops, а bandwith 1700 Мб, это значит что расчетный блок около 32Кбайт. Вообщем скорее всего это ограничения контроллера , а не бэкенда, из-за этого на многие массивы существуют ограничения на максимальное кол-во SSD. Например в netapp 2240, в VNX 5300 и даже в HP P6500 (25 штук), а также замечательная приписка (NOTE: Maximum array performance using SSDs can be achieved with just 8 SSDs. Adding more SSDs may not increase performance. However, using up to 25 SSDs can increase the capacity of applications that can fit into the SSD storage space, allowing the SSD performance to be useful to larger application situations.).

    To Роман:
    Статья очень спорная, но есть предложение:
    Тема ближайшей заметки в блог:
    На обычном windows сервере (можно на виртуальной машине) вы покажете технику как промерять:
    1. “Размер блока random ввода-вывода приложения по чтению и записи
    2. Размер блока sequential ввода-вывода приложения по чтению и записи ”
    3. Кол-во потоков, которое генерирует приложение
    4. и определение “working set”.
    которые автор статьи предлагает передать вендору/партнеру , а то у меня возникли некоторые затруднения в этом вопросе, возможно все о чем я пишу это азбука, тогда прошу ссылку на букварь.

  6. Евгений:

    Роман, а сколько дисковых операций ввода вывода на RAID-DP делается? в последнем абзаце читаю:
    “9.Определите тип RAID (RAID-10 требует совершить 2 дисковых операции ввода-вывода на каждую операцию random write с хоста, RAID-5 - 4 операции, RAID-6 - 6 операций, это то, что должно быть учтено) ”

    наверное поболее, чем 2?

  7. Евгений:

    Две. Одна запись блока на диск данных, и одна запись соответствующего ему блока на диск parity. Так как в WAFL блоки не перезаписываются, то есть не изменяют уже записанные данные, то есть все записываемые блоки считаются пустыми, то не требуется считывать предыдущее значение для расчета parity.

    Pavel Kosachev:

    > Статья очень спорная, но есть предложение:

    Павел, я думаю, что вы опять выбрали неверное слово. Я, например, не могу найти в статье ни одного места, с чем мог бы поспорить по существу. Что вызвал у вас такое мнение?

  8. Евгений:

    “Евгений:

    Две.”
    значит это еще одна очень ценная фишка RAID-DP, про которую надо упоминать :)))

  9. Pavel Kosachev:

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

    Далее, если автор описывает ограничения, то нужно тоже писать для какого конкретного случая не подходит конкретное использование технологии “Х”. Иначе статья превращается в то, с чем борется автор изначально (т.е. с тем, что по его мнению информация раскрыта не полностью или преподносится с определенного угла зрения).

    Часто беда в том, что те кто составляет такие вот статьи далеки от реальных задач и оперируют понятиями, “один заказчик сказал”.

  10. Pavel Kosachev:

    > Статья спорная потому что получить данные, которые вы просите, для того “чтобы решение работало” в общем случае невозможно

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

    > получить данные, которые вы просите

    Я лично ничего не прошу. Также как и автор.

    > Нельзя “взглянув” на операцию ввода/вывода определить к какому приложению он относится и как его спрашивают, последовательно или нет потому приложению все равно, это один из потока или нет

    По моему вы опять подменяете “не умею” на “невозможно”.
    И вот это уже “спорно”, но - на вашей стороне.

    > Далее, если автор описывает ограничения, то нужно тоже писать для какого конкретного случая не подходит конкретное использование технологии “Х

    Возможное сочетание ограничений и использований это матрица X * Y. Вы правда считаете, что полное и исчерпывающее описание всех случаев этой матрицы это тема для поста в блоге?

    Возвращаюсь к началу: давайте строже с терминами и определениями.

  11. Андрей:

    Очень любопытно, а какая трехбуквенная компания имелась в виду? Или все грешны? =)
    Среди основных игроков их уже три: EMC, IBM, HDS…

  12. Андрей:

    Да все грешны. И двух-, и четырехбуквенные - тоже :)

  13. Артур:

    Роман, а можно подробнее прок количество операция на бэкенде для RAID-DP? Если я правильно понимаю, то WAFL всегда пытается записать полный страйп. Получается, что для RAID-группы 14+2, при записи страйпа будет совершено 16 операций. Грубо на каждый блок с полезными данными будет сделано 1,14 операций. Правильно ли я это понял? Что происходит в том случае. если полный страйп не собирается?

  14. Артур:

    Да, только не “пытается”, а _всегда_ пишет. Так устроена WAFL, что запись в ней всегда происходит полным страйпом, так как _пере_записей блоков не делается (см. наш перевод TR-3002 в библиотеке Netwell). В этом, собственно, и есть главное, принципиальное преимущество таких FS, как WAFL или ZFS, перед обычными. У них всегда запись делается полным страйпом, пока данных для страйпа не набирается в NVRAM, данные на диски не пишутся. Когда собираются - пишутся в один присест, и атомарно, транзакционно переключаются на новое состояние FS.

  15. Артур:

    Роман, спасибо. TR-3002 читал. Хотелось бы еще какой-нибудь документ, более подробно описывающий работу WAFL и RAID-DP.
    Я все же встречал упоминание в курсе Data ONTAP 7.3 Performance Analysis, что страйп не всегда получается полный и приходиться производить чтение с дисков, чтобы посчитать парити.

    http://habrastorage.org/storage2/7a3/f57/16d/7a3f5716df2057bd08117706d17015ea.png
    http://habrastorage.org/storage2/e28/221/47f/e2822147f77c36ff559651041670cd4a.png

Оставить комментарий

20/0.161

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.