[Fonte] Alta Disponibilità in SQL Server (1) ---- una panoramica dell'alta disponibilità

Dal 2005 di SQL Server, Microsoft ha fornito una varietà di tecnologie ad alta disponibilità per ridurre i tempi di inattività e aumentare la protezione dei dati aziendali, e con il rilascio continuo di SQL Server 2008, SQL Server 2008 R2 e SQL Server 2012, ci sono molte tecnologie ad alta disponibilità in SQL Server per adattarsi a diversi scenari.

    Prima di iniziare questo articolo, inizierò con una breve panoramica di ciò che determina quale tecnologia ad alta disponibilità utilizzare.

    Molte aziende hanno bisogno che tutti o parte dei loro dati siano altamente disponibili, come i siti di shopping online, i database di prodotti online devono essere online 24 ore su 24, 7 giorni su 7, altrimenti in un ambiente di mercato altamente competitivo, il tempo di inattività significa perdita di clienti e ricavi. Ad esempio, in un call center che si basa su SQL Server, se il database si blocca, tutti i chiamanti possono solo sedersi e rispondere al cliente "Scusa, guasto del sistema", cosa anch'essa inaccettabile.

    Naturalmente, in un mondo ideale, tutti i dati critici sarebbero online in ogni momento, ma nel mondo reale ci sarebbero varie ragioni per cui il database non è disponibile, poiché è impossibile prevedere il momento e la forma del disastro, quindi è necessario adottare misure anticipate per prevenire varie emergenze, quindi SQL Server offre una varietà di tecnologie ad alta disponibilità, che includono principalmente: clustering, replicazione, mirroring, consegna di log, gruppi di disponibilità AlwaysOn e altre come backup e ripristino di file group, Tecnologie ad alta disponibilità a singola istanza come gli indici di ricostruzione online. L'uso della tecnologia ad alta disponibilità non serve a scegliere una tecnologia familiare per un uso diretto, ma a considerare l'azienda e la tecnologia in modo completo. Perché non esiste una tecnologia unica che possa raggiungere tutte le funzioni. Come adottare queste tecnologie in base alla propria attività specifica e al budget è ciò che viene chiamato una strategia ad alta accessibilità.

Quando si progetta una strategia ad alta accessibilità, dovresti prima considerare i seguenti fattori:

• RTO (Recovery Time Objective) - cioè obiettivo di tempo di recupero, indica quanto tempo di inattività è consentito, solitamente espresso da pochi 9 secondi, ad esempio, il 99,999% di disponibilità significa non più di 5 minuti di inattività all'anno, il 99,99% di disponibilità non più di 52,5 minuti all'anno, e il 99,9% di disponibilità non più di 8,75 ore di inattività all'anno. Vale la pena notare che il metodo di calcolo dell'RTO tiene conto se il sistema è 24*365 o semplicemente dalle 6 del mattino alle 21, ecc. Devi anche prestare attenzione se la finestra di manutenzione viene conteggiata come tempo di inattività, ed è più facile ottenere una maggiore disponibilità se la manutenzione e le patch del database sono consentite durante la finestra di manutenzione.
• RPO (Recovery Point Objective) – Noto anche come obiettivo del punto di recupero, indica quanta perdita di dati è consentita. Di solito, finché fai un buon backup, puoi facilmente ottenere perdite di dati zero. Ma quando si verifica un disastro, a seconda dell'entità della corruzione del database, il tempo necessario per ripristinare i dati da un backup farà sì che il database diventi non disponibile, influenzando così l'implementazione dell'RTO. Un esempio precoce e più famoso è un sistema bancario in Europa e negli Stati Uniti, considerando solo l'RPO, nel sistema ci sono solo backup completi e di log backup, backup completi ogni 3 mesi, backup di log ogni 15 minuti; quando si verifica un disastro, solo tramite backup completi e backup di log possono ripristinare i dati, quindi, anche se non ci sono perdite di dati, poiché ci sono voluti due giorni interi per ripristinare i dati, il sistema bancario è rimasto indisponibile per 2 giorni, perdendo così un gran numero di clienti. Un altro esempio opposto è un sito web video online domestico, che utilizza SQL Server come database relazionale back-end, il front-end utilizza No-SQL e importa regolarmente dati No-SQL nel database relazionale come backup.
  

    Budget – RTO e RPO sono collettivamente conosciuti come SLA (Service Level Agreements), e quando si progetta una strategia ad alta disponibilità, è necessario misurare quanto bene si rispettano gli SLA in base alla propria azienda, in base al budget e misurando il costo dei diversi SLA in caso di guasto. In generale, è difficile raggiungere alti SLA con un budget limitato, e anche se tali SLA si ottengono tramite architetture complesse, queste comportano anche elevati costi operativi e di manutenzione, quindi è necessario scegliere la tecnologia giusta all'interno del budget per rispettare gli SLA.

