Architettura e scenari di disponibilità elevata per SAP NetWeaver
Definizioni della terminologia
Disponibilità elevata: il termine si riferisce a un set di tecnologie che riduce al minimo i disservizi IT assicurando la continuità aziendale dei servizi IT tramite componenti ridondanti, a tolleranza di errore o protetti con failover all'interno dello stesso data center. In questo caso, il data center si trova all'interno di un'area di Azure.
Ripristino di emergenza: il termine indica anche ridurre al minimo le interruzioni per i servizi IT e il relativo ripristino, ma attraverso vari data center che potrebbero essere distanti anche centinaia di chilometri l'uno dall'altro. In questo caso, i data center potrebbero trovarsi in varie aree di Azure all'interno della stessa area geopolitica o in posizioni stabilite dal cliente.
Panoramica della disponibilità elevata
La disponibilità elevata di SAP in Azure può essere di tre tipi:
Disponibilità elevata dell'infrastruttura di Azure:
la disponibilità elevata può includere, ad esempio, l'infrastruttura di calcolo (macchine virtuali), rete o archiviazione e i relativi vantaggi per aumentare la disponibilità delle applicazioni SAP.
Uso del riavvio della macchina virtuale dell'infrastruttura di Azure per proteggere le applicazioni SAP:
se si decide di non usare funzionalità come Windows Server Failover Clustering (WSFC) o Pacemaker in Linux, viene usato il riavvio delle macchine virtuali di Azure. Ripristina le funzionalità nei sistemi SAP se sono presenti tempi di inattività pianificati e non pianificati dell'infrastruttura server fisica di Azure e della piattaforma Azure sottostante complessiva.
Disponibilità elevata delle applicazioni SAP:
Per ottenere una disponibilità elevata completa del sistema SAP, è necessario proteggere tutti i componenti SAP critici del sistema. Ad esempio:
- Server di applicazioni SAP ridondanti.
- Componenti univoci. Un esempio potrebbe essere un componente singolo punto di guasto (SPOF), come un'istanza di SAP ASCS/SCS o un sistema di gestione di database (DBMS).
La disponibilità elevata di SAP in Azure presenta alcune differenze rispetto alla disponibilità elevata di SAP in un ambiente fisico o virtuale locale.
Non esiste alcuna configurazione sapinst integrata sap a disponibilità elevata per Linux perché è disponibile per Windows. Per informazioni sulla disponibilità elevata di SAP in locale per Linux, vedere High availability partner information (Informazioni di disponibilità elevata sui partner).
Disponibilità elevata dell'infrastruttura di Azure
Contratto di servizio per le macchine virtuali a istanza singola
Attualmente è disponibile un contratto di servizio a singola macchina virtuale del 99,9% con archiviazione Premium. Per avere un'idea di come potrebbe essere la disponibilità di una singola macchina virtuale, è possibile calcolare il prodotto dei vari contratti di servizio di Azure disponibili.
La base per il calcolo è di 30 giorni al mese o 43.200 minuti. Ad esempio, un tempo di inattività dello 0,05% corrisponde a 21,6 minuti. Come di consueto, la disponibilità dei vari servizi viene calcolata nel modo seguente:
(Servizio di disponibilità n. 1/100) x (servizio di disponibilità n. 2/100) x (servizio di disponibilità n. 3/100) *...
Ad esempio:
(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 o una disponibilità complessiva del 99,75%.
Istanze multiple di macchine virtuali nello stesso set di disponibilità
Per tutte le macchine virtuali con due o più istanze distribuite nello stesso set di disponibilità, si garantisce la connettività della macchina virtuale ad almeno un'istanza del 99,95% del tempo.
Quando due o più macchine virtuali appartengono allo stesso set di disponibilità, a ciascuna macchina virtuale nel set di disponibilità viene assegnato un dominio di aggiornamento e un dominio di errore dalla piattaforma Azure sottostante.
- I domini di aggiornamento garantiscono che più macchine virtuali non vengano riavviate contemporaneamente durante la manutenzione pianificata di un'infrastruttura di Azure. ma che venga riavviata una sola macchina virtuale alla volta.
- I domini di errore garantiscono che le macchine virtuali vengano distribuite in componenti hardware che non condividono un commutatore di alimentazione e di rete comune. In caso di inattività non pianificata di server, commutatori di rete o alimentatori, ne risente solo una macchina virtuale.
Per altre informazioni, vedere Gestire la disponibilità delle macchine virtuali in Azure usando il set di disponibilità.
Zone di disponibilità di Azure
Azure sta implementando un concetto di azure zone di disponibilità in diverse aree di Azure. Nelle aree di Azure in cui sono disponibili le zone di disponibilità, le aree di Azure dispongono di più data center, indipendenti per fornitura di alimentazione, raffreddamento e rete. Il motivo alla base dell'offerta di diverse zone all'interno di una singola area di Azure è quello di consentire la distribuzione delle applicazioni tra le due o tre zone di disponibilità offerte. Supponendo che i problemi relativi alle fonti di alimentazione e/o alla rete interessino solo un'infrastruttura della zona di disponibilità, la distribuzione dell'applicazione in un'area di Azure è ancora pienamente funzionale. La capacità potrebbe risultare ridotta dal momento che alcune macchine virtuali in una zona potrebbero andare perse. Tuttavia, le macchine virtuali nelle altre due zone sono ancora pienamente funzionanti. Le aree di Azure che offrono le zone sono elencate in Zone di disponibilità di Azure.
Quando si usa zone di disponibilità, è necessario considerare alcuni aspetti. Ad esempio:
- Non è possibile distribuire set di disponibilità di Azure all'interno di una zona di disponibilità. Solo la possibilità di combinare set di disponibilità e zone di disponibilità è con gruppi di posizionamento di prossimità. Per altre informazioni, vedere l'articolo Combinare set di disponibilità e zone di disponibilità con gruppi di posizionamento di prossimità.
- Non è possibile usare Load Balancer Basic per creare soluzioni cluster di failover basate sui servizi cluster di failover di Windows o su Linux Pacemaker. È invece necessario usare lo SKU Load Balancer Standard di Azure.
- Azure zone di disponibilità non garantisce alcuna distanza certa tra le diverse zone all'interno di un'area.
- La latenza di rete tra diverse zone di disponibilità di Azure in diverse aree di Azure potrebbe essere diversa per ogni area di Azure. In alcuni casi, in cui un cliente può ragionevolmente eseguire il livello dell'applicazione SAP distribuito in zone diverse, poiché la latenza di rete da una zona alla macchina virtuale DBMS attiva è comunque accettabile a causa di un impatto sui processi aziendali. Mentre potrebbero esserci scenari dei clienti in cui la latenza tra la macchina virtuale DBMS attiva in una zona e un'istanza dell'applicazione SAP in una macchina virtuale in un'altra zona può essere troppo intrusiva e non accettabile per i processi aziendali SAP. Di conseguenza, le architetture di distribuzione devono essere diverse con un'architettura attivo/attivo per l'applicazione o attivo/passivo se la latenza è troppo elevata.
- L'uso di Dischi gestiti di Azure è obbligatorio per la distribuzione in Azure zone di disponibilità.
Set di scalabilità di macchine virtuali con orchestrazione flessibile
In Azure, set di scalabilità di macchine virtuali con orchestrazione flessibile offre un mezzo per ottenere la disponibilità elevata per i carichi di lavoro SAP, analogamente ad altri framework di distribuzione, ad esempio set di disponibilità e zone di disponibilità. Con un set di scalabilità flessibile, le macchine virtuali possono essere distribuite tra diverse zone di disponibilità e domini di errore, rendendole un'opzione adatta per la distribuzione di carichi di lavoro SAP a disponibilità elevata.
Il set di scalabilità di macchine virtuali con orchestrazione flessibile offre la flessibilità necessaria per creare il set di scalabilità all'interno di un'area o estenderlo tra le zone di disponibilità. Durante la creazione, il set di scalabilità flessibile all'interno di un'area con platformFaultDomainCount>1 (FD>1), le macchine virtuali distribuite nel set di scalabilità verranno distribuite tra il numero specificato di domini di errore nella stessa area. D'altra parte, la creazione del set di scalabilità flessibile tra zone di disponibilità con platformFaultDomainCount=1 (FD=1) distribuirà le macchine virtuali tra zone diverse e il set di scalabilità distribuirà anche le macchine virtuali tra domini di errore diversi all'interno di ogni zona per un'operazione ottimale. Per il carico di lavoro SAP è supportato solo un set di scalabilità flessibile con FD=1.
Il vantaggio dell'uso di set di scalabilità flessibili con FD=1 per la distribuzione tra zone, invece della distribuzione tradizionale della zona di disponibilità consiste nel fatto che le macchine virtuali distribuite con il set di scalabilità verranno distribuite tra domini di errore diversi all'interno della zona in modo ottimale. Per evitare le limitazioni associate all'uso del gruppo di posizionamento di prossimità per garantire la disponibilità delle macchine virtuali in tutti i data center di Azure o in ogni colonna vertebrale di rete, è consigliabile distribuire il carico di lavoro SAP tra zone di disponibilità usando un set di scalabilità flessibile con FD=1. Questa strategia di distribuzione garantisce che le macchine virtuali distribuite in ogni zona non siano limitate a un singolo data center o colonna dorsale di rete e che tutti i componenti di sistema SAP, ad esempio database, ASCS/ERS e il livello applicazione siano limitati a livello di zona.
Pertanto, per la nuova distribuzione del carico di lavoro SAP tra zone di disponibilità, è consigliabile usare un set di scalabilità flessibile con FD=1. Per altre informazioni, vedere il documento set di scalabilità di macchine virtuali per il carico di lavoro SAP.
Manutenzione pianificata e non pianificata delle macchine virtuali
Due tipi di eventi della piattaforma Azure possono influire sulla disponibilità delle macchine virtuali:
- Gli eventi di manutenzione pianificata sono gli aggiornamenti periodici eseguiti da Microsoft per la piattaforma Azure sottostante. Gli aggiornamenti migliorano l'affidabilità, le prestazioni e la sicurezza complessive dell'infrastruttura della piattaforma su cui vengono eseguite le macchine virtuali.
- Gli eventi di manutenzione non pianificata hanno luogo quando si verifica un guasto dell'hardware o dell'infrastruttura fisica sottostante la macchina virtuale. Può trattarsi, ad esempio, di errori della rete locale, guasti di un disco locale o altri errori a livello di rack. Quando viene rilevato un errore di questo tipo, la piattaforma Azure esegue automaticamente la migrazione della macchina virtuale dal server fisico non integro su cui è in esecuzione a un server fisico integro. Anche se rari, questi eventi possono anche richiedere il riavvio della macchina virtuale.
Per altre informazioni, vedere Manutenzione delle macchine virtuali in Azure.
Azure Storage redundancy (Ridondanza di Archiviazione di Azure)
I dati dell'account di archiviazione vengono sempre replicati per assicurare durabilità e disponibilità elevata nonché il rispetto del contratto di servizio di Archiviazione di Azure anche in caso di errori hardware temporanei.
Dato che Archiviazione di Azure mantiene tre immagini dei dati per impostazione predefinita, l'uso di RAID 5 o RAID 1 su più dischi di Azure non è necessario.
Per altre informazioni, vedere Replica di Archiviazione di Azure.
Azure Managed Disks
Managed Disks è un tipo di risorsa in Azure Resource Manager, è un'opzione di archiviazione consigliata anziché dischi rigidi virtuali archiviati negli account di archiviazione di Azure. I dischi gestiti sono allineati automaticamente a un set di disponibilità di Azure della macchina virtuale a cui sono collegati. e aumentano la disponibilità della macchina virtuale e dei servizi eseguiti su di essa.
Per altre informazioni, vedere Panoramica del servizio Managed Disks.
Si consiglia di usare i dischi gestiti, perché semplificano la distribuzione e la gestione delle macchine virtuali.
Confronto tra diversi tipi di distribuzione per il carico di lavoro SAP
Ecco un breve riepilogo dei vari tipi di distribuzione disponibili per i carichi di lavoro SAP.
| Funzionalità | Set di scalabilità di macchine virtuali con orchestrazione flessibile (FD=1) | Availability Zone (Zona di disponibilità) | Set di disponibilità |
|---|---|---|---|
| Comportamento della distribuzione | Le istanze si trovano in 1, 2 o 3 zone di disponibilità e distribuite tra rack diversi all'interno di ogni zona al massimo sforzo | Le istanze vengono spostate in 1, 2 o 3 zone di disponibilità | Le istanze si trovano all'interno dell'area e distribuite in un dominio di errore/aggiornamento diverso |
| Assegnare macchine virtuali e dischi gestiti a una zona di disponibilità specifica | Sì | Sì | No |
| Dominio di errore - Distribuzione massima (Azure distribuirà al massimo le istanze) | Sì | No | Sì, in base al numero di domini di errore definiti durante la creazione. |
| Allineamento del dominio di errore di calcolo nell'archiviazione | No | No | Sì |
| Prenotazione della capacità | Sì (assegnare la prenotazione della capacità a livello di macchina virtuale) | Sì | Numero |
Nota
- I domini di aggiornamento sono stati deprecati in modalità orchestrazione flessibile. Per altre informazioni, vedere Eseguire la migrazione di distribuzioni e risorse a set di scalabilità di macchine virtuali in Orchestrazione flessibile
- Per altre informazioni sull'allineamento da calcolo a dominio di errore di archiviazione, vedere Scelta del numero corretto di domini di errore per il set di scalabilità di macchine virtuali e Funzionamento dei set di disponibilità.
- Per abilitare la prenotazione della capacità, è importante controllare le limitazioni e le restrizioni della prenotazione della capacità.
Opzioni di distribuzione a disponibilità elevata per il carico di lavoro SAP
Quando si distribuisce un carico di lavoro SAP a disponibilità elevata in Azure, è importante prendere in considerazione i vari tipi di distribuzione disponibili e come possono essere applicati in aree di Azure diverse, ad esempio tra zone, in una singola zona o in un'area senza zone. La tabella seguente illustra diverse opzioni di disponibilità elevata per i sistemi SAP nelle aree di Azure.
| Tipo di sistema | Tra zone diverse in un'area | In una zona singe di un'area | In un'area senza zone |
|---|---|---|---|
| Sistema SAP a disponibilità elevata | Set di scalabilità flessibile con FD=1 | Set di disponibilità con gruppi di posizionamento di prossimità | Set di disponibilità |
| Set di disponibilità e zone di disponibilità con gruppi di posizionamento di prossimità | Set di scalabilità flessibile con FD=1 (selezionare una sola zona) | Set di scalabilità flessibile con FD=1 (nessuna zona è definita) | |
| Zone di disponibilità | Set di disponibilità |
- Distribuzione tra zone diverse in un'area: per la massima disponibilità, i sistemi SAP devono essere distribuiti in zone diverse in un'area. In questo modo si garantisce che se una zona non è disponibile, il sistema SAP continua a essere disponibile in un'altra zona. Se si distribuisce un nuovo carico di lavoro SAP tra zone di disponibilità, è consigliabile usare un set di scalabilità di macchine virtuali flessibile con l'opzione di distribuzione FD=1. Consente di distribuire più macchine virtuali in zone diverse in un'area senza doversi preoccupare dei vincoli di capacità o dei gruppi di posizionamento. Il framework del set di scalabilità assicura che le macchine virtuali distribuite con il set di scalabilità vengano distribuite tra domini di errore diversi all'interno della zona in modo ottimale. Tutti i componenti SAP a disponibilità elevata, ad esempio SAP ASCS/ERS, i database SAP vengono distribuiti in zone diverse, mentre più server applicazioni in ogni zona vengono distribuiti in un dominio di errore diverso in base al massimo sforzo.
- Distribuzione in una singola zona di un'area: per distribuire il sistema SAP a disponibilità elevata a livello di area in una località con più zone di disponibilità e se è essenziale per tutti i componenti del sistema trovarsi in una singola zona, è consigliabile usare i set di disponibilità con l'opzione di distribuzione Gruppi di posizionamento di prossimità. Questo approccio consente di raggruppare tutti i componenti di sistema SAP in una singola zona di disponibilità, assicurandosi che le macchine virtuali all'interno del set di disponibilità vengano distribuite in domini di errore e di aggiornamento diversi. Anche se questa distribuzione allinea il calcolo ai domini di errore di archiviazione, la prossimità non è garantita. Tuttavia, poiché questa opzione di distribuzione è a livello di area, non supporta Azure Site Recovery per il ripristino di emergenza da zona a zona. Inoltre, questa opzione limita l'intera distribuzione SAP a un data center, che può causare limitazioni di capacità se è necessario modificare le dimensioni dello SKU o le istanze dell'applicazione con scalabilità orizzontale.
- Distribuzione in un'area senza zone: se si distribuisce il sistema SAP in un'area in cui non sono presenti zone, è consigliabile usare i set di disponibilità. Questa opzione offre ridondanza e tolleranza di errore inserendo macchine virtuali in domini di errore e domini di aggiornamento diversi.
Importante
Si noti che le opzioni di distribuzione per le aree di Azure sono solo suggerimenti. La strategia di distribuzione più adatta per il sistema SAP dipenderà dai requisiti e dall'ambiente specifici.
Uso della disponibilità elevata dell'infrastruttura di Azure per proteggere le applicazioni SAP
Se si decide di non usare funzionalità come WSFC o Pacemaker in Linux (supportate per SU edizione Standard Linux Enterprise Server 12 e versioni successive e Red Hat Enterprise Linux 7 e versioni successive), viene usato il riavvio della macchina virtuale di Azure. Ripristina le funzionalità nei sistemi SAP se sono presenti tempi di inattività pianificati e non pianificati dell'infrastruttura server fisica di Azure e della piattaforma Azure sottostante complessiva.
Per altre informazioni sull'approccio, vedere Usare il riavvio delle macchine virtuali dell'infrastruttura di Azure per ottenere una maggiore disponibilità del sistema SAP.
Disponibilità elevata di applicazioni SAP in Azure IaaS
Per ottenere una disponibilità elevata completa del sistema SAP, è necessario proteggere tutti i componenti SAP critici del sistema. Ad esempio:
- Server di applicazioni SAP ridondanti.
- Componenti univoci. Un esempio potrebbe essere un componente singolo punto di guasto (SPOF), come un'istanza di SAP ASCS/SCS o un sistema di gestione di database (DBMS).
Le sezioni seguenti illustrano come ottenere la disponibilità elevata per tutti e tre i componenti critici del sistema SAP.
Architettura di disponibilità elevata per i server applicazioni SAP
Windows e
Linux
In genere non è necessaria una specifica soluzione a disponibilità elevata per le istanze del server applicazioni SAP e le istanze di dialogo. La disponibilità elevata si ottiene tramite la ridondanza e si dovranno configurare più istanze di dialogo in varie istanze di macchine virtuali di Azure. È necessario avere almeno due istanze dell'applicazione SAP installate in due istanze di macchine virtuali di Azure.
A seconda del tipo di distribuzione (set di scalabilità flessibile con FD=1, zona di disponibilità o set di disponibilità), è necessario distribuire le istanze del server applicazioni SAP di conseguenza per ottenere la ridondanza.
- Set di scalabilità flessibile con platformFaultDomainCount=1 (FD=1): i server applicazioni SAP distribuiti con set di scalabilità flessibile (FD=1) distribuiscono le macchine virtuali in zone di disponibilità diverse e il set di scalabilità distribuisce anche le macchine virtuali tra domini di errore diversi all'interno di ogni zona per un'operazione ottimale. In questo modo, se una zona non è disponibile, i server applicazioni SAP distribuiti in un'altra zona continuano a essere disponibili.
- Zona di disponibilità: i server applicazioni SAP distribuiti tra zone di disponibilità assicurano che le macchine virtuali si estendono in zone diverse per ottenere la ridondanza. In questo modo, se una zona non è disponibile, i server applicazioni SAP distribuiti in un'altra zona continuano a essere disponibili. Per altre informazioni, vedere Configurazioni del carico di lavoro SAP con Azure zone di disponibilità
- Set di disponibilità: i server applicazioni SAP distribuiti nel set di disponibilità assicurano che le macchine virtuali vengano distribuite in domini di errore e domini di aggiornamento diversi. Quando si inseriscono macchine virtuali in domini di aggiornamento diversi, assicurarsi che le macchine virtuali non vengano aggiornate contemporaneamente durante i tempi di inattività di manutenzione pianificata. Mentre l'inserimento di macchine virtuali in un dominio di errore diverso garantisce che la macchina virtuale sia protetta da errori hardware o interruzioni dell'alimentazione all'interno di un data center. Tuttavia, il numero di domini di errore e aggiornamento che è possibile usare nel set di disponibilità di Azure all'interno di un'unità di scala di Azure è finito. Se si continua ad aggiungere macchine virtuali a un singolo set di disponibilità, due o più macchine virtuali finirebbero nello stesso dominio di errore o aggiornamento. Per altre informazioni, vedere la sezione Set di disponibilità di Azure del documento Guida alla pianificazione e all'implementazione di macchine virtuali di Azure per SAP NetWeaver.
Solo dischi non gestiti: quando si usano dischi non gestiti con set di disponibilità, è importante riconoscere che l'account di archiviazione di Azure diventa un singolo punto di errore. Pertanto, è imperativo posses almeno due account di archiviazione di Azure, in cui vengono distribuite almeno due macchine virtuali. In una configurazione ideale, il disco di ogni macchina virtuale che esegue l'istanza di una finestra di dialogo SAP verrà distribuito in un account di archiviazione diverso.
Importante
Si consiglia di usare Azure Managed Disks per le installazioni di SAP a disponibilità elevata. Dato che i dischi gestiti si allineano automaticamente al set di disponibilità della macchina virtuale a cui sono collegati, aumentano la disponibilità della macchina virtuale e dei servizi in esecuzione su di essa.
Architettura di disponibilità elevata per un'istanza di SAP ASCS/SCS in Windows
È possibile usare una soluzione WSFC per proteggere l'istanza di SAP ASCS/SCS. In base al tipo di configurazione della condivisione cluster (condivisione file o disco condiviso), è possibile fare riferimento alla soluzione appropriata in base al tipo di archiviazione.
Condivisione cluster - Condivisione file
Condivisione cluster - Disco condiviso
Architettura di disponibilità elevata per un'istanza di SAP ASCS/SCS in Linux
In Linux, la configurazione del clustering di istanze di SAP ASCS/SCS dipende dalla distribuzione del sistema operativo e dal tipo di archiviazione in uso. È consigliabile implementare la soluzione appropriata in base al framework del cluster del sistema operativo specifico.
SUSE Linux Enterprise Server (SLES)
- Disponibilità elevata dell'istanza di SAP ASCS/SCS con NFS con montaggio semplice.
- Disponibilità elevata dell'istanza di SAP ASCS/SCS usando NFS in File di Azure.
- Disponibilità elevata dell'istanza di SAP ASCS/SCS con NFS in Azure NetApp Files.
- Disponibilità elevata dell'istanza di SAP ASCS/SCS tramite il server NFS.
Red Hat Enterprise Linux (RHEL)
Configurazione multi-SID dell'istanza di SAP ASCS/SCS con cluster di SAP NetWeaver
La configurazione multi-SID è supportata con WSFC, tramite la condivisione file e il disco condiviso. Per altre informazioni sull'architettura di disponibilità elevata multi-SID in Windows, vedere:
- Condivisione file: disponibilità elevata multi-SID dell'istanza di SAP ASCS/SCS per Windows Server Failover Clustering e condivisione file.
- Disco condiviso: disponibilità elevata multi-SID dell'istanza di SAP ASCS/SCS per Windows Server Failover Clustering e disco condiviso.
Il clustering multi-SID è supportato nei cluster Linux Pacemaker per SAP ASCS/ERS, limitatamente a cinque SID SAP nello stesso cluster. Per altre informazioni sull'architettura di disponibilità elevata multi-SID in Linux, vedere:
- SU edizione Standard Linux Enterprise Server (SLES): disponibilità elevata per SAP NW in macchine virtuali di Azure in SLES per applicazioni SAP con più SID.
- Red Hat Linux Enterprise (RHEL): disponibilità elevata per SAP NW in macchine virtuali di Azure in RHEL per applicazioni SAP con più SID.
Disponibilità elevata dell'istanza DBMS
In un sistema SAP, anche i server DBMS come singolo punto di errore. È quindi importante proteggere il database implementando una soluzione a disponibilità elevata. La soluzione a disponibilità elevata di DBMS varia in base al database usato per il sistema SAP. In base al database, seguire le linee guida per ottenere una disponibilità elevata nel database.
| Database | Raccomandazione sul ripristino di emergenza |
|---|---|
| SAP HANA | Replica di sistema HANA (HSR) |
| Oracle | Oracle Data Guard |
| IBM DB2 | Ripristino di emergenza a disponibilità elevata (HADR) |
| Microsoft SQL | Microsoft SQL AlwaysOn |
| SAP ASE | A edizione Standard HADR AlwaysOn |