nuage networks neutron networking in private clouds by jonas vermeulen
DESCRIPTION
Nuage Networks Neutron Networking in Private Clouds by Jonas Vermeulen EMEA Product Management Nuage NetworksTRANSCRIPT
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
Case 1 – Per-Tenant Scale
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
Case 1 – Per-Tenant Scale
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
Case 1 – Per-Tenant Scale
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@ Allocation by IPAM, DHCP relay in fabric
Immediate DNS registration
IP Fabric
Case 3 – Integration in existing environments
OpenStack
DHCP Neutron
HV VM
Tenant1 Br-int
VM
NIC
DNS
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@ Allocation by IPAM, DHCP relay in fabric
Immediate DNS registration
IP Fabric
Case 3 – Integration in existing environments
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
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@ Allocation by IPAM
DHCP/DNS by IPAM, with relay in fabric
IP Fabric
Case 3 – Integration in existing environments
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
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@ 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 ?
Case 4 – Roles of existing departments
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
Case 4 – Roles of existing departments
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 !