Distribuisci SQL Server su Azure Locale con operazioni disconnesse

si applica a:SQL Server

Questo articolo descrive come pianificare, distribuire, proteggere e gestire SQL Server su Windows Server o su macchine virtuali Linux (VM) supportate in Azure Locale con operazioni disconnesse.

Prima di iniziare:

  • Ottieni l'approvazione della tua organizzazione.
  • Ottieni la piattaforma per operazioni disconnesse.
  • Implementa la piattaforma all'interno dei confini di sicurezza della tua organizzazione.

I carichi di lavoro di SQL Server, il piano di controllo locale, i dati di gestione, l'integrazione delle identità e la governance rimangono on-premises. L'ambiente non richiede una connettività continua con Azure o internet. Utilizza flussi di lavoro approvati di trasferimento in più fasi o offline per aggiornamenti, pacchetti di supporto, dati di registrazione e altri artefatti necessari.

Per le implementazioni che mantengono la connettività con Azure, vedi Deploy SQL Server su Azure Locale.

Quando utilizzare operazioni disconnesse

Consideriamo operazioni disconnesse per:

  • Ambienti sovrani, regolamentati o isolati dove la connettività del cloud pubblico è vietata o inaffidabile.
  • Siti che richiedono esecuzione locale, amministrazione locale e controllo su dati e telemetria operativa.
  • Carichi di lavoro SQL Server che necessitano di virtualizzazione e storage Azure Locale senza dipendenza dal piano di controllo pubblico di Azure.

Puoi eseguire carichi di lavoro transazionali, analytics, business intelligence e data warehouse localmente. Integra le VM SQL Server con i tuoi sistemi di identità, monitoraggio, backup, sicurezza, patch e distribuzione software approvati on-local.

Important

L'estensione SQL Server per Azure Arc non è supportata per operazioni disconnesse. Azure Arc SQL Server inventario, valutazione delle migliori pratiche e capacità di gestione SQL Server basate su Azure non sono disponibili tramite questa estensione. Usa strumenti locali supportati per gestire e monitorare SQL Server in ogni VM.

Prerequisiti

Prima di distribuire SQL Server, verifica di avere:

  • Questi prerequisiti non richiedono connettività continua ad Azure o a internet.
  • Un ambiente operativo disconnesso Azure Locale approvato distribuito su hardware supportato all'interno dei confini di sicurezza della tua organizzazione. Verifica i servizi supportati e completa la distribuzione della piattaforma prima di continuare.
  • Supportava immagini Windows Server o Linux e sufficiente capacità di calcolo e storage per creare VM di carico di lavoro.
  • Rete locale, identità, certificati e sincronizzazione temporale che soddisfano i requisiti di retee identità della piattaforma.
  • Licenze SQL Server appropriate e licenze separate per la piattaforma Azure Locale disconnected operations. Rivedi i limiti di licenza e supporto e la fatturazione delle operazioni disconnesse.
  • Media di installazione SQL Server approvati, aggiornamenti cumulativi, driver, strumenti di gestione e pacchetti prerequisiti, con un processo offline controllato per trasferire e verificare questi artefatti.
  • Monitoraggio locale e target di backup protetti per i carichi di lavoro di SQL Server, separati dai backup sul piano di controllo.
  • Un processo di assistenza offline approvato per SQL Server e aggiornamenti del sistema operativo ospite.

Pianifica il carico di lavoro di SQL Server

Prima di dimensionare le VM, registra i requisiti del carico di lavoro:

  • Seleziona la versione e l'edizione di SQL Server in base alla dimensione del database, alle funzionalità di disponibilità, alle operazioni online, ai diritti di virtualizzazione e al ciclo di vita del supporto.
  • Registra l'utilizzo massimo della CPU, la memoria del working set, le operazioni di input/output al secondo (IOPS), il throughput, la latenza, la crescita del database, la domanda tempdb, la frequenza di generazione dei log e il livello di concorrenza.
  • Definire gli obiettivi dei punti di recupero (RPO) e gli obiettivi di tempo di recupero (RTO).
  • Identificare dipendenze applicative, metodi di autenticazione, requisiti di Transport Layer Security (TLS), porte, account di servizio, finestre di manutenzione, ritenzione di backup e dipendenze software offline.

Progetta le VM di SQL Server

Usa le seguenti indicazioni per progettare le tue VM SQL Server:

