SAP bázistechnológia

A teljesség igénye nélkül szeretnénk felsorolni az alábbiakban néhány olyan műszaki megoldást, amit szívesen használunk SAP témában, és talán túlmegy a szokásos "next-next-finish" megközelítésen.

SAP/Linux

Manapság már nem nagy kuriózum kijelenteni, hogy mi kizárólag Linux rendszereken üzemeltetünk SAP-t, de 2000-ben még az volt. Akkoriban nagyvállalati környezetben még renitens hackereknek számítottunk, akik nem akarják megfizetni a drága OS licenszeket és tanácsadói díjakat, és mindent saját kezűleg akarnak összeépíteni.

Utóbbi hozzáállásunk a mai napig megmaradt, szeretünk a "motorháztető alá" nézni, unortodox műszaki megoldásokat alkalmazni, technikai legókockákból egyedi terveket és rendszereket építeni.

Hardvermigráció SAP újratelepítés nélkül

Az egyik előnye annak, hogy mi "alulról" nézzük az SAP rendszereket, hogy részletesen ismerjük, hogy az SAP rendszer OS szinten mit és hol tárol, milyen beállítások alapján működik. Nem ijedünk meg, ha egy működő rendszert át kell migrálni egyik hostról a másikra, például hardvercsere vagy akár nagyobb lélegzetű OS frissítés esetében. Műszakilag nem feltétlen indokolt, hogy az adatbázist és az SAP alkalmazást újratelepítsük ilyen esetekben, elegendő az SAP filerendszereit és beállításait megfelelő módon átmásolni - természetesen alkalmazkodva a célrendszer tulajdonságaihoz, új storage rendszerhez stb.

SAP LXC konténerekben

OS konténerek

Az OS konténerizáció egy olyan technológia, amely lehetővé teszi több, egymástól elkülönített felhasználói környezet futtatását egyetlen operációs rendszeren belül. A konténerek a host operációs rendszer kernelét használják, de mindegyik saját fájlrendszerrel, hálózati interfésszel és folyamat­kezeléssel rendelkezik.

Az LXC (Linux Containers) hasonló a Solaris zónáihoz, vagy a FreeBSD jail megoldásához: userspace izolációt biztosítanak az alkalmazások részére.

Amikor 2008 körül a fél világ virtualizációban gondolkodott, mert az volt az aktuális hype: konszolidáljunk, virtualizáljunk; akkor mi az OS konténerekkel kezdtünk el foglalkozni. Amit óriási előnynek tartottunk:

• nincs virtualizációs réteg, az alkalmazások lassulás nélkül, natív OS szinten és sebességgel futnak a hoston
• nincs fix memóriafoglalás, minden konténer a közösből kap az igénye szerint, valójában csak limitet adunk meg (ami futás közben is módosítható)
• a host filerendszerét használhatják a konténerek, akár LVM/Btrfs/ZFS kötetként, akár raw device-ként.
• teljes OS környezetet ad, eltérően az alkalmazáskonténerekkel szemben (pl. Docker), tehát kívül-belül úgy viselkedik, mint egy önálló virtuális gép.
• akár másik, a host OS-től eltérő Linux disztribúciót is lehet telepíteni egy konténerbe, csak a kernel a közös - így használunk például SLES környezetben Ubuntu/Debian konténereket is
• egy logikai bridge interfész rákerül a host hálózati interfészére, amelyen keresztül a konténerek hozzáférnek a host hálózatához (természetesen saját IP címmel ugyanabból a hálózatból, címfordítás nélkül)
• mindeközben az összes kényelmi funkció (konténer snapshot / mentés, migráció másik hostra) elérhető, amit a virtalizációnál megszokhattunk

Úgyhogy az LXC megjelenése óta aktívan használjuk az OS konténereket. Egy tipikus, általunk tervezett és megvalósított konténerizált nagyvállalati SAP infrastruktúra:

SLES 15 LXC/libvirt

A SUSE Linux Enterprise Server szinte a kezdetektől támogatta az LXC használatát, ezért nagy örömmel kezdtük el az SAP rendszereket "bekonténerizálni", ha szabad ezt a csúnya szót használni. Minden kiválóan működött, egészen az SLES 15 SP4 verzióig, ahol is a SUSE ezt a lehetőséget megszüntette:

5.3.8 LXC containers have been removed

System containers using LXC have been removed in SUSE Linux Enterprise Server 15 SP4. This includes the following packages:

• libvirt-lxc
• virt-sandbox

As a replacement, we recommend commonly used alternatives like Docker or Podman.

SLES 15 LXD

Fentiek miatt új megoldást kerestünk, hiszen a virtualizáció számunkra nem volt elfogadható lehetőség, nem akartunk a konténerek előnyeiről lemondani.

Az alapvetően Ubuntu-n elérhető, Canonical-féle LXD egy remek LXC megvalósítás, rendkívül kényelmes és megbízható. Szerencsére az LXD a SLES15 rendszeren is elérhető, és kiválóan működik. Azóta minden rendszerünket átmigráltuk erre a megoldásra, így feljebb lehetett lépni az SLES15 SP szintekkel, egészen a legfrissebbig.

Rendszerkonszolidáció UID/GID konverzióval

Néha előfordul, hogy az ügyfél nem szeretne sem konténerizációt, sem virtualizációt, viszont igény, hogy egy fizikai hoston több SAP rendszer üzemeljen. Új telepítésnél ezzel nincs is semmi gond, de ha ezeket több működő szerverről hoznánk át, akkor előfordulhat, hogy az OS felhasználói és csoport azonosítók ütköznek egymással. Ilyen esetben van lehetőség az SAP rendszereket "megdolgozni", egy olyan állapottá konvertálni, hogy minden rendszer teljesen független lehessen egymástól.

