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

  • Articolo

Inoltre, alla distribuzione dei diversi livelli di architettura SAP nei set di disponibilità di Azure, Azure zone di disponibilità può essere usato anche per le distribuzioni dei carichi di lavoro SAP. 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. Questa mappa ti mostrerà quali aree forniscono o vengono annunciate per fornire zone di disponibilità.

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

  • Livello di applicazione SAP, che può essere costituito da una fino a poche decine di macchine virtuali. 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 DBMS 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 DBMS SAP, che rappresenta 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 dataceter della zona nel suo complesso. 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 DBMS in cui vengono protette 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 dataceter della zona nel suo complesso. 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 il livello SAP ASCS e DBMS, in cui in genere vengono esaminate due macchine virtuali ognuna. Per il livello 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 tra il 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:

  • La latenza massima del round trip di rete tra Azure zone di disponibilità è indicata 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.
  • Le zone di disponibilità non sono una soluzione di ripristino di emergenza ideale. In caso di calamità naturali gravi che causano danni molto estesi in alcune aree del mondo, inclusi danni notevoli alla rete elettrica, la distanza tra diverse zone potrebbe non essere sufficientemente estesa da costituire una soluzione di ripristino di emergenza adeguata.
  • La latenza di rete tra le zone di disponibilità non è la stessa in tutte le aree di Azure. In alcuni casi, è possibile distribuire ed eseguire il livello dell'applicazione SAP su zone diverse, perché la latenza di rete da una zona alla macchina virtuale DBMS attiva è accettabile. In alcune aree di Azure, tuttavia, la latenza tra la macchina virtuale DBMS attiva e l'istanza dell'applicazione SAP, distribuite in zone diverse, può non essere sufficiente per i processi aziendali SAP. In questi casi, l'architettura di distribuzione deve essere diversa, con un'architettura attiva/attiva per l'applicazione o un'architettura attiva/passiva in cui la latenza di rete tra zone è troppo elevata.
  • 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 di DBMS per le quali è necessario configurare la replica sincrona. Maggiore sarà la latenza di rete, maggiore sarà l'impatto sulla scalabilità del carico di lavoro.
    • La differenza nella latenza di rete tra una macchina virtuale che esegue un'istanza di dialogo SAP nella stessa zona dell'istanza del DBMS attiva e una macchina virtuale simile in un'altra zona. Maggiore sarà questa differenza, più alto sarà l'impatto sul tempo di esecuzione dei processi aziendali e dei processi batch, a seconda che siano eseguiti nella stessa zona del sistema DBMS o in una zona diversa.

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 DBMS 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.

Combinazione ideale delle zone di disponibilità

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 DBMS vengono distribuite in due zone. Il numero di macchine virtuali che eseguono il livello applicazione SAP viene distribuito in numeri pari nelle stesse due zone. Se viene eseguito il failover di una macchina virtuale DBMS o 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 DBMS attiva e le istanze dell'applicazione. Questa architettura è l'architettura preferita da distribuire tra le zone.
  • Attivo/passivo: la coppia di macchine virtuali che eseguono ASCS/SCS e la coppia di macchine virtuali che eseguono il livello DBMS vengono distribuite in due zone. Le macchine virtuali che eseguono il livello applicazione SAP vengono distribuito in una delle zone di disponibilità. Il livello applicazione viene eseguito nella stessa zona dell'istanza ASCS/SCS e DBMS attiva. Questa architettura di distribuzione viene usata se la latenza di rete tra le diverse zone è troppo elevata per eseguire il livello dell'applicazione distribuito tra le zone. Al contrario, il livello dell'applicazione SAP deve essere eseguito nella stessa zona dell'istanza DI ASCS/SCS e/o DBMS attiva. Se viene eseguito il failover di una macchina virtuale ASCS/SCS o DBMS nella zona secondaria, è possibile che si verifichi 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. In alcune aree di Azure questa architettura è l'unica architettura praticabile quando si vuole usare zone di disponibilità. Se non è possibile accettare il potenziale impatto di un failover di ASCS/SCS o DBMS nella zona secondaria, potrebbe essere preferibile rimanere con le distribuzioni del set di disponibilità

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 di macchina virtuale che si vuole usare per l'istanza del DBMS 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 per le due macchine virtuali di DBMS nelle due zone DBMS selezionate.
  • Usare niping come strumento di misurazione. lo strumento di SAP descritto nelle note di supporto SAP #500235 e #1100926. 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 DBMS.
  • 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.

