55
Community Stacker Bret Piatt OpenStack Tutorial IEEE CloudCom 2010 Twitter: @bpiatt

OpenStack Tutorial - SALSAHPCsalsahpc.indiana.edu/.../tutorials/OpenStackTutorialIEEECloudCom.pdf · Mainframe Era 90’s-2000’s Client ... (Servers, Files, Sites, Email) Primary

  • Upload
    dongoc

  • View
    217

  • Download
    0

Embed Size (px)

Citation preview

Community StackerBret Piatt

OpenStack TutorialIEEE CloudCom 2010

Twitter: @bpiatt

70’s – 80’sMainframe Era

90’s-2000’sClient Server Era

2010-beyondCloud Era

[Based on a Gartner Study]

Application Platforms Undergoing A Major Shift

2010 IT budgets aren’t getting cut....but CIOs expect their spend to go further.

#1 Priority is Virtualization#2 is Cloud Computing

Founded in 1998Publicly traded on NYSE: RAX120,000+ customers

$628m revenue in 2009 across two major businessesDedicated Managed HostingCloud Infrastructure & Apps (Servers, Files, Sites, Email)

Primary focus on customer service ("Fanatical Support")

3,000+ employees

9 datacenters in the US, UK and Hong Kong65,000+ physical servers

Overview of Rackspace

Rackspace Cloud: 3 Products with Solid TractionCompute: Cloud Servers

Virtualized, API-accessible servers with root accessWindows & Linux (many distros)Sold by the hour (CPU/RAM/HDD) with persistent storage Launched 2009Based on SlicehostXen & XenServer HVs

Storage: Cloud FilesLaunched 2008 Object file storev2.0 in May 2010

PaaS: Cloud SitesLaunched 2006Formally MossoCode it & Load it: .Net, PHP, Python apps autoscaled

Source: Guy Rosen (http://www.jackofallclouds.com)

Open ReST APIs released July 2009 (Creative Commons License)Included in major API bindings: Libcloud, Simple Cloud, jclouds, σ-cloudSupported by key cloud vendors and SaaS servicesMarketplace: http://tools.rackspacecloud.com

Active Ecosystem on Rackspace APIs

What is OpenStack?Overview of the project

OpenStack: The Mission

"To produce the ubiquitous Open Source cloud computing platform that will meet the needs of public and private cloud providers regardless of size, by being simple to implement and massively

scalable."

OpenStack History

Rackspace Decides to Open Source Cloud Software

March

NASA Open Sources Nebula

Platform

May June July

OpenStack formed b/w Rackspace and

NASA

Inaugural Design Summit in Austin

20102005

Rackspace Cloud

developed

OpenStack History

OpenStack launches with 25+

partners

July

First ‘Austin’ code release with 35+

partners

October November February

First public Design Summit in San

Antonio

Second ‘Bexar’ code release planned

2011

OpenStack Founding Principles

Apache 2.0 license (OSI), open development process

Open design process, 2x year public Design Summits

Publicly available open source code repository

Open community processes documented and transparent

Commitment to drive and adopt open standards

Modular design for deployment flexibility via APIs

Community with Broad Commercial Support

OpenStack Isn't Everything

ConsultantsBusiness Process Automation

Database EngineersOperating System TechniciansSystems Security ProfessionalsNetwork Experts

Servers, Firewalls, Load BalancersOperating SystemsStorageManagement ToolsVirtualization

Data CenterNetworkingPower

Software to provision virtual machines on standard hardware at massive scale

Software to reliably store billions of objects distributed across standard hardware

OpenStack Compute

OpenStack Object Storage

creating open source software to build public and private clouds

OpenStack Release Schedule

Design Summit:April TBA 2011

Cactus: April 15, 2011

Bexar:February 3, 2011

OpenStack Compute ready for enterprise private cloud deployments and mid-size service provider deploymentsEnhanced documentationEasier to install and deploy

Community gathers to plan for next release, likely Fall 2011

OpenStack Compute ready for large service provider scale deploymentsThis is the ‘Rackspace-ready’ release; need to communicate Rackspace support and plans for deployment

Building an OpenStack CloudDatacenter, Hardware, and Process

Business Prerequisites

Technical Prerequisites

Cloud Ready Datacenter Requirements

Bootstrapping Your Physical NodesBootstrapping the Host Machines

Building an OpenStack CloudObject Storage

Zettabyte1,000 Exabytes

1,000,000 PetabytesAll of the data on Earth today(150GB of data per person)

Zettabyte2% OF THE DATA ON EARTH IN 2020

If we stored all of the global data as “an average” enterprise..

..it would take....38.5% of the World GDP!

Data Must Be Stored Efficiently

ITEM MONTHLY FIGURESENTERPRISE AVGERAGE STORAGE COST $1.98 PER GIGABYTEWORLD GDP $5.13 TRILLIONCOST TO STORE A ZETTABYTE $1.98 TRILLION

Object Storage Summary

ReST-based API Data distributed evenly throughout system

Hardware agnostic: standard hardware, RAID not required

Object Storage Key Features

No centraldatabase

Scalable to multiple petabytes, billions of objects

Account/Container/Object structure (not file system, no nesting) plus Replication (N copies of accounts, containers, objects)

System Components

The Ring: Mapping of names to entities (accounts, containers, objects) on disk.

Stores data based on zones, devices, partitions, and replicasWeights can be used to balance the distribution of partitionsUsed by the Proxy Server for many background processes

Proxy Server: Request routing, exposes the public API

Replication: Keep the system consistent, handle failures

Updaters: Process failed or queued updates

Auditors: Verify integrity of objects, containers, and accounts

System Components (Cont.)

Account Server: Handles listing of containers, stores as SQLite DB

Container Server: Handles listing of objects, stores as SQLite DB

Object Server: Blob storage server, metadata kept in xattrs, data in binary format

Recommended to run on XFS

Object location based on hash of name & timestamp

Software Dependencies

Object Storage should work on most Linux platforms with the following software (main build target for Austin release is Ubuntu 10.04):

Python 2.6rsync 3.0

And the following python libraries:Eventlet 0.9.8WebOb 0.9.8SetuptoolsSimplejsonXattrNoseSphinx

Evolution of Object Storage Architecture

Version 1: Central DB (Rackspace Cloud Files 2008)

Version 2: Fully Distributed (OpenStack Object Storage 2010)

Example Small Scale Deployment

5 Zones2 Proxies per 25

Storage Nodes10 GigE to Proxies

1 GigE to Storage Nodes

24 x 2TB Drivesper Storage Node

Public Internet

Load Balancers (SW)

Example Large Scale Deployment -- Many Configs Possible

Example OpenStack Object Storage Hardware

Building an OpenStack CloudCompute

Asynchronous eventually consistent

communication

ReST-based API

Horizontally and massively scalable

Hypervisor agnostic: support for Xen ,XenServer, Hyper-V,

KVM, UML and ESX is coming Hardware agnostic: standard hardware, RAID not required

OpenStack Compute Key Features

API: Receives HTTP requests, converts commands to/from API format, and sends requests to cloud controller

Cloud Controller: Global state of system, talks to LDAP, OpenStack Object Storage, and node/storage workers through a queue

User Manager

ATAoE / iSCSI

Host Machines: workers that spawn instances

Glance: HTTP + OpenStack Object Storage for server imagesOpenStack Compute

System ComponentsAPI Server: Interface module for command and control requests

Designed to be modular to support multiple APIsIn current release: OpenStack API, EC2 Compatibility ModuleApproved blueprint: Open Cloud Computing Interface (OCCI)

Message Queue: Broker to handle interactions between servicesCurrently based on RabbitMQ

Metadata Storage: ORM Layer using SQLAlchemy for datastore abstraction

In current release: MySQLIn development: PostgreSQL

User Manager: Directory service to store user identitiesIn current release: OpenLDAP, FakeLDAP (with Redis)

Scheduler: Determines the placement of a new resource requested via the API

Modular architecture to allow for optimizationBase schedulers included in Austin: Round-robin, Least busy

System Components (Cont.)Compute Worker: Manage compute hosts through commands received on the Message Queue via the API�

Base features: Run, Terminate, Reboot, Attach/Detach Volume, Get Console Output

Network Controller: Manage networking resources on compute hosts through commands received on the Message Queue via the API

Support for multiple network modelsFixed (Static) IP addressesVLAN zones with NAT

Volume Worker: Interact with iSCSI Targets to manage volumes�Base features: Create, Delete, Establish

Image Store: Manage and deploy VM images to host machines

Hypervisor IndependenceCloud applications should be designed and packaged abstracted from the hypervisor, deploy and test for best fit for your workloadManage application definition and workload, not the machine image

Configuration managementAbstract virtual machine definition

Open Virtualization Format

Network ModelsPrivate VMs on Project VLANs or Public VMs on flat networks

Network DetailsSecurity Group: Named collection of network access rules

Access rules specify which incoming network traffic should be delivered to all VM instances in the groupUsers can modify rules for a group at any time

New rules are automatically enforced for all running instances and instances launched from then on

Cloudpipe: Per project VPN tunnel to connect users to the cloudCertificate Authority: Used for Project VPNs and to decrypt bundled imagesCloudpipe Image: Based on Linux with OpenVPN

Server GroupsDual Quad CoreRAID 10 Drives1 GigE Public1 GigE Private1 GigE Management

Public Network

Private Network(intra data center)

Management

Example OpenStack Compute Hardware

(other models possible)

Example innovation: Simcloud

Questions & Answers

Thank You!

Email: [email protected] Piatt

Twitter: @bpiatt

Backup ContentAdditional Information

Project Technical DocumentationOverall: http://wiki.openstack.org Object Storage (Swift): http://swift.openstack.orgCompute (Nova): http://nova.openstack.org

Project General DocumentationHome Page: http://openstack.org Announcements: http://openstack.org/blog

OpenStack Documentation

OpenStack: Core Open PrinciplesOpen Source: All code will be released under the Apache License allowing the community to use it freely.

Open Design: Every 6 months the development community will hold a design summit to gather requirements and write specifications for the upcoming release.

Open Development: We will maintain a publicly available source code repository through the entire development process. This will be hosted on Launchpad, the same community used by 100s of projects including the Ubuntu Linux distribution.

Open Community: Our core goal is to produce a healthy, vibrant development and user community. Most decisions will be made using a lazy consensus model. All processes will be documented, open and transparent.

Backup ContentBootstrapping a cloud

Hardware Selection

OpenStack is designed to run on industry standard hardware, with flexible configurations

Computex86 Server (Hardware Virt. recommended)Storage flexible (Local, SAN, NAS)

Object Storagex86 Server (other architectures possible)Do not deploy with RAID (can use controller for cache)

Server Vendor Support

Find out how much configuration your hardware vendor can provide

Basic needsBIOS settings

Network bootIP on IPMI card

Advanced supportHost OS installation

Still get management network IP via DHCP

Network Device Configuration

Build in a manner that requires minimal changeLay out addressing in a block based modelGo to L3 from the top of rack uplink

Keep configuration simpleMore bandwidth is better than advanced QoSLet the compute host machines create logical zones

Host Networking

DHCP for the management network Infinite leasesBase DNS on IP

Ex. nh-pod-a-10-241-61-8.example.orgOpenStack Compute handles IP provisioning for all guest instances – Cloud deployment tools only need to setup management IPs

Host OS Seed Installation

BOOTP / TFTP – Simple to configureSecurity must be handled outside of TFTPHost node must be able to reach management system via broadcast request

Top of rack router can be configured to forwardGPXE

Not all hardware supportsBetter concurrent install capability than TFTP

Host OS Installation

Building a configuration based on a scripted installation is better than a monolithic “golden image”

Preseed for Ubuntu / Debian hostsKickstart for Fedora / CentOS / RHEL hostsYaST for SUSE / SLES hostsRemote bootstrapping for XenServer / Hyper-V hosts

Scripted configuration allows for incremental updates with less effort

Post OS Configuration

Utilize a configuration management solutionPuppet / Chef / Cfengine

Create roles to scale out controller infrastructureQueueDatabaseController

Automate registration of new host machinesBase the configuration to run on management net IP

Backup ContentCompute

Component Architecture Detail