HANA esetében az UID/GID váltás picit bonyolultabb, mert a DB konfigurációba is bele kell nyúlni, de erre is van megoldás, lehet konszolidálni a rendszereket ott is.

Például az alábbi UID/GID konverziós táblázatban látható két S/4 HANA rendszer "összebútorozása": a 2-2 adatbázis és 2-2 alkalmazásszerver külön hostokon működött eddig. Ezt a 4 rendszert össze kellett húznunk egy közös hostra, ügyfél nem akart konténerizációt vagy virtualizációt, viszont így rengeteg UID/GID ütközést kellett kezelni. Megfelelő tervezéssel és OS beavatkozásokkal ez abszolút kivitelezhető.

LVM thinpool

A klasszikus felállás szerint a storage rendszeren kiosztjuk az SAP rendszereknek a saját köteteiket, mindegyiket alaposan túlméretezve, nehogy üzem közben valamelyik idejekorán beteljen. Ebből egyenesen következik, hogy a méregdrága storage jó részét soha nem használjuk ki, részben elégetve az értékes beruházásunk értelmét.

Overprovisioning

Olyan tárterület-kiosztási módszer, amikor összességében több területet osztunk szét a kötetek között, mint amennyi valójában rendelkezésre áll - számítva arra, hogy egyszerre nem az összes kötet fog betelni.

Amikor konténereket használunk (de akár virtualizáció esetében is), megtehetjük azt, hogy az egy hostra kiajánlott storage köteten kialakítunk egy ún. LVM thinpool-t, amin belül a logikai köteteket (amiből az OS és SAP filerendszerek lesznek) dinamikusan, overprovisioning használatával osztjuk szét. Ez azt jelenti, hogy bár kellően nagyra méretezzük itt is a filerendszereket, a thinpool csak a ténylegesen (adatokkal, fileokkal) elfoglalt, nem pedig a kiosztott terület alapján "fogy el". Konkrét példa: kiosztunk 3 rendszer felé az /sapmnt és /usr/sap filerendszereknek 500-500 GB-os kötetet, ez összesen 3 TB lenne, de a thinpool foglaltsága csak azt a 30-40 GB-ot fogja mutatni, amivel a kezdeti SAP telepítés befoglalja. Ha az egyik filerendszer üzem közben megnő, elmehet egészen 500 GB-ig, vagy ha megnöveljük azt az LV-t, akkor tovább is.

Így a filerendszer méret inkább kvótának minősül a gyakorlatban, és az értékes storage területet sokkal gazdaságosabban ki tudjuk használni.

Egyes újabb storage rendszerek már storage szinten is lehetővé teszik a thinpool kialakítását, így egy szinttel feljebb is megvalósulhat az overprovisioning.

Filerendszer mentések

Deduplikáció

Deduplikáció

A deduplikációs mentés olyan adatmentési technika, amely a mentési folyamat során csak az új vagy megváltozott adatokat menti el, miközben az ismétlődő adatokra csak referenciaként hivatkozik, így jelentősen csökkentve a mentések tárolási igényét.

Az adatbázismentéseknél, így SAP alatt is régóta létező mentési módszer, hogy ritkábban végrehajtott teljes DB mentések között gyakrabban futtatott differenciális / inkrementális mentésekkel mentjük a különbözetet, illetve még ennél is gyakrabban generálódnak az ún. offline redo logok (saparch fileok), amelyeket megfelelően elmentve biztosak lehetünk abban, hogy ebből a többszintű mentési struktúrából vissza tudunk állni bármilyen időpontra (PIT / point-in-time recovery), és persze mindig meglesznek az aktuális adataink, lehetőleg minimális adatvesztéssel.

Hasonló funkcionalitást biztosít a filerendszermentéseknél a deduplikáció. Éles üzemű SAP rendszereknél az egyes filerendszerek mérete még rendszeres karbantartás mellett is nagyon megnőhet, ugyanakkor fontos lenne, hogy minden adatot a lehető leggyakrabban, mégis a lehető legkisebb tárhelyfoglalással rendszeresen mentsünk.

Az alkalmazott megoldásaink közül mutatunk kettőt ízelítőül:

Pull backup

• külön hoston lévő SAP rendszerek esetén egy közös tárterületre szinkronizáljuk a binárisokat, konfigurációt és az SAP filerendszereket (természetesen az adatbázis adat- és logfileok nélkül - azt a DB mentés intézi), kívülről indítva
• ez a közös tárterület a minimális helyfoglalás végett egy tömörített btrfs filerendszer, amelyről óránként belső snapshot-ot készítünk, így visszamenőleg akár több hónapra/évre visszamenőleg megvan minden filerendszer mindenkori állapota
• napi / heti szinten, ahogy az üzlet megkívánja, elarchiváljuk az utolsó pillanatfelvételt szalagra, így hosszú távon is visszakereshető, elérhető
• mivel az SAP hostok visszafelé nem férnek hozzá a mentési területhez, az SAP rendszerek esetleges kompromittálódása esetén a mentések nem sérülhetnek.

Append-only repo

• hostonként a rajta futó SAP konténerek filerendszereit beküldjük egy deduplikációt ismerő, tömörített és titkosítást végző mentőeszközbe, ami egy helyi backup repository-ba menti a filerendszereket, majd egy offsite/offline mentéssel még azt is biztosítja
• bár közvetlenül az SAP konténerek nem látják a backup tárterületet, az LXC/LXD hostok elérik azt, ezért a mentőszerveren a backup repository append-only módban van: nem lehet a mentéseket módosítani, természetesen azokból törölni sem, kizárólag újabb mentést lehet ráküldeni - így bármilyen szándékos vagy akár véletlen beavatkozás nem tudja megsérteni az adatok integritását.

További mentési megoldásaink