Network Requirements Solutions (Part 2)

Hi everybody! Today we are going to continue explaining the network requirements solutions that we propose for our design. First af all, we will describe the architecture that we have chosen to design our Data Center. After considering the three possible implementations that HP (our provider) proposes (which are the flat architecture -1 tier-, the Spine and Leaf -2 tiers- and the 3-tier architecture) we have opted for the Spine and Leaf architecture. The flat one is obviously discarded because of its disadvantages: much less scalability, no segmentation and waste of bandwidth and computational resources. When deciding between the 2-tier or the 3-tier approach, the key factor is that nowadays most of the Data Center traffic is from East to West instead North to South, which is more common in legacy ones. When comparing 2-tier and 3-tier architectures, experts say that Spine and Leaf solutions are more suitable for East-West traffic patterns (you can learn more about it here and here). Furthermore, Spine and Leaf architectures are deterministic in terms of the hops that traffic between servers must take to reach the destination, while 3-tier ones are not deterministic (depending on the physical placement, traffic needs to pass through the core layer or not). This fact also helps to design the capabilities of the network in terms of bandwidth allocation as it is easier to calculate its Oversubscription Ratios.

Spine-Leaf vs 3-tier architectures

 

As you can see from our previous post, we are using VXLANs to improve the mobility, isolation and other characteristics from our Data Center solution. From it, you can deduce that we are implementing an Overlay Solution (Layer 2 over Layer 3).  It is relevant to say that HP Helion OpenStack, together with open source Neutron framework, enabled by HP’s Virtual Cloud Networking (VCN) SDN application will allow virtual overlay networks to be created between multiple hypervisors. VXLAN tunnels are created dynamically, and terminated within Open vSwitch instances, or by using either direct OVSDB or SDN-enabled termination on HP switches. VMware direct OVSDB method allows HP hardware VXLAN Tunnel End Points (VTEPs) to integrate directly with VMware NSX to bridge VMs on virtual networks to physical bare metal equipment.

Example of an overlay solution with the integration of VMWare NSX

 

Last but not least, we have decided to modify our preproduction environment. Considering that our solution is for bank institutions, we think these ones will need to take performance tests which cannot be carried out in a virtualised network sharing the same spine and leaf with the production environment. That's why we have pivoted and chosen that we will replicate the physical equipment into another spine and leaf network which will be smaller sized but realistic enough to perform those tests. As every week, thank you for following us and if you liked this post don't leave without leaving a comment and sharing it! See you soon!