CC BY
102
D. I. Poletaev, O. A. Poletaeva
THE FIRST PHASE OF THE DEVELOPMENT OF AN AUTOMATED INFORMATION SYSTEM FOR RECORDING THE DISTRIBUTION OF COMPETENCES
Ап automated information system (AIS) for recording the distribution of competences is developed to assess the development of competencies . The AIS should be implemented as a network application with access via the Internet. To clarify the requirements for the system it was decided to create a desktop application as prototype. The implementation of this application is discussed in the article.
Keywords: information system, competence approach.
Полетаев Дмитрий Игоревич — старший преподаватель кафедры «Информационные системы и технологии» ФГБОУ ВПО ПсковГУ, dmitrypoletaev@newmail.ru.
Полетаева Ольга Александровна — старший преподаватель кафедры «Информационные системы и технологии» ФГБОУ ВПО ПсковГУ, oapoletaeva@mail.ru.
УДК 004.75
М. И. Павлов
О НЕКОТОРЫХ АСПЕКТАХ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ В УПРАВЛЕНИИ ИНФОКОММУНИКАЦИОННЫМИ СЕТЯМИ
Сформулированы аспекты, требующие внимания при построении операторских сервисов, ориентированных на предоставление услуг облачными системами, определены структурные особенности системы управления данных сервисов и дана оценка перспективы развития данного направления на рынке информационных технологий и телекоммуникационных услуг.
Ключевые слова: система поддержки бизнеса, платформа управления облачными инфокоммуникациями.
Термин «облачные вычисления» (cloud computing) стал использоваться на рынке информационных технологий с 2008 года. Разработчики облачных вычислений определяют их как инновационную технологию, предоставляющую динамично масштабируемые вычислительные ресурсы и приложения через Интернет в качестве сервиса под управлением поставщика услуг (рисунок 1). На данный момент, идея облачных вычислений восходит к центрам коллективного пользования, к предоставлению — на новом витке развития — услуг, связанных с прикладными сервисами.
В сентябре 2011 года Национальный Институт Стандартов и Технологи США (The National Institute of Standards and Technology — NIST) разработал документ (NIST, 2011), в котором была сделана попытка дать определение понятию облачных вычислений^^^ computing).
Согласно этому документу, есть несколько характеристик облачных технологий, которые наиболее близко характеризуют то, что может считаться облачным. В эти характеристики вошли быстрая масштабируемость, возможность работы в режиме самообслуживания и подсчёт объёмов использованных ресурсов. Соответственно, любые сервисы, которые отвечают такого рода критериям можно относить к облачным.
Облачный Потребитель Облачный Провайдер Облачный
Уровень сервиса Облачный сервис- Брокер
БааБ
менеджмент Л Сервисное посредничество ,
Облачный Аудитор 1аа$
РааБ Поддержка бизнеса 6 о Є о Агрегирование
Аудит Уровень абстракции Провиженинг/ X и га г сервисов
безопасности е Q S
и контроля ресурсов Конфигурирование т а а с Арбитраж
Аудит соблюдения Уровень физических ресурсов компьютерное оборудование Портируемость/ Интероперабельность сервисов
приватности
Аудит производительности Инженерная инфраструктура
Облачный Оператор Связи
Рис. 1. Комбинированная концептуальная диаграмма референтной архитектуры облачных вычислений
В документе выделяются несколько моделей предоставления сервисов облачными системами:
а) программное обеспечение как услуга — Cloud Software as a Service (SaaS). Потребителю предоставляются программные средства — приложения провайдера, выполняемые на облачной инфраструктуре. Приложения доступны с различных клиентских устройств через интерфейс тонкого клиента, такой как браузер (например, электронная почта с web-интерфейсом). Потребитель не управляет и не контролирует саму облачную инфраструктуру, на которой выполняется приложение, будь то сети, серверы, операционные системы, системы хранения или даже некоторые специфичные для приложений возможности. В ряде случаев, потребителю может быть предоставлена возможность доступа к некоторым пользовательским конфигурационным настройкам;
б) платформа как услуга — Cloud Platform as a Service (PaaS). Потребителю предоставляются средства для развертывания (deploy) на облачной инфраструктуре создаваемых потребителем или приобретаемых приложений, разрабатываемых с использованием поддерживаемых провайдером инструментов и языков программирования;
в) инфраструктура как услуга — Cloud Infrastructure as a Service (IaaS). Потребителю предоставляются средства обработки данных, хранения, сетей и других базовых (фундаментальных) вычислительных ресурсов, на которых потребитель может развертывать и выполнять произвольное программное обеспе-
чение, включая операционные системы и приложения. Потребитель не управляет и не контролирует саму облачную инфраструктуру, но может контролировать операционные системы, средства хранения, развертываемые приложения и, возможно, обладать ограниченным контролем над выбранными сетевыми компонентными (например, сетевой экран хоста, управляемого потребителем).
Согласно предоставленным моделям, можно предположить, что особое внимание при организации управления этими моделями должно быть уделено следующим аспектам:
а) уровень операций (Operational Layer): инфраструктура является частью операционной системы, но часто выделяется в облачной архитектуре, поскольку облако накладывает новые требования на инфраструктуру, чтобы обеспечить доступ к общему пулу конфигурируемых вычислительных ресурсов (например, сетей, серверов, систем хранения, приложений и сервисов), которые могут быть быстро предоставлены и освобождены с минимальными усилиями по управлению и необходимостью взаимодействия с провайдером услуг (сервис-провайдером);
б) уровень обслуживания (Service Layer): на этом уровне определяются общие характеристики предоставляемых облачных услуг. Эти характеристики сервисов, как и других услуг, используются для задействования необходимых ресурсов уровня операций;
в) уровень бизнес-процессов: на этом уровне определяется будет ли модель представлена в качестве сервиса или как потребитель услуг;
г) потребительский уровень (Consumer Layer): потребительский уровень более строго отделен от сервис провайдеров и предназначен для объединения или замены облачных сервисов и услуг.
Необходимо также понимать, что проблемы любой сервис-
ориентированной архитектуры, такие как интеграция, обеспечение необходимого качества обслуживания (QoS) и управления являются также важными проблемами для всех решений облачной архитектуры. Среди них особенно выделяется проблема QoS ввиду того, что она накладывает дополнительные требования на «облако» с точки зрения управления и безопасности и при этом, согласно NIST (Mell, Peter, and Tim Grance, 2009), предъявляет требования к самообслуживанию, учету потребленных ресурсов, надёжности, производительности, автоматизации управления, эксплуатации и поддержке предпринимательства. Поддержка управления может быть представлена в виде общей платформы управления (Common Cloud Management Platform, ŒMP) (Ali Arsanjani, Michael Behrendt, Robert Dieckmann, Bernard Glasner, Petra Kopp, Heather Kreger, Stefan Pappe, 2011) в сервис ориентированной референтной архитектуре уровня QoS, которая включает в себя поддержку операций и поддержку бизнеса, иначе OSS и BSS. Это очень важно для управления и эффективного использования при предоставлении различных услуг, основанных на одном фундаменте.
CCMP предоставляет обеспечение внутренних бизнес-процессов операторов связи и состоит из двух основных подсистем — OSS (Operation Support System — система поддержки операций) и BSS (Business Support System — система поддержки бизнеса). Эти подсистемы обязательно должны быть использованы облачными сервисами для запуска в контексте соответствующих услуг
облака и соответствующей инсталляции CCMP. Кроме того, они должны включать в себя пользовательские интерфейсы, выполняющие три основные роли, определенные в референтной модели облачных систем — портал потребителя сервиса (Service Consumer Portal), используемый потребителями облачных услуг для самообслуживания и управления (фактически, экземпляр облачного сервиса, использующий специфический для работы с облаком интерфейс пользователя), портал сервис провайдера (Service Provider Portal), выступающего в роли сервис провайдера для внутренних пользователей и администраторов в повседневной деятельности, и портала развития услуг (Service Development Portal), используемого для создания облачных услуг. Функциональные возможности CCMP также должны быть доступны через API, предоставляемые внутренними компонентами платформы. Следует отметить, что архитектура, описанная в этой работе, является продуктом агностик к актуальным на данный момент программным продуктам, используемым для реализации этой архитектуры.
Рис. 2. Подробная модель CCMP, предлагаемая IBM
Как уже следует из названия, ССМР должна быть структурирована как платформа. Основанная на природе платформы, ССМР предоставляет набор услуг, которые могут (а иногда и должны) быть использованы в контексте конкретной службы облака (рисунок 2). Услуги по управлению, предоставляемые платформой создателям облачных сервисов не следует путать с облачными сервисами, разработанными создателями облачных услуг. Разработчикам облачных услуг настоятельно рекомендуется использовать управление услугами,
предоставляемыми ССМР с целью повышения экономической эффективности, необходимых для достижения высокой степени рентабельности в любой области облачных вычислений.
В связи с этим, также необходимо проводить специальную проверку на предмет совместимости всех программных компонент, имеющих финансовые последствия (осуществляющего биллинг потребления облачных услуг, например). Так как каждый облачный сервис требует усилий при интеграции с финансовой системой, то затраты и сложности, связанные с процессом его аудита, могут быть также очень непростыми. Создание единой развернутой компоненты биллинга, разделяемой между несколькими службами облака — это сложный и трудоёмкий процесс развертывания аудита, который должен быть выполнен один раз так, чтобы затем его можно было использовать для любого количества облачных сервисов, в отличие от развертывания аудита для каждой новой облачной услуги, внедренной в среде без ССМР. Очевидно, что такая концепция совместного доступа позволяет повысить эффективность и применяется не только для службы биллинга BSS, но и для любой службы управления, являющейся частью развернутой ССМР. Ввиду этого, ССМР может определяться как средство общего назначения для управления облачной платформой, предназначенное для поддержки управления любой категорией облачных услуг.
Как уже было сказано, ССМР разделяется на два основных элемента — OSS и BSS. Исторически сложилось так, что эти сокращения были использованы в телекоммуникационной индустрии в контексте обеспечения телекоммуникационно ориентированных услуг. Так как направление облачных вычислений идёт по аналогичному сценарию (предоставление услуг по сети), то будет уместно использовать их в тех же понятиях, как и в телекоммуникационной индустрии. Тем не менее, облачные сервисы, предоставляемые в контексте облачных вычислений, имеют более IT ориентированный характер, чем классические услуги связи.
В классическом мире телекоммуникационных услуг OSS и BSS рассматриваются как система поддержки операций/система поддержки бизнеса, что предполагает своего рода понятие монолитности соответствующего компонента. В противоположность этому, в контексте облачных вычислений OSS и BSS больше рассматриваются как комплекс операционных услуг и автономных услуг поддержки бизнеса, который отражает высокую степень модульности OSS и BSS. Эта архитектурная модульность также позволяет создателям облачных сервисов гибко выбирать реализации различных архитектурных элементов, входящих в ССМР.
Идеальным случаем оптимизации и эффективного использования в перспективе является использование как можно больше общих ССМР с OSS/BSS функциональностью для нескольких облачных сервисов, но из-за изоляции, разницы времени вывода продукта на рынок и появления требований для определенных облачных сервисов это может быть невозможно. В общем, OSS и BSS следует рассматривать как встроенный набор управленческого функционала платформы, лежащей в основе работы любой службы облака.
Все ССМР функции могут быть использованы для последовательного управления облачными сервисами, виртуализированными на любом уровне —
будь то на уровне гипервизора, на уровне операционной системы, уровне платформы или на уровне приложений виртуализации (рисунок 3). В связи с этим, вернемся к такому вышеупомянутому понятию как портал и остановимся на нем подробнее.
Портал — это интерфейс для внешнего мира, будь то клиент, поставщик или партнер. В референтной архитектуре есть три различных портала, которые можно разложить с тем же набором компонентов. Хотя мы и говорим о трёх различных порталах, с архитектурной точки зрения, все три портала могут быть реализованы единой моделью с различными правами доступа и предоставляющей различные возможности, в зависимости от того, кто вошел в систему. Данные категории разбиты на три группы и представляют собой следующее:
а) портал потребительских услуг (Service Consumer Portal). Он позволяет потребителям, бизнес-менеджерам и администраторам управлять своими облачными инструментами в режиме самообслуживания. Портал потребительских услуг предоставляет информацию и функциональность для каталога сервиса (Service Catalog), экземпляра службы управления пользователя или прав управления и отчётности. Портал потребительских услуг не предоставляет сервис-специальной облачной функциональности, т. к. это покрывается за счёт конкретной реализации пользовательского интерфейса этой облачной службы. Например, пользовательский интерфейс для запуска web конференции, отображающий всех участников, не будет тем, что осуществляется в рамках портала потребительских услуг;
б) портал поставщика услуг (Service Provider Portal). Позволяет сервис провайдерам управлять инфраструктурой и использовать компоненты управления, включенные в ССМР;
в) портал развития услуг (Service Development Portal). Служит для создания новых облачных сервисов.
CCMP
UI
BSS
OSS
manages
Application-level
virtualization
Platform-level virtualization
OS-level virtualization
Hypervisor/Infrastructure level virtualization
Virtualization options for Cloud service implementations
Рис. 3. ССМР поддерживает все уровни виртуализации
Также как в OSS и BSS, компоненты портала потребительских услуг и интерфейса пользователя потребительских услуг делятся на платформы и облачные сервисы с независимой частью и облачные сервис-ориентированные определения пользовательского интерфейса, которые могут быть подключены к этой базовой структуре программной системы.
В данном случае BSS будет представлять собой набор бизнес-услуг ССМР, необходимых для создания облачных сервисов. Данное применение обычно обуславливается возможностью повторного использования компонентов услуг уже указанных в контексте ССМР, и предполагает следующие результаты:
а) позволяет снизить необходимость в уникальных разработках новых сервисов и уменьшает общие расходы на поддержку системы;
б) приведет, вероятно, к тому, что облачные сервисы будут совместимы с другими службами облака, предоставляя клиенту еще больше экономии за счёт эффективного использования при масштабном применении большого количества сервисов;
в) стандартные компоненты и пользовательские интерфейсы позволят сократить сложность, упростить операции и сделать облачные решения более простыми в использовании.
Как и любой компонент ССМР, BSS является общей для всех типов облачных сервисов и может быть сконфигурирована необходимым образом в соответствии с контекстом услуг, поставляемых облаком. Так, например, биллинговая служба ССМР BSS должна иметь возможность создания биллинга использования виртуальных машин (IaaS), биллинга мульти-аренды для размещения промежуточного ПО и услуг для совместной работы (SaaS). Это ведет к необходимости надлежащего определения всех компонентов BSS на уровне платформы и использованию экспериментальных результатов с целью достижения необходимого поведения каждой компоненты BSS при предоставлении облачных услуг.
OSS представляет собой набор оперативного управления техническими услугами, предоставляемыми ССМР и необходимыми для реализации облачных сервисов.
Многие домены управления, представленные в OSS, могут возникнуть в традиционно управляемых центрах данных (мониторинг и управление событиями, инциденты и проблемы управления и т. п.), но есть некоторые компоненты, которые являются новыми и довольно специфичными для степени автоматизации и эффективности связанной с облаками. В частности для «традиционных» доменов управления важно отметить, что принципиально они такие же как в привычном всем понятии, так и в контексте облачных вычислений, с отличием в том, что в контексте облачных вычислений они реализуются совершенно иными путями, пользуясь высокой степенью однородности в облаке. Например, традиционно управляемый центр обработки данных реализован таким образом, что, в случае выхода из строя, администратору подается заявка на восстановление, и через некоторое время могут возникнуть сложности в случае
невыполнения этой заявки. С другой стороны существует и проблема управления для типичных VMaaS(Virtual Mashine as a Service, виртуальная машина как услуга) услуг, только тут в случае выхода из строя физического компьютера, виртуальная машина, работавшая на нем, начинает работать на другом. Конечно, это возможно только при наличии соглашения об уровне обслуживания облачной службы VMaaS, разрешающего подобные действия. Оба сценария описанного выше инцидента адресуются в сторону проблем управления, но совершенно отличаются способами их решения и радикально отличаются затратами на рабочую силу и SLA. Подобные «облачные» точки зрения существуют и для большинства других компонентов OSS.
Согласно положениям комплексного анализа экосистемы облачных услуг в России (IDC, 2011), объём российского рынка облачных услуг (публичных и частных) в 2010 году составил 35,08 млн долл. США. Данный рынок в настоящее время невелик, но его ожидаемые темпы роста должны существенно превысить аналогичные показатели по всему рынку ИТ-услуг в 2011-2015 годах. По прогнозам IDC, к концу 2015 года объём российского рынка облачных услуг превысит отметку в 1,2 млрд долл., демонстрируя среднегодовой темп роста более 100 %.
Среди продуктов, на базе которых были построены наиболее популярные в России SaaS-решения, отмечены продукты компаний Microsoft, Salesforce.com, Google и Oracle. Среди дистрибуторов-провайдеров упомянуты российские компании CT Consulting, Softline, «Мегаплан», «Техносерв Консалтинг».
Среди наиболее успешных поставщиков IaaS-решений в отчёте названы такие компании как Parking.ru, Oversun Scalaxy, IT Grad и Softline. Список лидирующих поставщиков услуг по предоставлению услуг частного облака возглавили HP, IBM, «КРОК», I-Teco и «Астерос».
Из вышеизложенного можно сделать вывод о четкой тенденции развития облачных вычислений, ведущей к конвергенции ИТ и телекоммуникаций, подразумевающей под собой новые принципы построения управления инфоком-муникационными сетями в соответствии с её реалиями а также новую идеологию использования уже существующих инфраструктур телеком провайдеров.
Литература
1. Mell, Peter, and Tim Grance. «Draft NIST Working Definition of Cloud Computing, version 15» National Institute of Standards and Technology, October 7, 2009.
2. Ali Arsanjani,Michael Behrendt, Gerd Breite, Robert Dieckmann, Bernard Glas-ner, Petra Kopp, Heather Kreger, Stefan Pappe «Introduction and Architecture Overview IBM Cloud Computing Reference Architecture 2.0», 2011.
3. Fang Liu, Jian Mao, Jin Tong «NIST Cloud Computing Reference Architecture Version 1», 2011.
4. Peter Mell, Timothy Grance NIST Special Publication 800-145 «The NIST Definition of Cloud Computing», 2011.
M. I. Pavlov
SOME ASPECTS OF CLOUD COMPUTING IN THE MANAGEMENT OF INFOCOMMUNICATION NETWORKS
This article defines the issues that require attention in the construction of cloud systems for operator’s services, presents the structural features of data management services and gives estimate the prospects of this trend in the market of information technologies and telecommunications services.
Keywords: business support system, cloud computing management platform.
Павлов Михаил Иванович — соискатель при аспирантуре по кафедре «Вычислительная техника» ФГБОУ ВПО ПсковГУ, начальник бюро ОНТ ОАО «ПЗ АТС-Т», freeman.47@mail.ru.
УДК 50(075.8)
А. Н. Верхозин
ИНТЕРПРЕТАЦИЯ КВАНТОВОЙ МЕХАНИКИ
Дан краткий обзор основных представлений (интерпретаций) квантовой механики. Каждая из рассмотренных интерпретаций содержит ряд спорных положений, обсуждение которых позволяет выработать свое понимание механизма парадоксальных квантовых явлений. Статья адресована студентам-экономистам, изучающим концепции современного естествознания, и всем читателям, интересующимся вопросами: «Какая реальность стоит за гранью квантово-механического эксперимента?» или: «Действительно ли наше восприятие в некотором смысле формирует физический мир?» Автор полагает, что развитие квантовых информационных технологий невозможно без ответа на эти фундаментальные вопросы.
Ключевые слова: квантовая механика, проблема измерения, волновая функция, не-локальность, запутанные состояния, квантовая томография.
Введение.
Надо ли интерпретировать квантовую механику? Многие скажут, что не надо. Например, Л. Д. Ландау очень не одобрял такие занятия. Но если признать эту установку правильной, то можно свести физику до уровня поварского дела: соблюдай «рецепты», решай задачи и не занимайся ерундой! Однако, решение прикладных задач — важный, но не единственный аспект квантовой механики. Не менее, а, может быть, и более важно понять глубинный смысл парадоксальных квантовых явлений. Без этого понимания нельзя представить себе прогресс квантовой информатики, начинающей практически осваивать новые технологии. Но и это еще не все. Ведь поразительные открытия последних лет говорят о том, что мы находимся на пороге смены физической картины мира и постижения тайны человеческого сознания. Понимая это, многие светлые умы
