🥇Ervaring met het veranderen van SAP-hosting: hoe u systemen kunt migreren zonder dat het ondraaglijk pijnlijk is

Of kan dat wel? Uiteraard is de migratie van SAP-systemen een complex en moeizaam proces, waarbij de coördinatie van alle betrokkenen essentieel is voor het succes ervan. En als de migratie in een kort tijdsbestek wordt uitgevoerd, wordt de taak vele malen ingewikkelder. 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 uitval van het systeem. Of cliënten hebben er geen vertrouwen in dat ze na een dergelijke operatie de voordelen zullen ontvangen die ze nodig hebben. Er zijn echter uitzonderingen.

Hieronder vertellen we over de moeilijkheden die klanten ondervinden bij het migratie- en onderhoudsproces van SAP-systemen. Daarnaast bespreken we waarom stereotypen niet altijd overeenkomen met de werkelijkheid en delen we een casestudy over hoe wij erin slaagden om de systemen van de klant in iets meer dan drie maanden te migreren naar een nieuwe infrastructuur.

Hosting van SAP-systemen

Nog maar vijf jaar geleden was het moeilijk voor te stellen dat klanten massaal gebruik zouden gaan maken van hostingbronnen voor SAP-applicaties. In de meeste gevallen werden ze on-premise geïmplementeerd. Met de ontwikkeling van outsourcingmodellen en de markt voor clouddiensten is de visie van de klant echter veranderd. Wat zijn de argumenten om voor SAP de cloud te kiezen?

Voor beginners die net van plan zijn SAP te implementeren, is cloudinfrastructuur een vrijwel standaardkeuze: schaalbaarheid van de bronnen voor de huidige behoeften van het systeem en geen bereidheid om bronnen te reserveren voor de ontwikkeling van niet-kerncompetenties.
In bedrijven met een groot systeemlandschap gebruiken CIO's SAP-systeemhosting om een kwalitatief nieuw niveau van risicomanagement te bereiken, omdat de partner verantwoordelijk is voor de SLA.
Het derde argument dat het vaakst wordt genoemd, zijn de hoge kosten voor het bouwen van infrastructuur om scenario's met hoge beschikbaarheid en DR te implementeren.
Factor 2027 – De leverancier kondigde aan dat de ondersteuning voor oudere systemen in 2027 stopt. Dit betekent dat de database naar HANA moet worden overgezet, wat kosten met zich meebrengt voor modernisering en de aanschaf van nieuwe rekenkracht.

De SAP-hostingmarkt in Rusland kan nu als behoorlijk volwassen worden beschouwd. Dit biedt volop mogelijkheden voor klanten die van hostingplatform willen veranderen. Toch kunnen dergelijke projecten terecht zorgen oproepen bij bedrijven vanwege de complexiteit van de migratieprocedure. Klanten stellen hierdoor hogere eisen aan dienstverleners: zij moeten niet alleen beschikken over uitzonderlijke expertise op het gebied van het hosten en ondersteunen van SAP-systemen, maar ook over succesvolle ervaring op het gebied van migratie.

Wat zijn de moeilijkheden bij het veranderen van SAP-hosting?

Hostingdiensten variëren. Ze voldoen mogelijk niet aan het aangegeven serviceniveau, kennen talloze "maar's" en voorwaarden met disclaimers in de kleine lettertjes, en beschikken over beperkte middelen en mogelijkheden. hostingproviderOnflexibiliteit in de communicatie met de klant, bureaucratie, technische beperkingen, gebrekkige technische ondersteuning en vele andere nuances – dit zijn slechts enkele valkuilen waar klanten tegenaan kunnen lopen wanneer ze hun bedrijfssystemen in outsourcinginfrastructuren beheren. Vaak blijven deze problemen verborgen voor de klant, weggestopt in een contract van meerdere pagina's, en komen ze pas aan het licht tijdens het daadwerkelijke gebruik van de diensten.

Op een gegeven moment wordt het de klant duidelijk dat het serviceniveau dat hij ontvangt, ver onder zijn verwachtingen ligt. Dit is een soort katalysator voor het vinden van oplossingen om de situatie te corrigeren. Als dat niet lukt, als de problemen zich opstapelen en echt pijnlijk worden, gaan ze over tot actieve actie om alternatieve opties uit te werken om van dienstverlener te veranderen.

Waarom wachten ze tot het laatste moment? De reden is simpel: het proces van het overdragen van systemen is niet altijd transparant en begrijpelijk voor klanten. Voor de klant is het lastig om de daadwerkelijke risico's die aan het migratieproces verbonden zijn, in te schatten. Je zou kunnen zeggen dat migratie voor klanten een soort black box is: de prijs, de downtime van de systemen, de risico's en hoe deze te beperken zijn onduidelijk. Over het algemeen is het donker en angstaanjagend. Als het hier niet lukt, zullen zowel de hoofden van de topmanagers als de uitvoerders rollen.

SAP is een systeem voor grote bedrijven, complex en, om het zachtjes uit te drukken, niet goedkoop. Er worden behoorlijke budgetten uitgegeven aan de implementatie, verfijning en het onderhoud ervan, en de levensvatbaarheid van de onderneming hangt af van de beschikbaarheid en correcte werking ervan. Stel je nu eens voor wat de gevolgen zouden zijn als een belangrijke productie zou worden stopgezet. Het gaat hierbij om financiële verliezen, die in getallen met een groot aantal nullen worden uitgedrukt, maar ook om reputatierisico's en andere even belangrijke risico's.

Laten we eens kijken naar de moeilijkheden die zich in elke fase kunnen voordoen, aan de hand van het voorbeeld van een SAP-systeemmigratie voor een van onze klanten.

Voorbereiding en ontwerp

Migratie is een formule met veel verschillende onderdelen. En een van de belangrijkste fasen is het ontwerpen en voorbereiden van de beoogde (nieuwe) infrastructuur.

We moesten ons verdiepen in de bestaande implementatie van systemen en hun architectuur. In de doelinfrastructuur hebben we op sommige plaatsen bestaande oplossingen overgenomen, op sommige plaatsen aangevuld en verbeterd, en op andere plaatsen opnieuw ontworpen. Daarnaast hebben we oplossingen zorgvuldig geselecteerd om de fouttolerantie en beschikbaarheid te garanderen en alle bronnen zoveel mogelijk geconsolideerd.

Tijdens het ontwerpproces zijn er veel verschillende oefeningen gedaan, waardoor we ons uiteindelijk zo goed mogelijk op de migratie konden voorbereiden en rekening konden houden met allerlei nuances en valkuilen (hier later meer over).

Uiteindelijk kregen we een op maat ontworpen privé-cloudinfrastructuur 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 om de productie en ‘alles anders’ te scheiden;
Een back-upsysteem gebaseerd op Veritas Netbackup met een aparte server, schijfruimte en tapebibliotheek.

En dit is hoe dit alles technisch werd geïmplementeerd.

SAP

Om opslag effectief te kunnen gebruiken voor productieve HANA, gebruikten we gedeelde schijven zonder systeemdatabasereplicatie met behulp van SAP-tools. Dit alles werd verpakt in een Active-Standby cluster van SUSE HAE gebaseerd op Pacemaker. Ja, de hersteltijd is iets langer dan bij replicatie, maar we besparen wel de helft op opslagruimte en dus ook op het budget van de klant.
In pre-productieomgevingen werden HANA-clusters verlaten, maar de productieconfiguratie werd technisch herhaald.
De test- en ontwikkelomgevingen waren verdeeld over meerdere servers zonder clusters in de MCOS-configuratie.
Alle applicatieservers waren gevirtualiseerd en gehost in VMware.

netwerk

We hebben de contouren van de besturings- en productienetwerken fysiek gescheiden door middel van switch stacks, waardoor de productienetwerken zijn gericht op het datacenter van de klant.
We hebben een voldoende aantal netwerkinterfaces voorzien om te voorkomen dat grote verkeersstromen met elkaar vermengd raken.
Om gegevens vanuit het opslagsysteem over te brengen, werden klassieke FC SAN-fabrieken gecreëerd.

SHD

De SAP-productie- en pre-productieworkloads bleven op de all-flash-array staan.
Testomgevingen voor ontwikkelaars en infrastructuurdiensten werden op een aparte hybride array geplaatst.

PDS

Gemaakt op basis van Veritas Netbackup.
We hebben een aantal extra ingebouwde scripts toegevoegd om MCOS-configuraties te back-uppen.
Operationele kopieën bewaren we op een schijfstation voor snel herstel. Voor langdurige opslag gebruiken we tapes.

controle

Alle hardware, besturingssystemen en SAP zijn geconfigureerd voor Zabbix.
We hebben een groot aantal handige dashboards verzameld in Grafana.
Wanneer er een waarschuwing optreedt, kan Zabbix een ticket aanmaken in het incidentmanagementsysteem, dat we in Jira hebben geïmplementeerd. De informatie wordt ook gedupliceerd in het Telegram-kanaal.

Algemene status van HANA

Status van SAP-toepassingsserver:

Infrastructuurdiensten

Om interne naamruimten te bedienen, zetten we een cluster van DNS-servers op die synchroniseren met de servers van de klant.
We hebben een aparte bestandsserver gecreëerd voor gegevensuitwisseling.
Om verschillende configuraties op te slaan, hebben we Gitlab toegevoegd.
Voor diverse gevoelige informatie gebruiken we HashiCorp Vault.

Migratieproces

Over het algemeen bestaat het migratieproces uit de volgende stappen:

voorbereiding van alle benodigde ontwerpdocumentatie;
onderhandelingen met de huidige provider - oplossen van organisatorische problemen;
aankoop, levering en installatie van nieuwe apparatuur voor het project;
testmigratie en procesdebuggen;
systeemoverdracht, gevechtsmigratie.

Eind oktober 2019 hebben we het contract getekend, de architectuur ontworpen en na overleg met de klant de benodigde apparatuur besteld.

