0 - 1

Лекция 1
Экономическая информация и информационные ресурсы
При изучении определенной проблемы исходят из базового набора
понятий, составляющего конструкцию содержания проблемы. В комплексе
задач создания и эксплуатации АИС в сфере экономики очень важно
определить базовые понятия: информация, данные, экономическая
информация, информационный ресурс экономики и др.
В общепринятом смысле понятие «информация» (от лат. informatiоп разъяснение, изложение) - это сведения, передаваемые людьми устным,
письменным или другим способом. Со временем появляются новые
определения понятия. С позиций кибернетики, информация - обмен
сведениями между людьми, человеком и автоматом, автоматом и автоматом,
обмен сигналами в животном и растительном мире, передача признаков от
клетки к клетке, от организма к организму. Насчитывается несколько сотен
определений понятия «информация». Каждое определение формируется в
зависимости от конкретных условий применения этого понятия. Постепенно
слово «информация» превратилось в общенаучное. В настоящее время оно
воспринимается как универсальная категория, как материя и энергия,
пространство и времени. Информация существует во времени и
пространстве, может передаваться между поколениями через века и
тысячелетия.
Отличительная черта информации - ее способность подвергаться
обработке в соответствии с потребностями человека, задачами специалиста.
Подавляющая масса информации собирается, передается и обрабатывается с
помощью знаков. Знаки - это сигналы, которые могут передавать
информацию при наличии соглашения об их смысловом содержании между
источниками и приемниками информации. Набор знаков, для которых
существует указанное соглашение, называется знаковой системой. Многие
знаковые системы, естественно, нельзя четко ограничить. Однако при
обработке данных на ЭВМ наличие точного перечня знаков и логикоарифметических правил обязательно.
Таким образом, в сфере социальной коммуникации проявляется не
только технологический, но и логический аспект переработки данных.
Информация - это результат логической переработки данных, который
используется людьми в общественно-исторической практике путем
применения различных форм, методов и средств. Информация может быть
представлена в различных формах. Это могут быть, например, звуковые
волны, алфавиты, радиоволны, электроимпульсы, светосигналы и др.
Среди методов можно указать, в частности, сравнение, анализ, синтез,
классификацию, индукцию, формализацию, моделирование и др. Если
говорить о средствах, то можно назвать речь, письмо, ЭВМ, сети ЭВМ и др.
Данные - это сведения об объектах реального мира, представленные в
регламентной
форме.
Форма
представления
данных
может
регламентироваться приказами, стандартами, инструкциями, другими
нормативными документами соответствующей управляющей системы.
Сведения - это характеристики, признаки, свойства объектов. В
методологическом отношении объекты реального мира - предметы и явления
(процессы) - воспринимаются через проявляемые ими свойства.
Информация, данные и сведения обладают функциональным свойством
отображения объектов реального мира. Но в определенных условиях
управления целесообразно различать эти понятия. Например, в филиале
предприятия собираются сведения по результатам производственной
деятельности. Затем эти сведения, в соответствии с регламентом,
оформляются документально в данные о филиале и передаются на головное
предприятие. Специалисты предприятия проводят логическую переработку
данных по всем филиалам. Затем на основе полученной информации
руководители принимают решение по управлению предприятием в целом и
конкретным филиалом, в частности. Рациональное решение по управлению
предприятием базируется на анализе достоверной, полной и своевременной
информации.
Информация применяется во всех сферах общественной практики.
Одна из таких значительных областей - экономика. Экономическая
информация создастся в результате экономической деятельности. Она
отображает экономические объекты и хозяйственные процессы, которые
происходят на этих объектах - предприятиях, фабриках, банках и др. Вместе
с тем сфера ее применения выходит за рамки экономики в силу
межотраслевого информационного обмена. В то же время на экономических
объектах может генерироваться и применяться информация, не являющаяся
экономической в строгом смысле этого слова, Например научная,
техническая, юридическая и др.
Путем классификации можно выделить свойства экономическо
информации (табл. 1).
Таблица 1.
Классификация экономической информации
Основание деления
Получаемые классы информации
Область создания
Управление, производство, статистический учет,
бухгалтерский учет, финансовая деятельность,
кредитная
деятельность,
налогообложение,
индустрия сервиса и др.
Масштаб действия
Местная,
региональная,
национальная,
континентальная, мировая
Уровень
управления Подразделение. предприятие,
объединение,
экономическими
отрасль. государство, содружество государств
объектами
Функции управления
Прогнозная, плановая, учетная, контрольная,
аналитическая и др.
Материальный носитель Папирус, пергамент, бумага, ткань, стекло,
Уровень достоверности
Уровень полноты
Уровень
своевременности
Уровень доступности
Уровень агрегируемости
Основание деления
Характер отображения
Форма движения
Уровень
технических
средств создания и (или)
использования
Вид процесса
Восприятие
органами
чувств
Средство
отображения
текста
Степень распространения
Адресат
Средства
распространения
пластик, пленка, интегральные среды и др.
Достоверная, недостоверная
Полная, неполная
Преждевременная,
своевременная,
несвоевременная
Открытая, ограниченного доступа, закрытая
(секретная)
Элементарная,
группировочная,
сводная,
комплексная
Получаемые классы информации
Документальная,
фактографическая,
комбинированная
Ассимиляция, документирование, коммуникация
Полученная
с
помощью:
ручных
(традиционные),
механизированных,
автоматизированных,
автоматических,
комбинированных средств
Сбор, регистрация, передача, анализ, синтез,
редукция
реферирование
предметизация
классификация, индексирование кодирование
шифрование, ввод в ЭВМ обработка, поиск
верификация,
хранение,
актуализация,
корректировка, копирование, тиражирование,
вывод отображение и др.
Визуальная (зрительная), аудиальная (слуховая),
комбинированная
Буквенная,
цифровая,
графическая,
комбинированная
Публикуемая, непубликуемая
Массовая, специальная
Печать радио телевидение локальные сети,
глобальные сети, специальные каналы
Каждый из указанных классов может быть подвергнут дальнейшей
детализации. Данная таблица не исчерпывает всех классификационных
признаков и соответствующих классов экономической информации. Она
лишь демонстрирует возможный порядок деления системы экономической
информации по выбираемым основаниям деления. В соответствии с
выделенными в таблице признаками можно определить понятие
«экономическая информация». Экономическая информация - это вид
информации, отображающей состояние экономических объектов и
происходящие в них хозяйственные процессы.
По своим свойствам экономическая информация – своеобразный
ресурс экономической деятельности. На се основе реализуется комплекс
задач и функций экономических объектов. Вместе с тем экономическая
информация в силу межотраслевого ее характера широко применяется и в
других сферах общественно-полезной деятельности. Экономическая
информация - неотъемлемая часть информационного ресурса экономики
всего общества. Информационный ресурс экономики - это система
сведений,
данных,
знаний,
сгенерированных
в
процессе
общественноисторической практики людей и используемых в экономической
деятельности. Следует отмстить, что экономическая информация занимает в
информационном ресурсе общества значительное место в силу не только
своего объема, но и содержательной значимости.
Среди существенных характеристик экономической информации,
указанных в табл. 1, можно отметить такое ее свойство как «форма
движения». Ассимиляция экономической информации характерна тем, что на
определенном этапе решения какой-либо экономической задачи в сознании
человека проявляется совокупность новых сведений, которые он
сопоставляет с системой собственных представлений, понятий, установок и
оценок. В результате такого сопоставления происходит ассимиляция новой
информации с ранее приобретенной человеком информацией. Происходит
обновление знаний человека об экономическом объекте или процессе.
Ассимиляция не распространяется далее сознания человека. В дальнейшей
деятельности человек может эту обновленную информацию осмыслить,
структурировать и оформить (зарегистрировать) в виде текста средствами
определенной
знаковой
системы,
то
есть
документировать.
Документированная форма движения экономической информации способна
выполнять процессы передачи информации от человека к человеку, но не
всегда и не везде это имеет место. Более развитая третья форма движения
информации
проявляется
тогда,
когда
документ,
содержащий
ассимилированную информацию, будет введен в каналы социальной
коммуникации. Это могут быть, например, публикация статистического
ежегодника в открытой печати, ввод экономического документа в сеть ЭВМ
и др. В данном случае экономическая информация становится доступной
широкому кругу специалистов.
АИС в управлении экономикой
ИС существовали с момента появления общества, поскольку на любой
стадии развития общество нуждается в координации процессов,
выполняемых на основе обмена сведениями и управления ими. Особенно это
касается производственных процессов - процессов, связанных с
производством материальных благ, так как они жизненно важны для
развития общества. Именно производственные процессы совершенствуются
наиболее динамично. А по мере их развития усложняется и управление ими,
что, в свою очередь, стимулирует совершенствование и развитие
информационных систем как наиболее эффективного инструмента для
передачи сообщений между участниками производства.
Для того чтобы понять, что же такое экономическая
автоматизированная информационная система, необходимо прежде всего
определить ее место в системе управления экономическим объектом.
Потребность в управлении возникает в том случае, когда необходима
координация действий членов некоторого производственного коллектива,
объединенных для достижения общих целей. Такими целями могут быть:
обеспечение устойчивости функционирования или выживания объекта
управления в конкурентной борьбе, получение максимальной прибыли,
выход на международный рынок и т.д. Цели сначала носят обобщенный
характер, а затем, в процессе уточнения, они формализуются управленческим
аппаратом в виде целевых функций. Координация действий по достижению
целей базируется на системе обмена информацией между участниками
производства. Система информационного обмена включает в себя
определенные процедуры, в частности регистрацию, обработку, поиск
информации и др.
В соответствии с кибернетическим подходом система управления
представляет собой совокупность объекта управления, например
предприятие, и субъекта управления - управленческого аппарата. Аппарат
объединяет в себе сотрудников, формирующих цели, перерабатывающих
информацию, вырабатывающих и принимающих решения, а также
контролирующих их выполнение. Роль АИС в контуре управления
экономическими объектами состоит в том, чтобы осуществить подготовку,
обработку и выдачу информации операторам управления - руководителям и
специалистам (рис. 1).
Рис.1. АИС в контуре системы управления экономическим объектом
ПС- прямая связь, ОС – обратная связь
В задачу объекта управления входят прием директивной информации,
выполнение планов, выработанных управленческим аппаратом, т.е.
реализация той деятельности, для которой создавалась система управления, а
также представление данных о состоянии выполнения планов.
Оба компонента системы управления связаны прямой и обратной
связями. Прямая связь выражается потоком директивной информации,
направляемой от управленческого аппарата к объекту управления. Обратная
связь представляет собой поток отчетной информации о выполнении
принятых решений, направляемых в обратном направлении. Указанные виды
связей в системе управления существуют между субъектом и объектом
управления напрямую, а также через АИС. В этом случае связь
осуществляется в части решения задач по передаче и обработке информации.
Директивная информация порождается управленческим аппаратом в
соответствии с целями управления и информацией о сложившейся
экономической ситуации, об окружающей среде. Отчетная информация
формируется объектом управления и отражает внутреннюю экономическую
ситуацию, а также степень влияния на нее внешней среды (задержки
платежей,
нарушения
подачи
энергии,
погодные
условия,
общественнополитическая ситуация в регионе и т.д.). Таким образом,
внешняя среда влияет не только на объект управления, но и поставляет
информацию управленческому аппарату решения которого зависят от
внешних факторов (состояния рынка, наличия конкуренции, величины
процентных ставок, уровня инфляции, налоговой и таможенной политики).
Взаимосвязь источника информации - аппарата управления, приемника
информации - предприятия, а также каналов передачи информации между
источником и приемником информации (прямая и обратная связи) и
составляют ИС экономического объекта.
Возрастание объемов информации в контуре управления, усложнение
ее обработки повлекло за собой сначала внедрение компьютеров на
отдельных операциях, а затем расширение их применения. Традиционная ИС
стала качественно меняться. В управленческом аппарате появилось новое
структурное подразделение, единственной функцией которого стало
обеспечение процесса управления информацией на основе применения
средств вычислительной техники. В связи с этим в контуре управления
появились новые информационные потоки, а старые потоки частично
изменили свое направление. Часть традиционной ИС стала постепенно, но
неуклонно трансформироваться в направлении все большей автоматизации
обработки информации. С учетом сферы применения выделяются:
технические ИС;
экономические ИС;
ИС в гуманитарных областях и др.
Так как далее речь будет идти об ИС экономического характера,
необходимо ввести понятие АИС в области экономики. АИС в экономике это совокупность методов и средств информационного, технического,
программно-математического и организационно-правового характера,
предназначенная для информационного обеспечения решения экономических
задач. Таким образом, можно обозначить отраслевой вид АИС экономическая автоматизированная информационная система (ЭАИС). С
помощью ЭАИС, к сожалению, может перерабатываться далеко не вся
информация, используемая для управления экономическим объектом,
поскольку на предприятиях циркулируют огромные информационные
потоки, играющие важную роль в принятии решений, обработка которых в
их полном объеме с помощью компьютеров невозможна. Причин здесь
несколько:
сложность структуризации информации и формализации процессов ее
переработки;
недостаточное количество вычислительных устройств (пар ка ЭВМ);
отсутствие экономической целесообразности и др.
В АИС от объекта управления направляется только та часть
информации, которую можно систематизировать и обрабатывать с помощью
компьютера. Аналогично от управленческого аппарата в АИС передается
лишь часть директивной информации, которая может быть соответствующим
образом переработана и передана объекту управления. По отношению к
общему объему информации доля информации, обрабатываемой в АИС, для
различных уровней управления колеблется от 10 до 20 %. В процессе
управления принимаются решения трех категорий: стратегические,
тактические и оперативные. В соответствии с этой классификацией
управленческий аппарат обычно имеет трехуровневую иерархию: высший,
средний и оперативный уровни.
Высший уровень (высшее руководство) определяет цели управления,
внешнюю политику, материальные, финансовые и трудовые ресурсы,
разрабатывает долгосрочные планы и стратегию их выполнения. В его
компетенцию входят анализ рынка, конкуренции, конъюнктуры и поиск
альтернативных стратегий развития предприятия на случай выявления
угрожающих тенденций в сфере его интересов.
На среднем уровне основное внимание сосредоточено на составлении
тактических планов, контроле над их выполнением, слежении за ресурсами и
разработке управляющих директив для вывода предприятия на требуемый
планами уровень.
На оперативном уровне происходит реализация планов и составляются
отчеты о ходе их выполнения. Руководство здесь состоит, как правило, из
работников, обеспечивающих управление цехами, участками, сменами,
отделами, службами. Основная задача оперативного управления заключается
в согласовании всех элементов производственного процесса во времени и
пространстве с необходимой степенью его детализации.
Процедурную
базу
АИС
составляют
автоматизированные
информационные технологии. Автоматизированная информационная
технология - это совокупность технических и программных средств,
предназначенная для реализации процессов обработки данных. Таким
образом, АИТ априори как бы базовая компонента (часть) АИС относительно
ее функции преобразования данных. Однако она не может полностью
подменить собой структуру и функции АИС. В АИТ отсутствуют некоторые
структурные компоненты АИС, без которых функционирование системы
невозможно, например технологический персонал, БД, комплект
инструктивной документации, ресурсы и др. Вместе с тем, основные
направления развития АИС, например расширение функций, реорганизация
структуры, улучшение функциональных и экономических показателей, в
значительной мере обусловливается уровнем применяемой технологии.
АИС обеспечивают решение экономических задач и тем самым
включаются в ПрО экономики. Предметная область экономики в
контексте АИС - это совокупность сведений о структуре, процессах и
свойствах экономических объектов и АИС, способах взаимосвязи и
процессах взаимодействия между ними. ПрО в значительной мере
определяет специфику решения задач построения и функционирования АИС.
Обобщенное понимание ПрО можно представить как совокупность объектов,
процессов, их количественных и качественных характеристик, а также связей
между ними, объединенных общей идеей, определенным смыслом или
понятием более высокого уровня. Эта область может быть описана в виде
некоторой
совокупности
сведений
о
ее
структуре,
основных
характеристиках, процессах, протекающих в ней, а также способов решения
задач. Значительная роль в ПрО принадлежит отношениям между объектами.
Именно они определяют смысловую сторону, окончательно формируют
конкретную ПрО путем выделения ее из других областей или случайного
скопления фактов. Упорядоченная и систематизированная совокупность
знаний образует модель ПрО.
Функционирование АИС основано на ТПОД. Эффективность АИС во
многом определяется качеством построения и функционирования ТПОД. С
целью дальнейшего рассмотрения конкретизируем определения основных
категорий ТПОД. Технологический процесс обработки данных - это
совокупность методов и средств, организованных в логическую
последовательность этапов обработки и выдачи информации пользователю
для решения экономических задач. Этап ТПОД - это совокупность
взаимосвязанных процедур, реализующих определенную функцию
технологического процесса.
Процедура ТПОД - это совокупность технологических операций,
обеспечивающая реализацию логической части этапа технологического
процесса обработки данных. Операция ТПОД - это элементарное действие,
обеспечивающее промежуточный логический результат процедуры
технологического процесса обработки данных. Технологический процесс
состоит из этапов. Процедурой может быть распечатка отдельного документа
на принтере среди множества других результатных документов, просмотр
промежуточных документов, уточнение содержания буфера обмена и др.
Процедура реализуется посредством набора операций обработки. Примером
операции может быть нажатие клавиши «ввод» на клавиатуре, которое
идентифицируется как команда на начало поиска или вывода найденного
файла на экран.
Процедуры преобразования данных имеют арифметическую и
логическую основы. Арифметическую основу составляют операции
сложения, вычитания, умножения и деления. Логические условия работы
ЭВМ и алгоритма обработки определяются в соответствии с
аксиоматическим аппаратом алгебры логики. Этот аппарат сформулировал
английский математик Дж. Буль (отсюда название - булева алгебра).
Следует отметить, что каждый этап ТПОД реализует определенную
функцию АИС, в частности регистрацию, сбор, передачу, ввод в ЭВМ,
обработку, поиск, хранение, актуализацию, корректировку, вывод,
отображение, копирование, тиражирование и др. Эти этапы взаимоувязаны
между собой в логическую последовательность. Коротко поясним каждую из
указанных функций. Регистрация данных - фиксирование сведений на
материальный носитель. Сбор данных - процесс получения сведений от
источников информации. Передача данных - процесс перенесения сведений
от источника к получателю. Ввод данных в ЭВМ - процесс перевода сведений
в память ЭВМ. Обработка данных - совокупность логических и
арифметических операций по преобразованию данных в информацию,
обеспечивающую решение задачи пользователя.
Поиск данных - совокупность логических операций по отбору
необходимых сведений из БД по запросу пользователя. Хранение данных размещение сведений на материальном носителе и поддержание их в
работоспособном состоянии. Актуализация данных - процесс обновления
сведений путем добавления в единицу информации вновь полученных
данных. Корректировка данных - процесс исправления ошибочных сведений
в определенной единице информации. Вывод данных из ЭВМ - процесс
перемещения данных из памяти ЭВМ на устройства представления данных,
находящиеся вне ЭВМ. Отображение данных - процесс представления
сведений в удобной для восприятия человеком форме. Копирование данных операция по идентичному воспроизведению данных. Тиражирование данных
- процесс воспроизведения данных в определенном количестве идентичных
экземпляров.
ТПОД в значительной мере определяется характером АИС и
соответствующим объектом управления. Современные технологии обработки
данных представляют довольно широкий типологический ряд. По уровню
открытости архитектуры технологии можно дифференцировать на замкнутые
и сетевые. Сетевые технологии можно разделить на локальные и открытые.
По характеру обрабатываемой информации технологии можно разделить на
текстовые, табличные и графические. По логическому уровню обработки
информации они подразделяются на технологии обработки данных,
технологии поиска данных, технологии преобразования данных, технологии
интеллектуальных систем. Возьмем несколько оснований деления и выделим
классы технологических процессов (табл. 2).
Таблица 2
Основные схемы технологического процесса обработки данных
АИС
Получаемые схемы технологического процесса
Основание деления
обработки данных
Обработка данных по Один показатель (например объем производства),
количеству
набор показателей(например стоимость основных
контролируемых
фондов стоимость ценных бумаг, фонд заработной
показателей объекта
платы и др.), полный состав показателей объекта
Один участок (например сборочный цех), несколько
Обработка данных по
участков (например бухгалтерия снабжение и сбыт,
количеству
планирование), полный состав подразделений
контролируемых
(звеньев)
объекта(например
комплексная
участков
(звеньев)
автоматизированная
корпоративная
объекта
информационная система)
Производство, подготовка производства, снабжение
Контролируемые
и
сбыт,
маркетинг,
трудовые
ресурсы,
подсистемы объекта
документооборот, сектор управления предприятием
и др.
Режимы
обработки
Пакетный, мультипрограммный, интерактивный
данных
Масштаб
Локальная ЭВМ, сеть подразделения, сеть фирмы,
технологического
отраслевая сеть, региональная сеть, национальная
процесса
сеть, континентальная сеть, глобальная сеть
Характер выдаваемой
Текстовый, изобразительный, комбинированный
информации
Периодичность выдачи Ежедневно,
еженедельно,
ежемесячно,
информации
ежеквартально, ежегодно
Путем сочетания выделенных классов можно строить различные схемы
технологических процессов обработки данных от простых до сложных. Так,
например, можно в глобальной сети выдавать ежедневно в интерактивном
режиме комбинированную информацию об объекте по любому набору
показателей деятельности предприятия.
Лекция 2
Распределенная обработка данных
При размещении БД на персональном компьютере, который не
находится в сети, БД всегда используется в монопольном режиме. Даже если
БД используют несколько пользователей, они могут работать с ней только
последовательно, и поэтому вопросов о поддержании корректной
модификации БД в этом случае здесь не стоит, они решаются
организационными мерами — то есть определением требуемой
последовательности работы конкретных пользователей с соответствующей
БД. Однако даже в некоторых настольных БД требуется учитывать
последовательность изменения данных при обработке, чтобы получить
корректный результат: так, например, при запуске программы балансного
бухгалтерского отчета все бухгалтерские проводки — финансовые операции
должны быть решены заранее до запуска конечного приложения.
Однако работа на изолированном компьютере с небольшой базой
данных в настоящий момент становится уже нехарактерной для большинства
приложений. БД отражает информационную модель реальной предметной
области, она растет по объему и резко увеличивается количество задач,
решаемых с ее использованием, и в соответствии с этим увеличивается
количество приложений, работающих с единой базой данных. Компьютеры
объединяются в локальные сети, и необходимость распределения
приложений, работающих с единой базой данных по сети, является
несомненной.
Действительно, даже когда вы строите БД для небольшой торговой
фирмы, у вас появляется ряд специфических пользователей БД, которые
имеют свои бизнес-функции и территориально могут находиться в разных
помещениях, но все они должны работать с единой информационной
моделью организации, то есть с единой базой данных.
Параллельный доступ к одной БД нескольких пользователей, в том
случае если БД расположена на одной машине, соответствует режиму
распределенного доступа к централизованной БД. (Такие системы
называются системами распределенной обработки данных.)
Если же БД распределена по нескольким компьютерам,
расположенным в сети, и к ней возможен параллельный доступ нескольких
пользователей, то мы имеем дело с параллельным доступом к
распределенной БД. Подобные системы называются системами
распределенных баз данных. В общем случае режимы использования БД
можно представить в следующем виде (см. рис. 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), который поддерживается
большинством поставщиков СУБД.
Лекция 3
Модели серверов баз данных
В период создания первых СУБД технология «клиент-сервер» только
зарождалась. Поэтому изначально в архитектуре систем не было адекватного
механизма организации взаимодействия процессов типа «клиент» и
процессов типа «сервер». В современных же СУБД он является фактически
основополагающим и от эффективности его реализации зависит
эффективность работы системы в целом.
Рассмотрим эволюцию типов организации подобных механизмов. В
основном этот механизм определяется структурой реализации серверных
процессов, и часто он называется архитектурой сервера баз данных.
Первоначально, как мы уже отмечали, существовала модель, когда
управление данными (функция сервера) и взаимодействие с пользователем
были совмещены в одной программе. Это можно назвать нулевым этапом
развития серверов БД.
Затем функции управления данными были выделены в
самостоятельную группу — сервер, однако модель взаимодействия
пользователя с сервером соответствовала парадигме «один-к-одному» (рис.
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.
Лекция 4
КЛАССИФИКАЦИЯ РАСПРЕДЕЛЕННЫХ СИСТЕМ.
Централизация и децентрализация.
Новые возможности, предоставляемые распределенной обработкой
данных, поставили перед администраторами, ответственными за обработку
информации, много сложных проблем. Какие функции должны быть
централизованы, а какие децентрализованы? Где должны храниться данные?
Какая конфигурация больших машин и персональных компьютеров окажется
наилучшей для обслуживания заказчика?
При проектировании систем необходимо учитывать три технических
аспекта – это данные, их обработка и механизмы управления этой
обработкой.
Но
помимо
технических,
приходится
учитывать
психологические, социальные и другие аспекты. Должно ли прикладное
программирование вестись централизованно или периферийными группами?
Должно ли общее руководство ходом разработки быть централизованным
или распределенным? Какие стандарты следует принимать централизованно?
Высокая степень централизации аппаратуры обычно увеличивает ее
стоимость. Но хорошо известно, что платить приходится не только за
аппаратуру. Существует множество различных аргументов, как <за>, так и
<против> централизации. И зачастую совсем не технические аргументы
оказываются решающими.
Важно отметить, что современный уровень технологии предоставляет
разработчику системы возможность выбора. Распределенная обработка
позволяет строить системы, в которых гибко сочетаются достоинства как
централизации, так и децентрализации.
В принципе аргументы <за> и <против> распределенной обработки в
некоторой конкретной системе распадаются на три группы, касающиеся
обработки, данных и механизмов управления. Каждая из этих групп требует
особого рассмотрения. Могут быть аргументы <за> централизацию одних
данных и рассредоточение других, причем они могут не совпадать с
аргументами в пользу распределения собственно обработки. Наконец, в
системе может быть в большой степени территориально рассредоточена
обработка, а общие механизмы управления локализованы.
Компьютерные сети могут иметь как централизованные механизмы
управления, так и рассредоточенные. В случае полной централизации
управления при выходе из строя центра становится неработоспособной вся
сеть. Распределенное управление предполагает, что с выходом из строя
любой части сети оставшаяся часть продолжает функционировать.
Надежность централизованной системы можно повысить, предусмотрев
несколько компьютеров в одном центре, готовых взять на себя функции
управления.
На практике мы сталкиваемся и с централизованным, и с
распределенным управлением, но чаще - с их комбинацией. В городе,
например, принято в основном распределенное управление. Некоторые
функции централизованы в мэрии, но город будет продолжать жить, если
мэрия окажется разрушенной. В человеческом организме большинство
жизненно важных функций централизовано. Он устойчив по отношению ко
многим травмам, но умирает при нарушении мозговой или сердечной
деятельности. Функционирование машинных сетей точно так же зависит от
работоспособности определенных критических компонентов. По мере того
как на сети будет возлагаться все большее число жизненно важных функций,
все большее значение начнет придаваться устойчивым к отказам механизмам
управления.
Если соединенные линиями связи процессоры территориально удалены
друг от друга, то перерабатываемые ими данные также могли бы быть
распределенными. Однако ограничения на размещение данных и размещение
процессоров различны. Во многих системах именно структура данных и
характер их использования обусловливают размещение процессоров.
Данные могут храниться двумя способами - непосредственно в виде
файлов или в базах данных. Файлы обычно создаются для работы с одной
прикладной задачей или группой связанных задач. База данных - это
хранящаяся в независимом от приложений виде совокупность данных, из
которой может быть порождено с помощью программного обеспечения
множество
различных записей. Использование БД дает большие
преимущества, однако их ПО весьма сложно и обычно устойчиво работает с
данными, сосредоточенными в одном месте. Распределенные данные
поэтому часто организуются в форме файлов.
Соображения, определяющие экономическую эффективность, для
систем хранения данных и для процессоров различны. Стоимость хранения
бита информации в памяти большего объема много ниже, чем в памяти
малого объема. Однако часто вовсе не стоимость хранения бита информации
определяет централизованную или децентрализованную форму хранения
данных. Централизация или децентрализация, как правило, диктуется
существом самих хранимых данных. Данные централизуются, если:
файл непрерывно обновляется, а территориально разобщенные
пользователи должны получать всякий раз последнее состояние данных
(как в файле резервирования авиабилетов);
поиск производится во всей совокупности данных;
над данными осуществляются операции со вторичными ключами.
Данные могут быть децентрализованными, если они используются
локально в точке их происхождения.
При низкой скорости обновления или при автономном обновлении (online) допустимо хранение нескольких копий одних и тех же данных в разных
местах.
Классификация распределенных систем по способам распределения
данных
Существует несколько типов систем, различающихся по характеру
распределения данных и их использованию (рис. 1). Приведенные на
рисунке схемы применимы к файловым системам, к базам данных или к их
комбинации.
На первых двух схемах показаны системы с централизованными
данными. При наличии нескольких управляющих машин они могут либо
находиться в том же месте, где размещены и данные, либо быть удалены от
них.
Следующие две схемы отображают иерархические системы. В схеме
иерархии зависимых данных данные в машинах нижнего уровня тесно
связаны с данными в машине верхнего уровня. Зачастую они могут быть
подмножествами данных верхнего уровня, используемыми в локальных
приложениях. Эталонная копия данных при этом может храниться на
верхнем уровне. При внесении изменений в данные на нижнем уровне эти
изменения должны передаваться в машину верхнего уровня - иногда
немедленно, иногда позднее, в цикле обновления. В других системах такого
типа нижний уровень может содержать те же данные, что и верхний, и еще
свои собственные, которые никогда не передаются наверх. Например, на
нижнем уровне могут храниться адреса клиентов и более детальная
информация о них. Эти данные, занимающие большой объем, обычно не
требуются на верхнем уровне. Верхний же уровень может хранить номера
клиентов, их имена, сведения о кредитах и заказах. Это - избыточная
информация. Она повторяется на обоих уровнях, и любая ее модификация
на нижнем уровне должна передаваться на верхний.
В схеме иерархии независимых данных все процессоры представляют
собой независимые замкнутые системы обработки данных. Структура
данных на машинах нижнего уровня сильно отличается от их структуры на
верхнем уровне. Наиболее распространенным примером отношений такого
вида могут служить системы, в которых нижние уровни предназначены для
рутинных повторяющихся (массовых) операций: приема заказов, контроля за
выпуском продукции, управления складом и т. п.
В машине верхнего уровня, расположенной, возможно, при главном
управлении предприятием, находится информационная система, которая
должна снабжать необходимой информацией руководство, планирующие
подразделения, отделы прогнозирования, разработчиков новых изделий и
стратегий. Все данные могут быть извлечены из нижних уровней, но они
суммируются, редактируются, реорганизуются с помощью вторичных
индексов или иных методов поиска, чтобы обеспечить ответы на
разнообразные, часто заранее непредвиденные вопросы.
Далее изображена схема, соответствующая системам с расщепленными
данными.
Здесь несколько систем с идентичными структурами данных. Система
в районе А хранит данные района А, система в районе В хранит данные
района В и т. д. Большинству обрабатываемых транзакций требуются только
те данные, которые находятся в обрабатывающей системе, но в некоторых
случаях для обработки транзакции, возникшей в одном районе, могут
потребоваться данные из другого района. При этом объектом передачи из
одного района в другой через сеть может стать либо транзакция, либо
данные. Во многих организациях установлено большое число персональных
компьютеров с одинаковыми расщепленными файлами в каждой, а сеть
объединяет их в единую систему.
Отметим различия между системами с расщепленными и с
разделенными данными. В системах с расщепленными данными прикладные
программы и структуры данных одни и те же. Программирование для всех
машин выполняет одна общая группа разработчиков. В системах же с
разделенными данными объединенные в сеть подсистемы содержат разные
данные и разные программы, как правило, создаются разными группами
разработчиков. Компьютеры получают возможность запрашивать данные
друг у друга. Компьютер конечного пользователя может быть подключен к
системе в целом.
Рассмотрим систему с реплицированными данными.
Идентичные копии данных хранятся в разных местах, потому что
дублирование памяти позволяет избежать передачи больших объемов
данных, и это оказывается дешевле. Такая организация имеет смысл только в
тех случаях, когда объем обновлений невелик.
Она состоит из независимых вычислительных систем, установленных
различными организациями для решения своих специфических задач и
объединенных через универсальную сеть. Каждый компьютер хранит только
собственные данные, и никакого сходства или единства форм организации
данных здесь нет. Пользователь может получить доступ к любой машине в
сети, но он должен в деталях знать, как организованы данные на этой
конкретной машине.
Многие конфигурации содержат комбинированные формы.
Классификация распределенных систем по типу распределения
процессоров (аспект обработки).
Существует несколько типов систем распределенной обработки
данных, в которых компоненты объединены с помощью средств связи.
Прежде всего определим горизонтальное и вертикальное
распределение.
Под
вертикальным
распределением
понимают
иерархию
процессоров. Как правило, транзакция входит в систему и покидает ее на
самом нижнем уровне. Может оказаться, что на самом нижнем уровне
транзакция обрабатывается полностью или же выполняются только
некоторые действия, и она передается на более высокий уровень. Все
транзакции либо какая-то их часть достигают верхнего уровня, который
имеет доступ к файлам или базам данных. Машина верхнего уровня
иерархии сама по себе может быть вычислительной системой и обрабатывать
свои собственные транзакции. Однако данные, с которыми она работает,
передаются ей системами нижних уровней. Так, на верхнем уровне может
оказаться система высшей ступени административного руководства. К ней
будут стекаться данные от заводов, отделений, складов и других систем.
При горизонтальном распределении процессоры не различаются по
рангу, все они имеют одинаковый статус. Транзакция проходит только через
один процессор, хотя в наличии может быть много процессоров. В некоторых
системах равноправных партнеров транзакции могут передаваться от одного
партнера к другому, вызывая в каждом обновление своих файлов.
Горизонтальное распределение иллюстрируется следующим рисунком.
На первой схеме несколько процессоров подсоединены к шине или к
широкополосному короткому каналу, на второй - к кольцу, на третьей и
четвертой (спутниковая связь) схемах представлены горизонтальные
компьютерные сети, в которых пользователь может войти в одну из машин.
Распределение по функциям
В некоторых системах распределение производится по функциям, а не
по способности полностью обработать транзакции. Централизованные
системы телеобработки 70-x годов работали с простыми терминалами и
выполняли почти все функции в центральной машине. Сначала были
вынесены вспомогательные системные и управляющие функции, затем такие,
как сбор данных, редактирование, диалог с оператором за терминалом и,
наконец, многие функции самих прикладных программ.
При этом предполагается распределение функций по вертикали, при
котором машины нижнего уровня передают транзакции вычислительной
системе более высокого уровня. В качестве машин нижнего уровня могут
использоваться интеллектуальные терминалы, в которых процессоры
выполняют функции редактирования сообщений, форматирования экрана,
организации диалога с оператором в процессе сбора данных, обеспечения
секретности, уплотнения сообщений. Они не обрабатывают транзакцию
полностью. При таком распределении периферийные машины не смогут
полностью автономно работать, если они окажутся отрезанными от главной
машины в случае отказов в системе связи или каких-либо других отказов.
В случае распределения по функциям жизненно важно тесное
взаимодействие между машинами разных уровней. Поэтому нужны единые
стандарты на всю систему, регламентирующие распределяемые функции.
Эти стандарты должны определять, каким образом машины нижних и
верхних уровней образуют части архитектуры всей системы с
соответствующими общими механизмами управления и программным
обеспечением.
Распределение по системам
В случае распределения по системам машины нижнего уровня сами по
себе являются системами, обрабатывающими свои собственные транзакции и
только в необходимых случаях передающими транзакции или данные вверх
по иерархии другим машинам.
При такой обработке периферийные
процессоры хранят свои собственные данные и могут автономно работать,
хотя и подключены к системам более высокого уровня.
При распределении по системам машины нижних и верхних уровней
могут быть совершенно различными и несовместимыми.
Комбинированные системы
Строгого разграничения между распределением по функциям и
распределением по системам не существует. В одних ситуациях наблюдается
переход от распределения по функциям к распределению по системам с
требованием все больших мощностей в периферийных машинах, в других периферийные машины начинают работать как автономные и затем
подсоединяются к системе более высокого уровня.
Вертикально распределенная конфигурация может содержать более
двух уровней процессоров. В некоторых системах число уровней доходит до
четырех.
К нижнему уровню могут относиться терминалы для ввода данных или
микропроцессоры, а также сканирующие датчики измерительных приборов.
На следующем уровне может располагаться компьютер в торговом
районе, собирающий и накапливающий данные, относящиеся к этому району,
или же компьютер на заводе, который собирает данные от микропроцессоров
и используется для планирования производственных операций.
Третий уровень представлен большой вычислительной системой в
каком-либо отделении фирмы, выполняющей разнообразные виды обработки
данных и управляющей различными базами данных для повседневных
рутинных операций. Этот вычислительной центр получает информацию от
систем нижележащего уровня и посылает им указания.
На самом верхнем уровне располагается административная
информационная система фирмы со своими структурами данных,
отличающимися от структур в системах, используемых для рутинных
операций. Эта система помогает при принятии различных административных
решений. В нее может быть заложена комплексная финансовая модель
фирмы или сложные программы, позволяющие осуществить оптимизацию
некоторых операций. Административная система получает обобщенные
данные от других систем, находящихся на более низких уровнях.
Горизонтальное распределение
До сих пор мы рассматривали системы с вертикальным
распределением. Перейдем теперь к обсуждению систем с горизонтальным
распределением.
Горизонтальные конфигурации можно классифицировать по степени
гомогенности (однородности) взаимодействующих систем. Степень
гомогенности влияет на общую структуру, на выбор программного
обеспечения, на способы передачи и на общие методы управления
функционированием сети.
В одних случаях мы имеем идентичные машины с едиными
прикладными программами в рамках конкретной фирмы. В других случаях
мы сталкиваемся с несовместимыми машинами, работающими по
совершенно разным программам в разных организациях и тем не менее
объединенными сетью.
Вопрос о том, какой должна быть конфигурация: вертикальной,
горизонтальной или смешанной, зависит от структуры обеспечиваемых
взаимодействий и схемы использования данных.
При проектировании распределенных систем приходится сталкиваться
со следующими проблемами:
Где находятся требуемые для выполнения работы устройства?
Независимы ли эти устройства или работа одних из них зависит от
результатов работы других? Какие хранимые данные необходимы для работы
устройств? Используют ли они общие или независимые данные? Какие
транзакции должны передаваться от одного устройства другому? Какова
схема потока транзакций? Должны ли транзакции передаваться от устройства
к устройству сразу или допустима задержка? Какова стоимость задержки?
В разных фирмах эти проблемы будут решаться по-разному, поскольку
различны
структуры
взаимодействий.
Различны
и
структуры
информационных потоков между устройствами. Таким образом, все фирмы
стремятся иметь свои собственные, естественные для них формы
распределенной обработки. То, что наиболее подходит для авиакомпании, не
обязательно хорошо для страхового общества.
Многоуровневые архитектуры клиент-сервер
Для решения перечисленных проблем используются многоуровневые
(три и более уровней) архитектуры клиент-сервер.
Такие архитектуры более разумно распределяют модули обработки
данных, которые в этом случае выполняются на одном или нескольких
отдельных серверах. Эти программные модули выполняют функции сервера
для интерфейсов с пользователями и клиента - для серверов баз данных.
Кроме того, различные серверы приложений могут взаимодействовать
между собой для более точного разделения системы на функциональные
блоки, выполняющие определенные роли.
Например, можно выделить сервер управления персоналом, который
будет выполнять все необходимые для управления персоналом функции.
Связав с ним отдельную базу данных, можно скрыть от пользователей все
детали реализации этого сервера, разрешив им обращаться только к его
общедоступным функциям. Кроме того, такую систему очень просто
адаптировать к Web, поскольку проще разработать html-формы для доступа
пользователей к определенным функциям базы данных, чем ко всем данным.
В трехуровневой архитектуре клиент не перегружен функциями
обработки данных, а выполняет свою основную роль системы
представления информации, поступающей с сервера приложений. Такой
интерфейс можно реализовать с помощью стандартных средств Webтехнологии - браузера, CGI и Java. Это уменьшает объем данных,
передаваемых между клиентом и сервером приложений, что позволяет
подключать клиентские компьютеры даже по медленным линиям типа
телефонных каналов. Кроме того, клиентская часть может быть
настолько простой, что в большинстве случаев ее реализуют с помощью
универсального браузера. Но если менять ее все-таки придется, то эту
процедуру можно осуществить быстро и безболезненно. Трехуровневая
архитектура клиент-сервер позволяет более точно назначать полномочия
пользователей, так как они получают права доступа не к самой базе
данных, а к определенным функциям сервера приложений. Это повышает
защищенность системы (по сравнению с обычно архитектурой) не только
от умышленного нападения, но и от ошибочных действий персонала.
Для примера рассмотрим систему, различные части которой работают
на нескольких удаленных друг от друга серверах. Допустим, что от
разработчика поступила новая версия системы, для установки которой в
двухуровневой архитектуре необходимо одновременно поменять все
системные модули. Если же этого не сделать, то взаимодействие старых
клиентов с новыми серверами может привести к непредсказуемым
последствиям, так как разработчики обычно не рассчитывают на такое
использование системы. В трехуровневой архитектуре ситуация упрощается.
Дело в том, что поменяв сервер приложений и сервер хранения данных (это
легко сделать одновременно, так как оба они обычно находятся рядом), мы
сразу меняем набор доступных сервисов. Таким образом, вероятность
ошибки из-за несоответствия версий серверной и клиентской частей резко
сокращается. Если в новой версии какой-либо сервис исчез, то элементы
интерфейса, обслуживавшие его в старой системе, просто не будут работать.
Если же изменился алгоритм работы сервиса, то он будет корректно работать
даже со старым интерфейсом.
Многоуровневые клиент-серверные системы достаточно легко можно
перевести на Web-технологию - для этого достаточно заменить клиентскую
часть универсальным или специализированным браузером, а сервер
приложений дополнить Web-сервером и небольшими программами вызова
процедур сервера. Для разработки этих программ можно использовать как
Common Gateway Interface (CGI), так и более современную технологию Java.
Следует отметить и тот факт, что в трехуровневой системе по каналу
связи между сервером приложений и базой данных передается достаточно
много информации. Однако это не замедляет вычислений, так как для связи
указанных элементов можно использовать более скоростные линии. Это
потребует минимальных затрат, поскольку оба сервера обычно находятся в
одном
помещении.
Таким
образом,
увеличивается
суммарная
производительность системы - над одной задачей теперь работают два
различных сервера, а связь между ними можно осуществлять по наиболее
скоростным линиям с минимальными затратами средств. Правда, возникает
проблема согласованности совместных вычислений, которую призваны
решать менеджеры транзакций - новые элементы многоуровневых систем.
Лекция 5
МЕТОДЫ РАБОТЫ В УСЛОВИЯХ ПЕРЕГРУЗКИ
Причины перегрузок в сети.
Оптимальность управления сетью в условиях перегрузок определяет
эффективность использования сети. Пока сеть загружена незначительно,
число принимаемых и обрабатываемых пакетов равно числу пришедших.
Однако, когда в сеть поступает слишком много пакетов может возникнуть
перегрузка и рабочие характеристики деградируют. При очень больших
загрузках пропускная способность канала или сети может стать нулевой.
Такая ситуация называется коллапсом сети.
Отчасти это может быть связано с недостатком памяти для входных
буферов, по этой причине некоторое увеличение памяти может помочь. Но
следует помнить, что всякое лекарство хорошо в меру. Еще в 1987 году
Нагле (Nagle) обнаружил, что если маршрутизатор имеет даже
беспредельную память, эффект перегрузки может оказаться еще более
тяжелым. Это сопряжено со временем, которые пакеты ожидают обработки.
Если время ожидания в очереди превышает длительность таймаута, появятся
дубликаты пакетов, что, безусловно, понижает эффективность системы.
Причиной перегрузки может быть медленный процессор или недостаточная
пропускная способность какого-то участка сети. Простая замена процессора
или интерфейса на более быстродействующий компонент не всегда решает
проблему - чаще переносит узкое место в другую часть системы. Перегрузка,
как правило, включает механизмы, усиливающие ее негативное воздействие.
Так переполнение буфера приводит к потере пакетов, которые позднее
должны будут переданы повторно (возможно даже несколько раз).
Процессор передающей стороны получает дополнительную паразитную
загрузку. Все это указывает на то, что контроль перегрузки является крайне
важным процессом. Следует делать различие между контролем потока и
контролем перегрузки. Под контролем потока подразумевается балансировка
потока отправителя и возможности приема и обработки получателя. Этот вид
контроля предполагает наличие обратной связи между получателем и
отправителем. В этом процессе участвуют, как правило, только два партнера.
Перегрузка же более общее явление, относящееся к сети в целом или к какойто ее части. Например, 10 ЭВМ хотят передать одновременно какие-то файлы
другим 10 ЭВМ. Конфликта потоков здесь нет, каждая из ЭВМ способна
переработать поступающие данные, но сеть не может пропустить поток,
генерируемый 10 сетевыми интерфейсами одновременно.
Начинать надо с решения проблемы выявления перегрузок.
Перегрузкой следует считать ситуацию, когда нагрузка в течение
некоторого оговоренного времени превышает заданную величину.
Параметрами, которые позволяют судить о наличии перегрузки могут
служить:
процент пакетов, отбрасываемых из-за отсутствия свободного
буферного пространства;
средняя длина очереди;
процент пакетов, пересылаемых повторно;
среднее время задержки пакета.
Когда перегрузка выявлена, нужно передать необходимую
информацию из точки, где она обнаружена, туда, где можно что-то сделать
для исправления ситуации.
Действия по устранению перегрузок.
Можно послать уведомление о перегрузке отправителю, загружая
дополнительно и без того перегруженный участок сети. Альтернативой этому
может быть применение специального поля в пакете, куда маршрутизатор
может записать соответствующий код при перегрузке, и послать его соседям.
Можно также ввести специальный процессор или маршрутизатор, который
рассылает периодически запросы о состоянии элементов сети. При
получении оповещения о перегрузки информационный поток может быть
послан в обход.
Решения по преодолению перегрузки делятся на три категории:
1. Организационные меры - преодоление перегрузки может быть
осуществлено понижением нагрузки или добавлением ресурсов приемнику.
2. Варьирование параметров - Положительный результат может быть
достигнут изменением механизма подтверждения (например, уменьшением
размера окна), вариацией значений таймаутов, вариацией политики
повторной передачи пакетов. В некоторых случаях позитивный результат
может быть получен изменением схемы буферизации.
3. Аппаратные решения. - Иногда решить проблему может
маршрутизатор, например, перераспределяющий трафик по нескольким
направлениям.
Алгоритмы устранения перегрузок в системах без обратной связи.
Алгоритм leaky bucket ("дырявое ведро")
Для систем без обратной связи решение проблемы выравнивания
скорости передачи данных может быть решено с помощью алгоритма leaky
bucket. Суть этого алгоритма заключается в том, что на пути потока
устанавливается буфер, выходной поток которого постоянен и согласован с
возможностью приемника. Если буфер переполняется, пакеты теряются.
Потеря пакетов вещь мало приятная, но это блокирует процессы, которые
могут привести к коллапсу сегмента или всей сети. Там, где потеря пакетов
нежелательна, можно применить более гибкий алгоритм.
Алгоритм Token Bucket ("маркерное ведро")
Алгоритм token bucket предполагает наличие в буферном устройстве
(или программе) некоторого количества маркеров. При поступлении на вход
буфера пакетов маркеры используются для их транспортировки на выход.
Дальнейшая передача данных на выход зависит от генерации новых
маркеров. Поступающие извне пакеты тем временем накапливаются в
буфере. Таким образом, полной гарантии отсутствия потерь мы не имеем и
здесь. Но алгоритм token bucket позволяет передавать на выход "плотные"
группы пакетов ограниченной численности (по числу маркеров), снижая в
некоторых случаях вероятность потери. Если буферное устройство
"смонтировано" внутри ЭВМ-отправителя, потерь можно избежать вовсе,
блокируя передачу при заполнении буфера. Как в одном так и в другом
алгоритме мерой передаваемой информации может быть не пакет, а n-байт
(где n некоторое оговоренное заранее число).
Методы устранения перегрузок в системах с обратной связью.
В системах, где управление трафиком осуществляется с
использованием обратной связи, можно достичь большей эффективности.
Метод управления разрешением.
Одним из механизмов преодоления перегрузок является управление
разрешением (admission control). Суть метода заключается в том, что при
регистрации перегрузки не формируется более никаких виртуальных
соединений до тех пор, пока ситуация не улучшится. Альтернативным
вариантом может служить решение, где формирование нового соединения
разрешается, но при этом осуществляется маршрутизация так, чтобы обойти
узлы, в которых выявлена перегрузка (смотри рис. 1 ).
На рис. 1 (верх) показан пример сети с двумя узлами,
характеризующимися
перегрузкой
(помечены
красным
цветом).
Предположим, что необходимо проложить виртуальный канал из узла А в
узел Б. Из графа маршрутов удаляются перегруженные узлы, после чего
осуществляется прокладка пути. В нижней части рисунка синим цветом
показан новый виртуальный канал.
Метод управления потоком с использованием пакетов блокировки
Еще более универсальным решением, пригодным для работы с
установлением соединения и без, является посылка пакетов блокировки
(choke packets). Маршрутизатор обычно контролирует загруженность всех
своих внешних каналов l, которая может принимать значения от 0 до 1. Когда
l достигает некоторого порогового значения, отправителю посылается пакет
блокировки. Параметром, который контролируется и определяет условие
отправки пакета блокировки, может служить длина очереди или
заполненность буфера. При вычислении этого параметра следует
использовать какую-либо методику усреднения, чтобы избежать слишком
частых блокировок.
Когда отправитель получает пакет блокировки, он должен уменьшить
трафик, посылаемый получателю на заданное число процентов. Так как на
пути к месту назначения может быть много пакетов, это вызовет серию
пакетов блокировки. Отправитель должен игнорировать пакеты блокировки в
течение некоторого времени после получения первого такого пакета. По
истечении этого периода отправитель прослушивает канал на протяжении
аналогичного времени, ожидая получения новых пакетов блокировки. Если
такой пакет приходит, канал все еще перегружен и отправитель снова должен
понизить темп посылки пакетов. Если на протяжении периода
прослушивания не приходит новых пакетов блокировки, отправитель может
увеличить поток снова.
ЭВМ может понижать трафик, корректируя свои параметры, например,
ширину окна или темп передачи на выходе устройства типа "дырявое ведро".
Обычно первый блокирующий пакет уменьшает поток вдвое, следующий на
0,25 от первичного и т.д. Увеличение потока также производится
аналогичными шагами. Существует большое число вариантов алгоритма
управления потоком с использованием пакетов блокировки.
Метод «честной очереди».
Ситуация перегрузки не всегда управляется однозначно. Например, при
поступлении на вход пакетов от трех источников возможна ситуация, когда
приемник посылает блокирующие пакеты всем отправителям, а откликнется
сокращением потока только один. В результате этот узел, который "играет по
правилам" (как это часто бывает и в жизни) оказывается в проигрыше. В 1987
году Нагле был предложен алгоритм fair queueing (честная очередь). В этом
алгоритме маршрутизатор организует независимые очереди для пакетов,
поступающих от разных источников. Когда выходной канал маршрутизатора
оказывается свободным, он просматривает очереди циклически и отравляет
очередной пакет. В результате при n очередях по завершении такого цикла
просмотров-посылок оказываются посланы по одному пакету из каждой
очереди. Такой алгоритм используется в некоторых ATM-переключателях.
Следует заметить, что этот алгоритм дает некоторые преимущества тем
узлам, которые посылают более длинные пакеты. Демерс (Demers) и др. в
1990 году предложил некоторое усовершенствоввание алгоритма. В данном
варианте организуется циклический просмотр очередей не по-пакетно, а побайтно. Система последовательно сканирует очереди и определяет
положение концов пакетов. Первыми отправляются более короткие пакеты.
Для иллюстрации предлагается рассмотреть рис. 2.
Рис. 2. Маршрутизатор с 4-мя входными каналами, в каждом из
которых ждет очереди передачи по одному пакету. В правой части рисунка
представлен порядок посылки этих пакетов.
Пакеты на рисунке имеют от трех до девяти октетов. Порядок
пересылки октетов показан в левой части рисунка. В отсутствии поступления
новых пакетов, кадры, записанные в буфер, будут переданы в порядке,
представленном в правой части рисунка. Особенностью этого алгоритма
является равенство приоритета всех входных каналов.
При передаче данных на большие расстояния эффективность
использования метода блокирующих пакетов снижается. Пока блокирующий
пакет дойдет через ряд промежуточных узлов до отправителя, на вход
получателя поступит большое число пакетов, которые не только усугубят
ситуацию перегрузки, но и могут вызвать потерю какой-то их доли, что, в
свою очередь, может потребовать повторной пересылки следовавших за
ними кадров. Для повышения эффективности часто применяется схема, при
которой блокирующие пакеты воздействуют на все маршрутизаторы по пути
своего следования. В этом случае снижения потока можно ожидать уже через
время, равное времени распространения сигнала до узла, ближайшего к
получателю пакетов. Такая схема требует того, чтобы все промежуточные
узлы имели достаточно емкие буферы, в противном случае возможны потери.
Метод «скользящее окно»
В протоколе ТСР используется алгоритм управления трафиком,
называемый "скользящее окно". Здесь размер окна, которое определяет число
сегментов, посылаемых без получения подтверждения, варьируется в
зависимости от наличия потерь пакетов. При большой вероятности потери
система переходит в режим, когда очередной пакет не посылается до тех пор,
пока не будет подтверждено получение предшествующего. При серьезных
перегрузках, когда потери становятся значительными, нарушается механизм
вычисления значений таймаутов, что может приводить к трудно
предсказуемым последствиям.
Метод отбрасывания пакетов
Если другие способы испробованы, а перегрузка не исчезла,
маршрутизатор начинает отбрасывать приходящие пакеты, которые уже не
может обработать. Самое простое - это предоставить случаю выбор
отбрасываемых пакетов. Но это не лучшая тактика. В случае пересылки
мультимедийных данных предпочтение следует делать для последних
полученных пакетов, а "старые" пакеты выбрасывать. При передаче файлов
наоборот "старый" пакет имеет приоритет, ведь если его отбросить, придется
повторно передавать не только его, но и все последующие пакеты.
Некоторые методы передачи изображения требуют передачи время от
времени всего кадра с последующей пересылкой только фрагментов, где
произошли изменения. В таких условиях потеря пакета, составляющего
базовый кадр, менее желательна. Сходные обстоятельства могут возникать и
в других приложениях. Можно помечать пакеты, присваивая им
определенные уровни приоритетов, что позволит осознанно принимать
решение об отбрасывании того или иного пакета в условиях перегрузки. В
перспективе проблема может быть решена на чисто коммерческой основе компонента трафика, помеченная как высоко приоритетная, будет
оплачиваться по более высокому тарифу. В некоторых сетях определенное
количество пакетов объединяется в группы, образующие сообщение. Если
одна ячейка такого сообщения выброшена, все сообщение будет повторно
переслано.
Если одна ячейка такого сообщения выброшена, все сообщение будет
повторно переслано.
ПРОГРАММНЫЕ СРЕДСТВА ЛВС. СЕТЕВЫЕ ОС.
Многослойная модель сети
Даже поверхностно рассматривая работу сети, можно заключить, что
вычислительная сеть — это сложный комплекс взаимосвязанных и
согласованно
функционирующих
программных
и
аппаратных
компонентов. Весь комплекс программно-аппаратных средств сети может
быть описан многослойной моделью:
 компьютеры (нижний слой);
 коммуникационное оборудование;
 операционные системы;
 сетевые приложения (верхний слой).
В основе любой сети лежит аппаратный слой стандартизированных
компьютерных платформ. В настоящее время в сетях успешно
применяются компьютеры различных классов — от персональных
компьютеров до мэйнфреймов и супер-ЭВМ. Набор компьютеров в сети
должен соответствовать набору решаемых сетью задач.
Второй слой — это коммуникационное оборудование. Хотя
компьютеры и являются центральными элементами обработки данных в
сетях, в последнее время не менее важную роль стали играть
коммуникационные устройства. Кабельные системы, повторители, мосты,
коммутаторы, маршрутизаторы и концентраторы из вспомогательных
компонентов сети превратились в основные как по влиянию на
характеристики сети, так и по стоимости. Сегодня коммуникационное
устройство может представлять собой сложный специализированный
мультипроцессор, который нужно конфигурировать, оптимизировать и
администрировать.
Третьим слоем, образующим программную платформу сети, являются
операционные системы (ОС). От того, какие концепции управления
локальными и распределенными ресурсами положены в основу сетевой ОС,
зависит эффективность работы всей сети. При проектировании сети важно
учитывать, насколько легко данная операционная система может
взаимодействовать с другими ОС сети, какой она обеспечивает уровень
безопасности и защищенности данных, до какой степени позволяет
наращивать число пользователей, можно ли перенести ее на компьютер
другого типа и многие другие соображения.
Самый верхний слой сетевых средств образуют различные сетевые
приложения, такие как сетевые базы данных, почтовые системы, средства
архивирования данных, системы автоматизации коллективной работы и т.д.
Очень важно представлять диапазон возможностей, предоставляемых
приложениями для различных областей применения, а также знать,
насколько они совместимы с другими сетевыми приложениями и
операционными системами.
Вычислительная
сеть
—
это
многослойный
комплекс
взаимосвязанных и согласованно функционирующих программных и
аппаратных компонентов: компьютеров, коммуникационного оборудования,
операционных систем, сетевых приложений.
Структура сетевой операционной системы
Работа вычислительной сети заключается в передаче данных от одного
компьютера к другому. В этом процессе можно выделить несколько
отдельных задач:
 распознать данные;
 разбить данные на управляемые блоки;
 добавить служебную информацию к каждому блоку, чтобы указать
местонахождение данных и указать получателя;
 добавить служебную информацию о синхронизации и информацию
для проверки ошибок;
 поместить данные в сеть;
 отправить их по заданному адресу.
В выполнении всех этих задач участвует сетевая операционная
система. Сетевая операционная система составляет основу любой
вычислительной сети. Каждый компьютер в сети в значительной степени
автономен, поэтому под сетевой операционной системой в широком смысле
понимается совокупность операционных систем отдельных компьютеров,
взаимодействующих с целью обмена сообщениями и разделения ресурсов по
единым правилам - протоколам. В узком смысле сетевая ОС - это
операционная система отдельного компьютера, обеспечивающая ему
возможность работать в сети.
К сетевому программному обеспечению относятся также драйверы
сетевых плат, различные для разных типов ЛВС (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
Функции сетевого
администратора
Управление
конфигурацией
Задачи
установка сетевых параметров, загрузка
программного обеспечения, ведение базы
данных конфигураций
Регистрация,
сбор
и хранение, обновление и выдача информации;
обработка информации
ведение сетевого журнала;
генерация отчетов
Контроль характеристик
статистическая обработка информации о
характеристиках сети;
регулирование статистических параметров
Управление в проблемных диагностика и локализация ошибок;
ситуациях
тестирование;
восстановление работоспособности сети
Управление
моделирование;
планированием
генерация искусственного трафика;
Поддержка пользователей
прогнозирование развития сети;
оценка
функциональных
возможностей
конкретных конфигураций;
принятие решений по модернизации и
развитию сети
определение групп пользователей
определение прав доступа
обучение пользователей
Управление сетью необходимо проводить как в условиях нормального
функционирования (в этом случае управление заключается в слежении и
контроле за правильностью действий пользователей и корректной работой
оборудования), так и в условиях возникновения проблемных ситуаций (в
этом случае управление направлено на ликвидацию отклонений и
восстановление работоспособности сети после сбоев).
В таблице перечислены проблемные ситуации, возникающие при
автоматизированной обработке информации в вычислительных сетях.
Факторы
Причины
Действия по
отклонений возникновения ликвидации
ПС
последствий ПС
Программн
оаппаратный
комплекс
1. отказы, сбои,
внешние
помехи
2. несовместимость компонентов
комплекса
3.
заражение
компьютерным
и вирусами
1. восстановление
компонентов
комплекса
2.
подбор
совместимых
компонентов
комплекса
3.
удаление
вирусов,
восстановление
информации
Таблица 2
Способы предупреждения
ПС
1. обеспечение
надежности, техническое
сопровождение
2. обеспечение
сопряжения компонентов
посредством интерфейсов
3.своевременная
антивирусная защита
Человечес- 1. нарушение
кий фактор регламента
работ
2. ошибки от
неумения,
невнимания
3.
несанкционированный доступ
1. восстановление
регламента работ
2. восстановление
информации
1. оптимизация процессов
управления сетью
2. интеллектуальное
информационное
3. восстановление сопровождение, обучение
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
Краткая история облачных вычислений
Термин «Облако» (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.

Частное облако — это безопасная ИТ-инфраструктура
контролируемая и эксплуатируемая в интересах одной-единственной
организации. Организация может управлять частным «облаком»
самостоятельно или поручить эту задачу внешнему подрядчику.
Инфраструктура может размещаться либо в помещениях заказчика, либо у
внешнего оператора (либо частично у заказчика и частично у оператора).

Гибридное облако — это ИТ-инфраструктура использующая
лучшие качества публичного и приватного облака при решении
поставленной задачи. Часто такой тип применяется, когда организация имеет
сезонные периоды активности, другими словами, как только внутренняя ИТинфраструктура не справляется с текущими задачами, часть мощностей
перебрасывается на публичное «облако» (например, большие объемы
статистической информации), а также для предоставления доступа
пользователям к ресурсам предприятия через публичное «облако».
Теперь рассмотрим возможности облачных вычислений:

Доступ к личной информации с любого компьютера,
подключённого к Интернету

Можно работать с информацией с разных устройств (ПК,
планшеты, телефоны и т.п.)

Не важно в какой операционной системе Вы предпочитаете
работать, — веб-сервисы работают в браузере любых ОС

Одну и туже информацию, как Вы, так и окружающие, могут
просматривать и редактировать одновременно с разных устройств

Многие платные программы стали бесплатными (или более
дешёвыми) веб-приложениями

Если что-то случится с вашим устройством (ПК, планшетом,
телефоном), то Вы не потеряете важную информацию, так как она теперь не
хранится в памяти устройств

Всегда под рукой свежая и обновлённая информация

Вы всегда пользуетесь самой последней версией программ и при
этом не надо следить за выходом обновлений

Можно свою информацию объединять с другими пользователями

Легко можно делиться информацией с близкими людьми или с
людьми из любой точки земного шарика.
Возможностей, весьма предостаточно, однако, есть и свои недостатки
(куда же без них), о которых также следует упомянуть.
«Ложка дегтя» — недостатки:

Необходимость постоянного соединения. Для получения
доступа к услугам «облака» необходимо постоянное соединение с Интернет

Программное обеспечение и его «кастомизация». Есть
ограничения по ПО, которое можно разворачивать на «облаках» и
предоставлять его пользователю. Пользователь имеет ограничения в
используемом обеспечении и иногда не имеет возможности настроить его
под свои собственные цели

Конфиденциальность. Конфиденциальность данных, хранимых
в публичных «облаках», в настоящее время, вызывает много споров, но в
большинстве случаев эксперты сходятся в том, что не рекомендуется хранить
наиболее ценные для компании документы на публичном “облаке”, так как в
настоящее время нет технологии, которая бы гарантировала 100%
конфиденциальность данных

Безопасность. «Облако” само по себе является достаточно
надежной системой, однако при проникновении в него злоумышленник
получает доступ к огромному хранилищу данных. Еще один минус, — это
использование систем виртуализации в которых, в качестве гипервизора,
используются ядра стандартных ОС (например Windows), что позволяет
использовать вирусы и уязвимости системы

Дороговизна оборудования. Для построения собственного
облака необходимо выделить значительные материальные ресурсы, что не
выгодно только что созданным и малым компаниям
Дальнейшая монетизация ресурса. Вполне возможно, что
компании в дальнейшем решат брать плату с пользователей за
предоставляемые услуги.
Как видите, есть две стороны медали. Впрочем, развитию технологии
это не вредит, а может даже и подстегивает.

Лекция 8
Обзор облачных технологий
Говоря о том, что такое облачные технологии и облачные вычисления,
всегда необходимо помнить о том, как определяются основные
характеристики любого настоящего облака – наличие пула ресурсов,
самообслуживание, эластичность и оплата на основе использования. Эти
характеристики были выведены 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-AService и Software-As-A-Service. В настоящее время существует широкая
таксономия терминов, сужающих контекст, например, MBaaS (MobileBackend-As-A-Service) и Metal-As-Service, но в общем смысле все сводится к
трем методам. В индустрии определены три типа поставок облачных
сервисов:

IaaS – набор связанных с инфраструктурой возможностей (ОС,
сетевое подключение, т.д.), предоставляемых клиенту на основе модели
"оплаты-за-использование" и могущих использоваться для размещения
приложений.

PaaS – функциональность более высокого уровня, связанная с
платформой и предоставляемая как сервис для разработчиков приложений. С
PaaS разработчики абстрагируются от низлежащей инфраструктуры.

SaaS – приложения, предлагаемые в качестве сервисов, когда
организации просто потребляют и используют приложение. Традиционно же
организация платила бы за использование приложения или приложение
монетизировалось бы через доход от рекламы.
Важно заметить, что эти три типа сервисов могут существовать
отдельно или в комбинации друг с другом: предложения типа SaaS
необязательно могут быть разработаны над предложениями PaaS, так как
решения, основанные на использовании PaaS, часто предоставляются как
SaaS, предложения же типа PaaS – больше, чем просто работающая на IaaS
платформа. Симбиоз трех методов поставки облачных сервисов, разумеется,
должен предваряться серьезным анализом и часто целым переосмыслением
архитектуры сервиса, который должен работать в облаке.
Следующей цифрой в принципе 4-3-2, характеризуется тип облака. Тип
облака влияет на размещенные в нем сервисы достаточно опосредовано – для
конечного пользователя использование сервиса, размещенного в приватном
облаке или размещенного в публичном, может не нести никакого различия –
использование практически всегда полностью прозрачно. Аналогично
методам поставки, существуют дополнительные термины, характеризующие
тип облака, например, Community Cloud, но данные типы так или иначе
являются либо развитием, либо симбиозом приватного или публичного
типов.
Таким образом, принцип 4-3-2 позволяет охарактеризовать любой
облачный сервис либо платформу таким образом, чтобы можно было понять,
действительно ли (на высоком уровне) сервис является облачным либо он
является простым виртуализованным сервисом, находящимся под
управлением живых людей и не предоставляет стандартные для облаков
преимущества.
Сценарии, подходящие для облаков
Для облака подходит определенный набор типов нагрузок. Первый это "включение/выключение", для которого характерна ситуация, в
которой в один момент времени необходимо обсчитать какую-либо задачу,
будь она научная, технологическая или бизнес. В этом случае мощности
простаивают ровно то время, которое они не требуются, что не является
эффективным подходом. Типичный пример такого типа нагрузок – научные
задачи на суперкомпьютерных кластерах.
Второй тип – быстрый рост – характерен для успешных стартапов и
проектов, когда, например, после анонсирования вашего проекта на
популярном ресурсе мощностей для обслуживания клиентов может просто не
хватить. В этом случае оперативное развертывание дополняющей аппаратнопрограммной инфраструктуры может занять время, в течении которого
проект может быть вообще недоступен. Развернуть мощности мгновенно в
локальном центре обработки данных и установить на них соответствующее
программное обеспечение, добавив ресурсы в ротацию балансировщика
нагрузки, практически невозможно.
Третий тип – непредсказуемый всплеск – характерен для успешных
стартапов, внезапный или неосторожный анонс сразу после запуска (без
соответствующего нагрузочного тестирования и обработки сценариев) может
вызвать резкий наплыв посетителей.
И, четвертый тип, это, например, сервис для подачи налоговой
отчетности – в какой-то определенный период происходит нагрузка, и он, в
целом, скорее всего будет неизменен, что позволяет запланировать задачи по
масштабированию таким образом, чтобы этот процесс происходил наиболее
эффективно и экономично.
Облачные технологии. Обзор решений.
Рассмотрим — какие решения, сервисы, программы уже существуют на
рынке и на что стоит обратить свое внимание. Начнем с сервисов:

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 по
всему миру, для автоматического обнаружения и классификации новых
видов вредоносных программ, появляющихся каждый день.
Лекция 9
Что дают нам облачные технологии?
Говоря совсем просто, облако — это возможность всегда иметь
гарантированный и безопасный доступ ко всей своей личной информации, а
также уход от необходимости держать в своем кармане много лишних вещей
(всяких флешек, дисков, проводов и всего такого прочего) или покупать
новый компьютер/комплектующие/программы/игры и пр. Несомненно, что
на данный момент, облачные технологии являются одной из самых
востребованных и интересных тем в 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.
Лекция 10
Суть концепции облачных технологий заключается в предоставлении
конечным пользователям удаленного динамического доступа к услугам,
вычислительным ресурсам и приложениям (включая операционные системы
и инфраструктуру) через интернет. Развитие сферы хостинга было
обусловлено возникшей потребностью в программном обеспечении и
цифровых услугах, которыми можно было бы управлять изнутри, но которые
были бы при этом более экономичными и эффективными за счет экономии
на масштабе.
Большинство сервис-провайдеров предлагают облачные вычисления в
форме 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-приложения, отвечающие современным стандартам
отрасли.
SaaS-технологии
SaaS (Software as a Service) - это модель использования бизнесприложений в качестве интернет-сервисов.
SaaS приложения работают на сервере SaaS-провайдера, а пользователи
получают к ним доступ через интернет-браузер. Пользователь не покупает
SaaS-приложение, а арендует его - платит за его использование некоторую
сумму в месяц. Таким образом достигается экономический эффект, который
считается одним из главных преимуществ SaaS.
SaaS-провайдер заботится о работоспособности приложения,
осуществляет техническую поддержку пользователей, самостоятельно
устанавливает обновления. Таким образом, пользователь меньше думает о
технической стороне вопроса, а сосредотачивается на своих бизнес-целях.
Основные преимущества SaaS над традиционным программным
обеспечением:
более низкая стоимость владения.
более короткие сроки внедрения.
низкий порог входа (можно быстро и бесплатно протестировать).
задачи по поддержке и обновлению системы полностью ложатся на
плечи SaaS-провайдера.
полная мобильность пользователя, ограниченная лишь «интернетпокрытием».
поддержка географически распределенных компаний и удаленных
сотрудников.
низкие требования к мощности компьютера пользователя.
Кросс-платформенность.
Недостатками SaaS считаются небезопасность передачи коммерческих
данных стороннему провайдеру, невысокое быстродействие и ненадежность
доступа из-за перебоев с интернетом.
Появились альтернативные технологии по отношению к SaaS. Они
представляют собой промежуточные варианты перехода от традиционного
ПО к SaaS, и скорее всего, скоро исчезнут.
S+S - Это альтернативный бренд, продвигаемый Microsoft, который
отличается от SaaS тем, что на компьютере пользователя используется не
браузер, а программный клиент.
Аренда (хостинг) приложений. Этот вариант отличается от SaaS лишь
архитектурой серверной части и не заметен для пользователя. Поэтому часто
хостеры приложений называют свои услуги SaaS-сервисами. Отличие в том,
что классические SaaS сервисы имеют multitenant-архитектуру, т.е. одно
приложение обслуживает много клиентов, а хостинг приложений
предполагает установку отдельной копии для каждого клиента. Второй
вариант дает больше возможностей настройки, но в то же время, он более
сложен для администрирования и обновления, и поэтому стоит дороже.
Практика применения облачных технологий
В 2011 году WINDOWS AZURE была объявлена коммерческой
системой. Как и традиционная ОС, WINDOWS AZURE позволяет запускать
приложения и хранить данные, но происходит это не на компьютере
пользователя, а в вычислительных облаках.
Операционная система WINDOWS AZURE является частью Windows
Azure Platform - группы облачных технологий для разработки ПО, которая
включает следующие элементы:
WINDOWS AZURE обеспечивает Windows-среду для работы
приложения и хранения данных в дата-центрах Microsoft
SQL Azure обеспечивает работу с реляционными базами данных на
основе сервера SQL. Данные могут храниться как в облачной среде, так и в
стенах предприятия, тем не менее, взаимодействуя с приложениями
WINDOWS AZURE
Windows Azure Platform AppFabric соединяет приложения, работающие
как в облачной, так и в традиционной среде, обеспечивая защищенную
передачу данных.
Несмотря на сходство названий, понятия fabric и AppFabric - совсем не
одно и то же. Первое относится к объединению физических машин внутри
облачной ОС, второе - к соединению приложений, работающих в разных
средах.
Непосредственно операционная система WINDOWS AZURE также
состоит из нескольких взаимосвязанных частей: Compute Service, Storage
Service и Fabric.
Compute Service отвечает за вычисления. Основная цель облачной
платформы состоит в том, чтобы обеспечить поддержку приложения,
запускающего огромное число пользователей в одно и то же время.
WINDOWS AZURE поддерживает несколько копий одного и того же кода на
разных физических серверах. В свою очередь, приложение может работать
сразу в нескольких версиях на нескольких виртуальных машинах, каждая из
которых
обеспечивается
гипервизором
на
основе
Hyper-V,
модифицированного для использования в облаках.
Существуют два типа рабочих версий облачного приложения: веб-роль
(Web role) и рабочая роль (Worker role). Первая умеет обрабатывать HTTPили HTTPS-запросы, и на ее виртуальной машине (ВМ) запущен сервер
Internet Information Services (IIS). Программист имеет возможность создать
версию веб-роли с помощью ASP.NET либо Windows Communication
Foundation (WCF), а также воспользоваться любой другой технологией .NET,
работающей с IIS. Приложение может быть создано на любом языке
программирования.
Напротив, рабочая роль не предполагает запуска IIS. Она выполняет
задачи в фоновом режиме. Например, веб-роль может быть применена для
получения запроса от пользователя. Но его обработка будет запущена позже
с помощью версии рабочей роли.
Storage Service обеспечивает хранение данных. ОС WINDOWS AZURE
поддерживает три способа работы с данными. Самый простой из них - BLOB,
содержащий бинарные данные с несложной иерархией. Этот тип организации
информации предназначен для хранения изображений, аудио и видео, т.?е.
для использования больших объемов. Когда необходимо структурировать
однотипные данные, то прибегают к таблицам, где для каждой единицы
информации существуют номер строки и номер колонки. Таблица в Storage
Service не является реляционной. Ее простая организация позволяет получать
доступ к данным посредством методов ADO.NET. В таком виде облачная ОС
распределяет хранение данных на несколько физических компьютеров, что
более эффективно, чем при использовании реляционной базы данных.
Рассмотренные способы обеспечивают хранение данных и доступ к
ним, а для их связи необходим третий способ, называемый «очередь».
Принцип организации данных в очередь основывается на следующем:
«Первый пришел - первый вышел». Этот способ помогает разным версиям
приложения обмениваться между собой сообщениями. Так связываются веброль и рабочая роль, поскольку синхронизация в облачной среденевозможна.
Предположим, пользователь через веб-интерфейс вызывает задачу,
требующую существенных вычислительных мощностей. Веб-роль
записывает полученный запрос в очередь. Рабочая роль, обращаясь к этой
очереди, принимает запрос и выполняет его. Результаты выполнения (ответ)
передаются по тому же принципу, через очередь. Независимо от метода
организации данных, информация в WINDOWS AZURE Storage
реплицируется 3 раза, что обеспечивает устойчивость системы: потеря
данных в одной из копий не фатальна. Кроме того, существуют архивные
копии, хранящиеся в другом дата-центре Microsoft. Это означает, что даже
если весь дата-центр уничтожен, информация будет поднята и восстановлена
из архивов другого центра.
Последняя составляющая ОС - Fabric - позволяет организовать набор
компьютеров, на которых хранятся приложения и данные WINDOWS
AZURE. Управление такой «компьютерной тканью» осуществляет
программное обеспечение, называемое fabric controller. Fabric осуществляет
мониторинг всех работающих приложений, управляет взаимодействием с ОС
на разных ВМ и выбирает физический сервер для запуска приложения, тем
самым
оптимизируя
использование
оборудования.
Управление
приложениями выполняется с помощью конфигурационных файлов,
содержащих XML-описание всего, что необходимо приложению, например
нужного количества виртуальных машин с веб-ролями и рабочими ролями.
Fabric controller создает эти виртуальные машины и отслеживает состояние
каждой из них, чтобы при необходимости заменить вышедшую из строя или
запустить ее на другом физическом сервере.
Компоненты WINDOWS AZURE позволяют строить приложения
разных типов. Так, для создания масштабируемого интернет-приложения
программисту достаточно употребить необходимое количество веб-ролей,
сохраняя данные в таблицах. А для приложения с параллельными
вычислениями потребуются веб-роль, очередь для сохранения запросов,
необходимое количество рабочих ролей и таблицы (или BLOB) для хранения
данных. В свою очередь, SQL Azure и AppFabric дают возможность
соединить решения WINDOWS AZUREс программами и базами данных,
функционирующими в рамках локальной сети или с облачными системами
других провайдеров.
Приложения,
созданные
на
основе
WINDOWS
AZURE,
предоставляются как сервис физическим лицам, корпоративным
пользователям или и тем, и другим одновременно. Вот примеры цен на
некоторые облачные услуги Microsoft:
вычислительные мощности - 0,12 долл./ч
хранилище данных в месяц - 0,15 долл./Гбайт
транзакции данных - 0,01 долл./10 Кбайт
загрузка данных - 0,10 долл./Гбайт
скачивание данных - 0,15 долл./Гбайт
С помощью WINDOWS AZURE независимый разработчик
программного обеспечения может создавать приложения для бизнеспользователей, применяя принципы программного обеспечения как сервиса.
Примером может послужить решение, разработанное американской
компанией Alinean, Inc. Ее сфера деятельности - предоставление по запросу
аналитических средств в области анализа продаж и маркетинга. Системы
Alinean позволяют оценить нужды и возможности бизнеса в будущем,
предложить решение для наращивания мощностей и подсчитать, когда
начнут окупаться инвестиции. Пользователями Alinean являются
корпоративные клиенты, находящиеся в разных уголках земного шара. Среди
них IBM, HP, Microsoft, Intel, AT&T, VMware, Oracle, Siemens, Symantec и др.
В дата-центре Alinean, находящемся в Орландо (Флорида, США), сервис по
запросу предоставляли 20 серверов, работающих 24 часа в сутки семь дней в
неделю. Объем бизнеса рос, и мощностей стало не хватать, да и содержание
внутреннего ЦОД становилось все дороже.
Поэтому было принято решение перенести разработанное ранее
программное обеспечение под крышу WINDOWS AZURE. В результате
потребовалось 28 виртуальных серверов с Azure и 20 SQL Azure (по 10 Гбайт
каждый). Благодаря оплате услуг по факту, Alinean удалось добиться
сокращения затрат по обслуживанию на 60?% по сравнению с предыдущей,
традиционной моделью. Кроме того, руководство оценивает в 160?%
отношение среднего увеличения прибыли к объему инвестиций (ROI - Return
On Investment) в WINDOWS AZURE по сравнению с вложениями в прежнюю
конфигурацию (100?%).
Благодаря масштабируемости WINDOWS AZURE позволяет вести учет
огромного количества пользователей. Создавая облачноерешение, компания-
разработчик может рассчитывать не только на корпорации, но и на
физических лиц. Такое приложение было сделано новозеландской компанией
TicketDirect International, которая, работая в онлайновом режиме,
осуществляет 45?% всех продаж билетов на культурные и спортивные
мероприятия Новой Зеландии. Предыдущая, традиционная, система продажи
билетов, функционировавшая на базе Microsoft SQL Server 7 и SQL Server
2000, была написана на Visual Basic 6. Приложение без проблем обслуживало
несколько сотен продаж в течение часа. Но в дни распродаж, когда
объявлялась скидка на посещение популярного мероприятия, до системы
пытались одновременно «достучаться» тысячи людей. Неудивительно, что
компьютерный парк продавца билетов не выдерживал такого наплыва
пользователей.
WINDOWS AZURE предоставила TicketDirect масштабируемую
инфраструктуру как сервис с возможностью оплаты по факту. В результате в
момент распродаж приложение начинает использовать дополнительные
мощности. Теперь компании TicketDirect не потребуется закупать
оборудование только для того, чтобы покрыть временные всплески
активности. Ограничений практически не существует. В облаках компания
способна обслужить несколько популярных мероприятий, начинающих свои
распродажи в одну и ту же минуту. WINDOWS AZUREпредоставит столько
мощностей, сколько необходимо для бизнеса.
В среде WINDOWS AZURE могут быть созданы внутренние
приложения, пользователями которых являются работники данного
предприятия. В этом случае масштабируемость, пожалуй, не так важна. Но
всплески активности случаются и внутри компании - тогда трудно
переоценить преимущества вычислений в облаках даже в стенах
предприятия. В качестве примера приведем саму компанию Microsoft,
вернее, ее отдел информационных технологий, где нашла свое
применениеWINDOWS AZURE. В рамках ежегодной благотворительной
кампании ИТ-отдел проводит онлайн-аукцион в пользу благотворительной
организации United Way. Прежде оборудование и ПО для него
поддерживались круглый год, в то время как мероприятие проводилось в
течение одного месяца всего лишь раз в году. Кроме того, в самом конце
аукциона обычно возникала еще одна проблема, с которой сталкивались
технические работники. Каждый раз в это время наблюдался всплеск
активности, и система оказывалась перегруженной.
Отдел ИТ принял решение мигрировать в вычислительные облака.
Были задействованы WINDOWS AZURE и Microsoft SQL Azure для хранения
данных. Теперь в последние дни аукциона ИТ-команда программирует
систему на использование большего количества ресурсов, чтобы обслужить
увеличивающийся поток запросов. Когда аукцион заканчивается, мощности
сокращаются соответственно нагрузке. Облачная модель готова обслужить
столько пользователей, сколько необходимо. Внутри огромной компании,
которой является Microsoft, система теперь позволяет собрать больше
средств, идущих на благотворительность.
Приведенные примеры говорят о создании систем по запросу. Но для
того чтобы поработать в среде WINDOWS AZURE, не обязательно
программировать свое собственное приложение. Сейчас каждый из нас
сумеет протестировать облачную ОС Microsoft в действии. На базе
WINDOWS AZURE в рамках «живой», работающей системы Windows Live
доступны офисные приложения по запросу. Windows Live позволяет
создавать документы в форматах Word, Excel и PowerPoint и хранить их на
виртуальном диске, в облаках. Любопытно, что система дает возможность
открыть онлайн-документ на ПК с помощью традиционного ПО Microsoft. В
будущем WINDOWS AZURE выйдет за пределы дата-центров ее
разработчика и будет устанавливаться в стенах других корпораций. Microsoft
объявила о предстоящем взаимодействии с такими компаниями, как Dell, HP
и eBay. Последняя планирует использовать облачное решение на основе
WINDOWS AZURE, благодаря чему абоненты смогут участвовать в
привычном аукционе eBay, используя iPad.
Заключение
На данный момент идет активная разработка и совершенствование
технологии облачных вычислений. Но речь идет именно о разработке, а не об
использовании. На данный момент многие бояться именно самого факта, что
информацию будут хранить сторонние люди. И хотя почти невозможность
утери либо кражи данных уже доказана, немногие готовы довериться
подобным сервисам. Так же сказывается недостаточное на данный период
времени качество, стабильность и скорость Интернет-соединений, что
создает ощутимые трудности для разработчиков.
При
использовании
облачных
вычислений,
потребители
информационных технологий могут существенно снизить капитальные
расходы - на построение центров обработки данных, закупку серверного и
сетевого оборудования, аппаратных и программных решений по
обеспечению непрерывности и работоспособности - так как эти расходы
поглощаются провайдером облачных услуг. Кроме того, длительное время
построения и ввода в эксплуатацию крупных объектов инфраструктуры
информационных технологий и высокая их начальная стоимость
ограничивают способность потребителей гибко реагировать на требования
рынка, тогда как облачные технологии обеспечивают возможность
практически мгновенно реагировать на увеличение спроса на
вычислительные мощности.
При использовании облачных вычислений, затраты потребителя
смещаются в сторону операционных - таким образом классифицируются
расходы на оплату услуг облачных провайдеров.
Однако, несмотря на эти существенные недостатки, плюсы от
внедрения данной технологии ясны всем. Ведь это экономия для
потребителей, борьба с пиратством для разработчиков, минимизация затрат в
IT сфере для бизнеса, унификация сетевых стандартов для всех
пользователей.