Fabric for the Next Generation Data Centre


Published on

The transition to the modern virtualised data centre is reshaping the compute environment and placing new
demands on the data centre network. Traditional complex and tiered network designs can no longer meet the real
time demands of the dynamic and cloud based data centre. This requires a fundamental rethink in the underlying
network architecture - the solution lies with fabric based networks. However, not all fabrics are created equals.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Read - http://juniper.net/us/en/local/pdf/whitepapers/2000327-en.pdf in conjunction with this deck.Also useful collateral to leave with customers following this presentation.
  • Background: The first 4 slides outline how most of the infrastructure in the Data Center has evolved, while the network design has remained unchanged and has now become outdated and not suited for purpose. Note – the physical infrastructure (servers/storage) and applications will have much higher focus for customers than networking infrastructure. An underlying message thru this presentation should be that having the right type of network will maximise the efficiency of these other areas.Content: Within many DC’s (see DC taxonomy info for more info on which types of customers) servers and storage have been both consolidated and virtualised. (Note: While storage has been consolidated for quite a long time, virtualising that storage resource is still relatively new - see ‘thin provisioning’ http://en.wikipedia.org/wiki/Thin_provisioning). These create pools of resource within the DC increasing efficiency (reducing cost/power/space etc) of that resource. (After 1st build) With SRX, security and other network services can also be consolidated and virtualised with similar benefits. (After 2nd build) A single high performance network is now needed to interconnect these new resource pools - which is the focus of this presentation.
  • Content: As well as the physical infrastructure applications have also evolved. In the older client server architecture the complete compute process was contained within a server. The majority of traffic flowing within a DC was between the client and server (referred to as ‘North/South’ traffic from a network perspective). Now to improve both application scalability and reliability SOA distributes individual applications onto single servers running dedicated routines within an application. Data passing between this routines now needs to cross the DC network (‘East/West traffic’), for many customers this accounts for over 75% of the traffic in the DC. Storage traffic, DataBase traffic, Virtualisation (VM) traffic, Server Mash-ups are all additional examples of new East/West traffic.
  • Content: This slide explains how businesses address the issue of managing this complexity by scaling back to keep within reasonable limits (Either limited by ability to fix in a reasonable time frame – or if an SP, within SLA).The “Choice”, is to either scale to take full advantage of virtualisation and server/app evolution discussed earlier, or constrain by designing in manageable silos. Narrative:Scalability ideally is the ability to add capacity without adding complexity. The red line represents adding more capacity to the data center network. Ideally the incremental operational complexity associated with that capacity is either zero or very small. What you see here is the ideal environment.[BUILD]: Unfortunately that is not reality. Today’s reality is that as you add more resourcesto today’s data center network they get exponentially more complex. [BUILD]: At some point in time, to limit that complexity, you will limit the size of the network itself.Further Reading:http://forums.juniper.net/t5/Architecting-the-Network/The-Mathematics-of-Complexity-You-Can-t-Just-Mask-It-You-Must/ba-p/39132
  • Background: These next 3 slides introduce the concept of ‘FABRIC’ as the ideal network architecture for the DC. Importantly this also defines ‘FABRIC’ as many of our competitors have also started using the term fabric in their marketing, but only partly meeting the requirements for a network fabric. (See Yankee report for more detail on what defines a Network Fabric)Content: This slide starts by showing the traditional 3 layer hierarchical DC network (with all the limitations mentioned earlier). Clicking through show that while this architecture was suited for client-server networks of the past, for modern server architectures in an ideal world each device would be directly connected to each other device. (While this might be possible for a few devices it clearly wouldn’t be practical at any scale).Key Point: We need a FLAT network infrastructure – where every port (device) is (or appears to be) directly connected to every other port. A true network FABRIC provides this ‘any to any’ connectivity. I.e. Claiming an architecture is a ‘fabric’ requires more than just creating a single point for management.
  • Content: A single Ethernet switch provides ‘Flat – any port to any port’ connectivity. A true Network Fabric requires that in addition to being ‘Flat’, it also operates and is managed as a single device, with all ports sharing a common state so that any packet only needs to be processed once to be able to reach it’s final destination (single hop). A single Ethernet switch meets the requirements of a Network Fabric. This slides continues to build to demonstrate that a single switch has limitations of scale (Which is one of the main reasons why the hierarchical LAN architecture was adopted in the DC). Key Messages: “Fabric” is often used by our competition to describe their control plane only solutions. This only simplifies management, and doesn’t provide the single hop + ‘any to any’ performance benefits also required from a DC network fabric.Further Reading: http://forums.juniper.net/t5/Architecting-the-Network/Not-All-Fabrics-Are-Created-Equal/ba-p/40121
  • Content: This slide introduces the concept of Network Fabric as the ‘ideal network’ to span the complete DC. This would provide both the ‘Performance’ and ‘Simplicity’ of a fabric (single switch) and encompasses Juniper’s vision for the Data Center Network.
  • Content: This slide explains the dramatic levels of simplification that running a 2 layer fabric based architecture can deliver. Earlier slides explained the link between interactions and complexity.Technical Messages: X-axis shows number of ports while the Y-axis then shows the number of managed devices required to connect this ports. Black line is for a conventional hierarchical DC network, and Blue line the resulting number of potential interactions. The lower lines are the equivalent for connecting the ports with a two layer network fabric based solution.Business Values: Such dramatic simplification will drive both operational cost savings and improved network reliability. (Plus application performance improvements previously mentioned).
  • Fabric for the Next Generation Data Centre

    1. 1. FABRIC FOR THE NEXT GENERATION Data Centre<br />Andy Jolliffe – Data Centre Strategy<br />Oct 2010<br />
    2. 2. Agenda<br />Evolution within the Data Centre<br />Network Fabrics for Data Centre<br />Simplifying the Data Centre Network<br />Juniper’s Vision<br />
    3. 3. The servers and storage evolved<br />Network services can be consolidated and virtualized<br />A single network to integrate the resource pools<br />Servers were consolidated<br />standardized<br />and virtualized<br />Storage was consolidated<br />and virtualized<br />
    4. 4. The Applications evolved<br />Client – Server Architecture<br />Service Oriented Architecture<br />Client<br />Client<br />95%<br />25%<br />75%<br />Server<br />Server<br />Server<br />Server<br />Server<br />Server<br />B<br />B<br />A<br />C<br />A<br />C<br />DB<br />D<br />DB<br />D<br />A fundamental change in data flows<br />
    5. 5. The network architecture has not changed<br />Complex<br />Inefficient<br />Expensive<br /><ul><li>High CapEx / OpEx
    6. 6. Constrains Virtualisation
    7. 7. Appliance sprawl
    8. 8. Multiple networks
    9. 9. Limited scalability
    10. 10. High Latency
    11. 11. Spanning Tree</li></ul>L2/L3Switch<br />L2/L3Switch<br />SSL VPN<br />Firewall<br />IPSec VPN<br />IPS<br />L2/L3 Switch<br />L2/L3 Switch<br />L2 Switch<br />Up to 75% of traffic<br />E<br />W<br />SERVERS<br />NAS<br />STORAGE<br />Cluster Network<br />FC SAN<br />
    12. 12. 3 problems with DATA CENTRe networks today<br />Data Center<br />N<br />Today’s Challenges:<br /><ul><li>Too slow
    13. 13. Too expensive
    14. 14. Too complex</li></ul>Up to 75% of traffic<br />E<br />W<br />S<br />
    15. 15. Every extra “hop” adds latency <br />Every hop adds to the potential for congestion – inconsistent performance<br />Application behavior is impacted<br />Solution<br />E<br />W<br />#1: TOO SLOW<br />Flat &Any-to-any network<br />Too Slow<br />Up to 75% of traffic<br />
    16. 16. #2: Challenges of Efficiency<br />Too Expensive<br />Up to 50% of the ports interconnect switches, not servers or storage<br />Up to 50% of the bandwidth is disabled by spanning tree<br />Up to 30% of the networkspend can be avoided<br />Eliminate$1Bof annual spend world wide<br />Solution<br />Eliminate STP<br />Reduce Tiers<br />
    17. 17. Operational Complexity<br /><ul><li>Number of managed devices
    18. 18. Each switch is autonomous
    19. 19. 7 managed devices
    20. 20. Number of potential interactions
    21. 21. Shared protocols
    22. 22. 21 potential interactions</li></ul>N = no. of managed devices<br />N<br />#3 Complexity – a function of devices + interactions<br />N*(N-1)<br />2<br />S<br />
    23. 23. CHALLENGES OF SCALE<br />Today’s Data Centre Network Forces a Choice<br />The ability to add capacity without adding complexity<br />SCALABILITY:<br />Today’s reality<br />Limits of Scale<br />Capacity<br />Capacity<br />Complexity<br />Complexity<br />Ideal<br />Scale<br />
    24. 24. DEFINING THE IDEAL NETWORK<br />Typical tree configuration<br />Flat - any port connected to any port<br />FABRIC <br />
    25. 25. DEFINING THE IDEAL NETWORK<br />Flat - any port connected to any port<br />FABRIC = PERFORMANCE<br />FABRIC <br />Fabric - definition<br />Control<br /><ul><li>Managed as a single device
    26. 26. All ports have shared state</li></ul>Data Forwarding<br /><ul><li>Flat – any to any
    27. 27. Packet processed only once</li></ul>Switch = Fabric<br />FABRIC = SIMPLICITY<br />Simplicity of a single switch<br />Single switch does not scale<br />
    28. 28. DEFINING THE IDEAL NETWORK – A FABRIC<br />Flat - any port connected to any port<br />FABRIC = PERFORMANCE<br />Fabric - definition<br />Control<br /><ul><li>Managed as a single device
    29. 29. All ports have shared state</li></ul>Data Forwarding<br /><ul><li>Flat – any to any
    30. 30. Packet processed only once</li></ul>FABRIC = PERFORMANCE<br />Single lookup for reduced latency<br />A Network Fabric has the….<br />FABRIC = SIMPLICITY<br />Simplicity of a single switch<br />FABRIC = SIMPLICITY + PERFORMANCE<br />Scalability of a network<br />
    31. 31. Fabric at the access layer <br />2<br />3<br />2<br />1<br />L2/L3Switch<br />L2/L3Switch<br />L2/L3 Switch<br />L2/L3 Switch<br />SRX5800<br />EX4200<br />L2 Switch<br />SERVERS<br />NAS<br />STORAGE<br />FC SAN<br />
    32. 32. ImprovinGApPlication Performance<br />×<br />up to 160µs<br />Routers/Switches<br />Access Switch<br />Access Switch<br />App 3<br />O/S<br />~2.6 – 17µs <br />EX 4200<br />EX 4200<br />Server 1<br />Rack 1<br />Server 2<br />Rack 2<br />Benefits for:<br /><ul><li>VMotion
    33. 33. DataBase calls
    34. 34. SOA
    35. 35. Server Mash-ups</li></ul>3<br />Hypervisor (VMWare)<br />Hypervisor<br />Hypervisor (VMWare)<br />Hypervisor<br />App 1<br />App 2<br />App 1<br />App 2<br />App 3<br />App 1<br />App 2<br />App 4<br />App 5<br />O/S<br />O/S<br />O/S<br />O/S<br />O/S<br />O/S<br />O/S<br />O/S<br />O/S<br />Unused<br />Unused<br />Unused<br />Unused<br />Unused<br />VM 1<br />VM 2<br />VM 1<br />VM 2<br />VM 3<br />VM 3<br />VM 4<br />VM 5<br />
    36. 36. 2<br />3<br />2<br />1<br />L2/L3Switch<br />L2/L3Switch<br />EX8216<br />L2/L3 Switch<br />collapse core &aggregation layers<br />L2/L3 Switch<br />SRX5800<br />EX4200<br />SERVERS<br />NAS<br />STORAGE<br />FC SAN<br />
    37. 37. Juniper's simplified data center approach will allow us to deploy a complete 10 Gigabit Ethernet network with ultra-low latency at a substantial cost savings," said Steve Rubinow, executive vice president and co-global CIO of NYSE Euronext. "Juniper has developed truly unique and innovative technologies that help us to deploy a very high capacity, low latency network that meets the stringent demands of the new data center. With Juniper, we are able to dramatically cut the cost and complexity of managing our data center network today, while continuing to enhance our competitive position with a next-generation data center fabric that will enable us to scale to tens of thousands of 10GbE ports. With such an elastic and efficient infrastructure, we can provide enhanced functionality to our customers at unmatched scale while minimizing total cost of ownership." <br />Case study: New York Stock Exchange: New Services Rollout<br />
    38. 38. FaBRIC AT THE CORE<br />3<br />2<br />1<br />2<br />2011<br />Fabric in the Core<br />2<br />MPLS/VPLS<br />Data Center Interconnect<br />MX Series<br />Eliminates need to run spanning tree<br />STP<br />EX8216<br />Virtual Chassis in the core<br /><ul><li>EX8200 and MX-3D
    39. 39. Eliminates STP and VRRP
    40. 40. Across L2 in the data center
    41. 41. Highly resilient architecture
    42. 42. Available early next year</li></ul>SRX5800<br />EX4500<br />EX4200<br />EX8208<br />Servers<br />FC Storage<br />NAS<br />FCoE<br />FC SAN<br />
    43. 43. Fabrics reduce complexity<br />Devices<br />Interactions<br />N*(N-1)<br />2<br />At 6000 ports:<br /><ul><li> 89% reduction in managed devices
    44. 44. 99% reduction in interactions</li></ul>10,000<br />400<br />Interactions<br />7,500<br />300<br />Complexity<br />At 1000 ports:<br /><ul><li> 83% reduction in managed devices
    45. 45. 97% reduction in interactions</li></ul>5,000<br />200<br />2,500<br />100<br />Managed Devices<br />Interactions with Virtual Chassis<br />5000<br />4000<br />6000<br />0<br />2000<br />1000<br />3000<br />No. of Ports<br />
    46. 46. JUNOS Operating System<br />T Series<br />EX8216<br /><ul><li>One OS
    47. 47. Single source code base
    48. 48. Consistent implementation of features </li></ul>EX8208<br />SRX5800<br />TX Matrix<br />SRX<br />SRX5600<br />SRX3600<br />NSMXpress<br />Frequent Releases<br />MX Series<br />SRX650<br /><ul><li>One Release
    49. 49. Single software release track of feature supersets
    50. 50. Stable, predictable development of new features</li></ul>EX4500<br />M Series<br />SRX240<br />EX4200<br />J Series<br />SRX210<br />EX3200<br />SRX100<br />EX2200<br />SECURITY<br />ROUTERS<br />SWITCHES<br /><ul><li>One Architecture
    51. 51. Modular software with resource separation
    52. 52. Highly available, secure and scalable software </li></ul>10.0<br />10.1<br />10.0<br />10.1<br />10.2<br />10.2<br />Module<br />x<br />–API–<br />Module<br />x<br />Frequent Releases<br />SRX<br />Tx Matrix<br />One OS<br />One Release<br />One Architecture<br />Video: Why is Junos different?<br />
    53. 53. 2 Tier FABRIC NETWORK<br />3<br />2<br />1<br />2<br />MPLS/VPLS<br />Data Centre Interconnect<br />MX Series<br />SRX5800<br />EX8216<br />EX8208<br />EX4500<br />EX4200<br />Servers<br />FC Storage<br />NAS<br />FCoE<br />FC SAN<br />
    54. 54. 2 Tier FABRIC NETWORK<br />3<br />2<br />1<br />2<br />MPLS/VPLS<br />Data Centre Interconnect<br />MX Series<br />SRX5800<br />EX8216<br />EX8208<br />EX4500<br />EX4200<br />Servers<br />FC Storage<br />NAS<br />FCoE<br />FC SAN<br />
    55. 55. Juniper Vision – SIMPLIFY<br />1<br />3<br />2<br />1<br />MPLS/VPLS<br />Data Centre Interconnect<br />MX Series<br />DATA CENTER FABRIC<br />SRX5800<br />The Stratus Project<br />SRX5800<br />A very large distributed L2/L3 switch that runs…<br />
    56. 56. STRATUS AT A GLANCE<br />Scale: <br />10’s to 10’s of 1000’s of ports<br />Performance:<br />Flat and Non-Blocking <br />Simplicity:<br />N=1<br />Designed for modern DC<br />Virtualization and Convergence<br />Juniper Confidential<br />
    57. 57. Legacy architecture Vs Stratus<br />N<br />The Stratus Solution:<br /><ul><li>Flat, any-to-any fabric
    58. 58. Inherently lower TCO
    59. 59. Massive Scale, N=1</li></ul>Today’s Challenges:<br /><ul><li>Too slow
    60. 60. Too expensive
    61. 61. Too complex</li></li></ul><li>How is Stratus different from solutions from other vendor “FABRICS”<br />Project Stratus<br />Building a fabric to behave like a single switch<br />L2 & L3<br />Yes<br />Yes<br />Network FabricData Plane<br /><ul><li>Flat
    62. 62. Any-to-any</li></ul>Control Plane<br /><ul><li>Single device
    63. 63. Shared state</li></ul>Network FabricData Plane<br /><ul><li>Flat
    64. 64. Any-to-any</li></ul>Control Plane<br /><ul><li>Single device
    65. 65. Shared state</li></ul>Other Vendor Fabrics(using Trill)<br />Making multiple switches try to behave like a fabric<br />L2 only<br />No<br />No<br />
    66. 66. Integrating stratus fabric<br />MX Series<br />Stratus Fabric<br />EX8216<br />SRX5800<br />EX4200<br />4<br />Pod 1<br />Pod 2<br />