close

SAP HANA-Betriebskonzepte – Technik leicht erklärt!

Jürgen Meynert
Geschätzte Lesezeit: 8 Minuten

Jürgen MeynertHeu­te erklärt unser Kol­le­ge Jür­gen Mey­nert im Detail alles zu den SAP HANA-Betriebs­kon­zep­ten. Die­ser Arti­kel ist daher etwas tech­ni­scher und län­ger als sonst. Aber das sind Schul­bü­cher ja auch und wir haben alle viel draus gelernt. Wir wün­schen Ihnen daher viel Spaß beim Ent­de­cken und Verstehen!

SAP ent­wi­ckelt mit HANA seit eini­gen Jah­ren eine neue tech­ni­sche Basis für ihre Anwen­dun­gen. Die Moti­va­ti­on dafür mag dar­in begrün­det sein, dass mit nicht flüch­ti­gem Haupt­spei­cher (NVRAM – non vola­ti­le RAM) ein tech­no­lo­gi­scher Para­dig­men­wech­sel bevorsteht.

Die In-memo­ry-Tech­no­lo­gie erfor­dert grund­sätz­lich neue Pro­gram­mier­mo­del­le, die sich nicht durch Anpas­sun­gen vor­han­de­ner Soft­ware rea­li­sie­ren las­sen, son­dern radi­kal neue Ansät­ze erfor­dern. Damit steht nicht nur in der Hardware‑, son­dern auch in der Soft­ware­tech­no­lo­gie ein Para­dig­men­wech­sel bevor. Im Zuge des tech­ni­schen Fort­schritts hat die Zugriffs­ge­schwin­dig­keit von Sto­rage­sys­te­men nicht Schritt hal­ten kön­nen mit den Zuwäch­sen bei der Pro­zessor­ge­schwin­dig­keit. Bei CPU-Takt­ra­ten von 3 GHz, was Zyklus­zei­ten von 0,3 Nano­se­kun­den ent­spricht, dau­ern Ver­ar­bei­tungs­schrit­te im Pro­zes­sor in der Grö­ßen­ord­nung von Nano­se­kun­den (ns), wäh­rend Zugrif­fe auf exter­nen Sto­rage sich im Bereich von Mil­li­se­kun­den (ms) bewe­gen. Das ist ein Miss­ver­hält­nis von 1 zu 1.000.000!

Als Kon­se­quenz war­ten CPUs bei Anwen­dun­gen der Infor­ma­ti­ons­ver­ar­bei­tung die meis­te Zeit auf IO. Nun reicht es nicht, nur den Sto­rage schnel­ler zu machen, etwa mit ultra­schnel­len Flash-Devices, da auch schon das Licht und damit auch die Daten im ns-Bereich nur eine sehr beschränk­te Distanz zurück­le­gen kön­nen (< 30 cm in 1 ns). Somit kann schnel­ler Daten­zu­griff letzt­lich nur dadurch erzielt wer­den, dass die Daten auch nahe beim Pro­zes­sor bereit­ge­hal­ten wer­den: im RAM, oder bes­ser noch im Cache.

Code to Data

Eine wei­te­re Beschleu­ni­gung der Ver­ar­bei­tungs­ge­schwin­dig­keit lässt sich dadurch erzie­len, dass Anwen­dungs­code direkt in der Daten­bank aus­ge­führt wird, wodurch ver­gleichs­wei­se hohe Laten­zen bei der Kom­mu­ni­ka­ti­on zwi­schen Appli­ka­ti­on und Daten­bank ver­mie­den wer­den. Wur­den also bis­lang Daten durch die Daten­bank zur Anwen­dung geschleust, wird zukünf­tig Anwen­dungs­code zu den Daten gebracht. Damit lässt sich der Para­dig­men­wech­sel am anschau­lichs­ten beschrei­ben: Statt „Data to Code“ heißt es zukünf­tig „Code to Data“.

Aktu­ell ist RAM aller­dings noch flüch­tig, sodass Schrei­bope­ra­tio­nen im Haupt­spei­cher durch eine Per­sis­tenz­schicht, also letzt­lich doch wie­der Sto­rage, abge­si­chert wer­den müs­sen. Für lesen­den Zugriff, auch auf sehr gro­ße Daten­men­gen, ist RAM heu­te bereits gut gerüs­tet, da mit immer höhe­rer Packungs­dich­te der Spei­cher­ele­men­te und gleich­zei­ti­gem Preis­ver­fall Rech­ner mit hohen RAM-Kapa­zi­tä­ten (bis zu meh­re­ren TB) zu ver­tret­ba­ren Prei­sen ver­füg­bar sind. Da Lesen aus dem RAM heu­te also effi­zi­ent und sinn­voll mög­lich ist, liegt der Fokus von SAP Hana und ande­ren In-memo­ry-Tech­no­lo­gien schwer­punkt­mä­ßig auf lesen­den Anwen­dun­gen wie Repor­ting und Busi­ness Intel­li­gence (OnLine Ana­ly­tic Pro­ces­sing, OLAP). Für trans­ak­tio­na­le Sys­te­me (OnLine Tran­sac­tion Pro­ces­sing, OLTP) kann man Vor­tei­le dar­aus gewin­nen, dass einer­seits Online-Repor­ting auf den trans­ak­tio­na­len Daten ohne Per­for­mance­ein­bu­ßen bei der Trans­ak­ti­ons­ver­ar­bei­tung mög­lich ist oder dass Code­stre­cken mit hohem Kom­mu­ni­ka­ti­ons­auf­kom­men zwi­schen Daten­bank und Appli­ka­ti­on von einer Ver­la­ge­rung in die Daten­bank schon jetzt pro­fi­tie­ren. Aber gleich ob OLAP oder OLTP, die In-memo­ry-DB (IMDB) benö­tigt eine Per­sis­tenz, denn spä­tes­tens, wenn der Rech­ner aus­ge­schal­tet wird, sind die Daten aus dem RAM verschwunden.

Per­sis­tenz­schicht und Performance

Da bei einer IMDB die Daten­zu­grif­fe über­wie­gend im RAM gesche­hen, könn­te man erwar­ten, dass der Sto­rage als Per­sis­tenz­schicht hin­sicht­lich Per­for­mance eine gerin­ge Rol­le spielt und in ers­ter Linie zur Absi­che­rung dient, damit kei­ne Daten ver­lo­ren gehen. Die Anfor­de­run­gen der SAP an die Per­for­mance der Per­sis­tenz waren und sind aber zum Teil höher als für klas­si­sche Daten­ban­ken. All­ge­mein las­sen sich bei Daten­ban­ken zwei Schreib­me­cha­nis­men aus­ma­chen – Log­wri­ter und Datawri­ter. Der Log­wri­ter doku­men­tiert zeit­nah (syn­chron) in einem eige­nen Bereich jede ein­zel­ne Ände­rung (Insert, Update, Dele­te), die auf der Daten­bank durch­ge­führt wird. Der Datawri­ter aktua­li­siert von Zeit zu Zeit (asyn­chron) die Ände­run­gen der Tabel­len im Sto­rage und sorgt für ein kon­sis­ten­tes, aber meist nicht aktu­el­les (da asyn­chro­nes) Abbild der Daten­bank. Kri­tisch für die Trans­ak­ti­ons­ver­ar­bei­tung und für eine Daten­bank-Reco­very, wenn sie ein­mal nötig sein soll­te, ist der Log­wri­ter. Eine Trans­ak­ti­on gilt erst dann als abge­schlos­sen, wenn der Log­wri­ter sie als doku­men­tiert zurück­ge­mel­det hat. Erst dann kann die Ver­ar­bei­tung fort­ge­setzt wer­den. Damit ist sicher­ge­stellt, dass nach einem unge­plan­ten Abbruch der Daten­bank der letz­te gül­ti­ge Zustand wie­der­her­ge­stellt wer­den kann, indem das letz­te kon­sis­ten­te Daten­image mit den dort noch nicht erfass­ten Log­ein­trä­gen fort­ge­schrie­ben wird (Roll Forward).

Log­wri­ter & Datawriter

In den frü­hen Revi­si­ons von Hana war der Log­wri­ter so kon­zi­piert, dass er alle Ände­run­gen in klei­nen Block­grö­ßen in den Log-Bereich schrieb. Bei umfang­rei­chen Ände­run­gen in der Daten­bank führ­te das zu einer erheb­li­chen Anzahl an IO-Ope­ra­tio­nen. Des­halb war damals die Anfor­de­rung von SAP, dass die Per­sis­tenz in der Lage sein muss­te, min­des­tens 100.000 IOps (IO-Ope­ra­tio­nen pro Sekun­de) schrei­ben zu kön­nen. Das ist mit ver­tret­ba­rem Auf­wand nur mit loka­len Flash-Devices (PCI-basiert) zu rea­li­sie­ren. Des­halb hat­ten und haben die meis­ten Sin­gle-Node-Instal­la­tio­nen von Hana PCIe basier­te Flash-Devices. Spä­ter wur­de Hana um eine Sca­le­Out-Archi­tek­tur erwei­tert für den Fall, dass der maxi­mal mög­li­che Haupt­spei­cher­aus­bau inner­halb eines Rech­ners nicht mehr aus­reich­te, eine grö­ße­re Daten­bank kom­plett zu spei­chern. Hana kann mit die­ser Opti­on auf meh­re­re Rech­ner­kno­ten ver­teilt werden.

Die Rech­ner kön­nen so aus­ge­legt wer­den, dass nicht alle aktiv sind, son­dern dass auch ein oder meh­re­re Kno­ten als Fai­l­over kon­fi­gu­riert wer­den kön­nen für den Fall, dass ein akti­ver Kno­ten aus­fällt. Das setzt aller­dings eine (exter­ne) Per­sis­tenz vor­aus, die von allen Rech­nern gele­sen wer­den kann, denn sonst kann ein Fai­l­over-Kno­ten nicht die Daten eines aus­ge­fal­le­nen Rech­ners ein­le­sen. Damit war das Kon­zept, Log-Daten sehr schnell auf ein loka­les Device zu schrei­ben, nicht mehr halt­bar. Dem­entspre­chend wur­de der Log­wri­ter dahin gehend opti­miert, dass er varia­ble Block­grö­ßen schrei­ben konn­te. Damit waren die hohen IO-Raten auch nicht mehr erfor­der­lich. In einem Sca­le­Out-Sze­na­rio waren knapp 20.000 IOps pro Rech­ner­kno­ten aus­rei­chend. Gleich­wohl hielt SAP die 100.000 IOps für Sin­gle-Nodes bis in die jüngs­te Ver­gan­gen­heit aufrecht.

Neben dem Log­wri­ter gibt es noch, wie schon erwähnt, den Datawri­ter. Zunächst soll­te man wie­der­um mei­nen, dass der unkri­tisch im Hin­blick auf Per­for­mance ist, da er ja asyn­chron schreibt. Tat­säch­lich schreibt Hana in kon­fi­gu­rier­ba­ren Zeit­ab­stän­den – Default ist fünf Minu­ten – soge­nann­te Save­points. Die Per­for­mance des Sto­rage muss so aus­ge­legt sein, dass zumin­dest vom Durch­satz das zwi­schen zwei Save­points geän­der­te Volu­men im ver­füg­ba­ren Zeit­in­ter­vall geschrie­ben wer­den kann. Da der Datawri­ter nach dem Prin­zip Copy-on-wri­te ver­fährt, ist die Schrei­blast ten­den­zi­ell sequen­zi­ell, da geän­der­te Blö­cke nicht über­schrie­ben wer­den, son­dern die Ände­run­gen in neu allo­kier­te Blö­cke abge­legt wer­den. Damit ver­ein­fa­chen sich die Anfor­de­run­gen an die Per­sis­tenz, weil sequen­zi­el­le IO wesent­lich effi­zi­en­ter rea­li­siert wer­den kann als Random-IO.

