ЭВОЛЮЦИЯ ВЫЧИСЛИТЕЛЬНОЙ ИНФРАСТРУКТУРЫ Текст научной статьи по специальности «Компьютерные и информационные науки»

ВЕСТН. МОСК. УН-ТА. СЕР. 15. ВЫЧИСЛ. МАТЕМ. И КИВЕРН. 2024. № 4. С. 190-233 Lomonosov Computational Mathematics and Cybernetics Journal

УДК 793.71

P. Jl. Смелянский1

ЭВОЛЮЦИЯ ВЫЧИСЛИТЕЛЬНОЙ ИНФРАСТРУКТУРЫ

«Не поднимешься на высокую гору — не узнаешь ровного места» «Из куриного гнезда феникс не вылетает» 36 китайских стратагем

Цель этой статьи — рассмотреть основные тенденции и этапы развития вычислительной инфраструктуры, ее компонентов, сформулировать основные уроки пройденного и постараться сформулировать возможные направления ее дальнейшего развития. Надо сразу подчеркнуть, что интересовать будут технологии и средства, непосредственно влияющие на состояние вычислительной инфраструктуры, основные тренды и этапы их развития. Работа не претендует на сколько-нибудь подробное изложение истории их возникновения и развития.

Ключевые слова: вычислительная инфраструктура, микроэлектроника, телекоммуникации, разработка программного обеспечения, Grid, мэйнфрейм, LSIC, мини-компьютер, персональный компьютер, сеть, операционная система, SDN, виртуализация, NFV, MANO, облачные вычисления.

DOI: 10.55959/MSU/0137-0782-15-2024-47-4-190-233

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

До тех пор, пока основным средством выполнения всего перечисленного выше являлся человек, средства вычислений и средства коммуникации не рассматривались как компоненты единой инфраструктуры и развивались независимо.

Переход экономик Франции и Англии в конце XVIII—начале XIX в., а затем и России, от аграрно-феодальной к промышленно-капиталистической формации требовал ускорения как процессов вычисления, так и процессов коммуникации. Это постоянно требовало усовершенствования инструментов для вычислений, методик (алгоритмов) расчетов, увеличения численности обученных людей, скорости коммуникации (обмена данными).

Различают несколько исторических этапов развития инструментов вычислений:

• ручной (до XVII в.);

• механический (до XIX в.);

• электромеханический (до середины XX в.);

• компьютерный этап (с середины XX в.) [1].

Скорость смены технологий постоянно нарастала [2, 3]. Компьютерный этап позволил исключить человека как средство вычислений. Появилась вычислительная техника — компьютеры,

1 Факультет ВМК МГУ, проф., д.ф.-м.н., e-mail: smelQcs.msu.ru

устройства обработки данных с программным управлением. Человеку уже не надо было самому выполнять вычисления. За ним сохранялось лишь формирование методик вычислений.

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

• как можно более глубокого использования параллелизма, т.е. одновременного выполнения нескольких действий, как при выполнении отдельно взятой команды, так и на всех этапах выполнения программы;

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

Одновременно с совершенствованием вычислителей шло развитие способов взаимодействия человека с ними. Первое время, до начала 60-х, человек должен был сам загружать данные и программы в вычислитель и получать результат расчетов. С появлением алфавитно-цифровых терминалов и мультипрограммных операционных систем с разделением времени он мог уже делать это удаленно. По мере развития каналов терминального доступа (роста скорости и протяженности линии передачи данных) инфраструктура вычислений стала меняться. Появились вычислительные центры (ВЦ), основу которых составляли мэйнфреймы — большие универсальные ЭВМ, которые обеспечивали высокий уровень надежности вычислений, благодаря избыточности аппаратного обеспечения. Операционные системы первых мэйнфреймов были оптимизированы для пакетного режима работы [4]. Позднее они стали поддерживать режим разделения времени с многотерминальной сетью, которая стала прообразом компьютерных сетей.

Появились сети ЭВМ для передачи данных между вычислителями. В первых сетях ЭВМ средства связи были специализированные, т.е. предназначались только для соединения ЭВМ между собой. Потом было осознано, что для этих целей можно использовать существующие средства коммуникации, например, телефонные сети, которые к середине XX в. охватывали около 80% населения планеты. Были созданы новые системы передачи данных, например, Ethernet, Wi-Fi, сотовые сети, системы космической связи.

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

Появление и развитие сетей ЭВМ и средств коммуникации было востребовано военными и гражданской промышленностью. Военным нужны были надежные, живучие системы коммуникации, которые нельзя было бы уничтожить однократным ударом, которые были бы способны по мере их разрушения снижать производительность, скорость работы, но сохранять способность передавать данные; надежные и высокоскоростные системы сбора и обработки данных. Промышленности нужны были средства для эффективного управления производством, развития и расширения рынка. Академическому сообществу необходимы были средства для моделирования и обработки данных экспериментов, наблюдений, управления крупными мультидисциплинарны-ми проектами. Сети ЭВМ стали основой информационных технологий. Рост возможностей вычислителей и средств передачи данных подстегивался ростом сложности и масштабностью задач, требующих решения. Большой вклад здесь внесли обработка данных научных экспериментов, потребности моделирования сложных технических систем, задачи государственного управления [2]. Во второй половине XX в. начались процессы интеграции средств коммуникации со средствами вычислений, которые коренным образом изменили представление об организации вычислений.

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

любой ее точке. Еще задолго до того, как в 1969 г. появился "зародыш Интернета" — компьютерная сеть из четырех узлов, многие специалисты в области computer science обращали внимание на потенциал удаленных вычислений (remote computing) [5]. Уже к началу 90-х появились средства, обеспечивающие удаленные вычисления на разделяемых вычислительных ресурсах, объединенных сетью передачи данных [6, 7], которые используются и по сей день. С возникновением Всемирной паутины и персональных компьютеров появилось много проектов, предлагавших разные подходы к организации удаленных вычислений на основе веб-технологии, например, [8-10] и др. Однако ни одна из них не получила широкого распространения.

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

Успехи в области микроэлектроники, телекоммуникации и информационных технологий, требования новых приложений в области науки и техники, управлении производством вдохновили специалистов на создание вычислительной инфраструктуры, основанной на идее вычислений по требованию за счет динамичного, гибкого, безопасного, скоординированного разделения ресурсов разных организаций. В 1999 г. была опубликована в [11] концепция такой вычислительной инфраструктуры, которая получила название GRID (энергосистема) по аналогии с электрическими сетями, которые предоставляют доступ к энергетическим ресурсам по требованию, на основе экономически эффективной агрегации ресурсов федерации поставщиков электроэнергии и потребителей. Попросту говоря, когда электрочайник подключают к розетке, никто не знает, энергией от какого генератора питается этот чайник. Для чайника и его владельца это абсолютно неважно.

Прошло более 20 лет, появились крупные поставщики вычислительных услуг и хранилищ данных в виде центров обработки данных, международные научные объединения, например, в области физики высоких энергий, метеорологии, где были сделаны попытки реализовать концепцию GRID — вычислений по требованию. Однако все эти попытки, по мнению авторов концепции, которая была опубликована в 2022 г. [77], не соответствовали тому, что было задумано GRID-пионерами. До сих пор еще осталось много того, что необходимо сделать, чтобы претворить в жизнь концепцию вычислений по требованию на основе неограниченно масштабируемой, эффективно виртуализируемой, программно управляемой, отказоустойчивой, безопасной, открытой федерации вычислительных ресурсов разных организаций, объединенных высокоскоростной сетью передачи данных с детерминированным качеством услуг передачи данных.

Возможности вычислительной инфраструктуры определяют три основные движущие силы:

• вычислительная техника (микроэлектроника);

• телекоммуникация;

• инженерия программного обеспечения.

Направления ее развития определяют требования приложений.

В этой статье постараемся понять, что уже удалось сделать, что не удалось и что предстоит еще сделать для того, чтобы претворить в жизнь эту многообещающую, заманчивую концепцию вычислений по требованию. Для этого мы проанализируем развитие указанных выше трех основных движущих сил к концу первой декады XXI в., рассмотрим основные свойства современных приложений и их требования, чтобы понять причины пессимистической оценки авторами концепции GRID попыток ее реализации. После этого рассмотрим, какие изменения произошли за последние 15 лет в области математических методов и в области упомянутых выше трех направлений, которые привели к качественным изменениям в управлении распределенной масштабируемой открытой вычислительной инфраструктурой с услугой "вычисление по требованию". Такой подход позволит нам увидеть, когда и при каких условиях возможности вычислительной инфраструктуры придут в соответствие с требованиями приложений.

1. Три источника, три составные части.

1.1. Микроэлектроника. Первый микропроцессор с функциями процессора обычной но тем временам ЭВМ появился в ноябре 1971 г., когда компания Intel выпустила микросхему 4004 [12]. Началась эра больших интегральных схем (БИС), содержащих до 10 ООО транзисторов на кристалле. В 1974 г. компания Intel выпустила микропроцессор 8080, который состоял из 4758 транзисторов. К 2000-м на первой сверхбольшой БИС семейства Pentium транзисторов было уже 125 млн, а производительность процессоров этого семейства оценивалась в 8.4 GFLOP. Согласно закону Мура к 2010 г. число транзисторов на кристалле должно было бы достичь 3 млрд, но удалось достичь только 1 млрд [15, 16] (см. рис. 1).

Достижения в области микроэлектроники привели к созданию в 70-х гг. нового класса вычислителей мини-компьютеров1, которые стали серьезным конкурентом мэйнфреймам основному вычислительному ресурсу вычислительных центров. Говоря современным языком, мэйнфрейм был высокопроизводительным, надежным сервером. Сравнительно невысокая стоимость мини-компьютеров и богатые функциональные возможности привели к тому, что мини-компьютеры стали вытеснять мэйнфреймы. Даже небольшие предприятия получили возможность иметь собственный компьютер. Мини-компьютеры активно стали применяться для управления технологическими процессами, позволили автоматизировать управление многими процессами на предприятиях. Однако все компьютеры одного предприятия работали автономно [13].

Inte". В043*.

• L'sp ташке»™ Intel 80Э8й^ Motwe,168020^

inter гсвбф 9 IIUH емй

mstdQO .¿Яв

^ íiCA 1802 9

¡ Tcchnotogv

10.000,000,OTO

lUráuiri 2ф

100.000,000

10,000,000

Рис. 1. Рост числа транзисторов на кристалле по годам

Начало 80-х гг. связано с еще одним знаменательным для эволюции вычислительной инфраструктуры явлением появлением персональных компьютеров. Эти вычислительные устройства были предназначены для выполнения рутинных офисных работ, работы с текстами, небольшими файлами, решения небольших вычислительных задач. Однако, как оказалось, производительность этих вычислителей была достаточной для сетевого программного обеспечения, которое было уже разработано за 70-е гг. "В воздухе витала идея" объединения этих вычислителей для решения более сложных вычислительных задач, чем офисная рутина. Их объединения также позволяло повысить доступность и эффективность использования дорогих периферийных устройств и дисковых массивов. Поэтому персональные компьютеры стали активно соединять в локальные сети, причем не только в качестве клиентских компьютеров, но и в качестве центров хранения и обработки данных, т.е. сетевых серверов, потеснив с этих ролей мини-компьютеры и мэйнфрей-

1Первый в мире мипи-компыотер появился в СССР в 1958 г. в МГУ. это была ЭВМ "Сетунь" [14]. Автором и руководителем проекта был Н.П. Врусепцов.

Рис. 2. Динамика роста производительности вычислителей общего назначения по годам

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

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

Updated 28th of February 2024

Следующим важным шагом в развитии микроэлектронной элементной базы вычислителей стало появление в 1988 г. промышленных микропроцессоров с суперскалярной архитектурой, где блок управления микропроцессора мог запускать на выполнение сразу несколько арифметико-логических команд, т.е. этому блоку было доступно несколько арифметико-логических блоков. В начале 2000-х появились многоядерные микропроцессоры, т.е. процессоры, у которых было несколько блоков управления, каждый из которых имел свой набор арифметико-логических блоков. Они могли параллельно выполнять несколько потоков команд разных программ. Это резко повысило производительность серверов (см. рис. 2). На этом рисунке динамика роста производительности дана в специальных единицах CPU mark, которые вычисляются но специальной формуле [17]. Эта формула дает комплексную оценку производительности в зависимости не только от частоты и количества тактов на команду процессора, но и учитывает скоростные характеристики памяти и дисков.

Появились компактные аппаратные серверы в конфигурации блейдов (blade лезвие). Это позволило собирать в одну стойку (гаек) до 20 серверов, соединяя их между собой через коммутатор в локальный вычислительный комплекс серверную ферму. Позднее несколько таких стоек стали объединять между собой высокоскоростной сетью. Такое объединение послужило технической основой для современных центров обработки и хранения данных.

В 1999 i'. появилась СБИС для обработки изображений графический процессор (ГП). Довольно быстро специалисты осознали, что с помощью такого процессора можно существенно быстрее выполнять однотипные операции над большими массивами данных по сравнению с традиционными центральными процессорами (ЦП). С точки зрения архитектуры ЦП и ГП относятся к разным классам вычислителей: ЦП относится к классу Single Instruction Single Data, т.е. когда в последовательном потоке команд, каждая применяется к строго определенному, ограниченному числу данных; ГП относится к классу Single Instruction Multiple Data, т.е. ГП позволяет применять одну и ту же команду одновременно к большому массиву данных. Например, такие операции возникают при работе с матрицами, обработке изображений и т.п. [18]. Устройство ГП в определенном смысле проще несколько блоков управления и у каждого десятки, сотни

арифметико-логических блоков ядер.

Появление ГП не было "новым словом" в архитектуре вычислителей. По существу ГП воспроизводил идею матричного сопроцессора, но на новом технологическом уровне. Например, в 1980 I'. компания 1СЬ выпустила матричный процессор БАР, который имел 4096 процессорных элементов или арифметико-логических блоков в нашей терминологии [19]. На рис. 3 представлено сопоставление производительности ГП и ЦП на одних и тех же массивах данных [18].

11

Рис. 3. Сопоставление роста быстродействия ЦП и ГП

Появление СБИС также дало мощный импульс развитию важного класса вычислителей суперкомпьютеров. Архитектура суперкомпьютеров основана на идеях параллелизма и конвейеризации вычислений. В этих машинах параллельно, т.е. одновременно, выполняется очень большое количество операций. Уже в 90-е гг. суперкомпьютеры стали строить в виде специализированной высокоскоростной сети, соединявшей кластеры из модулей микропроцессоров. Кластеры, в свою очередь, представляют собой сеть, соединяющую вычислительные модули, каждый из которых мог состоять из определенного числа микропроцессоров, возможно, с разной архитектурой, например, комбинации ЦП и ГП, возможно в сочетании со специализированными процессорами на программируемых логических интегральных схемах (ПЛИС). При этом и такая сеть, и микропроцессоры, используемые в кластерах, строятся с использованием самых последних достижений микроэлектроники и телекоммуникации, на момент создания суперкомпьютера.

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

1.2. Телекоммуникация: Сети передачи данных. В начале 60-х гг. в США и в СССР

были начаты исследования методов передачи данных, когда весь передаваемый массив данных делился на блоки, которые быстро и независимо друг от друга передавали но линиям связи, собирая в точке назначения. Суть исследований состояла в создании методов разбиения на блоки, которые назывались пакетами, определения структуры пакетов, способов кодирования данных в пакете, сбора и декодирования данных в точке назначения. Организация процесса передачи служила двум основным целям: не допустить перехвата пакетов с данными, но даже если таковое и произойдет, не дать злоумышленнику возможности собрать весь передаваемый массив данных целиком, обеспечить доставку данных до точки назначения даже в том случае, если один или несколько отдельных пакетов были уничтожены или не дошли но каким-то причинам. Позже, такой метод передачи данных получил название пакетной коммутации. В 1969 г. агентство перспективных исследований США (US Department of Defence's Advanced Research Projects

Agency) инициировало проект ARPANET по разработке стека протоколов для передачи данных между компьютерами на основе метода пакетной коммутации. Позже, на основе опыта проекта ARPANET, была создана сеть, объединившая академические организации США National Science Foundation Network (NSF-net), которая и получила название Интернет.

В 70-е гг. шла активная разработка архитектуры, программного обеспечения, реализующего обмен данными с помощью пакетной коммутации. Шла острая конкуренция между международным институтом стандартизации (International Standard Organization — ISO) и агентством DARPA за то, чья модель сетевого взаимодействия и ее программное обеспечение станет стандартом для промышленности. Организация ISO разрабатывала так называемую эталонную модель взаимодействия открытых систем (Open System Interconnection — OSI). Этот проект преследовал разработку принципов и стандартов, которые бы позволили строить системы, объединяя функциональные компоненты разных производителей так, чтобы они могли свободно обмениваться данными без специальных доработок. Эта цель была крайне актуальна. Уже в 60-е гг. возникла проблема несовместимости устройств, реализующих одни и те же функции, но изготовленных разными производителями. Это создавало массу технических проблем и было экономически невыгодно. Поэтому было решено создать для сетевого оборудования набор стандартов, регламентирующих интерфейсы и процедуры передачи пакетов, равно как и саму структуру пакета или, точнее говоря, протокольной единицы данных.

В проекте ARPANET фокус исследований был сосредоточен на протоколах последовательной передачи пакетов по неизменным на время передачи маршрутам [20]. Результаты этого проекта были положены в основу сети академических организаций США NSFnet, которая, по замыслу архитекторов Интернет, должна была объединять на основе стека протоколов TCP/IP сети разных академических организаций без нарушения их внутреннего устройства. В 1989 г. Интернет стал общедоступным [21].

Появление программного обеспечения, реализующего стек протоколов TCP/IP, в рамках свободно распространяемой версии FreeBSD операционной системы UNIX для мини-компьютеров, существенно ускорил "победу" модели сетевого взаимодействия TCP/IP и ее программного обеспечения над эталонной моделью OSI ISO и ее программной реализацией на базе протокола Х.25. В первой половине 90-х гг. XX в. модель сетевого взаимодействия TCP/IP стала стандартом de facto. Как уже было отмечено, появление мини-компьютеров, а затем и персональных компьютеров дало толчок к развитию локальных сетей передачи данных. Локальная сеть объединяла компьютеры одного предприятия, университета, расположенные в одном и то же здании, либо на локальной территории, где расстояние между компьютерами составляло не более нескольких километров, например, в кампусе одного и того же университета.

В 70-е гг. каждое предприятие само решало, как и с помощью каких средств объединять мини-компьютеры в локальную сеть. Уже в середине 80-х гг. положение дел изменилось: появились стандартные технологии объединения компьютеров в сеть — Ethernet, Arcnet, Token Ring, Token Bus [22], несколько позже FDDI [23]. Это позволило обеспечить совместимость разных ОС, поддерживающих один и тот же стек сетевых протоколов, а также стандартизировать интерфейс ОС с сетью передачи данных и реализовать его в виде набора драйверов сетевых адаптеров.

Все стандартные [24, 25] технологии локальных сетей опирались на тот же принцип коммутации пакетов, который был с успехом опробован и доказал свои преимущества при передаче данных в глобальных компьютерных сетях. Стандартные сетевые технологии существенно облегчили и упростили задачу построения локальной сети. Достаточно было приобрести сетевые адаптеры соответствующего стандарта, например, Ethernet, стандартный кабель, присоединить адаптеры к кабелю стандартными разъемами и установить на компьютер одну из популярных сетевых операционных систем, например, Novell NetWare. После этого сеть начинала работать, и последующее присоединение каждого нового компьютера не вызывало никаких проблем, если на нем был установлен сетевой адаптер, поддерживающий тот же протокол передачи данных.

Конец 90-х выявил явного лидера среди телекоммуникационных технологий локальных сетей — семейство Ethernet, в которое вошли классическая технология Ethernet 10 Мб/с, а также Fast Ethernet 100 Мб/с и Gigabit Ethernet 1000 Мб/с. Низкая стоимость оборудования Ethernet,

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

Разработчики локальных сетей привнесли в организацию работы пользователей много ново-i'o. Так, стало намного проще, чем в глобальных сетях, получать доступ к сетевым ресурсам, таким, как принтеры, дисковые массивы, специализированное оборудование. Пользователю не надо было запоминать особенности интерфейсов работы с таким оборудованием. Он мог после соединения через сеть с нужным ему ресурсом обращаться к нему с помощью тех же команд, которые он применял при работе с локальными ресурсами на своем компьютере. Это освободило непрофессиональных пользователей от необходимости изучать специальные (и достаточно сложные) команды для работы в сети.

Эти возможности стали доступны, прежде всего, благодаря появлению качественных кабельных линий связи, на которых даже сетевые адаптеры первого поколения обеспечивали скорость передачи данных до 10 Мб/с. Из-за небольшой протяженности каналов связи в локальных сетях, их стоимость была вполне приемлемой. Поэтому экономное расходование пропускной способности каналов, что характерно для глобальных сетей и по сей день, никогда не выходило на первый план при разработке протоколов локальных сетей. В таких условиях основным механизмом прозрачного доступа к ресурсам локальных сетей стали периодические широковещательные объявления серверами о своих ресурсах и услугах. На основании таких объявлений клиентские компьютеры составляли списки имеющихся в сети ресурсов и предоставляли их пользователю.

Сегодня, несмотря на солидный возраст, Ethernet продолжает доминировать в сетевой инфраструктуре во всем мире [26]. Требования к скорости передачи данных в промышленных отраслях постоянно растут, поскольку сложность и взаимосвязь корпоративных приложений для обработки данных продолжают расти. Такие приложения, как искусственный интеллект, различные виды виртуальной реальности, системы видеонаблюдения, системы распределенного хранения данных, озера данных и повышение качества аудио- и видеопередачи, везде требуют все большей пропускной способности каналов связи. На рис. 4 показан рост объемов передаваемых данных по годам в экзабайтах в месяц [28].

2017 2018 2019* 2020* 2021" 2022*

Рис. 4. Динамика роста объемов передаваемых данных в экзабайтах в месяц

В 90-е 1ч\ XX в. в сети Интернет стали активно использовать спутниковую связь. В этой технологии искусственные спутники выступают в роли ретрансляторов сигналов, поступающих от

наземных терминалов. Такие ретрансляторы объединяют в группировки, которые могут располагаться на орбитах разной высоты: геостационарных, среднеорбитальных и низкоорбитальных. С увеличением количества спутников на орбите и угла её наклона к экватору растет зона покрытия поверхности Земли, производительность и качество связи.

В 1997 г. появился протокол для беспроводного обмена данными в локальной сети Wireless Fidelity — WTi-Fi. Сегодня WTi-Fi-cein седьмого поколения обеспечивают скорость передачи данных до 30 Гб/с. Постоянно совершенствовались сети сотовой связи, уже сменилось 5 поколений этих сетей: 1G-5G. В 2009 г. выходит стандарт для оптических сетей связи Optical Transport Network, на основе технологии l)\YI).\I. которая использует коммутацию оптических каналов связи и обеспечивает пропускную способность по одной оптической линии до 600 Гб/с.

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

Сегодня сеть является важнейшим компонентом вычислительной инфраструктуры, соединяющей все инфраструктурные ресурсы для предоставления услуг. К концу 2010 г. практически все существующие виды технологий передачи данных были конвергентны. Основным стеком протоколов стал стек TCP/IP. Структура Интернет стала иерархической, постоянный рост объемов передаваемых данных требовал высоких скоростей передачи. С этой целью были разработаны новые протоколы управления трафиком, например, Multi-Protocol Labeling Switching — MPLS.

Однако, несмотря на достигнутый прогресс, к концу 2010 г. компьютерные сети были дороги, сложны и трудны в управлении. Они были полны разнообразного оборудования: маршрутизаторы, коммутаторы, программно-аппаратные middlebox'bi, примерами которых являются различные сетевые экраны, трансляторы адресов, балансировщики нагрузки, системы обнаружения вторжений, анализаторы пакетов, транскодеры и многое-многое другое. Весь этот "зоопарк" был наполнен проприетарным, т.е. являющимся собственностью производителя, программным обеспечением, закрытым от любых модификаций. Это программное обеспечение накапливалось годами в длительном процессе стандартизации и обеспечения интероперабельности и безопасности. Сетевые администраторы были вынуждены конфигурировать каждое устройство в сети индивидуально вручную, используя разные средства разных производителей. Некоторые производители предлагали для настройки своего оборудования определенную централизацию, но за счет проприетарных протоколов и интерфейсов. Такая организация управления сетью с трудом поддается инновациям, сложность управления растет с ростом сети, что ведет к росту как капитальных, так и эксплуатационных затрат. Характеристики качества каналов передачи данных были не детерминированы, количество протоколов и их вариантов достигало нескольких тысяч, управление сетью не было автоматизировано, не было сетевой операционной системы, т.е. программной системы, которая была бы ориентирована на управление не только доступом к сети передачи данных, но и непосредственно к сетевому оборудованию, управлению его функциональностью. Взаимодействие через сеть передачи данных было подвержено значительному числу угроз безопасности. Сеть как компонент вычислительной инфраструктуры стала важным элементом критических технологий, например, систем управления технологическими процессами. Инцидент на Бушерской АЭС в Иране в сентябре 2011 г. стал шоком для всех стран.

1.3. Инженерия программного обеспечения. В 1968 г. в деревне Гармиш-Патенкирхен (ФРГ) прошла конференция по проблемам разработки программного обеспечения. Там впервые прозвучал термин "инженерия программного обеспечения" (Software Engineering), трактуемый как технологии для систематического, дисциплинированного, измеримого подхода к разработке, функционированию и сопровождению программного обеспечения (далее ПО). Важным результатом конференции стало осознание, что разработка программного обеспечения стала индустриальной деятельностью. Все больше и больше массово выпускаемых продуктов содержало программные компоненты. Уже в 70-е гг. сложность программных систем превысила сложность систем, с которыми доводилось сталкиваться инженерам [30]. В силу естественных ограничений

интеллектуальных возможностей человека, его способности удержать в голове все подробности организации и функционирования сложной системы, нужны были соответствующие методы и средства разработки, мониторинга и поддержания функционирования разработанного ПО [2931].

Уже к началу 90-х гг. XX в. оборот в индустрии производства программного (только программного!) обеспечения превысил оборот автомобилестроения в США. К этому времени уже наметилась существенная диспропорция в темпах развития основных составляющих прогресса вычислительной инфраструктуры. Вот цифры, характеризующие их развитие к этому времени

[32]:

• производительность микропроцессоров удваивалась без увеличения стоимости кристалла каждые 18 месяцев, т.е. на 67% в год;

• пропускная способность сетей передачи данных возрастала на 75% в год;

• производительность труда программистов (скорость создания программ) — 4-5% в год.

Устранение этой диспропорции требовало специальных усилий.

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

Создателям уже первых вычислительных машин было ясно, что описание алгоритма в терминах системы команд машины очень трудоемко. Поэтому уже в то время возникла идея создания искусственного языка, который позволил бы ускорить процесс создания программ. Именно в этот период для преодоления трудностей программирования в машинном коде родилась фундаментальная для технологии программирования концепция сборочного программирования, когда программа собирается из фрагментов, которые называются модулями, и работа которых была бы тщательно выверена. Однако надежда на то, что языки решат все проблемы разработки больших программ, не оправдалась. Дело в том, что, несмотря на рост мощности компьютеров и опыта программирования на языках высокого уровня, росла сложность задач и приложений для их решений. Попытки решения таких задач стали выявлять ограниченность первых языков программирования. Важной вехой в их развитии и развитии технологий программирования стала разработка первого в мире объектно-ориентированного языка программирования Simula-67 для моделирования сложных систем [33]. Сейчас этот язык можно охарактеризовать как объектное расширение Algol 60. Главный вопрос, который поставила работа О. Дала и К. Найгаарта — важно не только то, на каком языке программировать, а то, как это делать. Это положило начало исследованиям методологий и технологий программирования.

Огромный вклад в развитие технологий программирования внес проект Multics — Multiplexed Information and Computing Service (MIT в 1963-1974 гг.), руководимый профессором Ф. Корбато [34]. Проект Multics был посвящен исследованиям и разработке принципов организации мультипрограммных операционных систем с разделением времени. В рамках этого проекта существовало четкое разделение концепции файлов (сегментов), вычислительных процессов и их адресного пространства. С некоторыми оговорками можно утверждать, что в проекте Multics были разработаны такие принципы, как: построение систем управления разделением времени между несколькими программами, управления виртуальной памятью, заложены основы виртуализации вычислительных ресурсов, создана первая полностью централизованная файловая система с поддержкой древовидной иерархической структуры, была впервые реализована концепция dvnamic linking (динамическое связывание) между исполняемой программой и модулем, содержащим код и данные, которые могут использовать и другие программы, и который находится в памяти компьютера, заложены основы того, что мы сейчас называем информационной безопасностью — защитой кода и данных исполняемых программ от взаимного влияния.

Непосредственно результаты проекта Multics не получили коммерческой популярности. Однако годы спустя идеи этого проекта дали импульс созданию ОС UNIX, языка программирования С, многопроцессорных операционных систем для поддержки объектно-ориентированного программирования [35]. Этот проект стал школой для многих известных программистов — Д. Ричи, К. Томпсона, Д. Бриклина и Б. Френкстона, А. Джоунс, Б. Дисков.

В 1968 г. компания IBM выпустила на рынок операционную систему VM/370 для мэйнфрейма IBM-370 с поддержкой технологии виртуализации [36]:

• в основе системы был монитор виртуальных машин — то, что мы сейчас называем гипер-визором;

• запускаемые виртуальные машины (ВМ) использовали мощности мэйнфрейма одновременно, без построения очередей;

• на каждой ВМ можно было запустить свою полноценную ОС, т.е. каждый пользователь получал в свое распоряжение отдельный виртуальный компьютер;

• ВМ были независимы и не влияли друг на друга.

Это решение было гораздо удобнее ОС с разделением времени, так как:

1) виртуальные машины используют ресурсы мэйнфрейма совместно, а не по очереди, поэтому эффективность выше;

2) каждая ВМ — копия исходной аппаратуры, можно запустить разные ОС, на разных виртуальных машинах;

3) у каждого пользователя своя ОС, поэтому они не влияют друг на друга — вся система становится надежнее.

Началась эра виртуализации. Пользователи подключались к мэйнфрейму через сеть терминалов. По существу это был прообраз "тонких клиентов". В распоряжении каждого пользователя были собственные клавиатура, мышь и монитор. К одному мэйнфрейму могли подключиться сотни терминалов. Можно сказать, в современной терминологии, IBM-370 выполняла функции Центра Обработки Данных (ЦОД). Начало 1970-х ознаменовалось рождением трех языков, роль которых в развитии современного программирования переоценить невозможно: Pascal (Н. Вирт, 1970), С (К. Томпсон и Д. Ритчи, 1971), Smalltalk (А. Кей, 1972). Эти языки положили начало трем важным направлениям в технологиях программирования: структурному (Pascal), системному (С) и объектно-ориентированному программированию (Smalltalk). Эта тройка определила и разные языковые ветви с непохожим синтаксисом и существенно отличающейся языковой культурой.

Стали интенсивно развиваться технологии программирования: нисходящей разработки (так называемого подхода "сверху вниз") и структурного программирования, модульного программирования, методов и средств сборочного программирования (когда программа собиралась из ранее написанных модулей). Активно велись исследования проблем обеспечения надежности и переносимости программ, управления коллективной разработкой программ. Объектно-ориентированное программирование обеспечило естественный подход к построению программных систем, согласно которому программа проектировалась как совокупность взаимодействующих друг с другом объектов, являющихся экземплярами определенных иерархически упорядоченных классов.

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

К 1987 г. операционные системы получили средства для работы со всеми основными технологиями передачи данных как в локальных (Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, ATM), так и глобальных сетях (Х.25, Frame Relay, ISDN, ATM), а также протоколы

для создания гетерогенных сетей (IP, IPX, AppleTalk, RIP, OSPF, BGP). Появились специализированные ОС, предназначенные исключительно для сетевого оборудования. Например, сетевая операционная система IOS компании Cisco Systems для маршрутизаторов обеспечивала работу программного обеспечения, реализующего стек сетевых протоколов.

В 90-х гг. сетевые технологии и сеть Интернет прочно вошла в обиход даже весьма отдаленных от компьютерной тематики областей человеческой деятельности. Развитие информационных технологий и их проникновение в обычную жизнь приобрело лавинообразный характер. Стали широко использоваться устройства, которые по сути являлись компьютерами, так как программно реализовывали функции традиционных устройств: телефона, плеера, органайзера, диктофона, фотоаппарата, видеокамеры, сканера и т.д. Причем зачастую одно устройство выполняло множество функций. Программируемой стала даже бытовая техника: телевизоры, стиральные, швейные и посудомоечные машины; микроволновые и электрические печи; кофемолки и холодильники.

Производство встраиваемых систем потребовало развития языков программирования и специальной технологии для программирования встраиваемых систем. В 1995 г. компания Sun Microsystems предложила технологию для программирования интеллектуальных устройств — технологию Jini со средствам программирования на объектно-ориентированном языке Java и с применением кроссплатформенных компиляторов для этого языка. В реализации языка Java для кроссплатформенной разработки программ были использованы принципы компиляции и интерпретации, что позволяло писать приложения, которые могли работать на разных аппаратных платформах и операционных системах без переписывания кода приложения.

Появление Всемирной паутины (World WTide Web) было подобно взрыву. За 5 лет с момента своего возникновения в 1991 г., ее стали использовать более 200 млн человек. Это пример самого стремительного распространение технологии за всю историю человечества. Всемирная паутина дала импульс лавинообразному появлению новых технологий разработки приложений, расцвету технологий виртуализации. Начали развиваться решения для серверной виртуализации.

Стало меняться само понятие приложения. Оно становится распределенным, интерактивным, многокомпонентным. Этот процесс сопровождался появлением новых языков программирования. Так, в 1995 г. появился язык JavaScript для управления элементами веб-страниц, придания им динамичности и интерактивности.

По мере развития интернет-технологий стало ясно, что интерактивных веб-страниц с элементами JavaScript недостаточно для решения множества задач. Для программирования на стороне сервера с целью создания динамических веб-страниц стали применяться уже существующие к тому времени языки Perl и Python. Начался процесс стандартизации интерфейсов для взаимодействия веб-сервисов. Примером одного из первых таких стандартов может служить интерфейс CGI (Common Gateway Interface — "интерфейс общего шлюза"). Становилось все более очевидным, что ни один язык не способен разрешить все проблемы, возникающие при разработке веб-сервисов, в одиночку. Как результат конвергенции языков HTML, Javascript и XML в 2005 г. появился "сплав" языков и технологий, получивший акроним AJAX (Asynchronous JavaScript and XML — "асинхронный JavaScript и XML"). Новизна этой технологии заключалась в возможности обмена данными браузера с веб-сервером в "фоновом" режиме. В результате, при обновлении данных веб-страница не перезагружалась полностью, и веб-приложение работало быстрее.

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

Сегодня благодаря развитию вычислительных средств и высокоскоростных систем передачи

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

Виртуализация вычислительных ресурсов в распределенной вычислительной среде столкнулась с проблемой фрагментации вычислительных ресурсов. Дело в том, что пока все приложения работали на одном и том же вычислителе, как например в случае VM-370, проблем не возникало. Когда же стали запускать приложения на серверных фермах, то, так как первые системы виртуализации не допускали миграции виртуальных машин с одного сервера на другой, возникла проблема фрагментации вычислительных ресурсов, аналогичная проблеме фрагментации физической памяти при ее виртуализации. В начале 2000-х компания VMware представила продукт для рынка серверов х86 — ESX Server, который позволил решить проблему фрагментации вычислительных ресурсов за счет роста скорости передачи данных в локальной сети серверной фермы, а с другой стороны, благодаря созданию технологии миграции виртуального вычислительного ресурса между физическими серверами. Позже появилось много других решений: гипервизоры Xen, OpenVZ и др. А технологии виртуализации легли в основу облачных технологий.

Как уже было отмечено, в 80-х гг. прошлого века вычислительная инфраструктура практически любой организации имела клиент-серверную архитектуру. В те времена вычислительные инфраструктуры были достаточно "замкнутыми" — каждая была предназначена для решения конкретной совокупности задач и не могла взаимодействовать с другими без специально написанного программного кода. В 90-е гг. прошлого века под влиянием веб-технологий возникла концепция сервисно-ориентированной архитектуры (Service-Oriented Architecture, SO А), основными принципами которой были [37]:

• представление приложения как множества взаимодействующих сервисов со стандартизованным интерфейсом;

• возможность использования одного и того же сервиса в сочетаниях с разными другими сервисами, независимо от их технологий разработки;

• возможность автономного масштабирования, развертывания и поддержки каждого сервиса.

Для реализации этой концепции возникла потребность в стандартном способе взаимодействия компонентов приложений-сервисов, которые были созданы с использованием разных технологий, и которые можно было бы исполнять на физически разных вычислителях и под разными ОС.

Вначале, следуя концепции объектно-ориентированного программирования, когда приложение рассматривалось как совокупность взаимодействующих экземпляров объектов, была разработана и стандартизирована технология Common Object Request Broker Architecture — CORBA. Эта технология обеспечивала:

• вызовы удаленных процедур, независимо от платформы их выполнения (Remote Procedure Call);

• транзакции обмена данными (в том числе удаленные!);

• безопасный обмен данными;

• событийное управление;

• независимость от языка программирования, ОС, аппаратной платформы выполнения, сетевой среды взаимодействия объектов;

• язык описания интерфейсов для обмена данными (Interface Definition Language, IDL).

Однако проблемы, связанные с недетерминизмом времени обращения к объекту и реакции объекта (например, CORBA не позволяла идентифицировать, является ли объект локальным по отношению к вызывающему его объекту, т.е. расположенным на том же самом сервере, или он является удаленным), сложность протоколов прикладного уровня для работы через стандартный стек TCP/IP, не дали ожидаемого эффекта.

Исправить указанные выше недостатки позволили веб-технологии:

• протокол HTTP;

• платформонезависимые языки описания данных, такие, как XML, JSON;

• создание интерфейса Architectural Styles and the Design of Network-based Software Architectures — REST;

• GraphQL — язык запросов и работы с данными с открытым исходным кодом для построения веб-ориентированных программных интерфейсов.

Произошел переход от методов удаленного вызова объектов к обмену сообщениями между веб-сервисами — одному из основных принципов SOA. Хотелось бы подчеркнуть, что SOA — это концепция, а веб-сервисы — это технология, одна из возможных для реализации принципов SOA. На этом история развития SOA не закончилась, но об этом ниже.

Другой важной вехой в развитии технологии разработки сложных, крупномасштабных научно-технических приложений в конце 90-х стал стандарт High Level Architecture (HLA). Этот стандарт был предназначен для создания и работы больших имитационных моделей сложных систем, для стандартизации и облегчения их построения путем повторного использования уже существующих имитационных моделей [38, 39]. Стандарт HLA [40] был ориентирован на применение в аэрокосмической, биомедицинской, автомобильной отраслях, SCADA-системах, а также в научно-исследовательском, инженерном и промышленном моделировании. Основными соображениями при его разработке были:

• простые "монолитные" имитационные модели не могут удовлетворить потребности профессиональных пользователей;

• все возможные сферы применения имитационного моделирования заранее неизвестны;

• должны быть предусмотрены возможности произвольного комбинирования отдельных имитационных моделей в сложные имитационные комплексы;

• архитектура распределенного моделирования должна быть максимально открыта для будущих технологий моделирования и имитации.

В терминах HLA модель — это федерация, состоящая из федератов, которые определяют действия над объектами, которые имеют состояния, описываемые наборами атрибутов. Федераты представляют собой математические описания поведения объектов — имитационные модели, заданные программно или представленные значениями датчиков аппаратных средств. Фактически федератами могут быть как имитационные модели, так и реальное оборудование или специальное программное обеспечение. Федератом может быть и человек, интерактивно взаимодействующий с каким-то из федератов. Единственным требованием является обеспечение единого интерфейса для взаимодействия. На рис. 5 показана схема иерархии федерации [41].

Взаимодействие федератов осуществляется с помощью специальной надстройки Run Time Infrastructure (RTI) [42, 44] над операционной системой того компьютера, на котором работает конкретный федерат. Взаимодействуют федераты с помощью механизма подписки. Федерат, заинтересованный в получении определенных атрибутов и сообщений от другого федерата, должен явно подписаться на них через RTI.

Федерация

I

Федерат Федерат

1

Объекты

I

Атрибуты

Рис. 5. Схема иерархии федерации

Итак, состояние вычислительной инфраструктуры в первой декаде 2000-х можно было бы охарактеризовать следующим образом: шла борьба за то, какой должна быть архитектура процессоров, бушевали войны в области операционных систем, перспективность Unix все еще вызывала вопросы, виртуализация вычислительных ресурсов еще не стала широко распространенной технологией, сеть не была виртуализирована, не имела программного управления, CORBA была на подъеме, а веб-технологии осваивали A.JAX. На рис. 6 представлены итоги опроса читателей журнала PCweek но вопросу, какие технологии с их точки зрения оказали значительное влияние на образ жизни и работы людей за период 2000 2010 гг. Ответы читателей говорят сами за себя: на первых местах оказались технологии телекоммуникации, средства вычислений многоядерные процессоры, средства виртуализации вычислительных ресурсов.

Достижение с помощью технологии Ethernet (GE) скорости порядка Гб/с [45] уравнивало эффективность и оперативность работы с удаленными сервисами но сравнению с локальными. Эксперименты [46] показали, что объединение уникальных ресурсов, таких, как суперкомпьютеры, позволяют создать новые виды вычислительной инфраструктуры, уникальные но своим возможностям и адаптированные к уникальным требованиям конкретного приложения [47]. Разработки приложений, состоящих из тесно связанных компонентов, взаимодействие между которыми было охраничено но времени, требовали создания специализированного инструментария для поддержки обмена данными между компонентами приложения, работающими на разных площадках. Такие приложения как, например, комплексное моделирование атмосферы с учетом модели океанов, моделирование информационно-управляющих) комплекса летательных аппаратов из-за сложности создания необходимой инфраструктуры, были малочисленны [48]. Для таких приложений создавалась специализированная, изолированная вычислительная инфраструктура. Основное внимание в этих проектах уделялось созданию средств разработки и платформе, обеспечивающей согласованное выполнение распределенного приложения в среде гетерогенных ресурсов с гарантированным соблюдением временных ограничений. Наиболее значимым здесь был проект I-WAY [49], который объединил около 50 научно-исследовательских групп, приложения которых взаимодействовали через национальную высокоскоростную научно-исследовательскую сеть США. Результатом этого проекта явилась инфраструктура I-Soft [50, 51].

2. Концепция GRID2. Как уже было отмечено выше, в 1999 г. Я. Фостер и К. Кеееель-ман опубликовали в [11] концепцию вычислительной инфраструктуры под названием GRID для

"Представленное здесь описание концепции GRID ближе всего соответствует так называемому вычислительному GRID.

Рис. 6. Технологии, которые оказали значительное влияние на образ жизни и работы людей за период 2000 2010 гг.

сложных распределенных вычислительных задач, где вычисления — это услуга по требованию. (Достаточно подробное изложение этой концепции на русском языке можно найти в [52, 53].) Следует признать, что общепринятого определения, что такое GRID, нет. Вот как сами авторы определяют концепцию GRID-инфраструктуры: "Компьютерная сеть GRID — это аппаратно-программная инфраструктура, которая обеспечивает надежный, устойчивый, повсеместный и недорогой доступ по требованию (выделено мною. — P.C.) к высокопроизводительным компьютерным ресурсам" [11]. Основные ее свойства они определяют так:

• "Координирует ресурсы, которые не подлежат централизованному контролю... (GRID объединяет и координирует ресурсы и пользователей, которые живут в разных доменах управления, — например, рабочий стол пользователя или центральный компьютер; разные административные подразделения одной и той же компании или разных компаний; решает вопросы безопасности, политики, оплаты, членства и т.д., которые возникают в этих условиях. В противном случае мы имеем дело с локальной системой управления.);

• использует стандартные, открытые протоколы и интерфейсы общего назначения... (GRID построен из протоколов и интерфейсов общего назначения, которые решают такие базовые проблемы, как аутентификация, авторизация, обнаружение ресурсов и доступ к ресурсам. ... [Это] важно, чтобы эти протоколы и интерфейсы были стандартными и открытыми. В противном случае мы имеем дело с системой, специфичной для приложения.);

• предоставляет нетривиальные качества обслуживания (выделено мною. — P.C.). (GRID позволяет скоординированно использовать его ресурсы для предоставления услуг различного качества, касающихся, например, времени отклика, пропускной способности, доступности и безопасности и/или совместного размещения нескольких типов ресурсов для удовлетворения сложных требований пользователей, поэтому полезность объединенной системы значительно больше, чем полезность суммы ее частей").

Научное сообщество обратило серьезное внимание на концепцию GRID-инфраструктуры, поскольку казалось, что для этого есть все возможности — высокопроизводительные вычислители почти достигли быстродействия 10 Tflops [54], микропроцессоры — сотен Mflops, пропускная способность каналов связи достигла 1 Gbps, благодаря успехам в области микропроцессорной техники, телекоммуникации. Веб-технологии, концепция SOA открыли новые возможности для разработки сложных приложений. Например, специалисты, проектировавшие Большой адронный коллайдер (БАК), осознали необходимость объединения сотен вычислительных систем, расположенных в географически разных местах, чтобы обеспечить анализ многих петабайтов данных, которые будут возникать в ходе экспериментов. С этой целью были инициированы проект EU Data GRID в Европе [55], а также проекты Particle Physics Data GRID (ppdg.net) и GRID Physics Network [56] в США, в России Russian Segment EU Data Grid [57-60]. Эти проекты стали основой для проекта Open Science GRID в EGEE США, а затем проекта EGI в Европе, а также международной вычислительной сети LHC (LCG) [61].

Многие GRID-подобные проекты координировались и финансировались как сугубо национальные для поддержки научно-исследовательского сообщества внутри страны. Например, Russian Date intensive Grid [62], China GRID [63], Национальная GRID-служба Великобритании (ngs.ac.uk), Thai GRID в Таиланде (thai GRID.or.th) [64], немецкая D-GRID (dgrid.de) [65], INFNgrid (italiangrid.org), Dutch GRID (dutchgrid.nl) и распределенный суперкомпьютер ASCI (DAS) в Нидерландах, Garuda GRID в Индии [66], NAREGI в Японии [67] и Open Science GRID в США [68]. Схематичное представление G RID-архитектуры из [11] приведено на рис. 7.

Здесь:

• Fabric — уровень доступа к ресурсам, коими могут быть вычислители, дисковые массивы, сетевые устройства и т.п. Ресурс может быть и логической сущностью — файловой системой, каталогом. Как отмечено в [52], этот уровень предоставляет набор интерфейсов для управления локальными ресурсами;

Appücääcri

_Л_

Cdleaive

Resource

ûmectrvity

Fafcric

Рис. 7. Схематичное представление GRID-архитектуры

• Connectivity обеспечивает "надежный транспорт и маршрутизацию сообщений, а также присвоение имен объектам сети, а протоколы аутентификации этого уровня, основываясь на коммуникационных, предоставляют криитографичсскис механизмы для идентификации и проверки подлинности пользователей и ресурсов" [52] ;

• Resource функциональность этого уровня обеспечивает согласование механизмов обеспечения безопасности, инициализацию, доступ и мониторинг ресурсов;

• Collective обеспечивает взаимодействие всего множества используемых ресурсов, их планирование, диагностику, репликацию данных;

• Application этот уровень обеспечивает доступ и запуск пользовательских приложений в GRID-ереде, которые могут взаимодействовать с помощью служб этой среды.

111 [ ] 1'|м|к'и с г рил-сервисы

\рац«|ив

Рссурсими центр N

Рис. 8. Обобщенная схема GRID-инфраструктуры

На рис. 8 представлена обобщенная схема вычислительной GRID-инфраструктуры [52]. Интерфейс пользователей предназначен для загрузки и запуска приложений/заданий, контроля их выполнения и получения результата, размещения данных. Ресурсный центр предоставляет ресурсы двух типов (или одного из них):

• вычислительный ресурс, который называется Вычислительный элемент и обеспечивает выполнение компонентов приложения;

• ресурс хранения данных, который обеспечивает хранение и транспортировку данных между аналогичными ресурсами и/или данным ресурсом и пользователем. Базовые GRID-службы3 обеспечивают работу всей GRID-инфраструктуры. Они распределены между следующими подсистемами :

• подсистема управления загрузкой — здесь находится служба распределения заданий — брокер ресурсов;

• подсистема управления данными — включает службу файлового каталога и службу каталога метаданных;

• подсистема информационного обслуживания и мониторинга GRID-инфраструктуры — здесь располагаются все службы регистрации и учета ресурсов GRID;

• подсистема безопасности и контроля прав доступа, которая включает службу выдачи и поддержки сертификатов, службу регистрации проектов4 и их пользователей и ряд других служб, связанных с управлением сертификатами разного уровня;

• подсистема журналирования, включает все службы отслеживания статуса выполняемых заданий;

• подсистема учета использования GRID-ресурсов.

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

Для функционирования GRID-инфраструктуры необходимы были средства и стандартизованные интерфейсы для построения и взаимодействия компонентов приложений пользователей с сервисами и службами GRID-инфраструктуры. Естественно было воспользоваться наработками в реализации концепции SOA с помощью технологии веб-сервисов и опыта реализации HLA стандарта. С этой целью были разработан эталонный набор спецификаций для построения и взаимодействия веб-сервисов — WebService Reference Framework (WSFR)5, который позволял компонентам приложения пользователя взаимодействовать со службами GRID-инфраструктуры, чтобы получать доступ, контролировать и изменять состояние доступных им ресурсов. Понятие ресурса трактовалось широко — это мог быть физический ресурс, коллекция данных, сервис или служба.

Набор WSRF включал следующие спецификации:

• WS-Resource Lifetime — способ управления жизненным циклом ресурса, включая удаление ресурса;

3 Здесь, следуя [55], будем использовать вместо термина "сервис", термин "служба".

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

5 Справедливости ради, надо заметить, что WSER так и не стал стандартом и не получил широкого распространения. В то же время концепция GRID предписывала использовать "стандартные, открытые протоколы и интерфейсы общего назначения".

• WS-Resource Properties — способ запроса состояния и модификации ресурсов;

• WS-Service Groups — способ представления и управления группами веб-сервисов и/или WTS-ресурсов;

• WTS-BaseFaults — средства информирования о сбоях или ошибках в работе веб-сервисов;

• WTS-BaseNotifications — спецификация интерфейсов производителя (NotificationProducers) и потребителя (NotificationConsumers) асинхронных сообщений, а также основные функции, выполняемые при рассылке сообщений и подписке на них, процессов приостановки/возобновления подписок и контроля срока подписки;

• WTS-BrokeredNotificatiions — средства, позволяющие объекту, который не является веб-сервисом, создавать асинхронные сообщения и рассылать их через особую посредническую службу (NotificationBroker);

• WTS-Topics — организация и категоризация тем для подписки.

Хорошее введение в "идеологию" WSRF можно найти в статьях [69].

К 2020 г. было предпринято много проектов создания GRID-инфраструктуры. Одной из первых была Information Power GRID (IPG), инициированная NASA [70] для интеграции своих суперкомпьютерных центров в интегрированную вычислительную среду. Другие примеры включают GRID-инфраструктуры для поддержки исследований в области физики высоких энергий и ядерной физики, исследований климата (например, Earth System GRID [71]), исследований землетрясений [72] и гравитационно-волновой астрономии [73]. Распределенный голландский суперкомпьютер ASCI [74] и французская система GRID5000 [75], Future GRID [76] в США, которые позволили провести широкий спектр инновационных исследований.

Однако, по мнению авторов концепции GRID, ни одна из многочисленных попыток реализовать полностью концепцию GRID до сих пор не увенчалась успехом [11, 77]. Ни одна из перечисленных в этой работе инфраструктур не удовлетворила всем требованиям, сформулированным авторами этой концепции, не позволила автоматически минимизировать время выполнения приложения в вычислительной инфраструктуре с учетом его временных ограничений за счет эффективного автоматического управления распределением вычислительной нагрузки между доступными вычислителями, "нетривиального качества обслуживания", эффективного управления передачей данных между компонентами приложения, ресурсами хранения данных возможности неограниченного наращивания вычислительных ресурсов по требованию [11].

3. Кто виноват? Большая часть ранних проектов по реализации GRID была сосредоточена на практическом выявлении возможностей и реализуемости нового класса инфраструктуры. Приведенная выше оценка ее реализуемости авторами концепции заставляет задуматься, а могла ли концепция вычисления по требованию как сервис быть реализована теми средствами и с теми технологическими возможностями, которые существовали к концу 2010 г.? Определенное представление о возможностях и развитии технологий к концу 2010 г. дает рис. 6 (см. статью "Технологии, которые оказали значительное влияние на образ жизни и работы людей за период 2000-2010 гг." в журнале PC Week за январь 2011 г. из разд. 1).

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

3.1. Свойства современных приложений. Для того чтобы понять, какими свойствами должна обладать GRID-подобная вычислительная инфраструктура, рассмотрим, какие требования к ней предъявляют современные приложения. В [78] представлен анализ широкого спектра приложений из различных прикладных областей, таких, как умный город, умный дом, здравоохранение (особенно такие направления, как телемедицина, хирургия), транспорт, сельское хозяйство, научные междисциплинарные исследования. Один из результатов этого анализа — все современные приложения чувствительны к времени отклика. Расстояние между точками обработки, хранения данных и получения результатов вычислений влияет на задержку транспортировки данных. Неправильный выбор локации вычислительной установки для выполнения компонента приложения, размещения его данных может нарушить работу приложения и даже блокировать его выполнение. Это означает, что допустимое расстояние между местом обработки данных (приложением или его компонентами) и их источником должны быть согласованы.

Еще один важный вывод, который был сделан в результате этого анализа, — привязка приложений или их компонентов к определенным географическим локациям неэффективна. Неэффективность проявляется, во-первых, в том, что ограничивается мобильность как источника данных, так и потребителя результата вычислений. Во-вторых, время нахождения запроса на вычисления в вычислительной инфраструктуре, т.е. сумма времен на передачу данных к месту обработки, нахождение заявки на обработку данных в очереди, на обработку данных (собственно вычисления), на передачу промежуточных результатов между компонентами приложения, которые могут выполняться в разных локациях, и время на доставку результата, существенно зависит от размещения данных и компонентов приложения. Это говорит о том, что, во-первых, нельзя отдавать размещение данных и компонентов приложения пользователю/разработчику, а во-вторых, алгоритмы управления ресурсами определяют эффективность инфраструктуры. Вычислительная инфраструктура должна динамически в ходе работы сама выбирать, где будут размещаться данные и происходить их обработка, исходя из заданной ей стратегии управления. Например, из практики хорошо известно, что в очереди к суперкомпьютеру задача может простоять несколько дней. В то же время эта же задача могла бы быть выполнена в облачной среде близлежащего центра обработки данных. Время выполнения в облачной среде наверняка будет больше, чем время выполнения в среде суперкомпьютера, но по критерию время нахождения заявки в системе, а именно этот критерий важен для пользователя, облачная среда может оказаться эффективнее. Поэтому управлять распределением приложений в вычислительной инфраструктуре, потоками данных должна сама вычислительная инфраструктура. Эти выводы подтверждают результаты исследования [79].

Как уже было отмечено, основной движущей силой развития инфраструктуры для вычислений, ее операционной среды, языков программирования и инструментов всегда были потребности приложений. Именно потребности приложений, а не возможности аппаратных средств, инженерии программирования, базового программного обеспечения. Набор свойств современных приложений, рассмотренный в [80], включает в себя: распределенность, масштабируемость, отказоустойчивость, интероперабельность, самодостаточность, режим реального времени, эластичность, кроссплатформенность и другие. Описания этих терминов можно найти в [80].

Для понимания дальнейшего поясним термин самодостаточность как относительно новый. В [80] он описан так: "приложение уже не представляется только кодом и исходными данными, оно сопровождается описанием структуры приложения, взаимосвязи его компонентов (далее сервисов приложений), указанием требуемого уровня их производительности/времени реакции, явно сформулированными требованиями к вычислительным и сетевым ресурсам, ресурсам хранения данных и доступа к ним, предполагаемым временным ограничениям на время вычислений и передачу данных в виде соглашения об уровне обслуживания (Application Service Level Agreement — далее ASLA), процедуры запуска приложений". Здесь уместно отметить, что WSRF очень схож по своими возможностями и предназначению с таким языком спецификаций. Отметим, что на момент создания WSRF средств программного управления сетью передачи данных еще не существовало. Сегодня для таких описаний активно развиваются специальные языки. Ярким примером прообраза такого языка может служить язык TOSCA [81] (далее такое описание будет

называться Спецификацией Функционирования Приложения (Application Operation Specification - AOS)).

3.2. Требования к вычислительной инфраструктуре. Приложение со свойствами, сформулированными выше, предъявляет следующие требования к вычислительной инфраструктуре [80]: детерминированность поведения, безопасность, доступность, надежность и отказоустойчивость, эффективность и справедливость при распределении ресурсов, повсеместная виртуализация всех видов ресурсов, масштабируемость, бессерверность. Детерминированность поведения — это возможность заранее прогнозировать количественные параметры функционирования, такие, как время исполнения, задержка на передачу данных, вероятность потери данных, доступность ресурсов. Бессерверная технология в [80] согласно [82] трактовалась следующим образом: инфраструктура должна автоматически размещать компоненты приложения таким образом, чтобы они могли взаимодействовать в соответствии с требованиями SLA приложения и так, чтобы гарантировать экономное использование ресурсов инфраструктуры. Чтобы вычислительная инфраструктура могла соответствовать требованиям эффективности и детерминированности и служить вычислительной инфраструктурой для приложений в вышесказанном смысле, ее функционирование должно соответствовать таким требованиям, как:

• предсказуемость и масштабирование времени выполнения компонентов приложения и времени их взаимодействия (передачи данных) согласно AOS;

• наличие методов оценки времени выполнения компонентов приложения, инвариантных к архитектуре вычислителей, входящих в состав сетевой вычислительной инфраструктуры;

• детерминированность характеристик передачи данных между компонентами приложения по наложенным (оверлейным) каналам (далее Quality of Service — QoS канала);

• надежная изоляция контура управления и контура передачи данных (далее просто контура данных) в сети передачи данных (СПД) вычислительной инфраструктуры от ошибок в сетевом оборудовании, а также изоляции потоков данных от вредоносных воздействий в этих контурах [80].

Для обеспечения детерминированности параметров передачи данных между компонентами приложения необходимо:

• устанавливать и гарантировать диапазоны изменения сквозной задержки и джиттера в СПД;

• гарантировать вероятность потери пакетов в СПД на уровне, соответствующем SLА-требованиям приложения;

• сделать оперативно управляемым использование доступной пропускной способности каналов СПД;

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

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

3.3. Что изменилось за последние 15 лет? Компьютерный мир существенно изменился с момента анонсирования "эры GRID". Произошедшие изменения были не просто больше, быстрее и лучше. Технология производства СБИС с 28 нм достигла уровня в 2 нм в 2024 г. Фирма Intel заявила план развития своих технологий, согласно которому к 2035 г. размер транзистора на кристалле сократится до 0.2 нм. Это позволит разметить на кристалле 400 мм2 не менее 3 трлн транзисторов, что превысит число нейронов в человеческом мозге. Они принесли новое качество. За период с 2014 по 2024 гг. производительность серверов возросла примерно в 7 раз [83], производительность супервычислителей выросла на 4 порядка [84], а пропускная способность каналов передачи данных за этот же период возросла с нескольких Гб/с до сотни Тб/с [85] (см. рис. 9). В 2023 I'. был поставлен рекорд скорости передачи данных по стандартному оптоволокну 1,7 млн Гб/с на расстояние 13 км [86]. При этом кабель с новой начинкой сохранил стандартные физические размеры. Это позволит использовать существующую кабельную инфраструктуру, что облегчит модернизацию существующих сетей.

Рис. 9. Динамика роста пропускной способности сотовых коммутаторов с прогнозом на 4 года впород

Рис. 10. Динамика роста скорости шины PCI

На рис. 9, 10 видно, что сегодня скорости передачи данных в сети практически сравнялись со скоростью операций ввода/вывода в компьютере. Здесь уместно вспомнить, что Д. Гилдер

в 2000 г. отметил [87, 88]: "Когда сеть заработает так же быстро, как внутренние каналы компьютера, компьютер распадается в сети на набор устройств специального назначения". Именно этот распад происходит сегодня, когда вычислительный узел в сети распадается на процессор общего назначения, графический процессор, нейроморфный процессор и множество сопроцессоров на основе программируемой логической интегральной схемы (ПЛИС), объединенных коммутатором с высокой пропускной способностью [89]. Такая организация вычислителя позволяет гибко подстраивать архитектуру вычислителя под особенности алгоритма приложения [90, 91].

За последние 15 лет произошли существенные изменения и в области разработки программного обеспечения: концепция SOA сильно эволюционировала. Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие проблемы, простые в решении. Сегодня SOA представляет концепцию микросервисной архитектуры — развитие концепции сервис-ориентированной архитектуры программного обеспечения, при котором приложение представлено в виде набора взаимодействующих небольших (насколько это возможно) и легко изменяемых модулей, — микросервисов. Например, так построена архитектура ядра сети 5G, согласно стандарту IMT 2020 [92]. Построение и настройку систем в соответствии с концепцией микро-SOA осуществляют специалисты гибкой разработки или DevOps'bi, которые обеспечивают процесс непрерывной интеграции новой функциональности, новых компонентов, разработанных разными командами программистов, зачастую не связанных друг с другом, в уже существующую информационную систему.

Создание больших, многокомпонентных приложений со сложными взаимосвязями требует больших команд разработчиков и большого распределенного репозитория кода, разбитого на специализированные домены. В то же время развитие, масштабирование и развертывание микросервисов каждого домена происходит независимо. Микросервисный подход позволяет строго разграничивать контекст (домен) каждого микросервиса и добиться требуемой степени независимости. Другим важным аспектом микросервисного подхода к разработке программного обеспечения является использование шаблонов микросервисов [93]. В каждом из шаблонов описывается задача, которую он решает, приведены рекомендации для применения шаблона, примеры кода или фрагменты кода, которые показывают, как реализовать шаблон. Примеры шаблонов микросервисов можно посмотреть в [94].

В настоящее время активно развивается подход, при котором шаблон микросервиса превращают в код с помощью Copilot [95], т.е. LLM-модели, обученной определенным языкам программирования. Уже в 2023 г. около 10% разработчиков программного обеспечения использовали этот подход [96]. Инструменты программирования нового поколения меняют возможности инженеров на каждом этапе жизненного цикла разработки программного обеспечения, от планирования и тестирования, до развертывания и обслуживания. Об этом говорится в исследовании компании McKinsev, результаты которого были обнародованы 20 июля 2023 г. [97]. Аналитики компаний McKensv и IDC прогнозируют, что к 2027 г. функции разработчика программного обеспечения существенно изменятся под влиянием технологии искусственного интеллекта. Аналитики отмечают, что резкий рост востребованности сервисов, предоставляемых по модели "как услуга", а также конвергенция современных платформ разработки приводят к формированию "гибридных" должностей. Аналитическое агенство IDC выделяет ряд ключевых направлений специализации в области ИТ-разработки. Это, в частности, DevOps — построение и настройка систем в соответствии с микро-SOA, DataOps — управление корпоративными данными и их аналитика в эпоху ИИ. Кроме того, DevSecOps, специализация которых близка к практике DevOps, но с акцентом на технологии информационной безопасности.

Важной вехой в развитии сетей передачи данных за последние 15 лет стало появление двух новых технологий: Программно-Конфигурируемых Сетей6 (ПКС) и Виртуализации Сетевых Функций7 (СФВ) , которые кардинально изменили то, как можно проектировать и управлять сетью передачи данных. Технология СФВ позволяет программно создавать многие сервисы, которые работают на виртуальном вычислителе (виртуальной машине). Такая возможность позво-

6Программно-Конфигурируемая Сеть — Software Defined Network (SDN).

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

Технология ПКС предложила новый подход к построению и управлению сетью. У этой технологии есть два принципиальных свойства, которые ее отличают от всех других. Во-первых, ПКС отделяет контур управления, который решает, как обрабатывать трафик (потоки данных), от контура данных, который направляет трафик в соответствии с политикой, определяющей контур управления. Во-вторых, ПКС консолидирует контур управления так, что единая программная платформа (контроллер) управляет сразу всеми устройствами в контуре данных, например, маршрутизаторами, коммутаторами, с помощью явно определенного интерфейса для прикладного программирования (API). На сегодня таких интерфейсов несколько, например, открытые протоколы, такие как OpenFlow, РСЕР, OVSDB или NETCONF [98].

Попытки отделить в сети передачи данных контур управления от контура данных были инициированы практическими потребностями. Однако, они шли в разрез с принципами построения Интернета, где изначально была заложена тесная связь процессов вычисления маршрута и передачи данных. Многие результаты этих попыток [99—102], нашли свое воплощение в концепции ПКС. Особое место в истории развития сетевых технологий занимает проблема виртуализации сети. Необходимо подчеркнуть, что точное определение термина "виртуализация сети" отсутствует. Здесь под этим термином мы будем понимать любую технологию, которая облегчает динамическое, оперативное отображение/размещение ресурсов виртуальной сети на/в физической сетевой инфраструктуре.

Хотя виртуализация сети приобрела известность благодаря возникновению ПКС, сама концепция виртуализации возникла до появления ПКС и фактически развивалась параллельно с концепцией программно-управляемых сетей. Эти две концепции на самом деле тесно связаны. Программно-управляемые сети часто предполагают механизмы для совместного использования физической инфраструктуры (несколько тенантов — взаимосвязанных виртуальных машин, в одном и том же центре обработке данных (ЦОД), эксперименты разных проектов в кампусе одного и того же университета) и поддержка отображения топологии логической (виртуальной) сети, которая отличается от топологии физической сети, на физическую сеть. Программируемое отображение сетевых ресурсов логической сети на инфраструктуру физической сети, изоляция логических ресурсов одной логической сети от влияния логических ресурсов другой логической сети, размещаемых на ресурсах одной и той же физической сети, являются центральными принципами виртуализации сети.

Виртуальная сеть не требует техники ПКС явно. Аналогично, отделение логически централизованного контура управления от контура данных не подразумевает виртуализацию сети. Однако есть несколько конкретных случаев, где симбиоз между виртуализацией сети и технологии ПКС оказывается крайне эффективным. Например, облачные вычисления. Этот вид вычислений стал одним из первых драйверов для виртуализации сети. Провайдеры услуг в ЦОД постоянно стремились повысить коэффициент загрузки оборудования ЦОД, снизить его фрагментацию. Для этого им нужна была техника, которая в рамках одной и той же локальной сети ЦОД позволяла бы нескольким клиентам (тенантам) совместно использовать одну и ту же физическую сетевую инфраструктуру. Компании Nicira в платформе NVP [ЮЗ] впервые предложила такую возможность для виртуализации сети, не требуя какой-либо поддержки со стороны аппаратных средств сетевых устройств. Это решение было основано на использовании техники наложенной (overlay) сети, где все виртуальные машины каждого тенанта подключались к абстрактному виртуальному коммутатору. В отличие от традиционных подходов к организации наложенных сетей, в этом решении каждый узел наложенной сети являлся расширением физической сети с помощью виртуального программного коммутатора (например, OpenVSwitch [104]), который инкапсулировал трафик, предназначенный для виртуальных машин, работающих на других серверах. Логически

7 Виртуализация Сетевых Функций — Network Function Virtualization (NFV).

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

ПКС-подход получил заметное признание. Появилось много разных контроллеров [105-110]. Программистами для них было создано много разных приложений таких, как динамическое управление доступом [111, 112], балансировка трафика [113, 114], виртуализация сети [115, 116], повышение энергоэффективности сети [117], миграция виртуальных машин и мобильность [118]. Первые коммерческие успехи, такие, как глобальное управление трафиком в Google [119] и платформа виртуализации сети от Nicira [ЮЗ], привлекли внимание промышленности. Многие из крупнейших в мире компаний в сфере информационных технологий (например, поставщики облачных сервисов, телеком-операторы, поставщики оборудования) присоединились к индустрии ПКС в лице таких консорциумов, как Open Networking Foundation [120] и инициатива "Open Daylight" [121].

Особенную популярность ПКС-технология получила в варианте SD-WAN. Еще до появления ПКС для соединения, например, разных локаций одной и той же компании, активно использовались техника туннелирования. Идея состояла в том, что между двумя точками в сети создавалось логическое соединение (туннель). Пакет с данными отправителя инкапсулировался, например, в IP-пакет (при этом могло происходить шифрование содержимого), который направляли по наложенному каналу (туннелю) в точку назначения. Для реализации этого подхода на выходе локальной сети каждой локации должен был стоять шлюз, который и осуществлял прокладку туннеля и инкапсуляцию отправляемых протокольных единиц с данными. Как правило, у шлюза было несколько наложенных каналов, которые могли вести к одному и тому же получателю, но с разными показателями качества. Туннелирование было известно до ПКС. Принципиальной новизной стало программное управление шлюзами, которые в случае SD-WAN находились под программным управлением контроллера сети. Таким образом, контроллер управлял выбором наложенного канала, по которому шлюзу надлежало передавать очередной инкапсулированный пакет. Выбор мог осуществляться, например, на основе качества канала, требований приложения и т.д.

Важным шагом в развитии техники виртуализации стала технология сетевой виртуализиро-ванной функции (СВФ) [122, 123], предлагающая использовать виртуализацию для программно реализованных функций обработки сетевого трафика. СВФ могут быть связаны произвольной топологией связей, в таком случае говорят о сетевом виртуализированном сервисе, что является в определенном смысле аналогом GRID-службы (см. п. 2).

Техника виртуализации вычислителя для работы приложений, например, веб-сервисов, баз данных и любой другой функциональности, нацеленной на обработку запросов пользователей, была известна и применялась до появления технологии СВФ. Будем разделять виртуализацию прикладных функций/сервисов (ПВФ/ПВС) и виртуализацию сетевых функций/сервисов (СВФ/СВС). Примерами сетевых функций могут служить NAT, Firewall. Примерами сетевых сервисов могут быть IP-телефония, видеоконференцсвязь, ЕРС-ядро сети сотовой связи, система билинга, DPI (Deep Package Inspection), трафик инжиниринг, мониторинг и т.п.

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

• в объекте обработки. Сетевая функция работает с сетевым трафиком и может располагаться на любом уровне стека протоколов. Прикладная функция обрабатывает запросы пользователей, широкий спектр данных, а не только сетевой трафик, и располагается на прикладном уровне стека протоколов;

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

Потеря доступа в большинстве случаев сведется к кратковременному снижению качества сервиса, например, дрожанию, искажению изображения. Для СВС непрерывность доступа критична. Например, для телеком-операторов недоступность сервиса обработки экстренных вызовов, например, в службу спасения, недопустима. Если абонент звонит в службу спасения с сообщением о пожаре в своей квартире, то нельзя сбросить его звонок в надежде, что он перезвонит.

Появление технологии СФВ стало возможным благодаря росту вычислительной мощности, объему памяти традиционных серверов и повышению качества каналов передачи данных. Концепция виртуализации сетевых функций зародилась в сфере телекоммуникации и была стандартизована в 2012 г. Европейским институтом телекоммуникационных стандартов (ETSI).

Другим важным фактором, способствовавшим появлению концепции виртуальных сервисов, стало развитие организации вычислений инфраструктуры на основе ЦОД; ЦОД стал узлом в сети передачи данных. Результатом развития техники виртуализации вычислений стало появление таких проектов, как Open Stack [124] — комплекс проектов свободного программного обеспечения, которые предназначены для создания виртуальной инфраструктуры (в виде виртуальных машин) для облачных сервисов и облачных хранилищ. Необходимо отметить также появление библиотеки Data Plane Development Kit (DPDK) — библиотеки драйверов для контроллеров сетевого интерфейса, предназначенных для быстрой обработки пакетов. Библиотека DPDK позволила обходить стек протоколов операционной системы и существенно ускорять доступ виртуальной машины к сетевому интерфейсу сервера. Этот проект был инициирован компанией Intel в конце первой декады 00-х, а в 2014 г. эта компания объявила этот проект как Open Source [125].

Следует отметить, что ЦОД может быть как в контуре управления сетью, так и в ее контуре данных сети. И там, и там ЦОД можно рассматривать как своего рода сетевое устройство, которое можно программировать с помощью техники СФВ, а ПКС позволяет нам проводить определенные потоки данных через те СВФ, размещенные в ЦОД, через которые необходимо. Так возникает мощная синергия между этим двумя важными концепциями современного подхода к архитектуре сетей передачи данных.

Важной вехой в развитии облачной инфраструктуры стало появление в 2013-2014 гг. платформ Docker и Kubernetes [126] и стандарта MANO от ETSI на платформу для управления жизненным циклом СВФ [127]. Docker — это открытая платформа, позволяющая создавать, тестировать и развертывать приложения в среде легких, портативных, самодостаточных контейнеров. Она "упаковывает" программное обеспечение в стандартизованные объекты, называемые контейнерами, которые включают все необходимое для работы приложения: библиотеки, системные инструменты, код. Контейнер может быть запущен в любой операционной среде, где есть платформа Docker. Kubernetes — это платформа для согласованного управления (оркестровки) контейнерами, которая позволяет масштабировать системы из контейнеров, управлять, координировать и планировать их работу.

Kubernetes и Docker — это контейнерные технологии. Они обеспечивают поддержку разработки приложений в соответствии с концепцией микросервисной архитектуры. Каждый микросервис выполняет одну функцию и взаимодействует с другими микросервисами через четко определенный, открытый интерфейс, с помощью сообщений. Контейнеризация предоставляет разработчикам программного обеспечения (прежде всего DevOps'aM) программный инструмент для упаковки и запуска микросервисов на разных платформах. Концептуально MANO-платформа состоит из трех уровней: оркестрация СВФ, управление СВФ и управления виртуализированной инфраструктурой. Менеджер виртуализированной инфраструктуры VIM — это система администрирования (management) виртуализированной инфраструктуры. Этот уровень отвечает за управление жизненным циклом виртуальных ресурсов, включая мониторинг работоспособности виртуального ресурса и его производительность. Примером VIM может служить OpenStack.

Менеджер СВФ создает, масштабирует, поддерживает работоспособность и удаляет экземпляры СВФ, восстанавливает их работоспособность в случае сбоя, предоставляет оркестратору детальную информацию о шаблоне экземпляра СВФ (например, описание на специализированном

языке) виртуального сервиса. Тот, в свою очередь, перенаправляет данные в систему управления инфраструктурой (например, OpenStack).

Основные функции оркестратора это:

• выделение и оркестрация виртуальных ресурсов;

• контроль топологии сети и инвентаризация ее ресурсов;

• конфигурация и активация сетевого сервиса на основе его спецификации на специальном языке;

• интерфейс взаимодействия с внешними приложениями.

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

Следует так же отметить быстрый рост численности ЦОД во всем мире. Так, например, по данным аналитического агентства Statista, число ЦОД в США за последние 5 лет увеличилось почти на 40% и достигло 5381 ЦОД. Ближайшая к США страна по числу ЦОД — Германия с 521 ЦОД, Россия с 297 ЦОД на 9 месте. Здесь важно отметить активную деятельность по разработке методов и средств по созданию сетей ЦОД. Проблем, не решенных на сегодня, здесь много. Для примера, заметим, что задержки на коммуникацию внутри ЦОД измеряются микросекундами, а между ЦОД — миллисекундами. Разница в три порядка приводит к тому, что, например, потеря доли процентов пакетов при коммуникации между ЦОД приводит к катастрофическому падению скорости взаимодействия между компонентами приложения.

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

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

Классические методы оптимизации [128] для этого не подходят, так как предполагают централизованное принятие решения, когда проводится централизованно комбинаторный поиск вариантов решения по четко определенному (детерминированному) алгоритму, позволяющему найти наилучшее решение проблемы. Такой подход кроме вычислительной сложности требует больших накладных расходов на сбор, обработку и передачу данных между компонентами вычислительной инфраструктуры.

В этих условиях предпочтительнее становятся методы распределенной, мультиагентной оптимизации (МАО). В мультиагентных методах решение задачи получается в ходе самоорганизации распределенного множества алгоритмов-агентов, способных к конкуренции и/или к кооперации, и имеющих собственные критерии, предпочтения и ограничения. Решение считается найденным, когда в ходе недетерминированных взаимодействий агенты достигают неулучшаемого консенсуса (временного равновесия или баланса интересов), который и принимается за решение задачи.

Развитие методов МАО существенно стимулировали достижения за указанный период времени в области математических методов распределенной оптимизации, позволяющие сократить число обменов и объем передаваемых данных при распределенной оптимизации в отдельных случаях до 240 раз, а в среднем до 4-5 раз [129, 130].

Идея тензорного поезда [131] в случае d-мерных массивов, данные в которых обладают определенной степенью зависимости, позволила снизить требования к объему памяти для их хранения с экспоненциальных, т.е. O(Nd) ячеек памяти, до почти линейных, т.е. O(d * N * r2), где r — максимальный из рангов тензорного поезда. При этом вычислительная сложность построения функционально-порожденных тензоров тензорного поезда всего лишь за O(d * N * r3) вычислений их элементов. Идеи тензорных разложений нашли ряд применений в задачах, связанных с оценкой ожидаемого времени выполнения программ [80], со сжатием нейросетевых моделей, где позволили сократить требования к памяти в десятки раз без существенных потерь в качестве их работы [132, 133]. В настоящее время за рубежом появляется интерес к пробным реализациям данных алгоритмов на специализированных СБИС [134], призванных решать задачи искусственного интеллекта.

Итак, прогресс в области математических методов, разработки программного обеспечения в концепции SOA, рост производительности вычислителей, скорости ввода/вывода и передачи данных в сетях существенно приближают нас к реализации концепции GRID. Однако архитектура вычислительной инфраструктуры, удовлетворяющей требованиям, перечисленным в п. 3.2, будет существенно отличаться от того, что предложили авторы Я. Фостер и К. Кессельман в 1999 г. (см. рис. 7).

Вычислительную инфраструктуру, удовлетворяющую требованиям, перечисленным в п. 3.2, мы будем называть сетевой вычислительной инфраструктурой (Network Powered by Computing, далее NPC). Ниже мы кратко рассмотрим основные положения архитектуры новой вычислительной инфраструктуры NPC и методы управления ею. После чего, в качестве примера применения математических методов мультиагентной оптимизации и распределенного машинного обучения для управления потоками данных, потоками приложений, прогнозирования времени исполнения приложения в конкретной вычислительной инфраструктуре с архитектурой NPC.

4. Что делать или вычислительная инфраструктура нового поколения. В этом разделе будет представлено краткое описание архитектуры вычислительной инфраструктуры, которая отвечает всем требованиям современных приложений, сформулированных в п. 3.2, и позволяет реализовать инфраструктуру, соответствующую определению концепции GRID, в том виде, как ее дали ее авторы (см. п. 2). Эту архитектуру вычислительной инфраструктуры будем называть Network Powered by Computing, или сокращенно NPC.

Функциональная архитектура NPC (рис. 11) была представлена в [80]. Основу построения NPC составляют технологии программно-конфигурируемых сетей (SDN) и виртуализации сетевых функций (NFV) [98]. Ее организация основана на федеративном принципе [11]. Федерат — это юридическое лицо, в ведении которого находится определенное количество вычислительных, сетевых ресурсов и ресурсов хранения данных. Федераты выделяют определенное количество своих ресурсов для совместного использования.

Архитектура NPC состоит из контура ресурсов и контура управления. Контур управления состоит из контура управления приложениями и сервисами и контура управления сетью передачи данных. Контур управления приложениями и сервисами организован в виде нескольких уровней:

• представления приложения, прикладных сервисов и сетевых функций (ASNF);

• управления виртуальными ресурсами (VRM);

• мониторинга и управления ресурсами (RSMCAP);

• оркестрации, администрирования и управления приложениями и сервисами (ОАМ).

Уровень ASNF отвечает за представление приложения: его кода и данных, спецификацию требований к запуску и работе приложения (AOS), представление прикладных сервисов и вир-туализированных сетевых функций VNF, необходимых для работы приложения, спецификацию требований к сети передачи данных между компонентами приложения. Спецификация требований к сети должна включать топологию взаимодействия компонентов приложения, требования

к качеству каналов (С^оБ) передачи данных между компонентами приложения, которые должны включать такие характеристики, как доступная пропускная способность, допустимая задержка, допустимая вероятность потери пакетов, допустимый диапазон изменения джиттера. На этом уровне происходит формирование АБЬА приложения и его дескриптора.

Рис. 11. Функциональная архитектура NPC

Уровень ASNF является распределенным в следующем смысле. У каждого федерата или группы федератов есть точка доступа к среде NPC NPC-SAP (NPC Service Access Point). NPC-SAP предоставляет интерфейс пользователям для доступа к ресурсам вычислительной инфраструктуры. Через этот интерфейс происходит загрузка приложения, его данных, кода и AOS-приложения. ANSF-уровень образует совокупность программного обсечения всех NPC-SAP.

Уровень VRM отвечает за определение и провиженинг8 необходимых виртуальных ресурсов, включая расчет их параметров (число ядер процессора, их тип, объем оперативной и дисковой памяти и т.п.), формирование топологии и требований к виртуальной сети виртуальных ресурсов, точек размещения необходимых СВФ в соответствии с AOS-спецификацией и прогнозируемым временем для вычислений и передачи данных с целью удовлетворения ASLA-приложения.

Уровень RSMCAP (Resource State Monitoring, Control And Prediction) отвечает за унифицированное представление состояния разнородных ресурсов NPC и мониторинг их текущего состояния, прогноз их состояния но запросу О AM-уровня. Прогнозирование позволяет сделать поведение NPC предсказуемым. Этот уровень осуществляет по запросу ОАМ-уровня запуск и загрузку виртуальных ресурсов.

Уровень ОАМ обеспечивает планирование и размещение виртуальных ресурсов приложения в среде NPC, их согласованное взаимодействие в соответствии с AOS-приложением, собирает данные о потреблении ресурсов для каждого компонента приложения, обеспечивает управление безопасностью и администрирование NPC.

Контур ресурсов NPC состоит из вычислительных, сетевых ресурсов и ресурсов хранения данных, предоставленных федератами (см. рис. 11). Вычислительные ресурсы и ресурсы хранения данных федерата всегда располагаются за NPCR NPC программно-управляемый маршрутизатор, функции которого будут рассмотрены ниже (NPCR изображен на рис. 11 справа от HPC/DC/Edge). Вычислительные ресурсы и ресурсы хранения данных, расположенные за конкретным NPCR, будем называть его локальными ресурсами; NPCR доступно несколько наложенных каналов с разным качеством сервиса, некоторые из которых могут быть использованы для передачи данных до одной и той же точки назначения.

8От английского provisioning обеспечение.

Control Plane Services ^^^^^^^^^^

to (he

5DN controller federate

control plane

T" SDN Data Plane

to the neighboring

federate date plane

Рис. 12. Архитектура контура данных федерата

Сеть передачи данных представляет собой SD-WAN-ссть (о SD-WAN см. п. 3.3) и может состоять из нескольких подсетей доменов. Один или несколько доменов могут находиться под контролем одной подсистемы управления. Организацию контура данных иллюстрирует рис. 12.

Каждая подсистема управления сетью это ПКС-контроллер, который управляет несколькими NPCR. Приложения этого контроллера состоят из приложений блока обеспечения безопасности и менеджмента сети, блока управления наложенными каналами (туннелями), блока управления качеством наложенных каналов, блока мониторинга состояния наложенных каналов, распределенного реестра наложенных каналов.

NPCR выполняет функции сразу нескольких традиционных устройств маршрутизатора трафика в SD-WAN сети в среде NPC, VPN-шлюза для его локальных ресурсов и предоставляет следующую функциональность:

1) загрузку компонентов приложения, прикладных сервисов, данных, СВФ между вычислительными ресурсами NPC среды в соответствии с указаниями ОАМ-уровня;

2) сбор и передачу на RSMCAP уровень информацию о состоянии своих локальных ресурсов;

3) выбор наиболее подходящих) наложенного канала из числа имеющихся каналов с точки зрения соответствия требованиям ASLA;

4) балансировку загрузки ресурсов NPC-ереды;

5) прокладку наложенного канала и организует защищенное соединение с использованием криитографи чееких методов.

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

По запросу от ОАМ-уровня контура управления приложениями и сервисами ПКС-контроллер сети выполняет следующие действия:

1) проверяет возможность соединения на соответствие политики доступа в сети;

2) обеспечивает защиту соединения с помощью крипто-шлюзов точек соединения;

3) проверяет наличия нужного и активного наложенного канала в распределенном реестре наложенных каналов;

4) если такого канала не обнаружено, то прокладывается новый канал, информация о котором заносится в распределенный реестр, и информирует о нем надлежащий ХРСП.

Для реализации управления ресурсами так организованной вычислительной инфраструктуры нам обязательно потребуются методы для оценки времени выполнения приложения на неоднородных вычислительных ресурсах МРС-среды, выбора наложенного канала, качество которого наиболее соответствует требованиям АБЬА-приложения, управления трафиком в сети, распределения вычислительной нагрузки (приложений и их компонентов).

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

5. Методы управления N Р С - и н ф р а с т рук т у р о й. Ранее было отмечено, что быстродействие современных вычислителей, скорости передачи данных, динамика масштабирования сетевых, прикладных сервисов и компонентов приложений, чувствительность их функционирования к задержкам вычислений и передачи данных диктуют необходимость применения алгоритмов оптимального управления ресурсами, потоками данных и вычислениями с как можно меньшей временной сложностью, так как задержки на принятия решений становятся критическими для функционирования приложения.

В п. 4.3 было кратко разъяснено, почему классические методы оптимизации не подходят для целей управления ресурсами МРС-инфраструктуры. Прежде всего потому, что они предполагают централизованное принятие решений, что влечет большие накладные расходы на сбор, обработку и передачу данных между компонентами вычислительной инфраструктуры.

Альтернативой классическим методам являются методы распределенной, мультиагентной оптимизации (МАО), где решение задачи формируется в ходе конкуренции между алгоритмами-агентами, использующими машинное обучение и имеющими собственные критерии, предпочтения и ограничения. Решение считается найденным, когда в ходе недетерминированных взаимодействий агенты достигают не улучшаемого консенсуса (временного равновесия или баланса интересов), который и принимается за решение задачи. Ниже мы рассмотрим нескольких таких алгоритмов.

В работе [79] представлено решение прогнозирования времени выполнения приложения, инвариантное к архитектурным особенностям вычислителя. Задача прогнозирования рассматривалась в следующей постановке. Дана спецификация приложения/программы и ее данных, код программы и сами данные не доступны. Дан набор вычислителей. Известны времена выполнения этого приложения, но возможно с другими данными на каких-то вычислителях из числа заданных. Требуется выбрать из заданного набора вычислителей тот, на котором это приложение со специфицированным набором данных может быть выполнено быстрее всего.

Задача прогнозирования времени выполнения программы на определенном вычислителе хорошо известна и является классической. Например, время выполнения программы на конкретном вычислителе, а также время ожидания в очереди можно спрогнозировать на основе истории ее запусков на этом вычислителе [135]. Для этого могут быть использованы многие алгоритмы экстраполяции, такие, как методы из [135], регрессии [135] или более сложные алгоритмы, такие, как ансамбль деревьев принятия решений (рандомный лес) [135]. Основным недостатком такого подхода является то, что он работает для случая одного вычислителя, а суть рассматриваемой задачи в прогнозировании времени выполнения программы на определенном наборе вычислителей. Конечно, упомянутые выше алгоритмы можно использовать для оценки времени выполнения программ на нескольких вычислителях. Однако их использование предполагает доступность истории запуска каждой программы на каждом вычислителе из заданного набора. Доступность такой информации рассматриваемая задача не предполагает.

Решение, представленное в [79], позволяет получить прогноз времени выполнения, имея лишь несколько историй выполнения программы на некоторых вычислителях из заданного набора. Поэтому нет необходимости запускать каждую программу на каждом вычислителе. Основная идея предложенного подхода основана на схожести рассматриваемой проблемы с проблемой, решаемой в рекомендательных системах [135]. Рекомендательная система (РС) прогнозирует степень предпочтения пользователем объектов из некоторого набора [135]. Примерами объектов могут быть какие-то товары. Рекомендательная система восстанавливает, прогнозирует отношения между пользователями и товарами на основе разрозненных пользовательских оценок предпочтения. При этом состав пользователей и товаров может изменяться.

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

Предложенное решение основано на методе усреднения по ансамблю [136] следующих алгоритмов: гребневой регрессии [137], корреляции Пирсона [138] и факторизации матриц [139]. Эксперименты показали, что ошибка этого решения прогноза времени выполнения программы: в случае наличия в матрице не более 15% пустых ячеек — менее 15%; при 85% пустых ячеек — не более 42%. Подробно решение и методика экспериментов приведены в [80]. Эксперименты проводились на наборах данных [141, 142]. Размер матрицы был порядка 0.5 * 103 вычпслптелей и 104 вариантов прикладных программ с разными вариантами данных. Согласно [143] современный ГП такую матрицу обсчитает за 16 мс. Следует учитывать, что по мере работы система будет обучаться в том смысле, что пробелов в матрице будет все меньше и меньше.

Предложенный метод оценки ожидаемого времени выполнения программы не предполагает обязательного централизованного решения. Вычислительные ресурсы \Р( '-среды могут быть разбиты на компоненты связности. Как уже было отмечено в п. 4, на уровне АБМР формируется дескриптор приложения, который рассылается по всем доменам. В каждом домене описанным выше способом оценивается ожидаемое время выполнения, на основании которого домены могут быть рейтингованы по предпочтительности. Такой подход позволит ускорить получение оценки ожидаемого времени выполнения. Коэффициент ускорения будет пропорционален числу доменов.

Теперь рассмотрим задачу распределения поступающих приложений по вычислительным ресурсам МРС в следующей постановке.

Обозначим функцию ЕТ : (АБ и УНЕ) х N ^ Я, где АБ — множество приложений в форме цепочек прикладных сервисов, УНЕ — множество виртуальных сетевых сервисов, Я — множество

ЕТ

АБ и УНЕ на определенном ощ € СН гДе СН — множество вычислительных ресурсов МРС. Эту функцию можно представить в виде матрицы, где столбцы соответствуют элементам из АБ и УНЕ, а строки — элементам из СН, элементы матрицы — время выполнения + время передачи данных на следующий по выбранному каналу. В этих терминах задачу оптимального распределения БЕC = AБ и УNЕ па вычислительные ресурсы МРС можно сформулировать следующим образом:

построить отображение Е : Ш ^ Г гДе Ш = {тк = (вк1,..., € АБ и УНЕ,

Г = (У, А) : У = СН — множество вычислительных ресурсов МРС, А = {(vi,vj)|vi,vj € У} — множество каналов наложенной сети, так, чтобы

\ОМ | _ — _ —

Е = ш1п £ + в— + 7((О% - °)2 + (—% - Д)2)Ь

О% О1

%

где:

а, в, 7 — константы;

с», Н» — объем занятых на сщ вычислительных ресурсов и ресурсов хранения; с», Н» — усредненный по времени объем вычислительных ресурсов и ресурсов хранения на сщ, использованных за период времени наблюдения;

О, А — усредненный по сщ объем вычислительных ресурсов и ресурсов хранения, использованных за период времени наблюдения.

Значения а, в, 7 являются коэффициентами настройки управления распределением Шк = = (вк1,..., вы) компонентов приложения. Требуется найти распределение составляющих Шк € Ш таким образом, чтобы минимизировать целевую функцию Е (1), т.е. в таблицу, представляющую функцию ЕТ, необходимо добавить идентификаторы компонентов вк» приложения в те позиции, которые соответствуют надлежащим ресурсам; Е из (1) дает нам набор {сщ }т, из которого необходимо выбрать только те элеметны, которые соединены каналами, образующими путь в Г, представляющим МРС, соответствующий АБЬА (т).

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

Ш. Пусть длина любого Шк € Ш не превосходит N где N = |СЖ| и |шк| = к ^ N. Тогда

к+1

количество узлов для выполнения компонентов из Шк равно ^ Ск = 2к. Количество возможных

»=0 к+1

размещений этих 2к подстрок над ^^С можно оценить как ^ С^С». Для случая, когда длины

»=0

Шк € Ш равномерно распределены на [1, Ж], это выражение можно оценить следующим образом:

Уже при N = 100 получаем оценку этого выражения 2150 > 10100 (гугол) размещений.

Эту оценку еще необходимо умножить на | WЕсли вспомнить, что мы рассматриваем самый простой случай, когда приложение представляет собой цепочку прикладных сервисов, то должно быть понятно, что пространство возможных вариантов в случае, когда топология приложения — ориентированный граф, то оценку уравнения (2) нужно будет умножить на количество путей в этом графе. Понятно, что методы классической математической оптимизации не удовлетворят временным ограничениям для решения задач. Естественно рассматривать решение в области мультиагентной оптимизации.

В [144] представлено исследование сформулированной выше задачи для случая крупномасштабных сетей, где сложно поддерживать и управлять всей сетью из одного узла, т.е. когда централизованный подход не приемлем. Например, в силу больших расстояний между вычислительными узлами. Там описано решение на основе мультиагентной оптимизации в комбинации с машинным обучением с подкреплением. Предложенный метод основан на следующих идеях:

• Г = (V, Л), где V = CN — множество вычислительных ресурсов NPC, A = {(vi,vj)|vi,vj € € V} — множество каналов наложенной сети, разбивают на домены связности;

• в каждом домене выбирают так называемый designated NPCR;

• designated NPCR всегда знает состояние вычислительных ресурсов и ресурсов хранения каждого вычислительного узла в своем домене;

• при поступлении очередного приложения, его дескриптор рассылается всем designated NPCR;

• если в домене есть вычислительный узел или узлы, которые могут выполнить приложение, удовлетворив требованиям ASLA, то designated NPCR этого домена рассылает всем остальным designated NPCR'aM сообщение готовности и ожидаемую оценку времени выполнения;

(2)

• если designated NPCR получает сообщение готовности от другого designated NPCR (назовем его победителем), но с лучшей оценкой времени выполнения, он начинает рассылать сообщение победителя;

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

При количестве узлов в несколько сотен процесс выбора победителя сойдется за небольшое число итераций (по опыту за 5-6). Заметим, размер домена — это еще один из параметров управления. Увеличивая число доменов, мы увеличиваем параллелизм процедуры выбора победителя, тем самым ускоряя процесс выбора, но увеличиваем количество обменов в процедуре выбора. В [144] показано, что предложенное мультиагентное решение с обучением с подкреплением превосходит эвристический алгоритм и дает результаты, близкие к эталонным.

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

К задачам управления трафиком относятся задачи маршрутизации, управления перегрузками, обеспечения определенного уровня качества обслуживания, балансировки и многие другие. Здесь мы рассмотрим один из этих многочисленных классов — балансировку трафика. Цель балансировки — обеспечить распределение нагрузки на сетевые устройства в соответствии с определенной целевой функцией. Примером целевой функции может быть равномерность загрузки сетевых устройств, каналов, доступных сетевому устройству и т.п.

Задачу балансировки можно рассматривать в разных постановках. Например, балансировка потоков, попакетная балансировка с разными целевыми функциями, т.е. критериями оптимизации. Здесь мы рассмотрим задачу балансировки в случае балансировки потоков с целью равномерной загрузки каналов NPCR. Целевая функция Ф будет выглядеть так: Ф = щ (—

1 1 (u,v)eE °u'v

где |E| — число наложенных каналов, а ^ = щ bu,v,cu,v — текущая загрузка

1 1 (u,v)eE u,v

канала и его номинальная пропускная способность соответственно.

Как уже было отмечено, масштабы и скорость передачи данных в современных сетях не позволяют получить оптимальное по скорости и точности балансировки трафика решение классическими математическими методами. Последние статьи [145, 147] по методам балансировки нагрузки показали, что основное внимание сейчас уделяется методам машинного обучения, особенно многоагентному обучению с подкреплением (MARL).

В [148] предложен новый метод Multi-Agent Routing using Hashing (MAROH). Метод MAROH основан на объединении идей децентрализованного мультиагентного обучения с подкреплением и алгоритмов консистентного хеширования. Эта комбинация позволила обеспечить справедливое распределение трафика между сетевыми ресурсами и эффективное их использование. Предложенный метод в каждый момент времени каждому выходному порту NPCR присваивает определенный вес, который потом используется консистентной хэш-функцией для распределения потоков данных между наложенными каналами. Таким образом, ключевой проблемой является то, как присвоить веса выходным портам NPCR и как построить надлежащую хеш-функцию.

MAROH-агенты располагаются на NPCR. Общая схема работы агента представлена на рис. 13. В MAROH используется метод, называемый нейронной сетью передачи сообщений (Message Passing Neural Network — MPNN). Этот метод предназначен для построения оптимальной передачи сообщений между агентами в сети, представленной неориентированным графом. Для TCP/IP-сетп эти сообщения — сообщения протокола внутридоменной маршрутизации IGP (например, OSPF) с обновлениями состояний сети, а для MAROH-агента — сообщения о состоянии агента.

Метод MPNN использует итеративный алгоритм передачи сообщений между вершинами NPC-графа, где располагаются агенты. Передаваемые сообщения это текущие состояния агентов, которые называются в MPPN скрытым состоянием (hidden state). В нашем случае скрытое состояние (обозначено на рис. 13 как hj, где j — номер агента, k — номер итерации) представлено тройкой, занятой полосой пропускания канала bij, пропускной способностью канала ci,j и текущими весами Ti,j.

Агенты инициализируют свое скрытое состояние

W

\

-Afc-fcg-J^

А2 :fc°

AI: Л? I /A3:

\ А7: h" А5:Ло

h°

I A8:"s 0

Агенты обрабатывают полученные сообщения и обновляют свое состояние

Л с,

итерации

к+1

Агенты отправляют свое состояние своим соседям

23 ^

га:

\„ ь

-шб-"m4"

.Ж.

mSN

Л

тЗ

Ч * ,..9 _

/

Агенты выбирают действие на основе последнего скрытого состояния и среда обновляет веса выходных портов

б

а

в

г

Рис. 13. Схема работы МАТЮН

Скрытое состояние может быть инициализировано случайно выбранными значениями, либо рассчитанными заранее на основе уже собранной статистики (рис. 13, а). Затем агенты отправляют свое скрытое состояние всем своим соседям в графе наложенной сети (рис. 13, б). На основе полученных сообщений от соседей и своего собственного скрытого состояния каждый \РСР обновляет свое скрытое состояние при помощи нейронной сети (рис. 13, в). Процесс отправки сообщений соседям и обновления скрытого состояния повторяется заранее заданное количество раз. Это обеспечивает распространение состояния агента в заранее определенной его окрестности. Размер этой окрестности определяет количество итераций отправки сообщений соседям и обновления скрытого состояния.

После завершения процесса обновления состояния специальная нейронная сеть на агенте рассчитывает ценность каждого возможного действия агента (рис. 13, г). Под действиями агента будем понимать операции по изменению веса канала: сложение с константой, умножение на константу или отсутствие изменения веса. Агент выбирает действие согласно выданной оценке. В результате изменяется вес наложенного канала, а после работы хеш-функции и распределение потоков данных в сети.

Были проведены эксперименты для сравнительного анализа эффективности метода \1 АР() I I с распространенными методами балансировки ЕСМР [149] и иСМР [150]. Также было проведено сравнение предложенного метода с мультиагентным методом, но с централизацией принятия решения. Такой вариант мультиагентного подхода обеспечивает оптимальное распределение трафика, так как он обладает информацией о состоянии всей сети. В результате сравнительного анализа было показано, что МАКОН эффективнее ЕСМР и иСМР и дает решение, сравнимое с централизованным подходом [148].

6. Заключение. Рост вычислительной и сетевой производительности, а также кардинальные изменения организации современных приложений требуют создания новой вычислительной инфраструктуры. В статье рассмотрена эволюция вычислительной инфраструктуры. Представлен анализ ретроспективы развития ее основных компонентов: средств вычислений, телекоммуникации и технологий создания программного обеспечения. На основании результатов этого анализа показано, что даже к концу 2010 г. концепция GRID не могла быть реализована в полной мере, как ее задумывали ее авторы, по следующим причинам: переносимость приложений все еще оставалась проблемой, техника виртуализации ресурсов, их миграции находилась в зачатке, отсутствовали технологии программного управления сетями передачи данных, сеть передачи данных была не виртуализирована, средства программного управления сетью не обеспечивали нужного уровня оперативности и гибкости, оркестрация виртуальных ресурсов, т.е. обеспечение автоматического, согласованного взаимодействия, согласованного выполнения сложных операций над виртуальными ресурсами отсутствовала, алгоритмов для автоматического управления масштабируемыми в широких пределах ресурсами распределенной вычислительной инфраструктуры с приемлемой вычислительной сложностью не было.

На основании анализа свойств современных приложений представлена архитектура Network Powered by Computing вычислительной инфраструктуры, которую можно рассматривать как развитие концепции GRID. Описаны функции ее основных блоков. Результаты этого анализа также позволили сформулировать требования к вычислительной инфраструктуре со стороны приложений.

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

Использование методов машинного обучения позволяют эффективно решить разнообразные задачи от прогнозирования состояния вычислительной инфраструктуры до планирования потоков данных внутри наложенной сети. Конечно, приведенные алгоритмы не решают всех проблем, которые необходимо решить для практического выправления NPC-инфраструктуры. Например, в области оценки времени исполнения приложения необходимо развить достигнутое на широкий спектр языков программирования, библиотек, технологий разработки. Необходимо разработать методы и средства для автоматического преобразования представления приложения и его данных в соответствии с требованиями конкретной платформы, используемой конкретным федератом. В области управления трафиком отметим, что балансировать трафик можно не только по потокам, но и по пакетам, по группам пакетов (flowlet). Балансировка — важный элемент в механизме обеспечения детерминированности качества наложенных каналов. Отдельная здесь проблема — управление перегрузками. Дело в том, что приложение работает в среде, где задержка измеряется нано-, микросекундами. Соответственно настраивается алгоритм управления перегрузками транспортного агента. Однако при взаимодействии компонентов приложения, расположенных, например, в разных ЦОД, задержка будет на уровне миллисекунд. Такая разница в задержках приведет к тому, что о потере каких-то пакетов на соединении между ЦОД приложение узнает не сразу, что приведет к потере производительности и пропускной способности наложенного канала.

Управление трафиком предполагает решение еще одной важной проблемы. Как уже было сказано, NPCR может быть доступно несколько наложенных каналов с разным качеством обслуживания, некоторые из которых можно использовать для передачи данных в один и тот же пункт назначения. Например, исследование показателей качества случайно выбранных каналов в Москве на транспортном уровне показало, что на трехчасовом интервале величина задержки

колеблется от нескольких микросекунд до 11 с, уровень потерь — до 7%, пропускная способность от 58,86 КБ/с до 69131 КБ/с.

Выбор оптимального по качеству обслуживания с точки зрения соответствия ASLA — это задача многокритериальной оптимизации, так как качество наложенного канала определяют четыре характеристики: пропускная способность, задержка, вероятность потери пакета и джиттер. Как известно алгоритмы многокритериальной оптимизации вычислительно сложны. В данном случае важными факторами, которые будут влиять на решение этой проблемы, будут, например, используемый алгоритм управления перегрузкой в агенте транспортного уровня, алгоритм шифрования передаваемых данных.

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

В части распределения потока приложений между вычислительными средствами необходимо исследовать и разработать алгоритмы планирования для приложений с разнообразной топологией. Многое предстоит сделать, чтобы обеспечить детерминированность поведения такой вычислительной инфраструктуры. Здесь большое значение будут иметь методы прогнозирования характеристик качества каналов наложенной сети передачи данных. Пример одного из таких методов можно найти в [151, 152].

В этой работе практически не были затронуты вопросы информационной безопасности, за исключением распределенного реестра наложенных каналов. Один из возможных подходов к построению такого реестра можно посмотреть в [153, 156].

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

Автор считает своей приятной обязанностью отметить вклад в подготовку этой статьи Ко-ренькова В.В., Заборовского B.C., Антоненко В.А., Волканова Д.Ю., Писковского В.О., Степанова Е.П. за прочтение рукописи и сделанные замечания. Также необходимо отметить помощь в подготовке текста Труховой М.Г. и Никифорова Н.И.

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

1. Айзексон У. Инноваторы. М.: Аст, 2015.

2. Тоффлер Э. Шок будущего. М.: Аст, 2003.

3. Gilder G . Microcosm: The quantum Revolution in Economics and Technology. Touchstone book, 1990.

4. Мэйнфреймы — прошлое и настоящее. URL: https://compress.ru/article.aspx?id= 11897

5. KleinrockL. UCLA to be First Station in Nationwide Computer Network. UCLA Press Release, 1969.

6. Litzkow M.J., Livny M., Mutka M.W. Condor M.W. A hunter of idle workstations.// 8th International Conference on Distributed Computing Systems. Washington, USA: IEEE Computer Society Press, 1988. P. 104-111.

7. Zhou S., Zheng X., Wang J., Delisle P.Utopia: a load sharing facility for large, heterogeneons distributed computer systems // Software: Practice and Experience. 1993. 23. N 12. P. 1305-1336.

8. В a r a 11 о о А., К a r a u 1 M., К e d e m Z., Wу с k о f f P. Charlotte: metacomputing on the web // 9th International Conference on Parallel and Distributed Computing Systems. Tokyo, Japan: IEEE Computer Society Press, 1996.

9. Alexandrov A.D., lb el M., Schauser K.E., Scheiman C.J. SuperWeb: towards a global web-based parallel computing infrastructure // 11th International Parallel Processing Symposium. Geneva, Switzerland: Computer Science, Engineering, 1997.

10. С ami el N., London S., Nisan N., Regev O. The POPCORN project distributed 1146 computation over the internet in Java // 6th International World Wide Web Conference. Santa Clara, California USA, 1997.

11. Foster I., Kesselman С. The GRID: Blueprint for a New Computing Infrastructure. San Francisco: Morgan Kaufmann Publishers, 1999.

12. Intel 8080. URL: https://ru.wikipedia.org/wiki/Intel_8080

13. Лекция "Эволюция вычислительных сетей". URL: https://infourok.ru/lekciya-evolyuciya-vichislitelnih-setey-3384634.html

14. Сетунь (компьютер). URL: https://ru.wikipedia.org/wiki/CeTyHb_(компьютер)

15. Hennessy J.L., Patterson D.A. A new golden age for computer architecture innovations like domain-specific hardware, enhanced security, open instruction sets, and agile chip development will lead the way // Comm. of the ACM. 2019. 62. N 2. P. 48-60.

16. Moore's Law Transistor Count 1970-2020. URL: https://c0mm0ns.wikimedia.0rg/w/index.php?curid= 98219918

17. Year on Year Performance. URL: https://www.cpubenchmark.net/year-on-year.html

18. Вычисления на GPU — зачем, когда и как. URL: https://habr.com/ru/companies/dbtc/articles/498374/

19. Yjckney R.W., Jesshope C.R. Parallel Computers. Bristol: Adam Hilger, 1981.

20. Якубайтис Э. А. Архитектура вычислительных сетей. M.: "Статистика", 1980.

21. Adam J. Architects of the net of nets / / IEEE Spectrum. Sept. 1996.

22. Перегодова M.A. Эволюция вычислительных сетей: от машины Чарльза Бэбиджа до первых глобальных сетей. URL: https://infourok.ru/lekciya-evolyuciya-vichislitelnih-setey-3384634.html

23. Смелянский Р.Л. Компьютерные сети. Т. 1, 2. М.: Издательский центр "Академия", 2011.

24. История развития телекоммуникации. URL: https://www.qtech.ru/istoriya-razvitiya-telekommunikatsionnykh-tekhnologiy/

25. Сетью единой: Немного истории развития Ethernet. URL: https://habr.com/ru/companies/cloud_mts/ articles/312030/

26. 50 лет Ethernet. Почему технология по-прежнему остается сердцем Интернета. URL: https://habr. com/ги/companies / timeweb / articles/741102/

27. PCI-SIG Speeds and Feeds Graphic Final. URL: https://pcisig.com/sites/default/files/files/PCI-SIG_ Speeds%20and%20Feeds%20Graphic_Final.pdf

28. Brooks F. The mythical man-month. US: Addison-Wesley, 1975.

29. D i j k s t r a E. A Discipline of Programming Pearson. US: Prentice-Hall, 1976.

30. Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. М.: Символ-Плюс, 2010.

31. Иордан Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. М.: Лори, 2012.

32. Королев Л.П., Смелянский Р.Л. Проблемы преподавания программирования в классическом университете // Лев Николаевич Королёв: Биография, воспоминания, документы. М.: МАКС Пресс, 2016.

33. Dahl O.J., Nygaart К. An ALGOL based simulation language // Comm. of the ACM. 1966.

34. Фернандо X.K. Человек, разделивший время. Блог компании CloudMTS. URL: https://habr.com/ г и/ companies / cloud _ mts/articles/542348/

35. Jones A.K., Robert J., Chansler J. R., Durham I., Schwans K.,Ve g d a h 1 S.R. StarOS, a multiprocessor operating system for the support of task forces // Comm. of the ACM. 1979.

36. Краткая история виртуализации. URL: https://dzen.ru/a/YaODAF6UwSa_BXFf.

37. Thomas E. Service-Oriented Architecture: Concepts, Technology, and Design. N.Y.: Prentice Hall, 2005.

38. Балашов В.В., Волканов Д.Ю., Смелянский Р.Л., Чистолинов М.В. Опыт построения среды имитационного моделирования распределенных систем с применением HLA // Третья международная научно-практическая конференция "Имитационное и комплексное моделирование морской техники и морских транспортных систем". СПб: ИКМ МТМТС, 2015.

39. Antonenko V.A., Chemeritskiy E.V., Glonina А.В., Konnov I.V., Pashkov V.N., Podymov V.V., Savenkov К.О., Smeliansky R.L., Volkanov D.Yu, Zakharov V.A., Z о r i n D.A. HLA-based distributed real-time embedded systems simulation tool // Proceedings of the 2013 Winter Simulation Conference: Simulation: Making Decisions in a Complex World. IEEE Press, 2013. P. 4012-4013.

40. IEEE Standard for Modeling and Simulation (M&S) High Level Architecture(HLA): 1516-2010 (Framework and Rules); 1516.1-2010 (Federate Interface Specification); 1516.2-2010 (Object Model Template (OMT) Specification) (1) (PDF) An Introduction to Developing Federations with High Level Architecture (HLA). URL: https://www.researchgate.net/publication/319176312_An_Introduction_to_Developing_ Federations_with_High_Level_Architecture_HLA

41. Гаммер М.Д. Распределенные имитационные системы. URL: https://habr.com/ru/users/ maxgammer /

42. Пашков В.П., Волканов Д.Ю. Разработка средства анализа и визуализации трасс распределенных вычислительных систем реального времени / / Труды международной научной конференции "Моделирование". Киев, Украина: Институт проблем моделирования в энергетике им. Г.Е. Пухова, 2012.

43. Антоненко В.А., Волканов Д.Ю. Средство трансляции внутренней логики федерата HLA для построения моделей РВС РВ на языке UML // Труды международной научной конференции "Моделирование". Киев, Украина: Институт проблем моделирования в энергетике им. Г.Е. Пухова, 2012.

44. Чемерицкий Е.В., Волканов Д.Ю., Смелянский Р. Л. Среда полунатурного моделирования на основе стандарта HLA // Труды международной научной конференции "Моделирование". Киев, Украина: Институт проблем моделирования в энергетике им. Г.Е. Пухова, 2012.

45. Catlett С., Smarr L. Metacomputing // Comm. of the ACM. 1992. 35. N6. P. 44-52.

46. Messina P. Distributed supercomputing applications // TheGRID: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, 1999. P.55-73.

47. Lyster P., Bergmao L., Li P., Stanfill D., Crippe В., Blom R., Pardo C.,Okaya D. CASA Gigabit supercomputing network: CALCRUST three-dimensional real-time multi-dataset rendering // Proc. Supercomputing'92. 1992.

48. Грибов Д.И., Смелянский Р.Л. Комплексное моделирование бортового оборудования летательного аппарата // Труды Второй Всероссийской научной конференции "Методы и средства обработки информации". М.: Изд-во МГУ, 2005. С. 59-74.

49. DeFanti Т., Foster I., Papka М., Stevens R.,K u h f u s s T. Overview of the I-WAY / / The International Journal of High Performance Computing Applications and High Performance Computing. 1996. 10. N 2-3. 14 23 131.

50. Foster I., Geisler J., Nickless W., Smith W., Tuecke S. Software infrastructure for the I-WAY metacomputing experiment // Concurrency Practice & Experience. 1998. 10. N 7. P. 567-581.

51. Stevens R., Woodward P., DeFanti Т., Catlett C. From the I-WAY to the National Technology GRID // Comm. of the ACM. 1997. 40. N 11. P. 50-61.

52. Д e м и ч e в А.П., Ильин В. А., Крюков А.П. Введение в грид-технологии // Препринт НИИЯФ МГУ. 2007. № 11. С. 832.

53. Коваленко В.П., К о р я г и н Д. А. Грид: истоки, принципы и перспективы развития / / Информационные технологии и вычислительные системы. 2008. 4. С. 8-50.

54. Штромайер Э., Донгарра Д., Саймон X. Рейтинг Тор500 и прогресс высокопроизводительных вычислений // Открытые системы. СУБД. 2016. № 01.

55. Calzarossa М., Tucci S., Gagliardi F., Jones В., Reale M.,B u r k e S. European data GRID project: experiences of deploying a large scale testbed for E-science applications // Performance Evaluation of Complex Systems: Techniquesand Tools. Berlin; Heidelberg: Springer, 2002. P.255-265.

56. Avery P., Foster I. The GriPhyN Project: Towards Petascale Virtual Data GRIDS. Technical Report GriPhy. 2001. 15.

57. Жучков А.В., Ильин В.А., Кореньков В.В. Некоторые аспекты создания глобальной системы распределенных вычислений в России / / Труды Всероссийской научной конференции "Высокопроизводительные вычисления и их приложения". М.: Изд-во МГУ, 2000. С. 227-229.

58. Ilyin V., Kruglov N., Korenkov V., Kryukov A., Kolosov V., Mitsyn V., Shamardin L., Tiknonenko E. EU-DataGrid segment in Russia. Testbed WP6 // Proc. of the XXIII Int. Symposium on Nuclear Electronics & Computing. Dubna, 2001. P. 105-108.

59. Ильин В.А., Кореньков В.В. Создание инфраструктуры DATAGRID в России // Всероссийская научная конференция "Научный сервис в сети ИНТЕРНЕТ". М.: Изд-во МГУ, 2002. С. 231.

60. Ильин В.А., Кореньков В.В. Создание Российского сегмента европейской инфраструктуры EU DataGrid // Труды Всероссийской конференции "Электронные библиотеки". Дубна, 2002. С.239-248.

61. LamannaM. The LHC computing grid project at CERN / / Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and ABsociated Equipment. 2004. 534. N 1-2. P. 1-6.

62. Ilyin V., Korenkov V., Kryukov A., Ryabov Yu., Soldatov A. Russian Date intensive Grid (RDIG): current status and perspectives towards national Grid initiative // Proc. of Int. Conf. "Distributed Computing and Grid-Technologies in Science and Education. GRID-2008". Dubna, 2008. P. 100-108.

63. Jin H. China GRID: Making GRID computing a reality // Digital Libraries: International Collaboration and Cross-Fertilization/ Eds. by: Chen Z., Chen H., Miao Q., Fu Y., Fox E., Lim E. Berlin; Heidelberg: Springer, 2005. P. 13-24.

64. Varavithya V., Uthayopas P. Tbai GRID: architecture and overview // NECTEC Technical Journal. 2000. 11. N 9. P. 219-224.

65. Gentzsch W., Reinefeld A. D-Frid // Future Generation Computer Systems. 2009. 25. N 3. P. 266-350.

66. P rah lad a Rao В., Ramakrishnan S., Raja Gopalan M., Subrata C., Man gal a N., 1399 Sridbaran R. E-Infrastructures in IT: A case study on Indian national GRID computing initiative — GARUDA // Computer Science Research and Development. 2009. 23. N 3. P. 283-290.

67. Matsuoka S., Shinjo S., Aoyagi M., Sekiguchi S., Us ami H., Miura K.Japanese Computational GRID Research Project: NAREGI // Proceedings of the IEEE. 2005. 93. N 3. P. 522-533.

68. Pordes R., Petravick D., Kramer В., Olson D., Livny M., Roy A., Avery P., Blackburn K., Wenaus Т., Wiirthwein F., Foster I., Gardner R., Wilde M., В 1 a t e с 1 с у A., M с G e e J., Quick R. The open science GRID // Scientific Discovery through Advanced Computing (SciDAC) Conference. 2007.

69. Технологии грид. M.: HUM им. M. В. Келдыша, 2006.

70. Johnston W.E., Gannon D., Nitzberg В. GRIDS as production computing environments: the engineering aspects of NASA's information power GRID // 8th IEEE International Symposium on High Performance Distributed Computing. IEEE Press, 1999.

71. Bernholdt D., Bharathi S., Brown D., Chanchio K., Chen M., Chervenak A., Cinquini L., Drach В., Foster I., Fox P., Garcia J., Kesselman C., Markel R., Middleton D., Nefedova V., Pouchard L., Shoshani A., Sim A., Strand G., Williams D. The Earth system GRID: supporting the next generation of climate modeling research // Proceedings of the IEEE. 2005. 93. N 3. P. 485-495.

72. Kesselman C., Foster I., Prudhomme T. Distributed telepresence: the NEES GRID earthquake engineering collaboratory // The GRID: Blueprint for a New Computing Infrastructure. Morgan Kaufman, 2004.

73. Barish B.C., Weiss R. LIGO and the detection of gravitational waves // PhysicsToday. 1999. 52. N 10. P. 44-50.

74. Bal H.E., et al. The distributed ASCI supercomputer project // Operating Systems Review. 2000. 34. N 4.

75. Raphael В., С a p p e 11 о F., et al. GRID'5000: A Large Scale And Highly Reconfigurable Experimental GRID Testbed. URL: https://www.semanticscholar.org/paper/GRID '5000%3A-A-Large-Scale-And-Highly-Reconfigurable-Bolze-Cappello/82cb49e8c26e79blafcceb009f45dfcb283f67e9

76. Von Laszewski G., Fox G.C., Wang F., Yonnge A.J., Kulshrestha A., Pike G.G., Smith W., Voeckler J., Figueiredo R.J., Fortes J., Keahey K., D e e 1 m a n E. Design of the future GRID experiment mansgernent framework // GRID Computing Environments Workshop at SC'IO. New Orleans, LA, 2010.

77. Foster I., Kesselman C. The Histoty of GRID. URL: https: //arxiv.org/abs/2204.04312

78. S m e 1 i a n s k у R. Hierarchical edge computing // International Conference on Modern Network Technologies. MoNeTec-2018. M.: IEEE, 2018. P. 97-105.

79. S m e 1 i a n s k у R. et al. On HPC and cloud environments integration // Performance Evaluation Models for Distributed Service Networks Series Studies in Systems, Decision and Control. Springer Nature, 2021. P. 343.

80. S m e 1 i a n s k у R. Network powered by computing: Next generation of computational infrastructure // Edge Computing — Technology, Management and Integration. IntechOpen, 2023. P. 47-70.

81. Topology and Orchestration Specification for Cloud Applications. URL: http://docs.oasis-open.org/tosca/ TOSCA/vl.O/os/TOSCA-vl.O-os.html

82. What is serverless computing?//ITPro Today. URL: https://www.itprotoday.com/serverless-computing/ what- serverless- computing

83. CPU Benchmarks. Year on Year Performance. URL: https://www.cpubenchmark.net/year-on-year.html

84. Pallavi Rao Charted: The Exponential Growth in AI Computation. URL: https://www.visualcapitalist. com/ср/charted-history-exponential-growth-in-ai-computation /

85. Передача данных: фантастическая скорость и новые методы. URL: https://habr.com/ru/companies/ yota / articles /283220/

86. URL: https://3dnews.ru/1088365/ustanovlen-rekord-skorosti-peredachi-dannih-po-standartnomu-optovoloknu-17-pbits

87. Margalit N., Xiang C.S., Bowersss A., Bjorlin R., Blum J. Dowers perspective on the future of silicon photonics and electronics // Appl. Phys. Lett. 2021. 118. Art.20501.

88. G. Gilder Technology Report. Vol.5. N 1. Gilder Technology Group and Forbes Magazine, 2000.

89. Talbot R. Hardware Disaggregation: Generating Site and Network-Wide Requirements. URL: https://networkmatter.com/2015/09/25/hardware-disaggregation-generating-site-and-network-wide-requirements/

90. S h a n Y. Distributing and Disaggregating Hardware Resources in Data Centers. URL: https:// escholarship.org/uc/item / 35s245rd

91. Copik M., Chrapek M., Schmid L., Calotoiu A., Hoefler T. Software Resource Disaggregation for HPC with Serverless Computing. URL: https://spcl.ethz.ch/Publications/.pdf/2022_copik_ serverless_hpc_report.pdf

92. Стандарт пятого поколения (5G) мобильной связи получил официальное название IMT-2020. URL: https://1234g.ru/novosti/imt-2020

93. Правила разработки облачных решений. URL: https://learn.microsoft.com/ru-ru/azure/architecture/ patterns/

94. Microservice Architecture Pattern. URL: https://microservices.io/patterns/microservices.html

95. Copilot: Умный инструмент для программистов. URL: https://gb.ru/blog/copilot/

96. Технология программирования: Основные этапы разработки программ. URL: https://www.tadviser. ru/index.php/

97. Обзор технологических трендов 2023 от McKinsey Digital. URL: https://adpass.ru/ obzor-tehnologicheskih-trendov-2023-ot-mckinsey-digital/

98. Смелянский Р.Л., Антоненко В.А. Концепция программного управления и виртуализации сетевых сервисов в современных сетях передачи данных. М.: КУРС, 2020.

99. Feamster N., Balakrishnan Н., Rexford J., Shaikh A., Van der Merwe K. The case for separating routing from routers // ACM SIGCOMM Workshop on Future Directions in Network Architecture. Portland, OR, 2004.

100. Lakshman T.V., Nandagopal Т., Ramjee R., Sabnani K., Woo T. The Soft Router Architecture / / Proc. 3nd ACM Workshop on Hot Topics in Networks (Hotnets-III). San Diego, С A, 2004.

101. Farrel A., Vasseur J., Ash J. A Path Computation Element (PCE)-Based Architecture / / Internet Engineering Task Force. RFC 4655. 2006.

102. Handley M., Kohler E., Ghosh A., Hodson O., Radoslavov P. Designing extensible IP router software // Proc. Networked Systems Design and Implementation. USENIX Association, 2005.

103. Nicira. It's Time to Virtualize the Network. 2012. URL: http://nicira.com/en/network-virtualization-platform

104. Pfaff В., Pettit J., Amidon K., Casado M., Koponen Т., Shenker S. Extending networking into the virtualization layer // Proc. HotNets. 2009.

105. Erickson D. The Beacon OpenFlow controller // Proc. HotSDN. Hong Kong, China, 2013.

106. Floodlight OpenFlow Controller. URL: http://floodlight.openflowhub.org/

107. Gude N., Koponen Т., Pettit J., Pfaff В., Casado M., McKeown N., Shenker S. NOX: Towards an operating system for networks // ACM SIGCOMM Computer Communication Review. 2008. 38. N 3. P. 105-110.

108. Koponen Т., Casado M., Gude N., Stribling J., Poutievski L., Zhu M., Ra-manathan R., Iwata Y., Inoue H., Hama Т., Shenker S. Onix: A distributed control platform for large-scale production networks // OSDI. 2010. 10. P. 1-6.

109. ON.Lab. ONOS: Open Network Operating System, 2013. URL: http://tinyurl.com/pjs9eyw

110. POX. URL: http://www.noxrepo.org/pox/about-pox/

111. Casado M., Freedman M.J., Pettit J., Luo J., McKeown N., Shenker S. Ethane: Taking control of the enterprise // ACM SIGCOMM. 2007. 37. N 4. P. 1-12.

112. Nayak A., Reimers A., Feamster N., Clark R. Resonance: Dynamic access control in enterprise networks // Proc. Workshop: Research on Enterprise Networking. Barcelona, Spain, 2009.

113. H a n d i g о 1 N., F 1 a j s 1 i k M., Seetharaman S., McKeown N., J о h a r i R. Aster*x: Load-balancing as a network primitive // ACLD '10: Architectural Concerns in Large Datacenters. 2010.

114. Wang R., Butnariu D., Rexford J. OpenFlow-based server load balancing gone wild / / Hot-ICE. 2011.

115. What is Network virtualization? URL: http://www.redhat.com/en/topics/virtualization/ what- is- network-virtualization

116. Sherwood R., Gibb G., Yap K.K., Appenzeller G., Mckeown N., Parulkar G. Can the production network be the testbed?// Proc. 9th USENIX OSDI. Vancouver, Canada, 2010

117. Heller В., Seetharaman S., Mahadevan P., Yiakoumis Y., Sharma P., Banerjee S., McKeown N. ElasticTree: Saving energy in data center networks // NSDI. 2010. N 10. P. 249-264.

118. E r i с k s о n D. et al. A demonstration of virtual machine mobility in an OpenFlow network // Demo at ACM SIGCOMM. 2008.

119. Jain S., Kumar A., Mandai S., Ong J., Poutievski L., Singh A., Venkata S., Wanderer J., Zhou J., Zhu M., Zolla J., Hlzle U., Stuart S., Vahdat A. B4: Experience with a globally deployed software defined WAN // ACM SIGCOMM. Hong Kong, Cina, 2013.

120. Open Networking Foundation. URL: https://www.opennetworking.org/

121. Open Daylight. URL: http://www.opendaylight.org/

122. Network Function Virtualization. URL: https://www.etsi.org/images/files/ETSITechnologyLeafiets/ NetworkFunctions Virtualization. pdf

123. Network Functions Virtualization—Everything Old Is New Again. URL: http://interact.f5.com/rs/f5/ images/F5%20NFV%20white%20paper.pdf

124. What is openstak? URL: https://www.openstack.org/software

125. Intel DPDK. URL: https://github.com/DPDK/dpdk

126. Дубровский A. Kubernetes платформой контейнерной оркестрации. URL: https://cloud.croc.ru/ blog/about-technologies / chto-takoe-kubernetes /

127. ETSI GS NFV-MAN 001 VI.1.1 (2014-12). URL: https://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_ 099/001/01.01.01_60/gs_nfv-man001 v010101p.pdf

128. Моисеев H.H., И в а н и л о в Ю.П., Столярова Е.М. Методы оптимизации. М.: Наука, 1978.

129. Karimireddy S. P., Kale S., M oh ri M., Reddi S. J., Stich S. U., Suresh A. T. SCAFFOLD: Stochastic Controlled Averaging for Federated Learning. URL: http://proceedings.mlr.press/ v 119/karimireddy 20a / karimireddy 20a. p df

130. Vogels T., Karimireddy S.P., Jaggi M. PowerSGD: Practical Low-Rank Gradient Compression for Distributed Optimization. URL: https://proceedings.neurips.cc/paper_files/paper/2019/file/ d9fbed9da256e344clfa46bb46c34c5f-Paper.pdf

131. Oseledets I., Tyrtyshnikov E. TT-cross approximation for multidimensional arrays // Linear Algebra and its Applications. 2010. 432. N 1. P. 70-88.

132. Gusak J., Kholiavchenko M., Ponomarev E., Markeeva L., Blagoveschen-sky P., Cichocki A., Oseledets I. Automated multi-stage compression of neural networks // Proceedings of the IEEE/CVF International Conference on Computer Vision Workshops. IEEE, 2019.

133. Novikov A., Podoprikhin D., Osokin A., Vetrov D.P. Tensorizing neural networks // Advances in Neural Information Processing Systems. 2015. 28.

134. Gong Y. et al. ETTE: Efficient tensor-train-based computing engine for deep neural networks // Proceedings of the 50th Annual International Symposium on Computer Architecture. Orlando, USA, 2023. Art. 68. P. 1-13.

135. Смелянский Р.Л. MC2E — метаоблачная вычислительная среда для междисциплинарных исследований // Вести. РАН. 2022. 92. № 1. С. 46-56.

136. Dzeroski S., Panov P., Zenko В. Machine learning, ensemble methods // Encyclopedia of Complexity and Systems Science/Ed. by: Meyers R. N.Y.: Springer, 2009.

137. Ridge Regression. URL: https://www.ncss.com/wp-content/themes/ncss/pdf/Procedures/NCSS/Ridge_ Regression.pdf

138. Ширяев A.H. Вероятность. M.: Наука, 1989.

139. Cheng СМ., J i n XQ. Matrix decomposition // Encyclopedia of Social Network Analysis and Mining/ Eds. by: Alhajj R., Rokne J. N.Y.: Springer. 2018.

140. Standard Performance Evaluation Corporation. URL: https://spec.org

141. Benchmark Documentation. URL: https://spec.org/mpi2007/Docs/

142. MPI Program Execution Time Prediction Algorithms from the Article. IFIP Networking 2022 SLICES Workshop. URL: https://github.com/andxeg/

143. Вычисления на GPU — зачем, когда и как. Плюс немного тестов. URL: https://habr.com/ru/ companies / dbtc / articles /498374/

144. Balashov V.V., Plakunov A.V., Smelyanskiy R.L., Stepanov E.P. On Domain based Task Allocation in Network Powered by Computing. URL: https://www.researchgate.net/publication/ 378013253_On_Domain_based_Task_Allocation_in_Network_Powered_by_Computing

145. Bernárdez G. et al. Is machine learning ready for traffic engineering optimization? // IEEE 29th International Conference on Network Protocols (ICNP). IEEE, 2021.

146. You X., et al. Toward packet routing with fully distributed multiagent deep reinforcement learning // IEEE Transactions on Systems, Man, and Cybernetics Systems. 52.2. IEEE, 2020. P. 855-868.

147. M a i X., Fu Q., Chen Y. Packet routing with graph attention multi-agent reinforcement learning // IEEE Global Communications Conference (GLOBECOM). IEEE, 2021.

148. Stepanov E.P, Smeliansky R.L., Plakunov A.V., Borisov A.V., Zhu X., Pei J., Y a o Z. On fair traffic allocation and efficient utilization of network resources based on MARL // Computer Networks. 2024. 250. P. 110540.

149. ECMP Load Balancing. URL: https://www.dsco.eom/c/en/us/td/docs/ios-xml/ios/mp_13_vpns/ configuration / xe-3s / asr903/ mp-13-vpns-xe-3s-asr903-book/mp-13-vpns-xe-3s-asr903-book_chapter_0100. pdf

150. UCMP Load Balancing. URL: https://www.cisc0.c0m/c/en/us/td/d0cs/i0s-xml/i0s/mp_i3_vpns/ configuration / xe-3s / asr903/17-1-1 /b-mpls-13- vpns-xe-17- l-asr900/ m-ucmp.pdf

151. Го Ф., Смелянский Р.Л., Королев В.Ю. Прогнозирование качества сервиса неоднородного канала в сетях передачи данных // Ломоносовские чтения. Научная конференция. Тезисы докладов. М.: Изд. отдел ф-та ВМиК МГУ; МАКС Пресс, 2024. С. 114-115.

152. Рязанов A.M., Волканов Д.Ю., Горшенин А.К. Метод формирования обучающих наборов данных для обучения алгоритмов прогнозирования качества гетерогенных каналов в сетях передачи данных. URL: https://istina.msu.ru/publications/article/604472582/

153. Шибаев П.П., Писковский В.О. Об эффективности использования приватных блокчейнов для хранения конфигураций на примере блокчейн-приложения для сетевого контроллера RUNOS // Ломоносовские чтения. Научная конференция. Тезисы докладов. М.: Изд. отдел ф-та ВМиК МГУ; МАКС Пресс, 2023. С. 59-60.

154. Писковский В. О., Шибаев П.П. Об эффективности использования приватных блокчейнов для хранения конфигураций на примере блокчейн-приложения для сетевого контроллера RUNOS // Материалы XVI Всероссийской мультиконференции по проблемам управления "Управление в распределенных и сетевых системах". Т. 2. Петрозаводск: Изд во Петрозаводского гос. ун-та, 2023. С. 203-206.

155. Шибаев П.П., Писковский В.О. Об эффективности хранения конфигураций в блокчейн хранилище контроллера ИКС Runos // Тихоновские чтения. Научная конференция. Тезисы докладов. М.: МАКС Пресс, 2023. С. 87.

156. Писковский В.О., Шибаев П.П. Блокчейн-хранилище для контроллера ИКС Runos: концепция и архитектура // Программные системы и инструменты. № 23. М.: МАКС Пресс, 2023. С. 69-76.

Поступила в редакцию 06.08.24 Одобрена после рецензирования 01.09.24 Принята к публикации 01.09.24