Dela via


SAP MaxDB-, liveCache- och innehållsserverdistribution på virtuella Azure-datorer

Det här dokumentet beskriver flera olika områden att tänka på när du distribuerar MaxDB, liveCache och Content Server i Azure IaaS. Som en förutsättning för det här dokumentet bör du ha läst dokumentet Överväganden för Azure Virtual Machines DBMS-distribution för SAP-arbetsbelastning samt andra guider i SAP-arbetsbelastningen i Azure-dokumentationen.

Detaljer för SAP MaxDB-distributioner i Windows

Sap MaxDB-versionsstöd i Azure

SAP stöder för närvarande SAP MaxDB version 7.9 eller senare för användning med SAP NetWeaver-baserade produkter i Azure. Alla uppdateringar för SAP MaxDB-servern eller JDBC- och ODBC-drivrutiner som ska användas med SAP NetWeaver-baserade produkter tillhandahålls enbart via SAP Service Marketplace. Mer information om hur du kör SAP NetWeaver på SAP MaxDB finns i SAP MaxDB.

Microsoft Windows-versioner och Azure VM-typer som stöds för SAP MaxDB DBMS

Information om hur du hittar den Microsoft Windows-version som stöds för SAP MaxDB DBMS i Azure finns i:

Vi rekommenderar starkt att du använder den senaste versionen av operativsystemet Microsoft Windows, som är Microsoft Windows 2016.

Tillgänglig SAP MaxDB-dokumentation för MaxDB

Du hittar den uppdaterade listan över SAP MaxDB-dokumentation i följande SAP Note-767598

SAP MaxDB-konfigurationsriktlinjer för SAP-installationer på virtuella Azure-datorer

Storage-konfiguration

Metodtips för Azure Storage för SAP MaxDB följer de allmänna rekommendationerna i kapitlet Lagringsstruktur för en virtuell dator för RDBMS-distributioner.

Viktigt!

Precis som andra databaser har SAP MaxDB även data och loggfiler. I SAP MaxDB-terminologi är dock rätt term "volym" (inte "fil"). Det finns till exempel SAP MaxDB-datavolymer och loggvolymer. Förväxla inte dessa med OS-diskvolymer.

Kort och kort måste du:

  • Om du använder Azure Storage-konton anger du det Azure-lagringskonto som innehåller SAP MaxDB-data- och loggvolymerna (data och loggfiler) till Lokal redundant lagring (LRS) enligt vad som anges i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning.
  • Avgränsa I/O-sökvägen för SAP MaxDB-datavolymer (datafiler) från I/O-sökvägen för loggvolymer (loggfiler). Det innebär att SAP MaxDB-datavolymer (datafiler) måste installeras på en logisk enhet och ATT SAP MaxDB-loggvolymer (loggfiler) måste installeras på en annan logisk enhet.
  • Ange rätt cachelagringstyp för varje disk, beroende på om du använder den för SAP MaxDB-data eller loggvolymer (data och loggfiler) och om du använder Azure Standard eller Azure Premium Storage enligt beskrivningen i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning.
  • Så länge den aktuella IOPS-kvoten per disk uppfyller kraven är det möjligt att lagra alla datavolymer på en enda monterad disk och även lagra alla databasloggvolymer på en annan enskild monterad disk.
  • Om mer IOPS och/eller utrymme krävs rekommenderar vi att du använder Microsoft Window Storage-pooler (endast tillgängliga i Microsoft Windows Server 2012 och senare) för att skapa en stor logisk enhet över flera monterade diskar. Mer information finns även i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning. Den här metoden förenklar administrationskostnaderna för att hantera diskutrymmet och undviker att distribuera filer manuellt över flera monterade diskar.
  • Vi rekommenderar starkt att du använder Azure Premium Storage för MaxDB-distributioner.

Reference Configuration of Azure IaaS VM for SAP MaxDB DBMS

Säkerhetskopiera och återställ

När du distribuerar SAP MaxDB till Azure måste du granska din metod för säkerhetskopiering. Även om systemet inte är ett produktivt system måste SAP-databasen som hanteras av SAP MaxDB säkerhetskopieras regelbundet. Eftersom Azure Storage behåller tre avbildningar är en säkerhetskopia nu mindre viktig när det gäller att skydda systemet mot lagringsfel och viktigare drifts- eller administrativa fel. Den främsta orsaken till att upprätthålla en korrekt säkerhetskopierings- och återställningsplan är att du kan kompensera för logiska eller manuella fel genom att tillhandahålla återställningsfunktioner för tidpunkt. Målet är att antingen använda säkerhetskopior för att återställa databasen till en viss tidpunkt eller att använda säkerhetskopiorna i Azure för att skapa ett annat system genom att kopiera den befintliga databasen.

Säkerhetskopiering och återställning av en databas i Azure fungerar på samma sätt som för lokala system, så du kan använda standardverktygen för SAP MaxDB-säkerhetskopiering/återställning, som beskrivs i något av dokumentationsdokumenten för SAP MaxDB som anges i SAP Note 767598.

Säkerhetskopiera och återställa med Azure Backup

