Termini, modalità e calcolo delle licenze
Come orientarsi nel licensing di SQL Server: terminologia di base, modalità di concessione delle licenze, il numero di istanze eseguibili e calcolo delle licenze.
SQL Server è un DBMS (Database Management System) relazionale sviluppato da Microsoft e viene utilizzato per gestire database dalle dimensioni e strutture più disparate. Insieme a Oracle Database e MySQL è una delle piattaforme per basi dati più diffuse al mondo grazie alle sue caratteristiche e funzionalità per l’archiviazione, l’elaborazione, l’analisi e la sicurezza dei dati.
Può essere utilizzato per vari scopi, come lo sviluppo di applicazioni, l’esecuzione di siti web, l’hosting di magazzini di dati o per supportare soluzioni di Business Intelligence. Tra i prodotti MS è spesso considerato il più “ostico” a causa delle sue regole di licenza non semplici e in continua evoluzione.
Prima di addentrarci nel licensing per SQL Server, teniamo presente che ogni versione ed edizione di SQL ha specifici termini di licenza, diritti e funzionalità.
Vediamo meglio le differenze tra edizione e versione e le caratteristiche funzionali.
Quasi sempre all’interno di contratti multi-licenza e CSP è possibile sfruttare il downgrade right, ovvero si ha il diritto di utilizzare versioni rilasciate in precedenza senza doverle acquistare: ad esempio, se si acquista oggi attraverso MPSA il prodotto SQL Server 2022, si può eseguire il downgrade dell’istanza a qualsiasi delle edizioni precedenti.
Vediamo meglio le principali, dividendole in gratuite e commerciali:
Opzioni gratuite
Opzioni commerciali
La Standard, infatti, è più adatta per progetti semplici in cui non sono richieste funzionalità avanzate di analisi dati, sicurezza e gestione; è una scelta cost-effective per implementazioni con esigenze moderate di prestazioni e scalabilità.
L’edizione Enterprise, invece, comprende tutte le funzionalità di base della Standard Edition più altri strumenti tipici dei database di alta fascia con prestazioni velocissime, virtualizzazione illimitata, elementi di business intelligence end-to-end allo scopo di «abilitare livelli di servizio elevati per carichi di lavoro cruciali e l’accesso dell’utente finale alle informazioni dettagliate sui dati»
Per quanto riguarda il downgrade delle edizioni, c’è una regola di base: se assegni una licenza SQL Server Enterprise a un host, puoi eseguire al suo interno sia un’istanza SQL Server Enterprise sia un’istanza SQL Server Standard.
Non è possibile invece il contrario, perché la SQL Server Standard è un’edizione considerata “più piccola” e non può quindi contenere SQL Server Enterprise. Unica eccezione a quando appena scritto è rappresentata dall’AHB (Azure Hybrid Use Benefit) dove è possibile coprire istanze Enterprise con licenze Standard applicando ai core utilizzati un moltiplicatore di 4 (ovvero servono 4 core Standard per coprire 1 core Enterprise).
La prima e più importante differenza in termini di licensing tra SQL Server Standard e SQL Enterprise è la modalità di licenza. Con l’edizione Standard è possibile scegliere sia il modello Server+CAL sia la licenza per core, mentre SQL Server Enterprise è disponibile solo tramite il modello di licenza per core*.
*Attenzione: il fatto che le licenze SQL Server Standard Core ed Enterprise Core vengano vendute in pacchetti dual core può creare confusione. Se a Microsoft si dice che si vogliono 88 licenze, considerando che vengono venduti in pacchetti da due core (e quindi due licenze), si rischia di acquistarne il doppio.
Come abbiamo anticipato prima, le licenze si possono concedere in due modi:
Al momento solo SQL Server Standard dispone di questo modello di licenza.
Chi ha acquistato licenze SQL Server Enterprise con il modello Server+CAL prima del 1 aprile 2012 può ancora rinnovare, indipendentemente dal fatto che la garanzia Software Assurance (SA) sia stata rinnovata o meno, ma non può acquistare nuove licenze.
La concessione di licenze SQL secondo il modello Client Access Licenses (CAL), come specificato nei diritti di utilizzo del prodotto, richiede che ogni istanza di SQL (virtuale o fisica) sia coperta da una singola licenza di SQL Server e che ogni utente e/o dispositivo che accede direttamente o indirettamente a un server SQL con licenza debba avere una licenza CAL (user/device CAL) di SQL Server della stessa versione o più recente. Per esempio, per accedere a un server SQL Server 2019 Standard Edition, un utente avrà bisogno di una CAL di SQL Server 2019 o 2022.
Ricordiamoci di considerare la regola del multiplexing: l’inserimento di tecnologia tra DBMS e consumatore non riduce mai il numero delle licenze richieste: è nel caso, ad esempio, di un utente o un dispositivo che accede a un server SharePoint supportato da SQL (quindi non direttamente) in cui serve una CAL SQL.
C’è da sottolineare che le CAL per SQL server non vengono mai fornite in bundle con altre CAL e non hanno alcun equivalente: questo implica che debbano essere acquistate in modo esplicito come SQL Server CAL (ad esempio Office 365 non le include e così pure i pacchetti Core CAL ed Enterprise CAL).
Un altro aspetto importante è che non sono previsti connettori esterni: se si ha più di 20 utenti per core o non sono quantificabili perché ad accedere al server è l’intera internet con carichi di lavoro Internet/Extranet o sistemi che si integrano con carichi di lavoro esterni, è necessaria (ma anche più economica) la licenza core dove non è necessario contare gli utenti e i dispositivi che accedono al server. Cosa invece che con le CAL va fatto, con il conto tenuto individualmente.
La regola empirica è quindi quella di guardare in modo critico quanti utenti e dispositivi si hanno in attivo che accedono indirettamente al server SQL e se questo numero crescerà nel prossimo periodo.
N.B. avvertenza sulla Software Assurance (SA): se una funzione richiede la SA sulla licenza dell’istanza di SQL Server, è probabile che richieda la SA anche per le CAL. Ad esempio, SQL Failover richiede SA sia per l’istanza che per le CAL.
Questo modello fornisce ai clienti una misura più precisa della potenza di calcolo e una metrica di licenza più coerente, indipendentemente dal fatto che le soluzioni siano distribuite su server fisici on-premises oppure in ambienti virtuali o cloud.
A differenza del modello Server+CAL non richiede licenze di accesso client, ma invece di concedere in licenza SQL per server, lo fa per ogni core del server che esegue SQL Server. Esistono formule specifiche e avvertenze per calcolare il numero richiesto di licenze core di SQL server.
Per ottenere la licenza di SQL Server con questo modello, è necessario contare il numero totale di core del server e acquistare il numero appropriato di licenze per core (vendute in confezioni da due).
Quando si assegna la licenza SQL Server a un’istanza SQL quello che si fa è essenzialmente assegnarla al sistema operativo in cui viene eseguito SQL Server, che può essere fisico o virtuale (vedi concetto di virtualizzazione: le VM, che sono “finti pc” che contengono sistemi operativi virtuali, possono venire eseguite all’interno di un sistema operativo fisico, detto “host” perché ospita VM).
Due considerazioni su questo modello:
1) la concessione di una licenza a un’istanza (una copia del file eseguibile del server eseguita come servizio del sistema operativo) non differisce a seconda che il sistema operativo sia in una VM o fisico
2) i Containers o contenitori, che raggruppano e isolano le applicazioni insieme ai file necessari per l’esecuzione in una sorta di “bolla”, possono funzionare sia all’interno di un sistema operativo fisico ma possono anche essere nidificati in macchine virtuali. In questo modello però ogni contenitore viene trattato come un ambiente di sistema operativo (OSE) virtuale separato (e non come un’altra macchina virtuale come nelle edizioni precedenti al 2022).
Nell’edizione Standard, una singola licenza SQL assegnata a un OSE consente di eseguire un numero illimitato di istanze SQL Server Standard all’interno dello stesso OSE. Se si hanno quattro applicazioni con requisiti simili (ad esempio richiedono tutte SQL Server Standard 2019), si può installare SQL server quattro volte nello stesso sistema operativo sotto un’unica licenza, con notevole risparmio dei costi.
Per quanto riguarda l’edizione Enterprise, ricordiamo che non può essere più acquistata con il modello Server+CAL ma ci sono organizzazioni con licenze esistenti e rinnovi continui (con o senza SA).
A prescindere o meno che si abbia rinnovato la SA, con un’Enterprise Edition che prevede questo modello di licenza, ci sono dei vincoli:
1) puoi eseguire un numero illimitato di istanze in un massimo di quattro ambienti di sistema operativo (macchine virtuali o container)
2) ci sono delle limitazioni HW: fino a massimo 20 core in caso di OSE fisico e fino a 20 hardware thread in caso di OSE virtuale
1) se si concede una licenza per core fisici, questa copre tutte le istanze all’interno del sistema operativo fisico. I container non sono inclusi, in quanto sono considerati VM
2) la stessa licenza non può essere assegnata alle macchine virtuali e ai container (questo era possibile nelle versioni precedenti SQL Server 2019, 2017, 2016, 2014, 2012). La concessione per VM o per contenitore è prevista solo nel caso si abbia SA (o abbonamento CSP che è l’equivalente).
Quindi in caso di SQL Server Standard con SA si hanno istanze illimitate all’interno del sistema operativo fisico, ma anche le VM e i contenitori all’interno del sistema operativo virtuale. Nell’altro modello i contenitori venivano trattati come macchine virtuali separate e quindi richiedono un set di licenze separate quindi in caso di ambienti fortemente containerizzati le licenze con SA attiva rappresentano una concreta opzione di risparmio perché non è più necessario contarli.
Se si ha SQL Server Enterprise con SA, si può concedere licenziare ogni core nell’host fisico ed eseguire su quest’ultimo un numero illimitato di macchine virtuali e contenitori. Questa è l’opzione migliore per le realtà che desiderano la virtualizzazione illimitata e hanno ambienti fortemente containerizzati.
Senza SA, infatti, ci sono dei limiti: il numero di macchine virtuali e contenitori da seguire non possono essere superiori al numero di licenze assegnate all’host (es. se un host ha 12 core, il numero di macchine virtuali è limitato a 24). Se si assegna SQL Server Enterprise senza SA a contenitori bisogna prestare attenzione: in questo caso vengono gestiti come macchine virtuali separate.
Quando si esegue SQL Server in un OSE fisico, tutti i core fisici del server devono essere dotati di licenza. In questo caso è necessario un minimo di quattro licenze core per ogni processore fisico del server. Quindi si osservano le caratteristiche della CPU, si contano i core fisici di una CPU e si assegnano almeno quattro licenze per CPU.
Bisogna ricordarsi che le licenze core sono vendute in confezioni da due, quindi bisogna dividere il numero di licenze richieste per due per determinare il numero effettivo di SKU di licenza da ordinare.
In questo caso la situazione è leggermente diversa: vanno contati i core virtuali (vCPUs) ricordando che il numero di licenze richieste ha un minimo di 4. Di conseguenza se l’OSE virtuale ha 2 vCPUs va comunque licenziato a quattro.
N.B. Se le vCPU sono supportate da più thread HW quest’ultimi vanno contati, ma si tratta di una situazione poco frequente: di solito gli hypervisor più diffusi tipo VMware o HyperV, una volta riavviati per abilitare l’hyperthreading, avranno tutte le vCPU mappate su un singolo thread.
Il tema delle licenze SQL è molto vasto e ci sono diversi argomenti da considerare. Ne accenniamo brevemente alcuni:
Gli host possono venire combinati in più cluster e questo per il semplice motivo che se un host si guasta le macchine virtuali possono essere spostate su un altro host. Ma potrebbe verificarsi la situazione per cui le macchine virtuali si muovono ma le licenze assegnate non possono farlo: quando questo diritto è previsto si parla di mobilità delle licenze, ovvero della capacità della licenza di spostarsi insieme alla macchina virtuale.
La licenza di un’istanza virtuale richiede una SA se il server virtuale si sposta tra gli host più di una volta ogni 90 giorni. Questo vantaggio è chiamato Mobilità delle licenze tra Farm di server.
Si tratta di un tema importante in caso di audit, con la verifica della conformità da parte del vendor: in caso di spostamenti di macchine virtuali, bisogna assicurarsi che le licenze coprano anche lo spostamento.
Uno dei vantaggi di SA più richiesti è la possibilità di implementare architetture di High Availability e Disaster Recovery: in previsione di eventi di failover è possibile installare ed eseguire istanze passive in OSE o server separati in sede o in Azure per il ripristino d’emergenza. Per quanto riguarda la necessità di licenziare i nodi, bisogna tenere presente che:
Le varie funzioni di SQL possono essere separate su più server. Alcune di queste funzioni non richiedono licenze, ma altre sì. I seguenti sono i componenti di SQL soggetti a licenza:
1) SQL Server Analysis Services SQL
2) Server Reporting Services SQL
3) Server Integrations Services
Ogni server con una funzione di SQL licenziabile richiede una propria licenza SQL, anche se tutti i server anche se lavorano tutti sullo stesso database. Di conseguenza se un database è in esecuzione su un server, i servizi di analisi su un secondo server e i servizi di reporting su un terzo server, tutti e tre i server richiedono licenze separate.
In WEGG siamo consulenti esperti di licensing Microsoft (SQL Server compreso), per cui se avete bisogno di supporto per effettuare il calcolo delle licenze necessarie, verificare la posizione di conformità e ottimizzare i costi legati alla spesa per SQL Server contattateci per una consulenza!
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2022 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda certificata ISO 9001:2015
