Windows Server 2008 R2: Risoluzione dei problemi di cluster di Failover
Quando il fallimento non è un'opzione, configurazione cluster di failover in Windows Server può aiutare a garantire la disponibilità vicino coerente.
John Marlin
Windows Server è cambiato nel corso degli anni, con diverse versioni, a diversi livelli di supporto e tattiche diverse per la risoluzione dei problemi. L'attuale politica di sostegno è che, per Windows Server 2008 o Windows Server 2008 R2 Failover Clustering soluzione da prendere in considerazione soluzioni ufficialmente supportati da Microsoft Customer Support Services (CSS), essi devono soddisfare le 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.
Assicurando il che avete una versione con supporto ufficiale, avete le migliori possibilità di tutto il lavoro. Non ci può essere sempre problemi con i fornitori di hardware, o Microsoft potrebbe essere necessario essere coinvolti per assistere con alcune configurazioni, ma le probabilità sono che si dovrebbe almeno essere buono per iniziare. Ecco uno sguardo ad alcuni dei più comuni problemi con Windows Server 2008 R2 Failover Clustering e come accuratamente risolvere questi problemi.
Il Cluster cambiando
Il modo in cui i cluster sono qualificati è cambiata significativamente in Windows Server 2008 R2 con l'introduzione della Cluster convalida guidata, che è integrato in Clustering di Failover. La procedura guidata di convalida del Cluster consente di eseguire una serie di test focalizzata su un insieme di server che si intende utilizzare come nodi in un Cluster.
Questo processo di convalida test il sottostante hardware e software, direttamente ed individualmente. Ciò fornirà una valutazione accurata di quanto bene una determinata configurazione sosterrà Clustering di Failover. Se lo si utilizza in un Cluster in esecuzione, esso può anche far sapere se stai incontro consigliate. È consigliabile eseguire quando si aggiungono nuovi componenti hardware o driver al Cluster.
Per chi ama lo scripting, Clustering di Failover ha ora Windows PowerShell supporta. Questo è qualcosa con cui si dovrebbe iniziare a diventare più familiare, come CLUSTER.EXE non viene aggiornata. Se non sai cosa sono i cmdlet e cosa significano, è possibile eseguire il comando Get-Help * * Cluster. Questo vi darà un elenco che descrive i comandi, come questo:
Nome sinossi
---- --------
Creare un nuovo cluster di failover di nuovo Cluster. Prima di creare un
cluster, deve...
Se non sai come usare il comando, è possibile utilizzare Get-Help New-Cluster –Examples per vedere esempi, come questo:
NAME
Nuovo Cluster
SINOSSI
Creare un nuovo cluster di failover. Prima di creare un cluster, si
necessario collegare l'hardware (server, reti e archiviazione) ed eseguire
i test di convalida.
-------------------------- EXAMPLE 1 --------------------------
C:\PS> > New-Cluster - Name cluster1-nodo node1, node2, Nodo3, Nodo4
Name
----
cluster1
Descrizione
-----------
Questo comando crea un cluster a quattro nodi denominato cluster1, utilizzando predefinito
impostazioni per l'indirizzamento IP.
Se si ricevono eventi in Windows, è sempre una buona idea per capire davvero cosa queste dire. Alcuni non sono come descrittivi che desideri. Un elenco di tutti gli eventi che si possono vedere, incluse le descrizioni di eventi, è disponibile online.
Registri eventi conducono il modo
Se si verifica un problema, Cluster eventi è uno dei primi luoghi che dovrebbe iniziare la ricerca. Qualsiasi critica, errore o avvisi sprigionati sarà nel registro eventi di sistema. I messaggi informativi (ad esempio un gruppo andando offline, spostandosi un gruppo a un altro nodo e così via) sarà nel canale operativo Cluster. Si possono vedere questi eventi nel Visualizzatore eventi / Registri applicazioni e servizi / Microsoft / Windows / FailoverClustering.
Se non siete sicuri di quale fosse il problema con un particolare gruppo di servizio/applicazione o una risorsa, è possibile visualizzare in gestione Cluster di Failover. Se stai evidenziato su un particolare gruppo, selezionare "Visualizza eventi critici per questa applicazione." Se stai evidenziata su una risorsa specifica, selezionare "Mostra gli eventi critici per questa risorsa".
Questo aprirà il registro eventi di sistema e il filtro per il gruppo specifico o una risorsa. Vi darà tutte le istanze trovate nel registro eventi di sistema per tutti i nodi del cluster. Questo potrebbe essere utile, come vi mostrerà tutto questo da un'unica posizione.
Una volta che hai identificato la risorsa, si può andare per i registri eventi di sistema per vedere se ci sono altri fattori. Non essere distratto dal sintomo — si concentrerà su una causa principale. Ad esempio, se un nome di rete o l'indirizzo IP non riesce, ci sono altri eventi di tipo rete potrebbero contribuire a questo (TCPIP dello stack fallisce, malfunzionamenti di scheda di rete e così via)?
Registrazione di Debug cluster ha cambiato alle sessioni di traccia eventi. Non c'è più CLUSTER.REGISTRO. Il sistema è ora scrive estrarre, trasformare e caricare i file (ETL) si trova nella cartella %WinDir%\System32\winevt\logs. Da questi file ETL, è possibile generare un CLUSTER singolo.Registro per essere visto da tutti e tre. Questa è una "istantanea" nel tempo, tuttavia. In altre parole, quando si genera un impostandole, non è più la scrittura al file impostandole stesso. Ogni volta che si genera uno su un nodo, e sovrascrivere quella attuale e sostituirlo con uno nuovo.
È possibile generare log con il comando di Windows Powershell Get-ClusterLog. Questo sta per uscire a tutti i nodi del Cluster e creare il file per ogni nodo nella cartella %WinDir%\Cluster\Reports. A seconda del numero di nodi e le dimensioni dei file, si può prendere in considerazione alcuni parametri aggiuntivi.
Dire avete un Cluster nove e vuole ottenere tutti i registri. È possibile utilizzare l'opzione –Destination per averli tutti generati e copiarli in una posizione specifica. Questo vi darà un singolo posto per farli. Esso sarà anche tag il nome del nodo come parte del nome file (ad esempio, Get-ClusterLog –Destination c:\logs. creerà Node1_Cluster.log, Node2_cluster.log e così via nella cartella c:\logs.).
Un'altra considerazione, se questo è un problema facilmente riproducibile: utilizzare l'opzione di –Timespan (in minuti). Semplicemente riprodurre il problema su un nodo ed eseguire Get-ClusterLog –Timespan 5 –Node Node1. Questo genererà un impostandole per solo Node1 e catturare solo gli ultimi cinque minuti.
Ecco alcuni suggerimenti per questo livello di risoluzione dei problemi:
- Il registro è complesso e dettagliato. Non dovrebbe essere il primo posto per iniziare la ricerca.
- Assicurarsi che rifletta il valore di almeno tre giorni di dati. In questo modo, se avete un fallimento il venerdì sera, i dati sarà ancora lì quando arrivate il Lunedi. Ogni registro è di 100 MB di dimensione. Se è necessario aumentare la dimensione, utilizzare il comando di Windows Powershell Set-Clusterlog –Size 200 (o di qualunque dimensione in megabyte specificare).
- Alcune applicazioni sono "rumoroso" o "chiacchierone" nei registri. Potrebbe essere necessario aumentare la dimensione del registro, se è così.
- Registro di Debug del Cluster viene generato come GMT, quindi avrete bisogno di convertire i tempi di corrispondenza quando si è verificato l'evento reale ora locale.
- A seconda di ciò che si desidera visualizzare, utilizzare –Destination o –Timespan.
Il mese prossimo, ci prenderemo voi attraverso alcuni scenari comuni di risoluzione dei problemi.
.jpg)
**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 su un server di cluster.