Delen via

Migratie van SAP HANA op grote Azure-exemplaren naar Azure Virtual Machines

  • Artikel

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

Overzicht

Azure Large Instances voor SAP HANA (HLI) zijn voor het eerst aangekondigd in september 2016. Sindsdien hebben velen deze hardware als een service gebruikt voor hun in-memory rekenplatform. Maar in de afgelopen jaren hebben de uitbreiding van de grootte van virtuele Azure-machines (VM's) en ondersteuning voor de uitschaalimplementatie van HANA de vraag naar ERP-databasecapaciteit van de meeste zakelijke klanten overschreden. Velen hebben interesse in het migreren van hun SAP HANA-workload van fysieke servers naar Azure-VM's.

Dit artikel is geen stapsgewijs configuratiedocument. Het beschrijft de algemene implementatiemodellen en biedt plannings- en migratieadvies. Het is onze bedoeling om de noodzakelijke overwegingen voor de voorbereiding te noemen om de downtime van de overgang tot een minimum te beperken.

Aannames

In dit artikel wordt uitgegaan van het volgende:

  • We houden alleen rekening met een homogene migratie van de HANA-database-rekenservice van Hana Large Instance (HLI) naar Azure-VM zonder aanzienlijke software-upgrade of patching. Deze kleine updates omvatten het gebruik van een recentere versie van het besturingssysteem (OS) of de HANA-versie die expliciet wordt vermeld als ondersteund door relevante SAP-opmerkingen.
  • U voert alle activiteiten voor updates/upgrades uit vóór of na de migratie. Bijvoorbeeld SAP HANA MCOS converteren 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 dat een systeem met herstel na noodgevallen met één exemplaar hetzelfde blijft op de bestemming.
  • U hebt de SLA (Service Level Agreement) van de doelarchitectuur (to-be) bekeken en begrepen.
  • Commerciële voorwaarden 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 de 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 het migratieplan gevalideerd.
  • Plan de VM voor herstel na noodgevallen samen met de primaire site. U kunt de HLI niet gebruiken als dr-knooppunt voor de primaire site die wordt uitgevoerd op VM's na de migratie.
  • U hebt de vereiste back-upbestanden gekopieerd naar doel-VM's, op basis van de vereisten voor bedrijfsherstel en naleving. Met vm-toegankelijke back-ups is herstel naar een bepaald tijdstip mogelijk tijdens de overgangsperiode.
  • Voor hoge beschikbaarheid (HSR) van SAP HANA-systeemreplicatie (HA) moet u het fencingapparaat 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 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 Migreren naar VM verbatim? Opmerking
1 Eén knooppunt met één SID Yes -
2 Eén knooppunt met meerdere onderdelen in één systeem (MCOS) Yes -
3 Eén knooppunt met herstel na noodgeval met behulp van opslagreplicatie No Opslagreplicatie is niet beschikbaar met het virtuele Azure-platform; huidige oplossing voor herstel na noodgeval wijzigen in HSR of back-up/herstel.
4 Eén knooppunt met herstel na noodgeval (multipurpose) met behulp van opslagreplicatie No Opslagreplicatie is niet beschikbaar met het virtuele Azure-platform; huidige oplossing voor herstel na noodgeval wijzigen in HSR of back-up/herstel.
5 HSR met fencing voor hoge beschikbaarheid Yes 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 No Vervang opslagreplicatie voor herstel na noodgeval door HSR of back-up/herstel.
7 Automatische failover van host (1+1) Yes Gebruik Azure NetApp Files (ANF) voor gedeelde opslag met Azure-VM's.
8 Uitschalen met stand-by Yes BW/4HANA met M128s, M416s, M416ms VM's die ANF alleen gebruiken voor opslag.
9 Uitschalen zonder stand-by Yes BW/4HANA met M128s-, M416s-, M416ms-VM's (met of zonder gebruik van ANF voor opslag).
10 Uitschalen met herstel na noodgeval met behulp van opslagreplicatie No Vervang opslagreplicatie voor herstel na noodgeval door HSR of back-up/herstel.
11 Eén knooppunt met herstel na noodgeval met behulp van HSR Yes -
12 HSR met één knooppunt naar herstel na noodgeval (geoptimaliseerd voor kosten) Yes -
13 HOGE en DR met HSR Yes -
14 Hoge beschikbaarheid en herstel na noodgevallen met HSR (geoptimaliseerd voor kosten) Yes -
15 Uitschalen met DR met behulp van HSR Yes BW/4HANA met M128s. M416s, M416ms-VM's (met of zonder gebruik van ANF voor opslag).

Planning van bron (HLI)

Bij 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 worden uitgevoerd voor de migratie naar azure-VM.

SAP HANA-huishouding

Het is een goede operationele gewoonte om de database-inhoud op te schonen, zodat ongewenste, verouderde gegevens of verouderde logboeken niet naar de nieuwe database worden gemigreerd. Bij het schoonmaken worden in het algemeen oude, verlopen of inactieve gegevens verwijderd of gearchiveerd. Deze 'gegevenshygiëne' moet worden getest in niet-productiesystemen om de geldigheid van data trim te valideren voordat ze worden gebruikt.

Netwerkconnectiviteit toestaan voor nieuwe VM's en virtuele netwerken

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

  • Wordt het nieuwe VM-migratiedoel in het bestaande virtuele netwerk geplaatst met IP-adresbereiken die al zijn toegestaan om verbinding te maken met de HLI? Er is dan geen verdere connectiviteitsupdate vereist.
  • Wordt de nieuwe Azure-VM in een nieuwe 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 uit de oorspronkelijke HLI-inrichting gebruiken om toegang toe te staan voor dit nieuwe IP-adresbereik van het virtuele netwerk. Coördineer met Microsoft Service Management om het virtuele netwerk in te schakelen voor HLI-connectiviteit.

    Notitie

    Als u de netwerklatentie tussen de toepassings- en databaselagen wilt minimaliseren, moeten de toepassings- en 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 serviceniveaudoelstellingen. In deze verplaatsing moet u ervoor zorgen dat de doelinfrastructuur voldoet aan de ingestelde doelen of deze overschrijdt.
De kans is groter dat uw SAP-toepassingsservers in een beschikbaarheidsset worden geplaatst. Als het huidige serviceniveau van de implementatie bevredigend is en als de doel-VM de hostnaam van de logische HLI-naam aanneemt, werkt het bijwerken van de DNS-adresomzetting (Domain Name Service) die verwijst naar het IP-adres van de VM zonder SAP-profielen bij te werken.

Onderbrekingsproces voor 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.

Overweging voor behoud 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 VM. U wordt aangeraden back-ups en momentopnamen op bestandsniveau op de HLI te maken, zelfs weken voordat de cut-over wordt uitgevoerd. Laat deze back-ups kopiëren naar een Azure Storage-account dat toegankelijk is voor de nieuwe SAP HANA-VM. Maak ook in de vroege overgangsperiode, voordat de op Azure gebaseerde back-up voldoende geschiedenis bouwt om te voldoen aan herstelvereisten voor een bepaald tijdstip, back-ups op bestandsniveau.

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 hebben 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 binnen uw SAP-landschap. Vergeet niet om de juiste actie te ondernemen om wijzigingen voor bewaking op te nemen en de ontvangers van de waarschuwingsmeldingen zo nodig bij te werken.

Betrokkenheid van Microsoft Operations-team

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

Microsoft-accountteam inschakelen

Plan de migratie dicht bij de verlengingstijd van het HLI-contract om onnodige kosten voor de rekenresource te minimaliseren. Als u de HLI buiten gebruik wilt stellen, coördineert u de beëindiging van het contract en sluit u de eenheid.

Bestemmingsplanning

Een zorgvuldige planning is essentieel bij het implementeren van een nieuwe infrastructuur die de plaats van een bestaande infrastructuur inneemt. Zorg ervoor dat de nieuwe toevoeging voldoet aan uw behoeften in het grotere schema van dingen. Hier volgen enkele belangrijke punten om rekening mee te houden.

Beschikbaarheid van resources in de doelregio

De implementatieregio van de huidige SAP-toepassingsservers ligt meestal 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 af te stemmen voor prestatieoptimalisatie. Zorg er daarbij voor dat de gekozen regio alle vereiste resources heeft. U kunt bijvoorbeeld de beschikbaarheid controleren van een bepaalde VM-familie of de Azure-zones die een installatie met hoge beschikbaarheid bieden.

Virtueel netwerk

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

Beveiliging

Of de nieuwe SAP HANA-VM nu 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 is ook een kans om de juiste grootte van uw HANA-berekeningsengine te bepalen. U kunt HANA-systeemweergaven met HANA Studio gebruiken om inzicht te krijgen in het verbruik van systeemresources, waardoor de juiste grootte kan worden aangepast 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 SAP HANA Azure-machines voor meer informatie. We raden u aan deze specificaties te bekijken en te vergelijken met uw bestaande HLI-systeemstatistieken om te zorgen voor voldoende IO-capaciteit en -prestaties voor uw nieuwe HANA-VM.

Gaat u PPG configureren voor de nieuwe HANA-VM en de bijbehorende servers? Dien vervolgens een ondersteuningsticket in om de co-locatie van de opslag en de VM te controleren en te controleren. Omdat uw back-upoplossing mogelijk moet worden gewijzigd, moet u ook de opslagkosten opnieuw bekijken om verrassingen voor 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 tot een minimum te beperken. Plaats de nieuwe database-VM en de huidige SAP-toepassingsservers in een PPG. Zie Nabijheidsplaatsingsgroep voor meer informatie over hoe Azure-beschikbaarheidsset en beschikbaarheidszones werken met PPG voor SAP-implementaties.

Als leden van uw HANA-systeem in meer dan één Azure-zone zijn geïmplementeerd, 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 verkleinen. Het hulpprogramma voor latentietest in de beschikbaarheidszone van het openbare domein helpt de meting te vereenvoudigen.

Back-upstrategie

Veel van onze klanten gebruiken al back-upoplossingen van derden voor SAP HANA op HLI. Als dat zo is, hoeven alleen toegevoegde beveiligde VM- en HANA-databases te 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 maken, herstellen en beheren voor meer informatie over SAP HANA-back-up in Azure-VM's.

DR-strategie

Als uw serviceniveaudoelen een langere hersteltijd mogelijk maken, kan back-up eenvoudig zijn. Een back-up maken naar blobopslag en ter plaatse herstellen of herstellen naar een nieuwe VM is de eenvoudigste en goedkoopste dr-strategie.

Op het platform voor grote instanties wordt HANA DR doorgaans 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, er is een replica van de broninfrastructuur vereist in de regio herstel na noodgeval. Deze DR-replica wordt geconfigureerd nadat de primaire migratie van HLI naar VM is voltooid. De DR HANA DB wordt geregistreerd bij het primaire SAP HANA on VM-exemplaar als een secundaire replicatiesite.

Doelwijziging van sap-toepassingsserverconnectiviteit

De HSR-migratie resulteert in een nieuwe HANA-databasehost en ook een nieuwe databasehostnaam voor de toepassingslaag. Wijzig SAP-profielen om de nieuwe hostnaam weer te geven. Als de wisseling wordt uitgevoerd met 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 beveiligingspatches op de HLI. Installeer vervolgens dezelfde pakketten op het doel. U kunt HSR gebruiken om vanuit een ouder besturingssysteem te repliceren naar een VM met een nieuwere versie van het besturingssysteem. Controleer de ondersteunde versies door sapnotitie 2763388 te bekijken.

Nieuwe SAP-licentieaanvraag

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

Verschillen in Service Level Agreement (SLA)

De auteurs noemen graag het verschil in beschikbaarheids-SLA tussen HLI en Azure VM. Geclusterde HLIs HA-paren bieden bijvoorbeeld een beschikbaarheid van 99,99%. Als u dezelfde SLA wilt bereiken, moet u VM's implementeren in beschikbaarheidszones. SLA voor Virtual 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 algemene stappen 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 SAP Help-artikel voor een overzicht van de stappen voor het instellen van systeemreplicatie. Het artikel heeft ook betrekking op het overnemen van een secundair systeem, een failback naar het primaire systeem en het uitschakelen van systeemreplicatie. Voor migratie hoeven we alleen de replicatiestappen in te stellen, over te nemen en uit te schakelen.

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 voor 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 vóór de downtime van de primaire HANA-database.

MCOS naar MDC-conversie

Het MCOS-implementatiemodel (Multiple Components in One System) is gebruikt door een aantal HLI-klanten. De motivatie was om de beperking voor 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 grote HANA-instantie. 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 misschien wilt. De standaardimplementatie voor SAP HANA 2.0 is MDC. Een alternatief is om de HANA-tenant te verplaatsen na de HSR-migratie. HANA-tenant verplaatsen combineert deze onafhankelijke HANA-databases tot cotenants in één HANA-container.

Overweging van toepassingslaag

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, wanneer u een nieuwe PPG wilt gebruiken, moet u 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 bij de hand hebt.

Zoek bestaande toepassingsservers en de nieuwe HANA-VM optimaal. U hoeft dan 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 overbodig worden. Ze kunnen worden afgesloten en verwijderd. Als de hostnaam van de doel-VM is gewijzigd en verschilt van de HLI-hostnaam, past u sap-toepassingsserverprofielen aan om naar de nieuwe host te verwijzen. Als alleen het IP-adres van de HANA-database is gewijzigd, werkt u de DNS-record bij om binnenkomende verbindingen naar de nieuwe HANA-VM te leiden.

Acceptatietest

Migratie van HLI naar VM brengt geen wezenlijke 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, moet een bestaande database buiten gebruik worden gesteld. Een zorgvuldige planning voor het behouden van het bronsysteem met de inhoud en back-upafbeeldingen is essentieel voor het geval er een terugval nodig is. Een goede planning biedt een snellere omkering.

Na de migratie

De migratietaak wordt pas uitgevoerd als we alle HLI-afhankelijke services en connectiviteit veilig hebben losgekoppeld om de integriteit van gegevens te garanderen. 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 zo nodig voor een sneller herstel. Alleen wanneer het bewaarvenster voor lokale back-ups is verstreken, moet u het grote HANA-exemplaar buiten gebruik stellen. Sluit vervolgens uw contractuele HLI-verplichtingen met Microsoft door contact op te leggen met hun Microsoft-vertegenwoordigers.

Verwijder een proxy (bijvoorbeeld Iptables, BIGIP) die is geconfigureerd voor HLI

Als een proxyservice zoals IPTables wordt gebruikt om on-premises verkeer van en naar de HLI te routeren, hebt u deze niet meer nodig na de geslaagde migratie naar de VM. Niettemin moet deze connectiviteitsservice worden bewaard zolang de HLI stand-by is. Sluit de service alleen af als 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 het gebruik van een proxyservice. Deze verbinding is niet meer nodig als de HLI-eenheid na de migratie ontbreekt. Net als bij de IPTables-proxyservice moet GlobalReach ook worden bewaard totdat de HLI volledig buiten gebruik is gesteld.

Besturingssysteemabonnement – verplaatsen/opnieuw gebruiken

Wanneer de VM-servers worden geïmplementeerd en de HLI's buiten gebruik worden gesteld, kunnen de abonnementen van het besturingssysteem worden vervangen of opnieuw worden gebruikt. Het is niet nodig om dubbel te betalen voor besturingssysteemlicenties.

Volgende stappen

Plan uw SAP-implementatie.

SAP-workloads in Azure: Controlelijst voor planning en implementatie