Eller är det möjligt? Att migrera SAP-system är naturligtvis en komplex och mödosam process, vars framgång kräver ett välkoordinerat arbete av alla deltagare. Och om migreringen genomförs på kort tid blir uppgiften mycket mer komplicerad. Alla bestämmer sig inte för att göra detta. Det kan finnas flera anledningar. Till exempel är processen i sig lång och organisatoriskt komplex. Dessutom finns det en risk för oplanerad driftstopp. Eller så är kunderna inte säkra på att de, efter att ha genomgått en sådan operation, kommer att få förmåner som står i proportion till de ansträngningar som lagts ned. Det finns dock undantag.
Under snittet kommer vi att prata om de svårigheter som kunder möter i processen att migrera och underhålla SAP-system, diskutera varför stereotyper inte alltid stämmer överens med verkligheten och dela en fallstudie av hur vi lyckades migrera en kunds system till ett ny infrastruktur på drygt tre månader.
SAP-systemhosting
För bara fem år sedan var det svårt att föreställa sig att kunder massivt skulle börja använda värdresurser för SAP-applikationer. I de flesta fall implementerades de på plats. Men med utvecklingen av outsourcingmodeller och molntjänstmarknaden började kundernas världsbild att förändras. Vilka är argumenten som påverkar valet till förmån för molnet för SAP?
- För nybörjare som precis har planerat att implementera SAP är molninfrastruktur nästan ett standardval – skalbarhet av resurser till systemets nuvarande behov och ovilja att avleda resurser till utveckling av icke-kärnkompetenser.
- I företag med ett stort systemlandskap når CIO:er med hjälp av att vara värd för SAP-system en kvalitativt annan nivå av riskhantering, eftersom Partnern ansvarar för SLA.
- Det tredje vanligaste argumentet är den höga kostnaden för att bygga infrastruktur för att implementera scenarier med hög tillgänglighet och DR.
- Faktor 2027 – leverantören tillkännagav slutet på stödet för äldre system 2027. Det innebär att överföra databasen till HANA, vilket medför kostnader för modernisering och inköp av ny datorkraft.
SAP-värdmarknaden i Ryssland kan nu anses vara ganska mogen. Och detta ger stora möjligheter för kunder som vill ändra sina värdplattformar. Sådana projekt kan dock med rätta orsaka oro bland företag på grund av migreringsförfarandets komplexitet. Detta tvingar kunderna att ställa ökade krav på tjänsteleverantörer, som inte bara måste ha exceptionell kompetens i att hosta och underhålla SAP-system, utan också framgångsrik erfarenhet inom migrationsområdet.
Vilka är svårigheterna med att byta SAP-värd?
Hosting är olika. Inkonsekvens med den deklarerade servicenivån, många "men" och asterisker med reservationer i liten text, begränsade resurser och kapacitet hos värdleverantören, bristande flexibilitet i frågor om kommunikation med kunden, byråkrati, tekniska begränsningar, låg kompetens för teknisk support specialister, liksom många andra nyanser - dessa är Detta är bara en liten del av de fallgropar som kunder kan stöta på när de driver sina affärssystem i outsourcing av infrastrukturer. Ofta, för kunden, förblir allt detta i skuggorna, i djungeln av ett flersidigt kontrakt, och dyker upp i processen att använda tjänsterna.
Vid något tillfälle blir det uppenbart för kunden att servicenivån han får är långt ifrån hans förväntningar. Detta är en slags katalysator för att hitta lösningar för att korrigera situationen och, i händelse av misslyckande, när problemen ackumuleras till gränsen och det blir mycket smärtsamt, går de vidare till aktiva åtgärder för att utveckla alternativa alternativ i riktning mot att byta tjänsteleverantör .
Varför väntar de till sista minuten? Anledningen är enkel - processen att migrera system för klienter är inte alltid transparent och begriplig. Det är svårt för klienten att bedöma de faktiska riskerna i samband med migreringsprocessen. Vi kan säga att migration för klienter är en sorts svart låda: det är oklart, priset, systemets driftstopp, risker och hur man kan mildra dem, och i allmänhet är det mörkt och skrämmande. Det är som att om det inte fungerar kommer huvudena att rulla både på toppen och på artisterna.
SAP är ett system på företagsnivå, komplext och milt uttryckt inte billigt. Anständiga budgetar spenderas på implementering, modifiering och underhåll, och företagets livslängd beror på deras tillgänglighet och korrekta drift. Föreställ dig nu konsekvenserna av att stoppa någon stor produktion. Det rör sig om ekonomiska förluster, som kan beräknas i siffror med ett stort antal nollor, samt anseende och andra lika betydande risker.
Vi kommer att analysera de svårigheter som kan uppstå i varje skede vid migrering av SAP-system från en av våra kunder.
Förberedelse och design
Migration är en formel med många olika delar. Och en av de viktigaste är stadiet för att designa och förbereda målinfrastrukturen (ny).
Vi behövde dyka in i den befintliga implementeringen av systemen, deras arkitektur. I målinfrastrukturen upprepade vi existerande lösningar någonstans, kompletterade och förbättrade dem vid vissa tillfällen, gjorde om dem någonstans, genomtänkte och valde lösningar för att säkerställa feltolerans och tillgänglighet, och konsoliderade även alla resurser så mycket som möjligt.
Under designprocessen genomfördes många olika övningar, vilket i slutändan gjorde det möjligt att förbereda så mycket som möjligt för migration och ta hänsyn till alla möjliga nyanser och fallgropar (mer om dem senare).
Det vi slutade med är en individuellt designad privat molninfrastruktur baserad på vårt datacenter:
- dedikerade fysiska servrar för SAP HANA;
- VMware virtualiseringsplattform för applikationsservrar och infrastrukturtjänster;
- duplicerade kommunikationskanaler mellan datacenter för L2 VPN;
- två huvudlagringssystem för att separera produkten och "allt annat";
- SRC baserad på Veritas Netbackup med separat server, diskhylla och bandbibliotek.
Och här är hur vi implementerade allt detta ur teknisk synvinkel.
SAP
- För att effektivt använda lagring för produktiv HANA använde vi delade diskar utan systemisk databasreplikering med SAP. Allt detta var insvept i ett Active-Standby SUSE HAE-kluster baserat på Pacemaker. Ja, återställningstiden är lite längre än med replikering, men vi sparar lagringsutrymme med hälften och som ett resultat sparar vi kundens budget.
- I förproduktionsmiljöer övergavs HANA-kluster, men tekniskt sett upprepades produktionskonfigurationen.
- Test- och utvecklingsmiljöer distribuerades över flera fler servrar utan kluster i en MCOS-konfiguration.
- Alla applikationsservrar virtualiserades och hostades i VMware.
Сети
- Vi separerade fysiskt konturerna av kontroll- och produktionsnätverk med staplar av switchar, och vände de produktiva mot kundens datacenter.
- Vi installerade ett tillräckligt antal nätverksgränssnitt för att inte blanda stora trafikflöden.
- För att överföra data från lagringssystem gjorde vi klassiska FC SAN-fabriker.
SHD
- Den produktiva och preproduktiva belastningen av SAP lämnades kvar på all-flash-matrisen.
- Testmiljöer för utvecklare och infrastrukturtjänster placerades på en separat hybridmatris.
IBS
- Gjord med Veritas Netbackup.
- Vi lade till lite till de inbyggda skripten för att säkerhetskopiera MCOS-konfigurationer.
- Vi lägger operativa kopior på en diskhylla för snabb återställning, och vi använder band för långtidslagring.
övervakning
- All hårdvara, OS och SAP installerades under Zabbix.
- Vi har samlat många användbara instrumentpaneler i Grafana.
- När ett larm inträffar kan Zabbix skapa en begäran i incidenthanteringssystemet, vi har det implementerat i Jira. Informationen dupliceras också i Telegram-kanalen.
Telegram
HANAs allmänna hälsa
SAP Application Server Status:
Infrastrukturtjänster
- För att betjäna interna namnutrymmen skapades ett kluster av DNS-servrar, som är synkroniserat med kundens servrar.
- Vi skapade en separat filserver för datautbyte.
- För att lagra olika konfigurationer lades Gitlab till.
- För olika känslig information tog vi HashiCorp Vault.
Migrationsprocess
I allmänhet består migreringsprocessen av följande steg:
- förberedelse av all nödvändig projektdokumentation;
- förhandlingar med den nuvarande leverantören - lösa organisatoriska frågor;
- köp, leverans och installation av ny utrustning för projektet;
- testmigrering och processfelsökning;
- systemöverföring, bekämpa migration.
I slutet av oktober 2019 skrev vi kontrakt, ritade sedan arkitekturen och efter överenskommelse med kunden beställde vi nödvändig utrustning.
Det du först måste vara uppmärksam på är leveranstiden för utrustningen. I genomsnitt tar leverans av certifierad hårdvara för SAP NAHA som uppfyller mjukvarutillverkarens krav för hårdvaruplattformar 10-12 veckor. Och med hänsyn till säsongsvariationer (genomförandet av projektet föll exakt på nyåret), kunde denna period ha ökat med ytterligare en månad. Följaktligen var det nödvändigt att påskynda processen så mycket som möjligt: vi arbetade med distributören och leverantören och kom överens om snabb leverans med flyg (istället för land- och sjövägar).
November och december gick åt till att förbereda migreringen och ta emot en del av utrustningen. Vi genomförde förberedelserna på en testbänk i vårt offentliga moln, där vi arbetade igenom alla huvudstegen och fångade möjliga svårigheter och problem:
- utarbetat en detaljerad plan för interaktion mellan projektteammedlemmar med timing minut för minut;
- byggde en testbänk för databasen och applikationsservrarna på ungefär samma sätt som i målinfrastrukturen;
- konfigurerat de nödvändiga kommunikationskanalerna och infrastrukturtjänsterna för att testa integrationernas funktion;
- utarbetade cutover-scenarier;
- Molnet hjälpte oss också att skapa förkonfigurerade virtuella maskinmallar, som vi sedan helt enkelt importerade och distribuerade till mållandskapet.
Strax före nyårshelgerna anlände den första satsen utrustning till oss. Detta gjorde det möjligt att distribuera vissa system på riktig hårdvara. Eftersom allt inte kom, kopplade vi in ersättningsutrustning, vars leverans vi lyckades komma överens med leverantören och distributörerna av. Vi tog emot resterna av målinfrastrukturen i slutskedet.
För att hålla tidsfristen var våra ingenjörer tvungna att offra nyårshelgerna och påbörja arbetet med att förbereda målinfrastrukturen den 2 januari, mitt under semestern. Ja, detta händer ibland när det brinner och det helt enkelt inte finns några andra alternativ. På spel var prestandan hos de system som företagets livslängd beror på.
Den allmänna migrationsordningen såg ut så här: först de minst kritiska systemen (utvecklingslandskap, testlandskap), sedan produktiva system. Det sista skedet av migrationen ägde rum i slutet av januari och början av februari.
Migreringsprocessen var planerad till minut. Detta är en övergångsplan med en lista över alla arbetsuppgifter, genomförandetid och ansvariga personer. Alla steg var redan utarbetade i testmigreringen, så i livemigreringen var det bara nödvändigt att följa planen och koordinera processen.
Migrationen genomfördes systematiskt i flera steg. Det finns två system i varje steg.
Resultatet av en tremånaders sprint blev ett system som är fullt i drift i CROCs datacenter. Generellt sett uppnåddes ett positivt resultat genom lagarbete, bidraget och engagemanget från alla deltagare i processen var maximalt.
Kundens roll i projektet
Det var inte lätt att kommunicera med leverantören som vår klient skulle lämna. Detta är förståeligt, de var sist på listan över personer som var intresserade av ett framgångsrikt slutförande av projektet. Kunden tog på sig uppgiften att eskalera och trampa på alla kommunikationsproblem och klarade detta 100500%. Speciellt tack till honom för detta. Utan ett sådant genomförbart deltagande i processen hade resultatet av projektet kunnat bli ett helt annat.
På grund av formaliseringen av processer på sidan av den "tidigare" leverantören, utfördes infrastrukturstöd av specialister som bokstavligen var långt ifrån problemen, på den tiden fortfarande deras kund. Till exempel kan processen att exportera samma databas ta från en timme till fem. Sedan verkade det som att detta var någon sorts magi, en hemlighet som aldrig avslöjades för oss. Förmodligen ägnade de tekniska supportingenjörerna sig åt meditation under tiden och glömde att någonstans i det avlägsna Ryssland finns deadlines, ingenjörer utan nyårssallader, kunden gråter och lider...
Projektresultat
Det sista steget i migreringen var överföringen av system för underhåll.
Nu tillhandahåller vi en enda fönstertjänst för kundförfrågningar och täcker hela omfattningen av uppgifter relaterade till att stödja infrastrukturkomponenter och SAP-bas tillsammans med vår partner - itelligence. Kunden har bott i ett privat moln i sex månader. Här är statistiken över serviceärenden under denna tid:
- 90 incidenter (20 % lösta utan att involvera kunden)
- Löst inom SLA – 100 %
- Oschemalagda systemavstängningar – 0
Om du har problem som liknar vår klients och du vill lära dig mer om hur du löser dem, skriv till: [e-postskyddad]
Källa: will.com