locked
Problema com cluster HA RRS feed

  • Pergunta

  • Boa noite,

    Alguém já passou por isso ou pode me ajudar no seguinte problema:

    Alterei o tipo da instância da AD+DNS e do banco de dados, após isso parou de funcionar failover devido a alteração do driver acredito eu. Removendo todos os driver da máquina de banco de dados, reiniciado-a, definindo os mesmos ips, voltou a funcionar o failover no data lost, mas o quorum não fica ativo.

    A replicação de dados do ALwaysOn não parou por isso, mesmo não conseguindo realizar o failover, ele conseguia replicar os dados para o nó secundário. 

    Tentei voltar para instância anterior e utilizar o mesmo driver, mas não funcionou também.

    Como posso solucionar esse problema com o cluster?

    O Cluster faz vínculo com o driver ou algo assim?



    Guisal

    sexta-feira, 21 de junho de 2019 22:16

Respostas

  • GuiSal,

    O cenário para solucionar este problema, esta justamente ligado ao uso do Disco de Quorum, é justamente ele o responsável em controlar qual é o nó ativo que esta fazendo uso do dados e bancos de dados da instância SQL Server.

    O serviço de cluster vai depender justamente dele e o seu respectivo driver para poder identificar quem esta "compartilhando" este recurso.

    Estamos falando de um disco de quorum criado através do serviço iSCSI Initiator?

    Minha sugestão, se possível pare o serviço de AlwaysOn e suas réplicas, para os serviços do SQL Server me cada nó, pare o serviço de cluster.

    Suba o serviço de cluster, remova o disco de quorum, depois represente o disco de quorum para o serviço de Cluster do Windows.

    Assim que Quorum estiver reapresentado suba o primeiro nós e depois os demais.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    sexta-feira, 21 de junho de 2019 22:48
    Moderador
  • GuiSal,

    Obrigado pelas respostas, temos o disco de quorum reconhecido e funcional pelos nós conforme os resultados obtidos, mas o File Share Witness esta Down.

    Como estão definidas as configurações de rede destes servidores? Todos estão utilizando IP fixo ou temos algum cenário de DHCP?

    Alguma conta de login do SQL Server teve sua senha alterada? A conta de usuário definida para ser utilizada no Windows Server Failover Cluster continua fazendo parte do grupo Administradores?

    Você já reconfigurou as entradas de DNS destes servidores em seu DNS Server? 

    Utilize o comando flushdns neste terceiro servidor para atualizar o cache dele, bem como, repopular as rotas e tabela arp.

    Veja se estes links podem te ajudar:

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd353893(v=ws.10)

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd353964(v=ws.10)


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    • Sugerido como Resposta IgorFKModerator segunda-feira, 24 de junho de 2019 13:30
    • Marcado como Resposta GuiSal terça-feira, 25 de junho de 2019 13:57
    segunda-feira, 24 de junho de 2019 10:42
    Moderador

Todas as Respostas

  • Boa noite,

    Alguém já passou por isso ou pode me ajudar no seguinte problema:

    Alterei o tipo da instância da AD+DNS e do banco de dados, após isso parou de funcionar failover devido a alteração do driver acredito eu. Removendo todos os driver da máquina de banco de dados, reiniciado-a, definindo os mesmos ips, voltou a funcionar o failover no data lost, mas o quorum não fica ativo.

    A replicação de dados do ALwaysOn não parou por isso, mesmo não conseguindo realizar o failover, ele conseguia replicar os dados para o nó secundário. 

    Tentei voltar para instância anterior e utilizar o mesmo driver, mas não funcionou também.

    Como posso solucionar esse problema com o cluster?

    O Cluster faz vínculo com o driver ou algo assim?



    Guisal

    Versão do S.O é W2012R2


    Guisal

    sexta-feira, 21 de junho de 2019 22:46
  • GuiSal,

    O cenário para solucionar este problema, esta justamente ligado ao uso do Disco de Quorum, é justamente ele o responsável em controlar qual é o nó ativo que esta fazendo uso do dados e bancos de dados da instância SQL Server.

    O serviço de cluster vai depender justamente dele e o seu respectivo driver para poder identificar quem esta "compartilhando" este recurso.

    Estamos falando de um disco de quorum criado através do serviço iSCSI Initiator?

    Minha sugestão, se possível pare o serviço de AlwaysOn e suas réplicas, para os serviços do SQL Server me cada nó, pare o serviço de cluster.

    Suba o serviço de cluster, remova o disco de quorum, depois represente o disco de quorum para o serviço de Cluster do Windows.

    Assim que Quorum estiver reapresentado suba o primeiro nós e depois os demais.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    sexta-feira, 21 de junho de 2019 22:48
    Moderador
  • Bom dia,

    Está configurado como "File Share Witness" se aplica também?

    Consegui um log:

    00001628.000004f4::2019/06/22-11:54:59.390 INFO  [RHS] Enqueuing Arbitrate call.
    00001628.000004f4::2019/06/22-11:54:59.390 INFO  [RHS] Waiting for Arbitrate call to be dequeued.
    00001628.00000aec::2019/06/22-11:54:59.390 INFO  [RES] File Share Witness <File Share Witness>: Beginning arbitration ...
    00001628.00000aec::2019/06/22-11:54:59.390 INFO  [RES] File Share Witness <File Share Witness>: Obtaining the virtual server token from the core netname resource.
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: Agent: CanModuleBeInitializedImp - Module can be initialized, current state Error
    0000075c.00000a28::2019/06/22-11:54:59.406 INFO  [RES] Network Name <Cluster Name>: HandleGetVSToken - Initializing Identity module
    0000075c.00000a28::2019/06/22-11:54:59.406 INFO  [RES] Network Name <Cluster Name>: Initializing config info
    0000075c.00000a28::2019/06/22-11:54:59.406 INFO  [RES] Network Name: Agent: Initializing (3c29bf61-9d8d-4d98-b233-1efeb09c2ada,Identity)
    0000075c.00000a28::2019/06/22-11:54:59.406 INFO  [RES] Network Name: Agent: Sending request Netname/InitializeIndirect to NN:Agent
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: Agent: OnInitialize (3c29bf61-9d8d-4d98-b233-1efeb09c2ada,Identity)
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: Agent: CanModuleBeInitializedImp - Module can be initialized, current state Error
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: Agent: Sending Initialize to module NN:3c29bf61-9d8d-4d98-b233-1efeb09c2ada:Identity
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: Agent: Sending request Netname/Initialize to NN:3c29bf61-9d8d-4d98-b233-1efeb09c2ada:Identity
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name <Cluster Name>: Identity: Initializing Name: ClusterDB, NetbiosName: CLUSTERDB, Type: Singleton
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name <Cluster Name>: Identity: Initializing core resource id
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name <Cluster Name>: Identity: Obtaining new token
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name:  [NN] Setting crypto access members for decrypt. New container = false.
    000015a0.00000b50::2019/06/22-11:54:59.406 INFO  [NM] Received request from client address 172.31.16.10.
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: [NNLIB] Priming local KDC cache to \\WIN-TRJMQJE5KL7.domain.net for domain domain.net
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: [NNLIB] PopulateKerbKDCLookupCache - DC flags 0
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: [NNLIB] LsaCallAuthenticationPackage success with a request of size 102, result size 0 (status: 0, subStatus: 0)
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: [NNLIB] Priming local KDC cache to \\WIN-TRJMQJE5KL7.domain.net for domain label domain
    0000075c.00000884::2019/06/22-11:54:59.406 INFO  [RES] Network Name: [NNLIB] LsaCallAuthenticationPackage success with a request of size 94, result size 0 (status: 0, subStatus: 0)
    00001628.000004f4::2019/06/22-11:54:59.422 INFO  [RHS] Waiting for Arbitrate call to be completed.
    0000075c.00000884::2019/06/22-11:54:59.437 WARN  [RES] Network Name: [NNLIB] LogonUserEx fails for user ClusterDB$: 1326 (useSecondaryPassword: 0)
    0000075c.00000884::2019/06/22-11:54:59.437 WARN  [RES] Network Name: [NNLIB] LogonUserCall fails for user ClusterDB$: (useSecondaryPassword: 1), password length is 0
    0000075c.00000884::2019/06/22-11:54:59.437 INFO  [RES] Network Name: [NNLIB] Logon failed for user ClusterDB$ (Error 3221225579), DC \\WIN-TRJMQJE5KL7.domain.net, domain domain.net
    0000075c.00000884::2019/06/22-11:54:59.437 INFO  [RES] Network Name <Cluster Name>: Identity: Obtaining Windows Token for Name: ClusterDB, SamName: ClusterDB$, Type: Singleton, Result: -1073741717, LastDC: \\WIN-TRJMQJE5KL7.domain.net
    0000075c.00000884::2019/06/22-11:54:59.437 INFO  [RES] Network Name: Agent: OnInitializeReply, Failure on (3c29bf61-9d8d-4d98-b233-1efeb09c2ada,Identity): -1073741717
    0000075c.00000884::2019/06/22-11:54:59.437 INFO  [RES] Network Name <Cluster Name>: SyncReplyHandler Configuration, result: -1073741717
    0000075c.00000a28::2019/06/22-11:54:59.437 ERR   [RES] Network Name <Cluster Name>: Initializing Identity module failed with error -1073741717
    0000075c.00000a28::2019/06/22-11:54:59.437 ERR   [RHS] Error 3221225579 from ResourceControl for resource Cluster Name.
    00001628.00000aec::2019/06/22-11:54:59.437 ERR   [RES] File Share Witness <File Share Witness>: Failed to get virtual server token from core NetName resource, error 3221225579.
    00001628.00000aec::2019/06/22-11:54:59.437 ERR   [RES] File Share Witness <File Share Witness>: Failed to retrieve the virtual server token from the core netname resource with 3221225579.
    000015a0.000014f8::2019/06/22-11:54:59.453 ERR   [RCM] Arbitrating resource 'File Share Witness' returned error 3221225579
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] Res File Share Witness: OnlineCallIssued -> ProcessingFailure( StateUnknown )
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] TransitionToState(File Share Witness) OnlineCallIssued-->ProcessingFailure.
    000015a0.000014f8::2019/06/22-11:54:59.453 ERR   [RCM] rcm::RcmResource::HandleFailure: (File Share Witness)
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [QUORUM] Node 1: PostRelease for 284bce95-ae09-47cb-85c7-8a463be45ede
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [QUORUM] Node 1: quorum is not owned by anyone
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] resource File Share Witness: failure count: 3, restartAction: 2 persistentState: 1.
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] numDependents is zero, auto-returning true
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] Greater than restartPeriod time has elapsed since first failure of File Share Witness, resetting failureTime and failureCount.
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] Will queue immediate restart (500 milliseconds) of File Share Witness after terminate is complete.
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] Res File Share Witness: ProcessingFailure -> WaitingToTerminate( DelayRestartingResource )
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] TransitionToState(File Share Witness) ProcessingFailure-->[WaitingToTerminate to DelayRestartingResource].
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] Res File Share Witness: [WaitingToTerminate to DelayRestartingResource] -> Terminating( DelayRestartingResource )
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [RCM] TransitionToState(File Share Witness) [WaitingToTerminate to DelayRestartingResource]-->[Terminating to DelayRestartingResource].
    00001628.000004f4::2019/06/22-11:54:59.453 INFO  [RHS] not calling terminate() since File Share Witness has already been terminated.
    000015a0.000003ac::2019/06/22-11:54:59.453 INFO  [RCM] HandleMonitorReply: TERMINATERESOURCE for 'File Share Witness', gen(4) result 0/0.
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [GUM] Node 1: executing request locally, gumId:251, my action: qm/set-node-weight, # of updates: 1
    000015a0.000003ac::2019/06/22-11:54:59.453 INFO  [RCM] Res File Share Witness: [Terminating to DelayRestartingResource] -> DelayRestartingResource( StateUnknown )
    000015a0.000003ac::2019/06/22-11:54:59.453 INFO  [RCM] TransitionToState(File Share Witness) [Terminating to DelayRestartingResource]-->DelayRestartingResource.
    000015a0.000003ac::2019/06/22-11:54:59.453 WARN  [RCM] Queueing immediate delay restart of resource File Share Witness in 500 ms.
    000015a0.000014f8::2019/06/22-11:54:59.453 WARN  [QUORUM] Node 1: weight adjustment not performed. Cannot go below weight count 3 in a hybrid configuration with 2+ nodes
    000015a0.000014f8::2019/06/22-11:54:59.453 INFO  [DM] An empty single transaction is cancelled 133:133:1157452+1::0
    000015a0.000014f8::2019/06/22-11:54:59.968 INFO  [RCM] Delay-restarting File Share Witness and any waiting dependents.
    000015a0.000014f8::2019/06/22-11:54:59.968 INFO  [RCM] Res File Share Witness: DelayRestartingResource -> OnlineCallIssued( StateUnknown )
    000015a0.000014f8::2019/06/22-11:54:59.968 INFO  [RCM] TransitionToState(File Share Witness) DelayRestartingResource-->OnlineCallIssued.
    000015a0.000014f8::2019/06/22-11:54:59.968 INFO  rcm::RcmResource::OnlineWorker[RCM] Issuing Arbitrate(File Share Witness) to RHS.

    Referente ao erro "WARN  [RES] Network Name: [NNLIB] LogonUserEx fails for user ClusterDB$: 1326 (useSecondaryPassword: 0)"

    Encontrei alguns blogs dizendo para resetar a senha do usuário, mas esse clusterDB não é usuário, ele está no grupo "Computer" no AD. Não consigo resetar a senha dele.


    Guisal

    sábado, 22 de junho de 2019 12:26
  • GuiSal,

    O disco de quorum é sim utilizado como um recurso compartilhado entre os nós, por isso eu falei para você parar todo ambiente, e reconfigurar a estrutura do quorum, sabendo que os bancos de dados devem no momento em que você parar os nós estar direcionado para o nó primário.

    Na verdade este usuário, é um recurso criado pela Windows Server para trabalhar como serviço de Cluster, o mesmo fica residente na ferramenta Usuários e Grupos Locais da sua máquina.

    Mas sinceramente falando, tomando com base esta disca, ao invês de tentar resetar a senha, pare então todo o serviço de Cluster e reinicialize o serviço.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    sábado, 22 de junho de 2019 13:12
    Moderador
  • Já reinicie o ambiente umas duas vezes para testar se algo voltava.

    Reiniciei a terceira agora e não funcionou.



    Guisal

    sábado, 22 de junho de 2019 18:49
  • Guisal,

    Veja se você consegui executar esta DMV: sys.dm_hadr_cluster, o resultado das colunas: quorum_state e quorum_state_desc vão poder nos ajudar a identificar o que esta acontecendo no seu ambiente.

    quorum_state tinyint Estado do quorum do WSFC, um dos seguintes:

    0 = Estado de quorum desconhecido

    1 = Quorum normal

    2 = Quorum forçado
    quorum_state_desc varchar(50)

    Descrição da quorum_state, um de:

    UNKNOWN_QUORUM_STATE

    NORMAL_QUORUM

    FORCED_QUORUM

    Execute também a sys.dm_hadr_cluster_members.

    Estou suspeitando que o disco de quorum não esta sendo reconhecido pelo Windows Server Failover Cluster.

    Seria possível apresentar um print da tela do seu WSFC?

    O que esta sendo registrado no Event Viewer?

    As unidades de disco existentes neste servidor, qual delas esta configurada para fazer o papel de File Share Witness?

    O nome do caminho de rede utilizado na configuração do File Share Witness foi recriado?

    Tente acessar este caminho systemroot\Cluster\Reports e verifique o que é apresentado no arquivo QuorumConfiguration.mht.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]



    sábado, 22 de junho de 2019 23:29
    Moderador
  • Obrigado pelo auxilo, segue algumas respostas:

     select * from sys.dm_hadr_cluster

    cluster_name quorum_type quorum_type_desc quorum_state quorum_state_desc
    ClusterDB 2 NODE_AND_FILE_SHARE_MAJORITY 1 NORMAL_QUORUM

    select * from sys.dm_hadr_cluster_members

    member_name|member_type|member_type_desc|member_state|member_state_desc |number_quorum_votes
    NODE1 0 CLUSTER_NODE 1 UP 1
    NODE2 0 CLUSTER_NODE 1 UP 1
    File Share Witness 2 FILE_SHARE_WITNESS 0 DOWN 1

    Seria possível apresentar um print da tela do seu WSFC

    As unidades de disco existentes neste servidor, qual delas esta configurada para fazer o papel de File Share Witness?

    R: Quem faz esse papel é um terceiro servidor win-trjmqje5kl7

    O nome do caminho de rede utilizado na configuração do File Share Witness foi recriado?

    R: Não consigo deletar ele, porém consigo recria-lo, com o mesmo nome e não fica ativo.

    Os eventviwer report erros: 1564 e 1069

    


    Guisal



    domingo, 23 de junho de 2019 20:49
  • GuiSal,

    Obrigado pelas respostas, temos o disco de quorum reconhecido e funcional pelos nós conforme os resultados obtidos, mas o File Share Witness esta Down.

    Como estão definidas as configurações de rede destes servidores? Todos estão utilizando IP fixo ou temos algum cenário de DHCP?

    Alguma conta de login do SQL Server teve sua senha alterada? A conta de usuário definida para ser utilizada no Windows Server Failover Cluster continua fazendo parte do grupo Administradores?

    Você já reconfigurou as entradas de DNS destes servidores em seu DNS Server? 

    Utilize o comando flushdns neste terceiro servidor para atualizar o cache dele, bem como, repopular as rotas e tabela arp.

    Veja se estes links podem te ajudar:

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd353893(v=ws.10)

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd353964(v=ws.10)


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    • Sugerido como Resposta IgorFKModerator segunda-feira, 24 de junho de 2019 13:30
    • Marcado como Resposta GuiSal terça-feira, 25 de junho de 2019 13:57
    segunda-feira, 24 de junho de 2019 10:42
    Moderador
  • Bom dia Junior,

    Segue respostas:

    Como estão definidas as configurações de rede destes servidores? Todos estão utilizando IP fixo ou temos algum cenário de DHCP?
    R: Os ips estão fixo;

    Alguma conta de login do SQL Server teve sua senha alterada?
    R:Não

    A conta de usuário definida para ser utilizada no Windows Server Failover Cluster continua fazendo parte do grupo Administradores?
    R: Sim

    Você já reconfigurou as entradas de DNS destes servidores em seu DNS Server?
    R: Sim

    Já havia feito o flush e arp -a -d também nos 3 servidores.

    Hoje o quorum voltou a funcionar, sem nenhuma alterarção... o ambiente não foi desligado ou executando algum comando.

    De qualquer forma, muito obrigado pelo auxilio.


    Guisal

    terça-feira, 25 de junho de 2019 13:56
  • GuiSal,

    Ok, que bom, será que algo ficou pensando no processamento do Cluster?

    Você poderia verificar no Event Viewer o que foi registrado por parte do serviço de cluster do Windows.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 25 de junho de 2019 17:13
    Moderador
  • Fui verificar os logs no painel "Failover Cluster Manager", mas devo ter apagado eles sem querer está vazio.

    Também não encontrei no eventwvr.msc.

    Mais uma vez muito obrigado pelo auxilio!!


    Guisal

    quarta-feira, 26 de junho de 2019 13:19