Condividi tramite

Configurazioni del carico di lavoro SAP con le zone di disponibilità di Azure

  • Articolo

La distribuzione dei diversi livelli di architettura SAP in Azure zone di disponibilità è l'architettura consigliata per le distribuzioni di carichi di lavoro SAP in Azure. Una zona di disponibilità di Azure è definita come: "Posizioni fisiche univoche all'interno di un'area. Ogni zona è costituita da uno o più data center dotati di alimentazione, raffreddamento e rete indipendenti". Azure zone di disponibilità non sono disponibili in tutte le aree. Per le aree di Azure che forniscono zone di disponibilità, controllare la mappa dell'area di Azure. L'articolo elenca le aree che forniscono zone di disponibilità. La maggior parte delle aree di Azure che sono dotate di ospitare carichi di lavoro SAP di dimensioni maggiori fornisce zone di disponibilità. Le nuove aree di Azure forniscono zone di disponibilità dall'inizio. Alcune delle regioni più vecchie erano o sono in corso di aggiornamento con zone di disponibilità.

A partire dalla tipica architettura SAP NetWeaver o S/4HANA, è necessario proteggere tre livelli diversi:

  • Livello dell'applicazione SAP, che può essere una o più decine di Macchine virtuali (VM). Si vuole ridurre al minimo la possibilità di distribuire macchine virtuali nello stesso server host. Si vuole anche che tali macchine virtuali si trovino in una prossimità accettabile al livello del database per mantenere la latenza di rete in una finestra accettabile
  • Livello SAP ASCS/SCS che rappresenta un singolo punto di errore nell'architettura SAP NetWeaver e S/4HANA. In genere, si osservano due macchine virtuali che si vuole coprire con un framework di failover. Di conseguenza, queste macchine virtuali devono essere allocate in domini di errore dell'infrastruttura diversi
  • Livello di database SAP, che rappresenta anche un singolo punto di errore. Nei casi consueti, è costituito da due macchine virtuali coperte da un framework di failover. Pertanto, queste macchine virtuali devono essere allocate in domini di errore dell'infrastruttura diversi. Le eccezioni sono distribuzioni con scalabilità orizzontale di SAP HANA in cui è possibile usare più di due macchine virtuali

