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

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

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

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

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


Rambler's Top100

  

"Плоды" большого дерева NDS

Том Зеллер

У каждого, кто создает базу данных NDS с большим числом объектов, могут возникнуть проблемы при копировании (с сервера на сервер) описаний NDS-объектов. Мы столкнулись с такими проблемами, работая с деревом NDS, имеющим 25 000 объектов, и решили рассказать вам о них подробнее.

Дерево NDS, содержащее 25 000 объектов

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

Мы собрали дюжину монтируемых в стойку серверов Compaq с процессором Pentium. Каждый из серверов имел 160-Мбайт ОЗУ и диски общей емкостью 25 Гбайт. Память с коррекцией ошибок и контроллер RAID обеспечивали высокие скорость работы и отказоустойчивость серверов Compaq. Сеть университетского городка представляет собой магистраль FDDI и несколько сотен сетей Ethernet в различных зданиях. Серверы имеют адаптеры FDDI, с помощью которых они подсоединены напрямую к магистрали. Сеть устроена таким образом, что между любой из рабочих станций и каждым из этих серверов есть только один маршрутизатор. Чтобы обеспечить для примерно 1000 IBM-совместимых машин и ПК Macintosh университета возможность подключаться к серверам так, как если бы эти серверы имели справочник Bindery, мы решили создать все объекты "пользователь" централизованно и поместить их в один контейнер типа "подразделение" (OU). Нам не хотелось перестраивать сложную информационную систему университетского городка. Мы понимали, что, возможно, приближаемся к пределу возможностей NDS, собирая много объектов в одном контейнере, но все иные варианты распределения объектов "пользователь" по контейнерам были надуманными и лишь усложняли систему. Инженеры фирмы Novell выразили определенные сомнения относительно эффективности системы с таким большим контейнером, но все же сказали, что она должна работать.

Мы организовали прием заявок на создание пользовательского бюджета (account) при помощи регистрационной формы, помещенной на Web-сервер. Более 10 000 бюджетов были созданы за две недели осеннего семестра. Сейчас у нас более 25 000 бюджетов, причем все они находятся в одном контейнере с именем Users.

Правила разделения

Помимо определения общей структуры NDS, мы должны были решить, как разбить базу данных NDS на разделы и хранить на наших серверах их копии. Большая база данных NDS делится на части, называемые разделами (partition). Копии любого раздела могут храниться на нескольких серверах. В результате повышается отказоустойчивость сети. Любой сервер может выйти из строя, но доступ к информации NDS сохранится, так как будет использоваться копия на другом сервере. Еще одна причина дублирования разделов — желание избежать передачи NDS-запросов по медленной или дорогой линии связи распределенной сети. Этого можно достичь, если такие запросы будут обслуживаться с помощью копии раздела на локальном сервере. Использование копий разделов требуется еще и потому, что восстановление NDS с ленты хорошо выполнимо только в простой сетевой среде.

Специалисты фирмы Novell категорически не рекомендуют делать этого в системах с большим числом разделов. Они советуют постоянно поддерживать копии всех разделов. В настоящее время произвольно выбранная часть дерева NDS не может быть восстановлена с ленты, необходимо восстанавливать все дерево целиком. Создавать разделы NDS и их копии необходимо, если сервер должен представлять содержимое заданного контейнера как объекты Bindery. В этом случае он должен иметь копию для чтения и записи раздела, содержащего этот контейнер. Чтобы все 12 центральных серверов могли эмулировать Bindery, на них потребовалось разместить копии большого раздела Users.

Если подразделение хочет установить сервер в дереве NDS, мы создаем контейнер для этого подразделения и формируем отдельный раздел для данного контейнера. При этом сервер подразделения хранит главную копию нового раздела, а другие (резервные) копии этого раздела мы размещаем на центральных серверах. Сейчас наше дерево содержит 25 разделов и, за исключением раздела Users, каждый из них включает небольшое число объектов. Возникающий при таком подходе вопрос, как много резервных копий могут хранить наши центральные серверы без заметных отрицательных последствий для своей работы, представляется довольно важным, но, к сожалению, ответа на него у нас нет.

Возникновение проблем

Существование 12 копий раздела Users породило большое число операций копирования. Каждый раз при создании объекта "пользователь" сервер, поддерживающий эту операцию, должен был передавать соответствующие новые данные NDS другим 11 серверам, и каждый раз, когда пользователь входил в сеть, содержимое поля "Время последнего входа в сеть" (last login time) обновлялось и дублировалось (на другие серверы). При создании и удалении объектов "пользователь" и "группа" копирование необходимой информации осуществлялось немедленно. В случае менее важных полей (в NDS) изменения накапливались и дублировались только спустя 30 мин. Следует отметить, что во всех таких случаях дублируется только изменение, а не все содержимое раздела. Однако, когда мы активно создавали тысячи объектов "пользователь" каждый день, а сами пользователи оживленно входили в сеть и выходили из нее, количество изменений в разделе Users было существенным. При создании нового объекта "пользователь" другим серверам передается около 16 Кбайт информации.

К сожалению, начав работать с нашей обновленной сетью, при дублировании изменений мы столкнулись с некоторыми серьезными проблемами. В течение трех месяцев трижды раздел Users не синхронизовался, и попытки возобновить нормальную работу сети с помощью утилиты DSRepair не увенчались успехом. Инженеры фирмы Novell решили первые две проблемы, войдя в систему с использованием программы pcANYWHERE и отредактировав напрямую файлы базы данных NDS. В третьем случае поврежденный объект остановил процесс синхронизации (разделов NDS). Сервер должен был переслать тысячи изменений раздела Users другому серверу, но поскольку один объект не копировался, операция дублирования изменений в целом не выполнялась. Затем этот сервер пытался посылать изменения следующему серверу, что опять оканчивалось неудачей, и так далее.

Тем временем в синхронизируемом разделе происходили новые изменения и, соответственно, число изменений, передававшихся при каждой неудачной попытке, росло. Как-то раз у всех серверов загруженность ЦП достигла 100%. Операции создания и удаления разделов NDS никогда не завершались. Каждые несколько минут, когда на какой-либо из этих серверов обрушивалась лавина изменений, процедура регистрации в NDS, обращающаяся к этому серверу, занимала 2 мин. Случилось даже так, что один сервер был недоступен целых четыре дня.

Решение проблемы

Фирма Novell разработала средство, которое помогло нам решить эту проблему. Это средство — программа DPSTAT.EXE, предоставляющая информацию о состоянии каждого раздела на каждом сервере и сообщающая имена поврежденных объектов, которые мешают дублированию. Будучи обнаруженным, поврежденный объект может быть уничтожен, что позволит синхронизации завершиться успешно. Наконец, в начале сентября прошлого года Novell выпустила новую версию модуля DS.NLM (см. раздел NDS Enhancements оперативной службы Network Computing по адресу http:// techweb.cmp.com/techweb/nc/ 701/701rev5.html), которая, кажется, полностью устранила проблему. Мы не замечали поврежденных объектов или невозможности копирования информации уже более трех месяцев. При этом не пользовались и утилитой DSRepair.

Нами сделано несколько выводов из этих случаев. Один из них состоит в том, что большой контейнер сам по себе не представляет проблемы. Если вы имеете 25 000 объектов, неважно находятся ли они в одном контейнере или распределены по разным в вашей сети, будет происходить много операций копирования. Поэтому мы не стали менять эту часть устройства системы. Хотя каждый сервер может представлять объекты, содержащиеся в 16 контейнерах как одну базу данных Bindery, при таком подходе не видно никаких преимуществ перед размещением объектов в одном контейнере. Однако у нас сложилось мнение, что поддержка 12 копий такого раздела NDS, — непомерная нагрузка для данной системы. Мы снизили число копий раздела Users до четырех, отказав, таким образом, в услугах эмуляции Bindery пользователям всех серверов, кроме этих четырех.

Другое следствие использования больших разделов — значительное время выполнения некоторых операций системного администрирования. Например, установка нового сервера, эмулирующего Bindery, требует размещения на нем новой копии раздела Users. На это необходимо около 4 ч, несмотря на то, что наши серверы оснащены 75-МГц процессорами Pentium и обмениваются данными по магистрали FDDI. Работа DSRepair также требует около 4 ч, причем услуги NDS не предоставляются почти все это время (этот процесс не затрагивает другие серверы, имеющие копию Users). Таким образом, даже незначительные проблемы могут привести к остановкам работы системы.


распечатать статью




  
5 '1996
СОДЕРЖАНИЕ

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

• Телефония через Internet: новое поле битвы?

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

• Беспроводные ЛВС: вчера, сегодня и завтра

• Недорогие коммутаторы Ethernet

• Мультимедиа и ЛВС

• Оптические дисковые автоматы

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

• Watchdog кусается

• "Плоды" большого дерева NDS

• Необычные, но невыдуманные истории

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

• Категории служб в сетях АТМ

• Будущее карманных устройств связи

• Передача данных по сетям сотовой связи

• Обзор аппаратуры SDH

• Связные заметки с выставки CeBIT

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

• Мир TCP/IP. Традиционные приложения (часть 2)

• Почтовый пакет компании Демос

• Списки рассылки: артерии информации

• Таблицы на Web

• Ваш след в Web

приложения клиент-сервер

• Связующее ПО. "Вождение" приложений по сети

• Связующее ПО. Смена веры

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

• Управляемые ИБП: защита предприятия

• Системы firewall: можете спать спокойно

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

• Сетевые принтеры: новинки на Comtek’96, Многофункциональность System 5000, Накопители TRAVAN TR-4 фирмы Seagate



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