Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Дерево NDS: профилактика и решение проблем роста

Том Зеллер, Джон Нааб

Одно дело — "вырастить" большое дерево NDS, и совсем другое — не дать ему "засохнуть". Здесь мы хотели бы немного поговорить о том, как избежать возможных проблем при использовании больших деревьев NDS.

В компьютерной сети нашего университета используется большое дерево NDS (Novell Directory Services), которое обеспечивает службу справочника более чем для 28 000 пользователей. Мы уже "пожинаем плоды" с "выращенного" нами дерева, содержащего 750 рабочих станций Windows NT, 350 компьютеров Macintosh и 40 серверов.

Который час?

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

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

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

Сделав такое назначение, мы сконфигурировали другие серверы в качестве серверов службы вторичного времени. Затем из утилиты SERVMAN. NLM настроили серверы вторичного времени таким образом, чтобы они синхронизировали время по назначенному "комитету". Такая конфигурация предохраняет от сбоев в настройке времени, которые могут произойти из-за их случайной синхронизации со временем на только что запущенном или ошибочно сконфигурированном сервере.

Чтобы сконфигурировать первичные серверы, введите их имена в окне Timesync Add Time Source ("Дополнительный источник времени для синхронизации") модуля SERVMAN.NLM. Затем, чтобы заставить ваши серверы использовать только введенные источники времени и не "прислушиваться" к любому другому объявленному в сети источнику времени, определите настройку Timesync Configured Sources ("Сконфигурированные источники времени для синхронизации"). Мы находим этот интерфейс несколько запутанным и для подстраховки предлагаем вам с помощью редактора проверить конфигурационный файл SYS:SYSTEM\TIMESYNC.CFG.

Вы также должны проконтролировать выставленное на вашем сервере время, запустив с консоли команду TIME. Для проверки всех серверов в дереве, воспользуйтесь опцией Time Synchronization ("Синхронизация по времени") из главного меню утилиты DSREPAIR.NLM. В случае возникновения проблем, первое, что необходимо сделать, — это проверить синхронизацию времени всех принадлежащих дереву серверов, а не только тех, в которых содержатся копии разделов NDS.

В ногу со временем

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

Novell также строго рекомендует, чтобы все серверы в дереве запускали одну и ту же версию загружаемых модулей NetWare NDS. Хотя отличающиеся версии и будут взаимодействовать, такая установка может привести к потере эффективности обмена информацией. Серверы в дереве NDS должны иметь по крайней мере версию 5.06 модулей NLM, которую можно получить на Web-узле Novell (support.novell.com). Кстати, отчет об установках времени, упомянутый выше, также показывает версию NDS, запущенную на каждом сервере. Чтобы обновить версию NDS, запущенную на сервере, поместите новый файл NDS.NLM в системный каталог и с консоли дайте команду SET DSTRACE=*. (т. е. звездочка с точкой после нее).

Поспевай за изменениями

Убедиться в том, что обмен информацией NDS протекает нормально, вы сможете, запустив опцию View Remote Server ID List ("Просмотр списка идентификаторов удаленных серверов") из меню расширенных опций программы DSREPAIR.NLM и выбрав при этом какой-нибудь сервер из списка. Нажатие клавиши Enter приведет к выводу меню идентификаторов серверов. Выбор опции Verify All Remote Server IDs ("Проверить все идентификаторы удаленных серверов") позволит вам выявить некорректные номера серверов, после чего они будут исправлены или удалены. Результаты проверки должны быть возвращены быстро. Если при обновлении экрана возникнут значительные паузы — более нескольких секунд, проверьте коммуникации.

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

Если в вашем дереве NDS был сервер, при демонтировании которого связанные с ним объекты не были удалены, то все они останутся в базе данных NDS. Чтобы проверить наличие таких "объектов-призраков" на каждом сервере, владеющем копией соответствующего раздела, необходимо воспользоваться утилитой DSREPAIR, выбрав из нее опцию Check External References ("Проверить внешние ссылки"). Если никакие объекты из дерева не удалялись, ваш список "отмерших" объектов, естественно, будет пуст. Оставление таких объектов в дереве может привести к замедлению работы NDS. Итак, "отмершие" объекты, которые почему-либо не были удалены утилитой DSREPAIR, могут стать причиной возникновения серьезных проблем.

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

Требования NDS к объему памяти

Для хранения информации NDS сервер должен иметь достаточный объем оперативной памяти. Одним из параметров, определяющих необходимый объем памяти, является время, в течение которого файл удерживается в кэш-памяти до замены более используемым. Чем больше это время — на экране статистики оно отображается в виде параметра Least Recently Used (LRU) — тем выше процент использования кэш-памяти.

Время LRU зависит от активности сервера и может меняться от нескольких часов (в периоды слабой его активности) до нескольких секунд (во время резервного копирования). Как и при работе с любыми другими системными параметрами, вам необходимо знать обычное состояние LRU для вашей среды. Служба подсказки консольного монитора предложит вам увеличить память, если показатель обращений к долговременной кэш-памяти (long-term cache hits) упадет ниже 98%. В свою очередь, утилита просмотра конфигурации, обсуждаемая ниже, рекомендует увеличить объем ОЗУ, если время LRU оказывается меньше 15 мин.

Дерево NDS, которым мы управляем, имеет в одном контейнере более 28 000 пользовательских объектов, поэтому в данном случае размер базы данных NDS превышает 100 Мбайт. У нашего сервера с ОЗУ объемом 160 Мбайт и 24 Гбайт дискового пространства время LRU было меньше 1 мин с учетом того, что он не выполнял никаких действий, кроме операций по синхронизации NDS. Нарастив на нем ОЗУ до 256 Мбайт, нам удалось добиться увеличения LRU до 30—60 мин.

Использование DSTRACE

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

Команда SET DSTRACE = ON создает экран консоли Directory Services ("Служба справочника"). Большинство команд DSTRACE просто устанавливают или отменяют фильтры и определяют, какие типы операций службы NDS отображать на экране Directory Services. По умолчанию фильтры установлены таким образом, чтобы отображался минимальный полезный объем информации, а именно какой сервер в сети и какой раздел находится в процессе синхронизации. С помощью команды SET DSTRACE = IN вы также можете посмотреть входящий трафик службы справочника. Полный список команд DSTRACE можно найти на Web-сервере фирмы Novell.

Однако есть один вопрос, ответ на который не столь очевиден. Иногда синхронизация множества копий одного раздела может завершиться выдачей сообщения: Synch: end synch of partition [containername] All processed = NO ("Синхронизация: окончена синхронизация копий раздела [имя контейнера] Все копии обработаны = Нет"). Хотя оно и указывает на возникновение проблемы в одном из серверов, но еще не означает, что синхронизация не выполнилась ни на одном из них.

Профилактика

Каждую рабочую неделю мы начинаем с выполнения операции синхронизации времени. Мы также проверяем обмен информацией NDS, используя опцию View Remote Server IDs ("Просмотр идентификаторов удаленных серверов") из утилиты DSREPAIR. Последний из указанных выше еженедельных "ритуалов" регулярно подтверждает, что все разделы синхронизированы и никаких ошибок при обмене информацией между серверами выявлено не было.

Каждые 2—3 месяца мы проверяем отчет об удаленных объектах с помощью утилиты DSREPAIR (опция Check External References). Список "отмерших" объектов должен быть пуст, кроме тех случаев, когда какие-либо объекты были удалены недавно. Служба технической поддержки Novell рекомендует один раз в несколько месяцев проводить профилактический запуск опции Repair Local Database ("Восстановление локальной базы данных") из утилиты DSREPAIR. Предупреждаем: запуск этой опции приводит к тому, что несколько часов сервер будет недоступен для пользователей.

Поиск ошибок

Следуя описанным выше профилактическим процедурам, вы сможете обеспечить бесперебойную работу вашего сервиса NDS в течение многих лет. Наш проработал почти полтора года, пока не возникли осложнения со списком "отмерших" объектов, связанные с монтированием серверов. Если вы испытаете аналогичные трудности, то лучшим инструментом для их устранения будет утилита DSREPAIR. Однако перед запуском процедуры восстановления удостоверьтесь, что загружены самая свежая версия модуля DS.NLM и связанные с ней инструментальные средства. Текущие версии указанных программ вы найдете по адресу http://support.novell.com/search/patlst.htm.

Если на сервере возникает какая-либо коммуникационная ошибка, попытайтесь запустить утилиту DSREPAIR с опцией Verify Remote Server ID ("Проверить идентификатор удаленного сервера"), затем — опцию Repair Server Address ("Восстановить адрес сервера") и подождите 10 мин, чтобы проконтролировать исправление ошибок. Эффект от запуска DSREPAIR не всегда проявляется сразу, поскольку может потребоваться время для окончания процесса синхронизации.

Еще одна "хитрость" заключается в том, чтобы запустить команду консоли RESET ROUTER, которая перестраивает маршрутную таблицу в памяти сервера и может устранить ошибку в коммуникациях.

Помимо перечисленных опций, в утилите DSREPAIR предусмотрена наиболее функционально мощная опция — Full Unattended Repair ("Полное безусловное восстановление"). Она проверяет внутреннюю согласованность базы данных NDS, локализует испорченные объекты, сверяет внутренние ссылки на удаленные серверы и обычно позволяет решить большинство проблем, возникающих в NDS. Перед ее запуском было бы полезно почистить файл DSREPAIR.LOG.

Решив запустить на каком-либо сервере утилиту DSREPAIR с опцией Full Unattended Repair, лучше всего оставьте его подключенным к сети, чтобы он мог передать изменения другим серверам. При условии, что такую процедуру необходимо проделать с несколькими серверами, имея достаточный запас времени, лучше выполнять ее за один раз на одном сервере. Время, требуемое для завершения работы DSREPAIR при ее запуске последовательно на каждом сервере в действительности будет меньше, чем при запуске ее одновременно на всех серверах. Дело в том, что в последнем случае каждый из них в момент завершения очередной операции будет находиться в состоянии ожидания для связи с соответствующим сервером, на котором, в свою очередь, также запущена процедура полного восстановления.

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





  
10 '1997
СОДЕРЖАНИЕ

колонка редактора

• И вечный бой, покой нам только снится

локальные сети

• SMP-серверы

• О Европейской Директиве и экранированных кабельных проводках

• Что могут сетевые компьютеры

• Как мы переходили с NetWare на Windows NT

корпоративные сети

• Дерево NDS: профилактика и решение проблем роста

• Модернизация сети с помощью АТМ (часть II)

• Windows NT против Unix: гонка продолжается

• Unicenter TNG: от управления ЭВМ к контролю над предприятием

• Делайте то, что актуально сегодня

услуги сетей связи

• Российский рынок телефонных услуг

• Измерения в системе сигнализации №7

• Страсти по CDMA

• Системные решения для громкоговорящей трансляционной сети

интернет и интрасети

• Грядет эра Java-управления

• Активы и пассивы сетевых mass media

защита данных

• Системы RAID - хранилища данных в сетях

новые продукты

• Универсальная система доступа NEVADA, Tainet Challenger 288 - модем со спидометром

только на сервере

• Интернет в вопросах и ответах

• Технология SecureFast фирмы Cabletron Systems и концепция потокового вещания корпорации Microsoft



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх