Come Scegliere e Configurare Azure SQL per Ottimizzare Prestazioni e Scalabilità

Azure SQL offre diverse modalità di acquisto e configurazione che consentono agli utenti di scegliere la soluzione più adatta alle proprie esigenze di prestazioni e scalabilità. La creazione di un pool elastico per il primo database SQL singolo è una procedura semplice che richiede solo l'assegnazione di un nome al pool. Una volta creato, è possibile aggiungere altri database che condivideranno le stesse risorse del pool. Quando necessario, è possibile scalare il pool aggiungendo più spazio di archiviazione.

Nel caso di una soluzione preconfigurata e relativamente semplice, i livelli di servizio DTU (Base, Standard e Premium) forniscono una configurazione di calcolo basata su un numero variabile di DTU, dimensioni massime regolabili per il database e periodi di retention dei backup crescenti. Il prezzo per DTU varia in base al livello di servizio scelto, con la possibilità di regolare il numero di DTU assegnato. Il livello di servizio predefinito per una nuova installazione di database SQL è l'opzione vCore Generale.

Per chi desidera prestazioni superiori e una gestione più raffinata delle risorse, Azure offre il livello Business Critical, che garantisce una migliore performance I/O e tolleranza ai guasti, ma a un prezzo significativamente più alto, pari a circa 2,7 volte quello del livello Generale. Questo livello include tre repliche aggiuntive del database e l'archiviazione SSD locale per garantire una bassa latenza.

Un’altra opzione per chi ha necessità di archiviazione di grandi dimensioni è il livello Hyperscale, che supporta database fino a 100 TB e può gestire fino a 327.680 operazioni di I/O al secondo. Inoltre, l'Hyperscale offre 10,2 GB di memoria per vCore, il doppio rispetto agli altri livelli. Tuttavia, è importante notare che il livello Hyperscale non è reversibile: una volta configurato, l'unica soluzione per passare a un altro livello di servizio è ridistribuire e migrare i dati.

Nel contesto delle opzioni hardware per vCore, Azure offre configurazioni che permettono di specificare un numero massimo di vCore, la memoria e lo spazio di archiviazione per l'installazione. La tariffa per il calcolo per vCore per secondo è determinata in base a queste configurazioni.

Le opzioni di servizio per SQL MI comprendono:

• General Purpose, adatto alla maggior parte dei carichi di lavoro, con separazione tra risorse di calcolo e archiviazione e latenza di 5-10 ms.

• Business Critical, raccomandato per applicazioni con requisiti di bassa latenza (1-2 ms), alta disponibilità e recupero rapido dai guasti.

• Next-gen General Purpose, attualmente in anteprima, una versione migliorata del livello General Purpose con prestazioni superiori e maggiore affidabilità.

In SQL MI, la selezione delle risorse hardware include opzioni di memoria e CPU variabili a seconda della serie di hardware scelta, che può essere standard o premium, con opzioni anche per una configurazione ottimizzata per la memoria. L’uso del vCore consente di scalare facilmente le risorse di calcolo e archiviazione in base alle esigenze.

Un aspetto cruciale nella scelta delle risorse per un’installazione SQL in Azure è comprendere le esigenze effettive dell’applicazione. La giusta combinazione di vCore, memoria, archiviazione e backup è fondamentale per garantire un buon equilibrio tra costo e performance. Scelte mal ponderate, come un’allocazione insufficiente di risorse per carichi di lavoro ad alta intensità o l’utilizzo di soluzioni più costose per carichi leggeri, possono comportare inefficienze nei costi e nelle prestazioni.

Come Configurare la Sicurezza e la Gestione degli Accessi in SQL Server

La configurazione della sicurezza in SQL Server è fondamentale per garantire l’integrità e la protezione delle informazioni all’interno di un sistema complesso. In un ambiente che utilizza Microsoft SQL Server o Azure SQL Database, la gestione degli accessi e la protezione delle risorse possono sembrare sfide difficili da affrontare, ma comprendere i principi di base e le migliori pratiche è essenziale per mantenere il sistema sicuro e ben organizzato.

