Archive for августа 2008

Дедупликация. Новости и слухи.

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

Во первых, многие заметили, произошел отказ от аббревиатуры 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. Она есть, но она бесплатна.

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

«Передний край» – iWARP

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

Стремительное продвижение технологий в повседневность 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

И снова здравствуйте. :)

Привет.

Executive summary: Блог восстановлен после неудачной передачи в неработоспособные руки. В дальнейшем буду продолжать сюда писать, не обещаю черезмерной регулярности, но буду. Тематика прежняя - системы хранения данных, прежде всего NetApp, и все что вокруг этой темы покажется интересным.

Office croud summary ;)
Я постарался восстановить его в прежнем объеме и со статьями на прежнем месте, так что если вы войдете на него по ссылке через поисковик, проиндексировавший прежний блог, то должны попасть на правильную страницу. Если что-то пойдет не так - напишите мне.
К сожалению потеряны фотографии и прочие документы, размещавшиеся на хостинге прежнего блога. Так что некоторые “кортинко не грузяцо” - это нормально. Может со временем как-то починю. А может и нет. Мне более интересен новый материал.
Пишите комментарии, если будет что сказать. Любому автору это приятно. К блогу прикручена авторизация по OpenID, можете пользоваться вашим OpenID-аккаунтом, например логином на livejournal, Yandex Mail или еще кого-то, их множество. Не обязательно регистрироваться у меня. Хотя и так тоже можно.

О замеченной дисфункции блога, в том или ином месте, пишите сюда в комменты.

Ну, поехали.

18/0.145

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