Of is het mogelijk? Uiteraard is het migreren van SAP-systemen een complex en moeizaam proces, waarvan het succes het goed gecoördineerde werk van alle deelnemers vereist. En als de migratie in korte tijd wordt uitgevoerd, wordt de taak veel gecompliceerder. Niet iedereen besluit dit te doen. Er kunnen verschillende redenen zijn. Het proces zelf is bijvoorbeeld langdurig en organisatorisch complex. Bovendien bestaat het risico op ongeplande systeemuitval. Of cliënten zijn er niet zeker van dat zij, nadat ze een dergelijke operatie hebben ondergaan, voordelen zullen ontvangen die evenredig zijn aan de geleverde inspanningen. Er zijn echter uitzonderingen.
Hieronder bespreken we de moeilijkheden waarmee klanten worden geconfronteerd bij het migreren en onderhouden van SAP-systemen, bespreken we waarom stereotypen niet altijd overeenkomen met de werkelijkheid, en delen we een casestudy van hoe we erin zijn geslaagd de systemen van een klant te migreren naar een nieuwe infrastructuur in iets meer dan drie maanden.
Hosting van SAP-systemen
Nog maar vijf jaar geleden was het moeilijk voor te stellen dat klanten massaal hostingbronnen voor SAP-applicaties zouden gaan gebruiken. In de meeste gevallen werden ze on-premise geïmplementeerd. Met de ontwikkeling van outsourcingmodellen en de markt voor clouddiensten begon het wereldbeeld van klanten echter te veranderen. Welke argumenten zijn van invloed op de keuze voor de cloud voor SAP?
- Voor beginners die net van plan zijn SAP te implementeren, is cloudinfrastructuur bijna een standaardkeuze: schaalbaarheid van bronnen voor de huidige behoeften van het systeem en onwil om middelen te besteden aan de ontwikkeling van niet-kerncompetenties.
- In bedrijven met een groot systeemlandschap bereiken CIO's met behulp van het hosten van SAP-systemen een kwalitatief ander niveau van risicobeheer, omdat De partner is verantwoordelijk voor de SLA.
- Het derde meest voorkomende argument zijn de hoge kosten van het bouwen van infrastructuur om hoge beschikbaarheids- en DR-scenario's te implementeren.
- Factor 2027 – de leverancier kondigde het einde aan van de ondersteuning voor oudere systemen in 2027. Dit betekent dat de database wordt overgedragen aan HANA, wat kosten met zich meebrengt voor modernisering en de aanschaf van nieuwe rekenkracht.
De SAP-hostingmarkt in Rusland kan inmiddels als behoorlijk volwassen worden beschouwd. En dit biedt volop mogelijkheden voor klanten die hun hostingplatform willen veranderen. Dergelijke projecten kunnen echter terecht zorgen baren bij bedrijven vanwege de complexiteit van de migratieprocedure. Dit dwingt klanten om hogere eisen te stellen aan dienstverleners, die niet alleen over uitzonderlijke competenties moeten beschikken op het gebied van het hosten en onderhouden van SAP-systemen, maar ook over succesvolle ervaring op het gebied van migratie.
Wat zijn de moeilijkheden bij het veranderen van SAP-hosting?
Hosting is anders. Inconsistentie met het aangegeven serviceniveau, veel ‘maar’ en sterretjes met reserveringen in kleine tekst, beperkte middelen en mogelijkheden van de hostingprovider, gebrek aan flexibiliteit op het gebied van communicatie met de klant, bureaucratie, technische beperkingen, lage competentie van technische ondersteuning specialisten, evenals vele andere nuances - dit is slechts een klein deel van de valkuilen die klanten kunnen tegenkomen bij het exploiteren van hun bedrijfssystemen in outsourcing-infrastructuren. Vaak blijft dit voor de klant in de schaduw, in de jungle van een contract van meerdere pagina's, en komt het naar voren tijdens het gebruik van de diensten.
Op een gegeven moment wordt het voor de klant duidelijk dat het serviceniveau dat hij krijgt ver beneden zijn verwachtingen ligt. Dit is een soort katalysator voor het vinden van oplossingen om de situatie te corrigeren en, in geval van mislukking, wanneer de problemen zich tot het uiterste ophopen en het erg pijnlijk wordt, gaan ze over tot actieve acties om alternatieve opties te ontwikkelen in de richting van het veranderen van de dienstverlener. .
Waarom wachten ze tot het laatste moment? De reden is simpel: het proces van het migreren van systemen voor klanten is niet altijd transparant en begrijpelijk. Voor de opdrachtgever is het lastig om de daadwerkelijke risico’s die aan het migratieproces verbonden zijn, in te schatten. We kunnen zeggen dat migratie voor klanten een soort zwarte doos is: het is onduidelijk wat de prijs, de downtime van het systeem, de risico's zijn en hoe deze kunnen worden beperkt, en in het algemeen is het duister en eng. Het is alsof, als het niet lukt, de koppen gaan rollen, zowel aan de top als bij de artiesten.
SAP is een systeem op bedrijfsniveau, complex en, op zijn zachtst gezegd, niet goedkoop. Er worden behoorlijke budgetten besteed aan de implementatie, aanpassing en onderhoud ervan, en de levensduur van de onderneming hangt af van hun beschikbaarheid en correcte werking. Stel je nu de gevolgen voor van het stopzetten van een grote productie. Dit zijn financiële verliezen, die kunnen worden berekend in cijfers met een groot aantal nullen, maar ook reputatierisico's en andere, even grote risico's.
We zullen de moeilijkheden analyseren die zich in elke fase kunnen voordoen bij de migratie van SAP-systemen van een van onze klanten.
Voorbereiding en ontwerp
Migratie is een formule met veel verschillende onderdelen. En een van de belangrijkste is de fase van het ontwerpen en voorbereiden van de beoogde (nieuwe) infrastructuur.
We moesten in de bestaande implementatie van de systemen en hun architectuur duiken. In de doelinfrastructuur hebben we ergens bestaande oplossingen herhaald, op sommige punten aangevuld en verbeterd, ergens opnieuw gedaan, oplossingen doordacht en geselecteerd om fouttolerantie en beschikbaarheid te garanderen, en ook alle middelen zoveel mogelijk geconsolideerd.
Tijdens het ontwerpproces zijn veel verschillende oefeningen uitgevoerd, waardoor het uiteindelijk mogelijk is geworden om zoveel mogelijk voor te bereiden op de migratie en rekening te houden met allerlei nuances en valkuilen (daarover later meer).
Wat we uiteindelijk hebben bereikt is een individueel ontworpen private cloud-infrastructuur op basis van ons datacenter:
- speciale fysieke servers voor SAP HANA;
- VMware-virtualisatieplatform voor applicatieservers en infrastructuurdiensten;
- dubbele communicatiekanalen tussen datacenters voor L2 VPN;
- twee hoofdopslagsystemen voor het scheiden van het product en “al het andere”;
- SRC gebaseerd op Veritas Netbackup met een aparte server, schijfplank en tapebibliotheek.
En hier ziet u hoe we dit allemaal vanuit technisch oogpunt hebben geïmplementeerd.
SAP
- Om opslag effectief te gebruiken voor productieve HANA, hebben we gedeelde schijven gebruikt zonder systemische databasereplicatie met behulp van SAP. Dit alles was verpakt in een Active-Standby SUSE HAE-cluster op basis van Pacemaker. Ja, de hersteltijd is iets langer dan bij replicatie, maar we besparen de helft van de opslagruimte en besparen daardoor het budget van de klant.
- In pre-productieomgevingen werden HANA-clusters verlaten, maar technisch gezien werd de productieconfiguratie herhaald.
- Test- en ontwikkelomgevingen werden verdeeld over meerdere servers zonder clusters in een MCOS-configuratie.
- Alle applicatieservers zijn gevirtualiseerd en gehost in VMware.
netwerk
- We hebben de contouren van de besturings- en productienetwerken fysiek gescheiden met stapels schakelaars, waardoor de productieve naar de datacenters van de klant zijn gedraaid.
- We hebben voldoende netwerkinterfaces geïnstalleerd om grote verkeersstromen niet te vermengen.
- Om gegevens uit opslagsystemen over te dragen, hebben we klassieke FC SAN-fabrieken gemaakt.
SHD
- De productieve en preproductieve belasting van SAP werd op de all-flash-array gelaten.
- Testomgevingen voor ontwikkelaars en infrastructuurdiensten werden op een aparte hybride array geplaatst.
PDS
- Gemaakt met Veritas Netbackup.
- We hebben een klein beetje toegevoegd aan de ingebouwde scripts om een back-up te maken van MCOS-configuraties.
- We plaatsen operationele kopieën op een schijfplank voor snel herstel, en we gebruiken tapes voor langdurige opslag.
controle
- Alle hardware, besturingssysteem en SAP zijn geïnstalleerd onder Zabbix.
- We hebben veel nuttige dashboards verzameld in Grafana.
- Wanneer er een alert optreedt, kan Zabbix een verzoek aanmaken in het incidentmanagementsysteem; wij implementeren dit in Jira. De informatie wordt ook gedupliceerd in het Telegram-kanaal.
Telegram
Algemene gezondheid van HANA
Status SAP-toepassingsserver:
Infrastructuurdiensten
- Om interne naamruimten te bedienen, is een cluster van DNS-servers opgericht, die worden gesynchroniseerd met de servers van de klant.
- Voor gegevensuitwisseling hebben we een aparte bestandsserver gemaakt.
- Om verschillende configuraties op te slaan, is Gitlab toegevoegd.
- Voor verschillende gevoelige informatie hebben we HashiCorp Vault gebruikt.
Migratie proces
Over het algemeen bestaat het migratieproces uit de volgende fasen:
- voorbereiding van alle benodigde projectdocumentatie;
- onderhandelingen met de huidige aanbieder - het oplossen van organisatorische vraagstukken;
- aankoop, levering en installatie van nieuwe apparatuur voor het project;
- testmigratie en procesfoutopsporing;
- systeemoverdracht, bestrijding van migratie.
Eind oktober 2019 tekenden we een contract, ontwierpen vervolgens de architectuur en bestelden na overeenstemming met de klant de benodigde apparatuur.
Waar u allereerst op moet letten, is de levertijd van de apparatuur. Gemiddeld duurt de levering van gecertificeerde hardware voor SAP NAHA die voldoet aan de eisen van de softwarefabrikant voor hardwareplatforms 10-12 weken. En rekening houdend met de seizoensinvloeden (de implementatie van het project viel precies op het nieuwe jaar), had deze periode met nog een maand kunnen toenemen. Daarom was het noodzakelijk om het proces zoveel mogelijk te versnellen: we werkten samen met de distributeur-leverancier en kwamen een versnelde levering per vliegtuig overeen (in plaats van land- en zeeroutes).
November en december werden besteed aan de voorbereiding van de migratie en het ontvangen van een deel van de uitrusting. We hebben de voorbereiding uitgevoerd op een testbank in onze publieke cloud, waar we alle belangrijke stappen hebben doorlopen en mogelijke moeilijkheden en problemen hebben opgespoord:
- een gedetailleerd plan opgesteld voor de interactie tussen projectteamleden met een timing van minuut tot minuut;
- bouwde een testbank voor de database- en applicatieservers op ongeveer dezelfde manier als in de doelinfrastructuur;
- de nodige communicatiekanalen en infrastructuurdiensten geconfigureerd om de werking van de integraties te testen;
- uitgewerkte cutover-scenario's;
- De cloud hielp ons ook bij het maken van vooraf geconfigureerde sjablonen voor virtuele machines, die we vervolgens eenvoudigweg importeerden en in het doellandschap implementeerden.
Kort voor de nieuwjaarsvakantie arriveerde de eerste partij apparatuur bij ons. Dit maakte het mogelijk om sommige systemen op echte hardware te implementeren. Omdat niet alles arriveerde, hebben we vervangende apparatuur aangesloten, waarvan we de levering met de leverancier en distributeurs hebben kunnen afstemmen. In de laatste fase hebben we de overblijfselen van de doelinfrastructuur ontvangen.
Om de deadline te halen, moesten onze ingenieurs de nieuwjaarsvakantie opofferen en op 2 januari, midden in de vakantie, beginnen met het voorbereiden van de doelinfrastructuur. Ja, dit gebeurt soms als het in brand staat en er simpelweg geen andere opties zijn. Op het spel stonden de prestaties van de systemen waarvan het leven van de onderneming afhangt.
De algemene volgorde van migratie zag er als volgt uit: eerst de minst kritische systemen (ontwikkelingslandschap, testlandschap), daarna productieve systemen. De laatste fase van de migratie vond eind januari en begin februari plaats.
Het migratieproces was tot op de minuut gepland. Dit is een overstapplan met een lijst van alle taken, doorlooptijd en verantwoordelijke personen. Bij de testmigratie waren alle stappen al uitgewerkt, dus bij de livemigratie was het alleen nodig om het plan te volgen en het proces te coördineren.
De migratie werd systematisch in verschillende fasen uitgevoerd. Er zijn twee systemen in elke fase.
Het resultaat van een sprint van drie maanden was een systeem dat volledig operationeel is in het CROC-datacenter. Over het algemeen werd door teamwerk een positief resultaat behaald; de bijdrage en toewijding van alle deelnemers aan het proces was maximaal.
De rol van de klant in het project
Communiceren met de aanbieder waar onze klant wegging was niet eenvoudig. Dit is begrijpelijk; zij waren de laatsten op de lijst van mensen die geïnteresseerd waren in de succesvolle afronding van het project. De klant nam de taak op zich om alle communicatieproblemen te escaleren en op te lossen en loste dit voor 100500% op. Speciale dank aan hem hiervoor. Zonder een dergelijke haalbare deelname aan het proces had het resultaat van het project compleet anders kunnen zijn.
Door de formalisering van processen aan de kant van de ‘voormalige’ aanbieder werd de infrastructuurondersteuning uitgevoerd door specialisten die letterlijk ver van de problemen stonden, destijds nog hun klant. Het proces voor het exporteren van dezelfde database kan bijvoorbeeld een uur tot vijf duren. Toen leek het erop dat dit een soort magie was, een geheim dat nooit aan ons werd onthuld. Waarschijnlijk hebben de technische ondersteuningsingenieurs zich ondertussen overgegeven aan meditatie, vergetend dat ergens in het verre Rusland deadlines zijn, ingenieurs zonder nieuwjaarssalades, de klant huilt en lijdt...
Projectresultaten
De laatste stap van de migratie was de overdracht van systemen voor onderhoud.
Nu bieden we één loketservice voor klantverzoeken en dekken we samen met onze partner itelligence het volledige takenpakket met betrekking tot de ondersteunende infrastructuurcomponenten en SAP-basis af. De klant leeft al zes maanden in een private cloud. Hier zijn de statistieken over servicegevallen gedurende deze periode:
- 90 incidenten (20% opgelost zonder tussenkomst van de klant)
- Opgelost binnen SLA – 100%
- Ongeplande systeemuitschakelingen – 0
Als u problemen heeft die vergelijkbaar zijn met die van onze klant, en u wilt meer weten over hoe u deze kunt oplossen, schrijf dan naar: [e-mail beveiligd]
Bron: www.habr.com