Openstack architecture for the enterprise (Openstack Ireland Meet-up)

OpenStack Architecture for the Enterprise

Keith Tobin Cloud Architect

2 Services OpenStack Architecture for the Enterprise

Speaker Profile

• Dell Cloud Architect

• Located in the Dell Cloud Center of Excellence in Dublin, Ireland

• Over two decades of software, platform and cloud development

• Organizer for OpenStack Ireland

• Loves all things OpenStack and Cloud

Keith Tobin


Forward & Backward Leaning Applications

Forward leaning applications are like cows

Backward leaning applications are like dogs

• They get names like ‘pepper’.

• We care about them, when they get sick the nurse them back to health.

• They get numbers like ‘726’

• When the get sick the are replaced.


Important Question

• What type of workload will my cloud being running? a) Forward leaning. b) Backward leaning. c) Mixed, both forward and backward.


Not all OpenStack deployments are the same

• Openstack is like a kit car. It is a set of building blocks that can be assembles in top a cloud.


Design Goals

• Design an OpenStack architecture to run both enterprise and cloud applications

• Meet enterprise performance expectations for VM’s, networking and storage

• Zero downtime on the control layer

• No data loss in the event of a single node failure

• Must be durable, reliable and highly available

• Must automatically recover after a fault situation has been fixed

• Minimize management tasks


Solution Stack

Percona MySQL

Deployment

Dynamic Load balancer

RabbitMQ Cluster

Storage

Networking Physical Layer

Servers R620 R720 C6100

Crowbar

Force10 SonicWall

RabbitMQ Cluster For HA

SUSE Linux SUSE Linux

Security SecureWorks

Managed Cloud Services

OpenStack OpenStack Titanium

CEPH on R720

Highly Available Dynamic Load Balancing

Tested Solution


Deployment With Crowbar


Deploying OpenStack with Crowbar Is Easy

• Crowbar boots and installs from ISO on a management node (server)

• Provides user with web UI for configuration and operations management

• Discovers all potential targets (servers) automatically

• Performs hardware configuration – BIOS configuration

– Performs updates to BIOS and firmware

• Installs OS on targets

• Deploys OpenStack from a set of configuration modules called barclamps


Crowbar Deployment

Chef Server

Crowbar PXE

DHCP

Identity

Barclamp

Database

Barclamp

Image

Barclamp

Networking

Barclamp

Block storage

Barclamp

Nova

Barclamp

Horizon

Barclamp

Controller

Node 01

Controller

Node 02

Controller

Node 03

Compute

Node 01

Compute

Node 02

Compute

Node 03

OpenStack


Crowbar 2 Status


Network Infrastructure


Redundant Network Infrastructure

Force 10 - Z9000

F10-Z9000

Network

Switch

Existing network fabric

Force 10 - S4810 Force 10 - S4810 Force 10 - S4810 Force 10 - S4810

Compute Node

Compute Node

Compute Node

Compute Node

Compute Node

Compute Node

Compute Node


Load Balancer


Active/Passive (Normal)

Load Balancer 01

(Active)

Load Balancer 02

(Passive)

Keystone etc.

Keystone etc.

Keystone etc.

KeepaliveD KeepaliveD

VIP Server 01 Server 02

VIP

Load Balancer 01

(Inactive)

Load Balancer 02

(Active)

Incoming API

Requests

Incoming API

Requests

Active/Passive (Fault)


Single HAProxy Bottleneck

HAProxy

Horizon

Glance-API

Nova-scheduler

Nova-API

Keystone-API

Neutron-API

Cinder-API

Neutron L2

Neutron L3

Neutron DHCP

Glance-registry

RabbitMQ

MySQL

iVIP eVIP

HAProxy

Horizon

Glance-API

Nova-scheduler

Nova-API

Keystone-API

Neutron-API

Cinder-API

Neutron L2

Neutron L3

Neutron DHCP

Glance-registry

RabbitMQ

MySQL

Server 01

(Active LB)

Server 02

Inactive LB


Dynamic Load Balancing

HAProxy HAProxy

Keystone

Etc….

Keystone

Etc…..

Keystone

Etc……

Quagga Quagga

Server 01 Server 02

HAProxy

Quagga

Server 03

Network

Switch

Network

Switch

OSPF

ECMP

Incoming API Traffic


Neutron


Neutron (Single Networking Node)

Keystone

Glance

MySQL

Etc….

Controller 01

Keystone

Glance

MySQL

Etc….

Controller 02

Nova

Compute 01

Nova

Compute 03

Network 01

OVS Agent

L3 Agent

DHCP Agent

Neutron API

Internet

Nova

Compute 02

Nova

Compute 04


Neutron (Separate Networking Nodes)

Controller 01 Compute 01

OVS Agent

L3 Agent

DHCP Agent

Neutron API

Internet

Controller 02

Neutron API

Ect….

Controller 03

Neutron API

Neutron Scheduler

Neutron Scheduler

Neutron Scheduler

Compute 02

OVS Agent

L3 Agent

DHCP Agent

Compute 03

OVS Agent

L3 Agent

DHCP Agent

Compute 04

OVS Agent

L3 Agent

DHCP Agent

Other OpenStack

Services

Other OpenStack

Services

Other OpenStack

Services

HAProxy HAProxy HAProxy

Quagga Quagga Quagga


RabbitMQ


RabbitMQ Cluster (With Mirrored Queues)

Controller 01

RabbitMQ

Controller 02

RabbitMQ

Ect….

Controller 03

RabbitMQ

Other OpenStack

Services

Other OpenStack

Services

Other OpenStack

Services

HAProxy HAProxy HAProxy

Quagga Quagga Quagga

Dynamic Load Balancer

Physical View Logical View

End Point

RabbitMQ 01 RabbitMQ 02 RabbitMQ 03


MySQL Database

24 Services Openstack Architecture for the Enterprise

MySQL Single Server (Normal Operation)

DB Server

Data

Application


MySQL Single Server (Failed)

DB Server 1

(Active)

Data

Application


MySQL Single Server (Failed)

DB Server 1

(Active)

Data

Application • Disadvantage

• Single point of failure


MySQL Active/Passive Failover


MySQL Active/Passive Failover (Normal Operation)

DB Server 1

(Active)

Data

DB Server 2

(Passive)

Data

Application

Async Replication

DB Server 1

(Failed)

Data

DB Server 2

(Active)

Data

MySQL Active/Passive Failover (Failed Node)

Disadvantages

• Inactive Server

• Limits scale

• Reduces the potential workload processing ability of the solution by half

• Async replication has potential for data inconsistencies across server nodes in fault situations


MySQL With DRDB


MySQL With DRDB (Normal Operation)

DB Server 1

Data

DB Server 2

Data

Application

Event

Event Confirmed

Server Not Available !

Disadvantages

• Inactive server

• Limits scale

• Reduces the potential workload processing ability of the solution by half

(Failed)


MySQL Multi-Master


MySQL Multi-Master Cluster

DB Server 1

Data

Application 01

DB Server 2

Data

DB Server 3

Data

Load balancer

Application 02


MySQL Multi-Master Cluster (Failed Node)

DB Server 1

Data

Application 01

DB Server 2

Data

DB Server 3

Data

Load balancer

Application 02


MySQL Async Replication


MySQL Async Replication

Server 1

Data

Server N

Data

• No guarantee that data will be consistent across all nodes at any point in time


MySQL Single Thread replication

C1 C2 C3 C4

C5 C6 C7 C8

Processor


MySQL Multi-Master Cluster

DB Server 1

Data

Application 01

DB Server 2

Data

DB Server 3

Data

Load balancer

Application 02

Disadvantages

• At any point in time there is no guarantee that data is in a consistent state within the cluster

• One thread allocated for replication tasks


Percona MySQL Cluster


Percona MySQL Cluster

Capability

Synchronous Replication

Data Consistency

Parallel Applying on All Nodes

Atomic Node Provisioning

Multi-Master



Capability


Data Consistency



Multi-Master

Server 1

Data

Server 2

Event

Event Confirmed

Application 01

Data


Data Consistency

Server 1

Data

Server 2

Data

Server 3

Data

Capability


Data Consistency



Multi-Master

At any point in time data is always consistent across all nodes in the cluster



C1 C2 C3 C4

C5 C6 C7 C8

Processor

Capability


Data Consistency



Multi-Master



DB Server 4

Data

Join Cluster

Join Cluster

DB Server 1

Data

DB Server 3

Data

DB Server 2

Data

New Node

Cluster

Capability


Data Consistency



Multi-Master


Multi-Master Cluster

DB Server 1

Data

Application 01

DB Server 2

Data

DB Server 3

Data

Dynamic Load balancer

Application 02

Capability


Data Consistency



Multi-Master


Block Storage


Block Storage

CEPH on R720


Logical Architecture


Thank you….

Keith Tobin Cloud Architect

Technology

Openstack architecture for the enterprise (Openstack Ireland Meet-up)