Clustering di un'istanza SAP ASCS/SCS in un cluster di failover Windows tramite un disco condiviso in Azure

  • Articolo

Sistema operativo Windows Windows

Windows Server Failover Clustering (WSFC) è la base di un'installazione SAP ASCS/SCS a disponibilità elevata in Windows.

Un cluster di failover è un gruppo di 1 + n server (nodi) indipendenti che funzionano insieme per aumentare la disponibilità di applicazioni e servizi. Se si verifica un errore in un nodo, WSFC calcola il numero di errori che possono verificarsi e mantiene un cluster integro per fornire applicazioni e servizi. A questo scopo è possibile scegliere tra diverse modalità quorum per ottenere il clustering di failover.

Prerequisiti

Prima di iniziare le attività in questo articolo, vedere l'articolo Architettura e scenari a disponibilità elevata per SAP NetWeaver.

Windows Server Failover Clustering in Azure

WSFC con macchine virtuali di Azure richiede passaggi di configurazione aggiuntivi. Quando si crea un cluster, è necessario impostare diversi indirizzi IP e nomi host virtuali per l'istanza ASCS/SCS di SAP.

Risoluzione dei nomi in Azure e nome host virtuale del cluster

La piattaforma cloud di Azure non consente di configurare indirizzi IP virtuali, ad esempio indirizzi IP mobili. È necessaria una soluzione alternativa per configurare un indirizzo IP virtuale per poter raggiungere la risorsa cluster nel cloud.

Il servizio Azure Load Balancer include un servizio di bilanciamento del carico interno per Azure. Con il Load Balancer interno, i client raggiungono il cluster tramite l'indirizzo IP virtuale del cluster.

È necessario distribuire il servizio di bilanciamento del carico interno nel gruppo di risorse che contiene i nodi del cluster. Configurare quindi tutte le necessarie regole di port forwarding usando le porte probe del servizio di bilanciamento del carico interno. I client possono connettersi tramite il nome host virtuale. Il server DNS risolve l'indirizzo IP del cluster e il servizio di bilanciamento del carico interno gestisce il port forwarding al nodo attivo del cluster.

Diagramma di una configurazione di Windows Server Failover Clustering in Azure senza un disco condiviso.

Disponibilità elevata di SAP ASCS/SCS con i dischi condivisi del cluster

In Windows, un'istanza di SAP ASCS/SCS contiene i servizi centrali SAP, il server di messaggistica SAP, i processi del server di accodamento e i file host globali di SAP. I file host globali di SAP archiviano i file centrali per l'intero sistema SAP.

Un'istanza di SAP ASCS/SCS include i componenti seguenti:

  • Servizi centrali SAP:

    • Due processi (per un server di messaggi e un server di accodamento) e un nome host virtuale ASCS/SCS usato per accedere ai due processi
    • Struttura dei file: S:\usr\sap\<SID>\ASCS/SCS<numero di istanza>

  • File host globali di SAP:

    • Struttura del file: S:\usr\sap\<SID>\SYS...

    • La condivisione file sapmnt, che consente l'accesso a questi file globali S:\usr\sap\<SID>\SYS... usando il percorso UNC seguente:

      \\<Nome host virtuale ASCS/SCS >\sapmnt\<SID>\SYS...

Diagramma di processi, struttura di file e condivisione file host globale di un'istanza di SAP ASCS/SCS.

In un'impostazione con disponibilità elevata eseguire il clustering delle istanze di SAP ASCS/SCS. Si usano dischi condivisi cluster (unità S nell'esempio di questo articolo) per inserire i file di host globale SAP ASCS/SCS e SAP.

Diagramma di un'architettura a disponibilità elevata di SAP ASCS/SCS con un disco condiviso.

Con un'architettura Enqueue Replication Server 1 (ERS1):

  • Lo stesso nome host virtuale ASCS/SCS viene usato per accedere ai processi del server messaggi e del server di accodamento SAP, oltre ai file host globali SAP tramite la condivisione file sapmnt.
  • Lo stesso disco condiviso del cluster S viene condiviso tra loro.

Con l'architettura di Enqueue Replication Server 2 (ERS2):

  • Lo stesso nome host virtuale ASCS/SCS viene usato per accedere al processo del server messaggi SAP, oltre ai file host globali SAP tramite la condivisione file sapmnt.
  • Lo stesso disco condiviso del cluster S viene condiviso tra loro.
  • Esiste un nome host virtuale ERS separato per accedere al processo del server di accodamento.

Diagramma di un'architettura a disponibilità elevata di SAP ASCS/SCS con un disco condiviso.

Dischi condivisi e server di replica accodamento

I dischi condivisi sono supportati con un'architettura ERS1, in cui l'istanza ERS1:

  • Non è in cluster.
  • Usa un nome localhost.
  • Viene distribuita in dischi locali in ognuno dei nodi del cluster.

I dischi condivisi sono supportati anche con un'architettura ERS2, in cui l'istanza ERS2:

  • È in cluster.
  • Usa un nome host virtuale o di rete dedicato.
  • È necessario configurare l'indirizzo IP del nome host virtuale ERS in un bilanciamento del carico interno di Azure, oltre all'indirizzo IP (A)SCS.
  • Viene distribuita su dischi locali in ognuno dei nodi del cluster, quindi non è necessario un disco condiviso.

Per altre informazioni su ERS1 e ERS2, vedere Server di replica accodamento in un cluster di failover Microsoft e Nuovo replicatore accodamento negli ambienti del cluster di failover nel sito Web SAP.

Opzioni per i dischi condivisi in Azure per carichi di lavoro SAP

Esistono due opzioni per i dischi condivisi in un cluster di failover Windows in Azure:

Quando si seleziona la tecnologia per i dischi condivisi, tenere presenti le considerazioni seguenti sui dischi condivisi di Azure per i carichi di lavoro SAP:

  • L'uso di dischi condivisi di Azure con Dischi SSD Premium di Azure è supportato per la distribuzione SAP in set di disponibilità e zone di disponibilità.
  • I Dischi di Archiviazione su disco Ultra di Azure e Dischi SSD Standard di Azure non sono supportati come dischi condivisi di Azure per i carichi di lavoro SAP.
  • Assicurarsi di effettuare il provisioning dei dischi SSD Premium di Azure con una dimensione minima del disco, come specificato in Intervalli SSD Premium, per potersi collegare contemporaneamente al numero necessario di macchine virtuali. In genere sono necessarie due macchine virtuali per i cluster di failover Windows di SAP ASCS.

Tenere presenti le considerazioni seguenti su SIOS:

  • La soluzione SIOS fornisce la replica di dati sincrona in tempo reale tra due dischi.
  • Con la soluzione SIOS si opera con due dischi gestiti. Se si usano set di disponibilità o zone di disponibilità, i dischi gestiti si trovano in cluster di archiviazione diversi.
  • La distribuzione nelle zone di disponibilità è supportata.
  • La soluzione SIOS richiede l'installazione e il funzionamento di software di terze parti, che è necessario acquistare separatamente.

Dischi condivisi di Azure

È possibile implementare la disponibilità elevata di SAP ASCS/SCS con dischi condivisi di Azure.

Prerequisiti e limitazioni

Attualmente, è possibile usare dischi SSD Premium di Azure come dischi condivisi di Azure per l'istanza di SAP ASCS/SCS. Sono attualmente in vigore le limitazioni seguenti:

  • I Dischi di Archiviazione su disco Ultra di Azure e Dischi SSD Standard non sono supportati come dischi condivisi di Azure per i carichi di lavoro SAP.
  • I dischi condivisi di Azure con dischi SSD Premium sono supportati per la distribuzione SAP in set di disponibilità e zone di disponibilità.
  • I dischi condivisi di Azure con dischi SSD Premium sono dotati di due opzioni di archiviazione:
    • L'archiviazione con ridondanza locale (LRS) per i dischi condivisi SSD Premium (valore skuName pari a Premium_LRS) è supportata con la distribuzione nei set di disponibilità.
    • L'archiviazione con ridondanza della zona (ZRS) per dischi condivisi SSD Premium (valore skuName pari a Premium_ZRS) è supportata con la distribuzione nelle zone di disponibilità.
  • Il valore del disco condiviso di Azure maxShares determina il numero di nodi del cluster che possono usare il disco condiviso. Per un'istanza di SAP ASCS/SCS, in genere si configurano due nodi in WSFC. Si imposta quindi il valore per maxShares su 2.
  • Un Gruppo di posizionamento di prossimità di Azure (PPG) non è necessario per il disco condiviso di Azure. Tuttavia, per la distribuzione SAP con PPG, attenersi alle linee guida seguenti:
    • Se si usano gruppi di disponibilità per un sistema SAP distribuito in un'area, tutte le macchine virtuali che condividono un disco devono far parte dello stesso PPG.
    • Se si usano gruppi di sicurezza di rete per un sistema SAP distribuito tra zone, come descritto in Gruppi di posizionamento di prossimità con distribuzioni di zona, è possibile collegare l'archiviazione Premium_ZRS alle macchine virtuali che condividono un disco.

Per altre informazioni, vedere la sezione Limitazioni della documentazione sui dischi condivisi di Azure.

Considerazioni importanti per i dischi condivisi SSD Premium

Considerare questi punti importanti sui dischi condivisi SSD Premium di Azure:

  • Archiviazione con ridondanza locale per dischi condivisi SSD Premium:

    • La distribuzione SAP con archiviazione con ridondanza locale per dischi condivisi SSD Premium opera con un singolo disco condiviso di Azure in un cluster di archiviazione. Se si verifica un problema con il cluster di archiviazione in cui viene distribuito il disco condiviso di Azure, influisce sull'istanza di SAP ASCS/SCS.

  • ZRS per dischi condivisi SSD Premium:

    • La latenza di scrittura per l'archiviazione con ridondanza della zona è superiore a quella dell'archiviazione con ridondanza locale a causa della copia tra zone dei dati.
    • La distanza tra le zone di disponibilità in aree diverse varia e lo stesso vale per la latenza del disco con ridondanza della zona tra zone di disponibilità. Eseguire benchmark sui dischi per identificare la latenza dei dischi ZRS nell'area.
    • L'archiviazione con ridondanza della zona per dischi condivisi SSD Premium replica in modo sincrono i dati in tre zone di disponibilità nell'area. Se si verifica un problema in uno dei cluster di archiviazione, l'istanza di SAP ASCS/SCS continua a essere eseguita perché il failover di archiviazione è trasparente al livello dell'applicazione.
    • Per altre informazioni, vedere la sezione Limitazioni della documentazione sull'archiviazione con ridondanza della zona per i dischi gestiti.

Per altre considerazioni importanti sulla pianificazione della distribuzione SAP, vedere Pianificare e implementare una distribuzione SAP in Azure e Tipi di archiviazione di Azure per i carichi di lavoro SAP.

Versioni del sistema operativo supportate

Windows Server 2016, 2019 e versioni successive sono supportati. Usare le immagini più recenti del data center.

Per questi motivi, è consigliabile usare almeno Windows Server 2019 Datacenter:

  • WSFC in Windows Server 2019 è compatibile con Azure.
  • Windows Server 2019 Datacenter include l'integrazione e la consapevolezza della manutenzione degli host di Azure e un'esperienza migliorata tramite il monitoraggio degli eventi pianificati di Azure.
  • È possibile usare nomi di rete distribuiti. Questa è l'impostazione predefinita. Non è necessario avere un indirizzo IP dedicato per il nome di rete del cluster. Inoltre, non è necessario configurare un indirizzo IP in un bilanciamento del carico interno di Azure.

Dischi condivisi in Azure con SIOS DataKeeper

Un'altra opzione per i dischi condivisi consiste nell'usare SIOS DataKeeper Cluster Edition per creare un'archiviazione con mirroring che simula l'archiviazione condivisa del cluster. La soluzione SIOS fornisce la replica di dati sincrona in tempo reale.

Per creare una risorsa disco condiviso per un cluster:

  1. Collegare un disco aggiuntivo a ogni macchina virtuale in una configurazione cluster Windows.
  2. Eseguire SIOS DataKeeper Cluster Edition in entrambi i nodi delle macchine virtuali.
  3. Configurare SIOS DataKeeper Cluster Edition per eseguire il mirroring del contenuto del volume collegato del disco aggiuntivo dalla macchina virtuale di origine al volume collegato del disco aggiuntivo della macchina virtuale di destinazione. SIOS DataKeeper astrae i volumi locali di origine e di destinazione e quindi li presenta a WSFC come un disco condiviso.

Diagramma di configurazione di Windows Server Failover Clustering in Azure con SIOS DataKeeper.

Nota

Non sono necessari dischi condivisi per la disponibilità elevata con alcuni prodotti DBMS, ad esempio SQL Server. La funzionalità AlwaysOn di SQL Server replica i file di dati e di log del sistema DBMS dal disco locale di un nodo del cluster nel disco locale di un altro nodo del cluster. In questo caso, la configurazione del cluster Windows non richiede un disco condiviso.

Configurazioni facoltative

I diagrammi seguenti illustrano più istanze SAP nelle macchine virtuali di Azure che eseguono Windows Server Failover Clustering per ridurre il numero totale di macchine virtuali.

Questa configurazione può consistere di server applicazioni SAP locali in un cluster SAP ASCS/SCS o di un ruolo del cluster SAP ASCS/SCS nei nodi Always On di Microsoft SQL Server.

Importante

L'installazione di un server applicazioni SAP locale in un nodo Always On di SQL Server non è supportata.

Sia SAP ASCS/SCS che il database di Microsoft SQL Server sono singoli punti di errore (SPOF). WSFC consente di proteggere questi SPOF in un ambiente Windows.

Anche se l'utilizzo delle risorse di SAP ASCS/SCS è piuttosto ridotto, è consigliabile ridurre la configurazione della memoria per SQL Server o il server applicazioni SAP di 2 GB.

Questo diagramma illustra i server applicativi SAP sui nodi WSFC con l'uso di SIOS DataKeeper:

Diagramma di configurazione di Windows Server Failover Clustering in Azure con SIOS DataKeeper e server applicativi SAP installati in locale.

Poiché i server applicazioni SAP sono installati in locale, non è necessario configurare alcuna sincronizzazione.

Questo diagramma illustra SAP ASCS/SCS nei nodi Always On di SQL Server con l'uso di SIOS DataKeeper:

Diagramma di SAP ASCS/SCS nei nodi Always On di SQL Server con SIOS DataKeeper.

Per informazioni su altre configurazioni, vedere le risorse seguenti:

Passaggi successivi