NEUTRONIUM

A PaaS Framework for OpenStack

NEUTRONIUM: A PAAS SERVICES FRAMEWORK

– Goal: An open ecosystem for platform services• Lots of services

• Services interoperate smoothly

• A large and diverse community of service developers/providers

– Anyone can add a new service• Does not require development by cloud provider

• New service is deeply integrated

EXAMPLES OF PAAS SERVICES

– SQL Databases

– NoSQL Databases

– Map/Reduce

– Load Balancers

– Web Servers (for example Tomcat)

– Messaging

– …

DEEPLY INTEGRATED SERVICES

– Deployment

– Management (for example database backup)

– Orchestration (to combine with other service)

– In PaaS web console and other user interfaces

– Integrated billing (optional)

– Monitoring

– Documentation

– …

NEUTRONIUM PAAS LAYER

Swift

Nova

Glance

Keystone

NeutroniumServers

…

IaaSPaaS

Library

Models

User APIs

NeutroniumWeb

Console

Command Line

Java, Ruby, …

Eclipse, …

Mobile

API (REST/JSON)

NEUTRONIUM REST/JSON API

– CRUD (create,read,update,delete)• Library items

• Models

– Instantiate template to produce model

– Management• Start - stop

• Version upgrades

• Scaling

• Backup

• …

– Current status of deployed components

NEUTRONIUM COMPONENTS

– Primitive• Hardware

− Compute (virtual machine)

− Storage (disk)

• Software− Machine images

− Executable code

– Compound• Combine other components

COMPONENT HIERARCHY

– Applications

– Standardized Stacks (for example LAMP)

– Services

– Primitive

COMPONENT TEMPLATES AND MODELS

– Component Template (like a class)• A non-procedural specification • Can be parameterized• Can contain conditionals

– Component Model (like an object)• Represents a currently deployed system

– Instantiation (Template => Model)• Expansion

− Formal parameter references => actual parameter values

− Conditionals evaluated and a single alternative selected

• Deployment− Plan: non-procedural spec => procedural deployment plan

− Bound to specific hardware

− Network bindings to IP and Port

– Templates and Models are both described using JSON syntax

COMPONENT PORTS AND CONNECTIONS

– Each component has a set of typed ports• URL (address of web server)

• Extension point (add servlet to a web server)

• Configuration (modify web server configuration)

– Connections• Connect a port of one component to a port on another components

• Source and destination ports must have compatible types

LIBRARIES

– Libraries provide custom semantics for services (and other components)

– System wide and per user

– Types• Component templates

• Machine images

• Executables

• JAR / WAR

• Script (Chef and other)

• …

– Named via path (/a/b/c)

COMPONENT ASPECT-ORIENTED PROGRAMMING

– Security boundaries

– Monitoring

– Geographic placement (across datacenters)

NEUTRONIUM EXTENSION POINTS(STANDARD INTERFACES)

– New services (via components)

– New user interfaces (via Neutronium REST/JSON Interface)

– New tools (by reading/modifying models)

– New semantics (by adding to libraries)

COMPONENT EXAMPLE

Load Balancer

Jetty

MyApp1(WAR)

MySQL

JettyJetty

MyApp1(WAR)

MyApp1(WAR)

COMPONENT EXAMPLE: JSON TEMPLATE

{"@component"="MyService",

"params"=[

{"@param"="servers", "default"=3},

{"@param"="replicas", "default"=0} ],

"parts"=[

{"@component"="lb", "val"="!/System/Services/LoadBalancer"},

{"@copies"="frontends", "count"="!servers", "val"=

{"@component"="frontend", "visible"=true,

"parts"=[

{"@component"="jetty", "val"="!System/Services/Jetty"},

{"@component"="war", "val"="!MyStuff/Wars/MyApp1"},

{"@connect"="x", "from"="!jetty.servlets", "to"=”!war"},

{"@visible"="serverport", "val"="!frontend.jetty.listener”} ] } },

{"@component"="database", "val"="!/System/Services/MySql",

"replicas"="!replicas"},

{"@connect"="c0", "from"="!lb.load" "to"="!frontends.frontend.serverport"},

{"@connect"="c1", "from"="!frontends.frontend.db", "to"="!database.listener"},

{"@visible"="ServiceEntry", "val"="!lb.listener”} ] }

NEUTRONIUM DISTRIBUTED ARCHITECTURE

– Highly-available, highly-reliable, highly-durable data

– Support multiple data centers

– Same API and capabilities available everywhere

– Partition tolerant, eventual consistency

MULTI-TENANT SERVICES

– A single tenant service is instantiated by deploying it

– A multi-tenant service is instantiated by registering with it

– Multi-tenant example: Swift

– Note that Neutronium itself is multi-tenant.

MULTI-TENANT MANAGEMENT SERVICES

– Example: MySQL database

– Each MySQL service is deployed as a single tenant database running on a new virtual machine

– But all MySQL databases might also share a multi-tenant MySQL management service• Monitoring

• Auto scaling

• Periodic backup

• Failure recovery

• …

– Other services may also have their own management services

© Copyright 2010 Hewlett-Packard Development Company, L.P.    HP CONFIDENTIAL