🥇Erfarenheter av att byta SAP-hosting: hur man migrerar system utan att det gör ont

Eller kan man? Självklart, migration av SAP-system är en komplex och noggrann process, där en samordnad insats från alla deltagare är avgörande för framgång. När migrationen dessutom måste ske på kort tid, blir uppgiften betydligt mer utmanande. Inte alla vågar sig på det. Det kan finnas flera skäl till detta. Till exempel är processen lång och organisatoriskt komplicerad. Dessutom finns det risk för oplanerade driftstopp. Eller så är kunder osäkra på att de, efter att ha genomgått en sådan operation, får fördelar som står i proportion till de ansträngningar som lagts ned. Men det finns undantag.

Under inlägget kommer vi att berätta om de svårigheter som beställare möter under migration och support av SAP-system, diskutera varför stereotyper inte alltid överensstämmer med verkligheten, och dela med oss av ett fall där vi lyckades migrera kundens system till en ny infrastruktur på drygt tre månader.

Hosting av SAP-system

För bara fem år sedan var det svårt att föreställa sig att kunder skulle börja använda hostingresurser för SAP-applikationer i stor skala. I de flesta fall implementerades de på plats. Men med utvecklingen av outsourcing-modeller och molntjänstmarknaden har kundernas synsätt börjat förändras. Vad är argumenten som påverkar valet av molnet för SAP?

För nybörjare som just har planerat att implementera SAP är en molninfrastruktur praktiskt taget standardval – skalbarhet av resurser efter systemets aktuella behov och en ovilja att avleda resurser till att utveckla icke-nyckelkompetenser.
I företag med stora systemlandskap når CIO:er med hjälp av hosting av SAP-system en helt ny nivå av riskhantering, eftersom partnern ansvarar för SLA.
Det tredje av de vanligaste argumenten är den höga kostnaden för att bygga upp en infrastruktur för att genomföra hög tillgänglighet och DR-scenarier.
Faktor 2027 – den av leverantören tillkännagivna upphörandet av stöd för föråldrade system år 2027. Detta innebär en övergång av databasen till HANA, vilket medför kostnader för modernisering och inköp av ny datorkapacitet.

Marknaden för SAP-hosting i Sverige kan idag betraktas som ganska mogen. Detta erbjuder stora möjligheter för kunder som vill byta sina hostingplattformar. Men sådana projekt kan fullt förståeligt väcka oro inom företagen på grund av komplexiteten i migrationsprocessen. Detta tvingar beställarna att ställa högre krav på tjänsteleverantörerna, som måste ha inte bara exceptionella kompetenser inom hosting och support av SAP-system utan också en framgångsrik erfarenhet inom migrationsområdet.

Vad innebär svårigheterna med att byta SAP-hosting?

Det finns olika typer av hosting. Bristande överensstämmelse med den angivna servicenivån, många "men" och stjärnor med förbehåll i liten text, begränsade resurser och möjligheter hostingleverantör, brist på flexibilitet i kommunikationen med kunden, byråkrati, tekniska begränsningar, låg kompetens hos teknisk support samt många andra nyanser — detta är bara en liten del av de fallgropar som kunder kan stöta på i processen att använda sina affärssystem i outsourcade infrastrukturer. Ofta förblir allt detta i skuggan av ett flersidigt avtal och kommer fram först i användningen av tjänsterna.

Vid något tillfälle blir det uppenbart för beställaren att servicenivån de får är långt ifrån förväntningarna. Detta fungerar som en katalysator för att söka lösningar för att rätta till situationen, och om detta misslyckas, när problemen samlas till en gräns där det blir riktigt smärtsamt, går de över till aktiva åtgärder för att utforska alternativ för att byta tjänsteleverantör.

Varför drar man ut på det in i det sista? Orsaken är enkel — processen att flytta system för kunder är inte alltid transparent och förståelig. Det är svårt för kunden att bedöma de faktiska riskerna kopplade till migrationsprocessen. Man kan säga att migration för kunder är en sorts svart låda: det är oklart vad kostnaden är, hur länge systemen kommer att vara nere, vilka risker som finns och hur man kan mildra dem, och överhuvudtaget är det mörkt och skrämmande. Här är saken den att om det inte lyckas, kommer huvuden att rulla både bland beslutsfattarna och utövarna.

SAP är komplexa företagsnivåsystem som, mildt sagt, inte är billiga. Betydande budgetar används för deras implementering, anpassning och support, och företagets överlevnad beror på deras tillgänglighet och korrekta funktion. Tänk nu på konsekvenserna av att stoppa en stor produktion. Det handlar om ekonomiska förluster som kan räknas i siffror med många nollor, samt rykte och andra, minst lika viktiga risker.

Låt oss analysera de svårigheter som kan uppstå i varje steg av migreringsprocessen för SAP-system hos en av våra kunder.

Förberedelse och design

Migration är en formel med många olika komponenter. En av de viktigaste delarna är design- och förberedelsesteget för den nya infrastrukturen.

Vi behövde dyka ner i den befintliga systemimplementeringen och deras arkitektur. I den nya infrastrukturen upprepade vi på vissa ställen befintliga lösningar, kompletterade och förbättrade i andra aspekter, och i vissa fall omarbetade vi, tänkte igenom och valde lösningar för att säkerställa redundans och tillgänglighet, samt maximalt konsoliderade alla resurser.

Under designprocessen genomfördes många olika övningar som till slut gjorde att vi var maximalt förberedda för migreringen och kunde ta hänsyn till alla möjliga detaljer och fällor (mer om detta senare).

Vad vi åstadkom är en individuellt designad privat molninfrastruktur baserad på vårt datacenter:

dedikerade fysiska servrar för SAP HANA;
virtualiseringsplattform VMware för applikationsservrar och infrastrukturtjänster;
duplicerade kommunikationskanaler mellan datacentren för L2; VPN;
två huvudlagringssystem för att separera produktivitet och "allt annat";
backuplösningar baserade på Veritas Netbackup med en separat server, diskhylla och bandbibliotek.

Här är hur vi tekniskt genomförde allt detta.

SAP

För effektiv användning av lagring för produktiv HANA använde vi delade diskar utan systematisk databassynkronisering via SAP. Allt detta integrerades i ett Active-Standby kluster av SUSE HAE byggt på Pacemaker. Ja, återställningstiden är något längre än med synkronisering, men vi sparar lagringsutrymme med hälften och därmed även kundens budget.
I förproduktionsmiljöer avstod man från HANA-kluster men upprepade tekniskt produktionskonfigurationen.
Testmiljöer och utvecklingsmiljöer spriddes över flera servrar utan kluster i MCOS-konfiguration.
Alla applikationsservrar virtualiserades och placerades i VMware.

Nätverk

Fysiskt separerade vi kontrollnätverken från produktionsnätverken med switchstackar, och riktade produktionsnätverken mot kundens datacenter.
Tillräckligt många nätverksgränssnitt installerades för att undvika blandning av stora trafikkällor.
För dataöverföring från lagringssystemet skapades klassiska FC SAN-fabriker.

Lagring

Produktions- och förproduktionsbelastningen för SAP lämnades på all-flash-array.
Utvecklarnas testmiljöer och infrastrukturservicetjänster placerades på en separat hybrid-beräkningslagring.

SRK

Skapades med hjälp av Veritas Netbackup.
Vi har lagt till några inbyggda skript för att säkerhetskopiera MCOS-konfigurationer.
Operativa kopior lagrades på diskhyllan för snabb återställning, och vi använder band för långsiktig lagring.

Övervakning

All hårdvara, operativsystem och SAP har implementerats under Zabbix.
Vi har samlat många användbara instrumentpaneler i Grafana.
Vid en Zabbix-alert kan systemet skapa ärenden i incidenthanteringssystemet, och vi använder Jira för det. Informationen dupliceras också i en Telegram-kanal.

Allmänt tillstånd för HANA

Status för SAP-applikationsservern:

Infrastrukturservicetjänster

För att stödja interna domännamn upprättades en DNS-serverkluster som synkroniseras med kundens servrar.
En separat filserver skapades för datautbyte.
För att lagra olika konfigurationer lades Gitlab till.
För känslig information använde vi HashiCorp Vault.

Migrationsprocessen

I allmänhet består migrationsprocessen av följande steg:

Förbereda all nödvändig projektdokumentation;
Förhandlingar med nuvarande leverantör - lösa organisatoriska frågor;
Inköp, leverans och installation av ny utrustning för projektet;
Testmigrering och justering av processen;
Flytt av system, produktiv migrering.

I slutet av oktober 2019 undertecknade vi kontrakt, därefter designade vi arkitekturen, och efter att den godkänts av kunden beställde vi nödvändig utrustning.

