Delen via

Migratie van SAP HANA op Azure Large Instance naar virtuele Azure-machines

  • Artikel

In dit artikel worden mogelijke implementatiescenario's voor Azure Large Instance beschreven en worden plannings- en migratiebenaderingen geboden met minimale downtime van overgangen.

Overzicht

Azure Large Instances for SAP HANA (HLI) werd voor het eerst aangekondigd in september 2016. Sindsdien hebben velen deze hardware als een service gebruikt voor hun in-memory rekenplatform. De uitbreiding van de grootte van de virtuele Azure-machine (VM) en de ondersteuning van de uitschaalimplementatie van HANA heeft de meeste enterprise-klanten de erp-databasecapaciteitsvraag overschreden. Velen zijn geïnteresseerd in het migreren van hun SAP HANA-workload van fysieke servers naar Azure-VM's.

Dit artikel is geen stapsgewijs configuratiedocument. Hierin worden de algemene implementatiemodellen beschreven en worden plannings- en migratieadvies geboden. Onze bedoeling is om noodzakelijke overwegingen voor de voorbereiding op te roepen om de downtime van de overgang te minimaliseren.

Aannames

In dit artikel wordt uitgegaan van het volgende:

  • We overwegen alleen een homogene migratie van de HANA-database-rekenservice van Hana Large Instance (HLI) naar Azure VM zonder aanzienlijke software-upgrade of patching. Deze secundaire updates omvatten het gebruik van een recentere besturingssysteemversie (OS) of HANA-versie die expliciet wordt vermeld als ondersteund door relevante SAP-notities.
  • U voert alle activiteiten voor updates/upgrades uit vóór of na de migratie. Sap HANA MCOS wordt bijvoorbeeld geconverteerd naar MDC-implementatie.
  • De migratiebenadering die de minste downtime biedt, is SAP HANA-systeemreplicatie. Andere migratiemethoden maken geen deel uit van het bereik van dit document.
  • Deze richtlijnen zijn van toepassing op zowel Rev3- als Rev4-SKU's van HLI.
  • De HANA-implementatiearchitectuur blijft voornamelijk ongewijzigd tijdens de migratie. Dat wil gezegd: een systeem met herstel na noodgevallen van één exemplaar blijft hetzelfde op de bestemming.
  • U hebt de SLA (Service Level Agreement) van de doelarchitectuur (to-be) beoordeeld en begrepen.
  • Commerciële termen tussen HLI's en VM's verschillen. Bewaak het gebruik van uw VM's voor kostenbeheer.
  • U begrijpt dat HLI een toegewezen rekenplatform is terwijl VM's worden uitgevoerd op een gedeelde maar geïsoleerde infrastructuur.
  • U hebt gevalideerd dat doel-VM's uw beoogde architectuur ondersteunen. Zie de SAP HANA-hardwaremap voor een lijst met ondersteunde VM-SKU's die zijn gecertificeerd voor SAP HANA-implementatie.
  • U hebt het ontwerp- en migratieplan gevalideerd.
  • Plan een VM voor herstel na noodgevallen samen met de primaire site. U kunt de HLI niet gebruiken als het DR-knooppunt voor de primaire site die wordt uitgevoerd op VM's na de migratie.
  • U hebt de vereiste back-upbestanden gekopieerd naar vm's, op basis van bedrijfsherstel- en nalevingsvereisten. Met toegankelijke back-ups van vm's is herstel naar een bepaald tijdstip mogelijk tijdens de overgangsperiode.
  • Voor hoge beschikbaarheid van SAP HANA-systeemreplicatie (HSR) moet u het afschermingsapparaat instellen en configureren volgens SAP HANA HA-handleidingen voor SLES en RHEL. Het is niet vooraf geconfigureerd zoals de HLI-case.
  • Deze migratiebenadering heeft geen betrekking op de HLI-SKU's met de Optane-configuratie.

Implementatiescenario's

U kunt migreren naar Azure-VM's voor alle HLI-scenario's. Algemene implementatiemodellen voor HLI worden samengevat in de volgende tabel. Als u wilt profiteren van aanvullende Azure-services, moet u mogelijk kleine architectuurwijzigingen aanbrengen.

Scenario-id HLI-scenario Migreer naar de exacte bewoordingen van de VIRTUELE machine? Opmerking
1 Eén knooppunt met één SID Ja -
2 Eén knooppunt met meerdere onderdelen in één systeem (MCOS) Ja -
3 Eén knooppunt met DR met opslagreplicatie Nee Opslagreplicatie is niet beschikbaar met een virtueel Azure-platform; wijzig de huidige DR-oplossing in HSR of back-up/herstel.
4 Eén knooppunt met DR (multipurpose) met opslagreplicatie Nee Opslagreplicatie is niet beschikbaar met een virtueel Azure-platform; wijzig de huidige DR-oplossing in HSR of back-up/herstel.
5 HSR met fencing voor hoge beschikbaarheid Ja Geen vooraf geconfigureerde SBD voor doel-VM's. Selecteer en implementeer een fencing-oplossing. Mogelijke opties: Azure Fencing Agent (ondersteund voor zowel RHEL, SLES als SBD.
6 Hoge beschikbaarheid met HSR, DR met opslagreplicatie Nee Vervang opslagreplicatie voor noodherstelbehoeften door HSR of back-up/herstel.
7 Automatische failover van host (1+1) Ja Gebruik Azure NetApp Files (ANF) voor gedeelde opslag met Azure-VM's.
8 Uitschalen met stand-by Ja BW/4HANA met M128s, M416s, M416ms-VM's die alleen ANF gebruiken voor opslag.
9 Uitschalen zonder stand-by Ja BW/4HANA met M128s, M416s, M416ms-VM's (met of zonder ANF voor opslag).
10 Uitschalen met herstel na noodgeval met behulp van opslagreplicatie Nee Vervang opslagreplicatie voor noodherstelbehoeften door HSR of back-up/herstel.
11 Eén knooppunt met DR met behulp van HSR Ja -
12 HSR met één knooppunt naar herstel na noodgeval (geoptimaliseerd voor kosten) Ja -
13 Hoge beschikbaarheid en dr met HSR Ja -
14 Hoge beschikbaarheid en herstel na noodgevallen met HSR (geoptimaliseerd voor kosten) Ja -
15 Uitschalen met DR met behulp van HSR Ja BW/4HANA met M128s. M416s, M416ms VM's (met of zonder ANF voor opslag).

Bronplanning (HLI)

Tijdens het onboarden van uw HLI-server hebben u en Microsoft Service Management de planning doorlopen van de reken-, netwerk-, opslag- en besturingssysteemspecifieke instellingen voor het uitvoeren van de SAP HANA-database. Er moet een vergelijkbare planning plaatsvinden voor de migratie naar azure-VM.

SAP HANA-huishouding

Het is een goede operationele procedure om de database-inhoud op te schonen, zodat ongewenste, verouderde gegevens of verouderde logboeken niet naar de nieuwe database worden gemigreerd. Huishouding omvat over het algemeen het verwijderen of archiveren van oude, verlopen of inactieve gegevens. Deze 'gegevens hygiëne' moet worden getest in niet-productiesystemen om de geldigheid van de gegevens te valideren voordat het productiegebruik wordt gebruikt.

Netwerkconnectiviteit toestaan voor nieuwe VM's en virtueel netwerk

In uw HLI-implementatie is het netwerk ingesteld op basis van de informatie die wordt beschreven in het artikel SAP HANA -netwerkarchitectuur (Large Instances). Netwerkverkeersroutering wordt ook uitgevoerd op de manier die wordt beschreven in de sectie Routering in Azure.

  • Is het nieuwe VM-migratiedoel in het bestaande virtuele netwerk geplaatst met IP-adresbereiken die al zijn toegestaan om verbinding te maken met de HLI? Vervolgens is er geen verdere connectiviteitsupdate vereist.
  • Wordt de nieuwe Virtuele Azure-machine in een nieuw Microsoft Azure Virtual Network geplaatst, mogelijk in een andere regio en gekoppeld aan het bestaande virtuele netwerk? Vervolgens kunt u de ExpressRoute-servicesleutel en resource-id van de oorspronkelijke HLI-inrichting gebruiken om toegang te verlenen tot dit nieuwe IP-bereik voor virtuele netwerken. Coördinaat met Microsoft Service Management om het virtuele netwerk in te schakelen voor HLI-connectiviteit.

    Notitie

    Om de netwerklatentie tussen de toepassings- en databaselagen te minimaliseren, moeten zowel de toepassings- als databaselagen zich in hetzelfde virtuele netwerk bevinden.

Bestaande beschikbaarheidsset voor app-lagen, beschikbaarheidszones en nabijheidsplaatsingsgroep (PPG)

