Інформаційні технології ІТ-сервісів архітектури додатків

Размещено на http://www.allbest.ru/

Інститут телекомунікацій і глобального інформаційного простору НАН України

Національний університет «Полтавська політехніка імені Юрія Кондратюка»

ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ ІТ-СЕРВІСІВ АРХІТЕКТУРИ ДОДАТКІВ

С.О. Довгий, О.В. Копійка,

О.С. Козлов, А.О. Литвиненко

м. Київ, м. Полтава



Анотація

системний архітектура програмний інфраструктура

Розглянуто розвиток Системної Архітектури ІТ-інфраструктури, орієнтованої на використання сучасних Дата-центрів. Метою досліджень є вироблення стратегії розвитку Системної Архітектури ІТ-інфраструктури на основі застосування передових методологій та концепцій провідних виробників апаратного та програмного забезпечення. Сформульовано наступний принцип побудови ІТ-інфраструктури: архітектури ІТ-інфраструктури визначають набір сервісів. ІТ-сервіси надаються трьом групам клієнтів. ІТ-сервіси та клієнти пов'язані 5 сценаріями реалізації. Інтеграцію ІТ-сервісів визначають 5 архітектур. В якості ІТ-сервісів ми розуміємо інформаційні технології, спрямовані на підтримання в технічно справному стані таких елементів: мережні пристрої, обчислювальна техніка, пристрої зберігання даних, служби автоматичного розгортання програмного забезпечення, мережеві служби, служби захисту периметра, служби каталогу, служби файлів і друку, служби управління даними, служби бізнес-додатків, служби управління ІТ, служби архівування та відновлення, служби управління сертифікатами, служби інтеграції. Архітектури визначають фундаментальні принципи побудови ІТсервісів і 'їх взаємозв'язок. Однією з найважливіших архітектур є архітектура програмних додатків. Архітектура програмних додатків визначається бізнес-потребами корпорації та підходами, методами створення додатків конкретним розробником. Вона визначає середовище виконання для додатків, механізми комунікацій між додатками і компонентами, інструментарії контролю додатка і управління його станом, а також сховище для структурованих і неструктурованих типів даних. Завдання архітектури: забезпечувати середовище для виконання компонентів додатків; підтримувати механізми диспетчеризації для комунікацій між компонентами додатків; реалізувати інструментарій для моніторингу рівня сервісів і діагностики проблем; забезпечувати зберігання структурованої і неструктурованої інформації. Стандартизація архітектури додатків дозволяє мінімізувати витрати, пов'язані з підтримкою декількох типів архітектур, кожна для визначеного типу бізнес-додатків.

Ключові слова: інформаційні технології; системна архітектура; ІТінфраструктура; дата-центри.



Abstract

Stanislav Dovgiy, Member of the National Academy of Sciences of Ukraine, D. S. (Computer science), professor, Director-organizer

Oleh Kopiika, D. S. (Computer science), professor, Head of department Oleksii Kozlov, Postgraduate

Alina Lytvynenko, Postgraduate institute of Telecommunications and Global Information Space of NASU, Kyiv, Ukraine National University «Yuri Kondratyuk Poltava Polytechnic», Poltava, Ukraine

INFORMATION TECHNOLOGIES OF APPLICATION ARCHITECTURE'S IT SERVICES

The development of the System Architecture of the IT infrastructure focused on the usage of modern Data Centers is considered. The purpose of the research is to develop a strategy for the development of the System Architecture of the IT infrastructure based on the usage of advanced methodologies and concepts of leading manufacturer's hardware and software. The following principle of IT infrastructure construction is formulated: IT infrastructure architectures define a set of services. IT services are provided to three groups of clients. IT services and clients are connected by 5 implementation scenarios. The integration of IT services is determined by 5 architectures. As IT services, we understand information technologies aimed at maintaining the following elements in technically good condition: network devices, computing equipment, data storage devices, automatic software deployment services, network services, perimeter protection services, directory services, file and print services, data management services, business application services, IT management services, archiving and recovery services, certificate management services, integration services. Architectures define the fundamental principles of building IT services and their relationship. One of the most important architectures is the architecture of software applications. The architecture of software applications is determined by the business needs of the corporation and the approaches, methods of creating applications by a specific developer. It defines the execution environment for applications, mechanisms of communication between applications and components, tools for controlling the application and managing its state, as well as storage for structured and unstructured data types. Tasks of the architecture: to provide an environment for the execution of application components; support dispatching mechanisms for communications between application components; implement tools for monitoring the level of services and diagnosing problems; provide storage of structured and unstructured information. Standardization of the application architecture allows you to minimize costs associated with the support of several types of architectures, each for a specific type of business application.

Keywords: information technologies; system architecture; IT infrastructure; data centers.



Вступ

Враховуючи сучасні вимоги до інформаційно-комунікаційних технологій, при реалізації проектів для крупних підприємств, економічно доцільно використовувати «хмарні технології». Сучасним трендом при цьому є побудова єдиного інформаційного простору для підприємства з використанням сучасної ІТ-інфраструктури, орієнтованої на Дата-центри [1-22]. Основними складовими єдиного інформаційного простору є: єдине транспортне середовище (програмно-конфігуровані мережі SDN (softwaredefined networking)); сервісно-орієнтована архітектура інформаційних систем; інфраструктурні та функціональні сервіси Дата-центрів [23-25].

Основою сервісних Дата-центрів є набір ІТ-сервісів. В якості ІТ-сервісів ми розуміємо комплекс робіт, спрямований на підтримання в технічно справному стані таких елементів: мережа; дані; ІТ-інфраструктура; інфраструктура інформаційних систем; безпека [26-28].

У цій статті розглядатимемо розвиток Системної Архітектури ІТінфраструктури, орієнтованої на використання сучасних Дата-центрів.

Метою даних досліджень є вироблення стратегії розвитку Системної Архітектури ІТ-інфраструктури на основі застосування передових методологій та концепцій провідних виробників апаратного та програмного забезпечення (HP, SUN, EMC, CISCO, Microsoft, ORACLE, Veritas).



КОНЦЕПЦІЯ РОЗВИТКУ ІТ-ІНФРАСТРУКТУРИ

Реалізація концепції розвитку ІТ-інфраструктури за рахунок побудови Дата-центрів показана на рис. 1.

Рис. 1 Концепція розвитку ІТ-інфраструктури

Такий підхід дозволяє проаналізувати існуючу ІТ -інфраструктуру та визначити шляхи побудови нової на базі протестованої, еталонної архітектури MSA [29].

При цьому створюється система компонентів, що описують: загальні підходи побудови системної архітектури; ІТ-сервіси - технологічні системи, які вирішують завдання корпорації; логічну модель ІТ-інфраструктури.

Сформулюємо наступний принцип побудови ІТ-інфраструктури: архітектури ІТ-інфраструктури визначають набір сервісів. ІТ-сервіси надаються трьом групам клієнтів. ІТ-сервіси та клієнти пов'язані 5 сценаріями реалізації. Інтеграцію ІТ-сервісів визначають 5 архітектур.

В якості ІТ-сервісів ми розуміємо інформаційні технології, спрямовані на підтримання в технічно справному стані таких елементів: мережні пристрої, обчислювальна техніка, пристрої зберігання даних, служби автоматичного розгортання ПЗ, мережеві служби, служби захисту периметра, служби каталогу, служби файлів і друку, служби управління даними, служби бізнесдодатків, служби управління ІТ, служби архівування та відновлення, служби управління сертифікатами, служби інтеграції [30-32].

Всі клієнти підприємства діляться на три основні групи. При необхідності, клієнти діляться всередині кожної категорії окр емо: співробітники, партнери та партнерські організації, зовнішні споживачі.

Сценарії реалізації: Дата-центр, департамент, віддалений офіс, екстранет, Інтернет Дата-центр.

Архітектури: безпеки, управління, зберігання даних, програмних додатків, мережева.

Архітектури визначають фундаментальні принципи побудови ІТ -сервісів і їх взаємозв'язок. Також, на базі архітектури формуються вимоги до створення ІТ-сервісів.

АРХІТЕКТУРА ПРОГРАМНИХ ДОДАТКІВ

Однією з найважливіших Архітектур є Архітектура програмних додатків.

Архітектура програмних додатків визначається бізнес-потребами корпорації та підходами, методами створення додатків конкретним розробником. Вона визначає середовище виконання для додатків, механізми комунікацій між додатками і компонентами, інструментарії контролю додатка і управління його станом, а також сховище для структурованих і неструктурованих типів даних.

Завдання архітектури:

1. Забезпечувати середовище для виконання компонентів додатків.

2. Підтримувати механізми диспетчеризації для комунікацій між компонентами додатків.

3. Реалізувати інструментарій для моніторингу рівня сервісів і діагностики проблем.

4. Забезпечувати зберігання структурованої і неструктурованої інформації.

Стандартизація архітектури додатків дозволяє мінімізувати витрати, пов'язані з підтримкою декількох типів архітектур, кожна для одного типу бізнес-додатків.

Зокрема, архітектура як одно-, так і багаторівневих додатків платформи включає в себе (рис. 2):

1. Операційну систему.

2. Середовище виконання - Framework.

3. Сервер додатків - Internet Information Server.

4. Компонентне середовище - COM - .

5. Службу асинхронного обміну повідомленнями - MSMQ.

Елементи Інфраструктури додатків, які є основними компонентами архітектури, не включають самі додатки. Корпорацією експлуатується значна кількість бізнес-додатків, кожен з яких вимагає своїх типів систем і компонентів на кожному рівні, і навіть різну кількість рівнів. Доцільно розглядати модернізацію поточних бізнес-систем і впровадження нових не тільки з боку необхідного функціоналу, але і з боку перспективи необхідної для них архітектури.

Формалізація архітектури додатків дозволить враховувати необхідні зміни ІТ-інфраструктури в цілому, а також мінімізувати витрати на впровадження нової технології шляхом використання вже існуючих компонентів (баз даних, серверів додатків, вебсерверів).

Для формування вимог до архітектури потрібно розглянути типові рівні та компоненти додатків. Типовий бізнес-додаток включає в себе до чотирьох рівнів і одинадцять основних компонентів (рис. 3).

Рівні:

1. Рівень даних - відповідає за управління даними і доступ до них.

2. Рівень додатків - відповідає за бізнес-логіку програми.

3. Рівень Web - відповідає за інтерфейс між додатком і користувачем або між додатком і іншим додатком.

4. Рівень клієнта - відповідає за встановлення інтерфейсу для користувача.

Рис. 2 Архітектура додатків

Додатки ставлять такі завдання перед інфраструктурою:

1. Мати можливість взаємодії з клієнтами - інтерактивними користувачами або іншими web-сервісами.

2. Отримати ресурси для обслуговування запитів від клієнтів.

3. Мати можливість для програмної взаємодії з іншими додатками.

4. Мати місце для надійного зберігання даних.



Рис. 3 Типові рівні та компоненти додатків

Розгортання додатків

Технології розгортання додатків повинні забезпечити необхідний рівень доступності, безпеки, керованості.

Доступність

Компоненти рівня програми, що вимагає найвищого рівня доступності (більше 99,90%), розміщуються в кластері з балансуванням навантаження (Load Balancing Cluster). Дана технологія прийнятна для компонентів з одним станом (stateless) або доступних тільки для читання, відключення в будь-який момент часу не приводить до втрати інформації або даних.

Компоненти рівня програми та рівня даних, що вимагають найвищого рівня доступності (більше 99,95%), розміщуються в Failover-кластері. Дана технологія забезпечує надмірність системних ресурсів з можливістю переміщати додаток з вузла, який відмовив, на резервний.

Захищеність

Компоненти програми можуть бути фізично рознесені на різні вузли мережі. Один додаток, один web-сервіс, може мати один, два або три рівні. Таким чином різні додатки можуть перебувати в різних зонах безпеки.

Кожна програма має надавати інформацію про свою підтримку технологій кластеризації та взаємодії своїх рівнів.

Типи клієнтів

Основні типи клієнтів, що використовуються Корпорацією, включають:

1. Тонкий клієнт (браузер). Логіка і дані зберігаються на серверах.

2. Товстий клієнт (Excel). Частина бізнес-логіки і профіль настройки користувача зберігаються на клієнті.

3. Програмний клієнт, який отримує доступ до Web -сервісу за допомогою протоколу SOAP. Один додаток є клієнтом іншого, при цьому інтерфейс користувача відсутній.

Інфраструктура життєвого циклу

Додаток протягом свого життєвого циклу всередині Дата-центру розгортається в п'яти інфраструктурних середовищах додатків (рис. 4):

1. Середовище розробки - виділене середовище, всередині якого створюються додатки. Менеджер розробки відповідає за роботу в цій зоні і за зміни і модифікації системи.

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

3. Тестове середовище - зона відповідальності менеджера тестування або менеджера приймання в експлуатацію. У даній зоні проводяться набори функціональних, навантажувальних і інших тестів на додатку. Зміни додатка не допускаються.

4. Перед-експлуатаційне середовище - зона «зберігання» готового до впровадження релізу додатка. Зміни не допускаються. Дана зона вже входить у відповідальність менеджера експлуатації.

5. Середовище експлуатації - середовище з найвищим рівнем контролю.

Рис. 4 Інфраструктурні середовища додатків Дата-центру

Логічний дизайн додатків

Стандарт 1: Дворівневий додаток для внутрішніх клієнтів (рис. 5 а)

Характеристики:

1. Прості міжкомпонентні зв'язки.

2. Проста схема розгортання програми.

3. Прості механізми контролю доступності.

4. Всі додатки знаходяться у Внутрішній Зоні Безпеки.



Рис. 5 а Дворівневий додаток для внутрішніх клієнтів

Стандарт 2: Трирівневий додаток для внутрішніх клієнтів (рис. 5 б)

Характеристики:

1. Незалежне масштабування рівнів бізнес-логіки і уявлення.

2. Діагностика проблем складна.

Стандарт 3: Дворівневий додаток для зовнішніх клієнтів з внутрішнім джерелом даних (рис. 5 в)

Характеристики:

1. Системи контролю периметрів забезпечують додатковий рівень захисту.

2. Розгортання системи складне.

Стандарт 4: Трирівневий додаток для зовнішніх клієнтів з внутрішнім джерелом даних (рис. 5 г)

Характеристики:

1. Необхідна настройка комунікацій між рівнями бізнес-логіки і уявлення.

2. Необхідний сервіс хостингу компонентів.

3. Діагностика проблем складна.

4. Розгортання додатка складне.

Рис. 5 б Трирівневий додаток для внутрішніх клієнтів

Рис. 5 в Дворівневий додаток для зовнішніх клієнтів з внутрішнім джерелом даних

Рис. 5 г Трирівневий додаток для зовнішніх клієнтів з внутрішнім джерелом даних

Рис. 5 д Трирівневий додаток для зовнішніх клієнтів з внутрішнім джерелом даних і додатком

Стандарт 5: Трирівневий додаток для зовнішніх клієнтів з внутрішнім джерелом даних і додатком (рис. 5 д)

Характеристики:

1. Бізнес-логіка і дані розміщуються в більш захищеній зоні.

2. Діагностика проблем складна.

3. Розгортання додатка складне.

Архітектура додатків реалізується у вигляді наступних елементів і стандартів.

Табл. 1

Елементи й стандарти архітектури додатків

Елемент	Характеристика
.NET Framework	Забезпечує виконуване середовище і бібліотеки класів для.NET коду
COM -	Середовище обслуговування та захисту компонентів додатка
Message Queuing	Технологія управління чергами повідомлень і асинхронними комунікаціями між компонентами додатка
Web Application Services	Обслуговування (hosting) Web-сервісів
Data Services	Обслуговування доступу до даних
File Services	Зберігання конфігураційних файлів (global.asax або Web.config, наприклад)
Networking Services	Забезпечення мережевих комунікацій
Certificate Services	Забезпечення аутентифікації, авторизації та криптографічного шифрування
Infrastructure Management Services	Інструментарій моніторингу та управління додатком і його компонентами
Мережеві стандарти: TCP / IP; UDP / IP. У якості мережі будемо використовувати програмно-конфігуровані мережі

(software-defined networking SDN). SDN - це підхід до управління мережею, який забезпечує динамічну, програмно ефективну конфігурацію мережевих елементів з метою покращення продуктивності мережі та моніторингу, що робить її більше схожою на хмарні обчислення, ніж на традиційне керування мережею [33]. SDN призначена для створення статичної архітектури традиційних мереж. SDN намагається централізувати дані про мережу в одному мережевому компоненті, відокремлюючи процес пересилання мережевих пакетів (площина даних) від процесу маршрутизації (площина керування) [34, 35]. Площина управління складається з одного або кількох контролерів, які вважаються мозком мережі SDN, в якій об'єднано весь інтелект. Однак централізація має свої недоліки, коли йдеться про безпеку [36], масштабованість та гнучкість [33], і це головна проблема SDN [36].

SDN зазвичай асоціювалась з протоколом OpenFlow (для віддаленого зв'язку з елементами мережевої площини з метою визначення шляху мережевих пакетів через мережеві комутатори) з моменту появи останнього в 2011 році. Однак з 2012 року цей термін також використовували власні системи [37, 38]. До них належать відкрите мережеве середовище Cisco Systems і платформа віртуалізації мережі Nicira.

Web-стандарти: HTTP / HTTPS; XML; SOAP / WSDL; WSE (WS-Security, WS-Routing, WS-Coordination, and WS-Transaction).

СУБД стандарти: SQL.

ІНТЕГРАЦІЯ ІНФРАСТРУКТУРИ ДОДАТКІВ

Будь-який компонент інфраструктури додатків повинен надавати рішення, яке дозволяє його інтегрувати з іншими компонентами. Інтеграція необхідна на рівні мережевих комунікацій, на рівні базових сервісів (доступ до файлових систем), на рівні доступу до джерел даних, на рівні взаємодії додатків. Крім технологічної складності інтеграції різнорідних систем, значно підвищується складність управління такими комплексами [39].

Оскільки в реальних умовах неможливо і часто недоцільно забезпечити поставку всіх компонентів інфраструктури від одного виробника, питання інтеграції може бути вирішене трьома шляхами: використання стандартів, використання проміжних середовищ-«перекладачів» (application integration services), самостійна розробка конекторів.

Використання стандартів

Ключовою характеристикою взаємодії з операційними системами і службами інших виробників є підтримка стандартів TCP / IP, IPX, Kerberos, PKI (X.509, PKCS), LDAP, HTTP, WBEM, DNS, DHCP, XML, UDDI, SOAP і інш.

Рис. 6 Підтримка стандартів

Крім стандартів, треба забезпечити додатковими технологіями інтеграції, як наприклад підсистема Interix, яка дозволяє виконувати додатки UNIX середовища.



Табл. 2

Додаткові технології інтеграції

Платформа	Мережа	Дані	Додатки
UNIX	Services for UNIX	Services for UNIX, Microsoft Interix	Microsoft Interix
IBM	Host Integration Server	Host Integration Server	Host Integration Server
Macintosh	Services for Macintosh	Services for Macintosh	N/A

Сервіс-орієнтована архітектура додатків (Service Oriented Architecture) спирається на Web-стандарти і дозволяє створити інфраструктуру додатків, здатних до безшовної інтеграції.

Стандарти Web Services Enhancements (WSE) описують схеми маршрутизації, посилальних зв'язків, інспекції, безпеки, транзакційних механізмів та інші компоненти інфраструктури SOA. Інфраструктура додатків повинна підтримувати набір стандартів WSE.

Табл. 3

Підтримка стандартів WSE Windows Server

Вимога	Приклад реалізації
Безпосередня підтримка XML Web Services	Забезпечення безпосередньої підтримки стандартів XML Web service, включаючи XML, SOAP, Universal Description, Discovery, і Integration (UDDI), і Web Services Description Language (WSDL).
Підтримка Enterprise UDDI	Включає Enterprise UDDI Services, динамічну та гнучку інфраструктуру для XML Web -сервісів. Даний компонент дозволяє компаніям отримати свою внутрішню UDDI службу.
Підтримка успадкованих систем	XML Web-сервіси інтегровані в Windows Server; існуючі компоненти COM - і Message Queuing можуть працювати спільно з Web-сервісами. COM - додатки можуть використовувати XML / SOAP. Message Queuing використовує SOAP і XML в якості основних протоколів.
Федеративна Інфраструктура	XML Web-сервіси забезпечують фундамент для безшовної інтеграції додатків.

Використання сервісів інтеграції

Сервіси інтеграції дозволяють грати роль транспорту і перекладача інформації. Сервіс інтеграції має бути створений у вигляді єдиної шини, брокера, інтегруючого системи відповідно до розроблених бізнес -процесів. Сервіс інтеграції може використовувати власну бізнес-логіку і забезпечувати інтеграцію в один бізнес -процес багатьох (більше двох) додатків.



ВИСНОВКИ ТА ПЕРСПЕКТИВИ ПОДАЛЬШИХ ДОСЛІДЖЕНЬ

1. Розглянуто розвиток Системної Архітектури ІТ-інфраструктури, орієнтованої на використання сучасних Дата-центрів.

2. Представлена стратегія розвитку Системної Архітектури ІТ - інфраструктури на основі застосування передових методологій та концепцій провідних виробників апаратного та програмного забезпечення (HP, SUN, EMC, CISCO, Microsoft, ORACLE, Veritas). Для системної архітектури представлені компоненти, що описують: загальні підходи побудови системної архітектури; ІТ-сервіси - технологічні системи, які вирішують завдання корпорації; логічну модель ІТ-інфраструктури.

3. Сформульовано наступний принцип побудови ІТ-інфраструктури: архітектури ІТ-інфраструктури визначають набір сервісів. ІТ -сервіси надаються трьом групам клієнтів. ІТ-сервіси та клієнти пов'язані 5 сценаріями реалізації. Інтеграцію ІТ-сервісів визначають 5 архітектур.

4. В якості ІТ-сервісів представлені інформаційні технології, спрямовані на підтримання в технічно справному стані таких елементів: мережні пристрої, обчислювальна техніка, пристрої зберігання даних, служби автоматичного розгортання ПЗ, мережеві служби, служби захисту периметра, служби каталогу, служби файлів і друку, служби управління даними, служби бізнес - додатків, служби управління ІТ, служби архівування та відновлення, служби управління сертифікатами, служби інтеграції.

5. Архітектури систем визначають фундаментальні принципи побудови ІТсервісів і їх взаємозв'язок.

6. На базі архітектури формуються вимоги до створення ІТ-сервісів.

7. Однією з найважливіших архітектур є архітектура програмних додатків.

8. Архітектура програмних додатків визначається бізнес -потребами корпорації та підходами, методами створення додатків конкретним розробником. Вона визначає середовище виконання для додатків, механізми комунікацій між додатками і компонентами, інструментарії контролю додатка і управління його станом, а також сховище для структурованих і неструктурованих типів даних. Завдання архітектури: забезпечувати середовище для виконання компонентів додатків; підтримувати механізми диспетчеризації для комунікацій між компонентами додатків; реалізувати інструментарій для моніторингу рівня сервісів і діагностики проблем; забезпечувати зберігання структурованої і неструктурованої інформації.

9. Стандартизація архітектури додатків дозволяє мінімізувати витрати, пов'язані з підтримкою декількох типів архітектур, кожна для визначеного типу бізнес-додатків.



СПИСОК ЛІТЕРАТУРИ

1. "Data Centres and Data Transmission Networks - Analysis". IEA. Retrieved 2022-03-06: веб-сайт. URL: https://www.iea.org/reports/data-centres-and-data-transmission-networks (Last accessed: 30.08.2023).

2. The European Commission H2020 EURECA Data Centre Project - Data centre energy efficiency guidelines, extensive online training material, case studies/lectures (under events page), and tools: веб-сайт. URL: https://www.dceureca.eu/ (Last accessed: 30.08.2023).

3. "An Oregon Mill Town Learns to Love Facebook and Apple". The New York Times. March 6, 2018: веб-сайт. URL: https://www.nytimes.com/2018/03/06/business/apple-facebook-data-center.html (Last accessed: 30.08.2023).

4. "Google announces London cloud computing data centre". BBC.com. July 13, 2017: вебсайт. URL: https://www.bbc.com/news/technology-40590080 (Last accessed: 30.08.2023).

5. "Cloud Computing Brings Sprawling Centers, but Few Jobs". The New York Times. August 27, 2016. data center.. a giant..facility.. 15 ofthese buildings, and six more.. under construction: веб-сайт. URL: https://www.nytimes.com/2016/08/27/technology/cloud-computing-brings-sprawling-centers-but-few-jobs-to-small-towns.html (Last accessed: 30.08.2023). `

6. Holusha, J. (2000). "Commercial Property/Engine Room for the Internet; Combining a Data Center With a 'Telco Hotel'". The New York Times. Retrieved June 23, 2019: веб-сайт. URL: https://www.nytimes.com/2000/05/14/realestate/commercial-property-engine-room-for-internet-combining-data-center-with-telco.html (Last accessed: 30.08.2023).

7. "Data center staff are aging faster than the equipment". Network World. August 30, 2018: веб-сайт. URL: https://www.networkworld.com/article/3301883/data-center-staff-are-aging-faster-than-the-equipment.html (Last accessed: 30.08.2023).

8. "This Wave of Data Center Consolidation is Different from the First One". February 8, 2018: веб-сайт. URL: https://www.datacenterknowledge.com/manage/wave-data-centerconsolidation-different-first-one (Last accessed: 30.08.2023).

9. Kantor, A. (2021-05-18). "Big Tech races to clean up act as cloud energy use grows". Financial Times. Retrieved 2022-03-06: веб-сайт. URL: https://www.ft.com/content/ c719f655-149c-4ce0-a7a5-18527c7776cf (Last accessed: 30.08.2023).

10. Bashroush, R. (2018). A Comprehensive Reasoning Framework for Hardware Refresh in Data Centres. IEEE Transactions on Sustainable Computing. 3 (4), 209-220.

11. Noormohammadpour, M. & Raghavendra, C. (2018). Datacenter Traffic Control: Understanding Techniques and Tradeoffs. IEEE Communications Surveys & Tutorials. 20 (2). 1492-1525. arXiv:1712.03530. doi:10.1109/comst.2017.2782753

12. Беркман, Л. Н. (2014). Теоретичні основи методології синтезу інформаційнокомунікаційних систем. Телекомунікаційні та інформаційні технології, №4, 12-20.

13. Довгий, С. (2000). Стан та проблеми розвитку телекомунікаційної мережі України. Наука та наукознавство.

14. Волошин, О. Ф., & Мащенко, С. О. (2010). Моделі та методи прийняття рішень: навч. посіб. для студ. вищ. навч. закл., 2-ге вид., перероб. та допов., К.: Видавничополіграфічний центр "Київський університет".

15. Rubinstein, A. (2013). Lecture Notes in Microeconomic Theory, 2nd., Princeton University Press. ISBN 978-0-691-15413-8.

16. Балашов, В.А., Копийка, О.В., & Ляховецкий, Л.М. (2005) VDSL - ближайшее будущее цифрового абонентского доступа. Зв`язок, № 4, 10-16.

17. Довгий, С.О. (2001). Приватизація, інвестиції та фондовий ринок: правові засади та практика. У 4 т., Відкрите акціонерне товариство «Укртелеком», К.: Укртелеком.

18. Jew, J. (2010). BICSI Data Center Standard: A Resource for Today's Data Center Operators and Designers. BICSI News Magazine.

19. Niles, S. (2011). Standardization and Modularity in Data Center Physical Infrastructure. Schneider Electric.

20. Telecommunications Infrastructure Standard for Data Centers. (2005). TIA STANDARD TIA-942. TELECOMMUNICATIONS INDUSTRY ASSOCIATION.

21. ANSI/BICSI 002-2011 Data Center Design and Implementation Best Practices. (2011). Committee Approval - January 2011 First Published.

22. TIA is accredited by the American National Standards Institute (ANSI) as a standards developing organization (SDO). URL: http://www.tiaonline.org/standards/ (Last accessed: 07.04.2022).

23. Концепции сетецентрического боевого управления ВС США, Великобритании и ОВС НАТО. Общее и различия. URL: http://factmil.com/publ/strana/velikobritanija/ koncepcii_setecentricheskogo_boevogo_upravlenija_vs_ssha_velikobritanii_i_ovs_nato_ob shhee_i_razlichija_2010/9-1-0-420 (Last accessed: 30.08.2023).

24. Kopeika, O., Tarasenko, I., Kisselevskiy, A., Karichenskiy, A. & Valiulin, T. (2007). Softline applies TMF standards as a guide when building Resource Inventory solution for nation-wide carrier Ukraine Telecom. TM Forum Case Study Handbook, Volume 3.

25. Barabash, O., Openko, P., Kopiika, O., Shevchenko, H., & Dakhno, N. (2019). Target Programming with Multicriterial Restrictions Application to the Defense Budget Optimization. Advances in Military Technology, 14, no. 2, 213-229. DOI: 10.3849/aimt.01291.

26. Choi, M.-J., Ju, H.-T., Hong, J. W.-K., & Yun, D.-S. (2008). Design and Implementation of Web Services-based NGOSS Technology Specific Architecture, Annals of Telecommunications. Special Issue on “Next Generation Network and Service Management”, Vol. 63, No. 3-4, 195-206.

27. Копейка, О. В. (2014). Архитектура системы управления ИТ-инфраструктурой в современных Дата-центрах. Наукові записки Українського науково-дослідного інституту зв'язку, № 29, 29-37.

28. Копійка, О.В. (2014). Методологія синтезу інформаційно-комунікаційних систем на базі єдиної інформаційної платформи. Автореф. докт. тех. наук, К.: Національна академія наук України, Інститут телекомунікацій і глобального інформаційного простору.

29. Еталонні архітектури MSA. (2005). К.: Майкрософт Україна; К.: Видавнича група BHN.

30. Копейка, О.В. (2014). Проектирование сервисов инфраструктуры приложений в дата-центрах. Телекомунікаційні та інформаційні технології, No 1, 19-27.

31. Копейка, О.В. (2014). Архитектура системы безопасности ИТ-инфраструктуры в дата-центрах. Сучасний захист інформації, No 1, 48-57.

32. Копейка, О.В. (2013). Сетевые службы и службы сетевых устройств в дата-центрах. Системи управління, навігації та зв'язку: наукове періодичне видання, №4(28), 98-104.

33. Benzekki, K., El Fergougui, A., & Elbelrhiti Elalaoui, A. (2016). Software-defined networking (SDN): A survey. Security and Communication Networks, 9 (18): 5803 5833. doi:10.1002/sec.1737.

34. Montazerolghaem, A. (2020). Software-defined load-balanced data center: design, implementation and performance analysis. Cluster Computing. Vol. 24 (2), 591-610. doi:10.1007/s10586-020-03134-x. ISSN 1386-7857. S2CID 220490312.

35. Довгий, С.О., Воробієнко, П.П., & Гуляєв, К.Д. (2013) Сучасні телекомунікації: Мережі, технології, безпека, економіка, регулювання. Видання друге (доповнене). Київ: «Азимут-Україна».

36. Montazerolghaem, A. (2020). Software-defined Internet of Multimedia Things: Energy efficient and Load-balanced Resource Management. IEEE Internet of Things Journal. Vol.9 (3), 2432-2442. doi:10.1109/JIOT.2021.3095237. ISSN 2327-4662.S2CID 237801052.

37. Software-defined networking is not OpenFlow, companies proclaim. URL: https://www.techtarget.com/searchnetworking/ (Last accessed: 30.08.2023).

38. InCNTRE's OpenFlow SDN testing lab works toward certified SDN product. URL: https://www.techtarget.com/news/ (Last accessed: 30.08.2023).

39. Довгий, С.О., & Копійка О.В. (2023) ІТ-інфраструктура як базова складова цифрової трансформації. Київ: ТОВ Видавництво «Юстон».

REFERENCES

1. "Data Centres and Data Transmission Networks - Analysis". IEA. Retrieved 2022-03-06 from https://www.iea.org/reports/data-centres-and-data-transmission-networks (Last accessed: 30.06.2023).

2. The European Commission H2020 EURECA Data Centre Project - Data centre energy efficiency guidelines, extensive online training material, case studies/lectures (under events page), and tools. Retrieved from https://www.dceureca.eu/ (Last accessed: 30.06.2023).

3. "An Oregon Mill Town Learns to Love Facebook and Apple". The New York Times. March 6, 2018. Retrieved from https://www.nytimes.com/2018/03/06/business/apple-facebook-data-center.html (Last accessed: 30.06.2023).

4. "Google announces London cloud computing data centre". BBC.com. July 13, 2017. Retrieved from https://www.bbc.com/news/technology-40590080 (Last accessed: 30.06.2023).

5. "Cloud Computing Brings Sprawling Centers, but Few Jobs". The New York Times. August 27, 2016. data center.. a giant..facility.. 15 ofthese buildings, and six more.. under construction. Retrieved from https://www.nytimes.com/2016/08/27/technology/cloudcomputing-brings-sprawling-centers-but-few-jobs-to-small-towns.html (Last accessed: 30.06.2023).

6. Holusha, J. (2000). "Commercial Property/Engine Room for the Internet; Combining a Data Center With a 'Telco Hotel'". The New York Times. Retrieved June 23, 2019 from https://www.nytimes.com/2000/05/14/realestate/commercial-property-engine-roomfor-internet-combining-data-center-with-telco.html (Last accessed: 30.06.2023).

7. "Data center staff are aging faster than the equipment". Network World. August 30, 2018. Retrieved from https://www.networkworld.com/article/3301883/data-center-staff-are-agingfaster-than-the-equipment.html (Last accessed: 30.06.2023).

8. "This Wave of Data Center Consolidation is Different from the First One". February 8, 2018. Retrieved from https://www.datacenterknowledge.com/manage/wave-data-centerconsolidation-different-first-one (Last accessed: 30.06.2023).

9. Kantor, A. (2021-05-18). "Big Tech races to clean up act as cloud energy use grows". Financial Times. Retrieved 2022-03-06 from https://www.ft.com/content/c719f655149c-4ce0-a7a5-18527c7776cf (Last accessed: 30.06.2023).

10. Bashroush, R. (2018). A Comprehensive Reasoning Framework for Hardware Refresh in Data Centres. IEEE Transactions on Sustainable Computing. 3 (4), 209-220.

11. Noormohammadpour, M. & Raghavendra, C. (2018). Datacenter Traffic Control: Understanding Techniques and Tradeoffs. IEEE Communications Surveys & Tutorials. 20 (2). 1492-1525. arXiv:1712.03530. https://doi.org/10.1109/comst.2017.2782753

12. Berkman, L.N. (2014). Theoretical bases of methodology of synthesis of information and communication systems. Telecommunication and information technologies, 4, 12-20 [in Ukrainian].

13. Dovgyi, S. (2000). The state and problems of the development of the telecommunications network of Ukraine. Science and scientific studies [in Ukrainian].

14. Voloshyn, O.F., & Mashchenko, S.O. (2010). Decision-making models and methods. education manual for students higher education acc., 2nd ed., revision. and added. K.: Kyiv University Publishing and Printing Center [in Ukrainian].

15. Rubinstein, A. (2013). Lecture Notes in Microeconomic Theory, 2nd., Princeton University Press. ISBN 978-0-691-15413-8.

16. Balashov, V.A., Kopiika, O.V., & Lyakhovetsky, L.M. (2005). VDSL - near future of digital subscriber access. Communication, 4, 10-16 [in Russian].

17. Dovgyi, S.O. (2001). Privatization, Investment and the Stock Market: Legal Principles and Practice. In the 4th grade: Ukrtelecom [in Ukrainian].

18. Jew, J. (2010). BICSI Data Center Standard: A Resource for Today's Data Center Operators and Designers. BICSI News Magazine.

19. Niles, S. (2011). Standardization and Modularity in Data Center Physical Infrastructure. Schneider Electric.

20. Telecommunications Infrastructure Standard for Data Centers. (2005). TIA STANDARD TIA-942. TELECOMMUNICATIONS INDUSTRY ASSOCIATION.

21. ANSI/BICSI 002-2011 Data Center Design and Implementation Best Practices. (2011). Committee Approval - January 2011 First Published.

22. TIA is accredited by the American National Standards Institute (ANSI) as a standards developing organization (SDO). Retrieved from http://www.tiaonline.org/standards/ (Last accessed: 07.04.2022).

23. Concepts of network-centric combat control of the US, UK and NATO Armed Forces. Generalities and differences. Retrieved from http://factmil.com/publ/strana/velikobritanija/ koncepcii_setecentricheskogo_boevogo_upravlenija_vs_ssha_velikobritanii_i_ovs_nato_ob shhee_i_razlichija_2010/9-1-0-420 (Last accessed: 30.06.2023).

24. Kopeika, O., Tarasenko, I., Kisselevskiy, A., Karichenskiy, A. & Valiulin, T. (2007). Softline applies TMF standards as a guide when building Resource Inventory solution for nation-wide carrier Ukraine Telecom. TM Forum Case Study Handbook, Volume 3.

25. Barabash, O., Open'ko, P., Kopiika, O., Shevchenko, H., & Dakhno, N. (2019). Target Programming with Multicriterial Restrictions Application to the Defense Budget Optimization. Advances in Military Technology, 14, no. 2, 213-229. https://doi.org/10.3849/aimt.01291

26. Choi, M.-J., Ju, H.-T., Hong, J. W.-K., & Yun, D.-S. (2008). Design and Implementation of Web Services-based NGOSS Technology Specific Architecture, Annals of Telecommunications. Special Issue on “Next Generation Network and Service Management”, Vol. 63, No. 3-4, 195-206.

27. Kopiika, O. V. (2014). The architecture of the IT infrastructure management system in modern data centers. Scientific Notes of the Ukrainian Scientific Research Institute of Communications, No. 29. 29-37 [in Ukrainian].

28. Kopiika, O. V. (2014). Methodology of the synthesis of information and communication systems based on a single information platform. Abstract of Doctor of Technical Sciences, K.: National Academy of Sciences of Ukraine, Institute of Telecommunications and Global Information Space.

29. Reference architectures MSA. (2005). К.: Microsoft Ukraine; K.: Publishing group BHN.

30. Kopiika, O. V. (2014). Designing application infrastructure services in data centers. Telecommunications and information technologies, No 1, 19-27 [in Russian].

31. Kopiika, O. V. (2014). The architecture of the IT infrastructure security system in data center. Modern information protection, No 1, 48-57 [in Russian].

32. Kopiika, O.V. (2013). Network services and network device services in Data Centers. Control, navigation and communication systems, 4 (28), 98-104 [in Russian].

33. Benzekki, K., El Fergougui, A., & Elbelrhiti Elalaoui, A. (2016). Software-defined networking (SDN): A survey. Security and Communication Networks, 9 (18): 5803-5833. https://doi.org/10.1002/sec. 1737

34. Montazerolghaem, A. (2020). Software-defined load-balanced data center: design, implementation and performance analysis. Cluster Computing. Vol. 24 (2), 591-610. https://doi.org/10.1007/s10586-020-03134-x. ISSN 1386-7857. S2CID 220490312.

35. Dovgiy, S.O., Vorobienko, P.P., & Gulyaev, K.D. (2013) Modern Telecommunications: Networks, Technologies, Security, Economics, Regulation. Second edition (supplemented). Kyiv: "Azimuth-Ukraine" [in Ukrainian].

36. Montazerolghaem, A. (2020). Software-defined Internet of Multimedia Things: Energy efficient and Load-balanced Resource Management. IEEE Internet of Things Journal. Vol. 9 (3), 2432-2442. https://doi.org/10.1109/JIOT.2021.3095237. ISSN 2327-4662. S2CID 237801052.

37. Software-defined networking is not OpenFlow, companies proclaim. Retrieved from https://www.techtarget.com/searchnetworking/ (Last accessed: 30.06.2023).

38. InCNTRE's OpenFlow SDN testing lab works toward certified SDN product. Retrieved from https://www.techtarget.com/news/ (Last accessed: 30.06.2023).

39. Dovgiy, S.O., & Kopiika, O. V. (2023). IT infrastructure as a basic component of digital transformation. Kyiv: Yuston Publishing House LLC [in Ukrainian].

Размещено на Allbest.ru

...