Was just doing some work mapping out our storage requirements in our main datacenter as we are about to setup a DR for a second datacenter along side our current production environment.
The problem we have at the moment, is we have an excessive amount of Raw Device Mappings in our evironment, which means we currently have well in excess of 100 Luns in use.
The environment we are about to mirror (which will also reside in VMware) is also likely to have in excess 100 Luns. Which as a end result, leaves us extremly close to the 256 Lun Maximum per host that exists in 4.1.
Given how heavily storage is utilised in a VM environment, do we see this being something that VMware is likely to add support for an increased number of luns per host? The environment we run wouldnt be classified as "Massive", especially when we are only talking 30 VM's across 18 hosts currently.
Id be interested to hear feedback on this. Im working very hard to scale back the number of luns we are using, as it appears this was not taken into adequate consideration when the current system was deployed.
Not sure on the configuration maximum increases during point releases, but if you could share with us why you need so many RDM's the community may be able to come up with an alternate solution for your problem.
So you are saying that all of your hosts can see all LUN's from your entire storage solution?
I believe this is a limit of the storage protocols in use. 256 is the miximum number of LUNS on a single target in the physical world and i suspect that this limit is due somehow to the way the Hypervisor sees storage. I am more concerned that you have so many RDMs and are planning to mirror a DR site, will these hosts see the DR volumes and their own production volumes simultaeneously? i had a customer with a similar deployment method once they got over 100 LUNs they started to get hit with Disk Timeouts, these were due to the length of time it was taking to rescan the backend when ever storage changes were made.
RDMs were common place a couple of years back where servers had come from physical to virtual and brought their legacy apps that required "physical RDM" to be able to Quiesce applications and provide consistent replicas. However the world moved on and most applications are now Virtual Aware and as such no longer have the RDM dependency. I'd recommend looking at the reasons why it is setup the way it is, what are th ebusiness drivers that dictate this and then go to the owners/app vendors and fuind out what they can do to allow you to produce a more manageable environment.
Think, more LUNs = more to manage, also how many of those LUNs are being fully utilised? how much storage capacity is wasted that could be recovered by changing to Thin Provisioned VMDKs?
Thx for the feedback guys. We are running a small-medium size SAP environment across VMware, and (for reasons prior to me) the current storage architecture is to assign a new lun and create new oracle files everytime the database outgrows available space. Im planning on investigating how to remove the large lun requirement sometime in the new early new year as at our current rate we are going to run into problems relating to running out of available luns. Additionally the luns are used as RDM's instead of VMDK's for performance and clustering reasons.
Once again thanks for all the feedback, im aware our current environment is way to heavy on lun requirements and its a priority im working on addressing to remove this.
On a side note, if anyone has links to calcuting IO throughput across vmware/fc/rdm/etc id greatly appreciate it.
vSphere 5.0 is just is beta period, but all people are under NDR.
But some limits will remain the same as the current version.