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