Modifica

Condividi tramite

Distribuzione di SAP in Azure con un database Oracle

Azure ExpressRoute
SAP HANA in istanze Large di Azure
Macchine virtuali di Azure
Rete virtuale di Azure
Azure NetApp Files

Questa architettura di riferimento illustra un set di procedure comprovate per l'esecuzione di sap NetWeaver a disponibilità elevata con Oracle Database in Azure. I principi dell'architettura sono indipendenti dal sistema operativo, tuttavia, se non diversamente specificato, si presuppone che l'architettura sia basata su Linux.

Il primo diagramma mostra un'architettura di riferimento per SAP in Oracle in Azure. È consigliabile distribuire tra due zone di disponibilità.

Diagramma dell'architettura di un sistema SAP di produzione in Oracle in Azure.

Scaricare un file di Visio di questa architettura e delle architetture correlate.

Nota

Per distribuire questa architettura di riferimento, sono necessarie le licenze appropriate dei prodotti SAP e di altre tecnologie non Microsoft.

Componenti

Questa architettura di riferimento descrive un tipico sistema di produzione SAP in esecuzione in Oracle Database in Azure, in una distribuzione a disponibilità elevata per ottimizzare la disponibilità del sistema. L'architettura e i relativi componenti possono essere personalizzati in base ai requisiti aziendali (obiettivo del tempo di ripristino (RTO), all'obiettivo del punto di ripristino (RPO), alle aspettative del tempo di attività, al ruolo del sistema) e potenzialmente ridotti a una singola macchina virtuale. Il layout di rete è semplificato per illustrare le entità architetturali di tale ambiente SAP e non intende descrivere una rete aziendale completa.

Rete

Reti virtuali. Il servizio Azure Rete virtuale connette le risorse di Azure tra loro con sicurezza avanzata. In questa architettura, la rete virtuale si connette all'ambiente locale tramite un gateway di rete privata virtuale (VPN) distribuito nell'hub di una topologia hub-spoke. Le applicazioni SAP e il database sono contenuti nella propria rete virtuale spoke. Le reti virtuali sono suddivise in subnet separate per ogni livello: applicazione (SAP NetWeaver), database e servizi condivisi (ad esempio Azure Bastion).

Questa architettura suddivide lo spazio degli indirizzi delle rete virtuale in subnet. Posizionare i server applicazioni in una subnet separata e in server di database in un altro server. In questo modo è possibile proteggerli più facilmente gestendo i criteri di sicurezza della subnet anziché i singoli server e separando in modo pulito le regole di sicurezza applicabili ai database dai server applicazioni.

Peering di reti virtuali. Questa architettura usa una topologia di rete hub-spoke con più reti virtuali con peering. Questa topologia fornisce la segmentazione di rete e l'isolamento per i servizi distribuiti in Azure. Il peering consente la connettività trasparente tra reti virtuali con peering tramite la rete backbone Microsoft.

Gateway con ridondanza della zona. Un gateway connette reti distinte, estendendo la rete locale alla rete virtuale di Azure. È consigliabile usare ExpressRoute per creare connessioni private che non passano tramite Internet pubblico, ma è anche possibile usare una connessione da sito a sito . Usare i gateway VPN o Azure ExpressRoute con ridondanza della zona per proteggersi dagli errori della zona. Vedere Gateway di rete virtuale con ridondanza della zona per comprendere le differenze tra una distribuzione di zona e una distribuzione con ridondanza della zona. Vale la pena ricordare qui che gli indirizzi IP usati devono essere di SKU Standard per una distribuzione di zona dei gateway.

Gruppi di sicurezza di rete. Per limitare il traffico in ingresso, in uscita e all'interno della subnet nella rete virtuale, creare gruppi di sicurezza di rete (NSG) che a loro volta vengono assegnati a subnet specifiche. Le subnet del database e dell'applicazione sono protette con gruppi di sicurezza di rete specifici del carico di lavoro.

Gruppi di sicurezza delle applicazioni. Per definire criteri di sicurezza di rete con granularità fine all'interno dei gruppi di sicurezza di rete in base ai carichi di lavoro incentrati sulle applicazioni, usare gruppi di sicurezza delle applicazioni anziché indirizzi IP espliciti. Consentono di raggruppare le macchine virtuali in base al nome e di proteggere le applicazioni filtrando il traffico da segmenti attendibili della rete.

Schede di interfaccia di rete (NIC). Le schede di interfaccia di rete consentono tutte le comunicazioni tra macchine virtuali in una rete virtuale. Le tradizionali distribuzioni SAP locali implementano più schede di interfaccia di rete per ogni macchina per segregare il traffico amministrativo rispetto al traffico aziendale.

