☰

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

tag-icon • tag-icon sql-server sql-server-2008 database-mirroring certificate
Зеркальное отображение базы данных SQL 2008 по каналу WAN с сертификатами

Я настраиваю зеркалирование базы данных по каналу WAN между двумя именованными экземплярами SQL 2008, чьи серверы хостов не являются членами домена, используя сертификаты для аутентификации. После многочисленных попыток заставить это работать самостоятельно я начал с нуля и пошел пошагово в соответствии с BOLhttp://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 я могу подключиться по telnet с 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 просто говорит о том, что в течение определенного тайм-аута сеанс зеркалирования не был запущен и запущен по какой-то причине. Когда вы вводите ALTER DATABASE ... SET PARTNER = 'tcp://..' на основном сервере, основной сервер подключается к зеркалуизеркало подключится к принципалу в ответ. Это означает, что оба значения «партнера» принципала и «партнера» зеркала, установленные ранее, вступают в силу, и оба они должны быть правильными, а базовая инфраструктура (маршрутизация, DNS, IPSEC, брандмауэры) должна разрешить подключение к нужному адресу:порту изобапартнеры. Добавьте свидетеля, если он у вас есть, и вы получите довольно сложный клубок TCP-подключений, который нужно будет проверить.

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

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

Связанный контент