Archive for июня 2009

Дедупликация - включить и пользоваться

Итак, если я вас убедил взять и попробовать использовать дедупликацию, то сделать это можно разными путями. Например таким:
Допустим лицензия на дедупликацию получена и введена.
Включить ее можно любым из доступных для управления системой хранения способов, например через командную строку. Но давайте посмотрим как это сделать с помощью нового System Manager-а, о котором я рассказывал совсем недавно. System Manager это приложение администрирования систем хранения NetApp, в виде MMC-оснастки (Microsoft Management Console) для любой Windows-системы.
Вот так включается дедупликация для тома, при его создании:
dedup-vol
В свойствах тома можно поменять расписание прохода дедупликации, выставив выбранное вами время, в том случае, если вас не устраивает автоматический режим (он срабатывает, напомню, при обнаружении простоя системы хранения, и запускает процесс дедупликации в фоновом режиме).
dedup-schedule
Страница управления томами также имеет средства запуска процесса вручную, например немедленно.
dedup-start
После окончания там же будет показана эффективность результата его работы.
dedup-savings
Ну и, наконец, если у вас используется VMware, и вы выбрали для хранения его датастора том по NFS, о преимуществах такого решения я много писал, то для такого случая есть специальный “мастер”.
dedup-wizard
Напомню, что NetApp гарантирует не менее чем двукратное снижение используемой емкости хранения, при использовании дедупликации и thin provisioning-а для систем VMware.

Дедупликация - как это работает у NetApp?

Дедупликация данных, то есть удаление из данных повторяющихся блоков с целью уменьшения объемов хранения, есть довольно горячая тема на сегодня.
Недавно начавшаяся “титаномахия” между NetApp и EMC, двумя крупнейшими по размерам производителями систем хранения с дедупликацией, за обладание третьим игроком этого рынка, компанией Data Domain, по очереди получающей от NetApp и EMC все повышающиеся по цене предложения о покупке, показывает интерес индустрии к теме.

Что же такое дедупликация, или, как она называлась раньше у NetApp, ASIS - Advanced Single Instance Store?

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

Однако есть другие варианты, наиболее просто демонстрируемый и широко распространенный сегодня - содержимое виртуальных машин. Если у вас есть пять виртуальных машин на базе Windows, то у вас есть, скорее всего, пять полностью идентичных инсталляций Windows, минимум на 2-3 гигабайта каждая, отличающихся на момент их создания, грубо говоря, только “именем компьютера” и IP-адресом, лежащих отдельно друг от друга на дисках, и занимающих свои 2-3 гигабайта.
Однако, так как это содержимое хранится внутри файла “виртуальных дисков”, то обычными методами мы никак не сможем устранить это дублирование. Ведь файлы этих виртуальных дисков все же не идентичны (на какие-то единицы процентов).
Аналогичный пример - базы данных. Если у нас для записи базы данных для полутора тысяч сотрудников указано “не женат/не замужем”, равно как и наоборот, или, например, в поле “город” указано “Москва”, а предусмотренное архитектурой базы BLOB-поле для хранения фотографии у 90% пустое, то это также будет дублированием.

Может быть просто обидно, хранить на дорогостоящих SAS и FC дисках многократно повторяющиеся, и по сути не нужные, не несущие информацию, избыточные блоки данных. Мы сохранили уникальный блок - все. Нужно его содержимое - берите его там, зачем копировать его по диску в сотнях и тысячах копий!
Так дело обстоит с точки зрения банальной логики.
Мы победили на файловом уровне, с помощью разных средств, рассылальщиков “башорга” по конторе, но с дублированием множества копий идентичных данных в виртуальных машинах справиться гораздо сложнее.

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

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

“Хэш-функция” это некая формула, по которой можно получить более или менее уникальный “фингерпринт”, “цифровой отпечаток пальца”, некое число, уникальное для данного сочетания байт. Сравнивать такие числа гораздо проще, чем содержимое файлов, от которых они взяты.
Простейший вариант хэш-функции, это так называемая “контрольная сумма”. У нас есть набор чисел-байт, давайте просуммируем их, и на выходе получим некое число, зависящее от значения тех, кого мы просуммировали. Проблема использования простейшей контрольной суммы очевидна.
Сумма 5+3+2 дает 10. Но и сумма 4+4+2 дает тоже 10.
Это называется “хэш-коллизия”, ситуация, когда разные по содержимому блоки дают идентичный результат хэш-функции. Чем это чревато - нетрудно сообразить. Основываясь только на результате хэша мы можем ошибочно удалить вовсе не идентичные по содержимому данные.

Решение в общем-то очевидно. На самом деле никто не пользуется примитивной контрольной суммой, я ее привел просто в качестве примера, иллюстрирующего проблему.
Для вычисления хэш-функции используются различные математические алгоритмы, более устойчивые к хэш-коллизии, наиболее известны, например, CRC32 или MD5.
Более устойчивые - да, но не абсолютно.
Устроит ли вас результат, что “ваши данные скорее всего, с высокой степенью вероятности, не будут ошибочно удалены”? По видимому - нет.

Что же делать? Снова очевидно - усложнять алгоритм, снижая вероятность коллизии.
Однако, возникает проблема накладных расходов. Вычисление сложного алгоритма есть довольно непростая и ресурсоемкая задача. А если учесть, что мы должны проделывать ее для каждого записываемого на систему хранения блока без исключения? Процессорные ресурсы сейчас дешевы, но не настолько же.

Именно это является причиной того, что массивно-дедуплицирующие системы, например такие, как система типа CAS (Content-addressable Storage) EMC Centera, очень, ОЧЕНЬ медленные на запись.

NetApp, представив в 2007 году свое решение той задачи, предсказуемо пошел своим путем.
Как я уже упоминал, системы NetApp хранят результат CRC, это сравнительно простой в вычислении и “недорогой”, но недостаточно устойчивый к коллизиям алгоритм вычисления, для каждого 512-байтного блока. Этот CRC достается нам, по сути, бесплатно, он в принципе уже есть на дисках, хотим мы этого, или нет, пользуемся им, или нет.
Но использовать только его для определения дубликатов нельзя.

Файловая структура WAFL, лежащая “в основе” всех систем хранения NetApp использует блок данных размером 4KB, то есть 8 таких секторов.
CRC от этих 8 секторов дают нам некий более или менее уникальный fingerprint такого блока.
Эти фингерпринты сводятся в массив внутренней “базы”, по которой производится поиск идентичных фингерпринтов. Как вычисление несложного хэша, так и поиск по значениям такого хэша, это, в принципе, не слишком сложная и ресурсоемкая задача, тем более, что, как я написал выше, значительная часть задачи уже и так решена, так как CRC у нас уже есть для всех секторов “бай дизайн”, изначально, по умолчанию.
Идентичные фингерпринты являются основанием предполагать идентичность соответствующих им блоков.
Обратите внимание, не “означают идентичность”, для этого алгоритм слишком прост.

Теперь, сократив количество подлежащих анализу блоков в сотни и тысячи раз, и обнаружив “достойных кандидатов”, мы проводим обычное побайтовое собеседование сравнение этих 4KB блоков, и вот если мы в результате этого сравнения обнаруживаем полную идентичность - вот тогда мы и удаляем, то есть вероятность неправомерного удаления в результате “хэш-коллизии” полностью устранена, но при этом, за счет такого двухстадийного процесса, мы обошлись без использования сложного и ресурсоемкого “устойчивого к коллизиям хэша”.

Однако у такого метода есть существенная особенность - он не может быть проведен online, в момент собственно записи данных. Это в чистом виде offline-алгоритм. Сперва данные записываются, потом генерируются fingerprint-ы, потом проходит поиск, выявляются кандидаты на дедупликацию, проводится побайтное сравнение дупликатов и принимается решение.

Однако “чистый offline” процесса дедупликации дает нам пренебрежимо малое влияние процесса на производительность системы. Конечно многое зависит от мощности системы, характера данных, и так далее, но чаще всего пользователи сообщают о влиянии на производительность от включенной дедупликации в 0% для чтения, и в районе 5-7% при записи, то есть, во многих случаях, пренебрежимо малых величинах.
В результате, системы NetApp могут использовать дедупликацию на ролях так называемых Primary storages, то есть основных, “боевых” системах хранения, а не только на хранилищах бэкапов, DR-реплик и резервных, ненагруженных системах.
Хотя применение дедупликации на primary storages и требует соблюдения рада оговорок, оно, как показывает практика прошедших пары лет, вполне работоспособно и широко применяется сегодня. И уж точно дедупликация пригодна для разнообразных secondary storages, таких как D2D Backup, реплики данных и резервные системы.

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

