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

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

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

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

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

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

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

  IMPORTANT: Если в сети присутствует лишь один сервер, то, скорее всего, поддерживаться будет только одна копия раздела [Root], поскольку инфраструктура сети не требует этого.

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

  NOTE: Репликация разделов не обеспечивает отказоустойчивость для файловой системы. Реплицируется только информация об объектах Каталога. Для обеспечения отказоустойчивости для файлов, следует провести зеркальное отражение либо дуплексирование жестких дисков, а также активизировать функцию Transaction Tracking System^TM (TTS^TM).

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

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

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

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

• Главная реплика. Главная реплика - это записываемая реплика, содержащая всю информацию об объектах раздела. Все операции с разделами (создание, объединение, перемещение, удаление) производятся с главной репликой раздела.
  Для каждого раздела может быть определена только одна главная реплика.
• Реплика для чтения и записи. Реплика для чтения и записи содержит ту же информацию об объектах, что и главная реплика. Она допускает модификацию (запись), если главная реплика раздела уже определена где-то еще в другом месте.
  Реплик для чтения и записи может быть сколько угодно.
  Клиентские рабочие станции могут обновлять только главные реплики и реплики для чтения и записи.
• Реплика только для чтения. Реплика только для чтения содержит ту же информацию об объектах, что и раздел, но эту информацию можно только считывать. Она используется тогда, когда необходимо чтение раздела, но запись в раздел при этом происходить не должна.

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

  По умолчанию программа инсталляции NetWare 4 копирует реплику для чтения и записи раздела, где производилось обновление сервера Bindery.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Если вы производите на сервере обновление NetWare 3^TM до NetWare 4, на этом сервере размещается реплика, позволяющая поддерживать сервис Bindery для максимум трех серверов в данном разделе.
• Если в дереве присутствует меньше трех реплик данного раздела, на данном сервере следует разместить реплику для обеспечения отказоустойчивости и возможностей восстановления после разрушения сети.

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

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

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

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

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

• Создавайте для каждого раздела не меньше трех реплик.
• Для раздела [Root] следует создать не меньше трех реплик (этот раздел требуется для поддержания целостности дерева). Программа инсталляции сервера автоматически создает одну реплику раздела [Root]. Остальные реплики нужно создавать вручную.
• Поддерживайте производительность сети, размещая реплики на сервере, к которому обращаются пользователи (на той же территории).
• В случае необходимости создавайте реплики для сервиса Bindery.
• Учитывайте требования обеспечения высокой производительности доступа к NDS, например, использования технологии обхода дерева и расположения разделов и реплик близко к пользователям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

• Сформированы ли разделы верхнего уровня с учетом границ контейнеров Подразделение, представляющих размещение или организационную структуру?
• Содержат ли разделы только объекты, относящиеся к одному территориальному пункту, или включают в себя высокоскоростные каналы глобальной сети (T1 или лучше)?
• Содержат ли разделы менее 1000 объектов?
• Размещены ли разделы поблизости от объектов (обычно объектов Пользователь), использующих ресурсы, которые содержатся в разделе?
• Сгруппированы ли в один раздел серверы, физически находящиеся в одном кабельном сегменте?
• Имеется ли для каждого раздела не менее трех реплик?
• Существуют ли реплики для поддержки сервиса Bindery?
• Расположены ли реплики на серверах таким образом, чтобы отвечать требованиям повышения производительности NDS, обеспечивая, например, технологию обхода дерева и размещение разделов и реплик поблизости от пользователей?

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

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

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

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

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