sticky
Grupo de disponibilidade pendente de forma intermitente WSFC RRS feed

  • Question

  • Pessoal, estou com problema intermitente no meu grupo de disponibilidade configurado no WSFC do Windows Server 2016 Standard, no qual o AG cai e fica com status de pendente tentando volta sem sucesso. Quando reinicia o servidor o mesmo volta a funcionar depois de alguns minutos. Analisando os logs do wsfc achei as seguintes mensagens:

    "A component on the server did not respond in a timely fashion. This caused the cluster resource 'AG' (resource type 'SQL Server Availability Group', DLL 'hadrres.dll') to exceed its time-out threshold. As part of cluster health detection, recovery actions will be taken. The cluster will try to automatically recover by terminating and restarting the Resource Hosting Subsystem (RHS) process that is running this resource. Verify that the underlying infrastructure (such as storage, networking, or services) that are associated with the resource are functioning correctly.
    Cluster resource 'AG' of type 'SQL Server Availability Group' in clustered role 'AG' 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."

    Inicialmente achei que pudesse está relacionado com a configuração dos componentes FAILURE_CONDITION_LEVEL ou HEALTH_CHECK_TIMEOUT apesar das mensagens e pesquisas apontarem para ele, mas pelo visto não parecer, pois fiz algumas alterações nas configurações padrões que não surtiram efeito.  

    Agradeço desde já o apoio na solução.

    Wednesday, October 23, 2019 8:50 PM

Answers

  • Deleted
    Thursday, October 24, 2019 12:18 PM
  • Jerfeson,

    Você já a verificar se o SQL Server esta registrando alguma coisa em seu Log?

    Tem algum arquivo de Dump criando neste caminho: C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\

    Verifique se este link pode te ajudar: 

    https://techcommunity.microsoft.com/t5/SQL-Server-Support/Diagnose-Unexpected-Failover-or-Availability-Group-in-RESOLVING/ba-p/318474


    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]

    Thursday, October 24, 2019 10:31 PM
    Moderator
  • Jerfeson,

    Vamos lá, em relação ao disco de Quórum, mesmo sendo dois nós, ele é necessário justamente para identificar em qual nó o sql server esta fazendo acesso ao dado.

    As suas abordagens estão corretas, ao meu ver o que esta acontecendo é justamente algo entre o momento que o Windows Server Cluster recebe a solicitação para desvio do fluxo de trabalho do nó e logo na sequência o outro nó deveria ser sensibilizado e inicializado, parece-me não posso afirmar, mas seu WSFC estão aguardando uma resposta do SQL Server.

    Se você realizar um ping para os IPs utilizados para cada nó e principalmente para o serviço do SQL Server, o que acontece?


    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]

    Friday, October 25, 2019 1:11 AM
    Moderator
  • Jerfeson,

    Que bom que você fez estes testes e conseguiu um avanço, em relação as suas perguntas, segue abaixo as minhas considerações:

    Será que essa configuração ocasionou na não persistência do erro? Configurei também os components: Provavelmente sim, desta forma o WSFC vai ter como identificar e aguardar alguma sinalização dos nós.

    Seria uma boa configuração? Neste momento sim, pois você não tem a mínima ideia do que pode estar acontecendo, sendo assim, vamos manter as configurações padrões e avançar, procure nos próximos dias realizar um monitoramento.


    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]

    Friday, October 25, 2019 10:13 PM
    Moderator

All replies

  • Jerfeson,

    Como esta a configuração do DNS no seu ambiente?


    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]

    Wednesday, October 23, 2019 11:01 PM
    Moderator
  • Essa informação Galvão não tenho muita precisão, pois teria que saber do pessoal de infra. Mas o que necessitaria saber pra buscar a informação? Segundo o pessoal de infra diz está Ok, mas não tenho como ter certeza de nada. Só mexemos com os servidores de banco.
    Thursday, October 24, 2019 1:52 AM
  • Deleted
    Thursday, October 24, 2019 12:18 PM
  • Inicia o computador ou somente o serviço SQL? Inicia o servidor, mas não me atentei em reiniciar apenas o serviço. Caso volte acontecer farei desta forma pra acompanhar o resultado.

    Pergunta boba: as instâncias SQL estão com atualização de software em dia? A nível de SQL Server sim. Ontem me reunir com administrador da infra e do suporte do servidor, onde foi analisado as condições dos dispositivos do servidor, principalmente das interfaces de rede e firmwares dos drives  (estava tudo ok). Atualizaram o sistema operacional, pois tinham atualizações a serem instaladas. A última atualização do SQL Server 2016 disponibilizada pela MS foi deste mês de outubro.

    Thursday, October 24, 2019 2:00 PM
  • Fiz as seguintes validações:

    1. No servidor A instalei e configurei o WSFC do Windows Server 2016;
    2. No WSFC do servidor A adicionei o servidor B, no qual já tinha instalado também o WSFC;
    3. No servidor A e B ativei e configurei AlwaysOn AG no SQL Server 2016 com apenas um banco de dados BD1;
    4. No AlwaysOn do servidor A o listener foi configurado com Ip estático e a porta 1433.

    Testes de failover executados:

    1. Executei o failover manual no servidor A usando o gestor do AlwaysOn do SQL Server 2016, onde o servidor B assumiu o papel de primário do ambiente passando a bola de secundário para o servidor A;

    Quando executei os testes de perda de conectividade e parada de serviço o comportamento já não foram tão satisfatórios. Quando paro o serviço do servidor A ou tiro a cabo da interface de rede do mesmo (lembrando que o servidor A já está como primário), percebi que o grupo de alta disponibilidade falha e não inicializa fazendo o failover automático como deveria da forma como está configurado no AlwaysOn do servidor A. Achei estranho o comportamento, pois os testes feitos acima fizeram parte dos itens de homologação e validação da tecnologia quando foi implementada no ambiente de produção. O problema nunca foi relatado. O que poderia está incorreto na configuração, pois creio que tenha tudo haver com o problema que estou relatado acima na thread. 

    Mensagem do log WSFC:

    "O Serviço de cluster não pôde colocar a função clusterizada 'AG' completamente online ou offline. Um ou mais recursos podem estar com falha. Isso pode afetar a disponibilidade da função clusterizada."

    "A função de cluster 'AG' excedeu o limite de failover. Ela esgotou o número configurado de tentativas de failover no período alocado para isso e ficará no estado de falha. Nenhuma outra tentativa será feita para colocar a função em modo online ou executar failover dela em outro nó do cluster. Verifique os eventos associados à falha. Depois de eliminadas as causas da falha, a função poderá ser colocada em modo online manualmente ou o cluster poderá tentar fazer isso outra vez após o período de atraso de reinicialização."

    Qual seria a melhor configuração para FAILURE_CONDITION_LEVEL e HEALTH_CHECK_TIMEOUT?

    O problema poderia está relacionado com a configuração da votação de quorum do WSFC? Analisei através dos comandos:

    #PowerShell Ise ->

    Import-Module FailoverClusters $cluster = "CLUSTER" $nodes = Get-ClusterNode -Cluster $cluster $nodes | Format-Table -property NodeName, State, NodeWeight --SSMS -> SELECT member_name, member_state_desc, number_of_quorum_votes FROM sys.dm_hadr_cluster_members;

    Estão todos com valor 1.


    Thursday, October 24, 2019 8:38 PM
  • Jerfeson,

    Você já a verificar se o SQL Server esta registrando alguma coisa em seu Log?

    Tem algum arquivo de Dump criando neste caminho: C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\

    Verifique se este link pode te ajudar: 

    https://techcommunity.microsoft.com/t5/SQL-Server-Support/Diagnose-Unexpected-Failover-or-Availability-Group-in-RESOLVING/ba-p/318474


    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]

    Thursday, October 24, 2019 10:31 PM
    Moderator
  • Jerfeson,

    Ok, mas seria importante sabermos se a propagação e resolução de nomes e ips em seu ambiente DNS estão sendo resolvidos corretamente, pois as configuração dos Nós, disco de Quorum e replicas estão totalmente relacionados com as configurações de DNS e rede.

    Verifique se você teria a possibilidade de fazer um flushdns em seu ambiente.


    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]

    Thursday, October 24, 2019 10:32 PM
    Moderator
  • Disparei Galvão um flushdns com sucesso em meu ambiente. Já tinha lido sobre o artigo citado e por esse motivo levantei as questões sobre as duas configurações. 

    Seria a situação normal a citada por mim?

    "

    1. Executei o failover manual no servidor A usando o gestor do AlwaysOn do SQL Server 2016, onde o servidor B assumiu o papel de primário do ambiente passando a bola de secundário para o servidor A;

    Quando executei os testes de perda de conectividade e parada de serviço o comportamento já não foram tão satisfatórios. Quando paro o serviço do servidor A ou tiro a cabo da interface de rede do mesmo (lembrando que o servidor A já está como primário), percebi que o grupo de alta disponibilidade falha e não inicializa fazendo o failover automático como deveria da forma como está configurado no AlwaysOn do servidor A. Achei estranho o comportamento, pois os testes feitos acima fizeram parte dos itens de homologação e validação da tecnologia quando foi implementada no ambiente de produção. O problema nunca foi relatado. O que poderia está incorreto na configuração, pois creio que tenha tudo haver com o problema que estou relatado acima na thread. "

    E quanto a configuração do quorum é de fato necessária nesta situação? São apenas dois Nós.

    Friday, October 25, 2019 12:51 AM
  • Jerfeson,

    Vamos lá, em relação ao disco de Quórum, mesmo sendo dois nós, ele é necessário justamente para identificar em qual nó o sql server esta fazendo acesso ao dado.

    As suas abordagens estão corretas, ao meu ver o que esta acontecendo é justamente algo entre o momento que o Windows Server Cluster recebe a solicitação para desvio do fluxo de trabalho do nó e logo na sequência o outro nó deveria ser sensibilizado e inicializado, parece-me não posso afirmar, mas seu WSFC estão aguardando uma resposta do SQL Server.

    Se você realizar um ping para os IPs utilizados para cada nó e principalmente para o serviço do SQL Server, o que acontece?


    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]

    Friday, October 25, 2019 1:11 AM
    Moderator
  • Se você realizar um ping para os IPs utilizados para cada nó e principalmente para o serviço do SQL Server, o que acontece? Fiz as seguintes validações no ambiente construído para testes: 

    1. Parei o serviço do SQL Server do servidor A quando esse estava como primário;
    2. Desabilitei a interface de rede do servidor A quando esse estava como primário;

    Mantive pingando do servidor A -> B e do A <- B sem perda de conectividade. Exceto quando desabilitei a interface de rede do servidor A. A transição do fluxo de trabalho ocorreu sem problemas, não mais o AG apresentando falha. Um detalhe configurei antes para análise o quorum (logo abaixo) no WSFC do servidor A usando a opção padrão já que não tinha ideia em trabalhar com disco e compartilhamento. Será que essa configuração ocasionou na não persistência do erro? Configurei também os componentes FAILURE_CONDITION_LEVEL = 5 e HEALTH_CHECK_TIMEOUT = 60000. Seria uma boa configuração?

     

    Lembrando que as configurações foram realizadas num ambiente de teste. Ainda não validei em um ambiente de produção, mas queria ter o feedback da galera do fórum.


    Friday, October 25, 2019 7:00 PM
  • Jerfeson,

    Que bom que você fez estes testes e conseguiu um avanço, em relação as suas perguntas, segue abaixo as minhas considerações:

    Será que essa configuração ocasionou na não persistência do erro? Configurei também os components: Provavelmente sim, desta forma o WSFC vai ter como identificar e aguardar alguma sinalização dos nós.

    Seria uma boa configuração? Neste momento sim, pois você não tem a mínima ideia do que pode estar acontecendo, sendo assim, vamos manter as configurações padrões e avançar, procure nos próximos dias realizar um monitoramento.


    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]

    Friday, October 25, 2019 10:13 PM
    Moderator
  • Fiz um teste em um ambiente de produção e quando desativamos a interface de rede no servidor secundário o ambiente parou de responder. No events de logs do WSFC peguei o seguinte erro: "O serviço de Cluster está sendo encerrado porque o quorum foi perdido. Isso pode ser causado pela perda de conectividade entre alguns dos nós do cluster ou todos eles, ou devido ao failover do disco testemunha. 
    Execute o Assistente para Validar Configuração para verificar a configuração de rede. Se a condição persistir, verifique se há erros de hardware ou software relacionados ao adaptador de rede. Além disso, verifique se há falhas em outros componentes da rede aos quais o nó esteja conectado, como hubs, comutadores ou pontes." Rodei o report de validação e retornou no item de VALIDAR CONFIGURAÇÃO DE QUORUM: "O cluster não está configurado com uma testemunha de quorum. Como prática recomendada, configure uma testemunha de quorum para ajudar a obter a maior disponibilidade do cluster." Não entendi já que usei a configuração típica de quorum. E é possível confirmar se realmente a configuração de quorum foi feita corretamente? Será que é necessário fazer a configuração de disco pra o quorum?

    Monday, October 28, 2019 8:31 PM
  • Jerfeson,

    Cara, isso é problema de rede, pode ter certeza, algum dos NÓS esta abortando o processo de transferência de responsabilidade entre eles, ou seja, quando chega a solicitação para assumir o mesmo não consegui se comunicar com o disco de quórum.

    Por acaso você esta utilizando iSCSI Initiator?

    Talvez seja o caso de aplicar um outro servidor fazendo o papel de Witness Quórum.


    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]

    Monday, October 28, 2019 8:44 PM
    Moderator
  • Por acaso você esta utilizando iSCSI Initiator? Não configurei, mas pode ser uma boa saide confere?

    Posso utilizar um espaço do meu disco local do servidor A que está configurado o WSFC? Depois atrelar na configuração do quorum de disco?


    Tuesday, October 29, 2019 6:42 PM
  • Jerfeson,

    Sim, isso mesmo, pode ser uma saída. Você deve justamente utilizar um espaço no Servidor dedicado ao WSFC e através do iSCSI fazer o processo de inicialização e apresentar este disco ao WSFC e seus respectivos nós.


    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]

    Tuesday, October 29, 2019 7:31 PM
    Moderator
  • Justamente grande Galvão. Acho que o problema está ai mesmo, pois testei em outro ambiente e deu o mesmo problema quando desabilitamos a interface de rede. Quando configuramos o WSFC por default é criada uma pasta "C:\ClusterStorage\". Posso usar como opção de configuração do quorum?
    Tuesday, October 29, 2019 10:22 PM
  • Jerfeson,

    Opa, estamos no caminho!!!!

    Sim, pode utilizar pasta, valide se a mesma não esta sendo removida no momento da falha.


    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]

    Tuesday, October 29, 2019 10:28 PM
    Moderator
  • Deleted
    Tuesday, October 29, 2019 11:12 PM
  • Deleted
    Tuesday, October 29, 2019 11:25 PM
  • "A component on the server did not respond in a timely fashion. This caused the cluster resource 'AG' (resource type 'SQL Server Availability Group', DLL 'hadrres.dll') to exceed its time-out threshold. As part of cluster health detection, recovery actions will be taken. The cluster will try to automatically recover by terminating and restarting the Resource Hosting Subsystem (RHS) process that is running this resource. Verify that the underlying infrastructure (such as storage, networking, or services) that are associated with the resource are functioning correctly.

    Jerfeson, você já deu uma lida no artigo "Understanding how Failover Clustering Recovers from Unresponsive Resources"?

    Eu concentraria a atenção nessa mensagem de erro e nas prováveis causas dela, bem como nas ações recomendadas quando essa mensagem de erro ocorre. Atenção ao item "How to Troubleshoot RHS Recovery".

    Se necessário, gere os cluster logs e em conjunto com a equipe de infraestrutura contacte o suporte da Microsoft.


    José Diz     Belo Horizonte, MG - Brasil     [query performance tuning: Porto SQL]


    Este conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita.


    José,

    Obrigado pelas observações, o Jerfeson já havia acessado este link em outra oportunidade.


    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]

    Wednesday, October 30, 2019 12:03 AM
    Moderator
  • Deleted
    Wednesday, October 30, 2019 10:48 AM
  • Quero agradecer a Galvão e José a atenção e paciência em compartilhar o conhecimento na solução do problema. Sou admirador do trabalho e dos posts de vocês na internet. 

    Jerfeson, qual é o chipset das placas de rede? Não me certifiquei dessas informações, pois na medida que fui testando configurações e estudando o caso, com auxílio de vocês, percebi que o problema não estava nos ambientes testados, mas na ausência de alguma configuração que deixei de fazer quando subi o WSFC.

    Já tinha lido os artigos sugeridos por José Diz nas minhas pesquisas.  O WSFC na validação sugere que cada servidor tenha duas interfaces de rede instaladas. A presença apenas de uma poderia causar esse problema? O estranho agora é que no meu ambiente de teste funciona e passa nos testes.

    Tem um detalhe também. Quando desativo a interface de rede do servidor A que está com WSFC configurada o Cluster fica offline.


    Quando forço o start forçado por quorum o Cluster volta a funciona, mas o AG não:

    "A função de cluster 'AG' excedeu seu limite de failover. Ele esgotou o número configurado de tentativas de failover dentro do período de failover alocado a ele e será deixado em um estado de falha. Nenhuma tentativa adicional será feita para colocar a função online ou executá-la com failover em outro nó no cluster. Verifique os eventos associados à falha. Após a resolução dos problemas que causam a falha, a função pode ser colocada online manualmente ou o cluster pode tentar colocá-la online novamente após o período de atraso de reinicialização."

    Friday, November 1, 2019 6:19 PM
  • Jerfeson,

    Vamos por partes:

    Quando desativo a interface de rede do servidor A que está com WSFC configurada o Cluster fica offline.

    Isso pode justamente ocorrer se você estiver tendo alguma inconsistência nas configurações do DNS, ou seja, os IPs utilizado por todo ambiente de Cluster estão registrados e atualizados em seu servidor DNS?

    Quando forço o start forçado por quorum o Cluster volta a funciona, mas o AG não:

    "A função de cluster 'AG' excedeu seu limite de failover. Ele esgotou o número configurado de tentativas de failover dentro do período de failover alocado a ele e será deixado em um estado de falha. Nenhuma tentativa adicional será feita para colocar a função online ou executá-la com failover em outro nó no cluster. Verifique os eventos associados à falha. Após a resolução dos problemas que causam a falha, a função pode ser colocada online manualmente ou o cluster pode tentar colocá-la online novamente após o período de atraso de reinicialização."

    Disco de Quorum não tem relação direta com o AG, o uso do AG é justamente uma implementação de alta disponibilidade vinculada ao AlwaysOn e não ao uso do Quorum.


    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]

    Friday, November 1, 2019 11:01 PM
    Moderator
  • Isso pode justamente ocorrer se você estiver tendo alguma inconsistência nas configurações do DNS, ou seja, os IPs utilizado por todo ambiente de Cluster estão registrados e atualizados em seu servidor DNS? Estão sim. Subi um ambiente usando WSFC com independência de domínio, onde realizado a configuração dos Ips dos servidores, do cluster e listener com sufixo DNS  no arquivo de Hosts dos servidores A e B. Assim passam a se comunicar normalmente. Tive o problema parecido num ambiente com domínio também.

    Quando forço o start forçado por quorum o Cluster volta a funciona, mas o AG não. Afirmativo. O WSFC volta a funciona, porém o AG não. Ficando somente online quando restabelece a conectividade da interface de rede.

    O quorum teria relação direta com WSFC correto? Os motivos dele ter ficado offline comprometeu o funcionamento do AG do AlwasOn. O que poderia está faltando na minha configuração então do WSFC e do AlwaysOn AG? 


    Monday, November 4, 2019 1:32 PM
  • Jerfeson,

    Vamos lá:

    O quorum teria relação direta com WSFC correto? Ele tem relação com o serviço de cluster configurado para os nós do SQL Server, sendo que o disco do quorum a partir do momento que ele é adicionado ao WSFC ele se torna um elemento parte de todo ambiente.

    Os motivos dele ter ficado offline comprometeu o funcionamento do AG do AlwasOn: Isso não tem relação, pois quando se utiliza o AlwaysOn, já destaquei é uma outra forma, uma outra tecnologia e recurso de alta disponibilidade que trabalha de forma paralela ao WSFC, todo controle deste ambiente não é feito diretamente pelo serviço de cluster do Windows, existe as comunicações entre as replicas envolvidas.

    O que poderia está faltando na minha configuração então do WSFC e do AlwaysOn AG? As replicas não estão conseguindo fazer a transfêrencia de papel entre si, quando um nó do AlwaysOn cai outra réplica tem que assumir o controle.


    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]

    Monday, November 4, 2019 10:20 PM
    Moderator
  • Deleted
    Tuesday, November 5, 2019 9:02 AM
  • Estou validando a seguinte configuração com o conceito da rede hearbeat: 

    VM A Interface 1 sql server 10.0.0.1  interface 2 192.168.0.1;

    VM B interface 1 sql  server 10.0.0.2 interface 2 192.168.0.2 ;

    Cluster 192.168.0.3;

    Listener 192.168.0.4.

    Ainda não implementei, mas irei configurar uma nova interface virtual em cada VM, no qual os dois servidores terão conectividade e configuração de faixa de IPs distintas da rede operacional. 

    https://support.microsoft.com/pt-br/help/258750/recommended-private-heartbeat-configuration-on-a-cluster-server 

    Wednesday, November 6, 2019 10:47 PM
  • Jerfeson,

    Ok, ótimo, se possível no seu servidor WSFC deixei três placas de rede, uma para atender as solicitações DNS, outra para as solicitações feitas ao WSFC e a última para uso em geral 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]

    Wednesday, November 6, 2019 11:45 PM
    Moderator