Openstack Basic with Neutron

  • 2,148 views
Uploaded on

 

More in: Internet , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,148
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
195
Comments
0
Likes
15

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 2014.07.12 - KwonSun Bae
  • 2. OpenStack - Networking We are Networker ~
  • 3. Agenda • OpenStack Overview  Architecture  Services  Example Architecture • Basic Services  Controller  Compute  Network • Process Flows • Networking –Neutron  Neutron Modular Layer 2 (ML2) Plug-in  ML2 Overview  ML2 Drivers  OpenvSwitch Plug-in  OVS Linux Bridge  OVS Internals  OVS Traffic Flows  OVS Configure • QnA
  • 4. OpenStack Overview • Cloud Software
  • 5. Architecture Docs - http://docs.openstack.org/icehouse/install- guide/install/apt/content/ch_overview.html#archit ecture_conceptual-architecture
  • 6. Services • Basic Services • Dashboard – Horizon • Compute – Nova • Networking – Neutron • Identity – Keystone • Image - Glance • Optional Services • Storage • Swift (Object) • Cinder (Block) • Database – Trove • Orchestration – Heat • Telemetry – Ceilometer • Supporting Services • Database – MySQL • Message Broker - RabbitMQ
  • 7. Services • Basic Services • Dashboard – Horizon • Compute – Nova • Networking – Neutron • Identity – Keystone • Image - Glance • Optional Services • Storage • Swift (Object) • Cinder (Block) • Database – Trove • Orchestration – Heat • Telemetry – Ceilometer • Supporting Services • Database – MySQL • Message Broker - RabbitMQ
  • 8. Example Architecture Three Nodes Architecture with Neutron.
  • 9. Example Architecture Three Nodes Architecture with Neutron. • Management network. Used for internal communication between OpenStack Components. • Internal network. Used for VM data communication within the cloud deployment. • External network. Used to provide VMs with Internet access. • Controller Node: Controller node contains all OpenStack API services. • Network Node: Network node contains DHCP server and virtual routing. • Compute Node: Network node contains compute service and neutron plugin
  • 10. Basic Services • Openstack operation을 위한 필수 Services
  • 11. Supporting Services • Database • MySQL • 각 Service들의 구성정보 저장 • Message Broker • RabbitMQ • 각 Service간의 Message전달,처리 • http://docs.openstack.org/training- guides/content/module001-ch008-queues- messaging.html
  • 12. Keystone For Identity Service.
  • 13. Glance For Image Provision, Store 등
  • 14. Nova Virtual Machine Management
  • 15. Nova The core components of Nova include the following: • The nova-api accepts and responds to end- user compute API calls. It also initiates most of the orchestration activities (such as running an instance) as well as enforcing some policies. • The nova-compute process is primarily a worker daemon that creates and terminates virtual machine instances via hypervisor APIs (XenAPI for XenServer/XCP, libvirt for KVM or QEMU, VMwareAPI for vSphere, etc.). • The nova-scheduler process is conceptually the simplest piece of code in OpenStack Nova: it take a virtual machine instance request from the queue and determines where it should run (specifically, which compute node it should run on).
  • 16. Neutron • plugin agent (quantum-*-agent):Runs on each hypervisor to perform local vswitch configuration. Agent to be run depends on which plugin you are using, as some plugins do not require an agent. • dhcp agent (quantum-dhcp- agent):Provides DHCP services to tenant networks. This agent is the same across all plugins. • l3 agent (quantum-l3-agent):Provides L3/NAT forwarding to provide external network access for VMs on tenant networks. This agent is the same across all plugins.
  • 17. Neutron Use Case: Per-tenant Routers with Private Networks A more advanced router scenario in which each tenant gets at least one router, and potentially has access to the OpenStack Networking API to create additional routers. The tenant can create their own networks, potentially uplinking those networks to a router. This model enables tenant-defined multi-tier applications, with each tier being a separate network behind the router. Since there are multiple routers, tenant subnets can be overlapping without conflicting, since access to external networks all happens via SNAT or Floating IPs. Each router uplink and floating IP is allocated from the external network subnet.
  • 18. Process Flows
  • 19. AMQP AMQP is the messaging technology chosen by the OpenStack cloud. The AMQP broker, either RabbitMQ or Qpid, sits between any two Nova components and allows them to communicate in a loosely coupled fashion. More precisely, Nova components (the compute fabric of OpenStack) use Remote Procedure Calls (RPC hereinafter) to communicate to one another; however such a paradigm is built atop the publish/subscribe paradigm so that the following benefits can be achieved: • Decoupling between client and servant (such as the client does not need to know where the servant reference is). • Full a-synchronism between client and servant (such as the client does not need the servant to run at the same time of the remote call). • Random balancing of remote calls (such as if more servants are up and running, one-way calls are transparently dispatched to the first available servant).
  • 20. Networking - Neutron
  • 21. Neutron ModularLayer 2 Plug-in (ML2) http://docs.openstack.org/trunk/config -reference/content/networking-options- plugins-ml2.html DRAFT - Document for Juno Original Goal • The Modular Layer 2 (ML2) Plugin is a framework allowing OpenStack Networking to simultaneously utilize the variety of layer 2 networking technologies found in complex real- world datacenters.
  • 22. ML2 “Drivers” ML2 exposes two different types of drivers: “Type” and “Mechanism” ML2 Type Drivers: • Maintain type-specific state Provide tenant network allocation Validate provider networks Current TypeDrivers: local, flat, VLAN, GRE, and VXLAN ML2 Mechanism Drivers: • Responsible for taking information sup plied by TypeDrivers and ensuring it is properly applied given the specific netw orking mechanisms which have been en abled Current MechanismDrivers: Arista, Cisco Nexus, Hyper-V, L2 Popula tion, LinuxBridge, Open vSwitch, Tail-F NCS
  • 23. Agenda • OpenStack Overview  Architecture  Services  Example Architecture • Basic Services  Controller  Compute  Network • Process Flows • Networking –Neutron  Neutron Modular Layer 2 (ML2) Plug-in  ML2 Overview  ML2 Drivers  OpenvSwitch Plug-in  OVS Linux Bridge  OVS Internals  OVS Traffic Flows  OVS Configure • QnA
  • 24. OpenvSwitch Linux Bridge http://www.slideshare.net/rajdeep/ope nvswitch-deep-dive VM – OVS Connection
  • 25. OVS Internals 각각의 bridge들은 bridge별 ovs demon 을 소유
  • 26. OVS Traffic Flows Compute Node to Network Node L3-agent • SNAT • Floating IP Create DHCP-agent • Subnet based Dynamic IP Lease • Each Subnet’s Gateway
  • 27. Neutron - Demo
  • 28. Lab Overview OpenStack installed on vSphere • 1 Hosts 3 Node Install • Controller • Network • Compute 향후 추가계획 • 호스트B 에 Compute node 추가 • 다른 Plug-in Test • Nova – vSphere 연동 Bebe's Lab Topology
  • 29. Lab Access and Demo Demo Scenario • L3-Agent(Router) Create • Network Create • Network Subnet Create • L3-Agent connect with Interfaces • Gateway Network connect • Instance attach • Floating IP Create • Floating IP Associate • Ping Test http://docs.openstack.org/admin- guide-cloud/content/l3_workflow.html
  • 30. QnA