Condividi tramite

Carico di lavoro SAP negli scenari supportati da macchine virtuali di Azure

  • Articolo

La progettazione di un'architettura di sistemi SAP NetWeaver, Hybris Business one o S/4HANA in Azure offre molte opportunità diverse per diverse architetture e strumenti da usare per ottenere una distribuzione scalabile, efficiente e a disponibilità elevata. Anche se dipende dal sistema operativo o dal sistema operativo usato da DBMS, esistono restrizioni. Inoltre, non tutti gli scenari supportati in locale sono supportati nello stesso modo in Azure. Questo documento illustra le configurazioni e le architetture supportate non a disponibilità elevata e configurazioni e architetture a disponibilità elevata usando esclusivamente macchine virtuali di Azure.

Nota

Il servizio Istanza Large di HANA è in modalità sunset e non accetta più nuovi clienti. È comunque possibile fornire unità per i clienti del servizio Istanza Large di HANA esistenti. Per le alternative, vedere le offerte di macchine virtuali di Azure certificate per HANA nella directory hardware di HANA. Per gli scenari che erano e sono ancora supportati per i clienti di istanze Large di HANA esistenti con istanze Large di HANA, vedere l'articolo Scenari supportati per le istanze Large di HANA.

Restrizioni generali della piattaforma

Azure include diverse piattaforme oltre a cosiddette macchine virtuali native di Azure offerte come servizio di prima parte. Istanze Large di HANA, che è in modalità tramonto è una di queste piattaforme. Servizi Azure VMware è un altro di questi servizi proprietari. I servizi Azure VMware in generale non sono supportati da SAP per l'hosting del carico di lavoro SAP. Per altre informazioni sul supporto VMware su piattaforme diverse, vedere la nota di supporto SAP #2138865 - Applicazioni SAP in VMware Cloud: prodotti supportati e configurazioni di macchine virtuali.

Oltre al Active Directory locale, Azure offre un servizio SaaS di Active Directory gestito con Microsoft Entra Domain Services (ad tradizionale gestito da Microsoft) e Microsoft Entra ID. I componenti SAP ospitati nel sistema operativo Windows si basano spesso sull'utilizzo di Windows Active Directory. In questo caso, l'istanza tradizionale di Active Directory è ospitata in locale dall'utente o da Microsoft Entra Domain Services (ancora in fase di test). Tuttavia, questi componenti SAP non possono funzionare con l'ID Microsoft Entra nativo. Il motivo è che esistono ancora maggiori lacune nelle funzionalità tra Active Directory nel formato locale o il modulo SaaS (Microsoft Entra Domain Services) e l'ID Microsoft Entra nativo. Questa dipendenza è il motivo per cui gli account Microsoft Entra non sono supportati per le applicazioni basate su SAP NetWeaver e S/4 HANA nel sistema operativo Windows. Gli account Active Directory tradizionali devono essere usati in tali scenari.

Servizio ACTIVE Directory Applicazioni supportate basate su SAP NetWeaver e S/4 HANA nel sistema operativo Windows
Windows Active Directory locale Supportata
Microsoft Entra Domain Services Supportata
Microsoft Entra ID Non supportato

Il codice precedente non influisce sull'utilizzo degli account Microsoft Entra per gli scenari Single Sign-On (SSO) con le applicazioni SAP.

Configurazione a 2 livelli

Una configurazione sap a 2 livelli viene considerata compilata da un livello combinato del dbms SAP e del livello applicazione che viene eseguito nello stesso server o unità di macchina virtuale. Il secondo livello è considerato il livello dell'interfaccia utente. Per una configurazione a 2 livelli, il livello dell'applicazione DBMS e SAP condividono le risorse della macchina virtuale di Azure. Di conseguenza, è necessario configurare i diversi componenti in modo che questi componenti non siano in competizione per le risorse. È anche necessario prestare attenzione a non sovrascrivere le risorse della macchina virtuale. Questa configurazione non offre disponibilità elevata, oltre ai contratti di servizio di Azure dei diversi componenti di Azure coinvolti.

Una rappresentazione grafica di tale configurazione può essere simile alla seguente:

Configurazione semplice a 2 livelli

Tali configurazioni sono supportate con Windows, Red Hat, SUSE e Oracle Linux per i sistemi DBMS di SQL Server, Oracle, Db2, maxDB e SAP ASE per i casi di produzione e non di produzione. Per SAP HANA come DBMS, SAP supporta tale scenario, come indicato nella nota SAP #1953429. Finora, nessuna delle distribuzioni Linux ha fornito documentazione sufficiente per configurare e gestire un cluster Pacemaker in una configurazione di questo tipo. Di conseguenza, questo tipo di configurazioni è supportato in Azure solo per i casi non di produzione che non richiedono un cluster di failover a disponibilità elevata.

Per tutte le combinazioni di sistema operativo/DBMS supportate in Azure, questo tipo di configurazione è supportato. Tuttavia, è obbligatorio impostare la configurazione del sistema DBMS e dei componenti SAP in modo che i componenti DBMS e SAP non siano in competizione per le risorse di memoria e CPU e con tale valore superano le risorse fisiche disponibili. Questa operazione deve essere eseguita limitando la memoria a cui è consentito allocare DBMS. È anche necessario limitare la memoria estesa SAP nelle istanze dell'applicazione. È anche necessario monitorare l'utilizzo complessivo della CPU della macchina virtuale per assicurarsi che i componenti non massimizzino le risorse della CPU.

Nota

Per i sistemi SAP di produzione, è consigliabile aggiungere altre configurazioni di disponibilità elevata e ripristino di emergenza, come descritto più avanti in questo documento

Configurazione a 3 livelli

In queste configurazioni si separa il livello applicazione SAP e il livello DBMS in macchine virtuali diverse. Questa operazione viene in genere eseguita per sistemi di grandi dimensioni e per motivi di maggiore flessibilità sulle risorse del livello dell'applicazione SAP. Nella configurazione più semplice non esiste una disponibilità elevata oltre i contratti di servizio di Azure dei diversi componenti di Azure coinvolti.

La rappresentazione grafica è simile alla seguente:

Diagramma che mostra una semplice configurazione a 3 livelli.

Questo tipo di configurazione è supportato in Windows, Red Hat, SUSE e Oracle Linux per i sistemi DBMS di SQL Server, Oracle, Db2, SAP HANA, maxDB e SAP ASE per i casi di produzione e non di produzione. Per semplificare, non è stata eseguita una distinzione tra le istanze di dialogo SAP Central Services e SAP nel livello applicazione SAP. In questa semplice configurazione a 3 livelli non esisterebbe alcuna protezione a disponibilità elevata per SAP Central Services.

Nota

Per i sistemi SAP di produzione, è consigliabile aggiungere altre configurazioni di disponibilità elevata e ripristino di emergenza, come descritto più avanti in questo documento

Più istanze di DBMS per macchina virtuale

In questo tipo di configurazione si ospitano più istanze DBMS per macchina virtuale di Azure. La motivazione può essere quella di avere meno sistemi operativi da gestire e con tale riduzione dei costi. Altre motivazioni devono avere maggiore flessibilità ed efficienza condividendo le risorse di una macchina virtuale di dimensioni maggiori o di un'unità di istanze Large di HANA tra più istanze DBMS. Finora queste configurazioni sono state visualizzate principalmente per i sistemi non di produzione.

Una configurazione simile alla seguente:

Più istanze di DBMS in un'unità

Questo tipo di distribuzione DBMS è supportato per:

L'esecuzione di più istanze di database in un host è necessario assicurarsi che le diverse istanze non siano in competizione per le risorse e quindi superare i limiti delle risorse fisiche della macchina virtuale. Ciò vale soprattutto per la memoria in cui è necessario limitare la memoria a chiunque delle istanze che condividono la macchina virtuale possa allocare. Ciò potrebbe anche essere vero per le risorse della CPU che possono essere utilizzate dalle diverse istanze del database. Tutti i sistemi di database indicati includono configurazioni che consentono di limitare l'allocazione della memoria e le risorse della CPU a livello di istanza. Per avere il supporto per una configurazione di questo tipo per le macchine virtuali di Azure, è previsto che i dischi o i volumi usati per i file di dati e di log/rollforward dei database gestiti dalle diverse istanze siano separati. In altre parole, i file di log o di log/rollforward dei database gestiti da un'istanza DBMS diversa non devono condividere gli stessi dischi o volumi.

