Red Hat Enterprise Linux OpenStack Platform 6 Component Overview

OpenStack Documentat ion TeamRed Hat

Red Hat Enterprise Linux OpenStackPlatform 6Component Overview

Understanding OpenStack components, their funct ionality, and theirinterfaces

Red Hat Enterprise Linux OpenStack Plat form 6 Component Overview

Understanding OpenStack components, their funct ionality, and theirinterfaces

OpenStack Documentation TeamRed Hat Customer Content [email protected]

Legal Notice

Copyright © 2015 Red Hat Inc.

The text o f and illustrations in this document are licensed by Red Hat under a CreativeCommons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation o f CC-BY-SA is available athttp://creativecommons.org/licenses/by-sa/3.0 /. In accordance with CC-BY-SA, if you distribute this document or an adaptation o f it, you mustprovide the URL for the original version.

Red Hat, as the licensor o f this document, waives the right to enforce, and agrees not to assert,Section 4d o f CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the InfinityLogo, and RHCE are trademarks o f Red Hat, Inc., registered in the United States and o thercountries.

Linux ® is the registered trademark o f Linus Torvalds in the United States and o ther countries.

Java ® is a registered trademark o f Oracle and/or its affiliates.

XFS ® is a trademark o f Silicon Graphics International Corp. or its subsidiaries in the UnitedStates and/or o ther countries.

MySQL ® is a registered trademark o f MySQL AB in the United States, the European Union andother countries.

Node.js ® is an o fficial trademark o f Joyent. Red Hat Software Collections is not fo rmallyrelated to or endorsed by the o fficial Joyent Node.js open source or commercial pro ject.

The OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/servicemarks or trademarks/service marks o f the OpenStack Foundation, in the United States and o thercountries and are used with the OpenStack Foundation's permission. We are not affiliated with,endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All o ther trademarks are the property o f their respective owners.

AbstractThe overview provides a short introduction to the product and its components, both core andsecondary.

1

Red Hat Ent erprise Linux OpenSt ack Plat form 6 Component Overview

2

PREFACE

PREFACE

3

CHAPTER 1. INTRODUCTION

Red Hat Enterprise Linux OpenStack Platform provides the foundation to build a private orpublic Infrastructure-as-a-Service (IaaS) cloud on top of Red Hat Enterprise Linux. It offers amassively scalable, fault-tolerant platform for the development of cloud-enabled workloads.

The current Red Hat system is based on OpenStack Juno, and packaged so that availablephysical hardware can be turned into a private, public, or hybrid cloud platform including:

Fully distributed object storage

Persistent block-level storage

Virtual-machine provisioning engine and image storage

Authentication and authorization mechanism

Integrated networking

Web browser-based GUI for both users and administration

The Red Hat Enterprise Linux OpenStack Platform IaaS cloud is implemented by a collectionof interacting services that control its computing, storage, and networking resources. Thecloud can be managed using a web-based dashboard or command-line clients, which allowadministrators to control, provision, and automate OpenStack resources. Additionally, theOpenStack has an extensive API, which is also available to end users of the cloud.


4

CHAPTER 2. CORE COMPONENTS

The following diagram provides a high-level overview of the OpenStack core components.

Figure 2.1. OpenStack components

Each OpenStack service has a code name, which is reflected in the names of configurationfiles and command-line utility programs. For example, the Identity service has aconfiguration file called keystone.conf.

Table 2.1. Core services

Service Code Descript ion Locat ion

Dashb o ard Ho rizo n

A web -b ased d ashb o ard fo r manag ingOp enStack services.

Sectio n 2.1,“ Op enStackDashb o ard(ho rizo n)”

Id entity Keysto ne

A centralized Id entity service thatp ro vid es authenticatio n andautho rizatio n fo r o ther services, andmanag es users, tenants, and ro les.

Sectio n 2.2,“ Op enStackId entity(keysto ne)”

Op enStackNetwo rking

Neutro n A netwo rking service that p ro vid esco nnectivity b etween the interfaces o fo ther Op enStack services.

Sectio n 2.3,“ Op enStackNetwo rking(neutro n)”

Blo ckSto rag e

Cind er A service that manag es p ers istent b lo cksto rag e vo lumes fo r virtual machines.

Sectio n 2.4,“ Op enStack Blo ckSto rag e (c ind er)”

CHAPT ER 2 . CORE COMPONENT S

5

Co mp ute No va A service that manag es and p ro vis io nsvirtual machines running o n hyp erviso rno d es.

Sectio n 2.5,“ Op enStackCo mp ute (no va)”

Imag e Glance A reg istry service fo r s to ring reso urcessuch as virtual machine imag es andvo lume snap sho ts.

Sectio n 2.6 ,“ Op enStack Imag e(g lance)”

Ob jectSto rag e

Swift A service p ro vid ing o b ject s to rag ewhich allo ws users to sto re and retrievefi les (arb itrary d ata).

Sectio n 2.7,“ Op enStackOb ject Sto rag e(swift)”

Telemetry

Ceilo meter

A service p ro vid ing measurements o fc lo ud reso urces.

Sectio n 2.8 ,“ Op enStackTelemetry(ceilo meter)”

Orchestratio n

Heat A service p ro vid ing a temp late-b asedo rchestratio n eng ine, which sup p o rtsthe auto matic creatio n o f reso urcestacks.

Sectio n 2.9 ,“ Op enStackOrchestratio n(heat)”


Each OpenStack service is comprised of a collection of Linux services, MariaDB databases,or other components, which together provide a functional group. For example, the glance-api and glance-registry Linux services, together with a MariaDB database, implementthe Image service.

2.1. OPENSTACK DASHBOARD (HORIZON)

The dashboard service provides a graphical user interface for end users and administrators,allowing operations such as creating and launching instances, managing networking, andsetting access controls. Its modular design allows interfacing with other products such asbilling, monitoring, and additional management tools. The service provides three basicdashboards: Project, Admin, and Settings.

Figure 2.2. Pro ject dashboard


6

The identity of the logged-in user determines the dashboards and panels that are visible inthe dashboard.

Table 2.2. Dashboard service components

Component Descript ion

o p enstack-d ashb o ard A Djang o (Pytho n) web ap p licatio n, p ro vid es accessto the d ashb o ard using any web b ro wser.

An Ap ache HTTP server (httpdservice)

Ho sts the ap p licatio n.


7

The following diagram provides an overview of the dashboard architecture, where thedashboard service interacts with the OpenStack Identity service for authentication andauthorization, the session backend for database services, the httpd service for hosting theapplication and all the other OpenStack services for API calls.

Figure 2.3. Dashboard in terfaces

2.2. OPENSTACK IDENTITY (KEYSTONE)

The Identity service authenticates and authorizes OpenStack users; the service is used by allOpenStack components. The service supports multiple forms of authentication includinguser name and password credentials, token-based systems, and AWS-style logins (AmazonWeb Services).

The Identity service also provides a central catalog of services and endpoints running in aparticular OpenStack cloud, which acts as a service directory for other OpenStack systems.OpenStack services use the following endpoints:

adminURL, the URL for the administrative endpoint for the service. Only the Identityservice might use a value here that is different from publicURL; all other services will usethe same value.

internalURL, the URL of an internal-facing endpoint for the service (typically the sameas the publicURL).

publicURL, the URL of the public-facing endpoint for the service.

region, in which the service is located. By default, if a region is not specified, the'RegionOne' location is used.


8

The Identity service uses the following concepts:

Users, which have associated information (such as a name and password). In addition tocustom users, a user must be defined for each cataloged service (for example, the'glance' user for the Image service).

Tenants, which are generally the user's group, project, or organization.

Roles, which determine a user's permissions.

Table 2.3. Ident ity service components


o p enstack-keysto ne Pro vid es the ad ministrative and p ub lic APIs.

Datab ases Fo r each o f the internal services.

2.3. OPENSTACK NETWORKING (NEUTRON)

The OpenStack Networking service handles the creation and management of a virtualnetworking infrastructure in the OpenStack cloud. Elements include networks, subnets, androuters; advanced services such as firewalls or virtual private networks (VPN) can also beused.

OpenStack Networking provides cloud administrators with flexibility in deciding whichindividual services should run on which physical systems. All service daemons can be runon a single physical host for evaluation purposes. Alternatively each service can have itsown physical host or even be replicated across multiple hosts for redundancy.

Because OpenStack Networking is software-defined, it can easily and quickly react tochanging network needs (for example, creating and assigning new IP addresses).Advantages include:

Users can create networks, control traffic, and connect servers and devices to one ormore networks.

OpenStack offers flexible networking models, so that administrators can change thenetworking model to adapt to their volume and tenancy.

IPs can be dedicated or floating; floating IPs allow dynamic traffic rerouting.

A limit of 4094 VLANs (4094 networks) can be used in OpenStack Networking. This translatesto a limit of 16M tunnels in the cloud, and a limit of 4094 tunnels per compute node.


9

Table 2.4 . OpenStack Networking service components


o p enstack-neutro n-server

A Pytho n d aemo n, which manag es user req uests (and exp o ses theAPI). It is co nfig ured with a p lug -in that imp lements the Op enStackNetwo rking API o p eratio ns using a sp ecific set o f netwo rkingmechanisms. A wid e cho ice o f p lug -ins are also availab le. Fo rexamp le, the openvswitch and linuxbridge p lug -ins use nativeLinux netwo rking mechanisms, while o ther p lug -ins interface withexternal d evices o r SDN co ntro llers.

o p enstack-neutro n-ml2

Plug -in manag es netwo rk d rivers, p ro vid ing ro uting and switchingservices (fo r examp le, fo r Op en vSwitch o r Ryu netwo rks).

Netwo rk ag ents Service that runs o n each no d e to p erfo rm lo cal netwo rkingco nfig uratio n fo r the no d e's virtual machines and netwo rking services(fo r examp le, Op en vSwitch).

o p enstack-neutro n-d hcp -ag ent

An ag ent p ro vid ing DHCP services to tenant netwo rks.

Rab b itMQ server(rabbitmq-server)

Pro vid es the AMQP messag e q ueue. Rab b itMQ (also used b y o therservices) hand les the Op enStack transactio n manag ement, inc lud ingq ueuing , d is trib utio n, security, manag ement, c lustering , andfed eratio n. Messag ing b eco mes esp ecially imp o rtant when anOp enStack d ep lo yment is scaled and its services are running o nmultip le machines.

Datab ase Pro vid es p ers istent s to rag e.

The placement of OpenStack Networking services and agents can vary depending onrequirements. The following diagram is an example of a common deployment model, utilizinga dedicated OpenStack Networking node and tenant networks.

Figure 2.4 . Networking example


10

Two Compute nodes run the Open vSwitch (ovs-agent), and one OpenStack Networkingnode performs the network functions: L3 routing, DHCP, NAT, including services such asFWaaS and LBaaS.

The Compute nodes have two physical network cards each, one for tenant traffic, andanother for management connectivity.

The OpenStack Networking node has a third network card specifically for provider traffic.

2.4 . OPENSTACK BLOCK STORAGE (CINDER)

The Block Storage (or volume) service provides persistent block storage management forvirtual hard drives. Block Storage allows the user to create and delete block devices, and tomanage the attachment of block devices to servers. The actual attachment and detachmentof devices is handled through integration with the Compute service. Both regions and zonescan be used to handle distributed block storage hosts.

Block storage is appropriate for performance-sensitive scenarios such as database storage,expandable file systems, or providing a server with access to raw block-level storage.Additionally, snapshots can be taken to either restore data or to create new block storagevolumes (snapshots are dependent upon driver support).

Basic operations include:

Create, list, and delete volumes.

Create, list, and delete snapshots.

Attach and detach volumes to running virtual machines.


11

Table 2.5. Block Storage service components


o p enstack-c ind er-vo lume Carves o ut s to rag e fo r virtual machines o n d emand . The vo lumeservice manag es the interactio n with the b lo ck sto rag e d evices.As req uests co me in fro m the sched uler, the vo lume servicecreates, mo d ifies, and remo ves vo lumes as req uired . A numb ero f d rivers are inc lud ed fo r interactio n with sto rag e p ro vid ers.

o p enstack-c ind er-ap i Resp o nd s to and hand les req uests, and p laces them in themessag e q ueue. When an inco ming req uest is received , the APIservice verifies id entity req uirements are met and translates thereq uest into a messag e d eno ting the req uired b lo ck sto rag eactio ns. The messag e is then sent to the messag e b ro ker fo rp ro cessing b y the o ther Blo ck Sto rag e services.

o p enstack-c ind er-b ackup Pro vid es the ab il i ty to b ack up a Blo ck Sto rag e vo lume to anexternal s to rag e rep o sito ry.

o p enstack-c ind er-sched uler

Assig ns tasks to the q ueue and d etermines the p ro vis io ningvo lume server. The sched uler service read s req uests fro m themessag e q ueue and d etermines o n which b lo ck sto rag e ho st thereq uest must b e actio ned . The sched uler then co mmunicateswith the vo lume service o n the selected ho st to p ro cess thereq uest.

Datab ase Pro vid es state info rmatio n.


Pro vid es the AMQP messag e q ueue. Rab b itMQ (also used b yo ther services) hand les the Op enStack transactio n manag ement,inc lud ing q ueuing , d is trib utio n, security, manag ement,c lustering , and fed eratio n. Messag ing b eco mes esp eciallyimp o rtant when an Op enStack d ep lo yment is scaled and itsservices are running o n multip le machines.

Although the main Block Storage services (volume, scheduler, API) can be co-located in aproduction environment, it is more common to deploy many instances of the volume servicewith one or more instances of the API and scheduler services managing them.

Figure 2.5. Block Storage architecture


12

2.5. OPENSTACK COMPUTE (NOVA)

The Compute service is the heart of the OpenStack cloud by providing virtual machines ondemand. Compute schedules virtual machines to run on a set of nodes by defining driversthat interact with underlying virtualization mechanisms, and exposing the functionality to theother OpenStack components.

Compute interacts with the Identity service for authentication, Image service for images (usedto launch instances), and the dashboard service for the user and administrative interface.Access to images is limited by project and by user; quotas are limited per project (forexample, the number of instances).

Many factors can impact scalability, but Red Hat Enterprise Linux OpenStack Platform isdesigned in such a way that, given enough network bandwidth and compute power, theenvironment horizontally scales without restriction. That is, theoretically, there are no upperlimits to the number of compute nodes or instances which a controller node can manage. Asa practical example for compute capacity, when using one controller node and oneOpenStack Networking node, Red Hat has created:

Over 400 instances / compute.

At least 64 compute nodes with plenty of CPU headroom on the controller (this numbercould have gone higher with additional hardware).

A limit of 4094 VLANs (4094 networks) can be used in OpenStack Networking. This translatesto a limit of 16M tunnels in the cloud, and a limit of 4094 tunnels per compute node.

Table 2.6 . Ways to segregate the cloud


13

Concept Descript ion

Reg io ns Each service catalo g ed in the Id entity service is id entified b y its reg io n,which typ ically rep resents a g eo g rap hical lo catio n, and its end p o int. In ac lo ud with multip le Co mp ute d ep lo yments, reg io ns allo w fo r the d iscretesep aratio n o f services, and are a ro b ust way to share so me infrastructureb etween Co mp ute installatio ns, while allo wing fo r a hig h d eg ree o f failureto lerance.

Cells A c lo ud 's Co mp ute ho sts can b e p artitio ned into g ro up s called cells (tohand le larg e d ep lo yments o r g eo g rap hically sep arate installatio ns). Cellsare co nfig ured in a tree. The to p -level cell ('API cell ' ) runs the nova-apiservice, b ut no nova-compute services. In co ntrast, each child cell runsall o f the o ther typ ical nova-* services fo und in a reg ular installatio n,excep t fo r the nova-api service. Each cell has its o wn messag e q ueueand d atab ase service, and also runs nova-cells, which manag es theco mmunicatio n b etween the API cell and its child cells .

This means that:

A s ing le API server can b e used to co ntro l access to multip le Co mp uteinstallatio ns.

A seco nd level o f sched uling at the cell level is availab le (versus ho stsched uling ), which p ro vid es g reater flexib il i ty o ver the co ntro l o f wherevirtual machines are run.


14

Ho stAg g reg ates andAvailab il i tyZo nes

A s ing le Co mp ute d ep lo yment can b e p artitio ned into lo g ical g ro up s (fo rexamp le, into multip le g ro up s o f ho sts that share co mmo n reso urces l ikesto rag e and netwo rk, o r which have a sp ecial p ro p erty such as trustedco mp uting hard ware).

If the user is :

An ad ministrato r, the g ro up is p resented as a Ho st Ag g reg ate, whichhas assig ned Co mp ute ho sts and asso ciated metad ata. Anag g reg ate's metad ata is co mmo nly used to p ro vid e info rmatio n fo ruse with nova-scheduler (fo r examp le, l imiting sp ecific flavo rs o rimag es to a sub set o f ho sts).

A user, the g ro up is p resented as an Availab il i ty Zo ne. The user canno tview the g ro up 's metad ata, no r which ho sts make up the zo ne.

Ag g reg ates, o r zo nes, can b e used to :

Hand le lo ad b alancing and instance d istrib utio n.

Pro vid e so me fo rm o f p hysical iso latio n and red und ancy fro m o therzo nes (such as b y using a sep arate p o wer sup p ly o r netwo rkeq uip ment).

Id entify a set o f servers that have so me co mmo n attrib ute.

Sep arate o ut d ifferent c lasses o f hard ware.

Concept Descript ion

Table 2.7. Compute service components


o p enstack-no va-ap i Hand les req uests and p ro vid es access to the Co mp ute services(such as b o o ting an instance).

o p enstack-no va-cert Pro vid es the certificate manag er.

o p enstack-no va-co mp ute

Creates and terminates virtual instances. Interacts with the Hyp erviso rto b ring up new instances, and ensures that the state is maintained inthe Co mp ute d atab ase.

o p enstack-no va-co nd ucto r

Pro vid es d atab ase-access sup p o rt fo r Co mp ute no d es (thereb yred ucing security risks).


15

o p enstack-no va-co nso leauth

Hand les co nso le authenticatio n.

o p enstack-no va-netwo rk

Hand les Co mp ute netwo rk traffic (b o th p rivate and p ub lic access).Hand les such tasks as assig ning an IP ad d ress to a new virtualinstance, and imp lementing security g ro up rules.

o p enstack-no va-no vncp ro xy

Pro vid es a VNC p ro xy fo r b ro wsers (enab ling VNC co nso les toaccess virtual machines).

o p enstack-no va-sched uler

Disp atches req uests fo r new virtual machines to the co rrect no d e.


Pro vid es the AMQP messag e q ueue. This server (also used b y Blo ckSto rag e) hand les the Op enStack transactio n manag ement, inc lud ingq ueuing , d is trib utio n, security, manag ement, c lustering , andfed eratio n. Messag ing b eco mes esp ecially imp o rtant when anOp enStack d ep lo yment is scaled and its services are running o nmultip le machines.

l ib virtd The d river fo r the hyp erviso r. Enab les the creatio n o f virtualmachines.

KVM Linuxhyp erviso r

Co mp utes sup p o rts the l ib virt d river, us ing KVM as the hyp erviso r.The hyp erviso r creates virtual machines and enab les their l ivemig ratio n fro m no d e to no d e. No te that Op enStack Bare MetalPro vis io ning (iro nic) is also inc lud ed as a techno lo g y p review in thisrelease, which allo ws the p ro vis io ning o f b are-metal machines (seeSectio n 3.1, “ Op enStack Bare Metal Pro vis io ning (iro nic)” ).

Datab ase Pro vid es b uild -time and run-time infrastructure state.


Figure 2.6 . Compute architecture


16

2.6. OPENSTACK IMAGE (GLANCE)

The Image service acts as a registry for virtual disk images. Users can add new images ortake a snapshot (copy) of an existing server for immediate storage. Snapshots can be usedas back up or as templates for new servers. Registered images can be stored in the ObjectStorage service, as well as in other locations (for example, in simple file systems or externalweb servers).

The following image formats are supported:

raw (unstructured format)

aki/ami/ari (Amazon kernel, ramdisk, or machine image)

iso (archive format for optical discs; for example, CD)

qcow2 (Qemu/KVM, supports Copy on Write)

vhd (Hyper-V, common for virtual machine monitors from VMware, Xen, Microsoft,VirtualBox, and others)

vdi (Qemu/VirtualBox)

vmdk (VMware)


17

Container formats can also be used by the Image service; the format determines the type ofmetadata stored in the image about the actual virtual machine. The following formats aresupported.

bare (no metadata is included)

ovf (OVF format)

aki/ami/ari (Amazon kernel, ramdisk, or machine image)

Table 2.8. Image service components


o p enstack-g lance-ap i Hand les req uests and imag e d elivery (interacts with sto rag eb ack-end s fo r retrieval and sto rag e). Uses the reg istry to retrieveimag e info rmatio n (the reg istry service is never, and sho uldnever b e, accessed d irectly).

o p enstack-g lance-reg istry

Manag es all metad ata asso ciated with each imag e.

Datab ase Sto res imag e metad ata.



2.7. OPENSTACK OBJECT STORAGE (SWIFT)

The Object Storage service provides a storage system for large amounts of data, accessiblethrough HTTP. Static entities such as videos, images, emails, files, or VM images can all bestored. Objects are stored as binaries on the underlying file system (using metadata storedin the file’s extended attributes, xattrs). The service's distributed architecture supportshorizontal scaling; redundancy as failure-proofing is provided through software-based datareplication.

Because the service supports asynchronous eventual consistency replication, it is wellsuited to multiple data-center deployment. Object Storage uses the concept of:

Storage replicas, which are used to maintain the state of objects in the case of outage. Aminimum of three replicas is recommended.


18

Storage zones, which are used to host replicas. Zones ensure that each replica of agiven object can be stored separately. A zone might represent an individual disk drive orarray, a server, all the servers in a rack, or even an entire data center.

Storage regions, which are essentially a group of zones sharing a location. Regions canbe, for example, servers or server farms usually located in the same geographical area.Regions have a separate API endpoint per Object Storage service installation, whichallows for a discrete separation of services.

The Object Storage service relies on other OpenStack services and components. Forexample, the Identity Service (keystone), the rsync daemon, and a load balancer are allrequired.

Table 2.9 . Object storage service components


o p enstack-swift-p ro xy Exp o ses the p ub lic API, p ro vid es authenticatio n, and isresp o nsib le fo r hand ling req uests and ro uting themacco rd ing ly. Ob jects are streamed thro ug h the p ro xy server tothe user (no t sp o o led ).

o p enstack-swift-o b ject Sto res, retrieves, and d eletes o b jects.

o p enstack-swift-acco unt Resp o nsib le fo r l is ting s o f co ntainers, us ing the acco untd atab ase.

o p enstack-swift-co ntainer Hand les l is ting s o f o b jects (what o b jects are in a sp ecificco ntainer), us ing the co ntainer d atab ase.

Ring fi les Co ntain d etails o f all the sto rag e d evices, and are used tod ed uce where a p articular p iece o f d ata is s to red (map s thenames o f s to red entities to their p hysical lo catio n). One fi le iscreated fo r each o b ject, acco unt, and co ntainer server.

Acco unt d atab ase Sto res acco unt d ata.

Co ntainer d atab ase Sto res co ntainer d ata.

ext4 o r XFS fi le system Used fo r o b ject s to rag e.


19

Ho usekeep ingp ro cesses

Rep licatio n, aud iting , and up d ating p ro cesses.


2.8. OPENSTACK TELEMETRY (CEILOMETER)

The Telemetry service provides user-level usage data for OpenStack-based clouds, whichcan be used for customer billing, system monitoring, or alerts. Data can be collected bynotifications sent by existing OpenStack components (for example, usage events emittedfrom Compute) or by polling the infrastructure (for example, libvirt).

Telemetry includes a storage daemon that communicates with authenticated agents througha trusted messaging system, to collect and aggregate data. Additionally, the service uses aplug-in system, which makes it easy to add new monitors. You can deploy the API Server,central agent, data store service, and collector agent on different hosts.

Table 2.10. Telemetry service components


ceilo meter-ag ent-co mp ute

An ag ent that runs o n each Co mp ute no d e to p o ll fo r reso urceuti l izatio n statis tics. Each nova-compute no d e must have a ceilometer-compute ag ent d ep lo yed and running .

ceilo meter-ag ent-central An ag ent that runs o n a central manag ement server to p o ll fo ruti l izatio n statis tics ab o ut reso urces no t tied to instances o rCo mp ute no d es. The ceilometer-central-agent canno tcurrently b e ho rizo ntally scaled , so o nly a s ing le instance o f thisservice sho uld b e running at any g iven mo ment.

ceilo meter-co llecto r An ag ent that runs o n o ne o r mo re central manag ement serversto mo nito r the messag e q ueues. No tificatio n messag es arep ro cessed and turned into Telemetry messag es, and sent b acko ut o n to the messag e b us using the ap p ro p riate to p ic.Telemetry messag es are written to the d ata sto re witho utmo d ificatio n. Yo u can cho o se where to lo cate these ag ents,b ecause all intra-ag ent co mmunicatio n is either b ased o n AMQPo r REST calls to the ceilometer-api service (as is the casefo r the ceilometer-alarm-evaluator service).

ceilo meter-alarm-evaluato r

Alarm service that trig g ers state transitio ns o n alarms..


20

ceilo meter-alarm-no tifier

Alarm service that executes req uired actio ns when alarms aretrig g ered .

ceilo meter-no tificatio n

An ag ent that p ushes metrics to the co llecto r service fro mvario us Op enStack services.

Mo ng o DB d atab ase Fo r co llected usag e d ata fro m co llecto r ag ents. Only theco llecto r ag ents and the API server have access to thed atab ase.

ceilo meter-ap i Runs o n o ne o r mo re central manag ement servers to p ro vid eaccess to d ata in the d atab ase.




2.9. OPENSTACK ORCHESTRATION (HEAT)

The Orchestration service provides a template-based way to create and manage cloudresources such as storage, networking, instances, or applications.

Templates are used to create stacks, which are collections of resources (for exampleinstances, floating IPs, volumes, security groups, or users). The service offers access to allOpenStack core services using a single modular template, with additional orchestrationcapabilities such as auto-scaling and basic high availability.

Features include:

A single template provides access to all underlying service APIs.

Templates are modular (resource oriented).

Templates can be recursively defined, and therefore reusable (nested stacks). This meansthat the cloud infrastructure can be defined and reused in a modular way.

Resource implementation is pluggable, which allows for custom resources.

Autoscaling functionality (automatically adding or removing resources depending uponusage).


21

Basic high availability functionality.

Table 2.11. Orchest rat ion service components


o p enstack-heat A CLI to o l that co mmunicates with the heat-ap i to execute AWSClo ud Fo rmatio n APIs.

o p enstack-heat-ap i An Op enStack-native REST API that p ro cesses API req uests b ysend ing them to the heat-eng ine o ver RPC.

o p enstack-heat-ap i-cfn Pro vid es an AWS-Query API that is co mp atib le with AWSClo ud Fo rmatio n and p ro cesses API req uests b y send ing themto the heat-eng ine o ver RPC.

o p enstack-heat-eng ine Orchestrates the launching o f temp lates and p ro vid e eventsb ack to the API co nsumer.

o p enstack-heat-ap i-c lo ud watch

Pro vid es mo nito ring (metrics co llectio n) fo r the Orchestratio nservice.

o p enstack-heat-cfnto o ls A p ackag e o f help er scrip ts (fo r examp le, c fn-hup , whichhand les up d ates to metad ata and executes custo m ho o ks).


22

CHAPTER 3. MODULE COMPONENTS

Red Hat Enterprise Linux OpenStack Platform includes the following module components.Module components add extra functionality to the IaaS functions offered by OpenStack corecomponents:

Table 3.1. Module services


Bare MetalPro vis io ning

Iro nic

A service that enab les the p ro vis io n o fp hysical machines (b are metal),sup p o rting a variety o f hard ware vend o rs(Techno lo g y Preview).

Sectio n 3.1,“ Op enStack BareMetal Pro vis io ning(iro nic)”

DataPro cessing

Sahara A service that enab les the fast p ro vis io nand easy manag ement o f Had o o p c lusterso n Op enStack.

Sectio n 3.2,“ Op enStack DataPro cessing(sahara)”

Op enStackDatab ase-as-a-Service

Tro ve A service that allo ws users to uti l ize thefeatures o f a relatio nal and no n-relatio nald atab ase eng ines, q uickly and easilywitho ut the b urd en o f hand ling co mp lexad ministrative tasks (Techno lo g y Preview).

Sectio n 3.3,“ Op enStackDatab ase-as-a-Service (tro ve)”

3.1. OPENSTACK BARE METAL PROVISIONING (IRONIC)

OpenStack Bare Metal Provisioning enables the user to provision physical machines (baremetal), supporting a variety of hardware vendors. Bare Metal Provisioning integrates with theCompute service (in the same way that virtual machines are provisioned), and provides asolution for the 'bare-metal-to-tenant' use case. For example, within the OpenStack cloud:

Hadoop clusters can be deployed on bare metal.

Hyperscale and high-performance computing (HPC) clusters can be deployed.

Database hosting for applications sensitive to virtual machines can be used.

The service consists of the Bare Metal Provisioning API, a Conductor, database- andhardware-specific drivers, and leverages common technologies like PXE, IPMI, and DHCP.

For more information about Ironic, see Introduction to Ironic.

CHAPT ER 3. MODULE COMPONENT S

23

http://docs.openstack.org/developer/ironic/deploy/user-guide.html

Important

The Red Hat Enterprise Linux OpenStack Platform 6 release includes OpenStackBare Metal Provisioning as a Technology Preview. For more information on thesupport scope for features marked as Technology Previews, seehttps://access.redhat.com/support/offerings/techpreview/.

3.2. OPENSTACK DATA PROCESSING (SAHARA)

OpenStack Data Processing enables the fast provisioning and easy management ofHadoop clusters on OpenStack. Hadoop is used to store and analyze large amounts ofdata, which is usually unstructured but can be a combination of both complex andstructured data:

Hadoop clusters are groups of servers acting as both storage servers, running theHadoop Distributed File System (HDFS), and compute servers, running Hadoop'sMapReduce (MR) framework. Cluster servers do not necessarily share memory or disks;they usually only share the network that connects them. This means that clusters can beeasily added or removed as needed.

Hadoop enables the fast analysis of its data because computation and storage are co-located, and work is divided across its servers, each of which offers local computationand storage services.

In OpenStack Data Processing:

The Identity service authenticates users and provides user security.

The Compute service provisions cluster VMs.

The Image service stores cluster VMs (each contain its operating system plus Hadoop).

The Object Storage service can be used to store data that is processed by Hadoop jobs.

Templates are used for cluster configuration. Nodes are grouped together using a NodeGroup template; Cluster templates are used to combine Node Groups.

Jobs are used to execute tasks on Hadoop clusters. Job binaries store executable code;data sources store input or output locations as well as any necessary credentials.

Data Processing supports different Hadoop distributions as well as vendor-specificmanagement tools (for example, Apache Ambari). Either the OpenStack dashboard or thecommand-line tool can be used for cluster provision and management.

Table 3.2. Sahara service components


24

https://access.redhat.com/support/offerings/techpreview/


o p enstack-sahara-ap i

API service. Hand les c luster req uests and d ata d elivery.

sahara CLI c lient fo r Sahara tasks. The majo rity o f actio ns that are availab lein the Op enStack d ashb o ard can also b e executed using the CLI(exclud ed is the ab il i ty to scale c lusters up and d o wn).

sahara-d b -manag e CLI c lient fo r d atab ase manag ement

sahara-d ashb o ard Plug in fo r the Op enStack d ashb o ard .

3.3. OPENSTACK DATABASE-AS-A-SERVICE (TROVE)

Openstack Database-as-a-Service (trove) allows users to utilize the features of a relationaland non-relational database engines, quickly and easily without the burden of handlingcomplex administrative tasks. OpenStack Database-as-a-Service supports the following:

Cloud users and database administrators can provision and manage multiple databaseinstances as needed.

High-performance resource isolation while automating complex administrative tasksincluding deployment, configuration, patching, backups, restores, and monitoring.

Table 3.3. Trove service components


tro ve-ap i The tro ve-ap i service p ro vid es a RESTful API that sup p o rts JSON andXML to p ro vis io n and manag e Tro ve instances.

tro ve-taskmanag er

The tro ve-taskmanag er service is resp o nsib le fo r tasks such asp ro vis io ning instances, manag ing the l ifecycle o f instances, andp erfo rming o p eratio ns o n the d atab ase instance.

CHAPT ER 3. MODULE COMPONENT S

25

tro ve-co nd ucto r The tro ve-co nd ucto r service runs o n the ho st. It is resp o nsib le fo rreceiving messag es fro m g uest instances to up d ate info rmatio n o n theho st. Fo r examp le, info rmatio n such as the status o f an instance o r thecurrent s tatus o f a b ackup . With tro ve-co nd ucto r, g uest instances d o no tneed a d irect co nnectio n to the ho st’s d atab ase. The tro ve-co nd ucto rservice l is tens fo r RPC messag es thro ug h the messag e b us and p erfo rmsthe relevant o p eratio n.

tro ve-g uestag ent

The tro ve-g uestag ent service runs within the g uest instance. It isresp o nsib le fo r manag ing and p erfo rming o p eratio ns o n the d atab aseitself. The tro ve-g uestag ent l is tens fo r RPC messag es thro ug h themessag e b us and p erfo rms the req uested o p eratio n.


Important

The Red Hat Enterprise Linux OpenStack Platform 6 release includesOpenStack Database-as-a-Service as a Technology Preview. For moreinformation on the support scope for features marked as Technology Previews,see https://access.redhat.com/support/offerings/techpreview/.

Although OpenStack Database-as-a-Service is available through defaultOpenStack channels, the user must currently install and configure it manually.


26


CHAPTER 4. DEPLOYMENT TOOLS

OpenStack offers a number of deployment tools with which you can deploy an OpenStackenvironment, in addition to being able to manually deploy an environment for learningpurposes.

4.1. RED HAT ENTERPRISE LINUX OPENSTACK PLATFORMINSTALLER

The Red Hat Enterprise Linux OpenStack Platform Installer is a wizard-based tool for theeasy deployment of Red Hat Enterprise Linux OpenStack Platform across a set of hardware.The Installer builds upon the Foreman deployment tool's capabilities and makes enterprise-grade installations much easier.

Figure 4 .1. Installer GUI

The following features are included in the Installer:

Simplified interface, offering a tool that is easier to use than Foreman and more robustthan PackStack.

Enables the orchestration and ordering of complex hardware environments, andsupports multi-node deployment.

Fully automates stage deployments; provides the automatic discovery of hardware,including bare-metal hosts.

Supported modes include:

CHAPT ER 4 . DEPLOYMENT T OOLS

27

Distributed, with either Compute networking (nova-network) or OpenStack Networking(neutron).

Distributed with HA (high availability), with either Compute networking (nova-network) orOpenStack Networking (neutron).

For more information about the Installer, see Deploying OpenStack: Enterprise Environments(Red Hat Enterprise Linux OpenStack Platform Installer)

4.2. PACKSTACK

Packstack is a command-line utility that uses Puppet modules to enable rapid deployment ofOpenStack on existing servers over an SSH connection. Deployment options are providedeither interactively, via the command line, or non-interactively by means of a text filecontaining a set of preconfigured values for OpenStack parameters.

Packstack is suitable for deploying the following types of configurations:

Single-node proof-of-concept installations, where all controller services and your virtualmachines run on a single physical host. This is referred to as an all-in-one install.

Proof-of-concept installations where there is a single controller node and multiplecompute nodes. This is similar to the all-in-one install above, except you may use one ormore additional hardware nodes for running virtual machines.

Important

Packstack is designed for proof-of-concept deployments, and is not suitable as aproduction deployment tool. Packstack makes many assumptions in itsconfiguration to simplify the installation process, and cannot deploy services in ahighly available (HA) or load balanced configuration, nor provide the flexibilityrequired for configuring complex networking.

For more information about Packstack, see Deploying OpenStack: Proof-of-ConceptEnvironments (Packstack).

4.3. OPENSTACK DEPLOYMENT (TRIPLEO)

OpenStack Deployment enables the user to install, upgrade, and operate OpenStack cloudsusing core OpenStack components. OpenStack Deployment includes the following:

A live image installer.

An operator-focused user interface. Additionally, OpenStack Deployment integrates withthe OpenStack dashboard to display metrics (for example, services or capacity).

Manual or automatic hardware discovery.


28

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5

Support for compute, block storage, object storage, and controller roles.

Image and service deployment using the Orchestration, Image, and Bare MetalProvisioning services.

Important

OpenStack Deployment (tripleO) is included as a Technology Preview in Red HatEnterprise Linux OpenStack Platform. For more information on the support scopefor features marked as Technology Previews, seehttps://access.redhat.com/support/offerings/techpreview/.

CHAPT ER 4 . DEPLOYMENT T OOLS

29


APPENDIX A. REVISION HISTORY

Revision 6 .0 - 6 T hu Jun 0 4 2 0 1 5 Radek Biba

BZ#1227721 - Revised a l ink to the sta tem ent regard ing techno logy preview.

Revision 6 .0 - 6 Fri Apr 30 2 0 1 5 Summer Long

BZ#1071070 - Added arch i tecture d iagram for Com pute.

Revision 6 .0 - 5 Fri Mar 1 3 2 0 1 5 Summer Long

BZ#1201130 - Minor ed i ting .

Revision 6 .0 - 4 T hu Feb 5 2 0 1 5 Summer LongRelease for Red Hat Enterpr ise Linux OpenStack P la tform 6.


30

https://bugzilla.redhat.com/show_bug.cgi?id=1227721



Documents

Red Hat Enterprise Linux OpenStack Platform 6 Component Overview