Falha na Transação Distribuída com o Windows Server 2008

4

Estou tendo um problema com uma nova configuração do servidor. Transações distribuídas iniciadas pelo servidor de aplicativos para o novo servidor estão falhando, mas funcionam bem com um servidor de banco de dados existente. Preciso de ajuda para determinar a causa do problema.

Por vários motivos, o novo servidor não está executando as versões mais recentes do Windows ou do SQL Server.

Configuração

SERVIDOR DE APLICAÇÃO

  • SO: Windows Server 2008 R2
  • Nome do NetBIOS: WEB-02
  • Configurado para falar com vários servidores de banco de dados, alguns locais, alguns remotos.
  • Portas do DCOM restritas a um intervalo de 5000 a 5020 para conversarem através do firewall para servidores remotos.
  • Firewall do Windows ativado
  • Propriedades do DTC
    • Acesso DTC à Rede marcado
    • Permitir clientes remotos, permitir administração remota desmarcada
    • Gerenciador de transações Comunicação
      • Permitir entrada, Permitir saída marcada
      • Nenhuma autenticação necessária
    • Ativar transações XA desmarcadas
    • Ativar transações SNA LU 6.2 verificado

NOVO SERVIDOR DE BANCO DE DADOS

  • SO: Windows Server 2008
  • Nome do NetBIOS: DB-06
  • SQL Server 2005
  • Nenhuma restrição nas portas do DCOM
  • Firewall do Windows desativado
  • Propriedades do DTC
    • Acesso DTC à Rede marcado
    • Permitir que clientes remotos sejam desmarcados,
    • Permitir administração remota marcado
    • Gerenciador de transações Comunicação
      • Permitir entrada, Permitir saída marcada
      • Nenhuma autenticação necessária
    • Ativar transações XA desmarcadas
    • "Ativar transações SNA LU 6.2" não existe

SERVIDOR DE BANCO DE DADOS EXISTENTE

  • SO: Windows Server 2003 R2
  • Nome do NetBIOS: DB-04
  • SQL Server 2005
  • Nenhuma restrição nas portas do DCOM
  • Firewall do Windows desativado
  • Propriedades do DTC
    • Acesso DTC à Rede marcado
    • Permitir que clientes remotos sejam desmarcados,
    • Permitir administração remota marcado
    • Gerenciador de transações Comunicação
      • Permitir entrada, Permitir saída marcada
      • Nenhuma autenticação necessária
    • Ativar transações XA desmarcadas
    • "Ativar transações SNA LU 6.2" não existe

Todos os três servidores fazem parte do mesmo domínio e estão na mesma sub-rede. Apenas um switch Ethernet está entre eles, sem roteador, firewall de hardware nem dispositivo de segurança.

Problema

Um aplicativo ASP.NET é executado no servidor de aplicativos e funciona corretamente ao executar uma transação no servidor de banco de dados existente (DB-04). Ao executar as mesmas etapas no novo servidor de banco de dados (DB-06), ele falha e relata a mensagem de erro: Communication with the underlying transaction manager has failed.

Etapas de solução de problemas

Vimos esse erro antes com este aplicativo e normalmente significa que o Coordenador de Transações Distribuídas não está configurado corretamente ou que um firewall está interferindo. No passado, usei o DTCPing para solucionar problemas e corrigir erros.

Desta vez, no entanto, embora o DTCPing esteja falhando, não consigo determinar a causa do problema, pois os servidores de banco de dados existente e novo parecem estar configurados da mesma forma, exceto na versão do sistema operacional.

O seguinte é do arquivo de log DTCPing ao executar um teste do servidor de aplicativos (WEB-02) para o novo servidor de banco de dados (DB-06). Note que eu mudei os endereços IP e nomes DNS.

Do arquivo de log no servidor de aplicativos

10-14, 16:08:11.346-->Error(0x424) at clutil.cpp @256
10-14, 16:08:11.346-->-->OpenCluster
10-14, 16:08:11.346-->-->1060(The specified service does not exist as an installed service.)
++++++++++++++++++++++++++++++++++++++++++++++
     DTCping 1.9 Report for WEB-02  
++++++++++++++++++++++++++++++++++++++++++++++
Firewall Port Settings:
    Port:5000-5020
RPC server is ready
++++++++++++Validating Remote Computer Name++++++++++++
10-14, 16:08:22.796-->Start DTC connection test
Name Resolution:
    DB-06-->1.1.1.6-->s6.mydomain.com
10-14, 16:08:22.812-->Start RPC test (WEB-02-->DB-06)
RPC test failed

Do arquivo de log no novo servidor de banco de dados

10-14, 16:07:46.128-->Error(0x424) at clutil.cpp @256
10-14, 16:07:46.128-->-->OpenCluster
10-14, 16:07:46.129-->-->1060(The specified service does not exist as an installed service.)
++++++++++++++++++++++++++++++++++++++++++++++
     DTCping 1.9 Report for DB-06  
++++++++++++++++++++++++++++++++++++++++++++++
RPC server is ready
10-14, 16:08:22.785-->RPC server:DB-06 received following information:
    Network Name: DB-06
    Source  Port: 56535
    Partner LOG: WEB-022872.log
    Partner CID: 1ACD8780-9446-4E94-869D-6F1BDF787BBF

Depois de clicar em PING no servidor de banco de dados, o seguinte é adicionado ao arquivo de log. Na janela de saída, há uma pausa entre invocar o método RPC e a falha, portanto ele falha após um tempo limite.

++++++++++++Validating Remote Computer Name++++++++++++
10-14, 16:13:18.924-->Start DTC connection test
Name Resolution:
    Web-02-->1.1.1.2-->web-02.mydomain.com
10-14, 16:13:18.933-->Start RPC test (DB-06-->Web-02)
Problem:fail to invoke remote RPC method
Error(0x6D9) at dtcping.cpp @303
-->RPC pinging exception
-->1753(There are no more endpoints available from the endpoint mapper.)
RPC test failed

Como explicado em Solucionando problemas do MSDTC com a ferramenta DTCPing na seção "MENSAGEM DE ERRO 4 - Não há mais nós de extremidade do mapeador de pontos de extremidade", na verdade, há mais pontos de extremidade para o mapeador. Eu executei netstat -an no servidor de aplicativos (aquele com portas restritas) e está usando apenas 10 das 20 portas disponíveis.

    
por Scott 15.10.2013 / 01:24

1 resposta

1

Após envolver a Microsoft e muitos rastreamentos de rede feitos e analisados, finalmente rastreamos o problema. O servidor de aplicativos fazia parte de um cluster de balanceamento de carga de rede e há uma falha em como a implementação de IPv6 no Windows Server 2008 R2 interage com o componente de balanceamento de carga de rede.

Como os servidores tinham endereços IPv4 roteáveis publicamente, a pilha IPv6 criava automaticamente um endereço "6to4". Esse é um endereço IPv6 especial que corresponde ao endereço IPv4 passível de publicação pública da máquina. Isso foi feito tanto para o endereço da própria máquina quanto para o endereço do cluster compartilhado. A falha é que, em seguida, registrou ambos endereços 6to4 no DNS sob o nome próprio . Isso é diferente de como a pilha do IPv4 funciona na mesma máquina. Com o IPv4, o endereço IP do cluster não está registrado no DNS.

O resultado é que, quando o servidor de aplicativos conectado ao novo servidor de banco de dados e o servidor de banco de dados tentaram fazer a ligação reversa ao servidor de aplicativos, veriam que havia endereços IPv6 para o servidor de aplicativos e tentariam se conectar usando um desses endereços. Mas como ele usava o endereço 6to4 que correspondia ao endereço IP cluster , outro servidor no cluster receberia a conexão e, como o DTC em esse servidor não esperava um reverso bind, falhou.

O servidor de banco de dados existente, sendo o Windows Server 2003 R2, não usou IPv6 e, portanto, não encontrou o problema.

A solução foi para desabilitar a geração automática de endereços 6to4. Você pode fazer isso por meio da diretiva de grupo ou usando a seguinte linha de comando:

netsh interface 6to4 set state disabled

Para configurá-lo de volta, você executaria o seguinte comando:

netsh interface 6to4 set state default

Para ver as configurações atuais, execute o seguinte comando. No Windows 2008 R2 / Windows 7 e posterior, ele também indicará se a configuração atual é devido à Diretiva de Grupo.

netsh interface 6to4 show state
    
por 13.03.2015 / 23:52