Содержание к диссертации
Введение
ГЛАВА 1 Анализ систем облачных вычислений с web интерфейсом 16
1.1 Общая характеристика облачных вычислений 16
1.2 Классификация облачных сервисов 21
1.3 Модели построения облачных систем 23
1.4 Приложения облачных вычислений c Web-интерфейсом 25
1.5 Фильтры и сервлеты 27
1.6 Критерии оценивания облачных систем 29
1.7 Постановка задач исследования 1.7.1 Содержательная постановка задачи исследования 33
1.7.2 Математическая постановка задачи исследования 34
Выводы по разделу 35
ГЛАВА 2. Модели многоканальных не марковских СМО с «Охлаждением» 37
2.1 Классификация систем массового обслуживания 37
2.2 Характеристика методов анализа СМО 41
2.3 Учет воздействия «охлаждения» на работу СМО 44
2.4 Аппроксимация с помощью распределений фазового типа 46
2.5 Диаграммы и матрицы переходов для моделей СМО с «охлаждением»
2.5 Модель облачных вычислений с Web-интерфейсом на основе СМО с «охлаждением» 59
2.6 Метод расчета распределения времени ожидания в очереди
2.6.1 Характеристика методов расчета времени ожидания 64
2.6.2 Метод расчета ПЛС времени ожидания заявки в очереди 69
Выводы по разделу 71
ГЛАВА 3. Программная реализация и тестирование моделей многоканальных смо с «охлаждением» 73
3.1 Описание программной реализации з
3.2 Общая характеристика программного комплекса 74
3.3 Состав комплекса 75
3.4 Подход к тестированию комплекса программ 76
3.5 Взаимная проверка результатов вычислений
3.6.1 Особенности разработки имитационных моделей СМО 80
3.6.2 Особенности алгоритма и программной реализации 84
Выводы по разделу 89
ГЛАВА 4. Практическое применение результатов исследований 90
4.1 Обучение в облачной модульной объектно-ориентированной динамической учебной среде Moodle 90
4.2 Проект ООО «1C - Scloud» 100
4.3 Данные по внедрению результатов исследований 106
Выводы по разделу 109
Заключение 110
Приложение а.исходные тексты основных функций комплекса программ расчета характеристик многоканальных смо 123
- Приложения облачных вычислений c Web-интерфейсом
- Диаграммы и матрицы переходов для моделей СМО с «охлаждением»
- Подход к тестированию комплекса программ
- Данные по внедрению результатов исследований
Приложения облачных вычислений c Web-интерфейсом
Все, что имеет отношение к сloud computing, принято называть словом 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 ("ПО как сервис"). Представляет «программное обеспечение по требованию», развернутое на удаленных серверах и каждый пользователь имеет возможность с помощью Интернета получать доступ. Поставщиком этой услуги регулируются вопросы обновления и лицензий на это обеспечение. Оплата выполняется за фактическое использование этого ПО. Примером являются GoogleDocs, GoogleCalendar и подобные онлайн-программы. Platform-as-a-Service ("платформа как сервис") Предоставляется компьютерная платформа с установленной операционной системой и определенным программным обеспечением. Integration-as-a-Service ("интеграция как сервис") Модель доставки Integration-as-a-Service обеспечивает интеграцию в облаке. Это позволяет совместно использовать данные в системах, а также сторонних поставщиков в режиме реального времени. Сюда входят услуги и функции пакетов централизации, оптимизации и интеграции корпоративных приложений, но предоставляемые как "облачный" сервис. Предприятия используют инициативы Integration-as-a-Service, чтобы повысить гибкость и автоматизировать бизнес-процессы. Security-as-a-Service ("безопасность как сервис")
Эта услуга дает возможность быстро развертывать продукты, позволяющие обеспечить безопасное использование Web-технологий, электронной переписки, локальной сети, что позволяет пользователям этого сервиса экономить на развертывании и поддержании собственной системы безопасности. Management/Governace-as-a-Service ("администрирование и управление как сервис")
Услуга обеспечивает управление и задание параметров работы одного или многих "облачных" сервисов. В основном такие параметры, как топология, использование ресурсов, виртуализация. Infrastructure-as-a-Service ("инфраструктура как сервис") Услуга предоставления по запросу необходимого пользователю количества динамических ресурсов (вычислительных и хранилища), виртуальных серверов, сетевой инфраструктуры, удаленных рабочих мест на основе облачных вычислений. Позволяет оптимизировать использование арендуемых мощностей. Testing-as-a-Service ("тестирование как сервис") Услуга позволяет тестировать локальные или "облачные" системы с использованием тестового ПО из "облака" (при этом никакого оборудования или обеспечения на предприятии, не требуется).
При построении облачных систем используют три основные модели: Публичное облако — ИТ-инфраструктура, используемая одновременно множеством компаний и сервисов. Ответственность за управление и обслуживание "облака" лежит на владельце ресурса, то есть провайдере. Абонентом предлагаемых сервисов может быть любая компания и индивидуальный пользователь. Примерами служат онлайн-сервисы: AmazonEC2, GoogleApps/Docs, MicrosoftOfficeWeb. Частное облако — безопасная ИТ-инфраструктура контролируемая и эксплуатируемая организацией, которая включает в себя несколько потребителей. Организация может управлять частным "облаком" самостоятельно или поручить это третьей организации. Инфраструктура может размещаться либо в помещениях заказчика, либо у внешнего оператора (либо частично у заказчика и частично у оператора).
Гибридное облако — ИТ-инфраструктура, использующая наилучшие качества публичного и приватного облака при решении поставленной задачи. Этот вид используется в основном случаях, когда у организации появляются сезонные периоды активности, иными словами, как только внутренняя ИТ-инфраструктура не справляется с текущими задачами, часть мощностей перебрасывается на публичное "облако" (например, большие объемы статистической информации), а также для предоставления доступа пользователям к ресурсам предприятия через публичное "облако" рисунок 1.3.1.
Диаграммы и матрицы переходов для моделей СМО с «охлаждением»
При исследовании моделей СМО с «охлаждением» при классификации будет удобным ввести дополнительное обозначение С, которое указывает вид распределения длительности «охлаждения». Соответственно, СМО с «охлаждением» определяется набором A/S/C/n , где A – входной поток, S – характеристика длительности обслуживания, C – характеристика длительности охлаждение, n – число каналов в СМО.
Наилучшим образом изученные модели – это те, в которых имеется до n каналов, и в которых распределения времени обслуживания и времени между постановками в очередь следуют экспоненциальному распределению M/M/n. В силу сделанных предположений такие модели, известные, как Марковские модели, имеют ограниченное применение и не подходят для наш работа. Наиболее изученными являются относительно простые модели M/M/n. Самый простой пример – это очередь M/M/1, для которой в руководствах по оценке производительности обычно приведены результаты для расчета установившегося распределения количества запросов.
Другой хорошо изученный класс – это системы очередей с измеренными механизмами обслуживания, описываемые Kaczynski в [14]. Mjgan Zobu и Vedat Salam [15] использовали последовательный критерий отношения вероятностей (SPRT - ПСКВ), в котором они исследовали две различные системы очередей многофазного типа, состоящие из гиперэкспоненциального и смешанного Эрланга. Самый активный интерес в последнее время был сфокусирован на исследованиях многоканальных не Марковских очередей, в которых потоки аппроксимированы по многофазному распределению. Например, Бубнов В.П., Хомоненко А.Д. и Тырва А.В. в [16] рассматривают модель С2/M/n с распределением Кокса для определения характеристик надежности программного обеспечения, таких, как количество исправленных ошибок, необходимого периода отладки и т.д. Brandwajn и Begin в [17] предлагают получисленный подход к расчету распределения установившегося значения вероятности для ряда запросов в любой момент времени и в момент постановки в очередь в системах типа Ph/M/c.
Описанная в настоящей статье не Марковская система очередей с «охлаждением» требует более сложного математического описания по сравнению с Марковскими моделями, например, поток запросов может быть повторяющимся или представленным произвольной стохастической функцией. Примеры предыдущих работ о системах очередей с прогревом даны Kolahi в [18] или Kreinin в [19]. Анатолий Хомоненко, Сергей Гиндин [20] использовали не Марковскую многоканальную систему с «разогревом» для оценки производительности облачного учета расходов на информационную безопасность. Они также разработали стохастические модели оценки производительности облачного вычисления путем изучения многоканальных систем с прогревом и гиперэкспоненциальной многофазной аппроксимации не Марковских процессов [21].
Для повышения точности вероятностного анализа при моделировании требуется применять реалистичные, следовательно, и более общие предположения о типах распределений составляющих процессов. В статистике широко используются гамма-распределение, равномерное, распределение Стьюдента и другие типы не Марковских вероятностных распределений.
При расчете сложных не Марковских систем обслуживания обычно осуществляется сведение исходного не Марковского процесса к Марковскому. Примером такого сведения является метод вложенных цепей Маркова: он заключается в выделении в ходе процесса моментов восстановления, в которые система обладает Марковским свойством.
Исходя из работы Кокса [11], для произвольных не Марковских вероятностных распределений может быть выполнена аппроксимация с использованием распределений фазового типа.
Преимуществом данного подхода является то, что обеспечивается наглядное представление аппроксимирующего случайного процесса в виде комбинации Марковских фаз, применимость к любому вероятностному процессу, легкость записи системы уравнений баланса, описывающих поведение соответствующей модели. Деление на фазы в данном случае не более чем математический прием, полезный при исследовании неэкспоненциальных распределений, оно не имеет физического смысла, относительно природы рассматриваемого случайного процесса.
Суть метода Кокса аппроксимации распределениями фазового типа состоит в следующем: рассматривается исходное не Марковское распределение СМО (длин интервалов между смежными заявками входящего потока, длительности «охлаждения», обслуживания). Рассматриваемое распределение заменяется одним из следующих распределений фазового типа:
Подход к тестированию комплекса программ
Сложность представленных методов анализа многоканальных СМО с «охлаждением» даже для Марковского случая и слабая теоретическая проработка методов расчета систем с немарковским обслуживанием и «охлаждением» вызвали необходимость создания эталонной имитационной модели.
Аналитические методы позволяют исследовать относительно небольшой круг задач массового обслуживания. При этом имитационное моделирование позволяет воспроизводить любой Марковский процесс в целях анализа или оптимизации системы.
Система моделируется путем прослеживания характерных событий в модельном времени, для каждого из которых создается ряд программ обработки событий. Эти программы подробно описывают изменения состояний, происходящие при наступлении каждого события. Развитие моделируемой системы во времени осуществляется путем выполнения программ обработки событий в порядке возрастания времени их возникновения, причем внутри подпрограмм модельное время не продвигается.
Процесс – это упорядоченная последовательность взаимосвязанных и разделенных промежутками времени событий, отражающая полный «жизненный путь» объекта в системе. Реализации процесса моделируются на ЭВМ при помощи нескольких серий случайных или псевдослучайных значений. Для работы с моделью, в зависимости от целей исследования, строится по текущему значению счетчика, который связан с данной целью. При помощи методов математической статистики возможно получить оценки искомых характеристик, усредненяя результаты моделирования по времени работы модели, а так же по числу реализаций самого процесса. Имитационная модель состоит из элементов, которые взаимодействуют между собой элементов: 1) состояний; 2) датчиков случайных чисел; 3) событий; 4) таймера; 5) счётчиков; 6) цепей событий; 7) блока инициализации; 8) цели моделирования; 9) критерия остановки; 10) методов обработки результатов. Для вероятностного продолжения процесса моделирования необходимо определить состояние системы с необходимой и достаточной степенью детальности. При этом состояние СМО задается текущим количеством заявок в ней, фазами прибытия, «охлаждения», текущим обслуживанием и моментами появлением каких либо ближайших событий.
В качестве события в модели используется скачкообразное изменение её состояния. При этом события могут быть первичными (прибытие заявки, завершение обслуживания или «охлаждением») и вторичными (по отношению к прибытию – прием заявки на обслуживание или постановка в очередь; по отношению к уходу – движение в очереди и т. п.), которые наступают как результат первичных событий. Для формирования в модели очередных состояний, таких как моменты наступления следующих первичных событий какого либо вида, используются датчики случайных чисел. Генерация случайных величин производится в соответствии с соответствующими законами распределения.
Непосредственно процесс имитирования происходит в системном (модельном) времени. Для подсчета данного системного времени используются, так называемые, таймеры.
Для моделирования необходимо, чтобы программа выстраивала последовательность событий с учетом их зависимости между собой. Непосредственно в процессе обработки цепей событий выстраивается сама логика модели. События наступающие одновременно с учетом системного времени, такие как: продвижение в очереди, уход обслуженной заявки из системы, выбор для обслуживания первой заявки очереди, формирования момента «охлаждения» или завершения обслуживания, находятся в цепи текущих событий. Очевидно, что последовательность обработки данных событий должна быть жестко определена. А цепь будущих событий состоит из событий, которые запланированы ранее на следующие моменты модельного времени (окончание обслуживания в других каналах, прибытие последующих заявок и т. п.). Цепь задержанных событий состоит из событий, которые прерваны из-за сложившихся в данный момент системного времени в системе условиями (такими как, занятость требуемых ресурсов).
В зависимости от момента наступления соответствующего события цепи делятся на упорядоченные или неупорядоченные. В неупорядоченную цепь легко добавляется новое событие, но при этом после выборки или добавления необходимо ее просмотреть для поиска более раннего события. Целесообразно просматривать с конца или использовать половинное деление, когда осуществляется вставка очередного события в список, который упорядочен по моментам наступления событий.
В узком смысле слова целью моделирования является определение показателей качества функционирования системы во время построения модели. Существенное влияние на структуру модели оказывает выбор цели с использованием счётчиков, необходимых для накапливания результатов имитационного моделирования. Так, при подсчете среднего времени для начала обслуживания необходимо иметь счетчики общего времени «охлаждения» и числа заявок, которые выбраны для обслуживания.
Для остановки цикла моделирования в определенный момент используется критерий остановки. Для упрошенного случая используется достижение заданного значения таймера, счетчика числа обслуженных заявок и т. п.
При обработке результатов имитационного моделирования производится сжатие полученной информации, расчет статистических оценок (точечных и интервальных), таких как математическое ожидание и высшие моменты искомых показателей.
Для создания имитационной модели СМО с «охлаждением» заявками в диссертации применялся язык программирования VisualFortran, поскольку применение традиционных сред имитационного моделирования (GPSS, AnyLogic и т.д.) для решения данной задачи ограничено по следующим причинам:
Данные по внедрению результатов исследований
Облако 1C (SCLOUD) позволяет избежать издержек с коробочной версией программы: покупку лицензии 1C, сервера, лицензии Microsoft, оплату подписки на ИТС, услуг системного администратора.
В общей сложности, облачная бухгалтерия позволяет сэкономить свыше 130 000 рублей по сравнению с коробочной версией. Для небольшого предприятия, стартапа или начинающего бизнеса такая экономия покажется настоящим подарком судьбы.
Еще одним плюсом ведения бухгалтерии в режиме онлайн является мобильность и надежность. Теперь пользоваться 1C можно в любом месте и в любое время, при этом гарантия сохранности данных на сервере будет в разы выше, чем на жестком диске стационарного компьютера.
SCLOUD - это облачная система для работы с программой 1С из любой точки мира. Компания существует уже боле 11 лет в сфере информационных технологий. Больше 5500 бизнесов уже доверились сервису SCLOUD. В системе есть тестовый период на 15 дней для оценки функционала и техподдержка.
Для управления бизнесом с помощью 1С в онлайн-режиме. Можно быстро загрузить базу с локального компьютера на сервер SCLOUD или выгрузить ее обратно на компьютер. Вся информация содержится в сохранности на защищенных серверах, см. рисунок 4.2.1.
Проект ООО «Scloud» представляет собой распределенное приложение для дистанционного управления финансами, позволяющее управлять счетами, а также осуществлять платежи и переводы через сеть Интернет, управлять лимитами по операциям. Система предоставляет средства в режиме реального времени информацию и средства управления, финансовую и бухгалтерскую отчетность, необходимый документооборот. Для оценивания оперативности функционирования ИС решены задачи построения подходящей модели и задания исходных данных для моделирования.
При построении модели учитывались следующие критерии. Во-первых, этап жизненного цикла ИС, на котором выполнялось моделирование. Данная система находилась на этапе тестирования, для моделирования использовались собранные сведения о его параметрах и результатах: длительностях интервалов времени между последовательными заявками, продолжительность выполнения тестовых сценариев. Во вторых, при получении требуемых для моделирования исходных данных учитывалась архитектура ИС: информация о количестве модулей, среднем времени их исполнения, вероятностях переходов между ними.
При испытаниях ИС с использованием пакета имитационного тестирования Apache JMeter собрана статистика по работе системы с 300 тестовыми пользователями, параллельно и независимо выполнявшими запросы различного рода:
Дополнительные расходы в системе на организацию Web-интерфейса включают расходы на кеширование для структуры динамически считываемого меню, и разнообразных справочников, используемых для проведения операций.
Программным комплексом было рассчитано и показано, что для системы очередей М/М/М/n с «охлаждением» со стабильным входным потоком изменения в поведении ожидаемого времени ожидания в очереди Wq и ожидаемое время в системе - W при изменении интенсивности охлаждения показана на рисунке 4.2.2. Параметры для этого расчета: X = 4,0, ц= 1,8, цс = от 0,5 до 3,5. тс=0.5 тс=1 тс=1.5 тс=2 тс=2.5 тс=3 тс=3.5 DL DLq Рисунок 4.2.2 Среднее число заявок в очереди и в системе M/M/M/n с "охлаждением" Расчеты с помощью программного комплекса также показали, что для Ег/M/M/n СМО с «охлаждением» и исходными параметрами моделирования были: A,i = 1, Х2 = 3, \х= 1,8, цс = в диапазоне от 0,5 до 3,5, Имели следующие результаты, показанные на рисунке. 4.2.3 и 4.2.4. 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 J 0,5 1,5 2 2,5 Интенсивность охлаждение (цс) З 3, W Wq Рисунок 4.2.3 Среднее время ожидания и пребывания в E2/M/M/n с "охлаждением" Дополнительно проводилось тестирование для граничных значений n – числа каналов в СМО. Результаты проверялись для n = 1 и n = 70, в последнем случае расчеты подтвердили ожидаемое сближение результатов для различных распределений длительности ожидания.
Модель многоканальной СМО типа E2/M/M/n с «охлаждением» покрывает множество значений коэффициента вариации 0,7 – 0,99; модель многоканальной СМО типа H2/M/M/n охватывает значения коэффициента вариации в диапазоне 1,5 – 4,9. Пограничным значением коэффициента вариации является 1. Это позволяет нам прийти к выводу о согласованности результатов вычисления стационарных распределений с помощью моделей многоканальных СМО с «охлаждением».
Другой вариант проверки корректности моделей СМО типа Е2/М/М/п и Hг/M/M/n с «охлаждением» состоит в следующем: задаем при проведении численных расчетов очень большое значение интенсивности «охлаждения», например, цг = [іЛ105. Это означает что «охлаждение» СМО происходит мгновенно, и соответствующие СМО можно сравнивать с многоканальной не Марковской СМО типа GI/M/M/n с рекуррентным входящим потоком заявок и без «охлаждения».
Полученная полнота тестирования комплекса, положительные результаты тестирования позволяют считать программную реализацию корректной в рассмотренном диапазоне значений исходных параметров. Согласованность практических результатов на разных моделях указывает на надежность и обоснованность теоретических основ разработанных алгоритмов.
На рисунке 4.3.5 приведены распределения времени пребывания заявки в системе облачных вычислений с учетом «охлаждения» и без него. На основании приведенных графиков можно сделать вывод о том, что при учете влияния времени «охлаждения» точность расчета характеристик оперативности обработки информации в системе облачных вычислений повышается на 7-15%. А при планировании необходимых вычислительных ресурсов ПС наблюдается повышение точности до 10%