about NetApp

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

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

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

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

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

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

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

–
¹
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:

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.

В ближайшие несколько постов я бы хотел поговорить о некоторых аспектах usable space на системах хранения NetApp. Usable Space на NetApp, а также методы его образования из raw, это также источник бесчисленных спекуляций наших уважаемых конкурентов (в дальнейшем "Н.У.К." ;).
Я отдельно остановлюсь на "говнилках" на эту тему в отдельном посте, а пока давайте разберем фундаментальные основы того, как из Raw Space образуется Usable Space, чтобы подойти к разбору FUD уже теоретически подкованными.

Но начнем издалека.

??так, из чего складывается пространство usable space?
Один из документов NetApp, на который я давал ссылку раньше, так и называется:
Trading Capacity for Data Protection – A Guide to Capacity Overhead on a StoreVault Storage System
Мы платим за надежность хранения raw-байтами, и получаем, в итоге, меньшее по размерам пространство, но с разнообразными "фичами". Это естественный процесс.

Простейший случай обмена "байтов на надежность" это RAID. Мы платим пространством одного диска (в случае RAID-5), двух (RAID-6), или половиной пространства (RAID-10 AKA RAID 0+1) за надежность и быстродействие.
Поверх RAID мы можем создать журналируемую файловую систему, и получаем "фичу" хранения и обработки "файлов", то есть огранизованных структур данных, со всем им присущим, и, вдобавок, защищаем целостность этих структур. Но, разумеется, партиции, загрузочные области, таблицы размещения файлов, ACL, структуры директориев, и прочее, все это также вычтется в свою очередь из пространства, дав нам взамен вышеописанные возможности, которых не было на простом и тупом raw-диске.
?? так далее, и так далее.

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

??з чего же складывается, в свою очередь, usable space на NetApp?

Как вы уже знаете (по крайней мере те, кто давно читает этот блог;), NetApp, как "система хранения данных", довольно "высокоуровнева" по природе, если воспользоваться терминами из области языков программирования. Также как, например, какой-нибудь C# или Java позволяет пишущему полностью абстрагироваться в программе от, например, физической структуры регистров процессора и управления памятью, и заняться более продуктивными вещами, чем вычисления адресов, так и в случае использования пространства хранения на NetApp администратор системы хранения может абстрагироваться от "дисков" и "raw bytes".

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

Он также как и "обычные системы хранения" (тм) использует нижний уровень виртуализации, в виде RAID (RAID это, с точки зрения железа ведь тоже некий "виртуальный девайс"), но начиная с версии своей OS Data ONTAP версии 7 сделан еще один шаг в направлении "высокоуровневой" виртуализации - Aggregates и FlexVol-ы.

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

Я уже писал раньше о важности такого параметра, как IOPS - Input-Output operations Per Second.
Для отдельного диска величина IOPS сравнительно невелика (в пределах двух, максимум трех сотен для SAS или FC, значительно меньше для SATA). Для того, чтобы увеличить производительность в IOPS, создатели дисковых систем хранения объединяют диски, например с помощью создания RAID-групп. Так, например, RAID-10 ("зеркало" с "чередованием") из 10 дисков будет иметь примерно вдесятеро большую производительность по IOPS, чем отдельный входящий в него диск. Это стало возможным за счет того, что, хотя для внешнего потребителя RAID это "один большой диск", внутри же он состоит из множества меньших, на каждый из которых мы можем писать свою порцию более-менее в параллельном режиме.

Однако бесконечно удлинять RAID тоже нельзя, так как снижается надежность и ухудшаются некоторые другие параметры. Кроме того далеко не всегда для данных, требующих высокой скорости, нужно так много места. А объединив 10 дисков по 300GB в RAID-10 мы получим "диск" размером полтора терабайта (300*10/2) под один только наш "скоростной файл". ?? так для каждой задачи.
Как правило производители "обычных систем хранения"(тм) выходят из положения путем возможности "конкатенации" (сложения A+B+C+D…) сравнительно небольших RAID-групп, и создании на получившемся пространстве так называемых LUN - логических устройств - "дисков".
Как видите, тут тоже своя "виртуализация" имеется.

Большим прорывом в свое время стала разработка уже покойной компанией DEC дисковых систем хранения, в которых появилась возможность объединить все "адресное пространство" жестких дисков, имеющихся в системе, в единый "пул байт", и уже поверх этого пула образовывать "виртуальные RAID" и разделы данных. Наследницы этих систем по сей день производятся компаний HP под названием EVA - Enterprise Virtual Array, и занимают до сих пор довольно значительную долю рынка, хотя нельзя закрывать глаза на тот факт, что системы эти постепенно (и все заметнее) морально устаревают, несмотря даже на столь прорывную и революционную идею в их основе.

Преимуществом объединения всех дисков в "общий пул" является возможность распределить входную нагрузку на все эти диски, работающие параллельно, нарезав на них нужное количество LUN нужных нам размеров, которые, свою очередь, также окажутся размазанными на все наши диски. При этом мы не платим за это "длинным RAID" и всеми его минусами, в виде, например, длительного ребилда и пониженной надежности. То есть, если мы имеем систему с 30 дисками, то, если мы сведем все эти диски в один aggregate, нарежем на нем нужное количество FlexVol, и насоздаем LUN (или будем использовать FlexVol под хранение файлов), то производительность каждого такого FlexVol, и LUN на нем, будет равна: 30*300 IOPS = ~ 9000 IOPS.
Все цифры, разумеется, условные и грубоприближенные, но с сохранением порядка.

??так, начиная с Data ONTAP 7, структура хранения выглядит примерно так:

То есть - физические диски, над ними Aggregate, над ними RAID-ы в WAFL, на ней FlexVol-ы, на которых уже, в свою очередь, располагаются LUN-ы или "сетевые папки" NAS.
Каждый из этих уровней немножко отнимает от raw space, и добавляет за это каких-нибудь возможностей.

Продолжение в следующем посте.

Специально свое мнение вынесу из комментов, так как читают меня в основном из RSS, и в комменты мало кто ходит.

Я не считаю, что Fibre Channel это плохо. FC это замечательная технология. Но любая технология лучше всего работает на своем месте, там, где она нужнее, там, где ее преимущества наиболее проявляются.

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

В прошлом своем посте я не столько пытался “опустить” FC, сколько донести мысль, что когда клиент покупает на “последние деньги” какой-нибудь Xyratex или Infortrend (все совпадения с реальным торговыми марками случайны;), при этом наполняет его дисками c “митина”, потому что “нет денег на родные”, но при этом собирается половину, а то и две трети цены массива потратить просто на “провод” для подключения, то это, мне кажется, крайний случай несбалансированности.

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

По моему мнению, FC в entry (да зачастую и не только entry) level это типичный пример гаражного тюнинга и “синих писалок” в IT. Это эффектно, но, как и дырки в глушителе, выдающие мощный рев на светофоре, нисколько не помогают с него уехать быстрее.

Почти всегда, начиная разговор с клиентом по поводу использования iSCSI вместо Fibre Channel, раз за разом я сталкиваюсь с одним упорным возражением:

“Ну… хм… Это же медленно!”

Ну, казалось бы, очевидно: FC это 4Gb/s, а iSCSI - 1Gb/s, “один” ведь в четыре раза меньше, чем “четыре” ведь так?

Давайте разберем что здесь на самом деле “медленно” и медленно ли.

Для определенности давайте рассматривать какую-нибудь реальную задачу.

Вот пример:
Требуется система хранения данных для консолидации данных 4 серверов, 1 файловый сервер и 3 сервера баз данных. Необходимо обеспечить двухпутевое отказоустойчивое подключение.

Но сперва немного теории.

Я уже писал на тему странного спутывания в восприятии совершенно разных параметров канала передачи данных: “полосы пропускания” (анг. “bandwith”) и “скорости” (анг. “speed”).
Для интересующихся подробностями просто сошлюсь на ранее опубликованный пост, а остальным перескажу вкратце.
“Скорость” канала передачи данных равна скорости света в соответствующей среде, и она постоянная, вне зависимости, используем мы 10Mb/s Ethernet или 16GB/s Infiniband.
Переводя на аналогии из “повседневной жизни” это ограничение скорости на дороге - 100 km/h.
Все автомобили по дороге передвигаются с разрешенной скоростью, и ее не превышают по причине физического ее ограничения на уровне физических констант.

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

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

Если скорость считывания и записи сервера с системы хранения, например, не превышают 10 Мбит/с, то совершенно неважно для быстродействия, используете ли вы 100Mbit/s Fast Ethernet, FC, Infiniband, или подставьте_любой_баззворд_из_презентации.
Если вы не используете даже имеющуюся полосу пропускания целиком, то расширение ее “неиспользуемой части” в 10 раз не приведет к сколь-нибудь значимому увеличению реального быстродействия системы.

Да, я знаю про разницу в латентности разных интерфейсов, о перспективности того или иного решения в будущем, о функциональных возможностях, давайте не станем углубляться в детали для того, чтобы рассмотреть лес за деревьями, именно он в данном случае важен, а не теоретические вариации, укладывающиеся в статистический разброс 5%

Вернемся к нашей практической системе хранения для 4 серверов.
В ходе предварительного анализа производительности, наиболее нагруженный сервер баз данных показал, по данным Windows Performance Monitor, следующие показатели:

Disk Read bytes/s 2700902/Average 63587550/Max
Disk Write bytes/s 736811/Average 1616167/Max

То есть, самый нагруженный сервер системы, в максимуме нагрузки, достигал порога чтения всего, примерно, в 60-65 мегабайт в секунду!
Это всего лишь (в пике дневной нагрузки, прошу заметить!) около 55-60% от полосы пропускания одного интерфейса Gigabit Ethernet, или, в случае типовой нагрузки в 2.5-3MB/s, всего около 2-3% от полосы пропускания GigE!

Возможно в данном случае мы упираемся в предел возможности локальных дисков серверов, на смену которым призвана встать система хранения, и сервер имеет большой запас по производительности, если мы обеспечим ему широкую полосу пропускания для данных? Но нет, показатель Disk Read/Write Queue редко когда превышает значение 8-9, что означает относительно слабо нагруженную дисковую подсистему, значит в дисковую производительность сервер практически не упирается.

??так, давайте посчитаем. В случае нашей рассмотренной выше небольшой IT-системы из четырех серверов, в случае выбора FC нам необходимы:
1. по два однопортовых или по одному двухпортовому FC HBA на каждый сервер - 8 однопортовых или 4 двухпортовых (QLogic QLE2462 2port - 700$ * 4 = 2400$)
2. два FC-коммутатора (недостаточно встроенных FC-портов для подключения всех 6 линков) допустим, пусть это будут массовые и недорогие Brocade 200E - 4000$ * 2 = 8000$.
3. Лицензия на FC (в зависимости от выбранного массива цена варьируется, например для системы типа FAS2050 это около 1200$ для одноконтроллерной и 2400$ для двухконтроллерной, отказоустойчивой, “кластерной” системы)
4. ПО поддержки многопутевости (стоит заметить, что в поставке Windows средство обеспечения многопутевости MPIO не поддерживает FC, только iSCSI, и использование MPIO с FC требует установки дополнительного программного модуля, так называемого DSM, обычно предлагаемого поставщиком решения системы хранения, он недорог, но тоже не 0$)
5. Кабеля FC optical LC-LC для подключения серверов к коммутаторам (8 шт) и коммутаторов к массиву (2 шт) (LC-LC optical 5m - 50$ * 10 = 500$).
6. затраты на монтаж и настройку (варьируется).
Кажется ничего не забыл :)

??того, нетрудно видеть, только на возможность использования протокола Fibre Channel мы потратим по меньшей мере около 12-15 тысяч долларов! При этом, как я показал выше, эти 12 тысяч совершенно не увеличат производительность получившейся системы. Они потрачены исключительно “на понты”, на возможность бросить в разговоре с коллегами “а, мы тут файбер ченэл себе прикупили”. :)
“Хороший понт дороже денег”, не спорю. ;) Но 12 тысяч это 12 тысяч. Тем более в наше непростое время на дворе.

Но если бы мы использовали эти, вполне существенные деньги, на что-нибудь действительно дающее реальный эффект, например на пару дополнительных серверов для других задач, премию сисадминам оплату услуг хорошего программиста-оптимизатора баз данных, или, например, в случае системы хранения данных, на дополнительные 10-12 дисков, то за те же деньги мы бы получили (см. ранее про IOPS дисков) систему хранения по меньшей мере на 1800-2500 IOPS быстрее!

?? только за счет отказа от “крутого”, “понтового”, но избыточного, и поэтому совершенно “неполезного” в данном случае Fibre Channel.

В связи с нынешней активизацией на рынке SSD и Flash, возможно кому-то будет интересно посмотреть, какие продвинутые методы применяют разработчики решений, для преодоления присущей flash-memory по своей природе ограничений на число циклов записи. Ограничения сегодня уже достаточно далеко отодвинуты, но, тем не менее, совсем сбрасывать со счетов этот фактор нельзя. Основной метод, применяемый для преодоления этого недостатка, это так называемый wear-leveling. Что это, и как работает, в объяснении “на пальцах” найдено в FAQ компании Corsair (89KB, PDF).

Любопытный документ найден в форумах NetApp Communities (кстати, рекомендую. Это открытый ресурс).

“Обмен дисковой емкости на зашиту данных”
Хотя это руководство и для StoreVault (S-series), но изложенное там верно и для FAS. ??з этого документа можно выяснить как превращается raw capacity дисков в usable capacity дискового пространства NetApp, и что вы получаете при этом взамен уменьшения пространства.

Trading Capacity for Data Protection – A Guide to Capacity Overhead on a StoreVault Storage System

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

Во первых, многие заметили, произошел отказ от аббревиатуры A-SIS, в пользу более понятного NetApp Dedupe и просто Deduplication. Шаг естественный. Немногие сходу вспомнят, что A-SIS это Advanced Single Instance Store, еще меньше - поймут о чем речь. Переход от “инженерной” аббревиатуры к “самоописывающему” названию есть вполне правильный путь.

Во вторых, проект “Дедупликация” скоро будет иметь две ветви: FAS Deduplication (ныне существует), и VTL Deduplication, ожидаемый давно, и обещаемый в первом ограниченно доступном для клиентов виде в конце этого года (сейчас она проходит ограниченное бета-тестирование).
Казалось бы, что за труд внедрить уже работающую технологию на параллельной линейке той же компании? Однако же как оказалось не все так просто. По сути под названием VTL Deduplication мы будем иметь некий принципиально новый продукт.
Не зря официальные лица так настойчиво повторяли весь год про “backup-oriented” и “stream optimized”.

Прежде всего, это действительно, в отличие от FAS Deduplication, ориентированного более на General Purpose применение, будет специализированное решение для дискового бэкапа, специально для этого заточенное. Причем заточенное настолько, что, как у меня сложилось впечатление, это будет принципиально иной по своему “коду” продукт под уже “раскрученным” названием. В пользу этого говорит и то, насколько долго с ним возятся.

Так, например, в VTL Dedupe, кроме уже известного режима post-process, который сохранился, добавится и некий inline. То есть система будет пытаться проводить дедупликацию в том числе и непосредственно “в онлайне”, в процессе поступления данных на диски, аналогично online compression.

Практический кейс: У меня есть 100 идентичных образов виртуальных машин по 1GB каждая (ну например 100 установленных Windows XP, отличающихся только несколькими байтами hostname). Я бэкаплю их на диски NetApp со включенной дедупликацией. Сколько понадобится выделить под это места? Нет, не 1GB. Даже несмотря на дедупликацию сперва нам нужно будет все 100GB, а затем 99GB нам вернутся, когда система завершит цикл дедупликации, происходящий в постпроцессе, в “оффлайне”.
В случае VTL Dedupe скорее всего какая-то часть дедупликации пройдет уже в процессе записи.

Второй момент, натолкнувший меня на мысль о принципиально ином продукте, был сведениями о том, что VTL Dedupe будет оперировать переменными размерами блока.

Напомню вкратце принцип работы FAS Deduplication.
Система хранения NetApp FAS устроена таким образом, что для каждого блока данных WAFL “внутри системы” вычисляется и хранится некая хэш-строка. Она довольно давно используется для дополнительного контроля целостности данных при их обработке в системе. Как я понимаю, для дедупликации просто воспользовались уже существующей в системе возможностью. Следствием стало то, что включение дедупликации как таковой, почти никак не затрагивает производительность самой системы. Ведь система и так уже эту функцию имела, добавился только некий процесс с существующими данными, осуществляемый в фоне, с низким приоритетом. Это позволило использовать дедупликацию в том числе и для систем хранения “общего применения”, что на сегодня не предлагает ни один из конкурентов.

??так, каждый 4kb-блок WAFL сопровождается хэш-строкой, идентифицирующей, с той или иной степенью достоверности, его уникальность. Если мы находим два идентичных хэша, то мы можем предположить, что соответствующие им блоки данных также иденичны. Для того, чтобы избежать так называемой “hash collision”, когда по какой-то причине один и тот же хэш соответствует разным блокам, такое возможно при не слишком сложном алгоритме вычисления хэша (который применяется в NetApp, дабы не грузить излишне систему) система проводит для таких блоков “контрольную проверку” путем простого побайтного сравнения этих 4kb-блоков. Если блоки действительно совпали, то один из них освобождается, а в таблице размещения указатель на него переставляется на оставшийся.

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

Это является основной причиной иногда наблюдаемой на практике невысокой эффективности дедупликации. Так, например, в случае VMFS-файлов VMware, обычно строго выровненных относительно границы блока, эффективность дедупликации будет высока. Однако, например, файлы резервных копий, создаваемых системами резервного копирования, часто имеют внутри себя то или иное смещение, при том, что физически содержимое их может быть и идентично.
??льдар, похоже это вот как раз твой случай.

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

Однако, как и в случае с FAS Deduplication, NetApp сохранил очень приятную для нас, “конечников”, модель с бесплатной лицензией. То есть лицензия-то все равно есть, и для включения дедупликации она все равно нужна, но она бесплатна. Нужно ее только заказать через вашего партнера. То есть ситуация как с лицензией для iSCSI. Она есть, но она бесплатна.

?? еще несколько слов в заключение. Уважаемые ребята из московского представительства: Роман, Роман, Саша :). Я знаю, что вы меня читаете ;) Бога ради, если вы считаете, что я вдруг опять ненароком тут засветил какую-то Страшно Охраняемую Военную Тайну, которую Рано Показывать Публике - свяжитесь со мной, что-нибудь придумаем, исключительно из соображений доброй воли. Угум?

Что есть что на горизонте.

Стремительное продвижение технологий в повседневность IT-служб иногда поразительно. Сегодня, когда интерфейсы Gigabit Ethernet устанавливаются уже даже в ноутбуки, реальностью становится 10Gigabit Ethernet, который еще пару лет назад был чем-то из области лабораторных изысканий. Что же принесет нам этот виток скоростной гонки интерфейсов – давайте посмотрим.

RDMA

RDMA это Remote DMA. Для тех, кто за заботами сегодняшнего дня забыл об основах, позволю себе немного поликбезничать.
DMA, или Direct Memory Access, это классическая технология ввода-вывода данных с помощью специального программируемого контроллера DMA – прямого доступа к памяти.

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

Проблема с загрузкой процессора при вводе-выводе была решена использованием процедуры DMA – Direct Memory Access. Процессор единожды сообщает специальному контроллеру DMA, с какого или в какой адрес в памяти он желает осуществить перемещение данных, а контроллер исполняет, по завершении уведомляя процессор об исполнении. Получает или передает байты жестким дискам, выводит массивы данных в видеоконтроллер или превращает «цифру» в звук.
Результат обычно весьма впечатляющ. IT-шники со стажем должны помнить, какой эффект давал переход жестких дисков персональных компьютеров с режима PIO (Programmed Input-Output) к DMA (и в дальнейшем к UltraDMA), степень загрузки процессора на интенсивных дисковых операциях снижалась в разы.

Но DMA это лишь локальные операции, проще говоря, возможные только в области памяти и устройств одного компьютера. А что если сделать технологию DMA возможной для разных и между компьютерами?
Так родилась идея RDMA – Remote Direct Memory Access.

Технология эта отнюдь не нова. За ее разработкой следит представительный RDMA Consortium, куда входят многие гранды индустрии, такие как IBM, Cisco, NetApp, EMC, HP, Intel, Microsoft, общим числом около 50. Она шумела как новинка еще в 1998 году, а в 2003 году RDMA Consortium объявил о завершении всех запланированных спецификаций. Однако множество проблем в реализации ограничили ее применение high-end HPC (high-performance computing) системами. RDMA той или иной форме применялась на системах Cray, Silicon Graphics и ряде других, столь же легендарных «небожителей».
Однако шли годы, и то, что было уделом экспериментальных и сверхвысокопроизводительных вычислений стало нашей повседневностью, вот и до 10G Ethernet очередь дошла.

Основной идеей, родившей и развивающей RDMA как концепцию, была «размещать нужные данные непосредственно в память приложения», минуя многочисленное каскадное буферирование «из буферов сетевого адаптера в буфера сетевого протокола, из него в буфера OS, из них в буфера дисков, и так далее». ??менно поэтому в приложении к RDMA часто используется термин «zero-copy», то есть «отсутствие копирования», имея ввиду, конечно же, вот такое вот многократное промежуточное копирование между источником и получателем данных.

Наиболее известной реализацией RDMA и его «zero-copy» в применении к системам передачи данных на сегодняшний день является Infiniband, разработанный в соответствии с этими требованиями. На сегодняшний день это наиболее известная сетевая система для высокопроизводительных кластерных интерконнектов, в свое время, за счет своей открытости и меньшей цены, вытеснившая из этой области проперитарный Myrinet.

iSCSI – SCSI over IP
Я уже не раз писал о iSCSI, и останавливаться подробно наверное нет смысла. Сегодня уже все так или иначе находящиеся в теме систем хранения знают что это. iSCSI это способ передавать обычные и привычные SCSI-пакеты «упакованными» (модное словечко: «инкапсулированными») в IP-пакеты, и транспортировать их в любой среде передачи IP, например по Ethernet-сети. Тем самым между сервером и его жесткими дисками может находиться не традиционный 68-жильный кабель WideSCSI, а сетевые карты, ethernet-коммутаторы, провода Cat5, СКС, и прочие привычные скорее для «сетевиков» вещи. В наше время, когда в области передачи данных все явственнее происходит конвергенция «все в Ethernet-провод», когда даже будущее такого консервативного протокола как FibreChannel его основным локомотивом, компанией Bocade, видится, по ее заявлениям, в виде FCoE – FibreChannel-over-Ethernet, ничего удивительного, что iSCSI нашел себе сегодня широчайшее применение.

TOE – TCP Offload Engine
iSCSI, как протокол в целом, состоит, по сути, из двух независимых частей. Также отдельно они, как правило, и реализуются в оборудовании. Одна часть – «SCSI», и все относящееся к этому протоколу. Вторая – «i» - TCP/IP и все касающееся его.
Как известно, iSCSI может быть реализован полностью программно, и, в ряде случаев это совсем неплохой выбор, недорогой и исключительно гибкий. При этом задачи поддержки протокола осуществляет специальная программа – iSCSI Initiator, которые сейчас существуют во всех распространенных операционных системах. Эта программа создает в системе «виртуальный SCSI-адаптер», с которым могут обычным образом взаимодействовать прикладные программы. В дальнейшем она производит на центральном процессоре системы собственно задачи инкапсуляции SCSI-пакетов в IP-пакеты и отправку их драйверу сетевого интерфейса Ethernet, как обычное приложение или драйвер.

Такая модель дает нам беспрецедентную гибкость реализации, однако, очевидно, создает дополнительную нагрузку на центральный процессор, которую, при скоростях вплоть до Gigabit Ethernet еще можно обычно игнорировать, но на скоростях 10Gigabit Ethernet это уже становится сложно. Поэтому для 10GigE-систем как правило применяются те или иные «аппаратные» реализации.

«Аппаратизация» iSCSI может быть осуществлена раздельно по рассмотренным выше частям. Мы можем сделать сетевую карту, которая будет самостоятельно производить всю TCP/IP-шную рутину, такую как расчет контрольных сумм и сборка фрагментов, такое устройство называется TCP Offload Engine – TOE. При этом «SCSI-адаптер» в системе у нас остается виртуальным.

Либо сделать полную реализацию обоих частей протокола, то есть аппаратный SCSI-адаптер, на выходе которого будет не WideSCSI-разъем, а сетевой интерфейс, медный или оптический. Реализация же самого протокола для системы и ее приложений, как и ранее, будет для приложения и операционной системы полностью скрыта.

Как правило адаптеры 10Gbit Ethernet имеют в себе либо TCP Offload Engine, сохраняя программную реализацию SCSI, на CPU системы, в драйвере. Либо полную аппаратную реализацию. Такие адаптеры принято называть, как и в FibreChannel-системах – HBA – Host Bus Adapter.

iWARP
iWARP это Internet Wide Area RDMA Protocol – протокол работы RDMA по IP-сетям, основанный на концепциях Virtual Inerface Architecture, и, в определенном смысле, может рассматриваться как некий «Infiniband-over-IP».

С того момента, когда возросшие скорости Ethernet-сетей стали явной проблемой для чисто программной реализации TCP/IP, разработчики задумались над методами разгрузки процессоров, и одним из них стал TOE – TCP Offload Engine – аппаратная реализация TCP/IP на микросхеме контроллера ethernet-адаптера. Такое решение значительно разгружает центральный процессор от задач поддержки передачи данных, которая теперь, в значительной мере, может осуществляться самим контроллером сети. Особенно это стало важно при увеличении скорости и переходе к 10Gbit Ethernet, работа над такими объемами может серьезно нагрузить и довольно мощный современный процессор. А ведь у него есть и другие задачи, кроме как считать контрольные суммы IP-пакетов.

Чаще всего с помощью iWARP передаются такие «вышележащие» протоколы, как SCSI RDMA Protocol (SRP), iSCSI Extensions for RDMA (iSER), Sockets Direct Protocol (SDP) и NFS-over-RDMA.
Как видите, интерес Network Appliance к данной технологии понятен и объясним.

iSER – iSCSI Extensions for RDMA - это расширение протокола iSCSI, позволяющее ему работать по сетям, предоставляющим RDMA-сервис, например по Infiniband или iWARP. Он позволяет передавать данные непосредственно из и в буфер данных SCSI, минуя многочисленные промежуточные копирования данные из одного буфера в другой при традиционной обработке и передаче данных.
Целью создания iSER была попытка избежать проблемы фрагментации TCP при работе «классического» iSCSI, который, как вы помните, унаследовал от TCP/IP сетей, кроме массы полезного, и неприятную проблему фрагментации, которая, на больших скоростях передачи, характерных для 10Gbit Ethernet может приводить к заметному ухудшению latency. Суть проблемы заключается в том, что, при передаче, согласно природе TCP, пакеты могут приходить получателю в произвольном порядке, и дело получателя расставить их в нужном порядке, прежде чем передавать на обработку. Однако, пока получателю не придет пакет «номер два», он не может передать в SCSI буфер уже принятые пакеты номер «один», «три», «четыре» … «десять», которые вынуждены дожидаться прихода заплутавшего по сети «второго».
Вследствие этого возможны плохопредсказуемые задержки, которые были незначительны на небольших скоростях, но уже не могут игнорироваться на высоких.
Для решения этой проблемы iSER использует «zero-copy»-возможности RDMA вместо обычного способа инкапсуляции в TCP.
В качестве протокола передачи на транспортном уровне может использоваться, кроме «нативного» SDP – Socket Direct Protocol, и специально разработанный для потоковых передач протокол SCTP – Stream Control Transmission Protocol (RFC4960), являющийся функционально объединяющим преимущества TCP и UDP для целей передачи «потоковых» данных.

Первоначально этот протокол разрабатывался для целей передачи телефонии через IP, но прекрасно подошел и для других потоковых нужд современной Сети. Поддержка SCTP широко присутствует во множестве распространенных операционных системах, например IBM AIX v5, Cisco IOS v12, FreeBSD v7, Linux 2.4/2.6, HP-UX, Sun Solaris 10.
RDMA и NetApp

Компанию NetApp и RDMA связывает многое. NetApp является одним из учредителей вышеупомянутого RDMA Consortium, и еще в 2002 году начала продавать любопытный продукт для своих систем хранения - DAFS Database Accelerator, решение, базирующееся на протоколе DAFS – Direct Access File System. Это RDMA-based протокол, ориентированный на работу с высокопроизводительными базами данных.
Однако, несмотря на хорошие бенчмарки, согласно которым доступ к сетевому хранилищу NFSv4 через сетевой интерфейс (использовалась специальная карта Emulex VirtualInterface) превосходил по параметрам доступ к локальным дискам системы, продукт не стал бестселлером, и вскоре незаметно исчез из прайс-листа, по видимому придя на рынок слишком рано.

Но сегодня продукты c RDMA появляются на рынке, используя уже широко и активно распространяющиеся 10Gbit Ethernet-системы. Среди их производителей стоит назвать, например, такие имена, как Chelsio Communications, производящий такой интересный продукт, как Chelsio S310SR – 10G-адаптер с TCP Offload Engine, аппаратным iSCSI, виртуализацией и RDMA. Причем цена за пару, в так называемом Evaluation Kit на сайте производителя, показана ниже чем 2000$ за карты с SR optical interface и ниже 1500$ за карты с «медным» CX4.
Существуют и версии в «мезонинном» исполнении, для установки в blade-системы, например в HP Type II Blade Systems или IBM Blade Center H.

Любопытно будет также ознакомиться с тестами и бенчмарками. Они, хотя и «вендорские бенчмарки», относиться к которым надо достаточно осмотрительно, но показывают потенциальные возможности новой технологии.

Experiences with NFS over IB and iWARP RDMA
OpenFabric Workshop, Sonoma, CA
May 1, 2007

InfiniBand and 10-Gigabit Ethernet for I/O in Cluster Computing
July 26-28 Cluster Symposium 2005

Performance Characterization of a 10-Gigabit Ethernet TOE

Head-to-TOE Evaluation of High-Performance Sockets over Protocol Offload Engines