Самоучитель системного администратора. 5-е изд
жүктеу/скачать 20,51 Mb. Pdf көрінісі
|
Cамоучитель системного администратора книга
Глава 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-структуры на другой сервер, можно просто скопировать файлы по новому пути и заменить ссылку со |