Why Network Bandwidth Matters in Cloud Hosting
One of the elements that have been closely discussed with the introduction of cloud hosting is multi-tenancy. This is when more than one non-related resource is allocated on the same hardware. A good example of this are VM instances that are running on the same servers sharing CPUs, memory and network adaptors. In the case of SaaS (Software as a Service), multi-tenancy is created when your have more than one client sharing the same application while making sure that the data is properly partitioned.
But when you have a tenant who behaves badly, the other tenants who act in good faith can find themselves starved out when there are controls lacking to limit the consumption habits of their neighbors. Sadly, this can happen all too easily. Often the limits are not enforced when the hosts believe they can easily scale up or down as needs arise. This is, after all, one of the big promises of cloud hosting.
Unfortunately, not all resources are created equal and so they also do not scale equally. Any re-allocations from the pool could result in a negative impact on the other tenants’ ability to scale as well. The area that is often forgotten in this scenario is bandwidth. While CPU time or memory can quite easily be controlled, the bandwidth process can be much harder to control for each tenant. Sometimes this can result in a denial of service to other tenants because they are sharing the same switch or running on the same network adaptor.
It is important for any cloud adaptor to remember that anything in the cloud needs bandwidth. So in addition to taking care of client requests, your client requests generate traffic which consumes bandwidth. In the end it doesn’t really matter if the traffic is created by communication with the storage network, database, or application servers. You could have the hypervisor substrate reallocating and balancing loads, they all take up bandwidth. The bottom line is there are limitations to the network, physical ones that can be as simple as fiber-based connections. It is rare for anyone to measure or understand the aggregate network load created by one tenant within the multi-tenant architecture and in many situations being able to directly access a particular network load may not even be possible.
So beyond how this affects performance, why should we care? Well, if you are designing solutions for the cloud, you need to be sure that you test your production environment’s real operating performance and not just count on the specs given by your host provider. A machine instance with two-cores operating at 2.5Ghz, 2048 megabytes of RAM, 500 gigabytes of disk space and 1 gigabyte network adapter does not equate 1:1 performance. Testing is imperative while the application is running in this environment. Of course, you still cannot assume it will run in real life the way it ran in a test environment. So be sure to also obtain average IOPS for storage, and average bandwidth over a reasonable amount of time, and always look at your response times around key processes. This should give you the minimum needed to assess.
Our newsletters and blogs are written to provide you with tools and information to meet your IT and cloud solution needs. We invite you to engage in our online community by following us on Twitter @GMOCloud and ‘Liking’ us on Facebook.
