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

Настављамо причу о хардверском делу система за архивирање како би систем у целини добио одговарајућу архитектуру и уштеде. Пре архивирања сви подаци релевантних система похрањени су на диск простору продукционих сториџ системима   (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. годину

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

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

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

Проблем

Оно што је нас иницијално довело до разматрања архитектуре сториџ система јесте проблем који се све више јавља код корисника, а то је проблем “бучног комшије”. Овај проблем се јавља у ситуацијама када један сервис утиче на рад осталих сервиса. Ако код појединачног корисника постоји само један сервис који је заиста битан за пословање, и ако тај сервис утиче на рад осталих, то генерално није велики проблем зато што је сервис који је битан добио ресурсе који му требају. Али шта ако постоји више критичних сервиса за пословање (под критичним се овде мисли на перформансе тих сервиса), или код клауд провајдера (овде се мисли и на кориснике који су интерно одговорни за сервисе својих служби и њихов 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 сервиси, где су потребни резултати у реалном времену.

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

PernixData FVP DFTM кластер – анализа могућности

PernixData FVP представља један од најимпресивнијих проширења постојећих виртуалних инфраструктура и могућности које доноси у брзини приступа диск подсистему су задивљујуће. Ова технологија из корена редефинише концепт приступа сториџ системима, уводећи нови меморијски слој у инфраструктуру, чиме се попуњава велики јаз између брзина приступа меморији и диску и тако повећавају укупне IO перформансе виртуалних машина и више редова величинa. PernixData FVP платформа представља најразвијенију и једину зрелу технологију овог типа у свету са пионирским функционалностима које пружа попут write-back кеш могућности, Distributed Fault Tolerant Memory (DFTM) система кластеринга RAM меморије хостова, компресије кеш садржаја и сл. Иако је могуће користити и друге flash технологије као локалне кеш ресурсе хостова, у овом посту желимо да прикажемо опцију коју сви корисници могу да искористе у својим инфраструктурама, а то је PernixData Distributed Fault Tolerant Memory (DFTM) опција. Концепт изa DFTM технологије је једноставан, а састоји се у искоришћавању вишка меморије хостова за кеширање како читања тако и уписа ка диск систему, чиме се кеш сториџ система проширује и на хостове. На овај начин се CPU, меморијски и део диск ресурса колоцирају у серверу па се укупне перформансе виртуалних машина драматично убрзавају. Ово је посебно изражено код диск интензивних и захтевних виртуалних машина, које су најчешће сервиси база података, где су убрзања најочигледнија.

Желимо да прикажемо, даље у посту, резултате понашања DFTM опције у пракси, код корисника где смо урадили PoC за PernixData технологију. Кренули смо посматрајући диск најзахтевније виртуалне машине које су притом имале највиша кашњења. За ово смо  користили постојећи vCenter Operations Manager систем, које нам је дао листу таквих машина прецизно сортирану. Изабирамо машину која има преко 10 ms кашњење. Иако је сториџ систем овог корисника сјајан, без великих осцилација у функцији, покушали смо да постигнемо боље перформансе за ову виртуалну машину. Виртуалне машина има на себи инсталирану захтевну SQL базу података. На следећем приказу видимо realtime перформансе ове виртуалне машине после миграције у vSphere кластер са подешеним PernixData FVP DFTM функцијом:

Добијамо изузетно високе перформансе постигнуте великим hit rate према кешу – око 20к IOPS-a и око 800MB/s. Ови параметри су ишли у тренуцима и више од 1GB/s. Овакви протоци одржавали су се током целог радног времена са сличним карактеристикама. Треба обратити пажњу колико у просеку 1% који се и даље чита са диска утиче на укупно кашњење (тренутак заокружен црвеном на горњем приказу). На следећој слици износимо 10 минутни просек, где читаоцу скрећемо пажњу на информације заокружене у црвеном правоугаонику. У њему се могу уочити односи у кашњењу при приступу подацима лоцираним у кешу (0,26 ms) и онима лоцираним на диску (8,18 ms), као и просечно кашњење од 2,56 ms.

Са друге стране интересантна (али потпуно логична) последица је да је виртуална машина после додавања у PernixData кластер скоро непрекидно искоришћавала 100% додељених CPU ресурса. Ово се види на следећем приказу:

Упоређивање са понашањем пре додавања у кластер са кешом – пикови нису прелазили 75% CPU искоришћења у интензивним тренуцима рада система. Слика једнонедељне CPU активности са тренутком додавања и избацивања из кластера означеним вертикалном жутом линијом следи (заокруживања вредности у једнонедељном приказу перформанси квари резолуцију). Треба уочити сиву кривуљу, која представља заузеће у процентима и црвену која представља апсолутно заузеће у MHz.

Како сваки систем ради онолико добро колико је добра најслабија карика, можемо закључити да смо bottleneck виртуалне машине који је до додавања у кеш кластер био на диск систему, додавањем у кластер померили на CPU ниво. Дакле сада је CPU уско грло за сервис који се налази на овој виртуалној машини, а не више диск! Шта можемо даље урадити како би још више повећали перформансе овог система?

Повећавањем броја процесора на овој виртуалној машини са 4 на 8 добијамо још боље перформансе према диску и полако спуштамо просек заузећа процесора. Даљим скалирањем на 16 процесора добијамо још боље перформансе али због других ограничења у броју физичких језгара у серверима хоста и архитектуре SQL паралелизације ова побољшања нису била толико импресивна.

На овај начин остварујемо смањење кашњења према диску 3 до 10 пута, бољу искоришћеност процесора на серверима и изнад свега боље опште перформансе критичних сервиса.

Braineering IT Solutions може урадити тестове за све кориснике коју су заинтересовани за ову технологију и доказати да перформансе диск система и подмилисекундна диск кашњења могу да се остваре и само софтверским механизмима, и то у једном дану, без великих улагања у комплексне сториџ системe. Јавите се, ту смо за вас!

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