Pertanto, in generale, il grande quadro per un'alta disponibilità può essere determinato da diverse domande di presa degli ordini:

• Qual è il tempo di inattività che gli azionisti sono disposti ad accettare?
• Quali tempi di inattività sono accettabili per i manager?
• Qual è il budget previsto per uno scenario ad alta disponibilità?
• Quanto è la perdita per ora dovuta al tempo di inattività?
  

• Backup a freddo: Il server di standby è configurato per accettare i dati del server primario e, in caso di guasto, ripristinare manualmente i dati nel database primario o riconfigurare la stringa di connessione o i permessi del programma per attivare il database di backup.
• Backup caldo: I dati del server primario trasmetteranno continuamente i log al server di backup (a intervalli irregolari possono essere di 15 minuti, 30 minuti, 1 minuto, ecc.), in questo modo il server primario verso il server di backup viene solitamente aggiornato asincronamente, quindi i dati del server principale e del server di backup non possono essere garantiti. Inoltre, questo schema tipicamente non implementa il monitoraggio automatico dei guasti e il failover.
• Backup a caldo: I dati del server primario sono automaticamente sincronizzati sul server di backup e, nella maggior parte dei casi, sono inclusi il monitoraggio automatico dei guasti e il failover, garantendo la coerenza dei dati tra il server principale e quello di backup.
  

    Con i backup da freddo a caldo o caldo, i costi schizzano alle stelle.

    Le funzionalità ad alta disponibilità supportate da SQL Server sono strettamente correlate a quella della versione, e l'edizione Enterprise supporta tutte le funzionalità ad alta accessibilità, inclusi:

• Cluster di failover
• L Immagine del database
• L Trasmissione del log delle transazioni
• L Istantanee del database
• L Aggiornamenti ad alta disponibilità
• L Memoria a caricamento caldo
• L Operazioni di indicizzazione online
• Database parzialmente online (solo il gruppo file master o gruppo file master e file NDF aggiuntivi vengono ripristinati)
  

    Per versioni specifiche con alta disponibilità, vedi:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxVale la pena notare che la versione Express gratuita può fungere da server testimone per il mirroring del database, con conseguente risparmio sui costi.

Cluster di failover

    I cluster di failover forniscono supporto ad alta disponibilità per l'intera istanza di SQL Server, il che significa che un'istanza SQL Server su un nodo del cluster effettua il failover verso altri nodi del cluster a causa di errori hardware, errori del sistema operativo, ecc. L'alta disponibilità è ottenuta da più server (nodi) che condividono uno o più dischi, e i cluster di failover appaiono nella rete nello stesso modo di un singolo computer, ma con caratteristiche di alta disponibilità. È importante notare che, poiché i cluster di failover si basano su dischi condivisi, esiste un unico punto di guasto del disco, quindi è necessario implementare protezioni aggiuntive come la replica SAN a livello disco. Il cluster di failover più comune è un cluster di failover a due nodi, che include master e slave.

Trasmissione del log delle transazioni

    La spedizione dei log delle transazioni offre protezione ad alta disponibilità a livello di database. La registrazione viene utilizzata per mantenere uno o più database di riserva (chiamati "database secondari") del corrispondente database di produzione (chiamato "database primario"). Prima che avvenga un failover, il database secondario deve essere completamente aggiornato applicando manualmente tutti i backup dei log non restaurati. La consegna dei log ha la flessibilità di supportare più database di riserva. Se sono necessari più database alternativi, la consegna dei log può essere utilizzata separatamente o come complemento al mirroring del database. Quando queste soluzioni vengono utilizzate insieme, il database principale della configurazione di mirroring attuale è anche il database principale della configurazione attuale di spedizione dei log.

    La consegna dei log delle transazioni può essere utilizzata per fare backup a freddo e a caldo.

Mirroring del database

    Il mirroring del database è in realtà una soluzione software che offre anche protezione a livello di database, garantendo un failover quasi istantaneo per migliorare la disponibilità del database. Uno specchio del database può essere utilizzato per mantenere un unico database di riserva (o "database speculare") per il corrispondente database di produzione (chiamato "database principale").
Poiché il database specchio è sempre in stato di ripristino, ma il database non viene ripristinato, il database specchio non può essere accessibile direttamente. Tuttavia, per carichi di sola lettura come i report, puoi usare indirettamente il database speculare creando uno snapshot del database speculare. Gli snapshot del database forniscono ai clienti accesso in sola lettura ai dati presenti nel database al momento della creazione dello snapshot. Ogni configurazione di mirroring del database coinvolge un "server principale" che contiene il database principale, e coinvolge anche un server speculare che contiene il database speculare. Il server specchio aggiorna continuamente il database specchio con il database principale.
    Il mirroring del database funziona in modalità sincrona in modalità ad alta sicurezza o in modalità asincrona in modalità ad alte prestazioni. In modalità ad alte prestazioni, le transazioni non devono aspettare che il server speculare scriva i log su disco prima di poter essere inviati, il che massimizza le prestazioni. In modalità ad alta sicurezza, le transazioni impegnate vengono commesse da entrambi i partner, ma il tempo di ritardo della transazione viene esteso. La configurazione più semplice di mirroring del database coinvolge solo il server principale e il server mirror. In questa configurazione, se il server principale viene perso, il server mirror può essere usato come server di riserva, ma può causare perdita di dati. La modalità ad alta sicurezza supporta la configurazione in standby con la modalità di alta sicurezza con failover automatico. Questa configurazione prevede un'istanza di server di terze parti chiamata "server testimone" che consente al server specchio di essere utilizzato come server di backup caldo. Il failover dal database primario al database speculare richiede tipicamente alcuni secondi.

    Il mirroring del database può essere utilizzato sia per backup a caldo che a caldo.

copiare

    La replicazione non è strettamente una caratteristica progettata per l'alta disponibilità, ma può essere applicata ad alta disponibilità. La replica fornisce protezione a livello di oggetto del database. La replica utilizza un modello di pubblicazione-abbonamento, in cui i dati vengono pubblicati dal server primario, noto come publisher, a uno o più abbonati secondari o abbonati. La replica offre disponibilità e scalabilità in tempo reale tra questi server. Supporta il filtraggio per fornire un sottoinsieme di dati agli abbonati, supportando al contempo aggiornamenti delle partizioni. L'abbonato è online e disponibile per reportistica o altre funzioni senza ripristino delle query. SQL Server offre quattro tipi di replica: replica snapshot, replica transazionale, replica peer-to-peer e replica merge.

AlwaysOnGruppo di usabilità

    AlwaysOn Availability Groups è una nuova funzionalità introdotta in SQL Server 2012. È inoltre fornita una protezione a livello di database. Espande inoltre il limite secondo cui il mirroring del database può essere solo 1:1, così che una replica primaria possa corrispondere a un massimo di 4 repliche secondarie (in SQL Server 2014, questo limite è stato ampliato a 8), di cui 2 repliche secondarie possono essere sincronizzate come backup caldi e repliche primarie in tempo reale, mentre le altre due repliche secondarie asincrone possono essere usate come backup caldi. Inoltre, le repliche secondarie possono essere configurate come solo lettura e possono essere utilizzate per sostenere il carico dei backup.

    Per questo motivo, il mirroring del database è contrassegnato come "obsoleto" in SQL Server 2012.

    Dopo aver compreso i concetti base di alta disponibilità e le tecnologie ad alta disponibilità offerte da SQL Server, diamo uno sguardo al design di una strategia ad alta disponibilità. La pianificazione di una strategia ad alta disponibilità può essere suddivisa in quattro fasi:

Requisiti di raccolta

    Il primo passo per decidere una strategia ad alta disponibilità è senza dubbio raccogliere i requisiti aziendali per stabilire SLA. RTO e RPO sono le parti più critiche e, su questa base, stabilire aspettative realistiche per i requisiti di disponibilità e stabilire una strategia realistica di alta disponibilità basata su queste aspettative.

Limiti di valutazione

    I limiti di valutazione non sono limitati solo alle limitazioni delle diverse tecnologie ad alta disponibilità in SQL Server, ma anche a quelle non tecniche. Se hai un budget di decine di migliaia di yuan, ma vuoi realizzare una soluzione ad alta disponibilità basata su data center off-site e replica SAN, è senza dubbio un sogno perduto. Un'altra limitazione non tecnica è il livello del personale operativo e, spesso, architetture complesse comportano personale operativo più qualificato. Altre limitazioni non tecniche includono la disponibilità di spazio su disco nel data center, se l'alimentazione e il condizionamento possono soddisfare le esigenze e il tempo necessario per implementare la strategia di disponibilità.

    Le limitazioni tecniche includono diverse funzioni e limitazioni ad alta accessibilità, funzioni supportate da diverse versioni di SQL Server, il numero di CPU e la dimensione della memoria. Si raccomanda vivamente di consultare prima le limitazioni delle diverse versioni e funzionalità di SQL Server sul sito MSDN di Microsoft prima di implementare una politica di alta disponibilità.

Tecnologia selezionata

    Dopo aver raccolto i requisiti e valutato i vincoli, il passo successivo è selezionare le tecnologie o la combinazione di tecnologie descritte in precedenza in questo articolo per soddisfare i requisiti SLA. Se la tecnologia selezionata non rispetta lo SLA, è facile segnalare quali limitazioni non rispettano lo SLA, permettendoti di richiedere risorse mancanti o compromessi sullo SLA.

Testare, validare e documentare

    Le policy di alta disponibilità devono essere rigorosamente testate e validate fin dall'inizio per garantire che le politiche di disponibilità attuali rispettino gli SLA. Tuttavia, quando viene lanciata una strategia ad alta disponibilità, è anche necessario testarla e convalidarla regolarmente per garantire che la politica attuale possa ancora rispettare gli SLA nonostante la crescita dei dati, i cambiamenti di business o dei requisiti. Allo stesso tempo, la configurazione della soluzione di disponibilità, il metodo di failover e il piano di disaster recovery dovrebbero essere documentati contemporaneamente, in modo da poter essere rintracciati in caso di guasto o in futura modifica della strategia di alta disponibilità.

Questo articolo spiega i concetti di base di alta disponibilità, il concetto di SLA, i diversi tipi di funzionalità ad alta disponibilità supportate in SQL Server e i passaggi necessari per progettare una strategia di alta accessibilità. Vale la pena notare che, sebbene questo articolo parli solo di alta disponibilità a livello di database, l'alta disponibilità non è solo una questione di DBA, ma include anche la collaborazione di diversi ruoli come personale operativo e di manutenzione di sistema, amministratori di rete, sviluppatori e manager per rispettare meglio gli SLA.