Vagy mégis? Természetesen a SAP-rendszerek migrálása bonyolult és időigényes folyamat, amelynek sikeréhez elengedhetetlen az összes résztvevő zökkenőmentes együttműködése. Ha a migrálás rövid határidőn belül történik, a feladat többszörösen bonyolultabbá válik. Nem mindenki vállalkozik erre. Ennek számos oka lehet. Például a folyamat önmagában hosszadalmas és szervezésileg is bonyolult. Ráadásul fennáll a kockázata a nem tervezett leállásoknak. Vagy a kilátásai nem biztosak abban, hogy egy ilyen műveletet követően a ráfordított erőfeszítések arányában hasznot fognak kapni. Ugyanakkor vannak kivételek is.
A cikkben beszámolunk azokról a nehézségekről, amelyekkel a megrendelők szembesülnek a SAP-rendszerek migrálása és fenntartása során, megvitatjuk, miért nem mindig felelnek meg a sztereotípiák a valóságnak, és megosztunk egy esetet arról, hogyan sikerült a megrendelő rendszereit mindössze három hónap alatt migrálni az új infrastruktúrába.
SAP-rendszerek hosztolása
Még öt évvel ezelőtt is nehezen lett volna elképzelni, hogy az ügyfelek tömegesen kezdenek el hosztolási erőforrásokat használni SAP-alkalmazásokhoz. A legtöbb esetben on-premise valósították meg őket. Azonban az outsourcig modellek és a felhőszolgáltatások piacának fejlődésével a megrendelők szemlélete elkezdett változni. Milyen érvek befolyásolják a felhő választását az SAP számára?
- Azok számára, akik most tervezik a SAP bevezetését, a felhő infrastruktúra gyakorlatilag az alapértelmezett választás – a rendszer aktuális igényeihez való erőforrás-skálázhatóság és a nem szakterülethez kapcsolódó kompetenciák fejlesztésére való erőforrások megszorítása.
- A nagy rendszertájjal rendelkező vállalatok számára a SAP-rendszerek hosztolásával a CIO új szintre emeli a kockázatkezelést, mivel az SLA-t egy partner vállalja.
- A harmadik leggyakrabban említett érv – az infrastruktúra kiépítésének magas költsége a magas rendelkezésre állás és a DR forgatókönyvek megvalósításához.
- 2027-es tényező – a gyártó által bejelentett elavult rendszerek támogatásának megszüntetése 2027-ben. Ez a HANA adatbázisra való áttérést jelenti, amely korszerűsítési és új számítási teljesítmény beszerzési költségeket von maga után.
Az SAP-hoszting piaca Oroszországban jelenleg meglehetősen érettnek mondható. Ez széles lehetőségeket kínál azok számára, akik szeretnék megváltoztatni hosztingplatformjaikat. Ugyanakkor az ilyen projektek jogosan okozhatnak aggodalmat a vállalkozások számára a migrációs folyamat bonyolultsága miatt. Ez arra kényszeríti az ügyfeleket, hogy magasabb követelményeket támasztanak a szolgáltatókkal szemben, akiknek nemcsak kivételes hoszting és SAP rendszerek támogatásához kapcsolódó kompetenciákkal kell rendelkezniük, hanem sikeres migrációs tapasztalattal is.
Mik a nehézségek az SAP-hoszting váltás során?
A hosztok különbözőek. A hirdetett szolgáltatási szinttel való eltérés, a sok „de” és apró betűs lábjegyzet, a források és lehetőségek korlátozottsága szolgáltató, a rugalmasság hiánya az ügyféllel való kommunikációban, bürokrácia, technikai korlátozások, a műszaki támogatás szakembereinek alacsony szakképzettsége, valamint számos egyéb nuansz — ezek csak a jéghegy csúcsát jelentik azokból a csapdákból, amelyekkel az ügyfelek szembesülhetnek üzleti rendszereik outsourcing infrastruktúrákban való üzemeltetése során. Gyakran az ügyfél számára mindez rejtve marad, a többoldalas szerződés labirintusában, és csak a szolgáltatások igénybevétele során derül ki.
Egy adott pillanatban az ügyfél számára nyilvánvalóvá válik, hogy a szolgáltatás szintje, amit kap, távol áll az elvárásaitól. Ez egyfajta katalizátor a helyzet javítására irányuló megoldások keresésére, és ha a helyzet nem javul, a felhalmozódó problémák elérik a határvonalat, ami komoly fájdalmat okoz, akkor aktív lépésekre lépnek az alternatív lehetőségek keresése érdekében a szolgáltatóváltás irányában.
Miért várnak az utolsó pillanatig? Az ok egyszerű — az ügyfelek számára a rendszerek átköltöztetése nem mindig átlátható és érthető folyamat. Az ügyfél nehezen tudja felmérni a migrációval összefüggő tényleges kockázatokat. Mondhatni, a migráció ügyfelek számára egyfajta fekete doboz: nem világos az ár, a rendszerek leállásának ideje, a kockázatok és azok minimalizálása, és egyáltalán sötét és félelmetes. Itt az a helyzet, hogy ha nem sikerül, akkor a fejek fognak repkedni a vezetők és végrehajtók körében is.
A SAP vállalati szintű rendszerek, amelyek bonyolultak és finoman szólva nem olcsók. Az implementálásuk, testreszabásuk és támogatásuk komoly költségvetéseket igényel, és elérhetőségük, valamint a helyes működésük az üzemeltetés életképeségétől függ. Most képzelje el egy jelentős gyártás leállásának következményeit. Ezek pénzügyi veszteségek, amelyek számjegyekben mérhetők, sok nullával, valamint reputációs és más, nem kevésbé jelentős kockázatok.
Vizsgáljuk meg azokat a nehézségeket, amelyek felmerülhetnek a migrációs SAP-rendszerek egyik ügyfelünk esetében.
Előkészítés és tervezés
A migráció egy olyan képlet, amely számos különböző összetevőből áll. Az egyik legfontosabb szakasz a cél (új) infrastruktúra tervezése és előkészítése.
Be kellett merülnünk a meglévő rendszerekbe, azok architektúrájába. A célinfrastruktúrában egyes megoldásokat ismételtünk, más aspektusokat kiegészítettünk és javítottunk, és voltak, amelyeket átalakítottunk, megterveztük és kiválasztottuk a megbízhatóságot és a rendelkezésre állást biztosító megoldásokat, valamint maximálisan konszolidáltuk az összes erőforrást.
A tervezési folyamat során sok különféle gyakorlatot hajtottunk végre, amelyek végül lehetővé tették, hogy maximálisan felkészüljünk a migrációra, és figyelembe vegyük az összes lehetséges árnyoldalt és buktatót (erről később).
Az eredményünk egy egyedileg megtervezett privát felhőinfrastruktúra a mi adatközpontunk alapján:
- dedikált fizikai szerverek SAP HANA számára;
- VMware virtualizációs platform az alkalmazás- és infrastruktúraszolgáltatásokhoz;
- másolt kapcsolatcsatornák az adatközpontok között L2-n; VPN;
- két fő tárolórendszer a termelés és a „minden más” elkülönítésére;
- Veritas Netbackup alapú SBackup egy különálló szerverrel, lemezes tömbbel és szalagos könyvtárral.
Íme, hogyan valósítottuk meg mindezt technikai szempontból.
SAP
- A produktív HANA tárolók hatékony kihasználása érdekében közös lemezeket használtunk, anélkül, hogy a SAP eszközeivel adatbázis-replikációt végeztünk volna. Mindezt az SUSE HAE aktív-tartalék klaszterébe csomagoltuk, amely a Pacemaker-en alapul. Igen, a helyreállítási idő valamivel hosszabb, mint a replikáció esetén, de cserébe kétszer annyi tárolóhelyet spórolunk meg, ami következésképpen csökkentheti az ügyfél költségvetését.
- Az előtermelői környezetekből elhagytuk a HANA klasztereket, de technikailag megismételtük a termelési konfigurációt.
- A tesztkörnyezeteket és fejlesztői környezeteket több szerverre osztottuk szét klaszterek nélkül, MCOS konfigurációban.
- Minden alkalmazásszervert virtualizáltunk és VMware-ben helyeztük el.
Hálózatok
- Fizikailag szétválasztottuk a kezelőhálózatok és a termelő hálózatok határait kapcsolók halmazával, a termelőket az ügyfél adatközpontja felé fordítva.
- Elég hálózati interfészt telepítettünk, hogy ne keveredjenek a nagy adattömörítési forgalmak.
- Az adatok tárolásához klasszikus FC SAN architektúrákat hoztunk létre.
Tárolórendszer
- A SAP termelői és előtermelői terhelését egy all-flash tárolón tartottuk.
- A fejlesztők tesztkörnyezetét és az infrastruktúra szolgáltatásokat külön hibrid tárolón helyeztük el.
SRK
- A Veritas Netbackup alapjára épült.
- Kicsit módosítottuk az beépített szkripteket, hogy backup-olják az MCOS konfigurációkat.
- Az operatív példányokat lemezpolcra helyeztük, hogy gyorsan vissza tudjunk állni, hosszú távú tárolásra pedig szalagokat használunk.
Monitorozás
- Minden hardver, operációs rendszer és SAP Zabbix alatt van nyilvántartva.
- Rengeteg hasznos irányítópultot gyűjtöttünk össze a Grafanában.
- Amikor Zabbix riasztást jelez, képes jegyet nyitni az incidens menedzsment rendszerében, nálunk ezt a Jira használja. Az információt egy Telegram csatornára is továbbítjuk.
Telegram
HANA általános állapota
SAP alkalmazásszerver állapot:
Infrastruktúra szolgáltatások
- A belső névtér kezeléséhez DNS szerver klasztert állítottunk fel, amely szinkronizálódik az ügyfél szervereivel.
- Külön fájlszolgáltatót hoztunk létre az adatok cseréjére.
- Különböző konfigurációk tárolására Gitlabot adtunk hozzá.
- Érzékeny információk tárolására HashiCorp Vault-ot használtunk.
Migrációs folyamat
Általában a migrációs folyamat a következő lépésekből áll:
- az összes szükséges projekt dokumentációjának előkészítése;
- tárgyalások a jelenlegi szolgáltatóval - szervezeti kérdések megoldása;
- új berendezések beszerzése, szállítása és telepítése a projekt keretein belül;
- tesztmigráció és a folyamat finomhangolása;
- rendszerek áttelepítése, éles migráció.
2019 október végén aláírtuk a szerződést, ezután megterveztük az architektúrát, majd annak ügyfél általi jóváhagyását követően megrendeltük a szükséges berendezéseket.
A legfontosabb dolog, amire figyelni kell, az az eszközök szállítási határideje. A SAP NAHA-hoz szükséges, a szoftvergyártó által előírt hardverplatform szabványainak megfelelő tanúsított hardver szállítása átlagosan 10-12 hétig tart. Figyelembe véve a szezonális tényezőket (a projekt megvalósítása éppen az új év köszöntésére esett) – ez az időszak akár egy hónappal is meghosszabbodhatott. Ennek megfelelően a folyamatot a lehető leggyorsabban kellett felgyorsítanunk: dolgoztunk a forgalmazó- és beszállítópartnerrel, és megállapodtunk gyorsított légiközlekedésről (a szárazföldi és tengeri szállítás helyett).
November és december a migráció előkészítésére és a szükséges hardver egy részének beszerzésére ment el. Az előkészítést a nyilvános felhőnk tesztkörnyezetében végeztük, ahol minden fő lépést gyakoroltunk, és az esetleges nehézségeket és problémákat azonosítottuk:
- elkészítettük a projektcsapatok résztvevőinek részletes együttműködési tervét perc alapú ütemezéssel;
- tesztkörnyezetet építettünk az adatbázisok és alkalmazás szerverek számára, körülbelül úgy, ahogyan a célinfrastruktúrában is lenne;
- beállítottuk a szükséges kommunikációs csatornákat és infrastrukturális szolgáltatásokat, hogy ellenőrizzük az integrációk működését;
- gyakoroltuk a cutover forgatókönyveket;
- a felhő emellett segített nekünk előre konfigurált virtuális gép sablonok létrehozásában, amelyeket később egyszerűen importáltunk és telepítettünk a cél tájban.
Nem sokkal az újévi ünnepek előtt megérkezett az első szállítmányunk. Ez lehetővé tette, hogy egy részét a rendszereknek valós hardveren telepítsük. Mivel nem minden érkezett meg, egy helyettesítő eszközt csatlakoztattunk, amelynek szállításáról sikerült megállapodnunk a forgalmazóval. A célinfrastruktúra hátralévő részeit már a végső szakaszban kaptuk meg.
A határidők betartása érdekében mérnökeinknek fel kellett áldozniuk az újévi ünnepeket, és január 2-án, az ünnepek kellős közepén elkezdték a célinfrastruktúra előkészítését. Igen, ez néha megtörténik, amikor sürgős, és nincs más lehetőség. A rendszerek működése volt a tét, ami a vállalat életképességét biztosította.
A migráció általános menete a következőképpen alakult: először a legkevésbé kritikus rendszerek (fejlesztési táj, tesztelési táj), majd a termelési rendszerek migrációja. A migráció végső szakasza január végén, február elején zajlott.
A migrációs folyamatot percre pontosan megtervezték. Ez egy cutover terv, amely tartalmazza az összes feladatot, végrehajtási időpontokat és felelősöket. Minden lépést már leteszteltek egy próbamigráción, így a tényleges migráción csupán követni kellett a tervet és koordinálni a folyamatot.
A migrációt rendszerenként, több lépésben hajtották végre. Minden lépésben két rendszer volt.
A három hónapos sprintek eredményeként egy teljesen működő rendszer került a KROK adatközpontjába. Összességében a pozitív eredmény a közös munkának köszönhető, minden résztvevő maximális hozzájárulása és elkötelezettsége hozzájárult a sikerhez.
A megrendelő szerepe a projektben
Kommunikálni a szolgáltatóval, akit a kliensünk elhagyott, nem volt egyszerű. Ez érthető, ők voltak az utolsók a projekt sikeres lezárása szempontjából érdekelt személyek listáján. A megrendelő átvette az összes kommunikációs kérdés escalálásának és tárgyalásának feladatait, és ezt 100500%-osan megoldotta. Külön köszönet ezért. Enélkül a támogatás nélkül a projekt eredménye teljesen másképp alakulhatott volna.
A korábbi szolgáltató oldalán a folyamatok formális jellege miatt a szakemberek, akik az infrastruktúra támogatásával foglalkoztak, gyakorlatilag távol álltak a problémák megoldásától, melyekkel akkoriban még az ügyfelük foglalkozott. Például egy adatbázis exportálása 1 órától 5 óráig is eltarthatott. Akkor úgy tűnt, mintha valami varázslat lenne, egy titok, amelyet soha nem tártunk fel. Valószínűleg a technikai támogatás mérnökei közben meditáltak, elfeledkezve arról, hogy ott, a távoli Oroszországban, határidők vannak, mérnökök ünnepi saláták nélkül, és az ügyfél sír és szenved...
A projekt eredményei
A migráció végső akkordja a rendszerek átadása volt a támogatásra.
Jelenleg egyablakos szolgáltatást biztosítunk a megrendelőnek, amely lefedi az infrastruktúra komponensei és a SAP basis támogatásának teljes feladatkörét, együttműködve az itelligence céggel. Az ügyfél már fél éve él a magánfelhőben. Íme a szolgáltatási esetek statisztikája ez idő alatt:
- 90 incidens (20%-át a megrendelő bevonása nélkül sikerült megoldani)
- SLA keretein belül megoldva – 100%
- Tervektől eltérő rendszerleállítások – 0
Ha Önnek hasonló feladatai vannak, mint amilyenek a kliensünknél voltak, és szeretne többet megtudni arról, hogyan oldhatja meg őket, írjon: ahaidukov@croc.ru
Forrás: habr.com