Det första att tänka på är leveranstiderna för utrustningen. I genomsnitt tar leveransen av certifierad hårdvara för SAP NAHA, som uppfyller programvaruleverantörens krav på hårdvaruplattformar, 10-12 veckor. Med hänsyn till säsongsvariationer (projektets genomförande krockade med nyår) kunde denna tidsram förlängas med ytterligare en månad. Därför var det nödvändigt att snabba på processen: vi arbetade med distributören-leverantören och förhandlade om snabbare frakt med flyg (istället för land- och sjövägar).

November och december ägnades åt att förbereda migreringen och ta emot delar av utrustningen. Förberedelserna genomfördes på en testplattform i vår offentliga moln, där vi arbetade igenom alla grundläggande steg och fångade eventuella svårigheter och problem:

vi förberedde en detaljerad plan för interaktionen mellan projektteamens deltagare med minut-timingar;
vi byggde en testplattform för databaser och applikationsservrar ungefär som i den målinriktade infrastrukturen;
vi konfigurerade nödvändiga kommunikationskanaler och infrastrukturservicetjänster för att kontrollera integrationsarbetet;
vi arbetade igenom cutover-scenarier;
molnet hjälpte oss också att skapa förkonfigurerade mallar för virtuella maskiner, som vi senare enkelt importerade och distribuerade i den målinriktade miljön.

Strax före nyårshelgerna anlände den första partiet av utrustning till oss. Detta gjorde det möjligt att distribuera delar av systemen på riktig hårdvara. Eftersom inte allt hade anlänt, kopplade vi in ersättningsutrustning, vars leverans vi lyckades förhandla fram med leverantörer och distributörer. Resterna av den målinriktade infrastrukturen fick vi först i det slutliga skedet.
För att hålla tidsramen fick våra ingenjörer offra nyårshelgerna och börja förberedelsen av den målinriktade infrastrukturen den 2 januari, mitt under helgfirandet. Ja, sådant händer ibland när det brinner och det inte finns några andra alternativ. I spel stod systemen som är avgörande för företagets verksamhet.

Den övergripande migrationsordningen såg ut så här: först de minst kritiska systemen (utvecklingslandskapet, testlandskapet), sedan de produktiva systemen. Den sista migrationsfasen genomfördes i slutet av januari-början av februari.

Migrationsprocessen var detaljerad ner till minut. Det här är en cutover-plan med en lista över alla uppgifter, genomförandetider och ansvariga personer. Alla steg hade redan övats under testmigreringen, så i den riktiga migreringen behövde vi bara följa planen och samordna processen.

Migreringen genomfördes systematiskt i flera steg. I varje steg ingick två system.

Resultatet av tre månaders sprint blev ett system som fungerar helt inom KROK:s datacenter. Generellt sett uppnåddes detta positiva resultat tack vare det gemensamma arbetet, där alla involverade bidrog maximalt.

Beställarens roll i projektet

Det var inte lätt att kommunicera med leverantören som vår kund lämnat. Förståeligt, de var de sista på listan av dem som var intresserade av projektets framgång. Beställaren tog på sig uppgifterna att eskalera och driva alla kommunikationsfrågor och lyckades med det till 100500%. Ett stort tack för det. Utan ett sådant engagemang i processen skulle resultatet av projektet kunna ha varit helt annorlunda.

På grund av formaliteten i processerna på den "tidigare" leverantörens sida hanterades infrastrukturen av specialister som bokstavligt talat var avskärmade från problemen hos deras kund vid den tiden. Till exempel kunde processen att exportera samma databas ta mellan en och fem timmar. Då verkade det som om det var någon form av magi, ett hemligt recept som vi aldrig fick ta del av. Ingenjörer från teknisk support kanske ägnade sig åt meditation och glömde att det i avlägsna Ryssland fanns deadlines, ingenjörer utan nyårsdelikatesser, och beställaren gråter och lider …

Projektets resultat

Det sista steget i migreringen var överlämnandet av systemen för support.

Nu tillhandahåller vi en servicepunkt för beställarens förfrågningar och hanterar hela omfattningen av uppgifter för support av infrastrukturkomponenterna och SAP-basis tillsammans med vår partner – itelligence. Klienten har varit verksam i ett privat moln i sex månader. Här är statistiken över servicefallen under denna tid: