Ali pa je to mogoče? Seveda je migracija sistemov SAP kompleksen in mukotrpen proces, katerega uspeh zahteva dobro usklajeno delo vseh udeležencev. In če se selitev izvede v kratkem času, postane naloga veliko bolj zapletena. Za to se ne odločijo vsi. Razlogov je lahko več. Sam proces je na primer dolgotrajen in organizacijsko zapleten. Poleg tega obstaja nevarnost nenačrtovanih izpadov sistema. Ali pa stranke niso prepričane, da bodo po taki operaciji prejele ugodnosti, sorazmerne vloženemu trudu. Vendar obstajajo izjeme.
Spodaj bomo govorili o težavah, s katerimi se soočajo stranke v procesu migracije in vzdrževanja sistemov SAP, razpravljali o tem, zakaj stereotipi ne ustrezajo vedno resničnosti, in delili študijo primera, kako nam je uspelo prenesti strankine sisteme na nove infrastrukture v dobrih treh mesecih.
Gostovanje sistemov SAP
Še pred petimi leti si je bilo težko predstavljati, da bodo stranke množično začele uporabljati vire gostovanja za aplikacije SAP. V večini primerov so bili izvedeni na mestu uporabe. Z razvojem modelov zunanjega izvajanja in trga storitev v oblaku pa se je pogled na svet strank začel spreminjati. Kakšni so argumenti, ki vplivajo na izbiro v korist oblaka za SAP?
- Za začetnike, ki so šele načrtovali implementacijo SAP, je oblačna infrastruktura že skoraj standardna izbira – razširljivost virov na trenutne potrebe sistema in nepripravljenost na preusmerjanje virov v razvoj stranskih kompetenc.
- V podjetjih z veliko sistemsko pokrajino dosežejo CIO s pomočjo gostovanja SAP sistemov kakovostno drugačno raven upravljanja tveganj, saj Partner je odgovoren za SLA.
- Tretji najpogostejši argument so visoki stroški izgradnje infrastrukture za izvajanje scenarijev visoke razpoložljivosti in DR.
- Faktor 2027 – prodajalec je leta 2027 napovedal konec podpore za stare sisteme. To pomeni prenos podatkovne baze v HANA, kar pomeni stroške posodobitve in nakupa nove računalniške moči.
Trg gostovanja SAP v Rusiji se zdaj lahko šteje za precej zrelega. In to ponuja veliko priložnosti za stranke, ki želijo spremeniti svoje platforme gostovanja. Vendar lahko takšni projekti upravičeno povzročajo zaskrbljenost podjetij zaradi zapletenosti postopka migracije. To stranke sili k povečanim zahtevam od ponudnikov storitev, ki morajo poleg izjemnih kompetenc pri gostovanju in vzdrževanju sistemov SAP imeti tudi uspešne izkušnje na področju migracij.
Kakšne so težave pri menjavi gostovanja SAP?
Gostovanja so drugačna. Neskladje z deklarirano ravnjo storitve, veliko "ampak" in zvezdic s pridržki v majhnem besedilu, omejeni viri in zmogljivosti ponudnika gostovanja, pomanjkanje prilagodljivosti pri komunikaciji s stranko, birokracija, tehnične omejitve, nizka usposobljenost tehnične podpore strokovnjaki, kot tudi številne druge nianse - to je le majhen del pasti, na katere lahko naletijo stranke pri upravljanju svojih poslovnih sistemov v zunanjih infrastrukturah. Pogosto za naročnika vse to ostane v senci, v džungli večstranske pogodbe in se pojavi v procesu uporabe storitev.
Na neki točki stranki postane očitno, da je raven storitve, ki jo prejme, daleč od njenih pričakovanj. To je nekakšen katalizator za iskanje rešitev za popravljanje situacije in v primeru neuspeha, ko se težave kopičijo do meje in postane zelo boleče, preidejo na aktivna dejanja za razvoj alternativnih možnosti v smeri menjave ponudnika storitev. .
Zakaj čakajo do zadnje minute? Razlog je preprost – postopek selitve sistemov za stranke ni vedno pregleden in razumljiv. Naročnik težko oceni dejanska tveganja, povezana s procesom migracije. Lahko rečemo, da je migracija za naročnike nekakšna črna skrinjica: nejasna je cena, izpad sistema, tveganja in kako jih omiliti, na splošno pa je temačna in strašljiva. Kot da, če ne bo šlo, se bodo glave zvrnile tako na vrhu kot na nastopajočih.
SAP je sistem na ravni podjetja, kompleksen in, milo rečeno, poceni. Za njihovo izvajanje, spreminjanje in vzdrževanje se porabijo dostojni proračuni, življenjska doba podjetja pa je odvisna od njihove razpoložljivosti in pravilnega delovanja. Zdaj pa si predstavljajte posledice ustavitve neke velike proizvodnje. Gre za finančne izgube, ki jih je mogoče izračunati v številkah z velikim številom ničel, pa tudi za tveganje ugleda in druga enako pomembna tveganja.
Analizirali bomo težave, ki se lahko pojavijo na vsaki stopnji v primeru migracije sistemov SAP od ene od naših strank.
Priprava in oblikovanje
Migracija je formula z veliko različnimi deli. In ena najpomembnejših je faza projektiranja in priprave ciljne (nove) infrastrukture.
Morali smo se poglobiti v obstoječo izvedbo sistemov, njihovo arhitekturo. V ciljni infrastrukturi smo nekje ponovili obstoječe rešitve, jih ponekod dopolnili in izboljšali, ponekod predelali, premislili in izbrali rešitve, ki zagotavljajo toleranco na napake in razpoložljivost ter vse vire tudi čim bolj konsolidirali.
Med procesom načrtovanja je bilo izvedenih veliko različnih vaj, ki so na koncu omogočile čim večjo pripravo na selitev in upoštevanje vseh vrst nians in pasti (o njih kasneje).
Na koncu smo dobili individualno zasnovano zasebno infrastrukturo v oblaku, ki temelji na našem podatkovnem centru:
- namenski fizični strežniki za SAP HANA;
- VMware virtualizacijska platforma za aplikacijske strežnike in infrastrukturne storitve;
- podvojeni komunikacijski kanali med podatkovnimi centri za L2 VPN;
- dva glavna sistema za shranjevanje za ločevanje izdelka in "vsega drugega";
- SRC, ki temelji na Veritas Netbackup z ločenim strežnikom, diskovno polico in tračno knjižnico.
In tukaj je, kako smo vse to implementirali s tehničnega vidika.
SAP
- Za učinkovito uporabo pomnilnika za produktivno HANA smo uporabili diske v skupni rabi brez podvajanja sistemske baze podatkov z uporabo SAP. Vse to je bilo zavito v gručo SUSE HAE Active-Standby, ki temelji na Pacemakerju. Da, čas obnovitve je nekoliko daljši kot pri replikaciji, vendar prihranimo prostor za shranjevanje za polovico in posledično prihranimo proračun stranke.
- V predprodukcijskih okoljih so bili grozdi HANA opuščeni, vendar je bila tehnično produkcijska konfiguracija ponovljena.
- Testna in razvojna okolja so bila razdeljena na več strežnikov brez gruč v konfiguraciji MCOS.
- Vsi aplikacijski strežniki so bili virtualizirani in gostovani v VMware.
Seti
- Konture nadzornih in proizvodnih omrežij smo fizično ločili s skladi stikal, produktivna pa obrnili proti podatkovnim centrom strank.
- Namestili smo zadostno število omrežnih vmesnikov, da ne mešamo velikih prometnih tokov.
- Za prenos podatkov iz sistemov za shranjevanje smo izdelali klasične FC SAN tovarne.
SHD
- Produktivna in predproduktivna obremenitev SAP je ostala na polju all-flash.
- Testna okolja za razvijalce in infrastrukturne storitve so bile postavljene v ločeno hibridno polje.
IBS
- Izdelano z uporabo Veritas Netbackup.
- Dodali smo nekaj vgrajenih skriptov za varnostno kopiranje konfiguracij MCOS.
- Delovne kopije odlagamo na diskovno polico za hitro obnovitev, za dolgoročno shranjevanje pa uporabljamo trakove.
Spremljanje
- Vsa strojna oprema, OS in SAP so bili nameščeni pod Zabbix.
- V Grafani smo zbrali veliko uporabnih nadzornih plošč.
- Ko pride do opozorila, lahko Zabbix ustvari zahtevo v sistemu za upravljanje incidentov; implementirali smo jo na Jira. Podatki so podvojeni tudi v kanalu Telegram.
Telegram
Splošno zdravstveno stanje HANA
Stanje aplikacijskega strežnika SAP:
Infrastrukturne storitve
- Za servisiranje notranjih imenskih prostorov je bila postavljena gruča strežnikov DNS, ki je sinhronizirana s strežniki stranke.
- Ustvarili smo ločen datotečni strežnik za izmenjavo podatkov.
- Za shranjevanje različnih konfiguracij je bil dodan Gitlab.
- Za različne občutljive informacije smo vzeli HashiCorp Vault.
Postopek selitve
Na splošno je postopek selitve sestavljen iz naslednjih stopenj:
- priprava vse potrebne projektne dokumentacije;
- pogajanja s trenutnim ponudnikom - reševanje organizacijskih vprašanj;
- nakup, dobava in namestitev nove opreme za projekt;
- preskusna migracija in odpravljanje napak v procesu;
- prenos sistemov, boj proti migraciji.
Konec oktobra 2019 smo podpisali pogodbo, nato zasnovali arhitekturo in po dogovoru s stranko naročili potrebno opremo.
Na kar morate biti najprej pozorni je dobavni rok opreme. V povprečju dobava certificirane strojne opreme za SAP NAHA, ki izpolnjuje zahteve proizvajalca programske opreme za platforme strojne opreme, traja 10–12 tednov. In ob upoštevanju sezonskosti (izvedba projekta je padla ravno na novo leto) bi se to obdobje lahko podaljšalo še za en mesec. Zato je bilo potrebno čim bolj pospešiti proces: sodelovali smo z distributerjem dobaviteljem in se dogovorili za pospešeno dostavo z letali (namesto po kopnem in morju).
Novembra in decembra sta se pripravljala na selitev in prejela del opreme. Pripravo smo izvedli na testni napravi v našem javnem oblaku, kjer smo obdelali vse glavne korake in ujeli morebitne težave in težave:
- pripravil podroben načrt interakcije med člani projektne skupine z minutnimi časovnimi razporeditvami;
- zgradili testno napravo za bazo podatkov in aplikacijske strežnike na približno enak način kot v ciljni infrastrukturi;
- konfigurirali potrebne komunikacijske kanale in infrastrukturne storitve za testiranje delovanja integracij;
- izdelani scenariji prekinitve;
- Oblak nam je tudi pomagal ustvariti vnaprej konfigurirane predloge navideznih strojev, ki smo jih nato preprosto uvozili in namestili v ciljno pokrajino.
Malo pred novoletnimi prazniki je k nam prispela prva serija opreme. To je omogočilo namestitev nekaterih sistemov na pravo strojno opremo. Ker vse ni prispelo, smo priključili nadomestno opremo, katere dobavo smo uspeli dogovoriti s prodajalcem in distributerji. V zaključni fazi smo prejeli ostanke ciljne infrastrukture.
Da bi izpolnili rok, so morali naši inženirji žrtvovati novoletne praznike in začeti s pripravo ciljne infrastrukture 2. januarja, sredi praznikov. Ja, to se včasih zgodi, ko gori in preprosto ni druge možnosti. Na kocki je bila učinkovitost sistemov, od katerih je odvisno življenje podjetja.
Splošni vrstni red selitve je bil videti takole: najprej najmanj kritični sistemi (razvojna pokrajina, testna pokrajina), nato produktivni sistemi. Zadnja faza selitve je potekala konec januarja in v začetku februarja.
Postopek selitve je bil načrtovan do minute natančno. To je presečni načrt s seznamom vseh nalog, časom izvedbe in odgovornimi osebami. Vsi koraki so bili izdelani že v testni migraciji, zato je bilo pri živi migraciji potrebno le slediti načrtu in uskladiti proces.
Selitev je potekala sistematično v več fazah. V vsaki stopnji sta dva sistema.
Rezultat trimesečnega sprinta je polno delujoč sistem v podatkovnem centru CROC. Na splošno je bil s timskim delom dosežen pozitiven rezultat, prispevek in predanost vseh udeležencev v procesu pa je bil maksimalen.
Vloga naročnika v projektu
Komunikacija s ponudnikom, ki ga je stranka zapuščala, ni bila enostavna. To je razumljivo, bili so zadnji na seznamu zainteresiranih za uspešen zaključek projekta. Stranka je prevzela nalogo stopnjevanja in pedaliranja vseh komunikacijskih težav in se temu spopadla 100500%. Za to mu gre posebna zahvala. Brez takšne uresničljive udeležbe v procesu bi bil lahko rezultat projekta povsem drugačen.
Zaradi formalizacije procesov na strani »bivšega« ponudnika so infrastrukturno podporo izvajali strokovnjaki, ki so bili dobesedno daleč od problemov, takrat še njihova stranka. Na primer, postopek izvoza iste baze podatkov lahko traja od ene do pet ur. Takrat se je zdelo, da je to nekakšna čarovnija, skrivnost, ki nam ni bila nikoli razkrita. Verjetno so se inženirji tehnične podpore medtem prepustili meditaciji, pozabili, da so nekje v daljni Rusiji roki, inženirji brez novoletne solate, kupec joče in trpi ...
Rezultati projekta
Zadnji korak migracije je bil prenos sistemov na vzdrževanje.
Zdaj zagotavljamo storitev enega samega okna za zahteve strank in pokrivamo celoten obseg nalog, povezanih s podporo komponent infrastrukture in SAP osnove skupaj z našim partnerjem - itelligence. Stranka že šest mesecev živi v zasebnem oblaku. Tukaj je statistika primerov storitev v tem času:
- 90 incidentov (20 % rešenih brez vpletanja stranke)
- Razrešeno v SLA – 100 %
- Nenačrtovane zaustavitve sistema – 0
Če imate težave, podobne tistim naše stranke, in želite izvedeti več o tem, kako jih rešiti, pišite na: [e-pošta zaščitena]
Vir: www.habr.com