Skip to end of metadata
Go to start of metadata
This page describes a CI prototype. It provides a high-level "storyboard" describing intent and expected content for a R2I2 prototype. It also describes prototype design, results and open issues.

Prototype Overview

See the Prototyping page for a list of all prototypes.

Subsystem CEI
Type Functional Risk
Priority Medium
Iteration R2I2
Dates Aug 2011
Status completed
Lead Tim Freeman, John Bresnahan
Description Investigate licensing solutions to run Matlab in a cloud (in general we will need to develop and prototype any "quirks" associated with execution engines).
Risks 2317 Cloud Computing Strategy
Results  

Summary

Licensing solutions to run Matlab in a cloud (in general we will need to develop and prototype any "quirks" associated with execution engines).

It appears that one of the Execution Engines we will be dealing with is Matlab – this is a licensed technology and can be run in the clouds but (last time I looked) requires a private network connection to a license server. I would like my team to have it "go through the fingers" at least once before integrating it into the design and understand the issues involved in running this for a larger community, at scale, and on a long-term basis. The outcome of this prototype will be mostly experience and a "small example".

The scope is to basically take matlab, read instructions, set up a VM on EC2 and get it to work with the license server that we will be using -- just to go through the process and have the opportunity to notice what we might potentially have there that might affect anything we'll be doing (e.g., if there are special configuration steps connected to standing up a VM running matlab)

Placement in Release 2 Architecture

The figure below shows the big picture. Matlab should be embedded within one type of execution engine among many to perform real-time data stream processing. It is expected that some Python process in a PyCC deals with the messaging and executes/feeds the Matlab process/processes on one Operation Unit.

The figure below illustrates in more detail the various interacting components of Execution engines in general and for the Matlab case (see lower right). The "Matlab Execution Engine" should in the end be based on an EPU with many Matlab OU instances satisfying the process execution needs. Potentially elastic policy.

See Also

Prototype Goals

  • Find out how Matlab can be "embedded" as an Execution Engine and how to deal with the license acquisition issues
  • Stimulate design discussions of how data stream processing can be architected for R2, with execution engines, process management, resource agents, governance interactions
  • Start thinking towards managing execution resources (VMs, Subscriptions, Licenses, Execution Engines, Processes=Matlab scripts) under the umbrella of a CEI resource management framework
  • Collect any design drawings and meeting notes
  • Provide input for architects to update use cases and architecture specs

Additional Design Elements

Governance

  • Munindar and team have an existing prototype for how to describe and implement the interactions in a distributed system. Concepts are: Matab, license broker, license resource provider etc.

Resource Life Cycle

Comments, Ideas

Might be able to discuss with Munindar's team about working with a Matlab license server as they have done some previous work with this.

Prototype Results

The findings of this prototype work have been documented here: Matlab, Firewalls, and Execution Engines

Labels

r2i2prototype r2i2prototype Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 30, 2011

    Michael Meisinger says:

    Matthew: Opportunity. Use the work that was down what was done at NCSU in terms ...

    Matthew: Opportunity. Use the work that was down what was done at NCSU in terms of the licensing solution for Matlab combined with a federated environment. License providers as resource providers.