Azure Virtual Machines planering och implementering för SAP NetWeaver

Microsoft Azure företag att skaffa beräknings- och lagringsresurser på minimal tid utan långa anskaffningscykler. Med tjänsten Azure Virtual Machine kan företag distribuera klassiska program som SAP NetWeaver-baserade program till Azure och utöka tillförlitligheten och tillgängligheten utan att ha ytterligare resurser tillgängliga lokalt. Azure Virtual Machine Services har också stöd för anslutning på flera platser, vilket gör det möjligt för företag att aktivt integrera Azure Virtual Machines i sina lokala domäner, sina privata moln och sina SAP-systemlandskap. Den white paper beskriver grunderna i Microsoft Azure Virtual Machine och innehåller en genomgång av planerings- och implementeringsöverväganden för SAP NetWeaver-installationer i Azure och bör därför vara det dokument som ska läsas innan du påbörjar faktiska distributioner av SAP NetWeaver på Azure. Dokumentet kompletterar sap-installationsdokumentationen och SAP-anteckningarna, som representerar de primära resurserna för installationer och distributioner av SAP-programvara på angivna plattformar.

Sammanfattning

Molnbaserad databehandling är en term som används ofta och som blir allt viktigare inom IT-branschen, från små företag upp till stora och multinationella företag.

Microsoft Azure är Cloud Services Platform från Microsoft, som erbjuder ett brett spektrum av nya möjligheter. Nu kan kunder snabbt etablera och avetablering av program som en tjänst i molnet, så de är inte begränsade till tekniska begränsningar eller budgetbegränsningar. I stället för att investera tid och budget i maskinvaruinfrastrukturen kan företag fokusera på programmet, affärsprocesserna och dess fördelar för kunder och användare.

Med Microsoft Azure Virtual Machine-tjänsterna, erbjuder Microsoft en omfattande plattform för infrastruktur som en tjänst (IaaS). SAP NetWeaver-baserade program stöds på virtuella Azure-datorer (IaaS). Det här faktabladet beskriver hur du planerar och implementerar SAP NetWeaver-baserade program i Microsoft Azure som valfri plattform.

Själva dokumentet fokuserar på två huvudaspekter:

• Den första delen beskriver två distributionsmönster som stöds för SAP NetWeaver-baserade program på Azure. Den beskriver också allmän hantering av Azure med SAP-distributioner i åtanke.
• Den andra delen beskriver implementeringen av de olika scenarier som beskrivs i den första delen.

Ytterligare resurser finns i kapitlet Resurser i det här dokumentet.

Definitioner i förskott

I hela dokumentet använder vi följande termer:

• IaaS: Infrastruktur som en tjänst
• PaaS: Plattform som en tjänst
• SaaS: Programvara som en tjänst
• SAP-komponent: ett enskilt SAP-program som ECC, BW, Solution Manager eller S/4HANA. SAP-komponenter kan baseras på traditionella ABAP eller Java-tekniker eller ett icke-NetWeaver-baserat program, till exempel Business Objects.
• SAP-miljö: en eller flera SAP-komponenter som är logiskt grupperade för att utföra en affärsfunktion som Utveckling, QAS, Utbildning, DR eller Produktion.
• SAP Landscape: Den här termen avser hela SAP-tillgångarna i en kunds IT-landskap. SAP-miljön innehåller alla produktions- och icke-produktionsmiljöer.
• SAP System: Kombinationen av DBMS-lager och programlager för, till exempel ett SAP ERP-utvecklingssystem, SAP BW-testsystem, SAP CRM-produktionssystem osv. I Azure-distributioner stöds det inte att dela upp dessa två lager mellan den lokala platsen och Azure. Innebär att ett SAP-system antingen distribueras lokalt eller distribueras i Azure. Du kan dock distribuera de olika systemen i ett SAP-landskap till antingen Azure eller lokalt. Du kan till exempel distribuera SAP CRM-utvecklings- och testsystemen i Azure, men i sap CRM-produktionssystemet lokalt.
• Flera platser eller hybrider: Beskriver ett scenario där virtuella datorer distribueras till en Azure-prenumeration som har plats-till-plats-, multiplats- eller ExpressRoute-anslutning mellan lokala datacenter och Azure. I vanlig Azure-dokumentation beskrivs även dessa typer av distributioner som mellan olika platser eller hybridscenarier. Orsaken till anslutningen är att utöka lokala domäner, lokal Active Directory/OpenLDAP och lokal DNS till Azure. Det lokala landskapslandskapet utökas till prenumerationens Azure-tillgångar. Med det här tillägget kan de virtuella datorerna ingå i den lokala domänen. Domänanvändare av den lokala domänen har åtkomst till servrarna och kan köra tjänster på dessa virtuella datorer (t.ex. DBMS-tjänster). Kommunikation och namnmatchning mellan virtuella datorer som distribuerats lokalt och Azure-distribuerade virtuella datorer är möjligt. Det här är det vanligaste och nästan exklusiva fallet som distribuerar SAP-tillgångar till Azure. Mer information finns i den här artikeln och i den här.
• Azure Monitoring Extension, Enhanced Monitoring och Azure Extension for SAP: Beskriv ett och samma objekt. Den beskriver ett VM-tillägg som måste distribueras av dig för att tillhandahålla grundläggande data om Azure-infrastrukturen till SAP-värdagenten. SAP i SAP-anteckningar kan referera till det som övervakningstillägg eller förbättrad övervakning. I Azure refererar vi till det som Azure-tillägget för SAP.

Resurser

Startpunkten för SAP-arbetsbelastningen på Azure-dokumentationen finns i Kom igång med SAP på Azure virtuella datorer. Från och med den här startpunkten hittar du många artiklar som täcker ämnena i:

• SAP NetWeaver och Business One på Azure
• SAP DBMS-guider för olika DBMS-system i Azure
• Hög tillgänglighet och haveriberedskap för SAP-arbetsbelastning i Azure
• Specifik vägledning för att köra SAP HANA på Azure
• Vägledning som är specifik för stora Azure HANA-instanser för SAP HANA DBMS

Följande SAP-anteckningar är relaterade till avsnittet om SAP på Azure:

Läs även SCN Wiki som innehåller alla SAP-anteckningar för Linux.

Allmänna standardbegränsningar och maxbegränsningar för Azure-prenumerationer finns i den här artikeln.

Möjliga scenarier

SAP ses ofta som ett av de mest verksamhetskritiska programmen i företag. Arkitekturen och driften av dessa program är främst komplex och det är viktigt att se till att du uppfyller kraven på tillgänglighet och prestanda.

Därför måste företag noga tänka igenom vilken molnleverantör de ska välja för att köra sådana affärskritiska affärsprocesser. Azure är den perfekta offentliga molnplattformen för affärskritiska SAP-program och affärsprocesser. Med tanke på den stora variationen av Azure-infrastruktur kan nästan alla befintliga SAP NetWeaver- och S/4HANA-system finnas i Azure i dag. Azure tillhandahåller virtuella datorer med många terabyte minne och mer än 200 processorer. Utöver det erbjuder Azure stora HANA-instanser,som tillåter uppskalning av HANA-distributioner på upp till 24 TB och SAP HANA skalningsdistributioner på upp till 120 TB. I dag kan man säga att nästan alla lokala SAP-scenarier också kan köras i Azure.

En grov beskrivning av scenarierna och vissa scenarier som inte stöds finns i dokumentet SAP-arbetsbelastning på scenarier som stöds av virtuella Azure-datorer.

Kontrollera de här scenarierna och några av de villkor som inte stöds i den refererade dokumentationen under planeringen och utvecklingen av din arkitektur som du vill distribuera till Azure.

Det vanligaste distributionsmönstret är ett scenario mellan olika platser som det visas

Anledningen till att många kunder använder ett distributionsmönster på flera platser är att det är mest transparent för alla program att utöka lokalt till Azure med hjälp av Azure ExpressRoute och hantera Azure som ett virtuellt datacenter. När allt fler tillgångar flyttas till Azure kommer den Azure-distribuerade infrastrukturen och nätverksinfrastrukturen att växa och de lokala tillgångarna minskar i enlighet med detta. Allt transparent för användare och program.

För att kunna distribuera SAP-system till antingen Azure IaaS eller IaaS i allmänhet är det viktigt att förstå de stora skillnaderna mellan erbjudandena för traditionella outsourcers eller värdar och IaaS-erbjudanden. Medan den traditionella värden eller outsourcer anpassar infrastrukturen (nätverk, lagring och servertyp) till den arbetsbelastning som kunden vill vara värd för, är det i stället kundens eller partnerns ansvar att beskriva arbetsbelastningen och välja rätt Azure-komponenter för virtuella datorer, lagring och nätverk för IaaS-distributioner.

För att samla in data för planering av distributionen till Azure är det viktigt att:

• Utvärdera vilka SAP-produkter som stöds när de körs på virtuella Azure-datorer
• Utvärdera vilka specifika operativsystemsutgåvningar som stöds med specifika virtuella Azure-datorer för dessa SAP-produkter
• Utvärdera vilka DBMS-versioner som stöds för dina SAP-produkter med specifika virtuella Azure-datorer
• Utvärdera om vissa av de nödvändiga OS/DBMS-versionerna kräver att du utför SAP-versionen, uppgradering av supportpaket och kerneluppgraderingar för att komma till en konfiguration som stöds
• Utvärdera om du behöver flytta till olika operativsystem för att distribuera i Azure.

Information om SAP-komponenter som stöds i Azure, stödda Azure-infrastrukturenheter och relaterade versioner av operativsystem och DBMS finns i artikeln Vilken SAP-programvara stöds för Azure-distributioner. Resultaten från utvärderingen av giltiga SAP-versioner, operativsystem och DBMS-versioner har stor inverkan på arbetet med att flytta SAP-system till Azure. Resultatet av den här utvärderingen kommer att definiera om det kan finnas betydande förberedelser i de fall där sap-uppgraderingar eller ändringar av operativsystem behövs.

Azure-regioner

Microsofts Azure-tjänster samlas in i Azure-regioner. En Azure-region är en eller en samling av datacenter som innehåller den maskinvara och infrastruktur som kör och är värd för de olika Azure-tjänsterna. Den här infrastrukturen innehåller ett stort antal noder som fungerar som beräkningsnoder eller lagringsnoder, eller som kör nätverksfunktioner.

En lista över de olika Azure-regionerna finns i artikeln Geografiska områden i Azure. Alla Azure-regioner erbjuder inte samma tjänster. Beroende på vilken SAP-produkt du vill köra och vilket operativsystem och DBMS som är relaterat till den kan du hamna i en situation där en viss region inte erbjuder de VM-typer som du behöver. Detta gäller särskilt vid körning SAP HANA, där du vanligtvis behöver virtuella datorer i M/Mv2 VM-serien. Dessa VM-familjer distribueras endast i en delmängd av regionerna. Du kan ta reda på vilka exakta virtuella datorer, typer, Azure-lagringstyper eller andra Azure-tjänster som är tillgängliga i vilka av regionerna med hjälp av webbplatsen Products available by region (Produkter tillgängliga per region). När du börjar planera och har vissa regioner i åtanke som primär region och slutligen sekundär region måste du först undersöka om de nödvändiga tjänsterna är tillgängliga i dessa regioner.

Tillgänglighetszoner

Flera av Azure-regionerna implementerade ett koncept som kallas Tillgänglighetszoner. Tillgänglighetszoner är fysiskt separata platser i en Azure-region. Varje tillgänglighetszon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverkstjänster. Om du till exempel distribuerar två virtuella datorer över två Tillgänglighetszoner av Azure och implementerar ett ramverk för hög tillgänglighet för ditt SAP DBMS-system eller SAP Central Services får du det bästa serviceavtalet i Azure. För det här specifika serviceavtalet för virtuella datorer i Azure kontrollerar du den senaste versionen av serviceavtalen för virtuella datorer. Eftersom Azure-regioner har utvecklats och utökats snabbt under de senaste åren kan topologin för Azure-regionerna, antalet fysiska datacenter, avståndet mellan dessa datacenter och avståndet mellan Azure-tillgänglighetszoner vara olika. Och med den nätverksfördröjningen.

Principen för Tillgänglighetszoner gäller inte för DEN HANA-specifika tjänsten för hana stora instanser. Serviceavtal för hana stora instanser finns i artikeln serviceavtal för SAP HANA på stora Azure-instanser

Feldomäner

Feldomäner representerar en fysisk felenhet som är nära relaterad till den fysiska infrastruktur som finns i datacenter, och även om ett fysiskt blad eller rack kan betraktas som en feldomän finns det ingen direkt en-till-en-mappning mellan de två.

När du distribuerar flera Virtual Machines som en del av ett SAP-system i Microsoft Azure Virtual Machine Services kan du påverka Azure Fabric Controller att distribuera ditt program till olika feldomäner, vilket uppfyller högre krav på serviceavtal för tillgänglighet. Distributionen av feldomäner över en Azure-skalningsenhet (en samling med hundratals beräkningsnoder eller Storage-noder och nätverk) eller tilldelningen av virtuella datorer till en specifik feldomän är något som du inte har direkt kontroll över. För att dirigera Azure-infrastrukturkontrollanten att distribuera en uppsättning virtuella datorer över olika feldomäner måste du tilldela en Azure-tillgänglighetsuppsättning till de virtuella datorerna vid distributionen. Mer information om tillgänglighetsuppsättningar i Azure finns i kapitel om Tillgänglighetsuppsättningar för Azure i det här dokumentet.

Uppgradera domäner

Uppgraderingsdomäner representerar en logisk enhet som hjälper dig att avgöra hur en virtuell dator i ett SAP-system, som består av SAP-instanser som körs på flera virtuella datorer, uppdateras. När en uppgradering Microsoft Azure genom processen med att uppdatera dessa uppgraderingsdomäner en i Microsoft Azure steg. Genom att sprida virtuella datorer vid distributionen över olika uppgraderingsdomäner kan du delvis skydda ditt SAP-system mot potentiella avbrott. För att tvinga Azure att distribuera de virtuella datorerna i ett SAP-system som är fördelade över olika uppgraderingsdomäner måste du ange ett specifikt attribut vid distributionstiden för varje virtuell dator. Precis som feldomäner är en Azure-skalningsenhet indelad i flera uppgraderingsdomäner. För att dirigera Azure-infrastrukturkontrollanten att distribuera en uppsättning virtuella datorer över olika uppgraderingsdomäner måste du tilldela en Azure-tillgänglighetsuppsättning till de virtuella datorerna vid distributionen. Mer information om tillgänglighetsuppsättningar i Azure finns i kapitel om Tillgänglighetsuppsättningar för Azure nedan.

Tillgänglighetsuppsättningar i Azure

Azure Virtual Machines i en Azure-tillgänglighetsuppsättning distribueras av Azure Fabric Controller över olika fel- och uppgraderingsdomäner. Syftet med distributionen över olika fel- och uppgraderingsdomäner är att förhindra att alla virtuella datorer i ett SAP-system stängs av i händelse av infrastrukturunderhåll eller ett fel inom en feldomän. Som standard är virtuella datorer inte en del av en tillgänglighetsuppsättning. En virtuell dators deltagande i en tillgänglighetsuppsättning definieras vid distributionen eller senare av en omkonfiguration och omdistribution av en virtuell dator.

Information om begreppet Azure-tillgänglighetsuppsättningar och hur tillgänglighetsuppsättningar relaterar till fel- och uppgraderingsdomäner finns i den här artikeln.

När du definierar tillgänglighetsuppsättningar och försöker blanda olika virtuella datorer i olika VM-familjer i en tillgänglighetsuppsättning kan du stöta på problem som hindrar dig från att inkludera en viss VM-typ i en sådan tillgänglighetsuppsättning. Orsaken är att tillgänglighetsuppsättningen är bunden till skalningsenhet som innehåller en viss typ av beräkningsvärdar. Och en viss typ av beräkningsvärd kan bara köra vissa typer av VM-familjer. Om du till exempel skapar en tillgänglighetsuppsättning och distribuerar den första virtuella datorn till tillgänglighetsuppsättningen och väljer en VM-typ av Esv3-familjen och sedan försöker distribuera en virtuell dator i M-familjen som den andra virtuella datorn, avvisas du i den andra allokeringen. Anledningen är att de virtuella datorerna i Esv3-familjen inte körs på samma värdmaskinvara som de virtuella datorerna i M-familjen gör. Samma problem kan uppstå när du försöker ändra storlek på virtuella datorer och försöker flytta en virtuell dator från Esv3-familjen till en vm-typ av M-familj. Vid storleksändring till en VM-familj som inte kan finnas på samma värdmaskinvara måste du stänga av alla virtuella datorer i tillgänglighetsuppsättningen och ändra storlek på dem för att kunna köra på den andra värddatortypen. Serviceavtal för virtuella datorer som distribueras i tillgänglighetsuppsättningen finns i artikeln Serviceavtal för virtuella datorer.

Principen för tillgänglighetsuppsättning och relaterad uppdaterings- och feldomän gäller inte för den HANA-specifika tjänsten för hana stora instanser. Serviceavtal för hana stora instanser finns i artikeln serviceavtal för SAP HANA på stora Azure-instanser.

Parkopplade Azure-regioner

Azure erbjuder Azure-regionpar där replikering av vissa data har aktiverats mellan dessa fasta regionpar. Regionkopplingen dokumenteras i artikeln Affärskontinuum och haveriberedskap (BCDR): Parkopplade Azure-regioner. Som artikeln beskriver är replikeringen av data knutna till Azure-lagringstyper som du kan konfigurera för att replikera till den kopplade regionen. Se även artikeln om Storage redundans i en sekundär region. De lagringstyper som tillåter sådan replikering är lagringstyper, som inte är lämpliga för DBMS-arbetsbelastning. Därför är användbarheten för Azure Storage-replikeringen begränsad till Azure Blob Storage (t.ex. i säkerhetskopieringssyfte) eller andra lagringsscenarier med lång svarstid. När du söker efter parkopplade regioner och de tjänster som du vill använda som primär eller sekundär region kan det uppstå situationer där Azure-tjänster och/eller VM-typer som du tänker använda i din primära region inte är tillgängliga i den parkopplade regionen. Eller så kan du stöta på en situation där den parkopplade Azure-regionen inte är acceptabel av dataefterlevnadsskäl. I dessa fall måste du använda en icke-länkad region som sekundär region/haveriberedskapsregion. I sådana fall måste du vara noga med replikeringen av en del av de data som Azure skulle ha replikerat själv. Ett exempel på hur du replikerar Active Directory och DNS till din haveriberedskapsregion beskrivs i artikeln Konfigurera haveriberedskap för Active Directory och DNS

Tjänster för virtuella Azure-datorer

Azure erbjuder en stor mängd virtuella datorer som du kan välja att distribuera. Det finns inget behov av direkt teknik och infrastrukturinköp. Tjänsterbjudandet för virtuella Azure-datorer förenklar underhåll och drift av program genom att tillhandahålla beräkning och lagring på begäran för att vara värd för, skala och hantera webbprogram och anslutna program. Infrastrukturhantering automatiseras med en plattform som är utformad för hög tillgänglighet och dynamisk skalning för att matcha användningsbehov med alternativet för flera olika prismodeller.

Med virtuella Azure-datorer gör Microsoft att du kan distribuera anpassade serveravbildningar till Azure som IaaS-instanser. Eller så kan du välja bland ett omfattande urval av förbrukningsbara operativsystemavbildningar från Azure Marketplace.

Ur ett driftsperspektiv erbjuder Azure Virtual Machine Service liknande upplevelser som virtuella datorer som distribueras lokalt. Du ansvarar för administration, åtgärder och korrigering av det specifika operativsystemet, som körs på en virtuell Azure-dator och dess program på den virtuella datorn. Microsoft tillhandahåller inte fler tjänster än att vara värd för den virtuella datorn i sin Azure-infrastruktur (infrastruktur som en tjänst – IaaS). För SAP-arbetsbelastningar som du som kund distribuerar har Microsoft inga erbjudanden utöver IaaS-erbjudandena.

Plattformen Microsoft Azure är en plattform för flera innehavare. Därför delas lagrings-, nätverks- och beräkningsresurser som är värdar för virtuella Azure-datorer, med några få undantag, mellan klienter. Intelligent begränsnings- och kvotlogik används för att förhindra att en klientorganisation påverkar prestanda för en annan klient (störande granne) på ett drastiskt sätt. I synnerhet för att certifiera Azure-plattformen för SAP HANA måste Microsoft bevisa resursisoleringen för fall där flera virtuella datorer regelbundet kan köras på samma värd till SAP. Även om logiken i Azure försöker hålla avvikelser i bandbredden liten, tenderar mycket delade plattformar att introducera större avvikelser i tillgängligheten för resurser/bandbredd än vad kunderna kan uppleva i sina lokala distributioner. Sannolikheten att ett SAP-system i Azure kan uppleva större avvikelser än i ett lokalt system måste beaktas.

Virtuella Azure-datorer för SAP-arbetsbelastning

För SAP-arbetsbelastning begränsade vi valet till olika VM-familjer som är lämpliga för SAP-arbetsbelastning och SAP HANA arbetsbelastning mer specifikt. Hur du hittar rätt typ av virtuell dator och dess möjlighet att arbeta med SAP-arbetsbelastning beskrivs i dokumentet Vilken SAP-programvara stöds för Azure-distributioner?

Utöver valet av helt stödda VM-typer måste du också kontrollera om dessa typer av virtuella datorer är tillgängliga i en specifik region baserat på webbplatsen Produkter som är tillgängliga per region. Men ännu viktigare är att du utvärderar om:

• PROCESSOR- och minnesresurser av olika typer av virtuella datorer
• IOPS-bandbredd för olika typer av virtuella datorer
• Nätverksfunktioner för olika typer av virtuella datorer
• Antal diskar som kan kopplas
• Möjlighet att utnyttja vissa Azure-lagringstyper

passar dina behov. De flesta av dessa data finns här (Linux) och här (Windows) för en viss typ av virtuell dator.

Som prismodell har du flera olika prisalternativ som listar:

• Betala per användning
• Reserverat ett år
• Reserverat i tre år
• Spotprissättning

Prissättningen för var och en av de olika erbjudandena med olika tjänsterbjudanden för operativsystem och olika regioner finns på webbplatsen Virtuella Linux-datorer Priser Windows Virtual Machines Priser. Mer information och flexibilitet för ett och tre års reserverade instanser finns i följande artiklar:

• Vad är Azure-reservationer?
• Flexibel storlek för virtuella datorer med reserverade VM-instanser
• Så tillämpas rabatten för Azure-reservation på virtuella datorer

Mer information om spotpriser finns i artikeln Azure Spot Virtual Machines. Prissättning av samma VM-typ kan också skilja sig mellan olika Azure-regioner. För vissa kunder var det värt att distribuera till en billigare Azure-region.

Dessutom erbjuder Azure koncepten för en dedikerad värd. Det dedikerade värdkonceptet ger dig mer kontroll över korrigeringar av cykler som utförs av Azure. Du kan schemalägga korrigeringen enligt dina egna scheman. Det här erbjudandet riktar sig specifikt till kunder med arbetsbelastningar som kanske inte följer den normala arbetsbelastningscykeln. Om du vill läsa mer om begreppen för dedikerade värderbjudanden i Azure kan du läsa artikeln Azure Dedicated Host. Det här erbjudandet stöds för SAP-arbetsbelastning och används av flera SAP-kunder som vill ha mer kontroll över uppdatering av infrastruktur och eventuella underhållsplaner för Microsoft. Mer information om hur Microsoft underhåller och korrigeringar av Den Azure-infrastruktur som är värd för virtuella datorer finns i artikeln Underhåll för virtuella datorer i Azure.

Virtuella datorer av första och andra generationen

Microsofts hypervisor-program kan hantera två olika generationer av virtuella datorer. Dessa format kallas Generation 1 och Generation 2. Generation 2 introducerades 2012 med en Windows Server 2012 hypervisor. Azure började använda virtuella datorer i generation 1. När du distribuerar virtuella Azure-datorer är standardvärdet fortfarande att använda generation 1-formatet. Under tiden kan du även distribuera VM-format av andra generationen. Artikeln Support for generation 2 VMs on Azure (Stöd för virtuella datorer i generation 2 på Azure) innehåller en lista över de Azure VM-familjer som kan distribueras som virtuella datorer i generation 2. Den här artikeln innehåller också viktiga funktionella skillnader mellan virtuella datorer i generation 2 eftersom de kan köras i privata Hyper-V-moln och Azure. Den här artikeln innehåller också en lista över funktionella skillnader mellan virtuella datorer i generation 1 och virtuella datorer i generation 2, eftersom de körs i Azure.

Det går inte att flytta en befintlig virtuell dator från en generation till den andra generationen. Om du vill ändra genereringen av den virtuella datorn måste du distribuera en ny virtuell dator av den generation du önskar och installera om programvaran som du kör på den virtuella datorn för genereringen. Den här ändringen påverkar bara den virtuella datorns bas-VHD-avbildning och har ingen inverkan på datadiskarna eller anslutna NFS- eller SMB-resurser. Datadiskar, NFS- eller SMB-resurser som ursprungligen tilldelades till, till exempel på en virtuell dator i generation 1.

Storage: Microsoft Azure Storage och datadiskar

Microsoft Azure Virtual Machines använder olika lagringstyper. När du SAP på Azure Virtual Machine Services är det viktigt att förstå skillnaderna mellan dessa två huvudtyper av lagring:

• Icke-beständig, beständig lagring.
• Beständig lagring.

Virtuella Azure-datorer erbjuder icke-beständiga diskar när en virtuell dator har distribuerats. Vid omstart av den virtuella datorn rensas allt innehåll på enheterna. Därför är det givet att datafiler och logg-/gör om-filer för databaser under inga omständigheter ska finnas på dessa icke-beständiga enheter. Det kan finnas undantag för vissa databaser, där dessa icke-beständiga enheter kan vara lämpliga för tempdb- och temp-tabellrymder. Undvik dock att använda dessa enheter för virtuella datorer i A-serien eftersom dessa icke-beständiga enheter har begränsat dataflöde med den virtuella datorfamiljen. Mer information finns i artikeln Understanding the temporary drive on Windows VMs in Azure (Förstå den tillfälliga enheten på virtuella Windows i Azure)

Windows

Enhet D:\ på en virtuell Azure-dator är en icke-bestående enhet som backas upp av vissa lokala diskar på Azure-beräkningsnoden. Eftersom den inte är bestående innebär det att alla ändringar som gjorts i innehållet på D:\ enheten går förlorad när den virtuella datorn startas om. Av "ändringar", t.ex. lagrade filer, skapade kataloger, installerade program osv.

Linux

Virtuella Linux Azure-datorer monterar automatiskt en enhet vid /mnt/resource som är en icke-bestående enhet som backas upp av lokala diskar på Azure-beräkningsnoden. Eftersom den inte är bestående innebär det att alla ändringar som görs i innehållet i /mnt/resource går förlorade när den virtuella datorn startas om. Av ändringar, t.ex. lagrade filer, skapade kataloger, installerade program osv.

Azure Storage-konton

När du distribuerar tjänster eller virtuella datorer i Azure ordnas distributionen av virtuella hårddiskar och VM-avbildningar i enheter som Azure Storage konton. Azure Storage-konton har antingen begränsningar i IOPS, dataflöde eller storlekar som de kan innehålla. Tidigare har dessa begränsningar dokumenterats i:

• Skalbarhetsmål för standardlagringskonton
• Skalbarhetsmål för Blob Storage-konton på premiumsidan

spela en viktig roll vid planeringen av en SAP-distribution i Azure. Det var på dig att hantera antalet bestående diskar i ett lagringskonto. Du behövde hantera lagringskontona och så småningom skapa nya lagringskonton för att skapa mer beständiga diskar.

Under de senaste åren har du avlösts av de här uppgifterna när du införde Azure Managed Disks. Rekommendationen för SAP-distributioner är att använda Azure Managed Disks i stället för att hantera Azure Storage-konton själv. Azure-hanterade diskar distribuerar diskar över olika lagringskonton, så att gränserna för de enskilda lagringskontona inte överskrids.

I ett lagringskonto har du en typ av mappbegrepp som kallas "containrar" som kan användas för att gruppera vissa diskar i specifika containrar.

I Azure följer ett disk-/VHD-namn följande namngivningsanslutning som måste ange ett unikt namn för den virtuella hårddisken i Azure:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Strängen ovan måste unikt identifiera den disk/VHD som lagras på Azure Storage.

Ständiga Lagringstyper i Azure

Azure erbjuder en mängd olika ständiga lagringsalternativ som kan användas för SAP-arbetsbelastningar och specifika SAP Stack-komponenter. Mer information finns i dokumentet Azure Storage för SAP-arbetsbelastningar.

Microsoft Azure Nätverk

Microsoft Azure tillhandahåller en nätverksinfrastruktur som möjliggör mappning av alla scenarier som vi vill realisera med SAP-programvara. Funktionerna är:

• Åtkomst utifrån, direkt till de virtuella datorerna via Windows-terminal Services eller ssh/VNC
• Åtkomst till tjänster och specifika portar som används av program på de virtuella datorerna
• Intern kommunikation och namnmatchning mellan en grupp virtuella datorer som distribuerats som virtuella Azure-datorer
• Anslutning på flera platser mellan en kunds lokala nätverk och Azure-nätverket
• Anslutning mellan Azure-regioner eller datacenter mellan Azure-platser

Mer information finns här: https://azure.microsoft.com/documentation/services/virtual-network/

Det finns många olika möjligheter att konfigurera namn och IP-upplösning i Azure. Det finns också en Azure DNS tjänst som kan användas i stället för att konfigurera en egen DNS-server. Mer information finns i den här artikeln och på den här sidan.

För scenarier på flera platser eller hybridscenarier förlitar vi oss på det faktum att den lokala AD/OpenLDAP/DNS har utökats via VPN eller privat anslutning till Azure. För vissa scenarier som beskrivs här kan det vara nödvändigt att ha en AD/OpenLDAP-replik installerad i Azure.

Eftersom nätverks- och namnmatchning är en viktig del av databasdistributionen för ett SAP-system beskrivs det här begreppet i detalj i DBMS-distributionsguiden.

Azure Virtual Networks

Genom att skapa en Azure Virtual Network kan du definiera adressintervallet för de privata IP-adresser som allokeras av Azure DHCP-funktioner. I scenarier mellan olika platser allokeras det definierade IP-adressintervallet fortfarande med DHCP av Azure. Domännamnsmatchning görs dock lokalt (förutsatt att de virtuella datorerna ingår i en lokal domän) och därför kan lösa adresser utöver olika Azure Cloud Services.

Varje virtuell dator i Azure måste vara ansluten till en Virtual Network.

Mer information finns i den här artikeln och på den här sidan.

MAC-adressen för det virtuella nätverkskortet kan ändras, till exempel efter storleksändringen och Windows- eller Linux-gästoperativsystemet hämtar det nya nätverkskortet och använder automatiskt DHCP för att tilldela IP- och DNS-adresser i det här fallet.

Statisk IP-tilldelning

Det är möjligt att tilldela fasta eller reserverade IP-adresser till virtuella datorer i en Azure-Virtual Network. Genom att köra de virtuella datorerna i en Azure Virtual Network kan du använda den här funktionen om det behövs eller krävs för vissa scenarier. IP-tilldelningen är giltig under hela förekomsten av den virtuella datorn, oberoende av om den virtuella datorn körs eller stängs av. Därför måste du ta hänsyn till det totala antalet virtuella datorer (virtuella datorer som körs och stoppas) när du definierar ip-adressintervallet för Virtual Network. IP-adressen förblir tilldelad antingen tills den virtuella datorn och dess nätverksgränssnitt tas bort eller tills IP-adressen av tilldelas igen. Mer information finns i den här artikeln.

Sekundära IP-adresser för SAP-värddatornamnvirtualisering

Varje Virtuell Azure-dators nätverkskort kan ha flera tilldelade IP-adresser. Den här sekundära IP-adressen kan användas för virtuella SAP-värdnamn som mappas till en DNS A/PTR-post om det behövs. De sekundära IP-adresserna måste tilldelas till Azure vNIC IP-konfiguration enligt den här artikeln och även konfigureras i operativsystemet eftersom sekundära IP-adresser inte tilldelas via DHCP. Varje sekundär IP-adress måste vara från samma undernät som det virtuella nätverkskortet är bundet till. Användning av Azure Load Balancer flytande IP stöds inte sekundär för sekundära IP-konfigurationer som pacemakerkluster. I det här fallet aktiverar IP-adressen för Load Balancer de virtuella SAP-värdnamnen. Se även SAP:s anteckning #962955 om allmänna riktlinjer med hjälp av virtuella värdnamn.

Flera nätverkskort per virtuell dator

Du kan definiera flera virtuella nätverkskort (vNIC) för en virtuell Azure-dator. Med möjligheten att ha flera virtuella nätverkskort kan du börja konfigurera nätverkstrafikseparation där till exempel klienttrafik dirigeras via ett vNIC och backend-trafik dirigeras via ett andra vNIC. Beroende på typen av virtuell dator finns det olika begränsningar för antalet virtuella nätverkskort som en virtuell dator kan ha tilldelats. Exakt information, funktioner och begränsningar finns i följande artiklar:

• Skapa en Windows virtuell dator med flera nätverkskort
• Skapa en virtuell Linux-dator med flera nätverkskort
• Distribuera virtuella datorer med flera nätverkskort med hjälp av en mall
• Distribuera virtuella datorer med flera nätverkskort med PowerShell
• Distribuera virtuella datorer med flera nätverkskort med Hjälp av Azure CLI

Plats-till-plats-anslutning

Lokalt är virtuella Azure-datorer och lokala länkade med en transparent och permanent VPN-anslutning. Det förväntas bli det vanligaste SAP-distributionsmönstret i Azure. Antagandet är att operativa procedurer och processer med SAP-instanser i Azure ska fungera transparent. Det innebär att du bör kunna skriva ut från dessa system och använda SAP Transport Management System (TMS) för att transportera ändringar från ett utvecklingssystem i Azure till ett testsystem som distribueras lokalt. Mer dokumentation om plats-till-plats finns i den här artikeln

VPN Tunnel enhet

För att kunna skapa en plats-till-plats-anslutning (lokalt datacenter till Azure-datacenter) måste du antingen skaffa och konfigurera en VPN-enhet eller använda routnings- och fjärråtkomsttjänsten (RRAS) som introducerades som en programvarukomponent med Windows Server 2012.

• Skapa ett virtuellt nätverk med en VPN-anslutning från plats till plats med Hjälp av PowerShell
• Om VPN-enheter för VPN Gateway-anslutningar från plats till plats
• Vanliga frågor och svar om VPN Gateway

Bilden ovan visar två Azure-prenumerationer som har IP-adressunderintervall som är reserverade för användning i virtuella nätverk i Azure. Anslutningen från det lokala nätverket till Azure upprättas via VPN.

Punkt-till-plats-VPN

Punkt-till-plats-VPN kräver att varje klientdator ansluter med sitt eget VPN till Azure. I SAP-scenarierna tittar vi på punkt-till-plats-anslutning är inte praktiskt. Därför ges inga ytterligare referenser till punkt-till-plats-VPN-anslutning.

Mer information finns här

• Konfigurera en punkt-till-plats-anslutning till ett VNet med Azure Portal
• Konfigurera en punkt-till-plats-anslutning till ett VNet med hjälp av PowerShell

VPN för flera webbplatser

Azure erbjuder numera också möjligheten att skapa VPN-anslutningar för flera webbplatser för en Azure-prenumeration. Tidigare var en enskild prenumeration begränsad till en plats-till-plats-VPN-anslutning. Den här begränsningen har gått bort med VPN-anslutningar för flera webbplatser för en enda prenumeration. Detta gör det möjligt att utnyttja mer än en Azure-region för en specifik prenumeration via konfigurationer på flera platser.

Mer dokumentation finns i den här artikeln

VNet-till-VNet-anslutning

Med hjälp av VPN för flera webbplatser måste du konfigurera en separat Azure-Virtual Network i var och en av regionerna. Ofta har du dock kravet att programvarukomponenterna i de olika regionerna ska kommunicera med varandra. Den här kommunikationen bör helst inte dirigeras från en Azure-region till den lokala regionen och därifrån till den andra Azure-regionen. Som genväg erbjuder Azure möjligheten att konfigurera en anslutning från en Azure-Virtual Network i en region till en annan Azure-Virtual Network i en annan region. Den här funktionen kallas VNet-till-VNet-anslutning. Mer information om den här funktionen finns här: https://azure.microsoft.com/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/ .

Privat anslutning till Azure ExpressRoute

Microsoft Azure Med ExpressRoute kan du skapa privata anslutningar mellan Azure-datacenter och antingen kundens lokala infrastruktur eller i en samlokal miljö. ExpressRoute erbjuds av olika MPLS(paket växlade) VPN-leverantörer eller andra nätverkstjänstleverantörer. ExpressRoute-anslutningar går inte via offentligt Internet. ExpressRoute-anslutningar ger högre säkerhet, bättre tillförlitlighet via flera parallella kretsar, snabbare hastigheter och kortare svarstider än vanliga anslutningar via Internet.

Mer information om Azure ExpressRoute och erbjudanden finns här:

• https://azure.microsoft.com/documentation/services/expressroute/
• https://azure.microsoft.com/pricing/details/expressroute/
• https://azure.microsoft.com/documentation/articles/expressroute-faqs/

Express Route möjliggör flera Azure-prenumerationer via en ExpressRoute-krets enligt dokumenten här

• https://azure.microsoft.com/documentation/articles/expressroute-howto-linkvnet-arm/
• https://azure.microsoft.com/documentation/articles/expressroute-howto-circuit-arm/

Tvingad tunneling i händelse av flera platser

För att virtuella datorer ska kunna ansluta till lokala domäner via plats-till-plats, punkt-till-plats eller ExpressRoute måste du se till att Internetproxyinställningarna distribueras även för alla användare på de virtuella datorerna. Som standard går programvara som körs på de virtuella datorerna eller användare som använder en webbläsare för att få åtkomst till Internet inte via företagets proxy, utan ansluter direkt via Azure till Internet. Men inte ens proxyinställningen är en 100 % lösning för att dirigera trafiken via företagets proxy eftersom det är programvarans och tjänsternas ansvar att söka efter proxyn. Om programvara som körs på den virtuella datorn inte gör det eller om en administratör ändrar inställningarna, kan trafiken till Internet tas bort igen direkt via Azure till Internet.

För att undvika en sådan direkt Internetanslutning kan du konfigurera tvingad tunneling med plats-till-plats-anslutning mellan den lokala platsen och Azure. Den detaljerade beskrivningen av funktionen Tvingad tunneling publiceras här https://azure.microsoft.com/documentation/articles/vpn-gateway-forced-tunneling-rm/

Tvingad tunnel med ExpressRoute aktiveras av kunder som annonserar en standardväg via ExpressRoute BGP-peeringsessioner.

Sammanfattning av Azure-nätverk

Det här kapitlet innehöll många viktiga punkter om Azure-nätverkstjänster. Här är en sammanfattning av huvudpunkterna:

• Med virtuella Azure-nätverk kan du lägga till en nätverksstruktur i din Azure-distribution. Virtuella nätverk kan isoleras mot varandra eller med hjälp av nätverkssäkerhetsgruppers trafik mellan virtuella nätverk kan styras.
• Virtuella Azure-nätverk kan användas för att tilldela IP-adressintervall till virtuella datorer eller tilldela fasta IP-adresser till virtuella datorer
• Om du vill konfigurera en plats-till-plats- eller punkt-till-plats-anslutning måste du skapa en Azure-Virtual Network först
• När en virtuell dator har distribuerats går det inte längre att ändra den Virtual Network tilldelats den virtuella datorn

Kvoter i tjänster för virtuella Azure-datorer

Vi måste vara tydliga med det faktum att lagrings- och nätverksinfrastrukturen delas mellan virtuella datorer som kör en mängd olika tjänster i Azure-infrastrukturen. Precis som i kundens egna datacenter sker överetablering av vissa infrastrukturresurser till en viss grad. Plattformen Microsoft Azure använder disk, CPU, nätverk och andra kvoter för att begränsa resursförbrukningen och för att bevara konsekventa och deterministiska prestanda. De olika typerna av virtuella datorer (A5, A6 osv.) har olika kvoter för antalet diskar, CPU, RAM och nätverk.

Vid planering och storleksändring SAP på Azure lösningar måste kvoter för varje storlek på den virtuella datorn beaktas. VM-kvoter beskrivs här (Linux) och här (Windows).

De kvoter som beskrivs representerar de teoretiska maxvärdena. Gränsen för IOPS per disk kan uppnås med liten I/O (8 kB) men kan eventuellt inte uppnås med stora I/Os (1 MB). IOPS-gränsen tillämpas på kornigheten för en enskild disk.

Som ett ungefärligt beslutsträd för att avgöra om ett SAP-system passar in i Azure Virtual Machine Services och dess funktioner eller om ett befintligt system måste konfigureras på olika sätt för att distribuera systemet i Azure kan beslutsträdet nedan användas:

1. Den viktigaste informationen att börja med är SAPS-kravet för ett visst SAP-system. SAPS-kraven måste delas upp i DBMS-delen och SAP-programdelen, även om SAP-systemet redan har distribuerats lokalt i en konfiguration på två nivåer. För befintliga system kan SAPS som är relaterade till maskinvaran som används ofta fastställas eller beräknas baserat på befintliga SAP-benchmarks. Resultaten finns på sidan Om SAP Standard Application Benchmarks. För nyligen distribuerade SAP-system bör du ha gått igenom en storleksövning som bör fastställa SAPS-kraven för systemet.
2. För befintliga system bör I/O-volymen och I/O-åtgärder per sekund på DBMS-servern mätas. För nyligen planerade system bör storleksövningen för det nya systemet också ge ungefärliga idéer om I/O-kraven på DBMS-sidan. Om du är osäker måste du så småningom utföra ett proof of Concept.
3. Jämför SAPS-kravet för DBMS-servern med de SAPS som de olika vm-typerna av Azure kan tillhandahålla. Informationen om SAPS för de olika typerna av virtuella Azure-datorer dokumenteras i SAP Note 1928533. Fokus bör ligga på den virtuella DBMS-datorn först eftersom databaslagret är lagret i ett SAP NetWeaver-system som inte skalas ut i de flesta distributioner. SAP-programlagret kan däremot skalas ut. Om ingen av de SAP-vm-typer som stöds kan leverera nödvändiga SAPS kan inte arbetsbelastningen i det planerade SAP-systemet köras på Azure. Du måste antingen distribuera systemet lokalt eller ändra arbetsbelastningsvolymen för systemet.
4. Enligt beskrivningen här (Linux) och här (Windows)tillämpar Azure en IOPS-kvot per disk oberoende av om du använder Standard Storage eller Premium Storage. Beroende på typen av virtuell dator varierar antalet datadiskar som kan monteras. Därför kan du beräkna ett maximalt IOPS-tal som kan uppnås med var och en av de olika typerna av virtuella datorer. Beroende på databasens fillayout kan du stripe-diskar bli en volym i gästoperativsystemet. Men om den aktuella IOPS-volymen i ett distribuerat SAP-system överskrider de beräknade gränserna för den största VM-typen av Azure, och om det inte finns någon chans att kompensera för mer minne, kan arbetsbelastningen i SAP-systemet påverkas allvarligt. I sådana fall kan du komma till en punkt där du inte bör distribuera systemet i Azure.
5. Särskilt i SAP-system, som distribueras lokalt i konfigurationer med två nivåer, är sannolikheten att systemet kan behöva konfigureras i Azure i en konfiguration med 3 nivåer. I det här steget måste du kontrollera om det finns en komponent i SAP-programlagret som inte kan skalas ut och som inte passar in i processor- och minnesresurserna som de olika typerna av virtuella Azure-datorer erbjuder. Om det verkligen finns en sådan komponent kan INTE SAP-systemet och dess arbetsbelastning distribueras till Azure. Men om du kan skala ut SAP-programkomponenterna till flera virtuella Azure-datorer kan systemet distribueras till Azure.

Om DBMS- och SAP-programlagerkomponenterna kan köras på virtuella Azure-datorer måste konfigurationen definieras med avseende på:

• Antal virtuella Azure-datorer
• VM-typer för enskilda komponenter
• Antal virtuella hårddiskar i DBMS VM för att tillhandahålla tillräckligt med IOPS

Hantera Azure-tillgångar

Azure Portal

Den Azure Portal är ett av tre gränssnitt för att hantera distributioner av virtuella Azure-datorer. De grundläggande hanteringsuppgifterna, som att distribuera virtuella datorer från avbildningar, kan utföras via Azure Portal. Dessutom är skapandet av Storage-konton, virtuella nätverk och andra Azure-komponenter också uppgifter som Azure Portal kan hantera bra. Funktioner som att ladda upp virtuella hårddiskar från en lokal plats till Azure eller kopiera en virtuell hårddisk i Azure är dock uppgifter som kräver antingen verktyg från tredje part eller administration via PowerShell eller CLI.

Administration och konfigurationsuppgifter för den virtuella datorinstansen är möjliga inifrån Azure Portal.

Förutom att starta om och stänga av en virtuell dator kan du också ansluta, koppla från och skapa datadiskar för instansen av den virtuella datorn för att avbilda instansen för avbildningsförberedelse och konfigurera storleken på den virtuella datorinstansen.

I Azure Portal grundläggande funktioner för att distribuera och konfigurera virtuella datorer och många andra Azure-tjänster. Alla tillgängliga funktioner omfattas dock inte av Azure Portal. I Azure Portal går det inte att utföra uppgifter som:

• Ladda upp virtuella hårddiskar till Azure
• Kopiera virtuella datorer

Hantering via Microsoft Azure PowerShell-cmdlets

Windows PowerShell är ett kraftfullt och utökningsbart ramverk som har implementerats av kunder som distribuerar ett större antal system i Azure. Efter installationen av PowerShell-cmdlets på en stationär dator, bärbar dator eller dedikerad hanteringsstation kan PowerShell-cmdletarna köras via fjärrstyrning.

Processen för att aktivera en lokal stationär/bärbar dator för användning av Azure PowerShell-cmdlets och hur du konfigurerar dem för användning med Azure-prenumerationerna beskrivs i den här artikeln.

Mer detaljerade anvisningar om hur du installerar, uppdaterar och konfigurerar Azure PowerShell-cmdlets finns också i Installera Azure PowerShell-modulen. Kundupplevelsen hittills har varit att PowerShell verkligen är det kraftfullare verktyget för att distribuera virtuella datorer och skapa anpassade steg i distributionen av virtuella datorer. Alla kunder som kör SAP-instanser i Azure använder PowerShell-cmdlets för att komplettera hanteringsuppgifter som de utför i Azure Portal eller till och med använder PowerShell-cmdlets exklusivt för att hantera sina distributioner i Azure. Eftersom Azure-specifika cmdlets delar samma namngivningskonvention som de mer än 2 000 Windows-relaterade cmdletarna är det enkelt för Windows-administratörer att utnyttja dessa cmdlets.

Se exempel här: https://blogs.technet.com/b/keithmayer/archive/2015/07/07/18-steps-for-end-to-end-iaas-provisioning-in-the-cloud-with-azure-resource-manager-arm-powershell-and-desired-state-configuration-dsc.aspx

Distribution av Azure-tillägget för SAP (se kapitlet Azure-tillägg för SAP i det här dokumentet) är endast möjligt via PowerShell eller CLI. Därför är det obligatoriskt att konfigurera PowerShell eller CLI när du distribuerar eller administrerar ett SAP NetWeaver-system i Azure.

Eftersom Azure tillhandahåller fler funktioner kommer nya PowerShell-cmdlets att läggas till som kräver en uppdatering av cmdletarna. Därför är det klokt att kontrollera Azure Download-webbplatsen minst en gång i månaden https://azure.microsoft.com/downloads/ för en ny version av cmdletarna. Den nya versionen installeras ovanpå den äldre versionen.

En allmän lista över Azure-relaterade PowerShell-kommandon finns här: Azure PowerShell dokumentation.

Hantering via Microsoft Azure CLI-kommandon

För kunder som använder Linux och vill hantera Azure-resurser är PowerShell kanske inte ett alternativ. Microsoft erbjuder Azure CLI som ett alternativ. Azure CLI tillhandahåller en uppsättning plattformsoberoende kommandon med öppen källkod för att arbeta med Azure-plattformen. Azure CLI innehåller ungefär samma funktioner som finns i Azure Portal.

Information om installation, konfiguration och hur du använder CLI-kommandon för att utföra Azure-uppgifter finns i

• Installera klassiska Azure CLI
• Installera Azure CLI 2.0
• Distribuera och hantera virtuella datorer med hjälp Azure Resource Manager-mallar och Azure CLI
• Använd klassiska Azure CLI för Mac, Linux och Windows med Azure Resource Manager

De första stegen för att planera en distribution

Det första steget i distributionsplaneringen är INTE att söka efter virtuella datorer som är tillgängliga för att köra SAP. Det första steget kan vara ett som är tidskrävande, men det viktigaste, är att arbeta med efterlevnads- och säkerhetsteam i företaget för att se vilka gränsvillkor som gäller för distribution av vilken typ av SAP-arbetsbelastning eller affärsprocess till det offentliga molnet. Om ditt företag har distribuerat annan programvara tidigare till Azure kan processen vara enkel. Om ditt företag är mer i början av resan kan det finnas större diskussioner som krävs för att ta reda på gränsvillkoren, säkerhetsvillkoren, som tillåter att vissa SAP-data och SAP-affärsprocesser finns i det offentliga molnet.

Som användbar hjälp kan du peka på Microsofts efterlevnadserbjudanden för en lista över efterlevnadserbjudanden som Microsoft kan erbjuda.

Andra problemområden som datakryptering för vilodata eller annan kryptering i Azure-tjänsten dokumenteras i Översikt över Azure-kryptering.

Underskatta inte den här fasen av projektet i planeringen. Det är först när du har avtal och regler kring det här ämnet som du behöver gå till nästa steg, som är planeringen av den nätverksarkitektur som du distribuerar i Azure.

Olika sätt att distribuera virtuella datorer för SAP i Azure

I det här kapitlet lär du dig olika sätt att distribuera en virtuell dator i Azure. Ytterligare förberedelseprocedurer samt hantering av virtuella hårddiskar och virtuella datorer i Azure tas upp i det här kapitlet.

Distribution av virtuella datorer för SAP

Microsoft Azure finns flera sätt att distribuera virtuella datorer och associerade diskar. Det är därför viktigt att förstå skillnaderna eftersom förberedelserna för de virtuella datorerna kan variera beroende på distributionsmetoden. I allmänhet tar vi en titt på följande scenarier:

Flytta en virtuell dator från en lokal plats till Azure med en icke-generaliserad disk

Du planerar att flytta ett specifikt SAP-system från en lokal plats till Azure. Detta kan göras genom att ladda upp den virtuella hårddisken, som innehåller operativsystemet, SAP-binärfilerna och DBMS-binärfilerna plus de virtuella hårddiskarna med data och loggfiler för DBMS till Azure. Till skillnad från scenario nr 2nedan behåller du värdnamnet, SAP SID och SAP-användarkontona på den virtuella Azure-datorn som de konfigurerades i den lokala miljön. Därför är det inte nödvändigt att generalisera avbildningen. Se kapitel Förberedelser för att flytta en virtuell dator från en lokal plats till Azure med en icke-generaliserad disk i det här dokumentet för lokala förberedelsesteg och uppladdning av icke-generaliserade virtuella datorer eller virtuella hårddiskar till Azure. Läs kapitlet Scenario 3: Flytta en virtuell dator från en lokal plats med hjälp av en icke-generaliserad virtuell Azure-hårddisk med SAP i distributionsguiden för detaljerade steg för att distribuera en sådan avbildning i Azure.

Ett annat alternativ som vi inte diskuterar i detalj i den här guiden är att använda Azure Site Recovery för att replikera SAP NetWeaver-programservrar och SAP NetWeaver Central Services till Azure. Vi rekommenderar inte att du använder Azure Site Recovery för databaslagret och i stället använder databasspecifika replikeringsmekanismer som HANA-systemreplikering. Mer information finns i avsnittet Skydda SAP i guiden Om haveriberedskap för lokala appar.

Distribuera en virtuell dator med en kundspecifik avbildning

På grund av specifika korrigeringskrav för operativsystemet eller DBMS-versionen kanske de tillhandahållna avbildningarna i Azure Marketplace inte passar dina behov. Därför kan du behöva skapa en virtuell dator med din egen privata OS/DBMS VM-avbildning, som kan distribueras flera gånger efteråt. För att förbereda en sådan privat avbildning för duplicering måste följande saker övervägas:

Windows

Mer information finns i Upload en generaliserad Windows VHD och använda den för att skapa nya virtuella datorer i Azure. Windows-inställningarna (till exempel Windows SID och värdnamn) måste abstraheras/generaliseras på den lokala virtuella datorn via kommandot sysprep.

Linux

Följ stegen som beskrivs i de här artiklarna för SUSE, Red Hateller Oracle Linuxför att förbereda en virtuell hårddisk som ska laddas upp till Azure.

Om du redan har installerat SAP-innehåll på din lokala virtuella dator (särskilt för system med två nivåer) kan du anpassa SAP-systeminställningarna efter distributionen av den virtuella Azure-datorn via proceduren för att byta namn på instansen som stöds av SAP Software Provisioning Manager (SAP Note [1619720).] Se kapitel Förberedelser för att distribuera en virtuell dator med en kundspecifik avbildning för SAP och Ladda upp en virtuell hårddisk från en lokal plats till Azure i det här dokumentet för steg för lokal förberedelse och uppladdning av en generaliserad virtuell dator till Azure. Läs kapitlet Scenario 2: Distribuera en virtuell dator med en anpassad avbildning för SAP i distributionsguiden för detaljerade steg för att distribuera en sådan avbildning i Azure.

Distribuera en virtuell dator från Azure Marketplace

Du vill använda en vm-avbildning från Microsoft eller tredje part från Azure Marketplace för att distribuera den virtuella datorn. När du har distribuerat den virtuella datorn i Azure följer du samma riktlinjer och verktyg för att installera SAP-programvaran och/eller DBMS på den virtuella datorn som i en lokal miljö. Mer detaljerad distributionsbeskrivning finns i kapitel Scenario 1: Distribuera en virtuell dator från Azure Marketplace för SAP i distributionsguiden.

Förbereda virtuella datorer med SAP för Azure

Innan du laddar upp virtuella datorer till Azure måste du se till att de virtuella datorerna och de virtuella hårddiskarna uppfyller vissa krav. Det finns små skillnader beroende på vilken distributionsmetod som används.

Förberedelse för att flytta en virtuell dator från en lokal plats till Azure med en icke-generaliserad disk

En vanlig distributionsmetod är att flytta en befintlig virtuell dator som kör ett SAP-system från en lokal plats till Azure. Den virtuella datorn och SAP-systemet på den virtuella datorn ska bara köras i Azure med samma värdnamn och förmodligen samma SAP SID. I det här fallet bör gästoperativsystemet för den virtuella datorn inte generaliseras för flera distributioner. Om det lokala nätverket har utökats till Azure kan även samma domänkonton användas på den virtuella datorn som de som användes före den lokala datorn.

Krav när du förbereder din egen Azure VM-disk är:

• Ursprungligen kunde den virtuella hårddisk som innehåller operativsystemet ha en maximal storlek på 127 GB. Den här begränsningen eliminerades i slutet av mars 2015. Nu kan den virtuella hårddisk som innehåller operativsystemet vara upp till 1 TB stor som vilken virtuell hårddisk Azure Storage värd som helst.
• Det måste vara i fast VHD-format. Dynamiska virtuella hårddiskar eller virtuella hårddiskar i VHDx-format stöds ännu inte i Azure. Dynamiska virtuella hårddiskar konverteras till statiska virtuella hårddiskar när du laddar upp den virtuella hårddisken med PowerShell-kommandon eller CLI
• Virtuella hårddiskar, som monteras på den virtuella datorn och ska monteras igen i Azure till den virtuella datorn, måste också ha ett fast VHD-format. Läs den här artikeln om storleksbegränsningar för datadiskar. Dynamiska virtuella hårddiskar konverteras till statiska virtuella hårddiskar när du laddar upp den virtuella hårddisken med PowerShell-kommandon eller CLI
• Lägg till ett annat lokalt konto med administratörsbehörighet, som kan användas av Microsoft Support eller som kan tilldelas som kontext för tjänster och program som ska köras i tills den virtuella datorn har distribuerats och lämpligare användare kan användas.
• Lägg till andra lokala konton eftersom de kan behövas för det specifika distributionsscenariot.

Windows

I det här scenariot krävs ingen generalisering (sysprep) av den virtuella datorn för att ladda upp och distribuera den virtuella datorn på Azure. Kontrollera att enheten D:\ används inte. Ange automatisk diskmontering för anslutna diskar enligt beskrivningen i kapitlet Ställa in automount för anslutna diskar i det här dokumentet.

Linux

I det här scenariot krävs ingen generalisering (waagent -deprovision) av den virtuella datorn för att ladda upp och distribuera den virtuella datorn på Azure. Kontrollera att /mnt/resource inte används och att ALLA diskar monteras via uuid. För OS-disken kontrollerar du att bootloader-posten även återspeglar den uuid-baserade monteringen.

Förberedelse för att distribuera en virtuell dator med en kundspecifik avbildning för SAP

VHD-filer som innehåller ett generaliserat operativsystem lagras i containrar på Azure Storage-konton eller som hanterade diskavbildningar. Du kan distribuera en ny virtuell dator från en sådan avbildning genom att referera till VHD- eller Managed Disk-avbildningen som en källa i dina distributionsmallfiler enligt beskrivningen i kapitel Scenario 2: Distribuera en virtuell dator med en anpassad avbildning för SAP i distributionsguiden.

Krav när du förbereder din egen Azure VM-avbildning är:

• Ursprungligen kunde den virtuella hårddisk som innehåller operativsystemet ha en maximal storlek på 127 GB. Den här begränsningen eliminerades i slutet av mars 2015. Nu kan den virtuella hårddisk som innehåller operativsystemet vara upp till 1 TB stor som vilken virtuell hårddisk Azure Storage värd som helst.
• Det måste vara i fast VHD-format. Dynamiska virtuella hårddiskar eller virtuella hårddiskar i VHDx-format stöds ännu inte i Azure. Dynamiska virtuella hårddiskar konverteras till statiska virtuella hårddiskar när du laddar upp den virtuella hårddisken med PowerShell-kommandon eller CLI
• Virtuella hårddiskar, som monteras på den virtuella datorn och ska monteras igen i Azure till den virtuella datorn, måste också ha ett fast VHD-format. Läs den här artikeln om storleksbegränsningar för datadiskar. Dynamiska virtuella hårddiskar konverteras till statiska virtuella hårddiskar när du laddar upp den virtuella hårddisken med PowerShell-kommandon eller CLI
• Lägg till andra lokala konton eftersom de kan behövas för det specifika distributionsscenariot.
• Om avbildningen innehåller en installation av SAP NetWeaver och namnbyte av värdnamnet från det ursprungliga namnet vid tidpunkten för Azure-distributionen är troligt, rekommenderar vi att du kopierar de senaste versionerna av SAP Software Provisioning Manager DVD till mallen. På så sätt kan du enkelt använda den sap-tillhandahållna funktionen för namnbyte för att anpassa det ändrade värdnamnet och/eller ändra SID för SAP-systemet i den distribuerade VM-avbildningen så snart en ny kopia har startats.

Windows

Kontrollera att enheten D:\ används inte Set disk automount for attached disks (Ange automatisk montering av diskar för anslutna diskar) enligt beskrivningen i kapitlet Setting automount for attached disks (Ange automount för anslutna diskar) i det här dokumentet.

Linux

Kontrollera att /mnt/resource inte används och att ALLA diskar monteras via uuid. För OS-disken kontrollerar du att bootloader-posten även återspeglar den uuid-baserade monteringen.

• SAP-gränssnittet (för administration och installation) kan förinstalleras i en sådan mall.
• Annan programvara som behövs för att köra de virtuella datorerna i olika lokala scenarier kan installeras så länge programvaran kan fungera med den virtuella datorns namnbyte.

Om den virtuella datorn är tillräckligt förberedd för att vara generisk och slutligen oberoende av konton/användare som inte är tillgängliga i det avsedda Azure-distributionsscenariot utförs det sista förberedelsesteget för generalisering av en sådan avbildning.

Generalisera en virtuell dator

Windows

Det sista steget är att logga in på en virtuell dator med ett administratörskonto. Öppna ett Windows kommandofönster som administratör. Gå till %windir%\windows\system32\sysprep och kör sysprep.exe. Ett litet fönster visas. Det är viktigt att markera alternativet Generalisera (standardvärdet är avmarkerat) och ändra avstängningsalternativet från standardinställningen "Starta om" till "stäng av". Den här proceduren förutsätter att sysprep-processen körs lokalt i gästoperativsystemet för en virtuell dator. Om du vill utföra proceduren med en virtuell dator som redan körs i Azure följer du stegen som beskrivs i den här artikeln.

Linux

Avbilda en virtuell Linux-dator som ska användas som mall för Resource Manager

Överföra virtuella datorer och virtuella hårddiskar mellan lokala datorer till Azure

Eftersom det inte går att ladda upp VM-avbildningar och diskar till Azure via Azure Portal måste du använda Azure PowerShell-cmdlets eller CLI. En annan möjlighet är att använda verktyget "AzCopy". Verktyget kan kopiera virtuella hårddiskar mellan den lokala platsen och Azure (i båda riktningarna). Den kan också kopiera virtuella hårddiskar mellan Azure-regioner. Läs den här dokumentationen för nedladdning och användning av AzCopy.

Ett tredje alternativ är att använda olika GUI-orienterade verktyg från tredje part. Se dock till att dessa verktyg stöder Azure-sidblobar. I vårt syfte behöver vi använda Azure Page Blob Store (skillnaderna beskrivs i Förstå blockblobar, tilläggsblobar och sidblobar. Verktygen i Azure är också effektiva när det gäller att komprimera de virtuella datorer och virtuella hårddiskar som måste laddas upp. Detta är viktigt eftersom den här effektiviteten i komprimering minskar uppladdningstiden (vilket varierar beroende på uppladdningslänken till Internet från den lokala anläggningen och den Azure-distributionsregion som är målet). Det är ett rimligt antagande att det tar längre tid att ladda upp en virtuell dator eller virtuell hårddisk från den europeiska platsen till de USA-baserade Azure-datacenteren än att ladda upp samma virtuella datorer/VHD:er till europeiska Azure-datacenter.

Ladda upp en virtuell hårddisk från en lokal plats till Azure

Om du vill ladda upp en befintlig virtuell dator eller virtuell hårddisk från det lokala nätverket måste en sådan virtuell dator eller vhd uppfylla kraven i kapitlet Förberedelser för att flytta en virtuell dator från en lokal plats till Azure med en icke-generaliserad disk i det här dokumentet.

En sådan virtuell dator behöver INTE generaliseras och kan laddas upp i det tillstånd och den form den har efter avstängningen på den lokala sidan. Samma sak gäller för ytterligare virtuella hårddiskar som inte innehåller något operativsystem.

Ladda upp en virtuell hårddisk och göra den till en Azure-disk

I det här fallet vill vi ladda upp en virtuell hårddisk, antingen med eller utan ett operativsystem, och montera den på en virtuell dator som en datadisk eller använda den som OS-disk. Det här är en process i flera steg

PowerShell

• Logga in på din prenumeration med Anslut-AzAccount
• Ange prenumerationen för din kontext med Set-AzContext och parametern SubscriptionId eller SubscriptionName – se Set-AzContext
• Upload den virtuella hårddisken med Add-AzVhd till ett Azure Storage konto – se Add-AzVhd
• (Valfritt) Skapa en hanterad disk från den virtuella hårddisken med New-AzDisk – se New-AzDisk
• Ange OS-disken för en ny VM-konfiguration till den virtuella hårddisken eller den hanterade disken med Set-AzVMOSDisk – se Set-AzVMOSDisk
• Skapa en ny virtuell dator från VM-konfiguration med New-AzVM – se New-AzVM
• Lägga till en datadisk till en ny virtuell dator med Add-AzVMDataDisk – se Add-AzVMDataDisk

Azure CLI

• Logga in på din prenumeration med az login
• Välj din prenumeration med az <subscription name or id > account set --subscription
• Upload den virtuella hårddisken med az storage blob upload – se Använda Azure CLI med Azure Storage.
• (Valfritt) Skapa en hanterad disk från den virtuella hårddisken med az disk create – se az disk.
• Skapa en ny virtuell dator som anger den uppladdade virtuella hårddisken eller den hanterade disken som os-disk med az vm create och parametern --attach-os-disk
• Lägga till en datadisk till en ny virtuell dator med az vm disk attach och parameter --new

Mall

• Upload den virtuella hårddisken med PowerShell eller Azure CLI
• (Valfritt) Skapa en hanterad disk från den virtuella hårddisken med PowerShell, Azure CLI eller Azure Portal
• Distribuera den virtuella datorn med en JSON-mall som refererar till den virtuella hårddisken enligt det som visas i det här JSON-exempelmallen eller med hjälp Managed Disks som det visas i det här JSON-exempelmallen.

Distribution av en VM-avbildning

För att kunna ladda upp en befintlig virtuell dator eller virtuell hårddisk från det lokala nätverket måste en virtuell dator eller VHD uppfylla kraven i kapitlet Förberedelse för distribution av en virtuell dator med en kundspecifik avbildning för SAP i det här dokumentet för att kunna använda den som en Azure VM-avbildning.

• Använd sysprep på Windows eller waagent -deprovision på Linux för att generalisera den virtuella datorn – se Teknisk referens för Sysprep för Windows eller Avbilda en virtuell Linux-dator som ska användas som en Resource Manager-mall för Linux
• Logga in på din prenumeration med Anslut-AzAccount
• Ange prenumerationen för din kontext med Set-AzContext och parametern SubscriptionId eller SubscriptionName – se Set-AzContext
• Upload den virtuella hårddisken med Add-AzVhd till ett Azure Storage konto – se Add-AzVhd
• (Valfritt) Skapa en hanterad diskavbildning från den virtuella hårddisken med New-AzImage – se New-AzImage
• Ange OS-disken för en ny VM-konfiguration till
  • VHD med Set-AzVMOSDisk -SourceImageUri -CreateOption fromImage – se Set-AzVMOSDisk
  • Set-AzVMSourceImage för hanterad diskavbildning – se Set-AzVMSourceImage
• Skapa en ny virtuell dator från VM-konfiguration med New-AzVM – se New-AzVM

Azure CLI

• Använd sysprep på Windows eller waagent -deprovision på Linux för att generalisera den virtuella datorn – se Teknisk referens för Sysprep för Windows eller Avbilda en virtuell Linux-dator som ska användas som en Resource Manager-mall för Linux
• Logga in på din prenumeration med az login
• Välj din prenumeration med az <subscription name or id > account set --subscription
• Upload den virtuella hårddisken med az storage blob upload – se Använda Azure CLI med Azure Storage.
• (Valfritt) Skapa en hanterad diskavbildning från den virtuella hårddisken med az image create – se az image.
• Skapa en ny virtuell dator som anger den uppladdade virtuella hårddisken eller den hanterade diskavbildningen som os-disk med az vm create och parameter --image

Mall

• Använd sysprep på Windows eller waagent -deprovision på Linux för att generalisera den virtuella datorn – se Teknisk referens för Sysprep för Windows eller Avbilda en virtuell Linux-dator som ska användas som en Resource Manager-mall för Linux
• Upload den virtuella hårddisken med PowerShell eller Azure CLI
• (Valfritt) Skapa en hanterad diskavbildning från den virtuella hårddisken med PowerShell, Azure CLI eller Azure Portal
• Distribuera den virtuella datorn med en JSON-mall som refererar till den virtuella hårddisken för avbildningen enligt det som visas i det här JSON-exempelmallen eller med hjälp av den hanterade diskavbildningen enligt det som visas i det här JSON-exempelmallen.

Ladda ned virtuella hårddiskar Managed Disks virtuella hårddiskar till en lokal plats

Azure Infrastructure as a Service är inte en envägs gata där man bara kan ladda upp virtuella hårddiskar och SAP-system. Du kan även flytta SAP-system från Azure tillbaka till den lokala världen.

Under tiden för nedladdningen kan de virtuella hårddiskarna eller Managed Disks inte vara aktiva. Även när du laddar ned diskar som är monterade på virtuella datorer måste den virtuella datorn stängas av och tas ur drift. Om du bara vill ladda ned databasinnehållet, som sedan ska användas för att konfigurera ett nytt system lokalt och om det är acceptabelt att systemet i Azure fortfarande kan användas under nedladdningen och installationen av det nya systemet, kan du undvika ett långt driftstopp genom att utföra en komprimerad databassäkerhetskopia till en disk och bara ladda ned disken i stället för att även ladda ned operativsystemet bas-VM.

PowerShell

• Ladda ned en hanterad disk Du måste först få åtkomst till den underliggande bloben för den hanterade disken. Sedan kan du kopiera den underliggande bloben till ett nytt lagringskonto och ladda ned bloben från det här lagringskontot.

  $access = Grant-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name> -Access Read -DurationInSecond 3600
  $key = (Get-AzStorageAccountKey -ResourceGroupName <resource group> -Name <storage account name>)[0].Value
  $destContext = (New-AzStorageContext -StorageAccountName <storage account name -StorageAccountKey $key)
  Start-AzStorageBlobCopy -AbsoluteUri $access.AccessSAS -DestContainer <container name> -DestBlob <blob name> -DestContext $destContext
  # Wait for blob copy to finish
  Get-AzStorageBlobCopyState -Container <container name> -Blob <blob name> -Context $destContext
  Save-AzVhd -SourceUri <blob in new storage account> -LocalFilePath <local file path> -StorageKey $key
  # Wait for download to finish
  Revoke-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name>
  

• Ladda ned en virtuell hårddisk När SAP-systemet har stoppats och den virtuella datorn stängs av kan du använda PowerShell-cmdleten på det lokala målet för att ladda ned de virtuella hårddiskarna tillbaka till den Save-AzVhd lokala världen. För att göra det behöver du URL:en för den virtuella hårddisken, som du hittar i lagringsavsnittet i Azure Portal (du måste gå till Storage-kontot och lagringscontainern där den virtuella hårddisken skapades) och du behöver veta var den virtuella hårddisken ska kopieras.

  Sedan kan du använda kommandot genom att definiera parametern SourceUri som URL för den virtuella hårddisken att ladda ned och LocalFilePath som den fysiska platsen för den virtuella hårddisken (inklusive dess namn). Kommandot kan se ut så här:

  Save-AzVhd -ResourceGroupName <resource group name of storage account> -SourceUri http://<storage account name>.blob.core.windows.net/<container name>/sapidedata.vhd -LocalFilePath E:\Azure_downloads\sapidesdata.vhd
  

  Mer information om Save-AzVhd cmdlet finns i Save-AzVhd.

Azure CLI

• Ladda ned en hanterad disk Du måste först få åtkomst till den underliggande bloben för den hanterade disken. Sedan kan du kopiera den underliggande bloben till ett nytt lagringskonto och ladda ned bloben från det här lagringskontot.

  az disk grant-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --duration-in-seconds 3600
  az storage blob download --sas-token "<sas token>" --account-name <account name> --container-name <container name> --name <blob name> --file <local file>
  az disk revoke-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>"
  

• Ladda ned en virtuell hårddisk När SAP-systemet har stoppats och den virtuella datorn stängs av kan du använda Azure CLI-kommandot på det lokala målet för att ladda ned de virtuella hårddiskarna tillbaka till den _azure storage blob download_ lokala världen. För att göra det behöver du namnet och containern för den virtuella hårddisken, som du hittar i "Storage-avsnittet" i Azure Portal (du måste navigera till Storage-kontot och lagringscontainern där den virtuella hårddisken skapades) och du behöver veta var den virtuella hårddisken ska kopieras.

  Sedan kan du använda kommandot genom att definiera parametrarna blob och container för den virtuella hårddisken att ladda ned och målet som den fysiska målplatsen för den virtuella hårddisken (inklusive dess namn). Kommandot kan se ut så här:

  az storage blob download --name <name of the VHD to download> --container-name <container of the VHD to download> --account-name <storage account name of the VHD to download> --account-key <storage account key> --file <destination of the VHD to download>
  

Överföra virtuella datorer och diskar i Azure

Kopiera SAP-system i Azure

Ett SAP-system eller till och med en dedikerad DBMS-server som stöder ett SAP-programlager består troligen av flera diskar, som innehåller antingen operativsystemet med binärfilerna eller data- och loggfilerna för SAP-databasen. Varken Azure-funktionerna för att kopiera diskar eller Azure-funktionerna för att spara diskar till en lokal disk har en synkroniseringsmekanism som ögonblicksbilder av flera diskar på ett konsekvent sätt. Därför skulle tillståndet för de kopierade eller sparade diskarna även om de är monterade mot samma virtuella dator vara annorlunda. Det innebär att databasen i slutet skulle vara inkonsekvent i det konkreta fallet med olika data och loggfiler som finns på de olika diskarna.

Slutsats: För att kunna kopiera eller spara diskar, som ingår i en SAP-systemkonfiguration, måste du stoppa SAP-systemet och även stänga av den distribuerade virtuella datorn. Först då kan du kopiera eller ladda ned diskuppsättningen för att antingen skapa en kopia av SAP-systemet i Azure eller lokalt.

Datadiskar kan lagras som VHD-filer i ett Azure Storage-konto och kan kopplas direkt till en virtuell dator eller användas som en avbildning. I det här fallet kopieras den virtuella hårddisken till en annan plats innan den ansluts till den virtuella datorn. Det fullständiga namnet på VHD-filen i Azure måste vara unikt i Azure. Som tidigare nämnts är namnet på ett namn med tre delar som ser ut så här:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Datadiskar kan också Managed Disks. I det här fallet används den hanterade disken för att skapa en ny hanterad disk innan den ansluts till den virtuella datorn. Namnet på den hanterade disken måste vara unikt inom en resursgrupp.

PowerShell

Du kan använda Azure PowerShell för att kopiera en virtuell hårddisk som visas i den här artikeln. Om du vill skapa en ny hanterad disk använder New-AzDiskConfig och New-AzDisk som du ser i följande exempel.

$config = New-AzDiskConfig -CreateOption Copy -SourceUri "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" -Location <location>
New-AzDisk -ResourceGroupName <resource group name> -DiskName <disk name> -Disk $config

Azure CLI

Du kan använda Azure CLI för att kopiera en virtuell hårddisk. Om du vill skapa en ny hanterad disk använder du az disk create enligt följande exempel.

az disk create --source "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --name <disk name> --resource-group <resource group name> --location <location>

Azure Storage verktyg

• https://storageexplorer.com/

Professionella utgåvor av Azure Storage Explorers finns här:

• https://www.cerebrata.com/
• https://clumsyleaf.com/products/cloudxplorer

Kopian av en virtuell hårddisk i ett lagringskonto är en process som bara tar några sekunder (liknar att SAN-maskinvara skapar ögonblicksbilder med lazy copy och copy vid skrivning). När du har en kopia av VHD-filen kan du koppla den till en virtuell dator eller använda den som en avbildning för att koppla kopior av den virtuella hårddisken till virtuella datorer.

PowerShell

# attach a vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -VhdUri <path to vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -ManagedDiskId <managed disk id> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a copy of the vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name <disk name> -VhdUri <new path of vhd> -SourceImageUri <path to image vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption fromImage
$vm | Update-AzVM

# attach a copy of the managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$diskConfig = New-AzDiskConfig -Location $vm.Location -CreateOption Copy -SourceUri <source managed disk id>
$disk = New-AzDisk -DiskName <disk name> -Disk $diskConfig -ResourceGroupName <resource group name>
$vm = Add-AzVMDataDisk -VM $vm -Caching <caching option> -Lun <lun, for example 0> -CreateOption attach -ManagedDiskId $disk.Id
$vm | Update-AzVM

Azure CLI

# attach a vhd to a vm
az vm unmanaged-disk attach --resource-group <resource group name> --vm-name <vm name> --vhd-uri <path to vhd>

# attach a managed disk to a vm
az vm disk attach --resource-group <resource group name> --vm-name <vm name> --disk <managed disk id>

# attach a copy of the vhd to a vm
# this scenario is currently not possible with Azure CLI. A workaround is to manually copy the vhd to the destination.

# attach a copy of a managed disk to a vm
az disk create --name <new disk name> --resource-group <resource group name> --location <location of target virtual machine> --source <source managed disk id>
az vm disk attach --disk <new disk name or managed disk id> --resource-group <resource group name> --vm-name <vm name> --caching <caching option> --lun <lun, for example 0>

Kopiera diskar mellan Azure Storage konton

Den här uppgiften kan inte utföras på Azure Portal. Du kan använda Azure PowerShell-cmdlets, Azure CLI eller en lagringswebbläsare från tredje part. PowerShell-cmdlets eller CLI-kommandon kan skapa och hantera blobar, vilket innefattar möjligheten att asynkront kopiera blobar över Storage-konton och mellan regioner i Azure-prenumerationen.

PowerShell

Du kan också kopiera virtuella hårddiskar mellan prenumerationer. Mer information finns i den här artikeln.

Det grundläggande flödet i PowerShell-cmdlet-logiken ser ut så här:

• Skapa en lagringskontokontext för källlagringskontot med New-AzStorageContext – se New-AzStorageContext
• Skapa en lagringskontokontext för mållagringskontot med New-AzStorageContext – se New-AzStorageContext
• Starta kopian med

Start-AzStorageBlobCopy -SrcBlob <source blob name> -SrcContainer <source container name> -SrcContext <variable containing context of source storage account> -DestBlob <target blob name> -DestContainer <target container name> -DestContext <variable containing context of target storage account>

• Kontrollera status för kopian i en loop med

Get-AzStorageBlobCopyState -Blob <target blob name> -Container <target container name> -Context <variable containing context of target storage account>

• Koppla den nya virtuella hårddisken till en virtuell dator enligt beskrivningen ovan.

Exempel finns i den här artikeln.

Azure CLI

• Starta kopian med

az storage blob copy start --source-blob <source blob name> --source-container <source container name> --source-account-name <source storage account name> --source-account-key <source storage account key> --destination-container <target container name> --destination-blob <target blob name> --account-name <target storage account name> --account-key <target storage account name>

• Kontrollera statusen om kopian fortfarande är i en loop med

az storage blob show --name <target blob name> --container <target container name> --account-name <target storage account name> --account-key <target storage account name>

• Koppla den nya virtuella hårddisken till en virtuell dator enligt beskrivningen ovan.

Diskhantering

VM/diskstruktur för SAP-distributioner

Vi rekommenderar att hanteringen av strukturen för en virtuell dator och tillhörande diskar är enkel. I lokala installationer utvecklade kunder många sätt att strukturera en serverinstallation.

• En basdisk som innehåller operativsystemet och alla binärfiler för DBMS och/eller SAP. Den här disken kan vara upp till 1 TB stor sedan mars 2015 i stället för tidigare begränsningar som begränsade den till 127 GB.
• En eller flera diskar, som innehåller DBMS-loggfilen för SAP-databasen och loggfilen för det tillfälliga dbms-lagringsområdet (om DBMS stöder detta). Om IOPS-kraven för databasloggen är höga måste du strimlar flera diskar för att nå den IOPS-volym som krävs.
• Ett antal diskar som innehåller en eller två databasfiler för SAP-databasen och DBMS-temporära datafiler (om DBMS stöder detta).

Windows

Med många kunder såg vi konfigurationer där till exempel SAP- och DBMS-binärfiler inte installerades på c:\ där operativsystemet installerades. Det fanns olika orsaker till detta, men när vi gick tillbaka till roten var det vanligtvis att enheterna var små och operativsystemuppgraderingar behövde ytterligare utrymme för 10–15 år sedan. Båda villkoren gäller inte längre för ofta. Idag c:\ -enheten kan mappas på stora volymdiskar eller virtuella datorer. För att hålla distributionerna enkla i sin struktur rekommenderar vi att du följer följande distributionsmönster för SAP NetWeaver-system i Azure

Den Windows operativsystemets växlingsfil ska finnas på enheten D: (icke-beständig disk)

Linux

Placera Linux-växlingsfilen under /mnt /mnt/resource i Linux enligt beskrivningen i den här artikeln. Växlingsfilen kan konfigureras i konfigurationsfilen för Linux-agenten /etc/waagent.conf. Lägg till eller ändra följande inställningar:

ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=30720

Om du vill aktivera ändringarna måste du starta om Linux-agenten med

sudo service waagent restart

Läs [SAP-1597355] för mer information om den rekommenderade växlingsfilens storlek

Antalet diskar som används för DBMS-datafilerna och typen av Azure Storage dessa diskar finns på bör fastställas av IOPS-kraven och den svarstid som krävs. Exakta kvoter beskrivs i den här artikeln (Linux) och den här artikeln (Windows).

Erfarenhet av SAP-distributioner under de senaste två åren lärde oss några lektioner, som kan sammanfattas som:

• IOPS-trafik till olika datafiler är inte alltid samma eftersom befintliga kundsystem kan ha datafiler av olika storlek som representerar deras SAP-databaser. Därför visade det sig vara bättre att använda en RAID-konfiguration över flera diskar för att placera datafilerna LUN som tas bort från dessa. Det fanns situationer, särskilt med Azure Standard Storage där en IOPS-hastighet träffar kvoten för en enskild disk mot DBMS-transaktionsloggen. I sådana scenarier rekommenderas användning av Premium Storage eller alternativt aggregera flera Standard Storage diskar med en programvarustrima.

Windows

• Prestandametodtips för SQL Server i Azure Virtual Machines

Linux

• Konfigurera programvaru-RAID på Linux
• Konfigurera LVM på en virtuell Linux-dator i Azure

• Premium Storage visar avsevärt bättre prestanda, särskilt för kritiska transaktionslogg-skrivningar. För SAP-scenarier som förväntas leverera produktion som prestanda rekommenderar vi starkt att du använder VM-Series som kan utnyttja Azure Premium Storage.

Tänk på att disken, som innehåller operativsystemet och som vi rekommenderar, binärfilerna för SAP och databasen (bas-VM) inte längre är begränsade till 127 GB. Den kan nu ha upp till 1 TB i storlek. Detta bör vara tillräckligt med utrymme för att behålla alla nödvändiga filer, inklusive till exempel SAP Batch-jobbloggar.

Mer förslag och mer information, särskilt för virtuella DBMS-datorer, finns i DBMS-distributionsguiden

Diskhantering

I de flesta fall måste du skapa ytterligare diskar för att kunna distribuera SAP-databasen till den virtuella datorn. Vi har talat om överväganden om antalet diskar i kapitlet VM/diskstruktur för SAP-distributioner i det här dokumentet. Med Azure Portal kan du ansluta och koppla från diskar när en grundläggande virtuell dator har distribuerats. Diskarna kan kopplas till/från när den virtuella datorn är igång och när den stoppas. När du kopplar en disk erbjuder Azure Portal att koppla en tom disk eller en befintlig disk som vid den här tidpunkten inte är ansluten till en annan virtuell dator.

Obs! Diskar kan bara kopplas till en virtuell dator åt gången.

Under distributionen av en ny virtuell dator kan du bestämma om du vill använda Managed Disks eller placera diskarna på Azure Storage konton. Om du vill använda Premium Storage rekommenderar vi att du använder Managed Disks.

Därefter måste du bestämma om du vill skapa en ny och tom disk eller om du vill välja en befintlig disk som har laddats upp tidigare och ska kopplas till den virtuella datorn nu.

VIKTIGT! Du vill INTE använda Host Cachelagring med Azure Standard Storage. Du bör lämna inställningen Värdcache på standardinställningen INGEN. Med Azure Premium Storage bör du aktivera Läs Cachelagring om I/O-egenskapen huvudsakligen läses som vanlig I/O-trafik mot databasdatafiler. När det gäller databastransaktionsloggfilen rekommenderas ingen cachelagring.

Windows

Så här kopplar du en datadisk i Azure Portal

Om diskarna är anslutna måste du logga in på den virtuella datorn för att öppna Windows Disk Manager. Om automount inte är aktiverat enligt rekommendationen i kapitlet Inställning av automountför anslutna diskar måste den nyligen anslutna volymen tas online och initieras.

Linux

Om diskarna är anslutna måste du logga in på den virtuella datorn och initiera diskarna enligt beskrivningen i den här artikeln

Om den nya disken är en tom disk måste du även formatera disken. För formatering, särskilt för DBMS-data och loggfiler gäller samma rekommendationer som för bare metal-distributioner av DBMS.

Ett Azure Storage-konto tillhandahåller inte oändliga resurser vad gäller I/O-volym, IOPS och datavolym. Vanligtvis påverkas virtuella DBMS-datorer mest av detta. Det kan vara bäst att använda ett separat Storage-konto för varje virtuell dator om du har några virtuella datorer med hög I/O-volym att distribuera för att hålla dig inom gränsen för Azure Storage-kontovolymen. Annars behöver du se hur du kan balansera dessa virtuella datorer mellan olika Storage-konton utan att nå gränsen för varje enskilt Storage konto. Mer information beskrivs i DBMS-distributionsguiden. Du bör också ha dessa begränsningar i åtanke för virtuella sap-programservrar eller andra virtuella datorer, som så småningom kan kräva ytterligare virtuella hårddiskar. Dessa begränsningar gäller inte om du använder Hanterad disk. Om du planerar att använda Premium Storage bör du använda Managed Disk.

Ett annat ämne som är relevant för Storage-konton är om de virtuella hårddiskarna i ett Storage-konto får geo-replikerade. Geo-replikering är aktiverat eller inaktiverat på Storage kontonivå och inte på VM-nivå. Om geo-replikering är aktiverat replikeras de virtuella hårddiskarna i Storage-kontot till ett annat Azure-datacenter inom samma region. Innan du bestämmer dig för detta bör du tänka på följande begränsning:

Geo-replikering i Azure fungerar lokalt på varje virtuell hårddisk på en virtuell dator och replikerar inte I/O i kronologisk ordning över flera virtuella hårddiskar på en virtuell dator. Därför replikeras den virtuella hårddisk som representerar den grundläggande virtuella datorn samt eventuella ytterligare virtuella hårddiskar som är anslutna till den virtuella datorn oberoende av varandra. Det innebär att det inte finns någon synkronisering mellan ändringarna på de olika virtuella hårddiskarna. Det faktum att I/Os replikeras oberoende av i vilken ordning de skrivs innebär att geo-replikering inte är av värde för databasservrar som har sina databaser distribuerade över flera virtuella hårddiskar. Förutom DBMS kan det också finnas andra program där processer skriver eller manipulerar data på olika virtuella hårddiskar och där det är viktigt att behålla ändringsordningen. Om det är ett krav ska geo-replikering i Azure inte aktiveras. Beroende på om du behöver eller vill ha geo-replikering för en uppsättning virtuella datorer, men inte för en annan uppsättning, kan du redan kategorisera virtuella datorer och deras relaterade virtuella hårddiskar i olika Storage-konton som har geo-replikering aktiverat eller inaktiverat.

Ange automount för anslutna diskar

Windows

För virtuella datorer, som skapas från egna avbildningar eller diskar, är det nödvändigt att kontrollera och eventuellt ange parametern automount. Om du anger den här parametern kan den virtuella datorn efter en omstart eller omdistribution i Azure montera de anslutna/monterade enheterna igen automatiskt. Parametern anges för de avbildningar som tillhandahålls av Microsoft i Azure Marketplace.

Information om hur du ställer in automount finns i dokumentationen för den körbara kommandorads-diskpart.exe här:

• Alternativ för Command-Line DiskPart
• Automount

Det Windows kommandoradsfönstret ska öppnas som administratör.

Om diskarna är anslutna måste du logga in på den virtuella datorn för att öppna Windows Disk Manager. Om automount inte är aktiverat enligt rekommendationen i kapitlet Inställning av automountför anslutna diskar måste den nyligen anslutna >tas online och initieras.

Linux

Du måste initiera en ny ansluten tom disk enligt beskrivningen i den här artikeln. Du måste också lägga till nya diskar i fliken /etc/fstab.

Slutlig distribution

Den slutliga distributionen och de exakta stegen, särskilt distributionen av Azure-tillägget för SAP, finns i distributionsguiden.

Åtkomst till SAP-system som körs på virtuella Azure-datorer

För scenarier där du vill ansluta till dessa SAP-system via det offentliga Internet med hjälp av SAP-gränssnittet måste följande procedurer tillämpas.

Senare i dokumentet diskuterar vi det andra större scenariot, anslutning till SAP-system i distributioner på flera platser, som har en plats-till-plats-anslutning (VPN-tunnel) eller Azure ExpressRoute-anslutning mellan lokala system och Azure-system.

Fjärråtkomst till SAP-system

Med Azure Resource Manager finns det inga standardslutpunkter längre som i den tidigare klassiska modellen. Alla portar på en Azure Resource Manager virtuell dator är öppna så länge:

1. Ingen nätverkssäkerhetsgrupp har definierats för undernätet eller nätverksgränssnittet. Nätverkstrafik till virtuella Azure-datorer kan skyddas via så kallade "nätverkssäkerhetsgrupper". Mer information finns i Vad är en nätverkssäkerhetsgrupp?
2. Ingen Azure Load Balancer har definierats för nätverksgränssnittet

Se arkitekturskillnaden mellan den klassiska modellen och ARM enligt beskrivningen i den här artikeln.

Konfiguration av SAP-systemet och SAP GUI-anslutningen via Internet

Se den här artikeln, som beskriver information om det här avsnittet: SAP GUI-anslutning stängd vid anslutning till SAP-system i Azure

Ändra brandväggsinställningar Inställningar virtuella datorer

Det kan vara nödvändigt att konfigurera brandväggen på dina virtuella datorer så att den tillåter inkommande trafik till SAP-systemet.

Windows

Som standard är Windows Firewall i en azure-distribuerad virtuell dator aktiverad. Du måste nu tillåta att SAP-porten öppnas, annars kommer SAP-gränssnittet inte att kunna ansluta. Gör så här:

• Öppna Kontrollpanelen\System and Security\Windows Firewall till Advanced Inställningar.
• Högerklicka nu på Regler för inkommande trafik och välj Ny regel.
• I följande guide väljer du att skapa en ny portregel.
• I nästa steg i guiden lämnar du inställningen på TCP och anger det portnummer som du vill öppna. Eftersom vårt SAP-instans-ID är 00 tog vi 3200. Om din instans har ett annat instansnummer ska porten som du definierade tidigare baserat på instansnumret öppnas.
• I nästa del av guiden måste du lämna objektet Tillåt anslutning markerat.
• I nästa steg i guiden måste du definiera om regeln gäller för domännätverk, privata nätverk och offentliga nätverk. Justera det om det behövs efter dina behov. Om du ansluter med SAP-gränssnittet utifrån via det offentliga nätverket måste du dock tillämpa regeln på det offentliga nätverket.
• I det sista steget i guiden ger du regeln ett namn och sparar genom att trycka på Slutför.

Regeln börjar gälla omedelbart.

Linux

Linux-avbildningarna i Azure Marketplace inte iptables-brandväggen som standard och anslutningen till SAP-systemet bör fungera. Om du har aktiverat iptables eller en annan brandvägg kan du läsa dokumentationen för iptables eller den använda brandväggen för att tillåta inkommande TCP-trafik till port 32xx (där xx är systemnumret för ditt SAP-system).

Säkerhetsrekommendationer

SAP-gränssnittet ansluter inte omedelbart till någon av SAP-instanserna (port 32xx) som körs, men ansluter först via porten som öppnas till SAP-meddelandeserverprocessen (port 36xx). Tidigare användes samma port av meddelandeservern för intern kommunikation till programinstanserna. För att förhindra att lokala programservrar oavsiktligt kommunicerar med en meddelandeserver i Azure kan de interna kommunikationsportarna ändras. Vi rekommenderar starkt att du ändrar den interna kommunikationen mellan SAP-meddelandeservern och dess programinstanser till ett annat portnummer på system som har klonat från lokala system, till exempel en klon av utveckling för projekttestning osv. Detta kan göras med standardprofilparametern:

rabel/msserv_internal

som beskrivs i Security Inställningar for the SAP Message Server

Enskild virtuell dator med SAP NetWeaver-demo/träningsscenario

I det här scenariot implementerar vi ett typiskt tränings-/demosystemscenario där det fullständiga tränings-/demoscenariot finns i en enda virtuell dator. Vi förutsätter att distributionen görs via mallar för VM-avbildningar. Vi förutsätter också att flera av dessa virtuella datorer för demonstration/träning måste distribueras med de virtuella datorerna med samma namn. Hela utbildningssystemen har ingen anslutning till dina lokala tillgångar och är motsatsen till en hybriddistribution.

Antagandet är att du har skapat en VM-avbildning enligt beskrivningen i vissa avsnitt i kapitlet Förbereda virtuella datorer med SAP för Azure i det här dokumentet.

Händelsesekvensen för att implementera scenariot ser ut så här:

PowerShell

• Skapa en ny resursgrupp för varje tränings-/demolandskap

$rgName = "SAPERPDemo1"
New-AzResourceGroup -Name $rgName -Location "North Europe"

• Skapa ett nytt lagringskonto om du inte vill använda Managed Disks

$suffix = Get-Random -Minimum 100000 -Maximum 999999
$account = New-AzStorageAccount -ResourceGroupName $rgName -Name "saperpdemo$suffix" -SkuName Standard_LRS -Kind "Storage" -Location "North Europe"

• Skapa ett nytt virtuellt nätverk för varje tränings-/demolandskap för att möjliggöra användning av samma värdnamn och IP-adresser. Det virtuella nätverket skyddas av en nätverkssäkerhetsgrupp som endast tillåter trafik till port 3389 för att aktivera fjärrskrivbordsåtkomst och port 22 för SSH.

# Create a new Virtual Network
$rdpRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGRDP -Protocol * -SourcePortRange * -DestinationPortRange 3389 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 100
$sshRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGSSH -Protocol * -SourcePortRange * -DestinationPortRange 22 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 101
$nsg = New-AzNetworkSecurityGroup -Name SAPERPDemoNSG -ResourceGroupName $rgName -Location  "North Europe" -SecurityRules $rdpRule,$sshRule

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name Subnet1 -AddressPrefix  10.0.1.0/24 -NetworkSecurityGroup $nsg
$vnet = New-AzVirtualNetwork -Name SAPERPDemoVNet -ResourceGroupName $rgName -Location "North Europe"  -AddressPrefix 10.0.1.0/24 -Subnet $subnetConfig

• Skapa en ny offentlig IP-adress som kan användas för att komma åt den virtuella datorn från Internet

# Create a public IP address with a DNS name
$pip = New-AzPublicIpAddress -Name SAPERPDemoPIP -ResourceGroupName $rgName -Location "North Europe" -DomainNameLabel $rgName.ToLower() -AllocationMethod Dynamic

• Skapa ett nytt nätverksgränssnitt för den virtuella datorn

# Create a new Network Interface
$nic = New-AzNetworkInterface -Name SAPERPDemoNIC -ResourceGroupName $rgName -Location "North Europe" -Subnet $vnet.Subnets[0] -PublicIpAddress $pip

• Skapa en virtuell dator. I det här scenariot har varje virtuell dator samma namn. SAP-SID för SAP NetWeaver-instanserna på de virtuella datorerna kommer också att vara samma. I Azure-resursgruppen måste namnet på den virtuella datorn vara unikt, men i olika Azure-resursgrupper kan du köra virtuella datorer med samma namn. Standardkontot "Administratör" för "Windows rot" för Linux är inte giltigt. Därför måste ett nytt administratörsanvändarnamn definieras tillsammans med ett lösenord. Storleken på den virtuella datorn måste också definieras.

#####
# Create a new virtual machine with an official image from the Azure Marketplace
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

# select image
$vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer" -Skus "2012-R2-Datacenter" -Version "latest"
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "SUSE" -Offer "SLES-SAP" -Skus "12-SP1" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "RedHat" -Offer "RHEL" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "Oracle" -Offer "Oracle-Linux" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$diskName="osfromimage"
$osDiskUri=$account.PrimaryEndpoints.Blob.ToString() + "vhds/" + $diskName  + ".vhd"

$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Windows
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Linux
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a Managed Disk Image
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMSourceImage -VM $vmconfig -Id <Id of Managed Disk Image>
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

• Du kan också lägga till ytterligare diskar och återställa nödvändigt innehåll. Alla blobnamn (URL:er till blobarna) måste vara unika i Azure.

# Optional: Attach additional VHD data disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
$dataDiskUri = $account.PrimaryEndpoints.Blob.ToString() + "vhds/datadisk.vhd"
Add-AzVMDataDisk -VM $vm -Name datadisk -VhdUri $dataDiskUri -DiskSizeInGB 1023 -CreateOption empty | Update-AzVM

# Optional: Attach additional Managed Disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
Add-AzVMDataDisk -VM $vm -Name datadisk -DiskSizeInGB 1023 -CreateOption empty -Lun 0 | Update-AzVM

CLI

Följande exempelkod kan användas i Linux. För Windows kan du antingen använda PowerShell enligt beskrivningen ovan eller anpassa exemplet till att använda %rgName% i stället för $rgName och ange miljövariabeln med hjälp av Windows kommandouppsättningen.

• Skapa en ny resursgrupp för varje tränings-/demolandskap

rgName=SAPERPDemo1
rgNameLower=saperpdemo1
az group create --name $rgName --location "North Europe"

• Skapa ett nytt lagringskonto

az storage account create --resource-group $rgName --location "North Europe" --kind Storage --sku Standard_LRS --name $rgNameLower

• Skapa ett nytt virtuellt nätverk för varje tränings-/demolandskap för att möjliggöra användning av samma värdnamn och IP-adresser. Det virtuella nätverket skyddas av en nätverkssäkerhetsgrupp som endast tillåter trafik till port 3389 för att aktivera fjärrskrivbordsåtkomst och port 22 för SSH.

az network nsg create --resource-group $rgName --location "North Europe" --name SAPERPDemoNSG
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGRDP --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 3389 --access Allow --priority 100 --direction Inbound
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGSSH --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 22 --access Allow --priority 101 --direction Inbound

az network vnet create --resource-group $rgName --name SAPERPDemoVNet --location "North Europe" --address-prefixes 10.0.1.0/24
az network vnet subnet create --resource-group $rgName --vnet-name SAPERPDemoVNet --name Subnet1 --address-prefix 10.0.1.0/24 --network-security-group SAPERPDemoNSG

• Skapa en ny offentlig IP-adress som kan användas för att komma åt den virtuella datorn från Internet

az network public-ip create --resource-group $rgName --name SAPERPDemoPIP --location "North Europe" --dns-name $rgNameLower --allocation-method Dynamic

• Skapa ett nytt nätverksgränssnitt för den virtuella datorn

az network nic create --resource-group $rgName --location "North Europe" --name SAPERPDemoNIC --public-ip-address SAPERPDemoPIP --subnet Subnet1 --vnet-name SAPERPDemoVNet

• Skapa en virtuell dator. I det här scenariot har varje virtuell dator samma namn. SAP-SID för SAP NetWeaver-instanserna på de virtuella datorerna kommer också att vara samma. I Azure-resursgruppen måste namnet på den virtuella datorn vara unikt, men i olika Azure-resursgrupper kan du köra virtuella datorer med samma namn. Standardkontot "Administratör" för "Windows rot" för Linux är inte giltigt. Därför måste ett nytt administratörsanvändarnamn definieras tillsammans med ett lösenord. Storleken på den virtuella datorn måste också definieras.

#####
# Create virtual machines using storage accounts
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password

#####
# Create virtual machines using Managed Disks
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Windows --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Linux --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd> --authentication-type password

#####
# Create a new virtual machine with a Managed Disk Image
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id> --authentication-type password

• Du kan också lägga till ytterligare diskar och återställa nödvändigt innehåll. Alla blobnamn (URL:er till blobarna) måste vara unika i Azure.

# Optional: Attach additional VHD data disks
az vm unmanaged-disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --vhd-uri https://$rgNameLower.blob.core.windows.net/vhds/data.vhd  --new

# Optional: Attach additional Managed Disks
az vm disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --disk datadisk --new

Mall

Du kan använda exempelmallarna på lagringsplatsen Azure-quickstart-templates på GitHub.

• Enkel virtuell Linux-dator
• Enkel Windows virtuell dator
• Virtuell dator från avbildning

Implementera en uppsättning virtuella datorer som kommunicerar i Azure

Det här icke-hybridscenariot är ett typiskt scenario för träning och demonstration där programvaran som representerar demo-/träningsscenariot är utspridd över flera virtuella datorer. De olika komponenterna som installeras på de olika virtuella datorerna måste kommunicera med varandra. I det här scenariot behövs ingen lokal nätverkskommunikation eller ett scenario mellan olika platser.

Det här scenariot är en utökning av installationen som beskrivs i kapitlet Single VM with SAP NetWeaver demo/training scenario of this document (Enkel virtuell dator med SAP NetWeaver- demo/träningsscenario i det här dokumentet). I det här fallet läggs fler virtuella datorer till i en befintlig resursgrupp. I följande exempel består träningslandskapet av en virtuell SAP ASCS/SCS-dator, en virtuell dator som kör en DBMS och en virtuell dator med SAP Application Server-instans.

Innan du skapar det här scenariot måste du tänka på grundläggande inställningar som redan används i scenariot tidigare.

Namngivning av resursgrupper och virtuella datorer

Alla resursgruppnamn måste vara unika. Utveckla ditt eget namngivningsschema för dina resurser, till exempel <rg-name>-suffix.

Namnet på den virtuella datorn måste vara unikt i resursgruppen.

Konfigurera nätverk för kommunikation mellan olika virtuella datorer

För att förhindra namngivningskollisioner med kloner av samma tränings-/demolandskap måste du skapa en Azure-Virtual Network för varje landskap. DNS-namnmatchning tillhandahålls av Azure eller så kan du konfigurera din egen DNS-server utanför Azure (vi ska inte gå vidare här). I det här scenariot konfigurerar vi inte vår egen DNS. För alla virtuella datorer i Virtual Network Azure-datorer aktiveras kommunikation via värdnamn.

Skälen till att separera tränings- eller demolandskap efter virtuella nätverk och inte bara resursgrupper kan vara:

• SAP-landskap som det har ställts in behöver sin egen AD/OpenLDAP och en domänserver måste vara en del av vart och ett av landskapen.
• SAP-miljön som konfigureras har komponenter som måste fungera med fasta IP-adresser.

Mer information om virtuella Azure-nätverk och hur du definierar dem finns i den här artikeln.

Distribuera virtuella SAP-datorer med företagets nätverksanslutning (mellan olika platser)

Du kör ett SAP-landskap och vill dela distributionen mellan datorer utan operativsystem för avancerade DBMS-servrar, lokala virtualiserade miljöer för programlager och mindre 2-nivåskonfigurerade SAP-system och Azure IaaS. Det grundläggande antagandet är att SAP-system i ett SAP-landskap måste kommunicera med varandra och med många andra programvarukomponenter som distribueras i företaget, oberoende av deras distributionsformulär. Det bör inte heller finnas några skillnader som introduceras av distributionsformuläret för slutanvändaren som ansluter med SAP-gränssnittet eller andra gränssnitt. Dessa villkor kan bara uppfyllas när vi har lokal Active Directory/OpenLDAP- och DNS-tjänsterna utökade till Azure-systemen via plats-till-plats-/multiplatsanslutning eller privata anslutningar som Azure ExpressRoute.

Scenario för ett SAP-landskap

Scenariot mellan olika platser eller hybridscenariot kan beskrivas ungefär som i bilderna nedan:

Minimikravet är användning av säkra kommunikationsprotokoll som SSL/TLS för webbläsaråtkomst eller VPN-baserade anslutningar för systemåtkomst till Azure-tjänsterna. Antagandet är att företag hanterar VPN-anslutningen mellan företagets nätverk och Azure på olika sätt. Vissa företag kan öppna alla portar tomt. Vissa andra företag kanske vill vara exakta i vilka portar de behöver öppna osv.

I tabellen nedan visas vanliga SAP-kommunikationsportar. I princip räcker det att öppna SAP-gatewayporten.

*) nn = SAP-instansnummer

**) sid = SAP-System-ID

Mer detaljerad information om portar som krävs för olika SAP-produkter eller SAP-tjänster av SAP-produkter finns https://scn.sap.com/docs/DOC-17124 här. Med det här dokumentet bör du kunna öppna dedikerade portar på den VPN-enhet som krävs för specifika SAP-produkter och SAP-scenarier.

Andra säkerhetsåtgärder vid distribution av virtuella datorer i ett sådant scenario kan vara att skapa en nätverkssäkerhetsgrupp för att definiera åtkomstregler.

Skriva ut på en lokal nätverksskrivare från SAP-instans i Azure

Skriva ut via TCP/IP i scenario med flera platser

Att konfigurera dina lokala TCP/IP-baserade nätverksskrivare på en virtuell Azure-dator fungerar på samma sätt som i företagsnätverket, förutsatt att du har en VPN-tunnel från plats till plats eller en ExpressRoute-anslutning upprättad.

Windows

Gör så här:

• Vissa nätverksskrivare har en konfigurationsguide som gör det enkelt att konfigurera skrivaren på en virtuell Azure-dator. Om ingen guideprogramvara har distribuerats med skrivaren är det manuella sättet att konfigurera skrivaren att skapa en ny TCP/IP-skrivarport.
• Öppna Kontrollpanelen -> Enheter och skrivare -> Lägg till en skrivare
• Välj Lägg till en skrivare med en TCP/IP-adress eller värdnamn
• Ange skrivarens IP-adress
• Standard för skrivarport 9100
• Installera vid behov lämplig skrivardrivrutin manuellt.

Linux

• Som för Windows följer du standardproceduren för att installera en nätverksskrivare
• följ bara de offentliga Linux-guiderna för SUSE eller Red Hat och Oracle Linux hur du lägger till en skrivare.

Värdbaserad skrivare över SMB (delad skrivare) i scenariot med flera platser

Värdbaserade skrivare är inte nätverkskompatibla. Men en värdbaserad skrivare kan delas mellan datorer i ett nätverk så länge skrivaren är ansluten till en dator som är påslagen. Anslut ditt företagsnätverk antingen plats-till-plats eller ExpressRoute och dela din lokala skrivare. SMB-protokollet använder NetBIOS i stället för DNS som namntjänst. NetBIOS-värdnamnet kan vara ett annat än DNS-värdnamnet. Standardfallet är att NetBIOS-värdnamnet och DNS-värdnamnet är identiska. DNS-domänen är inte meningsfull i NetBIOS-namnområdet. Därför får det fullständigt kvalificerade DNS-värdnamnet som består av DNS-värdnamnet och DNS-domänen inte användas i NetBIOS-namnområdet.

Skrivarresursen identifieras med ett unikt namn i nätverket:

• Värdnamnet för SMB-värden (behövs alltid).
• Namnet på resursen (behövs alltid).
• Namnet på domänen om skrivarresursen inte finns i samma domän som SAP-systemet.
• Dessutom kan ett användarnamn och ett lösenord krävas för att få åtkomst till skrivarresursen.

Anvisningar:

Windows

Dela din lokala skrivare. På den virtuella Azure-datorn öppnar Windows Explorer och skriver in resursnamnet på skrivaren. En skrivarinstallationsguide vägleder dig genom installationsprocessen.

Linux

Här följer några exempel på dokumentation om hur du konfigurerar nätverksskrivare i Linux eller ett kapitel om utskrift i Linux. Det fungerar på samma sätt på en virtuell Azure Linux-dator så länge den virtuella datorn är en del av ett VPN:

• SLES https://en.opensuse.org/SDB:Printing_via_SMB_(Samba)_Share_or_Windows_Share
• RHEL eller Oracle Linux https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sec-Starting_Print_Settings_Config

USB-skrivare (vidarebefordran av skrivare)

I Azure är möjligheten för Fjärrskrivbordstjänster att ge användare åtkomst till sina lokala skrivarenheter i en fjärrsession inte tillgänglig.

Windows

Mer information om utskrift Windows finns här: https://technet.microsoft.com/library/jj590748.aspx .

Integrering av SAP Azure-system i korrigerings- och transportsystem (TMS) i flera platser

SAP Change and Transport System (TMS) måste konfigureras för att exportera och importera transportbegärande mellan system i liggande läge. Vi förutsätter att utvecklingsinstanserna för ett SAP-system (DEV) finns i Azure medan kvalitetskontroll (QA) och produktiva system (PRD) finns lokalt. Dessutom förutsätter vi att det finns en central transportkatalog.

Konfigurera transportdomänen

Konfigurera din transportdomän på det system som du har angett som transportdomänkontrollant enligt beskrivningen i Konfigurera transportdomänkontrollanten. En systemanvändares TMSADM skapas och det rfc-mål som krävs genereras. Du kan kontrollera dessa RFC-anslutningar med hjälp av transaktionen SM59. Värdnamnsmatchning måste vara aktiverat i transportdomänen.

Anvisningar:

• I vårt scenario har vi beslutat att det lokala QAS-systemet ska vara CTS-domänkontrollanten. Anropa transaktions-STMS. Dialogrutan TMS visas. Dialogrutan Konfigurera transportdomän visas. (Den här dialogrutan visas bara om du inte har konfigurerat en transportdomän än.)
• Kontrollera att den automatiskt skapade användaren TMSADM är auktoriserad (SM59 -> ABAP Connection -> TMSADM@E61.DOMAIN_E61 -> Details -> Utilities(M) -> Authorization Test). Den inledande skärmen för transaktions-STMS bör visa att det här SAP-systemet nu fungerar som kontrollant för transportdomänen enligt följande:

Inkludera SAP-system i transportdomänen

Sekvensen för att inkludera ett SAP-system i en transportdomän ser ut så här:

• På DEV-systemet i Azure går du till transportsystemet (Client 000) och anropar transaktions-STMS. Välj Annan konfiguration i dialogrutan och fortsätt med Inkludera system i domän. Ange domänkontrollanten som målvärd (inklusive SAP-system i transportdomänen). Systemet väntar nu på att tas med i transportdomänen.
• Av säkerhetsskäl måste du sedan gå tillbaka till domänkontrollanten för att bekräfta din begäran. Välj Systemöversikt och Godkänn för det väntande systemet. Bekräfta sedan prompten så distribueras konfigurationen.

Det här SAP-systemet innehåller nu nödvändig information om alla andra SAP-system i transportdomänen. Samtidigt skickas adressdata för det nya SAP-systemet till alla andra SAP-system och SAP-systemet anges i transportkontrollprogrammets transportprofil. Kontrollera om RFC:er och åtkomst till domänens transportkatalog fungerar.

Fortsätt med konfigurationen av ditt transportsystem som vanligt enligt beskrivningen i dokumentationen Ändrings- och transportsystem.

Anvisningar:

• Kontrollera att din stms lokalt är korrekt konfigurerad.
• Kontrollera att värdnamnet för transportdomänkontrollanten kan matchas av den virtuella datorn i Azure och vice visa.
• Anropa transaktion STMS -> Annan konfiguration -> inkludera System i domänen.
• Bekräfta anslutningen i det lokala TMS-systemet.
• Konfigurera transportvägar, grupper och lager som vanligt.

I scenarier med plats-till-plats-anslutning mellan olika platser kan svarstiden mellan den lokala platsen och Azure fortfarande vara betydande. Om vi följer sekvensen med att flytta objekt genom utvecklings- och testsystem till produktion eller tänker på att tillämpa transporter eller supportpaket på de olika systemen inser du att vissa av systemen kommer att stöta på läsning eller skrivning av data i den centrala transportkatalogen beroende på platsen för den centrala transportkatalogen. Situationen liknar SAP-liggande konfigurationer där de olika systemen sprids genom olika datacenter med ett stort avstånd mellan datacentren.

För att undvika sådana fördröjningar och få systemen att fungera snabbt vid läsning eller skrivning till eller från transportkatalogen kan du konfigurera två STMS-transportdomäner (en för lokalt och en med systemen i Azure och länkar transportdomänerna. Läs den härdokumentationen, som förklarar principerna bakom det här konceptet i SAP TMS.

Anvisningar:

• Konfigurera en transportdomän på varje plats (lokalt och Azure) med hjälp av transaktions-STMS
• Länka domänerna med en domänlänk och bekräfta länken mellan de två domänerna.
• Distribuera konfigurationen till det länkade systemet.

RFC-trafik mellan SAP-instanser som finns i Azure och lokalt (lokalt)

RFC-trafik mellan system som är lokala och i Azure måste fungera. Om du vill konfigurera ett anslutningssamtalstransaktion SM59 i ett källsystem där du behöver definiera en RFC-anslutning mot målsystemet. Konfigurationen liknar standardkonfigurationen för en RFC-anslutning.

Vi förutsätter att de virtuella datorer som kör SAP-system som behöver kommunicera med varandra finns i samma domän i det här scenariot. Konfigurationen av en RFC-anslutning mellan SAP-system skiljer sig därför inte från installationsstegen och indata i lokala scenarier.

Åtkomst till lokala fildelningar från SAP-instanser som finns i Azure eller tvärtom

SAP-instanser som finns i Azure behöver åtkomst till filresurser, som finns i företagets lokaler. Dessutom måste lokala SAP-instanser ha åtkomst till filresurser som finns i Azure. Om du vill aktivera filresurser måste du konfigurera behörigheter och delningsalternativ på det lokala systemet. Se till att öppna portarna på VPN- eller ExpressRoute-anslutningen mellan Azure och ditt datacenter.

Support

Azure-tillägg för SAP

För att kunna mata in en del av Azure-infrastrukturens information om verksamhetskritiska SAP-system till SAP-värdagentinstanserna, som installeras på virtuella datorer, måste ett Azure-tillägg (VM) för SAP installeras för de distribuerade virtuella datorerna. Eftersom SAP:s krav var specifika för SAP-program, valde Microsoft att inte implementera de nödvändiga funktionerna i Azure, utan låta kunderna distribuera nödvändiga VM-tillägg och konfigurationer till sina Virtual Machines som körs i Azure. Distribution och livscykelhantering av Azure VM-tillägget för SAP automatiseras dock huvudsakligen av Azure.

Lösningsdesign

Den lösning som har utvecklats för att göra det möjligt för SAP-värdagenten att hämta nödvändig information baseras på arkitekturen för Azure VM Agent och Tilläggsramverk. Tanken med Azure VM-agenten och tilläggsramverket är att tillåta installation av program som är tillgängliga i galleriet Azure VM-tillägg på en virtuell dator. Huvudidéen bakom det här konceptet är att tillåta (i fall som Azure-tillägget för SAP), distribution av specialfunktioner till en virtuell dator och konfiguration av sådan programvara vid distributionen.

"Azure VM-agenten" som möjliggör hantering av specifika Azure VM-tillägg i den virtuella datorn matas in i virtuella Windows-datorer som standard när den virtuella datorn skapas i Azure Portal. När det gäller SUSE, Red Hat eller Oracle Linux är VM-agenten redan en del av Azure Marketplace avbildningen. Om du skulle ladda upp en virtuell Linux-dator från en lokal plats till Azure måste VM-agenten installeras manuellt.

De grundläggande byggstenarna i lösningen för att tillhandahålla azure-infrastrukturinformation till SAP-värdagenten i Azure ser ut så här:

Som du ser i blockdiagrammet ovan finns en del av lösningen i Azure VM Image och Azure Extension Gallery, som är en globalt replikerad lagringsplats som hanteras av Azure Operations. Det är det gemensamma SAP/MS-teamet som arbetar med Azure-implementeringen av SAP som ansvarar för att arbeta med Azure Operations för att publicera nya versioner av Azure-tillägget för SAP.

När du distribuerar en Windows virtuell dator läggs Azure VM-agenten automatiskt till i den virtuella datorn. Den här agentens funktion är att samordna inläsningen och konfigurationen av Azure-tilläggen för de virtuella datorerna. För virtuella Linux-datorer är Azure VM-agenten redan en del av Azure Marketplace operativsystemavbildningen.

Det finns dock ett steg som kunden fortfarande måste utföra. Det här är aktiverande och konfiguration av prestandasamlingen. Processen som rör konfigurationen automatiseras med ett PowerShell-skript eller CLI-kommando. PowerShell-skriptet kan laddas ned i Microsoft Azure Script Center enligt beskrivningen i distributionsguiden.

Den övergripande arkitekturen för Azure-tillägget för SAP ser ut så här:

För de exakta anvisningarna och detaljerade anvisningar för hur du använder dessa PowerShell-cmdlets eller CLI-kommandon under distributioner, följer du anvisningarna i distributionsguiden.

Integrering av Azure-belägna SAP-instanser i SAProuter

SAP-instanser som körs i Azure måste också vara tillgängliga från SAProuter.

En SAProuter möjliggör TCP/IP-kommunikation mellan deltagande system om det inte finns någon direkt IP-anslutning. Detta ger fördelen att det inte krävs någon anslutning från hela till slutet mellan kommunikationspartner på nätverksnivå. SAProuter lyssnar på port 3299 som standard. Om du vill ansluta SAP-instanser via en SAProuter måste du ge SAProuter-strängen och värdnamnet vid alla försök att ansluta.

SAP NetWeaver AS Java

Hittills har fokus för dokumentet varit SAP NetWeaver i allmänhet eller SAP NetWeaver-ABAP stacken. I det här lilla avsnittet visas specifika överväganden för SAP Java-stacken. Ett av de viktigaste SAP NetWeaver Java-baserade programmen är SAP-Enterprise Portal. Andra SAP NetWeaver-baserade program som SAP PI och SAP Solution Manager använder både SAP NetWeaver-ABAP och Java-stackar. Därför finns det verkligen ett behov av att överväga specifika aspekter som rör SAP NetWeaver Java-stacken också.

SAP-Enterprise Portal

Konfigurationen av en SAP-portal på en virtuell Azure-dator skiljer sig inte från en lokal installation om du distribuerar i scenarier mellan olika platser. Eftersom DNS görs lokalt kan portinställningarna för de enskilda instanserna göras enligt lokal konfiguration. De rekommendationer och begränsningar som beskrivs i det här dokumentet gäller hittills för ett program som SAP Enterprise Portal eller SAP NetWeaver Java-stacken i allmänhet.

Ett särskilt distributionsscenario för vissa kunder är SAP-Enterprise Portal:s direkt exponering mot Internet medan den virtuella datorvärden är ansluten till företagsnätverket via VPN-tunnel för plats till plats eller ExpressRoute. I ett sådant scenario måste du se till att specifika portar är öppna och inte blockeras av brandväggen eller nätverkssäkerhetsgruppen.

Den första portalens URI är http(er): <Portalserver>:5XX00/irj där porten är utformad enligt beskrivningen av SAP i https://help.sap.com/saphelp_nw70ehp1/helpdata/de/a2/f9d7fed2adc340ab462ae159d19509/frameset.htm .

Om du vill anpassa URL:en och/eller portarna för din SAP-Enterprise Portal kan du läsa den här dokumentationen:

• Ändra portal-URL
• Ändra standardportnummer, portalportnummer

Hög tillgänglighet (HA) och haveriberedskap (DR) för SAP NetWeaver som körs på Azure Virtual Machines

Definition av terminologi

Termen hög tillgänglighet (HA) är vanligtvis relaterad till en uppsättning tekniker som minimerar IT-avbrott genom att tillhandahålla affärskontinui för IT-tjänster via redundanta, feltoleranta eller redundansskyddade komponenter i samma datacenter. I vårt fall inom en Azure-region.

Haveriberedskap (DR) är också inriktad på att minimera avbrott i IT-tjänster och deras återställning, men mellan olika datacenter, som vanligtvis ligger hundratals kilometer bort. I vårt fall vanligtvis mellan olika Azure-regioner inom samma geopolitiska region eller enligt vad som har upprättats av dig som kund.

Översikt över hög tillgänglighet

Vi kan dela upp diskussionen om hög SAP-tillgänglighet i Azure i två delar:

• Hög tillgänglighet för Azure-infrastruktur, till exempel HA för beräkning (VM), nätverk, lagring osv. och dess fördelar med att öka tillgängligheten för SAP-program.
• Hög tillgänglighet för SAP-program, till exempel HÖG TILLGÄNGLIGHET för SAP-programvarukomponenter:
  • SAP-programservrar
  • SAP ASCS/SCS-instans
  • DB-server

och hur den kan kombineras med Azure-infrastrukturens HA.

SAP med hög tillgänglighet i Azure har vissa skillnader jämfört med SAP Med hög tillgänglighet i en lokal fysisk eller virtuell miljö. Följande dokument från SAP beskriver standardkonfigurationer för SAP med hög tillgänglighet i virtualiserade miljöer på Windows: https://scn.sap.com/docs/DOC-44415 . Det finns ingen sapinst-integrerad SAP-HA-konfiguration för Linux som den finns för Windows. Om SAP HA lokalt för Linux hittar du mer information här: https://scn.sap.com/docs/DOC-8541 .

Hög tillgänglighet för Azure-infrastruktur

Det finns för närvarande ett serviceavtal för enskilda virtuella datorer på 99,9 %. För att få en uppfattning om hur tillgängligheten för en enskild virtuell dator kan se ut kan du skapa produkten av de olika tillgängliga Azure-serviceavtalen: https://azure.microsoft.com/support/legal/sla/ .

Grunden för beräkningen är 30 dagar per månad eller 43 200 minuter. Därför motsvarar 0,05 % stilleståndstid 21,6 minuter. Som vanligt multipliceras tillgängligheten för de olika tjänsterna på följande sätt:

(Tillgänglighetstjänst nr 1/100) * (tillgänglighetstjänst nr 2/100) * (tillgänglighetstjänst #3/100)

Så här:

(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 eller en övergripande tillgänglighet på 99,75 %.

Hög tillgänglighet för virtuell dator (VM)

Det finns två typer av Azure-plattformshändelser som kan påverka tillgängligheten för dina virtuella datorer: planerat underhåll och oplanerat underhåll.

• Planerat underhåll är periodiska uppdateringar som Microsoft utför i syfte att förbättra tillförlitligheten, prestandan och säkerheten för den plattformsinfrastruktur som dina virtuella datorer körs i.
• Oplanerat underhåll utförs när det uppstått något fel på den underliggande maskinvaran eller fysiska infrastrukturen. Det kan vara lokala nätverksfel, lokala diskfel eller andra fel på racknivå. När ett sådant fel upptäcks migrerar Azure-plattformen automatiskt den virtuella datorn från den felaktiga fysiska servern som är värd för den virtuella datorn till en felfri fysisk server. Den här typen av händelser kan också göra att den virtuella datorn startas om, men det är ovanligt.

Mer information finns i Tillgänglighet för virtuella Windows i Azure och Tillgänglighet för virtuella Linux-datorer i Azure.

Azure Storage Redundans

Data i ditt Microsoft Azure Storage-konto replikeras alltid för att säkerställa hållbarhet och hög tillgänglighet, vilket uppfyller serviceavtalet för Azure Storage även vid tillfälliga maskinvarufel.

Eftersom Azure Storage har tre avbildningar av data som standard är RAID5 eller RAID1 över flera Azure-diskar inte nödvändiga.

Mer information finns i Azure Storage redundans.

Använda omstart av virtuell Azure-infrastruktur för att uppnå högre tillgänglighet för SAP-program

Om du bestämmer dig för att inte använda funktioner som Windows Server Failover Clustering (WSFC) eller Pacemaker på Linux (stöds för närvarande endast för SLES 12 och senare) används Omstart av virtuell Azure-dator för att skydda ett SAP-system mot planerade och oplanerade driftstopp för den fysiska Azure-serverinfrastrukturen och den övergripande underliggande Azure-plattformen.

Ett annat viktigt infrastrukturelement för hög tillgänglighet är lagring. Till exempel Azure Storage serviceavtal är 99,9 % tillgänglighet. Om en distribuerar alla virtuella datorer med sina diskar till ett enda Azure Storage-konto kommer eventuell otillgänglighet för Azure Storage att orsaka otillgänglighet för alla virtuella datorer som är placerade i det Azure Storage-kontot och även alla SAP-komponenter som körs på de virtuella datorerna.

I stället för att placera alla virtuella datorer i ett enda Azure Storage-konto kan du också använda dedikerade lagringskonton för varje virtuell dator och på så sätt öka den totala tillgängligheten för virtuella datorer och SAP-program genom att använda flera oberoende Azure Storage-konton.

Azure-hanterade diskar placeras automatiskt i feldomänen för den virtuella dator som de är anslutna till. Om du placerar två virtuella datorer i en tillgänglighetsuppsättning och använder Managed Disks, tar plattformen även hand om distributionen av Managed Disks till olika feldomäner. Om du planerar att använda Premium Storage rekommenderar vi starkt att du även använder Hantera diskar.

En exempelarkitektur för ett SAP NetWeaver-system som använder Azure-infrastrukturens HA- och lagringskonton kan se ut så här:

En exempelarkitektur för ett SAP NetWeaver-system som använder Azure-infrastrukturens HA och Managed Disks kan se ut så här:

För kritiska SAP-komponenter har vi uppnått följande hittills:

• Hög tillgänglighet för SAP-programservrar (AS)

  SAP-programserverinstanser är redundanta komponenter. Varje SAP AS-instans distribueras på en egen virtuell dator som körs i en annan Fel- och uppgraderingsdomän i Azure (se kapitlen Feldomäner och Uppgraderingsdomäner). Detta säkerställs med hjälp av Azure-tillgänglighetsuppsättningar (se kapitlet Tillgänglighetsuppsättningar för Azure). Potentiella planerade eller oplanerade otillgängliga Azure-fel eller uppgraderingsdomäner kommer att orsaka otillgänglighet för ett begränsat antal virtuella datorer med sina SAP AS-instanser.

  Varje SAP AS-instans placeras i sitt eget Azure Storage-konto – eventuell otillgänglighet för ett Azure Storage-konto leder till att endast en virtuell dator med sin SAP AS-instans blir otillgänglig. Tänk dock på att det finns en gräns på Azure Storage i en Azure-prenumeration. För att säkerställa automatisk start av (A)SCS-instansen efter omstarten av den virtuella datorn, se till att ange parametern Autostart i (A)SCS-instansens startprofil som beskrivs i kapitlet Använda autostart för SAP-instanser. Läs även kapitlet Hög tillgänglighet för SAP-programservrar för mer information.

  Även om du använder Managed Disks lagras dessa diskar också i ett Azure Storage-konto och kan vara otillgängliga i händelse av ett lagringsavbrott.

• Högre Tillgänglighet för SAP (A)SCS-instans

  Här använder vi Omstart av virtuell Azure-dator för att skydda den virtuella datorn med installerad SAP (A)SCS-instans. Vid planerade eller oplanerade avbrott i Azure-servrar startas virtuella datorer om på en annan tillgänglig server. Som tidigare nämnts skyddar omstart av virtuella Azure-datorer främst virtuella datorer och INTE program, i det här fallet (A)SCS-instansen. Genom omstarten av den virtuella datorn når vi indirekt högre tillgänglighet för SAP (A)SCS-instansen. Om du vill säkerställa automatisk start av (A)SCS-instansen efter omstarten av den virtuella datorn, se till att ange parametern Autostart i (A)SCS-instansens startprofil som beskrivs i kapitlet Använda autostart för SAP-instanser. Det innebär att den (A)SCS-instans som en SPOF (Single Point of Failure) som körs på en enda virtuell dator är den determinativa faktorn för tillgängligheten för hela SAP-miljön.

• Högre Tillgänglighet för DBMS-server

  I likhet med SAP (A)SCS-instansens användningsfall använder vi Azure VM Restart för att skydda den virtuella datorn med installerad DBMS-programvara, och vi uppnår högre tillgänglighet för DBMS-programvara genom omstart av virtuella datorer. DBMS som körs på en enda virtuell dator är också en SPOF, och det är den determinativa faktorn för tillgängligheten för hela SAP-miljön.

Hög tillgänglighet för SAP-program på Azure IaaS

För att uppnå fullständig hög tillgänglighet för SAP-system måste vi skydda alla kritiska SAP-systemkomponenter, till exempel redundanta SAP-programservrar och unika komponenter (till exempel en felkritisk systempunkt) som SAP (A)SCS-instans och DBMS.

Hög tillgänglighet för SAP-programservrar

För SAP-programservrar/dialoginstanser är det inte nödvändigt att tänka på en specifik lösning med hög tillgänglighet. Hög tillgänglighet uppnås genom redundans och därmed ha tillräckligt med av dem på olika virtuella datorer. De bör placeras i samma Azure-tillgänglighetsuppsättning för att undvika att de virtuella datorerna uppdateras samtidigt under planerat underhållsavbrott. De grundläggande funktionerna, som bygger på olika uppgraderings- och feldomäner i en Azure Scale Unit, introducerades redan i kapitlet Uppgraderingsdomäner. Tillgänglighetsuppsättningar för Azure presenterades i kapitlet Tillgänglighetsuppsättningar för Azure i det här dokumentet.

Det finns inget obegränsat antal fel- och uppgraderingsdomäner som kan användas av en Azure-tillgänglighetsuppsättning i en Azure-skalningsenhet. Det innebär att om du lägger ett antal virtuella datorer i en tillgänglighetsuppsättning hamnar förr eller senare mer än en virtuell dator i samma fel- eller uppgraderingsdomän.

När vi distribuerar några SAP-programserverinstanser på deras dedikerade virtuella datorer och antar att vi har fem uppgraderingsdomäner visas följande bild i slutet. Det faktiska maximala antalet fel- och uppdateringsdomäner inom en tillgänglighetsuppsättning kan komma att ändras i framtiden:

Hög tillgänglighet för SAP Central Services på Azure

Information om arkitekturen för hög tillgänglighet i SAP Central Services på Azure finns i artikeln Arkitektur med hög tillgänglighet och scenarier för SAP NetWeaver som postinformation. Artikeln pekar på mer detaljerade beskrivningar för de specifika operativsystemen.

Hög tillgänglighet för SAP-databasinstansen

Den typiska konfigurationen av SAP DBMS HA baseras på två virtuella DBMS-datorer där FUNKTIONER för hög tillgänglighet i DBMS används för att replikera data från den aktiva DBMS-instansen till den andra virtuella datorn till en passiv DBMS-instans.

Funktioner för hög tillgänglighet och haveriberedskap för DBMS i allmänhet och specifika DBMS beskrivs i DBMS-distributionsguiden.

Hög tillgänglighet från end-to-end för det fullständiga SAP-systemet

Här följer två exempel på en fullständig SAP NetWeaver HA-arkitektur i Azure – en för Windows och en för Linux.

Endast ohanterade diskar: Begreppen enligt beskrivningen nedan kan behöva komprometteras en del när du distribuerar många SAP-system och antalet distribuerade virtuella datorer överskrider den maximala gränsen på Storage-konton per prenumeration. I sådana fall måste virtuella hårddiskar för virtuella datorer kombineras inom ett Storage konto. Vanligtvis skulle du göra det genom att kombinera virtuella hårddiskar på SAP-programlagrets virtuella datorer i olika SAP-system. Vi har också kombinerat olika virtuella hårddiskar för olika VIRTUELLA DBMS-datorer i olika SAP-system i ett Azure Storage konto. Därmed håller IOPS-gränserna för Azure Storage-konton i åtanke ( https://azure.microsoft.com/documentation/articles/storage-scalability-targets )

Ha på Windows

Följande Azure-konstruktioner används för SAP NetWeaver-systemet för att minimera påverkan av infrastrukturproblem och värdkorrigeringar:

• Det fullständiga systemet distribueras på Azure (krävs – DBMS-lagret, (A)SCS-instansen och det fullständiga programlagret måste köras på samma plats).
• Det fullständiga systemet körs inom en Azure-prenumeration (krävs).
• Det fullständiga systemet körs inom en Azure-Virtual Network (krävs).
• Det går att separera de virtuella datorerna i ett SAP-system i tre tillgänglighetsuppsättningar även om alla virtuella datorer tillhör samma Virtual Network.
• Varje lager (till exempel DBMS, ASCS, programservrar) måste använda en dedikerad tillgänglighetsuppsättning.
• Alla virtuella datorer som kör DBMS-instanser av ett SAP-system finns i en tillgänglighetsuppsättning. Vi förutsätter att det finns fler än en virtuell dator som kör DBMS-instanser per system eftersom inbyggda funktioner för hög tillgänglighet i DBMS används, till exempel SQL Server AlwaysOn eller Oracle Data Guard.
• Alla virtuella datorer som kör DBMS-instanser använder sitt eget lagringskonto. DBMS-data och loggfiler replikeras från ett lagringskonto till ett annat lagringskonto med hjälp av funktioner för hög tillgänglighet i DBMS som synkroniserar data. Otillgängligt för ett lagringskonto gör att en klusternod SQL Windows otillgänglig, men inte hela SQL Server tjänsten.
• Alla virtuella datorer som kör (A)SCS-instansen av ett SAP-system finns i en tillgänglighetsuppsättning. Ett Windows Server Failover Cluster (WSFC) har konfigurerats på de virtuella datorerna för att skydda (A)SCS-instansen.
• Alla virtuella datorer som kör (A)SCS-instanser använder sitt eget lagringskonto. (A) SCS-instansfiler och global SAP-mapp replikeras från ett lagringskonto till ett annat lagringskonto med hjälp av SIOS DataKeeper-replikering. Otillgängligt för ett lagringskonto orsakar otillgänglighet för en (A)SCS Windows-klusternod, men inte hela (A)SCS-tjänsten.
• Alla virtuella datorer som representerar SAP-programserverskiktet finns i en tredje tillgänglighetsuppsättning.
• Alla virtuella datorer som kör SAP-programservrar använder sitt eget lagringskonto. Otillgängligt för ett lagringskonto leder till otillgänglighet för en SAP-programserver, där andra SAP-programservrar fortsätter att köras.

Följande bild illustrerar samma landskap med hjälp av Managed Disks.

Ha på Linux

Arkitekturen för SAP HA på Linux på Azure är i princip samma som för Windows enligt beskrivningen ovan. Se SAP Note [1928533 för] en lista över lösningar med hög tillgänglighet som stöds.

Använda Autostart för SAP-instanser

SAP erbjöd funktionen att starta SAP-instanser direkt efter starten av operativsystemet på den virtuella datorn. De exakta stegen dokumenterades i SAP Knowledge [Base-artikeln 1909114]. SAP rekommenderar dock inte att inställningen används längre eftersom det inte finns någon kontroll i instansens omstartsordning, förutsatt att mer än en virtuell dator påverkades eller att flera instanser kördes per virtuell dator. Om vi antar ett typiskt Azure-scenario med en SAP-programserverinstans på en virtuell dator och om en enskild virtuell dator så småningom startas om, är autostarten inte kritisk och kan aktiveras genom att lägga till den här parametern:

Autostart = 1

I startprofilen för SAP-ABAP och/eller Java-instansen.

Mer information om autostart för SAP-instanser finns här:

• Starta/stoppa SAP tillsammans med din Unix-server Starta/stoppa
• Starta och stoppa SAP NetWeaver-hanteringsagenter
• Så här aktiverar du automatisk start av HANA-databas

Större SAP-system på 3 nivåer

High-Availability aspekter av SAP-konfigurationer på 3 nivåer har redan diskuterats i tidigare avsnitt. Men vad gäller för system där DBMS-serverkraven är för stora för att finnas i Azure, men där SAP-programlagret kan distribueras till Azure?

Plats för SAP-konfigurationer på 3 nivåer

Det går inte att dela upp själva programnivån eller program- och DBMS-nivån mellan den lokala nivån och Azure. Ett SAP-system är antingen helt distribuerat lokalt ELLER i Azure. Det går inte heller att köra vissa programservrar lokalt och vissa andra i Azure. Det är startpunkten för diskussionen. Vi stöder inte heller att DBMS-komponenterna i ett SAP-system och SAP-programserverlagret distribueras i två olika Azure-regioner. Till exempel DBMS i USA, västra och SAP-programlagret i USA, centrala. Anledningen till att inte stödja sådana konfigurationer är svarstidens känslighet för SAP NetWeaver-arkitekturen.

Under föregående år utvecklade datacenterpartner dock samplatser till Azure-regioner. Dessa samplatser ligger ofta nära de fysiska Azure-datacentren i en Azure-region. Det korta avståndet och anslutningen för tillgångar på samplatsen via ExpressRoute till Azure kan resultera i en svarstid som är mindre än 2 millisekunder. I sådana fall är det möjligt att hitta DBMS-lagret (inklusive lagrings-SAN/NAS) på en sådan samplats och SAP-programlagret i Azure. HANA – stora instanser.

Säkerhetskopiering offline av SAP-system

Beroende på vilken SAP-konfiguration som valts (2- eller 3-nivå) kan det finnas ett behov av att backa upp. Innehållet i den virtuella datorn plus att ha en säkerhetskopia av databasen. De DBMS-relaterade säkerhetskopieringarna förväntas göras med databasmetoder. En detaljerad beskrivning för de olika databaserna finns i DBMS-guiden. Å andra sidan kan SAP-data säkerhetskopieras offline (inklusive även databasinnehållet) enligt beskrivningen i det här avsnittet eller online enligt beskrivningen i nästa avsnitt.

Offlinesäkerhetskopian kräver i princip en avstängning av den virtuella datorn via Azure Portal och en kopia av den virtuella basdisken plus alla anslutna diskar till den virtuella datorn. Detta skulle bevara en tidpunktsavbildning av den virtuella datorn och dess associerade disk. Vi rekommenderar att du kopierar säkerhetskopiorna till ett annat Azure Storage konto. Därför skulle proceduren som beskrivs i kapitlet Kopiera diskar mellan Azure Storage konton i det här dokumentet gälla.

En återställning av det tillståndet skulle bestå av att ta bort den virtuella basdatorn samt de ursprungliga diskarna på den virtuella basdatorn och monterade diskar, kopiera tillbaka de sparade diskarna till det ursprungliga Storage-kontot eller resursgruppen för hanterade diskar och sedan omdistribuera systemet. Den här artikeln visar ett exempel på hur du skriptar den här processen i PowerShell: https://www.westerndevs.com/_/azure-snapshots/

Se till att installera en ny SAP-licens eftersom återställning av en säkerhetskopia av en virtuell dator enligt beskrivningen ovan skapar en ny maskinvarunyckel.

Onlinesäkerhetskopiering av ett SAP-system

Säkerhetskopiering av DBMS utförs med DBMS-specifika metoder enligt beskrivningen i DBMS-guiden.

Andra virtuella datorer i SAP-systemet kan säkerhetskopieras med hjälp av funktionerna för säkerhetskopiering av virtuella Azure-datorer. Säkerhetskopiering av virtuella Azure-datorer är en standardmetod för att säkerhetskopiera en fullständig virtuell dator i Azure. Azure Backup lagrar säkerhetskopiorna i Azure och tillåter en återställning av en virtuell dator igen.

Azure som DR-plats för SAP-produktionslandskap

Sedan mitten av 2014 möjliggör tillägg till olika komponenter runt Hyper-V, System Center och Azure användning av Azure som DR-plats för virtuella datorer som körs lokalt baserat på Hyper-V.

En blogg som beskriver hur du distribuerar den här lösningen finns dokumenterad här: Skydda SAP-lösningar med Azure Site Recovery.

Sammanfattning för hög tillgänglighet för SAP-system

Viktiga punkter för hög tillgänglighet för SAP-system i Azure är:

• Vid den här tidpunkten kan inte SAP-felpunkten skyddas på exakt samma sätt som den kan göras i lokala distributioner. Anledningen är att delade diskkluster ännu inte kan byggas i Azure utan användning av programvara från tredje part.
• För DBMS-skiktet måste du använda DBMS-funktioner som inte förlitar sig på delad diskklusterteknik. Information finns dokumenterad i DBMS-guiden.
• För att minimera effekten av problem i feldomäner i Azure-infrastrukturen eller värdunderhållet bör du använda Azure-tillgänglighetsuppsättningar:
  • Vi rekommenderar att du har en tillgänglighetsuppsättning för SAP-programlagret.
  • Vi rekommenderar att du har en separat tillgänglighetsuppsättning för SAP DBMS-lagret.
  • Vi rekommenderar INTE att du använder samma tillgänglighetsuppsättning för virtuella datorer i olika SAP-system.
  • Vi rekommenderar att du använder Premium Managed Disks.
• I säkerhetskopieringssyften för SAP DBMS-lagret kontrollerar du DBMS-guiden.
• Det är inte helt meningsfullt att eftersom det vanligtvis går snabbare att omdistribuera enkla dialoginstanser.
• Det är logiskt att eftersom den virtuella datorn, som innehåller den globala katalogen i SAP-systemet och med den alla profiler för de olika instanserna, utförs med Windows Säkerhetskopiering eller till exempel tar i Linux. Eftersom det finns skillnader mellan Windows Server 2008 (R2) och Windows Server 2012 (R2), vilket gör det enklare att servera med de senaste Windows Server-versionerna, rekommenderar vi att du kör Windows Server 2012 (R2) som Windows gästoperativsystemet.

Nästa steg

Läs artiklarna:

• Azure Virtual Machines-distribution för SAP NetWeaver
• Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning
• Konfigurationer och åtgärder för SAP HANA i Azure-infrastrukturer