Quando i server sono inattivi, possono causare interruzioni ai tuoi obiettivi aziendali e causare una perdita di entrate. Ad esempio, una compagnia aerea potrebbe non essere in grado di prenotare voli per i clienti se le istanze e i database non sono disponibili. I sistemi possono non funzionare per una serie di motivi, come incendi, errori umani, errori del computer, errori del disco ed errori di programmazione.
Per evitare interruzioni e garantire continuità nei servizi aziendali, è estremamente importante disporre di strategie di alta disponibilità (HA) e ripristino di emergenza (DR). HA e DR sono spesso discussi insieme. HA si preoccupa di ridurre il più possibile i tempi di inattività del server, ma poiché nessun sistema è perfetto, il DR si concentra sul processo di utilizzo del supporto di backup per recuperare i dati persi nel caso in cui il sistema del database si interrompa.
AlwaysOn è un termine di marca/marketing utilizzato da SQL Server 2012 per descrivere le funzionalità HADR avanzate di Microsoft. Prima di AlwaysOn, il motore di database supportava altre soluzioni proprietarie integrate, come mirroring del database, cluster di failover e log shipping. Tuttavia, ciascuna di queste tecniche presentava vantaggi e limitazioni. Spesso, a seconda dei suoi obiettivi, un'organizzazione doveva combinare più metodi insieme per ottenere una strategia HADR desiderabile.
Le funzionalità AlwaysOn sono state introdotte in modo che tu non debba occuparti di tempo e risorse extra per implementare e introdurre complessità nella distribuzione per tenere conto della ridondanza del server e del database, incorrere in problemi con il ridimensionamento o avere hardware di standby che non viene utilizzato in modo efficiente. Queste caratteristiche uniscono convenientemente molte delle vecchie pratiche e migliorano le aree in cui non erano all'altezza. Per comprendere veramente il valore delle offerte AlwaysOn, è importante rivisitare i concetti fondamentali iniziali di come il motore di database garantisse il sistema HADR in passato.
Mirroring del database
La ridondanza del database può essere ottenuta tramite il mirroring. Ad esempio, puoi avere un'app client front-end che genera entrate che consente agli studenti di ordinare libri di testo online. Un cliente seleziona il proprio acquisto e le richieste vengono effettuate sul database di PsychologyBooks sul back-end. In caso di disastro che renda indisponibile il database di PsychologyBooks, lo studente non sarà in grado di completare l'ordine.
Per evitare questa interruzione, puoi avere un'istanza principale distribuita in produzione che contiene il database PsychologyBooks e avere una copia aggiuntiva di quel database PsychologyBooks su un server con mirroring in standby. Le app client possono riconnettersi alla copia con mirroring invece di subire interruzioni e dover attendere che il ripristino si concluda sul primario. La copia tiene il passo con le modifiche apportate all'originale ricevendo i registri delle transazioni e quindi rifacendo le modifiche registrate.
Le sessioni di mirroring possono funzionare in modalità diverse a seconda delle prestazioni o delle giustificazioni di sicurezza elevata. Convenientemente, il failover automatico è supportato quando la sessione di mirroring viene eseguita in modalità sincrona ad alta sicurezza e viene stabilito il consenso del quorum con la presenza di un server di controllo facoltativo.
Nonostante i vantaggi del mirroring, non è all'altezza perché fornisce solo la ridondanza del database, non la ridondanza del server. Ciò significa che se l'istanza del server primario si interrompe, entrambe le istanze si disattivano e non importa che sia presente una copia di riserva dei dati a livello di database. Lo standby non supporta le operazioni dell'utente e sarebbero necessari snapshot per ottenere una copia di sola lettura dei dati sull'istanza con mirroring. Il database è protetto, ma gli oggetti a livello di server, come l'appartenenza al ruolo del server, le informazioni di accesso ei lavori dell'agente, non lo sono.
Ad esempio, se esistesse un grande team di marketing e ogni membro avesse il proprio login, dovrebbe ripetere da capo il processo di ricreazione degli accessi per ogni persona. Quando si verifica il failover, è su una base di database indipendente e non come gruppo.
Gruppo di failover
Il clustering di failover offre ridondanza a livello di istanza e fornisce protezione da guasti hardware e del sistema operativo. Ad esempio, supponiamo che un nodo in Queen Anne prenda fuoco, causando un guasto all'apparecchiatura. L'intera istanza, che include oggetti a livello di istanza, come accessi o lavori specifici creati per eseguire attività specifiche, sarà protetta e potrà essere riavviata automaticamente su un altro nodo appartenente al cluster. Le app e i servizi client continueranno a essere disponibili per i clienti.
Lo scenario precedente funziona perché l'archiviazione è condivisa tra server fisici ridondanti in un gruppo di cluster di failover di Windows Server (WSFC). Sia il sistema operativo che SQL Server interagiscono in modo che un solo nodo alla volta possieda il gruppo di risorse WSFC.
Sfortunatamente, con uno storage comune, questa soluzione non fornisce la ridondanza del database fornita dalla precedente strategia di mirroring. Avere uno storage condiviso introduce dei rischi perché si traduce in un singolo punto di errore. Ad esempio, i dischi esterni possono contenere l'unica copia dell'importante database di PsychologyBooks e, nonostante il failover dell'istanza sul nodo Ballard, si verificherebbe comunque un'interruzione degli obiettivi aziendali se l'unico componente di archiviazione fosse compromesso. Il clustering di failover propone anche vincoli in termini di scalabilità perché le app client non sono in grado di gestire una quantità crescente di lavoro che si espande oltre il cluster.
Spedizione log
Un altro metodo per ottenere la ridondanza del database è il log shipping. I registri delle transazioni vengono sottoposti a backup sul server primario e inviati a uno o più server secondari per il ripristino. A differenza del mirroring, i database secondari possono essere idonei per l'attività di sola lettura e la frequenza del log shipping può essere configurata per intervalli diversi. C'è un vantaggio in termini di prestazioni negli scenari in cui i database secondari non devono necessariamente essere sincronizzati con il database primario in tempo reale.
Ad esempio, l'esecuzione di un rapporto di riepilogo statistico alla fine della notte per vedere quali libri di psicologia vengono venduti durante il giorno non richiede che il database di copia sia esattamente sincronizzato con il database principale. L'attività ad alta intensità di lettura blocca gli oggetti del database e può aumentare i tempi di attesa. Pertanto, l'esecuzione di report su un server secondario allevierebbe la richiesta di carico di lavoro sul server generatore di entrate principale.
Lo svantaggio è che il log shipping non supporta il failover automatico. Pertanto, se il server di origine si guasta, il database deve essere ripristinato manualmente. Come il mirroring, il log shipping non fornisce ridondanza del server ed è una soluzione a livello di database.
Capire AlwaysOn
Ciascuna delle vecchie tecnologie ha i suoi vantaggi e compromessi. Ma l'implementazione di una soluzione HADR personalizzata può diventare rapidamente complicata e richiedere una maggiore gestione poiché queste diverse strategie vengono arbitrariamente mescolate e abbinate insieme per soddisfare le esigenze aziendali. Pertanto, le funzionalità AlwaysOn sono state introdotte e forniscono una versione migliorata, già combinata, delle strategie precedenti.
SQL Server offre due funzionalità:gruppi di disponibilità AlwaysOn (AG) e istanze del cluster di failover AlwaysOn (FCI). Entrambi richiedono l'implementazione del clustering di failover di Windows Server (WSFC).
Un AG è un gruppo di database che eseguiranno il failover insieme. Saranno necessari diversi nodi fisici ridondanti con un'istanza di SQL Server installata su ciascuno dei nodi per ospitare le repliche di disponibilità. Ogni replica deve trovarsi su un nodo diverso dello stesso WSFC. Nello schema sopra, la replica primaria è ospitata sul nodo 01 e tutte le altre repliche secondarie sono idonee per il failover quando WSFC rileva che c'è un problema.
Il modo in cui le repliche secondarie rimangono sincronizzate con quelle primarie consiste nell'invio dei registri delle transazioni e nella ripetizione delle modifiche. AG supporta sia la modalità commit asincrona che sincrona. La replica primaria è idonea per la lettura e la scrittura, mentre le repliche secondarie sono idonee per la sola lettura. I backup possono essere eseguiti nella posizione secondaria.
Immediatamente, ci sono vantaggi con AlwaysOn AG. Ricordiamo da prima che alcuni dei difetti con il mirroring del database sono che un database può essere sottoposto a mirroring solo su un server secondario e che quando si verifica il failover, ogni database viene rispecchiato in modo indipendente. Con AG, i database vengono resi ridondanti in molte posizioni, come il nodo 02, il nodo 03, il nodo 04 e il nodo 05 nell'esempio precedente. Il supporto della disponibilità del database consente fino a nove repliche di disponibilità.
Inoltre, sarebbe necessario il log shipping per ottenere dati di sola lettura sul server secondario. Ma con AG, i dati di sola lettura sono già contabilizzati. Le attività ad alta intensità di lettura come i report possono essere eseguite su qualsiasi replica secondaria. Si noti inoltre che non esiste un vincolo di archiviazione condivisa.
Tuttavia, AG può essere combinato con AlwaysOn FCI per consentire la ridondanza del server. Un'istanza FCI può essere utilizzata per ospitare le repliche di disponibilità in modo che anche gli oggetti a livello di server come accessi e lavori dell'agente possano essere protetti. Questo approccio richiederà l'archiviazione condivisa. Tuttavia, verranno eliminati gli inconvenienti come la necessità di eseguire riconfigurazioni per le app client.
