Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer

Azure Virtual Machines är lösningen för organisationer som behöver beräknings-, lagrings- och nätverksresurser på minimal tid och utan långa anskaffningscykler. Du kan använda Azure Virtual Machines för att distribuera klassiska program som SAP NetWeaver-baserade ABAP, Java och en ABAP+Java-stack. Utöka tillförlitlighet och tillgänglighet utan ytterligare lokala resurser. Azure Virtual Machines stöder anslutning på flera platser, så att du kan integrera Azure Virtual Machines i din organisations lokala domäner, privata moln och SAP-systemlandskap.

I den här artikeln beskriver vi de steg du kan vidta för att distribuera SAP-system med hög tillgänglighet i Azure med hjälp Azure Resource Manager distributionsmodellen. Vi går igenom dessa viktiga uppgifter:

• Hitta rätt SAP-anteckningar och installationsguider som anges i avsnittet Resurser. Den här artikeln kompletterar installationsdokumentationen för SAP och SAP Notes, som är de primära resurser som kan hjälpa dig att installera och distribuera SAP-programvara på specifika plattformar.
• Lär dig skillnaderna mellan Azure Resource Manager och den klassiska Azure-distributionsmodellen.
• Lär dig Windows kvorumlägena för server-redundanskluster, så att du kan välja den modell som är rätt för din Azure-distribution.
• Läs mer Windows server redundanskluster delad lagring i Azure-tjänster.
• Lär dig hur du skyddar komponenter med en enskild felpunkt som Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)/SAP Central Services (SCS) och databashanteringssystem (DBMS) och redundanta komponenter som SAP Application Server i Azure.
• Följ ett steg för steg-exempel på en installation och konfiguration av ett SAP-system med hög tillgänglighet i ett Windows Server Failover Clustering-kluster i Azure med hjälp av Azure Resource Manager.
• Lär dig mer om ytterligare steg som krävs för Windows server-redundansklustring i Azure, men som inte behövs i en lokal distribution.

För att förenkla distribution och konfiguration använder vi i den här artikeln SAP-mallarna med tre nivåer Resource Manager tillgänglighet. Mallarna automatiserar distributionen av hela infrastrukturen som du behöver för ett SAP-system med hög tillgänglighet. Infrastrukturen stöder också SAP Application Performance Standard -storleksändring (SAPS) för ditt SAP-system.

Förutsättningar

Innan du börjar kontrollerar du att du uppfyller kraven som beskrivs i följande avsnitt. Kontrollera också alla resurser som anges i avsnittet Resurser.

I den här artikeln använder vi Azure Resource Manager för SAP NetWeaver med tre nivåer. En användbar översikt över mallar finns i SAP Azure Resource Manager-mallar.

Resurser

De här artiklarna innehåller SAP-distributioner i Azure:

• Azure Virtual Machines planering och implementering för SAP NetWeaver
• Azure Virtual Machines-distribution för SAP NetWeaver
• Azure Virtual Machines DBMS-distribution för SAP NetWeaver
• Azure Virtual Machines hög tillgänglighet för SAP NetWeaver (den här guiden)

Dessa SAP-anteckningar är relaterade till sap-ämnet i Azure:

Läs mer om begränsningarna för Azure-prenumerationer,inklusive allmänna standardbegränsningar och maxbegränsningar.

SAP med hög tillgänglighet med Azure Resource Manager jämfört med den klassiska Azure-distributionsmodellen

Distributionsmodellerna Azure Resource Manager Azure och klassiska Azure skiljer sig åt inom följande områden:

• Resursgrupper
• Azures interna lastbalanserare är beroende av Azure-resursgruppen
• Stöd för SAP-scenarier med flera SID:er

Resursgrupper

I Azure Resource Manager kan du använda resursgrupper för att hantera alla programresurser i din Azure-prenumeration. En integrerad metod i en resursgrupp har alla resurser samma livscykel. Till exempel skapas alla resurser samtidigt och de tas bort samtidigt. Läs mer om resursgrupper.

Azures interna lastbalanserare är beroende av Azure-resursgruppen

I den klassiska Azure-distributionsmodellen finns det ett beroende mellan azures interna lastbalanserare (Azure Load Balancer service) och molntjänstgruppen. Varje intern lastbalanserare behöver en molntjänstgrupp.

I Azure Resource Manager behöver du inte någon Azure-resursgrupp för att använda Azure Load Balancer. Miljön är enklare och mer flexibel.

Stöd för SAP-scenarier med flera SID:er

I Azure Resource Manager kan du installera flera ASCS/SCS-instanser för SAP-systemidentifierare (SID) i ett kluster. Flera SID-instanser är möjliga på grund av stöd för flera IP-adresser för varje intern Azure-lastbalanserare.

Om du vill använda den klassiska Azure-distributionsmodellen följer du procedurerna som beskrivs i SAP NetWeaver i Azure: Klustring av SAP ASCS/SCS-instansermed hjälp av Windows Server-redundansklustring i Azure med SIOS DataKeeper.

Windows Redundansklustring för server

Windows Redundansklustring för server är grunden för en SAP ASCS/SCS-installation med hög tillgänglighet och DBMS i Windows.

Ett redundanskluster är en grupp med 1+n oberoende servrar (noder) som arbetar tillsammans för att öka tillgängligheten för program och tjänster. Om ett nodfel inträffar Windows server-redundansklustring antalet fel som kan inträffa samtidigt som ett felfritt kluster upprätthålls för att tillhandahålla program och tjänster. Du kan välja mellan olika kvorumlägen för att uppnå redundansklustring.

Kvorumlägen

Du kan välja mellan fyra kvorumlägen när du använder Windows redundansklustring för server:

• Nodmajoritet. Varje nod i klustret kan rösta. Klustret fungerar bara med en majoritet av rösterna, det vill säga med mer än hälften av rösterna. Vi rekommenderar det här alternativet för kluster som har ett ojämnt antal noder. Till exempel kan tre noder i ett kluster med sju noder misslyckas, och klustret uppnår fortfarande en majoritet och fortsätter att köras.
• Node och Disk Majority. Varje nod och en avsedd disk (ett diskvittne) i klusterlagringen kan rösta när de är tillgängliga och i kommunikation. Klustret fungerar bara med en majoritet av rösterna, det vill säga med mer än hälften av rösterna. Det här läget är logiskt i en klustermiljö med ett jämnt antal noder. Om hälften av noderna och disken är online förblir klustret i felfritt tillstånd.
• Nod- och filresursmajoritet. Varje nod plus en angiven filresurs (ett filresursvittne) som administratören skapar kan rösta, oavsett om noderna och filresursen är tillgängliga och i kommunikationen. Klustret fungerar bara med en majoritet av rösterna, det vill säga med mer än hälften av rösterna. Det här läget är logiskt i en klustermiljö med ett jämnt antal noder. Det liknar läget Nod och Diskmajoritet, men använder en filresurs för vittne i stället för en vittnesdisk. Det här läget är enkelt att implementera, men om själva filresursen inte har hög åtkomst kan det bli en felpunkt.
• Ingen majoritet: Endast disk. Klustret har ett kvorum om en nod är tillgänglig och i kommunikation med en specifik disk i klusterlagringen. Endast de noder som också är i kommunikation med den disken kan ansluta till klustret. Vi rekommenderar att du inte använder det här läget.

Windows Lokal server redundansklustring

Bild 1 visar ett kluster med två noder. Om nätverksanslutningen mellan noderna misslyckas och båda noderna förblir igång avgör en kvorumdisk eller filresurs vilken nod som fortsätter att tillhandahålla klustrets program och tjänster. Noden som har åtkomst till kvorumdisken eller filresursen är den nod som säkerställer att tjänsterna fortsätter.

Eftersom det här exemplet använder ett kluster med två noder använder vi kvorumläget Nod och Filresursmajoritet. Node och Disk Majority är också ett giltigt alternativ. I en produktionsmiljö rekommenderar vi att du använder en kvorumdisk. Du kan använda nätverks- och lagringssystemteknik för att ge den hög tillgång.

Bild 1: Exempel på en Windows serverkonfiguration för redundanskluster för SAP ASCS/SCS i Azure

Delad lagring

