Библиотека

СОЛОВЬЕВ В. М., к.т.н.,доцент (СГУ, г. Саратов),
      СПЕРАНСКИЙ Д. В., д.т.н., профессор (МГУПС, г. Москва),
      ЩЕРБАКОВ М. Г., аспирант,
      ИРМАТОВ П. В., аспирант (СГУ, г. Саратов)

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

 

                Введение  

          
            В Поволжском региональном центре новых информационных технологий Саратовского государственного университета (ПРЦНИТ СГУ) при моделировании живых систем, при решении задач молекулярной динамики, механики сплошной среды, квантовой химии, медицины и т.п. широко применяются методы высокопроизводительных вычислений. При этом в основном используются университетские кластеры серверов высокопроизводительных вычислений, на которых развернуто самое разнообразное программное обеспечение (ПО), а в последнее время интенсивно внедряются технологии облачных вычислений (Cloud Computing). Наряду со стандартными средствами параллельного программирования и множеством их библиотек, которые университетский кластер обязан поддерживать, используется и многопроцессорное (многоядерное) «научное» ПО. Оно составляет основу высокопроизводительных вычислительных программно-информационных комплексов (ПИК). С получением Саратовским государственным университетом (СГУ) статуса Национального исследовательского университета (НИУ) количество решаемых задач, требующих высокопроизводительных вычислений, стало возрастать. Так, в работе НИУ стали принимать участие исследователи, не относящиеся к подразделениям СГУ, которым требуется удаленный доступ к ПИК. Именно поэтому актуальность облачных вычислений в СГУ еще более возросла.
            Исследовательский программно-информационный комплекс – это чаще всего ПИК инженерных расчетов (CAE-система) с проприетарным (proprietary) или свободно распространяемым (open source) программным обеспечением. Широкое применение в СГУ нашли ПИК, использующие приближенные численные методы и реализованные с помощью многоядерных пакетов конечно-элементного моделирования Elmer 6.0 и ANSYS v12. В основе этих пакетов лежит метод конечных элементов (МКЭ), для применения которого необходима адекватная трехмерная геометрическая модель, покрытая расчетной сеткой и «решатель», специально адаптированный для исследуемой области и работы в с применением облачных технологий.

            При работе с ПИК данные для проведения исследований обычно готовятся на клиентском рабочем месте (на рабочем месте исследователя). Для этого исходные данные («сырые» научные данные, полученные в ходе экспериментов) загружаются с серверов, экспериментальных установок, или с сервера баз данных и на этой основе готовится трехмерная геометрическая модель с использованием распространенных средств трехмерного моделирования (например, Salome Version 5.1.3). На созданную таким образом 3D модель в программе трехмерного моделирования накладывается расчетная сетка, и модель с наложенной расчетной сеткой передается на сервер высокопроизводительных вычислений для моделирования и визуализации результатов. Высокопроизводительные вычисления можно реализовать не только на университетском кластере, но и используя облачные технологии. Таким образом, во взаимодействии программ, входящих в ПИК, могут участвовать хранилища «сырых» научных данных, клиентское рабочее место исследователя и «облачные» сервисы.

                    Благодаря технологиям виртуализации серверы, доступные в сетях университета или Internet (облачные сервисы), могут объединяться в вычислительные кластеры с практически неограниченной производительностью, что и требуется исследователю для создания ПИК. Помимо высокой производительности и надежности, такой ПИК позволяет оптимизировать нагрузку на каждый сервер, следовательно, значительно снижать стоимость исследований. Низкая стоимость, высокая производительность и надежность, а также передача на аутсорсинг IT-специалистам университета поддержки кластерной инфраструктуры и научного программного обеспечения ПИК обеспечивают успех применения следующих облачных технологий в научных исследованиях:

• SaaS (Software as a Service), где научное прикладное программное обеспечение, поставляется в качестве Internet-сервисов. Однако существует опасность передачи научных данных для обработки их в «чужом» облаке.
•  IaaS (Infrastructure as a Service), облачные платформы, на которых можно арендовать «голые» Windows-Linux серверы с масштабируемой мощностью (Amazon Web Services, Rackspace Cloud) для последующего создания на их основе ПИК.
•  PaaS (Platform as a Service), облачные платформы со всем необходимым промежуточным и научным программным обеспечением (СУБД, фреймворки, сервисы Windows Azure, Force.com) для создания ПИК.

            Исследователи могут сами создавать ПИК в университетской сети или Internet, используя преимущества Cloud Computing, но некоторые из них опасаются размещать свою IT-инфраструктуру на чужих серверах. Для таких исследователей предлагаются «приватные облака» (Private Cloud). Исследователь использует защищенные облачные платформы с «голыми» ядрами и с помощью технологий виртуализации объединяет их в «приватные облака», куда легко переносится IT-инфраструктура ПИК. Таким образом, весь процесс создания ПИК на основе Linux-серверов можно представить следующими шагами:

• Выбрать нужный сервер на ресурсах Cloud-провайдера, используя Web-интерфейс или командную строку. Если выбирается и запускается сразу несколько серверов (кластер), то можно воспользоваться средствами API.
•  Запустить выбранные Linux-серверы, получить к ним SSH-доступ и связать их в кластер. Настроить кластер серверов, установить операционную систему (ОС) и требуемые пакеты, собрав их из исходных кодов и создав конфигурационные файлы. Настроить систему безопасности «приватного облака».
•  В «приватном облаке» (кластере серверов) создать ПИК, установив многоядерные пакеты конечноэлементного моделирования Elmer 6.0. Причем сделать это нужно максимально быстро, так как Cloud-провайдер требует за это высокую повременную оплату. Решить это поможет технология Opscode Chef [1].

            Облачные провайдеры (Amazon ЕС2, GoGrid, Rackspace) предоставляют возможность загрузки облачных платформ (виртуальных машин) в их центрах данных и получения удаленного доступа с почасовой оплатой стоимостью порядка трех рублей в час. Исследователь сам выбирает необходимую для его экспериментов аппаратную платформу и операционную систему, получает к ней доступ посредством протоколов RDP (Windows) или SSH (Linux) и тем самым создает ПИК. Далее он работает с ПИК так, как будто бы он реализован на его серверах. А именно, настраивает ОС, устанавливает необходимое научное ПО, обрабатывает результаты экспериментов и т.д.

            Методы управления серверной облачной инфраструктурой

 

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

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

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

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

• Он должен прекращать свою работу с отображением ошибки, в случае неправильного выполнения очередной инструкции. В качестве примера можно привести отсутствие конгруэнтности при исполь- зовании скриптового языка командной оболочки bash ОС Linux. Если инструкция, сd /storage/sources/r m – f r будет выполнена с недостаточными привилегиями для смены каталога, то результат будет следующим: cd /storage/sources/cd: permission denied:/storage/sources/rm -fr. Сообщение об ошибке может быть различным для разных ОС Linux, однако результат всегда одинаков: вместо удаления содержимого в каталоге /storage/sources/, будет удалено содержимое текущего каталога.
• Он должен вносить изменения в вычислительную систему в одном и том же порядке.
• Он должен иметь для большинства стандартных действий (создание каталога пользователя, работа с сервисами и т.д.) специализированные ресурсы, облегчающие работу администраторов и абстрагированные от конкретной ОС.
• Все специализированные ресурсы, используемые инструментом управления, должны быть идемпотентными и безошибочно многократно развертывать научное ПО [3]. Идемпотентность здесь понимается как свойство вычислительной системы, проявляющееся в том, что повторные действия над ней не изменяют её.

       С точки зрения программного кода научное ПО ничем не отличается от системного или какого-либо другого программного обеспечения. Поэтому методы управления серверной облачной инфраструктурой при автоматизированной установке ПО в равной мере применимы для любого вида программного обеспечения.

        

        Облачные технологии создания исследовательской IT-инфраструктуры 

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

        Фреймворк Chef состоит из клиента и сервера. Клиент поддерживает Ohai-сервис – сборщик информации о выбранном облачном сервере (IP-адрес, процессор, оперативная память, запущенные процессы, и множество другой информации). Эта информация передается на Chef-сервер, который постоянно «слушает» порт клиента и ждет от него входящих подключений. Сервер содержит базу данных, где хранятся данные о клиентах, поисковый движок, опциональный Web-интерфейс, и поваренную книгу – сборник файлов, рецептов, метаданных.

      Сервер работает с ресурсами Chef, а ресурсы используют провайдеры – конкретные классы, которые реализуют необходимые действия на сервере. Провайдеры выбираются Chef-сервером автоматически и зависят от установленной ОС. Таким образом, свободно распространяемый (open source) продукт Opscode Chef является специализированным фреймворком по настройке и управлению серверами. Программы установки и настройки (скрипты) создаются на языке Ruby DSL и являются рецептами Chef. Они абстрагированы от конкретной ОС и предоставляют специальные ресурсы, позволяющие работать с облачной инфраструктурой. Например, чтобы установить tar - пакет в ОС Linux в рецепте достаточно написать:

package "tar".

        Для запуска сервиса tomcat6:

service "tomcat6" d o / action :start / end.

        При выполнении кода запуска сервиса tomcat6, Chef сначала проверяет, не запущен ли уже этот сервис. Если сервис остановлен, Chef выполнит команду по его запуску, причем в зависимости от ОС команда может быть различной. Таким образом, фреймворк позволяет системному администратору создавать скрипты автоматизированной установки ПО, не привязываясь к конкретному дистрибутиву ОС. Однако может возникнуть необходимость выполнить различные действия с сервером в зависимости от ОС. Например, пакет Web сервера Apache в ОС RedHat называется httpd, а в ОС Ubuntu apache2. В этом случае рецепт может использовать условное ветвление:

package "apache2" d o

case node [:platform]

when "centos","

redhat","fedora","suse"

package_name "httpd"

when "debian","ubuntu"

package_name "apache2"

e n d

action : install

e n d .

        Ресурсы в Chef обеспечивают идемпотентность, но специальные проверки на полную идемпотентность отсутствуют. Так, например, следующий ресурс Chef не является идемпотентным:

bash "iptables startup" d o

user "root"

code <<-E0H

echo ". /etc/iptables.sh" >>/etc/rс.d/rc.local

E0H

end.

        В таких случаях администратор должен самостоятельно отслеживать идемпотентность и не допускать подобных ситуаций. В настоящее время в Chef доступны 24 ресурса, включая выше приведенные package и service, облегчающие конфигурирование вычислительной системы и установку нового ПО. Между ресурсами Chef возможна передача сообщений, что облегчает создание исследовательской IT-инфраструктуры. Например, в процессе выполнения рецепта нужно будет изменить конфигурационный файл Web-сервера. Для того чтобы изменения вступили в силу, необходим перезапуск соответствующего сервиса, однако иногда сервис перезапускать нежелательно (к примеру, он кем-то используется). В Chef это можно выполнить следующим образом:

template "/etc/www/configuresapache.

conf" d o

notifies :restart, "service[apache]"

e n d

service "apache".

      Здесь специальная инструкция notifies отправляет ресурсу service "apache" сообщение с действием, подлежащим выполнению.

        Все необходимые файлы для установки и конфигурирования конкретного научного ПО помещаются в единую структуру каталогов и такая структура называется поваренной книгой (Cookbook). Типичное содержание каталога Cookbook для установки Web- сервера Apache Tomcat имеет следующий вид:

| - - README.rdoc

| - - attributes

| '-- default.rb

| - - definitions

| '-- tomcat_app.rb

| - - files

| | -- centos

| | '-- rightscale.repo

| '-- default

| | - - JVM-MANAGEMENTMIB.

mib

| | - - dtomcat6

| | - - logging.properties

| | - - tomcat6

| - - libraries

| | -- tomcat.rb

| '-- tomcat_manager.rb

| - - metadata.json

| - - metadata.rb

| - - recipes

| '-- default.rb

'- - templates

'- - d e f a u l t

| -- m a n a g e r . x m l . e r b

| -- t o m c a t -

u s e r s . x m l . e r b

| -- tomcat6. c o n f . e r b

        Имя корневого каталога, содержащего все эти файлы, и является именем поваренной книги для приложения. Кроме рецептов, Chef оперирует такими понятиями как атрибуты (attributes/), определения (definitions/), файлы (files/), библиотеки (libraries/) и шаблоны (templates/). Атрибуты в Chef можно рассматривать как некие глобальные переменные во всей инфраструктуре, находящейся под управлением Chef-сервера. Обычно атрибуты содержат такие данные как IP адреса серверов кластера, информацию об ОС, установленном ПО, и т.д. При запуске Chef атрибуты формирует клиент и отправляет их на сервер, где они индексируются и становятся доступными для поиска. Это позволяет во время выполнения рецепта получить информацию о других серверах под управлением Chef ( например, на каких еще серверах этот рецепт выполняется или будет выполняться). Определения в Chef позволяют создавать новый ресурс, содержащий объединение других ресурсов. Файлы – это только файлы, требующие записи в вычислительную систему без изменений. Библиотеки содержат средства, позволяющие создать произвольный Ruby-код, расширяющий возможности Chef. Например, это может быть библиотека для сбора данных с LDAP- сервера для дальнейшего использования полученных данных в рецепте. Шаблоны – это файлы со специальными переменными, позволяющими передавать в эти файлы значения подставляемых переменных, и записывать файлы в указанное место ОС. Специальный файл metadata.rb содержит информацию о Cookbook.

        После создания кластера серверов с помощью фреймворка Chef и завершения работы с ним, необходимо его «выключить», выбрав из выпадающего меню у Cloud-провайдера команду «Terminate». Серверы не исчезнут мгновенно из списка запущенных, а перейдут в выключенное состояние «shutting-down» и отобразится их статус «terminated». В этом состоянии начисление денежных средств не происходит, а серверы становятся недоступным. В дальнейшем для установки и настройки конкретных научных приложений (создания ПИК) серверы нужно опять активировать. Исследователь может установить нужное ему ПО и продолжить работу с ПИК.

        

            Установка и настройка научных приложений

        Необходимый порядок действий при установке научного ПО на кластере с ОС Linux и использованием фреймворка Chef рассмотрим на конкретном примере моделирования живых систем с применением пакета конечно-элементного моделирования Elmer 6.0. При этом выделим общие вопросы инсталляции научных приложений в облачной инфраструктуре.

        Во-первых, необходимы дистрибутивные пакеты научного ПО. Если таких пакетов нет, то потребуется сборка их из исходного кода, что, в свою очередь, потребует установленных пакетов компилятора и сборщика. В рассматриваемом примере готовый пакета Elmer 6.0 отсутствует, так как он собирается на основе оригинальной оптимизированной кластерной редакции конечно-элементного решателя (solver), созданного в Саратовском государственном университете. Благодаря свойству масштабируемости «облачных» вычислений модуль решателя позволяет обрабатывать поступившие при моделировании живых систем данные даже в самом сложном случае не более, чем за несколько десятков секунд. В ПРЦНИТ СГУ для решателя в базовой версии исходного свободно распространяемого кода пакета Elmer 6.0 были доработаны и вновь скомпилированы пакеты MPICH2, GotoBLAS2, BLACS, SCALAPACK, PARMETIS, а также вновь созданы скрипты компиляции и сборки, позволяющие использовать обновленные версии комплекта компиляторов GNU (gcc/g++/gfortran). На основе пакета MUMPS была вновь создана версия решателя, оптимизированная для параллельных вычислений в «облаках».

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

        Обобщая вышеизложенные положения, можно выделить следующие функциональные требования для инструмента управления серверами:

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

   С точки зрения системного программиста, для создания понятного, кроссплатформенного кода необходимо обеспечить следующие требования:

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

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

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

        Таким образом, установленные научные приложения могут работать с другими программными модулями ПИК, некоторые из которых располагаются на рабочем месте исследователя. Так, при моделирова- нии живых систем препроцессор ПИК (на рабочем месте исследователя) может представлять собой стандартную для выполнения конечно-элементного моделирования свободно распространяемую систему геометрического моделирования SALOME с поддержкой генерации трехмерных конечно-элементных сеток на основе свободно распространяемых библиотек, дополненную специально разработанными конвертерами STL-IGES. Программа SALOME здесь выполняет графическую обработку 3D изображения живой системы и создает геометрическую твердотельную модель, которая затем используется для дальнейших вычислений.

        Реализация МКЭ в таком ПИК осуществляется с использованием облачных вычислений. Это позволяет свести уравнения в частных производных, описывающие деформируемое твердое тело (модель живой системы), к системам нелинейных уравнений (достаточно большой размерности) или к системам обыкновенных дифференциальных уравнений (также достаточно большой размерности). Задание свойств моделируемых объектов, значения нагрузок и граничных условий для 3D модели в системе конечно- элементных расчетов Elmer 6.0 выполняется в «облаке» на кластере серверов высокопроизводительных вычислений. На серверах высокопроизводительных вычислений выполняется также подготовка модели для расчета и запуск в «облаке» параллельного расчетного модуля.

    В «облаке» на серверах высокопроизводительных вычислений может выполняться и запуск модуля визуализации результатов моделирования на многопроцессорной системе конечно-элементных расчетов Elmer 6.0. Результаты моделирования затем отображаются системой визуализации ПИК.

        

          Заключение

        В статье представлена практическая реализация автоматизированного процесса установки распределенного научного ПО в облачной инфраструктуре, выполненная на базе фреймворка Chef. Проведенные исследования показали возможность создания систем быстрой установки и управления инфраструктурой кластера серверов, позволяя разворачивать несколько серверов одновременно в облачной инфраструктуре. В случае сбоя по каким-либо причинам, не связанным с ошибкой в работе вычислительной системы, самый простой способ разрешения проблемы – удаление виртуального кластера и попытка создать его в облаке снова. Как показал наш опыт, время создания кластера может варьироваться от 5 минут для простой конфигурации серверов до 10-15 минут для сложной. В выполненной разработке использован фреймворк Chef в качестве основного инструмента управления серверами. Вместе с тем могут быть использованы и другие подобные фреймворки, удовлетворяющие приведенным в статье теоретическим требованиям. В дальнейшем авторами планируется проведение исследования соответствия теоретическим требованиям описанной системы установки на базе Chef. Кроме того, требуются дополнительные исследования установки распределенных приложений со сложными связями.

Резюме

  

    Досліджено можливість автоматизації використання наукового програмного забезпечення в “cloudy infrastructure”. Показано, як реалізувати систему автоматизованого впровадження з використанням спеціалізованого фреймворка Chef. Описано програмно-інформаційний комплекс, який забезпечує впровадження високопродуктивного обчислювального кластера в “cloudy infrastructure”. В якості приклада наведено пакет кінцево-елементного моделювання Elmer 6.0

     

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

        

        Opportunities of automation of expansion of the scientific software in a cloudy infrastructure are investigated. It is shown how to realize system of the automated expansion with use specialized framework Chef. The program information complex developed by authors providing expansion high-efficiency computing cluster in cloudy infrastructure is described. As example, the automated system of expansion of a package of certainly-element modeling Elmer 6.0 is resulted

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

              Литература

1. Chef. Infrastructure Automation for the Masses.
2. Steve Traugott, Lance Brown Why Order Matters: Turing Equivalence in Automated Systems Administration
3. Idempotence.

        

       Источник: Сборник работ «Інформаційно-кируючі системи на залізничому транспорті»

           

                                               Библиотека