martedì 26 gennaio 2016

Nodo cluster di failover Ordine di avvio in Windows Server 2012 R2

In questo blog, il mio collega, JP, e vorrei parlare di come avviare un cluster, senza la necessità di switch ForceQuorum (FQ). Abbiamo identificato 3 diversi scenari e come il cluster si comporta quando si accendono i nodi in un certo ordine per Windows Server 2012 R2. Prima di tutto voglio citare due articoli che si dovrebbe essere a conoscenza.

Come correttamente arresto un cluster di failover o di un nodo
http://blogs.msdn.com/b/clustering/archive/2013/08/23/10443912.aspx

Raccomandazione di Microsoft è quello di configurare il cluster con un testimone
https://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_Witness

Ora, agli scenari.

Scenario 1: Cluster senza un testimone (nodo di maggioranza)
Scenario 2: cluster con un disco witness
Scenario 3: cluster con un witness di condivisione file

Nello scenario di seguito, si è cercato di avviare il cluster con e senza il testimone.

Scenario 1: Cluster senza un testimone (maggioranza dei nodi)
======================================= ==============

Usiamo il nome del cluster come 'CLUSTER' e il nome dei nodi come 'A' 'B' e 'C'. Abbiamo impostato il tipo di testimonianza di maggioranza dei nodi. Tutti i
nodi hanno un voto ponderato (nel senso di un assegnati e un voto di corrente). Il nucleo Gruppo cluster e le altre risorse (due volumi condivisi del cluster) sono sul nodo A. Inoltre, non abbiamo definito alcun proprietari preferiti di qualsiasi gruppo. Nell'interesse semplicistico, l'ID di nodo di ciascuno è come segue. È possibile ottenere NodeID con il Powershell commandlet Get-NodoCluster.

Stato Nome ID
==== ===== ==
A 1 Fino
B 1 Fino
C 1 Fino

Quando abbiamo grazia spegniamo il nodo A, tutte le risorse sul nodo failover su nodo B, che è il successivo più alto Node ID. Quando diciamo un arresto regolare, il che significa che stiamo spegnimento della macchina facendo clic sul menu Start o spegnere dopo aver applicato le patch. Tutte le risorse sono sul nodo B. Così i voti attuali sarebbero:

Nodo A = 0
nodo B = 1
nodo C = 1

Ora, andiamo con grazia chiudere Node B. Tutte le risorse ora failover al nodo C. Come per il modo in cui funziona quorum dinamici con Windows Server 2012 R2, il cluster sostiene su un nodo come "l'ultimo uomo in piedi". Così i nostri voti sono:

Nodo A = 0
nodo B = 0
Nodo C = 1

Ora vogliamo chiudere con grazia Nodo C pure. Dal momento che tutti i nodi sono giù, il cluster è giù.

Quando iniziamo il nodo A, che è stato chiuso prima, il cluster non si forma e si vede il seguito nel registro cluster:

INFO [NODE] Nodo 3: New unirsi n1: fase: 'Tentativo di connessione iniziale' stato (10060) ragione: 'Impossibile connettersi al endpoint remoto 192.168.1.101:~3343~'
DBG [HM] Tentativo di connessione di C non riuscita con errore (10060): Impossibile connettersi al punto remoto 192.168.1.101:~3343~.
INFO [NODE] Nodo 3: New unirsi n2: fase: 'Tentativo di connessione iniziale' stato (10060) ragione: 'Impossibile connettersi al telecomando endpoint 192.168.1.100:~3343~
'DBG [HM] Tentativo di connessione a C con l'errore (10060): Impossibile connettersi al punto remoto 192.168.1.100:~3343~.
DBG [VER] versioni di cluster calcolati: più alto [Maggiore 8 Minor 9600 Aggiornamento 3 ClusterVersion 0x00082580], più basso [Maggiore 8 Minor 9600 Aggiornamento 3 ClusterVersion 0x00082580] con escludono elenco di nodi: ()

Quando cominciamo nodo B, che è stato chiuso secondo, il cluster non è formato e di seguito sono le voci che vediamo nel registro cluster:

INFO [NODE] Nodo 1: New unirsi n2: fase: 'Tentativo di connessione iniziale' stato (10060) ragione: 'Impossibile connettersi al endpoint remoto 192.168.1.100:~3343~'
DBG [HM] Tentativo di connessione di C non riuscita con errore (10060): Impossibile connettersi al punto remoto 192.168.1.100:~3343~.
DBG [VER] versioni calcolati a grappolo: più alto [8 Maggiore Minore 9600 Aggiornamento 3 ClusterVersion 0x00082580], più basso [8 Maggiore Minore 9600 Aggiornamento 3 ClusterVersion 0x00082580] con esclusione dei nodi: ()

Entrambi i nodi stanno cercando di connettersi al nodo C, che è chiuso. Dal momento che sono in grado di connettersi al nodo C, non forma il cluster. Anche se abbiamo due nodi in su (A e B) e configurato per maggioranza dei nodi, il cluster non si forma.

COME MAI?? Bene vediamo.

Iniziamo Nodo C e ora il cluster è formato.

Anche in questo caso, PERCHE '?? Perché questo è accaduto quando gli altri no ??

Questo perché l'ultimo nodo (Nodo C), che è stato arrestato in mano il gruppo cluster. Quindi, per rispondere alle vostre domande, il nodo che è stato chiuso lo scorso è il primo nodo per essere acceso. Quando un nodo viene arrestato, il suo voto è cambiato a 0 nel Registro di sistema cluster. Quando un nodo va per avviare il servizio cluster, controllerà il suo voto. Se è 0, sarà solo partecipare a un cluster. Se è 1, in primo luogo cercare di entrare in un cluster e se non può connettersi al cluster di aderire, formerà il cluster.

Ciò è di progettazione.

Chiudere tutti i 3 nodi di nuovo nello stesso ordine.

Nodo Un primo
nodo B secondo
Nodo C scorso

Accendere Nodo C e il cluster è formato con i voti correnti come:

Nodo A = 0
nodo B = 0
Nodo C = 1

Attivare Nodo B. raggiunge e viene dato un voto. Attivare il nodo A. Si unisce e viene dato un voto.

Se si avvia un altro nodo nel cluster diverso dal nodo che è stato ultimo ad essere chiuso, l'interruttore ForceQuorum (FQ) deve essere utilizzato per formare il cluster. Una volta formato, è possibile avviare gli altri nodi in qualsiasi ordine e si sarebbero uniti.

Scenario 2: cluster con un testimone disco
=======================================
Prendiamo il stessi 3 nodi e lo stesso ambiente; ma, aggiungere una testimonianza del disco ad esso.

Osserviamo la differenza e il vantaggio di aggiungere il testimone. Per visualizzare la proprietà di peso testimone dinamico, utilizzare il commandlet PowerShell (Get-Cluster) .WitnessDynamicWeight.

PS C: \> (Get-Cluster) .WitnessDynamicWeight
0

NOTA:
L'impostazione 1 significa che ha un voto. L'impostazione di 0 significa che non dispone di un voto. Ricordate, noi ancora andare dai vecchi modi di mantenere i voti in un numero dispari

Inizialmente, il Gruppo cluster e tutte le risorse nel nodo A con gli altri nodi 2 aggiungendo utili ad esso. Il disco testimone aggiunge anche un voto in modo dinamico quando è necessario.

Nodo A = 1 voto = ID Nodo 1
Nodo B = 1 voto = ID Nodo 2
Nodo C = 1 voto = ID Nodo 3
witness di disco = 0 voto

Abbiamo grazia spegniamo il nodo A. Tutte le risorse e il passaggio Gruppo cluster al nodo B, mentre il nodo A perde il suo voto. Successivamente, abbiamo graziosamente spegniamo nodo B e perde il suo voto. Tutte le risorse e Gruppo cluster si muovono al Nodo C. Questo lascia Nodo C come "Last Man Standing", come nello scenario precedente. Garbo arrestare Nodo C come bene e il Cluster è giù.

Questa volta, invece di alimentare l'ultimo nodo che è stato chiuso, cioè il nodo C, potere sul nodo B che è stato chiuso nell'ordine, secondo nella lista.

Il cluster è UP !!!!!

Questo è dovuto al fatto che abbiamo un testimone configurato e Quorum dinamica entra in gioco. Se si seleziona il testimone peso dinamico ora, vedrete che ha un voto.

PS C: \> (Get-Cluster) .WitnessDynamicWeight
1

Perché ha un voto, le forme Cluster.

Scenario 3: Cluster con witness di condivisione file
========================================= ====
Anche in questo caso, prendiamo gli stessi 3 nodi, con lo stesso ambiente e aggiungere un witness di condivisione file ad esso.

Attualmente, il nodo A sta tenendo il Gruppo cluster e le altre risorse. Con gli altri 2 nodi e un witness di condivisione file aggiungendo la possibilità di aggiungere dinamicamente un voto ad esso se ne ha bisogno.

I voti sono segue

Nodo A = 1 voto = ID Nodo 1
Nodo B = 1 voto = ID Nodo 2
Nodo C = 1 voto = ID Nodo 3
witness di condivisione file = 0 voto

Abbiamo grazia spegniamo il nodo A. Le risorse si spostano oltre al nodo B e il nodo A perde un voto. Poiché il nodo A ha perso il voto, il witness di condivisione file regolata dinamicamente e si diede un voto per tenerlo a un numero dispari. Successivamente, abbiamo gradefully spegniamo Node B. Le risorse si spostano verso Nodo C e Nodo B perde anche il suo voto.

Il nodo C è ora il "Last Man Standing", che sta tenendo il Gruppo cluster e tutte le altre risorse. Quando abbiamo chiuso Nodo C, il cluster si spegne.

Diamo uno sguardo indietro al 2 ° scenario in cui abbiamo potuto girare su qualsiasi nodo e cluster sarebbe formare. Tutte le risorse sono in linea e abbiamo avuto una testimonianza del disco in posizione. Nel caso di un witness di condivisione file, questo non accade.

Se ci rivolgiamo nel nodo A, che è stato chiuso prima, il cluster non formerebbe anche se abbiamo un witness di condivisione file. Abbiamo bisogno di tornare a girare sul nodo che è stato arrestato lo scorso, vale a dire Nodo C (il "Last Man Standing"), per formare automaticamente il cluster.

Allora, qual è la differenza? Abbiamo un testimone configurato .... Questo perché il witness di condivisione file non sia in possesso di una copia del database del cluster.

Allora, perché stai facendo in questo modo?

Per rispondere a questo, dobbiamo andare indietro nel tempo per il modo in cui il cluster viene avviato e che cosa database cluster utilizza quando un modulo avviene.

In Windows 2003 e di seguito, abbiamo avuto l'unità quorum. L'unità quorum aveva sempre l'ultima copia del database. Il database contiene tutte le configurazioni, risorse, ecc per il cluster. Esso ha anche preso cura di replicare eventuali modifiche a tutti i nodi in modo avrebbero la informazioni aggiornate. Così, quando il cluster formata, sarebbe scaricare la copia sul disco quorum e quindi avviare. Questo in realtà non era il modo migliore di fare le cose in quanto vi è in realtà solo una copia e se va giù, tutto va verso il basso.

In Windows 2008, questo è cambiato. Ora, uno dei nodi o la testimonianza del disco avrebbe l'ultima copia. Tracciamo questo con un tag "Paxos". Quando viene apportata una modifica su un nodo (aggiungere risorse, eliminare risorsa, nodo join, ecc), che i nodi tag Paxos viene aggiornata. Sarà quindi inviare un messaggio a tutti gli altri nodi ( e disco witness, se disponibile) per aggiornare il suo database. In questo modo, tutto è in corso.