Du kan också integrera MaxDB-säkerhetskopiering med Azure Backup med hjälp av säkerhetskopieringsverktyget maxback från tredje part (https://maxback.io). Med MaxBack kan du säkerhetskopiera och återställa MaxDB i Windows med VSS-integrering, som också används av Azure Backup. Fördelen med att använda Azure Backup är att säkerhetskopiering och återställning görs på lagringsnivå. MaxBack ser till att databasen är i rätt tillstånd för säkerhetskopiering och återställning och hanterar automatiskt säkerhetskopiering av loggvolymer.

Prestandaöverväganden för säkerhetskopiering och återställning

Precis som i bare metal-distributioner beror prestanda för säkerhetskopiering och återställning på hur många volymer som kan läsas parallellt och dataflödet för dessa volymer. Därför kan man anta:

  • Ju färre diskar som används för att lagra databasenheterna, desto lägre är det totala läsdataflödet
  • Ju färre mål (Stripe-kataloger, diskar) som säkerhetskopieringen ska skrivas till, desto lägre dataflöde

För att öka antalet mål att skriva till finns det två alternativ som du kan använda, eventuellt i kombination, beroende på dina behov:

  • Ange separata volymer för säkerhetskopiering
  • Rensa målvolymen för säkerhetskopiering över flera monterade diskar för att förbättra IOPS-dataflödet på den randiga diskvolymen
  • Har separata dedikerade logiska diskenheter för:
    • SAP MaxDB-säkerhetskopieringsvolymer (dvs. filer)
    • SAP MaxDB-datavolymer (dvs. filer)
    • SAP MaxDB-loggvolymer (dvs. filer)

Att ta bort en volym över flera monterade diskar har diskuterats tidigare i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning.

Övriga beaktanden

Alla andra allmänna områden som Azure-tillgänglighetsuppsättningar eller SAP-övervakning gäller även enligt beskrivningen i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning. för distribution av virtuella datorer med SAP MaxDB-databasen. Andra SAP MaxDB-specifika inställningar är transparenta för virtuella Azure-datorer och beskrivs i olika dokument som anges i SAP Note 767598 och i följande SAP-anteckningar:

Detaljer för SAP liveCache-distributioner i Windows

Support för SAP liveCache-version

Minimal version av SAP liveCache som stöds i Azure Virtual Machines är SAP LC/LCAPPS 10.0 SP 25 , inklusive liveCache 7.9.08.31 och LCA-Build 25, släppt för EhP 2 för SAP SCM 7.0 och senare versioner.

Microsoft Windows-versioner och Azure VM-typer som stöds för SAP liveCache DBMS

Information om hur du hittar microsoft Windows-versionen som stöds för SAP liveCache i Azure finns i:

Vi rekommenderar starkt att du använder den senaste versionen av operativsystemet Microsoft Windows Server.

Sap liveCache-konfigurationsriktlinjer för SAP-installationer på virtuella Azure-datorer

Eftersom SAP liveCache är ett program som utför enorma beräkningar, har mängden och hastigheten för RAM och CPU en stor inverkan på SAP liveCache-prestanda.

För de typer av virtuella Azure-datorer som stöds av SAP (SAP Note 1928533) backas alla virtuella CPU-resurser som allokeras till den virtuella datorn av dedikerade fysiska CPU-resurser i hypervisor-programmet. Ingen överetablering (och därmed ingen konkurrens om CPU-resurser) äger rum.

För alla typer av azure-VM-instanser som stöds av SAP är vm-minnet på samma sätt 100 % mappat till det fysiska minnet – överetablering (överåtagande) används till exempel inte.

Ur det här perspektivet rekommenderar vi starkt att du använder de senaste virtuella datorerna i Dv2, Dv3, Ev3 och M-serien. Valet av olika typer av virtuella datorer beror på det minne du behöver för liveCache och de CPU-resurser du behöver. Precis som med alla andra DBMS-distributioner är det lämpligt att använda Azure Premium Storage för prestandakritiska volymer.

Lagringskonfiguration för liveCache i Azure

Eftersom SAP liveCache baseras på SAP MaxDB-teknik är alla rekommenderade metoder för Azure Storage som nämns för SAP MaxDB som beskrivs i det här dokumentet också giltiga för SAP liveCache.

Scenario med dedikerad virtuell Azure-dator för liveCache

Eftersom SAP liveCache intensivt använder beräkningskraft rekommenderar vi starkt att du distribuerar på en dedikerad virtuell Azure-dator för produktiv användning.

Dedicated Azure VM for liveCache for productive use case

Säkerhetskopiering och återställning för liveCache i Azure

säkerhetskopiering och återställning, inklusive prestandaöverväganden, beskrivs redan i de relevanta SAP MaxDB-kapitlen i det här dokumentet.

Övriga beaktanden

Alla andra allmänna områden beskrivs redan i det relevanta SAP MaxDB-kapitlet.

Detaljer för SAP Content Server-distributionen i Windows i Azure

SAP-innehållsservern är en separat serverbaserad komponent för att lagra innehåll, till exempel elektroniska dokument i olika format. SAP-innehållsservern tillhandahålls genom teknikutveckling och ska användas mellan program för alla SAP-program. Den är installerad på ett separat system. Typiskt innehåll är utbildningsmaterial och dokumentation från Kunskapslager eller tekniska ritningar från mySAP PLM Document Management System.

Versionsstöd för SAP-innehållsserver för virtuella Azure-datorer

SAP stöder för närvarande:

  • SAP-innehållsserver med version 6.50 (och senare)
  • SAP MaxDB version 7.9
  • Microsoft IIS (Internet Information Server) version 8.0 (och senare)

Vi rekommenderar starkt att du använder den senaste versionen av SAP Content Server och den senaste versionen av Microsoft IIS.

Kontrollera de senaste versionerna av SAP Content Server och Microsoft IIS i SAP Product Availability Matrix (PAM).

Microsoft Windows- och Azure VM-typer som stöds för SAP Content Server

Information om Windows-version som stöds för SAP Content Server i Azure finns i:

Vi rekommenderar starkt att du använder den senaste versionen av Microsoft Windows Server.

Konfigurationsriktlinjer för SAP Content Server för SAP-installationer på virtuella Azure-datorer

Lagringskonfiguration för innehållsserver i Azure

Om du konfigurerar SAP Content Server för att lagra filer i SAP MaxDB-databasen är alla rekommenderade metodtips för Azure Storage som nämns för SAP MaxDB i det här dokumentet också giltiga för SAP Content Server-scenariot.

Om du konfigurerar SAP Content Server för att lagra filer i filsystemet rekommenderar vi att du använder en dedikerad logisk enhet. Med Windows Lagringsutrymmen kan du också öka storleken på logiska diskar och IOPS-dataflödet, enligt beskrivningen i Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning.

PLATS för SAP-innehållsserver

SAP Content Server måste distribueras i samma Azure-region och Azure VNET där SAP-systemet distribueras. Du kan bestämma om du vill distribuera SAP Content Server-komponenter på en dedikerad virtuell Azure-dator eller på samma virtuella dator där SAP-systemet körs.

Dedicated Azure VM for SAP Content Server

PLATS för SAP Cache Server

SAP Cache Server är ytterligare en serverbaserad komponent som ger åtkomst till (cachelagrade) dokument lokalt. SAP Cache Server cachelagrar dokument från en SAP-innehållsserver. Detta är för att optimera nätverkstrafiken om dokument måste hämtas mer än en gång från olika platser. Den allmänna regeln är att SAP Cache Server måste vara fysiskt nära klienten som har åtkomst till SAP Cache Server.

Här har du två alternativ:

  1. Klienten är ett SAP-serverdelssystem Om ett SAP-serverdelssystem har konfigurerats för åtkomst till SAP Content Server är det SAP-systemet en klient. Eftersom både SAP-systemet och SAP-innehållsservern distribueras i samma Azure-region ligger de fysiskt nära varandra i samma Azure-datacenter. Därför behöver du inte ha en dedikerad SAP Cache Server. SAP UI-klienter (SAP GUI eller webbläsare) får direkt åtkomst till SAP-systemet och SAP-systemet hämtar dokument från SAP-innehållsservern.
  2. Klienten är en lokal webbläsare SAP-innehållsservern kan konfigureras att nås direkt av webbläsaren. I det här fallet är en webbläsare som körs lokalt en klient för SAP-innehållsservern. Lokalt datacenter och Azure-datacenter placeras på olika fysiska platser (helst nära varandra). Ditt lokala datacenter är anslutet till Azure via Azure Site-to-Site VPN eller ExpressRoute. Även om båda alternativen erbjuder säker VPN-nätverksanslutning till Azure, erbjuder inte plats-till-plats-nätverksanslutning något serviceavtal för nätverksbandbredd och svarstid mellan det lokala datacentret och Azure-datacentret. Om du vill påskynda åtkomsten till dokument kan du göra något av följande:
    1. Installera SAP Cache Server lokalt, nära den lokala webbläsaren (alternativ i bild nedan)
    2. Konfigurera Azure ExpressRoute, som erbjuder en dedikerad nätverksanslutning med hög hastighet och låg latens mellan lokalt datacenter och Azure-datacenter.

Option to install SAP Cache Server on-premises

Säkerhetskopiering/återställning

Om du konfigurerar SAP-innehållsservern för att lagra filer i SAP MaxDB-databasen beskrivs redan proceduren för säkerhetskopiering/återställning och prestandaöverväganden i SAP MaxDB-kapitlen i det här dokumentet.

Om du konfigurerar SAP-innehållsservern för att lagra filer i filsystemet är ett alternativ att köra manuell säkerhetskopiering/återställning av hela filstrukturen där dokumenten finns. I likhet med SAP MaxDB-säkerhetskopiering/återställning rekommenderar vi att du har en dedikerad diskvolym i säkerhetskopieringssyfte.

Övrigt

Andra SAP Content Server-specifika inställningar är transparenta för virtuella Azure-datorer och beskrivs i olika dokument och SAP-anteckningar: