Esplorare lo scenario di distribuzione Attivo/Attivo

  • 7 minuti

L'architettura di distribuzione viene detta attiva/attiva, perché i server applicazioni SAP attivi vengono distribuiti tra due o tre zone. L'istanza di SAP Central Services che utilizza la replica di enqueue è distribuita tra due zone. Lo stesso vale per il livello DBMS, che viene distribuito tra le medesime zone del servizio centrale SAP.

Quando si considera la configurazione attiva/attiva, è 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 sia ridotta. Il motivo è che occorre evitare variazioni estese nei tempi di esecuzione dei processi aziendali o dei processi batch, a seconda che un processo venga eseguito all'interno della stessa zona del server DBMS o tra zone diverse. La latenza ridotta riduce la variazione del tempo di esecuzione del processo batch tra le zone.

Considerare il layout di base dell'architettura attiva/attiva:

Diagramma che mostra la distribuzione attiva/attiva nelle zone.

A questa configurazione si applicano le considerazioni seguenti:

  • Non usando il gruppo di posizionamento di prossimità, le zone di disponibilità di Azure vengono considerate domini di errore per tutte le VM, perché i set di disponibilità non possono essere distribuiti nelle zone di disponibilità di Azure.
  • Se si vogliono combinare distribuzioni a livello di zona per il livello DBMS e i servizi centrali, ma si vogliono usare i set di disponibilità di Azure per il livello applicazione, è necessario usare i gruppi di prossimità di Azure.
  • 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. Il livello Basic di Load Balancer 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.
  • L'archiviazione Premium di Azure, l'archiviazione Ultra SSD e ANF non supportano alcun tipo di replica dell'archiviazione tra le 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 Azure Premium Files, viene offerta la ridondanza zonale con replica sincrona. L'utilizzo di condivisioni NFS e SMB replicate a livello di zona è pienamente supportato con distribuzioni a livello di applicazione SAP e cluster di failover a disponibilità elevata per i servizi SAP NetWeaver o SAP S/4HANA Centrals.
  • La terza zona viene usata per ospitare il dispositivo SBD se si crea un cluster SUSE Linux Pacemaker e si usano dispositivi SBD anziché l'agente di isolamento di Azure.
  • 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. Il trasferimento di dati tra il livello dell'applicazione SAP e il livello del DBMS SAP è piuttosto intensivo. Pertanto, lo scenario attivo/attivo può contribuire ad aumentare i costi.