Способы адресации
Для того, чтобы послать сообщение, необходимо указать адрес получателя. В очень простой сети адрес может задаваться в виде константы, но в более сложных сетях нужен и более изощренный способ адресации. Одним из вариантов адресации на верхнем уровне является использование физических адресов сетевых адаптеров. Если в получающем компьютере выполняется только один процесс, то ядро будет знать, что делать с поступившим сообщением — передать его этому процессу. Однако, если на машине выполняется несколько процессов, то ядру не известно, какому из них предназначено сообщение, поэтому использование сетевого адреса адаптера в качестве адреса получателя приводит к очень серьезному ограничению — на каждой машине должен выполняться только один процесс. Альтернативная адресная система использует имена назначения, состоящие из двух частей, определяющие номер машины и номер процесса. Однако адресация типа «машина-процесс» далека от идеала, в частности, она не гибка и не прозрачна, так как пользователь должен явно задавать адрес машины-получателя. В этом случае, если в один прекрасный день машина, на которой работает сервер, отказывает, то программа, в которой жестко используется адрес сервера, не сможет работать с другим сервером, установленном на другой машине. Другим вариантом могло бы быть назначение каждому процессу уникального адреса, который никак не связан с адресом машины. Одним из способов достижения этой цели является использование централизованного механизма распределения адресов процессов, который работает просто, как счетчик. При получении запроса на выделение адреса он просто возвращает текущее значение счетчика, а затем наращивает его на единицу. Недостатком этой схемы является то, что централизованные компоненты, подобные этому, не обеспечивают в достаточной степени расширяемость систем. Еще один метод назначения процессам уникальных идентификаторов заключается в разрешении каждому процессу выбора своего собственного идентификатора из очень большого адресного пространства, такого как пространство 64-х битных целых чисел. Вероятность выбора одного и того же числа двумя процессами является ничтожной, а система хорошо расширяется. Однако здесь имеется одна проблема: как процесс-отправитель может узнать номер машины процесса-получателя. В сети, которая поддерживает широковещательный режим (то есть в ней предусмотрен такой адрес, который принимают все сетевые адаптеры), отправитель может широковещательно передать специальный пакет, который содержит идентификатор процесса назначения. Все ядра получат эти сообщения, проверят адрес процесса и, если он совпадает с идентификатором одного из процессов этой машины, пошлют ответное сообщение «Я здесь», содержащее сетевой адрес машины. Хотя эта схема и прозрачна, но широковещательные сообщения перегружают систему. Такой перегрузки можно избежать, выделив в сети специальную машину для отображения высокоуровневых символьных имен. При применении такой системы процессы адресуются с помощью символьных строк, и в программы вставляются эти строки, а не номера машин или процессов. Каждый раз перед первой попыткой связаться, процесс должен послать запрос специальному отображающему процессу, обычно называемому сервером имен, запрашивая номер машины, на которой работает процесс-получатель. Совершенно иной подход — это использование специальной аппаратуры. Пусть процессы выбирают свои адреса случайно, а конструкция сетевых адаптеров позволяет хранить эти адреса. Теперь адреса процессов не обнаруживаются путем широковещательной передачи, а непосредственно указываются в кадрах, заменяя там адреса сетевых адаптеров.
Модели сетевых служб и распределенных приложений
Практически все современные операционные системы являются сетевыми, то есть позволяют своим пользователям (в том числе приложениям, работающим от имени пользователей) получать доступ не только к локальным ресурсам их собственных компьютеров, но и к ресурсам других компьютеров, подключенных к сети.
С этой целью практически любая локальная сеть имеет выход в глобальную сеть Интернет и постепенно становиться частью глобальной сети. Транспортной базой для такой интеграции стал единый стек протоколов TCP/IP.
Основные протоколы сетевого и транспортного уровня (IP, ICMP, ARP, TCP, UDP, RIP, OSPF) подробно изучались в учебной дисциплине «Вычислительные системы, сети и телекоммуникации». Они обеспечивают внутрисетевое и межсетевое взаимодействие компьютеров.
Доступ пользователей к разделяемым ресурсам как локальных, так и глобальных сетей осуществляется на основе набора разнообразных протоколов прикладного уровня (протокол доступа к гипертекстовым сервисам HTTP, протокол пересылки файлов FTP, почтовый протокол SMTP, протокол эмуляции удаленного терминала Telnet и другие).
В настоящее время наблюдается устойчивая тенденция к интеграции сетевых технологий, применявшихся в глобальной сети, например, DNS, электронная почта, Web-технологии, с технологиями локальных сетей, например службой каталогов, распределенной файловой системой и т.п.
Перспективными являются распределенные системы, которые заставляют набор сетевых машин работать как один многопроцессорный компьютер, динамически распределяя между ними все задания пользователей сети. В настоящее время истинно распределенных систем пока нет. Однако идея распределенной обработки данных (на нескольких компьютерах) применяется во всех сетевых службах, формируя элементы системной интеграции.
Цель темы – раскрыть назначение и основные механизмы глобальных и локальных сетевых технологий, элементы системной интеграции, принципы и модели распределенной обработки данных в сетевых операционных системах.
В результате изучения темы обучаемые должны усвоить:
· Назначение и модели распределенных приложений.
· Механизм организации взаимодействия между элементами распределенных приложений.
· Принципы построения и функционирования распределенных файловых систем.
· Назначение и функции службы каталогов в компьютерных сетях.
· Принципы функционирования системы защиты информации Kerberos.
ТЕМА 3. ГЛОБАЛЬНЫЕ И ЛОКАЛЬНЫЕ СЕТЕВЫЕ ТЕХНОЛОГИИ 1
3.1. Тенденции и перспективы развития распределенных операционных сред 2
3.1.1. Модели сетевых служб и распределенных приложений.. 3
3.1.2. Механизм организации взаимодействия в распределенных системах. 6
3.2. Распределенные файловые системы.. 10
3.2.1. Основные принципы построения. 10
3.2.2. Кэширование файлов. 14
3.2.4. Распределенная файловая система DFS.. 16
3.3. Элементы системной интеграции. 18
3.3.2. Домены и доверительные отношения. 24
3.4. Средства защиты информации в сети. 26
3.4.1. Базовые технологии сетевой безопасности.. 27
Вопросы для самопроверки. 33
Тенденции и перспективы развития распределенных операционных сред
Объединение компьютеров в сеть предоставляет возможность программам, работающим на отдельных компьютерах, оперативно взаимодействовать и сообща решать задачи пользователей. Связь между некоторыми программами может быть настолько тесной, что их удобнее рассматривать в качестве частей одного приложения, которое называют в этом случае распределенным, или сетевым.
Распределенные приложения могут обладать рядом преимуществ по сравнению с локальными:
· более высокая производительность;
· приближение к пользователю.
Следует выделить три основных параметра организации работы приложений в сети:
· способ разделения приложения на части, выполняющиеся на разных компьютерах сети;
· выделение специализированных серверов в сети, на которых выполняются некоторые общие для всех приложений функции;
· способ взаимодействия между частями приложений, работающих на разных компьютерах сети.
Модели сетевых служб и распределенных приложений
Существуют типовые модели распределенных приложений, в которых приложение делится на шесть функциональных частей:
· средства представления данных на экране, например средства графического пользовательского интерфейса;
· логика представления данных на экране, которая описывает правила и возможные сценарии взаимодействия пользователя с приложениями: выбор из системы меню, выбор элемента из списка и т. д.;
· прикладная логика – набор правил для принятия решений, вычислительные процедуры и операции;
· логика данных – операции с данными, хранящимися в некоторой базе, которые нужно выполнить для реализации прикладной логики;
· внутренние операции базы данных – действия СУБД (системы управления базами данных), вызываемые в ответ на выполнение запросов логики данных, такие как поиск записи по определенным признакам;
· файловые операции – стандартные операции над файлами и файловой системой, которые обычно являются функцией операционной системы.
Первые две функции приложения часто объединяют термином интерфейс пользователя.
Распределение приложения между большим числом компьютеров может повысить качество его выполнения (скорость, количество одновременно обслуживаемых пользователей и т. д.), но при этом существенно усложняется организация самого приложения, что может просто не позволить воспользоваться потенциальными преимуществами распределенной обработки. Потому на практике приложение обычно разделяют на две или три части для выполнения соответственно на двух или трех компьютерах. При этом распределение перечисленных выше функциональных частей приложения между компьютерами может быть различным.
На рис. 3.1 представлены варианты распределения частей приложения по двухзвенной схеме (между двумя компьютерами).
Рис. 3.1. Варианты распределения частей приложения по двухзвенной схеме
В централизованной схеме (рис. 3.1, а) компьютер пользователя работает как терминал, выполняющий лишь функции представления данных, а все остальные функции передаются центральному компьютеру – серверу.
Достоинство этого варианта: компьютер пользователя загружается незначительно и поэтому может быть низко производительным.
Основные недостатки: слабая масштабируемость (количество одновременно работающих пользователей определяется производительностью сервера) и низкая отказоустойчивость.
Вариант (рис. 3.1, б) реализует файловый сервер, когда на одном компьютере создается централизованное хранилище файлов пользователей. Для того чтобы в этой схеме можно было использовать локальные приложения, в сетевой ОС ввели такой компонент сетевой файловой службы, как редиректор. Редиректор перехватывает обращения к удаленным файлам и направляет запросы в сеть, освобождая приложение от необходимости явно задействовать сетевые системные вызовы.
Достоинство схемы: хорошая масштабируемость, так как дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный узел – файловый сервер.
Недостатки: возрастает сетевая нагрузка, что приводит к увеличению времени реакции приложения; клиентский компьютер должен обладать производительностью, достаточной для работы всех приложений
В варианте (рис. 3.1, в) нагрузка между компьютерами распределяется более равномерно. На серверный компьютер возлагаются функции проведения внутренних операций базы данных и файловые операции. Клиентский компьютер при этом выполняет все функции, специфические для данного приложения, а сервер – функции, реализация которых не зависит от специфики приложения, из-за чего эти функции могут быть оформлены в виде сетевых служб. Поскольку функции управления базами данных нужны далеко не всем приложениям, то в отличие от файловой системы они чаще всего не реализуются в виде службы сетевой операционной системы, а являются независимой распределенной прикладной системой.
Система управления базами данных (СУБД) является одним из наиболее часто применяемых в сетях распределенных приложений.
Термин «клиент-сервер» справедлив для любой двухзвенной схемы распределения функций, но исторически он чаще применяется для варианта, в котором сервер выполнял функции по управлению базами данных и поэтому часто используется как синоним этой схемы.
Трехзвенные схемы (рис. 3.2) позволяют еще больше сбалансировать нагрузку на различные компьютеры в сети, а также способствуют дальнейшей специализации серверов и средств разработки распределенных приложений.
Рис. 3.2. Вариант трехзвенной схемы распределения частей приложения
Промежуточный сервер называют в этом варианте сервером приложений, так как на нем выполняются логика работы приложения и логика обработки данных, представляющих собой наиболее специфические и важные части большинства приложений. Слой логики обработки данных вызывает внутренние операции базы данных, которые реализуются третьим звеном схемы – сервером базы данных.
Централизованная реализация логики приложения решает проблему недостаточной вычислительной мощности клиентских компьютеров для сложных приложений, а также упрощает администрирование и сопровождение. Операционная система сервера приложений должна обеспечивать высокую производительность вычислений. Причем таких серверов в сети может быть несколько.