Waar u allereerst op moet letten is de levertijd van de apparatuur. Gemiddeld duurt het 10-12 weken voor de levering van gecertificeerde hardware voor SAP NAHA, die voldoet aan de eisen van de softwarefabrikant aan hardwareplatforms. En rekening houdend met de seizoensgebondenheid (de uitvoering van het project viel precies op oudejaarsavond), had deze periode nog met een maand kunnen toenemen. Daarom was het noodzakelijk om het proces zo veel mogelijk te versnellen: we hebben samengewerkt met de distributeur-leverancier en afspraken gemaakt over een versnelde levering per vliegtuig (in plaats van over land en zee).

November en december werden besteed aan de voorbereidingen voor de migratie en de ontvangst van een deel van de apparatuur. We hebben ons voorbereid op een teststand in onze publieke cloud, waar we alle belangrijke stappen hebben doorlopen en mogelijke moeilijkheden en problemen hebben geïdentificeerd:

een gedetailleerd plan opgesteld voor de interactie tussen de leden van het projectteam, met timing op minuutbasis;
een teststand gebouwd voor de database- en applicatieservers, op ongeveer dezelfde manier als in de doelinfrastructuur;
de benodigde communicatiekanalen en infrastructuurdiensten geconfigureerd om de integraties te testen;
uitgewerkte omschakelingsscenario's;
Dankzij de cloud konden we ook vooraf geconfigureerde sjablonen voor virtuele machines maken, die we vervolgens eenvoudig konden importeren en implementeren in het doellandschap.

Kort voor de nieuwjaarsvakantie arriveerde de eerste lading apparatuur bij ons. Hierdoor werd het mogelijk om een aantal systemen op echte hardware te implementeren. Omdat niet iedereen arriveerde, hebben we vervangende apparatuur aangesloten. Over de levering daarvan zijn we het eens geworden met de leverancier en de distributeurs. De restanten van de doelinfrastructuur ontvingen wij reeds in de laatste fase.
Om de deadline te halen, moesten onze technici de nieuwjaarsvakantie opofferen en al op 2 januari, midden in de feestdagen, beginnen met het voorbereiden van de doelinfrastructuur. Ja, dat gebeurt soms als er brand is en er simpelweg geen andere opties zijn. Het ging om de functionaliteit van de systemen waarvan het voortbestaan van de onderneming afhangt.

De algemene volgorde van de migratie zag er als volgt uit: eerst de minst kritische systemen (ontwikkelingslandschap, testlandschap) en daarna productiesystemen. De laatste fase van de migratie vond plaats eind januari, begin februari.

Het migratieproces werd tot op de minuut gepland. Dit is een omschakelingsplan met een lijst van alle taken, doorlooptijden en verantwoordelijke personen. Tijdens de testmigratie waren alle stappen al uitgewerkt, dus bij de productiemigratie was het slechts een kwestie van het plan volgen en het proces op elkaar afstemmen.

De migratie werd systematisch in verschillende fasen uitgevoerd. In elke fase zijn er twee systemen.

Het resultaat van de sprint van drie maanden was een systeem dat volledig operationeel is in het KROK-datacenter. Over het geheel genomen werd het positieve resultaat bereikt dankzij gezamenlijke werkzaamheden; de bijdrage en toewijding van alle deelnemers aan het proces maximaal was.

De rol van de klant in het project

Het was niet eenvoudig om met de provider te communiceren dat onze klant wegging. Dat is begrijpelijk, want zij stonden onderaan de lijst van mensen die belang hadden bij de succesvolle afronding van het project. De klant heeft de taak op zich genomen om alle communicatieproblemen te escaleren en op te lossen en heeft dit voor 100500% opgelost. Speciale dank aan hem hiervoor. Zonder een dergelijke actieve deelname aan het proces had de uitkomst van het project er heel anders uit kunnen zien.

Door de formalisering van processen aan de kant van de ‘voormalige’ provider werd het infrastructuuronderhoud uitgevoerd door specialisten die letterlijk ver verwijderd waren van de problemen die op dat moment nog bij hun klant lagen. Het exporteren van dezelfde database kan bijvoorbeeld één tot vijf uur duren. Toen leek het wel magie, een geheim dat ons nooit werd onthuld. Waarschijnlijk zaten de technische ondersteuningstechnici in de tussentijd wat te mediteren en vergaten ze dat er ergens in het verre Rusland deadlines waren, technici zonder nieuwjaarsalades en de klant huilde en leed...

Projectresultaten

Het slotakkoord van de migratie was de overdracht van de systemen voor onderhoud.

Momenteel bieden we een one-stop-shopservice voor klantverzoeken en dekken we samen met onze partner itelligence het volledige takenpakket af voor de ondersteunende infrastructuurcomponenten en SAP-basis. De klant leeft nu al zes maanden in een privécloud. Hieronder vindt u de statistieken over servicegevallen gedurende deze periode:

90 incidenten (20% opgelost zonder tussenkomst van de klant)
Opgelost binnen SLA - 100%
Ongeplande systeemafsluitingen – 0

Als u soortgelijke taken heeft als die van onze klant en u wilt meer weten over hoe u deze kunt oplossen, schrijf dan naar: ahaidukov@croc.ru

Bron: www.habr.com