none
Le risorse di cluster su Windows 2008 R2 non vanno online a causa della mancata partenza del servizio FSRM RRS feed

  • Domanda

  • Salve,

    da alcuni giorni rilevo nel mio ambiente di produzione la seguente anomalia.

    Quando spengo 1 dei 2 nodi di un cluster, al suo riavvio il servizio FSRM non parte e negli eventi di sistema compare l'errore "The File Server Resource Manager service terminated with service-specific error %%-2147200234".

    Se si spengono contemporaneamente i 2 nodi, ciò fa sì che quando si avvia il primo nodo (o anche entrambi) le risorse del cluster non vadano correttamente online. In questa situazione, devo avviare il servizio manualmente su almeno 1 nodo e forzare online le risorse su quel nodo. Viceversa, se si riavviano separatamente i 2 nodi (in modo da passare il controllo del cluster sempre da uno all'altro) le risorse vanno comunque online, ma (a causa del servzio che non parte) compaiono errori ed alert critici tra gli eventi di cluster.

    Per andare nello specifico, l'ambiente è un dominio AD Windows Server 2003 - Windows Server 2008 R2. I 2 nodi del cluster sono anche AD Windows server 2008 R2.

    Le risorse in cluster sono sostanzialmente 2 dischi, 1 come quorum (modalità Node and Disk Majority) ed 1 come file-server per dati condivisi.

    Sottolineo che, quando avviene il problema, tra le risorse in cluster il disco va subito online correttamente, ma non vanno online la risorsa File Server quella Server Name.

    Qualcuno riesce ad aiutarmi su questo problema?

    Grazie a tutti in anticipo


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    mercoledì 29 febbraio 2012 10:32

Risposte

  • dato che in questo modo non riesco ancora ad approdare a soluzioni concrete, ho provato anche a considerare un altro tipo di approccio.

    dato che il problema si evidenzia quando si spengono entrambi i nodi (cioè quando c'è un blackout di corrente), ho deciso di approfondire come avviene lo spegnimento.

    in effetti lo spegnimento finora avveniva contemporaneamente (il software dell'ups mandava il segnale di spegnimento programmato ad entrambi i nodi nello stesso momento). ciò forse non è l'ideale: quando un nodo si spegne deve passare il controllo del cluster in modo pulito all'altro nodo, oppure deve sapere con certezza che l'altro nodo è giù e quindi non gli può passare il controllo. se non è così, ci troviamo in una situazione strana, non pulita, in cui è difficile capire cosa avviene.

    ebbene, ho sfalsato di 1 minuto lo spegnimento dei 2 nodi sul software dell'ups. in tal modo per adesso PARE che (tenendo comunque il servizio FSRM in avvio automatico, ma ritardato) alla riaccensione dei 2 nodi il servizio parta ed il cluster vada online.

    farò altre prove, ma intanto che ne pensi?


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    venerdì 9 marzo 2012 11:59

Tutte le risposte

  • Salve,

    da alcuni giorni rilevo nel mio ambiente di produzione la seguente anomalia.

    Quando spengo 1 dei 2 nodi di un cluster, al suo riavvio il servizio FSRM non parte e negli eventi di sistema compare l'errore "The File Server Resource Manager service terminated with service-specific error %%-2147200234".

    prova a vedere se questo thread

    http://forums.techarena.in/windows-server-help/661391.htm

    ti da uno spunto.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    mercoledì 29 febbraio 2012 11:22
    Moderatore
  • ciao edoardo e grazie per la tua risposta.

    giusto x fissare le idee, suggerisci di verificare se qualcuna della DLL indicate nel thread si è corrotta?

    questo vale anche se è diverso l'ambiente server (windows server 2003 R2, invece che windows server 2008 R2) ed è diverso l'errore segnalato negli eventi?


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    mercoledì 29 febbraio 2012 11:56
  • si, quello è un tentativo da fare.

    fai sapere, ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    mercoledì 29 febbraio 2012 12:05
    Moderatore
  • fatto.

    su windows 2008 R2 i files sono già presenti (non c'è bisogno di installare il servizio FSRM). quindi basta cercarli in un altro server.

    tutto coincide: dimensioni, date di creazione e di ultima modifica. perciò non credo sia questo il motivo.

    però magari l'idea che qualcosa possa essersi corrotto è giusta, anche perchè abbiamo avuto recentemente uno spegnimento accidentale dovuto ad una lunga mancanze di corrente (il programma di spegnimento dolce dell'UPS non ha funzionato correttamente.............)


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    mercoledì 29 febbraio 2012 12:12
  • prova un sfc /scannow con il disco di sistema inserito

    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    mercoledì 29 febbraio 2012 12:44
    Moderatore
  • scusa, ma non ho capito cosa intendi

    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    mercoledì 29 febbraio 2012 12:46
  • per ripristinare files di sistema corrotti puoi mettere il supporto del tuo sistema operativo nel lettore e lanciare un sfc /scannow da start/esegui.

    il comando ripristinerà eventuali files di sistema corrotti e, se non ce ne fossero, non farà nulla.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    mercoledì 29 febbraio 2012 13:31
    Moderatore
  • ottimo, non conoscevo assolutamente questo comando.

    in output mi viene anche un log di quello che eventualmente è stato ripristinato?


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    mercoledì 29 febbraio 2012 13:46
  • no, non c'è report. qui hai la sintassi

    http://technet.microsoft.com/en-us/library/cc938983.aspx


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    mercoledì 29 febbraio 2012 15:01
    Moderatore
  • ok, fatto anche questo.
    ho letto che prima di sovrascrivere un file corrotto il comando chiede conferma all'utente.
    in questo caso niente richieste di conferma, quindi nessun file aggiornato.
    l'errore si ripete esattamente come prima.
    piuttosto, come spiegheresti che avviene in modo esattamente analogo su entrambi i nodi? solitamente queste cose sono casuali e difficilmente riproducibili...........
    grazie

    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    mercoledì 29 febbraio 2012 16:47
  • hai  configurato la  recovery tab del servizio che non parte ?

    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    lunedì 5 marzo 2012 11:56
    Moderatore
  • sostanzialmente ho verificato la configurazione.

    era: first failure - RESTART THE SERVICE; second failure - RESTART THE SERVICE; subsequent failures - TAKE NO ACTION

    mi sembrava adeguata e l'ho lasciata così.

    ripeto, come spiegheresti che la cosa avviene in modo esattamente analogo su entrambi i nodi?

    dato che il servizio dipende dall'RPC service, sto indagando sulle cause che potrebbero far partire quest'ultimo con ritardo (con conseguente impossibilità a partire del FSRM service). nulla di illuminante finora


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    lunedì 5 marzo 2012 13:49
  • Oltre all'evento (nel registro di sistema) indicato all'inizio del thread, dopo il riavvio del nodo riscontro anche questi 2 (nel registro delle applicazioni):

    System
    - Provider
    [ Name] SRMSVC
    - EventID 8197
    [ Qualifiers] 32772
    Level 2
    Task 0
    Keywords 0x80000000000000
    - TimeCreated
    [ SystemTime] 2012-03-05T13:48:03.000000000Z
    EventRecordID 34314
    Channel Application
    Security
    - EventData
    Operation: Checking the File Server Resource Manager global configuration store. Starting File Server Resource Manager Service. Error-specific details: Error: CGlobalStoreManager::Install(), 0x80045316, The File Server Resource Manager service encountered an unexpected error. Check the application event log for more information

    ---------------------------------------------------------------------------------

    System
    - Provider
    [ Name] SRMSVC
    - EventID 8197
    [ Qualifiers] 32772
    Level 2
    Task 0
    Keywords 0x80000000000000
    - TimeCreated
    [ SystemTime] 2012-03-05T13:48:03.000000000Z
    EventRecordID 34313
    Channel Application
    Security
    - EventData
    Operation: Checking the File Server Resource Manager global configuration store. Starting File Server Resource Manager Service. Error-specific details: Error: ClusterRegCreateKey(), 0x80070046, The remote server has been paused or is in the process of being started.

    ---------------------------------------------------------------------------------------------

    Ti dicono qualcosa, uniti al primo?


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    lunedì 5 marzo 2012 14:04
  • trovo sempre questo

    This problem may occur when the DFSEXT.dll file is corrupted after service pack installation. Please rename the DFSEXT.dll file in the %systemroot%\system32\dllcache and %systemroot%\system32 folders, and then copy the DFSEXT.dll file from a normally working Windows Server 2003 R2 machine or expand this file from Windows Server 2003 R2 CD.

    ref: http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/2bcec027-03d7-432e-8ce3-fbdfda4fc15f/


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    lunedì 5 marzo 2012 15:07
    Moderatore
  • In effetti l'avevo letto anche io.

    Mi pare che riporti alla problematica del primo thread che mi hai suggerito.

    Le dimensioni e le date di modifica del file indicato sono esattamente le stesse dello stesso file installato sulle altre macchine Windows Server 2008 R2.

    Inoltre, mi sembrerebbe un po' strano che possa essersi corrotto su entrambi i nodi contemporaneamente.

    Piuttosto, che ne pensi se configuro l'avvio del servizio FSRM in AUTOMATIC (DELAYED START) e provo a farlo partire ritardato?

    Potrebbe essere che in questo caso il failure, se è causato da un servizio da cui dipende che parte in ritardo, venga evitato........


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    lunedì 5 marzo 2012 15:38
  • se quando avvii manualmente il servizio, questo parte senza errori, anche configurare un avvio ritardato potrebbe essere una buona mossa.

    prova e fai sapere, ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    martedì 6 marzo 2012 09:15
    Moderatore
  • l'ho provato su un solo nodo (il cluster è in produzione, ora non posso metterlo offline per fare i test) e funziona, cioè il servizio alla fine parte.

    bisogna vedere se questo tipo di avvio consente poi alle risorse del cluster di andare correttamente online.

    appena possibile faccio il test completo, spegnendo entrambi i nodi.

    nessuna idea su come risolvere la cosa in modo "pulito"?


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    martedì 6 marzo 2012 16:32
  • nessuna idea su come risolvere la cosa in modo "pulito"?

    per il modo "pulito" la strada è quella di individuare cosa non faccia partire correttamente il servizio e ci abbiamo provato verificando l'eseguibile del servizio stesso.

    una strada alternativa sarebbe quella di indagare se c'è qualcosa che va in conflitto col servizio stesso.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    mercoledì 7 marzo 2012 09:24
    Moderatore
  • il fatto che il servizio, se avviato manualmente a posteriori, parta correttamente significa che non ci sono blocchi sostanziali, ma solo temporanei.

    il fatto che la partenza automatica ritardata sembra funzionare lo conferma.

    quindi la mia opinione è che qualcosa da cui il servizio dipende impieghi più tempo del solito (e del normale) a partire. l'idea più immediata è forse quella di indagare sul servizio da cui dipende direttamente, e cioè l'RPC, che a sua volta dipende dai servizi DCOM Service Process Launcher e RPC Endpoint Mapper.

    fin qui la mia analisi, avrei bisogno di suggerimenti illuminanti su come approfondire l'indagine.

    grazie


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    mercoledì 7 marzo 2012 10:06
  • quindi la mia opinione è che qualcosa da cui il servizio dipende impieghi più tempo del solito (e del normale) a partire. l'idea più immediata è forse quella di indagare sul servizio da cui dipende direttamente, e cioè l'RPC, che a sua volta dipende dai servizi DCOM Service Process Launcher e RPC Endpoint Mapper.

    anche questa è una buona idea o ancora usare qualche tool di sysinternals cone process explorer per indagare cosa faccia piantare il servizio all'avvio.
    in bocca al lupo.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    venerdì 9 marzo 2012 08:00
    Moderatore
  • dato che in questo modo non riesco ancora ad approdare a soluzioni concrete, ho provato anche a considerare un altro tipo di approccio.

    dato che il problema si evidenzia quando si spengono entrambi i nodi (cioè quando c'è un blackout di corrente), ho deciso di approfondire come avviene lo spegnimento.

    in effetti lo spegnimento finora avveniva contemporaneamente (il software dell'ups mandava il segnale di spegnimento programmato ad entrambi i nodi nello stesso momento). ciò forse non è l'ideale: quando un nodo si spegne deve passare il controllo del cluster in modo pulito all'altro nodo, oppure deve sapere con certezza che l'altro nodo è giù e quindi non gli può passare il controllo. se non è così, ci troviamo in una situazione strana, non pulita, in cui è difficile capire cosa avviene.

    ebbene, ho sfalsato di 1 minuto lo spegnimento dei 2 nodi sul software dell'ups. in tal modo per adesso PARE che (tenendo comunque il servizio FSRM in avvio automatico, ma ritardato) alla riaccensione dei 2 nodi il servizio parta ed il cluster vada online.

    farò altre prove, ma intanto che ne pensi?


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    venerdì 9 marzo 2012 11:59
  • mi viene da pensare che hai trovato la soluzione ma per ora incrocio le dita per te fino al prossimo blackout.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    venerdì 9 marzo 2012 13:11
    Moderatore
  • mi scuso per il ritardo, avevo dimenticato che il thread era ancora aperto.

    tutto ok, non ho avuto altri problemi.

    risolto, grazie di tutto.


    Riccardo Buonomo System Engineer/Administrator TPR Service S.r.l. via Cornato, 136 - 81024 Maddaloni (CE) ITALY e-mail: riccardo.buonomo@tprservice.it web: www.tprservice.it

    martedì 21 agosto 2012 13:43
  • grazie a te del feedback, ciao.

    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org

    martedì 21 agosto 2012 13:54
    Moderatore