Eseguire il cluster di un'istanza di SAP ASCS/SCS in un cluster di failover Windows usando un disco condiviso in Azure
Windows
Windows Server Failover Clustering (WSFC) è la base di un'installazione SAP ASCS/SCS (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 del nodo, WSFC calcola il numero di errori che possono verificarsi e mantiene comunque un cluster integro per fornire applicazioni e servizi. È 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 servizio di bilanciamento del carico 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 regole di port forwarding necessarie 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.
Importante
Gli indirizzi IP mobili non sono supportati in una configurazione IP secondaria per una scheda di rete (NIC) in scenari di bilanciamento del carico. Per informazioni dettagliate, vedere Limitazioni di Azure Load Balancer. Se è necessario un indirizzo IP aggiuntivo per la macchina virtuale, distribuire una seconda scheda di interfaccia di rete.
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 S:\usr\sap\<SID>\SYS... usando il percorso UNC seguente:
\\<ASCS/SCS nome> host virtuale\sapmnt\<SID>\SYS...
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.
Con un'architettura ERS1 (Enqueue Replication Server 1):
- Lo stesso nome host virtuale ASCS/SCS viene usato per accedere al server messaggi SAP e ai processi del server di accodamento, oltre ai file host globali SAP tramite la condivisione file sapmnt .
- Lo stesso disco condiviso del cluster (unità S) viene condiviso tra di essi.
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 (unità S) viene condiviso tra di essi.
- Esiste un nome host virtuale ERS separato per accedere al processo del server di accodamento.
Dischi condivisi e server di replica accodamento
I dischi condivisi sono supportati con un'architettura ERS1, in cui l'istanza ERS1:
- Non è cluster.
- Usa un
localhostnome. - Viene distribuito su dischi locali in ognuno dei nodi del cluster.
I dischi condivisi sono supportati anche con un'architettura ERS2, in cui l'istanza ERS2:
- È cluster.
- Usa un nome host virtuale o di rete dedicato.
- È necessario configurare l'indirizzo IP del nome host virtuale ERS in un servizio di bilanciamento del carico interno di Azure, oltre all'indirizzo IP (A)SCS.
- Viene distribuito su dischi locali in ognuno dei nodi del cluster, quindi non è necessario un disco condiviso.
Per altre informazioni su ERS1 e ERS2, vedere Enqueue Replication Server in a Microsoft Failover Cluster and New Enqueue Replicator in failover environment on the SAP website (Server di replica di accodamento in un cluster di failover Microsoft e nuovo replicatore di accodamento in ambienti 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:
- Usare dischi condivisi di Azure per collegare i dischi gestiti di Azure a più macchine virtuali contemporaneamente.
- Usare SIOS DataKeeper Cluster Edition per creare una risorsa di archiviazione con mirroring che simula l'archiviazione condivisa del cluster.
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 nei set di disponibilità e nelle zone di disponibilità.
- Dischi Ultra di Azure Archiviazione 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 negli 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 dei 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 Ultra di Azure Archiviazione e i 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 nei set di disponibilità e nelle zone di disponibilità.
- I dischi condivisi di Azure con dischi SSD Premium sono dotati di due opzioni di archiviazione:
- L'archiviazione con ridondanza locale per i dischi condivisi SSD Premium (
skuNamevalore ) è supportata con la distribuzione nei set diPremium_LRSdisponibilità. - L'archiviazione con ridondanza della zona (ZRS) per i dischi condivisi SSD Premium (
skuNamevalore ) è supportata con la distribuzione nelle zone diPremium_ZRSdisponibilità.
- L'archiviazione con ridondanza locale per i dischi condivisi SSD Premium (
- Il valore maxShares del disco condiviso di Azure 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. Impostare quindi il valore per
maxSharessu2. - Un gruppo di posizionamento di prossimità di Azure (PPG) non è necessario per i dischi condivisi di Azure. Tuttavia, per la distribuzione SAP con gruppi di disponibilità, seguire queste linee guida:
- 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 disponibilità per un sistema SAP distribuito tra zone, come descritto in Gruppi di posizionamento di prossimità con distribuzioni di zona, è possibile collegare
Premium_ZRSl'archiviazione alle macchine virtuali che condividono un disco.
Per altre informazioni, vedere la sezione Limitazioni della documentazione relativa ai 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.
Archiviazione con ridondanza della zona 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 quindi la latenza del disco con ridondanza della zona tra zone di disponibilità. Eseguire il benchmark dei dischi per identificare la latenza dei dischi dell'archiviazione con ridondanza della zona 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 Archiviazione di Azure tipi 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 monitorando gli eventi pianificati di Azure.
- È possibile usare nomi di rete distribuiti. È l'opzione predefinita. Non è necessario avere un indirizzo IP dedicato per il nome di rete del cluster. Inoltre, non è necessario configurare un indirizzo IP in un servizio di 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:
- Collegare un disco aggiuntivo a ogni macchina virtuale in una configurazione cluster Windows.
- Eseguire SIOS DataKeeper Cluster Edition in entrambi i nodi delle macchine virtuali.
- Configurare SIOS DataKeeper Cluster Edition in modo che rispecchi il contenuto del volume aggiuntivo collegato al disco dalla macchina virtuale di origine al volume aggiuntivo collegato al disco della macchina virtuale di destinazione. SIOS DataKeeper astrae i volumi locali di origine e di destinazione e li presenta a WSFC come disco condiviso.
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ò essere server applicazioni SAP locali in un cluster SAP ASCS/SCS o 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 FILE 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 applicazioni SAP nei 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 nei nodi Always On di SQL Server con l'uso di SIOS DataKeeper:
Per informazioni su altre configurazioni, vedere le risorse seguenti: