☰

SQL 2008-Datenbankspiegelung über WAN-Verbindung mit Zertifikaten

tag-icon • tag-icon sql-server sql-server-2008 database-mirroring certificate
SQL 2008-Datenbankspiegelung über WAN-Verbindung mit Zertifikaten

Ich konfiguriere die Datenbankspiegelung über eine WAN-Verbindung zwischen zwei benannten SQL 2008-Instanzen, deren Hostserver keine Domänenmitglieder sind, und verwende Zertifikate zur Authentifizierung. Nach vielen Versuchen, dies selbst zum Laufen zu bringen, habe ich von vorne begonnen und bin Schritt für Schritt gemäß BOL vorgegangen.http://technet.microsoft.com/en-us/library/ms191140.aspx, das Problem, das ich lösen wollte, besteht jedoch weiterhin.

Das Problem betrifft die letzten Schritte, mit denen der Partnerstatus auf jedem Server festgelegt wird. Wenn ich Schritt 2 ausführe, um den Partnerstatus auf „HOST_A“ festzulegen, erhalte ich die folgende Fehlermeldung:

Meldung 1418, Ebene 16, Status 1, Zeile 2

Die Server-Netzwerkadresse „TCP://server-b.our-domain.com:5022“ kann nicht erreicht werden oder existiert nicht. Überprüfen Sie den Namen der Netzwerkadresse und ob die Ports für die lokalen und Remote-Endpunkte betriebsbereit sind.

Das Interessante ist jedoch, dass ich etwa 15 Sekunden lang sehen kann, wie der Datenverkehr auf der Firewall (TCPDUMP) zwischen den beiden Servern hin und her geht, bevor mir dieser Fehler zurückgegeben wird.

An diesem Punkt bin ich mir nicht sicher, wie ich weitermachen soll, da ich mich von SSMS auf SERVER-B aus problemlos mit der Instanz SERVER-A\BLUE verbinden kann und von SSMS auf SERVER-A aus problemlos mit der Instanz SERVER-B\RED verbinden kann. Ich bin sehr verwirrt, warum ich zu diesem Zeitpunkt den Fehler erhalte. Die Endpunkte auf beiden Seiten werden in sys.tcp_endpoints und sys.endpoints als gestartet aufgeführt.

Ein weiterer interessanter Hinweis ist, dassVorBeim Versuch von Schritt 2 kann ich eine Telnet-Verbindung von SERVER-A zu SERVER-B über 5022 und von SERVER-B zu SERVER-A über 5022 herstellen. Nachdem Schritt 2 jedoch fehlgeschlagen ist, kann ich keine Telnet-Verbindung mehr in beide Richtungen herstellen. TCPDUMP zeigt den Datenverkehr von einem zum anderen an, aber nachdem Schritt 2 fehlgeschlagen ist, gibt es keinen Rückverkehr.

Das Hauptproblem für mich besteht darin, dass dieser Fehler die falsche Beschreibung für das zu haben scheint, was tatsächlich passiert, da die Netzwerkadresse eindeutig existiert und erreicht werden kann und die Endpunkte ebenfalls betriebsbereit sind (zumindest bis der Vorgang fehlschlägt [Rolleyes]). Ich habe auch versucht, die Konfiguration in die entgegengesetzte Richtung durchzuführen (indem ich eine vollständige Sicherung/Wiederherstellung ohne Recovery usw. in die andere Richtung durchgeführt habe) und es schlägt auf genau dieselbe Weise fehl und liefert dieselben Fehler, aber wieder wird der gesamte Datenverkehr durch die Firewall angezeigt.

Zuletzt erhalte ich in SQL-Protokollen auch den Fehler „Fehler: 1443, Schweregrad: 16, Status: 2.“ Das scheint direkt damit zusammenzuhängen, und einiges von dem, was ich online gefunden habe, deutet auf ein Problem mit der Windows-Authentifizierung hin, das sollte jedoch nicht der Fall sein, da meine Endpunkte mit Zertifikaten konfiguriert sind.

Für jede Hilfe wäre ich sehr dankbar.

Hier ist das eigentliche T-SQL, das für die Einrichtung verwendet wurde und dem Inhalt des BOL-Artikels folgt.

--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

Antwort1

Verbinden Sie Profiler mit beiden Instanzen (alle drei, wenn es einen Zeugen gibt) und überwachen Sie die EreignisseAudit Database Mirroring Login-EreignisklasseUndBroker:Connection-Ereignisklasse.

Der Fehler 1418 besagt lediglich, dass die Spiegelungssitzung innerhalb eines bestimmten Timeouts aus irgendeinem Grund nicht betriebsbereit war. Wenn Sie ALTER DATABASE ... SET PARTNER = 'tcp://..' auf dem Principal ausführen, stellt dieser eine Verbindung zum Mirror her.UndDer Spiegel wird sich als Antwort mit dem Hauptserver verbinden. Das bedeutet, dass sowohl der Haupt-Partnerwert als auch der Spiegel-Partnerwert, die zuvor festgelegt wurden, ins Spiel kommen. Beide müssen korrekt sein und die zugrunde liegende Infrastruktur (Routing, DNS, IPSEC, Firewalls) muss eine Verbindung zur gewünschten Adresse/zum gewünschten Port zulassen.beidePartner. Wenn Sie den Zeugen hinzuziehen (falls Sie einen haben), haben Sie einen ziemlich komplexen Wirrwarr an TCP-Konnektivität, der überprüft werden muss.

Wenn das Problem die Zertifikatsicherheit ist, wird das Ereignis „Audit Database Mirroring Login“ die Ursache und das Problem klar angeben (Zertifikat ungültig, abgelaufen, falsches Zertifikat verwendet usw. usw.). Wenn das Problem die zugrunde liegende TCP-Struktur ist (Routing, DNS, IPSEC, Firewall usw.), wird das Problem tatsächlich im Ereignis „Broker:Connection“ angezeigt.

Wenn Sie genau verstehen möchten, wie die zertifikatsbasierte Authentifizierung funktioniert, lesen Sie weiter unterWie funktioniert die zertifikatsbasierte Authentifizierung?.

verwandte Informationen