We hebben het huidige implementatiemodel ontworpen om te voldoen aan bepaalde doelstellingen op serviceniveau. Zorg er in deze stap voor dat de doelinfrastructuur voldoet aan uw gestelde doelen of overschrijdt.
Waarschijnlijker dan niet, worden uw SAP-toepassingsservers in een beschikbaarheidsset geplaatst. Als het huidige niveau van de implementatieservice voldoende is en als de doel-VM ervan uitgaat dat de hostnaam van de logische HLI-naam wordt gebruikt, werkt het bijwerken van de DNS-adresomzetting (Domain Name Service) die verwijst naar het IP-adres van de VIRTUELE machine zonder SAP-profielen bij te werken.

Stopzetting van opslagreplicatie (indien gebruikt)

Als u opslagreplicatie hebt gebruikt als noodhersteloplossing, beëindigt u deze nadat de SAP-toepassing is afgesloten. Voordat u dit doet, moet u ervoor zorgen dat de laatste SAP HANA-catalogus, logboekbestand en gegevensback-ups worden gerepliceerd naar de externe DR HLI-opslagvolumes. Deze replicatie is belangrijk voor het geval er een noodgeval optreedt tijdens de overgang van de fysieke server naar de Azure-VM.

Opslag van gegevensback-ups

Na de overgang naar SAP HANA op uw Azure-VM zijn de op momentopnamen gebaseerde gegevens en logboekback-ups op de HLI niet eenvoudig toegankelijk of herstelbaar voor een VIRTUELE machine. We raden u aan om back-ups en momentopnamen op bestandsniveau op de HLI te maken, zelfs weken voordat de cut-over is. Laat deze back-ups worden gekopieerd naar een Azure Storage-account dat toegankelijk is voor de nieuwe SAP HANA-VM. In de vroege overgangsperiode, voordat de op Azure gebaseerde back-up voldoende geschiedenis bouwt om te voldoen aan de vereisten voor herstel naar een bepaald tijdstip, moet u back-ups op bestandsniveau maken.

Het maken van een back-up van de HLI-inhoud is essentieel. Het is ook verstandig om volledige back-ups van het SAP-landschap direct toegankelijk te maken voor het geval er een terugdraaiactie nodig is.

Systeembewaking aanpassen

U kunt veel verschillende hulpprogramma's gebruiken voor het bewaken en verzenden van waarschuwingsmeldingen voor systemen in uw SAP-landschap. Vergeet niet om de juiste actie te ondernemen om wijzigingen op te nemen voor het bewaken en bijwerken van de geadresseerden van de waarschuwingsmeldingen, indien nodig.

Betrokkenheid van Microsoft Operations-team

Open een ticket vanuit Azure Portal op basis van het bestaande HLI-exemplaar. Nadat het ondersteuningsticket is gemaakt, neemt een ondersteuningstechnicus contact met u op via e-mail.

Contact opnemen met het Microsoft-accountteam

Plan de migratie dicht bij de verlengingstijd van het HLI-contract om onnodige kosten voor de rekenresource te minimaliseren. Om de HLI uit bedrijf te nemen, coördineert u de beëindiging van het contract en sluit u de eenheid af.

Doelplanning

Zorgvuldige planning is essentieel bij het implementeren van een nieuwe infrastructuur om een bestaande infrastructuur te implementeren. Zorg ervoor dat de nieuwe toevoeging voldoet aan uw behoeften in het grotere schema van zaken. Hier volgen enkele belangrijke punten die u moet overwegen.

Beschikbaarheid van resources in de doelregio

De implementatieregio van de huidige SAP-toepassingsservers bevindt zich doorgaans dicht bij de bijbehorende HLI's. HLI's worden echter op minder locaties aangeboden dan beschikbare Azure-regio's. Wanneer u de fysieke HLI migreert naar een Azure-VM, is het ook een goed moment om de nabijheidsafstand van alle gerelateerde services voor prestatieoptimalisatie af te stemmen. Zorg ervoor dat de gekozen regio alle vereiste resources heeft. U kunt bijvoorbeeld controleren op de beschikbaarheid van een bepaalde VM-familie of de Azure-zones die installatie met hoge beschikbaarheid bieden.

Virtueel netwerk

Wilt u de nieuwe HANA-database uitvoeren in een bestaand virtueel netwerk of een nieuwe maken? De belangrijkste beslissingsfactor is de huidige netwerkindeling voor het SAP-landschap. Wanneer de infrastructuur van de implementatie van één zone naar twee zones gaat en PPG gebruikt, wordt er ook architectuurwijziging opgelegd. Zie het artikel Azure PPG voor optimale netwerklatentie met SAP-toepassing voor meer informatie.

Beveiliging

Of de nieuwe SAP HANA-VM wordt uitgevoerd op een nieuw of bestaand vnet/subnet, het is een nieuwe service die essentieel is voor uw bedrijf. Het verdient bescherming. Zorg ervoor dat toegangsbeheer voldoet aan het beveiligingsbeleid van uw bedrijf.

Aanbeveling voor vm-grootte

Deze migratie biedt ook de mogelijkheid om uw HANA-berekeningsengine op de juiste grootte te wijzigen. U kunt HANA-systeemweergaven gebruiken met HANA Studio om inzicht te hebben in het verbruik van systeemresources, waardoor de juiste grootte kan worden gebruikt om de bestedingsefficiëntie te verhogen.

Storage

Opslagprestaties zijn een van de factoren die van invloed zijn op de gebruikerservaring van uw SAP-toepassing. Er zijn minimale opslagindelingen gepubliceerd voor bepaalde VM-SKU's. Zie opslagconfiguraties voor virtuele AZURE-machines in SAP HANA voor meer informatie. We raden u aan deze specificaties te bekijken en te vergelijken met uw bestaande HLI-systeemstatistieken om voldoende IO-capaciteit en prestaties voor uw nieuwe HANA-VM te garanderen.

Configureert u PPG voor de nieuwe HANA-VM en de bijbehorende servers? Dien vervolgens een ondersteuningsticket in om de co-locatie van de opslag en de VIRTUELE machine te controleren en te controleren. Omdat uw back-upoplossing mogelijk moet veranderen, moet u ook de opslagkosten opnieuw bekijken om operationele uitgaven te voorkomen.

Opslagreplicatie voor herstel na noodgevallen

Met HLI was opslagreplicatie de standaardoptie voor herstel na noodgevallen. Deze functie is niet de standaardoptie voor SAP HANA op Azure VM. Overweeg HSR, back-up/herstel of andere ondersteunde oplossingen die voldoen aan de behoeften van uw bedrijf.

Beschikbaarheidssets, beschikbaarheidszones en nabijheidsplaatsingsgroepen

U kunt de afstand tussen de toepassingslaag en SAP HANA verkorten om de netwerklatentie minimaal te behouden. Plaats de nieuwe database-VM en de huidige SAP-toepassingsservers in een PPG. Zie Nabijheidsplaatsingsgroep voor meer informatie over hoe Azure-beschikbaarheidssets en beschikbaarheidszones werken met PPG voor SAP-implementaties.

Als leden van uw HANA-systeem zijn geïmplementeerd in meer dan één Azure-zone, moet u rekening houden met het latentieprofiel van de gekozen zones. Plaats SAP-systeemonderdelen om de afstand tussen de SAP-toepassing en de database te verminderen. Het testhulpprogramma voor de latentietest voor de beschikbaarheidszone van het openbare domein helpt de meting te vereenvoudigen.

Back-upstrategie

Veel van onze klanten maken al gebruik van back-upoplossingen van derden voor SAP HANA op HLI. Als u dat wel bent, moeten alleen beveiligde VM- en HANA-databases worden geconfigureerd. Lopende HLI-back-uptaken kunnen niet worden gepland als de machine na de migratie buiten gebruik wordt gesteld.

Azure Backup voor SAP HANA op VM is nu algemeen beschikbaar. Zie Back-up, herstel en beheer voor meer informatie over SAP HANA-back-ups in Azure-VM's.

DR-strategie

Als uw serviceniveaudoelen een langere hersteltijd bieden, kan het eenvoudig zijn om back-ups te maken. Een back-up naar blobopslag en herstel ter plaatse of herstel naar een nieuwe VIRTUELE machine is de eenvoudigste en minst dure DR-strategie.

Op het platform voor grote instanties wordt HANA DR meestal uitgevoerd met HSR. Op een Azure-VM is HSR ook de meest natuurlijke en systeemeigen SAP HANA DR-oplossing. Of de bronimplementatie nu één exemplaar of geclusterd is, een replica van de broninfrastructuur is vereist in de dr-regio. Deze DR-replica wordt geconfigureerd nadat de primaire HLI naar de VM-migratie is voltooid. De DR HANA-database wordt als secundaire replicatiesite geregistreerd bij het primaire SAP HANA op vm-exemplaar.

Doelwijziging van sap-toepassingsserververbinding

De HSR-migratie resulteert in een nieuwe HANA-databasehost en ook een nieuwe databasehostnaam voor de toepassingslaag. Wijzig SAP-profielen zodat deze overeenkomen met de nieuwe hostnaam. Als het overschakelen wordt uitgevoerd door naamomzetting met behoud van de hostnaam, is er geen profielwijziging vereist.

Besturingssysteem

De installatiekopieën van het besturingssysteem voor HLI en VM zijn, ondanks dat ze zich op hetzelfde releaseniveau bevinden (bijvoorbeeld SLES 12 SP4), niet identiek. Valideer de vereiste pakketten, hot fixes, patches, kernel en beveiligingsoplossingen op de HLI. Installeer vervolgens dezelfde pakketten op het doel. U kunt HSR gebruiken om te repliceren van een ouder besturingssysteem naar een VIRTUELE machine met een nieuwere versie van het besturingssysteem. Controleer de ondersteunde versies door SAP-notitie te controleren 2763388.

Nieuwe SAP-licentieaanvraag

Een eenvoudige aanroep om een nieuwe SAP-licentie aan te vragen voor het nieuwe HANA-systeem nu het is gemigreerd naar VM's.

Verschillen tussen Service Level Agreement (SLA)

De auteurs noemen graag het verschil in beschikbaarheids-SLA tussen HLI en Azure VM. Geclusterde HLIs-paren bieden bijvoorbeeld een beschikbaarheid van 99,99%. Als u dezelfde SLA wilt bereiken, moet u VM's implementeren in beschikbaarheidszones. Sla voor virtuele machines beschrijft de beschikbaarheid voor verschillende VM-configuraties, zodat klanten hun doelinfrastructuur kunnen plannen.

Migratiestrategie

In dit document behandelen we alleen de HANA-systeemreplicatiebenadering voor de migratie van HLI naar Azure VM. Afhankelijk van de geïmplementeerde doelopslagoplossing, verschilt het proces enigszins. De stappen op hoog niveau worden hieronder beschreven.

VM met premium/ultraschijven voor gegevens

Voor VM's die zijn geïmplementeerd met premium- of ultraschijven, is de standaardconfiguratie voor SAP HANA-systeemreplicatie van toepassing voor het instellen van HSR. Zie het HELP-artikel voor SAP voor een overzicht van de stappen voor het instellen van systeemreplicatie. Het artikel bevat ook informatie over het overnemen van een secundair systeem, het uitvoeren van een failback naar het primaire systeem en het uitschakelen van systeemreplicatie. Voor migratie hebben we alleen de installatie nodig, het overnemen en uitschakelen van replicatiestappen.

VM met ANF voor gegevens- en logboekvolumes

Op hoog niveau moeten de meest recente HLI-opslagmomentopnamen van de volledige gegevens en logboekvolumes worden gekopieerd naar Azure Storage. Van daaruit zijn ze toegankelijk en herstelbaar door de doel-HANA-VM. Het kopieerproces kan worden uitgevoerd met alle systeemeigen Linux-hulpprogramma's voor kopiëren.

Belangrijk

Kopiëren en gegevensoverdracht kan uren duren, afhankelijk van de grootte van de HANA-database en de netwerkbandbreedte. Het grootste deel van het kopieerproces moet worden uitgevoerd voorafgaand aan de downtime van de primaire HANA-database.

MCOS naar MDC-conversie

Het MCOS-implementatiemodel (Multiple Components in One System) is gebruikt door enkele van onze HLI-klanten. De reden hiervoor was om de beperking van MDC-opslagmomentopnamen (Multiple Databases Container) van eerdere SAP HANA-versies te omzeilen. In het MCOS-model worden verschillende onafhankelijke SAP HANA-exemplaren gestapeld in één HANA Large Instance. Het gebruik van HSR voor de migratie werkt prima, maar resulteert in meerdere HANA-VM's met elk één tenantdatabase. Dit model zorgt voor een drukker landschap dan wat u liever hebt. De standaardimplementatie voor SAP HANA 2.0 is MDC. Een alternatief is het verplaatsen van HANA-tenants na de HSR-migratie. HANA-tenants worden deze onafhankelijke HANA-databases gecombineerd tot cotenants in één HANA-container.