L’amministratore di sistema ha il compito di configurare il server e le risorse tramite account e ruoli, gestendo i permessi necessari per ciascun utente o gruppo di utenti. Una delle pratiche più raccomandate per la gestione dell’accesso amministrativo è l’uso di un account di gruppo anziché di un singolo account utente. In questo modo, è possibile evitare di dover modificare le credenziali quando si verificano cambiamenti nel personale, semplificando la gestione dell’accesso. L’account amministrativo, che ha il pieno controllo di tutti i database, è assegnato a un gruppo di sicurezza per semplificare l’amministrazione a lungo termine.

Anche se non è una pratica consigliata, è possibile creare account utente su un singolo computer Windows senza utilizzare Active Directory, permettendo l'autenticazione locale per gli utenti di Windows. Tuttavia, se SQL Server è installato su un computer Windows che è un membro di un dominio Active Directory, gli amministratori dovranno scegliere un utente di Active Directory quando aggiungono un amministratore a SQL Server. In ambienti come Azure, invece, si può fare uso di identità Microsoft Entra per abilitare l’accesso e l'autenticazione agli utenti tramite il sistema di identità del dominio Azure.

Per la creazione di logins e utenti in SQL Server, l’amministratore ha diverse opzioni. Quando si crea un login a livello di server, è possibile farlo tramite T-SQL utilizzando il comando CREATE LOGIN, per un account standard o per un'identità esterna come quelle gestite da Entra. Un esempio di codice per creare un login da un'identità esterna potrebbe essere il seguente: CREATE LOGIN [[email protected]] FROM EXTERNAL PROVIDER;. Questo comando consente di creare un login che corrisponde all’identità di un utente Entra. È possibile anche associare un login a un utente di database, utilizzando il comando CREATE USER per associare il login a una specifica identità di database.

Nel contesto di SQL Server, un login rappresenta un’identità a livello di server, mentre un utente è un’identità a livello di database. La gestione corretta di questi due tipi di principi di sicurezza è cruciale per garantire che ogni utente abbia accesso solo alle risorse di cui ha bisogno. Per creare un utente a livello di database che sia mappato a un login esistente, l’amministratore utilizza il comando CREATE USER testuser FROM LOGIN testuser.

L'importanza della gestione dei ruoli si riflette nel fatto che consente di delegare i compiti amministrativi in modo efficiente e sicuro. Alcuni ruoli predefiniti all’interno di SQL Server e Azure SQL permettono agli amministratori di delegare compiti specifici, come la lettura dei dati, la scrittura nei database o la gestione delle operazioni di backup. Ruoli come db_datareader, db_datawriter e db_backupoperator permettono di definire con precisione quali operazioni ogni utente o gruppo di utenti può eseguire.

In un ambiente di lavoro con SQL Server, la gestione degli accessi e dei permessi attraverso ruoli e identità è fondamentale per mantenere un sistema sicuro, controllato e facilmente scalabile. L’amministratore deve essere sempre consapevole dei permessi concessi a ciascun ruolo e utente, evitando di assegnare permessi eccessivi che potrebbero compromettere la sicurezza. La separazione dei compiti tra gli utenti e la gestione delle identità tramite ruoli personalizzati aiuta a garantire una sicurezza ottimale, in linea con le best practices di sicurezza.

Come configurare il backup e il ripristino in SQL Server e Azure SQL: Gestire la continuità e la protezione dei dati

Il modello di recupero di un database in SQL Server è fondamentale per definire come i dati vengono protetti e ripristinati in caso di necessità. Gli amministratori di sistema possono modificare questa impostazione dalla pagina delle opzioni nella finestra delle proprietà del database. Quando il modello di recupero viene cambiato da SIMPLE a FULL, viene introdotto un nuovo tipo di backup, chiamato backup del log delle transazioni. Questo tipo di backup consente di eseguire il ripristino a uno specifico punto nel tempo, a differenza dei backup completi, che permettono solo il ripristino dell'intero database.

Quando si crea un lavoro di ripristino in SSMS, l'opzione "Ripristina da" nella pagina Generale consente all'amministratore di selezionare quale backup ripristinare, nel caso in cui ci siano più lavori di backup per lo stesso database. I backup dei log delle transazioni possono essere eseguiti anche ogni 30 secondi, permettendo di avere numerosi backup tra cui scegliere al momento del ripristino. La funzione della linea temporale, accessibile cliccando sul pulsante "Timeline", apre la finestra della Timeline del Backup, dove diversi tipi di backup sono rappresentati da forme specifiche. L'amministratore può regolare l'intervallo temporale per visualizzare una serie di lavori completati e selezionare uno di questi per il ripristino.

Azure SQL Database offre anche una politica di ritenzione a lungo termine (LTR), che consente di conservare i backup per un periodo che può arrivare fino a 10 anni, rispondendo a esigenze legali o contrattuali. La configurazione della ritenzione dei backup può essere gestita tramite la finestra di configurazione delle politiche, dove l'amministratore può decidere per quanto tempo conservare i backup settimanali, mensili o annuali.

In alternativa all'uso del portale di Azure, gli amministratori possono eseguire backup e ripristini manualmente utilizzando i comandi T-SQL, come il comando BACKUP per eseguire un backup su disco locale o su un URL che punta a uno storage Azure Blob. In modo analogo, il comando RESTORE permette di ripristinare un database da un backup precedentemente creato, sia da disco che da URL.

La possibilità di eseguire backup su cloud storage è particolarmente utile quando i dati devono essere conservati in modo sicuro e facilmente recuperabile da qualsiasi punto del mondo. Quando si seleziona l'opzione URL per il backup, è necessario disporre di un account di storage Azure separato con accesso a un contenitore Blob. Inoltre, il server SQL deve autenticarsi con Azure tramite una firma di accesso condiviso (SAS).

Quando si ripristina un database da uno storage cloud, l'amministratore deve selezionare il dispositivo di backup nel dialogo di ripristino, utilizzando l'opzione di connettività a un account Microsoft per selezionare il contenitore Blob specifico. È importante che gli amministratori siano consapevoli della separazione tra l'ambiente del server SQL e quello di Azure, poiché ogni ambiente richiede misure di sicurezza distinte.

In scenari di alta disponibilità e recupero di emergenza (HA/DR), Azure offre numerose soluzioni per mantenere i database operativi anche in caso di disastri. Una di queste è la geo-replica attiva, che consente di creare una replica secondaria del database in una regione geografica diversa. Questo assicura la continuità operativa anche in caso di eventi catastrofici che coinvolgano la regione principale. La geo-replica attiva è disponibile per Azure SQL Database, ma non per Azure SQL Managed Instance, che utilizza invece i gruppi di failover automatico.

L'amministratore può configurare una geo-replica per un database esistente tramite il portale di Azure, scegliendo di creare una replica in una regione diversa. Una volta creata, la replica secondaria appare nella pagina delle repliche e l'amministratore può forzare il failover per scambiare i ruoli dei database, trasformando la replica in primaria. Questo processo di failover è essenziale per garantire che il database rimanga disponibile anche in caso di guasti significativi.

La gestione dei backup, del ripristino e delle soluzioni di alta disponibilità rappresenta un aspetto cruciale nella protezione dei dati aziendali. È fondamentale per gli amministratori comprendere le implicazioni di ciascun tipo di backup e configurazione, non solo per garantire la sicurezza dei dati, ma anche per ottimizzare il tempo di recupero e ridurre al minimo l'interruzione delle operazioni aziendali.