Windows Server 2008 R2: Scenari di risoluzione dei problemi relativi ai cluster di failover

  • Articolo

La configurazione di cluster di failover in Windows Server consente di garantire una disponibilità praticamente continuativa. In questo articolo vengono illustrati diversi potenziali scenari di risoluzione dei problemi.

John Marlin

Il mese scorso, ho guardato alcuni dei più comuni problemi con Windows Server 2008 R2 Failover Clustering e ha esaminato accuratamente risoluzione dei problemi.

Ricordate l'attuale politica di sostegno è che, per una soluzione Windows Server 2008 o Windows Server 2008 R2 Failover Clustering essere considerato una soluzione ufficialmente supportata da Microsoft Customer Support Services (CSS), deve soddisfare i seguenti criteri:

  • Tutti i componenti hardware e software devono soddisfare le qualifiche per ricevere un logo "Certificato per Windows Server 2008 R2".
  • La soluzione completamente configurata deve superare il test di convalida in gestione Cluster di Failover.

Qui ci sono diversi scenari che possono aiutare accelerare o informare i vostri sforzi successivi risoluzione dei problemi. Questi rappresentano alcuni dei problemi più comuni in supportati Windows 2008 R2 cluster di Failover, come pure i passaggi, che potrebbe essere necessario prendere per risolverle.

Scenario 1: Ci stavano facendo il nostro mensile lavaggio di oggetti Active Directory e inavvertitamente cancellato il CNO. Abbiamo cercato di creare uno nuovo, ma non riesce a venire in linea.

L'oggetto nome Cluster (CNO) è molto importante, perché è la comune identità del Cluster.

E viene creato automaticamente dalla procedura guidata crea Cluster e ha lo stesso nome del Cluster. Attraverso questo account, crea altri oggetti Cluster Computer virtuale (VCO) come configurare nuovi servizi e applicazioni sul Cluster. Se si elimina il CNO o prendono le autorizzazioni via, non è possibile creare altri oggetti come richiesto dal Cluster finché non viene ripristinato o le autorizzazioni corrette sono reintegrate.

Come con tutti gli altri oggetti in Active Directory, c'è un objectGUID associato. Questo è come Cluster di Failover sa hai a che fare con l'oggetto corretto. Se basta creare un nuovo oggetto, viene creato anche un nuovo objectGUID. Quello che dobbiamo fare è di ripristinare l'oggetto corretto, in modo che Cluster di Failover può continuare con le sue operazioni normali.

Quando si risolvono questo, abbiamo bisogno di scoprire due cose dalla risorsa Cluster. Windows PowerShell, eseguire il comando:

Get-ClusterResource "Nome del Cluster" | Get-ClusterParameterCreatingDC, objectGUID

Questo recupererà i valori necessari. Il primo parametro che vogliamo è la CreatingDC. Cluster di Failover crea il CNO, notiamo il controller di dominio (DC) su cui è stata creata. Per qualsiasi attività che dobbiamo fare con il Cluster (creare VCO, portano nomi on-line e così via), sappiamo per andare a questa DC per ottenere l'oggetto e la sicurezza. Se non è trovato su quella DC o che la DC non è disponibile, abbiamo ricerca di tutti gli altri che rispondono, ma sappiamo di andare qui prima.

Il secondo parametro è objectGUID per garantire che stiamo parlando l'oggetto corretto. Nel nostro esempio, il nome del Cluster è CLUSTER1, la creazione di DC è DC1 e l'objectGUID è 1a3cf049cf79614ebd94670560da6f04, come segue:

Oggetto nome valore
------     ----      -----
\\DC1.domain.com nome CreatingDC a grappolo
ObjectGUID1a3cf049cf79614ebd94670560da6f04 nome del cluster

Sarebbe necessario accedere alla macchina DC1 ed eseguire Active Directory Users and Computers. Se c'è un oggetto corrente CLUSTER1, possiamo controlliamo per vedere se ha gli attributi corretto. Una nota su questo è il display che si vedrà. Editor di attributi Active Directory, inizialmente non sta per mostrarvi il GUID mostrato qui, come non è visualizzarla in formato esadecimale.

Quello che inizialmente stai andando a vedere è 49f03c1a-79cf-4e61-bd94-670560da6f04. Il formato esadecimale fa un interruttore e funziona a coppie, che è un po' di confusione. Se si prendono i primi otto coppie di numeri e fare l'interruttore, 49f03c1a diventa 1a3cf049. Passando le prossime due coppie, 79cf diventa cf79 e poi 4e61 diventa 614e. Le coppie rimanenti rimangono invariate.

Si deve portare delle proprietà dell'objectGUID nell'editor attributo di vederlo in formato esadecimale che vede Clustering di Failover. Perché non è l'oggetto appropriato, noi dobbiamo prima eliminare l'oggetto per tirarla fuori l'immagine di ripristinare quella corretta.

Ci sono diversi modi di ripristinare l'oggetto. Potremmo usare un Active Directory ripristinare, un'utilità come ADRESTORE o il nuovo Active Directory Cestino (se in esecuzione di un controller di dominio Windows 2008 R2 con uno schema aggiornato). Utilizzando il nuovo Active Directory Recycle Bin rende le cose molto più facile ed è il processo più senza soluzione di continuità per ripristinare gli oggetti Active Directory eliminati.

Con Active Directory Recycle bin, noi possiamo cercare di trovare l'oggetto per ripristinare con il comando di Windows PowerShell:

Get-ADObject –filter 'isdeleted –eq $true –and samAccountName –eq "CLUSTER1$"' –includeDelectedObjects –property * | FormatListsamAccountName,objectGUID

Tale comando sta andando alla ricerca di qualsiasi oggetto eliminato con il nome CLUSTER1 in Active Directory Recycle Bin. Ci darà il nome account e objectGUID. Se ci sono più elementi, mostrerà tutti. Quando vediamo quello che vogliamo, avrebbe visualizzare come questo:

samAccountName : CLUSTER1$
objectGUID:49f03c1a-79cf-4e61-bd94-670560da6f04

Ora abbiamo bisogno di ripristinarlo. Dopo abbiamo eliminato quello corretto, il comando di Windows PowerShell per ripristinarla sarebbe:

49F03c1a-79cf-4e61-bd94-670560da6f04 – Identity Restore-ADObject

Ciò ripristinare l'oggetto nella stessa posizione (unità organizzativa o OU) e manterrà le stesse autorizzazioni e password dell'account computer conosciuti da Active Directory.

Questo è uno dei vantaggi di Active Directory Cestino rispetto a qualcosa come un'utilità come ADRESTORE. Utilizzando ADRESTORE, è necessario reimpostare la password, spostarlo all'unità organizzativa appropriata, riparare l'oggetto in Clustering di Failover e così via.

Con Active Directory Recycle Bin, portiamo semplicemente la risorsa Cluster nome on-line. Questa è anche una scelta migliore rispetto facendo un ripristino di Active Directory, soprattutto se ci sono stati nuovi oggetti utente di computer creati, se ci sono dei vecchi che non esiste e avrebbero dovuto essere eliminato ancora una volta, e così via.

Scenario 2: Mio volumi condivisi del Cluster Visualizza "Reindirizzamento accesso" in gestione Cluster di Failover. Come abbiamo correggere questo?

In primo luogo, rapidamente Ricapitoliamo la definizione di volumi condivisi del Cluster (CSVs). CSVs semplificare la configurazione e la gestione delle macchine virtuali Hyper-V (VMs), in un cluster di Failover. Con CSV in un Cluster di Failover che esegue Hyper-V, più macchine virtuali possono utilizzare lo stesso LUN (disco), eppure il failover (o spostare da nodo a nodo) indipendentemente l'uno da altro. Il CSV fornisce una maggiore flessibilità per i volumi di archiviazione in cluster. Ad esempio, è possibile mantenere i file di sistema separato dai dati per ottimizzare le prestazioni del disco, anche se i file di sistema e i dati sono contenuti in file di disco rigido virtuale (VHD).

Nelle proprietà per tutte le schede di rete che trasportano le comunicazioni cluster, assicurarsi che "Client per reti Microsoft" e "File e Printer Sharing per reti Microsoft" sono attivati per sostenere il Server Message Block (SMB). Ciò è necessario per CSV. Il server è in esecuzione Windows Server 2008 R2, modo fornisce automaticamente la versione di SMB richiesto da CSV, che è SMB2. Ci sarà solo una rete di comunicazione CSV preferita, ma queste impostazioni su più reti di abilitazione aiuta il Cluster hanno resilienza per rispondere ai fallimenti.

Reindirizzamento di mezzi di accesso tutte le operazioni dei / O stanno per essere "Reindirizzamento" sulla rete a un altro nodo che ha accesso all'unità. Ci sono fondamentalmente tre motivi per cui un disco è in modalità di reindirizzamento di accesso:

  1. Hai inserito manualmente e in modalità Redirect
  2. C'è una copia di backup in corso
  3. Ci sono problemi hardware, e il nodo non è possibile accedere direttamente all'unità

In questo scenario, noi abbiamo escluso opzione 1 e 2 di opzione. Questo ci lascia con opzione 3. Se guardiamo nel registro eventi di sistema, vediamo l'evento "ID evento: 5121" da Clustering di Failover.

Ecco la definizione di tale voce di registro: Cluster condiviso VolumeCSV ' disco Cluster x' non è più accessibile direttamente da questo nodo cluster. Accesso I/O per essere ridiretti al dispositivo di storage in rete attraverso il nodo a cui appartiene il volume. Ciò può portare a una riduzione delle prestazioni. Se il reindirizzamento di accesso è attivata per questo volume, per favore spegnerlo. Se reindirizzata accesso è spento, per favore risolvere i problemi di connettività di questo nodo al dispositivo di storage e I/O riprenderà a uno stato integro una volta è ristabilì la connettività al dispositivo di storage.

Prendendo quella posizione, abbiamo anche apparirebbe destra prima di questo evento per qualsiasi evento correlato all'hardware. Così ci apparirebbe per eventi come 9, 11 o 15 che indicano un problema hardware o comunicazione. Guardiamo in Gestione disco per vedere se abbiamo potuto vedere fisicamente il disco. Nella maggior parte dei casi, vedremo alcuni altri errori. Una volta che abbiamo corretto il problema con il back-end, possiamo portare il disco di questa modalità.

Tenere presente che il CSV rimarrà in esecuzione, finché almeno un nodo può comunicare con la rete di archiviazione collegati. Ecco perché sarebbe in modalità "Reindirizzamento". Scrive tutte le unità sono inviati al nodo che può comunicare ed esecuzione continua le macchine virtuali Hyper-V. Ci può essere una performance ha colpita su quelle macchine virtuali, ma continuano a correre. Così saremo mai veramente uscito di produzione, che è una buona cosa.

Scenario 3: Ho appena creato un nuovo Windows 2008 R2 Failover Cluster per l'uso con macchine virtuali a disponibilità elevata. Ho istituito l'unità per CSV, ma quando si tenta di accedervi, sia Explorer e gestione disco appendere. Sono in grado di copiare mio VHD unità per ottenere questo corso.

C'è solo un "vero" proprietario dell'unità e si chiama il nodo del coordinatore. Da questo nodo solo sarebbe fatto qualsiasi tipo di metadati scrive all'unità.

Quando aprite Esplora risorse o gestione disco, sta andando a voler aprire l'unità, in modo che possa fare qualsiasi scrive di metadati (se questo è l'intenzione). A causa di questo, qualsiasi unità che esso non possiede ottenere ridiretti nella rete al nodo coordinatore. Questo è diverso da quello dell'unità in "Reindirizzamento accesso."

Quando si risolvono questo, gestione Cluster di Failover mostrerà l'unità come on-line. Quindi, prima che si dovrebbe guardare per vedere quali eventi vengono registrati. Nel registro eventi di sistema, si potevano vedere questi eventi da Clustering di Failover:

ID Evento: 5120

Volume condiviso del cluster ' disco Cluster x' non è più disponibile su questo nodo a causa della 'STATUS_BAD_NETWORK_PATH(c00000be)'. Tutti i I/O verrà temporaneamente in coda fino a quando è ristabilì un percorso al volume.

ID Evento: 5142

Volume condiviso del cluster ' disco Cluster x' non è più accessibile da questo nodo cluster a causa di errore 'ERROR_TIMEOUT(1460)'. Si prega di risolvere connettività questo nodo al dispositivo di storage e la connettività di rete.

Tali registri eventi scaduta cercando di ottenere attraverso la rete al nodo coordinatore. Ecco che allora osserverebbe per vedere se ci sono altri errori nel registro eventi di sistema che vorrei segnalare di connettività di rete tra i nodi. Se ci sono, è necessario risolverle. Cose come una scheda di rete non funzionante o disabili possono causare questo.

Successivamente, è opportuno controllare la connettività di rete di base tra i nodi. Che cosa è innanzitutto necessario verificare è la rete su cui viaggia il traffico CSV. Il modo Clustering di Failover sceglie la rete da utilizzare per CSV è di valore più alto di metrico. Questo è diverso da come Windows identifica la rete.

L'adattatore di Failover Cluster Network Fault Tolerance (NETFT) ha un proprio sistema metrico utilizzato internamente. Tutte le reti rileva hanno un gateway predefinito e sarà data la metrica di 10000, 10100, come si va. Tutte le reti che non hanno un gateway predefinito partono da 1000, 1100 e così via. Utilizzo di Windows PowerShell, è possibile utilizzare il comando Get-ClusterNetwork | Nome FT, metrica, ruolo per vedere come l'adattatore NETFT li ha definiti. Si dovrebbe vedere qualcosa di simile a:

Nome metrica
-------------------
Gestione 10100
CSV traffico 1000
10000 LAN-WAN
Privata 1100

Con queste quattro reti, la rete ho ho identificato come il CSV è chiamato CSV traffico. L'indirizzo IP che sto usando per esso 1.1.1.1 per Node1 e 1.1.1.2 per Node2, così mi piacerebbe provare la connettività di rete di base con PING tra gli indirizzi IP.

Il passo successivo è quello di tentare una connessione SMB utilizzando gli indirizzi IP. Questo è solo cosa Clustering di Failover è intenzione di fare. Un semplice \\1.1.1.1 NET VIEW sarà sufficiente per vedere se c'è una risposta. Che cosa si dovrebbe tornare indietro è un elenco di azioni o un messaggio: "Ci sono voci nell'elenco."

Questo indica che si potrebbe fare una connessione a tale condivisione. Tuttavia, se viene visualizzato il messaggio "il sistema si è verificato un errore 53. Il percorso di rete non è stato trovato,"questo indica un problema di configurazione di TCP/IP con la scheda di rete.

Avendo "Client per reti Microsoft" e "File e Printer Sharing per reti Microsoft" attivato nella scheda di rete sono tenuti ad utilizzare CSV. Se non sono, otterrete questo problema di appendere Explorer. Selezionare questi e siete a posto.

In Cluster di Server Windows 2003 e sotto, togliendo queste opzioni è stata la procedura consigliata. Questo non è più il caso di andare avanti e si può vedere come si può rompere.

Altri fattori

Ci sono alcuni altri fattori che avrete bisogno di prendere in considerazione. Se i nodi del Cluster sono dei fallimenti risorsa Host sottosistema (RHS), si deve innanzitutto pensare sulla natura della RHS e quello che sta facendo. RHS è il componente di Cluster di Failover che fa un sacco di integrità delle risorse, il controllo per garantire che tutto sta funzionando. Per un indirizzo IP, assicurerà è sullo stack di rete e che risponde. Per i dischi, tenta di connettersi all'unità e non un comando DIR.

Se si verifica un incidente RHS, vedrete il sistema Log eventi IDs 1230 e 1146. In caso di 1230, in realtà identificherà la risorsa e la risorsa DLL utilizza. Se si blocca, significa che la risorsa non risponde come dovrebbe e potrebbe essere deadlock. Se questo dovesse bloccarsi su una risorsa disco, vorreste cercare errori relativi al disco o latenze dei dischi. Esecuzione di una Performance Monitor sarebbe un buon punto di partenza. Aggiornare i driver/firmware di carte o back-end può essere qualcosa di considerare come bene.

Hai intenzione di fare qualche utente rilevamenti di modalità. Clustering di failover effettua il monitoraggio sanitario da modalità kernel per un processo in modalità utente per rilevare quando la modalità utente diventa non risponde o appeso. Per recuperare da questa condizione, clustering sarà bug la casella di controllo. In caso affermativo, si vedrebbe una fermata 0x0000009E. Risoluzione dei problemi di questo comporterebbe a rivedere il file dump che crea per cercare si blocca. Anche vorreste avere Performance Monitor in esecuzione e cercare qualcosa che appare come appeso, perdite di memoria e così via.

Clustering di failover è dipendente su Windows Management Instrumentation (WMI). Se avete problemi con WMI, si sta andando ad avere problemi con il Clustering di Failover (creazione e l'aggiunta di nodi, migrazione e così via). Esegui controlli contro WMI, come WBEMTEST.EXE o script WMI anche remota.

Uno script che è possibile provare da Windows PowerShell è (dove il nodo1 è il nome del nodo effettivo):

Get-wmiobjectmscluster_resourcegroup-computer NODE1 - spazio dei nomi "root\mscluster"

Questo renderà una connessione WMI al Cluster e darvi informazioni sui gruppi.

Se non funziona, si dispone di alcuni problemi WMI. I servizi WMI può essere fermati, quindi potrebbe essere necessario riavviare li. Repository WMI può anche essere corrotti (utilizzare Windows PowerShell comando /salvagerepository winmgmt per vedere se è coerenza), e così via.

Qui ci sono alcuni punti di risoluzione dei problemi da ricordare:

  • Convalidare, convalidare, convalidare. Utilizzo della convalida del Cluster per la risoluzione dei problemi. Utilizzarlo per le migliori pratiche. Usarlo quando vengono apportate modifiche al vostro sistema.
  • Tutto è diretto verso Windows PowerShell. Se non sai ancora, iniziare a giocare con esso.
  • Perché siamo fiduciosi su oggetti di Active Directory, proteggersi. Abilitare Active Directory Recycle Bin e proteggere gli oggetti dall'eliminazione accidentale.
  • Quando si risolvono CSVs, non sempre supporre che è un problema hardware.
  • Risoluzione dei problemi, fare un passo indietro e guardare tutto ciò che può essere influenzata. Quindi avviare il restringimento la vostra attenzione.

Clustering di failover è progettato per rilevare, recuperare e segnalare problemi. Il fatto che il Cluster sta dicendo non c'è o è stato che un problema non significa che il Cluster ha provocato. Come alcune persone dicono: "Non sparare al Messaggero."

John Marlin

**John Marlin**è un senior support escalation engineer del gruppo di supporto tecnico commerciale. È stato con Microsoft per più di 19 anni, con gli ultimi 14 anni, concentrandosi sui Cluster di server.

Contenuto correlato