Distribuzione SAP in Azure tramite 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 descrive le procedure comprovate per l'esecuzione di SAP NetWeaver con Oracle Database in Azure in una configurazione a disponibilità elevata . I principi generali dell'architettura si applicano ai sistemi operativi supportati. Se non diversamente specificato, si supponga che questa architettura usi Linux.

Note

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

Architecture

Il diagramma seguente illustra 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 Visio di questa architettura e delle architetture correlate.

Workflow

Il flusso di lavoro seguente corrisponde al diagramma precedente:

  1. Gli utenti e i sistemi aziendali si connettono da reti Azure locali o con peering attraverso la rete hub nella rete virtuale SPOKE SAP.

  2. Sap Web Dispatcher e i server applicazioni SAP elaborano le richieste nel livello applicazione e inviano chiamate di database al nodo primario Oracle.

  3. Oracle Data Guard mantiene un database standby sincronizzato in un'altra zona di disponibilità e le macchine virtuali (VM) observer di Oracle Data Guard monitorano la replica e la prontezza per il failover.

  4. Se si verifica un errore di nodo o zona del database, il failover di avvio rapido di Oracle Data Guard promuove il nodo di standby al nodo primario e i server applicazioni SAP si riconnettono al nuovo nodo primario.

  5. I file system SAP condivisi, ad esempio i volumi sapmnt e transport, rimangono disponibili attraverso il livello resiliente selezionato del Network File System (NFS). I servizi di backup proteggono le macchine virtuali di database e applicazioni.

Components

Questa architettura di riferimento descrive un tipico sistema di produzione SAP eseguito in Oracle Database in Azure in una configurazione a disponibilità elevata per ottimizzare la disponibilità del sistema. È possibile modificare l'architettura e i relativi componenti in base ai requisiti aziendali, ad esempio l'obiettivo del tempo di ripristino (RTO), l'obiettivo del punto di ripristino (RPO), le aspettative del tempo di attività e il ruolo del sistema. Per gli ambienti non di produzione o i carichi di lavoro che non richiedono disponibilità elevata, è possibile distribuire il sistema in una singola macchina virtuale. Il layout di rete è semplificato per mostrare i principi architetturali di base di un ambiente SAP e non rappresenta un'intera rete aziendale.

Networking

  • Reti virtuali:Rete virtuale di Azure connette Azure risorse tra loro con sicurezza avanzata. In questa architettura la rete virtuale si connette all'ambiente locale tramite un gateway ExpressRoute distribuito nell'hub di una topologia hub-spoke. Questa architettura contiene applicazioni e database SAP nella propria rete virtuale spoke e suddivide le reti virtuali in subnet separate per ogni livello: applicazione (SAP NetWeaver), database e servizi condivisi come Azure Bastion.

    Questa architettura suddivide lo spazio degli indirizzi delle rete virtuale in subnet. Posizionare i server delle applicazioni in una subnet separata e i server di database su un'altra. Usando questo approccio, è possibile proteggere i server più facilmente gestendo i criteri di sicurezza della subnet anziché i singoli server. È anche possibile separare in modo pulito le regole di sicurezza applicabili ai database dai server applicazioni.

  • Peering di rete virtuale: Questa architettura utilizza una topologia di rete hub-and-spoke con più reti virtuali collegate tra loro tramite 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 di zona: Un gateway collega reti distinte ed estende la rete on-premises alla rete virtuale di Azure. È consigliabile usare Azure ExpressRoute per creare connessioni private che non passano tramite Internet pubblico, ma è anche possibile usare una connessione da sito a sito. Usare gateway ExpressRoute o VPN con ridondanza di zona per proteggere dai guasti delle zone. Per altre informazioni sulle differenze tra una distribuzione a zone e una distribuzione con ridondanza della zona, vedere Affidabilità nei gateway di rete virtuale di Azure. I gateway in una distribuzione di zona richiedono indirizzi IP SKU Standard.

  • Gruppi di sicurezza di rete (NSG): Per limitare il traffico in ingresso, in uscita e all'interno della rete virtuale , creare gruppi di sicurezza di rete e assegnarli a subnet specifiche. Gli NSG dedicati ai singoli carichi di lavoro proteggono le subnet del database e dell'applicazione.

  • Gruppi di sicurezza delle applicazioni (ASG): Per definire criteri di sicurezza di rete granulari all'interno degli NSG in base ai ruoli applicativi, usa ASGs anziché indirizzi IP espliciti. Assegnare le interfacce di rete delle VM agli ASG e usare tali gruppi come origini o destinazioni nelle regole NSG.

  • Nic: I controller di interfaccia di rete consentono tutte le comunicazioni tra macchine virtuali in una rete virtuale. Le distribuzioni SAP locali tradizionali implementano più schede di interfaccia di rete per computer per separare il traffico amministrativo dal traffico aziendale.

    In Azure, la rete virtuale è una rete SDN (Software-Defined Network) 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 rete di Azure supportano più indirizzi IP. Questo supporto è conforme alla procedura consigliata da SAP per 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. Per il livello applicativo SAP, la distribuzione utilizza macchine virtuali per tutti i ruoli di istanza. Questi ruoli includono SAP Web Dispatcher e i server applicativi SAP, le istanze dei servizi centrali SAP ASCS e Enqueue Replication Server (ERS) e i server applicativi Primary Application Server (PAS) e Additional Application Server (AAS). Modificare il numero di macchine virtuali in base alle esigenze. Per altre informazioni su come eseguire SAP NetWeaver nelle macchine virtuali, vedere Plan e implementare una distribuzione SAP in Azure.

Analogamente, l'architettura usa macchine virtuali per tutti i componenti Oracle, inclusi Oracle Database e le macchine virtuali observer Oracle. Le macchine virtuali observer in questa architettura sono inferiori ai server di database.

  • Macchine virtuali vCPU (Constrained Virtual CPU): Per risparmiare sui costi delle licenze Oracle, prendere in considerazione le macchine virtuali vincolate vCPU.

  • Famiglie di macchine virtuali certificate per SAP: Per altre informazioni sul supporto SAP per Azure tipi di vm e metriche di velocità effettiva (SAPS), vedere la nota SAP 1928533.

  • Gruppi di posizionamento di prossimità (PPG): Nella maggior parte delle distribuzioni di zona la latenza all'interno della zona è sufficiente per le applicazioni SAP. Se la latenza misurata tra l'applicazione e i livelli di database influisce sul carico di lavoro, usare ppg per le macchine virtuali SAP ASCS/SCS e livello applicazione. Mantenere le macchine virtuali di database fuori dal ppg per mantenere la flessibilità per il ridimensionamento delle macchine virtuali di database e le modifiche dello SKU.

  • Macchine virtuali di seconda generazione (gen2): Quando si distribuiscono macchine virtuali in Azure, è possibile scegliere generazione 1 (Gen1) o Gen2. Le macchine virtuali gen2 supportano funzionalità non fornite da Gen1. Queste funzionalità sono importanti per i database Oracle di grandi dimensioni perché alcune famiglie di macchine virtuali, ad esempio Mv2 e Mdsv2, vengono eseguite solo come macchine virtuali Gen2. La certificazione di SAP in Azure per alcune macchine virtuali più recenti potrebbe richiedere anche Gen2 per il supporto completo, anche se Azure supporta entrambe le generazioni per tali macchine virtuali. Per altre informazioni, vedere la nota SAP 1928533 - Prodotti supportati e Azure tipi di macchina virtuale.

    Tutte le altre macchine virtuali che supportano SAP supportano solo Gen2 o Gen1 e Gen2. È consigliabile distribuire tutte le macchine virtuali SAP come Gen2, anche quando i requisiti di memoria sono bassi. È possibile ridimensionare le macchine virtuali gen2 più piccole distribuite come Gen2 nella macchina virtuale più grande disponibile con una semplice operazione di deallocazione e ridimensionamento. Le macchine virtuali gen1 possono essere ridimensionate solo alle famiglie di macchine virtuali che Azure supportano per Gen1.

Storage

Questa architettura usa dischi gestiti di Azure per le macchine virtuali e condivisioni file di Azure o Azure NetApp Files per qualsiasi esigenza di archiviazione condivisa NFS, come sapmnt e i volumi NFS SAP transport. Per altre informazioni sulla distribuzione dell'archiviazione con SAP in Azure, vedere Archiviazione di Azure types for SAP workload guide (Guida ai tipi di carico di lavoro SAP).

Disponibilità elevata

L'architettura precedente mostra una distribuzione a disponibilità elevata, con ogni livello di applicazione contenuto in due o più macchine virtuali. Usa 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 di Azure con orchestrazione flessibile (FD=1), zone di disponibilità e set di disponibilità per aumentare la disponibilità delle risorse. Per altre informazioni sulle opzioni di distribuzione e sulla relativa applicabilità in aree di Azure diverse (incluse le zone, all'interno di una singola zona o in un'area senza zone), vedere Architettura a disponibilità elevata e scenari per SAP NetWeaver.

  • Servizi di bilanciamento del carico: Un servizio di bilanciamento del carico interno Azure distribuisce il traffico alle macchine virtuali nelle subnet SAP. Azure Load Balancer supporta la distribuzione a ridondanza di zona per le distribuzioni zonali di SAP.

    Prendere in considerazione i fattori decisionali quando si distribuiscono macchine virtuali tra zone di disponibilità per SAP. Considerare i PPG con una distribuzione in una zona di disponibilità e usarli solo per le VM del livello applicativo.

    Note

    Le zone di disponibilità forniscono alta disponibilità all'interno della regione, ma il ripristino di emergenza tra zone potrebbe non soddisfare i requisiti di resilienza in caso di un disastro geograficamente esteso. Selezionare una regione di disaster recovery in base ai requisiti aziendali e normativi in materia di distanza, alla disponibilità dei servizi, alla latenza e agli obiettivi di RPO/RTO.

  • Componenti specifici di Oracle: Nelle aree di zona si distribuiscono macchine virtuali di Oracle Database in zone di disponibilità diverse con il modello di distribuzione consigliato da SAP set di scalabilità di macchine virtuali con il numero di domini di errore impostato su 1 (FD=1). Nelle regioni senza zone di disponibilità, usare le opzioni di distribuzione HA regionali. 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 del database, una configurazione di Oracle Data Guard fast-start failover richiede macchine virtuali aggiuntive con l'Oracle Data Guard observer. Le macchine virtuali observer Oracle monitorano lo stato del database e della replica e facilitano il failover del database in modo automatizzato, senza gestione cluster. È possibile eseguire la gestione della replica di database tramite Oracle Data Guard Broker. Per altre informazioni, vedere Architetture per il database Oracle in Macchine virtuali di Azure.

    Questa architettura usa strumenti Oracle nativi senza software cluster o la necessità di un servizio di bilanciamento del carico nel livello di database. Con il failover rapido e la configurazione SAP di Oracle Data Guard, il processo di failover viene automatizzato e le applicazioni SAP si riconnettono al nuovo database primario in caso di failover.

    Esistono diverse soluzioni cluster non Microsoft come alternative, ad esempio SIOS Protection Suite o Veritas InfoScale, ed è possibile trovare i dettagli della distribuzione nella documentazione di ogni fornitore.

  • Oracle RAC: Oracle Real Application Clusters (RAC) non è supportato nelle macchine virtuali Azure. Oracle AI Database@Azure supporta le distribuzioni RAC in Exadata, ma tale servizio non fa parte di questa architettura. Per questa architettura basata su VM, Oracle Data Guard può fornire alta disponibilità e protezione dalle interruzioni del servizio a livello di rack, data center o area geografica.

  • Livello NFS: Per le distribuzioni SAP basate su Linux a disponibilità elevata, è necessario usare un livello NFS resiliente che fornisce volumi NFS per la directory di trasporto SAP, il sapmnt volume per i file binari SAP e volumi aggiuntivi per le istanze (A)SCS e ERS.

    Le opzioni per fornire un livello NFS includono:

  • Cluster SAP Central Services: Questa architettura di riferimento esegue Central Services in macchine virtuali discrete. Central Services diventa un potenziale singolo punto di errore (SPoF) quando viene distribuito in una singola macchina virtuale. Per implementare una soluzione a disponibilità elevata, è necessario un software di gestione del cluster che automatizza il failover delle istanze (A)SCS e ERS nella rispettiva macchina virtuale. Questa configurazione dipende dalla soluzione NFS scelta, quindi la configurazione segue i requisiti della soluzione.

    La soluzione cluster deve determinare quale macchina virtuale serve ogni servizio quando il software o l'infrastruttura non è più disponibile. SAP on Azure offre due opzioni per le implementazioni STONITH basate su Linux per gestire macchine virtuali o applicazioni non rispondenti:

    • STONITH block device (SBD): SBD supporta due forme. Nel modulo iSCSI si distribuiscono una o tre macchine virtuali aggiuntive che fungono da destinazioni iSCSI per un piccolo dispositivo a blocchi condivisi. Le macchine virtuali membri del cluster (le due macchine virtuali (A)SCS/ERS in questo pool di cluster) accedono regolarmente a questo dispositivo e usano i punti di montaggio SBD per esprimere il proprio voto e raggiungere il quorum per le decisioni del cluster. Questa architettura non include le macchine virtuali SBD aggiuntive. Nel modulo Azure disco condiviso, un disco condiviso Azure sostituisce le macchine virtuali di destinazione iSCSI, quindi non sono necessarie macchine virtuali aggiuntive. Per le distribuzioni tra zone, usare un disco condiviso ZRS per mantenere la disponibilità del disco tra le zone.

    • Azure agente di isolamento: questa opzione usa l'API di gestione Azure per bloccare i nodi non riusciti arrestandoli e riavviandoli tramite l'API di calcolo Azure. Non richiede macchine virtuali aggiuntive.

    Per i passaggi di configurazione e i dettagli di progettazione, vedere le guide collegate nella sezione Livello NFS. I gestori di cluster non certificati per Azure da Microsoft possono fornire alta disponibilità per SAP Central Services.

  • Pool di server applicativi SAP: Distribuire due o più server applicativi. Il message server SAP o i dispatcher web bilanciano il carico delle richieste per garantire l'alta disponibilità. Ogni server applicazioni funziona in modo indipendente e questo pool di macchine virtuali non richiede il bilanciamento del carico di rete.

  • Pool di SAP Web Dispatcher: Il componente Web Dispatcher bilancia il traffico SAP tra i server applicativi SAP. Per ottenere l'alta disponibilità del SAP Web Dispatcher, utilizzare un cluster di failover oppure una configurazione parallela di Web Dispatcher e posizionare le istanze di dispatcher dietro un sistema di bilanciamento del carico.

    Il dispatcher Web incorporato in (A)SCS è un'opzione speciale. Prevedere un dimensionamento adeguato dovuto al carico di lavoro aggiuntivo su (A)SCS.

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

  • Distribuzioni di Windows: Questo articolo è incentrato principalmente sulle distribuzioni basate su Linux. Gli stessi principi architetturali si applicano alle Windows. L'architettura Oracle non differisce tra Linux e Windows.

    Per informazioni dettagliate sull'applicazione SAP, vedere Eseguire SAP NetWeaver in Windows in Azure.

Considerations

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

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 (DR) e usa le zone di disponibilità.

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

Scaricare un file 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 include diverse opzioni:

  • Backup di Azure:Script forniti e gestiti da Azure per Oracle Database e Backup di Azure per i requisiti di backup di Oracle.

  • Archiviazione: Usa backup del database basati su file, ad esempio i backup pianificati con gli strumenti BR di SAP, e archiviali gestendone le versioni come file o directory nei servizi di archiviazione Azure Blob NFS, Azure Blob o File di Azure. Per i backup dei log e dei dati Oracle, vedere Strategie di backup per Oracle Database in una macchina virtuale Linux Azure.

  • Soluzioni di backup esterne: Vedere le indicazioni sull'architettura di un provider di archiviazione di backup che supporta Oracle in Azure.

Per le macchine virtuali non di database, è consigliabile Backup di Azure per le macchine virtuali per proteggere le macchine virtuali dell'applicazione SAP e l'infrastruttura di supporto, ad esempio SAP Web Dispatcher.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

I principali driver di costo in questa architettura sono:

  • SKU di macchine virtuali certificati ORACLE e SAP e il numero di macchine virtuali nel livello applicazione, nel livello di database e nei nodi osservatore.

  • Decisioni relative al modello di licenza Oracle per il software del sistema operativo e del database. Valutare l'uso di SKU di macchine virtuali con vCPU limitate per ridurre, ove appropriato, il numero di core soggetti a licenza.

  • Livelli di prestazioni dello storage e capacità allocata per i volumi Oracle di dati, log, backup e NFS condivisi.

  • Servizi di rete e di alta disponibilità, in particolare gateway ExpressRoute o VPN, servizi di bilanciamento del carico e traffico di replica tra zone o tra aree geografiche.

Vedere la stima preconfigurata nel calcolatore prezzi Azure per un'architettura Oracle a disponibilità elevata di medie dimensioni per stimare i costi per la topologia e gli SKU selezionati. Per controllare la spesa:

  • Dimensionare correttamente la memoria e la CPU della VM in base ai SAPS misurati e ai requisiti di throughput di Oracle.

  • Usare livelli di archiviazione con costi più elevati solo in cui i requisiti di latenza e di input/output al secondo (IOPS) li richiedono.

  • Valutare le prenotazioni o i piani di risparmio per il calcolo dello stato stabile dopo la convalida della flessibilità operativa e delle licenze.

Contributors

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

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