architektura+systemu+ opencontrail+ - semihalf · rack,+servers,+vms+ vm vm vm vm hypervisor+ vm vm...
Post on 21-Aug-2020
46 Views
Preview:
TRANSCRIPT
Architektura systemu OpenContrail
Michał Dubiel Kraków 2014
Plan
• Cloud operaBng system – Why?
• Network virtualizaBon – Why it is important – OpenContrail soluBon
• OpenContrail architecture – Goals, assumpBons – FuncBonal parBBoning – Components
CLOUD OPERATING SYSTEM
• Compute power • Storage • Networking
Machines in a datacenter
VM VM VM VM
hypervisor
VM VM VM VM
hypervisor
MIGRATIONS
VM VM VM VM
hypervisor
VM VM VM VM
hypervisor
Storage appliance
OperaBng System analogy
• Resources in a typical server – CPU cores – Memory – Storage – Networking
• Resources in a datacenter – Hardware machines – Storage appliances – Networking equipment
OpenStack
source: openstack.org
Up to now quite missing
source: openstack.org
NETWORK VIRTUALIZATION
• Virtual endpoints dominaBon • SoluBons
Rack, servers, VMs
VM VM VM VM
hypervisor
VM VM VM VM
hypervisor
VM VM VM VM
hypervisor
Server rack
To spine switch
A wider view Clos network
ObservaBons
• Majority of network endpoints are virtual
• Virtual networks dominate
• IsolaBon between them has to be provided
• While using the same physical network
• AutomaBcally
SoluBons
• Vlans – Default OpenStack approach – Limited, not flexible
• Overlay networking – OpenContrail as a Neutron plugin – Flexible – Scalable
VLANs
• VM’s interfaces placed on bridges – Each bridge for a virtual network
• Difficult to manage • 4096 VLAN tags limit – Can be extended using Shortest Path Bridging
• Physical switches have to contain the VN state
VM migraBon example
VM1 VM2
Server 1
VM3
VM4 VM5
Server 2
VM6
VM7 VM8
Server 3
VM9
Physical switch
Virtual networks:
1 2
3
VM migraBon example
VM1 VM2
Server 1
VM3
VM4 VM5
Server 2
VM6
VM7 VM8
Server 3
VM9
Physical switch
Virtual networks:
1 2
3
VM9 Payload
Eth + VLAN tag + IP
VM migraBon example
VM1 VM2
Server 1
VM3
VM4 VM5
Server 2
VM6
VM7 VM8
Server 3
VM9 Physical switch
Virtual networks:
1 2
3
VM9 Payload
Eth + VLAN tag + IP
Overlay networking
• “Old” technology, new for data-‐centers • Physical underlay network – IP fabric – No state of the virtual networks
• Virtual overlay network – Holds state of the virtual networks – Dynamic tunnels (MPLSoGRE, VXLAN, etc.)
VM migraBon example
VM1 VM2
Server 1
VM3
VM4 VM5
Server 2
VM6
VM7 VM8
Server 3
VM9
Physical switch
Virtual networks:
1 2
3
S3 VM9 Payload Physical network:
VM migraBon example
VM1 VM2
Server 1
VM3
VM4 VM5
Server 2
VM6
VM7 VM8
Server 3
VM9 Physical switch
Virtual networks:
1 2
3
S2 VM9 Payload Physical network:
Overlay networks advantages
• “Knowledge” about network only in the solware (vRouter)
• Any switch works for IP fabric network – No configuraBon – Only speed maners – Low price
• OpenContrail implementaBon is standards-‐based (MPLS, BGP, VXLAN, etc.)
OPENCONTRAIL ARCHITECTURE
• Goals • Nodes • Components
Architecture goals
• Scalability • CompaBbility • Extensibility • Fault tolerance • Performance
“Think globally, act locally”
• The system is physically distributed – No single point of failure – Scalability – Performance
• Logically centralized control and management – Simplicity – Ease of use
Architecture overview
Source: www.opencontrail.org
ConfiguraBon node
Source: www.opencontrail.org
ConfiguraBon node components
• ConfiguraBon API Server – AcBve/AcBve mode – Receives REST API calls – Publishes configuraBon to the IF-‐MAP Server – Receives configuraBon from other API Servers
• Discovery Service – AcBve/AcBve mode – A Registry of all OpenContrail services – Provides REST API for publishing and querying of services
ConfiguraBon node components (2)
• Schema Transformer – AcBve/Backup mode – Receives high-‐level configuraBon from IF-‐MAP Server – Transforms high-‐level constructs (eg. virtual network) to low-‐level (eg. rouBng instance)
• IF-‐MAP Server – AcBve/AcBve mode – Publishes system configuraBon to Control nodes, Schema Transformer
– All configuraBon comes from API Server (both high and low level)
ConfiguraBon node components (3)
• Service Monitor – AcBve/Backup mode – Monitors service virtual machines (firewall, analyzer, etc.)
– Calls nova API to control VMs • AMPQ Server (RabbitMQ) – CommunicaBon between system components
• Persistent storage (Cassandra) – Receives and stores system configuraBon from the ConfiguraBon API Server
ConfiguraBon flow (user)
1. User Request 2. Original API Server 3. RabbitMQ 4. All API Servers 5. Local IF-‐MAP Server 6. Schema Transformer
ConfiguraBon flow (transformed)
1. Schema Transformer 2. ConfiguraBon API Server 3. RabbitMQ 4. All API Servers 5. Local IF-‐MAP Server 6. Control nodes and DNS
Controller node
Source: www.opencontrail.org
Control node components • Controller – AcBve/AcBve mode – Receives configuraBon from IF-‐MAP Server – Exchanges XMPP messages with vRouter Agent – Federate with other nodes and physical switches via BGP/Netconf
• DNS Service – AcBve/AcBve – Receives configuraBon from IF-‐MAP Server – Exchanges XMPP messages with vRouter Agent – Front-‐end only, backend using host naBve ‘named’
Compute node Nova
Scheduler Contrail Control
node
Nova vif driver
KVM
VM VM VM
Contrail Agent
Contrail vRouter
Kernel space
Nova compute
Libvirt
NetLink /dev/flow pkt
TCP
QEMU
TUN/TAP
Compute node components
• vRouter Agent – CommunicaBon via XMPP with the Control node – InstallaBon of forwarding state into vRouter – ARP, DHCP, DNS proxy
• vRouter – Packet forwarding – Applying flow policies – EncapsulaBon, decapsulaBon
Agent <-‐> vRouter communicaBon
• NetLink – RouBng entry, next-‐hop, flow, etc. synchronizaBon
– Uses RCU • /dev/flow – Shared memory for flow hash tables
• pkt tap device – Flow discovery (first packet of a flow) – ARP, DHCP, DNS proxy
AnalyBcs node
Source: www.opencontrail.org
AnalyBcs node components
• API Server – REST API for querying analyBcs
• Collector – Collects analyBcs informaBon from all system nodes
• Query Engine – Map-‐reduce over collected analyBcs – Executes queries
• Rules Engine – Controls which events are collected by the Collector
Any quesBons?
top related