Eller er det muligt? Selvfølgelig er migrering af SAP-systemer en kompleks og omhyggelig proces, hvis succes kræver et velkoordineret arbejde fra alle deltagere. Og hvis migreringen gennemføres på kort tid, bliver opgaven meget mere kompliceret. Ikke alle beslutter sig for at gøre dette. Der kan være flere årsager. For eksempel er selve processen langvarig og organisatorisk kompleks. Derudover er der risiko for uplanlagt nedetid. Eller kunder er ikke sikre på, at de efter at have gennemgået en sådan operation vil modtage fordele svarende til den indsats, de har brugt. Der er dog undtagelser.
Under snittet vil vi tale om de vanskeligheder, som kunder står over for i processen med at migrere og vedligeholde SAP-systemer, diskutere, hvorfor stereotyper ikke altid stemmer overens med virkeligheden, og dele et casestudie af, hvordan vi formåede at migrere en kundes systemer til en ny infrastruktur på godt tre måneder.
SAP systemer hosting
For bare fem år siden var det svært at forestille sig, at kunder massivt ville begynde at bruge hostingressourcer til SAP-applikationer. I de fleste tilfælde blev de implementeret on-premise. Men med udviklingen af outsourcing-modeller og markedet for cloudtjenester begyndte kundernes verdensbillede at ændre sig. Hvilke argumenter har indflydelse på valget til fordel for skyen til SAP?
- For begyndere, der lige har planlagt at implementere SAP, er cloud-infrastruktur nærmest et standardvalg – skalerbarhed af ressourcer til systemets aktuelle behov og modvilje mod at omdirigere ressourcer til udvikling af ikke-kernekompetencer.
- I virksomheder med et stort systemlandskab når CIO'er ved hjælp af hosting af SAP-systemer et kvalitativt andet niveau af risikostyring, pga. Partneren er ansvarlig for SLA.
- Det tredje mest almindelige argument er de høje omkostninger ved at bygge infrastruktur for at implementere høj tilgængelighed og DR-scenarier.
- Faktor 2027 – leverandøren annoncerede afslutningen på support til ældre systemer i 2027. Det betyder overførsel af databasen til HANA, hvilket medfører omkostninger til modernisering og indkøb af ny computerkraft.
SAP-hostingmarkedet i Rusland kan nu betragtes som ret modent. Og dette giver rig mulighed for kunder, der ønsker at ændre deres hostingplatforme. Sådanne projekter kan dog med rette skabe bekymring blandt virksomheder på grund af migreringsprocedurens kompleksitet. Dette tvinger kunderne til at stille øgede krav til serviceudbydere, som ikke kun skal have exceptionelle kompetencer i at hoste og vedligeholde SAP-systemer, men også have succes med erfaring inden for migration.
Hvad er vanskelighederne ved at ændre SAP-hosting?
Hosting er forskellige. Uoverensstemmelse med det erklærede serviceniveau, mange "men" og stjerner med forbehold i lille tekst, begrænsede ressourcer og muligheder hos hostingudbyderen, manglende fleksibilitet i spørgsmål om kommunikation med klienten, bureaukrati, tekniske begrænsninger, lav kompetence i teknisk support specialister, samt mange andre nuancer - disse er Dette er blot en lille del af de faldgruber, som kunder kan støde på, når de betjener deres forretningssystemer i outsourcing af infrastrukturer. For klienten forbliver alt dette ofte i skyggen, i junglen af en flersidet kontrakt, og dukker op i processen med at bruge tjenesterne.
På et tidspunkt bliver det tydeligt for kunden, at det serviceniveau, han får, er langt fra hans forventninger. Dette er en slags katalysator for at finde løsninger til at rette op på situationen, og i tilfælde af fejl, når problemer akkumuleres til grænsen, og det bliver meget smertefuldt, går de videre til aktive handlinger for at udvikle alternative muligheder i retning af at skifte tjenesteudbyder .
Hvorfor venter de til sidste øjeblik? Årsagen er enkel - processen med at migrere systemer for klienter er ikke altid gennemsigtig og forståelig. Det er vanskeligt for klienten at vurdere de faktiske risici forbundet med migreringsprocessen. Vi kan sige, at migrering for klienter er en slags sort boks: det er uklart, prisen, systemets nedetid, risici og hvordan man afbøder dem, og generelt er det mørkt og skræmmende. Det er ligesom, hvis det ikke lykkes, så ruller hovederne både i toppen og hos de optrædende.
SAP er et system på virksomhedsniveau, komplekst og mildt sagt ikke billigt. Anstændige budgetter bruges på deres implementering, ændring og vedligeholdelse, og virksomhedens levetid afhænger af deres tilgængelighed og korrekte drift. Forestil dig nu konsekvenserne af at stoppe en eller anden stor produktion. Det er økonomiske tab, som kan opgøres i tal med et stort antal nuller, samt omdømme- og andre lige så væsentlige risici.
Vi vil analysere de vanskeligheder, der kan opstå på hvert trin i tilfælde af migrering af SAP-systemer fra en af vores kunder.
Forberedelse og design
Migration er en formel med mange forskellige dele. Og en af de vigtigste er fasen med at designe og forberede den målrettede (nye) infrastruktur.
Vi var nødt til at dykke ned i den eksisterende implementering af systemerne, deres arkitektur. I målinfrastrukturen gentog vi eksisterende løsninger et eller andet sted, supplerede og forbedrede dem på nogle punkter, gjorde dem om et sted, gennemtænkte og valgte løsninger for at sikre fejltolerance og tilgængelighed, og også konsoliderede alle ressourcer så meget som muligt.
Under designprocessen blev der udført mange forskellige øvelser, som i sidste ende gjorde det muligt at forberede så meget som muligt på migration og tage højde for alle mulige nuancer og faldgruber (mere om dem senere).
Det, vi endte med, er en individuelt designet privat cloud-infrastruktur baseret på vores datacenter:
- dedikerede fysiske servere til SAP HANA;
- VMware virtualiseringsplatform til applikationsservere og infrastrukturtjenester;
- duplikerede kommunikationskanaler mellem datacentre til L2 VPN;
- to hovedopbevaringssystemer til at adskille produktet og "alt andet";
- SRC baseret på Veritas Netbackup med separat server, diskhylde og båndbibliotek.
Og her er, hvordan vi implementerede alt dette fra et teknisk synspunkt.
SAP
- For effektivt at bruge storage til produktiv HANA brugte vi delte diske uden systemisk databasereplikering ved hjælp af SAP. Alt dette blev pakket ind i en Active-Standby SUSE HAE-klynge baseret på Pacemaker. Ja, gendannelsestiden er lidt længere end ved replikering, men vi sparer lagerplads med det halve og sparer som følge heraf kundens budget.
- I præproduktionsmiljøer blev HANA-klynger opgivet, men teknisk set blev produktionskonfigurationen gentaget.
- Test- og udviklingsmiljøer blev fordelt på flere servere uden klynger i en MCOS-konfiguration.
- Alle applikationsservere blev virtualiseret og hostet i VMware.
Netværk
- Vi adskilte fysisk konturerne af kontrol- og produktionsnetværk med stakke af switche, og vendte de produktive mod kundens datacentre.
- Vi installerede et tilstrækkeligt antal netværksgrænseflader for ikke at blande store trafikstrømme.
- For at overføre data fra lagersystemer lavede vi klassiske FC SAN-fabrikker.
SHD
- Den produktive og præproduktive belastning af SAP blev efterladt på all-flash-arrayet.
- Udviklertestmiljøer og infrastrukturtjenester blev placeret på et separat hybridarray.
IBS
- Lavet ved hjælp af Veritas Netbackup.
- Vi tilføjede en lille smule til de indbyggede scripts til backup af MCOS-konfigurationer.
- Vi lægger operationelle kopier på en diskhylde for hurtig gendannelse, og vi bruger bånd til langtidslagring.
overvågning
- Al hardware, OS og SAP blev installeret under Zabbix.
- Vi har samlet mange nyttige dashboards i Grafana.
- Når en alarm opstår, kan Zabbix oprette en anmodning i hændelsesstyringssystemet; vi har det implementeret på Jira. Oplysningerne duplikeres også i Telegram-kanalen.
Telegram
Generel sundhed af HANA
SAP Application Server Status:
Infrastrukturtjenester
- For at servicere interne navneområder blev der rejst en klynge af DNS-servere, som er synkroniseret med kundens servere.
- Vi oprettede en separat filserver til dataudveksling.
- For at gemme forskellige konfigurationer blev Gitlab tilføjet.
- For forskellige følsomme oplysninger tog vi HashiCorp Vault.
Migrationsproces
Generelt består migreringsprocessen af følgende faser:
- udarbejdelse af al nødvendig projektdokumentation;
- forhandlinger med den nuværende udbyder - løsning af organisatoriske problemer;
- indkøb, levering og installation af nyt udstyr til projektet;
- test migration og proces debugging;
- systemoverførsel, bekæmpe migration.
I slutningen af oktober 2019 underskrev vi en kontrakt, tegnede derefter arkitekturen, og efter aftale med kunden bestilte vi det nødvendige udstyr.
Det du først skal være opmærksom på er leveringstiden for udstyret. I gennemsnit tager levering af certificeret hardware til SAP NAHA, der opfylder softwareproducentens krav til hardwareplatforme, 10-12 uger. Og under hensyntagen til sæsonudsving (gennemførelsen af projektet faldt nøjagtigt på nytår), kunne denne periode være steget med endnu en måned. Derfor var det nødvendigt at fremskynde processen så meget som muligt: vi arbejdede med distributør-leverandøren og aftalte hurtig levering med fly (i stedet for land- og søveje).
November og december gik med at forberede migreringen og modtage noget af udstyret. Vi udførte forberedelsen på en testbænk i vores offentlige sky, hvor vi gennemarbejdede alle de vigtigste trin og fangede mulige vanskeligheder og problemer:
- udarbejdet en detaljeret plan for interaktion mellem projektteammedlemmer med minut-for-minut timing;
- byggede en testbænk til databasen og applikationsserverne på omtrent samme måde som i målinfrastrukturen;
- konfigureret de nødvendige kommunikationskanaler og infrastrukturtjenester for at teste integrationernes funktion;
- udarbejdede cutover-scenarier;
- Skyen hjalp os også med at skabe forudkonfigurerede virtuelle maskine-skabeloner, som vi derefter blot importerede og implementerede til mållandskabet.
Kort før nytårsferien ankom det første parti udstyr til os. Dette gjorde det muligt at installere nogle systemer på rigtig hardware. Da alt ikke nåede frem, tilsluttede vi erstatningsudstyr, som vi nåede at blive enige med leverandøren og distributørerne om. Vi modtog resterne af målinfrastrukturen i sidste fase.
For at overholde deadline var vores ingeniører nødt til at ofre nytårsferien og begynde arbejdet med at forberede målinfrastrukturen den 2. januar midt i ferien. Ja, dette sker nogle gange, når det brænder, og der simpelthen ikke er andre muligheder. På spil var ydeevnen af de systemer, som virksomhedens levetid afhænger af.
Den generelle migrationsrækkefølge så således ud: først de mindst kritiske systemer (udviklingslandskab, testlandskab), derefter produktive systemer. Den sidste fase af migrationen fandt sted i slutningen af januar og begyndelsen af februar.
Migreringsprocessen var planlagt ned til minuttet. Dette er en skæringsplan med en liste over alle opgaver, gennemførelsestid og ansvarlige personer. Alle trin var allerede udarbejdet i testmigreringen, så i live migreringen var det blot nødvendigt at følge planen og koordinere processen.
Migreringen blev gennemført systematisk i flere faser. Der er to systemer i hver fase.
Resultatet af en tre-måneders sprint var et system, der er fuldt operationelt i CROC-datacentret. Generelt blev der opnået et positivt resultat gennem teamwork; bidraget og dedikationen fra alle deltagere i processen var maksimalt.
Kundens rolle i projektet
Det var ikke let at kommunikere med den udbyder, vores klient forlod. Det er forståeligt, de var de sidste på listen over personer, der var interesserede i den succesfulde gennemførelse af projektet. Kunden påtog sig opgaven med at eskalere og pedalere alle kommunikationsproblemer og klarede dette 100500%. Særlig tak til ham for dette. Uden en sådan gennemførlig deltagelse i processen kunne resultatet af projektet have været helt anderledes.
På grund af formaliseringen af processer på siden af den "tidligere" udbyder blev infrastruktursupport udført af specialister, der bogstaveligt talt var langt fra problemerne, på det tidspunkt stadig deres kunde. For eksempel kan processen med at eksportere den samme database tage fra en time til fem. Så så det ud til, at dette var en slags magi, en hemmelighed, der aldrig blev afsløret for os. Sandsynligvis hengav de tekniske supportingeniører sig til meditation i mellemtiden og glemte, at et sted i det fjerne Rusland er der deadlines, ingeniører uden nytårssalater, kunden græder og lider...
Projektresultater
Det sidste trin i migreringen var overførsel af systemer til vedligeholdelse.
Nu leverer vi en enkelt vinduesservice til kundeønsker og dækker hele omfanget af opgaver relateret til at understøtte infrastrukturkomponenter og SAP-grundlag sammen med vores partner - itelligence. Klienten har boet i en privat sky i seks måneder. Her er statistikken over servicesager i denne tid:
- 90 hændelser (20 % løst uden at involvere kunden)
- Løst indenfor SLA – 100 %
- Uplanlagte systemnedlukninger – 0
Hvis du har problemer, der ligner vores klients, og du vil vide mere om, hvordan du løser dem, så skriv til: [e-mail beskyttet]
Kilde: www.habr.com