Quando si avvia un nodo nel cluster per formare il cluster, che sta per confrontare è Paxos con quello sul disco witness. Se successiva è la direzione in cui viene utilizzato il database cluster. Se il Paxos è successiva sulla testimonianza del disco, poi si scarica al nodo l'ultima copia e lo usa. Se il nodo locale è successiva, si arrivi al testimone disco e funziona con esso.

Noi facciamo le cose in questo modo in modo che non si perde alcuna configurazione. Ad esempio, si ha un 7 nodi Hyper-V cluster con 600 macchine virtuali in esecuzione. Nodo 6 è spento, per qualsiasi motivo, ed è per un po '. Nel frattempo, si aggiungono altri 200 macchine virtuali. Tutti i nodi e un testimone del disco sa su questo. Dicono che il rack o data center cluster è in perde potere. L'alimentazione viene ripristinata e Node6 viene acceso prima. Se c'è un testimone disco, sta per avere una copia del database cluster con tutte le 800 macchine virtuali e questo nodo che è stato giù per così tanto tempo li avrà. Se tu avessi un testimone di condivisione file (o nessun testimone) che non contiene il database cluster, si perderebbe il 200 e devono riconfigurare loro.

L'interruttore ForceQuorum (FQ) avrà la precedenza e questo inizia con qualunque database del cluster (e configurazioni) che sono sul nodo, indipendentemente da numeri Paxos tag. Quando si utilizza questo, fa di database cluster di quel nodo la copia "d'oro" e replica a tutti gli altri nodi (e disco witness), come si presentano. Quindi, essere cauti quando si usa questo interruttore. Nell'esempio precedente, si avvia Nodo 6, hai perso le macchine virtuali 200 e avrete bisogno di ricrearli nel cluster.

Come nota a margine, Windows Server 2016 cluster di failover segue questo stesso disegno. Se non avete avuto la possibilità di provarlo per vedere tutte le nuove caratteristiche, vieni a bordo e provare.

https://www.microsoft.com/en-us/server-cloud/products/windows-server-2016/default.aspx

Saluti,
Santosh Bathija e S Jayaprakash

martedì 5 gennaio 2016

Che cosa si dovrebbe considerare l'aggiornamento a SQL Server 2014

Supporto per SQL Server 2005 si conclude 12 aprile 2016. Le organizzazioni devono ora cominciare a pianificare per aggiornare i loro database in SQL Server 2014. Mentre è SQL Server 2005 che sta andando in pensione, la realtà è che ci sono ancora database SQL Server 2000 che sono ancora operativo anche se non sono state supportate da Microsoft dal 2013. In realtà, Attualmente sto lavorando su una migrazione un'istanza di SQL Server 2000 a SQL Server 2014 per un cliente. Che molte organizzazioni non capiscono è i costi operativi nella gestione di software di database datato. Peggio ancora è la percezione che il denaro è salvato da non investire nella migrazione a SQL 2014 o superiore.

Immaginate di guidare un modello di veicolo in ritardo come un conducente quotidiano. Con tutta l'usura con l'uso, l'imaging i costi maturati sulla manutenzione e la riparazione. Aggiungere la disponibilità (o indisponibilità) di pezzi per una vecchia auto. Prendere in considerazione il tempo necessario per prendere l'auto al meccanico, in attesa per il vostro veicolo da fissare, il fastidio di avere una macchina a noleggio se si ha realmente bisogno di guidare e tornare dal lavoro. Che dire di modifiche o integrazioni alle leggi nel corso degli anni? Auto più recenti non sono richieste prove di emissioni regolari rispetto ai loro colleghi più anziani. Detto questo, la maggior parte di noi sono dipendenti sulle nostre vetture in quanto contribuisce a come fare una vita. Lo stesso si può dire per la missione organizzazioni database critici si affidano a tutti i giorni.

Il tentativo di sostenere una piattaforma di database non supportato

Cinque anni fa, un ticket di supporto è stato emesso per conto di un cliente ancora in esecuzione su SQL Server versione 6.5. A quel tempo, SQL 6.5 è stato il suo quattordicesimo anno e supporto di Microsoft era scadenza modo passato. L'organizzazione è stata letteralmente in proprio dovrebbe qualcosa fosse accaduto. Il database originariamente riceve un Advanced Server di Windows 2000 su un hardware molto vecchio di cui un giorno non è riuscita. Quando il cliente non riusciva a trovare i driver hardware e firmware per il nuovo server per eseguire Windows 2000 Advanced Server, hanno deciso di spostare dal server fisico ad una macchina virtuale.

La migrazione da fisico a virtuale è stato doloroso. Il sistema operativo del server è stato aggiornato a Windows Server 2003, ma continuava a SQL Server alla versione 6.5 intatto. Il loro più efficienti era salito a circa 300 GB a quel punto. Allora un database di 300 GB-size era relativamente grande  per SQL Server 6.5 per supportare quanto non è stato progettato per gestire i dati che molto. A quel tempo la quantità massima di memoria di un server potrebbe avere era di circa 8 GB che era la quantità massima di memoria di Windows 2000 Advanced Server supporta.

Dopo la migrazione, i database continuamente si sono corrotti. Ticket di supporto per affrontare la corruzione del database sono stati emessi settimanale. La sfida ancora più grande è stato il nostro team di esperti altamente qualificati di SQL Server non funzionava più con SQL Server 6.5 e quindi tempo è stato speso re-imparare il prodotto solo per sostenerlo. Ho anche dovuto installare SQL Server 6.5 sul mio laboratorio di prova solo per farmi ri-orientato con gli strumenti di gestione. Gestione e supporto che database anche colpito il morale del team perché stavamo ottenendo frustrato con tutti i problemi che dobbiamo risolvere, invece di concentrarsi su cose più importanti che potrebbero trarre beneficio gli obiettivi di business.

Ecco un bellissimo video di una recente conferenza Ignite in Nuova Zelanda che racconta di una storia simile:



Trascorrere una grande quantità di denaro e risorse per sostenere una tecnologia obsoleta risorsa non è probabilmente una buona idea se si considera ciò che è veramente importante per l'azienda. Qui ci sono un certo punto di prendere in considerazione per aiutarvi a fare questa scelta per l'aggiornamento al software di database supportato:

Supporto del fornitore - Aziende come Microsoft definiscono supporto in due offerte. Vale a dire, il supporto mainstream e supporto esteso. Supporto Mainstream consente alle organizzazioni di ricevere miglioramenti per un prodotto specifico attraverso service pack e aggiornamenti cumulativi. Sotto supporto esteso, saranno forniti senza ulteriori miglioramenti e di tutti i casi di supporto relative cadranno sotto le pagate opzioni. Dopo aver esaurito la disponibilità di supporto esteso, sono tecnicamente da soli e il fornitore non può anche aiutare con qualsiasi richiesta di assistenza che si aprirà con loro. Naturalmente, solo perché il fornitore supporta la piattaforma in particolare non garantisce che il vostro team interno può.

La disponibilità di risorse qualificate -  Vuoi ancora mantenere una piattaforma di database mission-critical se nessuno sapeva come sostenerlo? Certo, si può eventualmente esternalizzare che a un fornitore di servizi gestiti, ma si può garantire che essi hanno le competenze tecniche per mantenere le luci accese? Una versione di un prodotto sarà molto più comune nel campo che ci saranno più qualificati talento e le risorse disponibili per mantenerla.

- Requisiti  HIPAA e conformità PCI entrambi richiedono le piattaforme di database e sistemi operativi di essere aggiornato con le ultime patch di sicurezza. Significa anche che è necessario rispettare le leggi ei regolamenti in vigore nel paese o nella regione in cui opera l'azienda e / o dei dati si svolge. La vostra piattaforma tecnologica esistente soddisfi tali requisiti di conformità o avete bisogno di effettuare l'aggiornamento a una versione più recente di essere in regola?
Questa è la realtà che i clienti devono affrontare quando si tratta di una versione precedente del prodotto.