The Beginning: Planning a Production OpenStack Cloud Presented by - - PowerPoint PPT Presentation

the beginning planning a production openstack cloud
SMART_READER_LITE
LIVE PREVIEW

The Beginning: Planning a Production OpenStack Cloud Presented by - - PowerPoint PPT Presentation

The Beginning: Planning a Production OpenStack Cloud Presented by Ben Silverman - Cincinnati Bell Technology Services Monday, May 13, 2019 Before we plan, ask yourself 1. What is my mission with this cloud? 2. Do you have an internal


slide-1
SLIDE 1

The Beginning: Planning a Production OpenStack Cloud

Presented by Ben Silverman - Cincinnati Bell Technology Services Monday, May 13, 2019

slide-2
SLIDE 2

2

  • 1. What is my mission with this cloud?
  • 2. Do you have an internal champion? Do they have

budget?

  • 3. Does OpenStack fit with your corporate culture?
  • 4. Do you have talent in-house to plan, deploy and
  • perate OpenStack?
  • 5. Are you considering a distribution, managed, or a

DIY solution?

  • 6. What will run on this cloud? Will it be built for VM’s,

containers, bare metal or all of the above?

Before we plan, ask yourself…

slide-3
SLIDE 3

3

  • 1. Define what use cases your enterprise needs for your first

production cloud.

  • 2. Identify any technical use cases or specific challenges in the

business use cases.

  • 3. Collect the capacity data of the use cases you want to bring.
  • 4. Determine the size of your cloud and remember, clouds are

elastic, and so is capacity planning.

  • 5. Research the openstack projects you will need to satisfy your

requirements.

  • 6. Determine what OpenStack projects will satisfy this cloud’s

needs and any expansion before the next upgrade.

  • 7. Create your hardware architecture from business and

technical objectives.

  • 8. Create your deployment and execution plans.
  • 9. Run unit tests on all components. Test capacity and high

availability.

Action Plan

slide-4
SLIDE 4

4

Ø Summary: This is simply a detailed summary of the entire document. Typically, this part of the deliverable will be used by managers, technology, and business leaders to understand the business impact of the overall recommendation. Requirements and the resulting architecture should be summarized. Ø Design review: This is the meat of the document. Requirements can be in whatever format is acceptable for your project management

  • team. Some prefer the user story format others simply prefer stated

items. Ø Hardware architecture: This is an explanation of roles and physical machines that take those roles. This should include a network diagram. Ø OpenStack architecture: This is a summary of available services and their relationships. This section should include a service diagram. Ø Roadmap: This section is optional and often lives in another

  • document. It's an opportunity to identify areas for improvement in

future releases of the platform.

The Design Document

slide-5
SLIDE 5

5

Ø Summary: This is simply a detailed summary of the entire document. Typically, this part of the deliverable will be used by managers, technology, and business leaders to understand the business impact of the overall recommendation. Requirements and the resulting cloud deployment plan should be summarized. Ø Deployment: What will be deployed. This section contains detailed information about hardware, software, and networking. Detailed bill

  • f materials for each type of server or network component should

be included as well as a network diagram down to the port level. Physical information is also located in this section. Ø Execution: This section focuses on the responsibilities matrix for the complete cloud build. This will also include testing. Ø Day 2 Operations: This will consist of the operational plans for after the cloud is built including governance, security, high availability, business resumption and disaster recovery.

The Deployment Plan

slide-6
SLIDE 6

6

Business drivers: Why is there a need for change? What are the expected outcomes? What benefit is the organization looking to achieve by implementing an OpenStack cloud? Current state: This section is to be used as a reference and comparison to any proposed cloud

  • design. This data will include the point of departure

architecture, including compute, storage and

  • network. It will also catalog some of the
  • perational data.

Point of Departure

Examples:

  • Company XYZ is finding itself behind competitors in

regard to innovation because it cannot deliver infrastructure to developers quickly.

  • The current virtualization platform ABC enterprises is

running is non-directional and expensive.

  • ElDinero Bank has data that it needs to process quickly

but it cannot leave the datacenter. Scaling takes too long with traditional infrastructure.

  • Joe Telco wants to be able to scale in and out it’s

network functions and run them virtualized.

  • College University has genome sequencing to process

but struggles with setting up the infrastructure for big data.

Component Configuration

Number of regions 1 Total number of nodes 160 Total number of unique users 1 Total number of instances 320 Total number of tenants 1 Block Storage backend VSAN Image backend vCenter Ephemeral storage ESX Object storage N/A Other storage NAS Guest OSes Centos 7

slide-7
SLIDE 7

7

Solution Principles: Specific principles that a solution will have to adhere to regarding capabilities and requirements. Technical Principles/Requirements: Several technical principles that need to be met regarding technical capabilities and requirements.

Point of Arrival

Term Definition Application Deployment Deployment of applications onto infrastructure via a single tool that uses an open API Single-Region Authentication, authorization and access from an integrated solution in the same region Configuration Portability Ability to have a persistent storage mechanism to store configurations for each application in region. Elasticity Ability to scale up and scale down based on increased tenant demand Faster, more reliable IaaS Creating deployment methodology that supports repeatable and reliable deployments of the JBS application in all of its variations. Term Definition Scalability Ability to support up to 320+ Compute nodes in 52 Datacenters (52 clouds) initially. Growing to 450+ total nodes as a roadmap item with a 2-year

  • utlook.

Network Ability to support a private IPv4 tenant network environment in a single cloud. That supports hundreds of Compute nodes. Storage Support persistent and ephemeral storage Upgrade Must be on a commercial OpenStack distribution with a manufacturer documented upgrade path and long-life releases.

slide-8
SLIDE 8

8

Putting It All Together

Define the business challenges we’re trying to solve and outcomes we’re looking to achieve from the LOB owners:

  • Reduce cost
  • Reduce time to market
  • Provide on-demand infrastructure on-premise (like AWS)

Record the technical objectives

  • As a technology leader I want to:
  • Serve up multiple tiers of self-service storage
  • Provide a multi-tenant architecture with network

isolation

  • Leverage commodity hardware for compute

Record any assumptions, capabilities or requirements of the platform:

  • Need a single tier of storage with > 2000 IOPS of read/write

performance per instance

  • Tenants must have network isolation
  • Must be able to deploy applications in a non-shared

compute manner for HA/DR (anti-affinity) Technical Architecture/OpenStack Architecture:

  • Remember to support the business and technical objectives
  • Create a MVP design that supports the most pressing and

important business and technical objectives

  • Keep it simple (KISS)
  • Cost is always a consideration, treat it like your money
slide-9
SLIDE 9

9

Physical Architecture

Architecture Plan Ø Categories of hardware Ø Compute Ø Storage Ø Network Ø Role Categories (OpenStack Architecture Design) Ø Compute Plane Ø Control Plane Ø Should consist of everything needed by an OpenStack Engineer to deploy the cloud

slide-10
SLIDE 10

10

OpenStack Architecture

Most Common OpenStack Architecture Categories Ø Compute Plane Ø Requirements are defined by expected workloads Ø High availability is designed in by horizontal scaling and availability zones Ø Bigger isn’t always better, scale out, not up Ø Control Plane Ø Requirements are driven by the services that will be installed Ø Typically no less than three servers Ø High availability is handled by load balancing and clustering Others can include: Storage Plane, Dedicated Network Plane, Cell Structure, etc.

slide-11
SLIDE 11

11

What is Network Functions Virtualization?

  • Simply put, a new way to define, create, and manage multiple

network functions by replacing dedicated network appliances with software and automation

  • The software that replaces the hardware function is called a Virtual

Network Function (VNF)

  • Useful for mobile gateways and for related functions like MME, SGW,

and PGWs.

  • NFV is not SDN but they can compliment each other.
slide-12
SLIDE 12

12

slide-13
SLIDE 13

13

Special Use Architectures

slide-14
SLIDE 14

14

slide-15
SLIDE 15

15

Lab: Thinking about the future, especially about 5G and edge technologies…

How does OpenStack fit? What are some of the challenges that might arise due to edge use cases?

slide-16
SLIDE 16

16

Developing The Final Deployment Plan

In review: Overview that includes:

  • Business drivers
  • Operational and technical challenges
  • Design principles
  • Technical principles.

Technical Architecture Recommendations

  • Compute, network and storage hardware
  • Rack layouts
  • Wiring and physical network layouts

OpenStack Architecture Recommendations

  • Projects beyond OpenStack core
  • Setting up availability zones and failure domains
  • Logical network layout
  • Security concerns
  • Plug-ins for storage and network
slide-17
SLIDE 17

17

Planning to Operate

Important Considerations: Logging, Monitoring, Alerting:

  • Centralized Logging and Aggregation
  • Intelligent log introspection and analysis
  • AIOps to reduce alert fatigue
  • Integration with existing tools

Other Operations Considerations

  • Governance
  • Security/Compliance
  • Service assurance and Disaster Recovery

Operators

  • Operator Education
  • System Reliability Engineers
  • DevOps Principles
  • Configuration management and upgrades
slide-18
SLIDE 18

Q & A

slide-19
SLIDE 19

Have a great rest of the summit!

THANK YOU!

Email: ben.silverman@cbts.com Twitter: @bensilverm LinkedIn: http://www.linkedin.com/in/benjsilverman

slide-20
SLIDE 20

What is a DevStack?

WHAT IS DevStack? PREREQUISITES CONFIGURATION

WHY USE IT THE COMMUNITY USING OPENSTACK ARCHITECTURE INSTALLING DevStack

  • Opinionated script that simply installs an OpenStack environment
  • Includes frameworks and example tests to run against the platform
  • These same sanity checks are used to check OpenStack during

code tests from OpenStack’s Gerrit, an open source team code collaboration tool.

  • Not intended as a general purpose OpenStack installer
  • Not suitable for production
  • You have been warned. Don’t do it.
slide-21
SLIDE 21

Prerequisites for DevStack

WHAT IS DevStack? PREREQUISITES CONFIGURATION

WHY USE IT THE COMMUNITY USING OPENSTACK ARCHITECTURE INSTALLING DevStack

  • You should have already procured a VM in Virtualbox with Centos

7 loaded.

  • You will need to add the stack user to the Centos system and give

it sudoers permissions. $ sudo useradd -s /bin/bash -d /opt/stack -m stack

  • Since this user will be making many changes to your system, it should

have sudo privileges: $ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack $ sudo su - stack

slide-22
SLIDE 22

Configuring Centos For DevStack

WHY USE IT THE COMMUNITY USING OPENSTACK ARCHITECTURE INSTALLING DevStack

Downloading DevStack Code

$ sudo su - stack $ sudo yum install git –y $ git clone https://git.openstack.org/openstack-dev/devstack $ cd devstack

  • The DevStack directory now contains all of the scripts and templates for configuring and installing

DevStack. WHAT IS DevStack? PREREQUISITES CONFIGURATION

slide-23
SLIDE 23

Configuring DevStack

INSTALL DevStack? PREREQUISITES CONFIGURATION

WHY USE IT THE COMMUNITY USING OPENSTACK ARCHITECTURE INSTALLING DevStack

Configure the deployment

  • In order to seed the installation with some basic information a few

configuration parameters need to be specified in local.conf. The first four are passwords that the installer will use for internal credentials and the HOST_IP is the external IP address of your Linux system you are using as the host. [[local|localrc]] ADMIN_PASSWORD=secret DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD HOST_IP=10.0.3.15

slide-24
SLIDE 24

25

OpenStack Pike Updates

WHAT IT IS WHY USE IT THE COMMUNITY USING OPENSTACK ARCHITECTURE

slide-25
SLIDE 25

DevOps and OpenStack

USING OPENSTACK ARCHITECTURE INSTALLING DevStack OTHER DISTRIBUTIONS DEVOPS

slide-26
SLIDE 26

DevOps and OpenStack

  • OpenStack development has extremely high change velocity
  • OpenStack developers practice DevOps and CI/CD in order to release code. It’s the
  • nly way.
  • The Basics of the CI Pipeline for OpenStack:
  • Code is created and shipped to an integration server (Jenkins) [Go, Travis, etc.]
  • Code is then governed by a review and repository tool (Gerrit) [Cgit, GitHub, etc.]
  • Automated testing is performed (lint checks, rspec-puppet, Tempest, Rally, etc.)
  • Packaging is done (rpmbuild/mock, sbuilder/pbuilder, etc.)
  • Packages are placed in an artifact repository (Artifactory, yum/apt repos, etc.)
  • Deployment jobs are done to test complete pipeline.

USING OPENSTACK ARCHITECTURE INSTALLING DevStack OTHER DISTRIBUTIONS DEVOPS

slide-27
SLIDE 27

OpenStack and Infrastructure as Code

  • Infrastructure as Code = An approach to infrastructure automation based on practices

learned in software development

  • Emphasizes consistent and repeatable routines for provisioning and changing systems

and their configurations.

  • The premise is that modern tooling can treat infrastructure as if it were software and

manipulate it as if it were data.

USING OPENSTACK ARCHITECTURE INSTALLING DevStack OTHER DISTRIBUTIONS DEVOPS

slide-28
SLIDE 28

DevStack Download & Config

Downloading DevStack Code

$ sudo su - stack $ git clone https://git.openstack.org/openstack-dev/DevStack $ cd DevStack

  • The DevStack directory now contains all of the scripts and templates for configuring and installing DevStack.

Configure the deployment

  • In order to seed the installation with some basic information a few configuration parameters need to be specified in

local.conf. The first four are passwords that the installer will use for internal credentials and the HOST_IP is the external IP address of your Linux system you are using as the host. [[local|localrc]] ADMIN_PASSWORD=secret DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD HOST_IP=10.0.3.15

slide-29
SLIDE 29

DevStack Install

Start the installation

$ ./stack.sh

  • The automated installation will start and will run until it is completely finished.

Collect host information at the end of the install

  • You should see something similar to the following at the end of the install:

$ This is your host IP address: 10.0.2.15 $ This is your host IPv6 address: ::1 $ 2017-09-26 18:39:27.058 | stack.sh completed in 1149 seconds.

slide-30
SLIDE 30

DevStack Test

Test the install by listing the hypervisors that are configured:

$ cd DevStack $ . openrc admin

  • This will load the environment variables for the admin account and the command line client.

Display the hypervisors:

$ openstack hypervisor list

+----+---------------------+-----------------+-----------+------- +| ID | Hypervisor Hostname | Hypervisor Type | Host IP | State |+----+---------------------+-----------------+-----------+------- +| 1 | DevStack | QEMU | 10.0.2.15 | up |+----+---------------------+-----------------+-----------+-------

slide-31
SLIDE 31

OpenStack Login and Demo