Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Проблемы производительности при использовании Autotiering и Megacaching | about NetApp

Проблемы производительности при использовании Autotiering и Megacaching

Сегодня в переводах – статья одного из моих любимых блогоавторов – уже знакомого вам Димитриса Крековкиаса, работающего в NetApp, и ведущего автономный блог recovermonkey.org. Обратите внимание, что, несмотря на то, что автор и является сотрудником NetApp, текст поста в равной мере относится и к системам NetApp, и его стоит внимательно прочесть также и партнерам NetApp, продающих их (и проводящих сайзинг) своим клиентам.

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

Покупатель, будь внимателен: верно ли вендор вашей системы хранения делает сайзинг по производительности, или они полагаются только на свои супер-технологии, типа Megacaching и Autotiering?

Posted on June 29, 2011 by Dimitris

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

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

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

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

Новые "умные технологии" делают сайзинг системы хранения более сложным, чем раньше.

Например, набирающая популярность концепция Megacaches может использоваться для значительного уменьшения объемов ввода-вывода, который добирается до бэкэнда и дисков системы хранения. Например на системах NetApp FAS вы можете использовать до 16TB интеллектуального, сверх-гранулярного (4K) и использующего дедупликацию данных кэша чтения. Это на самом деле гигантский размер, больший, чем обычно может понадобиться подавляющему большинству использующих системы хранения (и даже больший, чем многие системы хранения в целом). Другие вендоры также последовали за NetApp, и предлагают сегодня похожие технологии. ?мея такой объемный кэш, расположенный перед дисками, и перехватывающий на себя значительную часть ввода-вывода, многие вендоры имеют соблазн рекомендовать использовать в таких системах хранения диски SATA, имеющие большую удельную емкость, но, обычно, невысокую производительность, ведь производительность в данном случае планируется обеспечивать с помощью того или иного "мегакэша".

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

Как я показал выше, кэш хорошо работает в том случае, если значительная часть данных, которые мы называем "рабочим набором данных" (active working set), помещается в него. Но помните, что "рабочий набор данных" это не все ваши данные, это подмножество ваших данных, к которому обращаются на протяжении какого-то периода времени.

Для пользователя, у которого, допустим, база данных размером 20TB, реальный рабочий набор данных этой базы может составлять всего 5% — то есть этот набор вполне может целиком поместиться в 1TB кэша. Таким образом, кэш размером 1TB может обеспечить большинство потребностей в вводе-выводе базы данных. Диски же в бэкэнде вполне могут при этом быть недорогими SATA, просто чтобы удовлетворить необходимости разместить объем хранения всей базы данных.

Но как быть с тем периодом времени, когда характер ввода-вывода отличается от типового и ожидаемого? Например, это может быть период переиндексации, или объемного экспорта базы, или период конца месяца, или квартала, когда нагрузка на базу часто резко возрастает? Такие операции сильно изменяют объем рабочего набора данных, он может быстро вырасти от 5% до куда более значительных величин. При этом наша рассмотренная выше ситуация, с 1TB кэша и SATA в бэкэнде уже может перестать нас удовлетворять.

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

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

  1. Типичное использование – 20 000 IOPS, 100% random, 8K I/O-блок, 80% чтения
  2. Экспорт DB — высокие значения MB/s, в основном sequential write, большой размер I/O-блока, относительно немного IOPS
  3. Последовательное чтение после произвольной записи — например данные добавляются в DB в произвольном порядке, затем делается большое последовательное чтение, или даже несколько чтений параллельно

Как вы видите, профиль ввода-вывода не просто меняется, он становится принципиально другой. Если вы берете в расчет только вариант 1, у вас может не оказаться достаточно дисков в бэкэнде для стабильного потока при экспорте DB или параллельного sequential table scans. Если вы считаете только вариант 2, вы сочтете, что вам не нужно много кэша, так как ваш профиль ввода-вывода в основном последовательные (sequential) операции (а в большинстве случаев такие операции не кэшируются). Но ваша оценка будет полностью неверна для операций типичного использования.

Если вендор говорит вам, что проведенный ими сайзинг показал, что их предложение соответствует большинству ваших требований по вводу-выводу, то ваш вопрос должен быть: о каких типах ввода-вывода шла речь?

Другая новая модная технология (и судя по всему - переоцененная) это Autotiering.

Autotiering, если по-простому, позволяет перемещать на системе хранения фрагменты данных, так называемые "чанки" (chunks), в соответствии с активностью доступа к ним. Чанки, содержащие максимально активные данные постепенно перемещаются на SSD, в то время, как остальные, менее активные, могут спокойно оставаться на SATA.

Различные дисковые массивы используют разные методы выполнения Autotiering, обычно реализованных с помощью нижележащих архитектурных возможностей систем хранения, и имеют различные ограничения и характеристики. Например, EMC Symmetrix имеет размер чанка около 7.5MB. На HDS VSP, чанк имеет размер около 40MB. На IBM DS8000, SVC или EMC Clariion/VNX, он равен 1GB.

При использовании Autotiering, как и в случае использования кэширования, чем меньше размер чанка, тем эффективнее получается конечный результат. Например, чанк размером 7.5MB требует всего 3-5% пространства сверхбыстрых дисков как "верхнего tier", однако в случае чанков размером 1GB потребуется уже 10-15%, просто по причине того, что чанк большего размера содержит в себе не только "горячие" данные, но и "холодные", перемешанные, на протяжении этого гигабайта, с активными, "горячими" данными.

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

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

image

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

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

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

  1. Предоставьте вендору подробную статистику производительности — чем подробнее она будет, тем лучше. Если мы не будем знать, что происходит на хранилище, то трудно создать по настоящему хорошо спроектированную для вашей задачи систему хранения.
  2. Предоставьте ваши ожидания в области производительности — например "Мне бы хотелось, чтобы запросы в Oracle завершались за 1/4 нынешнего времен их выполнения" — и увяжите ваши ожидания по производительности с бизнес-целями (будет проще их оценивать).
  3. Попросите вендора показать его инструмент сайзинга и описать , каким именно образом делается математическая оценка и получается результат — тут нет и не может быть никакой магии!
  4. Спросите вендора, проанализровали ли они все возможные сценарии нагрузок, которые у вас имеются (не просто "для разных приложений" но разные нагрузки для каждого вашего приложения) — и как именно они это сделали.
  5. Попросите его показать вам каков по размеру, по его оценке, ваш "рабочий набор" данных, и какой объем его поместится в кэш.
  6. Попросите его объяснить вам, как ваши данные будут располагаться на Autotiered-системе. Каким образом определяется то, на каком tier-е будут располагаться те или иные фрагменты данных. Как это вычисляется? Какие моменты геометрии хранилища следует принять во внимание?
  7. Есть ли достаточно пространства для каждого уровня хранения (tier)? Для архитектуры Autotiering с большими чанками, есть ли у вас объем, равный 10-15% емкости общего стораджа, на SSD?
  8. Учтена ли дополнительная нагрузка на RAM и CPU контроллера во время работы кэширования и autotiering? Такие технологии обязательно нагружают CPU и RAM при работе. Спросите, каков этот оверхед (чем меньше чанк при Autotiering, тем больше оверхед на обработку метаданных, например). Ничто не дается на халяву.
  9. Остерегайтесь сайзинга, сделанного устно или "на салфетке", на калькуляторе, или даже в простой электронной таблице – Я еще ни разу не видел точную модель расчета производительности системы хранения в виде электронной таблицы.
  10. Остерегайтесь сайзинга, рассчитанного исходя из примитивного "диск 15K дает 180 IOPS"— на практике все куда сложнее!
  11. Разберитесь с разницей между последовательным (sequential) и произвольным (random) доступом к данным, режимом чтения (reads), записи (writes), а также размером оперируемого блока ввода-вывода (I/O size) для каждой оцениваемой архитектуры — в зависимости от платформы различие в способах работы ввода-вывода может сделать сравнение очень трудным для корректного сравнения между собой при различных требованиях к дисковой подсистеме.
  12. Разберитесь с тем, какую дополнительную нагрузку по вводу-выводу и емкости хранения создают решения Continuous Data Protection и репликации в ряде случаев это может утроить ее.
  13. Какой тип RAID предполагает использовать вендор? Учтено ли огромное дополнительное влияние на производительность у RAID-5 и RAID-6, при большой нагрузке на запись (плюс известный аспект надежности).
  14. Если вы получили предложение за необычно низкую цену, поинтересуйтесь стоимостью дальнейшего апгрейда системы. Принцип "Первый раз - бесплатно" используется очень многими отраслями бизнеса.
  15. ?, наконец, совсем немаловажное — спросите, исходя из какой нагрузки на контроллер системы хранения исходил вендор при сайзинге! Я с большим удивлением видел попытки продать систему, которая обеспечивала обслуживание рабочей нагрузки клиента с запланированным уровнем загрузки CPU контроллера на уровне 90%. Вы считаете, что такого запаса по производительности вам хватит? Помните – дисковая система хранения это просто компьютер с большим количеством дисков, и со специализированным аппаратным и программным содержимым, и здесь процессор может "затыкаться" точно также, как и в любой другой вычислительной системе.

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

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

  1. diz:

    IBM Easy Tier оперирует чанками (extents), размер задается руками - от 16 МБ до 2 Гб

  2. Nikolay:

    Пара вопросов, если можно:
    первый
    @@Остерегайтесь сайзинга, сделанного устно или “на салфетке”, на калькуляторе, или даже в простой электронной таблице – Я еще ни разу не видел точную модель расчета производительности системы хранения в виде электронной таблицы.@@ - интересно в чем кроме электронной таблицы выдают все sizing инструменты (включая нетаповский)свои данные?
    и второй
    @@Помните – дисковая система хранения это просто компьютер с большим количеством дисков, и со специализированным аппаратным и программным содержимым, и здесь процессор может “затыкаться” точно также, как и в любой другой вычислительной системе.@@ - это все-таки относится к системам NetApp, IBM и EMC. А к массивам HDS и HP - вряд ли. Массивы на “асиках” будут держать нагрузки и при 90% так же как при 40%.

  3. Алексей:

    Nikolay, объясните, пожалуйста, чем так хороши ASIC, что при росте утилизации, они не будут подвержены росту времени обслуживания?
    Закон latency=service_time/(1-utilization), насколько я знаю, применим к ASIC точно так же, как и к RISC/CISC CPU.

  4. Nikolay:

    Чем они “хороши” - тем что быстрее время обработки инструкции + меньше накладных расходов на обработку отдельной инструкции в сравнении с процессорами “общего” назначения. Прибавьте к этому объем кода firmware который меньше в разы у “монолитных” массивов. Получаем более стабильную работу под нагрузкой. Что в моем случае подтверждается тестами и практикой. Значение latency например на XP при 50% загрузки CPU и при 90% отличается на 1-2 миллисекунды. На NetApp 6210 я наблюдал более большой разброс - порядка 7-10 мс.

  5. diz:

    Все делают это чанками. Размер у EasyTier действительно может меняться, но выбранное IBM значение по умолчанию - 256MB. Почему не 16MB, хотя такая величина и возможна, думаю что догадываетесь.

    Nikolay:

    > Массивы на “асиках” будут держать нагрузки и при 90% так же как при 40%.

    О, пошел техномистицизм в дело :о)
    У них, в “асиках”, какие-то особые электроны бегают, надо полагать? ;D

    > Получаем более стабильную работу под нагрузкой.

    Тут все зависит от того, верите ли вы в это, или нет :)

  6. Nikolay:

    Ну может у вас это и техномистицизм. А у нас это результаты сравнительных нагрузочных тестов. Своим глазам которые смотрят на результаты суточных тестов XP 24K и FAS 6210 с помощью Orion я верю :)

  7. Nikolay:

    Да нет, я ничуть не отрицаю, что HP XP24K, в некоей произвольной и неизвестной конфигурации, проодит тесты Orion быстрее, чем некая FAS6210 в другой незвестной и произвольной конфигурации, это вполне возможно, но вот приписывать это исключтельно волшебному действию протеинов шелка специальных электронов в “асиках” мне кажется э-э… недальновидно :)

  8. Nikolay:

    ?нтересно - а где вы увидели в моих комментариях фразу про “специальных электронов в “асиках””? :) ?ли это манера ведения спора такая - сказать ерунду, а потом выдавать ее как сказнное другим человеком?

  9. Nikolay:

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

  10. Nikolay:

    Хм.. Во первых не вижу никакой абсудрности. Во вторых быстродействие микросхем ASIC обусловлено их архитектурными особенностями. Вдаваться в детали просто не хочется. Опять же я не утверждаю что “одни микросхемы “(”безблагодатные”) работают хуже, чем другие” - я утверждаю что массивы с “монолитной” архитектурой более предсказуемо ведут себя под высокой нагрузкой в отличии от массивов с “кластерной” архитектурой. Только и всего. Не очень понятно что у вас вызвало чересчур едкую визуализацию моих утверждений. Я ни в коем разе не говорю - что XP или USP лучше чем FAS или DS или Symmetrix.

  11. Nikolay:

    Я просто показываю вам, что фразы типа “мерседес круче чем бмв, потому что быстрее!” хороши на перемене в средней школе, но не здесь, где люди чаще всего компетентные и подготовленные. “Съедят-с”.
    Если не хотите “вдаваться в детали”, зачем вообще это было начинать тут?

  12. Nikolay:

    Так не было фраз то таких :) Точнее они появились в ваших комментариях к моим постам :))) Я же пишу:
    “Я ни в коем разе не говорю - что XP или USP лучше чем FAS или DS или Symmetrix.” - но вы этого не замечаете.
    Почему-то никто кроме вас не пытается меня “скушать”, я понимаю что блог ваш и писать вы можете что угодно - но манера ведения полемики когда оппоненту приписываются чужие высказывания мягко говоря некорректна.

  13. Nikolay:

    Ну давайте сойдемся на том, что я вас неправильно понял, был неправ и прошу меня извинить.
    Просто я всегда, гм-м-м… настораживаюсь ;), когда вижу сравнение некоего абстрактного стораджа, в неизвестной конфигурации, на неизвестной задаче и workload, который “быстрее” какого-то столь же неопределенного другого стораджа.
    Тем более, когда из этого сравнения делаются столь далеко идущие выводы, про “принципиальное преимущество одних микросхем над другими”. Видите ли, я в отрасль пришел “с другой стороны” чем вы, видимо, из микроэлектроники, скажем так. ? с моего конца ясно видно, что с “физической”, материалистической стороны, ASIC от процессора общего применения не отличается ровным счетом ничем. Они могут отличаться на уровне работающий в них программы. А могут и не отличаться, прошу заметить.

    Поэтому моление на всемогущие “аппаратные рэйды” и “волшебные асики”, которые внутри содержат “благодатный кремний 24 карата”, и потому “круче по определению” для меня из области мистицизма, а потому я и ерничаю как могу. :)

  14. Nikolay:

    Давайте :) Я сам по образованию разработчик микросхем и понимаю в чем заключаются отличия архитектур ASIC от CISC. ? опять же - подчеркиваю - я не утверждал что “волшебные асики” БЫСТРЕЕ - я выразил мнение (основанное на личном опыте) что “монолитные” массивы более предсказуемо держат высокую нагрузку.

  15. Nikolay:

    > я не утверждал что “волшебные асики” БЫСТРЕЕ - я выразил мнение (основанное на личном опыте) что “монолитные” массивы более предсказуемо держат высокую нагрузку.

    Осталось только объяснить за счет чего, и что мешает то же самое реализовать на “процесорах общего применения”, и наступит озарение всем.

    UPD: Объяснение “за счет того, что они используют ASIC” будет объяснением в стиле “рация - на бронетранспортере”, и не принимается :)

  16. Nikolay:

    Так вроде объяснил кратко:
    Чем они “хороши” - тем что быстрее время обработки инструкции + меньше накладных расходов на обработку отдельной инструкции в сравнении с процессорами “общего” назначения. Прибавьте к этому объем кода firmware который меньше в разы у “монолитных” массивов.

  17. Nikolay:

    Понимаете, ваше объяснение напоминает мне бессмертное: “- Э! Армяне лучше чем грузины! - Чем это? - Чем грузины!” :)

    Я как раз и спрашиваю, почему вы считаете, что “быстрее время обработки инструкции + меньше накладных расходов на обработку отдельной инструкции”? Вы отвечаете - “потому что быстрее”.
    Диалог вошел в рекурсию.

  18. bbk:

    Мне кажется что эти пары тезисов противоречат друг-другу:
    Утрерждение
    Nikolay 21 июля 2011, 3:49> А к массивам HDS и HP - вряд ли. Массивы на “асиках” будут держать нагрузки и при 90% так же как при 40%.
    Nikolay 23 июля 2011, 5:48> А у нас это результаты сравнительных нагрузочных тестов. Своим глазам которые смотрят на результаты суточных тестов XP 24K и FAS 6210 с помощью Orion я верю :)
    Nikolay 23 июля 2011, 17:48> Во вторых быстродействие микросхем ASIC обусловлено их архитектурными особенностями.
    Отрицание
    Nikolay 24 июля 2011, 18:18> Так не было фраз то таких :)

    Утрерждение
    Nikolay 21 июля 2011, 21:18> Чем они “хороши” - тем что быстрее время обработки инструкции + меньше накладных расходов на обработку отдельной инструкции в сравнении с процессорами “общего” назначения
    Отрицание
    Nikolay 23 июля 2011, 17:48> Я ни в коем разе не говорю - что XP или USP лучше чем FAS или DS или Symmetrix.

    Nikolay 24 июля 2011, 18:18> Почему-то никто кроме вас не пытается меня “скушать”
    Если только один romx вступил с вами в диалог, это ещё не значит, что все читающие не считают ванши тезисы об АС?КАХ (так и хочется добавить “Чудотворных”), как минимум абстрактными и оторванными от контекста.

    Nikolay 23 июля 2011, 17:48> Вдаваться в детали просто не хочется
    Уж будьте так любезны вдайтесь пожалуйста в глубины глубин и объясните свою точку зрения.

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

20/0.112

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.