Данная статья продолжает цикл, начатый в предыдущих номерах "Компьютер-Информ" (яя 2, 3). Мы уже говорили об архитектуре клиент-сервер и в общих чертах о продукте фирмы Microsoft - SQL Server 6.5. Сегодня рассмотрим вопрос о построении распределенной информационной системы на базе этого продукта. Подразумевается, что читатель обладает базовыми знаниями об архитектуре клиент-сервер.
Сразу же стоит определить класс систем, о которых пойдет речь. Мы будем называть распределенной систему, в которой функционирует более одного сервера баз данных. Причины, по которым имеет смысл хранить и обрабатывать данные на разных серверах, могут быть различными. Наиболее частые - необходимость уменьшить нагрузку на сервер и обеспечить работу территориально удаленных подразделений, связанных медленными и не очень надежными каналами связи.
Для того, чтобы обеспечить работу всех пользователей в едином информационном пространстве, необходимо решить задачу согласования данных на различных серверах. Решать эту задачу можно по-разному. За согласование может отвечать любой слой многослойного приложения - клиентское приложение или промежуточный слой бизнес-объектов (если он есть). В большинстве случаев наиболее целесообразной, однако, является реализация согласования данных путем непосредственного взаимодействия серверов баз данных. При таком способе клиентские приложения могут "забыть" о распределенной структуре данных и работать только с одним сервером. Кроме того, взаимодействие на уровне серверов баз данных является, как правило, более эффективным с точки зрения быстродействия и надежности.
Итак, рассмотрим средства, которые Microsoft SQL Server 6.5 предоставляет для организации распределенной информационной системы.
Основное средство взаимодействия двух SQL-серверов - это удаленные хранимые процедуры. Запрос или хранимая процедура, выполняемые на одном сервере, могут включать вызов процедуры, хранящейся на другом сервере. Другого способа непосредственного межсерверного взаимодействия не существует - один сервер не может напрямую обратиться к данным другого сервера при помощи операторов языка SQL (эта возможность появится в будущих версиях). Для того, чтобы один сервер мог вызывать процедуры другого, необходимо эти серверы "познакомить", т.е. определенным образом зарегистрировать. Делается это достаточно просто при помощи административного средства SQL Enterprise Manager. Как удаленные хранимые процедуры можно использовать, мы увидим в следующих разделах.
Предположим, в центральном отделении некой фирмы есть торговый зал (со своим небольшим складом) и главный склад. Оба подразделения охвачены автоматизированной системой, при этом в каждом из них функционирует свой SQL Server. В нашем примере наличие двух серверов будет оправдано, когда нагрузка на них достаточно высока, но большинство запросов затрагивает данные только одного, локального, сервера. Однако могут существовать ситуации, когда нужно модифицировать данные сразу на двух серверах.
Например, при выписке счета продавец в торговом зале делает отметку о резервировании товара на главном складе, если на складе торгового зала данный товар отсутствует. Соответственно, нужно обновить данные в рамках одной транзакции (выписка счета) одновременно на двух серверах - главного склада и торгового зала. Microsoft SQL Server 6.5 позволяет сделать это очень просто - при помощи менеджера распределенных транзакций DTC (Distributed Transaction Coordinator).
Всю непростую работу по согласованию изменений на двух серверах DTC берет на себя, используя общепринятый протокол двухфазной фиксации. Разработчик прикладной системы должен только объединить в распределенную транзакцию (при помощи команды BEGIN DISTRIBUTED TRANSACTION) изменения, производимые на локальном сервере (в данном случае на сервере торгового зала) и на удаленном сервере (сервере склада). Изменения локальных данных производятся при помощи обычных команд UPDATE или INSERT, а изменения данных на удаленном сервере - при помощи вызовов удаленных хранимых процедур (см. рис).
В предыдущем примере необходимо было обеспечить жесткую синхронизацию данных на двух серверах, и условия позволяли это сделать. Но существуют также ситуации, когда жесткая синхронизация в реальном времени и необязательна по условиям бизнес-процесса, и невозможна в силу, например, низкого качества линий связи. В этом случае уместно применить технологию тиражирования данных.
Например, если фирма ведет торговлю из нескольких удаленных офисов, а поставки осуществляет с центрального склада, на котором имеется достаточный запас товаров, то задачу синхронизации данных можно решить, организовав тиражирование выписанных счетов из филиалов в центральный склад с периодичностью один раз в сутки (или реже или чаще - в зависимости от требований бизнес-процесса).
Тиражирование может быть и двунаправленным - например, из центрального офиса в удаленные могут тиражироваться прайс-листы.
Тиражирование обеспечивает асинхронное согласование данных, которое устойчиво к временным потерям связи между серверами.
Преимущество такой "асинхронности" заключается также в возможности маневра - вы можете инициировать собственно процесс тиражирования в часы, когда серверы не загружены, а стоимость использования дорогих каналов связи - минимальна.
Средства, обеспечивающие тиражирование, входят в поставку SQL Server.
Что делать, если данные хранятся на разных серверах, а их требуется объединить в одном отчете? Можно построить распределенную выборку, используя механизм "подкачки данных". Для этого нужно вызвать удаленную процедуру, возвращающую необходимый набор данных с удаленного сервера, и вставить их в служебную таблицу на локальном сервере (что и является, собственно, подкачкой данных). А уже имея необходимые данные в локальных таблицах, можно строить сводный отчет.
"Подкачку данных" можно также использовать для синхронизации данных, хранящихся на разных серверах. Этот способ, на наш взгляд, более прост, чем тиражирование и распределенные транзакции, хотя и не обеспечивает всех их преимуществ.
Хотя тиражирование, как было сказано выше, устойчиво к временным потерям связи, оно нуждается в том, чтобы серверы, пусть на короткое время, но были "в зоне прямой видимости" друг друга. Что же делать, если по техническим причинам это невозможно? На помощь может прийти электронная почта. Ее можно использовать как асинхронный транспортный механизм, соединяющий удаленные SQL-серверы.
Например, в нашей фирме появился иногородний филиал, с которым нет прямого сетевого соединения, но организована доставка сообщений Microsoft Exchange по телефонным линиям или через Internet. Используя встроенные в SQL Server средства работы с Microsoft Exchange, мы можем организовать автоматический обмен данными между серверами по почте.
Разумеется, "почтовые" возможности SQL Server можно использовать и в других целях, например, для организации службы ответов на поисковые запросы по почте или для автоматической рассылки писем определенным лицам SQL-сервером при наступлении определенных событий в базе данных.
Когда в системе имеется несколько серверов, находящихся, например, на разных этажах большого здания, а то и в разных концах города, возникает вопрос: "Кто будет это хозяйство администрировать?". Если бы пришлось иметь по администратору на каждый сервер или одному администратору непрерывно разъезжать между разными офисами - это было бы слишком накладно. К счастью, (если, конечно, в этом может заключаться счастье) средства администрирования, входящие в состав Microsoft SQL Server, дают возможность избежать повышенных расходов на администрирование.
Во-первых, основное средство администратора - SQL Enterprise Manager позволяет работать со всеми серверами в сети, причем, делать это можно даже из дома, используя механизм удаленного доступа Windows 95.
Во-вторых, механизмы поддержки работы по расписанию и реакции на события позволяют администратору автоматизировать большую часть работ по обслуживанию баз данных. Эти работы, например, резервное копирование, будут выполняться без какого-либо вмешательства администратора, а о результатах их выполнения он может получать сообщения по электронной почте.