Virtual Networks: Host Perspective

Transcription

1 Networks: Host Perspective IETF-77 Anaheim, CA Network Research Group March 23rd, 2010 Sunay Tripathi 1

2 Evolving ization Landscape Physical OS Hypervisor Server Server Server Server Server Server V V V Physical Switch Router Network Switch Physical Switch Router Network Evolving Domain New Challenges Defining the Network and its scope Identifying the Machines on the network and policy enforcement Added complexity with new layers 2

3 Components of a Network Assigning MAC address to virtual s (V) and VSwitches > A randomly created MAC address is preferred to aid virtual machine migration > L2 networks are becoming bigger in data centers (1000s of hosts) and the hosts and becoming more powerful capable of hosting 100s of VM so MAC addresses can collide fairly often > For a Vswitch to be managed and be a identifyiable entity, it needs to have a MAC address too Identifying Machine on the network > Need mechanisms to find current physical location Policies associated with Vs and VM migration > MAC address, B/W limits, ACLs, host resources (CPUs, MIBs, stats, etc) need to be transferred to destination hypervisor during Machine migration > A centralized Port Profile Manager is not preferable since it creates another point of failure 3

4 Scope of a Network Naming and Identifying a Network Do they span just a layer 2 network or they span multiple IP networks that can be geographically separated > Perhaps we can classify them into two three types including a simple network that just spans a L2 Migrating, snapshotting a Network 4

5 Security in a ized Network L2 network open to new attacks > With SR-IOV virtualized s, a VM has ability to send bridge PDU, OSPF packets, etc and attack the L2 networks in new ways > Some OSes along with s can protect themselves but others can't > Some switch can deal with per VM security while others can't > Who does the protection can be a business decision so both modes need to be supported Performance and Security > Doing security checks twice doesn't improve performance > Clear protocols needed to negotiate who is doing the enforcement so we don't end up doing it twice (EVB group has some drafts) > At the same time, need to guarantee that it has been done atleast once Challenges > The environment gets very dynamic in terms of Number of Machines and migration > The policy enforcement, negotiation needs to scale in this environment 5

6 Isolation and B/W sharing For some people, Network means VLANs > VLANs do provide functional separation of the broadcast domains but have no resources attached to them > The hypervisors have QoS mechanisms that can be set on per V basis > Some switches can do QoS per VM basis Challenges > Too many VMs and Vs make up a Network > Configuring them individually is too challenging and error prone > Need a way to tie a group of VMs to a VLAN or extended VLAN and a mechanism for hypervisor and switch to negotiate B/W sharing mode 6

7 Diagnostics and Observability Statistics in a ized Network > Need per V statistics some OSes (like OpenSolaris) do it while others don't > Need per Network aggregated statistics 7

8 OpenSolaris Network ization Implemented via project Crossbow > Supports Vs and Vswitches with H/W assist > Per V MIBs > Supports configurable link speeds (QoS) between VMs > Works with link aggregation and IPMP > Vs can have VLAN tags assigned to them > Vs have dedicated, CPU, kernel threads and queues and are fully isolated from each other within the system 8

9 Crossbow: Network in a Box Physical Wire w/physical Machines Client Router Host 1 Host 2 Port 6 Port 9 Port 3 Port 1 Port Gbps 1 Gbps 1 Gbps 100 Mbps 1 Gbps Switch 3 Switch 1 Wire w/ Machines Client Router ( Router) Host 1 Host 2 V6 V9 V3 V1 V Gbps 1 Gbps 1 Gbps 100 Mbps 1 Gbps Vswitch 3 Vswitch 1 9

10 More details Related Links > CrossBow: > VNM: > Networking: Research Papers > Sigcomm VISA Crossbow: From H/W ized s to ized Networks > Sigcomm WREN Crossbow: A vertically integrated QoS stack > Usenix LISA Crossbow Wire: Network in a Box All the papers can be accessed via 10

11 BACKUP 11

12 Crossbow 'Hardware Lanes' Ground Up Design for multi-core and multi-10gige > Linear Scalability by using 'Hardware Lanes' with dedicated resources > Network ization and QoS designed in the stack > More Efficiency due to 'Dynamic Polling and Packet Chaining' Physical Physical Machine Switch Hardware Lane VLAN Separated C L A S S I F I E R Hardware Rings/DMA Hardware Rings/DMA Hardware Rings/DMA Kernel Threads and Queues Kernel Threads and Queues Kernel Threads and Queues Squeue Machine/Zone Machine/Zone Application 12

13 Network Containers ization Flows s & Switches Wire Solaris Global Zone Zone xb1-z1 SQUEUE Zone xb1-z2 SQUEUE Resource Control Bandwidth Partitioning H/W Partitioning CPUs/pri assignment bge0 Exclusive IP Instance V1 (100Mbps) Exclusive IP Instance V2 (200Mbps) Observability Real time usage for each Link/flow Finer grained stats per Link/flow History at no cost Rx/Tx DMA Rx/Tx DMA Flow Classifier Rx/Tx DMA Client xb2 Client xb3 13

14 (V) & Switches s > Functionally physical s: > IP address assigned statically or via DHCP and snooped individually > Appear in MIB as separate 'if' with configured link speed shown as 'ifspeed' > Vs can be created over Link Aggregation on can be assigned to IPMP groups for load balancing and failover support > Vs Can have multiple hardware lanes assigned to them > Can be created over physical (without needing a Vswitch) to provide external connectivity with switching done in H/W > Vs have configurable link speed, CPU and priority assignment > Standards based End to End Network ization > VLAN tags and Priority Flow Control (PFC) assigned to V extend Hardware Lanes to Switch > No configuration changes needed on switch to support virtualization Switches > Can be created to provide private connectivity between Machines 14

15 Machines Solaris Host OS ization Engine Host OS VIRTUAL SQUEUE All Traffic Solaris Guest OS 1 ization Engine HTTP SQUEUE Guest OS 1 VIRTUAL SQUEUE HTTPS SQUEUE DEFAULT SQUEUE Solaris Guest OS 2 ization Engine Guest OS 2 VIRTUAL SQUEUE All Traffic Host OS V Guest OS 2 V Host OS All traffic Guest OS 1 HTTP Guest OS 1 HTTPS Guest OS 1 DEFAULT Guest OS 2 All Traffic H/W Flow Classifier 15