Che cosa chiede davvero il carico

Davanti a una domanda sullo storage l’esame non vuole sapere quanti terabyte servono, ma quale grandezza fisica è il vincolo. Il volume di log scrive record piccoli in modo sincrono: ogni commit attende l’acknowledgement, quindi la variabile critica è la latenza di scrittura, non la banda. Il volume dati lavora a blocchi grandi durante savepoint, restore e ricarica dei dati in memoria: qui conta il throughput aggregato. File system come /hana/shared, /sapmnt e la transport directory devono invece essere montati da più nodi contemporaneamente, cosa che nessun managed disk offre: un disco resta attached a una sola VM per volta. La regola implicita di quasi tutte le domande: classifica il requisito (latency-bound, throughput-bound, shared access) e solo dopo scegli la tecnologia.

Managed disk: Premium è la base, Ultra Disk l’eccezione

I Premium SSD coprono la maggioranza dei deployment SAP e restano la scelta di default. Due leve fanno gran parte del lavoro: lo striping con LVM o mdadm, che somma IOPS e throughput di più dischi, e l’host caching, da impostare in modo diverso per volume dati e volume log — una cache di scrittura sotto il redo log è un errore classico. Sulle VM della famiglia M il Write Accelerator abbatte la latenza di scrittura del log su Premium SSD.

L’Ultra Disk entra quando il Premium non regge: latenza costantemente bassa e IOPS o throughput fuori dalla sua portata. La caratteristica distintiva è che capacità, IOPS e throughput si configurano in modo indipendente e si modificano senza rifare il layout: ideale per un volume di log piccolo ma velocissimo. In cambio ha vincoli: disponibilità limitata per region e zona, dipendenza dalla dimensione della VM, nessun host caching (che le domande usano come distrattore). Premium SSD v2 è la via di mezzo che disaccoppia prestazioni e capacità: se compare fra le opzioni, chiediti se il requisito giustifica davvero l’Ultra.

Azure NetApp Files: quando il file system va condiviso

Azure NetApp Files non è “un disco più veloce”: è un servizio di file storage NFS/SMB. Lo scegli quando il requisito è accesso condiviso da più nodi — /hana/shared in uno scale-out, /sapmnt e la global directory di un cluster ASCS/ERS, la transport directory — oppure quando servono prestazioni elevate senza gestire striping e caching sulla VM. Su HANA supporta anche /hana/data e /hana/log via NFSv4.1, tipico dello scale-out e degli ambienti che vogliono snapshot a livello di storage.

Il dimensionamento passa dal capacity pool: scegli un service level (Standard, Premium, Ultra) e una quota, e il throughput disponibile ai volumi deriva da questa combinazione. Conta anche la collocazione: volume e VM devono stare vicini, altrimenti la latenza vanifica il service level che stai pagando. Per il DR il servizio offre replica cross-region e cross-zone, cosa diversa da HANA System Replication.

Dimensionare partendo dalle prestazioni

Il principio da portare all’esame è che capacità e velocità si comprano insieme: con i managed disk sono tier e dimensione a determinare IOPS e throughput, con ANF service level e quota del pool. Un volume dimensionato sullo spazio occupato è quindi quasi sempre sotto-dimensionato sulle prestazioni: si parte dal requisito di I/O — sizing SAPS, misure del sistema esistente, configurazioni certificate per HANA — e la capacità arriva di conseguenza, spesso in eccesso rispetto ai dati reali. Limiti e configurazioni supportate vanno verificati sulla documentazione Microsoft e sulle SAP Note.

Trappole tipiche d’esame

  • Latenza sul redo log oltre il tollerabile con Premium SSD → Ultra Disk: il log è latency-bound; ingrandire il volume dati o alzare il caching non risponde al requisito.
  • Più nodi devono montare la stessa directory → Azure NetApp Files (o Azure Files NFS): un Azure shared disk serve a un cluster a blocchi con file system cluster-aware, non a esporre una share NFS.
  • Servono più IOPS ma lo spazio abbonda già → striping o cambio di tier: «aumenta la dimensione del disco» funziona solo perché le prestazioni scalano con la capacità, ed è l’opzione più costosa.
  • Il volume ANF non regge il throughput richiesto → agisci su service level e quota del capacity pool: la banda non si aggiunge al singolo volume indipendentemente dal pool.
  • /hana/shared in uno scale-out → file system condiviso, non dischi locali per nodo: una copia per nodo rompe il modello operativo.
  • Volume dati che deve reggere restore veloci → throughput aggregato con striping e caching di lettura: qui l’Ultra Disk è spesso sovradimensionato rispetto a un layout Premium ben progettato.