Latency within the Data Center (3rd Part on Latency)
In September’s Wired magazine, there was a great article titled Raging Bulls. This fabulous, well-articulated article focused on the world of high frequency traders. In short, this is a form of electronic stock trading where simply making $.00001 per trade is a very profitable business. This requires the need to make tens of thousands of trades a second with true micro-second latency. The IT group of high frequency traders truly understands the need for lower latency within the data center. As we at PeakColo look to build truly enterprise class-IaaS, we must not only look at stability but performance and performance guarantees. Latency is seen in all aspects of infrastructure and I would like to key in on differentiators we have either tackled or are tackling for some of the most demanding customers in the world:
Storage: On the storage front I like to break down disk access and network as two separate points of contention.
First, disk access is very complicated and no solution truly meets all. With that said, there are many ways to tackle it but to cut to the chase understanding your latency requirement is paramount. If your application writes thousands of small 1kiliobyte writes every second or several large writes of thousands of kilobytes you require completely different storage profile. If your Cloud provider believes they have a one storage solution that meets all your needs or only talks in RAID types, they are missing the boat all together for production application. Matching spindle type (Sata/Sas), speed (5400,7200, 10k, 15kRPMS) and SSD (MLC,SLC) mechanisms for network storage is only the start.
Second, Latency of the network must be considered. Small transactions may require local storage due to this latency. One may need to dive deeper and dissect network storage mediums, the older adage about Fiber channel being faster than standard Ethernet is no longer the case. New 10GB cut through switches actually move the smaller Ethernet payloads through the actual switch at nearly half the speed of 16GB fiber channel. No provider should be able to do it all but their ability to address what there solution is great for and options for what it’s not are paramount.
Thirdly, one must look at the paradigm of virtual network traffic moving east to west between VM’s and associated virtual services such as firewalls, load balancers, data base servers, and everything else seen in the typical enterprise physical data center. I sat on a recent panel where a competitor talked about 1GB into the server and the virtues of trunking these ports together instead of implementing underutilized 10GB ports on the host. The competitor missed the point that the 10GB ports provide a level of latency reduction which is all but required in highly virtualized environments. When one host can handle 10-100s of virtual servers, it’s not the aggregate throughput in volume but latency which allows applications to perform as good or better when compared to their physical counterparts.
Finally, there is the topic of latency of CPU and processing. I make several analogies when talking about our AMD and Intel workloads and how one may capitalize on their unique values. Although Intel presents a fewer core per socket alternative to AMD solutions, they do present far faster core and RAM speeds. My favorite analogy is the Ferrari and the Bus: The Ferrari (Intel) is the preferred platform for getting a small discrete work load from point A to point B the fastest such as database servers. Where the bus (AMD) is great at getting many general workloads from Point A to B in a good time as measured in a whole against moving all these general workloads in the Ferrari at comparable costs! (think Virtual Desktops)
Next article I will dive into the effect of latency when dealing with services between data centers.