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

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

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

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

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

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

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

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

Овај пост представља уводни текст који има за циљ да отвори тему којом ћемо се детаљније бавити у наредним постовима у погледу функционалности, карактеристика и архитектуре система за архивирање садржаја пословно критичних података предузећа са пословног и техничког погледа, а намењен је како људима који доносе стратешке одлуке и правце развоја информационих система предузећа тако и инжењерима и архитектама истог, а у смислу правилног и целовитог сагледавања предности постојања једног оваквог система са аспекта пословања, сигурности и доступности информација у власништву предузећа.
Системи за целовито архивирање података предузећа (Enterprise Information Archiving) омогућују ИТ управницима и корисницима информационих система предузећа чување и претрагу генерисаних садржаја у току животног циклуса посматраних апликација (е-пошта, фајлови, разговори, Share Point садржај и др.) као и њихову правилну локацију на одговарајуће системе за складиштење података или прилагођене cloud системе, чиме се остварују додатне уштеде у будућим инвестицијама и оперативним трошковима. Анализе показују да се око 90% података генерисаних у предузећу не искористи у првих 6 месеци од њиховог креирања. Такође великом уделу ових података корисници никада не приступе и при том руководство нема никакав увид у садржај и битност ових информација. Ово је последица одсуства система за централно претраживање генерисаних садржаја, јер се они налазе у хетерогеним апликативним системима који користе различите формате и форме похрањивања података и алгоритме претраге. Даље, сви ови подаци налазе се на примарним апликативним системима оптерећујући њихово функционисање, свакодневни одзив и непотребно заузимајући скуп примарни (tier-1) диск простор, чиме чине ове системе неоправдано скупим за имплементацију и одржавање. Све горе наведено представља класичан проблем мета знања (знања о знању) присутан у свим хетерогеним инфраструктурама и решењима које срећемо у данашњим ИТ технологијама.
Решавање овог проблема у последњим годинама поприма све већи значај, у средњим и великим пословним окружењима, како количина информација и њихов прираст постаје све већи, а њихова контрола и анализа све мање могућа. Такође постојање једног оваквог система и његова примена постаје све чешћи захтев ревизија ИТ инфраструктура и обавезан део постојећег електронског екосистема. Такође је битно да овакав систем буде дизајниран и имплементиран у оној форми која задовољава модерне техничке захтеве, једноставност коришћења, и не најмање битно, брзину доступности архивираног садржаја. По Гартнеровој анализи, до 2019. године 75% предузећа имаће имплементиран овакав систем у форми која је управо наведена, за разлику од тренутне вредности која чини једва 10% предузећа. Дакле налазимо се у правом тренутку да кренемо у правилну и суштинску анализу и решавање овог проблема са којим смо суочени у модерном пословању.
Сумарно речено, задатак нам је да уочимо и опишемо проблеме у архитектури тренутних апликативних решења присутних у предузећима, дефинишемо решења и захтеве које решења морају да поседују и да сумарно предложимо конкретан скуп технологија и целовиту архитектуру која те проблеме решава и захтеве испуњава у целини што ће бити урађено у следећим постовима на ову тему.

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

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

Проблем

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

SAP HANA DB платформа будућности

Адаптација ауторског текста објављеног у часопису Business&IT 2013. године.

Компанија SAP представила је DB платформу будућности и назвала је HANA. Да видимо шта је заправо ново…

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

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

Као решење наведених проблема SAP нуди нову, модерну in-memory DB платформу HANA. Ради се о релационој бази података и развојном окружењу које комбинује најмодернија достигнућа из области хардверских решења и софтверских техника, како би се постигле максималне перформансе и при том задржале све предности и поузданости трансакционих система.

SAP HANA је платформа која прихвата податке из различитих извора, а намењена је како SAP пословним апликацијама, тако и другим апликацијама и изворима структурираних и неструктурираних података, било за трансакционо, аналитичко или комбиновано процесирање. У основи платформе налази се хибридни систем складиштења података који комбинује три приступа – приступ на бази редова, на бази колона и објектни оријентисани приступ. Уз то, HANA користи модерне алгоритме за компресију, што омогућава да подаци заузимају мање простора и да буду смештени у радну меморију система уместо на хард-диск.

На овај начин приступ подацима постаје 100.000 пута бржи, а системи паралелног процесирања и поделе података уграђени у HANA платформу омогућавају њихово размештање на више процесорских језгара и сервера, што решава познати проблем традиционалних трансакционих DB система испољен у слабој хоризонталној проширивости.

Вреди поменути и остале функције, попут map-reduce алгоритма, алгоритама за претрагу текста, одсуство потребе за агрегацијом табела и уграђене multi-tenant функционалности, што ову релациону базу чини идеалном за cloud окружења и испоручиоце услуга.

SAP HANA може бити имплементирана и као екстензија постојећих DB система, када се користи за аналитичке процесе, што је омогућено различитим начинима репликације података из примарног система. Администрирање система омогућено је потпуно развијеним графичким SAP HANA Studiom, а интеракција над базама имплементирана је инжењерима познатим SQL и MDX језицима за писање скрипти и процедура. На овај начин доступни су миграција и портовање постојећих апликација на нови ХАНА систем без потребе за посебним знањима и преквалификацијама тима за управљање базама података и развој апликација.

Систем истовремено поседује и комплетну in-memory развојну платформу Extended Application Services (XS), која укључује Web server, server-side Java Script, што омогућава програмерима писање нових апликација за решавање најсложенијих big-data проблема, подршку за HTML5 и UI интеграционе сервисе, као и развијено тржиште апликација за ову платформу.

SAP HANA платформу испоручују сви водећи произвођачи хардвера као преконфигурисан систем у single-node или scale-out архитектури различитих меморијских капацитета и начина реализације високе доступности и толеранције на катастрофалне догађаје. На овај начин загарантовани су потпуна функционалност и перформансе система кроз хардверско-софверску компатибилност и подршку. SAP HANA платформа такође је подржана као виртуална инсталација на VMware vSphere окружењу.

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

Braineering креће снажно!

Brain

Иако је данас 1.април Braineering IT Solutions стартује са озбиљним вестима. Крећемо снажно и одлучно! Постали смо VMware Professional Solutions Provider партнер, NetApp silver партнер, Symantec и Veeam registered партнер, као и EMC и Fujitsu партнер. Овиме желимо да покажемо нашу жељу да нашим корисницима понудимо најбоље што IT индустрија може да понуди, најбоље решење за разнолике проблеме наших корисника, од једноставнијих до комплексних инфраструктура.

Ово је тек почетак!

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