Da die spal­ten­ba­sier­te inter­ne Archi­tek­tur von Hana ver­gleich­bar ist mit zu ein­hun­dert Pro­zent indi­zier­ten Daten­be­stän­den, fal­len im Ver­gleich zu ande­ren Daten­ban­ken bei Hana häu­fi­ger inter­ne Reor­ga­ni­sa­tio­nen an, die dann auch auf die Per­sis­tenz abge­bil­det wer­den. Damit erhöht sich die Anfor­de­rung des Data­writers an den Schreib­durch­satz. Dage­gen soll­te man erwar­ten, dass die Anfor­de­run­gen an den IO-Durch­satz beim Lesen von Daten eher gering sind, da Hana Daten eigent­lich im RAM lesen soll­te. Das mag für den Nor­mal­be­trieb rich­tig sein, stimmt aber nicht für den Fall, dass Hana hoch­ge­fah­ren wird. Nimmt man an, dass 1 TB Daten in den Haupt­spei­cher gele­sen wer­den müs­sen, dau­ert das bei einem Durch­satz von 1 GB/s noch immer­hin 20 Minu­ten. Das wäre kein Pro­blem, wenn Restarts der Daten­bank die Aus­nah­me wären. Da Hana aktu­ell aber stän­dig wei­ter­ent­wi­ckelt wird mit dem Ziel, eines Tages NVRAM opti­mal zu nut­zen, sind in regel­mä­ßi­gen Abstän­den Updates ein­zu­spie­len, die oft mit einem Restart der Daten­bank ein­her­ge­hen. Daher erklärt sich die Anfor­de­rung von SAP, die Per­sis­tenz auch mit hohen Durch­satz­ra­ten für das Lesen im Daten­be­reich auszustatten.

OLAP ver­sus OLTP

Auch wenn, wie oben erwähnt, der Haupt­ein­satz­be­reich von IMDBs ten­den­zi­ell im OLAP liegt, geht SAP bereits den Weg, auch OLTP-Anwen­dun­gen auf Hana zu pro­pa­gie­ren (Suite on Hana). Tech­nisch ist es mög­lich, für OLTP-Sys­te­me sowohl Sin­gle Nodes als auch Sca­le­Out-Archi­tek­tu­ren ein­zu­set­zen. Aus Sicht der Per­for­mance ergibt sich jedoch ein signi­fi­kan­ter Unter­schied. Wie bereits erläu­tert, kann sich für OLTP-Anwen­dun­gen ein Per­for­mance­vor­teil auf Hana erge­ben, wenn Code­stre­cken in die Daten­bank ver­la­gert wer­den, um zeit­auf­wän­di­ge Kom­mu­ni­ka­ti­on zwi­schen Appli­ka­ti­on und Daten­bank zu ver­mei­den. Wenn Hana aber in einer Sca­le­Out-Land­schaft über meh­re­re Rech­ner­kno­ten ver­teilt ist, wird es sehr schwie­rig, Code und Daten­ta­bel­len so über die Kno­ten zu ver­tei­len, dass die Code­stre­cken ihre Tabel­len auch auf dem glei­chen Rech­ner fin­den, auf dem sie gera­de ablau­fen. Denn wenn der Code sich die Daten von einem Nach­barkno­ten holen muss, fällt wie­der Kom­mu­ni­ka­ti­ons­auf­wand zwi­schen den Kno­ten an, was mit ver­gleichs­wei­se hoher Latenz geschieht, wie wenn der Code gleich auf dem Appli­ka­ti­ons­ser­ver ver­blie­ben wäre. Aus die­sem Grun­de ist eine Sin­gle-Node-Imple­men­tie­rung von Hana für OLTP auf jeden Fall gegen­über einer Sca­le­Out-Archi­tek­tur vorzuziehen.

Zugleich bestand SAP bis­lang für Hana als Sin­gle Node auf der Anfor­de­rung nach schnel­len (inter­nen) Log-Devices. Inter­ne Log-Devices sind jedoch für geschäfts­kri­ti­sche OLTP-Anwen­dun­gen nicht akzep­ta­bel, da ein Ver­lust des Rech­ners bzw. des Log-Devices gleich­zei­tig auch mit Daten­ver­lust ein­her­geht. Geschäfts­kri­ti­sche Daten, ins­be­son­de­re die Log­da­ten, soll­ten immer an eine zwei­te Loka­ti­on geschrie­ben (gespie­gelt) wer­den, sodass man im Not­fall die Daten­bank aus einer zwei­ten Quel­le bis zur letz­ten abge­schlos­se­nen Trans­ak­ti­on reco­vern kann.

Fuji­tsu hat schon früh­zei­tig die Hana-Sin­gle-Node-Archi­tek­tur in das Flex­Frame-Betriebs­kon­zept inte­griert und die Log­da­ten auf exter­ne, spie­gel­ba­re Sto­rage-Ein­hei­ten plat­ziert. Dort ste­hen zwar nicht die bis­her gefor­der­ten 100.000 IOps zur Ver­fü­gung, aber aus tech­ni­scher Sicht sind sie schon lan­ge nicht mehr not­wen­dig. Damit ist aber für Hana der von Flex­Frame bekann­te siche­re und fle­xi­ble Betrieb für geschäfts­kri­ti­sche Anwen­dun­gen mit den dafür typi­schen hohen SLAs gewähr­leis­tet. Zwi­schen­zeit­lich rückt auch SAP von den hohen IO-Anfor­de­run­gen für den Log­wri­ter ab, um Hana für eine fle­xi­ble Inte­gra­ti­on in den RZ-Betrieb vorzubereiten.

Effi­zi­en­tes Betriebs­kon­zept und Schattendatenbanken

Die For­de­rung nach siche­rer Daten­hal­tung und einem effi­zi­en­ten Betriebs­kon­zept ist durch die Inte­gra­ti­on von Hana in Flex­Frame gelöst. Mit gespie­gel­tem Shared-Sto­rage ist Hoch­ver­füg­bar­keit sowohl lokal als auch RZ-über­grei­fend gewähr­leis­tet. Ein offe­ner Punkt ist noch das Pro­blem der Wie­der­an­lauf­zei­ten. In Abhän­gig­keit von der Grö­ße der Daten­bank kann ein voll­stän­di­ger Restart selbst bei hoch­per­for­man­ten IO-Kanä­len über­mä­ßig lang dau­ern. Im Zuge der Wei­ter­ent­wick­lung von Hana arbei­tet SAP am Kon­zept der Schat­ten­da­ten­bank, das Umschalt­zei­ten idea­ler­wei­se mini­mie­ren wür­de, da Schat­ten­da­ten­ban­ken in der Regel nahe­zu syn­chron mit den pri­mä­ren Daten mit­lau­fen. Nach Aus­fall der pri­mä­ren Daten­bank wür­de die Akti­vie­rung und voll­stän­di­ge Reco­very der Schat­ten­da­ten­bank nur weni­ge Minu­ten bean­spru­chen, bis der Betrieb wie­der auf­ge­nom­men wer­den kann.

Schat­ten­da­ten­ban­ken sind in Hana heu­te noch nicht ver­füg­bar, aber als Vor­stu­fe dazu bie­tet Hana die Opti­on der Sys­tem­re­pli­ca­ti­on, die dafür sorgt, dass die Log­da­ten syn­chron zu einer zwei­ten Instanz repli­ziert wer­den und dass in regel­mä­ßi­gen Abstän­den dort der Colum­ns­to­re (die Spal­ten­struk­tur) von Hana in den Haupt­spei­cher vor­ge­la­den und aktua­li­siert wird. So ent­fällt bei einem Fai­l­over das kom­plet­te Nach­la­den des Column­stores, da der größ­te Teil schon vor­ge­la­den ist. Damit las­sen sich die Wie­der­an­lauf­zei­ten in kri­ti­schen Umge­bun­gen auf ein ver­nünf­ti­ges Maß reduzieren.

Die Emp­feh­lung für Anwen­dun­gen, die nur mini­ma­le Aus­fall­zei­ten erlau­ben, wäre, lokal zur pro­duk­ti­ven Hana-Instanz eine zwei­te Instanz mit Sytem­re­pli­ca­ti­on zu betrei­ben und für den Desas­ter-Fall die pro­duk­ti­ve Per­sis­tenz in ein zwei­tes RZ zu spie­geln. Da die Instanz mit der Sys­tem­re­pli­ca­ti­on die Rech­nerres­sour­cen nur zu einem klei­nen Teil nutzt, könn­ten par­al­lel dazu auf dem Rech­ner­kno­ten noch ande­re, nicht pro­duk­ti­ve Sys­te­me gefah­ren werden.

