Самоучитель системного администратора. 5-е издание

Глава 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