Nota

Per i sistemi SAP di produzione, è consigliabile aggiungere altre configurazioni di disponibilità elevata e ripristino di emergenza, come descritto più avanti in questo documento. Le macchine virtuali con più istanze DBMS non sono supportate con le configurazioni a disponibilità elevata descritte più avanti in questo documento.

Più istanze di finestra di dialogo SAP in una macchina virtuale

In molti casi, più istanze di dialogo sono stati distribuiti in server bare metal o anche in macchine virtuali in esecuzione in cloud privati. La ragione di queste configurazioni era adattare determinate istanze di dialogo SAP a determinati carichi di lavoro, funzionalità aziendali o tipi di carico di lavoro. Il motivo per cui non isolare tali istanze in macchine virtuali separate è stato lo sforzo di manutenzione e operazioni del sistema operativo. In molti casi, invece, i costi nel caso in cui l'host o l'operatore della macchina virtuale richiedano una tariffa mensile per macchina virtuale gestita e gestita. In Azure, uno scenario di hosting di più istanze di finestre di dialogo SAP all'interno di una singola macchina virtuale è supportato per scopi di produzione e non di produzione nei sistemi operativi di Windows, Red Hat, SUSE e Oracle Linux. Il parametro del kernel SAP PHYS_MEMSIZE, disponibile nei kernel Windows e Linux moderni, deve essere impostato se più istanze del server applicazioni SAP sono in esecuzione in una singola macchina virtuale. è anche consigliabile limitare l'espansione della memoria estesa SAP nei sistemi operativi, ad esempio Windows in cui viene implementata la crescita automatica della memoria estesa SAP. Questa operazione può essere eseguita con il parametro em/max_size_MBdel profilo SAP .

Nella configurazione a 3 livelli in cui vengono eseguite più istanze di dialogo SAP all'interno di macchine virtuali di Azure possono avere un aspetto simile al seguente:

Diagramma che mostra una configurazione a 3 livelli in cui vengono eseguite più istanze della finestra di dialogo SAP all'interno di macchine virtuali di Azure.

Per semplificare, non è stata eseguita una distinzione tra le istanze di dialogo SAP Central Services e SAP nel livello applicazione SAP. In questa semplice configurazione a 3 livelli non esisterebbe alcuna protezione a disponibilità elevata per SAP Central Services. Per i sistemi di produzione, non è consigliabile lasciare non protetto SAP Central Services. Per informazioni specifiche sulle cosiddette configurazioni multi-SID relative alle istanze centrali DI SAP e alla disponibilità elevata di tali configurazioni multi-SID, vedere le sezioni successive di questo documento.

Protezione a disponibilità elevata per il livello SAP DBMS

Quando si esamina la distribuzione di sistemi di produzione SAP, è necessario prendere in considerazione il tipo di hot standby di configurazioni a disponibilità elevata. In particolare con SAP HANA, dove i dati devono essere caricati in memoria prima di poter ottenere le prestazioni e la scalabilità complete, la correzione del servizio di Azure non è una misura ideale per la disponibilità elevata.

In generale, Microsoft supporta solo configurazioni a disponibilità elevata e pacchetti software descritti negli scenari di carico di lavoro SAP. È possibile leggere la stessa istruzione nella nota SAP #1928533. Microsoft non fornirà supporto per altri framework software di terze parti a disponibilità elevata non documentati da Microsoft con carico di lavoro SAP. In questi casi, il fornitore di terze parti del framework a disponibilità elevata è l'entità di supporto per la configurazione a disponibilità elevata che deve essere coinvolta dall'utente come cliente nel processo di supporto. Le eccezioni verranno menzionate in questo articolo.

In generale, Microsoft supporta un set limitato di configurazioni a disponibilità elevata nelle macchine virtuali di Azure o nelle unità di istanze Large di HANA.

Per le macchine virtuali di Azure, le configurazioni di disponibilità elevata seguenti sono supportate a livello di DBMS:

Importante

Per nessuno degli scenari descritti in precedenza, sono supportate le configurazioni di più istanze DBMS in una macchina virtuale. In ognuno dei casi, è possibile distribuire una sola istanza di database per ogni macchina virtuale e proteggerla con i metodi di disponibilità elevata descritti. La protezione di più istanze DBMS nello stesso cluster di failover Windows o Pacemaker non è supportata in questo momento. Oracle Data Guard è supportato anche solo per un'istanza singola per ogni caso di distribuzione di macchine virtuali.

Diversi sistemi di database consentono di ospitare più database in un'istanza DBMS. Analogamente a SAP HANA, più database possono essere ospitati in più contenitori di database (MDC). Per i casi in cui queste configurazioni multi-database funzionano all'interno di una risorsa cluster di failover, queste configurazioni sono supportate. Le configurazioni non supportate sono casi in cui sarebbero necessarie più risorse del cluster. Come per le configurazioni in cui si definiscono più gruppi di disponibilità di SQL Server, in un'istanza di SQL Server.

Configurazione a disponibilità elevata del sistema DBMS

A seconda dei sistemi operativi o di dbMS, i componenti come Il servizio di bilanciamento del carico di Azure potrebbero essere necessari o meno come parte dell'architettura della soluzione.

In particolare per maxDB, la configurazione dell'archiviazione deve essere diversa. Con maxDB, i file di dati e di log devono trovarsi nell'archiviazione condivisa per le configurazioni a disponibilità elevata. Solo per maxDB, l'archiviazione condivisa è supportata per la disponibilità elevata. Per tutti gli altri DBMS, gli stack di archiviazione separati per nodo sono le uniche configurazioni dei dischi supportate.

Altri framework a disponibilità elevata sono noti e sono noti per l'esecuzione anche in Microsoft Azure. Tuttavia, Microsoft non ha testato tali framework. Se si vuole creare la configurazione a disponibilità elevata con tali framework, è necessario collaborare con il provider di tale software per:

  • Sviluppare un'architettura di distribuzione
  • Distribuzione dell'architettura
  • Supporto dell'architettura

Importante

Microsoft Azure Marketplace offre un'ampia gamma di appliance soft che offrono soluzioni di archiviazione oltre all'archiviazione nativa di Azure. Queste appliance soft possono essere usate per creare condivisioni NFS e che teoricamente potrebbero essere usate nelle distribuzioni con scalabilità orizzontale di SAP HANA in cui è necessario un nodo di standby. A causa di vari motivi, nessuna di queste appliance soft di archiviazione è supportata per una delle distribuzioni DBMS di Microsoft e SAP in Azure. Le distribuzioni di DBMS nelle condivisioni SMB non sono supportate in questo momento. Le distribuzioni di DBMS in condivisioni NFS sono limitate alle condivisioni NFS 4.1 in Azure NetApp Files.

Disponibilità elevata per SAP Central Service

SAP Central Services è un secondo singolo punto di errore della configurazione SAP. Di conseguenza, è necessario proteggere anche questi processi di Central Services. L'offerta supportata e documentata per i carichi di lavoro SAP è simile alla seguente:

Delle soluzioni elencate, è necessaria una relazione di supporto con SIOS per supportare il Datakeeper prodotto e interagire direttamente con SIOS in caso di problemi. A seconda del modo in cui hai concesso in licenza il sistema operativo Windows, Red Hat e/o SUSE, potresti anche avere un contratto di supporto con il provider del sistema operativo per avere il supporto completo delle configurazioni a disponibilità elevata elencate.

La configurazione può anche essere visualizzata come segue:

Configurazione a disponibilità elevata di DBMS e ASCS

Sul lato destro della grafica viene visualizzato SAP Central Services a disponibilità elevata. Oltre a disporre dei servizi SAP Central protetti con un framework del cluster di failover che può eseguire il failover in scenari di errore. È necessaria una condivisione NFS o SMB a disponibilità elevata o un disco condiviso di Windows per assicurarsi che la directory di trasporto sapmnt e globale siano disponibili indipendentemente dall'esistenza di una singola macchina virtuale. Altre soluzioni, ad esempio Il server del cluster di failover Windows e Pacemaker richiedono un servizio di bilanciamento del carico di Azure per indirizzare o reindirizzare il traffico a un nodo integro.

