CC BY
10
БОТ: 10.15587/2312-8372.2017.118388
РОЗРОБКА МОДЕЛ1 ВИБОРУ ОПТИМАЛЬНО! КОНФ1ГУРАЦП КОМ-ПОНЕНТ1В АРХ1ТЕКТУРИ КРИТИЧНО! 1Т-1НФРАСТРУКТУРИ ПРИ !! ПРОЕКТУВАНН1
Дорогий Я. Ю.
1. Вступ
Щоб конкурувати на глобальному ринку, шдприемства все бтьше взаемодь ють з партнерами та замовниками за межами свой краши походження. Мета глоба-лiзацii операцiй - скорочення витрат, отримання робочо!' сили та досвщу, а також доступу на новi ринки.
У рамках свое1' глобальноi стратегii та структури багато шдприемств створю-ють дочiрнi шдприемства в шших краiнах. Пщприемство повинно визначити, в якiй мiрi кожна фшя е самодостатньою та незалежною вщ штаб-квартири при прийняттi рiшень. Покращення фiнансовоi ефективностi вiдбуваеться при активнш реакцп фiлii на змiни локального ринку, i навпаки, у випадку слiдування стандартизованим глобальним бiзнес-процесам таке покращення е малоймовiрним [1]. У той же час, надання дозволу фiлii приймати рiшення без втручання штаб-квартири може ство-рити напругу у вiдносинах, особливо щодо ршень, що пов'язанi з проектуванням та управлшням IT-iнфраструктури. Пiдприемства формують свою бiзнес-стратегiю через сво!' механiзми управлшня, а потiм узгоджують сво!' шформацшш ресурси для пiдтримки бiзнес-стратегii. Перехщ до децентралiзованого пiдходу дае можливють компаншм використовувати сво! 1Т-ресурси для реагування на умови, що виника-ють на мiсцевому ринку, в той же час, е ризик в тому, що швестицп в 1Т можуть не сп1впадати з загальною бiзнес-стратегiею пiдприемства. Такий недолж може збть-шити ймовiрнiсть витрат фшансових ресурсiв, незадоволенiсть користувачами, не-вдачi управлiння безпекою, створення менеджерiв, якi не хочуть iнвестувати в май-бутнi IТ-iнiцiативи i, зрештою, пiдiрвати кiнцевий фiнансовий результат. Саме тому, багато пiдприемств мають глобально-централiзованi процеси прийняття рiшень щодо ГГ-шфраструктури, особливо пiдприемства критично1' шфраструктури. Основна мета - зменшення ризикiв, оптимiзацiя розпод1лу ресурсiв, задоволення корис-тувачiв, посилення контролю та шдтримки стратегii компанii [2].
Основним аргументом в шдтримку централiзованого проектування та управ-лiння IТ-iнфраструктурою е можливють учасп у прийняттi ГГ-ршень для впливо-вих та досвщчених професiоналiв та менед,жерiв. Цi спещалюти надають перевагу 1Т-проектам на основi !х актуальностi, i як наслщок, цi проекти отримують адекват-не фшансування. У випадку, коли орган управлшня е децентралiзованим, спецiалiс-ти з шформацшних технологiй не можуть зрозумгги негативнi наслiдки !х щеально-го «мiсцевого» рiшення для вше1' компанii. Протилежний аргумент - централiзова-ний пiдхiд прийняття рiшень щодо 1Т може обмежувати вплив мюцевих професiо-налiв та менед,жерiв в процеш прийняття рiшень, в той час, як саме вони можуть мати краще розумшня само1' проблеми та вщповщних ринкiв. IТ-фахiвцi, що знахо-дяться у епiцентрi проблем, зумовлених умовами мiсцевого ринку, можуть мати
крашд можливосп щодо визначення вимог до ршень та прiоритетностi проекпв. Тому актуальним е дослщження проектування та управлшня IT-iнфраструктурою.
2. Объект досл1дження та його технолог1чний аудит
Об 'ектом дослгдження е критична ГГ-шфраструктура.
Критична ГГ-шфраструктура повинна:
- забезпечувати функцiонування екологiчно небезпечних та сощально зна-чимих виробництв та технолопчних процесiв, порушення штатного режиму яких може призвести до надзвичайно! ситуацп техногенного характеру;
- виконувати функцп iнформацiйноi системи, порушення (зупинення) фун-кцiонування яко! може призвести до негативних наслщюв в полiтичнiй, економiч-нiй, соцiальнiй, iнформацiйнiй, екологiчнiй та шших галузях;
- забезпечувати надання значного об'ему iнформацiйних послуг, часткове або повне зупинення яких може призвести до значних негативних наслщюв для нащонально! безпеки в багатьох галузях.
Основна проблема в данш галузi - повна вiдсутнiсть готових ршень, методо-логiй, iнструментарiю, як б пiдiйшли для моделювання, проектування та досль дження критичних ГГ-шфраструктур.
3. Мета та задач1 дослщження
Метою дано1 роботи е розробка моделi вибору оптимально! конф^рацп компоненпв архiтектури критично! IТ-iнфраструктури на стадп и проектування.
Для досягнення поставлено! мети необхщно виконати такi задача
1. Удосконалити iснуючий математичний аппарат прийняття ршень за допомогою Марковських процесш прийняття ршень для дослщження критичних ГГ-шфраструктур.
2. Дослiдити за допомогою побудовано! моделi вибiр конф^урацп центру обробки даних (ЦОД) для архпектури критично! IТ-iнфраструктури.
4. Дослщження кнуючих р1шень проблеми
Попереднi досл^^няя изна _ли п'ять напрямiв проектування та управлшня 1Т - стратепчне узгодження, управлiння ризиками, управлiння ресурсами, доставка вартост та оцiнка ефективносп [3]. Робота присвячена напряму стратепчного узгодження в областi проектування критичних ГГ-шфраструктур та визначае недолки та переваги рiшень, що пов'язаш з централiзованими/децентралiзованими проектними рiшеннями щодо архттектури IТ-iнфраструктури. Стратегiчне узгодження вимагае вщ керiвникiв узгодити IТ-стратегiю з загальною бiзнес-стратегiею як основну точку фокусу к IТ-iнфраструктури. Запропоновано модель пщтримки прийняття рiшень для забезпечення прийняття вiдповiдних проектних рiшень, що ствпадають з страте-гiею шдприемства з точки зору централiзацii/децентралiзацii, в яку включено знання про майбутш недолiки/переваги кожного проектного рiшення на базi запропонова-них критерiiв при проектуванш ГГ-шфраструктури.
В робот! [4] зроблено висновок, що стратепчне узгодження, в залежносп вщ контексту, може бути децентратзованим, централiзованим або змшаним. У дослiдженнi [5] опитано 500 менеджерш, вщповщальних за управлшня ГГ-шфраструкгурою та проведено подальше опитування 30 ГГ-директорш. Як результат, визначено, що сгратегiчне
узгодження ГГ-ршень забезпечуе зростання доход1в у випадку узгодження з б1знес-стратепею шдприемства, а в шшому випадку, може призвести до контрпродуктивних швестицш в ГГ-шфраструктуру.
Узгодження швестицш в ГГ-шфраструктуру, виходячи з потреб б1знесу, впливае на результат ГГ-шщатив, таких як впровадження системи ERP. Вщповщно до аргумент, описаних вище, деяк1 дослщження шдтримують центрашзащю, а деяк досль дження пщтримують децентрал1зацш. Наприклад, дослщження [6] показало, що продуктившсть зростае, а втрати зменшуються при використанш пщприемством централ1зованого планування та контролю за ГГ-шфраструктурою. Ще одне досль дження [7] виявило, що вщшнт характеристики обробки даних CRM та локал1зова-ний характер зусиль CRM найкраще шдтримуються при використанш технологш CRM у тюнш зв'язщ з бтьш широкою шфраструктурою та локальному управлшш.
В роботах [8-11] автори також вказують на необхщнють дослщження 1Г-шфраструктури у зв'язщ з забезпечуючими системами. Проектування архттектури у вщрив1 вщ них може вплинути на оптимальшсть отримано! IГ-iнфраструкгури.
5. Методи дослiджень
5.1. Опис математичноУ моделi вибору оптимально'1 конф^раци компонент архiтектури критично! 1Т-шфраструктури
Пропонована модель мае наступи! параметры: F - скшченна множина фшй шдприемства (F = {1,..,/});
Р - скшченна множина платформ IT (Р = {1,.., р});
Т - скшченна множина вцдаюв часу (Г = );
I - скшченна множина критерпв проектування;
Z - множина категорш запита в на змшу арх1тектури (Z = {l,..,z});
f е F - значення шдексу фшп шдприемства;
реР - значення шдексу платформи IT;
zeZ - значення шдексу запиту на змшу арх1тектури;
i е / - значення шдексу критерш проектування;
btel - бюджет нового проекту в момент часу t;
с f - вартють проектування/переходу на нову платформу р для фшп / з
врахуванням Bcix витрат на ПЗ, апаратш засоби, штеграцпо та впровадження; afp7 - варлсть виконання запиту на змшу архпектури 2 наплагформу р для фшп /;
bf I - виграш вщ виконання запиту на змшу архггектури 2 на платформу р для фшп / за критер1ем i.
Простер стаиiв модел1 описуеться наступними змшними:
xzf - кшьюсть запит1в на змшу архггектури 2, що ще не виконаш для фшп /;
curf - поточна платформа фшп /; X - матриця значень xzf; CUR - матриця значень сиг,;
S - стан процесу (S = [X,CUR,t]). Випадковi величины, що використовуються в моделг ргф - кшькють запит1в на змшу архггектури z для фшп / в момент часу t;
PR - матриця значень рг /;.
Простер piuieHb модел1 описуеться наступннмн змшннмн:
Уф - кшькють запит1в на змшу арх1тектури z для фшп / в момент часу t,
що потр1бно виконати;
lf -флаг переходу на платформу р для фиш / в момент часу t, що nmpiÖHO виконати;
Y - масив змшних простору рпнеиь;
9?(5) - множнна можливих рпнень для стану S ;
С' (У) - виграш за критер1ем i, пов'язаний з ршенням Y;
С (У) - виграш за вс1ма критер1ями, пов'язаний з рппенням Y;
RWD' (5) - максимальне очшуваие значения виграшу на п-му eTani в стаж
S закритер1ем i;
RWD(S^ - максимальне очжуване значения виграшу на п-му eTani в стаж S закритер1ем i.
Модель мае певний ряд обмежень. Для стану S = \X,CUR,t\ змшш простору стан iß в Y повинж задовольияти наступи! обмеження:
- обмеження бюджету проекту:
Yjllcfplfpt^ hv (!)
f р z f
- обмеження об'ему проекту:
Уф (2)
- вимоги щодо платформ:
(3)
Уф^ ■ (4)
Bei рппення Y, що задовольняють вимогам (1)—(4), для стану S формують множину можливих риыень Модель е гнучкою. Можна додати додатков1 об-
меження. Наприклад, можна врахувати виконання проектних рiшень, що забезпечу-ють цшснють системи та й безпеку.
Кожне можливе прийняте рппення мае певну кшькють безпосередньо очпеува-них витрат та виграппв. По-перше, очпеуваний виграш bfyj за критер1ем i при вико-
нанш запиту на змшу архггектури 2 для фшп /. Також пщприемство бере на себе
витрати ана виконання запиту на змшу архггектури г для фши /. Додатково, мо-
жуть також бути витрати с/р, пов'язаш з мпращею фшй / на платформу р.
Враховуючи наведене вище, виграш на черговому етагп проектування за критер1ем I, пов'язаний з ршенням У, можна розрахувати за формулою:
с1 (л=- - ЕЕед*- (5)
г ./ г / Р г ./
Значения С" (У) може бути як позитивним, так 1 негативним. Якщо
ХХ^Л^ХХ^/^+ХХ^А^ то вигPаш, пов'язаний з вибраиими
г / г / р г /
проектними рiшеннями, представлений першим термом функцп виграшу на черговому еташ проектування, переважуе витрати, як потрiбно зробити.
Невизначешсть поставлено!' задач 1 полягае у частот! запипв на змшу вщ кожно! фиш. В данш робот1 вважаеться, що значения РК е статично незалеж-ними. Нехай 5 = [Х], [СШ?] - поточний стан, Уе9^(5) - вибраний масив рь
шень { = [X'], [б7//\"] - стан теля виконання запиту на змшу. Тод1 значения
стану 5' змшюеться вццювццю до (6)-(8):
Х'г/=Хг/-УгЛ+РГф, (6)
сиг}Р=1м> ^
£' = £ + 1. (8)
Ймов1ршсть переходу з стану 5 в стан Б' для риыення У визначаеться як (9): Р35'^=Т\П.^{РГф\СиГ1р=Х'гГ-Хг/+Уг/г\ (9)
/е^ гег
Функцii пошуку моделi наступнi:
шахС'(У), (10)
1 4 7 4 7
=^{с (¥)+IX, и}. (1!)
ЯЖО^) = шах ХХ^(12)
5.2. Опис варiантiв побудови платформ на базi хмарних ГГ-шфраструктур
Для хмарних обчислень необхiдно забезпечити керування застосуваннями, реалiзувати взаемодiю з платформами вiртуалiзацii i мережною шфраструкту-рою пiд загальним сценарiем для вше1' системи. Система в цшому мае шдтри-мувати велику кшьюсть компонентiв i надавати загальнi шструменти керуван-
ня, як можуть гарантувати надiйне, безпечне i яюсне надання послуг кментам. Мережна, апаратна i програмна шфраструктури хмарно! системи мають вщпо-вщати iснуючим i новим мережним стандартам:
- ISO/IEC 17789 (ITU-T Y.3502) - 1нформацшш технологiï. Хмарнi обчи-слення. Еталонна архiтектура [12];
- NIST SP 500-291 - Стандарти хмарних обчислень [13];
- NIST SP 500-292 - Базова архитектура хмарних обчислень [14];
- ISO/IEC Committee Draft 27017 - Основи управлшня шформацшною безпекою для хмарних обчислень на базi ISO/IEC 27002 [15];
- ISO/IEC Draft International Standard 27018 - Основи захисту даних для публiчних хмарних сервiсiв [16];
- ISO/IEC Working Draft 27036-4 - 1нформацшна безпека вщносин з постачальни-ками - Частина 4: Керiвнi принципи для забезпечення безпеки хмарних сервiсiв [17];
- ISO/IEC Draft International Standard 27040. Безпека систем збер^ання даних IEEE P2301 - Профш сумiсностi i переносимост (CPIP) [18];
- IEEE P2302 - Взаемодiя хмарних систем (SIIF) [19];
- ANSI/TIA-942 [20], EN 50173-5 [21], ISO/IEC 24764 [22] - стандарти проектування хмарних дата-центрiв.
Нащональний шститут стандарт i технологш США (National Institute of Standards and Technology - NIST) у документ [12] подав огляд еталонноï архь тектури хмарних обчислень, який щентифшуе основних суб'ектiв, ï^ дiяльнiсть i функцiï у хмарних обчисленнях (рис. 1).
Рис. 1. Еталонна архитектура хмарних обчислень Нащонального шституту ста-
ндартiв i технологш США
Основними суб'ектами еталонноï архгтектури е:
- споживачi - особи, як фiзичнi, так i юридичш, якi користуються послу-гами провайдерiв хмарних обчислень;
- провайдери - особи, як фiзичнi, так i юридичш, як вiдповiдають за на-дання хмарних обчислень;
аудитори - фiзичнi або юридичш особи або оргашзащя, якi виконують незалежне оцiнювання хмарних обчислень;
- брокери - особи, як фiзичнi, так i юридичш, якi е ланкою м1ж провайдером i споживачем хмарних обчислень (можливi варiанти без участ брокера, тобто хма-рш послуги поставляються вiд провайдера до споживача безпосередньо);
- оператори зв'язку - особи, як фiзичнi, так i юридичш, або компанiя, яка нада-ла послуги пiдключення та доставки хмарних послуг вщ провайдера до споживача.
Основними моделями обслуговування е:
- IaaS - шфраструктура як послуга.
- PaaS - платформа як послуга.
- SaaS - програмне забезпечення як послуга.
К^м основних моделей обслуговування юнують такi моделi:
- HaaS - апаратне забезпечення як послуга.
- SecaaS - безпека як послуга.
- BPaaS - бiзнес-процес як послуга.
- DBaaS - база даних як послуга.
- TaaS - довiра як послуга.
- SDPaaS - хмарне середовище розроблення як послуга та iншi [23].
Крiм того, розрiзняють чотири основш модеЛi розгортання:
- Приватна (Private cloud).
- Модель спшьноти (Community cloud).
- Публiчна (Public cloud).
- Пбридна (Hybrid cloud).
На основi аналiзу розглянутих вище стандарт установлено, що типова хмарна архпектура е клiент-серверною з пiдтримкою технологи вiртуалiзащi, побудованою на базi ЦОД, i мае iерархiчну структуру. На рис. 2 зображено ти-пову мережну архiтектуру хмарноi системи.
Рис. 2. Типова мережева архпектура хмарних систем
Мережева структура складаеться з трьох основних рiвнiв: - Рiвень ядра (Core layer). На цьому рiвнi функщонують маршрутизатори або комутатори третього рiвня моделi OSI, як складають основу всiеi мережi
дата-центру з високошвидюсним и портами (10/40/100 GbE) для маршрутизацп потокiв мiж WAN i мережею дата-центру.
- Рiвень агрегацii або розподщу (Aggregation/Distribution layer). На цьому рь вш також працюють комутатори третього рiвня моделi OSI, основне призначення яких полягае у розподiлi навантаження мiж локальними мережами дата-центру.
- Рiвень доступу (Access layer). На даному рiвнi розташовуються кiнцевi точки (сервера) та мережеве обладнання, що пов'язуе ^m^i точки з рiвнем аг-регацii. На рiвнi доступу функщонують кластери дата-центрiв, що складаються з велико1' кiлькостi фiзичних серверiв i вiртуальних машин, якi функцiонують на кожному з них. На цьому ж рiвнi розташовуеться загальна мережа збер^ання даних SAN (Storage Area Network). Група, що складаеться зi взаемозв'язаних компоненлв зберiгання даних, обчислювальних i мережних ресурсiв, якi працюють спшьно на рiвнi доступу з метою надання доступу до сервiсiв або засто-сувань Рентам, називаеться точкою доставки або POD (Point of delivery).
На сьогодш поширеш двi основнi топологii з'еднання серверiв у кластерах: Top of Rack (ToR) i End of Row (EoR) [24]. ToR тополопя передбачае розмщен-ня окремого комутатора (або двох для забезпечення надлишковосп) на вершиш кожно!' стiйки серверiв. Комутатори рiвня доступу з'еднуються з комутаторами верхнього рiвня (рiвня агрегацп) волоконно-оптичними кабелями (рис. 3).
h
Рис. 3. Топологiя ToR (Top of Rack)
Позначення на рис. 3: m - загальна кшьюсть серверiв у кластерi i k - кшь-кiсть серверiв у кожнш стiйцi, з'еднаних з комутаторами рiвня доступу двома патчкордами для забезпечення надлишковостГ 1нша топологiя (рис. 4) передбачае використання одного (двох для надлишковосп) комутатора в кшщ (EoR) або в середин (MoR - Middle of Row) масиву стшок з серверами [25].
h
Рис. 4. Тополопя кластера EoR/MoR (End of Row/Middle of Row)
У такому виконанш мережеве навантаження повн1стю доводиться на EoR-комутатор.
З точки зору зв'язност мережi архгтектури ToR i EoR/MoR являють собою протилежш рiшення. В першому випадку зв'язанiсть мережi максимальна. Але потрiбнi великi витрати на обладнання i бiльшу кiлькiсть портiв на комутаторi рiвня агрегацii, до якого безпосередньо тдключеш ToR-комутатори рiвня доступу. В другому випадку потрiбна менша кiлькiсть портiв на комутаторi рiвня агрегацii i меншi витрати на комутатор рiвня доступу, але зв'язшсть мережi при цьому буде мтмальною.
При виборi топологii необхiдно враховувати накладш витрати на розгор-тання, кшьюсть обладнання та iншi критерп. Тому третiй варiант - пбридна ар-хiтектура мережi рiвня доступу кластера ЦОД мiж топологiями ToR i EoR. Да-ний варiант формуеться на базi комбiнацii двох концепцш з урахуванням на-кладних витрат та економii портiв. Як результат, варiант забезпечуе мiнiмально прийнятний рiвень критичностi вiдмов комутаторiв рiвня доступу, не знижуючи при цьому показники надшносп, порiвняно з тополопею ToR. Модель тако!' архiтектури показано на рис. 5.
Рис. 5. Пбридна тополопя кластеру
Пбридна тополопя передбачае шдключення дектькох стшок серверiв до окремих комутаторiв рiвня доступу, як можуть бути розташованi в середиш ряду.
На баз1 представлених топологш кластер1в формуеться архгтектура мереж1 ЦОД. G два основних вар1анти реал1заци мереж1 ЦОД. Перший вар1ант побудо-ви - архгтектуру мереж1 ЦОД з одним POD [26] подано на рис. 6.
Система е працездатною, якщо складаеться з мереж1 збер1гання даних SAN, хоча б одного з мережевих маршрут1в до кластер1в р1вня доступу i хоча б одного кластера з серверами.
Кластер 1 Кластер L SAN
Рис. 6. Архгтектура мереж! центру обробки даних (ЦОД) з одною точкою доставки (POD)
Другий вар1ант побудови - архгтектура мереж1 в1ртуального ЦОД з декшь-кома POD, показаний на рис. 7.
Рис. 7. Архгтектура центру обробки даних (ЦОД) з деклькома точками доставки (POD)
Таким ч Ъм, враховуючи вищенаведене, можна видшити наступш типи платформ, як будуть використаш в данш робот (табл. 1).
Центрашзоване ршення передбачае, що вс основш компоненти мереж1 знахо-дяться в штаб-квартир1 шдприемства (окр1м кластер1в).
Таблиця 1
Типи платформ_ _ _
Платформа Тип кластеру Арх1тектура мереж1 ЦОД Централ1защя/децентрал1защя Приблизна вартють, дол.
1 ToR 1 POD Ц 200000
2 EoR/MoR 1 POD Ц 300000
3 Hybrid 1 POD Ц 150000
4 ToR П POD Ц 600000
5 EoR/MoR П POD Ц 700000
6 Hybrid П POD Ц 550000
7 ToR П POD ДЦ 900000
8 EoR/MoR П POD ДЦ 1000000
9 Hybrid п POD ДЦ 800000
Децентрашзоване рiшення - компоненти розподтеш м1ж штаб-квартирою та фтшми тдприемства.
6. Результати досл1дження
Експериментальш дослiдження базт ються на проблемi вибору архiтектури мережi ЦОД для вiртуальноi критично!' IТ-iнфраструктури тдприемства, що складаеться з штаб-квартири та 2-х фшй.
Для дослiдження використанi наступш варiанти можливих ршень (табл. 2).
Таблиця 2
Варiанти конфiгурацiй_
Конф1гуращя Штаб-квартира Фшя 1 Фшя 2
1 Платформа 1 Платформа 1 Платформа 1
2 Платформа 1 Платформа 1 Платформа 3
3 Платформа 1 Платформа 2 Платформа 3
84 Платформа 9 Ь Платформа 9 Платформа 9
По суп, особи, що приймають ршення щодо вибору архiтектури для критично! 1Т-шфраструктури, мають виршити, чи потрiбно спроектувати всю 1Т-iнфраструктуру на платформi найнижчо! вартост (Платформа 3) або знайти ва-рiант, який буде дорожчий, але буде бiльш надiйним, ефективним тощо. Кож-ний варiант ршення потрiбно оцiнити з точки зору майбутшх потенцiйних про-ектiв та внесення змт до IТ-iнфраструктури, як цi проекти можуть вимагати. В табл. 3 наведет поди, як можуть викликати потребу в змшах для платформ. Кожний тип поди далi подiляеться на декiлька категорш згiдно з !х розмь ром, поширенням запиту на змiну та супутт витрати/виграши.
В табл. 4 наведена структура даних, що використана для дослщження за-пропоновано! моделг
У цш робот! пор1внюеться сукупний виграш, отриманий вщ рекомендаций, що надае запропонована модель, яка розглядае витрати та виграш за критер1ями одночасно.
Таблиця 3
Поди, що можуть викликати потребу в змiнах для платФор. _ _
Тип подН Приклад Виграш Витрати
Нове застосування Встановлення нового застосування через нош б1знес або 1Т-потреби Нош фшансош ви-граши, що надае но-ве застосування Витрати на розгортан-ня нового застосування в 1Т-шфраструктуру
Масштабування Збшьшення числа транзакцш через зростання кшькосп користувач1в тощо Додаткош фшанси шд нових користува-ч1в Витрати на масштабування шфраструктури
1нтегращя 1нтегращя нових застосувань через змшу виробничих процесс тощо Додаткош фшансош надходження або економ1я шд викори-стання покращених виробничих процесс ти на штегращю
Модиф1кащя систе-ми Потреба в комбшу-ванш р1зних титв даних тощо Виграш шд викорис-тання нових шдход1в щодо прийняття рь шен. Витрати на модифша-щю компонент з метою тдтримки нових титв даних тощо
Безпека Пщвищена увага хакер1в вимагае пок-ращення фаервол1в, захисту серверних операцшних систем тощо Зменшення потен-цшного негативного ефекту шд атак та збереження даних Витрати на проведення захода, спрямованих на покращення безпеки
Критичшсть Перехщ сершсу ь ранг критичних Пщвищена надш-н1с..ь, безпечшсть тощо Витрати на проведення заходЬ щодо переве-дення сершсу в ранг критичних
Для моделювання зроблено припущення, що фактична кшьюсть заштв на змшу арх1тектури для кожно!' фт 11 за певний перюд (ргу//) вщповщае розподшу
Пуасона за параметром X. Значення X коливаеться вщ 25 % до 200 % базового значення з кроком 5 % (36 точок проектування).
В ходi дослщження проанашзовано вплив змш у розподiлi запипв на змiну архь тектури фшй дочiрнiх компанш на вибiр платформи. Базовий розподщ запит1в на змшу арх1тектури встановлений на рiвнi 30 % для штаб-квартири, 35 % - для фшй 1 та 35 % - для фшй 2. Для спрощення представлення результапв моделювання фiксуе базовий ршень для штаб-квартири на рiвнi 30 % запиив, а для фiлiй 1 та 2 цей рiвень змшюеться вщ 0 % до 70 % з кроком 5 % (14 точок моделювання). Сумарно така схема моделювання дае 504 точки моделювання. Згщно з табл. 4 спочатку визнача-еться загальна ктьюсть запитiв на змiну архiтектури для кожно! фшй, а дал^ визна-чаеться розподт запитш на змшу архггектури по категор1ям, враховуючи к вiдносну частоту виникнення. Далi, визначаються вiдповiднi витрати та виграш по фшям.
Таблиця 4
Структура даних_ _ _
Лтаб-квартира/Фшя 1/Фшя п Плате юрма 1 Платформа 84
Катего-р1я Под1я Розм1р поди Оч1кувана частота виникнен-ня иод1'!, в м1сяць Оч1ку-ваш ви-трати, k$ Оч1кува-ний ви-граш, k$ Оч1ку-ваш ви-трати, k$ Оч1кува-ний ви-граш, k$
1 Нове застосу-вання Незнач-на 20 10 15 12 13
2 Нове застосу-вання Середня 5 20 30 ,2 44
3 Нове застосу-вання Велика 1 50 70 55 80
4 Масштабу-вання Незнач-на 5 5 10 3 5
5 Масштабу-вання Середня 3 15 25 10 12
6 Масштабу-вання Велика 1 30 40 40 80
7 1нтегращя Незнач-на 15 5 7 8 10
8 1нтегращя Середня 8 10 12 15 30
9 1нтегращя Велика 2 30 45 45 70
10 Модиф1кащя системи Незнач-на 20 " 6 3 5
11 Модиф1кащя системи Середня 10 10 17 12 18
12 Модиф1кащя системи Велика 1 25 55 30 44
13 Безпека Незнач-на 100 5 15 6 9
14 Безпека Середня 20 20 100 30 70
15 Безпека Велика 5 50 200 60 120
16 Критичшсть Незнач-на _ 5 5 40 2 5
17 Критичшсть Середня 2 10 70 12 60
18 Критичшсть Велика 1 100 800 120 700
На рис. 8 показат рекомендацп (з 84 можливих конфпурацш, наведених в табл. 2), наданих пропонованою моделлю для рiзних точок симуляцп проектування.
Функнш оптимально! полпики Л=0.95
70 60
ю
I 50
с
со
g 40
|
I 30 20 10
0 -т-т-т-t-,-т-т--
40 60 80 100 120 140 160 180 200 Запиттв на змшу, %
Рис. 8. Результати моделювання
Як видно з рис. 8, оптимальною з точки зору MaK№Mi3ami сукупного ви-грашу виявилася конфпуращя 4.
7. SWOT-аналiз результатiв дослщження
Strengths. При роботi з критичними ГГ-шфраструктурами, оцiнка вибору конкретного варiанту реалiзацii архiтектури е одшею з проблем, з якою стикаються всi методи, якi використовуються для проектування. Запропонована модель е водночас модульною та масштабованою в тому сенш, що мае достатню гнучюсть у виборi та використаннi як простих, так i складних критерпв вибору архiтектури для критич-ноi IТ-iнфраструктури. Модульнiсть досягаеться за рахунок використання рiзних конфiгурацiй елементш, тодi як масштабованiсть представлена у двох формах:
- масштабовашсть при побудовi моделi (топологiя i функцiональнiсть) критично! IТ-iнфраструктури;
- масштабованiсть з точки зору використання рiзного роду критерпв, необ-хiдних для порiвняння варiантiв реалiзацii. З точки зору моделювання, пропонова-ний пiдхiд дозволяе створювати моделi оцiнки варiантiв реалiзацii на базi рiзних критерiiв, якi можна далi використовувати як вхiднi моделi для подальшого порiв-няння за допомогою шших критерiiв, що в свою чергу, дае можливiсть знайти оп-тимальну архiтектуру критично!' ГГ-шфраструктури. Таким чином, модель дозволяе накопичувати моделi оцiнки варiантiв реалiзацii для багаторазового використання.
Модель побудована на використанш Маркiвського процесу прийняття ршень i надае всi необхiднi шструменти для побудови, планування, дослiдження, управлш-ня, оцшювання варiантiв архiтектури критичних IТ-iнфраструктур.
Weaknesses. На даному еташ розробки моделi единою вадою е вщсутшсть реа-льних параметрiв роботи щодо компонент критично1' IТ-iнфраструктури.
Opportunities. У майбутньому плануеться використати запропоновану модель для розробки моделей оцшювання вибору компонент всiх систем та шдсистем критично!' IТ-iнфраструктури, з кшцевою метою у виглядi створення бiблiотеки моделей, яка дозволить вибирати та легко використовувати !х для рiзних дослiджень. Запропонована модель та бiблiотека моделей надасть можливють дослiдникам про-
водити попередню оцiнку вар!анпв реалiзацiï архгтектури критично!' ГГ-шфраструктури за piзними критер1ями.
Threats. На даний момент важко передбачити негaтивнi ризики розроблено! моделi. Але можна точно сказати, що н1яких додаткових витрат розробник критично! ГГ-шфраструктури, що буде використовувати пропоновану модель та розробле-ну в майбутньому бiблiотеку моделей, нести не буде.
8. Висновки
1. Удосконалено iснуючий математичний апарат Марквських процеов прийнят-тя ршень з метою дослщження критичних ГГ-шфраструктур. Звичайний Марквський процес прийняття ршень пристосовано для оцшювання вибору оптимально! конфпу-ралд компонентов арх1тектури критично! ГГ-шфраструктури за piзними кpитеpiями.
2. Дослщжено можливють використання модел! Ця модель дозволяе проводи-ти оцшку вар!анпв реашзалп р!зних компонент та тдсистем критично! ГГ-шфраструктури. На простш модел! вибору оптимально! архгтектури центру обробки даних для критично! ГГ-шфраструктури перев!рена працездатшсть запропоновано! модел! - створена модель в пакет! MatLab, дослщжена и робота.
3. В результат! моделювання сере 84 можливих конфпурацш побудови центру обробки даних обрана найкраща за сумарним виграшом (конфпурацгя 4).
Лiтература
1. Ghemawat, P. Managing Differences: The Central Challenge of Global Strategy [Text] / P. Ghemawat // Harvard Business Review. - 2007. - Vol. 85, No. 3. - P. 58-68.
2. Simonsen, J. Involving Top Management in IT Projects [Text] / J. Simonsen // Communications of the ACM. - 2007. - Vol. 50, No. 8. - P. 52-58. doi: 10.1145/1278201.127820
3. Wilkin, C. L. A Review of IT Governance: A Taxonomy to Information Accounting Information Systems [Text] / C. L. Wilkin, R. Chenhall // Journal of Information Systems. - 2010. - Vol. 24, No. 2. - P. 107-146. doi:10.2308/jis.2010.24.2.107
4. Grover, V. Fix IT-Business Relationships Through Better Decision Rights [Text] / V. Grove, R. M. Henry, J. B. Thatcher // Communications of the ACM. -2007. - Vol. 50, No. 12. - P. 80-86. doi: 10.1145/1323688.1323699
5. Shpilberg, D. Avoiding the Alignment Trp in Information Technology [Text] / D. Shpilberg, S. Berez, R. Puryear, S. Shah // MIT Sloan Management Review. - 2007. - Vol. 49, No. 1. - P. 51-58.
6. Neirotti, P. Assessing the strategic value of Information Technology: An analysis on the insurance sector [Text] / P. Neirotti, E. Paolucci // Information & Management. - 2007. - Vol. 44, No. 6. - P. 568-582. doi:10.1016/j.im.2007.05.005
7. Sen, A. IT Alignment Strategies for Customer Relationship Management [Text] / A. Sen, A. P. Sinha // Decision Support Systems. - 2011. - Vol. 51, No. 3. -P. 609-619. doi:10.1016/j.dss.2010.12.014
8. Casalicchio, E. Federated Agent-based Modeling and Simulation Approach to Study Interdependencies in IT Critical Infrastructures [Text] / E. Casalicchio, E. Galli, S. Tucci // Proceedings of the IEEE International Symposium on Distributed Simulation and Real-Time Applications (DS-RT'07). - Chania, Crete, Greek. - 2007. doi: 10.1109/ds-rt.2007.11
9. Pederson, P. Critical Infrastructure Interdependency Modeling: A Survey of U.S. and International Research [Text]: Technical Report No. INL/EXT-06-11464 / P. Pederson, D. Dudenhoeffer, S. Hartley, M. Permann. - Idaho: Idaho National Laboratory, 2006. - 116 p. doi: 10.2172/911792
10. Panzieri, S. An approach to model complex interdependent infrastructures [Text] / S. Panzieri, R. Setola, G. Ulivi // IFAC Proceedings Volumes. - 2005. -Vol. 38, No. 1. - P. 404-409. doi:10.3182/20050703-6-cz-1902.00068
11. Dorogyy, Y. Development of the approach for designing, modelling and research of critical IT infrastructure [Text] / Y. Dorogyy // Technology audit and production reserves. - 2017. - Vol. 5, No. 2 (37). - P. 34-41. doi:10.15587/2312-8372.2017.112495
12. BS ISO/IEC 17789:2014. Information technology. Cloud computing. Reference architecture [Text]. - The British Standards Institution, 2014. doi: 10.3403/30268907
13. NIST SP 500-291. NIST Cloud Computing Standards Roadmap [Text]. -National Institute of Standards and Technology, 2013. doi: 10.6028/nist.sp.500-291r2
14. Marcus, B. Interfacing NIST IoT, Big Data, and Cloud Models [Electronic resource] / B. Marcus. - October 5, 2015. - Available at: \www/URL: https://bigdatawg.nist.gov/ uploadfiles/M0450 v1 3857254727.pdf
15. BS ISO/IEC 27017:2015. Information technology. Security techniques. Code of practice for information security controls based on ISO/IEC 27002 for cloud services [Text]. - The British Standards Institution, 2015. doi:10.3403/30259620
16. BS ISO/IEC 27018:2014. Information technology. Security techniques. Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors [Text]. - The British Standards Institution, 2014. doi: 10.3403/30266768
17. BS ISO/IEC 27036-4:2016. Information technology. Security techniques. Information security for supplier relationships. Guidelines for security of cloud services [Text]. - The British Standards Institution, 2016. doi:10.3403/30275201
18. BS EN ISO/IEC 27040:2016. Information technology. Security techniques. Storage security [Text]. - The British Standards Institution, 2015. doi: 10.3403/30249804
19. IEEE P 2302 ™/D 0.2. Draft Standard for Intercloud Interoperability and Federation (SIIF) [Electronic resource]. - The Institute of Electrical and Electronics Engineers, Inc., January 2012. - Available at: \www/URL: https://www.oasis-open.org/committees/download.php/46205/p2302-12-0002-00-DRFT-intercloud-p2302-draft-0-2.pdf
20. ANSI/TIA-942-2005. Telecommunications Infrastructure Standard for Data Centers [Electronic resource]. - Arlington: Electronic Components Industry
Association (ECIA), 2005. - Available at: \www/URL: http://www.ieee802.org/3/hssg/public/nov06/diminico 01 1106.pdf
21. BS EN 50173-5:2007+A2:2012 Information technology. Generic cabling systems. Data centres [Text]. - The British Standards Institution, 2007. doi: 10.3403/30141480
22. ISO/IEC 24764:2010. Information technology - Generic cabling systems for data centres [Electronic resource]. - International Organization for Standardization, 2010. - Available at: Ywww/URL: https: //www.iso. org/standard/43520. html
23. Shelimanova, Zh. V. Taxonomic scheme of cloud computing [Text] / Zh. V. Shelimanova, O. V. Yanovska, A. A. Furmanov // Radioelektronni i kompiuterni systemy. - 2015. - Vol. 74, No. 4. - P. 51-55.
24. Data Center Networking - Connectivity and Topology Design Guide [Electronic resource]. - Available at: Ywww/URL: https: //www.cdigroup.co .uk/wp-content/pdf-documents/data-centers/Enterasys-Data-Center-Design-Guide.pdf
25. SLA for App Service [Electronic resource] // Microsoft Azure. - July 2016. -Available at: Ywww/URL: https://azure.microsofLcom/en-us/support/legal/sla/app-service/v1 4/
26. Murray, P. Cloud Networking Architecture Description [Text] / P. Murray, B. Melander, V. Fusenig, M. Meulle, L. Vaquero // Scalable and Adaptable Internet Solutions. - 2011. - P. 14-69.