Overwegingen voor toepassingslagen

De databaseserver wordt weergegeven als het midden van een SAP-systeem. Alle toepassingsservers moeten zich in de buurt van de SAP HANA-database bevinden. In sommige gevallen moet u, wanneer u een nieuwe PPG wilt gebruiken, mogelijk bestaande toepassingsservers verplaatsen naar de PPG waar de HANA-VM zich bevindt. Het bouwen van nieuwe toepassingsservers wordt mogelijk eenvoudiger geacht als u al implementatiesjablonen hebt.

Zoek bestaande toepassingsservers en de nieuwe HANA-VM optimaal. Vervolgens hoeft u geen nieuwe toepassingsservers te bouwen, tenzij u meer capaciteit wilt.

Wanneer u een nieuwe infrastructuur bouwt om de beschikbaarheid van de service te verbeteren, kunnen uw bestaande toepassingsservers onnodig worden. Ze kunnen worden afgesloten en verwijderd. Als de hostnaam van de doel-VM is gewijzigd en verschilt van de HLI-hostnaam, past u de PROFIELEN van de SAP-toepassingsserver aan zodat deze verwijst naar de nieuwe host. Als alleen het IP-adres van de HANA-database is gewijzigd, werkt u de DNS-record bij om binnenkomende verbindingen met de nieuwe HANA-VM te leiden.

Acceptatietest

Migratie van HLI naar VM brengt geen materiële wijzigingen aan in de database-inhoud in vergelijking met een heterogene migratie. Toch raden we u aan de prestaties van de nieuwe installatie te controleren.

Cutover-plan

Hoewel deze migratie eenvoudig is, is er sprake van het buiten gebruik stellen van een bestaande database. Zorgvuldige planning voor het behouden van het bronsysteem met de inhoud en back-upafbeeldingen zijn essentieel voor het geval terugval noodzakelijk is. Goede planning biedt een snellere omkering.

Na de migratie

De migratietaak wordt pas uitgevoerd als we alle HLI-afhankelijke services en connectiviteit veilig loskoppelen om de integriteit van de gegevens te waarborgen. We raden u ook aan onnodige services af te sluiten. In deze sectie worden enkele van de belangrijkste items beschreven.

De HLI buiten gebruik stellen

Nadat de HANA-database is gemigreerd naar een Azure-VM, moet u ervoor zorgen dat er geen zakelijke transacties worden uitgevoerd op de HLI-database. Als u de HLI echter gedurende de tijdsduur van het lokale bewaarvenster voor back-ups houdt, zorgt u ervoor dat de HLI sneller kan worden hersteld, indien nodig. Alleen wanneer het lokale bewaarvenster voor back-ups voorbij is, moet u de HANA Large Instance buiten gebruik stellen. Sluit vervolgens uw contractuele HLI-toezeggingen met Microsoft door contact op te leggen met hun Microsoft-vertegenwoordigers.

Verwijder alle proxy's (bijvoorbeeld Iptables, BIGIP) die zijn geconfigureerd voor HLI

Als een proxyservice zoals de IPTables wordt gebruikt om on-premises verkeer naar en van de HLI te routeren, hebt u deze niet nodig na de geslaagde migratie naar de VM. Deze connectiviteitsservice moet echter worden bewaard zolang de HLI zich bevindt. Sluit de service alleen af zodra de HLI volledig buiten gebruik is gesteld.

Global Reach voor HLI verwijderen

Global Reach wordt gebruikt om de ExpressRoute-gateway van klanten te verbinden met de HLI ExpressRoute-gateway. Hiermee kan het on-premises verkeer van klanten de HLI-tenant rechtstreeks bereiken zonder gebruik te maken van een proxyservice. Deze verbinding is niet meer nodig bij afwezigheid van de HLI-eenheid na de migratie. Net als de IPTables-proxyservice moet GlobalReach ook worden bewaard totdat de HLI volledig buiten gebruik wordt gesteld.

Besturingssysteemabonnement : verplaatsen/hergebruiken

Wanneer de VM-servers worden geïmplementeerd en de HLI's buiten gebruik worden gesteld, kunnen de besturingssysteemabonnementen worden vervangen of opnieuw worden gebruikt. U hoeft niet dubbel te betalen voor besturingssysteemlicenties.

Volgende stappen

Plan uw SAP-implementatie.

SAP-workloads in Azure: Controlelijst voor planning en implementatie