Condividi tramite

Clustering di un'istanza SAP ASCS/SCS in un cluster di failover Windows tramite una condivisione file in Azure

  • Articolo

Logo di Windows. Windows

Windows Server Failover Clustering è alla base di un'istallazione ASCS/SCS di SAP a disponibilità elevata e di un sistema 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, Windows Server Failover Clustering 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à descritte in questo articolo, vedere gli articoli e le note SAP seguenti:

  • Scenari e architettura di disponibilità elevata in Macchine virtuali di Azure per SAP NetWeaver
  • Nota SAP 1928533, contenente:
    • Un elenco delle dimensioni delle macchine virtuali di Azure supportate per la distribuzione di software SAP
    • Importanti informazioni sulla capacità per le dimensioni delle VM di Azure
    • Software SAP e combinazioni di sistemi operativi e database supportati
    • Versione del kernel SAP richiesta per Windows in Microsoft Azure
  • La nota SAP 2015553 elenca i prerequisiti per le distribuzioni di software SAP supportate da SAP in Azure.
  • La nota SAP 2178632 contiene informazioni dettagliate su tutte le metriche di monitoraggio segnalate per SAP in Azure.
  • La nota SAP 1999351 contiene informazioni aggiuntive sulla risoluzione dei problemi per l'estensione di monitoraggio avanzato di Azure per SAP.
  • La nota SAP 2287140 elenca i prerequisiti per la funzionalità CA supportata da SAP del protocollo SMB 3.x.
  • Nota SAP 2802770 contiene informazioni sulla risoluzione dei problemi per la transazione SAP a esecuzione lenta AL11 in Windows 2012 e 2016.
  • La nota SAP 1911507 contiene informazioni sulla funzionalità di failover trasparente per una condivisione file in Windows Server con il protocollo SMB 3.0.
  • La nota SAP 662452 include consigli (disattivazione della generazione di nomi 8.3) per risolvere problemi di prestazioni/errori del file system non ottimali durante gli accessi ai dati.
  • Installare la disponibilità elevata di SAP NetWeaver in un cluster di failover Windows e condivisione file per le istanze di SAP ASCS/SCS in Azure

Nota

Il clustering di istanze ASCS/SCS di SAP tramite con condivisione file è supportato per sistemi SAP con kernel SAP versione 7.22 o successiva. Per informazioni dettagliate, vedere la nota SAP 2698948

Windows Server Failover Clustering in Azure

Rispetto alle distribuzioni bare metal o di cloud privato sono necessari passaggi aggiuntivi per configurare il clustering di failover Windows Server in Macchine virtuali di Microsoft Azure. 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 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. Il servizio di bilanciamento del carico interno gestisce il port forwarding al nodo attivo del cluster.

Figura 1: Configurazione di Windows Server Failover Clustering in Azure senza disco condiviso

Figura 1: Configurazione di Windows Server Failover Clustering in Azure senza disco condiviso

ASCS/SCS di SAP a disponibilità elevata con condivisione file

SAP ha sviluppato un nuovo approccio e un'alternativa per i dischi condivisi del cluster per il clustering di un'istanza ASCS/SCS di SAP in un cluster di failover di Windows. Invece di usare i dischi condivisi del cluster, è possibile usare una condivisione file SMB per distribuire i file di host globale SAP.

Nota

Una condivisione file SMB è un'alternativa all'uso dei dischi condivisi del cluster per il clustering delle istanze ASCS/SCS di SAP.

Questa architettura è specifica nei modi seguenti:

  • I servizi centrali SAP, con la propria struttura di file e i propri processi di messaggistica e accodamento, sono separati dai file dell'host globale SAP.
  • I servizi centrali SAP vengono eseguiti in un'istanza ASCS/SCS di SAP.
  • L'istanza ASCS/SCS di SAP è inclusa in un cluster ed è possibile accedervi usando il nome dell'host virtuale <nome host virtuale ASCS/SCS>.
  • I file globali SAP vengono inseriti nella condivisione file SMB e sono accessibili usando il <nome host globale> SAP: \\<SAP global host>\sapmnt\<SID>\SYS...
  • L'istanza ASCS/SCS di SAP viene installata in un disco locale in entrambi i nodi del cluster.
  • Il nome di rete <nome host virtuale ASCS/SCS> è diverso dall'<host globale SAP>.

Figure 2: Architettura a disponibilità elevata ASCS/SCS di SAP con condivisione file SMB

Figura 2: Nuova architettura a disponibilità elevata ASCS/SCS di SAP con una condivisione file SMB

Prerequisiti per una condivisione file SMB:

  • Protocollo SMB 3.0 (o versione successiva).
  • Possibilità di impostare elenchi di controllo di accesso di Active Directory (ACL) per gruppi di utenti di Active Directory e l'oggetto computer computer$.
  • La condivisione file deve essere abilitata per la disponibilità elevata:
    • I dischi usati per archiviare i file non devono essere un singolo punto di guasto.
    • Il tempo di inattività del server o della macchina virtuale non causa tempi di inattività nella condivisione file.

Il ruolo cluster <SID> di SAP non contiene dischi condivisi nel cluster o una risorsa di cluster generica con condivisione file generica.

Figura 3: Risorse ruolo cluster <SID> di SAP per l'uso di una condivisione file

Figura 3: Risorse ruolo cluster <SID> di SAP per l'uso di una condivisione file

Condivisioni file di tipo scale-out con Spazi di archiviazione diretta in Azure come condivisione file SAPMNT

È possibile usare una condivisione file di tipo scale-out per ospitare e proteggere i file dell'host globale SAP. Una condivisione file di tipo scale-out offre un servizio di condivisione file SAPMNT a disponibilità elevata.

Figura 4: Condivisione file di tipo scale-out usata per proteggere i file dell'host globale SAP

Figura 4: Condivisione file di tipo scale-out usata per proteggere i file dell'host globale SAP

Importante

Le condivisioni file di tipo scale-out sono completamente supportate nel cloud di Microsoft Azure e negli ambienti locali.

Una condivisione file di tipo scale-out offre una condivisione file SAPMNT a disponibilità elevata e a scalabilità orizzontale.

Il servizio Spazi di archiviazione diretta viene usato come disco condiviso per una condivisione file di tipo scale-out. È possibile usare Spazi di archiviazione diretta per creare spazi di archiviazione scalabili e a disponibilità elevata che usano server con risorse di archiviazione locali. Lo spazio di archiviazione condiviso usato per una condivisione file di tipo scale-out, come per i file dell'host globale SAP, non è un singolo punto di errore.

Quando si sceglie Spazi di archiviazione diretta, considerare questi casi d'uso:

  • Le macchine virtuali usate per compilare il cluster Spazi di archiviazione diretta devono essere distribuite in un set di disponibilità di Azure.
  • Per il ripristino di emergenza di un cluster Spazi di archiviazione diretta, è possibile usare i servizi di Azure Site Recovery.
  • Non è supportata l'estensione del cluster diretto dello spazio di archiviazione in diversi zone di disponibilità di Azure.

Prerequisiti SAP per le condivisioni file di tipo scale-out in Azure

Per usare una condivisione file di tipo scale-out, il sistema deve soddisfare i requisiti seguenti:

  • Almeno due nodi del cluster per una condivisione file di tipo scale-out.
  • Ogni nodo deve avere almeno due dischi locali.
  • Per motivi di prestazioni, è necessario usare la resilienza del mirroring:
    • Mirroring a due vie per una condivisione file di tipo scale-out con due nodi del cluster.
    • Mirroring a tre vie per una condivisione file di tipo scale-out con tre o più nodi del cluster.
  • È consigliabile usare tre o più nodi del cluster per una condivisione file di tipo scale-out, con il mirroring a tre vie. Questa configurazione offre una maggiore scalabilità e una maggiore resilienza di archiviazione rispetto alla configurazione della condivisione file di tipo scale-out con due nodi del cluster e il mirroring a due vie.
  • È necessario usare dischi Premium di Azure.
  • È consigliabile usare Azure Managed Disks.
  • È consigliabile formattare i volumi con Resilient File System (ReFS).
  • È possibile usare le dimensioni delle VM di Azure DS-Series o DSv2-Series.
  • Per ottenere prestazioni di rete di buon livello tra le macchine virtuali, necessari per la sincronizzazione dei dischi di Spazi di archiviazione diretta, usare un tipo di macchina virtuale che abbia almeno una larghezza di banda "alta". Per altre informazioni, vedere le specifiche DSv2-Series e DS-Series.
  • È consigliabile riservare capacità non allocata nel pool di archiviazione. Se si lascia capacità non allocata nel pool di archiviazione, si lascia ai volumi lo spazio per il ripristino "sul posto" nel caso in cui un'unità si guasti. Questo approccio migliora le prestazioni e la sicurezza dei dati. Per altre informazioni, vedere Scelta delle dimensioni dei volumi.
  • Non è necessario configurare il servizio di bilanciamento del carico interno di Azure per il nome di rete della condivisione file di tipo scale-out, ad esempio per <host globale SAP>. Questa configurazione viene eseguita per il <nome host virtuale ASCS/SCS> dell'istanza ASCS/SCS di SAP o per il sistema DBMS. Una condivisione file di tipo scale-out scala orizzontalmente il carico su tutti i nodi del cluster. <Host globale SAP> Usa l'indirizzo IP locale per tutti i nodi del cluster.

Importante

Non è possibile rinominare la condivisione file SAPMNT, che punta all'<host globale SAP>. SAP supporta solo il nome di condivisione "sapmnt".

Per altre informazioni, vedere SAP Note 2492395 - Can the share name sapmnt be changed? (SAP Note 2492395 - È possibile modificare il nome di condivisione sapmnt?)

Configurare le istanze ASCS/SCS di SAP e una condivisione file di tipo scale-out in due cluster

È necessario distribuire le istanze di SAP ASCS/SCS in un cluster separato, con il proprio ruolo del cluster SID> SAP<. In questo caso, si configura la condivisione file di tipo scale-out in un altro cluster, con un altro ruolo cluster.

Importante

L'installazione deve soddisfare i requisiti seguenti: le istanze di SAP ASCS/SCS e la condivisione SOFS devono essere distribuite in cluster separati.

Importante

In questo scenario, l'istanza di SAP ASCS/SCS è configurata per accedere all'host globale SAP usando il percorso UNC \\<SAP global host>\sapmnt\<SID>\SYS.

Figura 5: Istanza SAP ASCS/SCS e condivisione file di tipo scale-out distribuite in due cluster

Figura 5: Istanza ASCS/SCS di SAP e condivisione file di tipo scale-out distribuite in due cluster

Configurazioni facoltative

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

Può trattarsi di server applicazioni SAP locali in un cluster SAP ASCS/SCS o in 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). Per proteggere questi file SPOFs in un ambiente Windows WSFC viene usato.

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

Server applicazioni SAP nei nodi WSFC tramite server server di scalabilità orizzontale Windows

Figura 6: Configurazione del clustering di failover di Windows Server in Azure con sofS Windows e server applicazioni SAP installato localmente

Nota

L'immagine mostra l'uso di dischi locali aggiuntivi. Questa opzione è facoltativa per i clienti che non installeranno il software dell'applicazione nell'unità del sistema operativo (C:)

SAP ASCS/SCS nei nodi Always On di SQL Server tramite SofS Di Windows

Figura 7: SAP ASCS/SCS nei nodi Always On di SQL Server tramite SofS Windows

Nota

L'immagine mostra l'uso di dischi locali aggiuntivi. Questa opzione è facoltativa per i clienti che non installeranno il software dell'applicazione nell'unità del sistema operativo (C:)

Importante

Nel cloud di Azure ogni cluster usato per le condivisioni file SAP e con scalabilità orizzontale deve essere distribuito nel proprio set di disponibilità di Azure o in Azure zone di disponibilità. In questo modo viene garantita la distribuzione delle VM del cluster nell'infrastruttura di Azure sottostante. Le distribuzioni della zona di disponibilità sono supportate con questa tecnologia.

Condivisione file generica con SIOS DataKeeper come dischi condivisi del cluster

La condivisione file generica è un'altra opzione che si può usare ottenere una condivisione file a disponibilità elevata.

In questo caso è possibile usare una soluzione SIOS di terze parti come disco condiviso del cluster.

Passaggi successivi