Creazione di un cluster per un'istanza di SAP ASCS/SCS all'interno di un cluster di failover Windows usando un disco condiviso in Azure

Windows

Windows Server Failover Clustering (WSFC) è la base di un'installazione ad alta disponibilità (HA) di SAP ASCS/SCS e di sistemi di gestione di database (DBMS) 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 varie 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 (VM) 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 Azure non offre la possibilità 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 di Azure Load Balancer fornisce un servizio di bilanciamento del carico internal 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 Load Balancer 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.

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

In Windows un'istanza di SAP ASCS/SCS contiene servizi centrali SAP, il server messaggi SAP, i processi del server di accodamento e i file host globali 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...

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

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

• Lo stesso nome host virtuale ASCS/SCS viene utilizzato per accedere al server di messaggi SAP e ai processi del server di accodamento, e ai file host globali SAP tramite la condivisione file sapmnt.
• Il disco condiviso del cluster (unità S) è condiviso tra di loro.

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

• Lo stesso nome host virtuale ASCS/SCS viene utilizzato per accedere al processo del server di messaggi SAP, oltre che ai file host globali SAP tramite la condivisione file sapmnt.
• Il disco condiviso del cluster (unità S) è condiviso tra di loro.
• Esiste un nome host virtuale ERS distinto per accedere al processo del server di accodamento.

Dischi condivisi e Enqueue Replication Server

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:

• È raggruppato.
• Usa un nome host virtuale o di rete dedicato.
• Richiede che l'indirizzo IP del nome host virtuale dell'ERS sia configurato in un servizio di bilanciamento del carico interno di Azure, oltre all'indirizzo IP dell'(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 di accodamento in un cluster di failover Microsoft e Nuovo replicatore di accodamento negli ambienti di cluster di failover nel sito Web di SAP.

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

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

• Usare Azure dischi condivisi per collegare Azure Managed Disks a più macchine virtuali contemporaneamente.
• Usare SIOS DataKeeper Cluster Edition per creare un'archiviazione con mirroring che simula l'archiviazione condivisa del cluster.

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

• L'uso di dischi condivisi Azure con dischi Azure Premium SSD è supportato per la distribuzione SAP nei set di disponibilità e nelle zone di disponibilità.
• Ultra Disks e Azure SSD Standard non sono supportati come dischi condivisi Azure per i carichi di lavoro SAP.
• Assicurarsi di effettuare il provisioning di Azure Premium SSD con una dimensione minima del disco, come specificato negli intervalli di SSD Premium, per collegarsi contemporaneamente al numero di macchine virtuali richiesto. In genere sono necessarie due macchine virtuali per SAP ASCS in un cluster di failover Windows.

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.

Azure dischi condivisi

È possibile implementare SAP ASCS/SCS in HA con i dischi condivisi di Azure.

Prerequisiti e limitazioni

È possibile usare Azure dischi SSD Premium come dischi condivisi Azure per l'istanza di SAP ASCS/SCS. Tenere presente le limitazioni seguenti:

• i dischi Ultra e Standard non sono supportati come dischi condivisi Azure per i carichi di lavoro SAP.
• I dischi condivisi di Azure con SSD Premium sono supportati per la distribuzione SAP nei set di disponibilità e nelle zone di disponibilità.
• Azure shared disks con unità SSD Premium offrono 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 i dischi condivisi SSD Premium (valore skuName pari a Premium_ZRS) è supportata con la distribuzione nei set di disponibilità.
• Il valore del disco condiviso 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.
• Non è necessario un Azure gruppo di posizionamento di prossimità (PPG) per Azure dischi condivisi. 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 posizionamento di prossimità (PPGs) per un sistema SAP distribuito tra zone, secondo quanto 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 Limitations della documentazione relativa Azure dischi condivisi.

Considerazioni importanti per i dischi condivisi SSD Premium

Considera questi punti importanti relativi ai dischi condivisi Premium SSD Azure:

• LRS per dischi condivisi SSD Premium

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

• ZRS per dischi condivisi SSD Premium:

  • La latenza di scrittura per ZRS è superiore a quella di LRS a causa della copia dei dati tra zone.
  • La distanza tra le zone di disponibilità in aree diverse varia, così come la latenza del disco di archiviazione con ridondanza della zona tra le zone di disponibilità. Eseguire benchmark sui dischi per identificare la latenza dei dischi ZRS nell'area.
  • L'archiviazione con ridondanza della zona per i dischi condivisi SSD Premium replica i dati in modo sincrono 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 carichi di lavoro SAP.

Versioni del sistema operativo supportate

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

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

• WSFC in Windows Server 2019 è ottimizzato per Azure.
• Windows Server 2019 Datacenter include l'integrazione e la consapevolezza della manutenzione host di Azure e un'esperienza migliorata grazie al 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 Azure servizio di bilanciamento del carico interno.

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 ognuna delle macchine virtuali in una configurazione del 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.

Configurazioni facoltative

I diagrammi seguenti illustrano più istanze SAP in macchine virtuali Azure che eseguono il clustering di failover di Windows Server per ridurre il numero delle macchine virtuali.

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

Sia SAP ASCS/SCS che il database di Microsoft SQL Server sono singoli punti di errore (SPOF). WSFC consente di proteggere questi file SPOFs 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:

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

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

Per informazioni su altre configurazioni, vedere le risorse seguenti:

• Configurazione facoltativa per i server applicazioni SAP nei nodi WSFC usando Windows Scale-Out File Server

• Configurazione facoltativa per i server applicazioni SAP nei nodi WSFC tramite Server Message Block in Azure NetApp Files

• Configurazione facoltativa per SAP ASCS/SCS nei nodi SQL Server AlwaysOn tramite Windows Scale-Out File Server

• Configurazione facoltativa per SAP ASCS/SCS nei nodi SQL Server Always On tramite Blocco messaggi del server in Azure NetApp Files

Passaggi successivi

• Prepare l'infrastruttura di Azure per SAP HA usando un cluster di failover Windows e un disco condiviso per un'istanza di SAP ASCS/SCS

• Installare SAP NetWeaver HA in un cluster di failover Windows e un disco condiviso per un'istanza SAP ASCS/SCS