Archive for июля 2011

EMC Storage Pools – как это работает “под крышкой”.

Продолжаю свои изыскания в теме технологий EMC. На этот  раз я заинтересовался механизмом, лежащим в основе всех новых фишечек EMC CLARiiON/VNX – так называемым Storage Pool. Самым интересным и понятным для меня объяснением оказалась статья блоггера virtualeverything (он не сотрудник EMC, а, как я понял, работает в партнере-интеграторе, и имеет довольно широкое поле зрения, в котором и продукты EMC, и NetApp, и, например, Hitachi). Незначительно сокращенный перевод этой его заметки я предлагаю вашему вниманию.

Глубокое погружение в тему EMC Storage Pool.

Posted by veverything on March 5, 2011

Использование Storage Pools это довольно частая тема для дискуссии с моими коллегами и пользователями. Многая информация о устройстве и механизмах работы не слишком распространена или известна, поэтому я решил провести мое собственное исследование на этот счет, и поделиться его результатами.

Некоторое время назад EMC представила в своей линейке систем хранения CLARiiON новый принцип так называемого Virtual Provisioning и Storage Pools. Основная идея заключалась в упрощении администрирования системы хранения. Традиционный метод управления хранилищем это взять дисковый массив, наполненный дисками, создать из них дискретные группы RAID, и затем нарезать из этих групп LUNы, которые, затем, предоставляются хостам. Дисковый массив, в зависимости от своего размера, при этом может содержать до нескольких сотен таких групп, и часто превращается в архипелаг разрозненных "островков хранения" на этих RAID-группах. Это может вызывать серьезные затруднения при планировании пространства хранилища, чтобы устранить проблему нерационально потраченного при таком разбиении места, так как у большинства пользователей их потребности к хранилищу, и планы как разбить под задачи, меняются со временем, и, обычно, еще не ясны до конца в "день 1". Нужны были средства гибкого и простого администрирования, и родилась идея Storage Pools.

Storage pools, как следует из его имени, позволяет администраторам создавать "общий массив" (pool) хранения. В ряде случаев вы даже можете создать один большой, общий пул, куда входят все диски системы хранения, что значительно упрощает процессы администрирования. Больше нет отдельных пространств, не нужно углубляться в "тонкие материи" устройства и организации RAID group, схем разбиения, и так далее. Кроме того, появилась также технология FAST VP, которая позволяет перемещать блоки данных в соответствии с их активностью, по уровням хранения, например на более емкие и дешевые, или более быстрые и дорогие диски. Просто выделите и назначьте пространство из такого "пула" вашей задаче, динамически, гибко, и при этом еще и позволяя использовать auto tiering. Звучит здорово так? По крайней мере так утверждает маркетинг. Давайте разберемся с тем, как это работает "физически", и нет ли не вполне очевидных "подводных камней".

Continue reading ‘EMC Storage Pools – как это работает “под крышкой”.’ »

RAID-5, RAID-6 или RAID-10?

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

Недавно попалась на глаза интересная дискуссия, в которой приводились следующие данные.

Допустим мы имеем массив из 20 дисков SATA по 1TB (без учета необходимых для RAID дисков mirror и parity) , скорость ребилда у которого – 50MB/s, и который заполнен данными на 75%.

Тогда вероятность потери данных (именно потери данных, не просто отказа отдельного диска) из за выхода из строя дисков в RAID составляет, по годам эксплуатации:

Year 1:

RAID-5 - 13.76%
RAID-10 - 0.078%
RAID-6 - 0.516%

Year 2:

RAID-5 - 25.6%
RAID-10 - 0.156%
RAID-6 - 1.03%

Year 3:

RAID-5 - 36.86%
RAID-10 - 0.23%
RAID-6 - 1.54

Year 5:

RAID-5 - 53.30%
RAID-10 - 0.38%
RAID-6 - 2.56%

Раз уж мы находимся в блоге посвященном решениям NetApp, то не могу не отметить, что в случае использования RAID-DP, который хотя и является формально RAID-6, но вышеприведенные данные для него будут ближе к значениям RAID-10, так как важную роль в увеличении MTTDL (Mean Time To Data Loss – ожидаемое время до момента потери данных) играет скорость ребилда, на время которого, и до его окончания, показатели надежности любого RAID снижены, и которая, в случае RAID-DP, будет значительно выше (а время восстановления – короче), чем у “канонического” RAID-6.

Например в документе TR-3574 (пусть вас не смутит его “прикладной” заголовок про Exchange 2007, строго говоря работа эта совсем мало прикладная, а, в значительной мере, научная, по крайней мере по дотошности своего подхода) приводится такой расчет:

RAID type Probability of Data Loss in 5 Years Risk of Data Loss Relative to RAID-DP
RAID-10 (1 data disk) 0,33% 163
RAID-5 (7 data disks) 6% 3955
RAID-6 (7 data disks) 0,002% 1,0
RAID-DP (7 data disks) 0,002% 1,0

RAID-5 на 7 дисках данных (7d+1p) почти в четыре тысяч раз менее надежен, чем RAID-6, на тех же 7 дисках данных (7d+2p)!

Отсюда вы сами сможете ответить на часто возникающий вопрос, что более выгодно с точки зрения надежности: две группы RAID-5, допустим, по 5+1, или же одна RAID-6 10+2. Как вы видите, надежность RAID-6 в данном случае выше на порядки, даже не более длинной группе.

 

Не забывайте, в ряде случаев Mean Time To Data Loss может равняться Mean Time To Job Loss :)

 

PS: Если захотите углубиться самостоятельно в дебри расчетов и в тему надежности в RAID, то, кроме вышеуказанной TR-3574, могу также порекомендовать прочитать научную работу, опубликованную на прошлогоднем USENIX Hot Storage’10: Mean time to meaningless - MTTDL, Markov models, and storage system reliability

3TB SATA для DS4243

Объявлена доступность дисков 3.5" SATA 7.2KRPM для полок DS4243. Для их работы будет необходимо также использовать на контроллере Data ONTAP 8.0.2. Соответственно, это системы FAS/V6xxx, FAS/V3200, 3100 и FAS2040. Более ранние системы не поддерживаются данной версией OS, и эти диски не будут доступны для них, даже несмотря на возможность подключить DS4243.

Rightsized размер данных дисков - 2,479 GiB (или 2,538,546 MiB).

Проблемы производительности при использовании 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 лет только оттого, что цена, по которой вам его предложили, была так привлекательна…

Заработал сайт NetApp Linux Community

Если вы подключаете к системам хранения NetApp хост-сервера с так называемыми community-driven Linux дистрибутивами, то есть НЕ RedHat или SUSE, а различные CentOS, Debian, Gentoo, и так далее, которые, по понятным причинам, не могут входить в список официальной поддержки OS (Interoperability Matrix) у NetApp-а, то вам может быть интересна новая инициатива NetApp, который открыл сайт, с очевидным именем http://linux.netapp.com/, на котором будет оказываться поддержка использования linux-систем и систем хранения NetApp, силами комьюнити.

Например сейчас там уже начат выкладываться список совместимых и работоспособных конфигураций, а также HOWTO, которыми стоит руководствоваться, если вы решили использовать community-driven Linuxes в вашей работе.

Сайт только запущен, и пока там немного, но не забывайте, что это community-based support, и все, в конечном счете, зависит от вас.

Что означает сообщение FCP Partner Path Misconfigured (и что с ним делать)?

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

Поэтому я взял на себя труд перевести на русский прекрасно написанную статью из Knowledge Base с сайта NetApp, в которой подробно рассматривается эта ошибка, причины ее вызывающие, и методы устранения.

Что означает сообщение FCP Partner Path Misconfigured

https://kb.netapp.com/support/index?page=content&id=3010111

KB ID: 3010111 Version: 7.0
Published date: 04/29/2011

Проблема

AutoSupport message: FCP PARTNER PATH MISCONFIGURED

Сообщения Syslog и EMS

[hostname: scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured.
[hostname: scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured - Host I/O access through a non-primary and non-optimal path was detected.

Continue reading ‘Что означает сообщение FCP Partner Path Misconfigured (и что с ним делать)?’ »

Еще немного про autotiering

Проглядывая community.netapp.com обнаружил дискуссию о autotiering-е, откуда выдернул интересное мнение уже известного вам Dimitris K. (recoverymonkey). Хотя в оригинале это были три реплики-ответа в дискуссии в форуме, я слил их оформил их как отдельную “статью”.

Дискуссия идет о реализации autotiering в EMC FAST, а также о системах хранения Compellent, которые, до недавнего времени, были главным игроком на рынке tiering-а, и реализация прозрачного tiering-а в них была сделана ранее всех. В России они почти неизвестны, хотя сейчас, как я понимаю, они могут начать попадать в страну через каналы Dell.

Dimitris Kriekouvkas (recoverymonkey), сотрудник NetApp:

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

Посмотрите на опубликованные бенчмарки EMC – там нигде нет autotiering.

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

Если вы посмотрите на руководство наилучших практик по производительности и доступности для EMC CLARiiON (ссылку на этот документ я давал в прошлом посте про “матчасть”), то вы увидите следующее:

  • Вместо RAID-5 для больших пулов на SATA рекомендуется RAID-6 с размером группы в 10-12 дисков.
  • Thin Provisioning снижает производительность
  • Storage pools снижают производительность по сравнению с Traditional RAID
  • Данные и ввод-вывод не распределяются на все диски пула, как вы, возможно, предполагали (см ссылку).
  • Рекомендуется использовать drive ownership на только один контроллер
  • Нельзя смешивать разные типы RAID в одном пуле
  • Существуют ограничения по расширению пула дисками, в идеале расширение должно производиться увеличивая емкость пула вдвое (или, хотя бы, кратно количеству дисков в RAID-группе пула)
  • Для пула недоступны reallocate/rebalancing (для MetaLUN вы можете сделать restripe)
  • Процесс Tresspassing pool LUN (обычно при переключении LUN-а с одного контроллера на другой, например при выходе одного из них из строя, но, часто, и при других операциях) может приводить к снижению производительности, так как оба контроллера будут пытаться совершать операции ввода-вывода на LUN. Поэтому для pool LUN-ов важно оставаться закрепленными за тем контроллером, на котором они начали работать, иначе потребуется затратная миграция.
  • Не рекомендуется использовать thin LUN для задач, требующих высокой производительности по bandwidth.

Я хочу еще раз привлечь внимание к простому факту: дьявол кроется в деталях. Читайте мелкий шрифт.

Вам говорят: Autotiering волшебным образом, автоматически, решит ваши проблемы, без вашего участия, не беспокойтесь об этом. В реальности все не совсем так.

При работе autotiering, значительная часть вашего working set, рабочего набора данных, находящегося в активном использовании в данный момент, должно быть перемещено на быстрое хранилище.

Допустим у вас есть хранилище ваших данных, емкостью 50TB. Правило оценки, которым руководствуются инженеры EMC,  что 5% рабочего набора данных пользователя – “горячие данные”. Они перемещаются на SSD (в виде tier или cache). Таким образом вам нужно 2,5TB usable space на SSD, или примерно одна полку дисками SSD по 200GB, может быть больше, в зависимости от типа использованного RAID.

Принято считать, что объем “средней” нагрузки составляет 20% от объема, то есть 10TB, который размещается на дисках SAS или FC.

Остальное размещается на дисках SATA.

Вопрос на 10 миллионов долларов:

Что обойдется дешевле, autotiering и софт кэширования (он небесплатен) плюс 2,5TB SSD, плюс 10TB SAS, плюс 37,5TB SATA, или…

50TB SATA плюс NetApp FlashCache,или, например, 50TB SAS и Flash Cache?

Вопрос на 20 миллионов долларов:

Какая из этих двух конфигураций будет иметь более предсказуемую производительность?

 

Compellent – это еще одна интересная история.

Большинство обсуждающих Compellent не задумывается о том, что tiering-у у него подвергаются “снэпшоты”, а не непосредственно рабочие данные!

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

О чем не знают большинство интересующихся Compellent-ом:

Если вы изменяете содержимое данных на странице, то происходит это следующим образом:

  1. Перенесенная на SATA страница, содержащая данные, которые мы изменяем, остается на SATA.
  2. Новая страница, объемом 2MB создается на Tier1 (SAS/FC), куда реплицируется содержимое страницы с SATA, и где делается запись изменения. Даже если меняется в данных один байт.
  3. Когда с этой страницы будет сделан снэпшот, то он, в свою очередь, также может быть впоследствии перенесен на SATA, заменив прежнюю.
  4. Итого: 4MB занятого места для того, чтобы сохранить 2MB данных и один измененный байт.

И снова укажу: дьявол кроется в деталях. Если вы изменяете свои данные произвольным образом (random), вы получите множество “заснэпшоченных” страниц, и очень неэффективное использование пространства. Вот почему я всегда предупреждаю пользователей, которые интересуются Compellent-ом, задавать эти вопросы, и уяснить себе эти моменты, получив ясное описание от инженеров того, как используется пространство снэпшотов.

На NetApp мы имеем предельно гранулярное пространство, благодаря WAFL. Минимально возможный снэпшот по своему объему очень мал (это указатель, немного метаданных, плюс один измененный блок, размером 4KB). Поэтому на NetApp некоторые наши пользователи могут хранить сотни тысяч  снэпшотов на одной системе (например именно так делает один всем известный банк, использующий наши системы хранения).

 

Гранулярность, на самом деле, это только часть проблемы (производительность – другая ее часть). Сейчас страница у Compellent имеет размер 2MB (можно уменьшить до 512K, но это не позволит изменять размер стораджа). Если они перейдут, как обещают, на 64-битную арифметику в ПО, то они смогут получит  размер страницы 64K (это пока не подтверждено), однако тут есть вот какая проблема. Запись этой страницы на RAID может быть двумя способами.

Если это RAID-1, то тогда мы записываем две копии страницы, размером 64KB на каждый из дисков.

Если это RAID-5/6, то тогда нам надо поделить объем записываемой страницы, размером 64KB, поровну между всеми дисками данных, входящих в RAID. Допустим используется RAID-5 в варианте 4d+1p. Тогда на каждый диск в операции записи получится всего 16KB (и меньше). И если для RAID-1 размер записи в 64KB это довольно типичный размер записи сегмента в RAID, и запись таким размером достаточно производительна, то для RAID-5/6 это очень маленький кусочек для операции записи, что будет неизбежно отражаться на производительности.

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

Мы ставим 1-2 вида дисков плюс Flash Cache, и проблема решена (в большинстве случаев производительность становится в 2-3 раза выше, как минимум). Часто это получается даже не дороже.

Вот такие дела.

Multi-path High Availaility (MPHA) FAQ

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

Однако мне на прошедшей и этой неделе пока некогда, поэтому пока позвольте представить вашему вниманию перевод официального FAQ на тему MPHA, от NetApp, а свои мысли на этот счет я оставлю до времени, когда я смогу подробнее “посидеть над столом” и сформулировать их.

Пока же – официальная позиция NetApp на тему использования MPHA в системах хранения NetApp.

Continue reading ‘Multi-path High Availaility (MPHA) FAQ’ »

Учу матчасть :)

Как заповедали старшие – изучаю вооружение потенциального противника :)

Нашел тут EMC CLARiiON Best Practices for Performance and Availability (FLARE 30, 01.03.2011) и сижу, читаю.

Особо примечательные места выделяю. Ничего, что я сегодня без перевода? По-моему, в выделенном все достаточно понятно.

Уделяю особое внимание storage pool-ам и LUN-ам в них, так как только в pool-ах возможны новые фишечки, такие как FAST и thin provisioning.

Continue reading ‘Учу матчасть :)’ »

Некоторые данные о производительности EMC FASTcache и FAST VP

Несмотря на то, что EMC наотрез отказывается публиковать результаты производительности систем с FASTcache и FAST VP, храня по этому поводу многозначительное и загадочное молчание, невозможно запретить частным лицам анализировать и делиться своими результатами приобретенных ими систем.

Недавно в интернете удалось раскопать вот такие результаты.

image

Некто проследил и опубликовал результаты real world-работы системы NS480 (CX4-480), объемом 480 SAS, SATA и EFD дисков, на 28TB block и 100TB NAS data, оснащенной как FAST VP, так и FASTcache (4 диска EFD по 100GB, общей usable capacity в FASTcache – 183GB).

Пожалуйста, примите во внимание, что это Real World data, то есть реальная производительность системы, используемой под реальную пользовательскую работу (в рассмотренном случае – ERP, VMware, SQL server databases, CIFS shares), а не какие-то специальные тестовые условия. В этом и сила и слабость приведенных результатов. Сила в том, что это реальные, практические данные. Слабость – в том, что, вполне вероятно, мы не видим всех возможностей FAST/FASTcache.

image

Тем не менее “чем богаты – тем и рады”. Пока EMC хранит загадочное молчание, приходится перебиваться тем, что подарят сердобольные пользователи. Подробно о системе и полученных результатах – по ссылке выше.

Напомню, что, в отличие от EMC, NetApp результаты своих систем с Flash Cache не только не таит, а наоборот, активно пропагандирует и публикует, потому что, по справедливости, там есть чем гордиться.

UPD: В комментариях к посту также нашлось упоминание еще одних результатов.

http://sudrsn.wordpress.com/2011/03/19/storage-efficiency-with-awesome-fast-cache/
http://sudrsn.wordpress.com/2011/04/16/emc-fast-cache-increase-performance-while-reducing-disk-drive-count/

Правда там человек темнит о конфигурации.

18/0.183

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