Supponendo che sia necessario assicurarsi che l'applicazione che si basa su SQL Server 2012 come backend del database sia disponibile 24 ore su 24, anche se un computer server non funziona.

Come sviluppatore e non come DBA, faccio fatica a capire quando utilizzare quale scenario per il mio failover / alta disponibilità:

• Due (o più) server in un cluster di Failover di Windows, SQL Server come istanza cluster
• Due (o più) istanze di SQL Server mantenute aggiornate con la replica transazionale
• Due (o più) server SQL in un gruppo di disponibilità di SQL Server, configurati in modalità di commit sincrono

Quale di ciascuno di questi scenari funziona per quale tipo di carico di lavoro e quale tipo di guasto / interruzione può essere gestito da tali scenari? Sono persino comparabili / scambiabili?

Il modo in cui mi piace sempre visualizzare le soluzioni ad alta disponibilità è il seguente:

Istanza del cluster di failover di SQL Server (FCI)

Cosa è altamente disponibile? L'intera istanza. Ciò include tutti gli oggetti server (accessi, lavori di SQL Server Agent, ecc.). Ciò include anche i database e le loro entità di contenimento. È un'ottima soluzione per le istanze di SQL Server a disponibilità elevata, perché sarà il livello di contenimento con questa soluzione data.

Che dire dei rapporti? Nessuno, NULL, inesistente. Un'istanza del cluster di failover ha un nodo attivo che consegna il gruppo di cluster contenente l'istanza, VNN, ecc. E tutti gli altri nodi sono passivi, inattivi (per quanto riguarda l'attuale gruppo di cluster) e in attesa di un failover.

Cosa succede in caso di failover? Il tempo di inattività di una FCI sarà determinato dalla quantità di tempo impiegata dal nodo passivo per acquisire la risorsa del cluster e portare l'istanza di SQL Server in uno stato di esecuzione. Questo è in genere minimo nel tempo.

Qualche astrazione del cliente? Sì, questo verrà incorporato in modo innato con il nome della rete virtuale per l'istanza del cluster di failover. Questo indicherà sempre il nodo attivo che sta attualmente distribuendo la risorsa cluster di SQL Server.

Gruppi di disponibilità AlwaysOn

Cosa è altamente disponibile? Un gruppo di disponibilità sarà il contenimento logico dell'alta disponibilità qui, mentre un gruppo di disponibilità è costituito da un numero di database e un nome di rete virtuale (il listener, una risorsa cluster opzionale). Vale la pena notare che gli oggetti server come accessi e lavori di SQL Server Agent non faranno parte della soluzione HA e occorre prestare particolare attenzione per garantire che siano implementati correttamente con un gruppo di disponibilità. Non è un requisito eccessivamente gravoso, ma deve essere curato.

Che dire dei rapporti? Questa è un'ottima soluzione per i report, anche se probabilmente non userei una replica sincrona come istanza di reporting. Esistono due relazioni di commit, sincrone e asincrone. Secondo me e da quello che ho visto in pratica, è che la tua replica secondaria sincrona è lì in attesa di un disastro. Pensala come quella replica pronta a eseguire un failover senza perdita di dati in caso di problemi. Quindi esistono repliche asincrone in grado di gestire quel carico di lavoro di reporting. Non stai usando questa replica come soluzione di cui sopra, ma per altre cose come la segnalazione. I carichi di lavoro di reporting possono essere indirizzati a questa replica (direttamente o indirettamente tramite il routing di sola lettura tramite il listener).

Cosa succede in caso di failover? Per una replica secondaria di commit sincrono associata a failover automatico, si tratterà della modifica dello stato del ruolo di replica da SECONDARY_NORMAL a PRIMARY_NORMAL. Affinché ci sia un failover automatico, è necessario disporre di una replica secondaria sincrona attualmente sincronizzata e ciò che è implementato è il criterio di failover flessibile per determinare quando effettivamente dovrebbe verificarsi questo failover. Tale politica è effettivamente configurabile.

Qualche astrazione del cliente? Sì, è possibile configurare facoltativamente un listener di gruppi di disponibilità AlwaysOn. Questo è fondamentalmente solo un nome di rete virtuale (può essere visto tramite WSFC come una risorsa cluster nel gruppo cluster dell'AG) che punta alla replica primaria corrente. Questa è una parte fondamentale dello spostamento del carico di lavoro dei report e della creazione di un elenco di routing di sola lettura su tutti i server su cui si desidera reindirizzare il traffico ReadOnly (impostato tramite la stringa di connessione, con il provider .NET Framework per SQL Server, questo sarà il parametro Intento applicazione , impostato su ReadOnly ). È inoltre necessario impostare un URL di routing di sola lettura per ogni replica che si desidera ricevere questo carico di lavoro di report mentre si è nel ruolo di replica secondaria.

Replica transazionale

Cosa è altamente disponibile? Questo è discutibile, ma non dirò nulla . Non vedo la replica come una soluzione ad alta disponibilità. Sì, le modifiche ai dati vengono inviate agli abbonati ma stiamo parlando a livello di pubblicazione / articolo. Questo sarà un sottoinsieme dei dati (potrebbe includere tutti i dati, ma ciò non verrà applicato. Vale a dire creare una nuova tabella nel database del publisher e che non verrà automaticamente inviato agli abbonati). Per quanto riguarda l'HA, questo è il fondo del barile e non lo raggrupperò lì con una soluzione HA solida come una roccia.

Che dire dei rapporti? Un'ottima soluzione per la segnalazione di un sottoinsieme di dati, non c'è dubbio. Se si dispone di un database da 1 TB altamente transazionale e si desidera mantenere tale carico di lavoro di reporting fuori dal database OLTP, la replica transazionale è un ottimo modo per inviare un sottoinsieme di dati a un abbonato (o agli abbonati) per il carico di lavoro di reporting. Cosa succede se su quei 1 TB di dati il ​​carico di lavoro dei report è solo di circa 50 GB? Questa è una soluzione intelligente e relativamente configurabile per soddisfare le esigenze della tua azienda.

Sommario

Ciò che si riduce a una manciata di domande a cui è necessario rispondere (in parte dall'azienda):

1. Cosa deve essere altamente disponibile ?
2. Cosa impone lo SLA per HA / DR?
3. Che tipo di segnalazione avverrà e quali latenze sono accettabili?
4. Cosa dobbiamo gestire con l' HA geograficamente disperso ? (la replica dell'archiviazione è costosa, ma indispensabile con una FCI. Le AG non richiedono l'archiviazione condivisa da istanze autonome e potresti utilizzare un testimone di condivisione file per il quorum che potenzialmente elimina la necessità di archiviazione condivisa)

due (o più) server in un cluster di Failover di Windows, SQL Server come istanza cluster

1. Che tipo di carico di lavoro? "Dipende" - ma seriamente, questo è utile per un'applicazione online in cui è necessario disporre della disponibilità locale nel data center. Sei protetto da un guasto di una macchina o di un sistema operativo. Gli accessi, i lavori, i nuovi database, la manutenzione, ecc. Sono tutti automaticamente sincronizzati dal fatto che si tratta di un cluster con due nodi che sono esattamente gli stessi condividendo lo stesso archivio in modo da avere tutti gli stessi database di sistema. Failover molto veloce, ma c'è ancora un singhiozzo che sembra un riavvio di SQL Server quando si verifica il failover.

2. Contro / Preoccupazioni - Un singolo punto di errore è la tua memoria e tutti i suoi componenti. I venditori di SAN affermano sempre che "le SAN non si guastano" ma ci sono molte parti mobili in una rete di archiviazione e, come ho scritto qui sul blog , possono farlo . Inoltre, stai pagando un server secondario che non può fare altro che restare in attesa e aspettare .. Ora puoi fare Active / Active / Multi-Node e avere due istanze attive che possono eseguire il failover in entrambe le direzioni e utilizzare il secondo nodo.

3. Failover automatico? Il "più" automatico. Nessun testimone necessario, è un cluster. Questo è il lavoro di un cluster, per renderlo il più fluido possibile. Ora con uno di questi, quando si verifica un failover, lo "sentirai", perché SQL deve avviarsi o le connessioni devono puntare. Qui quando succede, ti sentirai sostanzialmente come un riavvio di SQL, i DB tornano indietro ed eseguono il ripristino / ecc.

Se ho un client che dice "Voglio essere pienamente aggiornato con tutti i database, tutti gli accessi, ecc." In un ambiente ad alta disponibilità nel mio data center locale perché ho una tolleranza incredibilmente bassa per i tempi di inattività, prenderei in considerazione le istanze del cluster di failover (sebbene il l'ultima opzione che menzionate è un forte contendente, salvo per dover fare un po 'di spese di gestione). Probabilmente farei un FCI locale e un secondario asincrono AG per proteggere da guasti al sito o guasti SAN.

due (o più) istanze di SQL Server mantenute aggiornate con la replica transazionale

1. Che tipo di carico di lavoro? Onestamente non andrei qui per molti casi di necessità di High Availability o Disaster Recovery come prima scelta. Non in SQL 2012 di sicuro. Ma fondamentalmente questo è buono se dovessi andare in un data center che non era vicino, non potevi usare una AG (forse un problema di dominio che ti impediva di usare il cluster di Windows richiesto per la AG), forse volevi essere nello standard di SQL Server che può eseguire la replica, ma non gli AG ma si desidera comunque avere la possibilità di leggere sul lato secondario ed essere asincroni.
2. Contro / Preoccupazioni - È la replica. Ha un sovraccarico, può non essere sincronizzato, puoi sviluppare problemi con le prestazioni sul lato sorgente, ecc.
3. Failover automatico - No. Devi gestirlo da solo. O attraverso CNAME che indicano l'uno o l'altro, e in teoria potresti scrivere il tuo processo per farlo, ma fuori dagli schemi? Nota qui.

due (o più) server SQL in un gruppo di disponibilità di SQL Server, configurati in modalità di commit sincrono

Questo è ciò che ho aiutato le persone a implementare sempre di più negli ultimi tempi, anche se a volte vado ancora al raggruppamento.

1. Che tipo di carico di lavoro? Questo è fantastico quando ho un set gestibile di database da mantenere sincronizzato, e le risorse e il tempo per assicurarmi che lavori, accessi, nuovi database, ecc. Rimangano sincronizzati (anche se il team di SQL Skills ha creato un ottimo componente aggiuntivo per automatizzare parte di questo per te rendendolo ancora più forte di un'opzione). Mi piace quando voglio mantenere le cose completamente separate. Sto proteggendo da problemi hardware, problemi di sistema operativo, problemi di installazione SQL, problemi di patch e problemi di SAN / archiviazione. Ho anche il vantaggio della possibilità di avere un secondario (se voglio pagare una licenza aziendale per esso) per essere un secondario attivo da cui posso leggere, fare backup, ecc. Inoltre in futuro posso aggiungere un terzo secondario asincrono in un sito remoto e con failover / DR.
2. Contro / Preoccupazioni Le licenze, il numero massimo di repliche, i costi delle licenze per trarre vantaggio da alcuni dei maggiori vantaggi (attivo secondario), richiedono impresa, richiedono il doppio dello spazio di archiviazione rispetto al clustering.
3. Failover automatico - Sì. Ciò può verificarsi con un'impostazione di controllo e gli sviluppatori di app possono connettersi all'ascoltatore anziché a un nodo, quindi il failover si verifica con il punto in cui l'ascoltatore punta e dovresti essere bravo lì. Quindi sì, puoi farlo qui - e dovresti - ma ovviamente dovresti testarlo bene.

Sommario

HA e DR sono diversi. E queste tecnologie aiutano a fornire pezzi di entrambi. Alta disponibilità significa (per me) che puoi recuperare rapidamente se succede qualcosa di brutto a una macchina, hai a disposizione un breve Obiettivo del punto di ripristino e Obiettivo del tempo di recupero. Questo è il clustering e un AG sincrono.

Disaster Recovery è "puoi rialzarti quando hai un errore anche nella tua soluzione HA. Per me questo può essere AGs quando vai in un altro data center, mirroring o persino replica.

È anche importante considerare ciò che è condiviso .

Il clustering di failover utilizza due o più nodi server che condividono un array di dischi. Se l'array del disco si arresta, si perde il servizio, indipendentemente dal numero di nodi server presenti. Se la sala server in cui si trova quell'array di dischi prende fuoco o inondazioni, si perde il servizio.

I gruppi di disponibilità AlwaysOn e il mirroring del database sono una tecnologia di clustering "nulla condiviso". Il database è presente su più array di dischi in più server. Se disponi di buoni collegamenti di rete, i servizi multipli possono trovarsi in più sale server, proteggendoti da incendi e inondazioni.

Solo per completezza, c'è la possibilità di utilizzare il semplice vecchio mirroring. I vantaggi qui includono avere due copie del database senza la complessità dell'utilizzo dei gruppi di disponibilità e senza la necessità di archiviazione condivisa per il clustering di failover. Lo svantaggio, sebbene lieve, è il mirroring è deprecato.

I tempi di failover con il mirroring sono dell'ordine di 10 secondi, anche se il codice dell'applicazione deve essere in grado di riprovare qualsiasi transazione che si sta verificando al momento del failover.