Gruppo di disponibilità Always On di Microsoft SQL Server in Google Cloud

Last reviewed 2026-08-12 UTC

Questo documento fornisce un'architettura di riferimento per il deployment di database Microsoft SQL Server ad alta affidabilità (HA) in Google Cloud utilizzando un gruppo di disponibilità Always On. Il documento include anche considerazioni sulla progettazione per l'alta affidabilità e il ripristino di emergenza (RE), opzioni di deployment, suggerimenti per l'automazione e indicazioni per le operazioni di backup e RE. Questo documento è rivolto ai professionisti tecnici che stanno valutando Google Cloud come piattaforma per l'esecuzione di database SQL Server. Si presuppone che tu abbia conoscenze di base di Compute Engine e SQL Server.

Google Cloud fornisce soluzioni convenienti, affidabili, sicure e ad alte prestazioni per l'esecuzione di database SQL Server. Per una panoramica delle soluzioni SQL Server supportate in Google Cloud, consulta SQL Server su Google Cloud.

Per gestire un deployment non di sviluppo di SQL Server in Google Cloud, utilizza una delle seguenti opzioni di licenza:

  • Bring Your Own License (BYOL): utilizza le tue licenze Microsoft SQL Server esistenti su Google Cloud. Devi utilizzare nodi single-tenant o Software Assurance con mobilità delle licenze.

  • Utilizza le licenze on demand: utilizza le immagini SQL Server predefinite in Google Cloud e paga una tariffa che include il costo di computing e il costo della licenza Microsoft. Google gestisce i contratti di licenza e la fatturazione di Microsoft.

La sezione Deployment di questo documento fornisce risorse per aiutarti a eseguire il deployment di questa architettura di riferimento.

Architettura

Il seguente diagramma mostra un'architettura di riferimento per un deployment di SQL Server configurato per l'alta disponibilità in Google Cloud:

Un'architettura che mostra un deployment di SQL Server con un gruppo di disponibilità Always On che si estende su VM di Compute Engine in zone e regioni diverse.

L'architettura precedente mostra un gruppo di disponibilità Always On con tre nodi in un cluster di failover di Windows Server (WSFC). Ogni nodo è una VM di Compute Engine che esegue SQL Server.

Un gruppo di disponibilità Always On è un pattern di deployment standard di settore per raggiungere gli obiettivi di affidabilità per i database SQL Server mission-critical. I gruppi di disponibilità Always On forniscono alta affidabilità locale (failover all'interno di una regione) e failover tra regioni per RE. Questo pattern di deployment è un'alternativa di livello enterprise al mirroring del database. Un gruppo di disponibilità Always On offre i seguenti vantaggi:

  • Nessun componente dell'infrastruttura specializzato richiesto: SQL Server gestisce la replica in tutte le repliche di database configurate.
  • Configurazione con SLA più elevato per SQL Server: RTO (Recovery Time Objective) inferiore a un minuto e RPO (Recovery Point Objective) quasi pari a zero.
  • Possibilità di trasferire i workload di sola lettura alle repliche secondarie: scala in modo efficiente il deployment per l'analisi e altri casi d'uso comuni.
  • Nodi in regioni aggiuntive per il DR: esegui il deployment di una replica principale e di un massimo di otto repliche secondarie.
  • Disponibile per Windows e Linux: puoi utilizzare uno strumento di terze parti come Pacemaker come gestore dei cluster per i deployment Linux.

Nell'architettura precedente, i nodi SQL Server principale e secondario si trovano in zone separate all'interno di una regione. Il nodo DR si trova in una regione geograficamente remota. I dati del nodo principale vengono replicati in modo sincrono nel nodo secondario e in modo asincrono nel nodo di RE.

Per distribuire il traffico dal livello di applicazione ai nodi del database principale e secondario all'interno di una regione, puoi utilizzare uno dei seguenti approcci:

Prodotti utilizzati

L'architettura utilizza i seguenti prodotti e componenti Google Cloud e Microsoft.

Google Cloud prodotto

  • Compute Engine: un servizio di computing sicuro e personalizzabile che ti consente di creare ed eseguire VM sull'infrastruttura di Google.
  • Google Cloud Hyperdisk: un servizio di archiviazione di rete che puoi utilizzare per eseguire il provisioning e scalare dinamicamente i volumi di archiviazione a blocchi con prestazioni configurabili e prevedibili.
  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di networking globali e scalabili per i tuoi workload Google Cloud . VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e il VPC condiviso.
  • Cloud Load Balancing: un portfolio di bilanciatori del carico globali e regionali scalabili e ad alte prestazioni.

Prodotti e componenti Microsoft

I seguenti componenti sono inclusi o abilitati sui nodi SQL Server:

  • Windows Server (versione 2019 o successive).
  • WSFC: un gruppo di istanze SQL Server installate su più nodi del cluster Windows Server o su più subnet.
  • Gruppo di disponibilità Always On: un'alternativa di alta affidabilità e RE di livello enterprise al mirroring del database.
  • Listener del gruppo di disponibilità: un nome di rete virtuale (VNN) che i client possono utilizzare per accedere a un database in una replica principale o secondaria di un gruppo di disponibilità Always On. I client non hanno bisogno di conoscere il nome dell'istanza fisica delle repliche. Poiché il listener instrada il traffico, non è necessario modificare la stringa di connessione del client dopo un failover.

Per il deployment di questa architettura sono necessari i seguenti componenti aggiuntivi:

Considerazioni sulla progettazione

Questa sezione descrive i fattori di progettazione, le best practice e i suggerimenti di progettazione che devi considerare quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti di affidabilità, efficienza operativa, sicurezza, costi e prestazioni.

Affidabilità

Questa sezione descrive le considerazioni e i suggerimenti di progettazione per creare e gestire un'infrastruttura affidabile per il deployment di SQL Server inGoogle Cloud.

Scegli una strategia di HA e RE

Per eseguire il deployment di database SQL Server affidabili in Google Cloud, devi adottare una strategia che combini l'infrastruttura solida di Google Cloud con le funzionalità di alta affidabilità e RE di SQL Server. Questa combinazione protegge i tuoi database da errori che vanno da interruzioni a livello di zona a disastri a livello di regione.

Quando progetti la strategia di HA e RE per il deployment di SQL Server, considera i seguenti fattori:

  • RPO: quanta perdita di dati è accettabile in caso di errore?
  • RTO: dopo un errore, quanto velocemente deve tornare operativo il database?
    • Per ottenere un RTO basso, utilizza un gruppo di disponibilità Always On.
    • Se un po' di tempo di inattività è accettabile, ripristina i database dai backup o utilizza la spedizione dei log con failover manuale.
  • Budget: valuta i compromessi tra costo e affidabilità.
    • Costo elevato, ma affidabile: utilizza un gruppo di disponibilità Always On con replica asincrona su nodi aggiuntivi in una regione di RE. Pianifica l'infrastruttura e le licenze ridondanti.
    • Costo medio: implementa la replica asincrona del disco in un'altra regione o utilizza Backup e RE.
    • Costo basso, ma tempo di ripristino elevato: esegui il backup dei database in un bucket Cloud Storage multiregionale.
  • Tipi di errori: quali tipi di errori devi gestire?
    • Per gestire gli errori a livello di hardware, di istanza e di zona, puoi utilizzare i gruppi di disponibilità.
    • Per eseguire il ripristino da interruzioni o disastri a livello di sito, hai bisogno di una soluzione di RE geograficamente dispersa, come la distribuzione dei log o i gruppi di disponibilità Always On con replica asincrona del database.
  • Criticità aziendale: quanto è critica l'applicazione per la tua attività?
    • Le applicazioni mission-critical richiedono una strategia che offra il massimo livello di disponibilità, una perdita di dati minima e un ripristino rapido.
    • Per i sistemi meno critici, prendi in considerazione una strategia che presuppone un tempo di inattività accettabile o una perdita di dati.

Utilizza il seguente questionario sul flusso decisionale per scegliere una strategia di affidabilità ottimale per il tuo database SQL Server. Le opzioni della strategia vanno da un gruppo di disponibilità Always On che fornisce una perdita di dati quasi pari a zero al backup offsite conveniente.

  1. I backup offsite soddisfano i tuoi RPO e RTO?
    • Sì: utilizza backup offsite o la spedizione dei log.
    • No: vai alla domanda successiva.
  2. Il tuo RTO o RPO è inferiore a un minuto?
    • Sì (RPO quasi pari a zero): utilizza un gruppo di disponibilità Always On di SQL Server con una replica del database di RE.
    • No: vai alla domanda successiva.
  3. Qual è il tuo RTO?
    • Meno di cinque minuti: utilizza un gruppo di disponibilità Always On di SQL Server con una replica del disco asincrona.
    • Un'ora o più: vai alla domanda successiva.
  4. Qual è il tuo RPO?
    • Meno di due ore: utilizza un gruppo di disponibilità Always On di SQL Server con Backup e RE.
    • 8 ore o più: utilizza backup offsite o la spedizione dei log.

Scegli le opzioni di backup appropriate

Se la tua strategia di affidabilità include i backup del database, scegli un metodo di backup che soddisfi i tuoi requisiti. Google Cloud offre le seguenti opzioni flessibili e di livello enterprise per il backup dei database SQL Server:

  • Backup diretto in un bucket Cloud Storage: scrivi i backup del database direttamente in Cloud Storage utilizzando il comando BACKUP TO URL e il connettore S3 in SQL Server (versione 2022 o successive). Per gli ambienti di produzione, puoi utilizzare una chiave di accesso HMAC (Hash-based Message Authentication Code). Questa opzione di backup offre una protezione conveniente per database e log senza la necessità di uno spazio di archiviazione locale intermedio.
  • Snapshot istantanei di Compute Engine: acquisisci snapshot simultanei su più dischi (ad esempio, su dischi Google Cloud Hyperdisk bilanciato) in meno di un secondo utilizzando le operazioni di blocco e sblocco di Transact-SQL (T-SQL) combinate con i gruppi di coerenza di Compute Engine. Questa opzione consente backup ad alte prestazioni a livello di VM per i database su più dischi e ha un requisito di blocco della scrittura quasi nullo.
  • Backup e DR: orchestra gli snapshot coerenti con l'applicazione utilizzando i provider Microsoft VSS e i gruppi di coerenza. Questa opzione di backup è adatta quando hai bisogno di un recupero point-in-time (PITR) granulare e multi-database e della possibilità di utilizzare i log per eseguire il roll forward dei database.
  • Google Cloud NetApp Volumes: crea snapshot istantanei e backup asincroni in vault remoti utilizzando il motore di archiviazione ONTAP. Consigliamo NetApp Volumes per le applicazioni aziendali sensibili alla latenza che richiedono una rapida mitigazione del ransomware e cloni efficienti in termini di spazio.

Per i deployment multi-cloud e ibridi che richiedono policy di protezione dei dati unificate, puoi scegliere un prodotto di backup di terze parti come Veeam, Veritas NetBackup o Cohesity.

Operazioni

Per garantire l'alta affidabilità e le prestazioni ottimali dei database SQL Server di cui è stato eseguito il deployment su VM di Compute Engine, configura un sistema completo di monitoraggio e avvisi utilizzando Cloud Monitoring e Cloud Logging.

  • Monitora continuamente le metriche per le risorse principali, come l'utilizzo della CPU e il carico della memoria. Configura avvisi di riferimento per rilevare la pressione sulle risorse prima che le query inizino a peggiorare.
  • Per evitare interruzioni della scrittura nel database, monitora continuamente l'utilizzo dello spazio su disco. Monitora lo stato generale del servizio e configura gli avvisi per ricevere notifiche quando i database si arrestano in modo imprevisto.
  • Per i deployment ad alta affidabilità, monitora eventuali failover non pianificati e assicurati una visibilità completa durante gli eventi di disaster recovery automatici.
  • Oltre alla telemetria a livello di sistema, Google Cloud fornisce una suite completa di metriche specifiche del database, come i limiti di connessione degli utenti attivi, il ritardo di replica e i tassi di transazione. Monitora queste metriche per controllare la disponibilità e le prestazioni dei tuoi database SQL Server.
  • Per acquisire errori a livello di applicazione come deadlock, danneggiamento del database ed errori dei job dell'agente direttamente dai log degli errori di SQL Server, configura avvisi personalizzati basati su log in Logging.

Sicurezza

Questa sezione descrive le considerazioni e i suggerimenti per la progettazione di un deployment di SQL Server in Google Cloud che soddisfi i requisiti di sicurezza del tuo workload.

Sicurezza di rete e isolamento

  • Per impedire l'esposizione esterna dei database, esegui il deployment delle istanze SQL Server con indirizzi IP privati all'interno di un VPC. Utilizza l'accesso privato ai servizi per instradare il traffico internamente. Questo approccio contribuisce a garantire che il traffico del database non attraversi mai la rete internet pubblica.
  • Limita ulteriormente l'accesso ai database configurando regole firewall VPC rigide che consentono il traffico solo da subnet di applicazioni autorizzate o blocchi CIDR specifici.
  • Per proteggere i dati in transito da intercettazioni e intrusioni, implementa la connettività criptata applicando TLS/SSL per tutte le connessioni al database.

Crittografia e controllo delle chiavi

  • Per impostazione predefinita, Google Cloud utilizza chiavi AES-256 gestite da Google per criptare automaticamente tutti i dati at-rest nei dischi del database, nei file temporanei e nei backup. Per soddisfare i requisiti degli ambienti di conformità, puoi implementare la crittografia a livello di database utilizzando la funzionalità di Transparent Data Encryption (TDE) di SQL Server.
  • Per garantire la sovranità dei dati, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK) in Cloud Key Management Service. Le CMEK ti offrono il controllo crittografico completo. Puoi gestire i cicli di vita delle chiavi, impostare pianificazioni di rotazione automatica e revocare istantaneamente l'accesso al database e ai relativi backup quando necessario.

Autenticazione e autorizzazione

  • Integra il tuo database con Microsoft Active Directory o centralizza la gestione delle identità nei database SQL Server e in altre risorseGoogle Cloud utilizzando Identity and Access Management (IAM).
  • Dopo aver stabilito le identità, applica il principio del privilegio minimo in modo che gli utenti e i service account delle applicazioni dispongano solo delle autorizzazioni necessarie per svolgere le loro funzioni. Mappa le identità ai ruoli granulari del database SQL Server.

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare i costi di configurazione e gestione di un deployment di SQL Server creato utilizzando questa architettura di riferimento. L'ottimizzazione dei costi contribuisce a garantire che il deployment soddisfi i requisiti di affidabilità e prestazioni del tuo workload entro i limiti del tuo budget.

Prendi in considerazione i seguenti consigli:

  • Disabilita il multi-threading simultaneo (SMT): disabilitando l'SMT, puoi ridurre del 50% il numero di core segnalati ai fini delle licenze. Eseguendo l'overprovisioning delle CPU del 20% e disabilitando l'SMT, puoi ottenere risparmi sostanziali sui costi delle licenze senza sacrificare le prestazioni. Per maggiori informazioni, consulta Imposta il numero di thread per core.
  • Utilizza SQL Server Standard Edition: a seconda dei requisiti di alta affidabilità e RE, puoi ridurre i costi di licenza utilizzando SQL Server Standard Edition anziché Enterprise Edition. Per saperne di più, consulta Edizioni e funzionalità supportate di SQL Server.
  • Ottimizza lo spazio di archiviazione: Google Cloud Hyperdisk offre diverse opzioni di disco tra cui scegliere in base alle esigenze del tuo deployment di SQL Server. Hyperdisk Balanced offre un equilibrio tra costi e prestazioni. Puoi scalare il throughput e le operazioni di I/O al secondo (IOPS) in modo indipendente, in modo che la spesa per l'infrastruttura corrisponda esattamente alle esigenze del workload. Per saperne di più, consulta la sezione Scegli un tipo di disco di archiviazione appropriato.

