Running OpenStack over a VXLAN Fabric Andre Pech - - PowerPoint PPT Presentation

running openstack over a vxlan fabric
SMART_READER_LITE
LIVE PREVIEW

Running OpenStack over a VXLAN Fabric Andre Pech - - PowerPoint PPT Presentation

Running OpenStack over a VXLAN Fabric Andre Pech Arista Networks Overview VXLAN Refresher Why VXLAN? Network Design Requirements Key


slide-1
SLIDE 1

Running ¡OpenStack ¡ ¡

  • ver ¡a ¡VXLAN ¡Fabric ¡

Andre ¡Pech ¡ Arista ¡Networks ¡

slide-2
SLIDE 2

Overview ¡

  • VXLAN ¡Refresher ¡
  • Why ¡VXLAN? ¡
  • Network ¡Design ¡Requirements ¡
  • Key ¡Decisions ¡Points ¡
  • OpenStack ¡over ¡VXLAN ¡designs ¡
  • Thoughts ¡on ¡future ¡work ¡
slide-3
SLIDE 3

VXLAN ¡Refresher ¡

  • Standardized ¡overlay ¡technology ¡for ¡

encapsulaIng ¡layer ¡2 ¡traffic ¡on ¡top ¡of ¡an ¡IP ¡ fabric ¡

IP Fabric

VTEP ¡A ¡ VTEP ¡B ¡ VNI ¡5000 ¡ Host ¡1 ¡ Host ¡2 ¡ Layer ¡2 ¡ Layer ¡2 ¡over ¡Layer ¡3 ¡ Layer ¡2 ¡

slide-4
SLIDE 4

Learning ¡and ¡Flooding ¡in ¡VXLAN ¡

  • MAC ¡Learning ¡

– Learn ¡based ¡on ¡traffic ¡received ¡over ¡the ¡tunnel ¡ – And/or ¡use ¡a ¡protocol ¡to ¡distribute ¡MAC ¡tables ¡

  • Handling ¡BUM ¡Traffic ¡

– BUM ¡= ¡Broadcast, ¡Unknown ¡Unicast, ¡and ¡ MulIcast ¡traffic ¡ – Common ¡opIons ¡for ¡BUM ¡traffic ¡distribuIon: ¡

  • IP ¡MulIcast ¡
  • Head-­‑end ¡replicaIon ¡/ ¡replicaIon ¡node ¡
slide-5
SLIDE 5

Why ¡VXLAN? ¡

  • Addresses ¡4K ¡VLAN ¡limitaIon, ¡enabling ¡up ¡to ¡

16M ¡tenant ¡networks ¡

  • Solves ¡mac ¡address ¡scaling ¡issues ¡at ¡the ¡core ¡of ¡

the ¡network ¡

  • Allows ¡for ¡be^er ¡scalability ¡and ¡failover ¡with ¡an ¡

L3 ¡ECMP ¡fabric ¡

  • VXLAN ¡support ¡is ¡only ¡required ¡at ¡endpoints, ¡

allowing ¡greater ¡vendor ¡flexibility ¡in ¡the ¡network ¡

  • Networking ¡ASIC ¡support ¡
slide-6
SLIDE 6

Real ¡World ¡Requirements ¡to ¡ Deploy ¡OpenStack ¡over ¡VXLAN ¡

  • No ¡IP ¡MulIcast! ¡

– IP ¡mulIcast ¡is ¡an ¡efficient, ¡protocol ¡based ¡mechanism ¡ for ¡BUM ¡traffic ¡distribuIon ¡ – But ¡no ¡one ¡wants ¡to ¡run ¡mulIcast ¡in ¡their ¡network ¡

  • Hardware ¡VXLAN ¡gateways ¡

– Get ¡North-­‑South ¡traffic ¡into ¡/ ¡out ¡of ¡your ¡cloud ¡ – Bridge ¡physical ¡infrastructure ¡(storage, ¡non-­‑virtualized ¡ servers, ¡etc) ¡into ¡virtual ¡networks ¡ – The ¡performance ¡and ¡density ¡of ¡soeware ¡VXLAN ¡ gateways ¡is ¡not ¡sufficient ¡

slide-7
SLIDE 7

Some ¡Key ¡Design ¡Decisions ¡

  • Soeware ¡vs ¡Hardware ¡VTEPs ¡
  • ReplicaIon ¡node ¡vs ¡fully ¡distributed ¡head-­‑end ¡

replicaIon ¡

  • External ¡SDN ¡Controller ¡vs ¡Standalone ¡

Neutron ¡

slide-8
SLIDE 8

Soeware ¡vs ¡Hardware ¡VTEPs ¡

  • Flexibility ¡of ¡Soeware ¡vs ¡Performance ¡of ¡

Hardware ¡

– Soeware ¡VTEPs ¡are ¡limited ¡only ¡by ¡RAM ¡and ¡CPU ¡ cycles, ¡but ¡there’s ¡an ¡overhead ¡cost ¡of ¡10-­‑30% ¡per ¡ compute ¡node ¡ – Hardware ¡VTEPs ¡have ¡great ¡density ¡and ¡ performance, ¡but ¡are ¡limited ¡to ¡the ¡size ¡of ¡ hardware ¡tables ¡

  • Network ¡management ¡in ¡a ¡VXLAN ¡

environment ¡

slide-9
SLIDE 9

ReplicaIon ¡Node ¡vs ¡ ¡ Fully ¡Distributed ¡Head ¡End ¡ReplicaIon ¡

  • ReplicaIon ¡nodes ¡can ¡be ¡purpose-­‑built ¡

– Flows ¡can ¡be ¡spread ¡across ¡mulIple ¡replicaIon ¡ nodes ¡ – But ¡they ¡to ¡be ¡managed ¡and ¡have ¡an ¡HA ¡story ¡

  • Head-­‑end ¡replicaIon ¡at ¡each ¡VTEP ¡requires ¡no ¡

HA ¡strategy ¡

– But ¡burdens ¡each ¡VTEP ¡with ¡the ¡cost ¡of ¡replicaIon ¡

slide-10
SLIDE 10

External ¡SDN ¡Controller ¡vs ¡ Standalone ¡Neutron ¡

  • Hard ¡tradeoff ¡to ¡quanIfy ¡
  • Generally ¡comes ¡down ¡to ¡funcIonality ¡vs ¡cost ¡
slide-11
SLIDE 11

OpenStack ¡over ¡VXLAN ¡

  • Three ¡designs ¡that ¡fit ¡the ¡real ¡world ¡

producIon ¡requirements: ¡

– External ¡SDN ¡controller ¡with ¡a ¡mix ¡of ¡Soeware ¡ and ¡Hardware ¡VTEPs ¡ – Standalone ¡Neutron ¡with ¡all ¡Hardware ¡VTEPs ¡ – Standalone ¡Neutron ¡with ¡a ¡mix ¡of ¡Soeware ¡and ¡ Hardware ¡VTEPs ¡

slide-12
SLIDE 12

External ¡SDN ¡Controller, ¡ Soeware ¡and ¡Hardware ¡VTEPs ¡

TOR ¡1 ¡ TOR ¡2 ¡ TOR ¡3 ¡ TOR ¡4 ¡ VTEP ¡ VTEP ¡ VTEP ¡ Compute ¡A ¡ VTEP ¡ Compute ¡B ¡ Compute ¡C ¡ Physical ¡Infra ¡

VM ¡ VM ¡ VM ¡ VM ¡ VM ¡ VM ¡

SDN ¡Controller ¡ (VMware ¡NSX, ¡ PLUMgrid,…) ¡ VTEP ¡ VTEP ¡ Neutron ¡ L3 ¡ L2 ¡ L3 ¡ L2 ¡ Controller ¡Plugin ¡ VNI ¡5000 ¡ VLAN ¡5 ¡

slide-13
SLIDE 13

External ¡SDN ¡Controller, ¡ Soeware ¡and ¡Hardware ¡VTEPs ¡

  • The ¡SDN ¡Controller ¡(for ¡example ¡VMware ¡NSX ¡
  • r ¡PLUMgrid) ¡

– Manages ¡virtual ¡VTEPs ¡and ¡the ¡VMs ¡behind ¡them ¡ – Integrates ¡with ¡the ¡hardware ¡VTEPs ¡to ¡configure ¡ gateway ¡funcIonality ¡for ¡end-­‑to-­‑end ¡provisioning ¡ driven ¡by ¡Neutron ¡ – Exchanges ¡VXLAN ¡MAC ¡address ¡table ¡informaIon ¡ between ¡the ¡physical ¡and ¡virtual ¡VTEPs ¡for ¡a ¡ mulIcast-­‑less ¡VXLAN ¡

