Scientific journal
Fundamental research
ISSN 1812-7339
"Перечень" ВАК
ИФ РИНЦ = 1,674

ANALYSIS OF SERVICE OPTIONS FOR CLOUD IT SERVICES ON THE BASIS OF AN SIMULATION MODEL

Razumnikov S.V. 1
1 Yurga Technological Institute (branch) of the National Research Tomsk Polytechnic University
When introducing cloud technologies, it is important to understand how services will behave in work. It is advisable to predict this and decide on the service at the design stage or immediately after implementation. This article presents an algorithm for constructing a simulation model for analyzing options for servicing cloud IT services and substantiates the possibility of using simulation to choose a service strategy. An example is given of computer experiments to simulate the number of completed processes by a cloud service for two possible work strategies. A comparison is also made of the calculations by the simulation model and the analytical one. These calculations give different values, but a similar result. It was noted that the analytical method does not have the flexibility that is inherent in simulation, and it can be problematic, as there may be difficulties in the calculations. The set parameters for the simulation model can be quickly and simply changed in accordance with the new source data and get a new solution. The presented simulation model for analyzing cloud IT service maintenance options is very well applied in work related to recommendations on the methodology for choosing a particular cloud IT service maintenance strategy for various task parameters.
simulation model
choice of service options
analysis
cloud technologies

Рынок облачных технологий уверенно растет и ежедневно обретает новых пользователей [1, 2]. При внедрении облачных технологий необходимо наличие стратегического плана, который может помочь правильно поставить перед ИТ-цели и увидеть их достижение, контролировать и корректировать движение к достижению результата [3, 4]. Этот план важен не только на стадии задания цели, но и после внедрения, на стадии сопровождения. В помощь в управлении работой облачных сервисов может служить математическое моделирование экономических процессов. Так имитационное моделирование позволяет не только и не столько выполнять быстрые и безошибочные вычисления, сколько проводить многовариантный анализ функционирования и развития экономических систем как в реальных, так и в гипотетических, виртуальных условиях непосредственно под управлением и с участием экспертов [5, 6].

Цель работы – разработать имитационную модель для анализа вариантов обслуживания облачных ИТ-сервисов. Для этого рассмотрим задачу выбора стратегии наиболее рационального варианта технического обслуживания облачных ИТ-сервисов. Инструментом для анализа вариантов будет являться имитационная модель «поведения» сервиса.

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

«Ухудшенное» состояние облачного сервиса говорит о том, что он может продолжать свою работу, т.е. возникла некая некритичная неисправность [7]. Известно, что устранение такой неисправности заняло бы время выполнения одной операции (можно предположить, что стоимость такого одного ремонта будет равна стоимости одной невыполненной операции). Восстановительная работа будет производиться по окончанию процесса, при котором произошла поломка и далее будет занимать все время выполнения следующей операции.

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

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

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

ИТ-отдел предприятия может дать указания пользователям облачных сервисов строго придерживаться одной из следующих стратегий (правил) по ремонту облачных сервисов (обозначим эти стратегии, как α и β):

Стратегия α – «выполнять ремонт маленьких неисправностей сразу же, как только сервис перейдет в «ухудшенное состояние».

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

Отметим, что «ухудшенное» состояние может носить временный характер и связано, как правило, с пропускной способностью сети. Интуитивно ИТ-отдел предполагает, что среднее число выполненных операций, а следовательно, и общие издержки зависимы от реализации определенного правила эксплуатации. Поэтому поставлена следующая проблема: выявить стратегию эксплуатации облачного сервиса из числа предложенных стратегий, α и β, при которых будет обеспечиваться максимум среднего числа операций (процессов) в день.

Формулирование модели

«Поведение» любого облачного сервиса в данной задаче представим множеством следующих вполне устойчивых состояний (положений):

1 состояние: «сервис исправен полностью»;

2 состояние: «сервис в ухудшенном состоянии»;

3 состояние: «сервис полностью неисправен».

Состояния 2 и 3 обозначим буквами A и B, а вероятности перехода в них – PA и PB.

Тогда все возможные состояния и переходы между состояниями можно представить в виде графа переходов (рис. 1).

Raz1.tif

Рис. 1. Граф перехода состояний облачного сервиса

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

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

Эксплуатационную политику β изобразим графом более сложным (рис. 3).

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

Таблица 1

Состояние облачного сервиса в конце выполнения процесса

Сервис начинает выполнять процесс в состоянии

Сервис завершает процесс в состоянии

Исправное

А

В

Исправное

А

a ≤ R < 1

       –

0 ≤ R < a

b ≤ R < 1

        –

0 ≤ R < b

где R – случайное число, равномерно распределенное в интервале (0; 1).

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

К примеру, облачный сервис выполняет процесс в состоянии А. Если найденное значение R будет удовлетворять неравенству R ≥ b, то облачный сервис закончит выполнение своих процессов в состоянии А. При этом: razum01.wmf

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

Raz2.tif

Рис. 2. Эксплуатационная политика стратегии α

Raz3.tif

Рис. 3. Эксплуатационная политика стратегии β

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

Алгоритм (блок-схема) имитационной модели

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

Raz4.tif

Рис. 4. Алгоритм имитации α и β-стратегий обслуживания облачных ИТ-сервисов

На блок-схеме указаны следующие обозначения:

SG1 – логическая переменная, которая обозначает «хорошее состояние при α-стратегии»; она может принимать значение 1, если облачный сервис будет находиться в хорошем состоянии при α-стратегии; значение 0, если облачный сервис при α-стратегии находится в положении А;

SG2 – логическая переменная, которая обозначает «хорошее состояние при α-стратегии»; принимает значение 1, если облачный сервис будет находиться в хорошем состоянии при β-стратегии, и 0, если облачный сервис в положении А;

SB2 – логическая переменная, отвечающая за «положение В при α-стратегии»; будет равна 1, если облачный сервис будет находиться в положении В β-стратегии, и 0 в других случаях;

DMAX – это число моделируемых дней;

D – текущее число дней при проведении моделирования;

RM – это число процессов в день при моделировании, включая отдельные процессы;

RA, RB – число реально выполненных процессов (операций) в течение дня при α и β стратегиях соответственно;

SRA, SRB – это общее число процессов (операций) в течение дней D при α и β стратегиях соответственно;

Z = (RA – RB) – разность между числом реально выполненных процессов при различных стратегиях;

SZ – это сумма значений Z за D дней.

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

В настоящее время используется аналитическое решение рассматриваемой задачи, т.е. формулы, которые определяют среднее количество процессов Mα и Mβ. Для понятной записи формул определим:

а – значение вероятности РА перехода в положение А;

b – значение вероятности РB перехода в положение B.

Таким образом, среднее количество операций при двух стратегиях определяется следующими соотношениями [5, 6]:

razum02.wmf

razum03.wmf

где N – это планируемое число выполнения операций в день.

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

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

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

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

1. Разработаем и реализуем алгоритмы моделирования (рис. 4) применения стратегий α и β. Исходные данные выберем следующие: пусть будет у нас N = 14 операций в день, Т = 70 дней, вероятность α-стратегии PA = 0,09, вероятность b-стратегий PB = 0,19. Моделирование произведем с использованием прикладного программного продукта Microsoft Excel

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

3. Произведем аналитический расчет среднего количества процессов для стратегий α и β, используя формулы 1 и 2.

razum04.wmf

razum05.wmf

С учетом Т = 70, получим: Мa = 904, Мb = 768.

Таблица 2

Эксперименты по моделированию количества выполненных процессов

Эксперименты

Выполнено операций по a-стратегии

Выполнено операций по β-стратегии

Вероятность

Аср*PА

Вср*PB

1

835

859

0

0

0

2

835

763

0,05

42

41

3

829

798

0,1

84

83

4

835

830

0,15

126

124

5

833

833

0,2

167

166

6

839

801

0,25

209

207

7

836

831

0,3

251

248

8

840

783

0,35

293

290

9

837

828

0,4

335

331

10

839

775

0,45

377

373

11

837

785

0,5

419

414

12

843

836

0,55

460

455

13

831

839

0,6

502

497

14

844

811

0,65

544

538

15

837

791

0,7

586

580

16

842

884

0,75

628

621

17

835

895

0,8

670

662

18

840

833

0,85

712

704

19

840

909

0,9

753

745

20

835

875

0,95

795

787

Среднее значение

837

828

1

837

828

 

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

Заключение

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

Работа выполнена при финансовой поддержке гранта РФФИ № 18-07-00031 «Модели, алгоритмы и программное обеспечение системы поддержки принятия стратегических решений к переходу на облачные технологии».