Ottimizzazione delle prestazioni

Questa sezione descrive le considerazioni e i suggerimenti di progettazione per un deployment di SQL Server che soddisfi i tuoi requisiti di prestazioni.

Eseguendo il deployment di SQL Server su VM di Compute Engine, ottieni il controllo completo del database e dell'infrastruttura sottostante. Le prestazioni del tuo workload dipendono dall'infrastruttura che scegli. Per bilanciare le prestazioni con i costi e l'affidabilità, devi prendere decisioni informate sulla famiglia di macchine delle VM e sul tipo di disco per i nodi del database.

Scegli una famiglia di macchine VM appropriata

La famiglia di macchine che scegli per le VM di Compute Engine determina la potenza di elaborazione (vCPU) e la memoria (RAM) disponibili per i nodi SQL Server. Queste risorse influiscono sulle prestazioni dei database.

Scegli una famiglia di macchine VM che risolva il principale collo di bottiglia delle prestazioni. Ad esempio, se il database SQL Server ha un utilizzo della CPU costantemente elevato, scegli un tipo di macchina dalla famiglia di macchine ottimizzate per il calcolo. Se il tuo database SQL Server mostra letture lente dal disco, scegli un tipo di macchina ottimizzato per la memoria.

La tabella seguente mette a confronto le famiglie di VM fornite da Compute Engine, il caso d'uso principale di ciascuna famiglia di macchine e l'impatto sulle prestazioni sui database SQL Server:

Famiglia e serie di macchine Caso d'uso primario Impatto sulle prestazioni di SQL Server
Per uso generico (serie di macchine N4) Bilanciamento di prezzo e prestazioni Utilizza questa famiglia di macchine come punto di partenza per la maggior parte dei workload. La serie di macchine N4 offre un equilibrio ottimale tra CPU e memoria per database di uso misto, applicazioni web e ambienti di sviluppo o test.
Ottimizzato per il calcolo (serie di macchine C3 o C4) Le massime prestazioni per core Utilizza questa famiglia di macchine per i workload con vincoli di CPU. Per i database che eseguono query complesse, elaborano grandi volumi di dati o gestiscono un numero elevato di operazioni di elaborazione delle transazioni online (OLTP), utilizza le serie di macchine C3 e C4. I tipi di macchine di queste serie contribuiscono a ridurre in modo significativo il tempo di esecuzione delle query.
Ottimizzate per la memoria (serie di macchine M3 o M4) Rapporti memoria/vCPU elevati Questa famiglia di macchine è ideale per le applicazioni che richiedono molta memoria. SQL Server memorizza nella cache i dati e i piani di esecuzione, il che offre prestazioni più elevate rispetto alla lettura dai dischi. Con database o data warehouse di grandi dimensioni per l'elaborazione analitica online (OLAP), le query in genere analizzano tabelle e set di dati di grandi dimensioni. Per questi casi d'uso, una memoria più elevata contribuisce a migliorare le prestazioni.

Per saperne di più, consulta la guida alle risorse e al confronto per le famiglie di macchine.

Scegli un tipo di disco di archiviazione appropriato

Le prestazioni del disco sono un fattore significativo per la reattività del database, che è fondamentale per le prestazioni dell'applicazione. Per i tipi di dischi offerti da Google Cloud, le prestazioni sono indicate utilizzando le seguenti metriche:

  • IOPS: il numero di richieste di lettura e scrittura che un disco può gestire al secondo. Le IOPS sono fondamentali per i workload OLTP che comportano molte operazioni di lettura e scrittura casuali di piccole dimensioni, come l'aggiornamento dei record dei clienti o l'elaborazione degli ordini.
  • Throughput: la quantità totale di dati che possono essere spostati da o verso il disco al secondo. Il throughput è essenziale per i workload OLAP che prevedono la scansione di grandi quantità di dati, come l'esecuzione di report, il data warehousing o l'esecuzione di backup.

La tabella seguente fornisce un confronto dei tipi di dischi Google Cloud tra cui puoi scegliere:

Tipo di disco Caratteristiche delle prestazioni Idoneità dei workload
Disco permanente SSD (pd-ssd) Prestazioni medio-alte a seconda del tipo di macchina della VM e delle dimensioni del disco Workload che richiedono prestazioni scalabili in base alle dimensioni del disco e alle vCPU della VM. Per saperne di più, consulta la panoramica delle prestazioni di Persistent Disk.
Hyperdisk bilanciato Prestazioni elevate con IOPS e throughput configurabili File di dati e di log di SQL Server di produzione. Hyperdisk bilanciato consente di configurare le IOPS e il throughput indipendentemente dalle dimensioni del disco e in base alle esigenze del workload.
Google Cloud Hyperdisk Extreme Prestazioni molto elevate con IOPS configurabili Workload OLTP mission-critical di fascia alta che richiedono IOPS massime e la latenza più bassa, come sistemi finanziari o di e-commerce su larga scala.
SSD locale IOPS e throughput più elevati rispetto agli altri tipi di disco Dati temporanei che non richiedono la durabilità dei Persistent Disk. Per dati come il database di sistema tempdb e il file di paging di Windows, le unità SSD locali offrono la latenza più bassa perché sono fisicamente collegate alle VM.

Abbina l'infrastruttura ai requisiti di prestazioni

Scegli i tipi di macchina e di disco delle VM in base ai requisiti di prestazioni del tuo workload. La tabella seguente suggerisce le configurazioni dell'infrastruttura per diversi scenari di workload:

Scenario Requisiti delle prestazioni Configurazione del disco e tipo di macchina consigliati
Database di e-commerce con un elevato numero di transazioni per OLTP IOPS elevato per gestire migliaia di piccole letture e scritture simultanee

Tipo di macchina VM: scegli un tipo di macchina ottimizzata per il calcolo (ad esempio, dalla serie di macchine C4) per un'elaborazione efficiente delle transazioni.

Dischi di dati e log: utilizza dischi Hyperdisk Balanced. Esegui il provisioning di un livello elevato di IOPS per soddisfare la domanda transazionale. Utilizza dischi separati per dati e log.

tempdb: utilizza i dischi SSD locali per l'offload delle operazioni temporanee e massimizzare le prestazioni.
Data warehouse aziendale per OLAP Throughput elevato per analizzare e aggregare terabyte di dati per i report

Tipo di macchina VM: scegli un tipo di macchina ottimizzato per la memoria (ad esempio, dalla serie di macchine M4), in modo da poter memorizzare nella cache la maggior parte possibile del set di dati di grandi dimensioni.

Disco di dati: utilizza i dischi Hyperdisk Balanced. Esegui il provisioning di un livello elevato di throughput per accelerare le scansioni di dati di grandi dimensioni.
Server di sviluppo o di gestione temporanea Convenienza piuttosto che prestazioni di picco

Tipo di macchina VM: scegli un tipo di macchina per uso generico con dimensioni ridotte della serie di macchine E2 o N4.

Dischi: utilizza Balanced Persistent Disk (pd-balanced) per tutti i file di database in modo da ottenere prestazioni accettabili a un costo ridotto.

Deployment

Per eseguire il deployment di questa architettura di riferimento, utilizza una delle seguenti risorse:

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: Kumar Dhanagopal | Cross-Product Solution Developer