Le principali differenze tra la distribuzione delle macchine virtuali critiche tramite set di disponibilità o zone di disponibilità sono:

  • La distribuzione con un set di disponibilità consente di allineare le macchine virtuali all'interno del set in un'unica zona o data center (qualunque cosa si applica per l'area specifica). Di conseguenza, la distribuzione tramite il set di disponibilità non è protetta da problemi di alimentazione, raffreddamento o rete che influiscono sui data center della zona nel suo complesso. Con i set di disponibilità, non esiste anche un allineamento forzato tra una macchina virtuale e i relativi dischi. Significa che i dischi possono trovarsi in qualsiasi data center dell'area di Azure, indipendentemente dalla struttura di zona dell'area. Sul lato più, le macchine virtuali sono allineate ai domini di aggiornamento e di errore all'interno di tale zona o data center. In particolare per il livello sap ASCS o del database in cui si proteggono due macchine virtuali per ogni set di disponibilità, l'allineamento con i domini di errore impedisce che entrambe le macchine virtuali finisano nello stesso hardware host.
  • Durante la distribuzione di macchine virtuali tramite Azure zone di disponibilità e la scelta di zone diverse (massimo tre possibili), le macchine virtuali verranno distribuite tra le diverse posizioni fisiche e con questo aggiunge protezione da problemi di alimentazione, raffreddamento o rete che influiscono sui data center della zona nel suo complesso. Anche le macchine virtuali e i dischi correlati si trovano nella stessa zona di disponibilità. Tuttavia, quando si distribuiscono più macchine virtuali della stessa famiglia di macchine virtuali nella stessa zona di disponibilità, non esiste alcuna protezione da tali macchine virtuali che terminano nello stesso host o nello stesso dominio di errore. Di conseguenza, la distribuzione tramite zone di disponibilità è ideale per SAP ASCS e il livello di database in cui in genere vengono esaminate due macchine virtuali. Per il livello dell'applicazione SAP, che può essere drasticamente superiore a due macchine virtuali, potrebbe essere necessario eseguire il fallback a un modello di distribuzione diverso (vedere più avanti).

La motivazione di una distribuzione in Azure zone di disponibilità deve essere che, oltre a coprire l'errore di una singola macchina virtuale critica o la possibilità di ridurre i tempi di inattività per l'applicazione di patch software all'interno di un'infrastruttura critica, si vuole proteggere da problemi di infrastruttura più grandi che potrebbero influire sulla disponibilità di uno o più data center di Azure.

Come un'altra funzionalità di distribuzione con resilienza, Azure ha introdotto set di scalabilità di macchine virtuali con orchestrazione flessibile per il carico di lavoro SAP. Il set di scalabilità di macchine virtuali offre un raggruppamento logico di macchine virtuali gestite dalla piattaforma. L'orchestrazione flessibile del set di scalabilità di macchine virtuali offre la possibilità di creare il set di scalabilità all'interno di un'area o estenderlo tra le zone di disponibilità. Durante la creazione, il set di scalabilità flessibile all'interno di un'area con platformFaultDomainCount>1 (FD>1), le macchine virtuali distribuite nel set di scalabilità verranno distribuite in un numero specificato di domini di errore nella stessa area. D'altra parte, la creazione del set di scalabilità flessibile tra zone di disponibilità con platformFaultDomainCount=1 (FD=1) distribuirà le macchine virtuali tra zone diverse e il set di scalabilità distribuirà anche le macchine virtuali tra domini di errore diversi all'interno di ogni zona per un miglior sforzo. Per il carico di lavoro SAP è supportato solo un set di scalabilità flessibile con FD=1. Il vantaggio dell'uso di set di scalabilità flessibili con FD=1 per la distribuzione tra zone, invece della distribuzione tradizionale della zona di disponibilità consiste nel fatto che le macchine virtuali distribuite con il set di scalabilità verranno distribuite tra domini di errore diversi all'interno della zona in modo ottimale. Per altre informazioni, vedere la guida alla distribuzione del set di scalabilità flessibile per il carico di lavoro SAP.

Considerazioni sulla distribuzione in più zone di disponibilità

Quando si usano le zone di disponibilità, tenere presente quanto segue:

  • Altre informazioni su Azure zone di disponibilità sono disponibili nel documento Aree e zone di disponibilità.
  • La latenza di round trip di rete sperimentata non è necessariamente indicativa della distanza geografica reale dei data center che formano le diverse zone. La latenza del round trip di rete è influenzata anche dalle connessioni via cavo e dal routing dei cavi tra questi diversi data center.
  • Se si usa zone di disponibilità come soluzione di ripristino di emergenza a distanza ridotta, tenere presente che si sono verificati disastri naturali che causano danni diffusi in diverse regioni del mondo, tra cui danni pesanti e diffusi alle infrastrutture elettriche. Le distanze tra varie zone potrebbero non essere sempre sufficientemente grandi da compensare tali calamità naturali più grandi.
  • La latenza di rete tra le zone di disponibilità non è la stessa in tutte le aree di Azure. Anche all'interno di un'area di Azure, le latenze di rete tra le diverse zone possono variare. Anche se, nel peggiore dei casi, la replica sincrona a livello di database basata sulla replica di sistema HANA o SQL Server AlwaysOn funzionerà senza influire sulla scalabilità del carico di lavoro.
  • Nel decidere dove usare le zone di disponibilità, tenere conto della latenza di rete tra le zone. La latenza di rete svolge un ruolo importante in due aree:
    • Latenza tra le due istanze del database che devono avere una replica sincrona. In base a operazioni di grande successo dei sistemi NetWeaver e S/4HANA tra zone con latenze di rete più elevate (meno di 1,5 millisecondi), questa considerazione può essere trascurata
    • La differenza nella latenza di rete tra una macchina virtuale che esegue un'istanza della finestra di dialogo SAP nella zona con l'istanza del database attiva e una macchina virtuale simile in un'altra zona. Con l'aumentare di questa differenza, aumenta anche l'influenza sul tempo di esecuzione dei processi aziendali e dei processi batch, a seconda che vengano eseguiti nella zona con il database o in una zona diversa (vedere più avanti in questo articolo).
  • La latenza di rete con Azure zone di disponibilità, anche nelle zone più grandi, è sufficientemente bassa per l'esecuzione dei processi aziendali SAP. Finora sono stati illustrati solo alcuni casi eccezionali in cui i clienti hanno bisogno di colocare il livello dell'applicazione SAP e il livello di database in una singola colonna dorsale di rete del data center.

Quando si distribuiscono macchine virtuali di Azure in più zone di disponibilità e si implementano soluzioni di failover nella stessa area di Azure, si applicano alcune restrizioni:

  • È necessario usare Azure Managed Disks quando si distribuisce nelle zone di disponibilità di Azure.
  • Il mapping delle enumerazioni di zona con le zone fisiche è fisso per ogni sottoscrizione di Azure. Se si usano sottoscrizioni diverse per distribuire i sistemi SAP, è necessario definire le zone ideali per ogni sottoscrizione. Se si vuole confrontare il mapping logico delle diverse sottoscrizioni, prendere in considerazione lo script Avzone-Mapping.
  • Non è possibile distribuire i set di disponibilità di Azure all'interno di una zona di disponibilità di Azure a meno che non si usi il gruppo di posizionamento di prossimità di Azure. Il modo in cui è possibile distribuire il livello di database SAP e i servizi centrali tra zone e allo stesso tempo distribuire il livello dell'applicazione SAP usando i set di disponibilità e ottenere comunque una stretta prossimità delle macchine virtuali è documentato nell'articolo Gruppi di posizionamento di prossimità di Azure per una latenza di rete ottimale con le applicazioni SAP. Se non si usano gruppi di posizionamento di prossimità di Azure, è necessario scegliere uno o l'altro come framework di distribuzione per le macchine virtuali.
  • Non è possibile usare un'istanza di Azure Load Balancer Basic per creare soluzioni cluster di failover basate su Windows Server Failover Clustering o Linux Pacemaker. È invece necessario usare lo SKU di Azure Load Balancer Standard.
  • È necessario distribuire la versione di zona del gateway ExpressRoute, dei Gateway VPN e degli indirizzi IP pubblici standard per ottenere la protezione di zona desiderata.

Combinazione ideale delle zone di disponibilità

A meno che non si configuri l'assegnazione del processo aziendale con funzionalità SAP come gruppi di accesso, gruppi di server RFC, gruppi di server Batch e processi aziendali simili, è possibile eseguire processi aziendali nelle diverse istanze dell'applicazione nel livello dell'applicazione SAP. L'effetto collaterale di questo fatto è che i processi batch possono essere eseguiti da qualsiasi istanza dell'applicazione SAP indipendentemente dal fatto che questi vengano eseguiti nella stessa zona con l'istanza del database attiva o meno. Se la differenza nella latenza di rete tra le zone di differenza è ridotta rispetto alla latenza di rete all'interno di una zona, la differenza nei tempi di esecuzione dei processi batch potrebbe non essere significativa. Tuttavia, maggiore è la differenza di latenza di rete all'interno di una zona, rispetto al traffico di rete tra zone, il tempo di esecuzione dei processi batch può essere influenzato maggiormente se il processo è stato eseguito in una zona in cui l'istanza del database non è attiva. È su di te come cliente decidere quali differenze accettabili in fase di esecuzione sono. E con ciò che la latenza di rete tollerabile per il traffico tra zone è per il carico di lavoro. Dal punto di vista tecnico, le latenze di rete tra Azure zone di disponibilità all'interno di un'area di Azure funzionano per l'architettura di NetWeaver, S/4HANA o altre applicazioni SAP. È anche disponibile come cliente potenzialmente per attenuare tali differenze usando i concetti SAP di gruppi di accesso, gruppi di server RFC, gruppi di server Batch e simili quando si decide per uno dei concetti di distribuzione introdotti in questo articolo.

Se si vuole distribuire un sistema SAP NetWeaver o S/4HANA tra zone, è possibile distribuire due modelli di architettura:

  • Attivo/attivo: la coppia di macchine virtuali che eseguono ASCS/SCS e la coppia di macchine virtuali che eseguono il livello di database vengono distribuite tra due zone. Le macchine virtuali che eseguono il livello applicazione SAP vengono distribuite in numeri pari nelle stesse due zone. Se viene eseguito il failover di un database o di una macchina virtuale ASCS/SCS, è possibile eseguire il rollback di alcune delle transazioni aperte e attive. Ma gli utenti rimangono connessi. Non importa in quale delle zone viene eseguita la macchina virtuale del database attiva e le istanze dell'applicazione. Questa architettura è l'architettura preferita da distribuire tra le zone. Nei casi in cui le latenze di rete tra zone causano differenze maggiori durante l'esecuzione di processi aziendali, è possibile usare funzionalità come gruppi di accesso SAP, gruppi di server RFC, gruppi di server Batch e simili a instradare l'esecuzione dei processi aziendali a istanze di dialogo specifiche che si trovano nella stessa zona con l'istanza del database attiva
  • Attivo/passivo: la coppia di macchine virtuali che eseguono ASCS/SCS e la coppia di macchine virtuali che eseguono il livello di database vengono distribuite tra due zone. Le macchine virtuali che eseguono il livello applicazione SAP vengono distribuite in una delle zone di disponibilità. Il livello applicazione viene eseguito nella stessa zona dell'istanza di database e ASCS/SCS attiva. È possibile usare questa architettura di distribuzione se si ritiene che la latenza di rete tra le diverse zone sia troppo elevata. Con ciò che causa differenze intollerabili nel runtime dei processi aziendali. In alternativa, se si vogliono usare le distribuzioni della zona di disponibilità come distribuzioni di ripristino di emergenza a breve distanza. le zone. Se un asCS/SCS o una macchina virtuale di database esegue il failover nella zona secondaria, potrebbe verificarsi una latenza di rete più elevata e con tale riduzione della velocità effettiva. È anche necessario eseguire il failback della macchina virtuale di cui è stato eseguito il failover prima possibile per tornare ai livelli di velocità effettiva precedenti. Se si verifica un'interruzione di zona, è necessario eseguire il failover del livello applicazione nella zona secondaria. Attività che gli utenti riscontrano come arresto completo del sistema.

Quindi, prima di decidere come usare zone di disponibilità, è necessario determinare:

  • La latenza di rete tra le tre zone di un'area di Azure, Conoscere la latenza di rete tra le zone di un'area consente di scegliere le zone con la latenza di rete minima nel traffico di rete tra zone.
  • La differenza tra la latenza tra le macchine virtuali all'interno di una delle zone scelte e la latenza di rete tra le due zone scelte.
  • Se i tipi di macchina virtuale che è necessario distribuire sono disponibili nelle due zone scelte. Con alcuni SKU di macchine virtuali, è possibile che si verifichino situazioni in cui alcuni SKU sono disponibili solo in due delle tre zone.

Latenza di rete tra e nelle zone

Per determinare qual è la latenza tra le varie zone, è necessario:

  • Distribuire lo SKU della macchina virtuale da usare per l'istanza del database in tutte e tre le zone. Assicurarsi che Rete accelerata di Azure sia abilitata durante l'esecuzione di questa misurazione. La rete accelerata è l'impostazione predefinita da alcuni anni. Tuttavia, verificare se è abilitato e funzionante
  • Dopo aver individuato le due zone con la minore latenza di rete, distribuire altre tre macchine virtuali dello SKU che si vuole usare come macchina virtuale del livello dell'applicazione nelle tre zone di disponibilità. Misurare la latenza di rete rispetto alle due macchine virtuali di database nelle due zone selezionate.
  • Usare niping come strumento di misurazione. lo strumento di SAP descritto nelle note di supporto SAP #500235 e #1100926. Considerare la classificazione della latenza di rete nella nota SAP #1100926 come indicazioni approssimative. Le latenze di rete superiori a 0,7 millisecondi non significano che il sistema non funzionerà tecnicamente o che i processi aziendali non soddisfino i singoli contratti di servizio. La nota non è destinata a indicare ciò che è supportato o non supportato da SAP e/o Microsoft. Prestare attenzione ai comandi documentati per le misurazioni della latenza. Poiché ping non funziona nei percorsi del codice di Rete accelerata di Azure, non è consigliabile usarlo.

Non è necessario eseguire questi test manualmente. È possibile trovare un test di latenza della zona di disponibilità della procedura di PowerShell che automatizza i test di latenza descritti.

In base alle misurazioni e alla disponibilità degli SKU di macchine virtuali nelle zone di disponibilità, è necessario prendere alcune decisioni:

  • Definire le zone ideali per il livello del database.
  • Stabilire se si vuole distribuire il livello dell'applicazione SAP attivo su una, due o tutte e tre le zone, in base alle differenze della latenza di rete all'interno di una zona o tra più zone.
  • Stabilire se si vuole distribuire una configurazione attiva/passiva o una configurazione attiva/attiva dal punto di vista dell'applicazione. Queste configurazioni sono illustrate più avanti in questo articolo.

Importante

Le misurazioni e le decisioni sono valide per la sottoscrizione di Azure in uso quando si eseguono le misurazioni. Se si usa un'altra sottoscrizione di Azure, il mapping delle zone enumerate potrebbe essere diverso per un'altra sottoscrizione di Azure. Di conseguenza, è necessario ripetere le misurazioni o scoprire il mapping della nuova sottoscrizione realetve alla sottoscrizione precedente lo strumento Avzone-Mapping script.

Importante

È previsto che le misurazioni descritte in precedenza forniscano risultati diversi in ogni area di Azure che supporta zone di disponibilità. Anche se i requisiti di latenza di rete non cambiano, può essere necessario adottare strategie di distribuzione diverse in diverse aree di Azure, perché la latenza di rete tra le zone può essere diversa. In alcune aree di Azure la latenza di rete fra le tre zone può essere notevolmente diversa. In altre aree la latenza di rete fra le tre zone può essere più uniforme. L'attestazione che esiste sempre una latenza di rete compresa tra 1 e 2 millisecondi non è corretta. La latenza di rete tra le zone di disponibilità nelle aree di Azure non può essere generalizzata.

Distribuzione attiva/attiva

Questa architettura di distribuzione viene chiamata attiva/attiva, perché i server applicazioni SAP attivi vengono distribuiti su due o tre zone. L'istanza di SAP Central Services che usa la replica di accodamento viene distribuita tra due zone. Lo stesso vale per il livello del database, che viene distribuito nelle stesse zone del servizio centrale SAP. Quando si considera questa configurazione, è necessario trovare i due zone di disponibilità nell'area che offrono latenza di rete tra zone accettabile per il carico di lavoro. Si vuole anche assicurarsi che il delta tra latenza di rete all'interno delle zone selezionate e la latenza di rete tra zone sia accettabile per il carico di lavoro.

Uno schema semplificato di una distribuzione attiva/attiva su due zone può essere simile al seguente:

Distribuzione attiva/attiva in una zona

A questa configurazione si applicano le considerazioni seguenti:

  • Non usando il gruppo di posizionamento di prossimità di Azure, azure zone di disponibilità viene considerato come domini di errore per tutte le macchine virtuali perché i set di disponibilità non possono essere distribuiti in Azure zone di disponibilità.
  • Se si vogliono combinare distribuzioni di zona per il livello di database e i servizi centrali, ma si vuole usare i set di disponibilità di Azure per il livello applicazione, è necessario usare i gruppi di prossimità di Azure come descritto nell'articolo Gruppi di posizionamento di prossimità di Azure per una latenza di rete ottimale con le applicazioni SAP.
  • Per i servizi di bilanciamento del carico dei cluster di failover di SAP Central Services e del livello di database, è necessario usare Lo SKU Standard di Azure Load Balancer. Load Balancer Basic non funziona tra le zone.
  • È necessario distribuire la versione di zona del gateway ExpressRoute, dei Gateway VPN e degli indirizzi IP pubblici standard per ottenere la protezione di zona desiderata.
  • La rete virtuale di Azure distribuita per ospitare il sistema SAP, unita alle relative subnet, è estesa tra le zone. Non è necessario separare le reti virtuali e le subnet per ogni zona.
  • Per tutte le macchine virtuali distribuite, è necessario usare Azure Managed Disks. I dischi non gestiti non sono supportati per le distribuzioni nelle zone.
  • L'archiviazione SSD Premium di Azure v2, l'archiviazione Ultra SSD o Azure NetApp Files non supporta alcuna replica sincrona di archiviazione tra zone. Per le distribuzioni di database, ci si basa sui metodi di database per replicare i dati tra zone.
  • Ssd Premium v1 che supporta la replica a livello di zona sincrono in zone di disponibilità non è stata testata con il carico di lavoro del database SAP. Di conseguenza, la replica sincrona di zona di Azure Premium SSD v1 deve essere considerata non supportata per i carichi di lavoro del database SAP.
  • Per le condivisioni SMB e NFS basate su File Premium di Azure, viene offerta la ridondanza di zona con replica sincrona. Controllare questo documento per la disponibilità dell'archiviazione con ridondanza della zona per File Premium di Azure nell'area in cui si vuole eseguire la distribuzione. L'utilizzo di condivisioni NFS e SMB replicate a livello di zona è completamente supportato con distribuzioni a livello di applicazione SAP e cluster di failover a disponibilità elevata per i servizi centrali NetWeaver o S/4HANA. I documenti che riguardano questi casi sono:
  • La terza zona viene usata per ospitare il dispositivo SBD se si compila un cluster SUSE Linux Pacemaker e si usano dispositivi SBD anziché l'agente di Isolamento di Azure. Oppure per più istanze dell'applicazione.
  • Per ottenere la coerenza in fase di esecuzione per i processi aziendali critici, è possibile provare a indirizzare determinati processi batch e utenti alle istanze dell'applicazione che si trovano nella zona con l'istanza del database attiva usando gruppi di server batch SAP, gruppi di accesso SAP o gruppi RFC. In un processo failover a livello di zona, tuttavia, è necessario spostare manualmente questi gruppi in istanze in esecuzione su macchine virtuali nella stessa zona della macchina virtuale del database attivo.
  • Può essere necessario distribuire le istanze di dialogo inattive in ognuna delle zone.

Importante

In questo scenario attivo/attivo si applicano addebiti per il traffico tra zone. Controllare i dettagli sui prezzi della larghezza di banda del documento. Il trasferimento dei dati tra il livello dell'applicazione SAP e il livello del database SAP è piuttosto intensivo. Pertanto, lo scenario attivo/attivo può contribuire ad aumentare i costi.

Distribuzione attiva/passiva

Se non è possibile trovare una configurazione che attenua il potenziale delta in fase di esecuzione dei processi aziendali SAP o se si vuole distribuire una configurazione di ripristino di emergenza a breve distanza, è possibile distribuire un'architettura con un carattere attivo/passivo dal punto di vista del livello applicazione SAP. Si definisce una zona attiva , ovvero la zona in cui si distribuisce il livello applicazione completo e in cui si tenta di eseguire sia l'istanza di database attiva che l'istanza di SAP Central Services. Con una configurazione di questo tipo, è necessario assicurarsi di non avere variazioni di runtime estreme, a seconda che un processo venga eseguito nella zona con l'istanza del database attiva o meno, nelle transazioni aziendali e nei processi batch.

Il layout di base di questa architettura è simile al seguente:

Distribuzione attiva/passiva in una zona

A questa configurazione si applicano le considerazioni seguenti:

  • I set di disponibilità non possono essere distribuiti nelle zone di disponibilità di Azure. Per attenuare i problemi, è possibile usare i gruppi di posizionamento di prossimità di Azure, come documentato nell'articolo Gruppi di posizionamento di prossimità di Azure per una latenza di rete ottimale con le applicazioni SAP.
  • Quando si usa questa architettura, è necessario monitorare attentamente lo stato e provare a mantenere l'istanza del database attiva e le istanze di SAP Central Services nella stessa zona del livello applicazione distribuito. Se si è verificato un failover di SAP Central Service o dell'istanza del database, assicurarsi di poter eseguire manualmente il failback nella zona con il livello applicazione SAP distribuito il più rapidamente possibile.
  • Per i servizi di bilanciamento del carico dei cluster di failover di SAP Central Services e del livello di database, è necessario usare Lo SKU Standard di Azure Load Balancer. Load Balancer Basic non funziona tra le zone.
  • È necessario distribuire la versione di zona del gateway ExpressRoute, dei Gateway VPN e degli indirizzi IP pubblici standard per ottenere la protezione di zona desiderata.
  • La rete virtuale di Azure distribuita per ospitare il sistema SAP, unita alle relative subnet, è estesa tra le zone. Non è necessario separare le reti virtuali per ogni zona.
  • Per tutte le macchine virtuali distribuite, è necessario usare Azure Managed Disks. I dischi non gestiti non sono supportati per le distribuzioni nelle zone.
  • L'archiviazione SSD Premium di Azure v2, l'archiviazione Ultra SSD o Azure NetApp Files non supporta alcuna replica sincrona di archiviazione tra zone. Per le distribuzioni di database, ci si basa sui metodi di database per replicare i dati tra zone.
  • Ssd Premium v1 che supporta la replica a livello di zona sincrono in zone di disponibilità non è stata testata con il carico di lavoro del database SAP. Di conseguenza, la replica sincrona a livello di zona configurabile di Ssd Premium di Azure v1 deve essere considerata non supportata per i carichi di lavoro del database SAP.
  • Per le condivisioni SMB e NFS basate su File Premium di Azure, viene offerta la ridondanza di zona con replica sincrona. Controllare questo documento per la disponibilità dell'archiviazione con ridondanza della zona per File Premium di Azure nell'area in cui si vuole eseguire la distribuzione. L'utilizzo di condivisioni NFS e SMB replicate a livello di zona è completamente supportato con distribuzioni a livello di applicazione SAP e cluster di failover a disponibilità elevata per i servizi centrali NetWeaver o S/4HANA. I documenti che riguardano questi casi sono:
  • La terza zona viene usata per ospitare il dispositivo SBD se si compila un cluster SUSE Linux Pacemaker e si usano dispositivi SBD anziché l'agente di Isolamento di Azure. Oppure per altre istanze dell'applicazione.
  • È consigliabile distribuire macchine virtuali inattivi nella zona passiva (dal punto di vista del database) in modo da poter avviare le risorse dell'applicazione in caso di errore di zona. Un'altra possibilità potrebbe essere usare Azure Site Recovery, che è in grado di replicare macchine virtuali attive in macchine virtuali inattiva tra zone.
  • È consigliabile investire nell'automazione che consente di avviare automaticamente il livello dell'applicazione SAP nella seconda zona in caso di interruzione della zona.

Configurazione combinata per disponibilità elevata e ripristino di emergenza

Microsoft non condivide alcuna informazione sulla distanza geografica fra le strutture che ospitano diverse zone di disponibilità in un'area di Azure. Tuttavia, alcuni clienti usano zone per una configurazione combinata di disponibilità elevata e ripristino di emergenza (breve distanza) che promette un obiettivo del punto di ripristino (RPO) pari a zero. Un RPO pari a zero significa che non è consigliabile perdere le transazioni di database di cui è stato eseguito il commit anche nei casi di ripristino di emergenza.

Nota

Se si usa zone di disponibilità come soluzione di ripristino di emergenza a distanza ridotta, tenere presente che abbiamo riscontrato calamità naturali che causano danni diffusi nelle regioni diferenti del mondo, tra cui danni pesanti e diffusi alle infrastrutture elettriche. Le distanze tra varie zone potrebbero non essere sempre sufficientemente grandi da compensare tali calamità naturali più grandi.

Ecco un esempio di una configurazione di questo tipo:

Disponibilità elevata e ripristino di emergenza combinati nelle zone

A questa configurazione si applicano le considerazioni seguenti:

  • Si presuppone che esista una distanza significativa tra le strutture che ospitano una zona di disponibilità. Oppure si è costretti a rimanere all'interno di una determinata area di Azure. I set di disponibilità non possono essere distribuiti nelle zone di disponibilità di Azure. Per compensare questo problema, è possibile usare i gruppi di posizionamento di prossimità di Azure, come documentato nell'articolo Gruppi di posizionamento di prossimità di Azure per una latenza di rete ottimale con le applicazioni SAP.
  • Quando si usa questa architettura, è necessario monitorare attentamente lo stato e provare a mantenere l'istanza del database attiva e le istanze di SAP Central Services nella stessa zona del livello applicazione distribuito. Se si è verificato un failover di SAP Central Service o dell'istanza del database, assicurarsi di poter eseguire manualmente il failback nella zona con il livello applicazione SAP distribuito il più rapidamente possibile.
  • Le istanze dell'applicazione di produzione devono essere preinstallate nelle macchine virtuali che eseguono le istanze dell'applicazione di controllo di qualità attive.
  • In un caso di errore di zona arrestare le istanze dell'applicazione qa e avviare invece le istanze di produzione. È necessario usare nomi virtuali per le istanze dell'applicazione per far funzionare questo meccanismo.
  • Per i servizi di bilanciamento del carico dei cluster di failover di SAP Central Services e del livello di database, è necessario usare Lo SKU Standard di Azure Load Balancer. Load Balancer Basic non funziona tra le zone.
  • È necessario distribuire la versione di zona del gateway ExpressRoute, dei Gateway VPN e degli indirizzi IP pubblici standard per ottenere la protezione di zona desiderata.
  • La rete virtuale di Azure distribuita per ospitare il sistema SAP, unita alle relative subnet, è estesa tra le zone. Non è necessario separare le reti virtuali per ogni zona.
  • Per tutte le macchine virtuali distribuite, è necessario usare Azure Managed Disks. I dischi non gestiti non sono supportati per le distribuzioni nelle zone.
  • L'archiviazione SSD Premium di Azure v2, l'archiviazione Ultra SSD o Azure NetApp Files non supporta alcuna replica sincrona di archiviazione tra zone. Per le distribuzioni di database, ci si basa sui metodi di database per replicare i dati tra zone.
  • Ssd Premium v1 che supporta la replica a livello di zona sincrono in zone di disponibilità non è stata testata con il carico di lavoro del database SAP. Di conseguenza, la replica sincrona a livello di zona configurabile di Ssd Premium di Azure v1 deve essere considerata non supportata per i carichi di lavoro del database SAP.
  • Per le condivisioni SMB e NFS basate su File Premium di Azure, viene offerta la ridondanza di zona con replica sincrona. Controllare questo documento per la disponibilità dell'archiviazione con ridondanza della zona per File Premium di Azure nell'area in cui si vuole eseguire la distribuzione. L'utilizzo di condivisioni NFS e SMB replicate a livello di zona è completamente supportato con distribuzioni a livello di applicazione SAP e cluster di failover a disponibilità elevata per i servizi centrali NetWeaver o S/4HANA. I documenti che riguardano questi casi sono:
  • La terza zona viene usata per ospitare il dispositivo SBD se si compila un cluster SUSE Linux Pacemaker e si usano dispositivi SBD anziché l'agente di Isolamento di Azure.

Passaggi successivi

Ecco alcuni passaggi da eseguire successivamente per la distribuzione in più zone di disponibilità di Azure: