SAP HANA-nätverksarkitektur (stora instanser)

I den här artikeln ska vi titta på nätverksarkitekturen för distribution av SAP HANA på Stora Azure-instanser (även kallat BareMetal-infrastruktur).

Arkitekturen för Azure-nätverkstjänster är en viktig komponent för att distribuera SAP-program på HANA Large Instance. Normalt har SAP HANA på Azure-distributioner (stora instanser) ett större SAP-landskap. De omfattar sannolikt flera SAP-lösningar med varierande storlekar av databaser, cpu-resursförbrukning och minnesanvändning.

Det är troligt att inte alla IT-system redan finns i Azure. Ditt SAP-landskap kan också vara hybrid. Databashanteringssystemet (DBMS) och SAP-programmet kan använda en blandning av NetWeaver, S/4HANA och SAP HANA. Ditt SAP-program kan till och med använda en annan DBMS.

Azure erbjuder olika tjänster som gör att du kan köra DBMS-, NetWeaver- och S/4HANA-systemen i Azure. Azure erbjuder nätverksteknik för att få Azure att se ut som ett virtuellt datacenter för dina lokala programvarudistributioner. Azure-nätverksfunktionerna omfattar:

• Virtuella Azure-nätverk som är anslutna till ExpressRoute-kretsen som ansluter till dina lokala nätverkstillgångar.
• En ExpressRoute-krets som ansluter lokalt till Azure med en minsta bandbredd på 1 Gbit/s eller högre. Den här kretsen tillåter tillräcklig bandbredd för överföring av data mellan lokala system och system som körs på virtuella datorer (VM). Det ger också tillräcklig bandbredd för anslutning till Azure-system från lokala användare.
• Alla SAP-system i Azure som har konfigurerats i virtuella nätverk för att kommunicera med varandra.
• Active Directory och DNS lokalt utökas till Azure via ExpressRoute lokalt. De kan också köras helt i Azure.

När du integrerar STORA HANA-instanser i Azures datacenternätverksinfrastruktur används även Azure ExpressRoute-teknik.

Kommentar

Endast en Azure-prenumeration kan bara länkas till en klientorganisation i en HANA Large Instance-stämpel i en specifik Azure-region. Omvänt kan en enda HANA Large Instance-stämpelklient länkas till endast en Azure-prenumeration. Det här kravet är förenligt med andra fakturerbara objekt i Azure.

Om SAP HANA på Azure (stora instanser) distribueras i flera Azure-regioner distribueras en separat klientorganisation i HANA Large Instance-stämpeln. Du kan köra båda under samma Azure-prenumeration förutsatt att dessa instanser ingår i samma SAP-landskap.

Viktigt!

Endast Azure Resource Manager-distributionsmetoden stöds med SAP HANA på Azure (stora instanser).

Extra information om virtuella nätverk

Om du vill ansluta ett virtuellt nätverk till ExpressRoute måste en Azure ExpressRoute-gateway skapas. Mer information finns i Om Expressroute-gatewayer för ExpressRoute.

En Azure ExpressRoute-gateway används med ExpressRoute till en infrastruktur utanför Azure eller till en Azure Large Instance-stämpel. Du kan ansluta Azure ExpressRoute-gatewayen till högst fyra ExpressRoute-kretsar, men bara om dessa anslutningar kommer från olika Microsoft Enterprise Edge-routrar (MSEE). Mer information finns i INFRASTRUKTUR och anslutning för SAP HANA (stora instanser) i Azure.

Kommentar

Det maximala dataflödet du kan uppnå med en ExpressRoute-gateway är 10 Gbit/s med hjälp av en ExpressRoute-anslutning. Att kopiera filer mellan en virtuell dator som finns i ett virtuellt nätverk och ett system lokalt (som en enda kopieringsström) uppnår inte det fullständiga dataflödet för de olika gateway-SKU:erna. Om du vill utnyttja den fullständiga bandbredden för ExpressRoute-gatewayen använder du flera strömmar eller kopierar olika filer i parallella strömmar av en enda fil.

Nätverksarkitektur för STORA HANA-instanser

Nätverksarkitekturen för STORA HANA-instanser kan delas upp i fyra delar:

• Lokala nätverk och ExpressRoute-anslutning till Azure. Den här delen är din (kundens) domän och är ansluten till Azure via ExpressRoute. Den här ExpressRoute-kretsen betalas helt av dig. Bandbredden ska vara tillräckligt stor för att hantera nätverkstrafiken mellan dina lokala tillgångar och den Azure-region som du ansluter med. Se längst ned till höger i följande bild.
• Azure-nätverkstjänster, som tidigare diskuterats, med virtuella nätverk, som återigen behöver ExpressRoute-gatewayer tillagda. För den här delen måste du skapa lämpliga design för att uppfylla kraven för program, säkerhet och efterlevnad. Fundera på om du vill använda STORA HANA-instanser med tanke på antalet virtuella nätverk och SKU:er för Azure Gateway att välja mellan. Se det övre högra hörnet i bilden.
• Anslutning av den stora HANA-instansen via ExpressRoute till Azure. Den här delen distribueras och hanteras av Microsoft. Allt du behöver göra är att ange vissa IP-adressintervall när du har distribuerat dina tillgångar i HANA Large Instance och anslutit ExpressRoute-kretsen till de virtuella nätverken. Mer information finns i INFRASTRUKTUR och anslutning för SAP HANA (stora instanser) i Azure. Det finns ingen extra avgift för anslutningen mellan Azure Data Center Network Fabric och HANA Large Instance-enheter.
• Nätverk inom HANA Large Instance-stämpeln, som mestadels är transparent för dig.

Följande två krav gäller fortfarande även om du använder Stora Hana-instanser:

• Dina lokala tillgångar måste ansluta via ExpressRoute till Azure.
• Du behöver ett eller flera virtuella nätverk som kör dina virtuella datorer. De här virtuella datorerna är värdar för programskiktet som ansluter till HANA-instanserna i HANA Large Instances.

Skillnaderna i SAP-distributioner i Azure är:

• HANA Stora instanser av din klientorganisation är anslutna via en annan ExpressRoute-krets till dina virtuella nätverk. De lokala till virtuella Azure-nätverken ExpressRoute-kretsar och kretsarna mellan virtuella Azure-nätverk och HANA Large Instances delar inte samma routrar. Deras belastningsförhållanden förblir separata.
• Arbetsbelastningsprofilen mellan SAP-programlagret och den stora HANA-instansen är av en annan typ. SAP HANA genererar många små begäranden och bursts som dataöverföringar (resultatuppsättningar) till programlagret.
• SAP-programarkitekturen är mer känslig för nätverksfördröjning än vanliga scenarier där data utbyts mellan lokalt och Azure.
• Azure ExpressRoute-gatewayen har minst två ExpressRoute-anslutningar. En krets är ansluten lokalt och en är ansluten från den stora HANA-instansen. Den här konfigurationen lämnar bara plats för ytterligare två kretsar från olika MSEE:er för att ansluta till ExpressRoute-gatewayen. Den här begränsningen är oberoende av användningen av ExpressRoute FastPath. Alla anslutna kretsar delar den maximala bandbredden för inkommande data i ExpressRoute-gatewayen.

Med revision 3 av HANA Large Instance-stämplar kan nätverksfördröjningen mellan virtuella datorer och HANA Large Instance-enheter vara högre än vanliga svarstider för vm-till-VM-nätverk. Beroende på Azure-regionen kan värdena överskrida svarstiden på 0,7 ms tur och retur som klassificeras som under genomsnittet i SAP Note #1100926 – Vanliga frågor och svar: Nätverksprestanda. Beroende på Azure-region och verktyget för att mäta svarstid mellan en virtuell Azure-dator och HANA Large Instance kan svarstiden vara upp till 2 millisekunder. Ändå distribuerar kunderna SAP HANA-baserade SAP-program för produktion på STORA SAP HANA-instanser. Kontrollera att du testar dina affärsprocesser noggrant med Stora Azure HANA-instanser. En ny funktion, som kallas ExpressRoute FastPath, kan avsevärt minska nätverksfördröjningen mellan STORA HANA-instanser och virtuella datorer på programnivå i Azure (se nedan).

Revision 4 av HANA Large Instance-stämplar förbättrar nätverksfördröjningen mellan virtuella Azure-datorer som distribueras i närheten av HANA Large Instance-stämpeln. Svarstiden uppfyller den genomsnittliga eller bättre klassificeringen än genomsnittet enligt beskrivningen i SAP Note #1100926 – Vanliga frågor och svar: Nätverksprestanda om Azure ExpressRoute FastPath har konfigurerats (se nedan).

Om du vill distribuera virtuella Azure-datorer i närheten av HANA Large Instances of Revision 4 måste du använda Azure Proximity Placement Groups. Närhetsplaceringsgrupper kan användas för att hitta SAP-programskiktet i samma Azure-datacenter som Revision 4-värdbaserade HANA Large Instances. Mer information finns i Azure Närhetsplaceringsgrupper för optimal nätverksfördröjning med SAP-program.

För att ge deterministisk nätverksfördröjning mellan virtuella datorer och HANA Large Instance är det viktigt att använda ExpressRoute-gateway-SKU:n. Till skillnad från trafikmönstren mellan lokala och virtuella datorer kan trafikmönstren mellan virtuella datorer och STORA HANA-instanser utveckla små men höga mängder begäranden och datavolymer. För att hantera sådana bursts rekommenderar vi starkt att du använder SKU:n för UltraPerformance-gatewayen. För typ II-klassen för HANA Large Instance-SKU:er är det obligatoriskt att använda SKU:n för UltraPerformance-gatewayen som en ExpressRoute-gateway.

Viktigt!

Med tanke på den övergripande nätverkstrafiken mellan SAP-program- och databasskikten stöds endast SKU:er för HighPerformance- eller UltraPerformance-gatewayen för virtuella nätverk för anslutning till SAP HANA på Azure (stora instanser). För SKU:er för HANA Large Instance Type II stöds endast SKU:n för UltraPerformance-gatewayen som en ExpressRoute-gateway. Undantag gäller när du använder ExpressRoute FastPath (se nedan).

ExpressRoute FastPath

I maj 2019 släppte vi ExpressRoute FastPath. FastPath sänker svarstiden mellan STORA HANA-instanser och virtuella Azure-nätverk som är värdar för virtuella SAP-programdatorer. Med FastPath dirigeras inte dataflödena mellan virtuella datorer och STORA HANA-instanser via ExpressRoute-gatewayen. De virtuella datorer som tilldelats i undernäten i det virtuella Azure-nätverket kommunicerar direkt med den dedikerade enterprise edge-routern.

Viktigt!

ExpressRoute FastPath kräver att undernäten som kör de virtuella SAP-programdatorerna finns i samma virtuella Azure-nätverk som är anslutet till HANA Large Instances. Virtuella datorer som finns i virtuella Azure-nätverk som är peerkopplade med det virtuella Azure-nätverket som är anslutet till HANA Large Instance-enheterna drar inte nytta av ExpressRoute FastPath. Därför är typiska designer för virtuella hubbar och ekrar, där ExpressRoute-kretsarna ansluter mot ett virtuellt hubbnätverk och virtuella nätverk som innehåller SAP-programskiktet (ekrar) peer-kopplade, och optimeringen av ExpressRoute FastPath fungerar inte. ExpressRoute FastPath stöder inte heller för närvarande användardefinierade routningsregler (UDR). Mer information finns i Den virtuella ExpressRoute-nätverksgatewayen och FastPath.

Mer information om hur du konfigurerar ExpressRoute FastPath finns i Ansluta ett virtuellt nätverk till STORA HANA-instanser.

Kommentar

En ExpressRoute-gateway för UltraPerformance krävs för att använda ExpressRoute FastPath.

Enda SAP-system

Den lokala infrastrukturen som tidigare visades är ansluten via ExpressRoute till Azure. ExpressRoute-kretsen ansluter till en MSEE. Mer information finns i Teknisk översikt över ExpressRoute. När vägen har upprättats ansluter den till Azure-stamnätet.

Kommentar

Om du vill köra SAP-landskap i Azure ansluter du till enterprise edge-routern närmast Azure-regionen i SAP-landskapet. HANA Large Instance-stämplar är anslutna via dedikerade enterprise edge-routrar för att minimera nätverksfördröjningen mellan virtuella datorer i Azure IaaS- och HANA Large Instance-stämplar.

ExpressRoute-gatewayen för de virtuella datorer som är värdar för SAP-programinstanser är anslutna till en ExpressRoute-krets som ansluter till den lokala miljön. Samma virtuella nätverk är anslutet till en separat enterprise edge-router. Gränsroutern är dedikerad till att ansluta till stämplar för stora instanser. Med FastPath dirigeras inte dataflödet från STORA HANA-instanser till virtuella DATORER på SAP-programnivå via ExpressRoute-gatewayen. Den här konfigurationen minskar svarstiden för nätverket.

Det här systemet är ett enkelt exempel på ett enda SAP-system. SAP-programlagret finns i Azure. SAP HANA-databasen körs på SAP HANA på Azure (stora instanser). Antagandet är att ExpressRoute-gatewaybandbredden på 2 Gbit/s eller 10 Gbit/s-dataflödet inte representerar en flaskhals.

Flera SAP-system eller stora SAP-system

Om du distribuerar flera SAP-system eller stora SAP-system som ansluter till SAP HANA (stora instanser) kan dataflödet för ExpressRoute-gatewayen bli en flaskhals. I så fall delar du upp programlagren i flera virtuella nätverk. Du kan också dela upp programskikten om du vill isolera produktions- och icke-produktionssystem i olika virtuella Azure-nätverk.

Du kan skapa ett särskilt virtuellt nätverk som ansluter till STORA HANA-instanser när:

• Göra säkerhetskopior direkt från HANA-instanserna i en stor HANA-instans till en virtuell dator i Azure som är värd för NFS-resurser.
• Kopiera stora säkerhetskopior eller andra filer från STORA HANA-instanser till diskutrymme som hanteras i Azure.

Använd ett separat virtuellt nätverk för att vara värd för virtuella datorer som hanterar lagring för massöverföring av data mellan STORA HANA-instanser och Azure. Det här arrangemanget undviker stor fil- eller dataöverföring från STORA HANA-instanser till Azure på ExpressRoute-gatewayen som hanterar de virtuella datorer som kör SAP-programskiktet.

För en mer utbyggbar nätverksarkitektur:

• Använd flera virtuella nätverk för ett enda, större SAP-programlager.

• Distribuera ett separat virtuellt nätverk för varje SAP-system som distribueras, jämfört med att kombinera dessa SAP-system i separata undernät under samma virtuella nätverk.

  Följande diagram visar en mer utbyggbar nätverksarkitektur för SAP HANA i Azure (stora instanser):

Beroende på vilka regler och begränsningar du vill tillämpa mellan de olika virtuella nätverk som är värdar för virtuella datorer i olika SAP-system bör du peer-koppla dessa virtuella nätverk. Mer information om peering för virtuella nätverk finns i Peering för virtuella nätverk.

Routning i Azure

Som standarddistribution är tre överväganden för nätverksroutning viktiga för SAP HANA i Azure (stora instanser):

• SAP HANA på Azure (stora instanser) kan endast nås via virtuella Azure-datorer och den dedikerade ExpressRoute-anslutningen, inte direkt från den lokala miljön. Direkt åtkomst från lokala enheter till HANA Large Instance-enheterna, som levereras av Microsoft till dig, är inte möjligt omedelbart. De transitiva routningsbegränsningarna beror på den aktuella Azure-nätverksarkitekturen som används för stora SAP HANA-instanser. Vissa administrationsklienter och program som behöver direkt åtkomst, till exempel SAP Solution Manager som körs lokalt, kan inte ansluta till SAP HANA-databasen. Undantag finns i följande avsnitt, Direktdirigering till STORA HANA-instanser.

• Om du har HANA Large Instance-enheter distribuerade i två olika Azure-regioner för haveriberedskap gäller samma tillfälliga routningsbegränsningar som tidigare. Med andra ord dirigerades inte IP-adresser för en stor HANA-instans i en region (till exempel USA, västra) till en stor HANA-instans som distribuerats i en annan region (till exempel USA, östra). Den här begränsningen är oberoende av användningen av Azure-nätverkspeering mellan regioner eller korsanslutning av ExpressRoute-kretsar som ansluter STORA HANA-instanser till virtuella nätverk. En grafisk representation finns i bilden i avsnittet Använda HANA Large Instance-enheter i flera regioner. Den här begränsningen, som kom med den distribuerade arkitekturen, förbjöd omedelbar användning av HANA-systemreplikering för haveriberedskap. De senaste ändringarna finns i Använda HANA-enheter för stora instanser i flera regioner.

• SAP HANA på Stora Azure-instanser har en tilldelad IP-adress från serverns IP-pooladressintervall som du skickade när du begärde hana large instance-distributionen. Mer information finns i INFRASTRUKTUR och anslutning för SAP HANA (stora instanser) i Azure. Den här IP-adressen är tillgänglig via De Azure-prenumerationer och -kretsar som ansluter virtuella Azure-nätverk till STORA HANA-instanser. IP-adressen som tilldelats från serverns IP-pooladressintervall tilldelas direkt till maskinvaruenheten. Den tilldelas inte längre via NAT (Network Address Translation), vilket var fallet i de första distributionerna av den här lösningen.

Dirigera routning till STORA HANA-instanser

Som standard fungerar inte den transitiva routningen i följande scenarier:

• Mellan HANA Large Instance-enheter och en lokal distribution.

• Mellan HANA Large Instance-enheter som distribuerats i olika regioner.

Det finns tre sätt att aktivera transitiv routning i dessa scenarier:

• En omvänd proxy för att dirigera data till och från. Till exempel F5 BIG-IP, NGINX med Traffic Manager distribuerat i det virtuella Azure-nätverket som ansluter till STORA HANA-instanser och till lokalt som en virtuell brandvägg/trafikroutningslösning.
• Använda IPTables-regler på en virtuell Linux-dator för att aktivera routning mellan lokala platser och HANA Large Instance-enheter, eller mellan HANA Large Instance-enheter i olika regioner. Den virtuella dator som kör IPTables måste distribueras i det virtuella Azure-nätverket som ansluter till STORA HANA-instanser och lokalt. Den virtuella datorn måste vara storleksanpassad så att den virtuella datorns nätverksdataflöde räcker för den förväntade nätverkstrafiken. Mer information om vm-nätverksbandbredd finns i artikeln Storlekar på virtuella Linux-datorer i Azure.
• Azure Firewall skulle vara en annan lösning för att aktivera direkttrafik mellan lokala enheter och HANA Large-instansenheter.

All trafik för dessa lösningar dirigeras via ett virtuellt Azure-nätverk. Därför kan trafiken också begränsas av de mjuka apparater som används eller av Azure Network Security Groups. På så sätt kan specifika IP-adresser eller IP-adressintervall från en lokal plats antingen blockeras eller uttryckligen tillåtas åtkomst till STORA HANA-instanser.

Kommentar

Tänk på att implementering och stöd för anpassade lösningar som involverar nätverksinstallationer från tredje part eller IPTables inte tillhandahålls av Microsoft. Support måste tillhandahållas av leverantören av den komponent som används eller av integreraren.

Global räckvidd för Express Route

Microsoft introducerade en ny funktion med namnet ExpressRoute Global Reach. Global Räckvidd kan användas för STORA HANA-instanser i två scenarier:

• Aktivera direkt åtkomst från lokal plats till dina HANA Large Instance-enheter som distribuerats i olika regioner.
• Aktivera direkt kommunikation mellan dina HANA Large Instance-enheter som distribuerats i olika regioner.

Direktåtkomst från lokal plats

I Azure-regioner där Global Reach erbjuds kan du begära aktivering av Global Reach för din ExpressRoute-krets. Den kretsen ansluter ditt lokala nätverk till det virtuella Azure-nätverk som ansluter till dina stora HANA-instanser. Det finns kostnader för den lokala sidan av ExpressRoute-kretsen. Mer information finns i prissättningen för Global Reach-tillägg. Du betalar inte extra kostnader för kretsen som ansluter de stora HANA-instanserna till Azure.

Viktigt!

När du använder Global Reach för att aktivera direkt åtkomst mellan dina HANA Large Instance-enheter och lokala tillgångar dirigeras inte nätverksdata och kontrollflödet via virtuella Azure-nätverk. I stället dirigeras nätverksdata och kontrollflöde direkt mellan Microsoft Enterprise Exchange-routrarna. Därför berörs inte NSG- eller ASG-regler, eller någon typ av brandvägg, NVA eller proxy som du distribuerade i ett virtuellt Azure-nätverk. Om du använder ExpressRoute Global Reach för att aktivera direkt åtkomst från lokala till HANA Stora instansenheter måste begränsningar och behörigheter för åtkomst till HANA stora instansenheter definieras i brandväggar på den lokala sidan.

Ansluta STORA HANA-instanser i olika Azure-regioner

På samma sätt kan ExpressRoute Global Reach användas för att ansluta två HANA Large Instance-klienter som distribuerats i olika regioner. Isoleringen är de ExpressRoute-kretsar som dina HANA Large Instance-klienter använder för att ansluta till Azure i båda regionerna. Det finns inga extra avgifter för att ansluta två HANA Large Instance-klienter som distribuerats i olika regioner.

Viktigt!

Dataflödet och kontrollflödet för nätverkstrafiken mellan HANA Large-instansklientorganisationer dirigeras inte via Azure-nätverk. Därför kan du inte använda Azure-funktioner eller virtuella nätverksinstallationer (NVA) för att framtvinga kommunikationsbegränsningar mellan dina HANA Large Instances-klienter.

Mer information om hur du aktiverar ExpressRoute Global Reach finns i Ansluta ett virtuellt nätverk till STORA HANA-instanser.

Internetanslutning för HANA Large Instance

STORA HANA-instanser har inte direkt internetanslutning. Den här begränsningen kan till exempel begränsa din möjlighet att registrera OS-avbildningen direkt med OS-leverantören. Du kan behöva arbeta med din lokala SUSE Linux Enterprise Server Subscription Management Tool-server eller Red Hat Enterprise Linux Subscription Manager.

Datakryptering mellan virtuella datorer och STORA HANA-instanser

Data som överförs mellan STORA HANA-instanser och virtuella datorer krypteras inte. Endast för utbytet mellan HANA DBMS-sidan och JDBC/ODBC-baserade program kan du dock aktivera kryptering av trafik. Mer information finns i Säker kommunikation mellan SAP HANA- och JDBC/ODBC-klienter.

Använda HANA Large Instance-enheter i flera regioner

För haveriberedskap måste du ha HANA Large Instance-enheter i flera Azure-regioner. Med endast Azure Global Vnet-peering fungerar den transitiva routningen som standard inte mellan HANA Large Instance-klientorganisationer i olika regioner. Global Reach öppnar dock upp kommunikationen mellan HANA Large Instance-enheter i olika regioner. Det här scenariot med ExpressRoute Global Reach möjliggör:

• HANA-systemreplikering utan fler proxyservrar eller brandväggar.
• Kopiera säkerhetskopior mellan HANA Large Instance-enheter i olika regioner för att göra systemkopior eller göra systemuppdateringar.

Föregående bild visar hur de virtuella nätverken i båda regionerna är anslutna till två ExpressRoute-kretsar. Kretsarna används för att ansluta till SAP HANA på Azure (stora instanser) i båda Azure-regionerna (grå linjer). Anledningen till de två korsanslutningarna är att skydda mot avbrott i MSEE:erna på båda sidor. Kommunikationsflödet mellan de två virtuella nätverken i de två Azure-regionerna ska hanteras över den globala peeringen för de två virtuella nätverken i de två olika regionerna (blå prickad linje). Den tjocka röda linjen beskriver ExpressRoute Global Reach-anslutningen. Med den här anslutningen kan HANA Large Instance-enheterna för dina klienter i olika regioner kommunicera med varandra.

Viktigt!

Om du använde flera ExpressRoute-kretsar använder du BGP-inställningar för AS Path prepending och Local Preference för att säkerställa korrekt routning av trafik.

Nästa steg

Lär dig mer om lagringsarkitekturen för SAP HANA (stora instanser).

SAP HANA-lagringsarkitektur (stora instanser)