Il sizing si misura in SAPS, non in core

Il primo errore di un progetto SAP su Azure è ragionare in vCPU e GB di RAM. L’unità di misura del mondo SAP è il SAPS (SAP Application Performance Standard), un indice di throughput applicativo derivato dal benchmark SD che descrive quanto lavoro un sistema riesce a smaltire, indipendentemente dall’hardware sottostante. Serve esattamente a questo: rendere confrontabili macchine diverse. Un server on-premise di cinque anni fa e una VM Azure di oggi si parlano solo attraverso i SAPS, perché il rapporto fra core fisici e capacità elaborativa non è costante nel tempo né fra piattaforme.

Per un sistema esistente (brownfield) i SAPS si ricavano dal comportamento reale: i report di workload del sistema (ST03 e affini), gli EarlyWatch Alert, l’andamento del carico su un periodo abbastanza lungo da includere chiusure e picchi stagionali. Per un impianto nuovo (greenfield) si parte dal sizing SAP — Quick Sizer e i report di sizing dedicati a HANA — che traduce utenti, moduli e volumi di documenti in SAPS e in fabbisogno di memoria. In entrambi i casi il risultato dell’assessment non è “una VM”, ma un requisito: SAPS necessari, memoria, un profilo di IOPS/throughput/latenza per il database e il vincolo di prossimità fra application server e DB. Il criterio d’esame è che si dimensiona sul picco sostenuto, non sulla media, e che il sizing dell’application layer e quello del database sono due esercizi distinti.

La certificazione SAP filtra le opzioni prima del costo

Non tutte le VM Azure sono utilizzabili per SAP. Sono supportate solo le famiglie e le size certificate da SAP per quel prodotto e per quel database, e la certificazione vale per combinazione: una size può essere certificata per SAP NetWeaver ma non per HANA come DB, oppure certificata per HANA solo con un sistema operativo e una configurazione di storage precisi. I riferimenti autoritativi sono la SAP Note dedicata ai tipi di VM Azure supportati e, per HANA, la Certified and Supported SAP HANA Hardware Directory, dove Microsoft pubblica anche i SAPS certificati per size.

La conseguenza pratica è che la certificazione è un filtro che si applica prima di ogni valutazione di costo o di prestazioni. Una size più economica che soddisfa i SAPS calcolati ma non compare in elenco non è “meno supportata”: è fuori supporto, e in uno scenario d’esame questa è la discriminante che invalida una risposta altrimenti plausibile.

Azure Migrate: discovery e assessment, non l’ultima parola

Azure Migrate è lo strumento per la scoperta e la valutazione del landscape esistente: inventario di server, dipendenze fra application server, database, interfacce e sistemi satellite, assessment basato sui dati di performance raccolti nel tempo, right-sizing e stima dei costi. È il modo corretto per costruire le migration wave e per capire che cosa si porta davvero in cloud.

Il limite, e l’esame lo sfrutta, è che il suo right-sizing è generico: ragiona su utilizzo di CPU, memoria e disco, non su SAPS né sulla lista delle VM certificate. La proposta di Azure Migrate va quindi sempre riconciliata con il sizing SAP e intersecata con le configurazioni certificate; l’ordine è discovery → SAPS → filtro di certificazione → scelta finale alla luce di storage, rete e requisiti HA. Per il deploy e la gestione conformi del landscape si guarda poi ad Azure Center for SAP solutions.

Quando la VM non basta: Azure Large Instances

Se il footprint di memoria richiesto da HANA supera quanto offrono le VM certificate più grandi, l’opzione è SAP HANA on Azure Large Instances: hardware bare-metal dedicato, ospitato in stanze adiacenti alle region e collegato alla VNet del cliente. Il trade-off è netto — nessuna elasticità, provisioning contrattuale a termine, modello operativo e meccanismi di HA/DR propri, diversi da quelli di una VM. Poiché le famiglie memory-optimized certificate hanno coperto footprint via via maggiori, la prima verifica resta sempre se il requisito rientra ancora in una VM certificata; la disponibilità corrente dell’offerta Large Instances va confermata sulla documentazione ufficiale.

Trappole tipiche d’esame

  • Il cliente fornisce core e RAM del sistema on-premise → traduci in SAPS: copiare la configurazione hardware è una risposta distrattore; la migrazione del sizing passa dal throughput misurato, non dalla parità di core.
  • Azure Migrate propone una size più economica → verificane la certificazione: il right-sizing automatico ignora l’elenco SAP; se la size non è certificata per quel carico e quel DB, la proposta va scartata a prescindere dal risparmio.
  • Size certificata per NetWeaver usata come host HANA → la certificazione è per combinazione: prodotto, ruolo (application vs database), sistema operativo e layout di storage fanno parte del vincolo, non solo il nome della VM.
  • Sizing costruito sulla media di utilizzo → dimensiona sul picco sostenuto: medie mensili nascondono chiusure e batch notturni; l’assessment deve coprire un periodo rappresentativo.
  • Requisito di memoria HANA fuori scala → prima VM certificate, poi Large Instances: proporre subito il bare-metal quando esiste una VM certificata adeguata è sbagliato quanto forzare una VM su un footprint che non regge.
  • Assessment fermo a CPU e memoria → mancano storage e latenza: IOPS, throughput e latenza per /hana/data e /hana/log, oltre alla vicinanza fra application server e database, fanno parte del dimensionamento tanto quanto i SAPS.