Area di progettazione Linee guida per SQL Server
Compute Dimensionare CPU virtuali per un utilizzo prolungato e per l'efficienza delle licenze. Evita l'oversubscription che crea una latenza imprevedibile delle query.
Memory Riserva memoria da destinare al sistema operativo, agli agenti, ai driver e alle attività di failover. Configura max server memory in modo che SQL Server non consumi la memoria necessaria ad altri processi.
Storage Usa volumi separati per il sistema operativo, i dati, i log tempdbdelle transazioni e i backup. Verifica latenza, throughput, profondità della coda, capacità, resilienza e soglie di spazio disponibile.
Rete Fornire percorsi stabili per client, management, backup e replica secondo necessità. Valida DNS, unità di trasmissione massima (MTU), regole firewall, trust TLS e connettività dell'ascoltatore.
Collocazione Posizionare repliche ad alta disponibilità su diversi nodi Azure Locale o domini di guasto. Usa l'anti-affinità dove disponibile.

Installare e configurare SQL Server

  1. Crea VM supportate da Windows Server o Linux seguendo le indicazioni per le VM di operazioni disconnesse.
  2. Trasferisci i supporti di installazione approvati, aggiornamenti cumulativi, driver, strumenti di gestione e pacchetti prerequisiti attraverso il tuo processo offline controllato.
  3. Installa SQL Server utilizzando le istruzioni per Windows o Linux. Installa solo le funzionalità di cui hai bisogno. Usa file di configurazione ripetibili o automazione, proteggi le chiavi prodotto e le credenziali, e documenta la base di build.
  4. Applica l'aggiornamento cumulativo approvato. Configura account di servizio, autenticazione, certificati TLS, regole firewall, collazione, max server memory, tempdbcrescita dei file del database e compressione di backup.
  5. Validare la latenza di archiviazione, la pressione di CPU e memoria, la connettività, l'integrità del database, i backup, le operazioni di ripristino e il comportamento delle applicazioni prima dell'uso in produzione.

Configurare la disponibilità elevata e il ripristino di emergenza

Progetta la disponibilità e il recupero per il carico di lavoro di SQL Server separatamente dal piano di controllo Azure Locale.

Opzioni di disponibilità di SQL Server

  • Gruppi di disponibilità sempre attivi: Usa VM SQL Server separate e posiziona repliche tra domini fisici di guasto. Per le distribuzioni in ambiente Windows, configura il clustering di failover di Windows Server, un witness locale e il quorum, i listener e la logica di ripetizione dei tentativi dell'applicazione senza fare affidamento su Azure Cloud Witness. Consulta la panoramica dei gruppi di disponibilità e le indicazioni per iniziare.
  • Istanze di cluster di failover su Windows: Usa lo storage condiviso supportato e una configurazione SQL Server clusterizzata supportata quando hai bisogno di protezione a livello di istanza. Vedi istanze del cluster di failover Always On e installazione del cluster di failover di SQL Server.
  • Resilienza dell'host: Usa posizionamento consapevole del cluster e anti-affinità affinché le repliche di SQL Server non condividano lo stesso nodo fisico o dominio di guasto.

Per i requisiti di clustering di Windows, vedi Windows Server Failover Clustering con SQL Server.

Per Linux, un gruppo di disponibilità senza un gestore di cluster fornisce repliche in scala di lettura, non ad alta disponibilità. Le implementazioni ad alta disponibilità richiedono un cluster manager supportato, come Pacemaker, mentre le implementazioni in produzione richiedono recinzione. Vedi Configura i gruppi di disponibilità su Linux. Verifica che la tua distribuzione Linux, il gestore del cluster, il meccanismo di recinzione e la configurazione di storage siano supportati nell'ambiente Azure Locale disconnesso prima di distribuire. Le procedure Windows linkate qui non stabiliscono il supporto per una topologia Linux.

Progettazione del recupero

Definire obiettivi di recupero per ogni database. Mantieni separati i backup di SQL Server coerenti rispetto all'applicazione da quelli sul piano di controllo. Replicare o esportare i backup in una zona o sito di sicurezza secondario approvato, proteggere le chiavi di crittografia in modo indipendente ed eseguire test di ripristino programmati.

Per ulteriori informazioni, consulta la panoramica del ripristino e recupero di SQL Server.

Mettere in sicurezza SQL Server

Applica una base di sicurezza di SQL Server che funzioni senza servizi di public cloud:

  • Su Windows, usa account a dominio a privilegio minimo o servizi gestiti dove supportato. Usa la configurazione dell'identità del servizio supportata dal tuo sistema operativo e limita i permessi per backup, monitoraggio e identità applicative.
  • Preferisci l'autenticazione integrata dove supportata. Su Linux, l'autenticazione Active Directory utilizza Kerberos e richiede la configurazione del nome principale del servizio (SPN) e della keytab specifica per SQL Server. L'integrazione dell'identità della piattaforma non configura l'autenticazione di SQL Server. Restringire sysadmin l'abbonamento, rimuovere login e funzionalità inutilizzate, disabilitare protocolli deboli e controllare regolarmente i permessi.
  • Richiedere TLS per le connessioni dei clienti. Per il traffico replica del gruppo di disponibilità, configurare autenticazione e crittografia sugli endpoint di mirroring del database. Gestisci i certificati tramite la tua infrastruttura locale di chiave pubblica (PKI) e monitora la salute della scadenza e della catena di fiducia.
  • Proteggere i dati con crittografia trasparente dei dati (TDE) o cifratura dei volumi, secondo opportunità. Cripta i backup, memorizza le chiavi separatamente e testa il recupero delle chiavi.
  • Abilita SQL Server Audit o controlli equivalenti per attività privilegiate, errori di accesso, modifiche ai permessi, accesso a oggetti sensibili e modifiche di configurazione.

Considerazioni sulla sicurezza in modalità disconnessa

  • Mantenere un repository offline approvato per aggiornamenti di SQL Server, driver, strumenti, definizioni di sicurezza e dipendenze. Verifica le firme e scansiona i reperti importati.
  • Per le chiamate REST verso l’esterno, consenti solo gli endpoint HTTPS locali approvati. Usa credenziali con ambito di database, limita EXECUTE ANY EXTERNAL ENDPOINTe verifica le richieste. Esamina le autorizzazioni e i requisiti degli endpoint per sp_invoke_external_rest_endpoint.
  • Documentare l'accesso d'emergenza, la rotazione delle credenziali, il rinnovo dei certificati, la sanificazione dei support-bundle e procedure di recupero che non dipendono dai servizi del public cloud.

Monitoraggio di SQL Server

Puoi monitorare l'infrastruttura Azure Locale, i servizi di controllo e la salute delle VM tramite soluzioni di monitoraggio esterne configurate. Installa e configura gli agenti e i pacchetti di gestione necessari per la tua soluzione di monitoraggio. Disconnected Operations non fornisce un servizio dedicato di monitoraggio SQL Server.

Monitorare SQL Server all'interno di ogni VM con funzionalità native, come viste di gestione dinamica, Extended Events e log degli errori, oppure una piattaforma di monitoraggio on-premises approvata. Su Windows, puoi anche usare avvisi di SQL Server Agent e contatori di prestazioni di Windows. Gli avvisi SQL Server Agent non sono supportati su Linux; controlla il supporto alle funzionalità di SQL Server in Linux per la tua versione.

Raccogli i seguenti segnali, a seconda del tuo carico di lavoro:

  • Disponibilità di SQL Server, stato del database, età dei backup ed errori dei processi.
  • Blocco, deadlock, attese, utilizzo della CPU e pressione sulla memoria.
  • Latenza di archiviazione, crescita del database e del log e integrità di tempdb.
  • Sincronizzazione replica ad alta disponibilità.

Conservare la telemetria nei repository locali approvati. Definisci soglie azionabili e procedure di escalation. Per il monitoraggio della piattaforma, vedi Monitorare operazioni disconnesse.

Fai un backup e recupera SQL Server

Important

La capacità di backup delle operazioni disconnesse protegge solo i dati delle VM del piano di controllo. Non fa backup dei carichi di lavoro di SQL Server né dei cluster di carichi di lavoro configurati. Configura i backup di SQL Server separatamente.

  1. Seleziona i modelli di recupero in base ai tuoi RPO. Programmare backup completi e, se necessario, backup differenziali su storage locale protetto. Per i database che utilizzano il modello di recupero completo o il modello di recupero bulk-logged, programmare anche backup del log delle transazioni. Il modello di recupero semplice non supporta i backup del log delle transazioni né il ripristino temporizzato. Usa compressione, checksum e crittografia dove appropriato.
  2. Conserva le copie in un dominio o sito separato per fallimento. Proteggi le chiavi di backup e crittografia in modo indipendente, e monitora capacità e età di backup.
  3. Test completi e ripristini su host alternativo. Quando è necessario un ripristino a un momento specifico, utilizzare il modello di recupero completo, mantenere la catena di backup del log e testare i ripristini a un momento specifico. Con il modello di recupero con registrazione in blocco, non è possibile eseguire un ripristino fino a un momento specifico all'interno di un backup del log che contiene modifiche registrate in blocco. Registrare gli RPO e gli RTO raggiunti e colmare eventuali lacune.

Per le procedure, vedi Backup e ripristino database SQL Server, Crea un backup completo del database e la panoramica di ripristino e recupero.

Servizio SQL Server non in linea

Mantenere le basi approvate per gli aggiornamenti cumulativi di SQL Server, le patch del sistema operativo ospite, i driver, gli strumenti di gestione e il software di sicurezza:

  • Testare gli aggiornamenti in un ambiente disconnesso rappresentativo.
  • Fai un backup dei carichi di lavoro prima di applicare gli aggiornamenti.
  • Applicare le patch alle repliche ad alta disponibilità secondo una sequenza controllata.
  • Valida il failover, la connettività delle applicazioni e le prestazioni dopo l'aggiornamento.
  • Microsoft pubblica l'aggiornamento cumulativo (CU) di SQL Server, il release generale di distribuzione (GDR) o aggiornamento di sicurezza applicabile tramite i canali standard di aggiornamento di servizio SQL Server e gli ultimi aggiornamenti e la cronologia delle versioni di SQL Server.

Distribuire gli aggiornamenti di SQL Server e del sistema guest tramite un meccanismo approvato per il sistema operativo guest:

Segui le linee guida separate per gli aggiornamenti delle operazioni disconnesse per gli aggiornamenti delle piattaforme.

Costruire applicazioni di IA locali

SQL Server 2025 può connettersi a endpoint locali approvati per il completamento della chat, come le implementazioni compatibili di Foundry Local. Le applicazioni possono combinare dati SQL con inferenza di modelli on-premises senza richiedere connettività di cloud pubblico.

Foundry Local su Azure Locale è in anteprima. Completare i prerequisiti di implementazione e accesso prima di integrare un modello con SQL Server. Prima di chiamare un endpoint locale del modello:

  • Abilitare l'opzione di configurazione del external rest endpoint enabled server. La procedura è disabilitata di default in SQL Server 2025.
  • Concedere al database chiamante il permesso principale EXECUTE ANY EXTERNAL ENDPOINT e configurare l'autenticazione e le credenziali richieste dall'endpoint.
  • Rendi l'endpoint HTTPS del modello distribuito raggiungibile dalla VM di SQL Server. Configurare i certificati TLS e la fiducia dei certificati per l'uso in produzione. Non affidarti a test di inferenza che bypassano la validazione dei certificati.

Esamina gli endpoint supportati e i requisiti di sicurezza prima di utilizzare sp_invoke_external_rest_endpoint. Per la distribuzione e l'inferenza dei modelli, vedi Foundry Local su Azure Locale, eseguire l'inferenza e usa i tuoi modelli.

L'inferenza locale dei modelli non stabilisce che gli strumenti per sviluppatori possano operare senza connettività cloud. Valida separatamente le esigenze di autenticazione, client e connettività di ogni strumento prima di includerlo in un flusso di lavoro scollegato.

Licenze e confini di supporto

Scegli il modello di licenza SQL Server prima di finalizzare la dimensionamento e la topologia di disponibilità delle VM. Valuta i requisiti di edizione, le licenze per i nuclei virtuali, le licenze fisiche con virtualizzazione illimitata, i diritti di garanzia software o abbonamento e i diritti non legati alla produzione. La capacità della piattaforma di operazioni disconnesse di Azure Locale è concessa in licenza separatamente.

  • Edizione: Validare i requisiti di funzionalità standard e aziendali, inclusi disponibilità, scala, operazioni online e diritti di virtualizzazione.
  • Ambito della licenza: Confronta le licenze virtual-core per VM con i modelli fisici idonei, in particolare quando si consolidano VM SQL Server.
  • Modello di licenza: Validare i requisiti di SQL Server Software Assurance o abbonamento e l'idoneità Vantaggio Azure Hybrid per operazioni disconnesse.
  • Documentazione: Mantieni un inventario di host, VM, core assegnati, edizioni, ambienti e documentazione delle licenze.

Rivedi la fatturazione delle operazioni disconnesse per le condizioni della piattaforma. L'SQL Server abilitato dalla documentazione di licenza Azure Arc descrive l'esperienza di gestione connessa; non è una procedura per installare l'estensione SQL Server non supportata in operazioni disconnesse.

Contenuti correlati

  • Ultimo aggiornamento: