Che cos'è SQL Server in Linux?
Le organizzazioni che eseguono Linux possono prendere in considerazione l'uso di SQL Server per ospitare i database. Allo stesso modo, le organizzazioni che eseguono SQL Server possono valutare il trasferimento dei server nel sistema operativo Linux. Ma perché dovrebbero affrontare un tale cambiamento?
In qualità di amministratore di sistema di World Wide Importers, si è responsabili dei server Linux che ospitano tutti i server Web front-end e della farm di database di Windows back-end. Si vuole usare l'esperienza Linux per distribuire SQL Server in Linux, quindi si esamineranno i principali vantaggi dell'uso di SQL Server in Linux. L'obiettivo è creare una presentazione per il CTO. Verranno illustrati i vantaggi di SQL Server in Linux e le implicazioni dell'installazione in Linux.
In questa unità si apprenderanno i motivi per cui è consigliabile eseguire SQL Server in Linux.
Perché usare SQL Server in Linux?
Linux è una raccolta di sistemi operativi, o distribuzioni, che vengono eseguiti nel kernel Linux. È un sistema operativo di ampia diffusione, sia per le distribuzioni locali che per quelle basate sul cloud. SQL Server è un noto sistema di gestione di database relazionali (RDBMS) tradizionalmente eseguito solo nel sistema operativo Windows. Da SQL Server 2017 in poi, Microsoft supporta installazioni di SQL Server nei sistemi operativi Linux.
Se si vuole eseguire SQL Server, tenere presente che non si è limitati alla piattaforma Windows. Essendo open source, Linux può essere installato su hardware commerciale a basso costo, riducendo le spese per le licenze del sistema operativo. Linux ha anche un footprint ridotto e requisiti hardware inferiori, che rendono più veloce l'avvio di macchine virtuali basate su Linux su server basati su Windows.
SQL Server in Linux supporta Ubuntu, Red Hat Enterprise Linux e SUSE.
Perché SQL Server?
Se si sceglie SQL Server in Linux come piattaforma di dati prescelta per Wide World Importers, è possibile distribuire in Linux tutti i database di SQL Server esistenti, che attualmente sono in esecuzione nella piattaforma Windows. Sarà anche possibile eseguire le applicazioni esistenti usando la versione Linux di SQL Server e l'organizzazione potrà riutilizzare le competenze esistenti per DBA e sviluppo di applicazioni.
Sarà sufficiente un semplice backup con successivo ripristino nel nuovo ambiente Linux. Un approccio più a basso rischio è quello di spostare un database non critico per l'azienda in Linux e confrontarne le funzionalità e le prestazioni direttamente con Windows. Se il confronto è positivo, sarà possibile creare una strategia di migrazione dettagliata per eseguire la migrazione di tutti i dati. Confrontare questo approccio con quello necessario per passare a una tecnologia di database diversa e a un sistema operativo diverso.
SQL Server in Linux offre anche tutti i vantaggi di prestazioni leader del settore. SQL Server è attualmente al primo posto per le prestazioni nel benchmark TPC-E e nei benchmark TPC-H 1 TB, 10 TB e 30 TB. Il National Institute of Standards and Technology (NIST) ha valutato SQL Server in Linux come il database più sicuro.
Un altro buon motivo per prendere in considerazione l'uso di SQL Server è la funzionalità PolyBase. Con PolyBase è possibile configurare origini esterne di dati che forniscono dati a tabelle esterne. Quando si inviano query, è possibile restituire i dati da queste tabelle esterne con le stesse modalità valide per i dati archiviati in tabelle normali all'interno del database di SQL Server. Le origini dati esterne possono includere Hadoop, account di Archiviazione BLOB di Azure, Oracle, PostgreSQL, MongoDB e molte altre. Dopo aver configurato le tabelle esterne, è anche possibile usarle per esportare o importare dati da o in SQL Server senza dover usare un pacchetto ETL (estrazione, trasformazione e caricamento) o uno strumento di importazione o esportazione separato. È anche possibile usare PolyBase per integrare origini dati esterne con gli strumenti di business intelligence di SQL Server.
Wide World Importers ha database in Oracle e SAP HANA oltre a SQL Server. Si sta valutando l'uso di strumenti ETL per popolare un data warehouse con i dati da tutte queste origini in modo da poterlo usare per scrivere report. Se si distribuisce SQL Server con PolyBase, è invece possibile valutare la possibilità di aggiungere Oracle e SAP HANA come origini dati esterne in SQL Server per integrare i tre sistemi. In questo modo, i report possono inviare tutte le query a SQL Server ma includono comunque i dati archiviati in Oracle e SAP HANA. In questa configurazione SQL Server funge da hub di virtualizzazione dei dati.
Codebase condivisa
Sia in Linux che in Windows, SQL Server usa SQLPAL (SQL Platform Abstraction Layer), che consente l'esecuzione di SQL Server in tutti i sistemi operativi supportati. Gli sviluppatori possono quindi scrivere applicazioni usando il linguaggio preferito (come .NET, PHP, node.JS, Java o Python) e aspettarsi che l'applicazione venga eseguita nello stesso modo ovunque, indipendentemente dal fatto che usino SQL Server in esecuzione in Windows, Linux, contenitori Linux, Azure SQL Edge o database SQL di Azure.
Contenitori
Uno svantaggio delle macchine virtuali è che ognuna necessita di tutte le risorse del sistema operativo, indipendentemente dal fatto che i servizi in esecuzione ne abbiano effettivamente bisogno. Un sistema di virtualizzazione inserito in un contenitore evita questo problema condividendo il sistema operativo host pur isolando le singole applicazioni e i servizi. Un servizio in esecuzione in un contenitore è isolato da un servizio in un altro contenitore. I servizi risultano in esecuzione in macchine virtuali separate, mentre in realtà condividono la memoria e i processori di un singolo sistema operativo.
È possibile eseguire SQL Server 2019 in contenitori Linux. Se è necessario gestire un numero elevato di questi contenitori, è possibile usare uno strumento di orchestrazione come Kubernetes o Docker Swarm. È possibile scegliere questa soluzione per la disponibilità elevata o per consentire ai team DevOps di implementare l'integrazione continua o il recapito continuo distribuendo il nuovo codice in contenitori.