Динамическая реконфигурация это что

Динамическое реконфигурирование микроконтроллера позволяет использовать более 100% его аппаратных ресурсов

Когда сталкиваются с проблемой разработки системы, которая должна выполнять множество задач, быть компактной и максимально энергоэффективной, весьма интересную возможность использования аппаратных ресурсов более чем на 100% предоставляет динамическое реконфигурирование. Представим торговый автомат, который, выполняя основную функцию принятия денег и выдачи товара, должен периодически обмениваться данными с центральным процессором. При использовании динамической реконфигурации тот же набор цифровых ресурсов, который в момент торговли настроен на выполнение функций таймеров/счетчиков, может быть сконфигурирован как блок UART и ШИМ для задания скорости передачи во время обмена с хост-процессором.

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

Динамическое изменение конфигурации

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

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

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

Рисунок 1.

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

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

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

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

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

Рисунок 2.

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

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

Как и программируемые аналоговые блоки, цифровая периферия также может выполнять различные функции, определяемые записью требуемых значений в конфигурационные регистры для данного цифрового блока. Программируемые входные/выходные соединения позволяют подключить любой вывод к любому периферийному устройству процессора. Таким образом, один и тот же аппаратный блок может подключаться к различным выводам в различное время. Например, цифровой блок, сконфигурированный как ШИМ для управления светодиодами, в другое время может выполнять функции универсального асинхронного приемопередатчика (UART), используя другие линии ввода/вывода.

Целесообразность динамического реконфигурирования

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

Алгоритмы автоматического восстановления ИС

3. Модель процесса автоматического восстановления отказоустойчивых КС.

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

Реконфигурация и способы восстановления КС.

Рекомендуемые материалы

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

Реконфигурация КС – изменение состава и способа взаимодействия программных и аппаратных средств системы с целью исключения отказавших программных или аппаратных компонентов. Реконфигурация производится после выявления отказа. Различают статическую и динамическую реконфигурацию.

Статическая реконфигурация системы осуществляется путем отключения неисправных компонентов КС. Динамическая реконфигурация по принципу проведения делится на следующие виды: замещение, дублирование, постепенная «деградация » .

После реконфигурации для продолжения нормальной работы системы необходимо её восстановить, восстановление системы происходит на двух уровнях (рис. 1).

1. Аппаратный уровень. Здесь производится восстановление отказавших компонентов КС двумя способами:

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

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

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

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

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

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

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

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

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

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

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

Рис. 2. Функционирование вычислительного процесса.

Модель процесса автоматического восстановления

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

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

Процессы восстановления в пассивных и активных отказоустойчивых КС имеют много общего. Рассмотрим граф на рис. 3.[1,7,10]:

Возникшая в КС ошибка S₁ может обнаруживаться либо аппаратными S₂, либо программными S₃ средствами контроля, либо не обнаруживаться средствами контроля S₄. В последнем случае результатом является отказ системы S₅.

В зависимости от степени применения пассивной отказоустойчивости в КС ошибка может быть маскирована S₆ и вычислительный процесс продолжается без задержки S₇. При обнаружении ошибки аппаратными средствами в большинстве систем проводится повторение выполняемой операции в заданное число раз. Если повторение было успешным, т.е. имел место сбой, последствия которого при повторении операции исчезли, вычислительный процесс продолжается S₈. Для повторении операции необходимо чтобы аппаратные средства сохранили операнды до окончания контроля над выполненной операцией. Если повторении операции было безуспешным S₉, то это говорит об устойчивой ошибке в аппаратуре и поэтому производится автоматическая реконфигурация S₁₀.

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

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

Аналогичные процедуры проводятся в случае, когда ошибка обнаружена программными средствами. После обнаружения ошибки программными средствами могут быть задействованы тесты S₁₄. Если тесты подтверждают наличие устойчивого отказа S₁₅, то следует реконфигурация S₁₀, возврат к контрольной точке S₁₁, восстановление данных S₁₂ и повторение вычислений S₁₃. Если устойчивого отказа нет S₁₆, то повторяются перечисленные операции без реконфигурации.

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

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

Контрольные вопросы и задания

1. Определите виды ошибок в КС которые можно исправить с помощью маскирования.

2. Дайте определение понятию «реконфигурация » .

3. Что такое динамическая и статическая реконфигурация.

4. Постройте граф состоянии и переходов процесса восстановления в отказоустойчивых КС.

Software Journal:
Theory and Applications

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

The article was published in issue №3 by 2018 year

» »
• Способы и средства динамической реконфигурации сетей суперкомпьютера при представлении пользовательских заданий в виде контейнеров

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

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

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

– параллельная программа, решающая прикладную задачу;

– требования к ресурсам: сколько ВМ, с какими характеристиками, на какое время требуется для выполнения параллельной программы;

– входные данные параллельной программы.

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

Управление пользовательскими заданиями в современных суперкомпьютерных системах осуществляется с помощью специального программного обеспечения – систем управления заданиями (СУЗ) [2], в качестве которых могут выступать такие известные продукты, как SLURM, PBS, Moab и др. Основной функционал СУЗ состоит в приеме входного потока пользовательских заданий, ведении очереди заданий, выделении вычислительных модулей суперкомпьютера для прошедшего через очередь задания, в запуске и контроле выполнения задания, освобождении выделенных ресурсов по завершении задания. Важным аспектом функционирования любой СУЗ является обеспечение надежной изоляции пользовательских заданий. Изоляция заданий подразумевает конфигурирование выделенных заданию ВМ таким образом, чтобы доступ к этим ВМ мог получить только пользователь – владелец задания. Кроме того, должно быть исключено влияние выполняющихся процессов одного задания на выполнение процессов другого задания.

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

ВМ суперкомпьютера выделяются СУЗ динамически из числа свободных на момент запуска задания, и заранее предсказать состав выделяемых модулей невозможно. В случае представления задания в виде контейнера или образа виртуальной машины это порождает задачу динамической конфигурации сетей суперкомпьютера для такого задания [3] с автоматической организацией необходимого уровня изоляции заданий. Настоящая работа посвящена поиску решений этой задачи для случая контейнерной виртуализации.

Средства контейнерной виртуализации

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

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

Прообраз средств контейнерной виртуализации можно увидеть в классической Unix-команде chroot, предоставляющей простейшую изоляцию файловой системы путем смены корневого каталога пользователя. По-настоящему о контейнерной виртуализации заговорили после появления в Linux механизмов пространства имен и контрольных групп, одним из самых известных проектов, использующих эти возможности, стал проект контейнеров Linux под названием LXC (Linux Containers). Существенный толчок в развитии технологии контейнерной виртуализации был дан в 2013 году появлением ПО Docker, компания-разработчик которого Docker Inc предоставила стандартный API, упростивший создание и использование контейнеров. В настоящее время Docker является средством контейнерной виртуализации, получившим наибольшее распространение, имеющим свободно распространяемую версию, наиболее активно развивающимся и имеющим наибольшее число готовых решений для организации сетевого взаимодействия контейнеров [4].

Docker позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, переносимый между любыми Linux-системами, ядро которых обладает поддержкой механизма контрольных групп. Изначально Docker использовал возможности реализации технологии контейнерной виртуализации LXC, но с 2015 года применяет собственную библиотеку libcontainer, абстрагирующую возможности ядра Linux по виртуализации.

ПО Docker может быть использовано для представления суперкомпьютерных пользовательских заданий в виде контейнеров [5, 6]. В указанных работах развертывание на суперкомпьютере пользовательского задания в виде набора контейнеров существенно опирается на возможности и средства распространенной СУЗ SLURM, что ограничивает применение предложенного способа. Например, в Межведомственном суперкомпьютерном центре РАН (МСЦ РАН) [7] и Институте прикладной математики им. М.В. Келдыша РАН [8] активно применяется отечественная Система управления прохождением параллельных заданий (СУППЗ) [8, 9]. С точки зрения организации вычислений главным отличием СУППЗ от других СУЗ, прежде всего от SLURM, является отсутствие постоянно работающих активных програм-мных компонентов, установленных на ВМ, – все компоненты СУППЗ устанавливаются на управляющую ЭВМ.

Сетевая инфраструктура современной суперкомпьютерной системы

Де-факто в современных суперкомпьютерных системах используются сети двух типов: транспортные (управляющие) и высокоскоростные коммуникационные сети.

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

Высокоскоростные коммуникационные сети предназначены для обмена информацией между процессами параллельной программы, выполняющимися на разных выделенных заданию ВМ. Стандартом последних лет в области высокопроизводительных вычислений стало использование в качестве высокоскоростных сетей Infiniband. С 2016 года началось внедрение сетей Intel Omni-Path [11] – реализации Infiniband от компании Intel.

Типовая организация сетевой инфраструктуры суперкомпьютера представлена на рисунке 1.

По сути организация транспортных и управляющих сетей суперкомпьютера ничем не отличается от организации обычных локальных сетей, основанных на стеке протоколов TCP/IP. Главным недостатком этого стека являются высокая латентность, обуславливающая существенные потери производительности при параллельных вычислениях [1]. По этой причине высокоскоростная сеть суперкомпьютера (Infiniband, Omni-Path) используется без применения стека TCP/IP.

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

Сетевые средства Docker

Сеть Docker построена на модели CNM (Container Network Model). Модель разработана компанией Docker и описывает основные компоненты и порядок их взаимодействия, необходимые для организации сетевого взаимодействия с контейнерами. Реализацией CNM является библиотека libnetwork, которая позволяет пользователю создать свой собственный сетевой драйвер, если существующие не удовлетворяют его требованиям.

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

bridge – связь устанавливается через мостовой интерфейс на физическом ВМ; у контейнеров, которые используют одинаковую сеть, есть своя собственная подсеть, и они могут передавать данные друг другу по умолчанию;

host – предоставляет контейнеру доступ к собственному пространству ВМ; контейнер будет «видеть» и использовать тот же интерфейс, что и ВМ;

macvlan – дает контейнерам прямой доступ к интерфейсу ВМ;

overlay – позволяет строить сети на нескольких компьютерах, использующих Docker, объединенных сетью.

Напомним, что сетевое взаимодействие контейнеров в рамках одного задания должно осуществляться как по управляющим и транспортным сетям (Ethernet), так и по высокоскоростным сетям, используемым в ходе вычислений (Infiniband, Omni-Path). Сетевые драйверы Docker нацелены на использование стека TCP/IP. В случае использования устройств высокоскоростной сети, настроенной для работы со стеком TCP/IP, можно организовать высокопроизводительные вычисления, используя стандартные средства Docker и не прибегая к дополнительным способам и средствам. Однако применение надстроек, обеспечивающих работу со стеком TCP/IP, над устройствами высокопроизводительной сети сильно повышает латентность, снижает производительность и в целом приводит к замедлению вычислений [1]. Если представлять пользовательские задания в виде контейнеров Docker, необходимо использовать высокопроизводительные сетевые устройства в «чистом» виде, без использования TCP/IP.

Docker позволяет добавлять в контейнер различные устройства, такие как графические карты, сетевые устройства и т.п. В рамках работы представляет интерес добавление поддержки устройств высокопроизводительной коммутируемой сети Infiniband. Для этого необходимо осуществить добавление двух устройств в момент запуска контейнера:

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

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

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

1. Использование Ethernet-сети физического ВМ.

Docker позволяет определить соответствие порта управляющего компьютера с открытым портом контейнера. При организации сети подобным образом удаётся получить доступ к контейнеру, используя IP-адрес ВМ и открытый на ВМ порт. Однако возможным становится получение доступа к контейнеру посредством любого ВМ, имеющего сетевой доступ к управляющему компьютеру такого контейнера. Для режима коллективного пользования необходимо обеспечить большую изоляцию вычислительных заданий, следовательно, рассматриваемый вариант неприменим.

2. Сети Docker типа overlay.

В версии Docker 1.12 [13] появилась новая опция, получившая название Swarm mode (режим роя). «Режим роя» позволяет объединить в кластер фоновые серверные процессы Docker, расположенные физически на разных узлах сети. При работе в таком режиме фоновый процесс Docker считает все ВМ единым контейнерным пространством. С «режимом роя» в Docker появился новый сетевой драйвер overlay. Контейнеры в данном случае называются службами. «Режим роя» позволяет производить запуск определенного количества контейнеров для одной службы, а также автоматически производит балансировку нагрузки между физическими компьютерами, выполняя равномерное распределение контейнеров по ВМ.

Для объединения контейнеров службы в единую подсеть необходимо создать сеть Docker с драйвером overlay, используя команду создания сети –docker network create driver overlay my_net (здесь my_net – произвольное имя сети).

Однако при таком подходе Docker не позволяет присоединять отдельные контейнеры к созданным подобным способом overlay-сетям. Использование служб Docker в рамках настоящей работы невозможно из-за отсутствия у них возможности предотвращения повышения пользователем своих привилегий внутри контейнера, поскольку команда создания службы docker service create не имеет соответствующего параметра запуска.

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

Динамическое реконфигурирование сетей суперкомпьютера
с помощью сторонних сетевых драйверов Docker

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

Проблема объединения контейнеров, расположенных на различных физических ВМ, привела к созданию различных сетевых дополнений для Docker, одним из которых является Project Calico [14]. Этот драйвер позволяет объединять контейнеры в единую сеть без использования средств оркестрации контейнеров и «режима роя» Docker. Project Calico является проектом с открытым исходным кодом, отличается безопасностью и легкой масштабируемостью, изначально предназначался для организации сетей в облачных средах.

Альтернативой Project Calico может служить средство настройки сетей Flannel [15], разработанное для системы автоматизации развертывания, масштабирования и управления контейнеризированными приложениями Kubernetes [16]. Однако Kubernetes является хорошим решением в качестве основы для управления ресурсами в облачных платформах [17], требует полного контроля над вычислительными модулями и несовместим с суперкомпьютерными СУЗ. Кроме этого, в работе [18] показано, что Project Calico обладает наилучшей производительностью по сравнению с Flannel и сетями Docker типа overlay.

Для обеспечения возможности работы с сетями, использующими драйвер Project Calico, необходимо:

– настроить распределенное хранилище данных etcd [19];

– сконфигурировать фоновый серверный процесс Docker;

– запустить службу сетей calico;

– создать определенный диапазон IP-адресов, необходимый для создания подсетей.

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

Архитектура сети с применением драйвера calico представлена на рисунке 2. Для работы драйвера calico требуется высоконадежное распределенное хранилище конфигурации etcd, настроенное на всех ВМ, где будет производиться запуск контейнеров, подключаемых к сети с использованием драйвера calico. Etcd представляет собой программный пакет, разработанный компанией CoreOS и предназначенный для хранения данных в формате «ключ-значение». Calico использует etcd для хранения информации о созданных диапазонах IP-адресов подсетей calico, а также для хранения соответствий имен контейнеров их IP-адресам и сетям.

После установки на ВМ программных средств (Docker, etcd, calico), необходимых для создания сети с драйвером calico, для динамической конфигурации сети необходимо выполнение следующих действий:

– для рассматриваемого задания выделить множество ВМ;

– на первом из выделенных заданию ВМ создать Docker-сеть, используя драйвер calico (такая сеть становится доступной на всех ВМ, входящих в кластер etcd);

– для каждого ВМ, выделенного заданию, проверить доступность созданной сети и присоединить к ней запускаемый в рамках задания контейнер;

– с первого из выделенных заданию ВМ проверить доступность в созданной сети всех выделенных ВМ: если все ВМ доступны, завершить конфигурацию сети; если хотя бы один ВМ недоступен, прервать создание сети и аварийно завершить задание.

После создания сети адресация осуществляется между контейнерами по адресам типа «имя_контейнера.имя_сети». Контейнеры, присоединенные к одной сети, не имеют доступа к контейнерам другой сети, даже если их IP-адреса находятся в одном диапазоне [12]. Доступ к Docker-сети, использующей драйвер calico, осуществим только из контейнера, который был к этой сети присоединен, что автоматически определяет необходимый уровень изоляции представленного в виде набора контейнеров задания.

Макет суперкомпьютерной системы с представлением пользовательских заданий
в виде контейнеров Docker

Каждый ВМ HP ProLiant BL2x220c G5 содержит в своем составе:

– два интерфейса Gigabit Ethernet;

– адаптер Infiniband Mellanox MT25204;

– два процессора Intel Xeon E5450 (4 ядра, работающих на частоте 3 ГГц);

– оперативную память 8 ГБ;

– встроенный жесткий диск 120 ГБ.

На каждый из ВМ было установлено следующее системное и инструментальное ПО:

– etcd (версия 3.2.15);

– docker community edition (версия 18.03);

– calicoctl (версия 0.22);

– модуль языка python paramiko (версия 2.4.1).

В качестве СУЗ на макете была использована СУППЗ, для которой авторами были разработаны два программных модуля автоматизации процедур запуска/остановки параллельных вычислительных заданий, представленных в виде Docker-контейнеров. Последовательность действий, выполняемых системой командных файлов СУППЗ при запуске вычислительного задания в виде контейнера, представлена на рисунке 4.

Часть действий выполняется на управляющей ЭВМ макета в специальном командном сценарии пролога СУППЗ, часть – на ВМ в специальном сценарии подготовки модуля. Командные файлы указанных сценариев доступны для модификации системному администратору СУППЗ, то есть процедура внесения в них изменений является стандартной и описана в документации СУППЗ.

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

Далее на первом из списка выделенных заданию ВМ выполняется команда создания сети Docker, использующей драйвер calico. Название сети соответствует имени задания, которое является уникальным в СУППЗ, чем обеспечивается изоляция вычислительного задания.

Для запуска контейнеров вычислительного задания необходимо извлечь образ из файла. Извлечение происходит на каждом из выделенных ВМ.

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

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

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

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

Далее вычислительное задание пользователя находится в стадии выполнения.

По истечении времени, выделенного СУППЗ на выполнение задания, происходит очистка выделенных ВМ от процессов задания. Последовательность действий по очистке модулей показана на рисунке 5.

Часть действий выполняется на управляющей ЭВМ макета в специальном командном сценарии эпилога СУППЗ, часть – на ВМ в специальном сценарии очистки модуля.

Командные файлы указанных сценариев доступны для модификации системному администратору СУППЗ, процедура внесения в них изменений, как и для сценариев пролога и подготовки модулей, является стандартной и описана в документации СУППЗ.

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

Заключение

Для решения задачи динамической реконфигурации сетей суперкомпьютера при запуске представленных в виде Docker-контейнеров пользовательских заданий авторами были исследованы ряд способов и средств. В ходе исследований выяснено, что стандартные сетевые средства Docker не удовлетворяют требованиям обеспечения необходимого уровня изоляции заданий. В результате был определен способ реконфигурации сетей, основанный на применении распределенного хранилища данных etcd и специального драйвера calico. Способ позволяет осуществить динамическую реконфигурацию сетей суперкомпьютера практически для любой системы управления заданиями. Авторы произвели практическую реализацию предложенного способа для отечественной СУППЗ, эксплуатируемой в качестве СУЗ на суперкомпьютерных системах МСЦ РАН и ИПМ им. М.В. Келдыша РАН. Результатом стал программно-аппаратный макет суперкомпьютерной системы, обеспечивающий обработку представленных в виде Docker-контейнеров заданий с динамической реконфигурацией сетей. Ближайшей перспективой работы является внедрение рассмотренного в статье способа на суперкомпьютерах МСЦ РАН, входящих в состав оборудования центра коллективного пользования вычислительными ресурсами МСЦ РАН.

Статья подготовлена в рамках выполнения государственного задания ФГУ ФНЦ НИИСИ РАН .

Литература

1. Баранов А.В., Николаев Д.С. Использование контейнерной виртуализации в организации высокопроизводительных вычислений // Программные системы: теория и приложения. 2016. Т. 7. № 1 (28).
С. 117–134. DOI: 10.25209/2079-3316-2016-7-1-117-134.

2. Баранов А.В., Киселёв А.В., Старичков В.В., Ионин Р.П., Ляховец Д.С. Сравнение систем пакетной обработки с точки зрения организации промышленного счета // Научный сервис в сети Интернет: поиск новых решений: тр. Междунар. суперкомп. конф. (17–22 сентября 2012 г., Новороссийск). М.: Изд-во МГУ, 2012. С. 506–508. URL: http://agora.guru.ru/abrau2012/pdf/506.pdf (дата обращения: 12.04.2018).

3. Шабанов Б.М., Овсянников А.П., Баранов А.В., Аладышев О.С., Киселёв Е.А., Жуков Я.О. Методы управления параллельными заданиями суперкомпьютера, требующими развертывания отдельных программных платформ и виртуализации сетей // Суперкомпьютерные дни в России: тр. Междунар. конф. (25–26 сентября 2017 г., Москва). М.: Изд-во МГУ, 2017. С. 616– 627. URL: https://elibrary.ru/download/elibrary_30632214_33009164.pdf (дата обращения: 05.07.2018).

4. Подорожный И.В., Светличный А.Н., Подлеснов А.В. Введение в контейнеры, виртуальные машины и docker // Молодой ученый. 2016. № 19. С. 49–53. URL: https://moluch.ru/archive/123/33873/ (дата обращения: 02.07.2018).

5. Щапов В.А., Денисов А.В., Латыпов С.Р. Применение контейнерной виртуализации Docker для запуска задач на суперкомпьютере // Суперкомпьютерные дни в России: тр. Междунар. конф. (26–27 сентября 2016 г., Москва). М.: Изд-во МГУ, 2016. С. 505–511. URL: https://elibrary.ru/download/elibrary_27206414_31832253.pdf (дата обращения: 05.07.2018).

6. Щапов В.А., Латыпов С.Р. Способы запуска задач на суперкомпьютере в изолированных окружениях с применением технологии контейнерной виртуализации Docker // Науч.-технич. вестн. Поволжья. 2017. № 5. С. 172–177.

7. МСЦ РАН – Вычислительные системы. URL: http://www.jscc.ru/scomputers.html (дата обращения: 04.07.2018).

8. Вычислительные ресурсы ИПМ им. М.В. Келдыша РАН. URL: http://www.kiam.ru/MVS/resourses/ (дата обращения: 04.07.2018).

9. СУППЗ. URL: http://suppz.jscc.ru/ (дата обращения: 03.07.2018).

10. Система управления прохождением параллельных заданий (СУППЗ). Руководство программиста (пользователя). URL: http://www.jscc.ru/informat/СУППЗ_Руководство_пользователя.pdf (дата обращения: 03.07.2018).

11. Intel® Omni-Path Architecture (Intel® OPA) Driving Exascale Computing and HPC with Intel. URL: https://www.intel.ru/content/www/ru/ru/high-performance-computing-fabrics/omni-path-driving-exascale-computing.html (дата обращения: 02.07.2018).

12. Николаев Д.С., Корнеев В.В. Использование механизмов контейнерной виртуализации в высокопроизводительных вычислительных комплексах с системой планирования заданий Slurm // Программная инженерия. 2017. Т. 8. № 4. С. 157–160.

13. Docker CE release notes. URL: https://docs.docker.com/release-notes/docker-ce/ (дата обращения: 02.07.2018).

14. Project Calico – Secure Networking for the Cloud Native Era. URL: https://www.projectcalico.org (дата обращения: 02.07.2018).

15. GitHub – coreos/flannel: flannel is a network fabric for containers, designed for Kubernetes. URL: https://github.com/coreos/flannel (дата обращения: 04.07.2018).

16. Production-Grade Container Orchestration – Kubernetes. URL: https://kubernetes.io (дата обращения: 05.07.2018).

17. Coullon H., Pertin D., Perez C. Production Deployment Tools for IaaSes: an Overall Model and Survey. 2017 IEEE 5th International Conference on Future Internet of Things and Cloud (FiCloud), 2017, pp. 183–190. DOI: 10.1109/FiCloud.2017.51.

18. Zeng H., Wang BS., Deng WP., Zhang, WQ. Measurement and Evaluation for docker container networking. Proc. 2017 Intern. Conf. on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC), 2017, pp. 105–108. DOI: 10.1109/CyberC.2017.78.

Реконфигурируемые вычисления — Reconfigurable computing

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

Содержание

История

Концепция реконфигурируемых вычислений существует с 1960-х годов, когда Джеральд Эстрин В статье предложена концепция компьютера, состоящего из стандартного процессора и набора «реконфигурируемого» оборудования. [1] [2] Главный процессор будет управлять поведением реконфигурируемого оборудования. Последний затем будет адаптирован для выполнения конкретной задачи, например обработка изображений или сопоставление с образцом, так же быстро, как выделенное оборудование. Как только задача была выполнена, оборудование можно было настроить для выполнения другой задачи. Это привело к созданию гибридной компьютерной структуры, сочетающей гибкость программного обеспечения со скоростью оборудования.

В 1980-х и 1990-х годах в этой области исследований наблюдалось возрождение, когда в промышленности и академических кругах было разработано множество предложенных реконфигурируемых архитектур. [3] такие как: Copacobana, Matrix, GARP, [4] Эликсент, NGEN, [5] Полип, [6] MereGen, [7] PACT XPP, Silicon Hive, Montium, Pleiades, Morphosys и PiCoGA. [8] Такие конструкции были возможны благодаря постоянному развитию кремниевых технологий, которые позволяли реализовать сложные конструкции на одном кристалле. Некоторые из этих массово-параллельных реконфигурируемых компьютеров были созданы в первую очередь для специальных субдоменов, таких как молекулярная эволюция, нейронная система или обработка изображений. Первый в мире коммерческий реконфигурируемый компьютер, Algotronix CHS2X4, был построен в 1991 году. Он не имел коммерческого успеха, но был достаточно многообещающим, чтобы Xilinx (изобретатель Программируемая вентильная матрица, FPGA) купил технологию и нанял персонал Algotronix. [9] Более поздние машины позволили впервые продемонстрировать научные принципы, такие как спонтанная пространственная самоорганизация генетического кодирования с помощью MereGen. [10]

Теории

Классификация Треденника

Таблица 1: Схема классификации парадигм Ника Треденника

Ранние исторические компьютеры:
	Источник программирования
Ресурсы исправлены	никто
Исправлены алгоритмы	никто
фон Неймана Компьютер:
	Источник программирования
Ресурсы исправлены	никто
Переменная алгоритмов	Программное обеспечение (потоки инструкций)
Реконфигурируемые вычислительные системы:
	Источник программирования
Переменная ресурсов	Configware (конфигурация)
Переменная алгоритмов	Flowware (потоки данных)

Фундаментальная модель парадигмы реконфигурируемой вычислительной машины, основанная на потоке данных анти машина хорошо иллюстрируется отличиями от других машинных парадигм, которые были введены ранее, как показано Ник Треденник следующая схема классификации компьютерных парадигм (см. «Таблица 1: Схема классификации парадигм Ника Треденника»). [11]

Xputer Хартенштейна

Ученый-компьютерщик Райнер Хартенштейн описывает реконфигурируемые вычисления в терминах антимашина это, по его словам, представляет собой фундаментальный сдвиг парадигмы от более традиционных машина фон Неймана. [12] Хартенштейн называет это парадоксом реконфигурируемых вычислений, когда программное обеспечение-конфигурируемое ПО (ПО-FPGA ) миграция приводит к зарегистрированным факторам ускорения более чем на четыре порядка, а также к снижению потребления электроэнергии почти на четыре порядка, хотя технологические параметры ПЛИС отстают от Кривая Гордона Мура примерно на четыре порядка, а тактовая частота существенно ниже, чем у микропроцессоров. Этот парадокс частично объясняется Синдром фон Неймана.

Высокопроизводительные вычисления

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

Расширение логики в ПЛИС позволило программировать более крупные и сложные алгоритмы в ПЛИС. Присоединение такой ПЛИС к современному процессору по высокоскоростной шине, например PCI Express, позволил настраиваемой логике действовать больше как сопроцессор а не периферийный. Это принесло реконфигурируемые вычисления в высокопроизводительные вычисления сфера.

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

Этот метод гетерогенных систем используется в компьютерных исследованиях и особенно в суперкомпьютеры. [13] В документе 2008 года сообщалось о факторах ускорения более чем на 4 порядка и факторах экономии энергии почти на 4 порядка. [14] Некоторые суперкомпьютерные фирмы предлагают гетерогенные блоки обработки, включая ПЛИС в качестве ускорителей. [ нужна цитата ] Одной из областей исследований является производительность потока инструментов программирования с двумя парадигмами, полученная для таких гетерогенных систем. [15]

Соединенные штаты Национальный фонд науки имеет центр высокопроизводительных реконфигурируемых вычислений (CHREC). [16] В апреле 2011 года в Европе прошла четвертая Конференция по многоядерным и реконфигурируемым суперкомпьютерам. [17]

Коммерческие высокопроизводительные реконфигурируемые вычислительные системы начинают появляться с анонсом IBM интеграция ПЛИС с ее МОЩНОСТЬ процессор. [18]

Частичная реконфигурация

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

Электронное оборудование, подобно программного обеспечения, можно разрабатывать модульно, создавая подкомпоненты, а затем компоненты более высокого уровня для их создания. Во многих случаях полезно иметь возможность заменить один или несколько из этих подкомпонентов, пока FPGA все еще работает.

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

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

Частичная реконфигурация поддерживается не всеми ПЛИС. Требуется специальный поток программного обеспечения с упором на модульную конструкцию. Обычно модули проектирования строятся по четко определенным границам внутри ПЛИС, что требует специального сопоставления проекта с внутренним оборудованием.

По функциональности конструкции частичную реконфигурацию можно разделить на две группы: [19]

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

Текущие системы

Эмуляция компьютера

С появлением доступных плат FPGA проекты студентов и любителей стремятся воссоздать старые компьютеры или реализовать более новые архитектуры. [20] [21] [22] Такие проекты создаются с использованием реконфигурируемого оборудования (ПЛИС), а некоторые устройства поддерживают эмуляцию нескольких старых компьютеров с использованием одного реконфигурируемого оборудования (C-One ).

КОПАКОБАНА

Компьютер, полностью основанный на ПЛИС, — это COPACOBANA, оптимизированный по стоимости взломщик кода и анализатор и его преемник RIVYERA. Дочерняя компания SciEngines GmbH проекта COPACOBANA университетов Бохума и Киля в Германии продолжает разработку компьютеров, полностью основанных на ПЛИС.

Митрионика

Митрионика разработал SDK, который позволяет писать программы с использованием разовое задание язык для компиляции и выполнения на компьютерах на базе FPGA. Программный язык Mitrion-C и процессор Mitrion позволяют разработчикам программного обеспечения писать и выполнять приложения на компьютерах на базе FPGA таким же образом, как и с другими вычислительными технологиями, такими как графические процессоры («GPU»), процессоры на основе ячеек, параллельная обработка. единиц («PPU»), многоядерных ЦП и традиционных одноядерных кластеров ЦП. (из бизнеса)

Национальные инструменты

Национальные инструменты разработали гибридную встроенную вычислительную систему под названием CompactRIO. Он состоит из реконфигурируемого шасси, в котором размещается программируемая пользователем ПЛИС, модули ввода-вывода с возможностью горячей замены, контроллер реального времени для детерминированной связи и обработки, а также графическое программное обеспечение LabVIEW для быстрого программирования в реальном времени и на ПЛИС.

Xilinx

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

Intel

Intel [23] поддерживает частичную реконфигурацию своих устройств FPGA на 28-нм устройствах, таких как Stratix V, [24] и на 20 нм устройствах Arria 10. [25] Процесс частичной реконфигурации Intel FPGA для Arria 10 основан на методологии иерархического проектирования в программном обеспечении Quartus Prime Pro, где пользователи создают физические разделы FPGA, которые можно перенастроить. [26] во время выполнения, в то время как остальная часть проекта продолжает работать. Программное обеспечение Quartus Prime Pro также поддерживает иерархическую частичную реконфигурацию и моделирование частичной реконфигурации.

Классификация систем

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

Гранулярность

Гранулярность реконфигурируемой логики определяется как размер наименьшего функционального блока (настраиваемого логического блока, CLB), к которому обращаются инструменты отображения. Высокая степень детализации, которую также называют мелкой детализацией, часто подразумевает большую гибкость при внедрении алгоритмов в оборудование. Однако с этим связан штраф в виде увеличенной мощности, площади и задержки из-за большего количества маршрутов, требуемых на одно вычисление. Мелкозернистые архитектуры работают на уровне манипуляции на битовом уровне; в то время как элементы крупнозернистой обработки (реконфигурируемый блок передачи данных, rDPU) лучше оптимизированы для приложений стандартного тракта данных. Одним из недостатков крупнозернистых архитектур является то, что они имеют тенденцию терять часть своего использования и производительности, если им нужно выполнять меньшие вычисления, чем обеспечивает их гранулярность, например, для добавления одного бита к функциональному блоку шириной четыре бита будет потрачено три бита. . Эту проблему можно решить, имея крупнозернистый массив (реконфигурируемый массив каналов данных, rDPA) и a FPGA на том же чипе.

Крупнозернистые архитектуры (rDPA ) предназначены для реализации алгоритмов, которым требуются тракты данных шириной слова (rDPU). Поскольку их функциональные блоки оптимизированы для больших вычислений и обычно включают в себя арифметико-логические устройства (ALU), они будут выполнять эти вычисления быстрее и с большей энергоэффективностью, чем набор связанных между собой более мелких функциональных блоков; это происходит из-за того, что соединительные провода короче, что приводит к меньшей емкости проводов и, следовательно, более быстрым конструкциям с меньшим энергопотреблением. Потенциальным нежелательным следствием наличия больших вычислительных блоков является то, что, когда размер операндов может не соответствовать алгоритму, может произойти неэффективное использование ресурсов. Часто тип запускаемых приложений известен заранее, что позволяет адаптировать логику, память и ресурсы маршрутизации для повышения производительности устройства, при этом обеспечивая определенный уровень гибкости для будущей адаптации. Примерами этого являются массивы для конкретных предметных областей, нацеленные на получение более высокой производительности с точки зрения мощности, площади и пропускной способности, чем их более общие более мелкозернистые FPGA двоюродных братьев за счет уменьшения их гибкости.

Скорость реконфигурации

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

Связь с хостом

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

Маршрутизация / межсоединения

Гибкость реконфигурируемых устройств в основном обусловлена ​​их маршрутизацией. Один стиль межсоединений стал популярным благодаря ПЛИС Поставщики Xilinx и Altera — это макет островного типа, где блоки расположены в массив с вертикальной и горизонтальной маршрутизацией. Макет с неадекватной маршрутизацией может страдать от плохой гибкости и использования ресурсов, что приводит к ограниченной производительности. Если предусмотрено слишком много межсоединений, потребуется больше транзисторов, чем необходимо, и, следовательно, большая площадь кремния, более длинные провода и большее энергопотребление.

Проблемы для операционных систем

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

Одна из основных задач операционной системы — скрыть оборудование и представить программы (и их программистов) красивыми, чистыми, элегантными и последовательными абстракциями для работы. Другими словами, две основные задачи операционной системы — это абстракция и управление ресурсами. [27]

Абстракция — это мощный механизм для решения сложных и различных (аппаратных) задач четко определенным и общим образом. Одна из самых элементарных абстракций ОС — это процесс. Процесс — это запущенное приложение, у которого есть ощущение (обеспечиваемое ОС), что оно выполняется самостоятельно на базовом виртуальном оборудовании. Это можно смягчить за счет концепции потоков, позволяющих одновременно запускать различные задачи на этом виртуальном оборудовании для использования параллелизма на уровне задач. Чтобы позволить различным процессам и потокам координировать свою работу, операционная система должна обеспечивать методы связи и синхронизации. [27]

В дополнение к абстракции необходимо управление ресурсами базовых аппаратных компонентов, поскольку виртуальные компьютеры, предоставляемые процессам и потокам операционной системой, должны совместно использовать доступные физические ресурсы (процессоры, память и устройства) пространственно и временно. [27]