Il costo si governa dopo il go-live
Il conto di un landscape SAP non si decide in fase di progetto: si decide nei mesi di esercizio successivi, agendo su tre leve indipendenti fra loro.
La prima è il tempo di accensione. Gli ambienti non produttivi — sandbox, sviluppo, QAS, formazione — vengono usati in fasce orarie prevedibili: deallocare le VM fuori orario azzera il costo di calcolo, mentre i dischi continuano a essere fatturati (il risparmio è quindi parziale ma sostanzioso). Va fermata in modo pulito l’istanza SAP prima di deallocare la macchina, non spenta la macchina sotto un sistema attivo. La produzione, per definizione, non rientra in questa leva.
La seconda sono le Azure Reservations e i savings plan: sconto in cambio di un impegno pluriennale. Convengono dove il consumo è stabile e prevedibile — la produzione, il database che gira 24/7, le Azure Large Instances — e sono l’impegno sbagliato per una risorsa accesa poche ore al giorno o destinata a essere ridimensionata a breve. La regola di lettura da portare all’esame: reservation per ciò che è sempre acceso, schedulazione di spegnimento per ciò che è acceso a intermittenza; sulla stessa risorsa le due strategie non si sommano.
La terza è il diritto d’uso delle licenze già possedute: Azure Hybrid Benefit consente di riusare licenze Windows Server e SQL Server con Software Assurance, e si applica anche alle subscription RHEL e SLES. In un confronto di costo, il prezzo con licenza inclusa e quello con licenza propria non sono comparabili: se lo scenario dice che il cliente ha già le licenze, l’ipotesi corretta è quella che le valorizza.
Rightsizing: si parte larghi, si corregge dopo
Il sizing iniziale nasce da un assessment (SAP Quick Sizer per i sistemi nuovi, dati di consumo reali per una migrazione) e viene quasi sempre arrotondato per eccesso, perché nessuno vuole rischiare il go-live. È esattamente lì che si nasconde il margine di recupero più grande: dopo qualche mese si confrontano le metriche reali — CPU, memoria, IO — con la taglia scelta e si scende di misura dove il carico non c’è.
Due vincoli non sono negoziabili. Primo: si resta dentro le VM certificate SAP e le configurazioni supportate (SAP Note 1928533 come riferimento); una VM più economica ma non certificata non è un’ottimizzazione, è un sistema fuori supporto. Secondo: il tier applicativo si dimensiona in SAPS, non in vCPU generiche, e HANA si dimensiona sulla memoria — un downsizing “che sembra equivalente” su una famiglia diversa può cambiare radicalmente i SAPS o i limiti di IO disponibili.
Storage: costo, throughput e latenza sono tre assi distinti
La scelta fra Premium SSD, Ultra Disk e Azure NetApp Files non si fa sul prezzo al gigabyte ma sul profilo di IO richiesto. Per /hana/log il parametro critico è la latenza in scrittura, non il throughput aggregato; per /hana/data conta la banda in lettura durante restart e caricamento. ANF è la scelta naturale quando servono share NFS condivise (/sapmnt, /usr/sap/trans, i mount di un cluster) o volumi HANA con snapshot integrati; Ultra Disk quando servono IOPS e latenza configurabili in modo indipendente dalla dimensione; Premium SSD, eventualmente con Write Accelerator sulle famiglie che lo supportano, per profili più ordinari. Attenzione al limite spesso dimenticato: la VM ha propri tetti di IOPS e throughput, quindi un disco più veloce sotto una VM già satura non produce alcun beneficio.
Individuare il collo di bottiglia prima di intervenire
Prima di cambiare qualcosa serve stabilire dove si perde tempo: calcolo, storage o rete. Le metriche di sistema operativo e le transazioni SAP di analisi del carico dicono se la CPU è satura o se il tempo è speso in attesa di IO; Azure Monitor for SAP solutions correla la vista Azure con quella SAP; HCMT serve a validare che lo storage rispetti i KPI attesi per HANA.
Il punto concettuale che l’esame verifica è che le leve non sono intercambiabili. Aumentare la taglia della VM non riduce la latenza di scrittura del log, e non riduce la distanza di rete fra application server e database: quella si governa collocando i tier vicini (stessa availability zone, eventualmente proximity placement group) e tenendo firewall e appliance fuori dal percorso applicativo. Ragiona sempre per criteri e confronti relativi — quale risorsa è satura, quale opzione offre latenza minore a parità di costo — perché numeri assoluti come SAPS, IOPS o listini cambiano, mentre i criteri restano. L’esame è disponibile solo in inglese, con soglia di superamento 700/1000.
Trappole tipiche d’esame
- Il DB risponde lentamente e viene proposto di ingrandire la VM → verifica prima dove si perde tempo: se l’attesa è su IO del log, la risposta è cambiare tipo di storage (Ultra Disk, ANF, Write Accelerator dove supportato), non salire di taglia; se la VM è già al suo tetto di IOPS, allora sì che la taglia conta.
- Carico di produzione costante 24/7 → reservation o savings plan: lo spegnimento programmato non è applicabile alla produzione; la leva corretta è l’impegno pluriennale sulla capacità.
- Ambienti dev/test usati solo in orario lavorativo → deallocazione schedulata, non reservation: impegnarsi su capacità accesa poche ore al giorno vanifica lo sconto; ricorda che i dischi restano a costo anche a VM deallocata.
- Serve una VM più economica per contenere i costi → resta nell’elenco certificato SAP: una taglia non certificata o una configurazione fuori nota SAP fa perdere il supporto, quindi non è mai la risposta corretta anche se il prezzo è migliore.
- Il cliente possiede già licenze Windows/SQL Server con Software Assurance → Azure Hybrid Benefit nel confronto: valutare i costi a prezzo pay-as-you-go con licenza inclusa falsa il paragone fra le opzioni.
- Latenza fra application server e database → avvicina i tier, non ingrandirli: un’appliance o un firewall interposto sul traffico app-DB e la dispersione fra region o zone lontane sono cause di latenza che nessuna dimensione di VM compensa.
- Sistema sovradimensionato da mesi → rightsizing sui dati di consumo reali: il sizing iniziale prudenziale va rivisto periodicamente con metriche osservate, non ricalcolato di nuovo sulle stime pre-migrazione.