Welcome to cloud computing with arms wide open… wait let us also welcome bundle of problems which comes with it. One of the key problems that we face in virtualized storage world is ‘Noisy Neighbor Syndrome’ (NSS). There are lot of explanation and solution available in the internet. But I want to explain in my own way 🙂
Noisy neighbor syndrome is like our Pakistan… A rogue country that intermittently attacks neighboring country India causing pernicious effects to latter and to all other surrounding nations to create a worst environment or situation.
In IT, Noisy Neighbor Syndrome is rogue virtual machine (VM) that intermittently corners SAN resources to bring down performance of rest of the VM which are using same SAN in the environment.
Let us find the solution for IT’s version of noisy neighbor syndrome which can be controlled compared to our rogue neighbor. Both India and Pakistan got their Independence from British in 1947. India reached Mars via ‘#Mangalyaan’, while Pakistan still trying to enter India via ‘Terror-ON’.
Now, lets get back to solving the problem in our hand. For any problems there are two ways of approach 1. Prevention 2. Solution
Capacity planning is the best bet to avoid Noisy Neighbor Syndrome (NNS) in the environment. Capacity Management (CM) team need to be well aware of critical applications, infrastructure and configuration limits of hardware and software products in the environment. A good architect always starts with thorough understanding of existing infrastructure before proposing them to move on towards cloud infrastructure. While doing this he/she would do proper sizing adding sufficient buffer to accommodate future IO growth or bust mode IO which causes sudden surge in IOPS requirements.
There are lot of solutions available to tackle this problem effectively based on customers capacity of investing on to it.
i. Better Network connectivity: Use of high end enterprise storage hardware and SAN directors which would scale up and scale out with fastest network inter-connectivity; minimizes the performance issues. Also, using devices like WAN application services (WAAS) improves end to end performance.
ii. Quality of Service: Setting configuration limits per VM @ ESX and IOPS limit per host entries in storage would restrict rogue VMs to snatch other VM’s chunk of IOPS / resources. We would draw a line and create boundaries based on application categorization and more importantly its customer willingness to have costly services by opting for it . Industry’s top storage products from #EMC, #HDS, #IBM do offer these cutting edge features.
iii. Unity of hypervisors and storage controllers: Storage controllers would pose a porblem due to its configuration limits in terms of front end adaptors speed, caching techniques and capacity and backend controllers and disk speeds. These details are not made aware to the hypervisors which simply push the I/O request from the apps. We need to have a product which can unite both hypervisor and strorage controllers (Say Hello to EMC #VMAX3). Let them be an entity which would provide information of configuration limits of each other. This helps IT architects to develop solution to create best cloud environment.
There is more power in unity than division. ~Emanuel Cleaver
Above quote applies to both type of NSS 🙂
Image courtesy: http://files.abovetopsecret.com/