Logo Host-telecom.com — профессиональный хостинг в Европе! Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

ATLEX Выделенные серверы: в Европе / в России.

Виртуальные серверы: в Европе / в России.

Партнерская программа

Хостинг + Certum Commercial SSL и домен в подарок

VPS: SSD, KVM, бесплатные бэкапы и администрирование 24/7

Бесплатный перенос сайта + подарки к новоселью

1.5. Файловые системы Windows NT

Windows NT 4.0 поддерживает две файловые системы: существовавшую ранее файловую систему FAT и собственную, новую файловую систему NTFS. (Все предыдущие версии поддерживали также файловую систему HPFS, разработанную для операционной системы OS/2 версии 1.х.)

FAT успешно применяется миллионами пользователей в составе различных ОС (прежде всего DOS и Windows 3.х). Однако не следует забывать, что в то время, когда она создавалась, основными устройствами для хранения данных были гибкие диски. Затем появились и жесткие диски, начался процесс наращивания их емкостей. В результате отдельные технологические решения тех дней потеряли свою актуальность.

К основным недостаткам FAT могут быть отнесены следующие:

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

Файловая система Windows NT FAT функционирует так же, как если бы она работала в среде MS-DOS или Windows. Практически можно без всяких опасений устанавливать Windows NT в существующем разделе FAT. Однако следует учитывать, что если были использованы какие-либо программы для сжатия или разбиения диска на разделы, то для чтения таких дисков скорее всего могут потребоваться специально разработанные для этих целей драйверы Windows NT. Файлы из разделов FAT могут безболезненно копироваться в разделы NTFS, но при выполнении обратной операции будет потеряна информация о правах доступа и об альтернативных связях файла.

Таким образом, если до установки Windows NT 4.0 на компьютере была установлена MS-DOS (или OS/2, если используется версия Windows NT 3.5х), то нет никакой необходимости переформатировать диск. Система преобразует FAT (или HPFS) в NTFS, сохранив всю информацию на диске. Обратное преобразование невозможно. Не стоит устанавливать NTFS только затем, чтобы использовать длинные (до 255 символов) имена файлов, так как для этих целей прекрасно подойдет и FAT. Возможность использования длинных имен файлов на FAT была введена только в версии Windows NT начиная с 3.5. Можно спокойно называть файлы и каталоги именами, выходящими за пределы традиционного для MS-DOS правила 8.3, нисколько не опасаясь, что эти файлы не будут доступны при работе в MS-DOS. Для таких файлов и каталогов будут назначены вторые, "короткие" имена.

Новая файловая система NTFS обладает лучшими показателями производительности и надежности по сравнению с FAT.

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

1.5.1. Структура файловой системы

Каждый файл на томе NTFS представлен записью в специальном файле, называемом Главной таблицей файлов (Master File Table, MFT).

В отличие от разделов FAT и HPFS все пространство тома NTFS представляет собой либо файл, либо часть файла. Основой структуры тома NTFS является Главная таблица файлов (Master File Table, MFT), которая содержит по крайней мере одну запись для каждого файла тома, включая одну запись для самой себя. Каждая запись имеет длину 2К.

Все файлы на томе NTFS идентифицируются номером файла, который определяется позицией файла в MFT. Каждый файл и каталог на томе NTFS состоит из набора атрибутов.

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

Загрузочный сектор тома NTFS располагается в начале тома, а его копия - в середине тома. Загрузочный сектор состоит из стандартного блока параметров BIOS, количества секторов в томе, а также начального логического номера кластера основной копии MFT и зеркальной копии MFT.

Файлы NTFS состоят по крайней мере из следующих атрибутов:

  • заголовок (H - header)
  • стандартная информация (SI - standard information)
  • имя файла ( FN - file name)
  • данные (data)
  • дескриптор безопасности (SD - security descriptor)

Рис. 1.5. Небольшие файлы

Небольшие файлы (small). Если файл имеет небольшой размер, то он может целиком располагаться внутри одной записи MFT размером 2К (рисунок 1.5). Из-за того, что файл может иметь переменное количество атрибутов, а также из-за переменного размера атрибутов нельзя наверняка утверждать, что файл уместится внутри записи. Однако, обычно файлы размером менее 1500 байт помещаются внутри записи MFT.

Большие файлы (Large). Если файл не вмещается в одну запись MFT, то этот факт отображается в значении атрибута "данные", который содержит признак того, что файл является нерезидентным, то есть, что файл находится вне таблицы MFT. В этом случае атрибут "данные" содержит виртуальный номер кластера для первого кластера каждого фрагмента данных (data run), а также количество непрерывных кластеров в каждом фрагменте (рисунок 1.6).

Рис. 1.6. Большие файлы

Очень большие файлы (huge). Если файл настолько велик, что его атрибут данных не помещается в одной записи, то этот атрибут становится нерезидентным, то есть он находится в другой записи таблицы MFT, ссылка на которую помещена в исходной записи о файле (рисунок 1.7). Эта ссылка называется внешним атрибутом (external attribute). Нерезидентный атрибут содержит указатели на фрагменты данных.

Рис. 1.7. Очень большие файлы

Сверхбольшие файлы (extremely huge). Для сверхбольших файлов внешний атрибут может указывать на несколько нерезидентных атрибутов (рисунок 1.8). Кроме того, внешний атрибут, как и любой другой атрибут может храниться в нерезидентной форме, поэтому в NTFS не может быть атрибутов слишком большой длины, которые система не может обработать.

Рис. 1.8. Сверхбольшие файлы

Каждый каталог NTFS представляет собой один вход в таблицу MFT, который содержит список файлов специальной формы, называемый индексом (index). Индексы позволяют сортировать файлы для ускорения поиска, основанного на значении определенного атрибута. Обычно в файловых системах FAT и HPFS используется сортировка файлов по имени. NTFS позволяет использовать для сортировки любой атрибут, если он хранится в резидентной форме.

Имеется две формы списка файлов.

Небольшие списки файлов (small indexes). Если количество файлов в каталоге невелико, то список файлов может быть резидентным в записи в MFT, являющейся каталогом (рисунок 1.9). В этом случае он называется небольшим каталогом. Небольшой список файлов содержит значения атрибутов файла. По умолчанию это имя файла, а также номер записи MTF, содержащей начальную запись файла.

Рис. 1.9. Небольшие каталоги

Большие списки файлов (large index). По мере того, как каталог растет, список файлов может потребовать нерезидентной формы хранения. Однако начальная часть списка всегда остается резидентной в корневой записи каталога в таблице MFT (рисунок 1.10). Имена файлов резидентной части списка файлов являются узлами B-дерева. Остальные части списка файлов размещаются вне MFT. Для их поиска используется специальный атрибут "размещение списка" (Index Allocation - IA), представляющий собой набор номеров кластеров, которые указывают на остальные части списка. Одни части списков являются листьями дерева, а другие являются промежуточными узлами, то есть содержат наряду с именами файлов атрибут Index Allocation, указывающий на списки файлов более низких уровней.

Рис. 1.10. Большие каталоги

1.5.2. Атрибуты файлов и каталогов

Каждый атрибут файла NTFS состоит из полей: тип атрибута, длина атрибута, значение атрибута и, возможно, имя атрибута.

Имеется системный набор атрибутов, определяемых структурой тома NTFS. Системные атрибуты имеют фиксированные имена и коды их типа, а также определенный формат. Могут применяться также атрибуты, определяемые пользователями. Их имена, типы и форматы задаются исключительно пользователем. Атрибуты файлов упорядочены по убыванию кода атрибута, причем атрибут одного и того же типа может повторяться несколько раз. Существует два способа хранения атрибутов файла - резидентное хранение в записях таблицы MFT и нерезидентное хранение вне ее. Сортировка может осуществляться только по резидентным атрибутам.

Ниже приведен список атрибутов.

  • Attribute List - определяет список атрибутов, которые являются допустимыми для данного конкретного файла;
  • File Name - этот атрибут содержит длинное имя файла, а также номер входа в таблице MFT для родительского каталога; если этот файл содержится в нескольких каталогах, то у него будет несколько атрибутов типа "File Name"; этот атрибут всегда должен быть резидентным;
  • MS-DOS Name - этот атрибут содержит имя файла в формате 8.3;
  • Version - атрибут содержит номер последней версии файла;
  • Security Descriptor - этот атрибут содержит информацию о защите файла: список прав доступа ACL и поле аудита, которое определяет, какого рода операции над этим файлом нужно регистрировать;
  • Volume Version - версия тома, используется только в системных файлах тома;
  • Volume Name - отметка тома;
  • Volume Information - номер версии NTFS;
  • Data - содержит обычные данные файла;
  • MFT bitmap - этот атрибут содержит карту использования секторов на томе;
  • Index Root - корень B-дерева, используемого для поиска файлов в каталоге;
  • Index Allocation - нерезидентные части индексного списка B-дерева;
  • External Attribute Information - содержит номер первого кластера и количество кластеров нерезидентного атрибута;
  • Standard Information - этот атрибут хранит всю остальную стандартную информацию о файле, которую трудно связать с каким-либо из других атрибутов файла, например, время создания файла, время обновления и другие.

1.5.3. Короткие имена

NTFS поддерживает имена файлов длиной до 255 символов. Имена файлов NTFS используют набор символов UNICODE с 16-битовыми символами. NTFS автоматически генерирует поддерживаемое MS-DOS имя для каждого файла. Таким образом, файлы NTFS могут использоваться в сети операционными системами MS-DOS и OS/2. Это особенно важно для файловых серверов в организациях, которые используют персональные компьютеры с этими двумя или тремя операционными системами. Создавая имена файла по схеме 8.3, NTFS также позволяет приложениям MS-DOS и Windows 3.х работать с файлами, имеющими длинные имена NTFS.

Поскольку NTFS использует набор символов UNICODE для имен файлов, существует возможность использования некоторых запрещенных в MS-DOS символов. Для генерации короткого имени файла в стиле MS-DOS NTFS удаляет все запрещенные символы, точки (кроме одной), а также любые пробелы из длинного имени файла. Далее имя файла усекается до 6 символов, добавляется тильда (~) и номер. Например, каждому недублированному имени файла добавляется ~1, повторяющиеся имена файлов заканчиваются символами ~2, ~3 и т.д. Расширение имени файла усекается до 3 символов.

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

На FAT короткое имя образуется путем использования первых 6 символов от длинного плюс знак "~" плюс цифра. Далее следует расширение файла. Если в длинном имени имеются пробелы, то они игнорируются. Если имеется несколько файлов с длинными именами, различающимися деталями за пределами первых 6 символов, то у коротких имен, соответствующих им будет изменяться последняя цифра. Если таких похожих файлов больше четырех, то первые 6 символов определяются по специальному алгоритму, а окончание имени всегда одинаково: "~5".

Например, если файл имеет имя "длинное имя файла.русское", то его короткое имя "ДЛИННО~1.РУС". Если у какоголибо файла в этом каталоге первые 6 символов имени и три символа расширения окажутся такими же, например, "длинное письмо.руслан", короткий вариант будет выглядеть так: "ДЛИННО~2.РУС".

На NTFS короткое имя образуется по несколько иному алгоритму, когда за основу берутся не первые 6 символов длинного имени, а их эквивалент в UNICODE.

Например, для файла, длинное имя которого "Очень хороший файл. С расширением", короткое имя будет выглядеть следующим образом: 9а10~1.gif

1.5.4. Надежность NTFS

NTFS является восстанавливаемой (recoverable) файловой системой. Она гарантирует согласованность данных тома, используя стандартную процедуру регистрации транзакций. Каждая операция ввода-вывода, которая изменяет файл на томе NTFS, рассматривается файловой системой как транзакция.

При модификации файла специальная компонента файловой системы - сервис регистрации файлов (Log File Service) - фиксирует всю информацию, необходимую для повторения (redo) или отката (undo) транзакции в специальном файле с именем $LogFile. Если транзакция не завершается нормально, то NTFS пытается закончить транзакцию (повторить) или производит ее откат. Этот метод обеспечивает минимальное время восстановления, однако восстанавливаются только системные данные (метаданные), пользовательские же данные могут быть утеряны.

Для обеспечения сохранности пользовательских данных используется программная поддержка массивов RAID (Redundant Array of Inexpensive Disks). В сочетании с поддержкой зеркализации дисков или расщепления с контролем четности (RAID 5) NTFS может выдержать любой одиночный сбой. В Windows NT поддерживаются уровни 0, 1 и 5.

В RAID 0 данные расщепляются на блоки по 64К, поддерживается от 2 до 32 дисков.

RAID 1 осуществляется на уровне разделов, то есть зеркализируются именно разделы. При отказе зеркализованного раздела администратор должен отменить отношения зеркализации, чтобы использовать оставшийся раздел как отдельный том. Затем можно использовать свободный раздел на другом диске, чтобы вновь установить зеркальные отношения. Зеркализации может быть подвергнут любой раздел, включая загрузочный (Boot Partition). В принципе зеркализация является более дорогим способом, чем другие, так как коэффициент использования дискового пространства составляет только 50%, с другой стороны, для небольших сетей это весьма приемлемый вариант, так как для его реализации достаточно только двух дисков.

RAID 5 требует минимум трех дисков (максимум 32 диска), поддерживает файловые системы FAT, NTFS, причем загрузочный раздел не может быть расщеплен. Если отказывает диск, входящий в состав массива RAID 5, то компьютер может продолжать работу и получать доступ к данным. Однако данные отказавшего диска будут в течение всего времени регенерироваться на основании данных других дисков, и производительность системы может упасть. Можно воссоздать данные отказавшего диска на новом диске. Для этого нужно иметь свободный раздел на каком-либо работоспособном диске равного или большего размера, чем отказавший. Затем запускается процедура восстановления данных из пункта Regenerate меню Fault Tolerance утилиты Disk Manager.

NTFS поддерживает также горячее переназначение секторов, когда при возникновении ошибки из-за наличия плохого сектора данные переписываются в новый хороший сектор, а сбойный исключается из работы. Администратор уведомляется с помощью утилиты просмотра событий Event Viewer о всех событиях, связанных с обработкой сбойных секторов, а также о потенциальной угрозе потери данных, если избыточная копия также отказывает.

1.6. Управление вводом-выводом

При разработке подсистемы ввода-вывода Windows NT ставились следующие задачи:

  • обеспечить поддержку нескольких файловых систем: FAT, CDFS, NTFS;
  • предоставить средства для упрощения разработки драйверов устройств, в том числе для SMP-платформ;
  • обеспечить возможность динамического добавления и удаления драйверов из системы;
  • обеспечить возможность ввода-вывода для отображаемых в памяти файлов.

Компоненты системы ввода-вывода представлены на рисунке 1.11. Каждый запрос на ввод-вывод представлен пакетом IRP (I/O Request Packet). Пакеты передаются от одной подсистемы ввода-вывода к другой. Менеджер ввода-вывода определяет порядок доставки пакетов IRP файловым системам и драйверам устройств. Менеджер не выполняет операций ввода-вывода, он только создает пакет IRP, передает его нужному драйверу и удаляет пакет, когда операция завершается. Драйвер же, получив IRP, выполняет операцию ввода-вывода, а затем возвращает пакет менеджеру для уничтожения или передачи другому драйверу.

Термин "драйвер" в Windows NT имеет более широкое значение, чем "драйвер устройства". Файловая система - это сложный драйвер, который принимает запросы к файлам и передает свои более конкретные запросы драйверам физических устройств.

Рис. 1.11. Компоненты системы ввода-вывода Windows NT

Кроме передачи пакетов, менеджер ввода-вывода выполняет следующие действия:

  • предоставляет драйверам некоторые общие функции, например, для вызова одного драйвера другим,
  • управляет буферами для запросов ввода-вывода,
  • управляет тайм-аутом для драйверов,
  • ведет записи о том, какие файловые системы установлены.

Unix в свое время представил новую упрощенную модель ввода-вывода. Все независимые данные представлялись в виде потока байтов, который направлялся в виртуальный файл; этот файл мог быть терминалом, межпроцессным конвейером или "настоящим" файлом. В Windows NT тоже принят этот подход. Запросы к виртуальным файлам менеджер ввода-вывода динамически направляет к реальным файлам: каталогам, физическим устройствам, конвейерам, почтовым ящикам или к любым адресатам, которые будут поддерживаться в будущем.

Особенностью Windows NT является общая структура ее драйверов и широкое определение того, что собой представляет драйвер. В Windows NT и драйвер устройства, и драйвер ФС построены единым образом, и для остальной части ОС имеют один и тот же вид. Более того, редиректоры и именованные конвейеры также выглядят как "файловые системы" и реализованы в виде драйверов. Каждый драйвер - это самодостаточный компонент, который может быть динамически добавлен или удален из системы.

Основные черты модели драйвера:

  • Драйверы переносимы. Они написаны на языке высокого уровня и мало зависят от архитектуры процессора (драйверы высокого уровня, такие как файловая система, совсем не зависят).
  • Операции ввода-вывода управляются пакетами IRP.
  • Система ввода-вывода может динамически назначать драйверы для новых устройств при изменении конфигурации системы.
  • Драйверы должны синхронизировать свой доступ к глобальным данным драйвера - из-за того, что выполнение драйвера может быть прервано либо высокоприоритетной нитью, либо высокоприоритетным прерыванием. Кроме того, драйвер может выполняться на многопроцессорном компьютере, что повышает вероятность одновременного обращения нескольких копий драйвера к общим глобальным данным.
  • Интерфейс драйверов с менеджером ввода-вывода стандартизирован, что позволяет менеджеру вызывать их "вслепую", не зная их особенностей или структур внутренних данных. Драйверы могут также вызывать друг друга (через менеджер ввода-вывода) для достижения многоуровневой обработки запросов ввода-вывода.

В Windows NT чаще используется многоуровневая модель обработки запроса ввода-вывода, но для простых устройств может применяться и одноуровневая модель, когда менеджер вызывает только драйвер устройства. Может использоваться не только двухуровневая модель (как, например, файловый драйвер - драйвер устройства), но и модель с большим числом уровней. Например, если в компьютере есть SCSI-адаптер, к которому подключен диск, то запрос к такому диску проходит через 3 драйвера: драйвер файловой системы, драйвер класса дисков, драйвер SCSI-порта.

Ввод-вывод в отображаемые файлы - это важное свойство Windows NT, которое обеспечивается как менеджером ввода-вывода, так и менеджером виртуальной памяти. Менеджер виртуальной памяти делает это свойство доступным для пользовательского режима. Подсистемы окружения (например, Win32) могут использовать эти сервисы менеджера виртуальной памяти для предоставления возможности отображения файлов своим приложениям.

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

Использование отображенных файлов резко увеличивает производительность системы.

Один из компонентов системы ввода-вывода - менеджер кэша - использует механизм отображенного ввода-вывода для управления своим кэшем, расположенным в оперативной памяти. Файловые системы и сетевой сервер используют этот кэш для размещения в нем часто используемых файловых данных. Тогда как в большинстве файловых систем объем кэша фиксированный, в Windows NT кэш растет или уменьшается в зависимости от наличия свободной физической памяти. Обращение к части файла, расположенной в кэше, является гораздо более быстрым.

1.7. Встроенная сетевая поддержка

В отличие от большинства других операционных систем, Windows NT изначально разрабатывалась с учетом возможности работы в сети. В результате этого функции совместного использования файлов, устройств и объектов встроены в интерфейс с пользователем. Администраторы могут централизовано управлять и контролировать работу сетей в масштабах крупных предприятий.

Сетевые функции Windows NT реализуются многими программными компонентами, и две наиболее важные из них имеют самую долгую историю в сетях Microsoft: редиректор и сетевой сервер. Как и в сети MS-NET, редиректор переправляет локальные запросы ввода-вывода на удаленный сервер, а сервер принимает и обрабатывает эти запросы.

Первые варианты редиректора и сервера Microsoft были написаны на ассемблере и располагались над существующим системным программным обеспечением MS-DOS. Новые редиректор и сервер встроены в Windows NT, они не зависят от архитектуры аппаратных средств, на которых работает ОС. Они написаны на С и выполнены как загружаемые драйверы файловой системы, которые могут загружаться или выгружаться в любое время. Они также могут сосуществовать с редиректорами и серверами других производителей.

Сетевой редиректор обеспечивает средства, необходимые одному компьютеру Windows NT для доступа к ресурсам другого компьютера по сети. Редиректор Windows NT обеспечивает доступ к удаленным файлам, именованным конвейерам и принтерам. Так как он поддерживает SMB-протокол, то он работает с существующими серверами MSNET и LAN Manager, обеспечивая доступ к системам MS-DOS, Windows и OS/2 из Windows NT.

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

Как и редиректор, сервер Windows NT на 100% совместим с существующими SMB-протоколами MS-NET и LAN Manager. Эта полная совместимость позволяет серверу обрабатывать запросы, исходящие не только от систем Windows NT, но и от других систем, работающих с программным обеспечением LAN Manager. Как и редиректор, сервер выполнен в виде драйвера файловой системы.

Может показаться странным, что сервер не реализован как серверный процесс пользовательского режима. Было бы логично ожидать, что сетевой сервер будет функционировать как защищенная подсистема - процесс, чьи нити ожидают поступления запросов по сети, выполняют их, а затем возвращают результаты по сети. Этот подход как наиболее естественный был тщательно рассмотрен при проектировании Windows NT, однако, учитывая опыт построения сетей VAX/VMS и опыт использования RPC, было решено для повышения производительности выполнить сервер как драйвер файловой системы. Хотя сервер и не является драйвером в обычном смысле, и он не управляет файловой системой на самом деле, использование модели драйвера обеспечивает некоторые преимущества.

Главное из них состоит в том, что драйвер реализован в среде NT executive и может вызывать кэш-менеджер NT непосредственно, что повышает скорость передачи данных. Например, когда сервер получает запрос на чтение большого количества данных, он вызывает кэш-менеджер для определения места расположения этих данных в кэше (или для загрузки этих данных в кэш, если их там нет) и для фиксации данных в памяти. Затем сервер передает данные непосредственно из кэша в сеть, исключая ненужные доступ к диску или копирование данных. Аналогично, при запросе на запись данных сервер вызывает кэш-менеджер для резервирования места для поступающих данных. Затем сервер пишет данные непосредственно в кэш. Записывая данные в кэш, сервер возвращает управление клиенту гораздо быстрее; затем кэш-менеджер записывает данные на диск в фоновом режиме (используя страничные средства менеджера виртуальной памяти).

Windows NT поддерживает не только сети Microsoft, но и другие за счет использования следующих средств:

  • Доступ к файловым системам, не совместимым с Microsoft, для подключения к ресурсам, удаленным файлам и устройствам ввода-вывода через общий интерфейс Win32 API (WNet API).
  • Несколько драйверов сетевого транспортного протокола могут быть загружены в одно и то же время, редиректоры для доступа к ним используют общий интерфейс.
  • Windows NT обеспечивает интерфейс и среду NDIS 3.0 для драйверов сетевых адаптеров для доступа к транспортным драйверам Windows NT.

За последние десятилетия получили распространение различные протоколы передачи информации по сети. Хотя Windows NT и не поддерживает все транспортные протоколы, она, по крайней мере, разрешает включать их поддержку, если есть их реализации третьими фирмами.

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

Windows NT решает эту проблему использованием единого программного интерфейса, называемого transport driver interface (TDI) - интерфейс транспортных драйверов для редиректоров и других высокоуровневых сетевых драйверов. TDI позволяет редиректорам и драйверам оставаться независимым от транспорта. Таким образом, одна версия редиректора или сервера может пользоваться любым транспортным механизмом, как показано на рисунке 1.12.

Рис. 1.12. Интерфейс транспортных драйверов

TDI обеспечивает набор функций, которые редиректоры могут использовать для пересылки любых типов данных с помощью транспортного уровня. TDI поддерживает как связи с установлением соединения (виртуальные связи), так и связи без установления соединения (датаграммные связи). Microsoft Windows NT обеспечивает следующие транспорты:

  • NetBEUI (NetBIOS Extended User Interface) - это транспортный протокол локальной сети, рассчитанный на односегментные сети.
  • TCP/IP - транспорт, используемый в Internet и ОС Unix.
  • IPX/SPX - набор транспортных протоколов, используемых Novell в сетях NetWare.
  • DECnet транспорт - это протокол, используемый корпорацией DEC, который позволяет Windows NT связываться с сетями DECnet.
  • AppleTalk - протокол, разработанный фирмой Apple Computer, который позволяет системам Apple Macintosh взаимодействовать с Windows NT.
  • XNX - это протокол Xerox Corporation, который использовался в ранних сетях Ethernet.
  • VINES - протокол сетей Banyan VINES.

Сетевые адаптеры поставляются вместе с сетевыми драйверами, которые раньше часто писались в расчете на взаимодействие с определенным транспортным протоколом - например, XNS или TCP/IP. Так как Windows NT позволяет загружать драйверы различных транспортных протоколов, то производители сетевых адаптеров, использующие такой подход, должны были бы писать для одного сетевого адаптера несколько сетевых драйверов, поддерживающих несколько транспортных протоколов. Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и среду, называемые "спецификация интерфейса сетевого драйвера" (NDIS - Network Driver Interface Specification), которые экранируют сетевые драйверы от деталей различных транспортных протоколов (рисунок 1.13).

Вместо написания транспортно-зависимого драйвера для Windows NT, сетевые производители придерживаются интерфейса NDIS. Таким образом, пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т.п.), используя один сетевой адаптер и один сетевой драйвер. Каждый драйвер NDIS ответственен за посылку и прием пакетов через свое сетевое соединение, а также за управление сетевым адаптером.

Рис. 1.13. NDIS-интерфейс

Windows NT обладает средствами для создания и выполнения распределенных приложений. Под распределенной обработкой раньше обычно понимали файловый и принтерный сервис.

Теперь под распределенной обработкой понимают более сложные механизмы модели клиент-сервер. Вместо хранения больших файлов баз данных на удаленной машине и копирования их для обработки на локальную машину каждый раз, когда пользователь хочет сделать запрос к базе данных, программное обеспечение, такое как Microsoft SQL Server, позволяет пользователю передать запрос на поиск в базе данных на удаленной машине. После завершения обработки операций поиска и сортировки на удаленной машине на пользовательскую машину возвращаются только результаты поиска. Такие вычисления по схеме клиент-сервер минимизируют нагрузку на сеть и загружают удаленный процессор, оставляя локальный процессор свободным. Преимущество подобных приложений состоит в том, что они используют процессорные циклы удаленных, часто более мощных компьютеров.

ОС должна обеспечивать средства для успешной реализации сетевых вычислений по схеме клиент-сервер. Вызов удаленных процедур (Remote Procedure Call - RPC) - является одним из таких средств, которое позволяет программисту создавать приложение, состоящее из любого количества процедур, некоторые из которых выполняются локально, а некоторые - выполняются на удаленных компьютерах через сеть.

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

1.8. Доменная справочная служба Windows NT

Домены позволяют структурировать сеть и упрощать задачи администрирования и управления. На основе доменов строится справочная служба сетей Windows NT.

Домен - это совокупность пользователей, серверов и рабочих станций, учетная информация о которых централизованно хранится в общей базе данных, называемой базой SAM (Security Accounts Manager database). Над этой базой данных реализована справочная служба Directory Services, которая, как и любая централизованная справочная служба, устраняет дублирование учетных данных в нескольких компьютерах и сокращает число рутинных операций по администрированию. Наличие общей базы учетных данных дает возможность пользователям получать доступ ко всем ресурсам домена при однократном логическом входе в этот домен.

Если администратор завел пользователя домена, то он имеет возможность зарегистрироваться на любой рабочей станции в этом домене. Для этого достаточно ввести имя, имя домена и пароль при регистрации, и Windows NT Workstation опознает пользователя и воссоздаст его рабочую среду.

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

Если запросы пользователей локализуются в пределах некоторой совокупности компьютеров, то каждую такую совокупность пользователей и компьютеров рационально объединить в один домен. Компьютерами Windows NT Server и Windows NT Workstation, являющиеся членами домена, можно управлять централизовано. Это значит, что с помощью утилиты Server Manager администратор может просматривать список сервисов, которые работают на удаленном компьютере точно так, же, как он это делает с помощью кнопки Services утилиты Control Panel локально. Кроме того, администратор может запускать или останавливать сервисы на удаленном компьютере, а также создавать и давать права на доступ к разделяемым каталогам и принтерам удаленных компьютеров - членов домена. К сожалению, такое централизованное управление возможно только компьютерами под управлением Windows NT Server или Windows NT Workstation, но не Windows 95 или Windows for Workgroups.

По сравнению со справочными службами NDS компании Novell или StreetTalk компании Banyan справочная служба Windows NT пока проигрывает в отношении функциональности и масштабируемости. В Windows NT нет иерархического упорядочивания ресурсов - списки пользователей и компьютеров плоские, а в больших организациях возможность распределения ресурсов по производственной иерархии очень важна, и NDS и StreetTalk ее поддерживают.

В отличие от справочной службы NDS NetWare база данных каждого домена не является распределенной. А значит при репликации она может копироваться только целиком. Это вынуждает в больших сетях создавать несколько доменов. Наличие копий SAM BP снижает нагрузку на первичный контроллер домена, но не снимает вопрос о возможности работы на одном компьютере базы, описывающей десятки тысяч пользователей.

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

Компания Microsoft собирается повысить функциональные возможности своей справочной службы в версии Windows NT 5.0, а в версии до 4.0 включительно для создания иерархической и масшитабируемой службы предлагается использовать механизм доверительных отношений (trust relationships).

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

Назад | Содержание | Вперед

 

хостинг сайтов ГиперХост — хостинг сайтов который Вы искали.

Виртуальный хостинг, Аренда VPS серверов, рация доменных имен, SSL сертификаты

💰 Самые низкие цены на домены

🔒 Отличный хостинг на SSD c бесплатными SSL

💻 Огромнейший выбор dedicated выделенных серверов

Новости мира IT:

Архив новостей

Последние комментарии:

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...