Torii-HLMAC: Torii-HLMAC: Fat Tree Data Center Architecture Elisa Rojas University of Alcala (Spain)

Transcription

1 Torii-HLMAC: Torii-HLMAC: Fat Tree Data Center Architecture Elisa Rojas University of Alcala (Spain) April

2 Outline Introduction Protocol description Tree-based Multiple Addresses structure and automatic assignment with Extended RSTP Tree-based forwarding Tree-based path repair Evaluation Simulation of Torii-HLMAC Other issues: Use of Virtual Machines at hosts, HLMAC Address Assignment Alternatives, Inter-L2 Mobility, Generalization to any data center topology Conclusions April

3 Introduction Data center networks are increasingly relying on Ethernet and flat layer two networks Due to its excellent price, performance ratio and configuration convenience Scale-out model over scale-up model High scale dimensions Limitations of RSTP Recent architecture proposals: VL2 PortLand DAC Blueprint April

4 Introduction So if we have the advantages of using this type of topology why not make the most of it and consider it as an specific topology to enhance the whole architecture and data center protocol? Torii-HLMAC April

5 Tree-based Multiple Addresses structure and automatic assignment with Extended RSTP April

6 Tree-based Multiple Addresses structure and automatic assignment with Extended RSTP April

7 Tree-based Multiple Addresses structure and automatic assignment with Extended RSTP April

8 HLMAC are local MAC (U/L bit=1) Almost 6 bytes (6bits+5x8bits) ROOT is Address = , (in fact the first byte will not be 1, since the U/L bit will be set to 1, but it is omitted) April

9 Tree-based forwarding Broadcast and Multicast April

10 Tree-based forwarding Unicast April

11 Tree-based forwarding Unicast April

12 Tree-based forwarding Unicast April

13 Tree-based forwarding Unicast April

14 Tree-based forwarding Unicast April

15 Tree-based path repair Broadcast and Multicast April

16 Tree-based path repair Broadcast and Multicast Path repair looks for the first alternative to avoid duplicates April

17 Tree-based path repair Broadcast and Multicast April

18 Tree-based path repair Unicast April

19 Tree-based path repair Unicast No possible duplicates, so next common root switch is chosen bidirectional communication April

20 Tree-based path repair Unicast Frame + Destination notification + Source notification April

21 Tree-based path repair Unicast Frame + Source notification April

22 Evaluation Simulation of Torii-HLMAC OMNeT++ (v4.1) Torii switch C++ implementation over MACRelayUnit (inet framework) [Extended STP BPDU given as a parameter] PortLand topology + UDP traffic exchange Proven forwarding & path repair (different levels of link failure) April

23 Evaluation Use of Virtual Machines at hosts Data center topologies: physical hosts usually composed by a number of virtual machines (VMs) installed Torii only uses the first 4 bytes of HLMAC adddresses So the last 2 bytes could be use to distinguish among those VMs (65535 active VMs), by being assigned in the reception order of their ARP messages. HLMAC Address Assignment Alternatives In general, the Torii-HLMAC proposal takes 1 byte of the 6 of the HLMAC per hierarchical level, and 2 bytes for the VMs Nevertheless, fewer bits could be assigned for this and could be used for some aditional functions (i.e. repair), without changing the protocol. April

24 Evaluation Inter-L2 Mobility Gratuitous ARP propagates the new HLMAC information Generalization to any data center topology We have just shown our proposel over the PortLand topology, what about different topologies? The generalized PortLand topology will also work for Torii- HLMAC: << k-port switches can support 100 percent throughput among k 3 /4 servers using k 2 /4 switching elements and the topology should be organized into k pods, each connecting k 2 /4 end hosts >> Torii-HLMAC could be used with k up to 16, more than enough. k 2 /4 < 2 6 k 2 < 64*4 = 256 k < 16 April

25 Evaluation Generalization to any data center topology While keeping the pods, any topology would work. The use of different topologies will depend on the most desirable feature: less cost using cheap off-the-self components (Clos Network) or less wiring complexity (Fat Tree). April

26 Conclusions Torii-HLMAC is a distributed, fault-tolerant, zero configuration fat tree data center architecture Forwarding needs no tables The only tables needed are the translations from MAC to HLMAC (and viceversa) of active hosts at the edge switches (table size <= active hosts) On the fly path repair No network manager No control messages Load balancing initially based on a hash function Hosts not affected (no need of any software or change) Independent of IP April

27 Conclusions Specific wiring to be done at the construction of the topology Broadcast flooding is not avoided ARP proxy could be used Multicast should be improved So that not all the switches are broadcasted April

28 Conclusions Fat trees are more convenient than Clos networks for Torii-HLMAC simpler wiring Deeper analysis needed: Comparison with other architectures Setup time (Extended RSTP) Broadcast reduction (proxys, host registration at directory, e.g. SEATTLE) Multicast optimization (IGMP snooping, others) Multiple path repair performance April

29 Torii-HLMAC Thank you for your attention! Any questions? Elisa Rojas University of Alcala (Spain) April