Распределенные операционные системы и среды Сетевые и

Распределенные операционные системы и среды

Сетевые и распределенные ОС • Компьютерная сеть – совокупность из нескольких компьютеров, объединённых посредством телекоммуникаций для обеспечения совместного использования данных и/или ресурсов. • Сетевая ОС предоставляет пользователю виртуальную вычислительную систему, работать с которой проще, чем с реальной сетевой аппаратурой. В то же время эта виртуальная система не полностью скрывает распределенную природу своего реального прототипа.

Термин “сетевая операционная система” используется в двух значениях: 1. Совокупность взаимодействующих ОС всех компьютеров сети. 2. Операционная система отдельного компьютера, позволяющая ему работать в сети.

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

Существует два типа распределенных операционных систем. 1. Мультипроцессорная операционная система (multiprocessor operating system) управляет ресурсами мультипроцессора. 2. Мультикомпьютерная операционная система (multicomputer operating system) разрабатывается для гомогенных мультикомпьютеров.

Зарождение компьютерных сетей • Компьютерные сети – логический результат развития двух научных и технологических областей современной цивилизации – коммуникаций и компьютерных технологий.

1950 -е годы. Эпоха мэйнфреймов Система пакетной обработки данных

1960 -е годы. Многотерминальные системы

1960 -е годы. Многотерминальные системы • Многотерминальные системы, работающие в режиме разделения времени – первый шаг на пути создания локальных вычислительных сетей. • Вычислительная мощность полностью централизована. • Функции ввода и вывода распределены. • Законом Гроша называют следующее замечание о производительности компьютеров, сделанное Хербом Грошем в 1965 году: «Существует фундаментальное правило, которое я скромно называю законом Гроша: получение добавочной экономии есть только квадратный корень от увеличения в скорости — то есть, чтоб сделать вычисления в 10 раз дешевле, вы должны сделать это в 100 раз быстрее. » • Следующий толчок к развитию – доступ удалённых терминалов к ресурсам мейнфрейма

Конец 60 -х, начало 70 -х. Зарождение первых глобальных сетей • Использование старых глобальных коммуникаций – телефонных сетей. • С конца 60 -х передача голоса в телефонных сетях всё больше переходит в цифровую форму. • WAN (Wide Area Network). Первые технологии, с поправкой на низкое качество каналов связи. (пакетная сеть X. 25). • 1969 – Министерство Обороны США инициировало создание ARPANET (Advanced Research Project Agency), объединившую суперкомпьютеры различных типов, работавших под разными операционными системами.

Начало 70 -х. Появление БИС. Первые ЛВС (LAN) • Появление БИС (Large-scale integrated circuits) подтолкнуло прогресс. Появились «миникомпьютеры» , нарушившие в т. ч. «закон Гроша» • ЛВС (локальные сети) – это объединения компьютеров, сосредоточенных на небольшой территории. • Сетевая технология – согласованная совокупность программных и аппаратных средств (например, драйверов, сетевых устройств, кабелей и т. д. ), а так же механизмов передачи данных по линиям связи, достаточный для построения вычислительной сети

Начало 70 -х. Появление БИС. Первые ЛВС (LAN)

80 -Е. Стандартизация сетевых технологий. • 1974 – появление архитектуры SNA, стандартизация технологии X. 25. • Начало 80 -х. Появление персональных компьютеров, создание Интернета в современном виде, широкое внедрение стека TCP/IP. • Середина 80 -х. Появление стандартных технологий локальных сетей. Ethernet – 1980, Token Ring, FDDI – 1985. • Конец 80 -х. Начало коммерческого использования Интернета.

90 -е. Бум Ethernet. Появление WWW • Среди технологий локальных сетей выявился явный лидер – Ethernet. • Дальнейшее развитие 100 Мбит/c и 1000 Мбит/c стандартов Ethernet. • Оптоволоконный бум. • Тим Бернерс-Ли автор технологий HTTP, URI/URL и HTML. 1989 – внутренний проект для CERN. 1991 – 1993 доработка стандартов и их публикация. • 1994 – начало работы W 3 C консорциума.

Функциональные компоненты сетевой ОС МД Принтер DVD Средства управления локальными ресурсами Сетевые средства Серверная часть Клиентская часть Редиректор Сетевая операционная система Транспортные средства (сетевые службы) В сеть Сетевая служба: серверная и клиентская части

Cредства управления локальными ресурсами компьютера реализуют все функции ОС автономного компьютера (распределение оперативной памяти между процессами, планирование и диспетчеризацию процессов, управление процессорами в мультипроцессорных машинах, управление внешней памятью, интерфейс с пользователем и т. д. ); Cетевые средства можно разделить на три компонента: 1. средства предоставления локальных ресурсов и услуг в общее пользование — серверная часть ОС; 2. средства запроса доступа к удаленным ресурсам и услугам — клиентская часть ОС; 3. транспортные средства ОС, которые совместно с коммуникационной системой обеспечивают передачу сообщений между компьютерами сети.

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

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

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

Клиент-серверная природа сетевых служб

Клиенты, рабочие станции, хосты, узлы Клиенты сети – компьютеры и другие сетевые устройства (например, принтеры), имеющие доступ к ресурсам сети, также программы, имеющие доступ к программам сервера. Чаще всего клиент – компьютер пользователя сети. Клиенты-компьютеры могут быть “тонкими” и “толстыми” клиентами. Рабочая станция: 1. Клиентский (пользовательский) компьютер, на котором установлена клиентская операционная система. 2. Высокопроизводительный компьютер, интенсивно использующий локальные и сетевые ресурсы. Хост – компьютер или другое устройство сети, имеющее IP-адрес. Узел – точка соединения в сети – компьютер или другое устройство, предназначенное для распознавания и обработки запросов на передачу информации другим узлам сети.

Варианты построения сетевых ОС На практике сложилось несколько подходов к построению сетевых операционных систем, различающихся глубиной внедрения сетевых служб в операционную систему: 1. сетевые службы глубоко встроены в ОС; 2. сетевые службы объединены в виде некоторого набора — оболочки; 3. сетевые службы производятся и поставляются в виде отдельного продукта.

2 Операционная система 3 Операционная система Встроенные сетевые службы (UNIX, Windows 2000, Net. Ware) Сетевая оболочка (набор сетевых служб) – LAN Manager, LAN Server 1 Операционная система Серверная Клиентск оболочка ая ОС: VAX VMS, VM, оболочка OS/400, OS/2, AIX Сетевые службы отдельные продукты (Win. Frame – для работы в среде Windows NT, Net. Ware Connect – для работы в среде Net. Ware)

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

Локальная часть К С Транспорт Локальная часть К К С Транспорт Одноранговая сеть Локальная часть К С Транспорт

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

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

Типовые функциональные части приложений: 1. Средства представления данных на экране (графический пользовательский интерфейс). 2. Логика представления данных на экране – описание правил и возможностей сценариев взаимодействия пользователя с приложением. 3. Прикладная логика – набор правил для принятия решения, вычислительные процедуры и операции. 4. Логика данных – операции с данными, хранящимися в базе данных, которые нужно выполнить для реализации прикладной логики. 5. Внутренние операции базы данных – действия СУБД в ответ на запросы логики данных (поиск записей по определенным признакам). 6. Файловые операции – стандартные операции над

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

Два крайних случая двухзвенной схемы: нагрузка в основном ложится на один узел — либо на центральный компьютер, либо на клиентскую машину. В централизованной схеме (1) компьютер пользователя работает как терминал, выполняющий лишь функции представления данных, тогда как все остальные функции передаются центральному компьютеру. Ресурсы компьютера пользователя используются в этой схеме в незначительной степени, загруженными оказываются только графические средства подсистемы ввода-вывода ОС, а также сетевые средства ОС. Программа, работающая на компьютере пользователя, называется эмулятором терминала — графическим или текстовым, в зависимости от поддерживаемого режима. Фактически эта схема повторяет организацию многотерминальной системы на базе мэйнфрейма, но вместо терминалов используются компьютеры, подключенные не через локальный интерфейс, а через сеть, локальную или глобальную.

Модели распределенных приложений Компьютер 1 1. Двухзвенные схемы Компьютер 2 Логика Операции приложения и базы обращения к базе данных Эмуляция терминала сервера Тонкий клиент (thin client) Сервер баз данных Компьютер 1 2. Интерфейс пользователя Файловые операции Логика приложения и обращения к базе данных Компьютер 2 Операции базы данных Толстый клиент (thick client) Файловые операции Сервер файлов

В схеме «файловый сервер» (2) на клиентской машине выполняются все части приложения, кроме файловых операций. В сети имеется достаточно мощный компьютер, имеющий дисковую подсистему большого объема, который играет роль файлового сервера. Распределенное приложение в этой схеме мало отличается от полностью локального приложения. Тонкий клиент — компьютер или программа-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер. Толстый или Rich-клиент в архитектуре клиент-сервер — это приложение, обеспечивающее (в противовес тонкому клиенту) расширенную функциональность независимо от центрального сервера.

Сравнение размеров — тонкий клиент в сравнении с традиционным настольным ПК Аппаратный тонкий клиент (например, Windows- и Linuxтерминалы) — специализированное устройство, принципиально отличное от ПК. Аппаратный тонкий клиент не имеет жёсткого диска, использует специализированную локальную ОС (одна из задач которой организовать сессию с терминальным сервером для работы пользователя), не имеет в своём составе подвижных деталей, выполняется в специализированных корпусах с полностью пассивным охлаждением.

Компьютер 1 Интерфейс пользователя Логика приложения и обращения к базе данных Клиент Компьютер 2 Операции базы данных Файловые операции Сервер 3. Оптимальное использование сильных сторон сервера и клиента Наиболее часто используется схема, в которой на серверный компьютер возлагаются функции проведения внутренних операций базы данных и файловых операций (3). Клиентский компьютер при этом выполняет все функции, специфические для данного приложения, а сервер — функции, реализация которых не зависит от специфики приложения, из-за чего эти функции могут быть оформлены в виде сетевых служб.

Трехзвенные схемы Компьютер 1 Интерфейс пользователя Клиент Компьютер 2 Логика приложения и обращения к базе данных Сервер приложений Компьютер 3 Операции базы данных Файловые операции Сервер баз данных На клиентской машине выполняются средства представления и логика представления, а также поддерживается программный интерфейс для вызова частей приложения второго звена — промежуточного сервера. Промежуточный сервер называют в этом варианте сервером приложений, так как на нем выполняются прикладная логика и логика обработки данных, представляющих собой наиболее специфические и важные части большинства приложений. Слой логики обработки данных вызывает внутренние операции базы данных, которые реализуются третьим звеном схемы — сервером баз данных. Цель – позволить приложению (клиенту) получить доступ к различным серверным сервисам, не беспокоясь о различиях между серверами

Два способа организации файловых операций Файловая система ОС должна предоставлять пользователям набор операций работы с файлами, оформленный в виде системных вызовов. Этот набор обычно состоит из таких системных вызовов, как create (создать файл), read (читать из файла), write (записать в файл) и некоторых других. Чаще всего с одним и тем же файлом пользователь выполняет не одну операцию, а последовательность операций. После большого количества операций чтения и записи пользователь завершает работу с данным файлом и переходит к другому. Какие бы операции не выполнялись над файлом, ОС необходимо выполнить ряд универсальных для всех операций действий: 1. По символьному имени файла найти его характеристики, которые хранятся в файловой системе на диске. 2. Скопировать характеристики файла в оперативную память, так как только таким образом программный код может их использовать. 3. На основании характеристик файла проверить права пользователя на выполнение запрошенной операции (чтение, запись, удаление, просмотр атрибутов файла). 4. Очистить область памяти, отведенную под временное хранение характеристик файла. Кроме того, каждая операция включает ряд уникальных действий, например чтение определенного набора кластеров диска, удаление файла и т. п.

1. Для каждой операции выполняются как универсальные, так и уникальные действия. Такая схема называется схемой без запоминания состояния операций (stateless). 2. Все универсальные действия выполняются в начале и конце последовательности операций, а для каждой промежуточной операции выполняются только уникальные действия (stateful). Первый способ обладает одним преимуществом — он более устойчив к сбоям в работе системы, так каждая операция является самодостаточной и не зависит от результата предыдущей. Поэтому первый способ иногда применяется в распределенных сетевых файловых системах (например, в Network File System, NFS компании Sun), когда сбои из-за потерь пакетов или отказов одного из сетевых узлов более вероятны, чем при локальном доступе к файлам.

• При втором способе в файловой системе вводятся два специальных системных вызова: open — открытие файла, и close — закрытие файла. • Системный вызов открытия файла open выполняется перед началом любой последовательности операций с файлом, а вызов закрытия файла close — после окончания работы с файлом. Основной задачей вызова open является преобразование символьного имени файла в его уникальное числовое имя, копирование характеристик файла из дисковой области в буфер оперативной памяти и проверка прав пользователя на выполнение запрошенной операции. Вызов close освобождает буфер с характеристиками файла и делает невозможным продолжение операций с файлом без его повторного открытия. Подавляющее большинство файловых систем поддерживает второй способ организации файловых операций как более экономичный и быстрый.

Файловые серверы типа stateful и stateless Файловый сервер может быть реализован по одной из двух схем: 1. без запоминания данных о последовательности файловых операций клиента, то есть по схеме stateless. 2. с запоминанием данных о последовательности файловых операций клиента, то есть по схеме stateful.

Для сервера stateless каждый запрос должен содержать исчерпывающую информацию (полное имя файла, смещение в файле и т. п. ), необходимую серверу для выполнения требуемой операции. Эта информация увеличивает длину сообщения и время, которое тратит сервер на локальное открытие файла. Серверы, работающее по схеме stateless, не поддерживают в протоколе обмена с клиентами таких операций, как открытие (open) и закрытие (close) файлов. Принципиально набор команд, предоставляемый клиенту, может состоять только из двух команд: read и write. Эти команды должны передавать в своих аргументах всю необходимую для сервера информацию — имя файла, смещение от начала файла и количество читаемых или записываемых байт данных. • Когда клиент посылает запрос на сервер stateless, сервер его выполняет, отсылает ответ, а затем удаляет из своих внутренних таблиц всю информацию о запросе. Между запросами на сервере не хранится никакой текущей информации о состоянии клиента

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

Серверы stateful работают по схеме, обычной для любой локальной файловой службы. Такой сервер поддерживает тот же набор вызовов, что и локальная система, то есть вызовы open, read, write, seek и close. Открывая файлы по вызову open, переданному по сети клиентом, сервер stateful должен запоминать в своей внутренней системной таблице, какие файлы открыл каждый пользователь. Обычно при открытии файла клиентскому приложению возвращается по сети дескриптор файла fd или другое число, которое используется при последующих вызовах для идентификации файла. При поступлении вызова read, write или seek сервер использует дескриптор файла для определения, какой файл нужен. В этой таблице хранится также значение указателя на текущую позицию в файле, относительно которой выполняется операция чтения или записи.

Сервер с сохранением состояния (stateful)

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

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

Блокировки файлов • Блокировки файлов и отдельных записей в файлах являются средством синхронизации между процессами, пытающимися использовать один и тот же файл одновременно. • Процессы могут иметь соответствующие права доступа к файлу, но одновременное использование этих прав (в особенности права записи) может привести к некорректным результатам. Примером такой ситуации является одновременное редактирование одного и того же документа несколькими пользователями. Если доступ к файлу не управляется блокировками, то каждый пользователь, который имеет право записи в файл, работает со своей копией данных файла. Результат такого редактирования непредсказуем — он зависит от того, в какой последовательности записывали изменения в файл применяемые пользователями приложения-редакторы.

• Многопользовательские ОС обычно поддерживают специальный системный вызов, позволяющий программисту установить и проверить блокировки на файл и его отдельные области. В его аргументах указывается дескриптор файла, для которого нужно установить или проверить блокировки, тип операции (блокирование или проверка, блокирование доступа для чтения или для записи), а также область блокирования — смещение от начала файла и размер в байтах. • Запрошенная блокировка записи не может быть установлена в том случае, если другой процесс уже установил свою блокировку записи на тот же файл. То есть блокировка записи является исключительной. Блокировки чтения не являются исключительными и могут устанавливаться на файл в том случае, если их области действия не перекрываются. Если на какую-то область файла установлена блокировка чтения, то на эту область нельзя установить блокировку записи.

Передача сообщений в распределенных системах Межпроцессное взаимодействие в компьютерных системах осуществляется: 1) совместным использованием данных, помещенных в разделяемую память; 2) передачей данных в виде сообщений. Сообщение – это блок информации, отформатированный процессом-отправителем таким образом, чтобы он был понятен процессу-получателю. Сообщение состоит из заголовка (обычно фиксированной длины) и набора данных определенного типа переменной длины.

Заголовок содержит: 1. Адресное поле состоит из двух частей — адреса процесса-отправителя и адреса процесса-получателя. Адрес каждого процесса может, в свою очередь, иметь некоторую структуру, позволяющую найти нужный процесс в сети, состоящей из большого количества компьютеров. 2. Последовательный номер, являющийся идентификатором сообщения. Используется для идентификации потерянных сообщений и дубликатов сообщений в случае отказов в сети. Набор данных содержит: 1. поле типа данных, указывающего, какие данные передаются; 2. поле длины данных, определяющее длину передаваемых данных; 3. поле данных, содержащее передаваемые данные.

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

TCP/UDP IP IP Ethernet Сетевой адаптер Компьютер 2 TCP/UDP Подсистема передачи сообщений Receive Подсистема передачи сообщений Приложение Send Компьютер 1 Приложение Примитивы обмена сообщениями и транспортные средства подсистемы ввода-вывода

• Транспортная подсистема сетевой ОС имеет обычно сложную структуру, отражающую структуру семиуровневой модели взаимодействия открытых систем (Open System Interconnection, OSI)

Удаленные вызовы процедур (RPC) • RPC впервые предложен фирмой Sun и реализован в ОС Solaris • Удаленный вызов процедуры (RPC) – абстракция вызова процедуры между процессами в сетевых системах • Заглушки (Stubs) – proxy в клиентской части для фактической процедуры, находящейся на сервере • Заглушка в клиентской части находит сервер и выстраивает (marshals) параметры. • Заглушка в серверной части принимает это сообщение, распаковывает параметры, преобразует их к нормальному виду и выполняет процедуру на сервере

Исполнение RPC

Структура модели ISO OSI. Функции уровней. 1. Физический уровень. (Physical Layer) На данном уровне основной единицей передачи информации является бит (bit) 2. Канальный уровень. (Data Link Layer) Основной единицей является фрейм(frame). Фрейм – особым образом сгруппированная группа битов физического уровня, к которому добавляется битовый заголовок, содержащий аппаратные адреса отправителя и получателя, контрольную сумму для определения целостности фрейма и некоторые флаги, управляющие процессом передачи. 3. Сетевой уровень. (Network Layer ) Основной единицей является пакет. Функцией данного уровня является объединение сетей. На данном уровне работает процесс маршрутизации – выбора оптимального маршрута передачи пакета. Пакет представляет собой информационный блок, содержащий информацию вышестоящего уровня, плюс заголовок, содержащий сетевые адреса отправителя и получателя и служебную информацию.

4. Транспортный уровень. (Transport Layer ) Протоколы транспортного уровня обеспечивают надежную передачу данных для протоколов более высоких уровней или для приложений. К фунциям уровня относятся обнаружение и исправление ошибок при передаче сообщения, контроль доставки, или восстановление аварийно прерванной связи, фрагментация пакетов с целью оптимизировать доставку сообщений. 5. Сеансовый уровень. (Session Layer ) Отвечает за поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. 6. Уровень представлений. ( Presentation Layer ) На данном уровне обеспечивается кодирование исходного сообщения. К примерам можно отнести представление текста в кодировке ASCII или Unicode, сжатие видео MPEG, и т. п. 7. Уровень приложений. (Application Layer ) Основной задачей данного уровня является организация интерфейса между объектом – отправителем сообщения, представление сообщения в машиннообрабатываемом виде и передача его на более низкие уровни модели.

TCP / IP • Transmission Control Protocol / Internet Protocol • Основоположники: Robert Kahn, Vinton Cerf (1972 – 1974) • Основан на использовании IP-адресов вида: a. b. c. d (четыре числа от 0 до 255) для любого хоста в сети и пакетов (packets) фиксированного размера, содержащих адрес получателя • Используется в Интернете • Более общее современное название: Internet Protocol Suite (различаются более новая версия – IPv 6 и более старая – IPv 4) • Другой вариант: UDP/IP (UDP – асинхронный транспортный протокол, обеспечивающий обмен датаграммами – байтовыми массивами переменной длины); менее надёжный, но более быстрый • Скорость TCP/IP не всегда удовлетворительна. Для оптимизации связи между узлами сети применяются Distributed Hash Tables (DHT) – распределенные хеш-таблицы и Peer-to-Peer (P 2 P) Networks – одноранговые сети. В них реализована своя система имен узлов сети и более быстрого их поиска, чем с использованием TCP/IP протоколов

Коммуникационные примитивы (send и receive) могут быть оформлены : 1. как внутренние процедуры ядра ОС (в этом случае ими могут использоваться только модули ОС) ; 2. как системные вызовы (доступные в этом случае процессам в пользовательском режиме); 3. как блокирующие или неблокирующие примитивы.

Выполнение процессаотправителя Send; приостановка выполнения Выполнение процессаполучателя Receive; приостановка выполнения Соо Тайм-аут для исключения блокировок процессов Возобновление выполнения бще ние Возобновление выполнения Синхронное взаимодействие с помощью блокирующих примитивов Send и Receive. Достоинства – простота, надежность, необходимость только 1 -го буфера. Недостатки – ограниченный параллелизм, возможность тупиков. е и жден р е тв Под При использовании блокирующего примитива Send процесс, выдавший запрос на его выполнение, приостанавливается до момента получения по сети сообщения-подтверждения о том, что приемник получил отправленное сообщение. Вызов блокирующего примитива Receive приостанавливает вызывающий процесс до момента, когда он получит сообщение.

Соо Выполнение процессаполучателя бще ние Тест – результат отрицательный е ени жд вер т Под Тест – результат отрицательный Выполнение процессаотправителя Асинхронное взаимодействие с помощью неблокирующих примитивов Send и Receive. Достоинства – производительность. Недостатки: сложность, необходимость в большом буфере, возможность потерь данных, необходимость в управлении потоком данных Тест – результат положит. При использовании неблокирующих примитивов Send и Receive управление возвращается вызывающему процессу немедленно, сразу после того, как ядру передается информация о том, где в памяти находится буфер, в который нужно поместить сообщение, отправляемое в сеть или ожидаемое из сети.

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

Сложность реализации RPC по сравнению с вызовом локальных процедур обусловлена: 1. Разными (разнесенными в пространстве) адресными полями компьютеров, что создает проблемы в передаче параметров и результатов, особенно если машины и ОС не идентичны. 2. Отсутствие разделяемой памяти означает, что значения параметров должны копироваться с одной машины на другую. 3. RPC использует нижележащую систему обмена сообщениями, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. 4. В реализации RPC участвует как минимум два процесса, аварийное завершение любого из них может привести к проблемам. 5. Неоднородность языков программирования и операционных сред.

Этапы выполнения RPC достигает прозрачности следующим путем: • Когда вызываемая процедура является удаленной, в библиотеку помещается вместо локальной процедуры другая версия процедуры, называемая клиентским стабом (stub - заглушка). Подобно оригинальной процедуре, стаб работает с использованием вызывающей последовательности, только в отличие от локальной процедуры он не помещает параметры в регистры и не запрашивает у ядра данные, вместо этого он формирует сообщение для отправки ядру удаленной машины.

Механизм RPC (использование клиентского и серверного стаба, организующих передачу параметров и возврат значения процедуры через сеть) Компьютер-клиент Процесс-клиент Return Call Компьютер-сервер Процедура RPC Call Return Выполнение Клиентский стаб Серверный стаб Упаковка параметров Распаковка параметров Сообщение: Имя, параметры Упаковка параметров Распаковка параметров Сообщение: Результат Ядро ОС RPC Runtime Receive Send Подсистема обмена сообщениями Сообщение-вызов Сообщение-ответ

Работа на клиентской стороне: 1. После того, как клиентский стаб был вызван программойклиентом, его первой задачей является заполнение буфера отправляемым сообщением. 2. Параметры должны быть преобразованы в соответствующий формат и вставлены в буфер сообщения. К этому моменту сообщение готово к передаче, поэтому выполняется прерывание по вызову ядра. 3. Когда ядро получает управление, оно переключает контексты, сохраняет регистры процессора и карту памяти, устанавливает новую карту памяти, которая будет использоваться для работы в режиме ядра. Т. к. контексты ядра и пользователя различаются, ядро должно скопировать сообщение в свое собственное адресное пространство, чтобы иметь к нему доступ, запомнить адрес назначения, и передать его сетевому интерфейсу.

• Работа на стороне сервера: 1. Поступающие биты помещаются принимающей аппаратурой либо во встроенный буфер, либо в оперативную память. 2. Когда вся информация будет получена, генерируется прерывание. Обработчик прерывания проверяет правильность данных пакета и определяет, какому стабу следует их передать. Если ни один из стабов не ожидает этот пакет, обработчик должен либо поместить его в буфер, либо вообще отказаться от него. Если имеется ожидающий стаб, то сообщение копируется ему. 3. Выполняется переключение контекстов, в результате чего восстанавливаются регистры и карта памяти, принимая те значения, которые они имели в момент, когда стаб сделал вызов receive. 4. Серверный стаб распаковывает параметры и помещает их в стек. Когда все готово, выполняется вызов сервера.

Windows Communication Foundation • Windows Communication Foundation (WCF) – это платформа корпорации Майкрософт нового поколения для построения распределенных систем. • WCF предназначена для разработки ориентированных на сервис приложений и организации обмена данными. Она поддерживает различные способы взаимодействий. В качестве сервера могут выступать как обычные, так и веб-приложения. При этом клиентом может быть приложение, построенное практически на любой платформе.

• При построении распределенной системы WCF обычно создаются три взаимосвязанных сборки. • 1. Сборка службы WCF. Эта библиотека *. dll содержит классы и интерфейсы, представляющие некую функциональность, которая предлагается внешним клиентам. • 2. Хост службы WCF. Этот программный модуль – сущность, которая принимает в себе сборку службы WCF. • 3. Клиент WCF. Это приложение, которое обращается к функциональности службы через промежуточный прокси-класс.

Общая схема взаимодействия хоста WCF и приложения клиента

• Сервис WCF - это приложение, предоставляющее для связи набор конечных точек (Endpoints). Их можно представить как точки связи с внешним миром. • Конечная точка определяется следующими характеристиками (ABC): • Адрес (Address) – задает сетевой адрес её расположения. • Связывание (Binding) – указывает параметры ее взаимодействия с внешним миром (протокол, кодирование и безопасность). • Контракт (Contract) – определяет, какие операции и данные она предоставляет клиентам от сервера. • Клиент – это программа, которая обменивается сообщениями с одной или несколькими конечными точками. Клиент, зная указанные характеристики, обращается к конечной точке для выполнения нужных ему операций.

Алгоритм применения WCF-сервиса – это всегда трехступенчатый процесс. 1. Вы определяете контракт и реализуете его в сервисе. 2. Вы выбираете или определяете связывание сервиса, оговаривающую вид протокола, способ кодирования, а также безопасность и другие вопросы. 3. Вы размещаете конечную точку контракта, привязывая ее (по имени) к сетевому адресу. • Эти три элемента независимы. Контракт может поддерживать множество привязок, а привязка может служить для нескольких контрактов. У сервиса может быть сразу много конечных точек (контрактов, привязанных к адресам), доступных одновременно. •

Сетевые файловые системы Элементы сетевой ФС: 1. Локальные ФС. 2. Интерфейсы локальной файловой системы. 3. Серверы сетевой ФС. 4. Клиенты сетевой ФС (программы, работающие на компьютерах, подключенных к сети). 5. Интерфейс сетевой ФС. 6. Протокол клиент-сервер сетевой ФС Клиент и сервер сетевой файловой системы взаимодействуют друг с другом по сети по определенному протоколу. В случае совпадения интерфейсов локальной и сетевой файловых систем этот протокол будет достаточно простым (ретрансляция серверу запросов , принятых клиентом от приложения, например, с использованием механизма RPC).

Приложения Сервер сетевой ФС Интерфейс сетевой ФС Приложения Интерфейс сетевой ФС Клиент сетевой ФС Пр сер ото ве кол рс ет кли ев ен ой т. ФС Клиент сетевой ФС Интерфейс локальной ФС Локальная ФС

Network File System (NFS) • Разработана Sun Microsystems для доступа к удаленным файлам через локальную или глобальную сеть. Изначальными требованиями при разработке NFS были: • потенциальная поддержка различных ОС; • протокол не должен зависеть от каких-либо определённых аппаратных средств; • должны быть реализованы простые механизмы восстановления в случае отказов сервера или клиента; • приложения должны иметь прозрачный доступ к удаленным файлам без использования специальных путевых имен или библиотек и без перекомпиляции; • для UNIX-клиентов должна поддерживаться семантика UNIX; • производительность NFS должна быть сравнима с производительностью локальных дисков; • реализация не должна быть зависимой от транспортных средств.

Имеет в своей истории 4 версии. • NFSv 1 была разработана в 1989 и являлась экспериментальной, работала на протоколе UDP. • NFSv 2 была выпущена в том же 1989 г при этом позволяла читать не более 2 Гб из файла. • NFSv 3 доработана в 1995 г. и описана в RFC 1813. Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCPпакетов большого размера, что существенно ускорило работоспосбоность технологии. • NFSv 4 доработана в 2000 г. и описана в RFC 3010, в 2003 г. пересмотрена и описана в RFC 3530. Четвертая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). • NFS версии v 4. 1 была одобрена IESG в 2010 г. , и получила номер RFC 5661. Важным нововведением версии 4. 1, является спецификация p. NFS — Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы дает возможность строить распределённые «облачные» хранилища и информационные системы.

Операционные системы

NFS • NFS абстрагирована от типов файловых систем как сервера, так и клиента. Взаимодействующие рабочие станции рассматриваются как набор независимых машин с независимыми файловыми системами, что позволяет совместно использовать файловые системы прозрачным образом. – Удаленная директория монтируется на локальную директорию. Смонтированная директория трактуется как полное поддерево локальной файловой системы. – Спецификация удаленной директории для операции монтирования не является прозрачной; необходимо указать имя машины с удаленной директорией. После этого файлы в удаленной директории могут быть доступны. – С учетом назначения полномочий доступа, потенциально любая файловая система (или директория внутри файловой системы), может быть смонтирована удаленно поверх локальной директории.

• NFS спроектирована для работы в неоднородном окружении различных машин, ОС и сетевых архитектур; спецификация NFS от них не зависит. • Эта независимость достигнута благодаря использованию примитивов RPC (Remote Procedure Call), реализованных поверх External Data Representation (XDR) – протокола. • Спецификация NFS различает сервисы, обеспечиваемые механизмом монтирования, и фактические удаленные файловые системы. • NFS – серверы не имеют состояния (stateless); каждый запрос должен иметь полный набор аргументов.

Протокол NFS • Предоставляет набор RPC для удаленных операций над файлами. Процедуры поддерживают следующие операции: – Поиск файла в директории – Чтение набора элементов директории – Управление ссылками и директориями – Доступ к атрибутам файлов – Чтение и запись файлов • NFS – протокол не поддерживает механизмы управления параллельным доступом • NFS - протокол осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Это означает, что любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без каких либо модификаций самой программы.

Реализация NFS состоит из нескольких компонентов. Некоторые из них локализованы либо на сервере, либо на клиенте, а некоторые используются и тем и другим. 1. Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. 2. Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC. 3. Внешнее представление данных (XDR — External Data Representation ) обеспечивает машиннонезависимый метод кодирования данных для пересылки через сеть.

4. 5. 6. 7. 8. Программный код сервера NFS отвечает за обработку всех запросов клиента и обеспечивает доступ к экспортируемым файловым системам. Программный код клиента NFS реализует все обращения клиентской системы к удаленным файлам путем посылки серверу одного или нескольких запросов RPC. Протокол монтирования определяет семантику монтирования и размонтирования файловых систем NFS. Демон mountd обрабатывает запросы монтирования. На клиенте набор демонов biod обрабатывает асинхронный ввод/вывод блоков файлов NFS. Менеджер блокировок сети (NLM — Network Lock Manager) и монитор состояния сети (NSM — Network Status Monitor) вместе обеспечивают средства для блокировки файлов в сети.

Три основных уровня архитектуры NFS • • • UNIX – интерфейс файловой системы (основан на вызовах open, read, write и close calls и на дескрипторах файлов). Уровень Virtual File System (VFS) – различает локальные и удаленные файлы, и в дальнейшем локальные файлы обрабатываются в соответствии с типами их файловых систем. – VFS активизирует операции, специфичные для конкретной файловой системы, для обработки локальных запросов в соответствии с типами файловых систем. – Вызывает процедуры NFS – протокола для удаленных запросов. NFS – сервисный уровень – нижний уровень архитектуры; реализует NFS - протокол

Схема архитектуры NFS

Протокол монтирования в NFS • Устанавливает первоначальную логическую связь между сервером и клиентом. • Операция монтирования включает имя удаленной директории, подлежащей монтированию, и имя машины-сервера, на которой она хранится. – Запрос на монтирования отображается на соответствующий RPC и передается на mount-сервер, исполняемый на серверной машине. – Export list – указывает список файловых систем, которые сервер экспортирует для монтирования, а также имена машин, на которых разрешено их монтировать. • Исполняя запрос на монтирование, соответствующий этому списку, сервер возвращает file handle—ключ к дальнейшему доступу. • File handle – идентификатор файловой системы, и номер inode (индексного узла), идентифицирующий монтируемую директорию внутри экспортируемой файловой системы. • Операция монтирования изменяет только точку зрения пользователя и не влияет на серверную часть.

Три независимых файловых системы

Монтирование в NFS Mounts Cascading mounts

Доступ к одной локальной файловой системе с помощью нескольких протоколов клиент-сервер Протокол SMB (Server Message Block – MS, Intel, IBM). Работает на прикладном уровне, используя TCP/IP (Net. BIOS, Net. BEUI), IPX. Клиент SMB Сообщение с запросом на установление соединения Подтверждение. Команды манипулирования файлами. NCP – Net. Ware Control Protocol Приложение FAT Клиент NCP Net. Ware Control Protocol Сервер NFS Сервер NCP Сервер SMB Интерфейс локальной файловой системы Локальная файловая система NTFS Клиент NFS Протокол NFS (UNIX) Network File System RAID-массивы

Рассмотрим сетевую файловую систему, построенную на базе локальной файловой системы FAT и использующую в качестве протокола клиент-сервер протокол SMB (Server Message Block), который был совместно разработан компаниями Microsoft, Intel и IBM и до сих пор является основой сетевой файловой службы в операционных системах семейства Windows (его последние расширенные версии получили название Common Internet File System, CIFS). SMB относится к классу протоколов, ориентированных на соединение. Работа протокола начинается с того, что клиент отправляет серверу специальное сообщение с запросом на установление соединения. В процессе установления соединения клиент и сервер обмениваются информацией о себе: они сообщают другу, какой диалект протокола SMB они будут использовать в этом соединении. Если сервер готов к установлению соединения, он отвечает сообщением-подтверждением.

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

Проблемы: 1. Отказ сервера сетевой ФС (локальные табл. открытых файлов). 2. Перегрузка сервера СФС (кэширование у клиента). 3. Нарушение целостности СФС (избыточность и репликация). 4. Аутентификация у клиента, авторизация на сервере.

Служба каталогов сетевых серверных ОС Служба каталогов (Directory Services) представляет собой базу данных и совокупность служб для именования, хранения и выборки информации в распределенной среде, доступных клиентам и администраторам этой среды. Причины, требующие в сети централизованной базы справочной информации: 1. Появление корпоративных информационных систем. Усложнение задач управления пользователями. Централизованное хранение учетных записей пользователей. 2. Управление сетевыми ресурсами, прозрачность доступа к сетевым ресурсам. 3. Управление сетью на основе БД о топологии сети и характеристик ее компонентов. 4. Организация управления распределенными приложениями. 5. Предоставление справочной информации для работы сетевых служб и сервисов. 6. Управления качеством обслуживания сетевого трафика. Примеры реализации службы каталогов : Novell Directory Service, Banyan Street Talk, Microsoft windows NT Directory Service, X 500 (Consultative Committee for International Telephone and Telegraph, CCITT совместно с ISO). Способы реализации: 1. Локальные базы справочных служб узкого (специализированного) назначения. 2. Единая централизованная справочная служба на основе распределенной базы данных

Служба каталога использует два типа сетей Рабочая группа Контроллер домена Windows 2000 Server Репликация Контроллер домена Локальная БД Windows 2000 Professional Службы Active Directory Домен Локальная БД Windows 2000 Professional Клиентский компьютер Локальная БД Достоинства: простота, не требуется Windows Server, удобство при небольшом количестве компьютеров при наличии опытных пользователей. Рядовой сервер Достоинства: централизованное администрирование, однократный вход в систему, удобство работы, обеспечивают масштабирование.

Архитектура Active Directory Возможности, предоставляемые службой каталогов: - централизованное управление всеми корпоративными ресурсами; - масштабируемость – способность охватывать домены, деревья, леса доменов; - расширяемость каталога c возможностью добавления новых классов объектов; - интеграция с DNS – автоматическое преобразование доменных имен в IP-адреса; - администрирование с использованием групповых политик; - единая регистрация в сети, доступ к ресурсам независимо от их расположения в сети; - безопасность информации, достигаемая централизованной защитой сети; - гибкость изменений в структуре каталога в соответствии с изменениями в структуре предприятия; - репликация информации по схеме со многими ведущими. 1. 2. 3. 4. 5. 6. Технологии, положенные в основу архитектуры Active Directory: Стандарты X 500 и X 509, определяющие информационную модель данных, синтаксис и формат цифровых сертификатов, используемых для аутентификации пользователей. Стандартный протокол доступа к каталогам LDAP (Lightweight Directory Access Protocol). Стек протоколов TCP/IP, являющийся основным в сетях масштаба корпорации. Служба DNS, используемая для разрешения доменных имен в IP-адреса. Протокол динамической конфигурации клиента DHCP. Система Kerberos – протокол аутентификации пользователей.

Клиенты LDAP/ADSI/Outl ook LDAP Транспорты репликации (RPC поверх IP, SMTP) Сетевые APIинтерфейсы Windows NT 4 API-интерфейсы REPL Репликация резервного контроллера домена Windows NT 4 SAM Клиенты Outlook MAPI Системный агент каталога (Directory System Agent, DSA) Уровень базы данных Расширяемое ядро хранилища Файл базы DSA предоставляет API-интерфейсы для выполнения запросов доступа к данных Ntds. dit каталогу. Уровень базы данных обеспечивает объектное представление информации БД путем применения семантики схемы к записям БД и изолирования верхних уровней службы каталога от исходной СУБД реляционного типа. Расширяемое ядро хранилища – файл базы данных Ntds. dit – обрабатывается только ядром хранилища. Администрирование этого файла осуществляется утилитой Ntdsutil. Архитектура Active Directory

Компоненты Active Directory Логическая структура: - объект – конкретная сущность (пользователь, принтер, папка, компьютер и т. д. ) с отличительным набором атрибутов; - контейнер – логическое объединение, группирующее объекты или контейнеры по некоторому признаку; - организационное подразделение – некоторый контейнерный объект, организующий объекты в логические административные группы; - домен – группа компьютеров, совместно использующих общую БД каталога; - дерево доменов –группировка одного или нескольких доменов со смежной структурой имен, предоставляющая совместный доступ к ресурсам; - лес доменов – объединение одного или более деревьев совместно использующих информацию каталога. Физическая структура: - контроллер домена – компьютер с серверной ОС Windows Server, хранящий раздел каталога (локальную БД домена) и отвечающий за аутентификацию пользователей; - подсеть – сетевая группа с заданной областью IP-адресов и сетевой маской, которая имеет определенное географическое положение; - сайт – одна или несколько подсетей со своим множеством IP-адресов.

Active Directory Схема каталога Directory Schema Class Schema Глобальный каталог Локальные БД доменов Разделы Active Directory Attribute Schema Схема каталога – определения всех объектов и правила, описывающие структуру каталога, синтаксис объектных классов и типы атрибутов, входящих в каталог. Сеть корпоративного предприятия представляется доменным деревом или доменным лесом.

Дерево доменов Деревья различают по : - иерархии доменов; - непрерывности пространства имен; - доверительным отношениям между доменами; - общей схеме; - способности отображать любой объект в списке глобального каталога. microsoft. com Доверяет clerc 2. dev. microsoft. com Пространство имен – набор правил именования, обеспечивающих иерархическую структуру, или путь в дереве. По стандартам DNS имя дочернего домена дополняется именем родительского. Доверяет Общий глобальный каталог clerc 1. dev. microsoft. com product. microsoft. com dev. microsoft. com Доверяет

Лес доменов доверие microsoft. co m доверие msnbc. com Общий глобальный каталог seattle. microsoft. com miami. microsoft. com доверие Леса различаются по: - одному или более набору деревьев; - несвязанному пространству имен между деревьями; - доверительным отношениям между этими деревьями; - общей схеме; - способности отображать любой объект в списке глобального каталога. ns. msnbc. com ms. msnbc. com доверие Доверительные отношения: - односторонние (явное доверие); - двусторонние транзитивные (полное доверие).

Контроллеры домена и сайты DNS - сервер 1. Поиск контроллера домена через DNS Рабочая станция LDAP - сервер Хранилище данных (data stores) - файл NTDS. DIT и глобальные каталоги (global catalogs) 2. Адрес контроллера домена 3. Доступ к данным каталога при помощи LDAP 4. Данные каталога Контроллер домена NTDS. DIT СОДЕРЖИТ: 1. Данные домена – информация об объектах домена (учетные записи, общие ресурсы, ОП, групповые политики). 2. Данные конфигурации (топология каталога, список лесов, деревьев, контроллеров и серверов ГК). 3. Данные схемы - информация об объектах и типов данных, которые могут храниться в каталоге.

Доступ и распространение данных Active Directory. Протоколы и репликация Основной метод репликации - режим multi-master – репликация с несколькими хозяевами. Часть изменений в каталоге выполняется в режиме с одним основным контроллером – основным контроллером операций (operations master – хозяин операций). Роли контроллера операций FSMO (Flexible Single Master Operation – гибкие операции с одним основным контроллером): Хозяин схемы (Schema Master) – управляет обновлениями и изменениями схемы каталога. Хозяин именования доменов (Domain Naming Master) – управляет добавлением и удалением доменов в лесу. Хозяин относительных идентификаторов (RID – Relative ID Master) – выделяет относительные идентификаторы контроллерам доменов. Эмулятор PDC (PDC emulator) – в смешанном режиме домена действует как главный контроллер. Хозяин инфраструктуры (Infrastructure Master) – обновляет все внутридоменные ссылки на объекты других доменов при изменениях этих объектов.

Управление объектами Active Directory Задачи управления: поиск объектов, их создание, изменение, перемещение и уничтожение.

Система Kerberos - это дополнительная сетевая система/протокол, позволяющая пользователям авторизоваться через защищенные сервисы на защищенном сервере. Такие сервисы как удаленный вход, удаленное копирование, защищенное копирование файлов между системами и другие задачи с высоким риском становятся допустимо безопасными и более контролируемыми. Принципы системы: 1. Все процедуры аутентификации между клиентами и серверами сети выполняются через посредника (Kerberos), которому доверяют обе стороны. 2. Клиент должен доказывать свою аутентичность для доступа к каждой нужной ему службе. 3. Все обмены по сети выполняются с использованием алгоритма шифрования DES. 4. Сетевая служба Kerberos построена по архитектуре клиент-сервер.

Протокол основан на понятии Ticket (билет). • Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). • Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдает первичное удостоверение пользователя доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). • Одним из преимуществ протокола Kerberos, обеспечивающим высокий уровень безопасности, является то, что при любых взаимодействиях не передаются ни пароли, ни значения хеша паролей в открытом виде. • При работе с протоколом Kerberos необходимо, чтобы системные часы всех участвующих во взаимодействии узлов были синхронизированы.

Если клиент желает связаться с сервером, то 1. он связывается со службой Kerberos для получения временного тикета (ticket. Правильное русское название - мандат) для доступа к Службе выделения мандатов (Ticket-Granting Service, TGS). 2. Ticket высылается в зашифрованном виде 3. клиент запрашивает у TGS возможность соединиться с сервером 4. Если все в порядке, TGS отсылает ticket на соединение 5. Далее клиент предъявляет этот ticket и свой идентификатор серверу

Доступ к ресурсу состоит из следующих этапов: - (1) определение легальности клиента, логический вход в сеть, получение разрешения на продолжение процесса доступа к ресурсу; - (2) получение разрешения на обращение к ресурсному серверу; - (3) получение разрешения на доступ к ресурсу.

Kerberos-сервер Квитанция и ключ сеанса Кs Аутентификационный сервер Идентификатор, пароль Р Сервер квитанций 2 1 Многократно используемая квитанция (KRS 1) Зашифрованная квитанция и К шифруются с помощью Р Kerberos-клиент 3 Файлсервер Разделяемый ключ К Сервер приложений KRS 1 Ресурсные серверы Квитанция: IDk , IDs, t, T, Кs A (аутентификатор: ID, IP, t) Сервер удаленного доступа

процесс аутентификации пользователя

Клиент аутентифицирован в домене и получает возможность осуществлять доступ к ресурсам домена, используя протокол Kerberos

KDC может подтвердить, что запрос пришел от «правильного» пользователя

Концепции DLL • DLL (англ. dynamic-link library — «библиотека динамической компоновки» , «динамически подключаемая библиотека» ) — понятие операционных систем Microsoft Windows и IBM OS/2, динамическая библиотека, позволяющая многократное использование различными программными приложениями. K DLL относятся также элементы управления Activ. X и драйверы. • В мире UNIX аналогичные функции выполняют так называемые разделяемые объекты (shared objects).

• Библиотеки DLL не присоединены непосредственно к выполняемым файлам с помощью редактора связей. • В выполняемый файл занесена только информация об их местонахождении. В момент выполнения программы загружается вся библиотека целиком. Благодаря этому разные процессы могут пользоваться совместно одними и теми же библиотеками, находящимися в памяти. Такой подход позволяет сократить объем памяти, необходимый для нескольких приложений, использующих много общих библиотек, а также контролировать размеры ЕХЕ-файлов.

• Первоначально предполагалось, что введение DLL позволит эффективно организовать память и дисковое пространство, используя только один экземпляр библиотечного модуля для различных приложений. Это было особенно важно для ранних версий Microsoft Windows с жёсткими ограничениями по памяти. • Предполагалось улучшить эффективность разработок и использования системных средств за счёт модульности. Замена DLL-программ с одной версии на другую должна была позволить независимо наращивать систему, не затрагивая приложений. Кроме того, динамические библиотеки могли использоваться разнотипными приложениями • В дальнейшем идея модульности выросла в концепцию COM

Основы технологии COM, COM+ • COM (англ. Component Object Model — объектная модель компонентов) — это стандарт, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. Этот двоичный стандарт обеспечивает средства, с помощью которых объекты и компоненты, разработанные на разных языках программирования разными поставщиками и работающие в различных операционных системах, могут взаимодействовать без каких-либо изменений в двоичном (исполняемом) коде. • Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Windows.

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

• Информация, необходимая сервисам СОМ и приложениям-клиентам для размещения и создания экземпляров компонентов, хранится в реестре Windows. Обратившись к реестру, приложения могут определить количество и тип установленных в системе компонентов. • Информация в реестре упорядочена иерархически и имеет несколько предопределенных высокоуровневых разделов. Важным подразделом HKEY_CLASSES_ROOT является CLSID (идентификаторы классов), в котором описывается каждый компонент, установленный в системе.

Элемент реестр а Prog. ID Назначение Задает строку Prog. ID для СОМ-класса. Может содержать 39 символов, в том числе и символ точки. Содержит путь и имя 32 -разрядного DLLфайла. Наличие пути необязательно, но если он не указан, то загрузка компонента In. Proc. Ser ver 32 возможна только в случае размещения его в одном из каталогов команд Windows (задается переменной среды PATH). Local. Serv Содержит путь и имя 32 -битового ЕХЕ-файла. er 32 Cur. Ver Prog. ID последней версии класса компонента.

• Технология COM+ (старое название Microsoft Transaction Server, MTS) входит в состав серверных операционных систем Microsoft и предназначена для поддержки систем обработки транзакций. • Технология COM+ базируется на возможностях COM и обеспечивает поддержку распределенных приложений на компонентной основе. • Технология расширяла возможности разработчиков COMкомпонентов, предоставляя : • автоматический пул потоков, создаваемый стандартным процессом-загрузчиком mtx. exe ; • доступ к контексту, в котором выполняется компонент (например, компоненты, используемые в ASP, могут с этой возможностью получить доступ к внутренним объектам той страницы, на которой они выполняются) ; • интеграция с транзакциями монитора MS DTC (контекст COM+ может автоматически содержать в себе транзакцию Microsoft Distributed Transaction Coordinator ).