|
Глава 10
зеркалирование можно настроить в разных режимах. Так, в режиме
актив-
ный/пассивный
изменения могут вноситься только на первом сервере, а на вто-
ром содержится лишь копия данных. В режиме
активный/активный
изменения
можно вносить на каждом сервере.
Основной сервер пересылает на вспомогательный сервер
журнал транзакций
—
журнал, в который вносятся изменения в данных. Второй сервер обрабатывает
журнал и вносит изменения в свою копию данных. Поэтому можно говорить об
асинхронном характере передачи данных.
Операции по изменению данных могут накапливаться по мере изменения базы дан-
ных и не вноситься на второй сервер, например, из-за сбоя сети. В итоге второй
сервер может гарантировать идентичность данных только при нормальном функ-
ционировании обоих серверов и сети передачи данных. Именно поэтому админист-
ратор обязан постоянно контролировать состояние репликации данных.
Ранее было отмечено, что репликация может быть настроена в двух вариантах: ак-
тивный/активный и активный/пассивный. Вариант активный/пассивный — это про-
стейший случай, когда данные могут меняться только на одном сервере. Обычно
с таким способом репликации никаких проблем нет.
Но если нужно настроить репликацию в обе стороны, и изменения возможны на
обоих серверах, неизбежны конфликты. Например, изменения на одном сервере
могут противоречить изменениям на другом: пусть на одном сервере значение А
равно 100, а на другом — 200. Какое из этих двух значений считать правильным и
включить в окончательный вариант БД? Именно поэтому настройку двухсторонней
репликации должен выполнять подготовленный администратор баз данных, кото-
рый хорошо представляет внутреннюю структуру системы и обрабатываемых дан-
ных.
Сама настройка зеркалирования не представляет сложности — вам нужно предва-
рительно сделать полную копию данных и включить режим восстановления
Full
.
После этого один из серверов назначается
издателем
(publisher) — это главный
сервер. А все остальные, которые будут копировать с него данные, будут называть-
ся
подписчиками
(subscribers). После настройки репликации надо обязательно про-
верить ход ее выполнения в системных журналах.
Снимки баз данных
Многие серверы SQL позволяют создавать
снимки данных
(snapshot) — они часто
используются при первичном копировании данных на второй сервер. Эта операция
выполняется средствами администрирования сервера, и мы не будем на ней акцен-
тировать ваше внимание.
Настройка клиентских подключений
Обычно прикладные программы настраиваются на подключение к одному серверу
баз данных. Поэтому, в случае отказа основного сервера БД, приложение не может
автоматически переключиться на второй сервер, где размещена копия БД, и поль-
зователь получит сообщение об ошибке, исправить которую можно лишь отредак-
Отказоустойчивая информационная система
509
тировав строку с именем сервера в настройках программы. Конечно, это выход, но
хотелось бы выполнить перенастройку программы без привлечения лишнего вни-
мания пользователя.
Чтобы программа могла автоматически переключаться на другой сервер, она долж-
на быть соответствующим образом настроена. Если программа для доступа к дан-
ным использует клиенты Native client или ADO.NET, то задать сервер с копией
данных можно так:
"Server=server1; Failover_Partner=server2; Database=office"
Распределенная файловая система
В Windows для подключения к общим сетевым ресурсам используется следующий
формат адреса:
//имя_сервера/имя_ресурса
. Понятно, что при выходе из строя
сервера сетевой ресурс, заданный с помощью такого адреса, станет недоступным.
Исключить одну такую точку отказа позволяет
распределенная файловая система
(Distributed File System, DFS), реализованная на серверах Windows 2000 и старше.
Распределенная файловая система также упрощает и администрирование
—
вы можете прозрачно для пользователей перемещать совместно используемые фай-
ловые ресурсы с одного компьютера на другой без прекращения обслуживания и
перенастройки рабочих станций.
Для Linux-систем на сегодняшний день, к сожалению, нет выделенного стандарт-
ного решения. Что-то наподобие DFS можно реализовать средствами NFS,
automount и LDAP/NDIS, но все это сложно и не очень гибко. Можно использовать
также файловые системы XtreemFS, GlusterFS, GFS (Google File System), GPFS
(General Parallel File System), Lustre и др. — это неплохие решения, но все равно
немного не то, хотя и лучше, чем вообще ничего. Информацию о настройке этих
файловых систем вы с легкостью найдете в Интернете.
Создание DFS
Структура распределенной файловой системы чем-то похожа на дерево каталогов.
В корне дерева расположена точка входа, называемая
корнем DFS
. Структура DFS-
домена хранится в службе каталогов (AD). А сам корень DFS — это набор ссылок
на совместно используемые ресурсы, которые находятся на разных компьютерах
сети.
Создается корень DFS средствами Windows Server 20
xx
. В одном домене может
поддерживаться несколько корней DFS, на обычных же серверах допускается на-
личие только одного DFS-корня. В роли корня DFS может выступать любая совме-
стно используемая папка. В этой папке не должны храниться файлы, а только ссыл-
ки на сетевые ресурсы.
После создания корня нужно собрать структуру папок DFS. Для этого используется
оснастка управления
DFSGUI.MSC
(рис. 10.1).
Если администратору сети нужно переместить ресурс из DFS-структуры на другой
сервер, можно просто скопировать файлы по новому пути и заменить ссылку со
510
Do'stlaringiz bilan baham: |
