Istanza gestita del database SQL di Azure è diventata disponibile a livello generale alla fine del 2018. Da allora, molte organizzazioni hanno iniziato a migrare a Istanza gestita per i vantaggi di un ambiente gestito. Le organizzazioni stanno sfruttando i backup gestiti, numerose funzionalità di sicurezza integrate, uno SLA di uptime del 99,99% e un ambiente sempre aggiornato in cui non sono più responsabili dell'applicazione di patch a SQL Server o al sistema operativo.
Una taglia non sempre adatto a tutti. Istanza gestita offre due livelli per le prestazioni. Lo scopo generale tier è progettato per applicazioni con requisiti di prestazioni e latenza I/O tipici e fornisce HA integrato. Il Business Critical tier è progettato per applicazioni che richiedono una bassa latenza di I/O e requisiti HA più elevati. Business Critical fornisce anche due secondari non leggibili e un secondario leggibile. Il secondario leggibile è un ottimo modo per distribuire il carico di lavoro dal primario, il che può abbassare il livello di servizio richiesto per il primario, diminuendo la spesa complessiva per l'istanza.
Quando l'istanza gestita è stata rilasciata per la prima volta, era possibile scegliere tra processori Gen4 e Gen5. Gen4 è ancora descritto nella documentazione, ma questa opzione non è per lo più disponibile ora. Per questo articolo, tratterò solo le configurazioni che utilizzano i processori Gen5.
Ogni livello di servizio supporta da 4 a 80 CPU logiche, note anche come core virtuali o vCore. La memoria viene allocata a circa 5,1 GB per vCore. Uso generico offre fino a 8 TB di archiviazione BLOB di Azure ad alte prestazioni, mentre Business Critical offre fino a 4 TB di archiviazione SSD locale super veloce.
Memoria
Avendo solo 5,1 GB di memoria per vCore, un'istanza con meno vCore potrebbe avere problemi. Le opzioni per le configurazioni vCore sono 4, 8, 16, 24, 32, 40, 64 e 80 vCore. Se esegui i calcoli su ciascuna delle opzioni vCore ((number of vCores) × (5.1 GB) ), otterrai le seguenti combinazioni core/memoria:
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
Per molte organizzazioni in cui ho aiutato la transizione da locale a Istanza gestita, ho riscontrato una significativa riduzione della memoria. Le configurazioni tipiche in locale sarebbero 4 vCore e 32 GB di memoria o 8 vCore e 64 GB. Entrambi rappresentano una riduzione di memoria superiore al 30%. Se l'istanza era già sotto pressione di memoria, ciò può causare problemi. Nella maggior parte dei casi, siamo stati in grado di ottimizzare l'istanza locale per alleviare la pressione della memoria prima di passare all'istanza gestita, ma in alcuni casi il cliente ha dovuto utilizzare un'istanza vCore superiore per alleviare la pressione della memoria .
Stoccaggio
L'archiviazione è un po' più difficile da pianificare e prendere in considerazione, a causa della necessità di considerare più fattori. Per l'archiviazione è necessario tenere conto dei requisiti di archiviazione complessivi sia per le dimensioni dello spazio di archiviazione che per le esigenze di I/O. Quanti GB o TB sono necessari per l'istanza di SQL Server e quanto deve essere veloce lo spazio di archiviazione? Quanti IOPS e quanto throughput utilizza l'istanza locale? A tal fine, è necessario basare il carico di lavoro corrente utilizzando perfmon per acquisire MB/s medi e massimi e/o acquisire snapshot di sys.dm_io_virtual_file_stats per acquisire l'utilizzo del throughput. Questo ti darà un'idea del tipo di I/O e del throughput di cui hai bisogno nel nuovo ambiente. Diversi clienti con cui ho lavorato hanno perso questa parte vitale della pianificazione della migrazione e hanno riscontrato problemi di prestazioni dovuti alla selezione di un livello di istanza che non supportava il loro carico di lavoro.
Questo è fondamentale per la baseline perché con i server locali, è comune avere lo storage fornito da una SAN super veloce con capacità di throughput elevate a macchine virtuali di dimensioni inferiori. In Azure, i limiti di IOPS e velocità effettiva sono determinati dalle dimensioni del nodo di calcolo e, nel caso di Manage Instance, dal numero di vCore allocati. Per scopi generici esiste un limite di 30-40.000 IOPS per istanza o da 500 a 12.500 IOPS per file a seconda delle dimensioni del file. Il throughput per file si basa anche su dimensioni che vanno da 100 MiB/s per file fino a 128 GB e fino a 480 MiB/s per file da 4 TB e più grandi. In Business Critical, gli IOPS vanno da 5,5 K a 110 K per istanza o 1.375 IOPS per vCore.
I consumer devono anche tenere conto del throughput di scrittura del log per l'istanza. General Purpose è 3 MB/s per vCore con un massimo di 22 MB/s per l'istanza e Business Critical è 4 MB/s per vCore con un massimo di 48 MB/s per l'intera istanza. Nella mia esperienza di lavoro con i clienti, molti hanno superato di gran lunga questi limiti per la velocità effettiva di scrittura. Per alcuni è stato uno spettacolo, per altri sono stati in grado di ottimizzare e modificare il proprio sistema per diminuire il carico.
Oltre alla necessità di conoscere il throughput complessivo e i requisiti di I/O, le dimensioni dello storage sono anche legate al numero di vCore scelti. Per scopi generali:
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Per aziende critiche:
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
Per scopi generici, una volta arrivati a 8 vCore, puoi massimizzare lo spazio di archiviazione disponibile, il che funziona bene per coloro che necessitano solo di scopi generici. Ma quando hai bisogno di Business Critical, le cose possono essere più difficili. Ho lavorato con molti clienti che hanno più TB allocati a macchine virtuali con 4, 8, 16 e 24 processori logici. Per ognuno di questi clienti, dovrebbero aumentare di almeno 32 vCore solo per soddisfare i loro requisiti di archiviazione, un'opzione costosa. Il database SQL di Azure presenta un problema simile con la dimensione massima del database e Microsoft ha creato un'opzione di iperscalabilità. Prevediamo che questa diventi un'opzione per Istanza gestita a un certo punto per affrontare i limiti di archiviazione in modo simile.
La dimensione di tempdb è anche correlata al numero di vCore. Nel livello per uso generico, ottieni 24 GB per vCore (fino a 1.920 GB) per i file di dati, con un limite di dimensione del file di registro tempdb di 120 GB. Per il livello Business Critical, tempdb può crescere fino alle dimensioni di archiviazione dell'istanza attualmente disponibili.
OLTP in memoria
Per coloro che stanno attualmente sfruttando In-Memory OLTP (o hanno intenzione di farlo), tieni presente che è supportato solo nel livello di servizio Business Critical. Anche la quantità di spazio disponibile per le tabelle in memoria è limitata da vCore:
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Conclusione
Quando si pianifica una migrazione a Istanza gestita SQL di Azure, è necessario tenere in considerazione diverse considerazioni prima di decidere di eseguire la migrazione. Innanzitutto è necessario comprendere appieno i requisiti di memoria, CPU e archiviazione, poiché ciò determinerà la dimensione dell'istanza. Altrettanto importante è sapere quali sono i tuoi requisiti di I/O di archiviazione. IOPS e velocità effettiva per il livello per uso generico sono direttamente legati a vCore e alle dimensioni dei file di database. Per Business Critical è legato al numero di vCore. Se si dispone di un carico di lavoro ad alta intensità di I/O, Business Critical è il livello di servizio più interessante in quanto fornisce IOPS e numeri di throughput più elevati. La sfida con Business Critical è la capacità di storage inferiore e il supporto di solo 1 TB per l'intera istanza fino a 16 vCore.
Con una pianificazione adeguata e il possibile deconsolidamento di istanze più grandi in istanze gestite più piccole, questa offerta può essere un'opzione di migrazione molto valida per molte organizzazioni. Il vantaggio sono i vantaggi di avere backup gestiti, HA integrato con uno SLA del 99,99%, funzionalità e opzioni di sicurezza aggiunte e non doversi preoccupare di patchare un sistema operativo o un'istanza di SQL Server.
