Condividi tramite

Acceleratore della zona di destinazione di SAP in Azure

  • Articolo

Usare l'acceleratore di zona di destinazione SAP in Azure per configurare e gestire le zone di destinazione del carico di lavoro all'interno della zona di destinazione su scala aziendale di Cloud Adoption Framework. L'acceleratore di zona di destinazione offre un approccio architetturale e un'implementazione di riferimento specifici per i sistemi SAP in Azure.

Distribuire l'acceleratore di zona di destinazione SAP in Azure dopo aver implementato correttamente una zona di destinazione su scala aziendale. Prima di distribuire SAP nell'acceleratore di zona di destinazione di Azure, vedere la panoramica e le linee guida per l'implementazione su scala aziendale.

Adattare l'acceleratore all'architettura

L'architettura dell'acceleratore di zona di destinazione di SAP in Azure varia in base all'organizzazione. Le considerazioni tecniche e le raccomandazioni di progettazione portano a configurazioni specifiche dello scenario specifico dell'organizzazione. Le raccomandazioni descritte in questo articolo possono portare a un'architettura che mette l'organizzazione in un percorso di scalabilità sostenibile.

L'acceleratore di zona di destinazione SAP in Azure è modulare. È possibile personalizzare le variabili di ambiente. L'approccio personalizzabile alle zone di destinazione include gli asset seguenti per supportare la pianificazione e l'implementazione:

Linee guida di progettazione

Quando si pianifica l'implementazione della zona di destinazione su scala aziendale, è necessario prendere decisioni di progettazione relative a diverse aree complessive. Questi articoli forniscono linee guida di progettazione e consigli per ogni area:

Architettura

È necessario comprendere e pianificare tutte le aree critiche dell'architettura di distribuzione. Questo articolo descrive i componenti chiave dell'architettura della zona di destinazione in Azure e l'architettura dei sistemi SAP.

Architettura delle zone di destinazione

Il diagramma seguente è un'architettura di riferimento concettuale che mostra le aree di progettazione critiche in un acceleratore di zona di destinazione di SAP in Azure:

Diagram that shows the SAP on Azure landing zone accelerator architecture.

Scaricare un file di Visio di questa architettura.

Nota

Quando si distribuisce un carico di lavoro SAP a disponibilità elevata in Azure, è importante considerare i vari tipi di distribuzione disponibili. Considerare anche come applicarli in aree di Azure diverse, ad esempio tra zone, in una singola zona o in un'area senza zone.

Per la massima disponibilità, distribuire sistemi SAP in diverse zone in un'area.

Per ottenere questo livello di disponibilità, è consigliabile usare un set di scalabilità di macchine virtuali flessibile con un platformFaultDomainCount valore (FD) pari a 1 . Per altre informazioni e una descrizione delle varie opzioni di distribuzione a disponibilità elevata per un carico di lavoro SAP, vedere Architettura e scenari a disponibilità elevata per SAP NetWeaver.

Architettura di sistemi SAP di alto livello

Il diagramma seguente è un'architettura di riferimento di un panorama dei sistemi SAP che include sistemi di produzione e non di produzione. Questa architettura è una delle numerose opzioni che è possibile usare per distribuire sistemi SAP in Azure. L'implementazione scelta dipende dai requisiti.

Usare l'architettura di riferimento come punto di partenza. È possibile scaricare il file di Visio e modificarlo in base ai requisiti aziendali e tecnici specifici quando si pianifica l'implementazione della zona di destinazione.

Diagram that shows the high-level architecture of an SAP systems landscape, with production and non-production systems, on Azure.

Workflow

Questo articolo fornisce un esempio di architettura SAP generale distribuita tra livelli diversi.

L'architettura di esempio di sistemi SAP descrive un panorama dei sistemi SAP con sistemi di produzione e non di produzione. Entrambi i sistemi vengono distribuiti nelle macchine virtuali. È possibile modificare le dimensioni e il numero di macchine virtuali per soddisfare le esigenze dell'organizzazione.

Questa architettura di esempio usa set di scalabilità di macchine virtuali per distribuire sistemi SAP in Azure. Il layout di rete in questo esempio è semplificato per illustrare i principi architetturali e non è progettato per descrivere un'intera rete aziendale.

Consigli

La distribuzione potrebbe essere diversa, a seconda dei requisiti aziendali. Queste raccomandazioni forniscono un punto di partenza.

Sottoscrizioni

L'architettura di sistemi SAP di esempio usa le tre sottoscrizioni seguenti:

  • Una sottoscrizione dell'hub virtuale di Azure che contiene la rete virtuale hub per le aree primarie e secondarie.

  • Una sottoscrizione di produzione SAP di Azure, in cui sono configurati i sistemi di produzione e ripristino di emergenza.

  • Una sottoscrizione di Azure SAP non di produzione, in cui un sistema non di produzione include un ambiente sandbox o uno sviluppo, una garanzia di qualità o sistemi di pre-produzione. Questa configurazione è facoltativa. È possibile usare una sottoscrizione per ogni zona del carico di lavoro.

Rete

L'architettura di sistemi SAP di esempio usa una topologia hub-spoke. La rete virtuale hub funge da punto centrale di connettività a una rete locale. Gli spoke sono reti virtuali SAP con peering con l'hub. È possibile usare gli spoke per isolare i carichi di lavoro.

L'architettura usa una rete virtuale SAP per ogni zona del carico di lavoro. Usa una rete virtuale SAP diversa per la produzione, lo sviluppo, la garanzia di qualità e la sandbox. Nell'architettura, la rete virtuale dell'hub di Azure è con peering con le reti virtuali di produzione, sviluppo, controllo qualità e sandbox. Il traffico scorre tra il data center locale e l'hub attraverso una connessione gateway.

Nota

Valutare la possibilità di configurare una VPN da sito a sito (S2S) come backup di Azure ExpressRoute o per eventuali requisiti di route di terze parti. Per altre informazioni, vedere Usare la VPN da sito a sito come backup per il peering privato di ExpressRoute.

Subnet e gruppi di sicurezza di rete

L'architettura suddivide lo spazio degli indirizzi della rete virtuale in subnet. È possibile associare ogni subnet a un gruppo di sicurezza di rete che definisce i criteri di accesso per la subnet. Posizionare i server applicazioni in una subnet separata in modo che sia possibile garantire più facilmente la sicurezza. È possibile gestire i criteri di sicurezza della subnet anziché gestire singoli server. Quando si associa un gruppo di sicurezza di rete a una subnet, il gruppo di sicurezza di rete si applica a tutti i server nella subnet ed è possibile controllare con granularità fine sui server.

Questa architettura ha tre o quattro subnet, a seconda del livello. Ad esempio, un sistema di produzione potrebbe avere le quattro subnet seguenti.

  • Azure NetApp Files: una subnet delegata per l'uso di Azure NetApp Files per diversi scenari SAP in Azure.
  • app Azure lication Gateway: subnet che gestisce il traffico proveniente da Internet. Ad esempio, questa subnet potrebbe gestire le app Fiori.
  • Applicazioni SAP: subnet che contiene server applicazioni SAP, SAP Central Services, istanze di servizi di replica accodamento SAP e dispatcher Web.
  • Database: subnet che contiene solo macchine virtuali di database.

Nota

L'architettura di sistemi SAP di esempio mostra la definizione esplicita dei dispatcher Web in un set di scalabilità di macchine virtuali separato. Il componente dispatcher Web è un servizio di bilanciamento del carico per il traffico SAP tra i server applicazioni SAP. Per ottenere la disponibilità elevata per SAP Web Dispatcher, Azure Load Balancer implementa il cluster di failover o la configurazione parallela del dispatcher Web. Configurare un'architettura di soluzione autonoma in una rete perimetrale per le comunicazioni con connessione Internet per soddisfare i problemi di sicurezza. Web Dispatcher incorporato in ASCS descrive un'opzione specifica. Prendere in considerazione il dimensionamento necessario a causa di altri carichi di lavoro in SAP ASCS.

set di scalabilità di macchine virtuali

Per tutti i pool e i cluster (SAP Web Dispatcher, server applicazioni SAP, SAP Central Services e SAP HANA), raggruppare le macchine virtuali in set di scalabilità di macchine virtuali separati. Non è previsto alcun addebito per la creazione di un set di scalabilità di macchine virtuali. Si paga solo per ogni macchina virtuale creata.

Macchine virtuali e zone di disponibilità

Una zona di disponibilità di Azure è una posizione fisica univoca all'interno di un'area. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete.

Quando si progettano zone di disponibilità, controllare la latenza tra le zone. Conoscere la latenza di rete tra le zone di un'area consente di scegliere le zone di disponibilità con la latenza di rete minima per il traffico di rete tra zone.

Quando si configurano le zone di disponibilità, usare i servizi con ridondanza della zona per le istanze di ExpressRoute, Azure Gateway VPN e gateway applicazione.

Per altre informazioni sull'architettura della zona di disponibilità per SAP in Azure, vedere Zone di disponibilità a disponibilità elevata di SAP.

Azure NetApp Files e File di Azure

Azure NetApp Files e File di Azure con NFS (Network File System) e Server Message Block (SMB) forniscono requisiti di condivisione file a disponibilità elevata per SAP Central Services, un montaggio SAP condiviso e una directory di trasporto globale.

Per gestire i requisiti della directory di trasporto, usare l'opzione gruppi di trasporto come descritto in Pianificazione e implementazione di Azure Macchine virtuali per SAP NetWeaver. Un altro modo per gestire i requisiti di trasporto consiste nel rendere uno dei livelli SAP il sistema di produzione primario che fornisce la condivisione della directory di trasporto ad altri sistemi nel panorama orizzontale.

I requisiti di disponibilità elevata per SAP Central Services variano a seconda del sistema operativo. Ad esempio:

Le condivisioni di Azure NetApp Files possono ospitare file di log e dati SAP HANA. Usare questa configurazione per un modello di distribuzione con scalabilità orizzontale HANA con nodi di standby. Azure NetApp Files supporta la scalabilità orizzontale di HANA o HANA con nodi di standby.

File di Azure offre due tipi principali di endpoint per l'accesso alle condivisioni file di Azure:

  • Gli endpoint pubblici hanno un indirizzo IP pubblico accessibile da qualsiasi parte del mondo.

  • Gli endpoint privati si trovano in una rete virtuale e hanno un indirizzo IP privato all'interno dello spazio indirizzi della rete virtuale.

L'architettura di sistemi SAP di esempio usa endpoint privati in modo che i client in una rete virtuale possano accedere ai dati tramite un collegamento privato, migliorando la sicurezza.

Connettività SAP BTP

Collegamento privato di Azure è ora disponibile a livello generale. Il servizio SAP collegamento privato supporta attualmente le connessioni da SAP BTP, il runtime di Cloud Foundry e altri servizi oltre alle risorse collegamento privato per il servizio di bilanciamento del carico più comune più scenari di macchine virtuali. Gli scenari di esempio includono SAP S/4HANA o SAP ERP in esecuzione nella macchina virtuale e la connessione a servizi nativi di Azure, ad esempio Database di Azure per MariaDB o Database di Azure per MySQL.

L'architettura di esempio mostra una connessione del servizio SAP collegamento privato agli ambienti BTP. SAP collegamento privato Service stabilisce una connessione privata tra servizi SAP BTP specifici e servizi specifici nell'infrastruttura come account del provider di servizi. Se si riutilizza la funzionalità di collegamento privato, i servizi BTP possono accedere all'ambiente S/4 HANA tramite connessioni di rete private, evitando così il trasferimento dei dati tramite la rete Internet pubblica.

Per altre informazioni sugli scenari per la connessione ai servizi BTP, vedere il post di blog della community SAP sull'effetto dell'architettura di collegamento privato Service.

Considerazioni

Quando si progetta la zona di destinazione, tenere conto delle considerazioni seguenti.

Consolidamento orizzontale

Valutare la possibilità di configurare il consolidamento orizzontale per sistemi non di produzione come ambienti sandbox e di sviluppo. Si considerino ad esempio casi d'uso diversi:

  • Gli scenari di database HANA in genere eseguono un'applicazione e un database in macchine virtuali separate.

  • Gli scenari anyDB possono avere distribuzioni a due livelli in cui l'applicazione SAP e il database vengono eseguiti nella stessa macchina virtuale.

I componenti sono separati nell'architettura di sistemi SAP di esempio per offrire maggiore flessibilità per la manutenzione, il dimensionamento, il monitoraggio e il controllo delle modifiche. Scegliere una progettazione in base ai requisiti.

Informazioni sui componenti

L'architettura di esempio include componenti che è possibile usare per le operazioni quotidiane 2. Questi componenti includono un insieme di credenziali di Servizi di ripristino di Azure per eseguire il backup di sistemi SAP e altri che consentono di estendere e migliorare la piattaforma dati SAP con i servizi dati di Azure nativi del cloud.

I servizi come Azure Synapse Analytics, Azure Data Factory e Azure Data Lake Archiviazione consentono di ottenere informazioni dettagliate aziendali combinando i dati SAP con dati non SAP e creando una piattaforma di analisi. Per valutare la progettazione dell'ambiente di sviluppo di soluzioni, esaminare le procedure consigliate. È possibile usare istanze diverse di Data Factory e Data Lake Archiviazione in base al livello SAP e alle procedure consigliate per la progettazione dell'ambiente.

Il runtime di integrazione di Azure è l'infrastruttura di calcolo usata dalle pipeline di Data Factory e Azure Synapse per fornire funzionalità di integrazione dei dati. Valutare la possibilità di distribuire macchine virtuali di runtime per questi servizi in ogni livello. Per esempi di come connettersi ai sistemi SAP e distribuire il runtime di integrazione di Azure, vedere gli articoli seguenti:

Per altre informazioni su tutti i componenti dell'architettura, vedere SAP S/4HANA in Linux in Azure.

Esempio di architettura orizzontale SAP con tre prodotti SAP

L'architettura di riferimento seguente è un'estensione dell'architettura di alto livello visualizzata in precedenza in questo articolo. Il diagramma descrive un caso d'uso di esempio con tre prodotti SAP. Mostra solo una delle opzioni che è possibile usare per distribuire sistemi SAP in Azure usando i set di scalabilità di macchine virtuali.

Usare questa architettura come punto di partenza. Scaricare il file di Visio e modificarlo in base ai requisiti aziendali e tecnici specifici quando si pianifica l'implementazione della zona di destinazione.

Diagram that shows an example use case with three SAP products.

Esempio di flusso di lavoro

I clienti SAP eseguono vari prodotti SAP in base ai casi d'uso specifici. Il diagramma dell'architettura mostra un caso d'uso di esempio con tre prodotti SAP comuni. Illustra un'architettura SAP di esempio distribuita tra livelli diversi.

Nel diagramma del flusso di lavoro ERP rappresenta un sistema SAP ECC legacy o un sistema SAP S/4HANA di nuova generazione. BW è SAP Business Warehouse. PI/PO si riferisce all'integrazione dei processi o all'orchestrazione dei processi. Diversi colori rappresentano vari prodotti SAP così come vengono visualizzati nel flusso di lavoro.

Implementazione

Sono disponibili due opzioni di implementazione.

Opzione 1

Il framework di automazione della distribuzione SAP in Azure è una raccolta di processi combinati con un flusso di lavoro flessibile. Il repository framework contiene il codice per distribuire automaticamente gli scenari SAP in Azure. I modelli sono separati nelle categorie seguenti.

  • Terraform nei moduli di Azure. Usare i moduli Terraform per distribuire i componenti dell'infrastruttura in Azure, tra cui:
    • Macchine virtuali
    • Rete
    • Archiviazione
  • Playbook ansible. Usare i playbook ansible per:
    • Configurare e distribuire macchine virtuali.
    • Installare SAP HANA.
    • Installare altre applicazioni necessarie.

Distribuire e installare i componenti del playbook Ansible nell'infrastruttura usando Terraform nei moduli di Azure.

Diagram that shows an overview of an SAP reference implementation.

Opzione 2

Il Centro di Azure per soluzioni SAP è un set di servizi di Azure che offre una soluzione unificata per la distribuzione e la gestione dei carichi di lavoro SAP mettendo insieme servizi, strumenti e framework.

L'istanza virtuale per le soluzioni SAP è la base di Centro di Azure per soluzioni SAP. È possibile usare Istanza virtuale per soluzioni SAP per creare e gestire sistemi SAP in modo appropriato, a livello di SID o a livello di singolo componente.

È possibile usare il Centro di Azure per le soluzioni SAP per seguire questa procedura:

  1. Deploy. Scegliere come distribuire il sistema SAP in Azure.
  2. Rappresentano. Creare una rappresentazione logica di ogni sistema durante la distribuzione o la registrazione di distribuzioni esistenti.
  3. Gestione. Configurare le operazioni con le funzionalità di gestione.

Diagram that describes how Azure Center for SAP solutions works.

Centro di Azure per soluzioni SAP offre queste funzionalità:

Distribuzione SAP guidata

Centro di Azure per soluzioni SAP automatizza la distribuzione di sistemi SAP S/4HANA in Azure. Fornisce una soluzione guidata per la distribuzione dell'infrastruttura e installa automaticamente il software S/4HANA.

È possibile fornire input minimo e scegliere il tipo di distribuzione corretto. Le distribuzioni si basano sulle procedure consigliate e sulle architetture di riferimento più recenti. È possibile ottenere raccomandazioni sul dimensionamento per distribuire il sistema SAP in base ai requisiti di memoria del database e S piattaforma di strumenti analitici.

Registrazione di sistemi SAP esistenti

Se si eseguono già sistemi SAP in Azure o si sta eseguendo una migrazione, è possibile usare Il Centro di Azure per le soluzioni SAP per integrare i sistemi esistenti usando un processo di registrazione semplice. Questo processo di registrazione è supportato per i sistemi SAP S/4HANA e NetWeaver ABAP eseguiti in Linux e Windows.

Gestione intelligente di SAP

Sia che si stia creando un nuovo sistema SAP o registrando un sistema esistente, Il Centro di Azure per le soluzioni SAP offre questi vantaggi:

  • Controlli di qualità, integrati con Azure Advisor, in modo da sapere quando le configurazioni dell'infrastruttura e del sistema operativo si discoscano dalle procedure consigliate e dagli standard documentati. Questi controlli possono risparmiare tempo durante la risoluzione dei problemi e aumentare la qualità del sistema richiedendo di agire prima che le deviazioni causino problemi.
  • Possibilità di visualizzare lo stato e l'integrità di SAP in più sistemi SAP da uno strumento centralizzato. Questa funzionalità consente di identificare rapidamente i problemi che interessano i sistemi SAP e i relativi componenti.
  • Possibilità di arrestare e avviare un sistema SAP direttamente da Azure.
  • Possibilità di visualizzare i costi post-distribuzione a livello di SID SAP.
  • Integrazione con Monitoraggio di Azure per soluzioni SAP. Questa integrazione fornisce il monitoraggio tecnico e consente di correlare i dati di telemetria del sistema SAP con i dati di telemetria del sistema operativo, del sistema DBMS e dell'infrastruttura di Azure sottostante.
  • Possibilità di eseguire ricerche tra i sistemi SAP in base a un SID usando Azure Resource Graph. Questa funzionalità semplifica l'individuazione delle risorse di Azure che fanno parte del panorama applicativo SAP. Resource Graph è un servizio di Azure che offre un'esplorazione efficiente delle risorse consentendo di eseguire query su larga scala tra sottoscrizioni.

Passaggi successivi

Esaminare le aree di progettazione seguenti per l'architettura dell'acceleratore di zona di destinazione di SAP in Azure: