Vagy lehetséges? Természetesen az SAP-rendszerek migrálása összetett és fáradságos folyamat, melynek sikeréhez minden résztvevő jól összehangolt munkájára van szükség. Ha pedig a migrációt rövid időn belül végrehajtják, a feladat sokkal bonyolultabbá válik. Nem mindenki dönti el ezt. Több oka is lehet. Például maga a folyamat hosszadalmas és szervezetileg bonyolult. Ezenkívül fennáll a nem tervezett rendszerleállás veszélye. Vagy az ügyfelek nem biztosak abban, hogy miután átestek egy ilyen műveleten, a ráfordított erőfeszítésekkel arányos előnyöket kapnak. Vannak azonban kivételek.
A vágás alatt beszélünk azokról a nehézségekről, amelyekkel az ügyfelek szembesülnek az SAP-rendszerek migrálása és karbantartása során, megvitatjuk, hogy a sztereotípiák miért nem mindig felelnek meg a valóságnak, és megosztunk egy esettanulmányt arról, hogyan sikerült áttelepítenünk egy ügyfél rendszerét egy új infrastruktúra alig több mint három hónap alatt.
SAP rendszerek hosting
Alig öt évvel ezelőtt nehéz volt elképzelni, hogy az ügyfelek tömegesen kezdenék el használni az SAP-alkalmazások tárhely-erőforrásait. A legtöbb esetben a helyszínen valósították meg őket. Az outsourcing modellek és a felhőszolgáltatások piacának fejlődésével azonban az ügyfelek világképe megváltozni kezdett. Milyen érvek befolyásolják az SAP-felhő melletti választást?
- A kezdők számára, akik most tervezték az SAP bevezetését, a felhő-infrastruktúra szinte standard választás – az erőforrások méretezhetősége a rendszer aktuális igényeihez, és nem hajlandó az erőforrásokat a nem alapvető kompetenciák fejlesztésére fordítani.
- A nagy rendszerterülettel rendelkező cégeknél az SAP rendszerek hosztolásának segítségével a CIO-k minőségileg eltérő kockázatkezelési szintet érnek el, mert A partner felelős az SLA-ért.
- A harmadik leggyakoribb é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.
- Factor 2027 – a gyártó bejelentette, hogy 2027-ben megszünteti a régi rendszerek támogatását. Ez azt jelenti, hogy az adatbázist át kell vinni a HANA-ba, ami modernizációs költségeket és új számítási teljesítmény beszerzését vonja maga után.
Az oroszországi SAP hosting piac mára meglehetősen kiforrottnak tekinthető. Ez pedig bőséges lehetőséget biztosít azoknak az ügyfeleknek, akik meg akarják változtatni tárhely-platformjaikat. Az ilyen projektek azonban joggal okozhatnak aggodalmat a vállalkozások körében a migrációs folyamat összetettsége miatt. Ez arra kényszeríti az ügyfeleket, hogy fokozott követelményeket támasztassanak a szolgáltatókkal szemben, akiknek nem csak az SAP rendszerek üzemeltetésében és karbantartásában kiemelkedő kompetenciákkal kell rendelkezniük, hanem a migráció terén is sikeres tapasztalattal kell rendelkezniük.
Milyen nehézségekkel jár az SAP tárhely megváltoztatása?
A hostingok különbözőek. Inkonzisztencia a bejelentett szolgáltatási szinttel, sok "de" és csillag fenntartással kis szövegben, a tárhelyszolgáltató korlátozott erőforrásai és képességei, rugalmasság hiánya az ügyféllel való kommunikációban, bürokrácia, technikai korlátok, a technikai támogatás alacsony kompetenciája szakemberek, valamint sok más árnyalat – ezek csak egy kis része azoknak a buktatóknak, amelyekkel az ügyfelek találkozhatnak, amikor üzleti rendszereiket kiszervezési infrastruktúrákban működtetik. Gyakran az ügyfél számára mindez az árnyékban, egy többoldalas szerződés dzsungelében marad, és a szolgáltatások igénybevétele során derül ki.
Egy ponton az ügyfél számára nyilvánvalóvá válik, hogy az általa kapott szolgáltatás messze elmarad az elvárásaitól. Ez egyfajta katalizátor a helyzet megoldására, és kudarc esetén, amikor a problémák a végletekig halmozódnak, és ez nagyon fájdalmassá válik, aktív cselekvésre lépnek, hogy alternatív lehetőségeket dolgozzanak ki a szolgáltatóváltás irányába. .
Miért várnak az utolsó pillanatig? Az ok egyszerű: a rendszerek migrációjának folyamata az ügyfelek számára nem mindig átlátható és érthető. Az ügyfél számára nehéz felmérni a migrációs folyamathoz kapcsolódó tényleges kockázatokat. Elmondhatjuk, hogy az ügyfelek számára a migráció egyfajta fekete doboz: nem világos, az ár, a rendszerleállás, a kockázatok és azok mérséklésének módja, és általában sötét és ijesztő. Ez olyan, hogy ha nem sikerül, akkor a csúcson és a fellépőkön is megfordul a fej.
Az SAP vállalati szintű rendszer, bonyolult és finoman szólva sem olcsó. Megvalósításukra, módosításukra és karbantartásukra tisztességes költségvetést költenek, elérhetőségüktől és megfelelő működésüktől függ a vállalkozás élettartama. Most képzelje el, milyen következményekkel járna néhány nagy termelés leállítása. Ezek nagyszámú nullaszámmal számszerűsíthető pénzügyi veszteségek, valamint reputációs és egyéb, hasonlóan jelentős kockázatok.
Elemezzük az egyes szakaszokban felmerülő nehézségeket az SAP-rendszerek egyik ügyfelünktől való migrálása esetén.
Előkészítés és tervezés
A migráció sok különböző részből álló képlet. És az egyik legfontosabb a cél (új) infrastruktúra tervezésének és előkészítésének szakasza.
El kellett merülnünk a rendszerek meglévő megvalósításában, architektúrájában. A célinfrastruktúrában a meglévő megoldásokat valahol megismételtük, egyes pontokon kiegészítettük, javítottuk, valahol újraírtuk, átgondoltuk és kiválasztottuk a hibatűrést és rendelkezésre állást biztosító megoldásokat, valamint lehetőség szerint minden erőforrást konszolidáltunk.
A tervezés során sokféle gyakorlatot hajtottak végre, amelyek végső soron lehetővé tették a migrációra való minél nagyobb felkészülést, és mindenféle árnyalatok és buktatók figyelembevételét (azokról később).
Végül egy egyedileg tervezett privát felhő infrastruktúrához jutottunk, amely adatközpontunkon alapul:
- dedikált fizikai szerverek az SAP HANA számára;
- VMware virtualizációs platform alkalmazásszerverekhez és infrastrukturális szolgáltatásokhoz;
- duplikált kommunikációs csatornák adatközpontok között az L2 VPN számára;
- két fő tárolórendszer a termék és a „minden más” elkülönítésére;
- Veritas Netbackup alapú SRC külön szerverrel, lemezpolccal és szalagos könyvtárral.
És íme, hogyan valósítottuk meg mindezt technikai szempontból.
SAP
- A hatékony HANA tárolás érdekében megosztott lemezeket használtunk rendszeres adatbázis-replikáció nélkül az SAP segítségével. Mindezt egy pacemakerre épülő Active-Standby SUSE HAE klaszterbe csomagolták. Igen, a helyreállítási idő kicsit hosszabb, mint a replikációnál, de a felére tárhelyet takarítunk meg, és ennek eredményeként az ügyfél költségvetését.
- A gyártás előtti környezetekben a HANA-fürtöket elhagyták, de technikailag a gyártási konfigurációt megismételték.
- A teszt- és fejlesztőkörnyezeteket MCOS-konfigurációban több fürt nélküli szerver között is szétosztották.
- Minden alkalmazásszerver virtualizált volt, és a VMware-ben tárolták.
Сети
- A vezérlő- és termelési hálózatok körvonalait fizikailag kapcsolókötegekkel választottuk el, a produktívakat az ügyfél adatközpontjai felé fordítottuk.
- Elegendő számú hálózati interfészt telepítettünk, hogy ne keverjük össze a nagy forgalmi áramlásokat.
- A tárolórendszerek adatainak átviteléhez klasszikus FC SAN gyárakat készítettünk.
SHD
- Az SAP produktív és termelés előtti terhelése az all-flash tömbön maradt.
- A fejlesztői tesztkörnyezetek és az infrastruktúra-szolgáltatások külön hibrid tömbbe kerültek.
IBS
- Veritas Netbackup segítségével készült.
- Hozzáadtunk egy kicsit a beépített szkriptekhez az MCOS konfigurációk biztonsági mentéséhez.
- Az üzemképes másolatokat lemezpolcra helyezzük a gyors helyreállítás érdekében, a hosszú távú tároláshoz szalagokat használunk.
megfigyelés
- Minden hardver, operációs rendszer és SAP a Zabbix alatt lett telepítve.
- Sok hasznos műszerfalat gyűjtöttünk össze a Grafanában.
- Amikor riasztás történik, a Zabbix kérést tud létrehozni az incidenskezelő rendszerben; ezt megvalósítottuk a Jira-n. Az információ a Telegram csatornán is megduplázódik.
Telegram
A HANA általános egészségi állapota
SAP alkalmazáskiszolgáló állapota:
Infrastrukturális szolgáltatások
- A belső névterek kiszolgálására DNS-kiszolgálók fürtje került felállításra, amely szinkronizálva van az ügyfél szervereivel.
- Az adatcseréhez külön fájlszervert hoztunk létre.
- A különféle konfigurációk tárolására a Gitlab került hozzáadásra.
- Különféle kényes információkért a HashiCorp Vaultot vettük igénybe.
Migrációs folyamat
A migrációs folyamat általában a következő szakaszokból áll:
- minden szükséges projektdokumentáció elkészítése;
- tárgyalások a jelenlegi szolgáltatóval - szervezési kérdések megoldása;
- a projekthez szükséges új berendezések beszerzése, szállítása és telepítése;
- migráció tesztelése és folyamathibakeresés;
- rendszerek átadása, migráció elleni küzdelem.
2019. október végén szerződést kötöttünk, majd megterveztük az architektúrát, majd a megrendelővel egyeztetve megrendeltük a szükséges berendezéseket.
Amire először figyelni kell, az a berendezés szállítási ideje. Átlagosan 10-12 hétig tart a szoftvergyártó hardverplatformokra vonatkozó követelményeinek megfelelő SAP NAHA tanúsított hardver szállítása. És figyelembe véve a szezonalitást (a projekt megvalósítása pontosan az újévre esett), ez az időszak még egy hónappal megnőhetett volna. Ennek megfelelően kellett a folyamatot a lehető legnagyobb mértékben felgyorsítani: együttműködtünk a forgalmazó-beszállítóval, és megegyeztünk a gyorsított repülős szállításban (a szárazföldi és tengeri útvonalak helyett).
A november és a december a migráció előkészítésével és a felszerelések egy részének átvételével telt. A felkészülést a nyilvános felhőnkben lévő tesztpadon végeztük, ahol végigdolgoztuk az összes fő lépést, és felfogtuk az esetleges nehézségeket, problémákat:
- részletes tervet készített a projektcsapat tagjai közötti interakcióról percenkénti időzítéssel;
- az adatbázis- és alkalmazásszerverekhez hozzávetőlegesen a célinfrastruktúrához hasonlóan épített tesztpadot;
- konfigurálta a szükséges kommunikációs csatornákat és infrastrukturális szolgáltatásokat az integrációk működésének teszteléséhez;
- átvágási forgatókönyvek kidolgozása;
- A felhő abban is segített, hogy előre konfigurált virtuálisgép-sablonokat hozzunk létre, amelyeket aztán egyszerűen importáltunk és telepítettünk a célterületre.
Nem sokkal az újévi ünnepek előtt megérkezett hozzánk az első adag felszerelés. Ez lehetővé tette egyes rendszerek valódi hardveren történő telepítését. Mivel nem érkezett meg minden, csereberendezéseket kapcsoltunk be, melyek szállításáról sikerült megegyezni az eladóval és a forgalmazókkal. Az utolsó szakaszban megkaptuk a célinfrastruktúra maradványait.
A határidő betartásához mérnökeinknek fel kellett áldozniuk az újévi ünnepeket, és január 2-án, az ünnepek közepette meg kellett kezdeni a célinfrastruktúra előkészítését. Igen, ez néha megtörténik, amikor ég, és egyszerűen nincs más lehetőség. A tét azoknak a rendszereknek a teljesítménye volt, amelyektől a vállalkozás élete függ.
A migráció általános sorrendje így nézett ki: először a legkevésbé kritikus rendszerek (fejlesztési táj, tesztelési környezet), majd a termelő rendszerek. A migráció utolsó szakasza január végén és február elején zajlott le.
A migrációs folyamatot percre pontosan megtervezték. Ez egy átvágási terv, amely tartalmazza az összes feladatot, az elvégzési időt és a felelős személyeket. A tesztmigrációban már minden lépés ki volt dolgozva, így az élő migrációnál már csak a tervet kellett követni és a folyamatot koordinálni.
A migráció szisztematikusan, több szakaszban történt. Minden szakaszban két rendszer van.
A három hónapos sprint eredménye egy olyan rendszer lett, amely a CROC adatközpontjában teljesen működőképes. Általánosságban elmondható, hogy csapatmunkával pozitív eredmény született, a folyamatban minden résztvevő közreműködése és elhivatottsága maximális volt.
A megrendelő szerepe a projektben
Ügyfelünk távozó szolgáltatójával nem volt könnyű kommunikálni. Ez érthető is, ők voltak az utolsók a projekt sikeres lebonyolítása iránt érdeklődők listáján. Az ügyfél magára vállalta az összes kommunikációs probléma eszkalálását és pedálozását, és ezzel 100500%-ig megbirkózott. Külön köszönet neki ezért. A folyamatban való ilyen megvalósítható részvétel nélkül a projekt eredménye egészen más lehetett volna.
A folyamatok formalizálása miatt a „volt” szolgáltató oldalán az infrastruktúra-támogatást olyan szakemberek végezték, akik szó szerint távol álltak a problémáktól, akkor még ügyfeleik. Például ugyanazon adatbázis exportálása egy órától ötig tarthat. Aztán úgy tűnt, hogy ez valami varázslat, egy titok, amelyet soha nem tártak fel előttünk. Valószínűleg a műszaki támogató mérnökök eközben meditációba merültek, elfelejtve, hogy valahol a távoli Oroszországban határidők vannak, mérnökök újévi saláták nélkül, a megrendelő sír és szenved...
Projekt eredményei
A migráció utolsó lépése a rendszerek karbantartásra való átadása volt.
Most egyablakos szolgáltatást nyújtunk a vevői igényekre, és lefedjük az infrastruktúra-elemek támogatásával és az SAP-bázissal kapcsolatos feladatok teljes körét partnerünkkel - az itelligence-vel. Az ügyfél hat hónapja egy privát felhőben él. Íme az ez idő alatti szolgáltatási esetek statisztikái:
- 90 incidens (20%-a az ügyfél bevonása nélkül megoldódott)
- SLA-n belül megoldva – 100%
- Nem tervezett rendszerleállások – 0
Ha ügyfelünkhöz hasonló problémái vannak, és szeretne többet megtudni ezek megoldásáról, írjon a következő címre: [e-mail védett]
Forrás: will.com