Recently, I was involved in designing a SQL2005 cluster. Let’s just say that it was going to have many more nodes until we found that we had to scale down to a 3+1 cluster because of drive letter limitation. The annoying thing is that even with a 3+1 cluster and with mountpoints used to the limit, we may still run out of drive letters.
With each node being a four-socket quad-core server, this 3+1 cluster would have 64 cores in total. Not a huge deal these days, but still quite a bit computing power nevertheless!
Since this a database consolidation environment, we want to be able to accommodate as many databases in a SQL instance as we practically and sanely can. That means fewer instances, and possibly better resource utilization. On the other hand, we want to be able to contain and fence the resource utilization of each application whose databases are hosted in this cluster. That means isolating their databases into their own SQL2005 instances and fencing the corresponding Windows processes with processor affinity and/or some kind of Windows resource management utility.
It’s common that many applications don’t need the computing power of all 16 cores. In fact, many applications may not even need two cores. But let’s assume that for capacity planning purposes, we’ll offer two cores as the minimum unit for a SQL2005 instance. So we can support up to 16 / 2 = 8 instances on each node. In this cluster with three node active, we can accommodate 3 x 8 = 24 instances. But wait! Each SQL2005 instance needs at least one drive letter, and the letter C is already taken. So we can’t really support 24 SQL2005 instances. In many environments, two or three drive letters are often reserved on each server, therefore, the practical number of available drive letters is probably 20 or less.
Now, in reality, to be serious, how often do you really want that many SQL2005 instances in a cluster? Probably not very often at all. But as computing power increases, it’ll increasingly become more likely. In fact, we were considering a 6+2 cluster before we realized that we probably didn’t want to go there because of the drive letter limit.
Is it insane to have this many instances in a cluster? If that’s the case, why does Microsoft continues to bump up the number nodes in a cluster? Even if the number of your instances in a cluster is well below the upper limit, you don’t want to later run into a situation where you have to migrate your instances somewhere else just to avoid running out of drive letters.
From a strictly system design perspective, drive letters are completely archaic and not cool. The restriction is artificial and a product of a primitive era. Okay, I don’t want to over do it here as what is cool to me may not be cool to you!
The strongest argument, however, is competition. When they can easily do 6+2 failover clusters, for SQL Server to be limited by drive letters, it is just an unnecessary distraction we can do without.