Freigeben über

Windows Server 2008 R2 - Il cluster log

  • Artikel

La disponibilità di informazioni su cui effettuare una analisi è di vitale importanza per il lavoro del Support Engineer. Nel caso di problemi che riguardano il servizio di Failover Clustering, oltre a dati relativi al sistema operativo, i cluster log sono le fonti di informazione di maggiore interesse.

Nel cluster log sono contenuti log su eventi di normale funzionamento del servizio cluster oltre che eventi di warning ed errore.

Anche se parte dei contenuti del cluster log possa apparire similare a quello presente in cluster basati su Windows Server 2003, in Windows Server 2008 R2 il cluster log è basato su nuovi meccanismi. Per questo motivo è utile una breve descrizione delle nuove peculiarità che, a volte, permettono di affrontare l’analisi in maniera più efficace e veloce.

Dove è il cluster log?

In Windows Server 2003, il cluster log è un file di testo in cui vengono inseriti gli eventi relativi al servizio cluster. Esso ha una dimensione massima e per questo motivo i log meno recenti vengono cancellati.
Il file di testo del cluster log è salvato di default nel path %SystemRoot%\Cluster (ad esempio C:\Windows\Cluster) dei nodi del cluster.

In Windows Server 2008 R2, i log relativi al servizio cluster sono gestiti diversamente. In particolare, il componente che ha in carico il logging è il processo Windows Event Tracing (ETW). Esso è lo stesso componente del sistema operativo che gestisce gli eventi System, Application etc.

Gli eventi del servizio Failover Cluster sono salvati in %WinDir%\System32\winevt\logs\ con estensione ‘.etl’. Ogni volta che il server viene riavviato, un nuovo file ETL è creato ed utilizzato; di default, solo i 3 file più recenti sono mantenuti:

image

Così come accade per il cluster log in Windows server 2003, ogni file ETL ha una dimensione massima (di default 100MB), raggiunta la quale i log più vecchi (all’interno dello stesso file ETL) vengono rimossi. Ogni file ETL, infatti, ha una struttura di buffer circolare che permette di liberare spazio ai nuovi eventi eliminando quelli meno recenti.

La figura seguente illustra graficamente il meccanismo sopra descritto:

image

Generare il cluster log

Per potere avere una versione leggibile del cluster log, dunque, si deve procedere con la generazione manuale dello stesso. Ciò è possibile utilizzando alcuni comandi da riga di comando messi a disposizione da cluster.exe che non fanno altro se non portare a un formato leggibile i singoli file ETL in un unico file di testo.

Di seguito elenco alcuni comandi utili per la gestione del cluster log:

  • cluster.exe log /g
    Questo comando genera istantaneamente il cluster log su ogni nodo del cluster. Il file generato (cluster.log) è salvato in %WinDir%\Cluster\Reports.
    Occorre recuperare i singoli cluster log da ogni nodo.
    image
    image

  • cluster.exe log /g /copy:”<path_di_salvataggio>”
    Esempio:     cluster.exe log /g /copy:”C:\temp_log”
    Questo comando esegue “cluster.exe log /g” su ogni nodo del cluster e poi copia i singoli cluster log generati nel path specificato, rinominando opportunamente i file in modo che sia comprensibile il nodo sorgente.

    image
    image

  • cluster.exe log /span:<number_of_minutes>
    Questo comando genera il cluster log prendendo in considerazione solo gli eventi registrati negli ultimi <number_of_minutes> minuti. Ciò è utile se si vuole evitare di esportare lo storico di giorni precedenti.
    Da notare è il fatto che questo comando non cancella alcun evento, semplicemente applica un filtro temporale sugli eventi.

  • cluster.exe log /node:”<node_name>”
    Questo comando genera il cluster log solo sul nodo specificato. Tale comando è utile in quei casi in cui un nodo è, ad esempio, spento in modo tale da evitare i ritardi di attesa per il nodo non disponibile.

I comandi sopra citati possono essere mescolati per generare cluster log secondo le proprie necessità.

I seguenti due comandi permettono di modificare altrettante impostazioni sul tracing dei log:

  • cluster.exe /size:<log_size_in_MB>
    Questo comando moodifica la dimensione massima di ogni file ETL utilizzato.
    La dimensione deve essere espressa in MB in un range tra 8 e 1024.

  • cluster.exe /level:<log_level>
    Questo comando permette di cambiare il livello di tracing tra i 6 valori ammessi (tra 0 e 5); più alto è il livello, più informazioni sono loggate: ciò comporta un più rapido esaurimento dello spazio disponibile per il singolo file ETL, quindi è opportuno tenere in considerazione questo aspetto.
    Il valore di default è 3 ed è caldamente suggerito di non impostare il log level al di sotto di questo valore dato che informazioni molto utili per l’analisi verrebbero perse.
    La seguente tabella illustra ciò che viene loggato in corrispondenza di ogni log level:

    image

Sia il log level che la size dei file ETL impostati sono ricavabili da riga di comando eseguendo il comando ‘cluster /prop’ :

image

Intervalli di tempo mancanti nel cluster log generato

Il particolare meccanismo per la gestione dei log può far sorgere qualche quesito a chi non ha ben chiaro il suo funzionamento. L’aspetto più comune è la presenza di intervalli di tempo non coperti dal cluster log generato.

Questa possibilità deriva dalla struttura di buffer circolare dei file ETL con l’utilizzo di un diverso file ETL dopo ogni riavvio del server.

I gap temporali presenti in cluster log generati è dovuto al fatto che 2 file ETL su 3 contengono log di due lassi temporali relativi a due reboot precedenti del server; il terzo file ETL (quello in uso) contiene un set di informazioni in evoluzione e, raggiunta la dimensione massima, i log più vecchi dall’ultimo reboot vengono rimossi. In questa circostanza, tra il precedente shutdown e il primo evento loggato nel file ETL in uso potrebbero essere stati rimossi vari log.

Conclusioni

In Windows Server 2008 (e 2008 R2), a differenza delle versioni precedenti del sistema operativo, il cluster log deve essere generato manualmente per potere ottenere un file similare a quello utilizzato in passato.

Dato che il passare del tempo potrebbe provocare la rimozione dei log meno recenti, come sopra discusso, è consigliata la generazione dei cluster log su tutti i nodi del cluster non appena si evince un problema su cui si voglia effettuare una analisi.

In base alla configurazione dei parametri relativi al cluster log, la rimozione dei vecchi dati può iniziare dopo qualche minuto, ora o giorni.

Consiglio di generare il cluster log al più presto dopo un evento di interesse invece di attendere una nuova occorrenza del problema!

Articoli consigliati

 

Alessandro Caniglia
Support Engineer
Microsoft Enterprise Platform Support