Använda omstart av virtuella datorer i Azure-infrastrukturen för att uppnå "högre tillgänglighet" för ett SAP-system

Det här avsnittet gäller för:

Windows och Linux

Om du bestämmer dig för att inte använda funktioner som Windows Server-redundansklustring (WSFC) eller Pacemaker i Linux (stöds för närvarande endast för SUSE Linux Enterprise Server [SLES] 12 och senare), används omstart av virtuella Azure-datorer. Det skyddar SAP-system mot planerad och oplanerad stilleståndstid för den fysiska Azure-serverinfrastrukturen och den övergripande underliggande Azure-plattformen.

Kommentar

Omstart av virtuella Azure-datorer skyddar främst virtuella datorer och inte program. Även om omstart av virtuella datorer inte erbjuder hög tillgänglighet för SAP-program, erbjuder den en viss nivå av infrastrukturtillgänglighet. Det erbjuder också indirekt "högre tillgänglighet" för SAP-system. Det finns inte heller något serviceavtal för den tid det tar att starta om en virtuell dator efter ett planerat eller oplanerat värdavbrott, vilket gör den här metoden med hög tillgänglighet olämplig för de kritiska komponenterna i ett SAP-system. Exempel på kritiska komponenter kan vara en ASCS/SCS-instans eller ett databashanteringssystem (DBMS).

Ett annat viktigt infrastrukturelement för hög tillgänglighet är lagring. Azure Storage SLA är till exempel 99,9 % tillgänglighet. Om du distribuerar alla virtuella datorer och deras diskar i ett enda Azure-lagringskonto kommer potentiell otillgänglighet i Azure Storage att orsaka otillgänglighet för alla virtuella datorer som placeras i lagringskontot och alla SAP-komponenter som körs i de virtuella datorerna.

I stället för att placera alla virtuella datorer i ett enda Azure-lagringskonto kan du använda dedikerade lagringskonton för varje virtuell dator. Genom att använda flera oberoende Azure-lagringskonton ökar du den totala tillgängligheten för virtuella datorer och SAP-program.

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 hanterade diskar tar plattformen hand om att distribuera de hanterade diskarna till olika feldomäner. Om du planerar att använda ett Premium Storage-konto rekommenderar vi starkt att du använder hanterade diskar.

En exempelarkitektur för ett SAP NetWeaver-system som använder azure-infrastruktur med hög tillgänglighet och lagringskonton kan se ut så här:

En exempelarkitektur för ett SAP NetWeaver-system som använder hög tillgänglighet i Azure-infrastrukturen och hanterade diskar kan se ut så här:

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

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

  SAP-programserverinstanser är redundanta komponenter. Varje SAP-programserverinstans distribueras på en egen virtuell dator, som körs i en annan Azure-fel- och uppgraderingsdomän. Mer information finns i avsnitten Feldomäner och Uppdatera domäner .

  Du kan säkerställa den här konfigurationen med hjälp av Azure-tillgänglighetsuppsättningar. Mer information finns i avsnittet Azure-tillgänglighetsuppsättningar .

  Potentiell planerad eller oplanerad otillgänglighet för en Azure-fel- eller uppgraderingsdomän orsakar otillgänglighet för ett begränsat antal virtuella datorer med sina SAP-programserverinstanser.

  Varje SAP-programserverinstans placeras i ett eget Azure-lagringskonto. Den potentiella otillgängligheten för ett Azure-lagringskonto gör att endast en virtuell dator inte är tillgänglig med sin SAP-programserverinstans. Tänk dock på att det finns en gräns för antalet Azure-lagringskonton i en Azure-prenumeration. För att säkerställa automatisk start av en ASCS/SCS-instans efter omstarten av den virtuella datorn anger du autostartparametern i startprofilen för ASCS/SCS-instansen.

  Mer information finns i Hög tillgänglighet för SAP-programservrar.

  Även om du använder hanterade diskar lagras diskarna i ett Azure-lagringskonto och kan vara otillgängliga i händelse av ett lagringsfel.

• Högre tillgänglighet för SAP ASCS/SCS-instanser

  I det här scenariot använder du omstart av virtuella Azure-datorer för att skydda den virtuella datorn med den installerade SAP ASCS/SCS-instansen. Vid planerade eller oplanerade driftstopp för 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 ASCS/SCS-instansen. Genom omstarten av den virtuella datorn når du indirekt "högre tillgänglighet" för SAP ASCS/SCS-instansen.

  För att säkerställa en automatisk start av ASCS/SCS-instansen efter omstarten av den virtuella datorn anger du parametern Autostart i startprofilen för ASCS/SCS-instansen. Den här inställningen innebär att ASCS/SCS-instansen som en enskild felpunkt (SPOF) som körs på en enda virtuell dator avgör tillgängligheten för hela SAP-landskapet.

• Högre tillgänglighet för DBMS-servern

  Precis som i det föregående användningsfallet för SAP ASCS/SCS-instansen använder du omstart av virtuella Azure-datorer för att skydda den virtuella datorn med installerad DBMS-programvara, och du uppnår "högre tillgänglighet" för DBMS-programvara via omstart av virtuella datorer.

  En DBMS som körs på en enda virtuell dator är också en SPOF, och det är den avgörande faktorn för tillgängligheten för hela SAP-landskapet.

Använda automatisk start för SAP-instanser

SAP erbjuder en inställning som gör att du kan starta SAP-instanser omedelbart efter att operativsystemet har startats på den virtuella datorn. Instruktionerna dokumenteras i SAP Knowledge Base-artikeln 1909114. SAP rekommenderar dock inte längre att inställningen används eftersom den inte tillåter kontroll över ordningen på omstarter av instanser om fler än en virtuell dator påverkas eller om flera instanser körs per virtuell dator.

Om vi antar ett typiskt Azure-scenario för en SAP-programserverinstans på en virtuell dator och en enskild virtuell dator så småningom startas om, är autostart inte kritiskt. Men du kan aktivera den genom att lägga till följande parameter i startprofilen för SAP Advanced Business Application Programming (ABAP) eller Java-instansen:

Autostart = 1

Kommentar

Parametern Autostart har även vissa brister. Mer specifikt utlöser parametern starten av en SAP ABAP- eller Java-instans när den relaterade Windows- eller Linux-tjänsten för instansen startas. Den sekvensen inträffar när operativsystemet startas. Omstarter av SAP-tjänster är dock också vanliga för SAP Software Lifecycle Management-funktioner som Software Update Manger (SUM) eller andra uppdateringar eller uppgraderingar. Dessa funktioner förväntar sig inte att en instans startas om automatiskt. Därför bör parametern Autostart inaktiveras innan du kör sådana uppgifter. Parametern Autostart ska inte heller användas för SAP-instanser som är klustrade, till exempel ASCS/SCS/CI.

Mer information om automatisk start för SAP-instanser finns i följande artiklar:

• Starta eller stoppa SAP tillsammans med unix-serverns start/stopp
• Starta och stoppa SAP NetWeaver-hanteringsagenter

Nästa steg

Information om fullständig SAP NetWeaver-programmedveten hög tillgänglighet finns i SAP-programmets höga tillgänglighet på Azure IaaS.