Обектният сторидж набира скорост с нарастването на неструктурираните данни

Категория: Информационна Сигурност , Сторидж
Information Security & Storage
сряда, 25 Август 2010 11:34ч

Обектният сторидж набира скорост с нарастването на  неструктурираните данни

 Обектният сторидж не е нова концепция в света на NAS, но някои продукти заобикалят традиционните интерфейси на файловата система, откакто започна дебатът за най-добрия начин за боравене с неструктурирани данни.

В епохата на Web 2.0, на експлозията на облачното и цифровото съдържание, корпоративните сторидж мениджъри преосмислят как да съхраняват неструктурирани данни, след като производителите пускат нови обектно базирани сторидж системи, проектирани да предоставят опростено управление и по-мащабируеми схеми за метаданни. Очаква се неструктурираните данни да надминат значително ръста на структурираните данни през следващите три години. Според доклада Enterprise Disk Storage Consumption Model на IDC, публикуван миналата есен, макар че се очаква съставният годишен ръст на транзакционни данни да е 21.8%, предвиждането за ръста на неструктурирани данни е 61.7%.

Ще има извънредно количество данни като цифрово видео и разрастване на мобилните мрежи. До пет години е много вероятно всеки телефон да бъде интелигентен. Професионалистите по сторидж вече разсъждават какво ще е необходимо при този ръст като сторидж инфраструктура.

Мислете в API, не във файлове

Традиционните йерархични файлови системи организират данните в „дървета“, състояща се от директории, папки, подпапки и файлове. Файловете сa логичeското представяне на блокове от данни, свързани с приложение и са най-познатите средства за работа с данни. Интерфейсите на мрежовите файлови системи като NFS и CIFS са добре разбрани, стандартизирани методи за предаване на логически групи от блокове от едно хранилище за съхранение към приложение.

Проблем възниква обаче, когато традиционните файлови системи, които теоретично имат ограничен брой файлове, които могат да адресират в една директория, и следят само прости метаданни, оперират в масивни хранилища от подобни файлове.

Файловите системи имат все по-малко смисъл с времето, тъй като размерът на данните расте, смятат специалистите. В архитектурно отношение има по-дълбок смисъл за всеки файл да има уникален 128-битов идентификационен номер и да се използва подобна на интернет система за локализиране на този файл. Един URL сочи към един адрес и има файлове на този адрес, а обектно-базираните сторидж интерфейси по същество работят на същия принцип.

С номер на обекта вместо име на файл е възможно повече данни да придружават един обект, а не само полетата „създаден“, „променен“ или „записан на“, налични в традиционните файлови системи. По този начин могат да бъдат приложени детайлни политики към обектите за по-ефективно и автоматизирано управление.

Без NFS или CIFS, които да подават файлове към приложенията, обектно базираните сторидж системи трябва да заменят този слой на абстракция между „суровите“ блокове от данни на диска и файлове, които приложението може да разпознае. Днешните обектно базирани системи използват стандартни API, като Representational State Transfer (REST) и Simple Object Access Protocol (SOAP), или частни API, които да казват на приложенията как да съхраняват и извличат данни.

Новите обектно базирани сторидж продукти се целя в облака

Компании като Amazon, Flickr, Google или YouTube, чиито интелектуална собственост и диференциация идват от предлагане на уеб базирани приложения и които програмират свои собствени интерфейси, това не е такъв голям проблем. Но за компании с десетки или стотици приложения съшиването на код, за да накарат всяко приложение да работи с обектно базиран сторидж, може да бъде обременяваща и нерентабилна задача. Има обаче някои производители на системи за съхранение, които предлагат предварително вградена, но гъвкава архитектура, която върши работа.

Фирма Caringo за първи път предложи адресирана към съдържанието сторидж (CAS) система за nearline, а не за архивиращ сторидж, където исторически се използваха CAS системи като ЕМС Centera (проектирани от същите инженери, които по-късно основават Caringo). През май 2008 г. компанията заяви, че нейният CAStor продукт може да заеме мястото на файловата система или на глобалното пространство от имена в традиционните клъстерирани продукти за съхранение. CAStor оперира с CIFS или NFS, използвайки файлова гейтуей система, която също може да се клъстерира (въпреки че не е налично глобално пространство от имена на гейтуея), както и HTTP достъп. Според компанията CAStor може да бъде инсталиран на почти всеки хардуер x86 с директно присъединен сторидж (DAS).

EMC навлезе на пазара през ноември 2008 г. с нейната система Atmos, която е наречена оптимизиран за облака сторидж (COS). Atmos използва обектно базирани метаданни, за да позволи на потребителите да задават правила, които определят къде да се съхраняват данните, кои услуги да се прилагат към тях и колко копия трябва да бъдат създадени и къде трябва да се съхраняват. Вградени са REST и SOAP уеб услугите, както и възможности като репликация, създаване на версии, компресиране на данните, дедубликация и изключване на диска. Потребителите не трябва да създават файлова система или да присвояват логически номера на устройства (LUN) по време на инсталирането те просто отговорят на няколко въпроса, за да установят правила.

DataDirect Networks обяви уеб мащабиране на обект (WOS) през юни 2009 г. и се очакваше да достави системата преди края на 2009 година. EMC каза, че Atmos може да се мащабира до няколко петабайта и милиарди файлове, но DataDirect Networks казва, че WOS могат да се справят с повече от 200 милиарда файла и 6 петабайта (PB). Компанията твърди също, че има предимство пред Atmos и в производителността, тъй като нейната система държи метаданните на обекта в паметта на сървърните възли. Atmos метаданните са разделени и се съхраняват в няколко бази данни, разположени на много дискове в системата.Cleversafe представи своята систем dsNet Object Store във фаза на бета тестване през септември 2009 г. Възлите за съхранение SliceStor на Cleversafe могат да „счупят“ един файл на 11 части за излишък, създавайки хеш, който е приложен към всяко парче за реконструкция. Cleversafe предвижда вградено криптиране и по-рано предлагаше продукта с блоков iSCSI или WebDAV интерфейс. Тя предлага API за обектно базиран достъп до dsNet въз основа на комплекта софтуер Java (SDK) или използвайки REST.

По-наскоро царят на облака Вал Берковичи от NetApp разкри в един блог, че компанията, известна най-вече с мрежовия си сторидж NAS, ще предложи в обозримо бъдеще собствен интерфейс за обектен сторидж.

Споровете около обектния сторидж

Пол Карпентер, главен технолог и съосновател на Caringo, е изобретил CAS като основател на FilePool, която стана Centera, след като бе продадена на EMC през 2001 година. Карпентер е станал може би най-изявеният поддръжник на обектно базирани системи за съхранение като заместители на файлови системи. „Това е един разгорещен дебат казва Карпентер. Лично аз съм убеден, че използвахме йерархичния начин твърде дълго.“

Карпентер твърди, че файловите системи първоначално са били построени, за да позволят едновременно достъп до по-малки групи от обекти, споделени между няколко потребители. Но сега, казва той, има „несъответствие между преобладаващите случаи на използване на неструктурирани данни и начина на работа на тези системи. Деветдесет до 95% от нас не се нуждаят от системи за съхранение с едновременно заключване за справочната информация.“

Карпентер отбелязва, че управлението на файловите системи е прекалено обстойно, за да бъдат практични в мащаба на петабайтите. Някои продукти създават виртуализационен слой, който представлява глобалното пространство от имена, но отдолу може да има 20 файлови системи, които трябва да се управляват самостоятелно и рано или късно Web 2.0 бизнес моделът изпада в невъзможност, казва той.

Обектните интерфейси отделят данните от хардуерния диск по начин, който не е по възможностите на файловата система. При обектите няма лимит за размерите или концепция за размера на диска, има само едно-единствено пространство от имена, което може теоретично да обхваща всички твърди дискове на планетата.

Един потребител на EMC и NetApp казва, че е съгласен с тази гледна точка. „Чувствам наистина силно, че файловите системи, които имаме днес, не са толкова добри. В мейнфрейм епохата, можехте да включвате атрибутите на даден файл, за да ги управлявате казва той. Ако се нуждаете да управлявате някои файлове по различен начин от другите с файловите системи, то сега го правите в отделни отделения на сървъра.“

Това противоречи на консолидацията, ставаща с виртуализацията на сървърите, и обектно базираният сторидж може да бъде ключов фактор за изграждане на виртуален сървърен свят, в който един обект не е файл, а VMDK (дисков файл на виртуалната машина). Това означава, че можете да споделите един VMDK между повече физически сървъри, отколкото е възможно с днешните файлови системи, и да го защитите в по-голяма степен чрез базирано на политики управление, при което може да се каже, че нещо с „P“ във VMDK името, следва да бъде защитено по различен начин от нещо с „D“ в името.

Все пак, дори в някои от най-взискателните среди, файловите системи може да свършат работа. Говорейки на скорошната конференция Wikibon.org, Юджийн Хакопианс, старши системен инженер в Калифорнийския технологичен институт, заяви, че 2 PB сторидж в неговата среда, включваща милиарди от 5 до 25 KB файлове, все още работи най-вече на традиционните системи за съхранение от Nexsan Technologies.

Но това е било въпрос на време, жизнен цикъл на проекта и бюджет, а не на технически предпочитания. „Ние сме разглеждали обектно базиран сторидж и го имаме предвид за по-нови проекти казва Хакопианс. Трудно е да се прехвърлите на новите технологии и хвърлите допълнителни пари, когато сте в средата на опита да изпълните проекта.“

Различни продукти за различни случаи на използване

Друга гледна точка счита, че файл срещу обект не трябва да бъде предложение от рода или-или. NetApp и EMC например изразяват тази гледна точка.

„Ако има ограничения в традиционните файлови системи, днес още не се сблъскваме с тях казва Петер Тейър, директор на маркетинга за средн клас продукти на EMC. Това е повече въпрос на приложно ориентираните случаи на използване при Web 2.0, изискващи допълнителни метаданни, които се задъхват в традиционното пространство на днешните файлови системи.“

Берковичи от NetApp споделя тази гледна точка. NetApp продължава да пуска продукти, базирани на файловата систем, като напоследък това е ONTAP 8 операционната система, която ще поддържа разширяване. Въпреки това, „ако трябва да се поддържат милиони, стотици милиони или милиарди подобни обекти, като медицински изображения, сторидж интерфейсите са истинско главоболие каза той. Вие не искате да създавате LUN, папки и разрешения, а просто искате една-единствена мащабируема директория.“

Някои потребители намират, че комбинация от продукти работи най-добре за различни нужди в рамките на една и съща среда. В Центъра за изследване наследствени заболявания на университета Джон Хопкинс обработката на данните за генетични изследвания се извършва с помощта на клиенти, присъединени към 72 TB клъстериранa NAS система на Isilon Systems, но след като данните престанат да се споделят активно между изследователите и се съхраняват като справочна информация, те се преместват на обектно базираната система CAStor на Caringo.

След като данните преминат в архивен етап е по-важно да може да се получи достъп до данните и метаданните бързо, когато това е необходимо.

Комбиниране на файлови протоколи със складове от обекти

Файловете и обектите не са непременно взаимно изключващи се идеи дори в рамките на една и съща система. Всъщност няколко съществуващи разширяващи се NAS системи вече имат складове за обекти, лежащи под файловия интерфейс, включително Titan на BlueArc, ActiveStore na Panasas и Hyper-scale Storage Cloud на ParaScale.

„Обектите са един претоварен термин казва Брент Уелч, директор софтуерна архитектура в Panasas. Различните хора го определят по различен начин, но това е по същество един контейнер за данни, който служи като градивен елемент за по-високо ниво системи за съхранение.“ Разпределената файлова система на Panasas преплита заедно NFS и основните складове с обекти, за да се отговори на изискванията за скалируемост при високопроизводителни изчисления.

Системи като CAStor и Atmos по същество премахват обратно слоя от мрежови протоколи и позволяват на приложението пряко да взаимодейства със склада от обекти. Някои продукти, като Titan на BlueArc, също позволяват на администраторите да търсят използване на по-подробни обектно базирани схеми на метаданни, въпреки че крайните потребители в дадената среда, имат достъп до системата чрез NFS.

Джеймс Райни, изпълнителен директор стратегически технологии в BlueArc, казва, че BlueArc е позволила на някои партньори да интегрират приложения директно в скалда с обекти с помощта на собствени API, и те имат предвид отварянето на това API за по-широка употреба.

Някои корпоративни потребители търсят да улеснят обектно базираните системи за архивиране на данни в техните среди, като поставят стандартен файлово базиран достъп заедно с една от по-новите обектни системи за съхранение, построена върху обикновен хардуер. BlueArc съхранява файловата система и метаданните на обектите в собствени полево програмируеми гейт масиви – FPGA, а Panasas използва собствен клиент NFS (виж „Мирно съвместно съществуване: Обектът среща файла“ по-долу).

Мирно съвместно съществуване: Обектът среща файла

„Ние имаме много наследени неща. Искаме да използваме обекти за скалируемост на архивите с медицински изображения в дългосрочен план, но не сме Web 2.0 компания, която да започне на чисто с база данни и обекти. В същото време почти всяка компютърна система на планетата може да се свърже чрез CIFS и NFS“ казва Майкъл Пасе, сторидж архитект на Медицински център в Бостън.

Пасе работи с ЕМС инженери, за да се получи достъп до файловете в Atmos. „Те ни помагат да дадем тласък от страна на файловите протоколи, но има значителна работа за вършене със Samba, за да се свърже към системи Windows чрез CIFS“ казва той.

Въпреки че управлението на обектите ще се превърне в необходимост някъде по пътя, Пасе смята, че Atmos хардуерът и разширяващите се архитектури са нужни в момента.

Свързването на Windows системи чрез CIFS и Samba към обектно базирана система е доста езотерично. Въпреки това Брент Уелч, директор софтуерна архитектура в Panasas, заявява, че версия 4.1 на стандарта NFS ще включва подкрепа за свързване чрез pNFS на клиент към файл, блок или обектно базирани сторидж системи, потенциално облекчаваща интеграцията на обектно базиран сторидж в корпоративните среди с наследени данни, какъвто е случаят на Пасе.

Въпреки усилията за сливане на обектните и файловите системи някои специалисти прогнозират, че дебатът около файловете и обектите ще продължи. Налице е нещо като религиозна война от доста време. Файловите системи бяха ключова технология в продължение на десетилетия, но бързо достигаме точка, в която няма особен смисъл повече да се привръзват данните към конкретен диск, свързан към определено име на път.


Етикети: сторидж продукти , Обектен сторидж , файлови системи

Четете още:



Последни новини
Джони Деп се завръща на голям екран в емблематичната си ...
 
AOC представя най-бързият геймърски монитор с NVIDIA G-SYNC до момента. ...
 
Още един смартфон от богатото портфолио на Huawei вече е ...
 
Приложенията Word, Excel и Outlook вече могат да бъдат интегрирани ...



Най-четени