SQL 2008 Espelhamento de banco de dados sobre o link WAN com certificados

1

Estou configurando o espelhamento de banco de dados em um link WAN entre duas instâncias nomeadas do SQL 2008 cujos servidores host não são membros do domínio, usando certificados para autenticação. Depois de muitas tentativas para fazer isso funcionar, comecei do zero e fui passo a passo, de acordo com o BOL link , no entanto, o problema que eu estava tentando resolver ainda está presente.

O problema está no conjunto de etapas finais que define o status do parceiro em cada servidor. Quando executo a etapa 2 para definir o status do parceiro em "HOST_A", recebo o seguinte erro:

Msg 1418, Level 16, State 1, Line 2

The server network address "TCP://server-b.our-domain.com:5022" can not be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational.

O interessante é que eu posso ver o tráfego no firewall (TCPDUMP) indo e voltando entre os dois servidores por cerca de 15 segundos antes que o erro seja cuspido para mim.

Neste ponto, não sei como proceder, pois posso conectar-me à instância SERVER-A \ BLUE do SSMS no SERVER-B e posso conectar-me à instância SERVER-B \ RED do SSMS no SERVER-A sem um problema. Estou muito confuso porque estou recebendo o erro neste momento. Os pontos de extremidade em ambos os lados são listados como iniciados em sys.tcp_endpoints e sys.endpoints.

Outra observação interessante é que antes tentando a etapa 2, eu posso fazer telnet de SERVER-A para SERVER-B sobre 5022 e de SERVER-B para SERVER-A acima de 5022, mas após a etapa 2 falhar , Não consigo mais telnetar nenhuma direção. O TCPDUMP mostrará o tráfego indo de um para o outro, mas não há tráfego de retorno após a etapa 2 falhar.

A questão principal para mim é que este erro parece ter a descrição errada para o que realmente está acontecendo, já que claramente o endereço de rede existe e pode ser alcançado e os terminais também estão operacionais (pelo menos até a operação falhar [Rolleyes] ) Eu também tentei fazer a configuração na direção oposta (fazendo um backup / restauração completo sem recuperação, etc. indo na outra direção) e ela falha da mesma maneira, fornecendo os mesmos erros, mas novamente com todo o tráfego mostrando o firewall.

Por fim, nos logs do SQL, também recebo o erro "Erro: 1443, Gravidade: 16, Estado: 2". O que parece estar diretamente relacionado, e alguns dos que eu encontrei on-line sugerem um problema com a autenticação do Windows, no entanto, isso não deve ser o caso, já que meus endpoints estão configurados com certificados.

Qualquer ajuda com isso seria muito apreciada.

Aqui está o T-SQL real usado para configurar isso, que segue o que está no artigo BOL.

--ON SERVER-A\BLUE
use master
go

create master key encryption by password = 'password123!'
go

create certificate CA_cert
        With subject = 'CA_cert Certificate'
go

create endpoint Mirroring
        STATE = STARTED
                AS TCP (
                        LISTENER_PORT=5022
                        , LISTENER_IP = ALL
                )
        FOR DATABASE_MIRRORING (
                AUTHENTICATION = CERTIFICATE CA_cert
                , ENCRYPTION = REQUIRED ALGORITHM AES
                , ROLE = ALL
        )
go

BACKUP CERTIFICATE CA_cert TO FILE = 'c:\sql\CA_cert.cer'
go


--ON SERVER-B\RED
use master
go

create master key encryption by password = 'password123!'
go

create certificate NJ_cert
        With subject = 'NJ_cert Certificate'
go

create endpoint Mirroring
        STATE = STARTED
                AS TCP (
                        LISTENER_PORT=5022
                        , LISTENER_IP = ALL
                )
        FOR DATABASE_MIRRORING (
                AUTHENTICATION = CERTIFICATE NJ_cert
                , ENCRYPTION = REQUIRED ALGORITHM AES
                , ROLE = ALL
        )
go

BACKUP CERTIFICATE NJ_cert TO FILE = 'c:\sql\NJ_cert.cer'
go


--ON SERVER-A\BLUE
create login NJ_login WITH PASSWORD = 'password123!'
go

CREATE USER NJ_user FOR LOGIN NJ_login
go

CREATE CERTIFICATE NJ_cert
        AUTHORIZATION NJ_user
        FROM FILE = 'C:\sql\NJ_cert.cer'
go

GRANT CONNECT ON ENDPOINT::Mirroring TO NJ_login
go


--ON SERVER-B\RED
create login CA_login WITH PASSWORD = 'password123!'
go

CREATE USER CA_user FOR LOGIN CA_login
go

CREATE CERTIFICATE CA_cert
        AUTHORIZATION CA_user
        FROM FILE = 'C:\sql\CA_cert.cer'
go

GRANT CONNECT ON ENDPOINT::Mirroring TO CA_login
go


--ON SERVER-B\RED
alter database testdb
        set partner = 'TCP://server-a.our-domain.com:5022'
go


--ON SERVER-A\BLUE
alter database testdb
        set partner = 'TCP://server-b.our-domain.com:5022'
go

-- Everything works fine up until this point at which time I get the previously mentioned errors
    
por tcnolan 22.01.2010 / 05:29

1 resposta

1

Anexe o Profiler às duas instâncias (todas as três, se houver uma testemunha) e monitore os eventos Audit Database Mirroring Classe de Eventos de Login e Broker: Classe de Eventos de Conexão .

O erro 1418 diz simplesmente que, dentro de um tempo limite específico, a sessão de mirroirng não estava ativa, por qualquer motivo. Quando você emite o ALTER DATABASE ... SET PARTNER = 'tcp: // ..' no principal o principal se conectará ao espelho e o espelho se conectará ao principal em resposta. O que significa que tanto o valor do 'parceiro' principal quanto o valor 'parceiro' do espelho, definidos anteriormente, entram em cena, e ambos precisam estar corretos e a infra-estrutura subjacente (roteamento, DNS, IPSEC, Firewalls) deve ser conectada para o endereço desejado: port de ambos parceiros. Acrescente a testemunha se tiver uma e obtenha uma bola de pelo bastante complexa de conectividade TCP que deve ser verificada.

Se o problema for a segurança do certificado, o evento Login do espelhamento do banco de dados de auditoria indicará claramente a causa e o problema (certificado inválido, expirado, certificado incorreto usado, etc.). Se o problema for a estrutura TCP (roteamento, DNS, IPSEC, firewall etc), então o evento Broker: Connection mostrará o problema.

Se você quiser entender exatamente como funciona a autenticação baseada em certificado, leia em Como funciona a autenticação baseada em certificados .

    
por 23.01.2010 / 00:05