Назад | Перейти на главную страницу

Зеркальное отображение базы данных 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, я могу подключиться по telnet от SERVER-A к SERVER-B через 5022 и от SERVER-B к SERVER-A через 5022, однако после сбоя шага 2 я больше не могу подключиться к любому из направлений. 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

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

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

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

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