In Azure la rete virtuale è una rete software-defined che invia tutto il traffico attraverso la stessa infrastruttura di rete. Non è quindi necessario usare più schede di interfaccia di rete per motivi di prestazioni. Tuttavia, se l'organizzazione deve separare il traffico, è possibile distribuire più schede di interfaccia di rete per macchina virtuale e connettere ogni scheda di interfaccia di rete a una subnet diversa. È quindi possibile usare i gruppi di sicurezza di rete per applicare criteri di controllo di accesso diversi in ogni subnet.

Le schede di interfaccia di rete di Azure supportano più indirizzi IP. Questo supporto è conforme alla procedura consigliata sap di usare i nomi host virtuali per le installazioni. Per una struttura completa, vedere la nota SAP 962955. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

Macchine virtuali

Questa architettura usa macchine virtuali (VM). Per il livello applicazione SAP, le macchine virtuali vengono distribuite per tutti i ruoli dell'istanza, ovvero Web Dispatcher e server applicazioni, sia per i servizi centrali SAP (A)SCS che per i server applicazioni (PAS, AAS). Modificare il numero di macchine virtuali in base alle esigenze. La guida alla pianificazione e all'implementazione di Azure Macchine virtuali include informazioni dettagliate sull'esecuzione di SAP NetWeaver nelle macchine virtuali.

Analogamente, per tutte le macchine virtuali Oracle vengono usate, sia per Oracle Database che per le macchine virtuali observer Oracle. Le macchine virtuali observer in questa architettura sono più piccole rispetto ai server di database effettivi.

  • Macchine virtuali vCPU vincolate. Per risparmiare sui costi delle licenze Oracle, prendere in considerazione l'uso di macchine virtuali vincolate vCPU
  • Famiglie di macchine virtuali certificate per SAP. Per informazioni dettagliate sul supporto SAP per i tipi di macchine virtuali di Azure e le metriche di velocità effettiva (SAPS), vedere la nota SAP 1928533. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

Gruppi di posizionamento di prossimità (PPG). Quando le macchine virtuali vengono distribuite nelle zone di disponibilità, la latenza all'interno della zona è in genere ideale per le applicazioni SAP. In rari casi, quando è necessario ridurre la latenza tra il database e le macchine virtuali dell'applicazione, è possibile usare gruppi di posizionamento di prossimità. Per tali situazioni, i gruppi di disponibilità garantiscono la collocazione, ovvero le macchine virtuali si trovano nello stesso data center per ridurre al minimo la latenza dell'applicazione. A causa di potenziali restrizioni con i gruppi di sicurezza di rete, l'aggiunta del database AvSet al PPG del sistema SAP deve essere eseguita in modo sparse e solo quando necessario. Per altri dettagli sugli scenari di utilizzo per i gruppi di disponibilità, vedere la documentazione collegata.

Macchine virtuali di seconda generazione (Gen2). Azure offre la scelta quando si distribuiscono macchine virtuali se devono essere di prima o 2. Le macchine virtuali di seconda generazione supportano le funzionalità chiave che non sono disponibili per le macchine virtuali di prima generazione. In particolare per i database Oracle di grandi dimensioni questa è di importanza perché alcune famiglie di macchine virtuali, ad esempio Mv2 o Mdsv2 , sono supportate solo come macchine virtuali Gen2. Analogamente, la certificazione SAP in Azure per alcune macchine virtuali più recenti potrebbe richiedere che siano solo Gen2 per il supporto completo, anche se Azure consente entrambi. Vedere i dettagli in SAP Note 1928533 - SAP Applications on Microsoft Azure: Supported Products and Azure VM types (Nota SAP 1928533 - Applicazioni SAP in Microsoft Azure: prodotti supportati e tipi di macchine virtuali di Azure).

Poiché tutte le altre macchine virtuali che supportano SAP consentono di scegliere solo Gen2 o Gen1+2 in modo selettivo, è consigliabile distribuire tutte le macchine virtuali SAP come Gen2, anche se i requisiti di memoria sono molto bassi. Anche le macchine virtuali più piccole una volta distribuite come Gen2 possono essere ridimensionate fino al più grande disponibile con una semplice operazione di deallocazione e ridimensionamento. Le macchine virtuali gen1 possono essere ridimensionate solo alle famiglie di macchine virtuali consentite per l'esecuzione di macchine virtuali gen1.

Storage

Questa architettura usa dischi gestiti di Azure per macchine virtuali e condivisioni file di Azure o Azure NetApp Files per qualsiasi requisito di archiviazione condivisa NFS (Network File System), ad esempio sapmnt e volumi NFS di trasporto SAP. Le linee guida per la distribuzione dell'archiviazione con SAP in Azure sono contenute in dettaglio nella guida ai tipi di Archiviazione di Azure per il carico di lavoro SAP

Disponibilità elevata

L'architettura precedente illustra una distribuzione a disponibilità elevata, con ogni livello applicazione contenuto in due o più macchine virtuali. Vengono usati i componenti seguenti.

In Azure, la distribuzione del carico di lavoro SAP può essere a livello di area o di zona, a seconda dei requisiti di disponibilità e resilienza delle applicazioni SAP e dell'area selezionata. Azure offre diverse opzioni di distribuzione, ad esempio set di scalabilità di macchine virtuali con orchestrazione flessibile (FD=1), zone di disponibilità e set di disponibilità per aumentare la disponibilità delle risorse. Per comprendere in modo completo le opzioni di distribuzione e la relativa applicabilità in aree di Azure diverse (incluse le zone, all'interno di una singola zona o in un'area senza zone), vedere Architettura e scenari a disponibilità elevata per SAP NetWeaver.

Servizi di bilanciamento del carico. Azure Load Balancer viene usato per distribuire il traffico alle macchine virtuali nelle subnet SAP. Quando si incorpora Azure Load Balancer in una distribuzione di zona di SAP, assicurarsi di selezionare il servizio di bilanciamento del carico dello SKU Standard. Il servizio di bilanciamento dello SKU Basic non supporta la ridondanza di zona.

Prendere in considerazione i fattori decisionali durante la distribuzione di macchine virtuali tra zone di disponibilità per SAP. L'uso di gruppi di posizionamento di prossimità con una distribuzione della zona di disponibilità deve essere valutato e usato solo per le macchine virtuali del livello applicazione.

Nota

zone di disponibilità supportare la disponibilità elevata all'interno dell'area, ma non sono efficaci per il ripristino di emergenza. Le distanze tra le zone sono troppo brevi. Le aree di ripristino di emergenza tipiche devono essere distanti almeno 100 miglia dall'area primaria.

Componenti specifici di Oracle. Le macchine virtuali di Oracle Database vengono distribuite in un set di disponibilità o in zone di disponibilità diverse. Ogni macchina virtuale contiene la propria installazione del software di database e dell'archiviazione del database locale della macchina virtuale. Configurare la replica sincrona del database tramite Oracle Data Guard tra i database per garantire la coerenza e consentire tempi di servizio RTO e RPO ridotti in caso di singoli errori. Oltre alle macchine virtuali di database, sono necessarie macchine virtuali aggiuntive con Oracle Data Guard Observer per un'installazione del failover fast-start di Oracle Data Guard. Le macchine virtuali observer Oracle monitorano lo stato del database e della replica e facilitano il failover del database in modo automatizzato, senza la necessità di gestione cluster. La gestione della replica del database può eseguire la scommessa e quindi usare Oracle Data Guard Broker per semplificare l'uso.

Per informazioni dettagliate sulla distribuzione di Oracle Data Guard, vedere la documentazione di Oracle Data Guard in Azure.

Questa architettura usa strumenti Oracle nativi senza software cluster effettivo o la necessità di un servizio di bilanciamento del carico nel livello di database. Con oracle Data Guard Fast-Start Failover e configurazione SAP, il processo di failover viene automatizzato e le applicazioni SAP si riconnettono al nuovo database primario in caso di failover. Esistono diverse soluzioni di cluster di terze parti come alternativa, ad esempio SIOS Protection Suite o Veritas InfoScale, i dettagli della distribuzione disponibili rispettivamente nella documentazione del fornitore di terze parti.

Oracle RAC. Oracle Real Application Cluster (RAC) non è attualmente certificato o supportato da Oracle in Azure. Tuttavia, le tecnologie e l'architettura di Oracle Data Guard per la disponibilità elevata possono offrire ambienti SAP altamente resilienti con protezione da rack, data center o interruzioni a livello di area del servizio.

Livello NFS. Per tutte le distribuzioni SAP a disponibilità elevata, è necessario usare un livello NFS resiliente, fornendo volumi NFS per la directory di trasporto SAP, il volume sapmnt per i file binari SAP e altri volumi per le istanze (A)SCS e ERS. Le opzioni per fornire un livello NFS sono

Cluster di servizi centrali SAP. Questa architettura di riferimento esegue Central Services in macchine virtuali discrete. Central Services è un potenziale punto di errore (SPOF) quando viene distribuito in una singola macchina virtuale. Per implementare una soluzione a disponibilità elevata, è necessario software di gestione del cluster che automatizza il failover delle istanze (A)SCS e ERS nella rispettiva macchina virtuale. Poiché questo è strettamente legato alla soluzione NFS scelta

La soluzione cluster scelta richiede un meccanismo per decidere in caso di indisponibilità del software o dell'infrastruttura che la macchina virtuale deve gestire i rispettivi servizi. Con SAP in Azure sono disponibili due opzioni per l'implementazione basata su Linux di STONITH: come gestire la macchina virtuale o l'applicazione non risponde

  • SUSE-Linux-only SBD (STONITH Block Device) - uso di una o tre macchine virtuali aggiuntive che fungono da esportazioni iSCSI di un piccolo dispositivo a blocchi, a cui si accede regolarmente dalle macchine virtuali membro del cluster effettive, due VM (A)SCS/ERS in questo pool di cluster. Le macchine virtuali usano questi montaggi SBD per eseguire il cast dei voti e quindi ottenere il quorum per le decisioni del cluster. L'architettura contenuta in questa pagina non contiene 1 o 3 macchine virtuali SBD aggiuntive.
  • Agente di isolamento di Azure. Senza usare macchine virtuali aggiuntive, l'API di gestione di Azure viene usata per verificare regolarmente la disponibilità delle macchine virtuali.

Le guide collegate all'interno della sezione livello NFS contengono i passaggi necessari e la progettazione per la rispettiva scelta del cluster. I gestori di cluster certificati di Azure di terze parti possono essere usati anche per offrire disponibilità elevata di SAP Central Services.

Pool di server applicazioni SAP. Due o più server applicazioni in cui la disponibilità elevata viene raggiunta dalle richieste di bilanciamento del carico tramite server messaggi SAP o dispatcher Web. Ogni server applicazioni è indipendente e non è necessario il bilanciamento del carico di rete per questo pool di macchine virtuali.

Pool di dispatcher Web SAP. Il componente Web Dispatcher viene usato come servizio di bilanciamento del carico per il traffico SAP tra i server applicazioni SAP. Per ottenere una disponibilità elevata di SAP Web Dispatcher, Azure Load Balancer implementa il cluster di failover o la configurazione parallela di Web Dispatcher.

Il dispatcher Web incorporato in (A)SCS è un'opzione speciale. È consigliabile prendere in considerazione il dimensionamento corretto a causa di un carico di lavoro aggiuntivo in (A)SCS.

Per le comunicazioni con connessione Internet, è consigliabile una soluzione autonoma nella rete perimetrale (nota anche come rete perimetrale) per soddisfare i problemi di sicurezza.

Distribuzioni di Windows. Questo documento, come già fatto all'inizio, è incentrato principalmente sulle distribuzioni basate su Linux. Per l'utilizzo con Windows, si applicano gli stessi principi architetturali e non esistono differenze di architettura con Oracle tra Linux e Windows.

Per la parte dell'applicazione SAP, vedere i dettagli nella guida all'architettura Eseguire SAP NetWeaver in Windows in Azure.

Considerazioni

Ripristino di emergenza

Il diagramma seguente illustra l'architettura di un sistema SAP di produzione in Oracle in Azure. L'architettura fornisce il ripristino di emergenza e usa le zone di disponibilità.

Diagramma che mostra un'architettura di un sistema SAP di produzione in Oracle in Azure.

Scaricare un file di Visio di questa architettura e delle architetture correlate.

Ogni livello architetturale nello stack di applicazioni SAP usa un approccio diverso per garantire la protezione del ripristino di emergenza. Per informazioni dettagliate sulle strategie di ripristino di emergenza e sull'implementazione, vedere Panoramica del ripristino di emergenza e linee guida sull'infrastruttura per il carico di lavoro SAP e le linee guida per il ripristino di emergenza per l'applicazione SAP.

Backup

Il backup per Oracle in Azure può essere eseguito tramite diversi mezzi:

  • Backup di Azure. Script forniti e gestiti da Azure per Oracle Database e Backup di Azure per i requisiti di backup di Oracle.
  • Archiviazione di Azure. Usando i backup di database basati su file, ad esempio pianificati con gli strumenti BR di SAP, per l'archiviazione e il controllo delle versioni come file/directory nei servizi di archiviazione NFS, BLOB di Azure o File di Azure. Vedere Dettagli documentati su come ottenere sia i backup di dati Oracle che i backup del log.
  • Soluzioni di backup di terze parti. Vedere l'architettura del provider di archiviazione di backup, che supporta Oracle in Azure.

Per le macchine virtuali non di database, è consigliabile Backup di Azure per la macchina virtuale per proteggere le macchine virtuali dell'applicazione SAP e racchiudere l'infrastruttura come SAP Web Dispatcher.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Passaggi successivi

Community

Le community possono rispondere alle domande ed essere utili per configurare correttamente la distribuzione. Prendere in considerazione queste risorse:

Vedere l'articolo seguente per altre informazioni e per esempi di carichi di lavoro SAP che usano alcune delle stesse tecnologie: