10469

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

Реферат

Информатика, кибернетика и программирование

Тема: Сетевые операционные системы. Управление распределенными ресурсами. Базовые примитивы передачи сообщений в распределенных системах. Единственным по-настоящему важным отличием распределенных систем от централизованных является межпроцессная вз...

Русский

2013-03-26

158.47 KB

7 чел.

Тема: «Сетевые операционные системы. Управление распределенными ресурсами».

  1.  Базовые примитивы передачи сообщений в распределенных системах.

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

Примечание.

Межпроцессное взаимодействие (англ. Inter-Process Communication, IPC) — набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов (RPC). Методы IPC зависят от пропускной способности и задержки взаимодействия между потоками и типа передаваемых данных.

Семафо́р — объект, позволяющий войти в заданный участок кода не более чем n потокам.

Семафор — это объект, с которым можно выполнить три операции.

init(n):

счётчик := n

 

enter():

ждать пока счётчик станет больше 0; после этого уменьшить счётчик на единицу.

 

leave():

увеличить счётчик на единицу.

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

Несмотря на концептуальную простоту этих системных вызовов - ПОСЛАТЬ и ПОЛУЧИТЬ - существуют различные варианты их реализации, от правильного выбора которых зависит эффективность работы сети. В частности, эффективность коммуникаций в сети зависит от способа задания адреса, от того, является ли системный вызов блокирующим или неблокирующим, какие выбраны способы буферизации сообщений и насколько надежным является протокол обмена сообщениями.

1.1 Способы адресации

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

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

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

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

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

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

1.2 Блокирующие и неблокирующие примитивы

Примитивы бывают блокирующими и неблокирующими, иногда они называются соответственно синхронными и асинхронными. При использовании блокирующего примитива, процесс, выдавший запрос на его выполнение, приостанавливается до полного завершения примитива. Например, вызов примитива ПОЛУЧИТЬ приостанавливает вызывающий процесс до получения сообщения.

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

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

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

Вопросом, тесно связанным с блокирующими и неблокирующими вызовами, является вопрос тайм-аутов. В системе с блокирующим вызовом ПОСЛАТЬ при отсутствии ответа вызывающий процесс может заблокироваться навсегда. Для предотвращения такой ситуации в некоторых системах вызывающий процесс может задать временной интервал, в течение которого он ждет ответ. Если за это время сообщение не поступает, вызов ПОСЛАТЬ завершается с кодом ошибки.

1.3 Буферизуемые и небуферизуемые примитивы

Примитивы, которые были описаны, являются небуферизуемыми примитивами. Это означает, что вызов ПОЛУЧИТЬ сообщает ядру машины, на которой он выполняется, адрес буфера, в который следует поместить пребывающее для него сообщение.

Эта схема работает прекрасно при условии, что получатель выполняет вызов ПОЛУЧИТЬ раньше, чем отправитель выполняет вызов ПОСЛАТЬ. Вызов ПОЛУЧИТЬ сообщает ядру машины, на которой выполняется, по какому адресу должно поступить ожидаемое сообщение, и в какую область памяти необходимо его поместить. Проблема возникает тогда, когда вызов ПОСЛАТЬ сделан раньше вызова ПОЛУЧИТЬ. Каким образом сможет узнать ядро на машине получателя, какому процессу адресовано вновь поступившее сообщение, если их несколько? И как оно узнает, куда его скопировать?

Один из вариантов - просто отказаться от сообщения, позволить отправителю взять тайм-аут и надеяться, что получатель все-таки выполнит вызов ПОЛУЧИТЬ перед повторной передачей сообщения. Этот подход не сложен в реализации, но, к сожалению, отправитель (или скорее ядро его машины) может сделать несколько таких безуспешных попыток. Еще хуже то, что после достаточно большого числа безуспешных попыток ядро отправителя может сделать неправильный вывод об аварии на машине получателя или о неправильности использованного адреса.

Второй подход к этой проблеме заключается в том, чтобы хранить хотя бы некоторое время, поступающие сообщения в ядре получателя на тот случай, что вскоре будет выполнен соответствующий вызов ПОЛУЧИТЬ. Каждый раз, когда поступает такое "неожидаемое" сообщение, включается таймер. Если заданный временной интервал истекает раньше, чем происходит соответствующий вызов ПОЛУЧИТЬ, то сообщение теряется.

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

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

1.4 Надежные и ненадежные примитивы

Ранее подразумевалось, что когда отправитель посылает сообщение, адресат его обязательно получает. Но реально сообщения могут теряться. Предположим, что используются блокирующие примитивы. Когда отправитель посылает сообщение, то он приостанавливает свою работу до тех пор, пока сообщение не будет послано. Однако нет никаких гарантий, что после того, как он возобновит свою работу, сообщение будет доставлено адресату.

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

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

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

  1. Распределенные файловые системы

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

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

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

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

Файловый сервис в распределенных файловых системах (впрочем как и в централизованных) имеет две функционально различные части: собственно файловый сервис и сервис каталогов. Первый имеет дело с операциями над отдельными файлами, такими, как чтение, запись или добавление, а второй - с созданием каталогов и управлением ими, добавлением и удалением файлов из каталогов и т.п.

  1. Интерфейс файлового сервиса

Для любого файлового сервиса, независимо от того, централизован он или распределен, самым главным является вопрос, что такое файл? Во многих системах, таких как UNIX и MS DOS, файл - это неинтерпретируемая последовательность байтов. Значение и структура информации в файле является заботой прикладных программ, операционную систему это не интересует.

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

Важным аспектом файловой модели является возможность модификации файла после его создания. Обычно файлы могут модифицироваться, но в некоторых распределенных системах единственными операциями с файлами являются СОЗДАТЬ и ПРОЧИТАТЬ. Такие файлы называются неизменяемыми. Для неизменяемых файлов намного легче осуществить кэширование файла и его репликацию (тиражирование), так как исключается все проблемы, связанные с обновлением всех копий файла при его изменении.

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

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

  1. Интерфейс сервиса каталогов

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

Принципиальной проблемой, связанной со способами именования файлов, является обеспечение прозрачности. В данном контексте прозрачность понимается в двух слабо различимых смыслах. Первый - прозрачность расположения - означает, что имена не дают возможности определить месторасположение файла. Например, имя /server1/dir1/ dir2/x говорит, что файл x расположен на сервере 1, но не указывает, где расположен этот сервер. Сервер может перемещаться по сети, а полное имя файла при этом не меняется. Следовательно, такая система обладает прозрачностью расположения.

Предположим, что файл x очень большой, а на сервере 1 мало места, предположим далее, что на сервере 2 места много. Система может захотеть переместить автоматически файл x на сервер 2. К сожалению, когда первый компонент всех имен - это имя сервера, система не может переместить файл на другой сервер автоматически, даже если каталоги dir1 и dir2 находятся на обоих серверах. Программы, имеющие встроенные строки имен файлов, не будут правильно работать в этом случае. Система, в которой файлы могут перемещаться без изменения имен, обладает свойством независимости от расположения. Распределенная система, которая включает имена серверов или машин непосредственно в имена файлов, не является независимой от расположения. Система, базирующаяся на удаленном монтировании, также не обладает этим свойством, так как в ней невозможно переместить файл из одной группы файлов в другую и продолжать после этого пользоваться старыми именами. Независимости от расположения трудно достичь, но это желаемое свойство распределенной системы.

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

  1. Семантика разделения файлов

Когда два или более пользователей разделяют один файл, необходимо точно определить семантику чтения и записи, чтобы избежать проблем. В централизованных системах, разрешающих разделение файлов, таких как UNIX, обычно определяется, что, когда операция ЧТЕНИЕ следует за операцией ЗАПИСЬ, то читается только что обновленный файл. Аналогично, когда операция чтения следует за двумя операциями записи, то читается файл, измененный последней операцией записи. Тем самым система придерживается абсолютного временного упорядочивания всех операций, и всегда возвращает самое последнее значение. Будем называть эту модель семантикой UNIX'а. В централизованной системе (и даже на мультипроцессоре с разделяемой памятью) ее легко и понять, и реализовать.

Семантика UNIX может быть обеспечена и в распределенных системах, но только, если в ней имеется лишь один файловый сервер, и клиенты не кэшируют файлы. Для этого все операции чтения и записи направляются на файловый сервер, который обрабатывает их строго последовательно. На практике, однако, производительность распределенной системы, в которой все запросы к файлам идут на один сервер, часто становится неудовлетворительной. Эта проблема иногда решается путем разрешения клиентам обрабатывать локальные копии часто используемых файлов в своих личных кэшах. Если клиент сделает локальную копию файла в своем локальном кэше и начнет ее модифицировать, а вскоре после этого другой клиент прочитает этот файл с сервера, то он получит неверную копию файла. Одним из способов устранения этого недостатка является немедленный возврат всех изменений в кэшированном файле на сервер. Такой подход хотя и концептуально прост, но не эффективен.

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

Следующий подход к разделению файлов заключается в том, чтобы сделать все файлы неизменяемыми. Тогда файл нельзя открыть для записи, а можно выполнять только операции СОЗДАТЬ и ЧИТАТЬ. Тогда для изменения файла остается только возможность создать полностью новый файл и поместить его в каталог под именем старого файла. Следовательно, хотя файл и нельзя модифицировать, его можно заменить (автоматически) новым файлом. Другими словами, хотя файлы и нельзя обновлять, но каталоги обновлять можно. Таким образом, проблема, связанная с одновременным использованием файла, просто исчезнет.

Четвертый способ работы с разделяемыми файлами в распределенных системах - это использование механизма неделимых транзакций, достаточно подробно описанного в разделе 3.3.3.

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

  1.  Семантика UNIX. Каждая операция над файлом немедленно становится видимой для всех процессов.
  2.  Сессионная семантика. Изменения не видны до тех пор, пока файл не закрывается.
  3.  Неизменяемые файлы. Модификации невозможны, разделение файлов и репликация упрощаются.
  4.  Транзакции. Все изменения делаются по принципу "все или ничего".

  1. Вопросы разработки структуры файловой системы

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

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

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

Аргументом в пользу разделения сервисов является тот факт, что они на самом деле слабо связаны, поэтому их раздельная реализация более гибкая. Например, можно реализовать сервер каталогов MS-DOS и сервер каталогов UNIX, которые будут использовать один и тот же файловый сервер для физического хранения файлов. Разделение этих функций также упрощает программное обеспечение. Недостатком является то, что использование двух серверов увеличивает интенсивность сетевого обмена.

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

Последний рассматриваемый здесь структурный вопрос связан с хранением на серверах информации о состоянии клиентов. Существует две конкурирующие точки зрения.

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

Рассмотрим эту проблему на примере файлового сервера, имеющего команды ОТКРЫТЬ, ПРОЧИТАТЬ, ЗАПИСАТЬ и ЗАКРЫТЬ файл. Открывая файлы, statefull-сервер должен запоминать, какие файлы открыл каждый пользователь. Обычно при открытии файла пользователю дается дескриптор файла или другое число, которое используется при последующих вызовах для его идентификации. При поступлении вызова, сервер использует дескриптор файла для определения, какой файл нужен. Таблица, отображающая дескрипторы файлов на сами файлы, является информацией о состоянии клиентов.

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

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

Преимущества обоих подходов можно обобщить следующим образом:

Stateless-серверы: 

  1. отказоустойчивы;
  2. не нужны вызовы OPEN/CLOSE;
  3. меньше памяти сервера расходуется на таблицы;
  4. нет ограничений на число открытых файлов;
  5. отказ клиента не создает проблем для сервера.

Statefull-серверы: 

  1. более короткие сообщения при запросах;
  2. лучше производительность;
  3. возможно опережающее чтение;
  4. легче достичь идемпотентности;
  5. возможна блокировка файлов.

2.7 Кэширование

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

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

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

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

Во-вторых, необходимо определить правило замены данных при заполнении кэш-памяти. Здесь можно использовать любой стандартный алгоритм кэширования, например, алгоритм LRU (least recently used), соответствии с которым вытесняется блок, к которому дольше всего не было обращения.

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

Хотя кэширование на сервере исключает обмен с диском при каждом доступе, все еще остается обмен по сети. Существует только один путь избавиться от обмена по сети - это кэширование на стороне клиента, которое, однако, порождает много сложностей.

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

Рис. 3.11. Различные способы выполнения кэша в клиентской памяти
а - без кэширования; б - кэширование внутри каждого процесса; в - кэширование в ядре;
г - кэш-менеджер как пользовательский процесс
 

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

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

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

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

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

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

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

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

Четыре алгоритма управления кэшированием обобщаются следующим образом:

1. Сквозная запись. Этот метод эффективен частично, так как уменьшает интенсивность только операций чтения, а интенсивность операций записи остается неизменной.

2. Отложенная запись. Производительность лучше, но результат чтения кэшированного файла не всегда однозначен.

3. "Запись-по-закрытию". Удовлетворяет сессионной семантике.

4. Централизованное управление. Ненадежен вследствие своей централизованной природы.

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

2.8 Репликация

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

1. Увеличение надежности за счет наличия независимых копий каждого файла на разных файл-серверах.

2. Распределение нагрузки между несколькими серверами.

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

На рисунке 3.12 показаны три возможных способа репликации. При использовании первого способа (а) программист сам управляет всем процессом репликации. Когда процесс создает файл, он делает это на одном определенном сервере. Затем, если пожелает, он может сделать дополнительные копии на других серверах. Если сервер каталогов разрешает сделать несколько копий файла, то сетевые адреса всех копий могут быть ассоциированы с именем файла, как показано на рисунке снизу, и когда имя найдено, это означает, что найдены все копии. Чтобы сделать концепцию репликации более понятной, рассмотрим, как может быть реализована репликация в системах, основанных на удаленном монтировании, типа UNIX. Предположим, что рабочий каталог программиста имеет имя /machine1/usr/ast. После создания файла, например, /machine1/usr/ast/xyz, программист, процесс или библиотека могут использовать команду копирования для того, чтобы сделать копии /machine2/usr/ast/xyz и machine3/usr/ast/xyz. Возможно программа использует в качестве аргумента строку /usr/ast/xyz и последовательно попытается открывать копии, пока не достигнет успеха. Эта схема хотя и работает, но имеет много недостатков, и по этим причинам ее не стоит использовать в распределенных системах.

На рисунке 3.12,б показан альтернативный подход - ленивая репликация. Здесь создается только одна копия каждого файла на некотором сервере. Позже сервер сам автоматически выполнит репликации на другие серверы без участия программиста. Эта система должна быть достаточно быстрой для того, чтобы обновлять все эти копии, если потребуется.

Последним рассмотрим метод, использующий групповые связи (рисунок 3.12,в). В этом методе все системные вызовы ЗАПИСАТЬ передаются одновременно на все серверы, таким образом копии создаются одновременно с созданием оригинала. Имеется два принципиальных различия в использовании групповых связей и ленивой репликации. Во-первых, при ленивой репликации адресуется один сервер, а не группа. Во-вторых, ленивая репликация происходит в фоновом режиме, когда сервер имеет промежуток свободного времени, а при групповой репликации все копии создаются в одно и то же время.

Рис. 3.12. а) Точная репликация файла; б) Ленивая репликация файла;
в) Репликация файла, использующая группу
 

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

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

Чтобы предотвратить ситуацию, когда из-за отказа первичный сервер не успевает оповестить об изменениях все вторичные серверы, изменения должны быть сохранены в постоянном запоминающем устройстве еще до изменения первичной копии. В этом случае после перезагрузки сервера есть возможность сделать проверку, не проводились ли какие-нибудь обновления в момент краха. Недостаток этого алгоритма типичен для централизованных систем - пониженная надежность. Чтобы избежать его, используется метод, предложенный Гиффордом и известный как "голосование". Пусть имеется n копий, тогда изменения должны быть внесены в любые W копий. При этом серверы, на которых хранятся копии, должны отслеживать порядковые номера их версий. В случае, когда какой-либо сервер выполняет операцию чтения, он обращается с запросом к любым R серверам. Если R+W > n, то, хотя бы один сервер содержит последнюю версию, которую можно определить по максимальному номеру.

Интересной модификацией этого алгоритма является алгоритм "голосования с приведениями". В большинстве приложений операции чтения встречаются гораздо чаще, чем операции записи, поэтому R обычно делают небольшим, а W - близким к N. При этом выход из строя нескольких серверов приводит к отсутствию кворума для записи. Голосование с приведениями решает эту проблему путем создания фиктивного сервера без дисков для каждого отказавшего или отключенного сервера. Фиктивный сервер не участвует в кворуме чтения (прежде всего, у него нет файлов), но он может присоединиться к кворуму записи, причем он просто записывает в никуда передаваемый ему файл. Запись только тогда успешна, когда хотя бы один сервер настоящий.

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

3.Проблемы взаимодействия операционных систем в гетерогенных сетях

3.1 Понятия "internetworking" и "interoperability"

До недавнего времени проблемы межсетевого взаимодействия не очень волновали отечественных пользователей и системных администраторов. Они уютно себя чувствовали в замкнутом мире IBM PC совместимых компьютеров, сетей Novell и сетевых адаптеров Ethernet, хотя в "большом" мире многие фирмы, в том числе и Novell, успешно продавали различные средства межсетевой связи. Однако пора монокультурного развития отечественных сетей заканчивается, организации приобретают различную технику, например, бизнес-серверы Hewlett-Packard, графические станции Sun или Silicon Graphics, мини-компьютеры AS-400 фирмы IBM и другую не менее достойную аппаратуру с разнообразными операционными системами, поэтому проблемы, характерные для западных корпоративных сетей, постепенно становятся актуальными и для нас.

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

Каждая сеть имеет свой номер, который используется на сетевом уровне при выполнении маршрутизации. Когда две или более сетей организуют совместную транспортную службу, то такой режим взаимодействия обычно называют межсетевым взаимодействием (internetworking). Для обозначения составной сети в англоязычной литературе часто также используются термины интерсеть (internetwork или internet). Интерсеть обеспечивает только передачу пакетов, не занимаясь их содержанием.

Так как понятие "номер сети" определяется на сетевом уровне, то оно является относительным, то есть, если в одном компьютере установлено программное обеспечение, поддерживающее несколько протоколов сетевого уровня (например, TCP и SPX), то данный компьютер может принадлежать нескольким сетям.

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

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

Задачи, решаемые с помощью редиректора:

  1.  Закрытие доступа к определённым адресам по сложным критериям.
  2.  Замена одного содержимого на другое (например, баннеров на пустые изображения)
  3.  Выдача сообщения о точной причине запрета доступа к странице
  4.  Выдача предупреждения о возможной фишинг-атаке (при наличии фишинг-фильтра)
  5.  Анализ статистики обращения к определённым ресурсам (как разрешённым, так и запрещённым)

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

3.2 Гетерогенность

Только небольшое количество сетей обладает однородностью (гомогенностью) программного и аппаратного обеспечения. Однородными чаще являются сети, которые состоят из небольшого количества компонентов от одного производителя.

Немногие организации имеют сети, составленные из оборудования, например, только IBM или DEC. Дни сетей от одного производителя миновали. Нормой сегодняшнего дня являются сети неоднородные (гетерогенные), которые состоят из различных рабочих станций, операционных систем и приложений, а для реализации взаимодействия между компьютерами используют различные протоколы. Разнообразие всех компонентов, из которых строится сеть, порождает еще большее разнообразие структур сетей, получающихся из этих компонентов. А если продолжить далее, и рассмотреть более сложные образования, получающиеся в результате объединения отдельных сетей в единую большую сеть, то становится понятным то множество проблем, связанных с проектированием, администрированием и управлением такой гетерогенной интерсетью. В идеале это объединение неоднородных сетей должно быть прозрачным для пользователя.

Так как сети создавались большей частью случайным образом, то приобретенные компьютеры и ОС отвечают, как правило, индивидуальным потребностям группы пользователей. Сети отдела строились для решения конкретных задач групп сотрудников. Например, инженерный отдел мог выбрать рабочие станции SPARC фирмы Sun Microsystems, соединенные сетью Ethernet, потому что им нужны были приложения, работающие только в среде UNIX. Разделение файлов при этом реализовывалось с помощью TCP/IP и NFS. В отделе продаж той же самой организации уже могли быть куплены компьютеры PS/2, установлена сеть Token Ring и операционная система NetWare для решения их собственных задач: ведения базы данных о клиентах, подготовки писем, разработки коммерческих предложений. Затем в рекламном отделе были выбраны компьютеры Macintosh, поскольку они наилучшим образом подходят для создания презентационных материалов. Macintosh'и соединены посредством LocalTalk, а файлы и принтеры разделяются с использованием AppleTalk. Отдел, отвечающий за автоматизацию предприятия, должен интегрировать все эти плохо совместимые системы в единый прозрачный организм.

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

3.3 Основные подходы к реализации взаимодействия сетей

Основные проблемы при организации взаимодействия различных сетей связаны с тем, что эти сети используют различные стеки коммуникационных протоколов. В каждом конкретном стеке протоколов, будь то стек DoD или Novell NetWare, средства, реализующие какой-либо уровень, обеспечивают интерфейс для вышележащего уровня своей системы и пользуются услугами интерфейсных функций нижележащего уровня. Например, средства реализации протокола Novell IPX в сервере предоставляют интерфейсные услуги протоколу NCP для приема запросов от рабочих станций и пересылки им ответов. В свою очередь протокол IPX пользуется интерфейсными функциями драйвера сетевого адаптера Ethernet, чтобы передать пакет для отправки в сеть.

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

К сожалению, в реальном мире компьютерных сетей существует несколько стеков протоколов, уже завоевавших свое место под солнцем и не собирающихся его уступать. Например, если на предприятии используются мейнфреймы IBM, то они скорее всего используют протоколы сетевой архитектуры SNA и аппаратуру Token Ring. Использование компьютеров DEC с операционной системой VAX означает, что используются протоколы DECnet и Ethernet. Сети локальных компьютеров используют чаще всего протоколы Novell NetWare, Banyan VINES, IBM LAN Server или Microsoft LAN Manager с аппаратурой Ethernet, Token Ring или ARCnet.

Существование многих стеков протоколов не вносит никаких проблем до тех пор, пока не появляется потребность в их взаимодействии, то есть потребность в доступе пользователей сети NetWare к мейнфрейму IBM или пользователей графических рабочих станций UNIX к компьютеру VAX. В этих случаях проявляется несовместимость близких по назначению, но различных по форматам данных и алгоритмам протоколов.

Общность различных стеков протоколов проявляется только на нижних уровнях - физическом и канальном. Здесь в настоящее время почти нет проблем для взаимодействия, так как большинство стеков могут использовать общие протоколы Ethernet, Token Ring, FDDI. Исключение составляют только мейнфреймы IBM, которые на нижнем уровне в основном используют протоколы типа ведущий-ведомый с синхронной передачей данных, ориентированные на иерархическую соподчиненную структуру мейнфрейм - групповой контроллер - терминалы. Да и соединение двух компьютеров, использующих на нижнем уровне различные протоколы, а на верхних - одинаковые не составляет проблемы - эта задача решается аппаратно с помощью транслирующего моста или маршрутизатора.

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

Если рассмотреть наиболее часто используемый в сетях сервис, а именно, файловый сервис, то различия в протоколах файлового сервиса в первую очередь связаны с различиями структур файловых систем. Например, пользователю MS-DOS непривычны приемы монтирования файловой системы UNIX в одно дерево, он хочет работать с разрозненными файловыми системами отдельных носителей, отображенными на буквы английского алфавита. Команды, используемые при работе с различными файловыми системами, также различны как по названию, так и по содержанию. Кроме того, даже для одной файловой системы в различных операционных системах предусмотрены различные удаленные сервисы. В ОС UNIX можно работать с удаленной файловой системой с помощью символьных команд протокола прикладного уровня FTP, переписывая файлы с удаленной машины на локальную по одному, а можно работать с протоколом NFS, который обеспечивает монтирование удаленной системы в локальную и требует других команд и приемов. Поэтому проблемы, возникающие на верхних уровнях, гораздо сложнее, чем проблемы замены заголовка пакета на канальном уровне.

Рис. 3.13. Два основных варианта согласования протоколов
а - трансляция протоколов; б - мультиплексирование стеков протоколов
 

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

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

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

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

Каждый из подходов имеет свои преимущества и недостатки, на которых мы остановимся позже.

3.4 Шлюзы

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

Рисунок 3.14 иллюстрирует принцип функционирования шлюза. В показанном примере шлюз, размещенный на компьютере 2, согласовывает протоколы клиентского компьютера 1 сети А с протоколами серверного компьютера 3 сети В. Допустим, что две сети используют полностью отличающиеся стеки протоколов. Как видно из рисунка, в шлюзе реализованы оба стека протоколов.

Рис. 3.14. Принципы функционирования шлюза 

Запрос от прикладного процесса клиентского компьютера сети А поступает на прикладной уровень его стека протоколов. В соответствии с этим протоколом на прикладном уровне формируются соответствующий пакет (или несколько пакетов), в которых передается запрос на выполнение сервиса некоторому серверу сети В. Пакет прикладного уровня передается вниз по стеку компьютера сети А, а затем в соответствии с протоколами канального и физического уровней сети А поступает в компьютер 2, то есть в шлюз.

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

3.5Мультиплексирование стеков протоколов

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

Рис. 3.15. Мультиплексирование стеков 

При мультиплексировании стеков протоколов на один из двух взаимодействующих компьютеров с различными стеками протоколов помещается коммуникационный стек другого компьютера. На рисунке 3.15 приведен пример взаимодействия клиентского компьютера сети 1 с сервером своей сети и сервером сети 2, работающей со стеком протоколов, полностью отличающимся от стека сети 1. В клиентском компьютере реализованы оба стека. Для того, чтобы запрос от прикладного процесса был правильно обработан и направлен через соответствующий стек, в компьютер необходимо добавить специальный программный элемент - мультиплексор протоколов. Мультиплексор должен уметь определять, к какой сети направляется запрос клиента. Для этого может использоваться служба имен сети, в которой отмечается принадлежность того или иного ресурса определенной сети с соответствующим стеком протоколов.

При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной. В общем случае на каждом уровне вместо одного протокола появляется целый набор протоколов, а мультиплексоров может быть несколько, выполняющих коммутацию между протоколами разных уровней (рисунок 3.16). Например, рабочая станция может получить доступ к сетям с протоколами NetBIOS, IP, IPX через один сетевой адаптер. Аналогично, сервер, поддерживающий прикладные протоколы NCP, SMB и NFS может без проблем выполнять запросы рабочих станций сетей NetWare, Windows NT и Sun одновременно.

Рис. 3.16. Мультиплексирование протоколов 

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

3.6 Использование магистрального протокола

Хорошим решением был бы переход на единый стек протоколов, но вряд ли эта перспектива осуществится в ближайшем будущем. Попытка введения единого стека коммуникационных протоколов сделана в 1990 году правительством США, которое обнародовало программу GOSIP - Government OSI Profile, в соответствии с которой стек протоколов OSI должен стать общим знаменателем для всех сетей, устанавливаемых в правительственных организациях США. Но, понимая бесполезность силовых мер, программа GOSIP не ставит задачу немедленного перехода на стек OSI, а принуждает пока к использованию этого стека в качестве "второго языка" правительственных сетей, наряду с родным, первым.

3.7 Вопросы реализации

При объединении сетей различных типов в общем случае необходимо обеспечить двухстороннее взаимодействие сетей, то есть решить две задачи (рисунок 3.17):

1. Обеспечение доступа клиентам сети A к ресурсам и сервисам серверов сети B.

2. Обеспечение доступа клиентам сети B к ресурсам и сервисам сети A.

Рис. 3.17. Варианты сетевого взаимодействия 

Эти задачи независимы и их можно решать отдельно. Прежде всего нужно понять, необходимо ли полное решение или достаточно и частичного, то есть нужно ли, чтобы пользователи, например, UNIX-машин имели доступ к ресурсам серверов сети NetWare, а пользователи персональных машин имели доступ к ресурсам UNIX-хостов, или же достаточно обеспечить доступ к ресурсам другой сети только одному виду пользователей.

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

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

В то время, как расположение программных средств, реализующих шлюз, уже было определено - они должны располагаться на компьютере, занимающем промежуточное положение между двумя взаимодействующими машинами, вопрос о размещении дополнительных стеков протоколов остался открытым. Заметим также, что шлюз реализует взаимодействие "многие-ко-многим" (все клиенты могут обращаться ко всем серверам).

Рассмотрим все возможные варианты размещения программных средств, реализующих взаимодействие двух сетей, которые основаны на мультиплексировании протоколов. Введем некоторые обозначения: С - сервер, К - клиент, ( - дополнительный протокол или стек протоколов.

На рисунке 3.18 показаны оба возможных варианта однонаправленного взаимодействия А®В: а) путем добавления нового стека к клиентам сети А, либо б) путем присоединения "добавки" к серверам сети В.

В первом случае, когда средства мультиплексирования располагаются на клиентских частях, только клиенты, снабженные средствами мультиплексирования протоколов, могут обращаться к серверам сети В, при этом они могут обращаться ко всем серверам сети В. Во втором случае, когда набор стеков расположен на каком-либо сервере сети В, данный сервер может обслуживать всех клиентов сети А. Очевидно, что серверы сети В без средств мультиплексирования не могут быть использованы клиентами сети А.

Рис. 3.18. Варианты размещения программных средств
(С - cервер, К - клиент, ( - средства сетевого взаимодействия)
 

Примером "добавки", модифицирующей клиентскую часть, может служить популярное программное средство фирмы Novell LAN Workplace, которое превращает клиента NetWare в клиента UNIX. Аналогичным примером для модификации сервера могут служить другие продукты фирмы Novell: NetWare for UNIX, который делает возможным использование услуг сервера UNIX клиентами NetWare, или Novell NetWare for VMS, который служит для тех же целей в сети VMS.

Взаимодействие А ( В реализуется симметрично.

Если же требуется реализовать взаимодействие в обе стороны одновременно, то для этого существует четыре возможных варианта, показанных на рисунке 3.19. Каждый вариант имеет свои особенности с точки зрения возможностей связи клиентов с серверами:

  1. Средства обеспечения взаимодействия расположены только на клиентских частях обеих сетей. Для тех и только тех клиентов обеих сетей, которые оснащены "добавками", гарантируется возможность связи со всеми серверами из "чужой" сети.
  2. Все средства обеспечения взаимодействия расположены на стороне сети А. Все клиенты сети В могут обращаться к серверам сети А (не ко всем, а только к тем, которые имеют сетевую "добавку"). Часть клиентов сети А, которые обозначены как К+(, могут обращаться ко всем серверам сети В.
  3. Средства межсетевого взаимодействия расположены только на серверных частях обеих сетей. Всем клиентам обеих сетей гарантируется возможность работы с серверами "чужих" сетей, но не со всеми, а только с серверами, обладающими сетевыми средствами мультиплексирования протоколов.
  4. Все средства межсетевого взаимодействия расположены на стороне В. Двусторонний характер взаимодействия обеспечивается модификацией и клиентских, и серверных частей сети В. Все клиенты сети А могут обращаться за сервисом к серверам сети В, обозначенным как С+(, а все серверы сети А могут обслуживать клиентов сети В, обозначенных как К+(.

Рис. 3.19. Варианты размещения программных средств при двустороннем взаимодействии
(С - cервер, К - клиент, ( - средства сетевого взаимодействия)
 

Очевидно, что наличие программных продуктов для каждого из рассмотренных вариантов сильно зависит от конкретной пары операционных систем. Для некоторых пар может вовсе не найтись продуктов межсетевого взаимодействия, а для некоторых можно выбирать из нескольких вариантов. Рассмотрим в качестве примера набор программных продуктов, реализующих взаимодействие Windows NT и NetWare. В ОС Windows NT и в серверной части (Windows NT Server), и в клиентских частях (Windows NT Workstation) предусмотрены встроенные средства мультиплексирования нескольких протоколов, в том числе и стека IPX/SPX. Следовательно эта операционная система может поддерживать двустороннее взаимодействие (по варианту 2) с NetWare без каких-либо дополнительных программных средств. Аналогичным образом реализуется взаимодействие сетей Windows NT с UNIX-сетями.

3.8 Сравнение вариантов организации взаимодействия сетей

Возвращаясь к принципам организации взаимодействия сетей, сравним два основных подхода - мультиплексирование протоколов и трансляцию протоколов (шлюзы).

Встроенные в сетевую ОС средства мультиплексирования протоколов дают все те преимущества, которые присущи встроенным средствам:

  1. Эти средства не нужно отдельно приобретать;
  2. Нет проблем их совместимости с другими продуктами.

Основным недостатком этого подхода является избыточность. Хотя средства мультиплексирования обычно позволяют загружать и выгружать по желанию пользователя различные стеки протоколов, но если нужно одновременно работать с тремя различными сетями, то в каждую рабочую станцию необходимо загрузить все три стека одновременно.

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

  1. Позволяет сосредоточить все функции согласования протоколов в одном месте и разгрузить рабочие станции от дополнительного программного обеспечения, а их пользователей - от необходимости его генерации. Шлюз сохраняет в локальной сети ее родную среду протоколов, что повышает производительность, так как стек протоколов был специально спроектирован для данной операционной среды и наилучшим образом учитывает ее особенности.
  2. Возникающие проблемы легко локализуются.
  3. Обслуживающий персонал работает в привычной среде, где можно использовать имеющийся опыт по поддержанию сети. Шлюзы сохраняют различные, несовместимые сети в их первозданном виде. Если имеется несколько различных сетей, то для их совместной работы может понадобиться значительное количество шлюзов. Для доступа пользователей сети UNIX к мейнфрейму понадобится шлюз UNIX-SNA, для подключения пользователей NetWare к компьютерам UNIX и мейнфрейму нужно два шлюза - NetWare-UNIX и NetWare-SNA.

Недостатки использования шлюзов:

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

4. Службы именования ресурсов и проблемы прозрачности доступа

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

Хотя полезных применений единой справочной службы много, она нужна по крайней мере для эффективного решения задачи администрирования, то есть ведения учетной информации на пользователей сети и определения прав доступа этих пользователей к разделяемым ресурсам сети. Эта задача всегда решалась каким-либо способом во всех многопользовательских операционных системах, не обязательно сетевых. В локальных версиях UNIX имеются файлы с предопределенными именами, хранящие эту информацию - например, файл /etc/passwd хранит информацию о пользователях и их паролях, а также о группах пользователей.

В идеале сетевая справочная информация должна быть реализована в виде единой базы данных, а не представлять собой набор баз данных, специализирующихся на хранении информации того или иного вида, как это часто бывает в реальных операционных системах. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая используется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение низкоуровневых адресов: WINS - устанавливает соответствие Netbios-имен IP-адресам, справочник DNS - сервер имен домена - оказывается полезным при подключении NT-сети к Internet, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Ближе к идеалу находятся справочные службы, поставляемые фирмой Banyan (продукт Streettalk III) и фирмой Novell (NetWare Directory Services), предлагающие единый справочник для всех сетевых приложений.

Единая база данных, хранящая справочную информацию, предоставляет все то же многообразие возможностей и порождает все то же множество проблем, что и любая другая крупная база данных. Она позволяет осуществлять различные операции поиска, сортировки, модификации и т.п., что очень сильно облегчает жизнь как администраторам, так и пользователям. Набор разрозненных баз данных не предоставляет такого прозрачного доступа к ресурсам сети, как это имеет место в случае использования ОС NetWare 3.x с ее базой bindery, локальной для каждого сервера. В последнем случае пользователь должен заранее знать, на каком сервере находится нужный ему ресурс и производить логическое подключение к этому серверу для получения доступа к этому ресурсу. Для того, чтобы получить доступ к ресурсам какого-нибудь сервера, пользователь должен иметь там свою учетную информацию, которая дублируется таким образом на всех серверах сети. В единой базе данных о каждом пользователе существует только одна запись.

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

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

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

Существует два подхода к организации справочной службы сети: доменный и глобальный. Рассмотрим эти подходы на конкретных примерах - доменной справочной службе ОС Windows NT и глобальной справочной службе NDS ОС NetWare. Естественно, это не единственные операционные системы, где такие службы имеются - доменная служба реализована в Microsoft LAN Manager и IBM LAN Server, а глобальная справочная служба - в ОС Banyan VINES (служба Streettalk III). Более того, существует стандарт X.500, разработанный МККТТ для глобальной справочной службы почтовых систем, который с успехом может применяться и применяется для хранения любой справочной информации.

4.1 Доменный подход

Домен - это основная единица администрирования и обеспечения безопасности в Windows NT. Для домена существует общая база данных учетной информации пользователей (user accounts), так что при входе в домен пользователь получает доступ сразу ко всем разрешенным ресурсам всех серверов домена.

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

Рис. 4.1. Доверительные отношения между доменами

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

Доверительные отношения не являются транзитивными. Например, если домен А доверяет домену В, а В доверяет С, то это не значит, что А автоматически доверяет С.

4.1.1 Основной и резервные контроллеры домена

В домене должен находится сервер, выполняющий роль основного контроллера домена (primary domain controller). Этот контроллер хранит первичную копию базы данных учетной информации пользователей домена. Все изменения, производимые в учетной информации, сначала производятся именно в этой копии. Основной контроллер домена всегда существует в единственном экземпляре. Пользователь, который администрирует домен, не должен явно задавать имя компьютера, который выполняет роль основного контроллера, утилита, в помощью которой осуществляется администрирование (в Windows NT это User Manager for Domains), должна по имени домена самостоятельно, в соответствии с заранее разработанным протоколом провести диалог с основным контроллером домена и сделать нужные изменения в его базе данных.

Кроме основного контроллера в домене могут существовать несколько резервных контроллеров (backup domain controllers). Эти контроллеры хранят реплики базы учетных данных. Все резервные контроллеры в дополнение к основному могут обрабатывать запросы пользователей на логический вход в домен.

Резервный контроллер домена решает две задачи:

  1. Он становится основным контроллером при отказе основного.
  2. Уменьшает нагрузку на основной контроллер по обработке логических входов пользователей.

Если сеть состоит из нескольких сетей, соединенных глобальными связями, то в каждой сети должен быть по крайней мере один резервный контроллер домена.

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

4.1.2 Четыре модели организации связи доменов

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

Microsoft предлагает использовать четыре типовые модели использования доменов на предприятии:

  1. Модель с одним доменом;
  2. Модель с главным доменом;
  3. Модель с несколькими главными доменами;
  4. Модель с полными доверительными отношениями.

Модель с одним доменом 

Эта модель подходит для организации, в которой имеется не очень много пользователей, и нет необходимости разделять ресурсы сети по организационным подразделениям. Главный ограничитель для этой модели - производительность, которая падает, когда пользователи просматривают домен, включающий много серверов.

Использование только одного домена также означает, что сетевой администратор всегда должен администрировать все серверы. Разделение сети на несколько доменов позволяет назначать администраторов, которые могут администрировать только отдельные серверы, а не всю сеть.

Таблица 4.1.
Преимущества и недостатки модели с одним доменом 

Преимущества

Недостатки 

Наилучшая модель для предприятий с небольшим
числом пользователей и ресурсов
Централизованное управление пользовательской
учетной информацией
Нет нужды в управлении доверительными отношениями
Локальные группы нужно определять только однажды

Низкая производительность, если
домен имеет слишком много
пользователей и/или серверов
Невозможность группирования
ресурсов

Модель с главным доменом 

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

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

Рис. 4.2. Модель с главным доменом

Таблица 4.2.
Преимущества и недостатки модели с главным доменом 

Преимущества

Недостатки 

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

Плохая производительность, если в главном домене слишком много пользователей и групп
Локальные группы нужно образовывать в каждом домене, где они используются

Модель с несколькими главными доменами 

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

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

Рис. 4.3. Модель с несколькими главными доменами

Каждый главный домен доверяет всем остальным главным доменам. Каждый домен отдела доверяет всем главным доменам, но доменам отделов нет необходимости доверять друг другу.

Так как все ресурсные домены доверяют всем главным, то данные о любом пользователе могут использоваться в любом отделе предприятия.

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

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

Таблица 4.3.
Преимущества и недостатки модели с несколькими главными доменами 

Преимущества

Недостатки 

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

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

Модель с полными доверительными отношениями 

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

Рис. 4.4. Модель с полными доверительными отношениями

Из-за резкого увеличения числа доверительных отношений эта модель не подходит для больших предприятий. Для n доменов нужно установить n(n-1) доверительных отношений.

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

Таблица 4.4.
Преимущества и недостатки модели с полными доверительными отношениями 

Преимущества

Недостатки 

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

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

4.2 Служба каталогов

Служба NDS ОС NetWare 4.x - это глобальная служба справочников, использующая распределенную объектно-ориентированную базу данных сетевых ресурсов. База данных NDS содержит информацию о всех сетевых ресурсах, включая информацию о пользователях, группах пользователей, принтерах, томах и компьютерах. NetWare использует эту информацию для обеспечения доступа к этим ресурсам.

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

База данных службы NDS представляет собой многоуровневую базу данных, поддерживающую информацию о ресурсах всех серверов сети. Для совместимости с предыдущими версиями NetWare в службе NDS предусмотрен механизм эмуляции базы bindery.

Служба NDS представляет собой значительный шаг вперед по сравнению с предыдущими версиями за счет:

  1. распределенности;
  2. реплицируемости;
  3. прозрачности;
  4. глобальности.

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

Рис.4.5. Разделы базы данных NDS

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

Прозрачность заключается в том, что NDS автоматически создает связи между программными и аппаратными компонентами, которые обеспечивают пользователю доступ к сетевым ресурсам. NDS при этом не требует от пользователя знаний физического расположения этих ресурсов. Задавая сетевой ресурс по имени, вы получите к нему корректный доступ даже в случае изменения его сетевого адреса или места расположения.

Глобальность NDS заключается в том, что после входа вы получаете доступ к ресурсам всей сети, а не только одного сервера, как было в предыдущих версиях. Это достигается за счет процедуры глобального логического входа (global login). Вместо входа в отдельный сервер пользователь NDS входит в сеть. После чего он получает доступ к разрешенным для него ресурсам сети. Информация, предоставляемая во время логического входа, используется для процесса идентификации пользователя. Позже, при попытке пользователя получить доступ к ресурсам, таким как серверы, тома или принтеры, фоновый процесс идентификации проверяет, имеет ли пользователь право использовать данный ресурс.

Объектно-ориентированный подход 

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

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

Еще одна категория объектов, в которую входят, например, объекты типа отдела предприятия, помогают организовывать и упорядочивать другие объекты.

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

Дерево каталогов 

NDS использует для хранения информации логическую структуру, называемую деревом каталогов (Directory Tree, DT). Эта иерархическая структура имеет корневой элемент (root) и ветви (рисунок 3.25). Администратору сети NetWare 4.x предоставляется удобная графическая утилита NetWare Administrator, работающая в среде Windows, наглядно представляющая каждый объект дерева каталогов NDS в виде иконки и отражающая связи между объектами. Пользователи также получают удобства прозрачного доступа к ресурсам всей сети, если они пользуются оболочкой NetWare для Windows, которая поддерживает диалог с NDS и представляет доступные пользователю ресурсы в виде вложенных пиктограмм.

Дерево каталогов содержит объекты двух типов:

  1. объекты-контейнеры,
  2. объекты листья.

Объекты-контейнеры содержат или включают другие объекты. Они используются для логического упорядочивания и организации других объектов дерева.

NDS содержит объекты-контейнеры трех типов, которые можно использовать для организации дерева объектов:

  1. Страна (Country) - необязательный объект, который можно использовать в сетях, охватывающих несколько стран.
  2. Организация (Organization) - располагается уровнем ниже, чем объекты-страны (если они используются).
  3. Отдел или подразделение организации (Organizational Unit) - располагается уровнем ниже, чем объекты-организации. Помогает в дальнейшем упорядочивании остальных объектов.

Рис. 4.6. Типичная структура дерева каталогов NDS

Объекты-листья не содержат другие объекты, они используются для представления конечных сетевых ресурсов, таких как компьютеры, тома, принтеры, пользователи и группы пользователей. В NDS определены еще и такие типы объектов-листьев, как:

  1.  организатор - используется для таких руководящих лиц фирмы, как руководитель группы или вице-президент,
  2.  сервер,
  3.  принт-сервер,
  4.  очередь печати,
  5.  карта каталогов на томе,
  6.  профиль - представляет командный файл входа Login Script для специальной группы пользователей, которые хотят разделять общие команды Login Script, но не обязательно входят в один объект-контейнер в дереве каталогов, или же для подмножества пользователей одного контейнера,
  7.  псевдоним - указывает на оригинальное местонахождения объекта в дереве. Любой объект может быть расположенным в нескольких местах дерева с использованием псевдонимов. Псевдонимы делают использование NDS более гибким и удобным.

Служба NDS и файловая система 

Служба NDS предназначена для управления такими сетевыми ресурсами, как серверы и тома NetWare, но она не обеспечивает управление файловой системой. Файлы и каталоги не являются объектами службы NDS. Однако они представляются в виде иконок при использовании графической утилиты NetWare Administrator. Одним из атрибутов объекта-тома является месторасположение физического тома, который содержит файлы и каталоги. Таким образом, объект-том представляет собой связь между NDS и файловой системой.

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

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

Имена и контексты 

В именовании объектов служба NDS использует те же принципы, что и файловые системы MS DOS и UNIX. Объект-лист имеет краткое имя, называемое Common Name (CN). Оно может состоять максимум из 64 символов, включая пробелы. Поэтому имя принтера "Быстрый, но часто ломающийся Epson" является законным. Аналогом полного имени файловой системы MS DOS является так называемое "различимое имя" - Distinguished Name. Различимое имя представляет собой конкатенацию всех имен объектов, расположенных на пути этого объекта к корню дерева. Составляющие различимого имени отделяются друг от друга точкой. В отличие от полных имен MS DOS крайней левой составляющей различимого имени является краткое имя объекта, а крайней правой составляющей - имя корневого объекта. Например,

Vova S.NetProgrammers.Microsoft.US

представляет собой различимое имя объекта-пользователя с сетевым именем Vova S, работающего в сетевом отделе фирмы Microsoft, расположенной в США. Возможен и другой вариант записи различимого имени с указанием типов объектов:

CN=Vova s.Ou=NetProgrammers.O=Microsoft.C=US.

Такой вид записи более содержателен.

Средства защиты объектов в NDS 

Служба NDS определяет права доступа одних сетевых объектов к другим. Различаются права доступа к объекту в целом и права доступа к его атрибутам.

По отношению к объектам существует следующий набор прав:

  1.  Browse - просмотр;
  2.  Add - добавление;
  3.  Delete - удаление;
  4.  Rename - переименование;
  5.  Supervisor - обеспечивает все перечисленные выше права.

По отношению к атрибутам объектов используются такие права:

  1.  Compare - сравнение значения атрибута;
  2.  Read - чтение значения атрибута;
  3.  Write - запись нового значения атрибута;
  4.  Self - присвоение себя в качестве значения атрибута другого объекта, например, если объект-группа разрешает право Self для объекта User, то последний может сделать себя членом этой группы;
  5.  Supervisor - все права по доступу к атрибутам.

С каждым объектом связан список управления доступом (ACL), в котором определяются права доступа к данному объекту со стороны других объектов.

Права доступа наследуются в дереве объектов сверху вниз, поэтому права объекта-контейнера наследуются входящими в него объектами. Для достижении необходимой гибкости в наделении объекта правами используется маска наследования (Inheritance Mask), с помощью которой можно заблокировать некоторые наследуемые права. С помощью наследования прав доступа главный администратор дерева, имеющий доступ ко всем его объектам, может назначить администратора поддерева, который получит права доступа ко всем объектам данного поддерева. Если поддерево соответствует какой-либо структурной единице предприятия (что и подразумевается), например отделу, то это будет администратор отдела, управляющий пользователями и ресурсами данного отдела.

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

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

Существуют три типа реплик: главная реплика (master replica), вторичная реплика (read/write replica) и реплика только для чтения (read-only replica).

Главная реплика позволяет проводить над ней такие операции, как создание нового раздела, слияние разделов и удаление раздела.

Вторичная реплика разрешает обновлять информацию об объектах, добавлять новые объекты, но не разрешает создавать новые разделы.

Реплика только для чтения позволяет только читать информацию из ее базы и проводить операции поиска.

В сети может существовать произвольное количество реплик. При изменения информации в какой-либо реплике автоматически запускается процесс обновления всех остальных реплик. Этот процесс называется процессом синхронизации службы каталогов (DSS).

Любой сервер NetWare, поддерживающий службу NDS, называется сервером имен.

5. Общий обзор сетевых ОС

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

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

Сетевая операционная система масштаба предприятия прежде всего должна обладать основными свойствами любых корпоративных продуктов, в том числе:

  1. масштабируемостью, то есть способностью одинаково хорошо работать в широком диапазоне различных количественных характеристик сети,
  2. совместимостью с другими продуктами, то есть способностью работать в сложной гетерогенной среде интерсети в режиме plug-and-play.

Корпоративная сетевая ОС должна поддерживать более сложные сервисы. Подобно сетевой ОС рабочих групп, сетевая ОС масштаба предприятия должна позволять пользователям разделять файлы, приложения и принтеры, причем делать это для большего количества пользователей и объема данных и с более высокой производительностью. Кроме того, сетевая ОС масштаба предприятия обеспечивает возможность соединения разнородных систем - как рабочих станций, так и серверов. Например, даже если ОС работает на платформе Intel, она должна поддерживать рабочие станции UNIX, работающие на RISC-платформах. Аналогично, серверная ОС, работающая на RISC-компьютере, должна поддерживать DOS, Windows и OS/2. Сетевая ОС масштаба предприятия должна поддерживать несколько стеков протоколов (таких как TCP/IP, IPX/SPX, NetBIOS, DECnet и OSI), обеспечивая простой доступ к удаленным ресурсам, удобные процедуры управления сервисами, включая агентов для систем управления сетью.

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

Важным свойством справочной службы является ее масштабируемость, обеспечиваемая распределенностью базы данных о пользователях и ресурсах.

Такие сетевые ОС, как Banyan Vines, Novell NetWare 4.x, IBM LAN Server, Sun NFS, Microsoft LAN Manager и Windows NT Server, могут служить в качестве операционной системы предприятия, в то время как ОС NetWare 3.x, Personal Ware, Artisoft LANtastic больше подходят для небольших рабочих групп.

Критериями для выбора ОС масштаба предприятия являются следующие характеристики:

  1. Органичная поддержка многосерверной сети;
  2. Высокая эффективность файловых операций;
  3. Возможность эффективной интеграции с другими ОС;
  4. Наличие централизованной масштабируемой справочной службы;
  5. Хорошие перспективы развития;
  6. Эффективная работа удаленных пользователей;
  7. Разнообразные сервисы: файл-сервис, принт-сервис, безопасность данных и отказоустойчивость, архивирование данных, служба обмена сообщениями, разнообразные базы данных и другие;
  8. Разнообразные программно-аппаратные хост-платформы: IBM SNA, DEC NSA, UNIX;
  9. Разнообразные транспортные протоколы: TCP/IP, IPX/SPX, NetBIOS, AppleTalk;
  10. Поддержка многообразных операционных систем конечных пользователей: DOS, UNIX, OS/2, Mac;
  11. Поддержка сетевого оборудования стандартов Ethernet, Token Ring, FDDI, ARCnet;
  12. Наличие популярных прикладных интерфейсов и механизмов вызова удаленных процедур RPC;
  13. Возможность взаимодействия с системой контроля и управления сетью, поддержка стандартов управления сетью SNMP.

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

Таблица. 1.
Основные характеристики сетевых операционных систем 

Novell
NetWare 4.1

Специализированная операционная система, оптимизированная для работы в качестве файлового сервера и принт-сервера
Ограниченные средства для использования в качестве сервера приложений: не имеет средств виртуальной памяти и вытесняющей многозадачности, а поддержка симметричного мультипроцесcирования отсутствовала до самого недавнего времени. Отсутствуют API основных операционных сред, используемых для разработки приложений, - UNIX, Windows, OS/2
Серверные платформы: компьютеры на основе процессоров Intel, рабочие станции RS/6000 компании IBM под управлением операционной системы AIX с помощью продукта NetWare for UNIX
Поставляется с оболочкой для клиентов: DOS, Macintosh, OS/2, UNIX, Windows (оболочка для Windows NT разрабатывается компанией Novell в настоящее время, хотя Microsoft уже реализовала клиентскую часть NetWare в Windows NT)
Организация одноранговых связей возможна с помощью ОС PersonalWare
Имеет справочную службу NetWare Directory Services (NDS), поддерживающую централизованное управление, распределенную, полностью реплицируемую, автоматически синхронизируемую и обладающую отличной масштабируемостью
Поставляется с мощной службой обработки сообщений Message Handling Service (MHS), полностью интегрированную (начиная с версии 4.1) со справочной службой
Поддерживаемые сетевые протоколы: TCP/IP, IPX/SPX, NetBIOS, Appletalk
Поддержка удаленных пользователей: ISDN, коммутируемые телефонные линии, frame relay, X.25 - с помощью продукта NetWare Connect (поставляется отдельно)
Безопасность: аутентификация с помощью открытых ключей метода шифрования RSA; сертифицирована по уровню C2
Хороший сервер коммуникаций
Встроенная функция компрессии диска
Сложное обслуживание

Banyan
VINES 6.0
и ENS
(Enterprise
Network
Services) 6.0

Серверные платформы:
ENS for UNIX:
работает на RISC-компьютерах под управлением SCO UNIX, HP-UX, Solaris, AIX
ENS for NetWare:
работает на Intel-платформах под управлением NetWare 2.x, 3.x, 4.x
VINES
работает на Intel-платформах
Клиентские платформы: DOS, Macintosh, OS/2, UNIX, Windows for Workgroups, Windows NT
Хороший сервер приложений: поддерживаются вытесняющая многозадачность, виртуальная память и симметричное мультипроцессирование в версии VINES и в ENS-версиях для UNIX. Поддерживаются прикладные среды UNIX, OS/2, Windows
Поддержка одноранговых связей - отсутствует
Справочная служба - Streettalk III, наиболее отработанная из имеющихся на рынке, с централизованным управлением, полностью интегрированная с другими сетевыми службами, распределенная, реплицируемая и автоматически синхронизируемая, отлично масштабируемая
Согласованность работы с другими сетевыми ОС: хорошая; серверная оболочка работает в средах NetWare и UNIX; пользователи NetWare, Windows NT и LAN Server могут быть объектами справочной службы Streettalk III
Служба сообщений - Intelligent Messaging, интегрирована с другими службами
Поддерживаемые сетевые протоколы: VINES IP, TCP/IP, IPX/SPX, Appletalk
Поддержка удаленных пользователей: ISDN, коммутируемые телефонные линии, X.25
Служба безопасности: поддерживает электронную подпись (собственный алгоритм), избирательные права доступа, шифрацию; не сертифицирована
Простое обслуживание
Хорошо масштабируется
Отличная производительность обмена данными между серверами, хуже - при обмене сервер-ПК

Microsoft
LAN
Manager

широкая распространенность
работает под OS/2 и UNIX
поддерживает мощные серверные платформы
один сервер может поддерживать до 2 000 клиентов

Microsoft
Windows NT Server
3.51
и 4.0

Серверные платформы: компьютеры на базе процессоров Intel,
PowerPC, DEC Alpha, MIPS
Клиентские платформы: DOS, OS/2, Windows, Windows for Workgroups, Macintosh
Организация одноранговой сети возможна с помощью Windows NT Workstation и Windows for Workgroups
Windows NT Server представляет собой отличный сервер приложений: он поддерживает вытесняющую многозадачность, виртуальную память и симметричное мультипроцессирование, а также прикладные среды DOS, Windows, OS/2, POSIX
Справочные службы: доменная для управления учетной информацией пользователей (Windows NT Domain Directory service), справочные службы имен WINS и DNS
Хорошая поддержка совместной работы с сетями NetWare: поставляется клиентская часть (редиректор) для сервера NetWare (версий 3.х и 4.х в режиме эмуляции 3.х, справочная служба NDS поддерживается, начиная с версии 4.0), выполненная в виде шлюза в Windows NT Server или как отдельная компонента для Windows NT Workstation; недавно Microsoft объявила о выпуске серверной части NetWare как оболочки для Windows NT Server
Служба обработки сообщений - Microsoft Mail, основанная на DOS- платформе, в этом году ожидается версия для платформы Windows NT - Microsoft Message Exchange, интегрированная с остальными службами Windows NT Server
Поддерживаемые сетевые протоколы: TCP/IP, IPX/SPX, NetBEUI, Appletalk
Поддержка удаленных пользователей: ISDN, коммутируемые телефонные линии, frame relay, X.25 - с помощью встроенной подсистемы Remote Access Server (RAS)
Служба безопасности: мощная, использует избирательные права доступа и доверительные отношения между доменами; узлы сети, основанные на Windows NT Server, сертифицированы по уровню C2
Простота установки и обслуживания
Отличная масштабируемость

IBM LAN Server 4.0

Серверные платформы: операционные системы MVS и VM для мейнфреймов; AS/400 с OS/400, рабочие станции RS/6000 с AIX, серверы Intel 486 или Pentium под OS/2
Поставляется с оболочками для клиентов: DOS, Macintosh, OS/2, Windows, Windows NT, Windows for Workgroups
Серверы приложений могут быть организованы с помощью LAN Server 4.0 в операционных средах MVS, VM, AIX, OS/2, OS/400. В среде OS/2 поддерживаются: вытесняющая многозадачность, виртуальная память и симметричное мультипроцессирование
Организация одноранговых связей возможна с помощью ОС Warp Connect
Справочная служба - LAN Server Domain, то есть основа на доменном подходе
Поддерживаемые сетевые протоколы: TCP/IP, NetBIOS, Appletalk
Безопасность - избирательные права доступа, система не сертифицирована
Служба обработки сообщений - отсутствует
Высокая производительность
Недостаточная масштабируемость

IBM и NCR
LAN
Manager

LAN Manager for UNIX хорошо распространена (15% объема мировых продаж сетевых ОС)
LAN Manager for AIX поддерживает RISC компьютеры System/6000 в качестве файлового сервера
Работает под UNIX, имеет все преимущества, связанные с использованием этой ОС


 

А также другие работы, которые могут Вас заинтересовать

26953. Основные правовые семьи современности 8.72 KB
  Национальноправовые системы историческая совокупность праваюридической практики и господствующей правовой идеологии отдельной страныотражающая ее социальноэкономические политические и культурные особенности.Суды общей юрисдикции рассматривают дела всех категорийпоэтому отсутствует деление права на частное и публичноенет деления права по отраслямнет кодификации норм права.ИСТОЧНИК:нормативноправовой актакт правотворчествапринятый в особом порядке строго определенными субъектами и содержащий норму права.Существенную роль при...
26954. Правовое регулирование и правовое воздействие. 7.35 KB
  ТИП ПРАВОВОГО РЕГУЛИРОВАНИЯ определенный порядок регулирования выражающий общую направленность воздействия на общественные отношения которая зависит от соотношения дозволений и запретов в праве. В основе такого регулирования лежит общее дозволение а само регулирование осуществляется при помощи конкретных запретов. В основе такого регулирования лежит общий запрет а само регулирование осуществляется при помощи конкретных дозволений.
26956. Виды правонарушений 6.48 KB
  состав Правонарушениевиновное поведение праводееспособного индивидакоторе противоречит предписаниям норм правапричиняет вред другим лицам и влечет за собой юридическую ответственность. ДИСЦИПЛИНАРНЫЙправонарушениекоторое совершается в сфере служебных отношенийи нарушаетглавным образом порядок отношений подчиненности по службе. АДМИНИСТРАТИВНЫЙправонарушениепосягающее на установленный законом общественный порядокна отношения в области исполнительной и рапорядительной деятельности органов госване связанные с осуществлением служебных...
26957. Причины правонарушений, пути их преодоления 9.63 KB
  ТЕОРИЯ ПРИРОЖДЕННОГО ПРЕСТУПНИКА есть людиобладающие определенным набором признакова потому предрасположенные к совершению преступленийт.Баснословные цены на продукты питания и промышленные товары привели к небывалому росту таких преступленийкак кражииные хищения имуществаграбежиразбои.На приобретение наркотиков и алкогольных напитков постоянно требуются немалые суммы денегчто провоцирует лицих употребляющихна совершение таких преступленийкак кражиграбежи ит. ПРОФИЛАКТИКАспециально осуществляемая деятельность по учету и...
26958. Понятие, признаки и виды юридической ответственности 12.44 KB
  Понятиепризнаки и виды юридической ответственности.Характеризуется определенными ЛИШЕНИЯМИкоторые правонарушитель должен претерпетьобъективное свойство ответственности; 3.Условиями этой ответственности являются: противоправное поведение должника возникновение убытков кредитора наличие причинной связи между поведением должника и возникновением убытков у кредитора вина должника.Административной ответственности подлежит лицо достигшее к моменту совершения административного правонарушения 16 лет.
26960. Понятие и формы реализации права 6.75 KB
  Понятие и формы реализации права. РЕАЛИЗАЦИЯ НОРМ ПРАВА воплощение их предписаний в правомерном поведении субъектов правав их практической деятельности. ОСОБЕННОСТИ: 1 Реализация права всегда связана ТОЛЬКО с ПРАВОМЕРНЫМ ПОВЕДЕНИЕМ людейтаким поведениемкоторое соответствует правовым предписаниям.Это АКТИВНЫЕ положительные действияиспользование права или исполнение обязанности;в другомБЕЗДЕЙСТВИЕ субъектоввоздержание от совершения противоправных действий.
26961. Применение норм права 11.11 KB
  Применение норм права. РЕАЛИЗАЦИЯ НОРМ ПРАВА воплощение предписаний норм права в правомерном поведении субъектов правав их практической деятельности. ОСОБЕННОСТИ: 1 Реализация права всегда связана ТОЛЬКО с ПРАВОМЕРНЫМ ПОВЕДЕНИЕМ людейтаким поведениемкоторое соответствует правовым предписаниям.Это АКТИВНЫЕ положительные действияиспользование права или исполнение обязанности;в другомБЕЗДЕЙСТВИЕ субъектоввоздержание от совершения противоправных действий.