none
Ripresa automatica dei ruoli AlwaysOn SQL

    Domanda

  • Buongiorno

    questa mattina abbiamo avuto un problema con 2 server Windows 2012 R2 in cluster, con opzione AlwaysOn su Sql 2014.
    Il Nodo 1, non aveva i db in sync (era stato fatto un suspend data movement per un problema avuto il giorno prima), quindi ne ho approfittato per fare gli
    aggiornamenti e riavviarlo.
    Il problema è che alla sua riaccensione, in automatico si è ripreso il ruolo di primary nell'AlwaysOn.
    Dopo poco, fortunatamente, accorgendosi che i db non erano in sync con il Nodo 2, li ha messi in recovery ed ha iniziato ad allinearli.

    La mia domanda è, perchè si è ripreso in automatico il ruolo di primary?

    La configurazione è la seguente:
    Server Istance         ROLE Availability Mode Failover Mode Connections in Primary Role Readable Secondary
       
    AL-SQL-CL2 Primary Synchronous continuos Automatic Allow all Connections         Yes
    AL-SQL-CL1 Secondary        Synchronous continuos Automatic Allow all Connections         Yes
     

    mercoledì 20 dicembre 2017 16:46

Tutte le risposte

  • Inoltre questa notte, in autonomia il servizio cluster ha cambiato puntamento dal Nodo 2 al Nodo 1, che è però rimasto in sola lettura, causando di fatto il blocco delle pagine web che accedevano a Sql.

    giovedì 21 dicembre 2017 08:24
  • Buongiorno

    abbiamo capito il problema di base, facevamo puntare gli applicativi al Cluster Name anzichè al Listener di SQL.

    Rimane però il problema della witness, in quanto se spegniamo il server dove risiede la cartella condivisa, il cluster va in errore e in altro servizio che abbiamo configurato non funziona più.

    Grazie

    giovedì 28 dicembre 2017 08:55
  • Buongiorno , hai provato a spostare manualmente il ruolo dal server 1 al server 2 e successivamente spegnere il server 1 ?

    Nella condizione ideale i due server devono scambiarsi i ruoli automaticamente .

    Nel log degli errori hai qualche messaggio significativo ?

    Saluti

    Quirino


    QuirinoS

    martedì 2 gennaio 2018 10:43
  • Buongiorno

    provando a spostarlo manualmente e spegnendo poi il server 1 funziona.

    Di seguito i log:

    Log Name:      System
    Source:        Microsoft-Windows-FailoverClustering
    Date:          02/01/2018 02:37:26
    Event ID:      1146
    Task Category: Resource Control Manager
    Level:         Critical
    Keywords:      
    User:          SYSTEM
    Computer:      SQL-CL1.local
    Description:
    The cluster Resource Hosting Subsystem (RHS) process was terminated and will be restarted. This is typically associated with cluster health detection and recovery of a resource. Refer to the System event log to determine which resource and resource DLL is causing the issue.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{BAF908EA-3421-4CA9-9B84-6689B8C6F85F}" />
        <EventID>1146</EventID>
        <Version>0</Version>
        <Level>1</Level>
        <Task>3</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-01-02T01:37:26.019276000Z" />
        <EventRecordID>115704</EventRecordID>
        <Correlation />
        <Execution ProcessID="2708" ThreadID="5548" />
        <Channel>System</Channel>
        <Computer>AL-SQL-CL1.astalegaleovh.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="NodeName">SQL-CL1</Data>
      </EventData>
    </Event>

    Log Name:      System
    Source:        Microsoft-Windows-FailoverClustering
    Date:          02/01/2018 02:37:25
    Event ID:      1177
    Task Category: Quorum Manager
    Level:         Critical
    Keywords:      
    User:          SYSTEM
    Computer:      SQL-CL1.local
    Description:
    The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. 
    Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{BAF908EA-3421-4CA9-9B84-6689B8C6F85F}" />
        <EventID>1177</EventID>
        <Version>0</Version>
        <Level>1</Level>
        <Task>42</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-01-02T01:37:25.996188300Z" />
        <EventRecordID>115702</EventRecordID>
        <Correlation />
        <Execution ProcessID="2708" ThreadID="6256" />
        <Channel>System</Channel>
        <Computer>AL-SQL-CL1.astalegaleovh.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="NodeName">SQL-CL1</Data>
      </EventData>
    </Event>

    Log Name:      System
    Source:        Microsoft-Windows-FailoverClustering
    Date:          02/01/2018 02:36:56
    Event ID:      1069
    Task Category: Resource Control Manager
    Level:         Error
    Keywords:      
    User:          SYSTEM
    Computer:      SQL-CL1.local
    Description:
    Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed.

    Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it.  Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{BAF908EA-3421-4CA9-9B84-6689B8C6F85F}" />
        <EventID>1069</EventID>
        <Version>1</Version>
        <Level>2</Level>
        <Task>3</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-01-02T01:36:56.685734000Z" />
        <EventRecordID>115700</EventRecordID>
        <Correlation />
        <Execution ProcessID="2708" ThreadID="6256" />
        <Channel>System</Channel>
        <Computer>SQL-CL1.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="ResourceName">File Share Witness</Data>
        <Data Name="ResourceGroup">Cluster Group</Data>
        <Data Name="ResTypeDll">File Share Witness</Data>
      </EventData>
    </Event>

    Log Name:      System
    Source:        Microsoft-Windows-FailoverClustering
    Date:          02/01/2018 02:36:56
    Event ID:      1564
    Task Category: File Share Witness Resource
    Level:         Critical
    Keywords:      
    User:          SYSTEM
    Computer:      SQL-CL1.astalegaleovh.local
    Description:
    File share witness resource 'File Share Witness' failed to arbitrate for the file share '\\dc-02\Witness'. Please ensure that file share '\\dc-02\Witness' exists and is accessible by the cluster.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{BAF908EA-3421-4CA9-9B84-6689B8C6F85F}" />
        <EventID>1564</EventID>
        <Version>0</Version>
        <Level>1</Level>
        <Task>34</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-01-02T01:36:56.676687300Z" />
        <EventRecordID>115699</EventRecordID>
        <Correlation />
        <Execution ProcessID="4440" ThreadID="632" />
        <Channel>System</Channel>
        <Computer>SQL-CL1.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="ResourceName">File Share Witness</Data>
        <Data Name="ShareName">\\al-dc-02\Witness</Data>
        <Data Name="BinaryParameterLength">4</Data>
        <Data Name="BinaryData">21000000</Data>
      </EventData>
    </Event>

    Log Name:      System
    Source:        Microsoft-Windows-FailoverClustering
    Date:          02/01/2018 02:35:55
    Event ID:      1135
    Task Category: Node Mgr
    Level:         Critical
    Keywords:      
    User:          SYSTEM
    Computer:      SQL-CL1.local
    Description:
    Cluster node 'SQL-CL2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{BAF908EA-3421-4CA9-9B84-6689B8C6F85F}" />
        <EventID>1135</EventID>
        <Version>0</Version>
        <Level>1</Level>
        <Task>5</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-01-02T01:35:55.928223900Z" />
        <EventRecordID>115693</EventRecordID>
        <Correlation />
        <Execution ProcessID="2708" ThreadID="3316" />
        <Channel>System</Channel>
        <Computer>SQL-CL1.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="NodeName">SQL-CL2</Data>
      </EventData>
    </Event>

    Log Name:      System
    Source:        Microsoft-Windows-FailoverClustering
    Date:          02/01/2018 02:35:55
    Event ID:      1135
    Task Category: Node Mgr
    Level:         Critical
    Keywords:      
    User:          SYSTEM
    Computer:      SQL-CL2.local
    Description:
    Cluster node 'SQL-CL1' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{BAF908EA-3421-4CA9-9B84-6689B8C6F85F}" />
        <EventID>1135</EventID>
        <Version>0</Version>
        <Level>1</Level>
        <Task>5</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-01-02T01:35:55.133256500Z" />
        <EventRecordID>113982</EventRecordID>
        <Correlation />
        <Execution ProcessID="2596" ThreadID="3324" />
        <Channel>System</Channel>
        <Computer>SQL-CL2.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="NodeName">SQL-CL1</Data>
      </EventData>
    </Event>

    mercoledì 3 gennaio 2018 14:43
  • il problema potrebbe essere questo "The Cluster service is shutting down because quorum was lost"

    Come è configurato il quorum ?

    hai un disco che fa da quorum o stai usando la share ?


    QuirinoS

    venerdì 5 gennaio 2018 09:31
  • Buongiorno

    abbiamo capito il problema di base, facevamo puntare gli applicativi al Cluster Name anzichè al Listener di SQL.

    Rimane però il problema della witness, in quanto se spegniamo il server dove risiede la cartella condivisa, il cluster va in errore e in altro servizio che abbiamo configurato non funziona più.

    Grazie

    Sono d'accordo con Quirino Scaramastra, probabilmente il problema sta proprio nella modalità di quorum che stai utilizzando (Maggioranza dei nodi e delle condivisioni file?).
    Ti consiglio la lettura di questa pagina:
    https://docs.microsoft.com/it-it/sql/sql-server/failover-clusters/windows/wsfc-quorum-modes-and-voting-configuration-sql-server

    venerdì 5 gennaio 2018 18:19
    Moderatore
  • Il quorum è un file share witness.

    la sua configurazione:

    mercoledì 10 gennaio 2018 15:01
  • Facciamo così...esegui questo comando PowerShell da uno dei nodi:
    Get-ClusterQuorum
    e riporta qui l'output che ti viene restituito.


    mercoledì 10 gennaio 2018 16:36
    Moderatore
  • Cluster             QuorumResource
    -------              --------------
    SQL-CL             File Share Witness
    giovedì 11 gennaio 2018 08:34
  • Dovresti avere anche una colonna "QuorumType" vicino a "QuorumResource", manca una parte nel tuo messaggio oppure non c'è proprio?
    giovedì 11 gennaio 2018 09:46
    Moderatore
  • cosi dovrebbe essere corretto.

    Puoi rivedere per cortesia la configurazione del gruppo Always-on


    QuirinoS

    giovedì 11 gennaio 2018 10:50
  • Tranne l'impostazione dei Backup, che devo per forza lasciare su Primary (CommVault vuole fare i backup solo sul nodo primario), tutto il resto è uguale.
    giovedì 11 gennaio 2018 11:18
  • Dovresti avere anche una colonna "QuorumType" vicino a "QuorumResource", manca una parte nel tuo messaggio oppure non c'è proprio?
    No non c'è proprio
    giovedì 11 gennaio 2018 11:18
  • ok controlliamo un impostazione nel file over cluster 

    dovresti andare sulla risorsa AG e fare le proprietà, poi sul tab fileover

    come è configurato ?


    QuirinoS

    giovedì 11 gennaio 2018 13:45
  • eccoti lo screenshot:

    giovedì 11 gennaio 2018 14:02
  • ok vediamo ora la share 


    QuirinoS

    giovedì 11 gennaio 2018 14:16
  • nel dettaglio


    QuirinoS

    giovedì 11 gennaio 2018 14:18
  • eccoti:

    giovedì 11 gennaio 2018 14:38
  • No non c'è proprio

    Allora prova ad utilizzare direttamente (Get-ClusterQuorum).QuorumType
    venerdì 12 gennaio 2018 15:19
    Moderatore
  • No non c'è proprio

    Allora prova ad utilizzare direttamente (Get-ClusterQuorum).QuorumType
    NodeAndFileShareMajority
    venerdì 12 gennaio 2018 15:41
  • NodeAndFileShareMajority

    OK, era proprio come pensavo, il quorum è configurato come "Maggioranza dei nodi e delle condivisioni file".
    Ti riporto una parte del link che ti avevo inserito precedentemente:

    Node and File Share Majority. Similar to Node Majority quorum mode, except that a remote file share is also configured as a voting witness, and connectivity from any node to that share is also counted as an affirmative vote.  More than one-half of the possible votes must be affirmative for the cluster to be healthy. 

    As a best practice, the witness file share should not reside on any node in the cluster, and it should be visible to all nodes in the cluster.

    Detto questo è normale che quando viene spento il server dove risiede la cartella condivisa il cluster va in errore: in quel caso non si ottiene più della metà dei voti, come confermato dall'evento con ID 1177 che ti viene restituito.
    https://technet.microsoft.com/en-us/library/cc773498(v=ws.10).aspx



    venerdì 12 gennaio 2018 15:48
    Moderatore
  • ok mi è chiaro tutto.

    Mi chiedo solo il perchè lui migra i ruoli quando va giù il quorum, essendo i 2 nodi comunque attivi.

    L.

    lunedì 15 gennaio 2018 08:49
  • Ciao dovresti avere la condizione di quorum lost , quando il nodo che ospita la share non è raggiungibile , essendo il quorum il punto di controllo del WSFC , quando lo stesso non è disponibile il cluster non è in grado di eleggere il nodo attivo .

    Questo viene fatto per garantire l'integrità del dato , per questo esiste il sistema dei voti , esiste tuttavia una procedura per forzare il riavvio dei servizi senza il quorum .

    Come esposto da Fabrizio in quel tipo di configurazione se la share non è esterna ai due nodi del cluster e se viene considerata come voto , quando uno dei nodi andrà giù avrai 2 voti e quindi la maggioranza il fail.

    Saluti

    Quirino


    QuirinoS

    lunedì 15 gennaio 2018 09:54
  • ok mi è chiaro tutto.

    Mi chiedo solo il perchè lui migra i ruoli quando va giù il quorum, essendo i 2 nodi comunque attivi.

    L.

    Perché una volta perso il quorum il cluster va offline, indipendentemente dallo stato dei nodi. Questo potrebbe portare ad un failover automatico sui nodi a seconda delle tempistiche, ma poco importa visto che comunque il cluster avrà perso l'alta disponibilità.
    Dovresti rivedere la configurazione per evitare la perdita del quorum, penso possa esserti utile questo articolo:
    http://www.edwinmsarmiento.com/so-you-think-your-sql-server-availability-group-is-really-highly-available/

    lunedì 15 gennaio 2018 10:01
    Moderatore