Лекция 1 Экономическая информация и информационные ресурсы
|
Скачать 1.6 Mb.
|
Распределение по системам В случае распределения по системам машины нижнего уровня сами по себе являются системами, обрабатывающими свои собственные транзакции и только в необходимых случаях передающими транзакции или данные вверх по иерархии другим машинам. При такой обработке периферийные процессоры хранят свои собственные данные и могут автономно работать, хотя и подключены к системам более высокого уровня. При распределении по системам машины нижних и верхних уровней могут быть совершенно различными и несовместимыми. Комбинированные системы Строгого разграничения между распределением по функциям и распределением по системам не существует. В одних ситуациях наблюдается переход от распределения по функциям к распределению по системам с требованием все больших мощностей в периферийных машинах, в других - периферийные машины начинают работать как автономные и затем подсоединяются к системе более высокого уровня. Вертикально распределенная конфигурация может содержать более двух уровней процессоров. В некоторых системах число уровней доходит до четырех. К нижнему уровню могут относиться терминалы для ввода данных или микропроцессоры, а также сканирующие датчики измерительных приборов. На следующем уровне может располагаться компьютер в торговом районе, собирающий и накапливающий данные, относящиеся к этому району, или же компьютер на заводе, который собирает данные от микропроцессоров и используется для планирования производственных операций. Третий уровень представлен большой вычислительной системой в каком-либо отделении фирмы, выполняющей разнообразные виды обработки данных и управляющей различными базами данных для повседневных рутинных операций. Этот вычислительной центр получает информацию от систем нижележащего уровня и посылает им указания. На самом верхнем уровне располагается административная информационная система фирмы со своими структурами данных, отличающимися от структур в системах, используемых для рутинных операций. Эта система помогает при принятии различных административных решений. В нее может быть заложена комплексная финансовая модель фирмы или сложные программы, позволяющие осуществить оптимизацию некоторых операций. Административная система получает обобщенные данные от других систем, находящихся на более низких уровнях. Горизонтальное распределение До сих пор мы рассматривали системы с вертикальным распределением. Перейдем теперь к обсуждению систем с горизонтальным распределением. Горизонтальные конфигурации можно классифицировать по степени гомогенности (однородности) взаимодействующих систем. Степень гомогенности влияет на общую структуру, на выбор программного обеспечения, на способы передачи и на общие методы управления функционированием сети. В одних случаях мы имеем идентичные машины с едиными прикладными программами в рамках конкретной фирмы. В других случаях мы сталкиваемся с несовместимыми машинами, работающими по совершенно разным программам в разных организациях и тем не менее объединенными сетью. Вопрос о том, какой должна быть конфигурация: вертикальной, горизонтальной или смешанной, зависит от структуры обеспечиваемых взаимодействий и схемы использования данных. При проектировании распределенных систем приходится сталкиваться со следующими проблемами: Где находятся требуемые для выполнения работы устройства? Независимы ли эти устройства или работа одних из них зависит от результатов работы других? Какие хранимые данные необходимы для работы устройств? Используют ли они общие или независимые данные? Какие транзакции должны передаваться от одного устройства другому? Какова схема потока транзакций? Должны ли транзакции передаваться от устройства к устройству сразу или допустима задержка? Какова стоимость задержки? В разных фирмах эти проблемы будут решаться по-разному, поскольку различны структуры взаимодействий. Различны и структуры информационных потоков между устройствами. Таким образом, все фирмы стремятся иметь свои собственные, естественные для них формы распределенной обработки. То, что наиболее подходит для авиакомпании, не обязательно хорошо для страхового общества. Многоуровневые архитектуры клиент-сервер Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент-сервер. Такие архитектуры более разумно распределяют модули обработки данных, которые в этом случае выполняются на одном или нескольких отдельных серверах. Эти программные модули выполняют функции сервера для интерфейсов с пользователями и клиента - для серверов баз данных. Кроме того, различные серверы приложений могут взаимодействовать между собой для более точного разделения системы на функциональные блоки, выполняющие определенные роли. Например, можно выделить сервер управления персоналом, который будет выполнять все необходимые для управления персоналом функции. Связав с ним отдельную базу данных, можно скрыть от пользователей все детали реализации этого сервера, разрешив им обращаться только к его общедоступным функциям. Кроме того, такую систему очень просто адаптировать к Web, поскольку проще разработать html-формы для доступа пользователей к определенным функциям базы данных, чем ко всем данным. В трехуровневой архитектуре клиент не перегружен функциями обработки данных, а выполняет свою основную роль системы представления информации, поступающей с сервера приложений. Такой интерфейс можно реализовать с помощью стандартных средств Web-технологии - браузера, CGI и Java. Это уменьшает объем данных, передаваемых между клиентом и сервером приложений, что позволяет подключать клиентские компьютеры даже по медленным линиям типа телефонных каналов. Кроме того, клиентская часть может быть настолько простой, что в большинстве случаев ее реализуют с помощью универсального браузера. Но если менять ее все-таки придется, то эту процедуру можно осуществить быстро и безболезненно. Трехуровневая архитектура клиент-сервер позволяет более точно назначать полномочия пользователей, так как они получают права доступа не к самой базе данных, а к определенным функциям сервера приложений. Это повышает защищенность системы (по сравнению с обычно архитектурой) не только от умышленного нападения, но и от ошибочных действий персонала. Для примера рассмотрим систему, различные части которой работают на нескольких удаленных друг от друга серверах. Допустим, что от разработчика поступила новая версия системы, для установки которой в двухуровневой архитектуре необходимо одновременно поменять все системные модули. Если же этого не сделать, то взаимодействие старых клиентов с новыми серверами может привести к непредсказуемым последствиям, так как разработчики обычно не рассчитывают на такое использование системы. В трехуровневой архитектуре ситуация упрощается. Дело в том, что поменяв сервер приложений и сервер хранения данных (это легко сделать одновременно, так как оба они обычно находятся рядом), мы сразу меняем набор доступных сервисов. Таким образом, вероятность ошибки из-за несоответствия версий серверной и клиентской частей резко сокращается. Если в новой версии какой-либо сервис исчез, то элементы интерфейса, обслуживавшие его в старой системе, просто не будут работать. Если же изменился алгоритм работы сервиса, то он будет корректно работать даже со старым интерфейсом. Многоуровневые клиент-серверные системы достаточно легко можно перевести на Web-технологию - для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. Для разработки этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java. Следует отметить и тот факт, что в трехуровневой системе по каналу связи между сервером приложений и базой данных передается достаточно много информации. Однако это не замедляет вычислений, так как для связи указанных элементов можно использовать более скоростные линии. Это потребует минимальных затрат, поскольку оба сервера обычно находятся в одном помещении. Таким образом, увеличивается суммарная производительность системы - над одной задачей теперь работают два различных сервера, а связь между ними можно осуществлять по наиболее скоростным линиям с минимальными затратами средств. Правда, возникает проблема согласованности совместных вычислений, которую призваны решать менеджеры транзакций - новые элементы многоуровневых систем. Лекция 5 МЕТОДЫ РАБОТЫ В УСЛОВИЯХ ПЕРЕГРУЗКИ Причины перегрузок в сети. Оптимальность управления сетью в условиях перегрузок определяет эффективность использования сети. Пока сеть загружена незначительно, число принимаемых и обрабатываемых пакетов равно числу пришедших. Однако, когда в сеть поступает слишком много пакетов может возникнуть перегрузка и рабочие характеристики деградируют. При очень больших загрузках пропускная способность канала или сети может стать нулевой. Такая ситуация называется коллапсом сети. Отчасти это может быть связано с недостатком памяти для входных буферов, по этой причине некоторое увеличение памяти может помочь. Но следует помнить, что всякое лекарство хорошо в меру. Еще в 1987 году Нагле (Nagle) обнаружил, что если маршрутизатор имеет даже беспредельную память, эффект перегрузки может оказаться еще более тяжелым. Это сопряжено со временем, которые пакеты ожидают обработки. Если время ожидания в очереди превышает длительность таймаута, появятся дубликаты пакетов, что, безусловно, понижает эффективность системы. Причиной перегрузки может быть медленный процессор или недостаточная пропускная способность какого-то участка сети. Простая замена процессора или интерфейса на более быстродействующий компонент не всегда решает проблему - чаще переносит узкое место в другую часть системы. Перегрузка, как правило, включает механизмы, усиливающие ее негативное воздействие. Так переполнение буфера приводит к потере пакетов, которые позднее должны будут переданы повторно (возможно даже несколько раз). Процессор передающей стороны получает дополнительную паразитную загрузку. Все это указывает на то, что контроль перегрузки является крайне важным процессом. Следует делать различие между контролем потока и контролем перегрузки. Под контролем потока подразумевается балансировка потока отправителя и возможности приема и обработки получателя. Этот вид контроля предполагает наличие обратной связи между получателем и отправителем. В этом процессе участвуют, как правило, только два партнера. Перегрузка же более общее явление, относящееся к сети в целом или к какой-то ее части. Например, 10 ЭВМ хотят передать одновременно какие-то файлы другим 10 ЭВМ. Конфликта потоков здесь нет, каждая из ЭВМ способна переработать поступающие данные, но сеть не может пропустить поток, генерируемый 10 сетевыми интерфейсами одновременно. Начинать надо с решения проблемы выявления перегрузок. Перегрузкой следует считать ситуацию, когда нагрузка в течение некоторого оговоренного времени превышает заданную величину. Параметрами, которые позволяют судить о наличии перегрузки могут служить: процент пакетов, отбрасываемых из-за отсутствия свободного буферного пространства; средняя длина очереди; процент пакетов, пересылаемых повторно; среднее время задержки пакета. Когда перегрузка выявлена, нужно передать необходимую информацию из точки, где она обнаружена, туда, где можно что-то сделать для исправления ситуации. Действия по устранению перегрузок. Можно послать уведомление о перегрузке отправителю, загружая дополнительно и без того перегруженный участок сети. Альтернативой этому может быть применение специального поля в пакете, куда маршрутизатор может записать соответствующий код при перегрузке, и послать его соседям. Можно также ввести специальный процессор или маршрутизатор, который рассылает периодически запросы о состоянии элементов сети. При получении оповещения о перегрузки информационный поток может быть послан в обход. Решения по преодолению перегрузки делятся на три категории: 1. Организационные меры - преодоление перегрузки может быть осуществлено понижением нагрузки или добавлением ресурсов приемнику. 2. Варьирование параметров - Положительный результат может быть достигнут изменением механизма подтверждения (например, уменьшением размера окна), вариацией значений таймаутов, вариацией политики повторной передачи пакетов. В некоторых случаях позитивный результат может быть получен изменением схемы буферизации. 3. Аппаратные решения. - Иногда решить проблему может маршрутизатор, например, перераспределяющий трафик по нескольким направлениям. Алгоритмы устранения перегрузок в системах без обратной связи. Алгоритм leaky bucket ("дырявое ведро") Для систем без обратной связи решение проблемы выравнивания скорости передачи данных может быть решено с помощью алгоритма leaky bucket. Суть этого алгоритма заключается в том, что на пути потока устанавливается буфер, выходной поток которого постоянен и согласован с возможностью приемника. Если буфер переполняется, пакеты теряются. Потеря пакетов вещь мало приятная, но это блокирует процессы, которые могут привести к коллапсу сегмента или всей сети. Там, где потеря пакетов нежелательна, можно применить более гибкий алгоритм. Алгоритм Token Bucket ("маркерное ведро") Алгоритм token bucket предполагает наличие в буферном устройстве (или программе) некоторого количества маркеров. При поступлении на вход буфера пакетов маркеры используются для их транспортировки на выход. Дальнейшая передача данных на выход зависит от генерации новых маркеров. Поступающие извне пакеты тем временем накапливаются в буфере. Таким образом, полной гарантии отсутствия потерь мы не имеем и здесь. Но алгоритм token bucket позволяет передавать на выход "плотные" группы пакетов ограниченной численности (по числу маркеров), снижая в некоторых случаях вероятность потери. Если буферное устройство "смонтировано" внутри ЭВМ-отправителя, потерь можно избежать вовсе, блокируя передачу при заполнении буфера. Как в одном так и в другом алгоритме мерой передаваемой информации может быть не пакет, а n-байт (где n некоторое оговоренное заранее число). Методы устранения перегрузок в системах с обратной связью. В системах, где управление трафиком осуществляется с использованием обратной связи, можно достичь большей эффективности. Метод управления разрешением. Одним из механизмов преодоления перегрузок является управление разрешением (admission control). Суть метода заключается в том, что при регистрации перегрузки не формируется более никаких виртуальных соединений до тех пор, пока ситуация не улучшится. Альтернативным вариантом может служить решение, где формирование нового соединения разрешается, но при этом осуществляется маршрутизация так, чтобы обойти узлы, в которых выявлена перегрузка (смотри рис. 1 ).  На рис. 1 (верх) показан пример сети с двумя узлами, характеризующимися перегрузкой (помечены красным цветом). Предположим, что необходимо проложить виртуальный канал из узла А в узел Б. Из графа маршрутов удаляются перегруженные узлы, после чего осуществляется прокладка пути. В нижней части рисунка синим цветом показан новый виртуальный канал. Метод управления потоком с использованием пакетов блокировки Еще более универсальным решением, пригодным для работы с установлением соединения и без, является посылка пакетов блокировки (choke packets). Маршрутизатор обычно контролирует загруженность всех своих внешних каналов l, которая может принимать значения от 0 до 1. Когда l достигает некоторого порогового значения, отправителю посылается пакет блокировки. Параметром, который контролируется и определяет условие отправки пакета блокировки, может служить длина очереди или заполненность буфера. При вычислении этого параметра следует использовать какую-либо методику усреднения, чтобы избежать слишком частых блокировок. Когда отправитель получает пакет блокировки, он должен уменьшить трафик, посылаемый получателю на заданное число процентов. Так как на пути к месту назначения может быть много пакетов, это вызовет серию пакетов блокировки. Отправитель должен игнорировать пакеты блокировки в течение некоторого времени после получения первого такого пакета. По истечении этого периода отправитель прослушивает канал на протяжении аналогичного времени, ожидая получения новых пакетов блокировки. Если такой пакет приходит, канал все еще перегружен и отправитель снова должен понизить темп посылки пакетов. Если на протяжении периода прослушивания не приходит новых пакетов блокировки, отправитель может увеличить поток снова. ЭВМ может понижать трафик, корректируя свои параметры, например, ширину окна или темп передачи на выходе устройства типа "дырявое ведро". Обычно первый блокирующий пакет уменьшает поток вдвое, следующий на 0,25 от первичного и т.д. Увеличение потока также производится аналогичными шагами. Существует большое число вариантов алгоритма управления потоком с использованием пакетов блокировки. |
Похожие:
 |
Рабочая программа дисциплины (модуля) «Информационные технологии в управлении проектом» «Информационные технологии и ресурсы в менеджменте»; «Методы и модели в принятии управленческих решений»; «Управление финансами»;... |
|
Организационно-правовое обеспечение образовательной деятельности Материально-техническая база, библиотечно-информационные ресурсы, информационно-техничексие ресурсы |
|
Комплекс тестовых заданий для учащихся 7 класса по теме «информация.... ... |
|
Информационные ресурсы сети Интернет для организации образовательного... Нму «Национальный институт образования» Министерства образования Республики Беларусь |
|
Информационные Интернет-ресурсы образовательного назначения |
|
Трудовые ресурсы как социально-экономическая категория и объект управления Без людей нет организации. Без нужных людей ни одна организация не сможет достичь своих целей и выжить. Несомненно, что трудовые... |
|
Конспект лекций по курсу сд. Ф корпоративные информационные системы Лекция № Понятие о сетях. Корпоративные информационные системы. Структура и назначение кис. Характеристика. Требования к организации... |
 |
Учебно-методический комплекс дисциплины дс. Ф. 2 Интернет технологии... Целью преподавания дисциплины является ознакомление студентов с понятием информационные ресурсы, общей характеристикой процессов... |
|
Лекция I и проблема языка и сознания лекция II 31 слово и его семантическое... Монография представляет собой изложение курса лекций, про* читанных автором на факультете психологии Московского государственного... |
|
Лекция I и проблема языка и сознания лекция II 31 слово и его семантическое... Монография представляет собой изложение курса лекций, про* читанных автором на факультете психологии Московского государственного... |
|
Рабочая программа дисциплины в10 Интернет технологии и ресурсы образовательной... Целью освоения дисциплины является: ознакомление студентов с понятием информационные ресурсы, общей характеристикой процессов сбора,... |
|
Перечень вопросов к зачету Информационные ресурсы. Уровни информационных ресурсов в управлении экономическими процессами |
|
Трудовые ресурсы как социально-экономическая категория и объект управления Заказать написание новой работы по этой теме нажмите, удерживая нажатой клавишу Ctrl |
|
Информационные ресурсы Безопасность работы с микроорганизмами III-IV групп патогенности (опасности)и возбудителями паразитарных болезней сп 2322-08 |
|
Конспект лекций по дисциплине для специальности 080101. 65 «Экономическая безопасность» Информационные системы в экономике: конспект лекций по дисциплине для обучающихся по специальности 080101. 65 «Экономическая безопасность»... |
|
Лекция Предмет, задачи и методы перевода Лекция Общая характеристика современной теории перевода. Лекция Переводческая эквивалентность |