Esplorare le zone di disponibilità

  • 7 minuti

Gli scenari di distribuzione descritti in precedenza si basano ampiamente sui set di disponibilità. In alcuni casi, questi scenari possono essere adattati all'uso delle zone di disponibilità di Azure. Ciò, tuttavia, comporta la necessità di tenere presenti alcune considerazioni aggiuntive e modifiche all'architettura.

Una zona di disponibilità di Azure è definita come: Le zone sono posizioni fisiche univoche 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. 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ù di decine di macchine virtuali. Si vuole ridurre al minimo la possibilità di distribuire macchine virtuali nello stesso server host. Si vuole inoltre che tali macchine virtuali all'interno della prossimità accettabile al livello del sistema di gestione del database mantengano la latenza di rete in una finestra accettabile.
  • Livello SAP ASCS/SCS che rappresenta un singolo punto di guasto nell'architettura SAP NetWeaver e S/4HANA. In genere, si osservano due macchine virtuali che si vuole coprire con un framework di failover. Pertanto, queste macchine virtuali devono essere allocate in diversi domini di errore e aggiornamento dell'infrastruttura.
  • Livello DBMS 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 diversi domini di errore e aggiornamento dell'infrastruttura. Le eccezioni sono le distribuzioni scale-out di SAP HANA in cui è possibile usare più di due macchine virtuali.

Ogni organizzazione ha requisiti univoci ed è necessario progettare le applicazioni in modo da soddisfare al meglio le esigenze aziendali complesse. La definizione di un contratto di servizio di destinazione consente di valutare se l'architettura soddisfa i requisiti aziendali. Alcuni aspetti da considerare:

  • Quali sono i requisiti di disponibilità?
  • Quanto tempo di inattività è accettabile?
  • Quanto costa un potenziale tempo di inattività all'azienda?
  • Quanto si deve investire per rendere l'applicazione a disponibilità elevata?
  • Quali sono i requisiti di backup dei dati?
  • Quali sono i requisiti di replica dei dati?
  • Quali sono i requisiti di monitoraggio?
  • L'applicazione ha specifici requisiti di latenza?

Considerazioni per decidere di usare le zone di disponibilità:

  • Non esistono garanzie relative alle distanze tra varie zone di disponibilità all'interno di un'area di Azure.

  • 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 in zone diverse in quanto 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, se distribuita in zone diverse, potrebbe non essere accettabile per i processi aziendali SAP. In questi casi, l'architettura di distribuzione deve essere diversa con un'architettura attiva/attiva per l'applicazione o attiva/passiva se la latenza di rete tra zone è troppo elevata.

  • Quando si decide dove usare le zone di disponibilità, basare la decisione sulla 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.
    • Differenza nella latenza di rete tra una macchina virtuale che esegue un'istanza della finestra di dialogo SAP nella zona con l'istanza 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 tra zone di disponibilità e si stabiliscono soluzioni di failover all'interno della 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.
  • Non è possibile distribuire set di disponibilità di Azure all'interno di una zona di disponibilità di Azure. Scegliere l'una o l'altra opzione 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 Load Balancer Standard di Azure.