Процедура однократного подключения пользователя к сети

Подключившись по LOGIN к сети, пользователь получает доступ ко всем файловым серверам, их томам и другим объектам, по отношению к которым он имеет соответствующие права. При выполнении команды LOGIN пользователь прежде всего должен указать имя регистрации. По этому имени NetWare 4.х определяет местоположение требуемого объекта User в дереве NDS. В таблице 3.15 определяются правила кодирования имени регистрации в команде LOGIN.

Таблица 3.15. Правила кодирования имени регистрации в команде LOGIN

Способ кодирования

Описание

.Имя

Наличие точки в начале Имени означает, что это Имя определяет полное имя объекта User в дереве NDS (т. е. полный путь от объекта User до корня дерева).

Имя

Отсутствие точки в начале и в конце Имени означает, что для определения местоположения объекта User в дереве NDS это Имя присоединяется слева к Имени1, указанному в строке Name Context="Имя1" файла NET.CFG. Полный путь поиска будет иметь вид: Имя.Имя1

Имя.

Наличие точки в конце Имени означает, что для определения местоположения объекта User это Имя присоединяется слева к контексту, расположенному на более высоком уровне иерархии. Т. е. если Name Context="Имя1.Имя2.Имя3..." то полный путь поиска будет иметь вид: Имя.Имя2.Имя3....

Имена в команде LOGIN и в строке Name Context могут быть составными, т. е. могут состоять из идентификаторов, разделённых точками. Рассмотрим примеры, иллюстрирующие эти правила.

Предположим, что в контейнерном объекте CLASS (рисунок 3.6) создан объект пользователя (User) с именем USR. В таблице 3.16 показаны различные способы кодирования имени регистрации в команде LOGIN.

Таблица 3.16. Примеры кодирования имени регистрации в команде LOGIN

Имя регистрации в LOGIN

Имя в строке Name Context файла NET.CFG

Полный путь поиска объекта User (полное имя объекта) в дереве NDS (от оконечного объекта к корневому)

.USR.CLASS.MSTU или .CN=USR.OU=CLASS.O=MSTU

Произвольное

USR.CLASS.MSTU

USR или CN=USR

CLASS.MSTU

USR.CLASS.MSTU

USR.CLASS или CN=USR.OU=CLASS

MSTU

USR.CLASS.MSTU

ADMIN. или CN= ADMIN.

CLASS.MSTU

ADMIN.MSTU

Новые возможности администрирования на уровне NDS

В таблице 3.17 перечислены новые возможности администрирования на уровне NDS NetWare 4.х.

Таблица 3.17.Новые возможности администрирования на уровне NDS NetWare 4.х

NetWare 3.х

NetWare 4.х

На каждом сервере создаются разные базы данных Bindery.

База данных NDS - это база данных всей сети. На разных серверах можно хранить копии базы данных NDS или её частей (разделов).

Администрирование выполняется с помощью разных текстовых утилит (SYSCON, FILER, SALVAGE и т. д.).

Основное средство администрирования - это графическая утилита (Windows-программа) NWADMIN, позволяющая выполнять все основные функции администратора: защиту объектов дерева NDS и их свойств (опекуны, IRF), защиту файловой системы каждого сервера, который определён в дереве NDS (опекуны, IRF, атрибуты), описание объектов печати, описание пользователей, групп, менеджеров, операторов, описание сценариев подключения всех типов, управление печатью, описание шлюзов MHS и их клиентов (для NetWare 4.1) и т.д.

NetWare 4.х предлагает средства копирования дерева NDS или его частей (разделов) на разные файловые серверы. Разделы являются логическими единицами. Физические копии разделов называют репликами. Использование копий разделов позволяет повысить:

• надёжность системы, т. к. при выходе из строя какого-либо сервера пользователь может подключиться к сети, используя копию раздела NDS на другом сервере,
• производительность системы, т. к. в распределённых сетях требуемые части дерева NDS можно хранить на серверах, которые располагаются ближе к пользователю.

С помощью текстовой утилиты PARTMGR или графической программы NWADMIN (пункт меню Tools/Partition Manager) можно выполнить следующие операции над разделами и репликами:

• создать раздел,
• объединить два раздела в один,
• создать реплику,
• изменить тип реплики,
• удалить реплику.

1. Создание раздела

В процессе инсталляции первого сервера сети автоматически создаются первый раздел NDS, началом которого служит объект [Root] (корень дерева), и Master-реплика этого раздела. При инсталляции следующего сервера сети новый сервер будет автоматически содержать Read/Write-реплику дерева NDS, но при условии, что имеется менее трёх реплик этого раздела.

Рис. 3.11. Разделы NDS

Для создания нового раздела вручную необходимо указать на контейнер - корень будущего раздела. При этом автоматически создаётся Master-реплика нового раздела. Она сохраняется на сервере, который хранит Master-реплику родительского раздела (для первого раздела, создаваемого вручную, родительским разделом будет раздел [Root]). Если, кроме того, существуют другие серверы, хранящие Read/Write(Read-Only)-реплики этого же родительского раздела, то на них автоматически создаются Read/Write(Read-Only)-реплики создаваемого раздела.

Следует отметить, что создаваемые разделы всегда покрывают всё дерево NDS и никогда не перекрываются между собой (рисунок 3.11).

2. Объединение двух разделов в один

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

3. Создание реплики (т. е. новой копии раздела)

Для создания новой реплики необходимо указать на контейнер (корень раздела), выбрать сервер, на котором требуется создать реплику, и определить тип этой реплики (Read/Write или Read-Only).

При этом следует помнить, что каждый раздел может иметь только одну Master-реплику (все остальные реплики должны быть Read/Write или Read-Only). На сервере можно хранить только одну реплику раздела.

4. Изменение типа реплики

При изменении типа реплики следует учитывать, что

• при изменении Read/Write(Read-Only)-реплики на Master-реплику тип старой Master-реплики автоматически изменяется на Read/Write,
• изменение типа Read/Write-реплики на Read-Only и наоборот не влияет на другие реплики этого раздела.

5. Удаление реплики

При удалении реплики необходимо помнить следующее:

• нельзя удалить Master-реплику; при необходимости следует изменить тип какой-либо Read/Write(Read-Only)-реплики на Master, при этом старая Master-реплика автоматически преобразуется в Read/Write-реплику, которую уже можно удалить,
• в целях обеспечения устойчивости к отказам следует иметь, как минимум, две реплики для каждого раздела.

Предыдущая глава || Оглавление || Следующая глава