Sca­le­Out

Bleibt noch zu dis­ku­tie­ren, wie eine Sca­le­Out-Archi­tek­tur gegen­über einem Sin­gle Node zu bewer­ten ist. Im Grun­de gilt sowohl für OLTP als auch für OLAP, dass bei glei­cher Daten­bank­grö­ße der Sin­gle Node, sofern von den RAM-Kapa­zi­tä­ten mög­lich, die bevor­zug­te Alter­na­ti­ve ist. Das hat im Wesent­li­chen zwei Grün­de. Der ers­te wur­de schon bei der Dis­kus­si­on im Zusam­men­hang mit OLTP dis­ku­tiert. Die Kom­mu­ni­ka­ti­on zwi­schen den Daten­bank­kno­ten kos­tet ver­gleichs­wei­se viel Zeit und beein­flusst die Per­for­mance nega­tiv. Spe­zi­ell bei OLAP-Anwen­dun­gen ist das Pro­blem der geschick­ten Zuord­nung von Code­stre­cken zu den Daten nicht so rele­vant wie bei OLTP, da Que­ries sich von ihrer mathe­ma­ti­schen Struk­tur in der Regel gut ver­teilt abar­bei­ten las­sen. Trotz­dem bleibt aber das Pro­blem der Latenz, weil die Teil­ergeb­nis­se einer Que­ry schließ­lich auf einem Kno­ten zusam­men­ge­führt und in ein End­ergeb­nis kon­so­li­diert wer­den müssen.

Ein zwei­tes Pro­blem stellt sich bei­spiels­wei­se bei Joins, die über Tabel­len gehen, die über meh­re­re Kno­ten ver­teilt sind. Bevor der Join aus­ge­führt wer­den kann, müs­sen die Daten der betei­lig­ten Tabel­len auf den Kno­ten über­tra­gen und zwi­schen­ge­spei­chert wer­den, auf dem der Join durch­ge­führt wird. Das kos­tet einer­seits Zeit und ande­rer­seits zusätz­lich Haupt­spei­cher. Bei einem Sin­gle Node ent­fällt die Daten­über­tra­gung und Zwi­schen­spei­che­rung, da ja alle Daten lokal sind. Damit ergibt sich als Emp­feh­lung, dass Anwen­dun­gen so lan­ge wie mög­lich mit einer Sin­gle-Node-Instanz bedient wer­den sollten.

Die aktu­el­len Ent­wick­lun­gen in der Hard­ware­tech­nik kom­men die­sem Ansatz ent­ge­gen. Mit der im Febru­ar 2014 offi­zi­ell ver­füg­ba­ren Hard­ware wird es mög­lich sein, bis zu 12 TB RAM in einer Maschi­ne zu instal­lie­ren. SAP lässt inzwi­schen ver­lau­ten, dass sie mit der neu­en Hard­ware für OLTP-Anwen­dun­gen bis zu 6 TB auf einem Rech­ner für pro­duk­ti­ve Sys­te­me unter­stüt­zen wird und für OLAP bis zu 2 TB bei acht bestück­ten Sockeln gegen­über 1 TB in der Ver­gan­gen­heit. Das klingt plau­si­bel, da sich die CPU-Leis­tung der neu­en Pro­zessor­ge­nera­ti­on etwa ver­dop­pelt hat. Aller­dings hat sich auch die Per­for­mance der Hana-Tech­no­lo­gie in den ver­gan­ge­nen Jah­ren stän­dig und signi­fi­kant ver­bes­sert, sodass man sich aus tech­ni­scher Sicht für die Zukunft auch noch grö­ße­ren RAM-Aus­bau als 2 TB für einen Kno­ten in einer Sca­le­Out-Archi­tek­tur vor­stel­len kann.

Schlagwörter: , , , ,

Keine Trackbacks
Story Page