Building managedprivatecloud kvh_vancouversummit

Copyright 2015 © by KVH Co., Ltd. All Rights Reserved

Building Managed Private Cloud for Enterprises with OpenStack and Midonet

Matsuno Tatsuya <[email protected]>

Cloud and IT Managed Service Strategy at KVH

www.kvhasia.com


2

Agenda

• Introduction

• Definition of Enterprise and Managed Private Cloud

• Challenges in OpenStack based Private Cloud

• Our approach

• Validation for OpenStack and Midonet

• Customer voice, additional requirements

• Wrap up


3

KVH was founded in

1999 by Fidelity Group

as an IT/network

service provider in

Japan

About KVH

Company Name: KVH Co., Ltd.

Established: April 1999

Ownership: Colt Group S.A. (London Stock Exchange: COLT)

President and CEO: Edward Higase

Employees: 500 +

Customers: 2,200 +

Launched data center services

Launched IT managed services

Launched cloud services

Expanded Regionally in Asia

Launched metro fiber data network

services

Lines of Business

• Networks

• Data Centers

• IT management

• Voice services

1999 2002 2004 2010

2012 2014~

Expanded Pan-Europe / Pan-Asian with Colt

Acquired by Colt Group

(related company

transaction) in December

2014 to be Colt’s service

platform for Asia


4

KVH Is An Information Delivery Platform

2

3

3 1

1

2

3

1

KVH has a wide service portfolio spanning data centers, networks and IT services

DATA CENTERS

(Colocation, DC Operations)

High-spec DCs located in major Asian cities conform to strict requirements of financial institutions

NETWORKS

(Ethernet, Leased Line, Mngd Networks, Internet, Voice)

Best-in-class, elastic bandwidth connectivity to the cloud/DC ecosystems in Asia

IT SERVICES

(Mngd Infra, Security, Storage, Private Cloud)

Traditional managed services and dedicated cloud environments tailored to unique industry needs


5

Definition of Enterprises and Managed Private Cloud

• Difference between Tech-savvy companies and Enterprises

• Tech Savvy company: Capability from home grown tools (D.I.Y), many full-stackers

• Enterprise: Limited engineering resources, Need Turn-key solution

• Enterprises in Japan

• Require higher level of: Reliability, Recovery time, Accountability

• Quality is primary ,followed by cost, function or agility…

• Enterprise’s challenges today

• New competitors from different categories

• Cost pressure, CAPX and OPEX reduction

• Focus on their main business rather than infrastructure management

• Time to the market

• Virtualization and public cloud are default choice

• Don’t have enough engineering resources to enjoy OSS capabilities

• Predictable cost for computing

• Need data sovereignty for risk management


6

Definition of Enterprise and Managed Private Cloud

• Managed Private Cloud Check List:

Enterprise Requirements Managed Private

Cloud

OPEX Based Billing

Dedicated Hardware

Data Sovereignty

Predictable Cost

Optimized Reliability

Future Scalability

Controllable Environment

Operations with SLA

KVH choose OpenStack!


7

Challenges with OpenStack based Private Cloud

• Capacity planning and design before deployment

• Performance validation after deployment

• Providing SLA & 24x7 engineering support

• Root Cause Analysis, Tier3 contact for technical deep-dive

• Network reliability and scalability for future expansion

• Controller high availability


8

Our Choice

• Midonet and Mirantis for Managed Private Cloud with OpenStack

Distributed forwarding engine

Scalable Layer3 and Layer2 Gateway

No Single Point of Failure

Align with Neutron

Controller HA with Open Architecture

Platform Choices (Host OS, Network)

Many deployments and experience

24x7 support with SLA

Mature Provisioning Tool (FUEL)


9

Why Midonet?

Network Assessment

NW Option Summary Service Desk HA Scale Dashboard Conclusion

OVS De-facto Standard Hard to get Tier3 Support

NW Node HA is ?

Need tuning

Horizon

DVR + VRRP is not reliable enough Still improving

Linux Bridge + 802.1q

Many use cases in simple large scale environment

Hard to get Tier3 Support

NW Node HA is ?

Horizon + CLI (VLAN)

Prefixed VLAN design is required Dynamic change with switch configuration is challenging

Neutron + HW Vendor Plugin

Network Vendor Solution Compatible with HW Devices

Horizon

High cost for private cloud Will fit to WAN integration with HW

MidoNet Distributed overlay solution with scalability and high availability

Fully

redundant

Tested

Horizon

Open and robust architecture LBaaS capability Fit to private cloud

* As of May Y2014 (Ice House)


10

Why Mirantis?

Mirantis A B C D E

Controller HA ? ?

?

Automation ? ? ?

No Lock-in

Global Support

English Only

Flexibility

?

Host Linux Choice

Customer Use Cases

?

Support Cost

OpenStack Distribution Assessment * As of May Y2014 (Ice House)


11

Midonet Gateway

Validation for OpenStack with Midonet

Validation Test Environment (All physical no virtual host):

OpenStack Private Cloud

Fabric Switch

Mongo DB

Controller

Compute Node

Storage Switch

Storage Node

Internet External NW Midonet L2 and L3 Gateway Reliability

Failover – Failback

Controller HA & Midonet NSDB Reliability


Ceph Storage Reliability


*photo image


12

Networking: L3 Gateway Load Sharing and Fail Over

OpenStack Region

Compute

Midonet

L3GW

Midonet

L3GW

BGP Peer

Internet

OpenStack Region

Compute

Midonet

L3GW

Midonet

L3GW

BGP Peer

Internet

Failover

Recovery

1) Stop Midonet Agent 2) Stop BGP on Quagga 3) I/F Shutdown 4) Host OS Shutdown

Failure Scenarios

• Result: No service impact for all failure scenarios

Router Router Router Router


13

Networking: L2 Gateway Load Sharing and Fail Over

OpenStack Region

Compute

Midonet

L2GW

Midonet

L2GW

Switch Switch

External Network

OpenStack Region

Compute

Midonet

L2GW

Midonet

L2GW

External Network

Gateway Failure

VLAN100 VLAN200 VLAN100

VLAN200

Switch Switch

1) Stop Midonet Agent 2) I/F Shutdown 3) Host OS Shutdown

• Result: 1sec-5sec downtime during failover and failback processes


14

Controller HA by Mirantis FUEL

https://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html

Controller

https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/how-we-fought-for-openstack-ha

”How We Fought for OpenStack HA” (Openstack Summit Paris)

Controller #1

up down up

Controller #2 Controller #3

Controller #1

up down


up

Controller #1

down up


up

*Mirantis OpenStack 5.1.1 Documentation/Reference Architecture

• Result: No business impact when one controller node down/up


15

Customer’s voice: Challenges when in production

• Start small then scale my cloud without Biz impact

• Release Management, how to upgrade my OpenStack

• Interoperability with appliances / legacy systems

• Monitoring OpenStack resources

• Alert handling operations

• Billing system for their end customers


16

Start small then scale : Compute & Storage

• Within the region and additional region

Option1:

Add new compute nodes

Juno

Option2:

Add new region

Juno

Juno Region A

Juno Region B

Juno

Resource, capacity and release management are easier by “Option2”


17

Start small then scale: Network (Public)

• Public Access Scale out with Midonet L3 Gateway

OpenStack Region

Compute

Midonet

L3GW

Midonet

L3GW

BGP Peer

Internet

scale out

OpenStack Region

Compute

Midonet

L3GW

Midonet

L3GW

BGP Peer

Internet

Midonet

L3GW

Midonet

L3GW

Router Router Router Router


18

Start small then scale : Network (External)

• External Network Access with Midonet Layer2 Gateway

OpenStack Region

Compute

Midonet

L2GW

Midonet

L2GW

External Network

OpenStack Region

Compute

Midonet

L2GW

Midonet

L2GW

External Network

Midonet

L2GW

Midonet

L2GW

VLAN100 VLAN200 VLAN100 VLAN200 VLAN300 VLAN400

Switch Switch Switch Switch

scale out


19

How to upgrade OpenStack

• OpenStack Release Management

Option1: Rolling Upgrade New controller cluster installed, migrate compute nodes

Kilo Juno

Kilo

Controller

Option2, step-1: Add new region Add new region with new version

Option2, step-2: Upgrade after VM migration Upgrade Region A after all VM migration

Juno (Juno) Region A

(kilo) Region B

(Juno) Region A

(kilo) Region B

(kilo) Region A

(kilo) Region B

VM VM


20

Interoperability with Appliance

FW Requirement

LB Requirement

Basic

Advance

Advance Basic

Midonet/vApp

FW Box

LB Box

FW Box

Security Group

Midonet (LBaaS)

Security Group

LB vApp

• Customer still wants to use existing appliance functions

#1

#2 #3


21

OpenStack

Region A Region B

Interoperability with Appliances: option #1

Without Hardware Appliance:

L3 SW (core)

AZ-A

AZ-B

Service A

FW

The Internet

External NW

Midonet

L3GW

Midonet

L2GW

Service B Service C

AZ-A

AZ-B

LBaaS LB

vApp

Sec Group

LBaaS

802.1Q

Sec Group

Sec Group

BGP Peer

GREトンネル

Overlay

FW


22

OpenStack環境

Region A Region B


Firewall BOX and vApp or Midonet LBaaS

L3 Device

AZ-A

AZ-B

Service A

FW

The Internet

Midonet

L3GW

Midonet

L2GW

Service B Service C

FW FW

FW FW

FW FW

Floating IP control by L3 Device

AZ-A

AZ-B

Service C FW Service B FW Service A FW

BGP Peer

802.1Q

LBaaS LB

vApp LBaaS

Overlay

Overlay

External NW

FW


23

OpenStack環境

Region A Region B


FW BOX + LB BOX via L2GW

L3 SW (core)

AZ-A

AZ-B

Service A

FW

The Internet

Midonet

L2GW

Midonet

L2GW

Service B Service C

FW LB

FW FW

FW FW

AZ-A

AZ-B

Service C FW + LB Service B FW + LB Service A FW + LB

FW LB

FW LB

FW FW

802.1Q

802.1Q

GREトンネル

GREトンネル

External NW

FW


24

Wrap up

• Reliable and Proven Network and Controller

• Future release wish list:

• L2 failover – failback control, scale out with active/active

• Easy release management

• Dynamic interoperability with Appliances

• Billing tool, Monitoring, Audit tools and features improvement

• KVH still needs better answers for bespoke customer solutions


25

Thank you!

Building managedprivatecloud kvh_vancouversummit

Technology

Transcript of Building managedprivatecloud kvh_vancouversummit