Future Grid Software Architecture

(1)

Future Grid

Software Architecture

Future Grid

Software Architecture

(2)

What is the FutureGrid?

• _{Provides rich and flexible test-bed}

• _{Enable rigorous scientific experiments in grid}

and cloud computing

• _{Extends existing software as well as new}

software development

• _{Follow standard best practices for}

(3)

Software to support Infrastructure

(4)

Future Grid Users

• _{Application/Scientific}

users

• _{System administrators}

• _{Software developers}

• _{Testbed users}

• _{Performance modelers}

• _Educators

• _Students

• _{Supported by}

• _FutureGrid

• _{Infrastructure}

&

(5)

Impact on Organization

(6)

Impact

• Impact on Software and tools from each committee • Examples:

– _{Hardware - > scripts}

– Training -> convenient tools to conduct training

– Performance -> monitoring tools

– _{User support -> portal, knowledgebase}

• Take existing tools to minimize new developments

– Adapt to our own needs

– Example: use xcat for deployment

• This impact motivated the organization

– _{Role of the software architect is to integrate between the different groups and}

coordinate software related activities

– Role of the software committee is to support the adaptation, reuse and development of software to support the activities of the other committees

(7)

Impact on Organization

(8)

Objectives: Software

• _{significant extensions to existing software} • _{software developed}

• _{existing open-source software}

• _{open-source, integrated suite of software to}

– _{instantiate and execute grid and cloud experiments.} – _{perform an experiment}

– _{collect the results}

– tools for instantiating a test environment,

• Torque, MOAB, xCAT, bcfg, and Pegasus, Inca, ViNE, a number of other tools from our partners and the open source community

• Portal to interact

(9)

Software Architecture

(10)

Tasks for the near term

• _{We have identified a working model for deploying FutureGrid}

• _{We need to put the components together and identify possible}

opportunities to improve these components while providing significant capabilities to the users

• _{We need to work as an integrated team which we have clearly}

demonstrated in the past through multiple collaborations

• _{All of us work on one or the other aspect of software for}

FutureGrid Software Architecture

• _{We will together refine the diagram and develop missing}

components and deploy them with the teams

• _{A spiral software development is used following the program}

(11)

Spiral Development

• _Objectives

• _Risks

• _Development

• _{Plan next step}

• _Iterate

(12)

(13)

Security

• _Objective

– _{Our Hardware and}

network must be secure

– _{Provide single sign on} – _{Make security easy on}

the user

– _{Leverage Teragrid}

security framework

• _Risks

– _{Software is new/novel}

and could have bugs that lead to security

vulnerabilities

(14)

Security

• _Isolation

–

_{Virtual machines}

• _{Single Sign-on}

–

_{Provide the Software services to enable single sign}

on

–

_{Integrate with TeraGrid Single Sign-on}

–

_{Use MyProxy, PKI, …}

–

_{Enable integration of new security frameworks}

(15)

Networking & Security

• _{Global NOC}

– _{SNAPP. High speed data collection and visualization}

– Visible Backbone. An XML Network data collection and analysis tool which presents a system-wide view of the network

– Animated Traffic Map. Geographical view of network usage data

– _{IU Router}_{Proxy. Allows access to a limited set of router commands through a web interface} – _Multicast_{Tools. Custom tools to monitor and debug multicast}

– _{Nagios. Network state monitoring software with custom plugins and user interface} – _{Alertmon. Nagios front-end with links to ticketing and documentation}

– _Syslog_{Scripts. Analysis of syslog entries} – MRTG. Gathers and graphs time series data

– _{Iperf. Network bandwidth measurement tool} – _{OWAMP. One-way latency measurement}

– _Ixia_{IxTraffic. BGP and Netflow analysis and reporting} – _{RANCID. Network device configuration version control}

– _Ganglia_{Cluster Toolkit. Distributed monitoring and execution system} – Arbor Peakflow. Network anomaly detection

(16)

(17)

FG Interfaces

• _Objective

– _{Make access simple} – _{Support various users}

favorite interface

• _Risks

– _{Interface development}

may cost a lot of time

– _{Only partial software}

solution exist,

integration is needed

• _{Provide a}

– _Portal

– _{Command line Interface} – _{API (if feasible)}

(18)

(19)

Future Grid Testbed (Dynamic Provisioning)

(20)

Command line

• _{fg-deploy-image}

– _{host name} – _{image name} – _{start time} – _{end time} – _{label name}

• _fg-add

– _{label name}

– _{framework hadoop} – _{version 1.0}

• _{Deploys an image on a}

host

• _{Adds a feature to a}

(21)

Software Architecture

(22)

FG Stratosphere

• _Objective

– _{Higher than a particular}

cloud

– _{Provides all mechanisms to}

provision a cloud on a given FG hardware

– _{Allows the management of}

reproducible experiments

– _{Allows monitoring of the}

environment and the results

• _Risks

– _{Lots of software}

– _{Possible multiple path to do}

the same thing

• _{Good news}

– _{We worked in a team, know}

about different solutions and have identified a very good plan

– _{We can componentize}

(23)

Runtime Adaptable InsertioN Service

• _Objective

– _{Provide dynamic}

provisioning

– _{Allow bare metal} – _{Cloud neutral}

• _{Nimbus, Eucalyptus, …}

– _{Future oriented}

• Dryad

• …

• _Risks

– _{Multiple pathways exist}

to implement RAIN

– _{Some frameworks (e.g.}

MS are more complex to provision)

(24)

Runtime Adaptable InsertioN Service

• _A:

– _{Use a cloud to do}

provisioning

• _B:

– _{Create image}

– _{Use xcat to provision} – _{Use the provisioned}

environment

• _{C: (not available at time of}

writing the proposal)

– _{Set up specialized queues}

with same image

– _{Submit jobs to the}

appropriate queue

(25)

RAIN: Dynamic Provisioning



Change underlying system to support current user

demands



Linux, Windows, Xen, Nimbus, Eucalyptus



Stateless images



Shorter boot times



Easier to maintain



Stateful installs



Windows



Use moab to trigger changes and xCAT to manage

installs

(26)

(a subset)

Arch Install Type OS Virtualization Frontend

X86_64 stateful Linux

X86_64 stateful Linux Xen

X86_64 stateful Linux Xen Nimbus

X86_64 stateful Linux Xen Eucalyptus

X86_64 stateless Linux

X86_64 stateless Linux Xen

X86_64 stateless Linux Xen Nimbus

(27)

xCAT and Moab



xCAT



uses installation infrastructure to perform installs



creates stateless Linux images



changes the boot configuration of the nodes



remote power control and console (IPMI)



Moab



meta-schedules over resource managers

 _{TORQUE and Windows HPC}



control nodes through xCAT

 _{changing the OS}

 _{remote power control}

(28)

Metascheduler

• _Objective

– _{Provide matching of}

hardware to minimize optimization criteria

– _Utilization

– _{Turnaround time} – _{Carbon emission}

• _Risk

– _{Information is inaccurate} – _{Not all experiments will}

be deterministic and prediction is difficult

– _{Integration of}

provisioning in

(29)

Experiment Manager

• _Objective

– _{Manage the provisioning}

for reproducible experiments

– _{Coordinate workflow of}

experiments

– _{Share workflow and}

experiment images

– _{Minimize space through}

reuse

• _Risk

– _{Images are large}

– _{Users have different}

requirements and need different images

(30)

Monitoring & Performance Engineering

• _Objective

– _{Monitor the state of FG} – _{Support metascheduling} – _{Support users to design}

efficient programs in the testbed that can be run elsewhere

– _{Model the use of}

external resources

• _Risks

– _{Some VM do not expose}

all monitoring

information (due to security)

– _{Monitoring can produce}

lots of data and stress on hardware and

(31)

Software Architecture

(32)

(33)

Timeline: Hardware

08/13/2020 http://futuregrid.org 33