Сетевое взаимодействие серверов

Для успешного сетевого взаимодействия двух серверов с использованием удаленного вызова процедур (Remote Procedure Calls, RPC) — когда каждый из серверов запускает RPC-процедуры на машине другого сервера — нужна тщательная разработка их конфигурации. В этом разделе рассматриваются основные этапы этого процесса и покажем читателю, как можно проверить текущее состояние сетевого взаимодействия между серверами.

Прежде всего, конфигурация каждого из серверов должна разрешать удаленный доступ к этому серверу. Это достигается установкой соответствующего конфигурационного параметра, например, командой sp_configure “remote access”, 1.

Во-вторых, файл интерфейсов каждого сервера должен содержать описание другого сервера.

Здесь окажется полезной единая централизованная серверная версия файла интерфейсов, о которой мы говорили выше. Клиентская версия файла интерфейсов может и не содержать информацию обо всех удаленных серверах. В нее следует включить описание только серверов, непосредственно открытых для пользователей. Если пользователю одного сервера потребуется направить RPC-вызов на другой сервер, это обращение будет направлено через первый сервер, который найдет описание второго сервера в своем файле интерфейсов.

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

Это позволяет запустить на нескольких серверах приложение, в которое жестко встроено имя используемого сервера (например “servernamel”). В таблице sysseruers каждого из серверов внутреннему имени servernamel в качестве внешнего псевдонима присваивается имя самого этого сервера, чтобы заставить приложение обращаться к серверу, работающему на данной локальной машине.

Процесс, описанный выше, происходит при взаимодействии с сервером архивации Backup Server. SQL Server System 10 и System 11 способны создавать и загружать дампы только через сервер архивации. Он представляет собой открытое серверное приложение. Поэтому он выступает по отношению к SQL Server в качестве удаленного сервера. Внутреннее имя сервера архивации SYB_BACKUP жестко встроено в каждый SQL Server.

Это может привести к проблемам, как только в вашей системе появляется второй SQL Server, поскольку каждый SQL Server будет обращаться к серверу архивации по имени SYB_BACKUP. При установке SQL Server и сервера архивации программа sybinit по умолчанию присваивает значение SYB_BACKUP параметрам srvname и srvnetname таблицы sysservers.

При вызове сервера архивации по внутреннему имени (srvname) SYB_BACKUP все серверы баз данных системы определят, что в качестве его сетевого имени (srvnetпате) также указано SYB_BACKUP. Серверы найдут в своих идентичных серверных файлах интерфейсов описание сервера архивации с именем SYB_BACKUP и дружно обратятся к одному и тому же порту одной и той же серверной машины, на которой действительно работает сервер архивации с указанным именем.

Эти операции были бы не нужны, если на каждом сервере имелся бы индивидуальный файл интерфейсов, указывающий на локальную копию сервера архивации SYB_BACKUP.

Мы не раз говорили о преимуществах, которые бы дала единая копия файла интерфейсов, действующая в масштабах всей информационной системы. Реальное решение проблемы дает модификация значений сетевого имени (srvnetname) сервера архивации в таблице sysservers каждого отдельного SQL Server. Именами индивидуальных серверов архивации проще всего выбрать <имя_сервера>_BСК., где в качестве имени_сервера указывается имя соответствующего SQL Server. Теперь при обращении к серверу архивации по внутреннему имени SYBJBACKUP (srvname из таблицы sysservers) SQL Server сопоставит это имя с сетевым именем <имя_сервера>_BСК. (srvnetname из таблицы sysservers).

Под этим именем в общем файле интерфейсов будет найден локальный сервер, работающий на той же самой машине. Важно подчеркнуть, что, изменив внутреннее имя сервера архивации (srvname = SYB_BACKUP), вы не сможете его использовать в работе SQL Server.

В-четвертых, таблица sysremotelogins каждого сервера должна содержать строку, определяющую характер обработки запросов на соединение (remote logins), поступающих со стороны удаленных серверов.

Это означает, что при поступлении на сервер В любого RPC-вызова с сервера А, имеющего то же самое учетное имя, учетная информация пользователей серверов А и В будет сопоставлена. Запрос будет выполнен только при совпадении паролей пользователя на обоих серверах. Несовпадение паролей или отсутствие пользователя сервера А в числе пользователей сервера В приведет к отказу в выполнении RPC-вызова. Подобная схема обработки удаленных запросов является наиболее безопасной, но она требует идентичности списков пользователей на всех серверах. Можно также установить соответствие некоторых пользователей сервера А с другими пользователями сервера

В и задать с помощью процедуры sp_remotelogin режим взаимного доверия между серверами, не требующий совпадения их пользовательских паролей. Администратор баз данных должен знать, какой режим контроля запросов сконфигурирован на каждом из серверов его системы, и насколько надежные гарантии безопасности этот режим предоставляет.

Обратите внимание на то, что каждый удаленный сервер, описанный в таблице sysservers, имеет уникальный идентификатор srvid, соответствующий параметру remoteserverid таблицы sysremotelogins.

Это позволяет установить связь между описанием удаленного сервера в таблице sysservers и уровнем контроля за обращениями, поступающими от этого сервера. В нашем примере сервер А имеет идентификатор srvid = 1 в таблице sysservers. Ему в таблице sysremotelogins соответствует строка с remoteserverid = 1 и рассмотренными выше значениями suid = “1 и status = 0.

В-пятых, локальный SQL Server, инициирующий RPC-вызов, должен обладать собственным внутреннем именем. Оно описано в его таблице sysservers под идентификатором srvid = 0 и выдается командой select @@servername (т.е. результат ее выполнения не должен быть NULL).

Итак; в приведенной выше конфигурации требуется, чтобы каждый пользователь сервера А, обращающийся с RPC-вызовами на удаленный сервер В, имел на этих серверах идентичные системные имена и пароли. Процедура sp_remotelogin позволит изменить или вообще отменить подобные требования.

Для проверки возможности взаимодействия серверов А и В, подключитесь командой isql к серверу А и введите команду execute server В … sp_who. Если ответом будет список пользователей сервера В, значит успешное обращение сервера А к серверу В возможно. Для проверки взаимодействия в противоположном направлении, подключитесь командой isql к серверу В и введите команду execute server A. . .sp_who. Отметим, что имя сервера, указываемое в команде execute перед конструкцией . . . sp_who, зависит от конкретного содержимого таблицы sysseruers каждого сервера.

Другими словами, для того, чтобы команда execute server В … sp_who могла быть выполнена на сервере А, в его таблице sysseruers второй сервер должен быть описан под именем server В. Подчеркнем, что речь идет здесь о внутреннем имени (srvname) сервера В, под которым он известен серверу А. Сетевое имя сервера В, указанное в параметре srvnetname той же таблицы sysseruers, может быть любым. (Если оно позволит серверу А успешно найти нужный удаленный сервер в своем файле интерфейсов.)

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100