Цели и задачи
Для сети следует определить стратегию создания разделов, сформировав границы разделов и эффективно разместив реплики.
Для определения границ разделов и типов реплик, которые следует хранить на серверах сети, воспользуйтесь картами ресурсов, картами размещений, картами топологии локальных и глобальных сетей, структурой дерева Каталога и рекомендациями по созданию разделов.
Характеристики реплик
Реплика в своей основе является физической копией раздела. На любом сервере NetWare 4 в сети может храниться неограниченное число реплик каждого раздела. К тому же на одном сервере NetWare 4 может храниться несколько реплик, если эти реплики были созданы для уникальных разделов.
Идентификация четырех типов реплик
Имеется четыре типа реплик.
Главная реплика. Главная реплика - это записываемая реплика, содержащая всю информацию об объектах раздела. Все операции с разделами (создание, объединение, перемещение, удаление) производятся с главной репликой раздела.
Для каждого раздела может быть определена только одна главная реплика. Реплика для чтения и записи. Реплика для чтения и записи содержит ту же информацию об объектах, что и главная реплика. Она допускает модификацию (запись), если главная реплика раздела уже определена где-то еще в другом месте.
Реплик для чтения и записи может быть сколько угодно.
Клиентские рабочие станции могут обновлять только главные реплики и реплики для чтения и записи. Реплика только для чтения. Реплика только для чтения содержит ту же информацию об объектах, что и раздел, но эту информацию можно только считывать. Она используется тогда, когда необходимо чтение раздела, но запись в раздел при этом происходить не должна.
NOTE: Реплика только для чтения не может использоваться на сервере, где требуется сервис Bindery, потому что для сервиса Bindery требуется записываемая реплика. Если сервис Bindery установлен, используйте либо главную реплику, либо реплику для чтения и записи.
По умолчанию программа инсталляции NetWare 4 копирует реплику для чтения и записи раздела, где производилось обновление сервера Bindery.
Реплика подчиненной ссылки. Реплика подчиненной ссылки не может модифицироваться пользователями. Она автоматически помещается NDS на сервер, если родительский раздел имеет на этом сервере главную реплику, реплику для чтения и записи или реплику только для чтения, а дочерняя реплика на этом сервере отсутствует.
При создании на сервере реплики для чтения и записи или реплики только для чтения для дочернего раздела реплика подчиненной ссылки удаляется.
Сетевые ресурсы хранятся в главных репликах, репликах для чтения и записи и репликах только для чтения. Реплики только для чтения имеют ограниченный диапазон применения и обычно не используются. Реплики подчиненной ссылки создаются и размещаются автоматически и служат для связывания между собой разделов дерева.
| Спланировать подход для обеспечения согласованности сетевого времени для серверов и клиентов сети | Глава 5 |
| Создать эффективный план обеспечения доступа и использования сетевых ресурсов | Глава 6, |
| Разработать стратегию обеспечения эффективного управления сетевыми приложениями. | Глава 8 |
| Разработать стратегию миграции для серверов и рабочих станций, работающих под предыдущей версией NetWare или другой сетевой операционной системой | Глава 9 |
| Создание графика внедрения | Глава 10 |
| |
Обзор характеристик разделов
Раздел является поддеревом или ветвью дерева Каталога. Каждый раздел именуется в соответствии с корневым объектом раздела. Он является для раздела контейнером наивысшего уровня. Этот контейнер называется также корневым элементом раздела.
Объект [Root] всегда включается в первый из создаваемых разделов, называемый разделом.
Когда раздел является частью другого раздела дерева Каталога, его называют дочерним разделом. Стоящий выше него раздел называется родительским разделом.
На приведенном ниже рисунке показаны отношения между родительским и дочерним разделами в дереве Каталога.
Разделы должны подчинятся определенному набору правил. Эти правила состоят в следующем.
Figure 6-1. Родительский и дочерние разделы
Раздел может содержать только объекты Каталога и связанные с ними данные. Он не может включать какой-либо информации о файлах и каталогах файловой системы. Объект Каталога может существовать только в одном разделе. Разделы могут храниться только на серверах NetWare 4. Разделы не могут накладываться друг на друга. Разделы должны содержать связанное с ними поддерево.
Оценка полученных результатов
Завершив разработку стратегии создания разделов, сверьтесь с приведенными ниже вопросами, которые помогут вам оценить эффективность этой стратегии.
Сформированы ли разделы верхнего уровня с учетом границ контейнеров Подразделение, представляющих размещение или организационную структуру? Содержат ли разделы только объекты, относящиеся к одному территориальному пункту, или включают в себя высокоскоростные каналы глобальной сети (T1 или лучше)? Содержат ли разделы менее 1000 объектов? Размещены ли разделы поблизости от объектов (обычно объектов Пользователь), использующих ресурсы, которые содержатся в разделе? Сгруппированы ли в один раздел серверы, физически находящиеся в одном кабельном сегменте? Имеется ли для каждого раздела не менее трех реплик? Существуют ли реплики для поддержки сервиса Bindery? Расположены ли реплики на серверах таким образом, чтобы отвечать требованиям повышения производительности NDS, обеспечивая, например, технологию обхода дерева и размещение разделов и реплик поблизости от пользователей?
Определение границ разделов
Создание эффективных границ разделов дает возможность для определения размера и оптимизации базы данных Каталога в сети. Для этого следует ознакомиться с некоторыми из базовых характеристик разделов.
Определение эффективной стратегии размещения реплик
Определение максимально эффективной стратегии размещения реплик позволяет оптимизировать для базы данных Каталога ее отказоустойчивость, возможности доступа и простоту перемещения. Для этого следует ознакомиться с некоторыми из основных характеристик реплик.
Определение процесса обновления и синхронизации реплик
При внесении изменений в объекты, расположенные в разделе, информация об этих изменениях автоматически передается во все остальные реплики этого раздела. Это обеспечивает согласование глобальной базы данных Каталога. Репликам передаются только изменения в данных. Например, если пользователь меняет номер телефона, передается только новый номер телефона, а не весь объект Пользователь.
Главная реплика участвует в процессе синхронизации разделов, обмениваясь с другими репликами информацией об изменениях, но не контролирует этот процесса. Аналогичным образом все реплики для чтения и записи синхронизируются с остальными репликами раздела. Реплики только для чтения также синхронизируются с другими репликами, но при этом они получают обновления только от других серверов.
База данных NDS является "не совсем согласованной" базой данных. При появлении изменений не все реплики раздела в каждый данный момент времени содержат полностью совпадающую информацию. На практике содержимое реплик в любой конкретный момент времени будет, скорее всего, немного различным. Однако по мере передачи информации об изменениях всем репликам, эти реплики будут стремиться к достижению некоторого согласованного состояния.
Некоторые изменения, например, изменения пользовательского пароля, передаются всем репликам немедленно. Менее критичные изменения, например, время последней регистрации пользователя, перед посылкой в сеть накапливаются локально в течение некоторого небольшого промежутка времени.
Чтобы произошла синхронизация, должна быть установлена связь с каждой репликой. При создании раздела к объекту контейнера, функционирующему в качестве корневого объекта раздела, добавляются некоторые дополнительные атрибуты. Эти свойства используются для управления синхронизацией данных реплик раздела.
При решении проблемы синхронизации следует учитывать три атрибута.
| Указатель реплики | Каждый раздел содержит запись о расположении всех своих реплик. Эта информация хранится в свойстве реплики раздела, по одному элементу свойства на каждую реплику раздела. Набор указателей реплик разделов создает список реплик раздела, иногда называемый кольцом реплик или списком реплик. |
| Синхронизировано до | Каждая реплика в списке реплик раздела поддерживает список временных меток. Сервер, содержащий некоторую реплику, использует этот атрибут для определения состояния синхронизации реплики в сравнении с другими репликами, входящими в список. Этот атрибут иногда называется вектором временных меток. |
| Наследуемый список управления доступом (ACL) | Корневой объект раздела отвечает за определение прав доступа, наследуемых им самим от объекта [Root]. Этот атрибут является прежде всего сводным списком ACL для всех объектов раздела. |
Определение размера и количества разделов
Размер разделов может значительно повлиять на синхронизацию и время реакции системы. При планировании разделов следует сохранять баланс факторов, связанных с размером.
Необходимо учитывать следующее.
При некоторых конфигурациях сетевого оборудования разделы, содержащие больше 1000 объектов, могут вызвать большие задержки при синхронизации и сильно увеличить сетевой трафик. Разделы, содержащие меньше 50 объектов, могут привести к излишним затратам на управление. Если дерево содержит много медленных каналов глобальной сети, может возникнуть необходимость в дополнительном разделении. Для лучшего определения областей управления и контроля ваша административная модель может потребовать создания большего количества разделов нижнего уровня. На количество разделов влияет объем сетевого трафика, который может поддерживать ваша сеть. Количество разделов может определяться статическим характером объектов. Если сеть быстро растет, вам следует учитывать перспективы ее роста, создав достаточно небольшие разделы. Тем не менее деление и объединение разделов является достаточно простой задачей.
NOTE: При работе с разделами большого объема операции с разделами требуют времени, если сеть имеет низкую пропускную способность, а производимые действия затрагивают большое количество объектов.
| |
Определение стратегии создания разделов и репликации
В этом разделе описано, как определять стратегию создания разделов для сети. Здесь обсуждаются следующие темы.
Если в вашей среде имеется только один сервер, то стратегию создания разделов разрабатывать не нужно. Переходите сразу к главе 5 .
В сетях с несколькими серверами, соответствующими приведенным ниже условиям, следует воспользоваться установками для создания разделов репликации, предлагаемыми в NetWare 4TM
по умолчанию.
Нет каналов связи по глобальной сети Не больше 15 серверов Меньше 1000 объектов
Чтобы получить дополнительную информацию, см. .
Определение требований к разделам
Разделы следует создавать только для того, чтобы.
Уменьшить зависимость от одного сервера сети Уменьшить размер базы данных, хранящейся на любом отдельном сервере Разместить ресурсы ближе к пользователям для увеличения производительности Снизить сетевой трафик, возникающий в результате доступа пользователей в сеть Снизить сетевой трафик, связанный с процессом синхронизации Снизить затраты на администрирование
Откажитесь от разделения, если оно:
Приводит к увеличению затрат на администрирование Создает дополнительные подчиненные ссылки на дочерние и родительские разделы Увеличивает сложность сети Увеличивает время, необходимое на перемещение по дереву Приводит к небольшому увеличению сетевого трафика
Прежде чем приступать к созданию стратегии создания разделов для разработанного вами проекта дерева, следует определить наилучшее соотношение возникающих при этом преимуществ и недостатков.
Основные функции реплик
Реплики обеспечивают для сети следующие три функции.
Отказоустойчивость каталога. Если происходит сбой диска или закрытие сервера, аутентификация пользователей в сети и предоставление информации об объектах, определяемых репликой на отключенном сервере, могут обеспечиваться репликой, находящейся на другом сервере.
Если на нескольких серверах присутствует одна и та же информация, то при аутентификации в сети или использовании сервисов клиенты не зависят от какого-либо одного сервера.
IMPORTANT: Если в сети присутствует лишь один сервер, то, скорее всего, поддерживаться будет только одна копия раздела [Root], поскольку инфраструктура сети не требует этого.
В этом случае единственным способом обеспечения некоторого уровня отказоустойчивости является поддержка текущей резервной копии базы данных Каталога. Убедитесь, что ваше программное обеспечение резервного копирования способно создавать резервные копии NDS.
NOTE: Репликация разделов не обеспечивает отказоустойчивость для файловой системы. Реплицируется только информация об объектах Каталога. Для обеспечения отказоустойчивости для файлов, следует провести зеркальное отражение либо дуплексирование жестких дисков, а также активизировать функцию Transaction Tracking SystemTM (TTSTM).
Увеличение скорости доступа. Размещение соответствующей информации Каталога на серверах, пространственно расположенных поблизости от рабочих групп, часто получающих доступ к находящейся на них информации, заметно увеличивает скорость выполнения операций аутентификации, обновления и поиска, поскольку вся необходимая информация пересылается с ближайшего сервера.
Доступ к информации, имеющейся в разделах, соединенных каналами глобальной сети, улучшается и уменьшается трафик глобальной сети - последнее зависит от объема требующейся синхронизации.
Обход дерева. Поиск конкретной информации в дереве Каталога называется обходом дерева или определением имен. Эта технология дает клиентам возможность отыскивать информацию Каталога, находящуюся не в том контейнере, где находятся их объект Пользователь. NDS производит процесс определения имен для поиска информации.
Каждая реплика содержит ссылки (указатели) на серверы, где хранятся реплики, являющиеся для позиции данной реплики в дереве Каталога подчиненными или вышестоящими. При поиске нужной информации NDS использует эти указатели для перемещения вверх или вниз по дереву.
Размещение реплик часто запрашиваемой информации на локальных серверах увеличивает скорость определения имен.
Планирование размещения реплик
При инсталляции первого сервера дерева Каталогов на этом сервере размещается первая реплика раздела [Root]. Первый сервер содержит главную реплику раздела [Root].
Для этого сервера не существует специальных прав или соглашений. При наличии в дереве других серверов реплику раздела [Root] в любой момент можно удалить или превратить в реплику для чтения и записи.
На следующем рисунке показано, как можно осуществить репликацию раздела [Root] в сети.
Figure 6-2. Пример размещения раздела [Root]
При инсталляции в дереве дополнительных серверов руководствуйтесь двумя простыми правилами, чтобы определить, нужно ли размещать реплику на данном сервере.
Если вы производите на сервере обновление NetWare 3TM
до NetWare 4, на этом сервере размещается реплика, позволяющая поддерживать сервис Bindery для максимум трех серверов в данном разделе. Если в дереве присутствует меньше трех реплик данного раздела, на данном сервере следует разместить реплику для обеспечения отказоустойчивости и возможностей восстановления после разрушения сети.
Во всех остальных случаях, если на сервере необходимо разместить реплику, ее следует добавлять вручную.
На следующем рисунке показано, как можно разместить реплики на сервере в дереве Каталога.
Figure 6-3. Пример размещения реплики
Планирование схемы разделов
При инсталляции первого сервера в дереве Каталога создается раздел с объектом [Root]. Данный раздел в этот момент времени содержит сразу все дерево Каталога и называется разделом [Root].
Раздел [Root] - это единственный раздел, создаваемый программой инсталляции. Все остальные разделы нужно создавать вручную.
Схема разделов должна походить на треугольник, с небольшим числом разделов на верхнем уровне и увеличением числа разделов при перемещении вниз по дереву. При такой структуре создается меньше подчиненных ссылок, чем для дерева, в верхней части которого больше разделов, чем в нижней.
Такую треугольную структуру можно построить, если вы всегда будете создавать разделы достаточно близко к конечным объектам (в частности, пользователям). Раздел [Root] является исключением.
Предварительные требования
Вам потребуются копии следующих проектных документов.
Карты топологии глобальных сетей Карты размещения Карты ресурсов Структура дерева Каталога Рекомендации по созданию разделов Вам следует закончить дизайн дерева Каталога. Чтобы получить дополнительную информацию, см. главу 3 .
Проектирование границ разделов
В большинстве случаев границы разделов следует устанавливать в соответствии с физической инфраструктурой сети. Это во многом совпадает с подходом к разработке верхних и нижних уровней дерева Каталога.
Как правило, если проект дерева структурирован правильно, стратегию создания разделов будет легко осуществлять и поддерживать. При разделении дерева Каталогов воспользуйтесь следующими рекомендациями.
Определите разделы верхнего уровня согласно границам Подразделений, отражающим местонахождение организации или ее организационную структуру. Спланируйте разделение так, чтобы разделы содержали объекты, расположенные на одной территории. Не допускайте, чтобы разделы соединялись медленными каналами связи глобальной сети.
К одной территории относится один пункт размещения организации или несколько пунктов размещения, связанных высокоскоростными каналами глобальной сети (T1 или лучше).
Поддержка реплик подчиненных ссылок будет осуществляться через каналы глобальной сети, если через эти каналы не производится передача разделов . Убедитесь, что ваша стратегия обеспечивает разумный баланс между поддержкой локальных разделов и снижением числа создаваемых реплик подчиненных ссылок
При создании локальных разделов также следует рассмотреть вопросы резервного копирования NDS. Если вы собираетесь регулярно проводить резервное копирование всего дерева из центрального пункта, то необходимо учитывать время, требующееся на передачу информации по каналам глобальной сети. После инсталляции первого сервера NetWare 4 следует воспользоваться NDS Manager или PARTMGR для создания разделов, прежде чем вы приступите к инсталляции последующих серверов.
SUGGESTION: Успешный подход, уменьшающий потребность в ручном размещении разделов, состоит в проведении предварительного разделения дерева с последующим добавлением дополнительных серверов в каждый из разделов. Создавайте небольшие разделы. Размещайте разделы вблизи объектов Каталога (в частности, объектов Пользователь), использующих ресурсы, содержащиеся в разделе. Серверы, находящиеся в одном кабельном сегменте, следует группировать в один раздел, если вы выделяете раздел в силу любой из следующих причин.
Имеются каналы глобальной сети В разделе присутствует больше пяти серверов В разделе присутствует больше 1000 объектов
Проектирование разделов нижнего уровня
Разделы нижнего уровня определяются в соответствии с административным делением организации и способом представления ее подразделений в схеме дерева. Проект дерева Каталога должен отражать структуру подразделений, отделов и рабочих групп, существующих в организации. Разделы следует создавать в соответствии с этой структурой.
Размещение реплик
В большинстве случаев реплики следует размещать в соответствии с требованиями обеспечения отказоустойчивости, доступности и простоты перемещения. Воспользуйтесь следующими рекомендациями.
Создавайте для каждого раздела не меньше трех реплик. Для раздела [Root] следует создать не меньше трех реплик (этот раздел требуется для поддержания целостности дерева). Программа инсталляции сервера автоматически создает одну реплику раздела [Root]. Остальные реплики нужно создавать вручную. Поддерживайте производительность сети, размещая реплики на сервере, к которому обращаются пользователи (на той же территории). В случае необходимости создавайте реплики для сервиса Bindery. Учитывайте требования обеспечения высокой производительности доступа к NDS, например, использования технологии обхода дерева и расположения разделов и реплик близко к пользователям.
Размещение реплик для администрирования
Операции с разделами требуют, чтобы была доступна главная реплика каждого раздела. Вам следует убедиться, что на серверах, находящихся физически близко к администратору раздела, находятся главные реплики.
Размещение реплик для обеспечения доступа
Разместите реплики в наиболее доступных местах. Например, если группам пользователей из разных контейнеров требуется доступ к определенному объекту, находящемуся в другом разделе, следует поместить реплику на сервер, находящийся в контейнере, расположенном на уровень выше контейнеров, содержащих эти группы.
Размещение реплик для облегчения перемещения
Размещайте реплики на серверах, где хранятся объекты, необходимые пользователям и ресурсам, физически расположенным близко от сервера. Это обеспечивает более быструю реакцию на запросы пользователя при аутентификации регистрации и доступе к сетевым ресурсам.
Размещайте реплики на сервере, где содержатся личные каталоги пользователей, к которым необходим доступ. На локальных серверах, к которым пользователи получают доступ, также следует размещать реплики объектов Каталога, находящихся на противоположных концах канала глобальной сети.
Размещение реплик для повышения отказоустойчивости
Для каждого раздела следует создавать не меньше трех реплик. В зависимости от уровня производительности или топологии сети может возникнуть необходимость в создании большего числа реплик.
Разместите по меньшей мере одну копию каждой реплики вне локальной территории вашего офиса, например в другом здании. Число мест, в которых будут размещены реплики, определяется планом восстановления сети после катастрофических сбоев, принятым в вашей организации. Используя реплики разделов, можно восстановить большую часть сети.
Убедитесь, что реплики подчиненных ссылок не используются для обеспечения отказоустойчивости - они могут быть использованы при восстановлении структуры дерева, но не конечных объектов.
Размещение реплик для сервиса Bindery
Сервис Bindery активизируется при инсталляции. Он также автоматически активизируется, если вы производите обновление сервера из NetWare 2 или NetWare 3.
Если сервис Bindery активизирован, сервер получает реплику для чтения и записи для максимум трех разделов, содержащих объект-контейнер в контексте Bindery.
Для поддержки сервиса Bindery воспользуйтесь следующими рекомендациями. Определите все контейнеры, содержащие ресурсы Bindery, и запишите их контекст (он называется контекстом Bindery). Определите разделы, содержащие контейнеры с ресурсами Bindery. Поместите на сервер реплики для чтения/записи этих разделов.
Размещение реплик на серверах
Размещайте на сервере минимально возможное количество реплик.
Размещайте реплики на лучших серверах сети. Медленные серверы могут повлиять на синхронизацию реплик на всех серверах в кольце реплик. (Кольцом реплик называется группа серверов, содержащих реплики одного и того же раздела).
Разработка разделов для верхних уровней
Первый уровень разделов, следующий после раздела [Root], разрабатывается в соответствии с сетевой инфраструктурой и особенностями физического размещения организации. Например, если ваша организация расположена на нескольких территориях, то в проекте вашего дерева должна отражаться географическая структура ее размещения. Для каждой из этих территорий следует создать разделы верхнего уровня.
Если ваша организация расположена на одной территории, разделы верхнего уровня должны отражать организационную структуру верхних уровней. Однако разделение в организации, расположенной на одной территории, в большей степени зависит от числа объектов, входящих в ветвь контейнера, нежели от физической инфраструктуры. Это происходит из-за отсутствия медленных каналов глобальной сети.
Если приходится принимать во внимание полосу частот каналов глобальной сети, имеет смысл создавать разделы меньшего размера и реплицировать их в меньшем количестве пунктов с меньшим числом подчиненных разделов. Это снизит сетевой трафик при осуществлении синхронизации по каналам глобальной сети.
и размещение реплик позволяет вам
Создание разделов и размещение реплик позволяет вам масштабировать дерево Каталога в соответствии с потребностями организации. Этот процесс может оказаться очень простым, если будет состоять лишь в принятии значений по умолчанию, или же сложным, связанным с разработкой разделов и матрицы размещения реплик для определения размещения разделов и реплик в большом количестве пунктов.
В приведенной ниже таблице перечислены основные правила, которых следует придерживаться при разделении дерева Каталога.
| Размещение | В сетях, содержащих каналы глобальной сети, не следует создавать разделы, включающие в себя несколько территориальных пунктов Создавайте разделы вокруг близлежащих серверов (физически удаленные друг от друга серверы следует помещать в разные разделы) В верхней части дерева размещайте меньше разделов, а в нижней части - больше |
| Размер | Поддерживайте разделы небольшого размера Раздел [Root] должен быть небольшим Как правило, в раздел должно входить меньше 1000 объектов, и ни в коем случае не больше 3500. Как правило, раздел должен иметь не больше десяти-пятнадцати подчиненных разделов, и ни в коем случае не больше сорока. |
В приведенной ниже таблице перечислены основные правила, которых следует придерживаться при размещение реплик в Каталоге.
| Размещение | Производите репликацию локально, а не через каналы глобальной сети. (При репликации через канал глобальной сети приходится передавать/принимать информацию о синхронизации NDS, что может снизить скорость передачи трафика по каналу глобальной сети). При наличии возможности, располагайте главные реплики физически близко к главным репликам родительских и дочерних разделов. |
| Количество | Всегда храните две или три реплики раздела, но не больше десяти. Размещайте на сервере не более десяти реплик. |
Создание матрицы репликации
Вам следует создать для сети матрицу репликации. Для организации физического размещения реплик для каждого раздела воспользуйтесь приведенной ниже таблицей. Для повышения отказоустойчивости рекомендуется создавать по три реплики каждого раздела, но, в зависимости от требований обеспечения пользовательского доступа, может потребоваться большее количество реплик. Чтобы получить дополнительную информацию, см. .
о каждом объекте Каталога всем
Объекты Каталога и их атрибуты находятся в базе данных, поддерживаемой и обслуживаемой Netware Directory ServicesTM
(NDSTM, службой Каталога Netware). NDS передает информацию о каждом объекте Каталога всем серверам в сети.
NDS производит эту операцию, разделяя базу данных на логические сегменты дерева Каталога, а затем копируя каждый из логических сегментов на группу серверов сети. Такое логическое сегментирование называется созданием разделов, или разделением. Процесс копирования логических сегментов на серверы называется репликацией.
Хотя разделение и репликация базы данных означает, что на каждом из серверов сети присутствует не вся информация базы данных Каталога, между серверами устанавливаются связи, дающие возможность доступа ко всей информации этой базы данных. Однако это не значит, что реплики разделов хранятся на каждом сервере NetWare. Процесс разделения и связи между серверами управляется и отслеживается утилитами NetWare 4.
При определении стратегии разделения важно помнить, что разделение - это просто логическое сегментирование базы данных Каталога, тогда как репликация - это физическое размещение раздела на серверах сети. Это означает, что вам следует принимать во внимание не только структуру дерева Каталога, но и физическую инфраструктуру сети.
Вам также следует разработать стратегию создания разделов, обеспечивающую максимально эффективное размещение реплик, не требующую усиленного контроля и не увеличивающую сетевой трафик.
Значения по умолчанию
Ниже приводятся значения по умолчанию для разделения и репликации.
| Главная | Первый сервер NetWare 4 в сети получает главную реплику раздела [Root]. Первый сервер в разделе получает главную реплику этого раздела. |
| Для чтения и записи | Новые серверы. Второй и третий сервер в разделе получают реплики этого раздела для чтения и записи. Остальные серверы не получают реплик, если только при инсталляции не был активизирован сервис Bindery. Если на новом сервере активизирован сервис Bindery, сервер получает реплику для чтения и записи для максимум трех разделов, в контексте Bindery которых присутствует объект-контейнер. Обновленный сервер. Сервер, где было произведено обновление из NetWare 2 или NetWare 3, получает реплику для чтения и записи для максимум трех разделов, в контексте Bindery которых присутствует объект-контейнер. Примечание: Сервис Bindery активизируется при инсталляции. Если производится обновление сервера из NetWare 2 или NetWare 3, она активизируется автоматически. |
| Только для чтения | Нет |
| Подчиненная ссылка | Реплики подчиненных ссылок создаются и размещаются автоматически, и служат для связывания разделов дерева друг с другом. |
Цели и задачи
Задача планирования стратегии синхронизации времени состоит в определении эффективного метода синхронизации времени, после чего требуется найти наилучший способ для установки и применения этого метода в сети.
Чтобы определить, какие серверы времени нужно использовать и какой формат связи между серверами сети следует принять, воспользуйтесь картами ресурсов, картами размещения, картами топологии локальных/глобальных сетей и документом, определяющим проект дерева.
Использование единственного эталонного сервера времени
В качестве конфигурации по умолчанию в NetWare 4 используется единственный эталонный сервер времени. Первый сервер, инсталлируемый в сети NetWare 4, автоматически конфигурируется как единственный эталонный сервер времени. Все остальные серверы, инсталлируемые в сети NetWare 4, конфигурируется как вторичные серверы времени.
Конфигурация единственного эталонного сервера времени подходит для сетей, удовлетворяющих следующим условиям.
Имеется менее тридцати серверов NetWare 4 Отсутствуют каналы глобальных сетей Используется только один часовой пояс
Вам следует убедиться, что единственный эталонный сервер времени расположен в центральной части сети, и что часы на нем работают нормально. Единственный эталонный сервер следует проверять ежедневно, чтобы обеспечить установку верного времени дня и синхронизацию времени.
Ограничением конфигурации с использованием единственного эталонного сервера времени является недостаточная устойчивость к сбоям в том случае, если сервер времени потеряет связь с сетью на продолжительный период времени. Это может привести к потере синхронизации вторичных серверов времени с сетевым временем по Гринвичу (UTC).
Однако если единственный эталонный сервер времени потеряет связь, до ее восстановления в качестве единственного эталонного сервера времени временно может быть назначен один из вторичных серверов времени.
На приведенном ниже рисунке показан единственный эталонный сервер времени, предоставляющий информацию о времени вторичным серверам времени и своим собственным клиентским рабочим станциям. Вторичные серверы времени, в свою очередь, предоставляют информацию о времени своим рабочим станциям.
Figure 7-1. Единственный эталонный сервер времени
Единственный эталонный сервер времени может работать в сетях любого размера, однако показанная на Рис. 7-1 конфигурация синхронизации времени используется преимущественно в небольших сетях, не имеющих каналов глобальной сети.
IMPORTANT: Если вы используете единственный эталонный сервер времени, не используйте в том же дереве первичных или эталонных серверов времени, поскольку значения их эталонов времени могут конфликтовать между собой.
Использование группы источников времени
Использование группы источников времени требует назначения хотя бы одного сервера в качестве эталонного сервера времени и хотя бы двух серверов - первичными серверами времени. Эталонный сервер времени опрашивает входящие в группу источника времени первичные серверы времени для проведения голосования по поводу правильности значения времени.
На следующем рисунке показан единственный эталонный сервер времени, предоставляющий информацию о времени первичным серверам времени. Первичные серверы, в свою очередь, передают информацию о времени вторичным серверам времени. Каждый из серверов может предоставлять информацию о времени своим клиентским рабочим станциям.
Figure 7-2. Группа источника времени с единственным эталонным сервером времени
Обычно в сети устанавливается только один эталонный сервер времени. Если вы используете несколько эталонных серверов времени, вам следует синхронизировать каждый такой сервер по одному и тому же внешнему источнику времени, например, радиочасам, атомным часам, или информация о времени, полученной из Internet.
На следующем ресунке показана сеть, в которой для предоставления значения времени двум отдельным эталонным серверам времени используется внешний сервер времени.
Figure 7-3. Два эталонных сервера времени, использующих внешний источник времени
Такая конфигурация требует модификации параметров времени, входящих в группу источника времени серверов NetWare 4.
Сервер NetWare 4, назначенный эталонным сервером времени, должен располагаться в центральной части сети. Серверы NetWare 4, назначенные первичными серверами времени, должны либо располагаться на той же территории, что и эталонный сервер времени, либо использоваться в качестве серверов времени локального типа.
Если вы создаете конфигурацию для сети, расположенной в нескольких территориальных пунктах, вам следует стратегически разместить первичные серверы времени в соответствии с инфраструктурой глобальной сети. Это снизит передаваемый по глобальной сети трафик, благодаря наличию в каждом из пунктов своего источника времени для вторичных серверов времени и клиентских рабочих станций.
Если инфраструктура глобальной сети требует использования в группе времени более семи первичных серверов времени, следует по мере необходимости создавать дополнительные группы источников времени. Однако следует обеспечить синхронизацию всех эталонных серверов по одному и тому же внешнему источнику времени. Эталонные серверы времени не могут производить синхронизацию времени с другими эталонными серверами.
Все остальные серверы сети должны быть назначены вторичными серверами времени.
Использование комбинации форматов связи
В одной и той же сети можно использовать оба описанных выше метода. Однако список заказной конфигурации, хранящийся на сервере, всегда имеет преимущество над информацией SAP, получаемой сервером.
Если на сервере нет списка заказной конфигурации, для синхронизации времени используется информация SAP.
SUGGESTION: В сети, где после первоначальной инсталляции добавление серверов и переконфигурация осуществляются нечасто, и в тех сетях, где используется единственный эталонный сервер времени, рекомендуется использовать SAP (устанавливается при инсталляции по умолчанию).
В сетях, где серверы часто добавляются и удаляются, следует использовать список заказной конфигурации.
Использование комбинации методов синхронизации времени
В задачу сервиса синхронизации времени не входит установка верного времени дня на серверах. Он может лишь поддерживать внутренние часы серверов, установленными на общее время.
Вы можете обеспечить правильность сетевого времени, просто проверяя значение UTC на источнике времени по наручным часам, или подключив источник времени ко внешнему источнику времени при помощи модема, радио, или через Internet.
NOTE: Если серверы-источники времени разделены каналами глобальной сети или спутниковыми каналами, что вызывает задержку при передаче пакетов, величину погрешности синхронизации следует скорректировать.
| |
Использование методов внешней синхронизации времени
Общее время может быть установлено при помощи подключения всех сетевых серверов к одному внешнему источнику времени. В зависимости от стоимости источника или аппаратной конфигурации этот метод установки общего времени в сети может оказаться эффективным.
Примерами внешних источников времени являются радиочасы, атомные часы или информация о времени, полученная из Internet.
Использование методов внутренней синхронизации времени
NetWare 4 дает возможность поддерживать на всех серверах одно и то же время UTC. Это делается при помощи серверной утилиты под названием TIMESYNC.NLM. Утилита TIMESYNC обеспечивает возможность установки различных типов серверов-источников времени, предоставляющих информацию о времени остальным серверам и клиентам.
Использование SAP (протокола оповещения о сервисе)
По умолчанию первичные, эталонные и единственные эталонные серверы времени для извещения о своем присутствии в сети используют протокол оповещения о сервисе (SAP, Service Advertising Protocol). Потребители времени не используют SAP.
Первичные и эталонные серверы времени используют информацию SAP, чтобы найти другие серверы, которые следует опрашивать для определения сетевого времени.
Вторичные серверы времени используют информацию SAP, чтобы выбрать сервер времени, с которым следует синхронизироваться.
Преимущество метода SAP заключается в том, что он допускает быструю инсталляцию и не зависит от структуры сети. Он также имеет возможность автоматической реконфигурации в случаях изменения режимов работы или установки в сети дополнительных серверов.
Однако при использовании метода SAP создается дополнительный сетевой трафик.
Метод SAP к тому же может оказать разрушительное воздействие на крупные сетевые среды, где время от времени появляются "тестовые" серверы, особенно в том случае, если такой сервер сконфигурирован как источник времени (единственный, эталонный или первичный).
Использование списка заказной конфигурации
Заказная (настраиваемая) конфигурации серверов времени дает большие возможности управления синхронизацией времени, но для эффективной синхронизации серверов требует большего объема планирования.
Преимущество списка заказной конфигурации состоит в том, что вы при его использовании осуществляется полный контроль за средой синхронизации времени.
К тому же списки заказной конфигурации помогают избавиться от ненужного трафика SAP, также как и от ошибок, связанных со случайной реконфигурацией.
В списке также можно указать определенные серверы-источники времени, с которыми должен связываться какой-либо сервер.
Можно также указать, что сервер не должен обращать внимания на информацию SAP, приходящую от других серверов времени, и не должен при помощи SAP объявлять о своем присутствии.
Настраиваемая конфигурация требует дополнительного времени на планирование и инсталляцию.
К тому же устанавливать и удалять первичные, эталонные и единственные эталонные серверы становится труднее. Вам придется вручную вносить изменения в соответствующий список, принятый и поддерживаемый на каждом сервере.
При настройке серверов времени можно воспользоваться утилитой SERVMAN или параметрами утилиты SET для установки следующих значений параметров.
Time Sources
Содержит список определенных серверов времени, с которыми данный сервер должен связываться. Configured Sources
Указывает, должен ли сервер обращать внимание на информацию SAP, приходящую от других серверов-источников времени. Service Advertising
Запрещает передавать по сети информацию SAP об источнике времени Directory Tree Mode
Указывает, должен ли сервер игнорировать оповещение об источниках времени по SAP, если это оповещение приходит не из дерева Каталога, где содержится данный сервер. Этот параметр не действует, если установлен параметр Configured Sources.
Чтоб получить более подробную информацию об установке данных параметров при помощи утилит SERVMAN или SET, см. главу 4 "Monitoring and Maintaining Time Synchronization" в книге Supervising the Network.
Использование TIMESYNC
TIMESYNC автоматически загружается на всех серверах NetWare 4. TIMESYNC - это утилита, отвечающая за обновление значений времени по Гринвичу (UTC) на каждом сервере в соответствии с UTC сети. Синхронизация времени активизируется при загрузке утилиты TIMESYNC.
TIMESYNC определяет, соответствует ли значение времени внутренних часов значению времени, предоставляемому источником времени. Осуществляется это посредством определения, синхронизировано ли время внутренних часов в пределах установленной погрешности относительно значения, получаемого от источника времени. Если погрешность синхронизации находится в пределах установленного интервала времени, сервер посылает флаг синхронизации времени, указывающий, что синхронизация установлена.
Пределы погрешности синхронизации устанавливаются при помощи параметров TIMESYNC в утилитах SERVMAN или SET. Значением по умолчанию является расхождение в 2000 миллисекунд, или приблизительно 2 секунды.
К какому разделу следует перейти
| Создать эффективный план обеспечения доступа и использования сетевых ресурсов | Глава 6 |
| Разработать стратегию миграции для серверов и рабочих станций, работающих под предыдущей версией NetWare или другой сетевой операционной системой | Глава 9 |
| Создание графика внедрения | Глава 10 |
| |
Оценка полученных результатов
Закончив планирование синхронизации времени, сверьтесь с приведенным ниже списком вопросов, чтобы оценить эффективность созданного вами плана.
Используете ли вы установки по умолчанию, если ваша сеть отвечает следующим условиям?
Отсутствуют каналы глобальной сети Имеется менее тридцати серверов Используется только один часовой пояс Если важным является соответствие времени значению UTC, осуществили ли вы подключение к внешнему источнику времени какого-либо типа? Используете ли вы список конфигурации, если в вашей сети есть медленные каналы глобальной сети? Если в группе источника времени больше семи первичных серверов времени, создали ли вы дополнительные группы источников времени, синхронизированные по тому же внешнему источнику времени?
Определение формата связи
Источники и потребители времени, чтобы осуществлять передачу и получение времени, должны поддерживать между собой связь. Источники времени должны связываться с другими источникам времени, чтобы участвовать в голосовании и определять верное сетевое время по Гринвичу (UTC).
Чтобы находить друг друга, серверы-источники времени используют один из двух методов: либо SAP, либо список заказной конфигурации.
Определение источника времени и эффективной конфигурации
В задачу определения наилучшего для вашей сети источника времени и конфигурации входит следующее.
Определение используемого источника времени Определение эффективной конфигурации Определение формата связи
Определение эффективного источника времени
Определение типа источника времени для сети основано на выбранном вами методе синхронизации. Чтобы получить дополнительную информацию, см. .
Существует два типа серверов времени: функционирующие как источники или как потребители времени. Принципы работы этих серверов практически совпадают. Эти принципы таковы.
Все серверы предоставляют время любому источнику времени, потребителю времени или рабочей станции. Все серверы отвечают за свою собственную синхронизацию, что означает, что они должны решать, синхронизированы ли они с сетевым временем по Гринвичу (UTC) или нет, и сообщать свой статус синхронизации. Все серверы должны корректировать скорость хода своих внутренних часов для устранения несоответствий, и обеспечивать синхронизацию времени с другими серверами сети.
Определение эффективного метода синхронизации времени
NetWare 4 требуется поддерживать правильное системное время (время "реального мира"), чтобы обеспечить использование правильных временных меток даты и времени для файлов, проводить ревизии и регистрацию, а также управлять ограничениями времени регистрации пользователей. Важно также поддерживать общее время на серверах всей сети.
Синхронизация времени обеспечивает механизмы для коррекции и компенсирования хода часов операционной системы. Кроме того, она также поддерживает время по Гринвичу - UTC (Universal Time Coordinated) или GMT (Greenwich Mean Time), - общемировое стандартное время, соответствующее времени на нулевом меридиане (0 долготы).
Это делается путем присвоения какой-либо группе серверов статуса источника времени для всех остальных серверов и клиентских рабочих станций в сети. Все остальные серверы действуют в качестве вторичных серверов времени, получая значения UTC из источника времени. Эти взаимосвязи обеспечивают коррекцию любых отклонений внутренних часов различных серверов и поддержку общесетевого времени.
Создать общий источник времени для всей сети можно при помощи одного из следующих методов, или их комбинации.
Внутренняя синхронизация времени Внешняя синхронизация времени
Определение эффективной конфигурации
Определение эффективной конфигурации синхронизации времени зависит от физической инфраструктуры сети. Вам следует просмотреть проектную документацию по вашей сети, относящуюся к топологии глобальных/локальных сетей.
В большинстве случаев подходит одна из двух основных конфигураций серверов времени. Эти конфигурации таковы.
Единственный эталонный сервер Группа источников времени
Для моделирования стратегии синхронизации времени в сети выберите одну из этих конфигураций серверов времени.
Определение серверов времени NetWare
Утилита TIMESYNC позволяет установить в NetWare 4 до четырех типов серверов времени. Список и описание приведены в следующей таблице.
Table 7-1. Типы серверов времени
| Вторичный (по умолчанию) | Получает время с сервера-источника времени, предоставляет информацию о времени клиентским рабочим станциям | Вторичный сервер времени может связываться с другим вторичным сервером времени для получения правильного значения времени. Однако если промежуточный сервер времени недоступен, серверы, связывающиеся с ним для получения правильного значения времени могут оказаться в слишком большом количестве переходов от сервера-источника времени. | Старается сохранить синхронизацию с одним источником времени. Не участвует в голосовании. Большинство серверов будут являться вторичными. |
| Первичный сервер времени | Для определения времени проводит опрос и голосование вместе с другими первичными серверами времени и предоставляет информацию о времени вторичным серверам времени и клиентским рабочим станциям. Используется с эталонными серверами времени для передачи информации о времени вторичным серверам времени и клиентским рабочим станциям. | Должен иметь возможность связаться хотя бы с одним первичным сервером времени или эталонным сервером времени. | Опрашивает остальные источники времени, чтобы определить правильное сетевое время и скорректировать ошибки часов. Устанавливает статус синхронизации на основе отклонения от расчетного сетевого времени, не принимая во внимание статус остальных опрошенных источников времени. |
| Единственный эталонный сервер времени | Предоставляет информацию о времени вторичным серверам времени и клиентским рабочим станциям. Обычно используется в небольших ЛС. | Все серверы должны иметь возможность связаться с единственным эталонным сервером времени. В такой сети не может быть первичных или эталонных серверов времени. | Действует также, как и эталонный сервер времени, хотя и не синхронизируется с остальными серверами. |
| Эталонный сервер времени | Получает информацию о времени из внешнего источника времени и предоставляет информацию о времени первичным и вторичным серверам времени. Такой сервер следует использовать, если в сети должен быть центральный пункт контроля времени. | Обычно в сети устанавливается только один эталонный сервер времени. Если в сети несколько эталонных серверов времени, они должны синхронизироваться с одним и тем же внешним источником времени. | Работает так же, как и первичный сервер времени, но не корректирует своих внутренних часов. Обеспечивает центральный пункт контроля времени для всей сети. |
Каждый сервер синхронизации времени выполняет три основных функции.
Предоставляет информацию о времени по Гринвичу (UTC) по требованию любого модуля NLM или клиентской рабочей станции Предоставляет статусную информацию, указывающую, синхронизировано ли время UTC Корректирует скорость хода внутренних часов для компенсации отклонений и обеспечения синхронизации с UTC.
Дополнительную информацию можно найти в разделе .
Планирование стратегии синхронизации времени
В этой главе описано, как планировать стратегию синхронизации времени. Здесь обсуждаются следующие темы.
Если в вашей среде присутствует только один сервер, вам не нужно осуществлять планирование синхронизации времени. Переходите к выполнению следующей процедуры. Дополнительную информацию можно найти в главе 6 .
Предлагаемые в NetWare 4TM
значения по умолчанию следует принять в многосерверных средах, отвечающих следующим условиям.
Нет каналов глобальной сети Имеется менее тридцати серверов Используется только один часовой пояс
Чтобы получить дополнительную информацию, см. раздел . Вам может также потребоваться просмотреть информацию о возможностях комбинирования методов внутренней и внешней синхронизации времени. Дополнительную информацию можно найти в разделе .
Предварительные требования
Вам потребуются копии следующих проектных документов.
Карты ресурсов Карты размещения Карты топологии локальных/глобальных сетей Проект дерева Каталога
Синхронизация времени является способом поддержки
Синхронизация времени является способом поддержки правильного порядка совершения событий NDS в случае осуществления разделения и репликации базы данных Каталога.
Синхронизация времени может осуществляться при помощи внешних или внутренних источников времени.
Внешние источники времени
Если вы используете метод внешней синхронизации времени, источник времени определяется как внешний.
Для синхронизации часов на рабочих станциях и серверах NetWare чаще всего используются источники, информацию с которых получают при помощи модема или по радио.
NOTE: Список независимых служб источников времени можно найти в форуме NOVLIB в NetWire. В данный момент соответствующий файл называется TIMESG.TXT.
Для определения процедур установки и дальнейшей поддержки воспользуйтесь проектной документацией и документами, предоставляемыми соответствующим источником времени.
Внутренние источники времени
Входящая в NetWare 4 система синхронизации времени поддерживает три типа источников времени.
Система синхронизации времени определяет всех потребителей времени как вторичные серверы времени.
Вторичные серверы времени получают информацию о времени с единственного эталонного, эталонного или первичного сервера времени. Они корректируют свои внутренние часы для синхронизации с сетевым временем, и передают информацию о времени клиентским рабочим станциям.
Вторичные серверы времени не участвуют в процессе определения правильного сетевого времени.
Эта база данных может находиться
Объекты Каталога находятся в базе данных, поддерживаемой и управляемой NetWare Directory ServicesTM
(NDSTM). Эта база данных может находиться на одном сервере, или может быть разделена и в виде реплик размещена на других серверах. NDS гарантирует, что при внесении изменений в объекты в одном разделе эти изменения будут внесены во все реплики этого раздела в том же порядке, в котором и совершались.
Если для какого-то объекта в разделе существует несколько событий, NDS обеспечивает применение этих событий к объекту в правильном порядке. Допустим, один администратор переименовывает объект, а другой администратор перемещает этот объект. Если эти события произойдут в неверном порядке, объект невозможно будет переименовать, поскольку он будет отсутствовать в первоначальном контексте.
Чтобы гарантировать, что события происходят в правильном порядке, NDS записывает время каждого события в соответствии с общим источником времени. Эта запись времени называется временной меткой. NDS использует временные метки для того, чтобы при модификации базы данных обеспечить выполнение событий в нужное время и в нужном порядке. NDS также использует временные метки для записи значений времени "реального мира" в сети и установки дат истечения срока действия.
В среде с одним сервером внутренних часов этого сервера достаточно для поддержки общего источника времени для сети.
В многосерверной среде NetWare 4 использует функцию поддержки общего времени на всех серверах NetWare 4 в сети. Это называется синхронизацией времени.
Общий источник времени для отслеживания правильной последовательности событий поддерживается путем синхронизации времени на всех серверах NetWare 4. Вам следует спланировать стратегию синхронизации времени, чтобы обеспечить эффективную и точную поддержку общего источника времени.
NOTE: Стандартным форматом для времени и смещений времени является [+|-] HH:MM:SS. На практике необходимо указывать лишь значащую часть показателя времени (то есть, +7:0:0 - то же самое, что и 7).
Кроме того, в приведенных в этой главе примерах в качестве разделителя времени используется двоеточие, тогда как символ, действительно используемый в качестве разделителя, определяется информацией о стране на каждом из серверов. В большинстве случаев в NetWare 4 процедуры ввода и вывода, работающие с датой и временем поддерживают указание языка и используют соответствующие стране формат и символы.
Значения по умолчанию
Ниже приводятся значения по умолчанию для синхронизации времени.
| Единственный эталонный | Первый сервер NetWare 4 в сети устанавливается в качестве единственного эталонного сервера времени. |
| Вторичный | Все дополнительные серверы сети, кроме первого, устанавливаются как вторичные серверы времени. |