Nel prendere queste decisioni, tenere presenti anche le raccomandazioni per la latenza di rete di SAP documentate nella nota SAP #1100926.

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 indicate in precedenza restituiscano risultati diversi in ogni area di Azure che supporta le 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 verrà distribuita tra due zone. Lo stesso vale per il livello DBMS, che verrà distribuito tra le stesse zone di SAP Central Services. Quando si considera questa configurazione, è necessario trovare le due zone di disponibilità nell'area di appartenenza che offrono una latenza di rete tra zone accettabile per il carico di lavoro e per la replica DBMS sincrona. È anche opportuno assicurarsi che la differenza tra la latenza di rete all'interno delle zone selezionate e tra le zone non sia eccessiva.

La natura dell'architettura SAP è che, a meno che non venga configurata in modo diverso, gli utenti e i processi batch possono essere eseguiti nelle diverse istanze dell'applicazione. L'effetto collaterale di questo fatto con la distribuzione attiva/attiva è che i processi batch possono essere eseguiti da qualsiasi istanza dell'applicazione SAP indipendentemente dal fatto che questi vengano eseguiti nella stessa zona con DBMS attivo 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 di più se il processo è stato eseguito in una zona in cui l'istanza DBMS 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.

Le aree di Azure in cui una distribuzione attiva/attiva di questo tipo possono essere possibili senza differenze significative in fase di esecuzione e velocità effettiva all'interno del livello dell'applicazione distribuito in diversi zone di disponibilità, ad esempio:

  • Australia orientale (due delle tre zone)
  • Brasile meridionale (tutte e tre le zone)
  • India centrale (tutte e tre le zone)
  • Stati Uniti centrali (tutte e tre le zone)
  • Asia orientale (tutte e tre le zone)
  • Stati Uniti orientali (due delle tre zone)
  • Stati Uniti orientali 2 (tutte e tre le zone)
  • Germania centro-occidentale (tutte e tre le zone)
  • Israele centrale (tutte e tre le zone)
  • Italia settentrionale (due delle tre zone)
  • Corea centrale (tutte e tre le zone)
  • Polonia centrale (tutte e tre le zone)
  • Qatar Centrale (tutte e tre le zone)
  • Europa settentrionale (tutte e tre le zone)
  • Norvegia orientale (due delle tre zone)
  • Sudafrica settentrionale (due dei tre)
  • Stati Uniti centro-meridionali (tutte e tre le zone)
  • Asia sud-orientale (tutte e tre le zone)
  • Svezia centrale (tutte e tre le zone)
  • Svizzera settentrionale (tutte e tre le zone)
  • Emirati Arabi Uniti settentrionali (tutte e tre le zone)
  • Regno Unito meridionale (due delle tre zone)
  • Europa occidentale (due delle tre zone)
  • Stati Uniti occidentali2 (tutte e tre le zone)
  • Stati Uniti occidentali3 (tutte e tre le zone)

L'elenco di aree fornito non consente ai clienti di testare il carico di lavoro per decidere se è possibile un'architettura di distribuzione attiva/attiva.

Le aree di Azure in cui l'architettura di distribuzione SAP attiva/attiva tra zone potrebbe non essere possibile, ad esempio:

  • Canada centrale
  • Francia centrale
  • Giappone orientale

Anche se per il carico di lavoro individuale, potrebbe funzionare. Pertanto, è necessario testare prima di decidere per un'architettura. Azure lavora costantemente per migliorare la qualità e la latenza delle reti. Le misurazioni condotte anni fa potrebbero non riflettere più le condizioni correnti.

A seconda di ciò che si è disposti a tollerare in caso di differenze di runtime, anche altre aree non elencate potrebbero essere qualificate.

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

Active/Active zone deployment

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 DBMS 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 per i cluster di failover di SAP Central Services e per il livello DBMS, è necessario usare lo SKU di Azure Load Balancer Standard. Load Balancer Basic non funziona tra zone.
  • 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.
  • Azure Archiviazione Premium, Archiviazione ULTRA SSD o ANF non supportano alcun tipo di replica di archiviazione tra zone. Per le distribuzioni DBMS, ci si basa sui metodi di database per replicare i dati tra zone
  • 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 SU edizione Standard Linux Pacemaker e si usano dispositivi SBD invece dell'agente di Isolamento di Azure. Oppure per più istanze dell'applicazione.
  • Per ottenere coerenza in fase di esecuzione per i processi aziendali critici, è possibile provare a indirizzare determinati processi batch e utenti a istanze dell'applicazione nella stessa zona dell'istanza DBMS attiva usando gruppi di server batch, i gruppi di accesso SAP o i 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 tra il livello dell'applicazione SAP e il livello SAP DBMS è a uso piuttosto intensivo di dati. Pertanto, lo scenario attivo/attivo può contribuire ad aumentare i costi.

Distribuzione attiva/passiva

Se non si riesce a trovare una differenza accettabile tra la latenza di rete all'interno del traffico di rete di una zona e tra zone, è possibile distribuire un'architettura attiva/passiva dal punto di vista del livello dell'applicazione SAP. Occorre definire una zona attiva, che è la zona in cui si distribuisce il livello dell'applicazione completo e in cui si tenta di eseguire sia l'istanza DBMS attiva che l'istanza di SAP Central Services. Con questa configurazione, è necessario assicurarsi di non avere variazioni estreme a livello di tempi di esecuzione, a seconda che un processo venga eseguito o meno nella stessa zona dell'istanza DBMS attiva, per le transazioni aziendali e i processi batch.

Le aree di Azure in cui questo tipo di architettura di distribuzione tra zone diverse può essere preferibile sono:

  • Canada centrale
  • Francia centrale
  • Giappone orientale
  • Norvegia orientale
  • Sudafrica settentrionale

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

Active/Passive zone deployment

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 le istanze di DBMS e di SAP Central Services attive nella stessa zona del livello dell'applicazione distribuita. Se si è verificato un failover del servizio centrale SAP o dell'istanza DBMS, 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 per i cluster di failover di SAP Central Services e per il livello DBMS, è necessario usare lo SKU di Azure Load Balancer Standard. Load Balancer Basic non funziona tra zone.
  • 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.
  • Azure Archiviazione Premium, Archiviazione ULTRA SSD o ANF non supportano alcun tipo di replica di archiviazione tra zone. Per le distribuzioni DBMS, ci si basa sui metodi di database per replicare i dati tra zone
  • 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 SU edizione Standard Linux Pacemaker e si usano dispositivi SBD invece dell'agente di Isolamento di Azure. Oppure per altre istanze dell'applicazione.
  • È consigliabile distribuire macchine virtuali inattivi nella zona passiva (dal punto di vista DBMS) 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. Nonostante ciò, alcuni clienti usano le zone per una configurazione di disponibilità elevata e ripristino di emergenza combinata che promette un obiettivo del punto di ripristino (RPO, Recovery Point Objective) 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

È consigliabile usare una configurazione simile alla seguente solo in determinate circostanze. È ad esempio possibile usarla quando i dati non possono essere spostati fuori dall'area di Azure per motivi di sicurezza o conformità.

Ecco un esempio di una configurazione di questo tipo:

Combined high-availability DR in zones

A questa configurazione si applicano le considerazioni seguenti:

  • Si presuppone che esista una distanza significativa tra le strutture che ospitano una zona di disponibilità, in caso contrario è obbligatorio 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 le istanze di DBMS e di SAP Central Services attive nella stessa zona del livello dell'applicazione distribuita. Se si è verificato un failover del servizio centrale SAP o dell'istanza DBMS, 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 per i cluster di failover di SAP Central Services e per il livello DBMS, è necessario usare lo SKU di Azure Load Balancer Standard. Load Balancer Basic non funziona tra zone.
  • 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.
  • Azure Archiviazione Premium, Archiviazione ULTRA SSD o ANF non supportano alcun tipo di replica di archiviazione tra zone. Per le distribuzioni DBMS, ci si basa sui metodi di database per replicare i dati tra zone
  • 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 SU edizione Standard Linux Pacemaker e si usano dispositivi SBD invece dell'agente di Isolamento di Azure.

Passaggi successivi

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