Eller er det mulig? Selvfølgelig er migrering av SAP-systemer en kompleks og møysommelig prosess, hvis suksess krever godt koordinert arbeid fra alle deltakerne. Og hvis migreringen gjennomføres på kort tid, blir oppgaven mye mer komplisert. Ikke alle bestemmer seg for å gjøre dette. Det kan være flere årsaker. For eksempel er selve prosessen langvarig og organisatorisk kompleks. I tillegg er det en risiko for uplanlagt nedetid. Eller klienter er ikke sikre på at de, etter å ha gjennomgått en slik operasjon, vil motta fordeler som står i forhold til innsatsen som er brukt. Det finnes imidlertid unntak.
Under snittet skal vi snakke om vanskelighetene som kunder møter i prosessen med å migrere og vedlikeholde SAP-systemer, diskutere hvorfor stereotypier ikke alltid samsvarer med virkeligheten, og dele en casestudie av hvordan vi klarte å migrere en kundes systemer til en ny infrastruktur på drøyt tre måneder.
SAP systemer hosting
For bare fem år siden var det vanskelig å forestille seg at klienter massivt ville begynne å bruke vertsressurser for SAP-applikasjoner. I de fleste tilfeller ble de implementert på stedet. Men med utviklingen av outsourcing-modeller og skytjenestemarkedet begynte kundenes verdensbilde å endre seg. Hva er argumentene som påvirker valget til fordel for skyen for SAP?
- For nybegynnere som nettopp har planlagt å implementere SAP, er skyinfrastruktur nærmest et standardvalg – skalerbarhet av ressurser til dagens behov i systemet og motvilje mot å avlede ressurser til utvikling av ikke-kjernekompetanse.
- I selskaper med et stort systemlandskap, ved hjelp av hosting av SAP-systemer, når CIOer et kvalitativt annet nivå av risikostyring, fordi Partneren er ansvarlig for SLA.
- Det tredje vanligste argumentet er de høye kostnadene ved å bygge infrastruktur for å implementere høy tilgjengelighet og DR-scenarier.
- Faktor 2027 - leverandøren kunngjorde slutten på støtten for eldre systemer i 2027. Det betyr overføring av databasen til HANA, noe som medfører kostnader til modernisering og innkjøp av ny datakraft.
SAP-vertsmarkedet i Russland kan nå betraktes som ganske modent. Og dette gir gode muligheter for kunder som ønsker å endre sine hosting-plattformer. Imidlertid kan slike prosjekter med rette skape bekymring blant bedrifter på grunn av kompleksiteten til migrasjonsprosedyren. Dette tvinger kundene til å stille økte krav til tjenesteleverandører, som ikke bare må ha eksepsjonell kompetanse innen hosting og vedlikehold av SAP-systemer, men også vellykket erfaring innen migrering.
Hva er vanskelighetene med å endre SAP-hosting?
Hosting er forskjellige. Inkonsistens med det deklarerte servicenivået, mange "men" og stjerner med forbehold i liten tekst, begrensede ressurser og muligheter til vertsleverandøren, mangel på fleksibilitet i spørsmål om kommunikasjon med klienten, byråkrati, tekniske begrensninger, lav kompetanse for teknisk støtte spesialister, så vel som mange andre nyanser - disse er Dette er bare en liten del av fallgruvene som klienter kan møte når de opererer sine forretningssystemer i outsourcing av infrastruktur. Ofte, for klienten, forblir alt dette i skyggen, i jungelen av en flersidig kontrakt, og dukker opp i prosessen med å bruke tjenestene.
På et tidspunkt blir det åpenbart for kunden at servicenivået han får er langt unna forventningene. Dette er en slags katalysator for å finne løsninger for å rette opp situasjonen, og i tilfelle feil, når problemene samler seg til grensen og det blir veldig smertefullt, går de videre til aktive handlinger for å utvikle alternative alternativer i retning av å endre tjenesteleverandøren .
Hvorfor venter de til siste øyeblikk? Årsaken er enkel - prosessen med å migrere systemer for klienter er ikke alltid gjennomsiktig og forståelig. Det er vanskelig for klienten å vurdere de faktiske risikoene knyttet til migrasjonsprosessen. Vi kan si at migrering for klienter er en slags svart boks: det er uklart, prisen, systemets nedetid, risikoer og hvordan de skal reduseres, og generelt er det mørkt og skummelt. Det er som om det ikke fungerer, vil hodene rulle både på toppen og på utøverne.
SAP er et system på bedriftsnivå, komplekst og mildt sagt ikke billig. Anstendige budsjetter brukes på implementering, modifikasjon og vedlikehold, og bedriftens levetid avhenger av tilgjengelighet og korrekt drift. Tenk deg nå konsekvensene av å stoppe en viss stor produksjon. Dette er økonomiske tap, som kan beregnes i tall med et stort antall nuller, samt omdømme og andre like betydelige risikoer.
Vi vil analysere vanskelighetene som kan oppstå på hvert trinn i tilfelle migrering av SAP-systemer fra en av våre kunder.
Forberedelse og design
Migrasjon er en formel med mange forskjellige deler. Og en av de viktigste er stadiet med å designe og forberede målinfrastrukturen (ny).
Vi trengte å dykke ned i den eksisterende implementeringen av systemene, deres arkitektur. I målinfrastrukturen gjentok vi eksisterende løsninger et sted, supplerte og forbedret dem på noen punkter, gjorde dem om et sted, tenkte gjennom og valgte løsninger for å sikre feiltoleranse og tilgjengelighet, og også konsoliderte alle ressurser så mye som mulig.
Under designprosessen ble det utført mange forskjellige øvelser, som til slutt gjorde det mulig å forberede seg mest mulig på migrasjon og ta hensyn til alle slags nyanser og fallgruver (mer om dem senere).
Det vi endte opp med er en individuelt designet privat skyinfrastruktur basert på datasenteret vårt:
- dedikerte fysiske servere for SAP HANA;
- VMware virtualiseringsplattform for applikasjonsservere og infrastrukturtjenester;
- dupliserte kommunikasjonskanaler mellom datasentre for L2 VPN;
- to hovedlagringssystemer for å skille produktet og "alt annet";
- SRC basert på Veritas Netbackup med egen server, diskhylle og båndbibliotek.
Og her er hvordan vi implementerte alt dette fra et teknisk synspunkt.
SAP
- For å effektivt bruke lagring for produktiv HANA, brukte vi delte disker uten systemisk databasereplikering ved bruk av SAP. Alt dette ble pakket inn i en Active-Standby SUSE HAE-klynge basert på Pacemaker. Ja, gjenopprettingstiden er litt lengre enn ved replikering, men vi sparer lagringsplass med halvparten og sparer dermed kundens budsjett.
- I pre-produksjonsmiljøer ble HANA-klynger forlatt, men teknisk sett ble produksjonskonfigurasjonen gjentatt.
- Test- og utviklingsmiljøer ble distribuert over flere servere uten klynger i en MCOS-konfigurasjon.
- Alle applikasjonsservere ble virtualisert og hostet i VMware.
Сети
- Vi skilte fysisk konturene av kontroll- og produksjonsnettverk med stabler av brytere, og vendte de produktive mot kundens datasentre.
- Vi installerte et tilstrekkelig antall nettverksgrensesnitt for ikke å blande store trafikkstrømmer.
- For å overføre data fra lagringssystemer laget vi klassiske FC SAN-fabrikker.
SHD
- Den produktive og preproduktive belastningen av SAP ble igjen på all-flash-arrayet.
- Utviklertestmiljøer og infrastrukturtjenester ble plassert på en egen hybrid array.
IBS
- Laget ved hjelp av Veritas Netbackup.
- Vi har lagt til litt til de innebygde skriptene for å sikkerhetskopiere MCOS-konfigurasjoner.
- Vi legger operative kopier på en diskhylle for rask gjenoppretting, og vi bruker bånd for langtidslagring.
overvåking
- All maskinvare, OS og SAP ble installert under Zabbix.
- Vi har samlet mange nyttige dashboards i Grafana.
- Når et varsel oppstår, kan Zabbix opprette en forespørsel i hendelsesstyringssystemet; vi implementerer det i Jira. Informasjonen dupliseres også i Telegram-kanalen.
Telegram
Generell helse til HANA
SAP Application Server Status:
Infrastrukturtjenester
- For å betjene interne navneområder ble det opprettet en klynge med DNS-servere, som er synkronisert med kundens servere.
- Vi opprettet en egen filserver for datautveksling.
- For å lagre ulike konfigurasjoner ble Gitlab lagt til.
- For forskjellig sensitiv informasjon tok vi HashiCorp Vault.
Migrasjonsprosess
Generelt består migrasjonsprosessen av følgende stadier:
- utarbeidelse av all nødvendig prosjektdokumentasjon;
- forhandlinger med gjeldende leverandør - løse organisatoriske problemer;
- kjøp, levering og installasjon av nytt utstyr til prosjektet;
- testmigrering og prosessfeilsøking;
- systemoverføring, bekjempe migrasjon.
I slutten av oktober 2019 signerte vi kontrakt, tegnet deretter arkitekturen, og etter avtale med kunden bestilte vi nødvendig utstyr.
Det du først må være oppmerksom på er leveringstiden på utstyret. I gjennomsnitt tar levering av sertifisert maskinvare for SAP NAHA som oppfyller programvareprodusentens krav til maskinvareplattformer 10-12 uker. Og tatt i betraktning sesongvariasjoner (gjennomføringen av prosjektet falt nøyaktig på nyttår), kunne denne perioden ha økt med ytterligere en måned. Følgelig var det nødvendig å fremskynde prosessen så mye som mulig: vi jobbet med distributør-leverandøren og ble enige om fremskyndet levering med fly (i stedet for land- og sjøveier).
November og desember gikk med til å forberede migreringen og motta noe av utstyret. Vi utførte forberedelsene på en testbenk i vår offentlige sky, hvor vi jobbet gjennom alle hovedtrinnene og fanget opp mulige vanskeligheter og problemer:
- utarbeidet en detaljert plan for samhandling mellom prosjektteammedlemmer med minutt-for-minutt timing;
- bygget en testbenk for databasen og applikasjonsserverne på omtrent samme måte som i målinfrastrukturen;
- konfigurert nødvendige kommunikasjonskanaler og infrastrukturtjenester for å teste driften av integrasjonene;
- utarbeidet cutover-scenarier;
- Skyen hjalp oss også med å lage forhåndskonfigurerte virtuelle maskinmaler, som vi så enkelt importerte og distribuerte til mållandskapet.
Rett før nyttårsferien kom det første partiet med utstyr til oss. Dette gjorde det mulig å distribuere noen systemer på ekte maskinvare. Siden ikke alt kom, koblet vi til erstatningsutstyr, som vi klarte å avtale med leverandøren og distributørene om. Vi mottok restene av målinfrastrukturen i sluttfasen.
For å overholde fristen måtte ingeniørene våre ofre nyttårsferien og begynne arbeidet med å klargjøre målinfrastrukturen 2. januar, midt i ferien. Ja, dette skjer noen ganger når det brenner og det rett og slett ikke er andre alternativer. På spill var ytelsen til systemene som bedriftens levetid avhenger av.
Den generelle migrasjonsrekkefølgen så slik ut: først de minst kritiske systemene (utviklingslandskap, testlandskap), deretter produktive systemer. Den siste fasen av migrasjonen fant sted i slutten av januar og begynnelsen av februar.
Migrasjonsprosessen var planlagt ned til minuttet. Dette er en cutover-plan med liste over alle oppgaver, gjennomføringstid og ansvarlige personer. Alle trinnene var allerede utarbeidet i testmigreringen, så i livemigreringen var det bare nødvendig å følge planen og koordinere prosessen.
Migreringen ble gjennomført systematisk i flere trinn. Det er to systemer i hvert trinn.
Resultatet av en tre måneders sprint var et system som er fullt operativt i CROC-datasenteret. Generelt ble et positivt resultat oppnådd gjennom teamarbeid, bidraget og engasjementet fra alle deltakerne i prosessen var maksimalt.
Kundens rolle i prosjektet
Det var ikke lett å kommunisere med leverandøren vår klient forlot. Dette er forståelig; de var sist på listen over personer som var interessert i en vellykket gjennomføring av prosjektet. Kunden tok på seg oppgaven med å eskalere og pedalere alle kommunikasjonsproblemer og taklet dette 100500%. Spesiell takk til ham for dette. Uten en slik gjennomførbar deltakelse i prosessen kunne resultatet av prosjektet blitt et helt annet.
På grunn av formaliseringen av prosessene på siden av den "tidligere" leverandøren, ble infrastrukturstøtte utført av spesialister som bokstavelig talt var langt fra problemene, på den tiden fortsatt deres kunde. For eksempel kan prosessen med å eksportere den samme databasen ta fra en time til fem. Da virket det som om dette var en slags magi, en hemmelighet som aldri ble avslørt for oss. Sannsynligvis henga de tekniske støtteingeniørene seg til meditasjon i mellomtiden, og glemte at et sted i det fjerne Russland er det tidsfrister, ingeniører uten nyttårssalater, kunden gråter og lider...
Prosjektresultater
Det siste trinnet i migreringen var overføring av systemer for vedlikehold.
Nå tilbyr vi en enkelt vindu-tjeneste for kundeforespørsler og dekker hele omfanget av oppgaver knyttet til støtte for infrastrukturkomponenter og SAP-grunnlag sammen med vår partner - itelligence. Klienten har bodd i en privat sky i seks måneder. Her er statistikken over tjenestesaker i denne tiden:
- 90 hendelser (20 % løst uten å involvere kunden)
- Løst innenfor SLA – 100 %
- Uplanlagte systemavslutninger – 0
Hvis du har problemer som ligner på våre kunder, og du ønsker å lære mer om hvordan du løser dem, skriv til: [e-postbeskyttet]
Kilde: www.habr.com