Зеркальное отображение базы данных SQL 2008 по каналу WAN с сертификатами

Я настраиваю зеркальное отображение базы данных по каналу WAN между двумя именованными экземплярами SQL 2008, хост-серверы которых не являются членами домена, с использованием сертификатов для проверки подлинности. После многих попыток заставить это работать самостоятельно, я начал с нуля и пошёл шаг за шагом согласно BOL http://technet.microsoft.com/en-us/library/ms191140.aspx, однако проблема, которую я пытался решить все еще присутствует.

Проблема заключается в наборе заключительных шагов, который устанавливает статус партнера на каждом сервере. Когда я выполняю шаг № 2, чтобы установить статус партнера на "HOST_A", я получаю следующую ошибку:

Сообщение 1418, уровень 16, состояние 1, строка 2

Сетевой адрес сервера "TCP://server-b.our-domain.com:5022" не может быть достигнут или не существует. Проверьте имя сетевого адреса и убедитесь, что порты для локальной и удаленной конечных точек работают.

Интересно, однако, что я могу видеть трафик на межсетевом экране (TCPDUMP), идущий взад-вперед между двумя серверами в течение примерно 15 секунд, прежде чем эта ошибка снова наплевает на меня.

На данный момент я не уверен, что делать дальше, потому что я могу подключиться к экземпляру SERVER-A\BLUE из SSMS на SERVER-B, и я могу без проблем подключиться к экземпляру SERVER-B\RED из SSMS на SERVER-A. Я очень смущен, почему я получаю ошибку в данный момент времени. Конечные точки с обеих сторон перечислены как запущенные в sys.tcp_endpoints и sys.endpoints.

Еще одно интересное замечание: перед выполнением шага 2 я могу подключиться к серверу от SERVER-A до SERVER-B через 5022 и от SERVER-B до SERVER-A через 5022, однако после сбоя шага 2 я больше не могу telnet в любом направлении. TCPDUMP покажет трафик, идущий от одного к другому, но обратного трафика не будет после шага 2.

Основная проблема для меня заключается в том, что эта ошибка, по-видимому, имеет неправильное описание того, что на самом деле происходит, поскольку ясно, что сетевой адрес существует и может быть достигнут, и конечные точки также работают (по крайней мере, до тех пор, пока операция не завершится [Rolleyes]). также попытался выполнить конфигурацию в противоположном направлении (полное резервное копирование / восстановление без восстановления и т. д. в другом направлении), и он не может работать точно так же, предоставляя те же ошибки, но снова со всем трафиком, отображаемым на межсетевом экране.

Наконец, в журналах SQL я также получаю сообщение об ошибке "Ошибка: 1443, уровень серьезности: 16, состояние: 2". Который, кажется, имеет прямое отношение, и кое-что из того, что я нашел в Интернете, предлагает проблему с аутентификацией Windows, однако это не должно иметь место, так как мои конечные точки настроены с сертификатами.

Любая помощь с этим будет принята с благодарностью.

Вот фактический T-SQL, используемый для настройки этого, который следует за тем, что находится в статье 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

1 ответ

Решение

Присоедините Profiler к обоим экземплярам (всем трем, если есть свидетель) и следите за событиями. Класс событий входа в систему зеркального отображения базы данных аудита и посредник: класс событий подключения.

Ошибка 1418 просто говорит, что в течение определенного времени сеанс mirroirng не был запущен по какой-либо причине. Когда вы запускаете команду ALTER DATABASE ... SET PARTNER = 'tcp://..' на принципале, принципал подключается к зеркалу, а зеркало в ответ подключается к принципалу. Это означает, что как значение основного партнера, так и значение зеркального партнера, установленные ранее, входят в картину, и они оба должны быть правильными, а базовая инфраструктура (маршрутизация, DNS, IPSEC, брандмауэры) должна устанавливать соединение на нужный адрес: порт от обоих партнеров. Добавьте свидетеля, если он у вас есть, и у вас получился довольно сложный шарик связи TCP, который необходимо проверить.

Если проблема заключается в безопасности сертификата, то в событии Audit Database Mirroring Login будет четко указана причина и проблема (сертификат недействителен, срок его действия истек, использовался неверный сертификат и т. Д.) Если проблема связана с фабрикой TCP (маршрутизация, DNS, IPSEC, брандмауэр и т. Д.), То событие Broker:Connection фактически покажет проблему.

Если вы хотите точно понять, как работает аутентификация на основе сертификатов, читайте в разделе Как работает аутентификация на основе сертификатов.

Другие вопросы по тегам