Che cosa protegge ciascun livello dell’infrastruttura
La prima domanda da farsi davanti a uno scenario di alta disponibilità non è “quale servizio uso”, ma “da quale guasto mi devo difendere”. Ogni costrutto Azure copre un raggio diverso e non si sostituisce agli altri.
L’availability set distribuisce le VM su fault domain e update domain distinti dentro un singolo datacenter: protegge dal guasto di un rack (alimentazione, rete, storage condiviso) e dalla manutenzione pianificata della piattaforma, che non colpisce mai tutti gli update domain insieme. Non protegge dalla perdita del datacenter.
L’availability zone distribuisce le VM su datacenter fisicamente separati dentro la stessa region: protegge dalla perdita di un intero datacenter. Il prezzo è una latenza fra zone superiore a quella intra-zona, che va misurata perché il collegamento fra application server e database SAP è sensibile: se il test di latenza non è soddisfacente, la coppia application server/DB va tenuta in zona con proximity placement group e la ridondanza si costruisce replicando la coppia in un’altra zona.
La region secondaria protegge dalla perdita della region: è il piano di disaster recovery, non di alta disponibilità, e implica un RPO diverso da zero perché la replica diventa asincrona.
Attenzione: un availability set non può contenere VM zonali. Sono modelli alternativi, non componibili sulla stessa VM.
I SAP Central Services sono il punto singolo di guasto
In un impianto SAP gli application server (PAS e AAS) sono già ridondabili per moltiplicazione: se ne aggiungono altri, distribuiti su zone diverse, e i logon group bilanciano gli utenti. Non serve un cluster.
I SAP Central Services (ASCS/SCS) no: message server ed enqueue server sono unici per sistema, e la perdita delle lock table blocca l’impianto. La soluzione standard è renderli un servizio clusterizzato, affiancato dall’Enqueue Replication Server che mantiene una copia delle lock su un altro nodo. A questo si aggiunge una share condivisa altamente disponibile per /sapmnt e le directory globali, tipicamente su Azure NetApp Files (NFS su Linux, SMB su Windows) o su una soluzione file condivisa equivalente.
Pacemaker con fencing oppure Windows Server Failover Cluster
Su Linux il cluster è Pacemaker (SLES o RHEL, con le estensioni HA supportate). Il pezzo che l’esame verifica davvero è il fencing: senza uno STONITH funzionante il cluster non è supportato, perché nulla impedisce a due nodi che si sono persi di vista di scrivere entrambi sulle stesse risorse — lo split-brain. Le due strade sono l’Azure fence agent, che chiama il control plane di Azure per spegnere il nodo sospetto usando un’identità registrata in Microsoft Entra ID con un ruolo dedicato, e SBD, che usa dispositivi a blocchi condivisi e richiede infrastruttura aggiuntiva. L’Azure fence agent dipende dalla raggiungibilità degli endpoint di gestione Azure: se la connettività in uscita non è garantita, il fencing fallisce proprio quando serve.
Su Windows il ruolo lo svolge il Windows Server Failover Cluster, con quorum da configurare (cloud witness è l’opzione tipica in Azure) e storage condiviso o share SMB per i file globali. In entrambi i casi il virtual hostname del cluster non funziona con il gratuitous ARP: serve un internal load balancer con floating IP e probe sulla porta corretta.
La replica del database
Il database non si protegge con il cluster: si protegge con la replica nativa, che il cluster eventualmente automatizza. Su SAP HANA è HANA System Replication, con modalità sincrona per la coppia in alta disponibilità dentro la region e asincrona verso la region di DR; le configurazioni multi-target permettono di avere entrambe. Il failover automatico però arriva da Pacemaker che pilota HSR: HSR da sola replica e basta. Su SQL Server si usano gli availability group Always On, sincroni con failover automatico per l’HA e asincroni per il DR, appoggiati a WSFC. Azure Site Recovery resta l’opzione per il livello applicativo e per le VM senza replica nativa, non per i database SAP produttivi; e Azure Backup for SAP HANA è protezione del dato, non continuità di servizio.
Trappole tipiche d’esame
- Il carico deve sopravvivere alla perdita di un datacenter nella region → availability zone: l’availability set copre rack e manutenzione dentro un datacenter, non la perdita del sito. Se la region non offre zone, la risposta corretta ripiega su availability set più DR cross-region.
- HANA System Replication configurata, failover richiesto automatico → serve anche Pacemaker: la replica sposta i dati, non promuove il secondario né muove l’IP virtuale. Senza cluster il takeover è manuale.
- Cluster Pacemaker in Azure senza connettività in uscita verso il control plane → fencing rotto: l’Azure fence agent non riesce a spegnere il nodo isolato. Vanno previste outbound rule, NAT gateway o l’alternativa SBD.
- Application server SAP “da mettere in cluster” → distraente: i dialog instance si rendono ridondanti aggiungendo istanze su zone diverse e usando i logon group. Il cluster serve ad ASCS/SCS e, con la replica, al database.
- Backup configurato, quindi HA coperta → falso: Azure Backup for SAP HANA risponde a RPO/retention e a errori logici, non evita il fermo del servizio.
- Latenza fra application tier e DB tier fuori soglia in configurazione multi-zona → proximity placement group: si accorpano i componenti nella stessa zona e si replica la coppia altrove, invece di sparpagliare i tier fra zone diverse.