Системи за централно архивирање података – захтеви система за складиштење податка

Настављамо причу о хардверском делу система за архивирање како би систем у целини добио одговарајућу архитектуру и уштеде. Пре архивирања сви подаци релевантних система похрањени су на диск простору продукционих сториџ системима   (NetApp, EMC, HP, IBM и др). Како je цена примарног сториџ система (tier 1) по гигабајту висока, податке којима се ретко или уопште не приступа треба преместити на уређаје посебно дизајниране за складиштење пасивних“ података и на тај начин ослободити велике количине простора за продукционе сервисе. Осим смањења цена по гигабајту складишног простора, ови специфични tier 2 диск системи имају и функционалне предности у односу на продукциона окружења. Треба поменути неколико ових функционалности као и захтев који овај уређај мора да испуни:

А. дедупликација : уређаји који су посебно дизајнирани за ове сврхе поседују функционалност inline дедупликације података на нивоу блока променљиве величине чиме се драстично редукује количина података које архиве заузимају, што заједно са софтверским технологијама присутним у апликацији за архивирање (SI –Single Instancing на фајл нивоу, компресија и др) омогућавају уштеде од приближно 90 процената. Све вишеструке копије података заузимају само онолико простора на уређајима колико заузима компресован и дедуплициран садржај једне копије.
Б. репликација : уређаји поседују уграђене функционалности за репликацију података на друге удаљене системе, чиме се добија могућност аутоматске дислокације архиве на другу локацију, могућност disaster recovery-ја система за архивирање. Захтева се да процес репликације ради на нивоу дедуплицираних блокова чиме се умногоме смањује неопходна мрежна пропусност неопходна за пренос података до удаљених система. Такође се захтева да блокови који буду преношени до удаљених локација буду енкриптовани ради заштите од неовлашћеног коришћења.
В. интерфејси : неопходно је да физички уређај има одговарајући интерфејс којим комуницира са системом за архивирање као и са системом за бекап архиве и којем презентује све своје функционалности. Из система архивирања и бекапа се тако управља целим процесом (life cycles) од креирања архива, репликације на удаљене локације, бекапа архиве до брисања архива из система. На овај начин се администрација концентрише само на конкретан систем (архивски и бекап систем, а избегава се свакодневна администрација уређаја) чиме се значајно олакшава администрација целог система.
Г. Гартнер лидер : захтева се да систем буде наведен као лидер у Гартнеровој анализи уређаја у овој категорији у претходној календарској години

Хардверски системи за складиштење архивираних података на примарној и секундарној локацији који одговарају горе наведеним захтевима су EMC DataDomain фамилија производа доступна у разним категоријама у зависности од комплексности система за архивирање и количине садржаја намењеног архивирању у предузећу. Ови уређаји омогућавају лаку конфигурацију и употребу система и за потребе проширења постојећих бекап система у предузећу и за саме процедуре бекапа архива јер поседују неисцрпне функционалности прилагођене овим наменама.

Предложено решење представља платформу са највећим маркет уделом у свету. Своју популарност постигло је широком функционалном подршком, као и великом базом корисника.  Подршка за уређај присутна је у свим водећим бекап и архивским системима, што га чини идеалном опцијом за свако предузеће. Подршка на нашем тржишту и брза доступност резервних делова, за разлику од уређаја ван лидерског квадранта, чине предузећа који се определе за ову опцију потпуно сигурним у високу доступност и функционални континуитет система. За кориснике са имплементираним NetBackup опцијом, уређај пружа највећу могућу подршку за овај бекап софтвер, омогућава да и бекап систем буде проширен на ове уређаје и искоришћен као додатни простор за бекап процедуре. Подршка за OST протокол омогућава екстерну контролу напредних функционалности из постојећег NetBackup система, креирање Automatic Image Replication (AIR) мултидоменског окружења, VMWare и native accelerator опције, Granular Recovery (GRT) подршку и др. Детаљнија обрада бекапа самог Enterprise Vault архивског система биће доступна корисницима по захтеву. На следећој слици налази се Гартнеров магични квадрат за овај тип уређаја из 2014 године, где је и означена његова припадност лидер квадранту:

Гартнеров магични квадрат за Tier-2 диск системе за 2014. годину

У следећем посту бавићемо се целокупном архитектуром система за централно архивирање.

Системи за централно архивирање података – општи захтеви

Када говоримо о архивирању података предузећа, имамо пре свега на уму податке који су део система чији је садржај неструктурираног типа. У ову категорију спадају системи који чине велики део података у предузећу и чија су контрола и животни циклуси првенствено остављени власницима самих података тј. корисницима. Свако предузеће располаже управо оваквим решењима који заузимају велики удео простора на примарном (tier-1) систему за складиштење података, а присутни су углавном у облику електронске поште у  Microsoft Exchange или Lotus Domino системима, затим у облику фајлова и докумената у Share Point и File Server инфраструктурама и то обично на неколико физичких локација које су интегрални део предузећа. Како се већини ових информација приступа веома ретко, пожељно је имати механизам који препознаје овај садржај и интелигентно га премешта у систем који је способан да га анализира, претражује и складишти на одговарајућим уређајима који су прилагођени овом садржају.

Други део садржаја, који такође чини значајан удео у заузећу простора, представљају подаци који имају структуру и део су система продукционих, развојних и тест окружења база података. Највећи део ових структурираних информација део су Microsoft SQL или Oracle система. Како је садржај самих база високо зависан од логике апликација које те податке генеришу и мењају, то не постоји аутоматски систем ван логике апликације који је способан да самостално контролише базе у целини или у њиховом делу без апликативне подршке. Зато се архивирање овог дела података реализује уз помоћ самог апликативног решења или апликативног тима, а процес не поседује априори аутоматизам присутан у подацима неструктурираног типа.

Трећи део садржаја налази се на корисничким системима и уређајима и такође су део неструктурираних података система електронске поште. Ови подаци представљају корисничке архиве чуване ван система за централно складиштење и веома су подложне губитку у случају квара корисничких машина. Целовит систем за архивирање укључује и процес дислокације ових корисничких мејл архива на централизовани систем и њихово укључивање у претрагу и анализу. Овај део архивирања не мора да укључује све кориснике, већ део корисника чије су локалне архиве по садржају значајне за пословање предузећа и чији би губитак имао негативне последице по исто.

Систем за целовито архивирање података предузећа на основу горе наведених општих принципа треба да укључује следећа начела архитектуре који морају бити испуњени. Овде наводимо само део листе начела, а целовити садржај доступан Вам је по захтеву:

  • Централизација система за архивирање – софтвер за архивирање мора омогућити архивирање свих неструктурираних апликативних садржаја у власништву предузећа у јединственој и централизованој конзоли, без коришћења вишеструких апликативних решења, вишеструког начина лиценцирања нити обуке запослених инжењера за различите платформе. На овај начин се постиже једноставно коришћење система, лакша имплементација и централизована подршка произвођача софтвера као и партнера у току животног циклуса система.
  • Коришћење одговарајућих уређаја за складиштење архивираних података – дестинација архивираног садржаја са tier 1 система за складиштење података мора бити премештена на специјализоване tier 2 диск системе чије су капиталне и операционе инвестиције значајно ниже, а са друге стране имају функције прилагођене овим наменама.
  • Подршка за multi-site топологијуСистем мора подржавати архивирање удаљених локација предузећа и ресурса који су тамо имплементирани. Овај захтев може бити остварен коришћењем централизоване имплементације, имплементацијом посебног проширења на удаљеним локацијама или њиховом комбинацијом. Такође пожељна је могућност да систем може архивирати садржаје различитих AD домена, уколико предузеће поседује комплексну организациону структуру.
  • Висока доступност система – како ће будући систем за архивирање садржати велики део пословно критичних информација захтева се његова висока доступност за кориснике. Такође се захтева могућност update-a компоненти и оперативних система компоненти током радног времена. Систем мора садржати редундантност по свим компонентама архитектуре (виртуалне машине, сервери, мреже, сториџ итд.)

Горе наведена начела и принципи представљају смернице за израду комплетног решења за архивирање. У наредним постовима укључићемо се у причу о конкретним производима који задовољавају горе изнете захтеве, те ћемо се детаљније укључити у анализу карактеристика предложених производа и услова који они морају додатно да испуне.

Архитектура сториџ система

Да ли архитектура сториџ система утиче на перформансе, скалабилност, или у крајњем случају на проблеме који су тренутно актуелни код корисника? Данашњи блог пост ће покушати да одговори на ова питања. Са реалним проблемима и примерима решења тих проблема, надамо се да ћете после овог текста приликом следеће евалуације сториџ решења уврстити и категорију архитектуре.

Проблем

Оно што је нас иницијално довело до разматрања архитектуре сториџ система јесте проблем који се све више јавља код корисника, а то је проблем “бучног комшије”. Овај проблем се јавља у ситуацијама када један сервис утиче на рад осталих сервиса. Ако код појединачног корисника постоји само један сервис који је заиста битан за пословање, и ако тај сервис утиче на рад осталих, то генерално није велики проблем зато што је сервис који је битан добио ресурсе који му требају. Али шта ако постоји више критичних сервиса за пословање (под критичним се овде мисли на перформансе тих сервиса), или код клауд провајдера (овде се мисли и на кориснике који су интерно одговорни за сервисе својих служби и њихов SLA), или шта ако постоји један сервис који функционално није толико битан (неки аналитички сервис који захтева доста ресурса) а утиче на рад сервиса који су битни. Како у свим овим ситуацијама да се обезбеди квалитет тих сервиса?

За ресурсе као што су процесор и меморија постоје механизми изолације и резервације, али код сториџ система који је код традиционалних архитектура централно место за све сервисе (што је и било логично са становишта интегритета података и манипулације над подацима) било је врло тешко изоловати и/или резервисати ресурсе зато што их је коначно много. Како решити овај проблем? Па на неколико начина, један најочигледнији је да се праве острва ресурса, где би критичан сервис имао свој сториџ систем који би се димензионисао за захтеве сервиса. Други начин може бити да се приликом иницијалне набавке, сториџ систем димензионише за ситуације збира перформанси свих захтеваних критичних сервиса. И први и други начин више једноставно нису прихватљиви због своје неекономичности и нефлексибилности. Када би само постојао неки механизам квалитета сервиса на самом сториџ систему који је довољно интелигентан да ради у синхронизацији са комплетном инфраструктуром, или када би нам архитектура сториџ система обезбедила да и логички и физички раздвојимо сервисе. Е па имамо среће, и једно и друго решење већ постоје! Ајде прво да видимо какви типови архитектуре сториџ система постоје. Нећемо говорити о типовима сториџ система (all-flash, hybrid), нити о интерконекцијама унутар сториџ система (10GB eth, IB), нити о конекцијама ка сервисима (FC, FCoE), већ искључиво о архитектури.

Типови архитектуре

На слици се могу видети четири типа сториџ архитектуре. Идемо редом.

1. Clustered архитектура

Подразумева неку врсту актив пасив архитектуре где у суштини податак опслужује један контролер, иако се до њега може доћи и преко другог али неоптимизованом путањом (кашњење је веће). Оптимизована путања је директна и са веома малим кашњењем, где једино кашњење које постоји долази из потребе што постоји нека врста високе расположивости (HA) између контролера и репликације кеш меморије због конзистентности података. Због једноставности ове архитектуре, лакше је убацити додатне сервисе над подацима на тој директној путањи податка (као што су дедупликација, компресија, снепшотови, репликација и остало). Ова врста архитектуре омогућава scale-up и scale-down, где се додавањем дискова могу повећати перформансе система али систем је и даље перформантан колико је перформантан један контролер. Варијација ове архитектуре је нека врста федерације, где се више парова овог типа архитектуре стави под један механизам управљања али на крају податак опслужује један мозак/контролер. Ова федерације не може да се назове scale-out системом зато што повећање перформанси система захтева додатно балансирање и тунирање ресурса и сервиса унутар федерације. Примери вендора и решења ове врсте архитектуре су NetApp FAS cDOT, EMC VNX, Pure Storage, Nimble,…

2. Scale-out tightly coupled архитектура

Ова врста архитектуре подразумева да се меморија дели између нодова (како кеш меморија тако и метадата) а сами подаци су дистрибуирани између одређног броја нодова. Идеја овог модела је била симетричност и једнака оптерећост свих нодова. И у случају отказа неког од нодова, оптерећење би опет било равномерно расподељено на преостале нодове. По дефиницији код ове врсте архитектуре постоји доста саобраћаја између самих нодова, па нека од решења користе јединствене интерконекције између нодова. Ова врста архитектуре је права scale-out архитектура зато што се перформансе система повећавају линеарно додавањем нових дискова и нодова. Али због комплексности је врло тешко додати нове сервисе манипулације над податком (дедуп, компресија и остали). Примери ове врсте архитектуре су EMC XtremIO, HP 3PAR, EMC VMAX, IBM DS.

3. Scale-out loosеly coupled архитектура

У овом случају меморија се не дели између нодова али су подаци на неки начин дистрибуирани између нодова и то на трансакционалан начин (постоји нека врста синхроне репликације података унутар нодова). Добра страна ове врсте архитектуре је скалабилност. Неки од примера ове врсте архитектуре су VMware VSAN, SolidFire, SimpliVity, Nutanix, EMC ScaleIO.

4. Дистрибуирана архитектура

Слично као код претходне ни овде нема дељења меморије између нодова и подаци су дистрибуирани али на некохерентан начин (постоји нека врста асинхроне репликације унутар нодова). Примери ове врсте архитектуре су AWS S3, EMC Atmos, Ceph.

Ок, шта је сада мало јасније после ове приче о архитектури. Па надамо се да је јасније да једино scale-out архитектура омогућава дистрибуцију оптерећења и балансирање ресурса где нисмо ограничени перформансама једног нода/контролера и да ако један сервис засити један контролер сви остали сервиси ће то приметити. Али и даље недостаје један део, а то је квалитет сервиса и интелигенција инфраструктуре као целине.

Квалитет сервиса

Када говоримо о квалитету сервиса већ постоје нека решења, нека више а нека мање употребљива, али добра ствар је да су сви препознали овај проблем и иду ка правом решењу. Ако имамо инфраструктуру која је комплетно виртуелизована, VMware већ неко време ради на решавању проблема бучног комшије и сада је Storage IO Control већ прилично робустан и стабилан механизам за додавања правичности између виртуелних машина али и даље недостаје квалитет сервиса зато што VMware не зна могућности сториџ система. Неки од сториџ вендора су обезбедили квалитет сервиса на нивоу LUN-a, где је могуће ограничити по throughput-у или броју IOPS-a одређени LUN, примери су NetApp cDOT (слика) и HP 3PAR.

Али од свих вендора најдаље је отишао SolidFire који је обезбедио квалитет сервиса у смислу обезбеђивања минимума за одређени сервис, тј. да у сваком тренутку тај минимум мора бити обезбеђен, и што је још компликованије овај минимум је могуће одредити за кашњење! као параметар квалитета сервиса. SolidFire је интегрисао овај QoS механизам са VMware SIOC чиме је обезбедио интелигенцију на нивоу самог хипервизора који има највише информација о самом сервису који опслужује.

vSphere 6.0 и функционалност VVOL где виртуелна машина постаје објекат на кога се примењују правила о квалитету сервиса још више поједностављује имплементацију, али још доста времена треба да прође док сториџ вендори не прихвате ову промену и пут ка софтверски дефинисаном дата центру.

За крај, архитектура је битна, као и посвећеност самих вендора у решавању актуелних проблема. Некима је олакшан посао одабиром архитектуре а неки вендори имају тежак задатак пред собом да испуне очекивања корисника и сервиса.

NetApp Virtual Storage Tier (FlashCache и FlashPool)

Netapp као лидер у сфери сториџ технологија, својим иновативним решењима је годинама гурао индустрију напред, како себе тако и своје конкуренте, покушавајућу да реши разнолике проблеме својих корисника. Једно од таквих решења је сигурно и Virtual Storage Tier (VST), хибридно сториџ решење, које у комбинацији са флеш технологијом решава проблем са перформансама код корисника са непредвидивим сториџ потребама (консолидација серверске инфраструктуре, базе података, file сервиси).

Мало о флеш технологији

Чврсти дискови (HDD) имају недостатак када је реч о опслуживању високо захтевних апликација а тај недостатак је број улаз/излаз операција у секунди (IOPS). Пошто имају перформансе до 300 насумичних операција читања у секунди, сториџ систему који је требао да опслужи апликације које захтевају више десетина хиљада ИОПС-а било је потребно више стотина дискова, иако капацитет који би се тако добио није био потребан. Овакав трошак у виду повећања броја дискова, простора у рековима, потрошње струје и потребе за хлађењем више није прихватљив код савремених компанија. Такође, време приступа подацима код HDD се мери у мили секундама док код SSD у микро секундама, тиме само HDD постају недовољни да опслуже апликације које су осетљиве на кашњење.

Због јасног добитка у перформансама заједно са мањом потрошњом струје, флеш SSD и остали флeш уређаји полако преузимају улогу HDD. Али пошто SSD коштају и до десет пута више од HDD по гигабајту простора, потребно је наћи праву стратегију примене SSD а да то буде економски оправдано. Постоји неколико опција како се може користити флeш технологија:

1. Хибридна сториџ решења – комбинују перформансе флеш уређаја са капацитетом HDD тако што податке који се активно користе или пребаце на флеш или користе флеш као механизам за кеширање таквих података

2. Сервер флеш решења – локални флеш уређаји у серверима се користе као сториџ простор или као простор за кеширање, тиме задовољавајући потребе за веома ниским кашњењем приступа подацима. PernixData је један од примера ове технологије о којој смо већ писали.

3. All Flash Array (AFA) – високе перформансе и висок степен поузданости за апликације критичне за пословање. Линк за мало више информација.

NetApp VST

VST је пример хибридног сториџ решења, које потпуно аутоматизовано у реалном времену користи флеш уређаје у комбинацији са SAS и/или SATA дисковима, интелигентно кешира блокове којима се често приступа. Две технологије чине VST. Прва је NetApp Flash Cache, PCI-e флеш модули за окружења са високим насумичним операцијама читања, где се кашњење смањује и преко 10 пута. Ова технологија представља кеширање на нивоу контролера сториџ система. Друга технологија у оквиру VST je NetApp Flash Pool, која користи SSD дискове у окружењима где је потребно интелигентно кеширање насумичних операција и читања и писања. Ова технологија је на нивоу физичког груписања дискова (агрегата).

Ок, сада ћете сигурно рећи, па сваки сториџ вендор има неко решење за аутоматизовани сториџ тиринг, и ефикасно коришћење флеш технологије у сврхе повећања перформанси система. Оно што NetApp VST издваја од осталих је што за разлику од осталих, ово решење је потпуно аутоматизовано и у реалном времену се активни подаци убрзавају, чиме су бенефити видљиви тренутно. Ово је посебно битно код окружења која се брзо мењају и где је workload непредвидив, као што су нпр. виртуелизована окружења са великим бројем разноликих сервиса. Оно што смо ми искуствено могли да видимо, окружења која су посебно добро користила ову технологију су такође и OLTP сервиси, где су потребни резултати у реалном времену.

Ако до сада није јасан тренд, како ИТ индустрије глобално, тако и наших постова, флеш технологија је ту да промени свет, и ми ћемо наставити да пишемо о разноликим применама флеш технологије у производима и решењима. И оно што је битно иако смо употребили реч тренд, не треба узети тренд  безрезервно и у некој лошој конотацији, циљ је свима исти, а то је решавање проблема код корисника на различите начине зато што су и окружења код корисника различита…

EMC Судар Титана (VMAX vs. XtremIO)

Право је време за неке нове ствари и технологије. Данас говоримо о две технологије компаније EMC. Једна је у прошлости направила од компаније EMC број 1. сториџ вендора у свету (vMAX/Symmetrix). А друга технологијa ће обезбедити да EMC и остане на тој позицији (XtremIO).

Мало историје

VMAX а пре тога и Symmetrix су компанијама које имају високе захтеве у погледу доступности, поузданости, и константности перформанси у окружењима са различитим сервисима (OLTP, OLAP, big data, virtual infrastructure), били de facto стандард када су у питању сториџ захтеви. Always-on архитектура, напредна изолација грешака, робустан механизам интегритета података као и унапређења хардвера и софтвера без застоја су само неке од функционалности ових система које су их чиниле правим решењем код корисника са највећим захтевима. Али шта се променило? Две ствари су се десиле. Прво компаније су почеле да размишљају “зеленије”, и не смеју више себи да дозволе да хране стотине и стотине хард дискова да би задовољиле захтеве нпр. једног трансакционог система. И друга ствар је да су flash уређаји постали ценовно упоредиви (ценовно када говоримо по цени GB простора, и поготово када говоримо о цени IOPS-a) са традиционалним сториџ системима са “вртећим” дисковима. XtremIO систем са само flash дисковима (all-flash array – AFA) који је од старта направљен као систем само са flash дисковима (архитектура и OS) постаје нови стандард за високо захтевне сервисе који морају да обезбеде високе перформансе (broj IOPS-a) са веома малим кашњењем, и да у сваком тренутку те вредности буду предвидиве и константне.

Архитектура је битна

arhitekture

(слика преузета са http://virtualgeek.typepad.com/virtual_geek/2014/01/understanding-storage-architectures.html)

Неки од будућих постова ће детаљније говорити о архитектури сториџ система и о утицају архитектуре на проблеме које срећемо код корисника. Али за сада, на слици се може видети преглед архитектура и оно што је битно за данашњу тему је да су и VMAX и XtremIO тип 2. архитектуре (tightly coupled scale out). Оно што обезбеђује овај тип архитектуре је прави scale out систем, коме се повећавају и перформансе и капацитет додавањем додатних јединица (контролера и дискова). Овакав тип архитектуре обезбеђује да податак може опслужити било који контролер сториџ система без утицаја на перформансе система. Тип 2. архитектура носи са собом и препреку у смислу додавања додатних сервиса и манипулације над подацима (snapshots, replication, deduplication, compression) због дистрибуиране архитектуре и дељења меморије између контролера. И за ове додатне сервисе је потребно доста времена и рада развојног тима инжењера ових система. Због ових разлога XtremIO тренутно не задовољава све захтеве свих корисника. У којим случајевима XtremIO НИЈЕ право решење:

– ако су захтев комплексне репликационе технологије (стотине репликационих објеката, стотине репликационих конзистентних група, комплексне репликационе топологије, …)

– ако је захтев подршка за mainframe

– ако је захтев сториџ систем који ће све радити задовољавајуће, и као бекап дестинација и као NAS уређај, итд. За ове захтеве су бољи избори EMC VNX, NetApp FAS, …

Као што видите, захтеви за против (mainframe и insane replication) су стварно специфични и мали број корисника (ако и један у нашем региону) има овакве захтеве. Тако да је време да сви почнемо да размишљамо – AFA! иако постоји и бољих акронима 🙂

У неком од следећих постова направићемо поређење тренутно најбољих All Flash Array – AFA решења на тржишту, са више техничких детаља и приче о архитектури сториџ система.

До тада…

xtremio