slide-14
SLIDE 14

ML2 ¡

  • First, ¡a ¡quick ¡plug ¡for ¡ML2 ¡
  • ML2 ¡is ¡a ¡new ¡Neutron ¡plugin ¡in ¡Havana ¡which ¡

provides: ¡

– SeparaIon ¡between ¡the ¡state ¡of ¡tenant ¡networks ¡and ¡ how ¡that ¡state ¡is ¡then ¡realized ¡across ¡the ¡network ¡ – Flexibility ¡in ¡how ¡the ¡virtual ¡and ¡physical ¡network ¡are ¡ managed ¡ – MulI-­‑vendor ¡support ¡via ¡mulIple ¡“Mechanism ¡ Drivers” ¡managing ¡pieces ¡of ¡the ¡network ¡in ¡parallel ¡

  • Talk ¡on ¡ML2 ¡by ¡Bob ¡Kukura ¡and ¡Kyle ¡Mestery ¡on ¡

Friday ¡at ¡11am ¡

slide-15
SLIDE 15

Standalone ¡Neutron, ¡ All ¡Hardware ¡VTEPs ¡

VTEP ¡ VTEP ¡ VTEP ¡ Compute ¡A ¡ VTEP ¡ Compute ¡B ¡ Compute ¡C ¡ Physical ¡Infra ¡

VM ¡ VM ¡ VM ¡ VM ¡ VM ¡ VM ¡

VTEP ¡ VTEP ¡ Neutron ¡ ML2 ¡ OVS ¡ Arista ¡ VNI ¡5000 ¡ VLAN ¡5 ¡ VLAN ¡5 ¡ OVS ¡ OVS ¡ OVS ¡ L3 ¡ L2 ¡ L3 ¡ L2 ¡

slide-16
SLIDE 16

Standalone ¡Neutron, ¡ All ¡Hardware ¡VTEPs ¡

  • Take ¡advantage ¡of ¡hardware ¡capabiliIes, ¡

reduce ¡CPU ¡uIlizaIon ¡of ¡each ¡compute ¡node ¡

  • Limited ¡to ¡4K ¡tenant ¡networks ¡(sIll ¡limited ¡by ¡

the ¡VLAN ¡space) ¡

– Though ¡some ¡work ¡and ¡ML2 ¡mulI-­‑segment ¡ support, ¡you ¡could ¡do ¡rack-­‑specific ¡VLAN ¡ allocaIon ¡and ¡get ¡beyond ¡the ¡4K ¡tenant ¡network ¡ limit ¡

slide-17
SLIDE 17

Standalone ¡Neutron, ¡ Soeware ¡and ¡Hardware ¡VTEPs ¡

VTEP ¡ VTEP ¡ VTEP ¡ Compute ¡A ¡ VTEP ¡ Compute ¡B ¡ Compute ¡C ¡ Physical ¡Infra ¡

VM ¡ VM ¡ VM ¡ VM ¡ VM ¡ VM ¡

VTEP ¡ VTEP ¡ Neutron ¡ ML2 ¡ OVS ¡ Arista ¡ L3 ¡ L2 ¡ L3 ¡ L2 ¡

slide-18
SLIDE 18

Thoughts ¡on ¡Future ¡Work ¡

  • Standalone ¡Neutron ¡with ¡Soeware ¡and ¡Hardware ¡

VTEPs ¡is ¡hard ¡to ¡achieve ¡today ¡

– Requires ¡hook ¡to ¡share ¡VXLAN ¡connecIvity ¡info ¡ between ¡the ¡virtual ¡and ¡physical ¡infrastructure ¡ – L2 ¡populaIon ¡mechanism ¡driver ¡in ¡ML2 ¡is ¡a ¡step ¡in ¡ the ¡right ¡direcIon ¡

  • Need ¡a ¡general ¡model ¡of ¡VXLAN ¡gateway ¡nodes ¡

in ¡Neutron ¡

– Dynamically ¡a^ach/detach ¡physical ¡infrastructure ¡into ¡ tenant ¡networks ¡

slide-19
SLIDE 19

QuesIons? ¡