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

Распределенная система синхронизация кода.

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

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

Распределенные системы обнаружения спама.

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

Распределенная система управления сетями.

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

Распределенная файловая система (Distributed File System – DFS) для OL Windows 2000 Server представляет собой одну из сетевых служб, которая упрощает поиск и администрирование данных в корпоративных сетях.

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

2.3 Нефункциональные требования к РСОИ

Требования бывают: функциональные и нефункциональные.

Функциональные – поддаются локализации при реализации

Нефункциональные – относятся к качеству системы – носят глобальный характер и оказывают существенное влияние на выбор общей архитектуры системы на этапе проектирования:

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

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

· Никто не обладает полной информацией о системе

· Решения принимаются на основе лекальной информации

· Сбой в одном месте не вызывает нарушения работы алгоритма

· существования единого времени не требуется

· Прозрачность (в следующем билете)

Открытость

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

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

Неоднородность

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

· Компоненты могут приобретаться в готовом виде

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

· Компоненты создаются разными разработчиками

· Используются различные технологии

Разделение ресурсов

Ресурс – аппаратура, ПО, данные. Требуется определить, кому будет разрешен доступ к ресурсу => требуется вести учет пользователей. Менеджер ресурсов – компонент, предоставляющий доступ к разделяемым ресурсам.

Модели взаимодействия:

· Клиент-серверная (сервер предоставляет доступ к ресурсам)

· Концепция распределенных объектов, предоставляющих доступ к имеющимся у них ресурсам при обращении других компонентов

Отказоустойчивость

Система может продолжать работу даже в случае неисправности => избыточность => применение репликации (при отказе компонента, начинает работать его копия и обслуживание не прекращается)

2.4 Прозрачность в РСОИ

Имеет несколько различных аспектов:

1. Прозрачность масштабируемости (обеспечивается 4, 5) - программист не должен знать, как достигается масштабируемость распределенной системы.

2. Прозрачность производительности (обеспечивается 4, 5) – пользователь и программист не знают, как поддерживается хорошая производительность.

3. Прозрачность отказа (обеспечивается 5, 6) - пользователям и программистам не требуется знать, как ВС справляется с отказами.

4. Прозрачность миграции (обеспечивается 7, 8) – перемещение компонентов незаметно для пользователей и без специальных действий со стороны разработчиков этих компонентов

5. Прозрачность репликации (обеспечивается 7, 8) – пользователям и разработчика не требуется знать, кто предоставляет услугу – реплика или основной компонент. Разработчики компоненты не должны учитывать возможность его репликации

6. Реплика – копия, которая остается синхронизированной с оригиналом

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

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

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

2.5 Удаленный вызов процедуры: общие сведения

Есть машины: A и B. A вызывает процедуру, которая выполняется на B.

count = read(fd, buf, bytes);

Стек при вызове процедуры:

 Скачать реферат