Cos’è SQL Server AlwaysOn?
Da: Simon Liew | Aggiornato: 2017-02-20 | Commenti (10) | Correlati: Altro > Gruppi di disponibilità
Problema
SQL Server AlwaysOn è un termine popolare menzionato in varie fonti, ma cosa significa veramente SQL Server AlwaysOn? Questo suggerimento spiegherà il termine SQL Server AlwaysOn e le sue due tecnologie principali.
Soluzione
SQL Server AlwaysOn è un termine di marketing che si riferisce alla soluzione di alta disponibilità e disaster recovery introdotta con il lancio di SQL Server 2012.
Per essere più specifici, SQL Server AlwaysOn consiste in due tecnologie:
- AlwaysOn Failover Clustering Instances (AlwaysOn FCI)
- AlwaysOn Availability Groups (AlwaysOn AG)
Mentre entrambe le tecnologie hanno delle somiglianze, come il fatto di richiedere Windows Server FailoverClustering (WSFC) come base per la sua implementazione, ciascuna è una tecnologia distinta sotto l’ombrello AlwaysOn.
AlwaysOn Failover Clustering Instances (FCI)
AlwaysOn FCI ha bisogno di storage condiviso come una SAN iSCSI o Fibre Channel a cui possono accedere tutti i nodi del cluster. C’è anche la possibilità di utilizzare strumenti di replica dei dati di terze parti che possono assistere con i requisiti di archiviazione se non si dispone di storage condiviso o si vuole fare questo per le macchine virtuali o nel cloud.
Supporta il clustering multisito attraverso le sottoreti che permette il failover delle istanze di SQL Server attraverso i centri dati, ma questo richiede la replica dei dati tra lo storage condiviso in ogni centro dati.
AlwaysOn FCI è disponibile sia su SQL Server Standard che su Enterprise Edition, ma impone restrizioni su SQL Server Standard Edition come un limite di 2 nodi.
Quando si installa SQL Server si seleziona l’opzione “New SQL failover clusterinstallation”.
Un’implementazione di un sito singolo a due nodi AlwaysOn FCI (usando la modalità quorum Node e DiskMajority) è rappresentata qui sotto.
La modalità quorum aiuta a determinare quali nodi sono disponibili e quali nodi dovrebbero essere il nodo primario. Avendo un’altra macchina/oggetto coinvolto può determinare se la comunicazione tra le macchine è persa e quindi se deve verificarsi un afailover. Di seguito sono riportati esempi comuni di modalità quorum che possono essere utilizzati in una configurazione AlwaysOn FCI.
- Maggioranza del nodo
- Maggioranza del nodo e del file sharing
- Maggioranza del nodo e del disco (simmetrico)
Uno storage simmetrico significa un disco del cluster che è condiviso tra tutti i nodi WSFC. Questo permette che lo storage su disco condiviso sia disponibile a tutti i potenziali failovernodes nel cluster WSFC.
AlwaysOn Availability Groups
AlwaysOn AG non richiede lo storage su disco condiviso per il server che ospita SQL Server. Questa tecnologia di alta disponibilità di SQL Server è stata una caratteristica Enterprise. Questo significa che non è possibile configurare SQL ServerStandard Edition per utilizzare AlwaysOn AG con versioni precedenti a SQL Server 2016.Ora c’è un’opzione per creare un gruppo di disponibilità di base con SQL Server 2016Standard edition che discuto qui sotto.
Quando si installa SQL Server si seleziona l’opzione “New SQL stand-alone…”.
Un’implementazione di AlwaysOn AG per HA e DR (utilizzando la modalità quorum Node Majority) è illustrata di seguito.
Di seguito ci sono diversi esempi comuni di modalità quorum utilizzati in una configurazione AlwaysOn AG.
- Maggioranza di nodo
- Maggioranza di nodo e condivisione di file
- Maggioranza di nodo e disco (asimmetrico)
Uno storage asimmetrico significa che un disco del cluster è condiviso solo tra un sottoinsieme di nodi. La capacità del disco asimmetrico è stata introdotta per la prima volta su Windows Server 2008.permette che un testimone del disco sia configurato e accessibile solo ai nodi di un sito, tipicamente il sito primario.
Nuove caratteristiche in SQL Server 2016
Ora che avete capito le differenze tra AlwaysOn FCI e AlwaysOn AG, SQL Server 2016 ha introdotto due varietà aggiuntive di AlwaysOn AG.
- AlwaysOn Basic Availability Groups (AlwaysOn BAG)
- AlwaysOn Distributed Availability Group (AlwaysOn DAG)
AlwaysOn Basic Availability Group (AlwaysOn BAG)
La funzionalità di AlwaysOn è ora inclusa in SQL Server 2016 Standard Edition, ma viene indicata come AlwaysOn BAG. Viene creato e gestito in modo simile a AG, maAlwaysOn BAG è in grado di utilizzare solo un sottoinsieme di funzioni rispetto al più avanzatoAlwaysOn AG su SQL Server Enterprise Edition. Un esempio di limitazione è che BAG permette solo di avere due repliche (primaria e secondaria).
AlwaysOn BAG fornisce supporto di failover solo per un singolo database, sostituendo il mirroring del database che è deprecato.
AlwaysOn Distributed Availability Group (AlwaysOn DAG)
AlwaysOn DAG sono gruppi di AG liberamente accoppiati. AlwaysOn DAG funziona su due AG distinte, il che significa che risiedono su due WSFC distinte con la propria gestione del quorum e del voto.
Questa configurazione permette alle repliche secondarie di un AG di esistere in una regione geografica diversa da quella primaria. Un esempio di caso d’uso potrebbe essere quello di abilitare carichi di lavoro in sola lettura per regioni remote e allo stesso tempo evitare qualsiasi potenziale problema di rete nel sito secondario che può influenzare il sito primario.
Caratteristiche di AlwaysOn FCI e AlwaysOn AG
Ognuna delle due tecnologie differisce nel suo scopo. È possibile combinare AlwaysOn FCI e AlwaysOn AG. I requisiti aziendali potrebbero richiedere un’elevata disponibilità locale all’interno di un data center utilizzando AlwaysOn FCI, e un disaster recovery cross data center utilizzando AlwaysOn AG. Significa solo che la soluzione consisterebbe in una combinazione di storage condiviso e non condiviso nell’implementazione.
Se vi state chiedendo quale soluzione implementare, la tabella sottostante riassume le somiglianze e le differenze di caratteristiche tra le soluzioni SQL Server AlwaysOn FCI e AlwaysOn AG come guida per la valutazione di SQL Server AlwaysOn.
| AlwaysOn FCI per HA e DR | AlwaysOn AG per HA e DR | |
|---|---|---|
| Soluzione storage condiviso | Non-Soluzione di archiviazione non condivisa | |
| Ha a livello di istanza Logins, SQL Agent, certificati e altri oggetti a livello di istanza di SQL Server sono intatti dopo il failover |
Ha a livello di database (può essere uno o più database) Aggiungimento manuale dei login, SQL Agent, certificati e altri oggetti a livello di istanza di SQL Server a tutti i secondari |
|
| Protezione a livello di istanza senza ridondanza di dati | Ogni gruppo di database secondari AG è una copia ridondante del primario | |
| Avere nodi attivi e passivi. Nessun concetto di database secondario. | La replicaDR può essere attiva secondaria per il backup, carico di lavoro in sola lettura. | |
| L’applicazione si connette tramite il nome del server virtuale | L’applicazione si connette tramite il nome dell’ascoltatore AG | |
| Non mantiene una copia ridondante dei dati, quindi non protegge da un guasto del sottosistema I/O | Protezione contro un guasto del sottosistema I/O i..e Automatic Page Repair | |
| Nessun requisito speciale rispetto ai modelli di recupero dei database | I database in AG devono essere in modello FULL recovery |
Altre cose da notare per entrambi:
- Ogni singola implementazione AlwaysOn è un’implementazione WSFC
- Sia le FCI che le AG possono estendersi su più centri dati, ma con implementazioni diverse
- Possono essere implementate su sistemi fisici SQLServer, o su sistemi SQL Server che sono in esecuzione come macchine virtuali
Sommario
Ogni volta che viene menzionato SQL Server AlwaysOn, non è specifico perché può riferirsi sia a AlwaysOn FCI che a AlwaysOn AG.
In breve:
- AlwaysOn = {SQL Server Failover Cluster Instances, Availability Groups}
- AlwaysOn != SQL Server Failover Cluster Instances != Availability Groups
- Availability Groups != Database Mirroring
- WSFC != SQL Server Failover Cluster Instances
Passi successivi
- Soluzioni ad alta disponibilità (SQL Server)
- Modalità di quorum WWSFC e configurazione del voto (SQL Server)
- Modelli di configurazione del quorum di Windows Server Failover Clustering spiegati
- SQL Server AlwaysOn Availability Groups – Configurazione parte 1
- Installazione di SQL Server 2008 su un cluster di Windows Server 2008 parte 1
- Suggerimenti sul clustering di SQL Server
- Suggerimenti sui gruppi di disponibilità di SQL Server
Ultimo aggiornamento: 2017-02-20
Informazioni sull’autore
Simon Liew è un consulente indipendente di SQL Server a Sydney, Australia. È un Microsoft Certified Master per SQL Server 2008 e ha conseguito un Master in Distributed Computing.Vedi tutti i miei consigli
- Altri consigli per SQL Server DBA…