Размещено на http://www.allbest.ru/

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Кубанский государственный технологический университет»

Факультет Машиностроения и автосервиса

Кафедра Систем управления и технологических комплексов

Контрольная работа

по дисциплине «Математическое и программное обеспечение распределенных систем управления»

Краснодар 2017

Введение

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

? формирование у студентов минимально необходимых знаний в области построения распределенных систем;

? ознакомление с техническими, алгоритмическими, программными и

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

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

информационный технология алгоритмический

1. Концепции программных решений

Хотя аппаратные решения важны для РС, наибольшее влияние на них оказывают именно программные решения.

Программные решения влияют, в первую очередь, на удобство работы пользователя в РИС:

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

· память,

· процессоры,

· периферийное оборудование,

· сеть и данные.

В этом они подобны ОС.

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

Эти функции обычно выполняют ОС.

Для распределенных компьютеров ОС можно разделить на две категории:

· сильно связанные

· и слабо связанные.

1.1. Сильно связанные ОС обычно называются распределенными ОС (Distributed Operation System, DOS) и используются для управления мультипроцессорными и гомогенными мультикомпьютерными системами.

Основная их цель - скрыть тонкости управления аппаратным обеспечением.

1.2. Слабо связанные ОС называются сетевыми ОС (Network Operation System, NOS). Они используются для управления гетерогенными мультикомпьютерными системами. Помимо традиционных функций управления ресурсами, они должны обеспечить доступ удаленных клиентов к локальным службам.

Для создания РИС служб сетевой ОС недостаточно.

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

Эти компоненты образуют средства промежуточного уровня (middleware) и составляют основу современных РИС. В таблице 1. представлены основные назначения ОС и промежуточного уровня.

 Таблица 1.

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

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

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

Поэтому этот уровень и называется промежуточным.

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

Примечание

Сомкеты(англ.socket-- разъём) -- название программного интерфейсадля обеспеченияобмена данными междупроцессами. Процессы при таком обмене могут исполняться как на однойЭВМ, так и на различных ЭВМ, связанных между собойсетью.Сокет--абстрактныйобъект, представляющий конечную точку соединения.

Следует различать клиентскиеисерверные сокеты. Клиентские сокеты грубо можно сравнить с конечными аппаратамителефонной сети, а серверные -- скоммутаторами. Клиентское приложение (например,браузер) использует только клиентские сокеты, а серверное (например,веб-сервер, которому браузер посылает запросы) -- как клиентские, так и серверные сокеты.

1.3. Модели промежуточного уровня.

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

Такая РИС обычно называется системой промежуточного уровня (middleware).

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

Среди моделей определяющих распределение и связь, можно отметить следующие:

1. Самая простая ранняя модель - представление всех объектов в виде файлов (распределенная файловая система).

Пример - файловая система Unix.

2. Вторая ранняя модель основана на удаленных вызовах процедур (Remote Procedure Calls, RPC).

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

Внешне это выглядит как обычный вызов процедуры.

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

Например - DCOM, CORBA.

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

В Web1.0 применяется модель распределенных документов.

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

1.4. Службы (сервисы) промежуточного уровня

Эти службы предназначены для обеспечения основных характеристик РС, прежде всего: прозрачности, открытости и масштабируемости.

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

Интерфейс транспортного уровня (IP), который предоставляется сетевой ОС, полностью заменяется другими средствами.

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

Кроме того, системы промежуточного уровня предоставляют средства для прозрачного доступа к распределенным БД, файловым системам, документам Web.

1.5. Важные службы (сервисы) промежуточного уровня

Важные службы (сервисы) промежуточного уровня , общие для всех систем

1. Именование (naming).

В Web любой документ поименован посредством URL, содержащим имя сервера, на котором находится документ с данным URL.

2. Обеспечение сохранности данных.

Пример - механизм распределенных транзакций.

3. Обеспечение защиты программ и данных.

Основная проблема защиты в системах промежуточного уровня - в распределенности. В сочетании с требованием расширяемости защита превращается в одну из наиболее трудно реализуемых в РИС служб.

2. Архитектура «Клиент-Серверного» взаимодействия

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

Рис. 1 Система клиент/сервер

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

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

2.1 Двухуровневая архитектура

Самой простой архитектурой клиент/сервер является двухуровневая, в которой приложение состоит из сервера (или множества идентичных серверов) и группы клиентов. Существует два вида такой архитектуры (рис. 4).

1. Модель тонкого клиента. В этой модели вся работа приложения и управление данными выполняются на сервере. На клиентской машине запускается только ПО уровня представления.

2. Модель толстого клиента. В этой модели сервер только управляет данными. На клиентской машине реализована работа приложения и взаимодействие с пользователем системы.

Рис. 2. Компьютеры в сети клиент/сервер

Рис. 3. Уровни программного приложения

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

Рис. 4. Модели тонкого и толстого клиентов

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

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

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

Рис. 5. Система клиент/сервер для сети банкоматов

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

Появление языка Java и загружаемых аплетов позволили разрабатывать модели клиент/сервер, которые находятся где-то посередине между моделями тонкого и толстого клиента. Часть программ, составляющих приложение, можно загружать на клиентской машине как аплеты Java и тем самым разгрузить сервер. Интерфейс пользователя строится посредством Web-браузера, который запускает аплеты Java. Однако Web-браузеры от различных производителей и даже различные версии Web-браузеров от одного производителя не всегда выполняются одинаково. Более ранние версии браузеров на старых машинах не всегда могут запустить аплеты Java. Следовательно, такой подход можно использовать только тогда, когда вы уверены, что у всех пользователей системы установлены браузеры, совместимые с Java.

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

2.2 Трехуровневая архитектура клиент/сервер

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

Рис. 6. Трехуровневая архитектура клиент/сервер

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

Банковскую систему, использующую Internet-сервисы, можно реализовать с помощью трехуровневой архитектуры клиент/сервер. База данных расчетов (обычно расположенная на главном компьютере) предоставляет сервисы управления данными, Web-сервер поддерживает сервисы приложения, например средства перевода денег, генерацию отчетов, оплату счетов и др. А компьютер пользователя с Internet-браузером является клиентом. Как показано на рис. 7, эта система масштабируема, так как в нее относительно просто добавить новые Web-серверы при увеличении количества клиентов.

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

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

2.3 Многоуровневые системы

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

Рис. 7. Распределенная архитектура банковской системы с использованием Internet-сервисов

Разработчики архитектур клиент/сервер, выбирая наиболее подходящую, должны учитывать ряд факторов. В табл. 2 перечислены различные случаи применения архитектуры клиент/сервер.

Таблица 2. Применение разных типов архитектуры клиент/сервер

Заключение

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

РИС упрощают интеграцию разных приложений в единую систему;

Масштабируемость.

Размер РИС ограничен только размерами базовой сети.

Платой за эти преимущества:

* усложнение ПО,

* снижение производительности

* проблемы с безопасностью.

Список использованных источников

1.? Таненбаум Э. Распределенные системы. Принципы и парадигмы / Э. Таненбаум, М. ван Стеен. - СПб.: Питер, 2003. - 877 с.: ил. - (Серия «Классика computer science»).

2.? Олифер В.Г. Олифер Н.А. Компьютерные сети. Принципы технологии протоколы (4-е изд.) // СПб.: - Питер, 2010, 916 с. 4 изд.

3.? Миков А.И., Замятина Е.Б. Распределенные системы и алгоритмы // INTUIT, 2007.

4.? Мельников П.П. Технология разработки HTML-документов: Учеб. пособие. - 2005. - 112 с.

4. http://nashaucheba.ru/v22381/соммервилл,_иан._инженерия_программного_обеспечения?page=12

Размещено на Allbest.ru