Configurare una combinazione di disponibilità elevata e ripristino di emergenza

  • 6 minuti

Microsoft non condivide informazioni sulle distanze geografiche tra le strutture che ospitano zone di disponibilità di Azure diverse in un'area di Azure. Nonostante ciò, alcuni clienti usano le zone per una configurazione combinata di disponibilità elevata e ripristino di emergenza che promette un obiettivo del punto di ripristino (RPO, Recovery Point Objective) pari a zero. Questo significa che non si dovrebbe perdere alcuna transazione di database di cui è stato eseguito il commit, anche per un ripristino di emergenza.

Microsoft consiglia la configurazione della zona di disponibilità 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à.

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. Di conseguenza, in questo caso, avete un dominio di aggiornamento e un dominio di guasto per il livello dell'applicazione. Ciò è dovuto al fatto che è stato distribuito solo in una zona. Questa configurazione presenta alcuni leggeri svantaggi rispetto all'architettura di riferimento che prevede la distribuzione del livello dell'applicazione in un set di disponibilità di Azure.

  • 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 verifica un failover dell'istanza di SAP Central Services o DBMS, è opportuno assicurarsi che sia possibile eseguire manualmente il failback nella zona con il livello dell'applicazione SAP distribuita non appena possibile.

  • Le istanze dell'applicazione di produzione devono essere preinstallate nelle macchine virtuali che eseguono le istanze dell'applicazione di controllo di qualità attive.

  • Se si verifica un errore di zona, si arrestano le istanze dell'applicazione di controllo qualità e si avviano invece le istanze di produzione. È necessario usare nomi virtuali per le istanze dell'applicazione per far funzionare questo meccanismo.

  • Per i bilanciatori di carico dei cluster di failover dei servizi centrali di SAP e del livello DBMS, è necessario utilizzare lo Standard SKU di Azure Load Balancer. Il servizio di bilanciamento del carico di base non funziona tra le 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.

  • L'archiviazione Premium di Azure e l'archiviazione Ultra SSD non supportano alcun tipo di replica dell'archiviazione tra le zone. L'applicazione (DBMS o SAP Central Services) deve replicare i dati importanti.

  • Lo stesso vale per la directory sapmnt condivisa, ovvero un disco condiviso (Windows), una condivisione CIFS (Windows) o una condivisione NFS (Linux). È necessario usare una tecnologia che replica questi dischi condivisi o condivisioni tra le zone. Sono supportate le tecnologie seguenti:

    • Per Windows, una soluzione cluster che utilizza SIOS DataKeeper, come documentato nel clustering di un'istanza SAP ASCS/SCS in un cluster di failover di Windows utilizzando un disco condiviso del cluster in Azure.
    • Per SUSE Linux, una condivisione NFS compilata come documentato in Disponibilità elevata per NFS in Macchine virtuali di Azure in SUSE Linux Enterprise Server.

  • Attualmente, la soluzione che utilizza Microsoft Scale-Out File Server non è supportata in diverse zone.

  • La terza zona viene usata per ospitare il dispositivo SBD nel caso in cui si crei un cluster SUSE Linux Pacemaker o altre istanze dell'applicazione.