Nuage Networks Neutron Networking in Private Clouds by Jonas Vermeulen

Copyright 2013 Alcatel-Lucent. All rights reserved. CONFIDENTIAL - SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW

PROPRIETARY – USE PURSUANT TO COMPANY INSTRUCTION Nuage Networks

Jonas Vermeulen EMEA Product Management Nuage Networks

Nuage Networks Neutron Networking in Private Clouds

Similarities with Public Cloud Environment

The owner

Optimizes for low cost (servers, hv, automation,…)

Measures usage and charges

The user

Requires APIs, portals, agility

Wants to be isolated “VPC”

Is constantly comparing offers on the market: internal vs external

Enterprises like the flexibility + cost structure

But need it private – Information Protection, Control, Compliancy,…

Private Cloud – Technically the same ?

Users/Owners also have advanced technical requirements

Per-Tenant Scale

Lots and lots of applications communicating with each other

# subnets being factor higher

Managing Security groups

Supporting “legacy” applications

Integrate with existing Environment

Preserve roles of existing departments

How else to convince business units to use this new cloud??

Case 1 – Per-Tenant Scale The default internet model for Isolated Applications = Amazon VPC

Mostly web apps

Own address space

Floating IP to go outside, with Security Groups as first level of protection

Implementation in OpenStack

Front End

Business logic

Front End

Business logic

Front End

Business logic

Internet

Tenant x Tenant y Tenant z

Network Node

Case 1 – Per-Tenant Scale

Enterprise Applications

Lots of them, with lots of Interaction

Applications have connections to a “management” network and to the “internet”/”intranet”

Enterprise network desires

Fully isolate lifecycle phases – dev/QA/…

Isolate individual applications to users

Use unique (IPv4) addressing

Have up to 10.000+ VMs / 1000+ subnets behind a distributed router

Management

Internet/Intranet

Dev

QA

Prod


Solution A: Applications isolated with tenants + External networks (FIP) for inter-app

(-) Meaning of a Floating IP in a private context?

(-) Floating IPs are routed through the Network

IceHouse / Juno (L3 Fabric) – via NN

(-) Multiple Floating IP subnets

Solution B: Applications isolated with tenants + Shared networks

Routing across shared networks in a separate customized tenant router

(-) Shared Networks visible/accessible to all tenants

(-) Scale across 10.000+ VMs / 1000+ subnets

Business logic Business logic

Ext Router

Network Node

Shared

Tenant x Tenant y


With Nuage Networks: Applications isolated with tenants

Networks are mapped to tenants of choice

Routing in distributed fashion within a lifecycle domain

Exit points via dynamic or static routing

Business logic Business logic

Distr. RouterForDev Mapping

Shared

Public

Tenant x Tenant y


Enterprise requirements for enforcing Security

1. vPort Oriented – AWS Equivalent (eg. Windows <-> AD ; Web <-> App)

Possible Today: using Security Groups

Scale of 10K x 10K VMs

vPort x vPort = vPort2 x (Calculations + Messages + …)

2. Tenant/Network/Subnet Oriented (Project 1 <-> Project 2, Subnet 1 <-> Subnet 2)

Enterprises are looking for more advanced solutions

Case 2 – Supporting legacy applications

Apps running only on VMWare

Multicast applications

Voice / Storage applications

QoS : Trust / Override

Rate-Limits

Local breakout to proxy

Sending /Receiving L3 Multicast (eg Video)

Combining fabric + overlay

Hypervisor

Hypervisor

Hypervisor

SrvGroup1 - ESXi

Hypervisor

Hypervisor

Hypervisor

DC1

SrvGroup2 - KVM

Case 3 – Integration in existing environments Enterprises rely heavily on Existing DHCP / DNS

installations

IP@ Allocation by IPAM, DHCP relay in fabric

Immediate DNS registration

DHCP

IP Fabric

DNS

IP Fabric

Case 3 – Integration in existing environments

OpenStack

Neutron

HV VM

Tenant1 Br-int

VM

NIC

Tenant2

VM

Br-tun Neutron

DHCP Agent (Tenant 2)

Current

DHCP / DNS with OpenStack

IP@ Allocation by Neutron

DHCP -> dnsmasq at network node

DNS -> OpenStack Designate ?

Enterprises rely heavily on Existing DHCP / DNS installations



IP Fabric


OpenStack

DHCP Neutron

HV VM

Tenant1 Br-int

VM

NIC

DNS

Tenant2

VM

Br-tun Neutron

DHCP Agent (Tenant 2)

Current








IP Fabric


OpenStack

DHCP Neutron

HV VM

Tenant1 Br-int

VM

NIC

DNS

Tenant2

VM

Br-tun Neutron L3 Agent

(Tenant 2)

3. DHCP Relay

1. Subnet Sync 2. IP@ Alloc

DHCP Relay






IP@ Allocation by IPAM

DHCP/DNS by IPAM, with relay in fabric

IP Fabric


OpenStack

DHCP Neutron

HV VM

Tenant1 Br-int

VM DHCP Relay

NIC

DNS

Tenant2

VM

Br-tun Neutron L3 Agent

(Tenant 2)

3. DHCP Relay

1. Subnet Sync 2. IP@ Alloc






IP@ Allocation by IPAM

DHCP/DNS by IPAM, with relay in fabric

Case 4 – Roles of existing departments

Cloud = “Fast, Fast, Fast…” (BMW OpenStack Summit – 2/11)

However…

Enterprise change process prevents agility, speed

Separation of responsibilities across operational teams

Apps – deploying on provided infrastructure

Network – Allocating subnet ranges

Security – Users + ACLs

Compute – Infrastructure

…

Apps

Security

Compute

Network

Go for evolution or revolution ?


Today in OpenStack:

Create member roles in keystone

Edit /etc/<project>/policy.json to restrict actions

Assign members to roles

Remains a chain of activities = status-quo


Today in OpenStack:

Create member roles in keystone

Edit /etc/<project>/policy.json to restrict actions

Assign members to roles

What has been done in Nuage :

Templated design

Includes/excludes subnet allocations

Includes/excludes ACL/QoS policies

Pre-approved , Design-once/Deploy-multiple times

Permission model to match organization structure

Remains a chain of activities = status-quo

THANK YOU Let’s work together to address Advanced Private Cloud needs !

Technology

Nuage Networks Neutron Networking in Private Clouds by Jonas Vermeulen