How clouds and fibre has remade the data centre

There are several problems with this approach. The soft switch needs to enforce policy and access control list (ACL); make sure VLANs are followed and implement security. For example, if one image is compromised, it should not be able to freely communicate with the other images on the server, if policy says they should not be talking to each other.

If they were on different physical servers the network would make sure policy and security procedures were followed. The simple answer is that the group that maintains the server and the soft switch needs to make sure all the network controls are followed and in place. The practical problem with this approach is the coordination required between the two groups and the level of knowledge of the networking required by the server group. Having the network group maintain the soft switch in the server creates the same set of problems.

Today, the answer is to learn to deal with confusion and develop procedures to make the best of the situation and hope for the best. A variation on this is to use a soft switch from the same vendor as the switches in the network. The idea is that coordination will be easier since the switch vendor built it and has hopefully made the coordination easier. Cisco is offering this approach with VMware.

The third solution is to have all the communications from the virtual server sent to the network switch. This would simplify the switch in the VM since it would not have to enforce policy, tag packets or worry about security. The network switch would perform all these functions as if the virtual servers were directly connected to the servers and this was the first hop into the network.

This approach has appeal since it keeps all the well developed processes in place and restores clear accountability on who does what. The problem is spanning tree does not allow a port to receive a packet and send it back on the same port. The answer is to eliminate the spanning tree restriction of not allowing a message to be sent back over the port it came from.

Spanning Tree and virtualisation

The second curve ball from virtualisation is ensuring that there is enough throughput to and from the server and that the packet takes the best path through the data centre. As the number of processors on the physical server keep increasing, the number of images increase, with the result that increasingly large amounts of data need to be moved in and out of the server.

The first answer is to use 10 Gigabit and eventually 40 or 100 Gigabit. This is a good answer but may not be enough since the data centre needs to create a very low latency, non-blocking fabric with multiple paths. Using both adapters attached to different switches allows multiple paths along the entire route, helping to ensure low latency.

Once again spanning tree is the problem. The solution is to eliminate spanning tree, allowing both adapters to be used. The reality is the new generation layer 2 switches in the data centre will act more like routers, implementing their own version of OSPF at layer 2.

Storage

The last reason new switches are needed is Fibre Channel storage. Switches need to support the ability to run storage traffic over Ethernet/IP such as NAS, ISCSI or FCoE. Besides adding support for the FCoE protocol they will also be required to abandon spanning tree and enable greater cross sectional bandwidth.

For example Fibre Channel requires that both adapters to the server are active and carrying traffic, something the switch's spanning tree algorithm doesn't support. Currently the FCoE protocol is not finished and vendors are implementing a draft version. The good news is that it is getting close to finalisation.