Полезная информация

Server for Information Technologies
Сервер поддерживается
Центром Информационных Технологий
(095) 932-9212, 932-9213, 939-0783
E-mail: info@citforum.ru
Сервер Информационных Технологий содержит море(!) аналитической информации

Определение эффективной стратегии размещения реплик

Определение максимально эффективной стратегии размещения реплик позволяет оптимизировать для базы данных Каталога ее отказоустойчивость, возможности доступа и простоту перемещения. Для этого следует ознакомиться с некоторыми из основных характеристик реплик.

Характеристики реплик

Реплика в своей основе является физической копией раздела. На любом сервере NetWare 4 в сети может храниться неограниченное число реплик каждого раздела. К тому же на одном сервере NetWare 4 может храниться несколько реплик, если эти реплики были созданы для уникальных разделов.

Основные функции реплик

Реплики обеспечивают для сети следующие три функции.

Идентификация четырех типов реплик

Имеется четыре типа реплик.

Сетевые ресурсы хранятся в главных репликах, репликах для чтения и записи и репликах только для чтения. Реплики только для чтения имеют ограниченный диапазон применения и обычно не используются. Реплики подчиненной ссылки создаются и размещаются автоматически и служат для связывания между собой разделов дерева.

Определение процесса обновления и синхронизации реплик

При внесении изменений в объекты, расположенные в разделе, информация об этих изменениях автоматически передается во все остальные реплики этого раздела. Это обеспечивает согласование глобальной базы данных Каталога. Репликам передаются только изменения в данных. Например, если пользователь меняет номер телефона, передается только новый номер телефона, а не весь объект Пользователь.

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

База данных NDS является "не совсем согласованной" базой данных. При появлении изменений не все реплики раздела в каждый данный момент времени содержат полностью совпадающую информацию. На практике содержимое реплик в любой конкретный момент времени будет, скорее всего, немного различным. Однако по мере передачи информации об изменениях всем репликам, эти реплики будут стремиться к достижению некоторого согласованного состояния.

Некоторые изменения, например, изменения пользовательского пароля, передаются всем репликам немедленно. Менее критичные изменения, например, время последней регистрации пользователя, перед посылкой в сеть накапливаются локально в течение некоторого небольшого промежутка времени.

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

При решении проблемы синхронизации следует учитывать три атрибута.

Атрибут Описание
Указатель репликиКаждый раздел содержит запись о расположении всех своих реплик. Эта информация хранится в свойстве реплики раздела, по одному элементу свойства на каждую реплику раздела. Набор указателей реплик разделов создает список реплик раздела, иногда называемый кольцом реплик или списком реплик.
Синхронизировано доКаждая реплика в списке реплик раздела поддерживает список временных меток. Сервер, содержащий некоторую реплику, использует этот атрибут для определения состояния синхронизации реплики в сравнении с другими репликами, входящими в список. Этот атрибут иногда называется вектором временных меток.
Наследуемый список управления доступом (ACL)Корневой объект раздела отвечает за определение прав доступа, наследуемых им самим от объекта [Root]. Этот атрибут является прежде всего сводным списком ACL для всех объектов раздела.

Планирование размещения реплик

При инсталляции первого сервера дерева Каталогов на этом сервере размещается первая реплика раздела [Root]. Первый сервер содержит главную реплику раздела [Root].

Для этого сервера не существует специальных прав или соглашений. При наличии в дереве других серверов реплику раздела [Root] в любой момент можно удалить или превратить в реплику для чтения и записи.

На следующем рисунке показано, как можно осуществить репликацию раздела [Root] в сети.

Figure 6-2. Пример размещения раздела [Root]

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

Во всех остальных случаях, если на сервере необходимо разместить реплику, ее следует добавлять вручную.

На следующем рисунке показано, как можно разместить реплики на сервере в дереве Каталога.

Figure 6-3. Пример размещения реплики

Размещение реплик

В большинстве случаев реплики следует размещать в соответствии с требованиями обеспечения отказоустойчивости, доступности и простоты перемещения. Воспользуйтесь следующими рекомендациями.

Размещение реплик для повышения отказоустойчивости

Для каждого раздела следует создавать не меньше трех реплик. В зависимости от уровня производительности или топологии сети может возникнуть необходимость в создании большего числа реплик.

Разместите по меньшей мере одну копию каждой реплики вне локальной территории вашего офиса, например в другом здании. Число мест, в которых будут размещены реплики, определяется планом восстановления сети после катастрофических сбоев, принятым в вашей организации. Используя реплики разделов, можно восстановить большую часть сети.

Убедитесь, что реплики подчиненных ссылок не используются для обеспечения отказоустойчивости - они могут быть использованы при восстановлении структуры дерева, но не конечных объектов.

Размещение реплик для обеспечения доступа

Разместите реплики в наиболее доступных местах. Например, если группам пользователей из разных контейнеров требуется доступ к определенному объекту, находящемуся в другом разделе, следует поместить реплику на сервер, находящийся в контейнере, расположенном на уровень выше контейнеров, содержащих эти группы.

Размещение реплик для облегчения перемещения

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

Размещайте реплики на сервере, где содержатся личные каталоги пользователей, к которым необходим доступ. На локальных серверах, к которым пользователи получают доступ, также следует размещать реплики объектов Каталога, находящихся на противоположных концах канала глобальной сети.

Размещение реплик для администрирования

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

Размещение реплик для сервиса Bindery

Сервис Bindery активизируется при инсталляции. Он также автоматически активизируется, если вы производите обновление сервера из NetWare 2 или NetWare 3.

Если сервис Bindery активизирован, сервер получает реплику для чтения и записи для максимум трех разделов, содержащих объект-контейнер в контексте Bindery.

Для поддержки сервиса Bindery воспользуйтесь следующими рекомендациями.

  1. Определите все контейнеры, содержащие ресурсы Bindery, и запишите их контекст (он называется контекстом Bindery).
  2. Определите разделы, содержащие контейнеры с ресурсами Bindery.
  3. Поместите на сервер реплики для чтения/записи этих разделов.

Размещение реплик на серверах

Размещайте на сервере минимально возможное количество реплик.

Размещайте реплики на лучших серверах сети. Медленные серверы могут повлиять на синхронизацию реплик на всех серверах в кольце реплик. (Кольцом реплик называется группа серверов, содержащих реплики одного и того же раздела).

Создание матрицы репликации

Вам следует создать для сети матрицу репликации. Для организации физического размещения реплик для каждого раздела воспользуйтесь приведенной ниже таблицей. Для повышения отказоустойчивости рекомендуется создавать по три реплики каждого раздела, но, в зависимости от требований обеспечения пользовательского доступа, может потребоваться большее количество реплик. Чтобы получить дополнительную информацию, см. "Примеры шаблонов проектной документации".

Резюме

Создание разделов и размещение реплик позволяет вам масштабировать дерево Каталога в соответствии с потребностями организации. Этот процесс может оказаться очень простым, если будет состоять лишь в принятии значений по умолчанию, или же сложным, связанным с разработкой разделов и матрицы размещения реплик для определения размещения разделов и реплик в большом количестве пунктов.

В приведенной ниже таблице перечислены основные правила, которых следует придерживаться при разделении дерева Каталога.

Условие Рекомендации
Размещение
  • В сетях, содержащих каналы глобальной сети, не следует создавать разделы, включающие в себя несколько территориальных пунктов
  • Создавайте разделы вокруг близлежащих серверов (физически удаленные друг от друга серверы следует помещать в разные разделы)
  • В верхней части дерева размещайте меньше разделов, а в нижней части - больше
Размер
  • Поддерживайте разделы небольшого размера
  • Раздел [Root] должен быть небольшим
  • Как правило, в раздел должно входить меньше 1000 объектов, и ни в коем случае не больше 3500.
  • Как правило, раздел должен иметь не больше десяти-пятнадцати подчиненных разделов, и ни в коем случае не больше сорока.

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

Условие Рекомендации
Размещение
  • Производите репликацию локально, а не через каналы глобальной сети. (При репликации через канал глобальной сети приходится передавать/принимать информацию о синхронизации NDS, что может снизить скорость передачи трафика по каналу глобальной сети).
  • При наличии возможности, располагайте главные реплики физически близко к главным репликам родительских и дочерних разделов.
Количество
  • Всегда храните две или три реплики раздела, но не больше десяти.
  • Размещайте на сервере не более десяти реплик.

Оценка полученных результатов

Завершив разработку стратегии создания разделов, сверьтесь с приведенными ниже вопросами, которые помогут вам оценить эффективность этой стратегии.

Значения по умолчанию

Ниже приводятся значения по умолчанию для разделения и репликации.

Тип реплики Значение по умолчанию
ГлавнаяПервый сервер NetWare 4 в сети получает главную реплику раздела [Root].
Первый сервер в разделе получает главную реплику этого раздела.
Для чтения и записиНовые серверы. Второй и третий сервер в разделе получают реплики этого раздела для чтения и записи. Остальные серверы не получают реплик, если только при инсталляции не был активизирован сервис Bindery.
Если на новом сервере активизирован сервис Bindery, сервер получает реплику для чтения и записи для максимум трех разделов, в контексте Bindery которых присутствует объект-контейнер.
Обновленный сервер. Сервер, где было произведено обновление из NetWare 2 или NetWare 3, получает реплику для чтения и записи для максимум трех разделов, в контексте Bindery которых присутствует объект-контейнер.
Примечание: Сервис Bindery активизируется при инсталляции. Если производится обновление сервера из NetWare 2 или NetWare 3, она активизируется автоматически.
Только для чтенияНет
Подчиненная ссылкаРеплики подчиненных ссылок создаются и размещаются автоматически, и служат для связывания разделов дерева друг с другом.

К какому разделу следует перейти

Чтобы Перейдите к
Спланировать подход для обеспечения согласованности сетевого времени для серверов и клиентов сети Глава 5 "Планирование стратегии синхронизации времени"
Создать эффективный план обеспечения доступа и использования сетевых ресурсов Глава 6, "Создание плана доступа"
Разработать стратегию обеспечения эффективного управления сетевыми приложениями. Глава 8 "Разработка стратегии управления приложениями"
Разработать стратегию миграции для серверов и рабочих станций, работающих под предыдущей версией NetWare или другой сетевой операционной системойГлава 9 "Разработка стратегии миграции"
Создание графика внедрения Глава 10 "Создание графика внедрения"

Назад | Содержание | Вперед


Comments: info@citmgu.ru
Copyright © CIT