Bild 1 visar också ett delat lagringskluster med två noder. I ett lokalt delat lagringskluster identifierar alla noder i klustret delad lagring. En låsningsmekanism skyddar data från skador. Alla noder kan identifiera om en annan nod misslyckas. Om en nod misslyckas blir den återstående noden ägare till lagringsresurserna och säkerställer tjänsternas tillgänglighet.

Nätverk och namnmatchning

Klientdatorer når klustret via en virtuell IP-adress och ett virtuellt värdnamn som DNS-servern tillhandahåller. De lokala noderna och DNS-servern kan hantera flera IP-adresser.

I en typisk konfiguration använder du två eller flera nätverksanslutningar:

• En dedikerad anslutning till lagringen
• En kluster-intern nätverksanslutning för pulsslag
• Ett offentligt nätverk som klienter använder för att ansluta till klustret

Windows Redundansklustring för server i Azure

Jämfört med distributioner utan dator eller privata moln kräver Azure Virtual Machines ytterligare steg för att konfigurera Windows server-redundansklustring. När du skapar en delad klusterdisk måste du ange flera IP-adresser och virtuella värdnamn för SAP ASCS/SCS-instansen.

I den här artikeln diskuterar vi viktiga begrepp och de ytterligare steg som krävs för att skapa ett kluster för centrala tjänster med hög tillgänglighet för SAP i Azure. Vi visar hur du konfigurerar verktyget SIOS DataKeeper från tredje part och hur du konfigurerar den interna Azure-lastbalanseraren. Du kan använda dessa verktyg för att skapa ett Windows redundanskluster med ett filresursvittne i Azure.

Bild 2: Windows för redundansklustring för server i Azure utan en delad disk

Delad disk i Azure med SIOS DataKeeper

Du behöver delad klusterlagring för en SAP ASCS/SCS-instans med hög tillgänglighet. Från och med september 2016 erbjuder Azure inte delad lagring som du kan använda för att skapa ett delat lagringskluster. Du kan använda programvara från tredje part SIOS DataKeeper Cluster Edition för att skapa en speglad lagring som simulerar delad klusterlagring. SIOS-lösningen tillhandahåller synkron datareplikering i realtid. Så här kan du skapa en delad diskresurs för ett kluster:

1. Koppla ytterligare en virtuell Azure-hårddisk (VHD) till var och en av de virtuella datorerna i en Windows klusterkonfiguration.
2. Kör SIOS DataKeeper Cluster Edition på båda virtuella datornoderna.
3. Konfigurera SIOS DataKeeper Cluster Edition så att den speglar innehållet i den ytterligare VHD-anslutna volymen från den virtuella källdatorn till den ytterligare VHD-anslutna volymen på den virtuella måldatorn. SIOS DataKeeper abstraherar käll- och målvolymerna och presenterar dem sedan för Windows Server Failover Clustering som en delad disk.

Få mer information om SIOS DataKeeper.

Bild 3: Windows för redundansklustring för server i Azure med SIOS DataKeeper

Namnmatchning i Azure

Azure-molnplattformen erbjuder inte alternativet att konfigurera virtuella IP-adresser, till exempel flytande IP-adresser. Du behöver en alternativ lösning för att konfigurera en virtuell IP-adress för att nå klusterresursen i molnet. Azure har en intern lastbalanserare i Azure Load Balancer tjänsten. Med den interna lastbalanseraren når klienterna klustret via klustrets virtuella IP-adress. Du måste distribuera den interna lastbalanseraren i resursgruppen som innehåller klusternoderna. Konfigurera sedan alla nödvändiga regler för vidarebefordran av portar med avsökningsportarna för den interna lastbalanseraren. Klienterna kan ansluta via det virtuella värdnamnet. DNS-servern matchar klustrets IP-adress och den interna lastbalanseraren hanterar port vidarebefordran till den aktiva noden i klustret.

SAP NetWeaver hög tillgänglighet i Azure Infrastructure-as-a-Service (IaaS)

För att uppnå hög tillgänglighet för SAP-program, till exempel för SAP-programvarukomponenter, måste du skydda följande komponenter:

• SAP Application Server-instans
• SAP ASCS/SCS-instans
• DBMS-server

Mer information om hur du skyddar SAP-komponenter i scenarier med hög tillgänglighet finns i Azure Virtual Machines planering och implementering för SAP NetWeaver.

SAP Application Server med hög tillgänglighet

Du behöver vanligtvis inte någon specifik lösning med hög tillgänglighet för SAP-programservern och dialoginstanserna. Du uppnår hög tillgänglighet genom redundans och du konfigurerar flera dialoginstanser i olika instanser av Azure Virtual Machines. Du bör ha minst två SAP-programinstanser installerade i två instanser av Azure Virtual Machines.

Bild 4: SAP Application Server med hög tillgänglighet

Du måste placera alla virtuella datorer som är värdar för SAP Application Server-instanser i samma Azure-tillgänglighetsuppsättning. En Azure-tillgänglighetsuppsättning säkerställer att:

• Alla virtuella datorer ingår i samma uppgraderingsdomän. En uppgraderingsdomän ser till exempel till att de virtuella datorerna inte uppdateras samtidigt under planerat underhållsavbrott.
• Alla virtuella datorer ingår i samma feldomän. En feldomän ser till exempel till att virtuella datorer distribueras så att ingen enskild felpunkt påverkar tillgängligheten för alla virtuella datorer.

Läs mer om hur du hanterar tillgängligheten för virtuella datorer.

Eftersom Azure Storage-kontot är en potentiell felpunkt är det viktigt att ha minst två Azure-lagringskonton där minst två virtuella datorer distribueras. I en idealisk konfiguration skulle diskarna för varje virtuell dator som kör en SAP-dialoginstans distribueras i ett annat lagringskonto.

SAP ASCS/SCS-instans med hög tillgänglighet

Bild 5 är ett exempel på en SAP ASCS/SCS-instans med hög tillgänglighet.

Bild 5: SAP ASCS/SCS-instans med hög tillgänglighet

Hög tillgänglighet för SAP ASCS/SCS-instans Windows redundansklustring för server i Azure

Jämfört med distributioner utan dator eller privata moln kräver Azure Virtual Machines ytterligare steg för att konfigurera Windows server-redundansklustring. Om du vill Windows ett redundanskluster behöver du en delad klusterdisk, flera IP-adresser, flera virtuella värdnamn och en intern Azure-lastbalanserare för klustring av en SAP ASCS/SCS-instans. Vi diskuterar detta mer detaljerat längre fram i artikeln.

Bild 6: Windows Server Failover Clustering för en SAP ASCS/SCS-konfiguration i Azure med SIOS DataKeeper

DBMS-instans med hög tillgänglighet

DBMS är också en enda kontaktpunkt i ett SAP-system. Du måste skydda den med hjälp av en lösning med hög tillgänglighet. Bild 7 visar en SQL Server Always On-lösning för hög tillgänglighet i Azure, med Windows Server Failover Clustering (Redundansklustring för server) och den interna Azure-lastbalanseraren. SQL Server Always On replikerar DBMS-data och loggfiler med hjälp av en egen DBMS-replikering. I det här fallet behöver du inte klusterdelade diskar, vilket förenklar hela installationen.

Bild 7: Exempel på en SAP DBMS med hög tillgänglighet med SQL Server Always On

Mer information om klustring av SQL Server i Azure med hjälp av Azure Resource Manager-distributionsmodellen finns i följande artiklar:

• Konfigurera Always On-tillgänglighetsgrupp i Azure Virtual Machines manuellt med hjälp av Resource Manager
• Konfigurera en intern Azure-lastbalanserare för en Always On-tillgänglighetsgrupp i Azure

Distributionsscenarier för hög tillgänglighet från hela slutet

Distributionsscenario med arkitekturmall 1

Bild 8 visar ett exempel på en SAP NetWeaver-arkitektur med hög tillgänglighet i Azure för ett SAP-system. Det här scenariot konfigureras på följande sätt:

• Ett dedikerat kluster används för SAP ASCS/SCS-instansen.
• Ett dedikerat kluster används för DBMS-instansen.
• SAP Application Server-instanser distribueras på sina egna dedikerade virtuella datorer.

Bild 8: SAP arkitekturmall 1 med hög tillgänglighet, dedikerade kluster för ASCS/SCS och DBMS

Distributionsscenario med arkitekturmall 2

Bild 9 visar ett exempel på en SAP NetWeaver-arkitektur med hög tillgänglighet i Azure för ett SAP-system. Det här scenariot konfigureras på följande sätt:

• Ett dedikerat kluster används för både SAP ASCS/SCS-instansen och DBMS.
• SAP Application Server-instanser distribueras i egna dedikerade virtuella datorer.

Bild 9: SAP arkitekturmall 2 med hög tillgänglighet, med ett dedikerat kluster för ASCS/SCS och ett dedikerat kluster för DBMS

Distributionsscenario med arkitekturmall 3

Bild 10 visar ett exempel på en SAP NetWeaver-arkitektur med hög tillgänglighet i Azure för två SAP-system, med < SID1 och > < > SID2. Det här scenariot konfigureras på följande sätt:

• Ett dedikerat kluster används för både SAP ASCS/SCS SID1-instansen och SAP ASCS/SCS SID2-instansen (ett kluster).
• Ett dedikerat kluster används för DBMS SID1 och ett annat dedikerat kluster används för DBMS SID2 (två kluster).
• SAP Application Server-instanser för SAP-systemet SID1 har sina egna dedikerade virtuella datorer.
• SAP Application Server-instanser för SAP-systemet SID2 har sina egna dedikerade virtuella datorer.

Bild 10: SAP arkitekturmall 3 med hög tillgänglighet, med ett dedikerat kluster för olika ASCS/SCS-instanser

Förbereda infrastrukturen

Förbereda infrastrukturen för arkitekturmall 1

Azure Resource Manager för SAP förenklar distributionen av nödvändiga resurser.

Mallarna med tre nivåer i Azure Resource Manager också stöd för scenarier med hög tillgänglighet, till exempel i Arkitekturmall 1, som har två kluster. Varje kluster är en sap-felpunkt för SAP ASCS/SCS och DBMS.

Här kan du hämta mallar Azure Resource Manager exempelscenariot som beskrivs i den här artikeln:

• Azure Marketplace bild
• Anpassad avbildning

Så här förbereder du infrastrukturen för arkitekturmall 1:

• I Azure Portal på bladet Parametrar i rutan SYSTEMTILLGÄNGLIGHET väljer du HA.

  

Bild 11: Ange SAP-parametrar för Azure Resource Manager tillgänglighet

Mallarna skapar:

• Virtuella datorer:

  • Virtuella datorer för SAP Application Server: <SAPSystemSID>-di-<-nummer >
  • Virtuella ASCS/SCS-klusterdatorer: <SAPSystemSID>-ascs-<Number>
  • DBMS-kluster: <SAPSystemSID>-db-<Number>

• Nätverkskort för alla virtuella datorer med associerade IP-adresser:

  • <SAPSystemSID>-nic-di-<Number>
  • <SAPSystemSID>-nic-ascs-<Number>
  • <SAPSystemSID>-nic-db-<Number>

• Azure-lagringskonton

• Tillgänglighetsgrupper för:

  • Virtuella datorer med SAP Application Server: <SAPSystemSID>-avset-di
  • Virtuella datorer för SAP ASCS/SCS-kluster: <SAPSystemSID>-avset-ascs
  • Virtuella DBMS-klusterdatorer: <SAPSystemSID>-avset-db

• Intern Lastbalanserare i Azure:

  • Med alla portar för ASCS/SCS-instansen och IP-<SAPSystemSID>-lb-ascs
  • Med alla portar för SQL Server DBMS och IP-<SAPSystemSID>-lb-db

• Nätverkssäkerhetsgrupp:<SAPSystemSID>-nsg-ascs-0

  • Med en öppen extern Remote Desktop Protocol(RDP)-port till <SAPSystemSID>-ascs-0 virtuell dator

Distribuera virtuella datorer med företagsnätverksanslutning (mellan olika platser) som ska användas i produktion

För SAP-system för produktion distribuerar du virtuella Azure-datorer med företagsnätverksanslutningar med hjälp av Azure VPN för plats-till-plats eller Azure ExpressRoute.

1. Välj Azure Portal i rutan NEWOREXISTINGSUBNET på bladet Parametrar i rutan NEWOREXISTINGSUBNET.

2. I rutan SUBNETID lägger du till den fullständiga strängen för ditt förberedda Azure-nätverksundernätID där du planerar att distribuera dina virtuella Azure-datorer.

3. Kör följande PowerShell-kommando för att hämta en lista över alla Azure-nätverksundernät:

   (Get-AzureRmVirtualNetwork -Name <azureVnetName>  -ResourceGroupName <ResourceGroupOfVNET>).Subnets
   

   Fältet ID visar SUBNETID.

4. Kör följande PowerShell-kommando för att hämta en lista över alla SUBNETID-värden:

   (Get-AzureRmVirtualNetwork -Name <azureVnetName>  -ResourceGroupName <ResourceGroupOfVNET>).Subnets.Id
   

   SUBNETID ser ut så här:

   /subscriptions/<SubscriptionId>/resourceGroups/<VPNName>/providers/Microsoft.Network/virtualNetworks/azureVnet/subnets/<SubnetName>
   

Distribuera endast molnbaserade SAP-instanser för testning och demonstration

Du kan distribuera ditt SAP-system med hög tillgänglighet i en molnbaserad distributionsmodell. Den här typen av distribution är främst användbar för användningsfall för demonstration och testning. Det passar inte för produktionsanvändningsfall.

• Välj Azure Portal i rutan NEWOREXISTINGSUBNET på bladet Parametrar i rutan NEWOREXISTINGSUBNET. Lämna fältet SUBNETID tomt.

  SAP-Azure Resource Manager skapar automatiskt det virtuella Azure-nätverket och undernätet.

Förbereda infrastrukturen för arkitekturmall 2

Du kan använda den här Azure Resource Manager för SAP för att förenkla distributionen av nödvändiga infrastrukturresurser för SAP Architectural Template 2.

Här kan du hämta mallar Azure Resource Manager det här distributionsscenariot:

• Azure Marketplace bild
• Anpassad avbildning

Förbereda infrastrukturen för arkitekturmall 3

Du kan förbereda infrastrukturen och konfigurera SAP för flera SID. Du kan till exempel lägga till ytterligare en SAP ASCS/SCS-instans i en befintlig klusterkonfiguration. Mer information finns i Konfigurera ytterligare en SAP ASCS/SCS-instansi en befintlig klusterkonfiguration för att skapa en SAP-konfiguration med flera SID i Azure Resource Manager .

Om du vill skapa ett nytt kluster med flera SID kan du använda snabbstartsmallarnaför flera SID på GitHub . Om du vill skapa ett nytt kluster med flera SID måste du distribuera följande tre mallar:

• ASCS/SCS-mall
• Databasmall
• Mall för programservrar

Följande avsnitt innehåller mer information om mallarna och de parametrar som du behöver ange i mallarna.

ASCS/SCS-mall

ASCS/SCS-mallen distribuerar två virtuella datorer som du kan använda för att skapa ett Windows Server-redundanskluster som är värd för flera ASCS/SCS-instanser.

Om du vill konfigurera ASCS/SCS multi-SID-mallen anger du värden för följande parametrar i ascs/SCS multi-SID-mallen:

• Resursprefix. Ange resursprefixet, som används för att lägga till prefixet för alla resurser som skapas under distributionen. Eftersom resurserna inte bara tillhör ett SAP-system är prefixet för resursen inte SID för ett SAP-system. Prefixet måste vara mellan tre och sex tecken.
• Stacktyp. Välj stacktyp för SAP-systemet. Beroende på stacktypen har Azure Load Balancer (endast ABAP eller Java) eller två privata IP-adresser (ABAP+Java) per SAP-system.
• OS-typ. Välj operativsystem för de virtuella datorerna.
• SAP-systemantal. Välj det antal SAP-system som du vill installera i det här klustret.
• Systemtillgänglighet. Välj HA.
• Administratörsnamn och administratörslösenord. Skapa en ny användare som kan användas för att logga in på datorn.
• Nytt eller befintligt undernät. Ange om ett nytt virtuellt nätverk och undernät ska skapas, eller om ett befintligt undernät ska användas. Om du redan har ett virtuellt nätverk som är anslutet till ditt lokala nätverk väljer du befintligt.
• Undernäts-ID. Om du vill distribuera den virtuella datorn till ett befintligt virtuellt nätverk där du har ett undernät som definierats som den virtuella datorn ska tilldelas ska du namnge ID:t för det specifika undernätet. ID:t ser vanligtvis ut så här: /subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualNetworks/<virtual network name>/subnets/<subnet name>

Mallen distribuerar en Azure Load Balancer instans, som stöder flera SAP-system.

• ASCS-instanserna är konfigurerade för instansnummer 00, 10, 20...
• SCS-instanserna är konfigurerade för instansnummer 01, 11, 21...
• INSTANSERNA för ASCS Enqueue Replication Server (ERS) (endast Linux) har konfigurerats för instansnummer 02, 12, 22...
• SCS ERS-instanserna (endast Linux) konfigureras för instansnummer 03, 13, 23...

Lastbalanseraren innehåller 1 (2 för Linux) VIP(er), 1x VIP för ASCS/SCS och 1x VIP för ERS (endast Linux).

Följande lista innehåller alla belastningsutjämningsregler (där x är antalet SAP-system, till exempel 1, 2, 3...):

• Windows specifika portar för varje SAP-system: 445, 5985
• ASCS-portar (instansnummer x0): 32x0, 36x0, 39x0, 81x0, 5x013, 5x014, 5x016
• SCS-portar (instansnummer x1): 32x1, 33x1, 39x1, 81x1, 5x113, 5x114, 5x116
• ASCS ERS-portar på Linux (instansnummer x2): 33x2, 5x213, 5x214, 5x216
• SCS ERS-portar på Linux (instansnummer x3): 33x3, 5x313, 5x314, 5x316

Lastbalanseraren är konfigurerad för att använda följande avsökningsportar (där x är antalet SAP-system, till exempel 1, 2, 3...):

• Avsökningsport för ASCS/SCS-intern lastbalanserare: 620x0
• ERS-avsökningsport för intern lastbalanserare (endast Linux): 621x2

Databasmall

Databasmallen distribuerar en eller två virtuella datorer som du kan använda för att installera hanteringssystemet för relationsdatabaser (RDBMS) för ett SAP-system. Om du till exempel distribuerar en ASCS/SCS-mall för fem SAP-system måste du distribuera den här mallen fem gånger.

Om du vill konfigurera databasens multi-SID-mall anger du värden för följande parametrar i databasens multi-SID-mall:

• Sap System Id. Ange SAP-system-ID för det SAP-system som du vill installera. ID:t används som ett prefix för de resurser som distribueras.
• Os-typ. Välj operativsystem för de virtuella datorerna.
• Dbtype. Välj typ av databas som du vill installera i klustret. Välj SQL om du vill installera Microsoft SQL Server. Välj HANA om du planerar att installera SAP HANA på de virtuella datorerna. Se till att välja rätt typ av operativsystem: välj Windows för SQL och välj en Linux-distribution för HANA. Den Azure Load Balancer som är ansluten till de virtuella datorerna konfigureras för att stödja den valda databastypen:
  • SQL. Lastbalanseraren lastbalanserar port 1433. Se till att använda den här porten för din SQL Server Always On-konfiguration.
  • HANA. Lastbalanseraren lastbalanserar portarna 35015 och 35017. Se till att installera SAP HANA med instansnummer 50. Lastbalanseraren använder avsökningsport 62550.
• Sap System Size. Ange antalet SAPS som det nya systemet ska tillhandahålla. Om du inte är säker på hur många SAPS som systemet kräver kan du fråga din SAP Technology Partner eller System Integrator.
• Systemtillgänglighet. Välj HA.
• Administratörsnamn och administratörslösenord. Skapa en ny användare som kan användas för att logga in på datorn.
• Undernäts-ID. Ange ID:t för det undernät som du använde vid distributionen av ASCS/SCS-mallen eller ID:t för det undernät som skapades som en del av ascs/SCS-malldistributionen.

Mall för programservrar

Mallen för programservrar distribuerar två eller flera virtuella datorer som kan användas som SAP Application Server-instanser för ett SAP-system. Om du till exempel distribuerar en ASCS/SCS-mall för fem SAP-system måste du distribuera den här mallen fem gånger.

Om du vill konfigurera mallen för programservrar med flera SID anger du värden för följande parametrar i mallen för programservrar med flera SID:

• Sap System Id. Ange SAP-system-ID för det SAP-system som du vill installera. ID:t används som ett prefix för de resurser som distribueras.
• Os-typ. Välj operativsystem för de virtuella datorerna.
• Sap System Size. Antalet SAPS som det nya systemet kommer att tillhandahålla. Om du inte är säker på hur många SAPS som systemet kräver kan du fråga din SAP Technology Partner eller System Integrator.
• Systemtillgänglighet. Välj HA.
• Administratörsnamn och administratörslösenord. Skapa en ny användare som kan användas för att logga in på datorn.
• Undernäts-ID. Ange ID:t för det undernät som du använde vid distributionen av ASCS/SCS-mallen eller ID:t för det undernät som skapades som en del av ascs/SCS-malldistributionen.

Virtuellt Azure-nätverk

I vårt exempel är adressutrymmet för det virtuella Azure-nätverket 10.0.0.0/16. Det finns ett undernät med namnet Subnet, med adressintervallet 10.0.0.0/24. Alla virtuella datorer och interna lastbalanserare distribueras i det här virtuella nätverket.

DNS IP-adresser

Gör följande för att ange de DNS IP-adresser som krävs.

1. I den Azure Portal på bladet DNS-servrar kontrollerar du att alternativet DNS-servrar för det virtuella nätverket är inställt på Anpassad DNS.

2. Välj dina inställningar baserat på vilken typ av nätverk du har. Mer information finns i följande resurser:

   • Lägg till IP-adresserna för de lokala DNS-servrarna.
     Du kan utöka lokala DNS-servrar till de virtuella datorer som körs i Azure. I det scenariot kan du lägga till IP-adresserna för de virtuella Azure-datorer där du kör DNS-tjänsten.
   • För isolerade distributioner i Azure: Distribuera ytterligare en virtuell dator i samma Virtual Network som fungerar som en DNS-server. Lägg till IP-adresserna för de virtuella Azure-datorer som du har ställt in för att köra DNS-tjänsten.

   

   Bild 12: Konfigurera DNS-servrar för Azure Virtual Network

   Anteckning

   Om du ändrar IP-adresserna för DNS-servrarna måste du starta om de virtuella Azure-datorerna för att tillämpa ändringen och sprida de nya DNS-servrarna.

I vårt exempel installeras och konfigureras DNS-tjänsten på Windows virtuella datorer:

Värdnamn och statiska IP-adresser för den klustrade SAP ASCS/SCS-instansen och den klustrade DBMS-instansen

För lokal distribution behöver du dessa reserverade värdnamn och IP-adresser:

När du skapar klustret skapar du de virtuella värdnamnen pr1-ascs-vir och pr1-dbms-vir och de associerade IP-adresser som hanterar själva klustret. Information om hur du gör detta finns i Samla in klusternoder i en klusterkonfiguration.

Du kan manuellt skapa de andra två virtuella värdnamnen pr1-ascs-sap och pr1-dbms-sap och de associerade IP-adresserna på DNS-servern. Den klustrade SAP ASCS/SCS-instansen och den klustrade DBMS-instansen använder dessa resurser. Information om hur du gör detta finns i Skapa ett virtuellt värdnamn för en klustrad SAP ASCS/SCS-instans.

Ange statiska IP-adresser för de virtuella SAP-datorerna

När du har distribuerat de virtuella datorer som ska användas i klustret måste du ange statiska IP-adresser för alla virtuella datorer. Gör detta i Azure Virtual Network konfiguration och inte i gästoperativsystemet.

1. I Azure Portal väljer du Nätverkskort för > resursgrupp Inställningar > > IP-adress.

2. På bladet IP-adresser går du till Tilldelning och väljer Statisk. I rutan IP-adress anger du den IP-adress som du vill använda.

   Anteckning

   Om du ändrar IP-adressen för nätverkskortet måste du starta om de virtuella Azure-datorerna för att tillämpa ändringen.

   

   Bild 13: Ange statiska IP-adresser för nätverkskortet för varje virtuell dator

   Upprepa det här steget för alla nätverksgränssnitt, det vill säga för alla virtuella datorer, inklusive virtuella datorer som du vill använda för Din Active Directory/DNS-tjänst.

I vårt exempel har vi dessa virtuella datorer och statiska IP-adresser:

Ange en statisk IP-adress för den interna Azure-lastbalanseraren

SAP Azure Resource Manager mallen skapar en intern Azure-lastbalanserare som används för SAP ASCS/SCS-instansklustret och DBMS-klustret.

Så här anger du en statisk IP-adress för den interna Azure-lastbalanseraren:

1. Den första distributionen anger den interna lastbalanserings-IP-adressen till Dynamisk. I Azure Portal på bladet IP-adresser, under Tilldelning, väljer du Statisk.

2. Ange IP-adressen för den interna lastbalanseraren pr1-lb-ascs till IP-adressen för det virtuella värdnamnet för SAP ASCS/SCS-instansen.

3. Ange IP-adressen för den interna lastbalanseraren pr1-lb-dbms till IP-adressen för det virtuella värdnamnet för DBMS-instansen.

   

   Bild 14: Ange statiska IP-adresser för den interna lastbalanseraren för SAP ASCS/SCS-instansen

I vårt exempel har vi två interna Azure-lastbalanserare som har dessa statiska IP-adresser:

Standardregler för ASCS/SCS-lastbalansering för den interna Azure-lastbalanseraren

SAP Azure Resource Manager mallen skapar de portar som du behöver:

• En ABAP ASCS-instans med standardinstansnumret 00
• En Java SCS-instans med standardinstansnumret 01

När du installerar din SAP ASCS/SCS-instans måste du använda standardinstansnumret 00 för din ABAP ASCS-instans och standardinstansnumret 01 för Din Java SCS-instans.

Skapa sedan nödvändiga interna slutpunkter för belastningsutjämning för SAP NetWeaver-portarna.

Om du vill skapa nödvändiga interna slutpunkter för belastningsutjämning skapar du först dessa slutpunkter för belastningsutjämning för SAP NetWeaver ABAP ASCS-portarna:

Tabell 1: Portnummer för SAP NetWeaver ABAP ASCS-instanser

Skapa sedan dessa slutpunkter för belastningsutjämning för SAP NetWeaver Java SCS-portarna:

Tabell 2: Portnummer för SAP NetWeaver Java SCS-instanser

Bild 15: Standardregler för ASCS/SCS-lastbalansering för den interna Azure-lastbalanseraren

Ange IP-adressen för lastbalanseraren pr1-lb-dbms till IP-adressen för det virtuella värdnamnet för DBMS-instansen.

Ändra STANDARDreglerna för lastbalansering i ASCS/SCS för den interna Azure-lastbalanseraren

Om du vill använda olika tal för SAP ASCS- eller SCS-instanserna måste du ändra namn och värden för deras portar från standardvärden.

1. I den Azure Portal väljer du < SID>-lb-ascs lastbalanserare > Lastbalanseringsregler.

2. Ändra följande värden för alla belastningsutjämningsregler som tillhör SAP ASCS- eller SCS-instansen:

   • Namn
   • Port
   • Backend-port

   Om du till exempel vill ändra standardinstansnumret för ASCS från 00 till 31 måste du göra ändringarna för alla portar som anges i tabell 1.

   Här är ett exempel på en uppdatering för port lbrule3200.

   

   Bild 16: Ändra STANDARDreglerna för lastbalansering i ASCS/SCS för den interna Azure-lastbalanseraren

Lägga Windows virtuella datorer i domänen

När du har tilldelar en statisk IP-adress till de virtuella datorerna lägger du till de virtuella datorerna i domänen.

Bild 17: Lägga till en virtuell dator i en domän

Lägga till registerposter på båda klusternoderna i SAP ASCS/SCS-instansen

Azure Load Balancer har en intern lastbalanserare som stänger anslutningar när anslutningarna är inaktiva under en viss tidsperiod (en tidsgräns för inaktivitet). SAP-arbetsprocesser i dialoginstanser öppnar anslutningar till SAP-ifyllningsprocessen så snart den första iqueue/dequeue-begäran måste skickas. Dessa anslutningar förblir vanligtvis etablerade tills arbetsprocessen eller den förkommande processen startas om. Men om anslutningen är inaktiv under en viss tidsperiod stänger den interna Azure-lastbalanseraren anslutningarna. Det här är inget problem eftersom SAP-arbetsprocessen återupprättar anslutningen till den förslutna processen om den inte längre finns. Dessa aktiviteter dokumenteras i utvecklarspårningarna av SAP-processer, men de skapar en stor mängd extra innehåll i dessa spårningar. Det är en bra idé att ändra TCP/IP och KeepAliveTime på KeepAliveInterval båda klusternoderna. Kombinera dessa ändringar i TCP/IP-parametrarna med SAP-profilparametrarna, som beskrivs senare i artikeln.

Om du vill lägga till registerposter på båda klusternoderna i SAP ASCS/SCS-instansen lägger du först till dessa Windows-registerposter på båda Windows-klusternoderna för SAP ASCS/SCS:

Tabell 3: Ändra den första TCP/IP-parametern

Lägg sedan till Windows registerposter på båda Windows för SAP ASCS/SCS:

Tabell 4: Ändra den andra TCP/IP-parametern

Om du vill tillämpa ändringarna startar du om båda klusternoderna.

Konfigurera ett Windows serverkluster för redundanskluster för en SAP ASCS/SCS-instans

Att konfigurera ett Windows serverkluster för redundanskluster för en SAP ASCS/SCS-instans omfattar följande uppgifter:

• Samla in klusternoderna i en klusterkonfiguration
• Konfigurera ett klusterfilresursvittne

Samla in klusternoderna i en klusterkonfiguration

1. I guiden Lägg till roll och funktioner lägger du till redundanskluster till båda klusternoderna.

2. Konfigurera redundansklustret med hjälp av Klusterhanteraren för växling vid fel. I Klusterhanteraren för växling vid fel väljer du Skapa kluster och lägger sedan bara till namnet på det första klustret, nod A. Lägg inte till den andra noden ännu. du lägger till den andra noden i ett senare steg.

   

   Bild 18: Lägg till server- eller virtuellt datornamn för den första klusternoden

3. Ange klustrets nätverksnamn (virtuellt värdnamn).

   

   Bild 19: Ange klusternamnet

4. När du har skapat klustret kör du ett klustervalideringstest.

   

   Bild 20: Kör klusterverifieringskontrollen

   Du kan ignorera eventuella varningar om diskar i det här läget i processen. Du lägger till ett filresursvittne och de delade SIOS-diskarna senare. I det här skedet behöver du inte bekymra dig om att ha ett kvorum.

   

   Bild 21: Ingen kvorumdisk hittades

   

   Bild 22: Kärnklusterresursen behöver en ny IP-adress

5. Ändra IP-adressen för kärnklustertjänsten. Klustret kan inte starta förrän du ändrar IP-adressen för kärnklustertjänsten eftersom serverns IP-adress pekar på en av de virtuella datornoderna. Gör detta på sidan Egenskaper för kärnklustertjänstens IP-resurs.

   Vi måste till exempel tilldela en IP-adress (i vårt exempel 10.0.0.42) för klustrets virtuella värdnamn pr1-ascs-vir.

   

   Bild 23: I dialogrutan Egenskaper ändrar du IP-adressen

   

   Bild 24: Tilldela DEN IP-adress som är reserverad för klustret

6. Ta klustrets virtuella värdnamn online.

   

   Bild 25: Klusterkärntjänsten är igång och med rätt IP-adress

7. Lägg till den andra klusternoden.

   Nu när kärnklustertjänsten är igång kan du lägga till den andra klusternoden.

   

   Bild 26: Lägg till den andra klusternoden

8. Ange ett namn för den andra klusternodvärden.

   

   Bild 27: Ange värdnamnet för den andra klusternoden

   Viktigt

   Kontrollera att kryssrutan Lägg till alla berättigade lagringsenheter i klustret INTE är markerad.

   

   Bild 28: Markera inte kryssrutan

   Du kan ignorera varningar om kvorum och diskar. Du anger kvorum och delar disken senare, enligt beskrivningen i Installera SIOS DataKeeper Cluster Edition för SAP ASCS/SCS-klusterresursdisken.

   

   Bild 29: Ignorera varningar om diskkvorum

Konfigurera ett klusterfilresursvittne

Konfigurering av ett klusterfilresursvittne omfattar följande uppgifter:

• Skapa en filresurs
• Ange kvorum för filresursvittne i Klusterhanteraren för växling vid fel

Skapa en filresurs

1. Välj ett filresursvittne i stället för en kvorumdisk. SIOS DataKeeper stöder det här alternativet.

   I exemplen i den här artikeln finns filresursvittnet på den Active Directory/DNS-server som körs i Azure. Filresursvittnet kallas domcontr-0. Eftersom du skulle ha konfigurerat en VPN-anslutning till Azure (via PLATS-till-plats-VPN eller Azure ExpressRoute) är Din Active Directory/DNS-tjänst lokal och är inte lämplig för att köra ett filresursvittne.

   Anteckning

   Om Active Directory/DNS-tjänsten endast körs lokalt ska du inte konfigurera filresursvittnet på operativsystemet Active Directory/DNS Windows som körs lokalt. Nätverksfördröjningen mellan klusternoder som körs i Azure och Active Directory/DNS lokalt kan vara för stor och orsaka anslutningsproblem. Se till att konfigurera filresursvittnet på en virtuell Azure-dator som körs nära klusternoden.

   Kvorumenheten måste ha minst 1 024 MB ledigt utrymme. Vi rekommenderar 2 048 MB ledigt utrymme för kvorumenheten.

2. Lägg till klusternamnsobjektet.

   

   Bild 30: Tilldela behörigheter på resursen för klusternamnobjektet

   Se till att behörigheterna inkluderar behörighet att ändra data i resursen för klustrets namnobjekt (i vårt exempel pr1-ascs-vir$).

3. Om du vill lägga till klustrets namnobjekt i listan väljer du Lägg till. Ändra filtret för att söka efter datorobjekt, förutom de som visas i bild 31.

   

   Bild 31: Ändra objekttyperna så att de inkluderar datorer

   

   Bild 32: Markera kryssrutan Datorer

4. Ange klustrets namnobjekt enligt bild 31. Eftersom posten redan har skapats kan du ändra behörigheterna, som du ser i bild 30.

5. Välj fliken Säkerhet för resursen och ange mer detaljerade behörigheter för klustrets namnobjekt.

   

   Bild 33: Ange säkerhetsattribut för klusternamnsobjektet i kvorum för filresursen

Ange kvorum för filresursvittne i Klusterhanteraren för växling vid fel

1. Öppna guiden Konfigurera kvoruminställning.

   

   Bild 34: Starta guiden Konfigurera inställning för klusterkvorum

2. På sidan Välj kvorumkonfiguration väljer du Välj kvorumvittnet.

   

   Bild 35: Kvorumkonfigurationer som du kan välja mellan

3. På sidan Välj kvorumvittne väljer du Konfigurera ett filresursvittne.

   

   Bild 36: Välj filresursvittnet

4. Ange UNC-sökvägen till filresursen (i vårt exempel \ domcontr-0\FSW). Om du vill se en lista över de ändringar du kan göra väljer du Nästa.

   

   Bild 37: Definiera filresursplatsen för vittnesresursen

5. Välj de ändringar du vill ha och välj sedan Nästa. Du måste konfigurera om klusterkonfigurationen på det sätt som visas i bild 38.

   

   Bild 38: Bekräftelse på att du har konfigurerat om klustret

När du har Windows redundansklustret måste du göra ändringar i vissa tröskelvärden för att anpassa redundansidentifiering till villkor i Azure. De parametrar som ska ändras dokumenteras i den här bloggen: https://techcommunity.microsoft.com/t5/Failover-Clustering/Tuning-Failover-Cluster-Network-Thresholds/ba-p/371834 . Förutsatt att de två virtuella datorerna som skapar Windows-klusterkonfigurationen för ASCS/SCS finns i samma undernät måste följande parametrar ändras till dessa värden:

• SameSubNetDelay = 2000
• SameSubNetThreshold = 15
• RoutingHistoryLength = 30

De här inställningarna testades med kunder och gav en bra kompromiss för att vara tillräckligt motståndskraftiga på den ena sidan. Å andra sidan gav dessa inställningar tillräckligt snabb redundans i verkliga feltillstånd för SAP-programvara eller nod-/VM-fel.

Installera SIOS DataKeeper Cluster Edition för SAP ASCS/SCS-klusterresursdisken

Nu har du en fungerande konfiguration Windows Server Failover Clustering i Azure. Men om du vill installera en SAP ASCS/SCS-instans behöver du en delad diskresurs. Du kan inte skapa de delade diskresurser som du behöver i Azure. SIOS DataKeeper Cluster Edition är en lösning från tredje part som du kan använda för att skapa delade diskresurser.

Installation av SIOS DataKeeper Cluster Edition för SAP ASCS/SCS-klusterresursdisken omfattar följande uppgifter:

• Lägga till .NET Framework 3.5
• Installera SIOS DataKeeper
• Konfigurera SIOS DataKeeper

Lägg till .NET Framework 3.5

Microsoft .NET Framework 3.5 aktiveras eller installeras inte automatiskt på Windows Server 2012 R2. Eftersom SIOS DataKeeper kräver att .NET Framework finns på alla noder som du installerar DataKeeper på måste du installera .NET Framework 3.5 på gästoperativsystemet på alla virtuella datorer i klustret.

Det finns två sätt att lägga till .NET Framework 3.5:

• Använd guiden Lägg till roller och funktioner i Windows enligt bild 39.

  

  Bild 39: Installera .NET Framework 3.5 med hjälp av guiden Lägg till roller och funktioner

  

  Bild 40: Installationsförloppet när du installerar .NET Framework 3.5 med hjälp av guiden Lägg till roller och funktioner

• Använd kommandoradsverktyget för dism.exe. För den här typen av installation måste du komma åt SxS-katalogen på Windows installationsmediet. I en upphöjd kommandotolk skriver du:

  Dism /online /enable-feature /featurename:NetFx3 /All /Source:installation_media_drive:\sources\sxs /LimitAccess
  

Installera SIOS DataKeeper

Installera SIOS DataKeeper Cluster Edition på varje nod i klustret. Om du vill skapa virtuell delad lagring med SIOS DataKeeper skapar du en synkroniserad spegling och simulerar sedan delad klusterlagring.

Innan du installerar SIOS-programvaran skapar du domänanvändaren DataKeeperSvc.

Så här installerar du SIOS DataKeeper:

1. Installera SIOS-programvaran på båda klusternoderna.

   

   

   Bild 41: Första sidan i SIOS DataKeeper-installationen

2. I dialogrutan som visas i bild 42 väljer du Ja.

   

   Bild 42: DataKeeper informerar dig om att en tjänst kommer att inaktiveras

3. I dialogrutan som visas i bild 43 rekommenderar vi att du väljer Domän eller Serverkonto.

   

   Bild 43: Användarval för SIOS DataKeeper

4. Ange användarnamnet och lösenorden för domänkontot som du skapade för SIOS DataKeeper.

   

   Bild 44: Ange domännamnet och lösenordet för SIOS DataKeeper-installationen

5. Installera licensnyckeln för din SIOS DataKeeper-instans enligt bild 45.

   

   Bild 45: Ange din SIOS DataKeeper-licensnyckel

6. Starta om den virtuella datorn när du uppmanas till det.

Konfigurera SIOS DataKeeper

När du har installerat SIOS DataKeeper på båda noderna måste du starta konfigurationen. Målet med konfigurationen är att ha synkron datareplikering mellan de ytterligare virtuella hårddiskarna som är kopplade till var och en av de virtuella datorerna.

1. Starta verktyget DataKeeper Management and Configuration och välj sedan Anslut Server. (I bild 46 är det här alternativet inringat i rött.)

   

   Bild 46: SIOS DataKeeper-hanterings- och konfigurationsverktyg

2. Ange namnet eller TCP/IP-adressen för den första noden som hanterings- och konfigurationsverktyget ska ansluta till och, i ett andra steg, den andra noden.

   

   Bild 47: Infoga namnet eller TCP/IP-adressen för den första noden som hanterings- och konfigurationsverktyget ska ansluta till och i ett andra steg den andra noden

3. Skapa replikeringsjobbet mellan de två noderna.

   

   Bild 48: Skapa ett replikeringsjobb

   En guide vägleder dig genom processen för att skapa ett replikeringsjobb.

4. Definiera namn, TCP/IP-adress och diskvolym för källnoden.

   

   Bild 49: Definiera namnet på replikeringsjobbet

   

   Bild 50: Definiera basdata för noden, som ska vara den aktuella källnoden

5. Definiera namnet, TCP/IP-adressen och diskvolymen för målnoden.

   

   Bild 51: Definiera basdata för noden, som ska vara den aktuella målnoden

6. Definiera komprimeringsalgoritmerna. I vårt exempel rekommenderar vi att du komprimerar replikeringsströmmen. I synnerhet i omsynkroniseringssituationer minskar komprimeringen av replikeringsströmmen avsevärt omsynkroniseringstiden. Observera att komprimering använder CPU- och RAM-resurser för en virtuell dator. När komprimeringsfrekvensen ökar, ökar även mängden processorresurser som används. Du kan också justera den här inställningen senare.

7. En annan inställning som du måste kontrollera är om replikeringen sker asynkront eller synkront. När du skyddar SAP ASCS/SCS-konfigurationer måste du använda synkron replikering.

   

   Bild 52: Definiera replikeringsinformation

8. Definiera om volymen som replikeras av replikeringsjobbet ska representeras av en klusterkonfiguration Windows Server-redundanskluster som en delad disk. För SAP ASCS/SCS-konfigurationen väljer du Ja så att Windows-klustret ser den replikerade volymen som en delad disk som den kan använda som klustervolym.

   

   Bild 53: Välj Ja för att ange den replikerade volymen som en klustervolym

   När volymen har skapats visar datakeeperhanterings- och konfigurationsverktyget att replikeringsjobbet är aktivt.

   

   Bild 54: DataKeeper-synkron spegling för SAP ASCS/SCS-resursdisken är aktiv

   Klusterhanteraren för växling vid fel nu disken som en DataKeeper-disk, som du ser i bild 55.

   

   Bild 55: Klusterhanteraren för växling vid fel visar disken som DataKeeper replikerade

Installera SAP NetWeaver-systemet

Vi beskriver inte DBMS-installationen eftersom installationerna varierar beroende på vilket DBMS-system du använder. Vi förutsätter dock att problem med hög tillgänglighet med DBMS åtgärdas med funktionerna som de olika DBMS-leverantörerna stöder för Azure. Till exempel Always On eller databasspegling för SQL Server och Oracle Data Guard för Oracle-databaser. I det scenario som vi använder i den här artikeln har vi inte lagt till mer skydd i DBMS.

Det finns inga särskilda överväganden när olika DBMS-tjänster interagerar med den här typen av klustrad SAP ASCS/SCS-konfiguration i Azure.

Installera SAP med en ASCS/SCS-instans med hög tillgänglighet

Installation av SAP med en ASCS/SCS-instans med hög tillgänglighet omfattar följande uppgifter:

• Skapa ett virtuellt värdnamn för den klustrade SAP ASCS/SCS-instansen
• Installera den första SAP-klusternoden
• Ändra SAP-profilen för ASCS/SCS-instansen
• Lägga till en avsökningsport
• Öppna brandväggens Windows port

Skapa ett virtuellt värdnamn för den klustrade SAP ASCS/SCS-instansen

1. I den Windows DNS-hanteraren skapar du en DNS-post för det virtuella värdnamnet för ASCS/SCS-instansen.

   Viktigt

   IP-adressen som du tilldelar till det virtuella värdnamnet för ASCS/SCS-instansen måste vara samma som den IP-adress som du tilldelade till Azure Load Balancer (< SID>-lb-ascs).

   IP-adressen för det virtuella SAP ASCS/SCS-värdnamnet (pr1-ascs-sap) är samma som IP-adressen för Azure Load Balancer (pr1-lb-ascs).

   

   Bild 56: Definiera DNS-posten för sap ASCS/SCS-klustrets virtuella namn och TCP/IP-adress

2. Om du vill definiera IP-adressen som tilldelats det virtuella värdnamnet väljer du DNS > Manager-domän.

   

   Bild 57: Nytt virtuellt namn och TCP/IP-adress för SAP ASCS/SCS-klusterkonfiguration

Installera den första SAP-klusternoden

1. Kör det första klusternodsalternativet på klusternod A. Till exempel på pr1-ascs-0-värden.

2. Om du vill behålla standardportarna för den interna Azure-lastbalanseraren väljer du:

   • ABAP: ASCS-instansnummer 00
   • Java-system: SCS-instansnummer 01
   • ABAP+Java-system: ASCS-instansnummer 00 och SCS-instansnummer 01

   Om du vill använda andra instansnummer än 00 för ABAP ASCS-instansen och 01 för Java SCS-instansen måste du först ändra standardreglerna för azures interna lastbalanserare. Mer information finns i Ändra standardreglerna för ASCS/SCS-standardbelastningsutjämning för deninterna Azure-lastbalanseraren.

Följande uppgifter beskrivs inte i standarddokumentationen för SAP-installation.

Ändra SAP-profilen för ASCS/SCS-instansen

Du måste lägga till en ny profilparameter. Profilparametern förhindrar att anslutningar mellan SAP-arbetsprocesser och den lokala servern stängs när de är inaktiva för länge. Vi nämnde problemscenariot i Lägg till registerposter på båda klusternoderna i SAP ASCS/SCS-instansen. I det avsnittet introducerade vi också två ändringar i vissa grundläggande TCP/IP-anslutningsparametrar. I ett andra steg måste du ange att den köserver som ska skicka en signal så att anslutningarna inte kommer upp i den interna Lastbalanserarens keep_alive inaktiva tröskelvärde i Azure.

Så här ändrar du SAP-profilen för ASCS/SCS-instansen:

1. Lägg till den här profilparametern i SAP ASCS/SCS-instansprofilen om du använder ENSA1:

   enque/encni/set_so_keepalive = true
   

   I vårt exempel är sökvägen:

   <ShareDisk>:\usr\sap\PR1\SYS\profile\PR1_ASCS00_pr1-ascs-sap

   Till exempel till SAP SCS-instansprofilen och motsvarande sökväg:

   <ShareDisk>:\usr\sap\PR1\SYS\profile\PR1_SCS01_pr1-ascs-sap

   För både ENSA1 och ENSA2 kontrollerar du att OS-parametrarna har angetts enligt beskrivningen i keepalive SAP-anteckningen 1410736.

2. Om du vill tillämpa ändringarna startar du om SAP ASCS/SCS-instansen.

Lägga till en avsökningsport

Använd avsökningsfunktionen i den interna lastbalanseraren för att få hela klusterkonfigurationen att fungera med Azure Load Balancer. Azures interna lastbalanserare distribuerar vanligtvis den inkommande arbetsbelastningen jämnt mellan deltagande virtuella datorer. Detta fungerar dock inte i vissa klusterkonfigurationer eftersom endast en instans är aktiv. Den andra instansen är passiv och kan inte acceptera någon av arbetsbelastningen. En avsökningsfunktion hjälper när den interna Azure-lastbalanseraren endast tilldelar arbete till en aktiv instans. Med avsökningsfunktionen kan den interna lastbalanseraren identifiera vilka instanser som är aktiva och sedan endast rikta in sig på instansen med arbetsbelastningen.

Så här lägger du till en avsökningsport:

1. Kontrollera den aktuella ProbePort-inställningen genom att köra följande PowerShell-kommando. Kör den inifrån en av de virtuella datorerna i klusterkonfigurationen.

   $SAPSID = "PR1"     # SAP <SID>
   
   $SAPNetworkIPClusterName = "SAP $SAPSID IP"
   Get-ClusterResource $SAPNetworkIPClusterName | Get-ClusterParameter
   

2. Definiera en avsökningsport. Standardportnumret för avsökning är 0. I vårt exempel använder vi avsökningsporten 62000.

   

   Bild 58: Standardporten för klusterkonfigurationsavsökning är 0

   Portnumret definieras i SAP Azure Resource Manager mallar. Du kan tilldela portnumret i PowerShell.

   Om du vill ange ett nytt ProbePort-värde för SAP <SID> IP-klusterresursen kör du följande PowerShell-skript. Uppdatera PowerShell-variablerna för din miljö. När skriptet körs uppmanas du att starta om SAP-klustergruppen för att aktivera ändringarna.

   $SAPSID = "PR1"      # SAP <SID>
   $ProbePort = 62000   # ProbePort of the Azure Internal Load Balancer
   
   Clear-Host
   $SAPClusterRoleName = "SAP $SAPSID"
   $SAPIPresourceName = "SAP $SAPSID IP"
   $SAPIPResourceClusterParameters =  Get-ClusterResource $SAPIPresourceName | Get-ClusterParameter
   $IPAddress = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Address" }).Value
   $NetworkName = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Network" }).Value
   $SubnetMask = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "SubnetMask" }).Value
   $OverrideAddressMatch = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "OverrideAddressMatch" }).Value
   $EnableDhcp = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "EnableDhcp" }).Value
   $OldProbePort = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "ProbePort" }).Value
   
   $var = Get-ClusterResource | Where-Object {  $_.name -eq $SAPIPresourceName  }
   
   Write-Host "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:" -ForegroundColor Cyan
   Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
   
   Write-Host
   Write-Host "Current probe port property of the SAP cluster resource '$SAPIPresourceName' is '$OldProbePort'." -ForegroundColor Cyan
   Write-Host
   Write-Host "Setting the new probe port property of the SAP cluster resource '$SAPIPresourceName' to '$ProbePort' ..." -ForegroundColor Cyan
   Write-Host
   
   $var | Set-ClusterParameter -Multiple @{"Address"=$IPAddress;"ProbePort"=$ProbePort;"Subnetmask"=$SubnetMask;"Network"=$NetworkName;"OverrideAddressMatch"=$OverrideAddressMatch;"EnableDhcp"=$EnableDhcp}
   
   Write-Host
   
   $ActivateChanges = Read-Host "Do you want to take restart SAP cluster role '$SAPClusterRoleName', to activate the changes (yes/no)?"
   
   if($ActivateChanges -eq "yes"){
   Write-Host
   Write-Host "Activating changes..." -ForegroundColor Cyan
   
   Write-Host
   write-host "Taking SAP cluster IP resource '$SAPIPresourceName' offline ..." -ForegroundColor Cyan
   Stop-ClusterResource -Name $SAPIPresourceName
   sleep 5
   
   Write-Host "Starting SAP cluster role '$SAPClusterRoleName' ..." -ForegroundColor Cyan
   Start-ClusterGroup -Name $SAPClusterRoleName
   
   Write-Host "New ProbePort parameter is active." -ForegroundColor Green
   Write-Host
   
   Write-Host "New configuration parameters for SAP IP cluster resource '$SAPIPresourceName':" -ForegroundColor Cyan
   Write-Host
   Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
   }else
   {
   Write-Host "Changes are not activated."
   }
   

   När du har fört SAP <SID-klusterrollen > online kontrollerar du att ProbePort har angetts till det nya värdet.

   $SAPSID = "PR1"     # SAP <SID>
   
   $SAPNetworkIPClusterName = "SAP $SAPSID IP"
   Get-ClusterResource $SAPNetworkIPClusterName | Get-ClusterParameter
   
   

   

   Bild 59: Avsökning av klusterporten när du har angett det nya värdet

Öppna den Windows brandväggens avsökningsport

Du måste öppna en port Windows brandväggsavsökning på båda klusternoderna. Använd följande skript för att öppna en port Windows brandväggsavsökning. Uppdatera PowerShell-variablerna för din miljö.

$ProbePort = 62000   # ProbePort of the Azure Internal Load Balancer

New-NetFirewallRule -Name AzureProbePort -DisplayName "Rule for Azure Probe Port" -Direction Inbound -Action Allow -Protocol TCP -LocalPort $ProbePort

ProbePort är inställt på 62000. Nu kan du komma åt \ filresursen \ascsha-clsap\sapmnt från andra värdar, till exempel från ascsha-dbas.

Installera databasinstansen

Om du vill installera databasinstansen följer du processen som beskrivs i sap-installationsdokumentationen.

Installera den andra klusternoden

Om du vill installera det andra klustret följer du stegen i installationsguiden för SAP.

Ändra starttypen för SAP ERS-Windows-tjänstinstansen

Ändra starttypen för SAP ERS-Windows till Automatisk (fördröjd start) på båda klusternoderna.

Bild 60: Ändra tjänsttypen för SAP ERS-instansen till fördröjd automatisk

Installera den primära SAP-programservern

Installera PAS-instansen (Primary Application Server) <SID>-di-0 på den virtuella dator som du har angett som värd för PAS. Det finns inga beroenden i Azure eller DataKeeper-specifika inställningar.

Installera SAP Additional Application Server

Installera en SAP Additional Application Server (AAS) på alla virtuella datorer som du har angett som värd för en SAP Application Server-instans. Till exempel på sid<->-di-1 för att <SID>-di- < n > .

Testa redundans för SAP ASCS/SCS-instansen och SIOS-replikering

Det är enkelt att testa och övervaka en redundans för EN SAP ASCS/SCS-instans och SIOS-diskreplikering med hjälp av Klusterhanteraren för växling vid fel och SIOS DataKeeper-hanterings- och konfigurationsverktyget.

SAP ASCS/SCS-instansen körs på klusternod A

SAP PR1-klustergruppen körs på klusternod A. Till exempel på pr1-ascs-0. Tilldela den delade diskenheten S, som är en del av SAP PR1-klustergruppen och som ASCS/SCS-instansen använder, till klusternod A.

Bild 61: Klusterhanteraren för växling vid fel: SAP- klustergruppen körs på klusternod A

I verktyget SIOS DataKeeper Management and Configuration ser du att delade diskdata replikeras synkront från källvolymenheten S på klusternod A till målvolymenheten S på klusternod B. Till exempel replikeras den från pr1-ascs-0 [10.0.0.40] till pr1-ascs-1 [10.0.0.41].

Bild 62: I SIOS DataKeeper replikerar du den lokala volymen från klusternod A till klusternod B

Redundans från nod A till nod B

1. Välj något av följande alternativ för att initiera en redundans av SAP <SID>-klustergruppen från klusternod A till klusternod B:

   • Använda Klusterhanteraren för växling vid fel
   • Använda Redundanskluster PowerShell

   $SAPSID = "PR1"     # SAP <SID>
   
   $SAPClusterGroup = "SAP $SAPSID"
   Move-ClusterGroup -Name $SAPClusterGroup
   
   

2. Starta om klusternod A inom Windows gästoperativsystemet (detta initierar en automatisk redundans av SAP <SID>-klustergruppen från nod A till nod B).

3. Starta om klusternod A från Azure Portal (detta initierar en automatisk redundans av SAP <SID>-klustergruppen från nod A till nod B).

4. Starta om klusternod A med Azure PowerShell (detta initierar en automatisk redundans av SAP <SID>-klustergruppen från nod A till nod B).

   Efter redundansen körs SAP klustergruppen på klusternod B. Den körs till exempel på pr1-ascs-1.

   

   Bild 63: I Klusterhanteraren för växling vid fel körs SAP- klustergruppen på klusternod B

   Den delade disken är nu monterad på klusternod B. SIOS DataKeeper replikerar data från källvolymenheten S på klusternod B till målvolymenheten S på klusternod A. Den replikerar till exempel från pr1-ascs-1 [10.0.0.41] till pr1-ascs-0 [10.0.0.40].

   

   Bild 64: SIOS DataKeeper replikerar den lokala volymen från klusternod B till klusternod A