none
SQL Server 2012 - Availability Group - Testando Cenários de Failover RRS feed

  • Pergunta

  • Boa tarde a todos 

    Estou implementando um Availability Group em uma cloud e preciso testar alguns cenários de falha.

    Estou usando 2 instâncias configuradas com AG síncrono e failover automático e Failure-Condition Level 5

    Entre meus testes estão 2 cenários que me deixaram intrigado!

    1. Perda de conectividade da instância primária (Bloqueio via firewall das portas 1433 e 5022 (mirroring)) - Já tive caso do pessoal de TI bloquear sem querer as portas do SQL....

    O failover não aconteceu...O AG fica offline. Necessário Failover manual com FORCE_FAILOVER_ALLOW_DATA_LOSS...
    Tudo bem que os 2 nós do cluster estão up, mas deixar o AG inteiro offline? 
    Este comportamento está correto? o que posso fazer para me prevenir disto?
    E ainda tem que dar "resume data moviment" no secundário...

    2. Perda de conectividade com unidade iSCSI onde ficam os dados (Pra testar, deixei o disco offline...) (Deixei o tempdb neste disco também pra ver o que acontecia :) )

    Erro gravidade nível 24! Todos os bancos estão inacessíveis....inclusive master, tempdb...tudo.....Eita pipoca!!!
    O AG fica online, o AG Dashboad mostra todos os bancos sincronizados e todas replicas online... (What!!!!)
    Lembrando que estou usando Failure-Condition Level "5"...
    Claro que minha aplicação está offline....
    Em uma das tentativas, a instância ficou offline e em outra ela ficou online, porém com todos os bancos inacessíveis...

    Este comportamento está correto? o que posso fazer para me prevenir disto? o iSCSI ficar offline é raro, mas só este ano já aconteceu pra mim umas 3 vezes....(Softlayer cloud)

    Um failover automático neste caso seria esperado....

    O BOL diz que banco de dados corrompido, suspect não provoca failover automático, mas com o disco de todos dos bd inclusive de sistema offline...

    "Damaged databases and suspect databases are not detected by any failure-condition level. Therefore, a database that is damaged or suspect (whether due to a hardware failure, data corruption, or other issue) never triggers an automatic failover."

    Estes 2 cenários estão me deixando muito preocupado....

    Se o failover automático não acontecer em problemas de conectividade ou problemas de disco como este acima, ele vai acontecer na vida real quando? 
    quando o server inteiro parar....shutdown mesmo...ou com failover manual....?

    O cluster da instância resolveria nestes cenários? O problema do iSCSI continuaria, pois o shared disk estaria offline...


    • Editado VictorMLima quinta-feira, 7 de novembro de 2013 18:02
    quinta-feira, 7 de novembro de 2013 17:58

Respostas

  • Victor,

    O conceito do AlwaysOn Availability Group é uma forma de Alta Disponibilidade acoplada a um serviço de Cluster, na verdade o que esta rodando em cenário de Cluster é as suas réplicas de banco de dados e não propriamente dita a instância do SQL Server.

    Respondendo a suas perguntas:

    1. Perda de conectividade da instância primária (Bloqueio via firewall das portas 1433 e 5022 (mirroring)) - Já tive caso do pessoal de TI bloquear sem querer as portas do SQL....

    O failover não aconteceu...O AG fica offline. Necessário Failover manual com FORCE_FAILOVER_ALLOW_DATA_LOSS...

    Tudo bem que os 2 nós do cluster estão up, mas deixar o AG inteiro offline? 

    Sim porque o AG é composto por todos os Nodes que estão envolvidos no Grupo.

    Este comportamento está correto? o que posso fazer para me prevenir disto?

    Sim esta correto e é reflexo da falta de conectividade. Para você se prevenir é colocar estas portas de rede como exceções no seu firewall.

    E ainda tem que dar "resume data moviment" no secundário...

    Sim você tem que dar resume para que os dados possam ser movimentados e sincronizados.

    2. Perda de conectividade com unidade iSCSI onde ficam os dados (Pra testar, deixei o disco offline...) (Deixei o tempdb neste disco também pra ver o que acontecia :) )

    Neste tipo de cenário o Failover Cluster é totalmente afetado e sua área de armazenamento se torna offline por isso os bancos de dados aparecendo como Offline.

    Para que isso não ocorra você vai ter que trabalhar com Failover condicition nível 1 ou 3, conforme a tabela abaixo:

    Level

    Failure Condition

    1

    Specifies that an automatic failover should be initiated when any of the following occurs:

    • The SQL Server service is down.

    • The lease of the availability group for connecting to the WSFC cluster expires because no ACK is received from the server instance. For more information, see How It Works: SQL Server AlwaysOn Lease Timeout.

    2

    Specifies that an automatic failover should be initiated when any of the following occurs:

    • The instance of SQL Server does not connect to cluster, and the user-specified HEALTH_CHECK_TIMEOUT threshold of the availability group is exceeded.

    • The availability replica is in failed state.

    3

    Specifies that an automatic failover should be initiated on critical SQL Server internal errors, such as orphaned spinlocks, serious write-access violations, or too much dumping.

    This is the default behavior.

    4

    Specifies that an automatic failover should be initiated on moderate SQL Server internal errors, such as a persistent out-of-memory condition in the SQL Server internal resource pool.

    5

    Specifies that an automatic failover should be initiated on any qualified failure conditions, including:

    • Exhaustion of SQL Engine worker-threads.

    • Detection of an unsolvable deadlock.

    Parece que você esta misturando conceitos de cluster em seu cenário!!! Você tem alguma das instâncias do SQL Server instaladas em Cluster?



    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    sexta-feira, 8 de novembro de 2013 12:23
    Moderador
  • Victor,

    Mas você tem um Failover Clustering Services configurado?

    O iSCSI vai trabalhar linkado com o cluster, mas neste caso somente para o disco de quorum, como repositório para controle de funcionamento do serviço de cluster e seus nodes.

    Por isso eu estou pensando que você esta se confundindo entre AlwaysOn em relação ao Failover Clustering.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quinta-feira, 14 de novembro de 2013 12:21
    Moderador
  • Victor,

    É ai que esta o erro, se você não esta utilizando iSCSI para o disco de quorum, mas sim nas réplicas, você esta com seu ambiente totalmente separado.

    Sinceramente o AG não vai trabalhar da forma correta.

    Recomendo acessar o Blog do Luan Moreno que também é MVP, lá você vai encontrar alguns artigos sobre AlwaysOn.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]


    sexta-feira, 22 de novembro de 2013 13:56
    Moderador

Todas as Respostas

  • Victor,

    O conceito do AlwaysOn Availability Group é uma forma de Alta Disponibilidade acoplada a um serviço de Cluster, na verdade o que esta rodando em cenário de Cluster é as suas réplicas de banco de dados e não propriamente dita a instância do SQL Server.

    Respondendo a suas perguntas:

    1. Perda de conectividade da instância primária (Bloqueio via firewall das portas 1433 e 5022 (mirroring)) - Já tive caso do pessoal de TI bloquear sem querer as portas do SQL....

    O failover não aconteceu...O AG fica offline. Necessário Failover manual com FORCE_FAILOVER_ALLOW_DATA_LOSS...

    Tudo bem que os 2 nós do cluster estão up, mas deixar o AG inteiro offline? 

    Sim porque o AG é composto por todos os Nodes que estão envolvidos no Grupo.

    Este comportamento está correto? o que posso fazer para me prevenir disto?

    Sim esta correto e é reflexo da falta de conectividade. Para você se prevenir é colocar estas portas de rede como exceções no seu firewall.

    E ainda tem que dar "resume data moviment" no secundário...

    Sim você tem que dar resume para que os dados possam ser movimentados e sincronizados.

    2. Perda de conectividade com unidade iSCSI onde ficam os dados (Pra testar, deixei o disco offline...) (Deixei o tempdb neste disco também pra ver o que acontecia :) )

    Neste tipo de cenário o Failover Cluster é totalmente afetado e sua área de armazenamento se torna offline por isso os bancos de dados aparecendo como Offline.

    Para que isso não ocorra você vai ter que trabalhar com Failover condicition nível 1 ou 3, conforme a tabela abaixo:

    Level

    Failure Condition

    1

    Specifies that an automatic failover should be initiated when any of the following occurs:

    • The SQL Server service is down.

    • The lease of the availability group for connecting to the WSFC cluster expires because no ACK is received from the server instance. For more information, see How It Works: SQL Server AlwaysOn Lease Timeout.

    2

    Specifies that an automatic failover should be initiated when any of the following occurs:

    • The instance of SQL Server does not connect to cluster, and the user-specified HEALTH_CHECK_TIMEOUT threshold of the availability group is exceeded.

    • The availability replica is in failed state.

    3

    Specifies that an automatic failover should be initiated on critical SQL Server internal errors, such as orphaned spinlocks, serious write-access violations, or too much dumping.

    This is the default behavior.

    4

    Specifies that an automatic failover should be initiated on moderate SQL Server internal errors, such as a persistent out-of-memory condition in the SQL Server internal resource pool.

    5

    Specifies that an automatic failover should be initiated on any qualified failure conditions, including:

    • Exhaustion of SQL Engine worker-threads.

    • Detection of an unsolvable deadlock.

    Parece que você esta misturando conceitos de cluster em seu cenário!!! Você tem alguma das instâncias do SQL Server instaladas em Cluster?



    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    sexta-feira, 8 de novembro de 2013 12:23
    Moderador
  • Obrigado por responder

    Respondendo a suas respostas:

    1. Sobre a resposta da pergunta de Perda de conectividade da instância primária 

    Este meu teste foi para simular uma falta de conectividade, já que não posso desabilitar o adaptador de rede pra este teste...vou perder o acesso...Estas portas estarão liberadas em meu uso normal...

    Este teste mostra que se tiver alguma perda da conectividade entre os 2 servidores o Failover não ira acontecer?

    Este comportamento não me parece correto. Como posso testar isso de outra forma?


    2. Sobre a resposta da pergunta de Perda de conectividade com unidade iSCSI 

    Estou usando o  Failover conditions 5, que no meu entendimento compreende todos os outros níveis além de causar failover quando acontecer exaustão de worker-threads e dead locks sem solução...

    Portanto, mostra que este tipo de erro não provoca Failover e isto é assustador, pois esperava que se minhas unidades de iSCSI estiverem offline, Erro gravidade nível 24, o failover acontecesse...

    As instâncias não estão em cluster, com shared disk e tudo mais. Estou testando o AG e vendo se ele atende minhas expectativas.



    segunda-feira, 11 de novembro de 2013 17:09
  • Victor,

    Mas você tem um Failover Clustering Services configurado?

    O iSCSI vai trabalhar linkado com o cluster, mas neste caso somente para o disco de quorum, como repositório para controle de funcionamento do serviço de cluster e seus nodes.

    Por isso eu estou pensando que você esta se confundindo entre AlwaysOn em relação ao Failover Clustering.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quinta-feira, 14 de novembro de 2013 12:21
    Moderador
  • Obrigado por responder.

    Estou testando a solução do AlwaysOn, onde devo configurar o Failover Cluster do Windows. Estou utilizando a opção de Shared folder localizado em outro servidor. Não uso iSCSI para quorum.

    Porém uso iSCSI para os discos de dados. Cada réplica tem seu próprio iSCSI para armazenar os dados.

    Minha preocupação é no caso de perder a conectividade com uma unidades iSCSI (rede, problema na storage, pau no windows, sei lá). Gostaria que acontecesse o failover neste caso, mas não aconteceu.

    quarta-feira, 20 de novembro de 2013 16:25
  • Victor,

    É ai que esta o erro, se você não esta utilizando iSCSI para o disco de quorum, mas sim nas réplicas, você esta com seu ambiente totalmente separado.

    Sinceramente o AG não vai trabalhar da forma correta.

    Recomendo acessar o Blog do Luan Moreno que também é MVP, lá você vai encontrar alguns artigos sobre AlwaysOn.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]


    sexta-feira, 22 de novembro de 2013 13:56
    Moderador
  • Obrigado pelas respostas
    sexta-feira, 22 de novembro de 2013 14:35