Зеркальное отображение базы данных 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 фактически покажет проблему.
Если вы хотите точно понять, как работает аутентификация на основе сертификатов, читайте в разделе Как работает аутентификация на основе сертификатов.