Q: Насколько эффективна дедупликация для хранимых данных?
А: NetApp сделал специальный эмпирический калькулятор, с помошью которого можно приблизительно оценить результат для разных типов данных.
http://www.dedupecalc.com/

Q: А как бы не приблизительные и эмпирические цифры узнать, а на моих конкретных данных?
A: У NetApp есть небольшая программка, которую можно запустить на том данных, она просчитает по нему fingerprint и сообщит ожидаемую эффективность дедупликации. Взять ее можно у партнера NetApp, так как она под определенными ограничениями, не просите ее у меня.
Партнеру скажите, что вам нужна программка SSET под Windows или Linux, он ее может скачать с партнерского раздела.

Q: Я запустил дедупликацию (или SSET) по тому данных, на котором у меня лежит сотня full backup моих данных, и я ожидал получить высокую степень эффективности на таких данных, ведь по сути это полностью одинаковые данные за небольшими изменениями, но получил результат заметно менее ожидаемого, почему так?
A: Дело в том, что для дедупликации важна абсолютная идентичность данных в пределах 4KB-блока. Если идентичные данные имеют по какой-то причине смещение между сравниваемыми блоками, хоть на байт (такое часто случается в форматах файлов резервного копирования), они уже будут считаться неидентичными для алгоритма дедупликации FAS, который не умеет обрабатывать смещение данных в блоках. Эта проблема решена в алгоритме дедупликации для систем VTL, лучше подходящих, и специально заточенных под бэкапы.
По этой причине, кстати, дедупликация FAS так эффективна для виртуальных дисков виртуальных машин, обычно виртуальные диски всегда идентично выровнены между собой, и границы блоков для них совпадают.

Q: Как можно получить лицензию для имеющейся системы?
A: Свяжитесь с ее продавцом, он закажет для вашей системы лицензию. Она бесплатна, но она нужна. Как правило для всех новых систем она поставляется по умолчанию, как iSCSI, например.

Q: Есть ли какие-то ограничения по использованию?
A1: Конечно есть :) Для полного понимания рекмендуется прочесть соответствующий Best Practices на сайте NetApp, а из FAQ-овых вопросов - обязательно посмотрите, какой лимит определен для вашей системы хранения. Он зависит от версии используемой Data ONTAP, и на момент написания этого текста, для 7.3.1 составляет 1TB для FAS2020 (самой младшей), 2TB для 2050 и 3020, 3TB для 3050, 4TB для 3040 и 3140, выше (3070, 3160, 6000) размер тома с включенной дедупликацией может быть равен максимальному размеру тома на системе хранения - 16TB. Это ограничение вызвано нежеланием перегружать возможным процессом не слишком большие объемы памяти и процессоров для этих систем, что могло бы вызвать заметное снижение рабочей производительности системы.
Если вы создали том больше, чем разрешено для данной OS и данного “железа”, то дедупликация не запустится. С другой стороны и ничего плохого тоже не произойдет :).
А2: Обратите также внимание, что дедупликация производится только для активной файловой системы. Если много блоков данных “заперто” в снэпшотах, то степень достигнутой дедупликации будет ниже, так как блоки данных в снэпшотах не обрабатываются. Возможно со временем эту проблему решат, но пока перед началом дедупликации рекомендуется удалять снэпшоты, провести дедупликацию, после чего снэпшоты можно снова брать и использовать.

Q: Велична в 2TB на том данных, подлежащих дедупликации, это объем записываемых в него данных?
A: Нет, это именно размер тома. Если у вас на системе ограничение 2TB на том с дедупликацией, и при этом вы пишете на него данные, которые могут быть дедуплицированы вдвое, то после записи 2TB и первого прохода процесса дедупликации, у вас освободится 1TB, который вы, в свою очередь, сможете записать после окончания этого процесса. Далее по этому записанному 1TB также пройдет дедупликация, и после ее окончания вы снова получите свободное место. Но первоначально объем записи равен размеру тома, не забывайте, что это именно оффлайновая дедупликация, даже если вы заливаете 2TB нулей, вы получите эффект только после его обработки.
Однако, если вы включили дедупликацию на томе большего размера, на котором есть всего 2TB и менее данных, то дедупликация просто не включится. Важен именно размер тома.

Q: Могу я вернуть “как было” если у меня что-то пойдет “не так”?
A: Конечно, можно как включить, так и выключить дедупликацию в любой момент, а также вернуть назад “дупликацию”, если почему-то что-то не устроит.

Где еще почитать поподробнее по-русски о технических аспектах:
RUS TR-3505 Deduplication for FAS and V-series Best Practices.pdf


UPD:
О том, как дедупликация влияет на производительность работы систем хранения NetApp можно прочитать здесь:
Дедупликация и производительность работы


UPD2: Кстати, знаете ли вы, что NetApp гарантирует экономию по меньшей мере 50% объема хранения в случае использования дедупликации для данных виртуальных сред (VMware ESX/vSphere, MS Hyper-V/Hyper-V R2, Citrix Xen)?
http://www.netapp-vi.eu/ru/

Не переусердствуй, пиная мертвого льва.

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

“В рамках тендера в финал выходят три компании и со всеми из них встречается Лицо Принимающее Решение (далее ЛПР) для общего знакомства. Все три компании пыжатся представить себя в лучшем свете и во время встречи высказываются в духе “мы лучшие из лучших и нет нам достойных конкурентов, кроме компании А, а оставшиеся в Вашем тендере компании - шелуха, чего мучатся выбором - выбирайте нас”. Надо отметить, что компания А выбыла из тендера в первом туре, не пройдя квалификацию по техусловиям и предоставив изначально чрезвычайно дорогое предложение.

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

Так то :) А что, вполне реальная история. Не слишком усердствуй, когда хвалишь выбывшего из тендера конкурента.

Взято тут:
http://blog.chirkov.net/2009/06/14/sravnenie-sebya-s-konkurentami/

О именах и названиях.

Относительно недавнее приобретение одним из конкурентов NetApp, компанией HP, компании-стартапа LeftHand, вместе с его продуктовой линейкой одноименных систем хранения, породило просто небывалый простор для шуточек и даже скабрезностей со стороны конкурентов.
Интересно, а в английском что, за этим понятием нет такого шлейфа “отрицательного смысла”?
Тут тебе и “леворукие”, и “обе руки - левые”, и даже бессмертное “слабое подобие левой руки”.

Silent Data Corruption - неотслеженное повреждение данных

Без технологии защиты, действующей “от двери и до двери”, повреждение данных может пройти незамеченным, и тогда процесс восстановления окажется длительным, трудным и дорогостоящим, если и вообще возможным. Без технологии проверки целостности данных на всем протяжении пути данных, такое необнаруженное повреждение может вести к неожиданным и трудноотлавливаемым проблемам.Недавняя статья в PC Magazine (опуликована 25 августа 2008 года) сообщает о произошедшем в реальной жизни инциденте:

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

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

Одно из мест, где повреждение данных может произойти, это процесс записи на диск. Есть два основных вида повреждений диска. Первый - так называемый “latent sector errors” или “неустойчивая ошибка чтения сектора”, который обычно является следствием физического сбоя диска. Примером может служить ошибка чтения, о которой сообщает дисковый массив.
Такой вид ошибки обычно детектируется с помощью ECC или CRC в канале ввода-вывода, и чаще всего исправляется автоматически.

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

Недавнее исследование1, проведенное в Университете Висконсина, Университете Торонто и компании NetApp было сосредоточено на “тихих ошибках” жестких дисков. Исследование проводилось в течении 41 месяца, и анализировались ошибки контрольных сумм 1,53 миллионов жестких дисков.

При исследовании использовались данные блоков на уровне файловой системы, чтобы обнаружить ранее необнаруживаемые ошибки контрольны сумм. В течении 41 месяца “тихие ошибки” были зарегистрированы на 0.86% из 358000 дисках SATA и 0.065% из 1.17 миллионов дисков Fibre Channel. Хотя эти величины и невысоки, но они представляют собой необнаруживаемые, и полностью “тихие ошибки”, которые могут привести к потере или искажению данных, и, в результате, значительному простою.


1
L. Bairavasundaram, G. Goodson, B. Schroeder, A. Arpaci-Dusseau, R. Arpaci-Dusseau, “An Analysis of Data Corruption in the Storage Stack “, FAST08

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

Еще в 2001 году Oracle выступил с инициативой HARD- Hardware Assisted Resilient Data - программой мер, обеспечивающих сквозной контроль целостности информации от диска до приложения.
Постепенно к этой программе присоединяются новые участники, обеспечивающие соответствующий функционал в своих продуктах. С 2003 года существует стандарт (Protection Information) подготовленный группой ANSI T10, с 2007 года в рамках инициативы DII (Data Integrity Initiative) сотрудничают Oracle, Emulex, Seagate и LSI, организована координирующая группа SNIA Data Integrity Working Group. C 2008 соответсвующие средства и поддержка, по инициативе Oracle, внесены в ядро Linux, начиная от 2.6.27.

Возможно интересующиеся темой уже знают, что в дисках NetApp используется специальный размер сектора - 520 байт, вместо стандартных 512. Именно эти 8 байт на сектор и используются для хранения дополнительной информации для защиты и обнаружения искажения информации на самом нижнем, ниже RAID уровне.

Вот как определяет этот механизм группа ANSI T10:
ANSI T10 PI sector specification

Protection Informаtion Standart (PI) это расширение спецификации SCSI Block Command, утвержденного техническим комитетом T10. Спецификация PI относится к коммуникации между контроллером SCSI и устройством хранения. Стандартным образом данные размещаются в 512-байтных блоках. Стандарт DIF определяет дополнительные 8 байт, увеличивающие сектор до 520 байт. Дополнительные байты используются для хранения тегов, которые используются для проверки содержимого 512 байт данных в секторе.

FC HBA (как SCSI-контроллер в данном случае) генерирует соответствующие 8 байт служебных данных, которые записываются вместе с сектором. В дальнейшем это позволить иметь дополнительный “слой” защиты в случае ошибочного чтения или записи данных на самом “низком уровне”.

В настоящий момент на сайте Oracle в списке поддержавших и проверенных тестами Oracle EMC (Symmetrix), NetApp (все модели), Hitachi Data Systems (USP), а также “братья” последней, такие как HP XP и Sun StorEdge 99xx, и малоизвестные у нас системы NEC и Fujitsu.

Как видно из списка, среди модульных (не-”highend”) систем пока эта технология реализована (с 2004 года) только у NetApp, и у них единственных проходит полный набор тестов HARD, хотя я слышал, что EMC CLARiiON также использует “нестандартный” (на самом деле как раз стандартный, в соответствии с новым стандартом ANSI T10) размер сектора, с той же целью.
Соответствующее ПО под названием SnapValidator обеспечивает работу контрольных алгоритмов Oracle внутри системы хранения, и гарантирует полную целостность данных Oracle “от двери до двери”, от блока данных в памяти сервера, до сектора данных на “блине” жесткого диска.

SnapValidator на сайте NetApp

T10 Committee: End-to-End Data Protection Justification, July 1, 2003.

Обратная связь

Порой процесс взаимодействия меня, как автора, с читателями бывает довольно необычен.
Тем 44 посетителям, что зашли в течении прошедшего месяца с поисковиков по запросу:
netapp simulator how to add disk

Вот так:)

netapp simulator how to add disk

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

“Сынок! Как твоя штука поможет нам рубить деревья?”

Ну раз у меня в эту неделю большой писательский кризис (на самом деле я готовлю новый перевод Best Practices, на это раз про MS Exchange 2007), то позвольте небольшой оффтопик.
Подслушанное в подкасте Stack Overflow Джоэла Спольски:

“Как кастрировать быка” это книга Дейва Хитца, основателя NetApp… это книга, в которой он рассказывает историю создания компании NetApp.

Он рассказыват там историю, которая, я думаю, любопытна, про то, что значит работать на корпоративном рынке, и чем такой рынок отличается от рынка “коробочных продуктов”, и в чем разница между этими типами клиентов…
Первая история, которую он рассказал, случилась, когда они в первый раз пытались выйти на этот рынок и сделать продажу в корпоративный сегмент.
Он приехал в Georgia-Pacific (крупнейший американский, да, возможно, и мировой производитель бумаги) с презентацией и демо-системой NetApp, и провел демонстрацию, которую многократно успешно проводил в предыдущие годы. Он рассказал про терабайты в секунду, и о том, как много данных может хранить его устройство, и о том, какие протоколы поддерживаются, и прочие такие штуки технического плана, и о том, насколько дешевле их система по сравнению с конкурентами.

После презентации глава IT-департамента спросил с характерным джорджийским акцентом: “Сынок, мы рубим деревья, и делаем из них туалетную бумагу. Скажи мне, как твоя штука может помочь нам рубить деревья и делать из них туалетную бумагу?”
Ну и конечно не стоит говорить, что тот контракт они не получили.”

Почему NetApp до сих пор не использует SSD?

Несомненно одна из “горячих тем” 2008-09 года это SSD - Solid State Disks - “твердотельные” диски на технологии Flash. Они появились повсеместно, от недорогих нетбуков “до 300$” до дорогих серверных систем. В прошлом году использование SSD в системах хранения данных было анонсировано EMC для их линейки Symmetrix.
Часто приходится отвечать на вопросы: “А что же NetApp не реагирует, и не поддержит свое реноме передовой инновационной инженерной компании? Где же у NetApp SSD?”

А NetApp, как всегда, движется своим путем.

Что есть SSD? SSD это flash, знакомый нам уже много лет, но организованный таким образом, чтобы “обманывать” прочие устройства, чтобы те думали, что они работают с обычным HDD.
Этакий аппаратный “эмулятор HDD”. Кроме этого чем SSD отличается от знакомых нам, уже сто лет как, USB-”брелков”? Да по сути ничем. Ну да, SATA это в принципе более производительная шина, чем USB2.0. Да, в современных контроллерах Flash используется чередование и wear-leveling, но все то же самое используется и в современных высокоскоростных USB-”флешках”.

То есть в чем инновационность SSD? Только в том, что мы можем ставить его в те, ранее выпущенные устройства, которые знают и умеют работать только с жесткими дисками.
Некая аналогия с VTL - Virtual Tape Library. Мы можем поставить их там, где софт умеет работать только с ленточными библиотеками, как, например, какние-нибудь запрограммированные на Коболе мэйнфреймы 70-80-х годов. И при этом нам не надо ничего менять на стороне остальной системы.
Но в том случае, когда нас не заботит “обратная совместимость” с прежним оборудованием, если мы можем создать IT-систему с нуля, тогда нам, скорее всего, незачем эмулировать поведение ленточных библиотек, мы можем поддерживать диски нативно.
По моему наблюдению, именно это причина плохих продаж VTL в России, по сравнению со всем миром, где VTL совершенно явные фавориты, выпускаемые многими вендорами дисковых систем.
В России просто незначительна проблема “унаследованного оборудования” и “унаследованных решений” (legacy solutions), и проблема совместимости для “начисто” создаваемой IT-инфраструктуры минимальна.
Конечно конкретно NetApp VTL это не только эмуляция, но также множество других, зачастую уникальных фич, таких как Direct Tape Creation и дедупликация, но в основном все так.

Таким образом, EMC решило эту задачу минимально затратным и наименее “умным” способом, просто сэмулировав на высокоскоростных Flash-устройствах обычные диски, подобно тому, как VTL эмулирует “ленточные библиотеки” на дисковых массивах.
Если здоровый человек хорошо размахнется и ударит отбойным молотком, то, конечно, сможет использовать его в качестве обычной кувалды, но нативное его применение может быть гораздо эффективнее.

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

Вот, что пишет у себя в блоге уже знакомый вам инженер-разработчик NetApp Костадис Руссос:

“Существует три возможных варианта ситуации с доступом к датасету:
1. Низкий уровень IOPS, малая нагрузка
2. Высокая нагрузка по IOPS, когда датасет помещается в кэш
3. Высокая нагрузка по IOPS, когда датасет НЕ помещается в кэш

Очевидно, что из этих трех сценариев только третий - кандидат на использование Flash-дисков.”

Однако NetApp выбрал иной путь, создав PAM - Performance Acceleration Module, модуль расширения кэша. Своеобразный “SSD”, но не в виде эмуляции дисков, как принято сейчас делать, а на уровне архитектуры системы в целом.

Он же:

Практика показывает, что большинство данных это так называемые “холодные данные” (то есть данные, уровень обращений к которым невысок). Таким образом платить за высокую производительность для “холодных данных” есть очень дорогостоящее решение. Но если система хранения обеспечивает высокую производительность работы для “горячих” данных, даже если они при этом лежат на медленном хранилище, то цена Flash, как среды хранения данных, в таком случае значительно уменьшается.
Другими словами, да, жесткие диски 15KRPM не обеспечивают исключительно высокой производительности, но они обеспечивают достаточный уровень, для достаточного объема данных, оставляя для SSD Flash нишу.

Я довольно давно собираюсь развернуто написать про PAM и его устройство, те, кто был в этом году на NetApp Innovation 2009 наверняка слышал рассказ специалиста московского отделения компании, Романа Ройфмана, о Performance Acceleration Module.

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

18/0.176

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