Not discounting the East-West requirements in bandwidth (serviced by Spine and Leaf) and the possibility of delivering storage over an IP protocol, it is an imperative for any IDC 3rd Platform mechanism to be software defined. This is, in no small part, to accommodate the new rate of change associated with 3rd Platform application development included over the entirety of the application life-cycle. Manual ticket processing should not be allowed to stand in the way of the life-cycle process.
It is important to remember that, in Enterprise Cloud, not all of the applications deployed there will be 3rd Platform. There's also a high probability that there will not only be 2nd Platform applications living within the same infrastructure, but there is also the possibility of 1st Platform connectivity requirements. It's the old adage in IT, the pendulum swings but some of this stuff just doesn't go away.
So, there also needs to be a means to connect to legacy or classical systems. The combination is further complicated by a need, that is turning into a requirement, to isolate communication between individual applications to reduce the possible threat perimeter.
The connectivity managed between all of these systems must be API driven.
Consider this example architectural pattern:
 |
| SDN Any to any network architecture pattern |
In this example, the individual hypervisors are physically connected to the network, but rely upon a point-to-point tunnel to communicate with other hosts. In this example, it's based on VxLAN, but in reality could be any tunneling mechanism.
The virtual switch VTEP in the hypervisor is managed from a control plane, in this case, VMware NSX, that maintains Open VSwitch DataBase (OVSDB) information about its hosts under management.
The physical switch level VTEPs are managed by Arista Cloud Vision CVX, which maintains principal authority over the OVSDB and inner-connectivity of the Virtual Network Interfaces (VNI). It also creates the means to connect to bare-metal systems (far right) utilizing the VTEP in the switch.
VMware NSX acts as a substituent to the Arista Cloud Vision CVX such that one state mapping is managed across the entirety of the network in the OVSDB.
The result:
- The network is programatically defined
- There is software definition of both the physical and logical network endpoints
- It is managed through the interaction of API
- Provides isolation between application communications
No comments:
Post a Comment