Лекция 1

Распределенная обработка данныхПри размещении БД на персональном компьютере, который не

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

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

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

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

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

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

работы. Часть терминов нам уже известна, но повторим здесь их дополнительно.

ТерминологияПользователь БД — программа или человек, обращающийся к БД на

ЯМД.Запрос — процесс обращения пользователя к БД с целью ввода,

получения или изменения информации в БД.Транзакция — последовательность операций модификации данных в

БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние.

Логическая структура БД — определение БД на физически независимом уровне, ближе всего соответствует концептуальной модели БД.

Топология БД – Структура распределенной БД — схема распределения физической БД по сети.

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

Удаленный запрос — запрос, который выполняется с использованием модемной связи.

Возможность реализации удаленной транзакции — обработка одной транзакции, состоящей из множества SQL-запросов на одном удаленном узле.

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

Распределенный запрос — запрос, при обработке которого используются данные из БД, расположенные в разных узлах сети.

Системы распределенной обработки данных в основном связаны с первым поколением БД, которые строились на мультипрограммных операционных системах и использовали централизованное хранение БД на устройствах внешней памяти центральной ЭВМ и терминальный многопользовательский режим доступа к ней. При этом пользовательские терминалы не имели собственных ресурсов — то есть процессоров и памяти, которые могли бы использоваться для хранения и обработки данных. Первой полностью реляционной системой, работающей в многопользовательском режиме, была СУБД SYSTEM R, разработанная фирмой IBM, именно в ней были реализованы как язык манипулирования данными SQL, так и основные принципы синхронизации, применяемые при распределенной обработке данных, которые до сих пор являются базисными практически во всех коммерческих СУБД.

Общая тенденция движения от отдельных mainframe-систем к открытым распределенным системам, объединяющим компьютеры среднего класса, получила название DownSizing. Этот процесс оказал огромное влияние на развитие архитектур СУБД и поставил перед их разработчиками ряд сложных задач. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД, использовавшей собственные модели, форматы представления данных и языки доступа к данным и т. д., к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в глобальную сеть компьютеров различных моделей и производителей.

В то же время происходил встречный процесс — UpSizing. Бурное развитие персональных компьютеров, появление локальных сетей также оказали серьезное влияние на эволюцию СУБД. Высокие темпы роста производительности и функциональных возможностей PC привлекли внимание разработчиков профессиональных СУБД, что привело к их активному распространению на платформе настольных систем.

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

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

Модели «клиент—сервер» в технологии баз данных

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

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

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

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

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

функции ввода и отображения данных (Presentation Logic); прикладные функции, определяющие основные алгоритмы

решения задач приложения (Business Logic); функции обработки данных внутри приложения (Database Logic), функции управления информационными ресурсами (Database

Manager System); служебные функции, играющие роль связок между функциями

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

приведена на рис. 2.

Рис.2. Структура типового интерактивного приложения, работающего с базой данных

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

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

приложений предоставляет знако-ориентированный пользовательский интерфейс, задаваемый моделями CICS (Customer Control Information System ) и IMS/DC фирмы IBM и моделью TSO (Time Sharing Option) для централизованной main-фреймовой архитектуры. Модель GUI — графического пользовательского интерфейса, поддерживается в операционных средах Microsoft's Windows, Windows NT, в OS/2 Presentation Manager, X-Windows и OSF/Motif.

Бизнес-логика, или логика собственно приложений (Business processing Logic), — это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, C++, Cobol, SmallTalk, Visual-Basic.

Логика обработки данных (Data manipulation Logic) — это часть кода приложения, которая связана с обработкой данных внутри приложения. Данными управляет собственно СУБД (DBMS). Для обеспечения доступа к

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

Обычно операторы языка SQL встраиваются в языки 3-го или 4-го поколения (3GL, 4GL), которые используются для написания кода приложения.

Процессор управления данными (Database Manager System Processing) — это собственно СУБД, которая обеспечивает хранение и управление базами данных. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения.

В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.

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

распределенная презентация (Distribution presentation, DP); удаленная презентация (Remote Presentation, RP); распределенная бизнес-логика (Remote business logic, RBL); распределенное управление данными (Distributed data

management, DDM); удаленное управление данными (Remote data management, RDA).

Рис. 3. Распределение функций приложения в моделях «клиент—сервер»

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

Двухуровневые моделиДвухуровневая модель фактически является результатом

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

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

файлового сервера (File Server, FS). В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиенте. Распределение функций в этой модели представлено на рис. 4.

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

Рис. 4. Модель файлового сервераДостоинства этой модели в том, что мы уже имеем разделение

монопольного приложения на два взаимодействующих процесса. При этом

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

Каков алгоритм выполнения запроса клиента?Запрос клиента формулируется в командах ЯМД. СУБД переводит этот

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

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

Недостатки: высокий сетевой трафик, который связан с передачей по сети

множества блоков и файлов, необходимых приложению; узкий спектр операций манипулирования с данными, который

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

(защита только на уровне файловой системы).Модель удаленного доступа к даннымВ модели удаленного доступа (Remote Data Access, RDA) база данных

хранится на сервере. На сервере же находится ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 5.

Рис. 5. Модель удаленного доступа (RDA)Преимущества данной модели; перенос компонента представления и прикладного компонента на

клиентский компьютер существенно разгрузил сервер БД, сводя к минимуму общее число процессов в операционной системе;

сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями

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

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

Основное достоинство RDA-модели — унификация интерфейса «клиент-сервер», стандартом при общении приложения-клиента и сервера становится язык SQL.

Недостатки: все-таки запросы на языке SQL при интенсивной работе

клиентских приложений могут существенно загрузить сеть; так как в этой модели на клиенте располагается и

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

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

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

должны быть соблюдены следующие условия:1. Необходимо, чтобы БД в каждый момент отражала текущее

состояние предметной области, которое определяется не только собственно данными, но и связями между объектами данных. То есть данные, которые хранятся в БД, в каждый момент времени должны быть непротиворечивыми.

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

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

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

5. Одной из важнейших проблем СУБД является контроль типов данных. В настоящий момент СУБД контролирует синтаксически только стандартно-допустимые типы данных, то есть такие, которые определены в DDL (data definition language) — языке описания данных, который является частью SQL. Однако в реальных предметных областях у нас действуют данные, которые несут в себе еще и семантическую составляющую, например, это координаты объектов или единицы различных метрик, например рабочая неделя в отличие от реальной имеет сразу после пятницы понедельник.

Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных, который иногда называется механизмом поддержки доменной структуры. Модель сервера баз данных представлена на рис. 6.

Рис. 6. Модель активного сервера БДВ этой модели бизнес-логика разделена между клиентом и сервером.

На сервере бизнес-логика реализована в виде хранимых процедур —

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

Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД.

Термин «триггер» взят из электроники и семантически очень точно характеризует механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер. Каждый триггер представляет собой также некоторую программу, которая выполняется над базой данных. Триггеры могут вызывать хранимые процедуры.

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

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

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

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

осуществляет мониторинг событий, связанных с описанными триггерами;

обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;

обеспечивает исполнение внутренней программы каждого триггера;

запускает хранимые процедуры по запросам пользователей;

запускает хранимые процедуры из триггеров; возвращает требуемые данные клиенту; обеспечивает все функции СУБД: доступ к данным, контроль и

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

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

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

вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 7. Этот промежуточный уровень содержит один или несколько серверов приложений.

Рис. 7. Модель сервера приложенийВ этой модели компоненты приложения делятся между тремя

исполнителями: Клиент обеспечивает логику представления, включая

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

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

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

Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application).

Отметим, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений. (On-line analytical processing.) В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как С, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость.

Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки ХА-протокола (X/Open transaction interface protocol), который поддерживается большинством поставщиков СУБД.

Лекция 2Модели серверов баз данныхВ период создания первых СУБД технология «клиент-сервер» только

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

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

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

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

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

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

Рис. 8. Взаимодействие пользовательских и клиентских процессов в модели «один-к-одному»

Проблемы, возникающие в модели «один-к-одному», решаются в архитектуре «систем с выделенным сервером», который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис. 9). Логически каждый клиент связан с сервером отдельной нитью («thread»), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной («multi-threaded»).

Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей («trashing»).

Рис. 9. Многопотоковая односерверная архитектураКроме того, возможность взаимодействия с одним сервером многих

клиентов позволяет в полной мере использовать разделяемые объекты (начиная с открытых файлов и кончая данными из системных каталогов), что значительно уменьшает потребности в памяти и общее число процессов операционной системы. Например, системой с архитектурой «один-к-одному» будет создано 100 копий процессов СУБД для 100 пользователей, тогда как системе с многопотоковой архитектурой для этого понадобится только один серверный процесс.

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

В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера («virtual server») (рис. 10).

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

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

Рис. 10. Архитектура с виртуальным серверомПодобная организация взаимодействия клиент-сервер может

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

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

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

Рис. 11. Многопотоковая мультисерверная архитектураСуществует несколько возможностей распараллеливания выполнения

запроса. В этом случае пользовательский запрос разбивается на ряд подзапросов, которые могут выполняться параллельно, а результаты их выполнения потом объединяются в общий результат выполнения запроса. Тогда для обеспечения оперативности выполнения запросов их подзапросы могут быть направлены отдельным серверным процессам, а потом полученные результаты объединены в общий результат (см. рис 12). В данном случае серверные процессы не являются независимыми процессами, такими, как рассматривались ранее. Эти серверные процессы принято называть нитями (treads), и управление нитями множества запросов пользователей требует дополнительных расходов от СУБД, однако при оперативной обработке информации в хранилищах данных такой подход наиболее перспективен.

Рис. 12. Многонитевая мультисерверная архитектура

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

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

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

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

Действительно, если мы рассмотрим, например, последовательность операций реляционной алгебры:

R5=R1 [ А,С]R6=R2 [A.B.D]R7 = R5[A > 128] R8 =R5[A]R6то операции первую и третью можно объединить и выполнить

параллельно с операцией два, а затем выполнить над результатами последнюю четвертую операцию.

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

И третий вид параллелизма является гибридом двух ранее рассмотренных (см. рис. 14).

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

Рис. .13. Выполнение запроса при вертикальном параллелизме

Рис. 14. Выполнение запроса при гибридном параллелизме

Распределенная обработка данныхПод распределенной обработкой данных понимается такой способ

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

Распределенная база данных (РБД) является виртуальным объектом, части которого расположены на удаленных базах данных, связанных каналами связи.

Физически РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

• Каждый узел обладает своими собственными системами баз данных;

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

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

В основе распределённых баз данных лежат следующие требования:1. Локальная автономия;2. Независимость от центрального узла;3. Непрерывное функционирование;4. Независимость от расположения;5. Независимость от фрагментации;6. Независимость от репликации;7. Обработка распределённых запросов;8. Управление распределёнными транзакциями;9. Независимость от аппаратного обеспечения;10. Независимость от операционной системы;11. Независимость от сети;12. Независимость от СУБД.

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

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

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

рассматриваться как равные. Следовательно, не должно существовать никакой зависимости и от центрального «основного» узла с некоторым централизованным обслуживанием, например централизованной обработкой запросов, централизованным управлением транзакциями или

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

Непрерывное функционированиеОдним из преимуществ распределенных систем является то, что они

обеспечивают более высокую надежность и доступность.• Надежность(вероятность того, что система выполняет свойственные

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

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

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

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

Независимость от фрагментацииВ системе поддерживается фрагментация данных, если некоторое

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

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

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

Независимость от репликацииВ системе поддерживается независимость от репликации, если

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

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

Обработка распределенных запросов

При обработке в распределенной системе запроса необходимо выработать эффективную стратегию его реализации. Например, запрос на объединение отношений Rx, расположенного на узле X, и отношения Ry, хранимого на узле Y, может быть выполнен с помощью перемещения отношения Rx на узел Y, перемещения отношения Ry на узел X или перемещения этих двух отношений на третий узел Zи т.д. Это означает, что при выполнении запроса на распределенной БД необходим его предварительный анализ с последующим выбором оптимальной стратегии его реализации.

Управление распределенными транзакциямиВ распределенной системе выполнение транзакции связано с

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

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

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

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

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

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

та же СУБД могла работать под управлением разных ОС.

Независимость от сетиЕсли система в состоянии поддерживать несколько узлов с разным

аппаратным обеспечением и разными операционными системами, то желательно, чтобы в ней поддерживались разные типы сетей.

Независимость от СУБДЭта цель означает, что желательно, чтобы распределенная БД

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

Лекция 3КЛАССИФИКАЦИЯ РАСПРЕДЕЛЕННЫХ СИСТЕМ.Централизация и децентрализация.Новые возможности, предоставляемые распределенной обработкой

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

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

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

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

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

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

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

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

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

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

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

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

локально в точке их происхождения. При низкой скорости обновления или при автономном обновлении (on-

line) допустимо хранение нескольких копий одних и тех же данных в разных местах.

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

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

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

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

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

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

Далее – системы с расщепленными данными. Здесь несколько систем с идентичными структурами данных. Система

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

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

Рассмотрим систему с реплицированными данными. Идентичные копии данных хранятся в разных местах, потому что

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

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

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

Многие конфигурации содержат комбинированные формы.

Классификация распределенных систем по типу распределения процессоров (аспект обработки).

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

Прежде всего определим горизонтальное и вертикальное распределение.

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

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

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

Распределение по функциям В некоторых системах распределение производится по функциям, а не

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

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

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

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

Распределение по системам В случае распределения по системам машины нижнего уровня сами по

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

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

Комбинированные системыСтрогого разграничения между распределением по функциям и

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

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

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

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

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

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

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

Горизонтальное распределениеДо сих пор мы рассматривали системы с вертикальным

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

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

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

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

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

Где находятся требуемые для выполнения работы устройства? Независимы ли эти устройства или работа одних из них зависит от результатов работы других? Какие хранимые данные необходимы для работы устройств? Используют ли они общие или независимые данные? Какие транзакции должны передаваться от одного устройства другому? Какова схема потока транзакций? Должны ли транзакции передаваться от устройства к устройству сразу или допустима задержка? Какова стоимость задержки?

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

Многоуровневые архитектуры клиент-сервер Для решения перечисленных проблем используются многоуровневые

(три и более уровней) архитектуры клиент-сервер.Такие архитектуры более разумно распределяют модули обработки

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

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

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

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

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

Многоуровневые клиент-серверные системы достаточно легко можно перевести на Web-технологию - для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. Для разработки этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java.

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

Лекция 4МЕТОДЫ РАБОТЫ В УСЛОВИЯХ ПЕРЕГРУЗКИПричины перегрузок в сети.Оптимальность управления сетью в условиях перегрузок определяет

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

Отчасти это может быть связано с недостатком памяти для входных буферов, по этой причине некоторое увеличение памяти может помочь. Но следует помнить, что всякое лекарство хорошо в меру. Еще в 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 от первичного и т.д. Увеличение потока также производится

аналогичными шагами. Существует большое число вариантов алгоритма управления потоком с использованием пакетов блокировки.

Метод «честной очереди».Ситуация перегрузки не всегда управляется однозначно. Например, при

поступлении на вход пакетов от трех источников возможна ситуация, когда приемник посылает блокирующие пакеты всем отправителям, а откликнется сокращением потока только один. В результате этот узел, который "играет по правилам" (как это часто бывает и в жизни) оказывается в проигрыше. В 1987 году Нагле был предложен алгоритм fair queueing (честная очередь). В этом алгоритме маршрутизатор организует независимые очереди для пакетов, поступающих от разных источников. Когда выходной канал маршрутизатора оказывается свободным, он просматривает очереди циклически и отравляет очередной пакет. В результате при n очередях по завершении такого цикла просмотров-посылок оказываются посланы по одному пакету из каждой очереди. Такой алгоритм используется в некоторых ATM-переключателях. Следует заметить, что этот алгоритм дает некоторые преимущества тем узлам, которые посылают более длинные пакеты. Демерс (Demers) и др. в 1990 году предложил некоторое усовершенствоввание алгоритма. В данном варианте организуется циклический просмотр очередей не по-пакетно, а по-байтно. Система последовательно сканирует очереди и определяет положение концов пакетов. Первыми отправляются более короткие пакеты. Для иллюстрации предлагается рассмотреть рис. 2.

Рис. 2. Маршрутизатор с 4-мя входными каналами, в каждом из которых ждет очереди передачи по одному пакету. В правой части рисунка представлен порядок посылки этих пакетов.

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

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

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

Метод «скользящее окно»В протоколе ТСР используется алгоритм управления трафиком,

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

Метод отбрасывания пакетовЕсли другие способы испробованы, а перегрузка не исчезла,

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

Если одна ячейка такого сообщения выброшена, все сообщение будет повторно переслано.

Лекция 5ПРОГРАММНЫЕ СРЕДСТВА ЛВС. СЕТЕВЫЕ ОС.Многослойная модель сети

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

компьютеры (нижний слой); коммуникационное оборудование; операционные системы; сетевые приложения (верхний слой). В основе любой сети лежит аппаратный слой стандартизированных

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

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

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

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

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

Структура сетевой операционной системы

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

распознать данные; разбить данные на управляемые блоки; добавить служебную информацию к каждому блоку, чтобы указать

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

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

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

К сетевому программному обеспечению относятся также драйверы сетевых плат, различные для разных типов ЛВС (Ethernet, TR, AppleTalk и др.). Но и внутри одного типа ЛВС имеется много плат с разными характеристиками интеллектуальности, скорости, объема буферной памяти. Так, например, ЛВС Ethernet работает с большинством популярных сетевых операционных систем.

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

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

В сетевой операционной системе отдельной машины можно выделить несколько частей:

Сетевое программное обеспечение ДрайверПлата сетевого адаптера.

Структура сетевой ОС.

Средства управления локальными ресурсами компьютера выполняют функции:

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

пользование - серверная часть ОС. Эти средства обеспечивают: блокировку файлов и записей, что необходимо для их

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

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

своим периферийным устройствам. Средства запроса доступа к удаленным ресурсам и услугам -

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

Коммуникационные средства ОС, с помощью которых происходит обмен сообщениями в сети. Эта часть обеспечивает:

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

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

Взаимодействие компонентов операционной системы при взаимодействии компьютеров

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

компьютерами сети, они могут выступать в трех разных ролях:

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

Компьютер, обращающийся с запросами к ресурсам другой машины, играет роль узла-клиента.

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

Рис.3

Одноранговые сетевые ОС и ОС с выделенными серверамиОчевидно, что сеть не может состоять только из клиентских или

только из серверных узлов. Сеть может быть построена по одной из трех схем: сеть на основе одноранговых узлов — одноранговая сеть; сеть на основе клиентов и серверов — сеть с выделенными

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

Каждая из этих схем имеет свои достоинства и недостатки, определяющие их области применения.

(а) Одноранговая сеть

(б) Сеть с выделенными серверамиРис.4

Одноранговые сети.В одноранговых сетях все компьютеры равны в правах доступа к

ресурсам друг друга. Каждый пользователь может по своему желанию объявить какой-либо ресурс своего компьютера разделяемым, после чего другие пользователи могут его эксплуатировать. В таких сетях на всех компьютерах устанавливается одна и та же ОС, которая предоставляет всем компьютерам в сети потенциально равные возможности. Одноранговые сети могут быть построены, например, на базе ОС LANtastic, Personal Ware, Windows for Workgroup, Windows NT Workstation.

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

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

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

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

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

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

Сети с выделенными серверами.В больших сетях средства централизованного администрирования,

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

В сетях с выделенными серверами используются специальные варианты сетевых ОС, которые оптимизированы для работы в роли серверов и называются серверными ОС. Пользовательские компьютеры в таких сетях работают под управлением клиентских ОС.

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

Выделенный сервер не принято использовать в качестве компьютера для выполнения текущих задач, не связанных с его основным назначением, так как это может уменьшить производительность его работы как сервера. В связи с такими соображениями в ОС Novell NetWare на серверной части возможность выполнения обычных прикладных программ вообще не предусмотрена, то есть сервер не содержит клиентской части, а на рабочих станциях отсутствуют серверные компоненты. Однако в других сетевых ОС функционирование на выделенном сервере клиентской части вполне возможно. Например, под управлением Windows NT Server могут запускаться обычные программы локального пользователя, которые могут потребовать выполнения клиентских функций ОС при появлении запросов к ресурсам других компьютеров сети. При этом рабочие станции, на которых установлена ОС Windows NT Workstation, могут выполнять функции невыделенного сервера.

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

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

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

Гибридная сетьВ больших сетях наряду с отношениями клиент-сервер сохраняется

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

Рис.5 Гибридная сеть.

Функции сетевых операционных систем.

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

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

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

Управление ресурсами включает запросы и предоставление ресурсов. Операционная система управляет выделением и использованием

аппаратных ресурсов: памяти; процессорного времени; дискового пространства; периферийных устройств.Большинство сетевых операционных систем не только предоставляет

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

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

координацию доступа к ресурсам, - чтобы исключить ситуацию, когда два компьютера одновременно пытаются получить доступ к ресурсу;

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

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

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

эти привилегии; удалить определенных пользователей из списка пользователей,

поддерживаемого сетевой операционной системой.Сетевые операционные системы содержат инструментальные средства

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

Коммуникационные функции обеспечивают адресацию, буферизацию, маршрутизацию.

Защита от несанкционированного доступа возможна на любом из следующих уровней:

ограничение доступа в определенное время, и (или) для определенных станций, и (или) определенное число раз;

ограничение совокупности доступных конкретному пользователю каталогов;

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

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

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

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

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

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

приоритеты сообщений; автоматизированная выдача ответов посредством электронной почты,

звуковой сигнализации и т.д.; контроль нарушений системы защиты.

Выбор сетевой ОС.

Результаты опроса: пять основных критериев выбора сетевой ОС

Рис.6 Результаты опроса: пять главных статей расходов, связанных с приобретением сетевой ОС

Лекция 6УПРАВЛЕНИЕ ВЫЧИСЛИТЕЛЬНОЙ СЕТЬЮ. Администрирование сети.Функционирование сети начинается с приемных испытаний и

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

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

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

Управляемость Управляемость сети подразумевает возможность централизованно

контролировать состояние основных элементов сети, выявлять и разрешать

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

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

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

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

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

Таблица 1

Функции сетевого администратора

Задачи

Управление конфигурацией

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

Регистрация, сбор и хранение, обновление и выдача информации;

обработка информации ведение сетевого журнала;генерация отчетов

Контроль характеристик статистическая обработка информации о характеристиках сети;регулирование статистических параметров

Управление в проблемных ситуациях

диагностика и локализация ошибок;тестирование;восстановление работоспособности сети

Управление планированием

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

Поддержка пользователейопределение групп пользователейопределение прав доступаобучение пользователей

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

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

Таблица 2Факторы отклонений

Причины возникновения ПС

Действия по ликвидации последствий ПС

Способы предупреждения ПС

Программно-аппаратный комплекс

1. отказы, сбои,внешние помехи2. несовмести-мость компо-нентов комплекса3. заражение компьютерными вирусами

1. восстановлениекомпонентов комплекса2. подбор совместимых компонентов комплекса

3. удаление вирусов, восстановление

1.надежности, техническое сопровождение2.компонентов посредством интерфейсов3.своевременная антивирусная защита

информацииЧеловечес-кий фактор

1. нарушение регламента работ2. ошибки от неумения, невнимания3. несанкциониро-ванный доступ

1. восстановление регламента работ2. восстановление информации3. восстановление прежнего состояния

1. управления сетью2. интеллектуальное информационное сопровождение, обучение3. контроль доступа к информации

Таблица 3Причины возникновения проблемных ситуаций

Количество случаев

Ошибки пользователей 25%Нарушения регламента работы 25%Сбои ПО 15%Отказы и сбои АО 15%Несовместимость 10%Внешние помехи 5%Вирусы 5%

Управление программно-аппаратным комплексом сети.Масштаб задач по управлению сетью зависит: от размера сети; численности и профессионализма сотрудников, которые обеспечивают

поддержку сети; средств, выделяемых на поддержку сети; ожидаемой отдачи от использования сети.Контроль сети нужен для: увеличения производительности сети в существующей конфигурации; планирования и прогноза развития сети; выявления узких мест в сети.Узкое место - "тормозящее" устройство, использующее заметно

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

Большинство СОС имеют утилиты мониторинга, которые помогают администратору контролировать различные аспекты функционирования сервера. Сети Novell - LANAlizer, Windows NT Server - Performance Monitor. Они позволяют администратору сети наблюдать в реальном времени и в записи:

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

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

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

Диагностика ВСПод термином "диагностика локальной сети" понимается процесс

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

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

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

Основных причин неудовлетворительной работы прикладного ПО в сети может быть несколько:

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

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

Комплексная диагностика предполагает выполнение следующих работ (этапов).

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

Измерение текущей загруженности сервера и определение влияния степени его загрузки на время реакции прикладного ПО.

Измерение текущей загруженности канала связи сети, и определение влияния загрузки канала связи на время реакции прикладного ПО.

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

Измерение числа ошибок передачи данных на уровне канала связи и выяснение причин их возникновения.

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

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

Выявление дефектов архитектуры сети. Наиболее надежным способом локализации дефектов архитектуры

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

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

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

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

подключается активное оборудование: сетевые платы, концентраторы, коммутаторы.

Любая методика тестирования сети существенно зависит от имеющихся в распоряжении системного администратора средств.

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

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

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

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

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

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

Моделирование трафика локальной сети. Когда сеть масштаба предприятия становится настолько сложной, что один человек уже не в состоянии предугадать, кaк повлияют нa нее отдельные изменения, aдминистрaторы сети обрaщaются к системaм моделировaния локaльной вычислительной сети. Тaкие прогрaммные продукты, кaк Bones PlanNet фирмы Comdisco Systems и L-Net фирмы CACI Products позволяют им лучше проследить прохождение сетевого трaфикa и достaточно точно оценить влияние новых приложений и пользовaтелей.

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

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

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

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

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

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

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

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

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

Сбор данных. Как правило, средства моделирования сети вычисляют ее производительность на основе показателей ее фактического и оцениваемого трафика, указываемых администратором сети. Многие программы моделирования воспринимают данные и от инструментальных средств анализа сети, таких как анализатор протокола Sniffer фирмы Network General. Для крупномасштабных моделей такая возможность имеет важное значение: без нее пришлось бы подсчитывать передаваемые пакеты и вводить множество данных. Установив программные агенты, позволяющие получить картину полного сетевого трафика, вы можете использовать и данные, получаемые с помощью продуктов административного управления сетью, таких как SunNet Manager фирмы Sun Microsystems и Open View фирмы Hewlett Packard.

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

Средства моделирования обычно включают в себя модули обработки, эмулирующие сетевые устройства, такие как мосты и концентраторы, так что моделируемый трафик будет подвергаться той же обработке, что и реальный. Например, в пакете моделирования PlanNet фирмы Comdisco вы найдете возможность эмуляции всего оборудования - от сети Token Ring и сегментов Ethernet до средств передачи речевых данных и телекоммуникационных линий T-3. После того как модель сети построена и работает, вы можете поэкспериментировать, добавляя в нее протоколы, пользователей или сетевые сегменты. Вы можете разбить сеть на дополнительные сегменты, применив в них, например, линию связи T-1, и посмотреть, что произойдет. Средство моделирования покажет вам коэффициент использования сети в процентах от ее пропускной способности, уровни трафика и ошибок, время реакции. Даже при помощи такого измерительного инструмента, как Sniffer, моделирование позволяет получить лишь ту точность, которую дают базовые данные. Если при измерении трафика вы не охватили адекватный диапазон сетевой активности или ваши оценки роста объема трафика, генерируемого новым приложением, неверны, то вы не получите реалистичного описания производительности. Вам необходимы не только точные данные, но и определенная подготовка и понимание того, что означает программа

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

Все это требует времени. Построение точной модели сложной сети может занять месяц или более. Следует принимать во внимание также значительную стоимость подобных пакетов (порядка 10000 долл.).

Управление пользователями.Управление пользователями заключается в решении следующих задач: добавление/удаление новых пользователей; объединение пользователей в группы; предоставление/снятие привилегий группам и отдельным

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

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

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

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

доступные программы).При установке СОС автоматически создается учетная запись

пользователя, обладающего полной "властью" в сети (в среде Novell - Supervisor, в Microsoft - Administrator), и учетная запись гостя (guest).

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

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

СОС может определять стандартные (встроенные) группы пользователей.

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

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

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

Таблица 4Название группы

Внутренние ресурсы

Уровни доступак внутренним ресурсам

Доступ в Internet и электронная почта

Администратор

Все сетевые ресурсы

Права администратора в каталогах, в том числе изменение уровня и прав доступа

Все сетевые ресурсы

Разработчики

Базы данных разрабатываемых документов

Создание, чтение файлов, запись в файл, создание подкаталогов и файлов, удаление каталогов, поиск файлов, изменение каталогов

Все сетевые ресурсы

Сотрудники в офисе

Вся информация предприятия (учреждения)

Ограничение доступа к папкам (по необходимости)

Ограничение по IP- адресу (адресата и источника),ограничение по содер-жанию корреспон-денции

Сотрудники вне офиса

Вся информация предприятия

Ограничение доступа к папкам (по необходимости)

Ограничение по IP- адресу (адресата и

(учреждения) источника),ограничение по содер-жанию корреспон-денции,аутентификация удаленного пользова-теля перед осуществ-лением доступа

Поставщики, деловые партнеры, клиенты

Специальные каталоги и папки для производи-телей, партнеров и клиентов

Доступ только к специально отведенным областям

Ограничение по IP- адресу (адресата и источника).Идентификация и аутентификация удаленного пользователя

Потенциальные клиенты

Специальные каталоги и папки для клиентов

Просмотр объектов (чтение и поиск файлов)

При открытом доступе Интрасеть должна быть изолирована; идентификация пользователя не требуется

Обучение пользователей.Обучение пользователей и обслуживающего персонала должно свести

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

серверы должны быть модифицированы в соответствии с новым стандартом. Наличие серверов с различными стандартами вызовет путаницу среди пользователей и персонала и сведет на нет преимущества стандартизации.

Рекомендации по проектированию корпоративных сетей. Основные сетевые протоколы и технологии реализованы в

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

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

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

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

3. При выборе типа линий связи между отдельно стоящими зданиями необходимо провести сравнительный анализ проводных линий и радиоканалов.

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

5. Относительно выбора одного из двух наиболее популярных вариантов построения подсетей (ЛВС) - Ethernet или Token Ring однозначные выводы отсутствуют. Если нагрузка подсети может превышать 35 % (т.е. без

учета конфликтов передача данных в сети занимает 35 % времени), то лучше использовать Token Ring. При меньшей загрузке предпочтительнее Ethernet, так как обеспечиваются меньшие задержки. Вариант Ethernet можно применять и при большем трафике, но тогда нужно предусмотреть разделение ЛВС на подсети с мостовым соединением между ними. Число подсетей и распределение рабочих мест по подсетям рекомендуется определять по правилу 80/20, по которому 80 % трафика должно сосредоточиваться внутри подсети и только 20 % следует отводить во вне, иначе эффективность Ethernet будет невысокой. Следует также рассмотреть целесообразность использования виртуальных ЛВС.

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

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

8. Для корректировки и верификации проекта сети нужно использовать имеющиеся средства имитационного моделирования.

Примерами программ анализа и моделирования вычислительных сетей могут служить COMNET III и OPNET. Ниже приведены краткие характеристики этих программ.

COMNET III; (фирма CACI Products Company; http://www.caciasl.com). Интерактивное моделирование работы локальных и территориальных вычислительных сетей. Исходные данные задаются на проблемно-ориентированных языках моделирования MODSIM или SIMSCRIPT с графическими расширениями. На экране ЭВМ изображается топология сети с указанием узлов, линий связи, источников данных (трафика). В результате моделирования определяются "узкие" места, задержки в передаче данных, загрузка линий, буферов, процессоров, длины очередей, пиковые нагрузки. Имеется библиотека моделей протоколов и аппаратных средств: маршрутизаторов (3COM, Cisco, DEC, HP и др.), алгоритмов протоколов (TCP/IP, SNA, RIP, OSPF, IGRP и др.) и ряда методов доступа (CSMA/CD, FDDI, ALOHA).

OPNET (Planner and Modeler); (фирма OPNET; http://www.mil3.com). Анализ работы различных локальных и территориальных гетерогенных вычислительных сетей, в том числе высокоскоростных сетей FDDI и ATM, радиоканалов с временным мультиплексированием и др. На входном графическом языке задается структура сетей с указанием процессоров, источников потоков данных, очередей, трансмиттеров и т.п. Система

позволяет сравнивать различные архитектуры построения сетей, определять размещение серверов, рассчитывать трафик. В библиотеке системы имеются модели различных протоколов (Ethernet, FDDI, TCP/IP, ATM, PSTN, Frame Relay и др.).

Математическое обеспечение для моделирования сетей и сетевых протоколов - системы массового обслуживания и/или сети Петри. Для структурного синтеза сетей используют дискретное математическое программирование и экспертные системы, перспективно применение генетических алгоритмов синтеза. Существуют пакеты интерактивного проектирования сетей. С их помощью можно изобразить поэтажную схему здания, разместить на ней обозначения компьютеров и сетевого оборудования, выбрать из базы данных типы оборудования и каналов связи, проверить допустимость их совместного использования и другие ограничения. Пример такого пакета - NetSuit Advanced Professional Design фирмы NetSuit Development.

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

Лекция 7Методы передачи информации.Существует множество различных сетевых протоколов, и некоторые из

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

Синхронная передача.Синхронная передача используется при создании стабильной

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

Рисунок 1 Кадры, разделенные на области при синхронной передаче

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

Идея станет еще прозрачней, если мы нарисуем кадры один под другим, создав таким образом «суперкадр» (Рисунок 2). Области, расположенные прямо друг под другом, принадлежат одному соединению.

Рисунок 2 Суперкадр

Синхронная передача используется для связи вашего коммутатора с коммутатором телефонной компании. В этом случае мы используем канал E1 (или T1 в США), состоящий из 32 областей по 64 Кб/с каждый. Область может использоваться для телефонного звонка. Поэтому, в теории, одновременно гарантированы 32 звонка (хотя некоторые области могут использоваться для служебных целей).

Пакетная передача.Пакетная передача крайнее важна для передачи данных. Обычно в

пакетах хранятся данные различного размера.

Рисунок 3 Пакетная передача

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

Асинхронная передача.Асинхронная передача использует протокол ATM. Этот тип передачи

сочетает в себе возможности пакетной и синхронной передачи.

Рисунок 4 Асинхронная передача

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

Виртуальная цепь.Некоторые сетевые протоколы создают в сети виртуальные цепи.

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

Рисунок 5 Виртуальная цепь

На рисунке 5 между узлами A и D создана виртуальная цепь, проходящая через узлы B, F и G. Все пакеты должны проходить по этой цепи.

В иерархии Интернета TCP является протоколом высокого уровня, который устанавливает соединение и гарантирует доставку данных. Он используется поверх протокола IP. Если какие-либо пакеты данных потеряны, требуется их повторная передача. Если пакеты данных были потеряны из-за разрушения узла и в сети есть другой возможный маршрут, передача автоматически повторяется по другому пути.

Виртуальные цепи разделяются на следующие группы:Постоянные (Постоянные Виртуальные Цепи — Permanent Virtual

Circuit (PVC)), т.е. цепи, созданные сетевым администратором на постоянной основе.

Коммутируемые (Коммутируемые Виртуальные Цепи — Switched Virtual Circuit (SVC)), т.е. виртуальные цепи, которые создаются динамически при необходимости. SVC создается с помощью сигнальных протоколов, использующихся для связи пользователя и смой сети. Сеть сигнализирует пользователю о различных событиях, которые могут использоваться для контроля работы сети и ее администрирования. SVC-соединение состоит из двух стадий: создание виртуальной цепи и ее использование в соединение.

PVC соответствует выделенным линиям, а SVC – коммутируемым линиям телефонной сети.

Протоколы, использующие виртуальные цепи, называются Сетевыми услугами с предоставлением физического доступа (Connection—Oriented Network Services — CONS), а протоколы, передающие пакеты без использования виртуальных цепей, называются Сетевыми услугами без

предоставления физического доступа (Connection-Less Network Services — CLNS).

Сетевые протоколы.Сетевым протоколом называется набор правил, позволяющий

осуществлять соединение и обмен данными между двумя и более включёнными в сеть компьютерами.Фактически разные протоколы зачастую описывают лишь разные стороны одного типа связи; взятые вместе, они образуют так называемый стек протоколов. Названия <протокол> и <стек протоколов> также указывают на программное обеспечение, которым реализуется протокол.

Уровни протоколов.Наиболее распространённой системой классификации сетевых

протоколов является так называемая модель OSI. В соответствии с ней протоколы делятся на 7 уровней по своему назначению - от физического (формирование и распознавание электрических или других сигналов) до прикладного (API для передачи информации приложениями):

Прикладной уровень (Application layer). Верхний (7-й) уровень модели, обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя доступ к сетевым службам, таким как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Также отвечает за передачу служебной информации, предоставляет приложениям информацию об ошибках и формирует запросы к уровню представления. Пример: HTTP, POP3, SMTP.

Уровень представления (Presentation layer). 6-й уровень отвечает за преобразование протоколов и кодирование/декодирование данных. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные преобразует в формат, понятный приложениям. На уровне представления может осуществляться сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально.

Сеансовый уровень (Session layer). 5-й уровень модели отвечает за поддержание сеанса связи, что позволяет приложениям взаимодействовать между собой длительное время. Сеансовый уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия.

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

передачи. Блоки данных он разделяет на фрагменты, размер которых зависит от протокола, короткие объединяет в один, а длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка. Пример: TCP, UDP

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

Канальный уровень (Data Link layer). Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Данные, полученные с физического уровня, он упаковывает во фреймы, проверяет на целостность, если нужно исправляет ошибки и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня - MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. На этом уровне работают коммутаторы, мосты. В программировании этот уровень представляет драйвер сетевой платы, в операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровней между собой, это не новый уровень, а просто реализация модели для конкретной ОС. Примеры таких интерфейсов: ODI, NDIS

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

В основном используются протокол TCP/IPОпределение:Transmission Control Protocol/Internet Protocol, TCP/IP (Протокол

управления передачей/Протокол Интернета).Большинство операционных систем сетевых серверов и рабочих

станций поддерживает TCP/IP, в том числе серверы NetWare, все системы Windows, UNIX, последние версии Mac OS, системы OpenMVS и z/OS компании IBM, а также OpenVMS компании DEC. Кроме того, производители сетевого оборудования создают собственное системное программное

обеспечение для TCP/IP, включая средства повышения производительности устройств. Стек TCP/IP изначально применялся на UNIX-системах, а затем быстро распространился на многие другие типы сетей.

Протоколы локальных сетей IPX/SPX; NetBEUI; AppleTalk; TCP/IP; SNA; DLC; DNA;

Свойства протоколов локальной сети.В основном протоколы локальных сетей имеют такие же свойства, как

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

Протоколы локальных сетей должны иметь следующие основные характеристики:

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

IEEE 802.В основном все протоколы, рассматриваемые в этой главе,

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

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

Таблица Протоколы локальных сетей и сетевые операционные системы

Протокол Соответствующая операционная система IPX/SPX Novell NetWare NetBEUI Первые версии операционных систем Microsoft Windows AppleTalk Apple Macintosh TCP/IP UNIX, Novel NetWare, современные версии операционных

систем Microsoft Windows, операционные системы мэйнфреймов IBM

SNA Операционные системы мэйнфреймов и миникомпьютеров IBM

DLC Клиентские системы, взаимодействующие с мэйнфреймами IBM, настроенными на работу с протоколом SNA

Понятие протокола Интернет.Очевидно, что рано или поздно компьютеры, расположенные в разных

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

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

Лекция 8Краткое описание протоколов Интернет

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

Основные протоколы используемые в работе Интернет: TCP/IP POP3 SMTP FTP HTTP IMAP4 WAIS Gorpher WAP TCP/IPВ 1972 году группа разработчиков под руководством Винтона Серфа

разработала протокол TCP/IP - Transmission Control Protocol/Internet Protocol (Протокол управления передачей/Протокол Интернета).

Эксперимент по разработке этого протокола проводился по заказу Министерства обороны США. Данный проект получил название ARPANet (Advanced Research Projects Agency Network - Сеть агентства важных исследовательских проектов). Очевидно, что в обстановке войны, когда необходимость в обмене информацией встает как никогда остро, возникает проблема непредсказуемости состояния пути, по которому будет передана та или иная информация - любой из узлов передачи в любой момент может быть выведен из строя противником. Поэтому главной задачей при разработке сетевого протокола являлась его "неприхотливость" - он должен был работать с любым сетевым окружением и, кроме того, обладать гибкостью в выборе маршрута при доставке информации.

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

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

Схема функционирования протокола TCP/IP

HTTPПротокол HTTP (Hypertext Transfer Protocol - Протокол передачи

гипертекста) является протоколом более высокого уровня по отношению к протоколу TCP/IP - протоколом уровня приложения. HTTP был разработан для эффективной передачи по Интернету Web-страниц. Именно благодаря HTTP мы имеем возможность созерцать страницы Сети во всем великолепии. Протокол HTTP является основой системы World Wide Web.

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

Чтобы текст, составляющий содержимое Web-страниц, отображался на них определенным образом - в соответствии с замыслом создателя страницы - он размечается с помощью особых текстовых меток - тегов языка разметки гипертекста (HyperText Markup Language, HTML).

Адреса ресурсов Интернета, к которым вы обращаетесь по протоколу HTTP, выглядит примерно следующим образом:

http://www.tut.by

FTPПротокол FTP (File Transfer Protocol - Протокол передачи файлов)

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

ftp://ftp.netscape.com

TELNETС помощью этого протокола вы можете подключиться к удаленному

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

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

WAISWAIS расшифровывается как Wide-Area Information Servers. Этот

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

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

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

GopherПротокол Gopher - протокол уровня приложения, разработанный в 1991

году. До повсеместного распространения гипертекстовой системы World Wide Web Gopher использовался для извлечения информации (в основном

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

Gopher переводится как "суслик", что отражает славное университетское прошлое разработчиков этой системы. Студенческие спортивные команды Университета Миннесоты носили название Golden Gophers ("Золотые суслики").

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

WAPWAP (Wireless Application Protocol) был разработан в 1997 году группой

компаний Ericsson, Motorola, Nokia и Phone.com (бывшей Unwired Planet) для того, чтобы предоставить доступ к службам Интернета пользователям беспроводных устройств - таких, как мобильные телефоны, пейджеры, электронные органайзеры и др., использующих различные стандарты связи.

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

Сетевые службы и протоколыСетевые протоколы фактически управляют сетью, указывая сетевым

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

Существует множество типов сетевых протоколов, работающих в разных сетях и на разных уровнях модели OSI. Вот некоторые из них:

TCP/IP NetBEUI IPX/SPX NWLink Apple Talk DLC

Протоколы удаленного доступа

В состав операционных систем Windows входит служба Routing and Remote Access Service (RRAS), которая позволяет удаленным клиентам прозрачно подключаться к удаленному серверу. Служба RRAS поддерживает три протокола удаленного доступа:

Point-to-Point Protocol (PPP) - стандартизованный набор протоколов обеспечивающий:

механизм согласования параметров устройств передачи данных; механизм сжатия передаваемой информации с целью повышения

эффективности и надежности передачи; механизм обнаружения и исправления ошибок; механизмы защиты, предотвращающие несанкционированные

подключения. Serial Line Internet Protocol (SLIP) - простой протокол, не

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

Asynchronous NetBEUI (AsyBEUI) - протокол службы удаленного доступа Microsoft, известный также как асинхронный NetBEUI; применяется устаревшими клиентами удаленного доступа под управлением Windows NT, Windows 3.1, Windows for Workgroups, MSDOS и LAN Manager.

Стек протоколов TCP/IP

Стек TCP/IP - набор протоколов, разработанных для обеспечения взаимосвязи различных устройств в сети Интернет. Стек включает следующие протоколы

Протокол IP (Internet protocol) - основной протокол сетевого уровня. Определяет способ адресации на сетевом уровне. Обеспечивает маршрутизацию в сетях, представляющих собой объединение сетей, базирующихся на разных сетевых технологиях.

Протокол ARP (Address Resolution Protocol) - вспомогательный протокол стека TCP/IP, предназначенный для определения аппаратного адреса узла назначения по заданному IP-адресу.

Протокол ICMP (Internet Control Message Protocol) - вспомогательный протокол стека TCP/IP, предназначенный для обмена информацией об ошибках передачи данных протоколом IP, а также для обмена управляющей информацией на сетевом уровне. В частности, утилита PING использует этот протокол для посылки так называемого "эхо-запроса".

Протокол IGMP (Internet Group Management Protocol) - протокол, используемый для отправки данных определенной группе получателей.

Протокол TCP (Transmission Control Protocol) - протокол, обеспечивающий гарантированную доставку данных с установлением виртуального соединения между программами, которым требуется использовать сетевые услуги. Установление виртуального соединения предполагает, что получатель готов к приему данных от конкретного отправителя. Это означает, что все параметры взаимодействия согласованы, и компьютер-получатель выделил соответствующие ресурсы для обеспечения приема.

Протокол UDP (User Datagram Protocol) - протокол, обеспечивающий негарантированную доставку данных без установления виртуального соединения между программами, которым требуется использовать сетевые услуги.

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

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

Для решения этих проблем разработаны протоколы транспортного уровня TCP и UDP.

Идентификация программ в протоколах TCP и UDP обеспечивается уникальными числовыми значениями, так называемыми номерами портов. Номера портов назначаются программам в соответствии с ее функциональным назначением на основе определенных стандартов. Для каждого протокола существуют стандартные списки соответствия номеров портов и программ. Так, например, программное обеспечение WWW, работающее через транспортный протокол TCP, использует TCP-порт 80, а служба DNS взаимодействует с транспортными протоколами TCP и UDP через TCP-порт 53 и UDP-порт 53 соответственно.

Таким образом, протокол сетевого уровня IP и транспортные протоколы TCP и UDP реализуют двухуровневую схему адресации: номера TCP- и UDP-портов позволяют однозначно идентифицировать программу в рамках узла, однозначно определяемого IP-адресом. Следовательно, комбинация IP-адреса и номера порта позволяет однозначно идентифицировать программу в сети Интернет. Такой комбинированный адрес называется сокетом (socket).

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

Компоненты прикладного уровня HTTP, FTP, SMTP, SNMP, TelnetНа прикладном уровне работает множество стандартных утилит и

служб TCP/IP, к числу которых относятся: протокол НТТР - используется для организации доступа к

общим данным, расположенным на веб-серверах, с целью публикации и

чтения общедоступной информации. Протокол HTTP описывает взаимодействие между HTTP-серверами (веб-серверами) и HTTP-клиентами (веб-браузерами). В состав Windows XP и Windows Server 2003 входит как клиентская часть (веб-браузер Internet Explorer v6.0), так и серверная (веб-сервер Internet Information Server, IIS);

протокол FTP - служба Интернета, обеспечивающая передачу файлов между компьютерами. В Windows XP и Windows Server 2003 поддерживаются клиенты FTP: Internet Explorer v6.0 и утилита командной строки FTP. Сервер FTP входит в состав Web-сервера IIS;

протокол SMTP - применяется почтовыми серверами для передачи электронной почты. Сервер IIS поддерживает работу с протоколом SMTP для обработки почтовых сообщений;

протокол Telnet - протокол эмуляции терминала, применяемый для подключения к удаленным узлам сети. Telnet позволяет клиентам удалено запускать приложения; кроме того, он упрощает удаленное администрирование. Реализации Telnet, доступные практически для всех ОС, облегчают интеграцию в разнородных сетевых средах. В Windows XP и Windows Server 2003 включены клиент и сервер Telnet;

службы имен - набор протоколов и служб позволяющий управлять именованием компьютеров в сети;

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

• Протокол NWLinkЭто Microsoft-совместимый IPX/SPX протокол для Windows.

Необходим для доступа к сетям под управлением серверов с ОС Nоwell NetWare. Сам протокол NWLink реализует сетевой и транспортный уровень взаимодействия.

Для доступа к файлам или принтерам сервера NetWare надо задействовать специальный редиректор, представленный в Windows XP Professional службой CSNW (клиент для сетей NetWare), а в Windows Server 2003 - службой GSNW (шлюз для сетей NetWare). Протокол NWLink включен в состав обеих ОС Windows и устанавливается автоматически вместе с клиентом и службой шлюза для NetWare.

• Протокол Apple Talk Это набор протоколов, разработанный Apple Computer, Inc. для связи

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

• Протокол DLC

Протокол DLC (Data Link Control) был разработан для объединения мэйнфрэймов IBM. Он не проектировался как основной протокол персональных компьютеров в сети. Зачастую его используют для печати на сетевых принтерах Hewlett-Packard.

• Стандарт IrDAАссоциация Infrared Data Association (IrDA) определила группу

двусторонних высокоскоростных беспроводных протоколов для обмена информацией в инфракрасном диапазоне, обычно называемых IrDA. Протоколы IrDA обеспечивают взаимодействие компьютеров со множеством устройств: цифровыми камерами, принтерами, карманными компьютерами типа PocketPC и др. В Windows XP и Windows Server 2003 включена поддержка IrDA.

• Порядок привязки протоколовПротоколы можно добавлять, удалять и выборочно привязывать ко всем

сетевым интерфейсам сервера. По умолчанию порядок привязки протоколов определяется последовательностью, в которой они были установлены. Но при этом администратор всегда может изменить этот порядок для отдельных интерфейсов, что делает процесс управления более гибким. Например, к одному интерфейсу могут быть привязаны протоколы TCP/IP и IPX/SPX с приоритетом протокола TCP/IP, a к другому - те же протоколы, но с приоритетом IPX/SPX. Кроме того, для отдельных сетевых интерфейсов, протоколов и их комбинации можно произвольно включать или отключать сетевые службы. Это позволяет администраторам легко создавать защищенные конфигурации сети (например, отключить все сетевые службы для общедоступных интерфейсов с прямым подключением к Интернету).

Лекция 9Порядок привязки протоколов.Протоколы можно добавлять, удалять и выборочно привязывать ко всем

сетевым интерфейсам сервера. По умолчанию порядок привязки протоколов определяется последовательностью, в которой они были установлены. Но при этом администратор всегда может изменить этот порядок для отдельных интерфейсов, что делает процесс управления более гибким. Например, к одному интерфейсу могут быть привязаны протоколы TCP/IP и IPX/SPX с приоритетом протокола TCP/IP, a к другому - те же протоколы, но с приоритетом IPX/SPX. Кроме того, для отдельных сетевых интерфейсов, протоколов и их комбинации можно произвольно включать или отключать сетевые службы. Это позволяет администраторам легко создавать защищенные конфигурации сети (например, отключить все сетевые службы для общедоступных интерфейсов с прямым подключением к Интернету).

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

Остановимся на особенностях протоколов более высоких уровней, реализуемых программно.

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

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

Рис.1. Функции драйвера сетевого адаптера в модели OSI

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

Прежде чем приобрести плату адаптера, необходимо ознакомиться со списком совместимого оборудования (Hardware Compatibility List, HCL), который публикуют все производители сетевых операционных систем. Выбор там довольно велик (например, для Microsoft Windows Server список включает более сотни драйверов сетевых адаптеров). Если в перечень HCL не входит адаптер какого-то типа, лучше его не покупать.

Протоколы высоких уровнейСуществует несколько стандартных наборов (или, как их еще называют,

стеков) протоколов, получивших сейчас широкое распространение:набор протоколов ISO/OSI; IBM System Network Architecture (SNA); Digital DECnet; Novell NetWare;

Apple AppleTalk; набор протоколов глобальной сети Интернет, TCP/IP.Включение в этот список протоколов глобальной сети вполне

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

Протоколы перечисленных наборов делятся на три основных типа:Прикладные протоколы (выполняющие функции трех верхних уровней

модели OSI – прикладного, представительского и сеансового); Транспортные протоколы (реализующие функции средних уровней

модели OSI – транспортного и сеансового); Сетевые протоколы (осуществляющие функции трех нижних уровней

модели OSI).Прикладные протоколы обеспечивают взаимодействие приложений и

обмен данными между ними. Наиболее популярны:FTAM (File Transfer Access and Management) – протокол OSI доступа к

файлам; X.400 – протокол CCITT для международного обмена электронной

почтой; Х.500 – протокол CCITT служб файлов и каталогов на нескольких

системах; SMTP (Simple Mail Transfer Protocol) – протокол глобальной сети

Интернет для обмена электронной почтой; FTP (File Transfer Protocol) – протокол глобальной сети Интернет для

передачи файлов; SNMP (Simple Network Management Protocol) – протокол для

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

Telnet – протокол глобальной сети Интернет для регистрации на удаленных серверах и обработки данных на них;

Microsoft SMBs (Server Message Blocks, блоки сообщений сервера) и клиентские оболочки или редиректоры фирмы Microsoft;

NCP (Novell NetWare Core Protocol) и клиентские оболочки или редиректоры фирмы Novell.

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

TCP (Transmission Control Protocol) – часть набора протоколов TCP/IP для гарантированной доставки данных, разбитых на последовательность фрагментов;

SPX – часть набора протоколов IPX/SPX (Internetwork Packet Exchange/Sequential Packet Exchange) для гарантированной доставки данных, разбитых на последовательность фрагментов, предложенных компанией Novell;

NWLink – реализация протокола IPX/SPX компании Microsoft;

NetBEUI – (NetBIOS Extended User Interface, расширенный интерфейс NetBIOS) – устанавливает сеансы связи между компьютерами (NetBIOS) и предоставляет верхним уровням транспортные услуги (NetBEUI).

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

IP (Internet Protocol) – TCP/IP-протокол для негарантированной передачи пакетов без установления соединений;

IPX (Internetwork Packet Exchange) – протокол компании NetWare для негарантированной передачи пакетов и маршрутизации пакетов;

NWLink – реализация протокола IPX/SPX компании Microsoft; NetBEUI – транспортный протокол, обеспечивающий услуги

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

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

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

Рис. 2. Соотношение уровней модели OSI и протоколов сети Интернет

Рис. 3. Соотношение уровней модели OSI и протоколов операционной системы Windows Server

Рис. 4. Соотношение уровней модели OSI и протоколов операционной системы NetWare

Теперь следует подробнее рассмотреть некоторые наиболее распространенные протоколы.

Модель OSI допускает два основных метода взаимодействия абонентов в сети:

Метод взаимодействия без логического соединения (или метод дейтаграмм).

Метод взаимодействия с логическим соединением.Метод дейтаграмм – это простейший метод, в котором каждый пакет

рассматривается как самостоятельный объект (рис. 5).Пакет при этом методе передается без установления логического

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

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

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

Метод с логическим соединением (рис. 6) разработан позднее, чем метод дейтаграмм, и отличается усложненным порядком взаимодействия.

Рис. 5. Метод дейтаграмм

Рис. 6. Метод с логическим соединением

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

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

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

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

Примеры протоколов, работающих по методу дейтаграмм— это протоколы IP и IPX.

Примеры протоколов, работающих по методу с логическим соединением – это TCP и SPX.

Именно для того, чтобы объединить достоинства обоих методов, эти протоколы используются в виде связанных наборов: TCP/IP и IPX/SPX, в которых протокол более высокого уровня (TCP, SPX), работающий на базе протокола более низкого уровня (IP, IPX), гарантирует правильную доставку пакетов в требуемом порядке.

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

Если скорость не слишком важна, то прикладные программы применяют еще более высокий уровень, например, протокол NetBIOS, предоставляющий удобный сервис. Компанией Microsoft предложена своя реализация протокола IPX/SPX, называемая NWLink. Протоколы IPX/SPX и NWLink поддерживаются операционными системами NetWare и Windows. Выбор этих протоколов обеспечивает совместимость по сети любых абонентов с данными операционными системами.

Набор (стек) протоколов TCP/IP был специально разработан для глобальных сетей и для межсетевого взаимодействия. Он изначально ориентирован на низкое качество каналов связи, на большую вероятность ошибок и разрывов связей. Этот протокол принят во всемирной компьютерной сети Интернет, значительная часть абонентов которой подключается по коммутируемым линиям (то есть обычным телефонным линиям).

Как и протокол IPX/SPX, протокол TCP/IP также поддерживает маршрутизацию. На его основе работают протоколы высоких уровней, такие как SMTP, FTP, SNMP. Недостаток протокола TCP/IP —более низкая скорость

работы, чем у IPX/SPX. Однако сейчас протокол TCP/IP используется и в локальных сетях, чтобы упростить согласование протоколов локальных и глобальных сетей. В настоящее время он считается основным в самых распространенных операционных системах.

В стек протоколов TCP/IP часто включают и протоколы всех верхних уровней (рис. 7). И тогда уже можно говорить о функциональной полноте стека TCP/IP.

Как протокол IPX, так и протокол IP являются самыми низкоуровневыми протоколами, поэтому они непосредственно инкапсулируют свою информацию, называемую дейтаграммой, в поле данных передаваемого по сети пакета.

Рис. 7. Соотношение уровней модели OSI и стека протоколов TCP/IP

При этом в заголовок дейтаграммы входят адреса абонентов (отправителя и получателя) более высокого уровня, чем MAC-адреса, – это IPX-адреса для протокола IPX или IP-адреса для протокола IP. Эти адреса включают номера сети и узла, хоста (индивидуальный идентификатор абонента). При этом IPX-адреса (рис. 8) более простые, имеют всего один формат, а в IP-адрес (рис. 9) могут входить три формата (класса A, B и C), различающиеся значениями трех начальных битов.

Рис. 8. Формат IPX- адреса

Рис. 9. Форматы IP-адреса

Интересно, что IP-адрес не имеет никакой связи с MAC-адресами абонентов. Номер узла в нем присваивается абоненту независимо от его MAC-адреса. В качестве идентификатора станции IPX-адрес включает в себя полный MAC-адрес абонента.

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

Протокол NetBIOS (сетевая базовая система ввода/вывода) был разработан компанией IBM для сетей IBM PC Network и IBM Token-Ring по образцу системы BIOS персонального компьютера. С тех пор этот протокол стал фактическим стандартом (официально он не стандартизован), и многие сетевые операционные системы содержат в себе эмулятор NetBIOS для обеспечения совместимости. Первоначально NetBIOS реализовывал сеансовый, транспортный и сетевой уровни, однако в последующих сетях на более низких уровнях используются стандартные протоколы (например, IPX/SPX), а на долю эмулятора NetBIOS остается только сеансовый уровень. NetBIOS обеспечивает более высокий уровень сервиса, чем IPX/SPX, но работает медленнее.

На основе протокола NetBIOS был разработан протокол NetBEUI, который представляет собой развитие протокола NetBIOS до транспортного уровня. Однако недостаток NetBEUI состоит в том, что он не поддерживает межсетевое взаимодействие и не обеспечивает маршрутизацию. Поэтому данный протокол используется только в простых сетях, не рассчитанных на подключение к Интернет. Сложные сети ориентируются на более универсальные протоколы TCP/IP и IPX/SPX. Протокол NetBEUI в настоящее время считается устаревшим, хотя даже в операционной системе Windows XP предусмотрена его поддержка, правда, только как дополнительная опция.

Наконец, упоминавшийся уже набор протоколов OSI – это полный набор (стек) протоколов, где каждый протокол точно соответствует определенному уровню стандартной модели OSI. Набор содержит маршрутизируемые и транспортные протоколы, серии протоколов IEEE 802, протокол сеансового уровня, представительского уровня и несколько протоколов прикладного уровня.

Лекция 10Системы складирования данных.Архитектура хранилищ данных.Информационная технология складирования данных (data warehousing)

родилась в недрах компании IBM и была окончательно сформулирована Б. Инмоном и Р. Кимбаллом в 90-х годах прошлого столетия как метод решения информационно-аналитических задач в области принятия и поддержки решений. Возникнув на стыке технологии баз данных (БД), систем поддержки принятия решений (СППР — DSS) и компьютерного анализа данных, в дальнейшем концепция складирования данных претерпела эволюцию, поскольку оказалась пригодной для широкого круга приложений в бизнесе, науке и технологии.

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

Рис. 1 Упрощенная принципиальная схема функционирования организации

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

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

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

Рис. 2 Особенности систем складирования данных

Хранилище данных (ХД — data warehouse) является местом складирования собираемых в системе данных и информационным источником для решения задач анализа данных и принятия решений. Как правило, объем информации в ХД является достаточно большим. Упрощенно можно сказать, что хранилище данных управляет данными, которые были собраны как из операционных систем организации (OLTP-систем — On-Line Trasactions Processing), так и из внешних источников данных, и которые длительный период времени хранятся в системе. Более точное определение будет дано позже, после обсуждения истории создания концепции складирования данных.

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

эффективно использовались в аналитических приложениях ( analytical applications ).

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

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

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

Совместное действие этих операций в рамках ИС приводило к конфликтам в данных - потерям данных, ошибкам в обновлении и т.д. - так называемым аномалиям в данных. Предложив реляционную модель (которая является достаточно строго математической, а, следовательно, приемлемо контролируемой моделью), Е. Кодд в целом решил ряд проблем и задач операционной обработки данных. Создание реляционных СУБД позволило достаточно грамотно (с учетом уровня компетентности разработчика) строить системы операционной (или, как ее еще называют, транзакционной) обработки данных - OLTP (On-Line Trasactions Proccessing).

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

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

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

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

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

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

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

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

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

Наиболее важным фактором в развитии складирования данных стало увеличение мощности аппаратной платформы компьютеров, поскольку ХД хранят обычно очень большие объемы информации. Параллельно росла вычислительная мощность ПК и развитое программное обеспечение, которые позволили разработать и внедрить архитектуру клиент/сервер. Почти ко всем ХД можно обратиться с ПК, оснащенного развитыми инструментальными программными средствами. Эти средства изменяются от очень простых обработчиков запросов до мощных графических многомерных средств анализа данных. Создание серверных операционных систем, таких как Windows и Unix, повысило надежность в функционировании и дало мощные возможности распределенной вычислительной среде. Эти технологические факторы способствовали быстрому развитию систем складирования данных.

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

На рис.4 просуммированы основные факторы, способствующие созданию и развитию концепции систем складирования данных и хранилищ данных.

Различия между транзакционной и аналитической обработкой данных.

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

OLTP-системы спроектированы для оптимального выполнения предопределенных запросов в режиме работы, близком к режиму реального времени. Для таких систем обычно можно определить распределение нагрузки во времени, определить время пиковых нагрузок, оценить критические запросы и применить к ним процедуры оптимизации, поддерживаемые современными СУБД. Также относительно легко определить максимально допустимое время ответа на определенный запрос в системе. Стоимость времени ответа такого запроса может быть оценена на основе отношения стоимости выполнения операций ввода-вывода / стоимость затрат на трафик по сети. Например, для системы обработки заказов можно задать число активных менеджеров по оформлению заказов и среднее число заказов в течение каждого часа работы.

Данные в системах складирования данных остаются неизменными.Другое ключевое свойство данных в системе складирования данных

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

Данные в хранилище данных хранятся значительно более длительное время, чем в OLTP-системах.

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

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

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

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

Как правило, архитектуру ХД составляют следующие компоненты:средства извлечения данных из различных БД OLTP-систем,

унаследованных систем и других внешних источников данных;средства трансформации и очистки данных. Точность

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

программное обеспечение БД. Как правило, это высокопроизводительная РСУБД, используемая для структуризации и хранения информации;

средства для соединения источников данных с хранилищем и клиентов с сервером.

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

Все это – сложное специальное программное обеспечение, стоимость которого также может исчисляться десятками и сотнями тысяч долларов.

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

Характер и масштаб решаемых задач анализа данных определяет и подходы к выбору архитектуры и проектированию ХД.

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

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

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

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

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

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

Основные типы программно-аппаратной архитектуры хранилища данных

Рис. 5 Типовая обобщенная концептуальная схема для архитектуры ХД

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

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

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

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

Хранилище данных. Представляет собой ядро системы складирования данных. Это могут быть один или несколько серверов БД для поддержки ХД.

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

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

Уровень информационного доступа. Обеспечивает непосредственное общение пользователя с ХД. В качестве таких средств могут выступать стандартные пакеты MS Office, Lotus Notes или специальные программные продукты.

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

Типовыми архитектурами для систем складирования данных принято считать следующие:

системы с глобальным ХД;

системы с независимыми киосками данных; системы с интегрированными киосками данных; системы, разработанные на основе комбинации из

вышеперечисленных архитектур.Глобальное хранилище данных (Global data warehouse), или

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

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

Централизованное глобальное ХД характерно для организаций, расположенных территориально в одном здании. Оно поддерживается отделом информационных систем организации. Распределенное глобальное ХД также может быть использовано в рамках организации в целом. Оно физически распределяется по подразделениям организации и также поддерживается отделом информационных систем.

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

Управление ХД определяет, кто решает: какие данные должны поступать в ХД; когда данные должны поступать в ХД; когда данные должны обновляться; кому разрешен доступ к данным в ХД.Таким образом, для глобального ХД существуют два основных

архитектурных решения, как показано на рис.6.

Рис. 6. Основные архитектурные решения для глобального ХД

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

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

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

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

Киоски данных могут быть взаимозависимы или взаимосвязаны (так называемые связанные киоски данных ). Такая архитектура ХД включает в

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

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

Главным достоинством создания ХД такой архитектуры является более глобальное представление данных. Взаимосвязанные киоски данных могут управляться в рамках того подразделения, в котором они создаются.

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

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

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

базами данных, к ХД применимы следующие основные методологические подходы:

"сверху вниз" (Top down design); "снизу вверх" (Bottom down design); "из середины" (Middle of design).На выбор подхода к реализации ХД оказывают влияние следующие

факторы: состояние текущей информационной инфраструктуры

организации;

имеющиеся в наличии ресурсы; требования по возврату инвестиций; потребности организации в интегрированном представлении

данных о своей деятельности; скорость реализации.Выбор методологического подхода к реализации ХД влияет на объем и

тщательность проектирования.Подход "сверху вниз". Подход "сверху вниз" требует детального

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

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

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

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

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

вверх"). Таким образом, на каждом витке спирали может быть использован каждый из двух указанных выше подходов.

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

Характеристика решений ведущих производителей.Дадим краткий обзор решений основных производителей

программного обеспечения для разработки ХД. При изложении материала будем использовать следующую схему:

название проекта компании и его цель; архитектурные решения; СУБД и используемая модель данных; возможности языка обработки данных; степень охвата жизненного цикла (анализ — проектирование —

реализация — поддержка); возможные конкурентные преимущества.IBM. Решение компании IBM называется Data Warehouse Plus. Целью

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

IBM предлагает встроенную поддержку трех типов архитектурных решений для ХД:

независимый киоск данных; взаимосвязанные киоски данных; глобальное ХД.Несущая СУБД для ХД — семейство объектно-реляционных СУБД

DB2. Язык манипулирования данными — SQL.Преимущество решений IBM проявляется, когда и системы

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

С приобретением компании Informix Software IBM взяла под свое крыло ряд удачных решений этой компании в области систем складирования данных.

Oracle. Решения, предлагаемые компанией, преследуют две основные цели: предоставление пользователям широкого ассортимента программных продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative.

Компания Oracle не предлагает поддержку каких-либо встроенных архитектурных решений для ХД.

Несущая СУБД для ХД — семейство объектно-реляционных СУБД Oracle 11g/10g. Язык манипулирования данными — SQL. Начиная с версии

8i, диалект SQL существенно дополнен набором функций для аналитической обработки данных, вплоть до построения линейной регрессии.

Компания выпускает специальный CASE-инструментарий для проектирования ХД.

Конкурентные возможности Oracle определяются следующими факторами:

имеется набор готовых приложений для разработки ХД, обеспечивающий полный жизненный цикл;

компания является одним из лидеров по продажам в области анализа данных;

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

NCR. Решение этой компании в области складирования данных ориентировано на организации, у которых имеются потребности в системах DSS (система поддержки и принятия решений) и системах OLAP. Предлагаемая архитектура называется Enterprise Information Factory (виртуальное предприятие).

Несущая СУБД для ХД — реляционная СУБД Teradata.Конкурентным преимуществом решений компании является большой

опыт применения СУБД Teradata и связанных с ней методов параллельной обработки данных.

SAS Institute. Компания считает себя поставщиком полного решения для организации ХД. Компания предлагает методологию Rapid Data Warehousing для быстрого создания и наполнения ХД. В основу этой методологии положено:

обеспечение доступа к данным в ХД с возможностью их извлечения из разнообразных источников данных (интероперабельность);

преобразование и манипулирование данными в рамках 4GL (Data Step);

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

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

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

Sybase. Стратегия компании в области ХД основывается на разработанной архитектуре Warehouse WORKS.

Несущая СУБД для ХД — реляционная СУБД Sybase System 11, средство подключения к базам данных OmniCONNECT. Язык манипулирования данными — SQL и средства быстрой разработки приложений.

Компания выпускает специальный CASE-инструментарий для проектирования ХД.

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

Microsoft. Компания сравнительно недавно стала активно предлагать комплексные решения в области ХД. Целью корпорации Microsoft является создание инструментальной и технологической среды, которая позволила бы минимизировать затраты на создание ХД и сделала бы этот процесс доступным для массового пользователя. Акцент предлагаемых компанией решений в области складирования данных концентрируется на развитии инструментальных средств OLAP.

Корпорация предлагает спецификации среды Microsoft Data Warehousing Framework для создания и использования ХД. Открытость среды Microsoft Data Warehousing Framework обеспечила ее поддержку многими производителями программного обеспечения.

Цель Microsoft Data Warehousing Framework состоит в том, чтобы упростить разработку, внедрение и администрирование решений на основе ХД. Эта спецификация призвана обеспечить:

открытую архитектуру, которая интегрируется и расширяется третьими фирмами;

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

доступ к разделяемым метаданным со стороны процессов разработки ХД.

Несущая СУБД для ХД — реляционная СУБД MS SQL Server. Язык манипулирования данными — SQL со встроенными средствами обработки многомерных кубов.

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

Software AG. Деятельность компании в области ХД происходит в рамках программы Open Data Warehouse Initiative.

Несущая СУБД для ХД — сетевая СУБД ADABAS. Язык манипулирования данными — Natural 4GL.

У компании имеются собственные средства извлечения и анализа данных, а также программный продукт управления ХД SourcePoint.

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

Лекция 11Типовые программно-аппаратные решения хранилищ данных.

Общие типовые решения.Существует несколько вариантов реализации ХД в рамках типовой

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

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

Киоски данных Архитектура представляет собой облегченный вариант ХД тематической направленности. Бывают киоски данных, связанные с интегрированным ХД или несвязанные (автономные).

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

Хранилища данных с многоуровневой (в основном трехзвенной) архитектурой, или корпоративные ХД. Архитектура является разновидностью глобального ХД, в которую технологически реализуются три уровня (рис.1). На первом уровне располагается корпоративное ХД организации. На втором уровне поддерживаются связанные киоски данных тематической направленности на основе многомерной СУБД. На третьем уровне находятся клиентские приложения пользователей с установленными на них средствами анализа данных.

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

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

Корпоративная информационная фабрика (Corporate Information Factory, CIF). Эта архитектура является развитием архитектуры корпоративного ХД (enterprise data warehouse, EDW). Ее использование предполагает скоординированное извлечение данных из источников, загрузку их в реляционную БД со структурой в третьей нормальной форме, использование построенного ХД для наполнения дополнительных репозиториев презентационных данных.

Хранилище данных с архитектурой шины данных (Data Warehouse Bus). В этой архитектуре ХД не является единым физическим репозиторием

(в отличие от CIF). Это "виртуальное" ХД, представляющее коллекцию витрин данных, каждая из которых имеет архитектуру типа "звезда".

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

Рис.1. Хранилища данных с многоуровневой архитектурой ХД

Существенные различия в программном обеспечении у различных производителей определяются следующими факторами:

1) используемая модель данных; 2) степень охвата жизненного цикла; 3) встроенная поддержка различных архитектур; 3) возможности языка обработки данных. Можно обратить внимание на

следующие две основные тенденции.Производители предлагают комплексные решения по созданию

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

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

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

1. Комбинация готовых продуктов (решений) разных фирм без непосредственного программирования.

2. Использование полной замкнутой цепочки продуктов (решений) одной фирмы-поставщика.

3. Использование контура продуктов (решений) одной фирмы поставщика с дополнением до замкнутой цепочки совместимыми продуктами третьих фирм.

Простое масштабируемое решениеПример простого масштабируемого решения можно предложить,

основываясь на использовании Crystal Enterprise и Crystal Reports (фирма Business Objects) как инструментов конечного пользователя.

ХД реализуется на СУБД Oracle, DB2, MS SQL Server или других, имеющих ODBC-интерфейс или интерфейс прямого доступа с Crystal Enterprise. Обычно применяется классическая архитектура ХД без киосков данных. Для этого решения большое значение имеет тщательное проектирование структуры ХД и запросов. Необходимо разработать и создать приложения для очистки данных (или воспользоваться имеющими у поставщиков средствами).

Преимущества.Сводится к минимуму объем программирования, т.к. все стадии

покрываются готовыми коробочными продуктами.Сокращается время разработки и создания ХД (за счет исключения

трудоемкого процесса написания программ).Время разработки типового запроса — от 2-х до 6-ти часов, время

разработки типового отчета – 1-2 дня.Такое решение хорошо для создания прототипов ХД, поскольку в

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

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

Такое решение прекрасно подходит и для создания виртуальных ХД.Недостатки.Разработка сложных перекрестных запросов может занять много

времени.Это решение не подходит для сложной аналитической обработки

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

Замкнутое типовое решение.

Замкнутое типовое решение можно предложить на основе использования замкнутой цепочки продуктов одной фирмы-поставщика, например Microsoft (рис.2), Oracle (рис.3), SAS или Sybase.

Рис. 2. Типовое решение на основе продуктов Microsoft

Рис. 3. Типовое решение на основе продуктов Oracle

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

сервисов.Время разработки и создания ХД поддается строгому описанию и

достаточно точной оценке.Такое решение хорошо для создания ХД, которые предполагается

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

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

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

Кадровый вопрос: необходимо нанимать высококвалифицированные кадры, умеющие работать с набором продуктов выбранной компании. Как правило, обучение своих сотрудников по всем направлениям работы с ХД малоэффективно, хотя и привлекательно.

Области применения технологии хранилищ данных.Концепция хранилищ данных находит применение во многих сферах

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

1. Разработка основы для создания аналитических подсистем сопровождения бизнеса.

2. Разработка ХД как составной части виртуального предприятия.3. Разработка ХД для цифровых (электронных) библиотек и

мультимедиа.Основные сферы применения технологии складирования данных

приведены в табл.1. Имеется тенденция расширения проникновения концепции в те сферы бизнеса, где необходимо выполнять, с одной стороны, сравнительный анализ, искать зависимости в данных, выявлять тренды в рядах динамики, а с другой – использовать системы складирования данных в связке с системами операционной обработки.

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

№ Сфера деятельности Комментарий

1 Сегментация рынка CRM

2 Планирование продаж, прогнозирование и управление CRM, SCM

3 Опека клиентов CRM

4 Схемы лояльности

5 Проектирование и разработка продуктов MRP/ERP

6 Интеграция цепочки поставок SCM, ERP/MRP, SCP, SCE, DRP, JIT

7 Инновации и новые возможности

8 Новые возможности приложений с использованием Интернет/Интранет

eBusiness, TMP

9 Приложения, основанные на агентах программного обеспечения

10 Приложения для извлечения знаний и кибер-организация EIF, виртуальное

предприятие

11 Распространение DW из области стратегического планирования в область бизнес операций

VDW

12 Приложения для вертикальных секторов индустрии CRM, TMP

13 Готовые DW (off-the-shalf)

14 Автоматизация принятия решений DSS, EIS

15 Новые категории оперативных приложений, ориентированные на клиента

OLAP

16 Сбор и анализ экспериментальных данных в химии, физике, биологии

EDW

17 Хранение мультимедийной информации в DW DL

Сокращения, использованные в колонке "Комментарий" табл. 1. и не поясненные ранее, имеют следующие значения:

CRM (Customer Relationship Management) – управление взаимоотношениями с клиентами;

SCM (Supply Chain Management) – управление цепочкой поставок;SCP (Supply Chain Planing — планирование управления цепочкой

поставок;SCE (Supply Chain Executing) — реализация управления цепочкой

поставок;DRP (Distribution Resource Planing) — планирование потребностей

распределения;JIT (Just-in-Time) — точно в срок;MRP (Manufacturing Resource Planing) – планирование материальных

затрат;VDW (Virtual Data Warehouse) – виртуальные хранилища данных;DL (Digital Library) – цифровые библиотеки;ERP (Enterprise Resource Planing) – системы планирования масштаба

предприятия;TMP (Trading Partner Management) – управление деловыми партнерами;EIF (Enterprise Information Factory) – виртуальное предприятие.Рассмотрим несколько примеров применения технологии

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

Аналитические CRM-системы.Оперативные системы CRM содержат следующие компоненты: центры

обработки мобильных сообщений, данные по обслуживанию клиентов,

данные из отдела продаж, данные о продажах через интернет-магазины, данные ERP систем, данные из ИСР (EIS) и других внешних источников. Эти системы выступают источниками данных для аналитических CRM. Типовая структура аналитического ХД CRM-системы приведена на рис.4.

Рис. 4. Архитектура аналитической CRM-системы

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

Наиболее известное работающее решение в области аналитических CRM в телекоммуникациях имеет компания SAS Institute (US WEST Communications).

Аналитические SRM-системы.Аналитические SRM (Supply Relationship Management) системы

занимаются управлением взаимоотношениями с поставщиками. Пример типовой архитектуры для ХД аналитических SRM систем приведен на рис.5.

Рис. 5. Архитектура аналитической SRM-системы

Конкурентные преимущества.Снижение затрат (от 5 до 15%), потока сырья, планирования,

исполнения и контроля прохождения.Повышение эффективности стратегии бизнеса в области управления

финансовыми, материальными и информационными потокамиСоздание оптимальных циклов поставок.Оптимизация бизнес процессов на уровне работы с поставщиками.Сокращение времени поставок.Увеличение прибыли (от 5 до 15%)Сопутствующие проблемы.При использовании отдельных SRM-решений возможен конфликт с

другими решениями.Возникает ряд сложностей с обучением персонала.Сопротивление поставщиков и дистрибъютеров.Наиболее известное решение в области создания аналитических SRM-

систем разработано компанией SAS Institute.

Аналитические SCM-системы.Аналитические SCM-системы, не встроенные в ERP-системы,

представляют собой информационные системы для решения задач анализа и оптимизации в управлении жизненным циклом продукции. Пример типовой архитектуры для ХД аналитической SCM-системы приведен на рис.6.

Рис. 6. Архитектура аналитической SCM-системы

Достоинства использования SCM-решений.Минимизация издержек сети сбыта.Снижение затрат, оптимизация потоков сырья, материалов,

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

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

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

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

решениями.

Возникает ряд сложностей с обучением персонала.Сопротивление поставщиков и дистрибъютеров.Конкурентные преимущества.Уменьшение стоимости и времени обработки заказов (от 20 до 40%).Сокращение времени выхода на рынок (от 15 до 30%).Сокращение закупочных издержек (от 5 до 15%).Уменьшение складских запасов (от 20 до 40%).Сокращение производственных затрат (от 5 до 15%).Увеличение прибыли (от 5 до 15%).По уровню использования SCM-решений телекоммуникации занимают

второе место в мире (после нефти и газа). Перечень наиболее удачных решений в области оперативных SCM-систем приведен в табл. 2

Таблица 2. Решения в области оперативных SCM

Компания Программные продукты

IBM WebSphere (for e-Business), интеграция с ERP

SAP Business Information WareHouse, SAP Advanced Planer & Optimizer Logistics Execution System

BAAN IBAAN c совокупностью модулей в архитектуре ПО BAAN, в том числе и использованием хранилища данных

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

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

Рис. 7. Место хранилища данных в виртуальном предприятии

Мультимедийные хранилища данныхОчень перспективным в последнее время становится разработка ХД

для цифровых (электронных) библиотек и мультимедиа. Современные СУБД имеют ряд встроенных возможностей для хранения и выборки мультимедийных данных (например СУБД Pilot). Однако большинство решений по созданию мультимедийных баз данных реализуется на реляционных СУБД, обладающих возможностью работы с BLOB-данными и имеющими поддержку очень больших БД. Типичными представителями таких СУБД являются СУБД Oracle (имеет специальные средства выборки визуальной информации — VIR и интернет-систему обработки файлов iFS), DB2 и Informix (теперь IBM).

Примерами мультимедийных ХД являются разрабатываемые во всем мире электронные хранилища музейных данных (образы картин и других экспонатов).

Обсудим особенности типового решения создания мультимедийных ХД на основе реляционных СУБД. Следует отметить следующие свойства медиаданных:

неструктурированная форма с точки зрения теории реляционных баз данных;

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

выражен простым типом данных реляционных СУБД;

поиск данных затруднен или просто невозможен стандартными средствами СУБД.

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

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

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

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

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

технологий обсуждается предложенная Биллом Инмоном концепция так называемой корпоративной информационной фабрики (Corporate Information Factory, CIF) как одной из основополагающих вычислительных архитектур для производства информационных продуктов предприятия. Для любого предприятия реализацию такой концепции можно рассматривать как важную перспективную задачу, решение которой не только позволит повысить качество управления взаимоотношениями с внешними организациями (налоговыми и финансовыми государственными структурами) и партнерами, но и значительно увеличить производительность его подразделений, поставляющих информацию, необходимую для принятия стратегических решений.

Рассмотрим более подробно концепцию CIF.

Производству данных — свою технологию.Корпоративная информационная фабрика — это логическая

архитектура программно-аппаратного решения по производству, складированию, управлению и доставке данных для поддержки принятия стратегических и тактических решений в масштабе организации. Концепция CIF, предложенная классиком в области теории хранилищ данных Биллом Инмоном в серии его работ, подразумевала системно организованное взаимодействие репозиториев оперативных данных (Operational Data Store), центрального ХД, витрин данных и системы интеллектуального анализа данных (Data Mining) за счет создания технологических цепочек переработки и доставки данных.

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

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

Краеугольным камнем правильно спроектированной CIF являются, безусловно, метаданные. Задача этого слоя — описать в рамках единой терминологической базы (метаданные бизнес-пользователя) всю совокупность объектов управления средой CIF (метаданные администрирования). Только подход "от метаданных" позволяет из гетерогенного потока входной информации получить однородное описание среды и предметной области, что дает возможность одинаково легко обращаться к измерениям, кубам, отчетам и бизнес-объектам на основе произвольных выборок. Таким образом, обеспечивается высокое качество циркулирующей в CIF информации.

Структурные компоненты CIF.В основе CIF лежит модель функционального разделения процессов

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

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

Логическая структура CIF включает в себя несколько типовых архитектурных элементов табл.3.

Таблица 3. Типовые архитектурные элементы логической структуры CIF

Элемент Характеристика

Системы, доставшиеся "по наследству" (Legacy Systems)

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

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

Приложения оперативного управления организацией (OLTP)

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

Оперативные склады данных (Operational Data Store - ODS)

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

Компоненты преобразования данных (ETL-tools, Staging Area, Near-line Storage)

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

Корпоративное хранилище данных (Enterprise Data Warehouse)

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

Витрины данных (Data Marts)

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

Приложения поддержки принятия решений (DSS) и приложения анализа данных (DM)

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

Инфраструктура сетевых коммуникаций

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

CIF на предприятии.На предприятии производственные и финансовые потоки тесно

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

Описанная выше в общих чертах схема превращения данных в информационные продукты и составляет суть концепции CIF на любом предприятии (рис.8).

Рис. 8. "Корпоративная информационная фабрика"

Хранилище данных — фундамент CIF предприятия.Складирование данных — это технология, с помощью которой можно

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

Рассмотрим подробнее, как "фабрика управленческих данных" функционирует на предприятии.

ERP/MRP II системы как источники данных для CIF.Первоначальное наполнение корпоративного ХД и постоянное

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

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

Таким образом, на первом шаге построения CIF-системы источники данных накапливают информацию в масштабе предприятия в "сыром" виде: она не подготовлена для анализа и компиляции аналитической отчетности.

Интеграция и преобразование данных.Организация процесса интеграции является еще одним фактором

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

Для наполнения корпоративного ХД в нем обычно предусматриваются инструментальные средства:

для извлечения и доставки из различных оперативных БД и внешних источников;

для очистки, преобразования и интеграции;для загрузки;для актуализации.Хранилище данных.ХД — это предметно-ориентированная, интегрированная,

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

Управление данными.Процесс управления данными предусматривает комплекс процедур,

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

Инструментальные средства для производства информационных продуктов.

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

средства для многомерного представления данных и манипулирования ими;

средства для формирования отчетов;систему информационных запросов.В качестве отличительных характеристик подхода Билла Инмона к

архитектуре ХД можно назвать следующие:1. Использование реляционной модели организации атомарных

данных и многомерной модели — для организации суммарных данных.2. Использование подхода "проектирование из середины" при

создании больших ХД, что позволяет создавать ХД поэтапно.3. Использование третьей нормальной формы для организации

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

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

5. ХД — это не механическая коллекция витрин данных, а физически целостный объект.

Хранилища данных с архитектурой шины данных.В данной архитектуре ХД с архитектурой шины данных, предложенной

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

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

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

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

ХД с архитектурой шины данных состоит из набора взаимосвязанных киосков данных, которые созданы для обслуживания бизнес-процессов организации (См. рис.9).

Рис. 9. Хранилище данных с архитектурой шины данных

Можно отметить типичные характеристики ХД с архитектурой шины данных.

1. Использование многомерной модели организации данных с архитектурой "звезда" (star scheme).

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

3. ХД не является единым физическим репозиторием (в отличие от CIF). Это "виртуальное" ХД, представляющее коллекцию витрин данных, каждая из которых имеет архитектуру типа "звезда".

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

Обе эти архитектуры отличаются в основном способами представления данных. В CIF, они, как правило, нормализованы, а в ХД с архитектурой шины данных — нет.

Объединенное (федеративное) ХД.Для любой организации, особенно многофилиальной, наличие

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

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

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

Рис. 10. Федеративное хранилище данных

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

Каждый из экземпляров федеративного ХД хранит копию базовой бизнес-модели и общие основные данные (common master dat), причем каждое ХД более высокого уровня содержит итоговые транзакционные данные более низкого уровня. Общие основные данные — например, схема организационной структуры компании — отправляются "вниз", т.е. из корпоративного (глобального) ХД, а суммарные данные о транзакциях отправляются "верх", т.е. из локального ХД. Таким образом, "федерация" ХД может предоставить местным отделениям необходимую гибкость, а также

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

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

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

ВыводыКомпонентами типовой архитектуры ХД являются:программное обеспечение промежуточного слоя. Основное назначение

этих компонент состоит в обеспечении доступа к сети и доступа к данным;БД OLTP систем и данные внешних источников;предварительная обработка и загрузка данных;ХД, реализованное средствами СУБД;метаданные, которые играют роль справочника о данных;уровень доступа к данным — программное обеспечение, которое

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

непосредственное общение пользователя с ХД;уровень администрирования.В последнее время возрастает практический интерес к использованию

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

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

400% возврат инвестиций, вложенный в создание хранилища данных (по результатам трехлетнего исследования опыта 62-х корпораций, проведенного IDC). Сроки исполнения — от 6 месяцев до 2-х лет в зависимости от объема хранилища данных, при следующем распределении затрат: для небольшого подразделения — $ 400000-600000, для большого подразделения — $800000-1500000, для большой корпорации — $15000000.

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

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

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

Лекция 12Краткая история облачных вычислений.Термин «Облако» (cloud) используется как метафора, основанная на

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

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

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

1. История и ключевые факторы развитияДля того чтобы понять что такое «облако» стоит начать с истории

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

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

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

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

Следующими важнейшими вехами в истории концепции облачных вычислений стало заявление Джона МакКарти, компьютерный исследователь, известный своими разработками (создатель термина "Artificial Intelligence" и языка программирования Lisp), о том, что "вычислительные мощности могут когда-нибудь стать публично доступными ресурсами", и выпуск в 1966 году книги Дугласа Пархилла "The Challenge of the Computer Utility", в которой он описал практически все основные характеристики существующих сегодня облаков, а также впервые употребив сравнение с электрической сетью.

Идея того, что сейчас мы называем облачными вычислениями, впервые была озвучена Джозефом Карлом Робнеттом Ликлайдером (J.C.R. Licklider) в 1970году, когда он был ответственным за разработку ARPANET (Advanced Research Projects Agency Network). Идея Линклайдера заключалась в том, что каждый человек будет подключен к сети, из которой он будет получать не только данные, но и программы. Другой ученый Джон Маккарти (John McCarthy) говорил о том, что вычислительные мощности будут предоставляться пользователям как услуга (сервис). На этом развитие облачных технологий было приостановлено до 90-х годов. Ее развитию поспособствовали ряд факторов:

Стремительное развитие сети Интернет, а именно пропускной способности. Хотя в начале 90-х глобальных прорывов в области облачных технологий не произошло, сам факт «ускорения» Интернета дал толчок к скорейшему развитию технологии.

В 1999 году появилась компания Salesforce.com, которая предоставила доступ к своему приложению через сайт. Эта компания стала первой компанией, предоставившей свое программное обеспечение по принципу «программное обеспечение как сервис» (SaaS).

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

В 2006 году Amazon запустила сервис Elastic Compute cloud (EC2), где пользователи могли запускать свои собственные приложения. Таким образом, сервисы Amazon EC2 и Amazon S3 стали первыми сервисами облачных вычислений.

Свой вклад в развитие облачных вычислений внесла компания Google со своей платформой Google Apps для веб-приложений в бизнес секторе.

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

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

Далее, более 40 лет, история облачных вычислений продолжала развиваться, концепция постепенно выкристаллизовывалась, до тех пор, пока в 2006 года компания Amazon не запустила платформу Amazon Web Service (AWS), модернизировав свои центры обработки данных, которые, как и большинство компьютерных инфраструктур, использовали лишь 10% от их емкости. Можно считать, что компания Amazon сыграла ключевую роль в открытии рынка облачных вычислений во всем мире, оптимизировав как собственные ресурсы, так и начав получать с ранее простаивавших ресурсов прибыль. Спустя всего несколько лет, в 2008 году, были анонсированы облачные платформы от Microsoft и Google, Windows Azure и Google App Engine соответственно. В 2010 году увидел свет первый выпуск платформы Windows Azure. Начиная с примерно 2008 года рынок облачных вычислений начал стремительно вырастать, заполняясь как топовыми игроками (Amazon, Microsoft, Salesforce, Google, HP, Dell, AT&T, RackSpace), так и организациями, предлагающими облачные ресурсы для решения конкретных задач (Engine Yard, gCloud3, OrangeScape). В последнее время облачными вычислениями начали всерьёз интересоваться исследователи и научные учреждения (в т.ч. академические), начали защищаться научные работы об облачных вычислениях.

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

программном обеспечении, с которым он работает. Термин «Облако» используется как метафора, основанная на изображении Интернета на диаграмме компьютерной сети, или как образ сложной инфраструктуры, за которой скрываются все технические детали. Согласно документу IEEE, опубликованному в 2008 году, «Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в интернет и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т.д.

Облачная обработка данных как концепция включает в себя понятия:инфраструктура как услуга,платформа как услуга,программное обеспечение как услуга,данные как услуга,рабочее место как услугаи другие технологические тенденции, общим в которых является

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

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

Терминология.Хотя термин «облачные вычисления» является устоявшимся, в русском

языке он имеет другое значение, нежели оригинал. «Cloud» помимо облака имеет и иное значение, а именно рассеяный; собственно значение «рассеянный» и подразумевается в англоязычной терминологии.

Платформы.Для обеспечения согласованной работы ЭВМ, которые предоставляют

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

Облачные вычисления и виртуализация.Для облачных вычислений основным предположением является

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

Облачные вычисления (cloud computing) — это технология распределённой обработки данных в которой компьютерные ресурсы и мощности предоставляются пользователю как интернет-сервис. Если объяснить доступным языком, то – это Ваша, в некотором смысле рабочая площадка в интернете, а точнее на удаленном сервере.

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

У вас есть электронная почта (e-mail)? Конечно, есть. Так вот, если Вы работаете с почтой на каком-то сайте-сервисе (например, gmail), который эту почту позволяет использовать, то это и есть ничто иное как облачный сервис. Или, к примеру, обработка изображений. Если вы уменьшаете размер, переворачиваете свою фотографию в Photoshop или другой специальной программе, то к облачной технологии Вы не имеете никакого отношения, — всё происходит и обрабатывается локально на Вашем компьютере. А вот, если, загрузив изображение, к примеру, через сервис Picasa, Вы его обрабатываете по ту сторону, то бишь в браузере, то это и есть то самое «облако».

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

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

Основание пирамиды «инфраструктура» – это набор физических устройств (серверы, жесткие диски и т.д.), над ней выстраивается «платформа» — набор услуг и верхушка – программное обеспечение, доступное по запросу пользователей.

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

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

Услуги, предоставляемые облачными системами.Все, что касается сloud сomputing (далее СС), обычно принято

называть словом aaS. Расшифровывается это просто – «as a Service«, то есть «как сервис», или «в виде сервиса».

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

Storage-as-a-Service («хранение как сервис»)Это, пожалуй, самый простой из СС-сервисов, представляющий собой дисковое пространство по требованию. Каждый из нас когда-нибудь сталкивался с ситуацией, когда на мониторе появлялось зловещее предупреждение: «Логический диск заполнен, чтобы освободить место, удалите ненужные программы или данные». Услуга Storage-as-a-Service дает возможность сохранять данные во внешнем хранилище, в «облаке». Для Вас, оно будет выглядеть, как дополнительный логический диск или папка. Сервис является базовым для остальных, поскольку входит в состав практически каждого из них. Примером может служить Google Drive и прочие схожие сервисы.

Database-as-a-Service («база данных как сервис») Здесь скорее больше для админов, ибо сия штука предоставляет возможность работать с базами данных, как если бы СУБД была установлена на локальном ресурсе. Причем, в этом случае гораздо легче «расшаривать» проекты между разными исполнителями, не говоря уже о том, сколько деньжат можно сэкономить на компьютерном железе и лицензиях, требуемых для грамотного использования СУБД в крупной или даже средней организации.

Information-as-a-Service («информация как сервис») Дает возможность удаленно использовать любые виды информации, которая может меняться ежеминутно или даже ежесекундно.

Process-as-a-Service («управление процессом как сервис») Представляет собой удаленный ресурс, который может связать воедино несколько ресурсов (таких как услуги или данные, содержащиеся в пределах одного «облака» или других доступных «облаков»), для создания единого бизнес-процесса.

Application-as-a-Service («приложение как сервис») Еще, может называется, Software-as-a-Service («ПО как сервис»). Позиционируется как «программное обеспечение по требованию», которое развернуто на удаленных серверах и каждый пользователь может получать к нему доступ посредством Интернета, причем все вопросы обновления и лицензий на данное обеспечение регулируется поставщиком данной услуги. Оплата, в данном случае, производиться за фактическое использование последнего. В качестве примера можно привести Google Docs, Google Calendar и т.п. онлайн-программы.

Platform-as-a-Service («платформа как сервис») Пользователю предоставляется компьютерная платформа с установленной операционной системой и некоторым программным обеспечением.

Integration-as-a-Service («интеграция как сервис») Это возможность получать из «облака» полный интеграционный пакет, включая

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

Security-as-a-Service («безопасность как сервис») Данный вид услуги предоставляет возможность пользователям быстро развертывать продукты, позволяющие обеспечить безопасное использование веб-технологий, электронной переписки, локальной сети, что позволяет пользователям данного сервиса экономить на развертывании и поддержании своей собственной системы безопасности.

Management/Governace-as-a-Service («администрирование и управление как сервис») Дает возможность управлять и задавать параметры работы одного или многих «облачных» сервисов. Это в основном такие параметры, как топология, использование ресурсов, виртуализация.

Infrastructure-as-a-Service («инфраструктура как сервис») Пользователю предоставляется компьютерная инфраструктура, обычно виртуальные платформы (компьютеры), связанные в сеть, которые он самостоятельно настраивает под собственные цели.

Testing-as-a-Service («тестирование как сервис») Дает возможность тестирования локальных или «облачных» систем с использованием тестового ПО из «облака» (при этом никакого оборудования или обеспечения на предприятии, не требуется).

Utility computing Идея не нова, но эта форма облачных технологий приобрела новую жизнь с Amazon.com, Sun, IBM и другими, предлагающими в настоящее время виртуальные серверы вычислительных ресурсов по принципу коммунальных услуг, доступ к которым клиент может получить в любое время. Выгода для Вас как клиента в том, что вы платите за вычислительные ресурсы и программное обеспечение только тогда, когда они вам действительно нужны. Концепция utility computing (UC) — предоставление вычислительных ресурсов по принципу коммунальных услуг - позволяет добиться недостижимой ранее эффективности.

Среда разработки как сервис Другой вариант SaaS, эта форма облачных технологий обеспечивает среду разработки как сервис. Вы создаете собственные приложения, которые работают на инфраструктуре провайдера и доставляются пользователям через Интернет с серверов провайдера. Как и Legos, эти услуги ограничиваются дизайном поставщика и его возможностями, так что вы конечно не получаете полную свободу, но вы получите предсказуемость и предварительную интеграцию. Пример подобного сервиса Salesforce.com, Coghead и новый Google App Engine.

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

предоставляемые SecureWorks, IBM и Verizon так-же попадают в эту категорию, поскольку предоставляют услуги на основе анти-спама Postini, недавно приобретенного Google.

Service commerce platforms Эта услуга гибрид SaaS и MSP, сервис входящий в облачные технологии предлагает услуги из центра, с которым пользователи в дальнейшем взаимодействуют. Данный сервис наиболее распространен в условиях торговли. Позволяет пользователям например заказать билеты для путешествия или секретарские услуги из общей платформы, которая затем координирует предоставление услуг и цен в допустимых пределах заданных пользователем. Работает этот сервис как автоматизированное бюро обслуживания. Для примера можно привести Rearden Commerce и Ariba.

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

Для наглядности, обобщим все эти сервисы архитектуры «облако», в одну схему на которой приведена классификация сервисов, по типу услуг.

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

Публичные Частные Гибридные.

Кратко по каждой: Публичное облако — это ИТ-инфраструктура, используемая

одновременно множеством компаний и сервисов. Пользователи не имеют возможности управлять и обслуживать данное «облако», а вся ответственность по этим вопросам возложена на владельца ресурса. Абонентом, предлагаемых сервисов может стать любая компания и индивидуальный пользователь. Примерами могут служить онлайн-сервисы: Amazon EC2, Google Apps/Docs, Microsoft Office Web.

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

Гибридное облако — это ИТ-инфраструктура использующая лучшие качества публичного и приватного облака при решении поставленной задачи. Часто такой тип применяется, когда организация имеет сезонные периоды активности, другими словами, как только внутренняя ИТ-инфраструктура не справляется с текущими задачами, часть мощностей перебрасывается на публичное «облако» (например, большие объемы статистической информации), а также для предоставления доступа пользователям к ресурсам предприятия через публичное «облако».

Теперь рассмотрим возможности облачных вычислений: Доступ к личной информации с любого компьютера,

подключённого к Интернету Можно работать с информацией с разных устройств (ПК,

планшеты, телефоны и т.п.) Не важно в какой операционной системе Вы предпочитаете

работать, — веб-сервисы работают в браузере любых ОС Одну и ту же информацию, как Вы, так и окружающие, могут

просматривать и редактировать одновременно с разных устройств Многие платные программы стали бесплатными (или более

дешёвыми) веб-приложениями Если что-то случится с вашим устройством (ПК, планшетом,

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

Всегда под рукой свежая и обновлённая информация Вы всегда пользуетесь самой последней версией программ и при

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

людьми из любой точки земного шарика.

Обзор облачных технологий.

Говоря о том, что такое облачные технологии и облачные вычисления, всегда необходимо помнить о том, как определяются основные характеристики любого настоящего облака – наличие пула ресурсов, самообслуживание, эластичность и оплата на основе использования. Эти характеристики были выведены National Institute of Standards and Technology (NIST). Авторы для описания облачных сервисов используют принцип 4-3-2. Первая цифра, 4, используется для описания четырех основных характеристик облачного сервиса.

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

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

Elastic – эластичность заключается в возможности динамического масштабирования по запросу за очень короткое время.

Usage Based – Модель оплаты по факту использования содержит в себе свод правил, регламентирующих, что пользователь платит только тогда, когда использует выделенные мощности. Это позволяет перенаправить часть ресурсов, ранее использовавшихся для оплаты поддержки и обслуживания, например, периодически простаивающего оборудования, на бизнес-задачи организации и реализовать ту необходимую гибкость, которая лежит в основе эффективного использования ресурсов. Экономия очевидна – благодаря объединению ресурсов в пулы и модели оплаты по факту использования многие расходы становятся излишними, их можно избежать, и построить ту инфраструктуру, которая максимально отвечает бизнес-сценариям организации, на то время, которое она должна существовать.

Вторая цифра принципа 4-3-2, характеризует три основных метода поставки облачных сервисов: Infrastructure-As-A-Service, Platform-As-A-Service и Software-As-A-Service. В настоящее время существует широкая таксономия терминов, сужающих контекст, например, MBaaS (Mobile-Backend-As-A-Service) и Metal-As-Service, но в общем смысле все сводится к трем методам. В индустрии определены три типа поставок облачных сервисов:

IaaS – набор связанных с инфраструктурой возможностей (ОС, сетевое подключение, т.д.), предоставляемых клиенту на основе модели

"оплаты-за-использование" и могущих использоваться для размещения приложений.

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

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

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

Следующей цифрой в принципе 4-3-2, характеризуется тип облака. Тип облака влияет на размещенные в нем сервисы достаточно опосредовано – для конечного пользователя использование сервиса, размещенного в приватном облаке или размещенного в публичном, может не нести никакого различия – использование практически всегда полностью прозрачно. Аналогично методам поставки, существуют дополнительные термины, характеризующие тип облака, например, Community Cloud, но данные типы так или иначе являются либо развитием, либо симбиозом приватного или публичного типов.

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

Сценарии, подходящие для облаков

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

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

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

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

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

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

рынке и на что стоит обратить свое внимание. Начнем с сервисов: iCloud Облачный сервис iCloud от компании Apple (пришедший

на смену MobileMe), полностью автоматический и бесплатный (хоть и с небольшими функциональными ограничениями). Оный сохраняет Ваш всевозможный контент (почта, календарь, контакты, документы, музыка, видео и изображения и т.д.) на серверах, а затем доставляет его на все устройства (iPhone, iPad, iPod touch, Mac и PC) с помощью беспроводной технологии Push.

Google Play новый облачный сервис под названием Google Play от «корпорации добра», который предназначен для размещения пользователями кинофильмов, музыки, приложений и книг на специально предназначенных для хранения цифровой информации серверах. Доступ к сервису предоставляется непосредственно из браузера, независимо от ОС, а поэтому может осуществляться как с ПК, так и с мобильных устройств на базе Android. У каждого пользователя есть возможность  разместить и хранить до 20-ти тысяч музыкальных записей на бесплатной основе, а также напрямую скачивать на сервер приобретенные в магазинах (Android Market, Google Music и Google eBookstore) цифровые товары – кинофильмы, электронные книги, программы, музыкальные треки, как купленные, так и взятые напрокат.

OnLive всем знакомый сервис. Предоставляет возможность играть в современные игры даже на самом простом и слабеньком компьютере. Технически это выглядит следующим образом: сама игра располагается на удаленном сервере и там же производится обработка графики, которая поступает на компьютер к пользователю уже в «готовом» виде. Проще говоря, те вычисления, которые при обычной игре на компьютере выполняют видеокарта, процессор и пр, здесь уже выполнены на сервере, а Ваш компьютер используется лишь как монитор, получающий конечную картинку. Если Вы не поняли, то всё это значит, что автоматически снимаются все проблемы с производительностью компьютера и количеством свободного места на жестком диске, ведь не требуется даже установка. Кроме того, отпадает необходимость платить довольно большие деньги сразу за продукт (игру и т.п.), который Вам не обязательно придется по душе. К тому, что, не секрет, что большинство игр не хочется проходить повторно, поэтому получается, что стоимость нескольких часов (или пусть даже нескольких дней) удовольствия — неоправданно высока. Куда удобней был бы вариант, при котором Вы платили бы только за то время, которое играете. Или же — Вы бы платили некую небольшую фиксированную сумму

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

Xbox Live Еще один, всем небезызвестный, игровой сервис, который также предоставляет богатую интернет-функциональность и имеет отношение к облачным технологиям. Суть сервиса в том, что обладатели приставок Xbox 360 и КПК на базе Windows Phone 7, могут играть друг с другом в компьютерные игры и общаться, а также покупать адд-оны и различный мультимедийный контент, в онлайн-магазине. Получается, сервис создает некую виртуальную вселенную для геймеров, компоненты которой расположены не на консолях конечных пользователей, а в облаке.

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

А поскольку нам, как пользователям, больше всего интересно именно программное обеспечение (а не всякие там платформы, как сервис), то сейчас мы и рассмотрим «программный ландшафт» (SaaS) облаков. Другими словами, давайте приведем наиболее популярные программные решения, которые сейчас существуют на рынке.

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

Именно по этому пути и пошли два хедлайнера ИТ-индустрии (а по совместительству еще и конкуренты) — Google и Microsoft. Обе компании выпустили наборы сервисов, позволяющих работать с документами.

Со стороны Google — это их Google Docs (ныне Google Диск):Бесплатный онлайн-офис, включающий в себя текстовый, табличный

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

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

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

Со стороны Microsoft — это их Microsoft Office Web Apps:Приложения Microsoft Office Web Apps, позволяют использовать

возможности Microsoft Office, через веб-браузер и работать с документами (причем, не только просматривать их, но и редактировать) непосредственно на веб-сайте, на котором они хранятся.

 

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

Также стоит отметить, что оба сервиса тесно взаимосвязаны с почтой (Gmail в первом случае и Hotmail во втором) и файловыми хранилищами, тобишь, чтобы воспользоваться Google Docs, достаточно завести бесплатный аккаунт гугл и Вы получите набор программ для работы с текстами, электронными таблицами и тп, прямо в браузере. Для многих, Google Docs полностью заменил, как уже и говорилось выше, платный MS Office.

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

Не менее популярны и облачные хранилища файлов. Самым известным хранилищем считается..

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

файлами для всех Ваших ПК и даже смартфонов. Самое интересное, что тут не придется делать никаких особых действий, ибо операционная система сама будет воспринимать общую папку, как и все остальные папки на винчестере, а дропбокс просто займется синхронизацией. Cервис позволяет бесплатно хранить до 2 Гб данных. Главный акцент в нем делается на синхронизации и обмене информацией. Dropbox ведёт историю загрузок, чтобы после удаления файлов с сервера была возможность восстановить данные, плюс ведётся история изменения файлов, которая доступна на период последних 30 дней.

Windows Live SkyDrive. Сервис SkyDrive позволяет сохранять до 7 ГБ (а обмен можно производить файлами до 100 МБ) информации в упорядоченном с помощью стандартных папок виде. Для изображений предусмотрен режим предпросмотра, а также возможность показать их в виде слайдов. Кроме того, что сервис интегрирован с Microsoft Office, он также поддерживает новую операционную систему Windows 8 (а точнее, клиент SkyDrive встроен в приложения Metro и позволяет загружать в «облако» документы и фотографии за один клик, открывать файлы из удаленного хранилища).

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

облачные технологии. Например, в стане борьбы с цифровой «нечистью» также сделали ставку на облачные вычисления. И вот результат — бесплатный антивирус Panda Cloud Antivirus.

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

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

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

Конечно, обычному пользователю пока сложно в полной мере оценить (и раскрыть) весь их потенциал, но то, что он есть, — видно невооруженным глазом. Таким образом, вне всякого сомнения, будущее облачных технологий представляется весьма радужным, ибо такие гиганты (Microsoft, Apple и Google) просто так уж точно ничего не делают и совершенно понятно, что если уж они зашли на эту неизведанную территорию, то явно не собираются с неё уходить, ведь еще два года назад концепция «облако» казалась лишь красивой идеей и смелым экспериментом, а сегодня преимущества облачных технологий могут почувствовать даже те люди, которые не связаны с разработкой программ, веб-технологиями и прочими узкоспециализированными вещами (вышеупомянутые Xbox Live, Windows Live, OnLive, Google Docs — яркие тому примеры).

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

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

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

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

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

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

Примерно такая же ситуация в музыке.Обычная технология: скачали или купили песню и слушаете. Файлы и

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

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

Что дают нам облачные технологии?Для предприятий плюс облачных технологий однозначно в том, что им

не нужно покупать своё серверное оборудование, строить локальную сеть, заботиться о её работоспособности, тратиться на модернизацию и на зарплату сисадминам.

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

А за работоспособность и безопасность отвечают те, кто предоставляет услугу «облака», за соответствующую плату от клиента.

Основной аудиторией для таких сервисов, скорее всего, будут корпоративные клиенты, заинтересованные в электронных системах документооборота, корпоративных почтовых ящиках и прочих виртуальных инструментов незаменимых в современном офисе. Обычным пользователям, скорее всего, еще надолго хватит бесплатных «облаков» — вроде того же Gmail от Google.

Где находится облако?Облачные технологии стали возможны благодаря бурному развитию

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

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

Самые известные «облачные» сервисы

Эти «облачные сервисы», можно разделить на три основные категории: инфраструктура как сервис платформа как сервис программное обеспечение как сервисЭто три кита, на которых строится понимание принципов работы

облаков, по сути «замещающих» для пользователей их собственную информационную инфраструктуру, или конкретную программно-аппаратную платформу, или ПО.

Windows Live SkyDrive Безусловный «номер один» по объему дискового пространства, бесплатно предоставляемого зарегистрированным пользователям — 25 Гбайт! Хранить можно файлы любых форматов, но некоторые получают дополнительные преимущества. Так, если это документы Office, то, с помощью интегрированных в SkyDrive Office Web Apps, их можно редактировать прямо в браузере, а установленный на компьютере Office 2010 позволяет сохранять и открывать документы непосредственно в SkyDrive.

Компания Microsoft запустила еще один «облачный» сервис Office 365. microsoft office 365 объединил веб-версии самых популярных офисных приложений Word, Excel и PowerPoint. Теперь все они работают в браузере. Этот пакет приложений платный, предназначен для использования как в малом бизнесе, так и на крупных предприятиях.

Dropbox - это более известный сервис, чем SkyDrive, хотя и уступающий ему по объему бесплатного дискового пространства — 2 Гбайт. С бесплатным тарифом можно использовать очень удобный клиент Dropbox, устанавливаемый на PC или смартфоны, который позволяет работать со своими данными, или получать доступ к файлам через web-интерфейс.

Поисковый гигант Google планирует в ближайшие недели серьезно потревожить нервы Dropbox, введя в строй свой новый проект — сервис Google Drive, который будет предназначен для облачного хранения пользовательских файлов.

Grooveshark – это один из самых популярных в мире музыкальных облачных сервисов.

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

картину, приведенного списка, наверное, хватит.

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

Облачные вычисления (англ. cloud computing) - технология распределённой обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как интернет-сервис. Предоставление пользователю Интернет-услуг – ключевое понятие. Под Интернет-сервисом стоит понимать не только доступ к сервису через Интернет, но и так же доступ через обычную сеть с использованием веб-технологий.

Из истории и определения видно, что основой создания и стремительного развития послужили крупные интернет сервисы, такие как Google, Amazon и др., а так же технический прогресс. Более подробно остановимся на влиянии программного и аппаратного развития.

Развитие многоядерных процессоров привело к увеличению производительности при тех же размерах оборудования, снижению стоимости оборудования, а как следствие эксплуатационных расходов, снижению энергопотребления облачной системы, что для большинства Центров Обработки Данных (ЦОД) является большой проблемой при наращивании мощностей. Увеличение емкостей носителей информации, и как следствие снижение стоимости хранения 1Мб информации привело к безграничному увеличению объемы хранимой информации, снижению стоимости обслуживания хранилищ информации при значительном увеличении объемов хранимых данных. Развитие технологии многопоточного программирования привело к эффективному использованию вычислительных ресурсов многопроцессорных систем, гибкому распределению вычислительных мощностей «облака». Развитие технологии виртуализации привело к возможности создания виртуальной инфраструктуры, гибкому масштабированию и наращиванию систем, снижению расходов на организацию и сопровождение систем, доступности виртуальной инфраструктуры через сеть Интернет. Увеличение пропускной способности сети привело к увеличению скорости обмена данными, снижению стоимости Интернет трафика, доступности облачных технологий. Все эти факторы привели к повышению конкурентоспособности облачных технологий в сфере Информационных Технологий.

Как и у любой технологии, облачные технологии имеют как свои достоинства, так и недостатки. К основным достоинствам можно отнести следующие:

Доступность – «облака» доступны всем и везде, где есть Интернет и с любого устройства, где есть браузер.

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

Гибкость – неограниченность вычислительных ресурсов (виртуализация).

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

Безопасность – высокий уровень безопасности при грамотной организации, однако, при халатном отношении эффект может быть противоположным.

Большие вычислительные мощности – пользователь может использовать все доступные в «облаке» вычислительные мощности.

При всех своих достоинствах облачные технологии имеют ряд серьезных недостатков:

Постоянное соединение с сетью – для работы с «облаком» необходимо постоянное подключение к сети.

Программное обеспечение – пользователю доступно только то программное обеспечение, которое есть в «облаке», а так же пользователь не может настраивать приложения под себя.

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

Надежность – потеря информации в «облаке» означает невозможность ее восстановления.

Безопасность – хотя «облако» является достаточно надежной системой, но в случае проникновения злоумышленника, ему будет доступен огромный объем данных.

Дороговизна оборудования – для создания своего «облака» необходимы значительные материальные ресурсы.

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

Все как услуга (Everything as a Service) – при таком подходе пользователю будет доступно все от программно аппаратной части до управления бизнес процессами, включая взаимодействие между пользователями. Все что требуется от пользователя – это доступ в сеть Интернет.

Инфраструктура как услуга (Infrastructure as a Service) – пользователю доступна только компьютерная инфраструктура (как правило, виртуальные платформы, связанные в сеть), которую он сам настраивает под свои нужды.

Платформа как услуга (Platform as a Service) – пользователю доступна компьютерная платформа с установленной операционной системой и, возможно, программным обеспечением.

Программное обеспечение как услуга (Software as a Service) – пользователю доступно программное обеспечение, развернутое на удаленных серверах, доступ к которому осуществляется через сеть Интернет. Такой вид услуги подразумевает оплату только лишь за фактическое пользование программным обеспечением, а все вопросы по лицензированию и обновлению программного обеспечения лежат на поставщике данной услуги.

Аппаратное обеспечение как услуга (Software as a Service) – пользователю предоставляется оборудование на правах аренды, которое он может использовать в своих целях. Данный вид услуги очень похож на услуги «Инфраструктура как сервис» и «Платформа как сервис», за исключением того, что пользователь имеет доступ только лишь к оборудованию, на которое он сам устанавливает все программное обеспечение.

Рабочее место как услуга (Workplace as a Service) – компания организует рабочие места для своих сотрудников, устанавливая и настраивая все необходимое программное обеспечение.

Данные как услуга (Data as a Service) – пользователю предоставляется дисковое пространство для хранения информации.

Безопасность как услуга (Security as a Service) – позволяет пользователям развертывать продукты, обеспечивающие безопасность веб-технологий, переписки, локальной системы.

Облачные сервисы, предоставляющие те или иные виды услуг, в свою очередь делятся на три категории: публичные, частные и гибридные.

Публичное «облако» - ИТ-инфраструктура, которую используют множество компаний и сервисов. Пользователи при этом не могут управлять и обслуживать данное «облако», вся ответственность по этим вопросам лежит на владельце «облака». Абонентом может стать любая компания, а так же любой индивидуальный пользователь. «Облака» такого типа предлагают легкий и доступный в цене способ развертывания веб-сайтов или бизнес-систем с большими возможностями масштабирования, которые не доступны в «облаках» других типов. Примеры: онлайн сервисы Amazon EC2 и Simple Storage Service (S3), Google Apps/Docs, Salesforce.com, Microsoft Office Web.

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

Гибридное «облако» - ИТ-инфраструктура, использующая лучшие стороны публичного и частного типов «облаков». Такой тип в основном

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

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

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

Облачные технологии развиваются стремительно и охватывают все больше и больше сфер деятельности. Например, почтовые клиенты. Ещё недавно у большинства пользователей был установлен тот или иной почтовый клиент приёма, отправки и обработки электронной почты, сейчас роль почтового клиента выполняет Gmail, а в качестве гибких и удобных альтернатив такие сервисы как Yahoomail, Webmail, Hotmail и другие. Более того, в последнее время среди достаточно крупных мировых порталов наметилась тенденция по переносу почтовых систем на готовые площадки вроде Gmail. В данном случае пользователь изначально получает знакомый ему интерфейс.

Похожая ситуация наблюдается и с офисными пакетами. Онлайн редакторы Zoho Writer или Документы Google могут выполнять те же самые функции, что и обычные офисные пакеты, более того, многие такие редакторы не только могут форматировать и сохранять документы, но и импортировать и экспортировать их в другие форматы. Табличные редакторы Editgrid или Google могут легко заменить Exel. И это далеко не полный список всех доступных сервисов, доступных всем тем, у кого есть доступ к сети Интернет.

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

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

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

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

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

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

За что мы платим, пользуясь облачными технологиями?Каждый хочет знать за что взимается плата, в случае с оплатой

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

обязательная абонентская плата за пользование аппаратными ресурсами (серверами, дата-центрами, ЦОДами), называется данная облачная модель IaaS;

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

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

Облачная технология это сервис?Безусловно, облачная технология обладает всеми признаками сервиса: взимается абонентская плата; компьютерная инфраструктура принадлежит облачному

провайдеру;

программное обеспечение при использовании облачной модели PaaS или SaaS также принадлежит компании, оказывающей облачные услуги;

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

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

облачный провайдер обеспечивает полную (бесплатную) техническую поддержку 24/7;

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

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

Для бизнеса или для частного использованияОблачные технологии развиваются в обоих направлениях. Нельзя

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

Уже был приведен пример с облачными технологиями "Google" в виде почтового сервиса "Gmail" и сервиса "Яндекса" — "Яндекс.Музыка." Данные примеры достаточно наглядно отображают удобство для обычного человека независимо от пола и вероисповедания.

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

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

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

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

осуществлении масштабируемости или, особенно, при восстановлении работоспособности облака, в следствии случайно поломки аппаратной инфраструктуры;

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

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

Большинство сервис-провайдеров предлагают облачные вычисления в форме VPS-хостинга, виртуального хостинга, и ПО-как-услуга(SaaS). Облачные услуги долгое время предоставлялись в форме SaaS, например, Microsoft Hosted Exchange и SharePoint.

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

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

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

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

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

предоставление услуг, когда пользователи могут производить оплату по факту и регулировать объем своих ресурсов в зависимости от реальных потребностей без долгосрочных обязательств Булусов А. ИТ-руководители пока избегают «облачных» технологий. //CNews 21 апреля 2010 г..

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

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

По мнению Parallels, в ближайшие 5-10 лет большая часть ИТ переместится в облака пяти различных типов. Будут проприетарные платформенные облака, предоставляющие различные платформенные услуги, - Google (тип 1), Microsoft (тип 2) и другие крупные ИТ игроки (тип 3), такие как IBM, Apple, HP и Amazon.

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

Платформенные облака* Тип1: Облако Google* Тип2: Облако Microsoft* Тип3: Другие облака(например, IBM и Apple -- Amazon, Facebook,

Adobe и другие)Облака услуг* Тип4: Облака сервис-провайдеров -- операторы связи, веб-хостеры,

ISV, SaaS* Тип5: Внутренние облака крупных компаний (Fortune 1000)При сегодняшнем уровне конкуренции на рынке ИТ залогом успеха

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

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

ЗаключениеНа данный момент идет активная разработка и совершенствование

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

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

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

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