Nell'elenco visualizzato non è presente alcuna menzione del sistema operativo Oracle Linux. Oracle Linux non supporta Pacemaker come framework del cluster. Se si vuole distribuire il sistema SAP in Oracle Linux ed è necessario un framework a disponibilità elevata per Oracle Linux, è necessario collaborare con fornitori di terze parti. Uno dei fornitori è SIOS con protection suite per Linux supportato da SAP in Azure. Per altre informazioni, vedere la nota SAP #1662610 - Dettagli del supporto per SIOS Protection Suite per Linux per altri dettagli.

Archiviazione supportata con gli scenari di SAP Central Services elencati in precedenza

Poiché solo un subset di tipi di archiviazione di Azure fornisce condivisioni NFS o SMB a disponibilità elevata per l'utilizzo negli scenari del cluster SAP Central Services un elenco di tipi di archiviazione supportati

  • Il server del cluster di failover Windows con file server con scalabilità orizzontale Windows può essere distribuito in tutti i tipi di archiviazione di Azure nativi, ad eccezione di Azure NetApp Files. Tuttavia, è consigliabile usare Archiviazione Premium a causa di contratti di servizio superiori nella velocità effettiva e nelle operazioni di I/O al secondo.
  • Il server del cluster di failover Windows con SMB in Azure NetApp Files è supportato in Azure NetApp Files. Anche le condivisioni SMB ospitate nei servizi file Premium di Azure sono supportate per questo scenario. File standard di Azure non è supportato
  • Il server del cluster di failover Windows con disco condiviso windows basato su SIOS Datakeeper può essere distribuito in tutti i tipi di archiviazione di Azure nativi, ad eccezione di Azure NetApp Files. Tuttavia, è consigliabile usare Archiviazione Premium a causa di contratti di servizio superiori nella velocità effettiva e nelle operazioni di I/O al secondo.
  • SUSE o Red Hat Pacemaker che usano condivisioni NFS in Azure NetApp Files è supportato.
  • SUSE o Red Hat Pacemaker usando condivisioni NFS in File Premium di Azure usando l'archiviazione con ridondanza locale o archiviazione con ridondanza della zona supportate. File standard di Azure non è supportato
  • SUSE Pacemaker che usa una drdb configurazione tra due macchine virtuali è supportata usando i tipi di archiviazione di Azure nativi, ad eccezione di Azure NetApp Files. È tuttavia consigliabile usare uno dei servizi di prima parte con File Premium di Azure o Azure NetApp Files.
  • Red Hat Pacemaker che usa glusterfs per fornire una condivisione NFS è supportato usando tipi di archiviazione nativi di Azure, ad eccezione di Azure NetApp Files. È tuttavia consigliabile usare uno dei servizi di prima parte con File Premium di Azure o Azure NetApp Files.

Importante

Microsoft Azure Marketplace offre un'ampia gamma di appliance soft che offrono soluzioni di archiviazione oltre all'archiviazione nativa di Azure. Queste appliance soft di archiviazione possono essere usate per creare condivisioni NFS o SMB, che teoricamente potrebbero essere usate anche in SAP Central Services in cluster di failover. Queste soluzioni non sono supportate direttamente per il carico di lavoro SAP di Microsoft. Se si decide di usare tale soluzione per creare la condivisione NFS o SMB, il supporto per la configurazione del servizio centrale SAP deve essere fornito dalla terza parte proprietaria del software nell'appliance soft di archiviazione.

Cluster di failover di SAP Central Services multi-SID

Per ridurre il numero di macchine virtuali necessarie in scenari SAP di grandi dimensioni, SAP consente l'esecuzione di istanze di SAP Central Services di più sistemi SAP diversi nella configurazione del cluster di failover. Si supponga di avere 30 o più sistemi di produzione NetWeaver o S/4HANA. Senza il clustering con più SID, queste configurazioni richiedono 60 o più macchine virtuali in 30 o più configurazioni del cluster di failover Windows o Pacemaker. La distribuzione di più servizi centrali SAP tra due nodi in una configurazione del cluster di failover può ridurre significativamente il numero di macchine virtuali. Tuttavia, la distribuzione di più istanze di SAP Central Services in una configurazione cluster a due nodi presenta anche alcuni svantaggi. I problemi relativi a una singola macchina virtuale nella configurazione del cluster si applicano a più sistemi SAP. La manutenzione del sistema operativo guest in esecuzione nella configurazione del cluster richiede un maggiore coordinamento perché sono interessati più sistemi SAP di produzione. Gli strumenti come SAP LaMa non supportano il clustering multi-SID nel processo di clonazione del sistema.

In Azure è supportata una configurazione di cluster multi-SID per il sistema operativo Windows con ENSA1 e ENSA2. È consigliabile non combinare l'architettura del servizio di replica di accodamento precedente (ENSA1) con la nuova architettura (ENSA2) in un cluster multi-SID. I dettagli su tale architettura sono documentati negli articoli

Per SUSE, è supportato anche un cluster multi-SID basato su Pacemaker. Finora la configurazione è supportata per:

  • Un massimo di cinque istanze di SAP ASCS/SCS
  • L'architettura ice del server di replica di accodamento precedente (ENSA1)
  • Configurazioni del cluster Pacemaker a due nodi

La configurazione è documentata in Disponibilità elevata per SAP NetWeaver in macchine virtuali di Azure in SUSE Linux Enterprise Server per applicazioni SAP con più SID

Un cluster multi-SID con il server di replica accodamento ha un aspetto schemasto

Diagramma che mostra un cluster multi-SID con il server di replica di accodamento.

Scenari di scalabilità orizzontale di SAP HANA

Gli scenari di scalabilità orizzontale di SAP HANA sono supportati per un subset delle macchine virtuali di Azure certificate di HANA elencate nella directory hardware di SAP HANA. Tutte le macchine virtuali contrassegnate con "Sì" nella colonna "Clustering" possono essere usate per la scalabilità orizzontale OLAP o S/4HANA. Le configurazioni senza standby sono supportate con i tipi di Archiviazione di Azure di:

  • Azure Archiviazione Premium v1, incluso l'acceleratore di scrittura di Azure per il volume /hana/log
  • Azure Archiviazione Premium v2
  • Disco Ultra
  • Azure NetApp Files

Le configurazioni con scalabilità orizzontale di SAP HANA per OLAP o S/4HANA con nodi di standby sono supportate esclusivamente con NFS condiviso ospitato in Azure NetApp Files.

Per altre informazioni sulle configurazioni di archiviazione esatte con o senza nodo di standby, vedere gli articoli:

Scenario di ripristino di emergenza

Sono supportati diversi scenari di ripristino di emergenza. Le architetture di emergenza vengono definite come architetture, che dovrebbero compensare un'area di Azure completa che esce dalla griglia. Ciò significa che la destinazione del ripristino di emergenza deve essere un'area di Azure diversa come destinazione per eseguire il panorama sap. Sono stati separati metodi e configurazioni nel livello DBMS e nel livello non DBMS.

Livello DBMS

Per il livello DBMS, sono supportate le configurazioni che usano i meccanismi di replica nativa DBMS, ad esempio Always On, Oracle Data Guard, Db2 HADR, SAP ASE Always-On o replica di sistema HANA. È obbligatorio che il flusso di replica in questi casi sia asincrono, anziché sincrono come in scenari di disponibilità elevata tipici distribuiti in una singola area di Azure. Un esempio tipico di una configurazione di ripristino di emergenza DBMS supportata è descritto nell'articolo Disponibilità di SAP HANA tra aree di Azure. Il secondo grafico in tale sezione descrive uno scenario con HANA come esempio. I database principali supportati per le applicazioni SAP sono tutti in grado di essere distribuiti in uno scenario di questo tipo.

è supportato l'uso di una macchina virtuale di dimensioni inferiori come istanza di destinazione nell'area di ripristino di emergenza perché tale macchina virtuale non riscontra il traffico completo del carico di lavoro. In questo modo, è necessario tenere presenti le considerazioni seguenti:

  • I tipi di vm più piccoli non consentono che molti dischi collegati rispetto alle macchine virtuali più piccole
  • Le macchine virtuali più piccole hanno una velocità effettiva di rete e archiviazione inferiore
  • Il ridimensionamento tra le famiglie di macchine virtuali può essere un problema quando vengono raccolte macchine virtuali diverse in un set di disponibilità di Azure o quando il ridimensionamento deve verificarsi tra la famiglia M-Series e la famiglia di macchine virtuali Mv2
  • Utilizzo della CPU e della memoria per l'istanza del database in grado di ricevere il flusso di modifiche con un ritardo minimo e risorse di CPU e memoria sufficienti per applicare queste modifiche con un ritardo minimo ai dati

Altre informazioni sulle limitazioni delle diverse dimensioni delle macchine virtuali sono disponibili nella pagina dimensioni delle macchine virtuali

Un altro metodo supportato per la distribuzione di una destinazione di ripristino di emergenza consiste nel disporre di una seconda istanza DBMS installata in una macchina virtuale che esegue un'istanza DBMS non di produzione di un'istanza SAP non di produzione. Questa operazione può risultare un po' più complessa perché è necessario capire quali risorse di memoria, CPU, larghezza di banda di rete e larghezza di banda di archiviazione sono necessarie per le istanze di destinazione specifiche che devono funzionare come istanza principale nello scenario di ripristino di emergenza. In particolare in HANA è consigliabile configurare l'istanza che funge da destinazione di ripristino di emergenza in un host condiviso in modo che i dati non vengano precaricati nell'istanza di destinazione di ripristino di emergenza.

Nota

L'utilizzo di Azure Site Recovery non è stato testato per le distribuzioni DBMS nel carico di lavoro SAP. Di conseguenza, non è supportato per il livello DBMS dei sistemi SAP in questo momento. Altri metodi di replica di Microsoft e SAP non elencati non sono supportati. L'uso di software di terze parti per la replica del livello DBMS di sistemi SAP tra aree di Azure diverse deve essere supportato dal fornitore del software e non sarà supportato tramite i canali di supporto Microsoft e SAP.

Livello non DBMS

Per il livello dell'applicazione SAP e le condivisioni finali o le posizioni di archiviazione necessarie, i due scenari principali vengono usati dai clienti:

  • Le destinazioni di ripristino di emergenza nella seconda area di Azure non vengono usate per scopi di produzione o non di produzione. In questo scenario, le macchine virtuali che funzionano come destinazione di ripristino di emergenza non vengono distribuite e l'immagine e le modifiche apportate alle immagini del livello dell'applicazione SAP di produzione vengono replicate nell'area di ripristino di emergenza. Una funzionalità che può eseguire tale attività è Azure Site Recovery. Azure Site Recovery supporta uno scenario di replica da Azure ad Azure come questo.
  • Le destinazioni di ripristino di emergenza sono macchine virtuali effettivamente in uso da sistemi non di produzione. L'intero panorama SAP è distribuito in due aree di Azure diverse con sistemi di produzione in genere in un'area e in sistemi non di produzione in un'altra area. In molte distribuzioni dei clienti, il cliente ha un sistema non di produzione equivalente a un sistema di produzione. Il cliente ha istanze dell'applicazione di produzione preinstallate nei sistemi non di produzione a livello di applicazione. In un evento di failover, le istanze non di produzione vengono arrestate, i nomi virtuali delle macchine virtuali di produzione spostate nelle macchine virtuali non di produzione (dopo aver assegnato nuovi indirizzi IP in DNS) e le istanze di produzione preinstallate vengono avviate

Cluster SAP Central Services

I cluster SAP Central Services che usano dischi condivisi (Windows), condivisioni SMB (Windows) o condivisioni NFS sono un po' più difficili da replicare. Sul lato Windows, La replica di archiviazione di Windows è una possibile soluzione. In Linux rsync è una soluzione praticabile. Anche la replica tra aree di Azure NetApp Files è una soluzione praticabile.

Scenario non supportato

È disponibile un elenco di scenari, che non sono supportati per il carico di lavoro SAP nelle architetture di Azure. Non supportato significa che SAP e Microsoft non sono in grado di fornire supporto per queste configurazioni e devono rinviare a un'eventuale terza parte coinvolta che ha fornito software per stabilire tali architetture. Due delle categorie sono:

  • Appliance soft di archiviazione: ci sono vari elettrodomestici soft di archiviazione sul mercato. Alcuni fornitori offrono la propria documentazione su come usare le appliance soft di archiviazione in Azure correlate al software SAP. Il supporto di configurazioni o distribuzioni che coinvolgono tali appliance soft di archiviazione deve essere fornito dal fornitore dell'appliance soft di archiviazione. Questo fatto si manifesta anche nella nota di supporto SAP #2015553
  • Framework a disponibilità elevata: solo Pacemaker e Windows Server Failover Cluster sono supportati framework di disponibilità elevata per il carico di lavoro SAP in Azure. Come accennato in precedenza, la soluzione di SIOS Datakeeper è descritta e documentata da Microsoft. Tuttavia, i componenti di SIOS devono essere supportati tramite SIOS Datakeeper come fornitore che fornisce tali componenti. SAP ha anche elencato altri framework di disponibilità elevata certificati in varie note SAP. Alcuni di essi sono stati certificati anche dal fornitore di terze parti per Azure. Tuttavia, il supporto per le configurazioni che usano tali prodotti deve essere fornito dal fornitore del prodotto. Diversi fornitori hanno un'integrazione diversa nei processi di supporto SAP. È necessario chiarire il processo di supporto più adatto per il fornitore specifico prima di decidere di usare il prodotto con le configurazioni SAP distribuite in Azure.
  • I cluster di dischi condivisi in cui si trovano i file di database nei dischi condivisi non sono supportati, ad eccezione di maxDB. Per tutti gli altri database, la soluzione supportata consiste nell'avere percorsi di archiviazione separati anziché una condivisione SMB o NFS o un disco condiviso per configurare scenari di disponibilità elevata

Altri scenari, che non sono supportati, sono scenari come:

  • Scenari di distribuzione che introducono una latenza di rete più ampia tra il livello applicazione SAP e il livello SAP DBMS come in NetWeaver, S/4HANA e ad esempio Hybris. ad esempio:
    • Distribuzione di uno dei livelli in locale, mentre l'altro livello viene distribuito in Azure
    • Distribuzione del livello applicazione SAP di un sistema in un'area di Azure diversa rispetto al livello DBMS
    • Distribuzione di un livello nei data center che si trovano in modalità condivisa in Azure e nell'altro livello in Azure, ad eccezione dei casi in cui tale modello di architettura viene fornito da un servizio nativo di Azure
    • Distribuzione di appliance virtuali di rete tra il livello applicazione SAP e il livello DBMS
    • Uso dell'archiviazione ospitata nei data center che si trovano nel data center di Azure per il livello SAP DBMS o la directory di trasporto globale SAP
    • Distribuzione dei due livelli con due diversi fornitori di servizi cloud. Ad esempio, la distribuzione del livello DBMS in Oracle Cloud Infrastructure e il livello applicazione in Azure
  • Configurazioni del cluster HANA Pacemaker a istanze multipla
  • Configurazioni del cluster Windows con dischi condivisi tramite SOFS o SMB in ANF per i database SAP supportati in Windows. È invece consigliabile usare la replica nativa a disponibilità elevata dei database specifici e usare stack di archiviazione separati
  • Distribuzione di database SAP supportati in Linux con file di database che si trovano in condivisioni NFS su ANF, ad eccezione di SAP HANA, Oracle in Oracle Linux e Db2 in Suse e Red Hat
  • Distribuzione di Oracle DBMS in qualsiasi altro sistema operativo guest rispetto a Windows e Oracle Linux. Vedere anche nota di supporto SAP #2039619

Gli scenari che non sono stati testata e pertanto non hanno esperienza con l'elenco, ad esempio:

  • Azure Site Recovery replica di macchine virtuali livello DBMS. Di conseguenza, è consigliabile usare la funzionalità di replica asincrona nativa del database per la potenziale configurazione del ripristino di emergenza

Passaggi successivi

Leggere i passaggi successivi nella pianificazione e nell'implementazione di Azure Macchine virtuali per SAP NetWeaver