🥇 Erfaring med skift af SAP-hosting: hvordan man migrerer systemer uden det bliver en smertefuld oplevelse

Eller kan man? Selvfølgelig er migration af SAP-systemer en kompleks og omhyggelig proces, hvor det er vigtigt med et velfungerende samarbejde mellem alle deltagere. Og hvis migrationen skal finde sted inden for stramme deadlines, bliver opgaven mange gange mere kompliceret. Ikke alle tør tage springet. Der kan være flere grunde til dette. For eksempel er selve processen lang og organisatorisk kompleks. Derudover er der risiko for uplanlagte systemnedetider. Eller kunderne er ikke sikre på, at de efter en sådan operation vil opnå fordele, der står i forhold til de kræfter, der investeres. Men der er også undtagelser.

Under overskriften vil vi tale om de vanskeligheder, som kunderne oplever under migrationen og vedligeholdelsen af SAP-systemerne, diskutere, hvorfor stereotyper ikke altid svarer til virkeligheden, og dele en case om, hvordan vi fik migreret kundens systemer til den nye infrastruktur på bare lidt over tre måneder.

Hosting af SAP-systemer

For kun fem år siden var det svært at forestille sig, at kunderne massivt ville begynde at bruge hostingressourcer til SAP-applikationer. I de fleste tilfælde blev de implementeret on-premise. Men med udviklingen af outsourcingmodeller og markedet for cloud-tjenester begyndte kundernes synspunkter at ændre sig. Hvad er argumenterne, der påvirker valget af cloud til SAP?

For nybegyndere, der netop har planlagt implementeringen af SAP, er cloud-infrastruktur næsten et standardvalg - skalerbarhed af ressourcer under systemets nuværende behov og uvilje til at aflede ressourcer til udvikling af ikke-kernekompetencer.
I virksomheder med et stort systemlandskab kan CIO'erne med hjælp fra hosting af SAP-systemer nå et kvalitativt nyt niveau af risikostyring, da partneren bærer ansvaret for SLA.
Den tredje af de mest almindelige argumenter er de høje omkostninger ved at opbygge en infrastruktur til at implementere scenarier for høj tilgængelighed og DR.
Faktor 2027 – den annoncerede ophør af understøttelsen af forældede systemer fra leverandøren i 2027. Dette indebærer en overgang af databaser til HANA, hvilket medfører omkostninger til modernisering og anskaffelse af ny computing-kapacitet.

Markedet for SAP-hosting i Danmark kan nu betragtes som tilstrækkeligt modent. Dette giver mange muligheder for kunder, der ønsker at skifte deres hostingplatforme. Dog kan sådanne projekter med rette vække bekymringer hos virksomheder på grund af kompleksiteten ved migrationsproceduren. Dette får kunderne til at stille højere krav til tjenesteudbydere, som skal have ikke kun fremragende kompetencer inden for hosting og support af SAP-systemer, men også en vellykket erfaring inden for migration.

Hvad er udfordringerne ved at skifte SAP-hosting?

Der findes forskellige hostingløsninger. Uoverensstemmelser mellem det lovede serviceniveau, mange "men" og stjerner med forbehold i småttryk, begrænsning af ressourcer og muligheder, hostingudbyder, manglende fleksibilitet i kommunikationen med kunden, bureaukrati, tekniske begrænsninger, lav kompetence blandt teknisk support samt mange andre nuancer — dette er blot en lille del af de faldgruber, kunder kan støde på, mens de bruger deres forretningssystemer i outsourcing-infrastrukturer. Ofte forbliver alt dette skjult i dybden af en fler-sidet kontrakt og dukker først op i brugen af tjenesteydelserne.

På et tidspunkt bliver det klart for kunden, at serviceniveauet, de modtager, er langt fra deres forventninger. Dette fungerer som en katalysator for at finde løsninger på situationen, og hvis det ikke lykkes, når problemerne hober sig op til bristepunktet, går de i gang med aktivt at overveje alternative muligheder i retning af et skift af tjenesteudbyder.

Hvorfor vente til sidste øjeblik? Årsagen er enkel — processen med at flytte systemer er ikke altid gennemsigtig og forståelig for kunden. Det er svært for kunden at vurdere de reelle risici forbundet med migrationsprocessen. Man kan sige, at migration for kunder er en form for sort boks: uklart, omkostninger, systemernes nedetid, risici og hvordan man kan minimere dem, og det hele er i det hele taget skræmmende. For hvis det ikke lykkes, vil hovederne rulle både hos ledelsen og blandt de udførende.

SAP er virksomhedsniveau systemer, komplekse og mildt sagt ikke billige. Der bruges betydelige budgetter til deres implementering, udvikling og support, og virksomhedens drift afhænger af deres tilgængelighed og korrekte funktion. Forestil dig nu konsekvenserne af at stoppe produktionen på en større fabrik. Det er økonomiske tab, der kan tælles i tal med mange nuller samt omdømme og andre, lige så betydningsfulde risici.

Lad os se på de udfordringer, der kan opstå på hvert trin via et case study om migrationen af SAP-systemer for en af vores kunder.

Forberedelse og projektering

Migration er en formel med mange forskellige komponenter. Og en af de vigtigste er projekt- og forberedelsesfasen af den nye (mål) infrastruktur.

Vi var nødt til at dykke ned i den eksisterende implementering af systemerne, deres arkitektur. I den målrettede infrastruktur genskabte vi nogle af de eksisterende løsninger, supplerede og forbedrede visse elementer, redesignede nogle, overvejede og valgte løsninger for sikring af fejltolerance og tilgængelighed, samt konsoliderede alle ressourcer så meget som muligt.

I designprocessen blev der udført mange forskellige øvelser, som i sidste ende gjorde det muligt at være maksimalt forberedt til migrationen og tage højde for alle nuancer og faldgruber (som vi senere vil se nærmere på).

Hvad vi endte med var en individuelt designet infrastruktur for et privat sky baseret på vores datacenter:

dedikerede fysiske servere til SAP HANA;
virtualiseringsplatform VMware til applikationsservere og infrastruktur services;
duplicerede kommunikationskanaler mellem datacentre for L2 VPN;
to primære SAN'er til at adskille produktivitet og 'alt det andet';
backup-løsning baseret på Veritas Netbackup med en dedikeret server, diskarray og båndbibliotek.

Og sådan implementerede vi det hele fra et teknisk perspektiv.

SAP

For effektivt at bruge lagre til produktiv HANA brugte vi delte diske uden systemisk database-replikation ved hjælp af SAP. Alt dette blev sat op i et Active-Standby cluster SUSE HAE baseret på Pacemaker. Ja, genopretningstiden er lidt længere end med replikation, men vi opnår en pladsbesparelse i SAN med det dobbelte og dermed en økonomisk besparelse for kunden.
I preproduktionsmiljøer blev der givet afkald på HANA-klustre, men konfigurationen blev teknisk replikeret i produktionsmiljøet.
Testmiljøer og udviklingsmiljøer blev fordelt over flere servere uden klustre i MCOS-konfigurationen.
Alle applikationsservere blev virtualiseret og placeret i VMware.

Netværk

Fysiske konturer for administrationsnetværk og produktionsnetværk blev adskilt af switch-stakke, mens produktionsnetværket blev rettet mod kundens datacenter.
Der blev sikret tilstrækkeligt med netværksgrænseflader for ikke at blande store trafikstrømme.
For datatransmission fra SAN-lagringssystemet blev der anvendt klassiske FC SAN-fabrikker.

SAN

Den produktive og preproduktive SAP-belastning blev forladt på en all-flash lagringsenhed.
Udviklernes testmiljøer og infrastrukturen tjenester blev placeret på en separat hybrid lagringsenhed.

SRK

Baseret på Veritas Netbackup.
Vi tilføjede lidt til de indbyggede scripts for at lave backup af MCOS-konfigurationerne.
Hurtige sikkerhedskopier blev placeret på en diskhylde for at kunne gendanne hurtigt, mens vi bruger bånd til langtidsopbevaring.

Overvågning

Alt hardware, OS og SAP blev sat op under Zabbix.
Vi har samlet mange nyttige dashboards i Grafana.
Når der opstår en alarm, kan Zabbix åbne en ticket i incidentsystemet, som vi har implementeret i Jira. Oplysningerne duplikeres også i en Telegram-kanal.

Generel tilstand af HANA

Status for SAP-applikationsserveren:

Infrastruktur tjenester

For at supportere interne navnerum oprettede vi et cluster af DNS-servere, som synkroniseres med kundens servere.
Vi lavede en separat filserver til dataudveksling.
For at gemme forskellige konfigurationer tilføjede vi Gitlab.
Til følsomme oplysninger anvendte vi HashiCorp Vault.

Migrationsproces

Generelt består migrationsprocessen af følgende faser:

forberedelse af al nødvendig projektdokumentation;
forhandlinger med den nuværende udbyder — løsning af organisatoriske spørgsmål;
indkøb, levering og installation af nyt udstyr til projektet;
testmigration og justering af processen;
overførsel af systemer, produktionsmigration.

I slutningen af oktober 2019 underskrev vi kontrakten, hvorefter vi designede arkitekturen, og efter godkendelse fra kunden bestilte vi det nødvendige udstyr.

Det første, man skal være opmærksom på, er leveringstiden for udstyr. I gennemsnit tager levering af certificeret hardware under SAP NAHA, som opfylder softwareproducentens krav til hardwareplatforme, 10-12 uger. Og når man tager sæsonbestemtheden i betragtning (projektets implementering faldt præcist sammen med nytår) kunne denne tid forlænges med endnu en måned. Derfor var det nødvendigt at fremskynde processen: vi arbejdede sammen med distributøren, og vi indgik en aftale om accelereret levering med fly (i stedet for land- og søtransport).

November og december blev brugt på at forberede migrationen og modtage en del af udstyret. Forberedelsen blev udført på en teststand i vores offentlige cloud, hvor vi arbejdede med alle de vigtigste trin og identificerede mulige udfordringer og problemer:

udarbejdede en detaljeret plan for interaktionen mellem deltagerne i projektteamene med minut-til-minut tidsplaner;
opbyggede en teststand for databaser og applikationsservere på samme måde som i det målrettede infrastruktur;
indlejrede de nødvendige kommunikationskanaler og infrastrukturtjenester for at teste integrationsfunktionaliteten;
arbejdede med cutover-scenarier;
cloudet hjalp os også med at danne forudkonfigurerede skabeloner til virtuelle maskiner, som vi efterfølgende blot importerede og udsendte i det endelige landskab.

Lige før nytår ankom den første levering af udstyr til os. Dette gjorde det muligt at implementere en del af systemerne på det faktiske hardware. Da ikke alt var ankommet, tilsluttede vi udskiftningseudstyr, som vi havde formået at aftale med leverandøren og distributørerne. Resten af den målrettede infrastruktur modtog vi først i den afsluttende fase.
For at nå tidsfristen måtte vores ingeniører give afkald på nytårsferien og begynde arbejdet med forberedelsen af den målrettede infrastruktur den 2. januar, midt under festlighederne. Ja, sådanne situationer opstår sommetider, når tidsfristerne er stramme, og der ikke er andre muligheder. Systemernes funktionalitet, som virksomhedens drift afhænger af, var på spil.

Den samlede migrationsproces så således ud: først de mindst kritiske systemer (udviklingslandskabet, testlandskabet), derefter de produktive systemer. Den afsluttende migrationsfase fandt sted i slutningen af januar-begyndelsen af februar.

Migreringsprocessen var detaljeret ned til minut. Dette er en cutover-plan med en liste over alle opgaver, udførelsestid og ansvarlige personer. Alle trin var allerede blevet fuldført på en testmigration, så i den rigtige migration skulle man blot følge planen og koordinere processen.

Migrationen blev udført systematisk i flere trin. Hver fase havde to systemer.

Resultatet af den tre måneders sprint blev et system, der fungerer fuldt ud i KROK Data Center. Generelt er det positive resultat opnået takket være det fælles arbejde, hvor alle deltageres bidrag og engagement var maksimalt.

Kundens rolle i projektet

Det var ikke let at kommunikere med udbyderen, som vores klient forlod. Det er forståeligt, de var de sidste på listen over personer, der var interesseret i en succesfuld afslutning af projektet. Kunden tog ansvar for at eskalere og håndtere alle kommunikationsspørgsmål og klarede det til perfektion. For dette skylder vi dem en særlig tak. Uden en sådan aktiv deltagelse i processen kunne projektets resultat have været helt anderledes.

På grund af formaliserede processer hos den 'tidligere' udbyder blev infrastrukturen håndteret af specialister, der bogstaveligt talt var fjerne fra problemerne, der på det tidspunkt stadig var kundens. For eksempel kunne eksportprocessen af den samme database tage fra en til fem timer. Dengang virkede det som en form for magi, hemmeligheden blev aldrig afsløret for os. Ingeniørerne i teknisk support kunne have givet sig hen til meditation og glemt, at deadlines, ingeniører uden nytårssalater, og en grædende og lidende kunde, var en realitet et sted i det fjerne Rusland...

Projektets resultater

Den endelige fase af migrationen var overdragelsen af systemer til support.

Nu tilbyder vi en one-stop service for kundens henvendelser og håndterer alle opgaver relateret til support af infrastrukturkomponenter og SAP basis sammen med vores partner – itelligence. Klienten har været i et privat cloud i seks måneder. Her er statistikken for servicehændelser i denne periode: