Sounds like one thing you can use is a model to help communicate the details of the problem to everyone involved. Most IT people don't understand that there are many interrelated capacities within a data center. The uninformed person will expect to be able to fill up the server racks with whatever they can afford until the server racks are full, and disregard things like power, cooling, weight, and cabling. Also, overall capacity means little if that capacity can't be delivered where it's needed, so distribution of these resources needs to be considered, as well. It's not obvious to many people that space and money are only two of a data center's manageable (and exhaustable) resources. A good growth plan will take into account all of the variables, identify constraints and propose plans for replenishing resources when they run out.
In our case, to cut through the confusion when planning our latest data center upgrade, we stopped trying to enumerate all of the variables -- kW, BTUs, square feet, network ports, rack units, etc. -- at once. Instead, we devised a standard planning unit based on our "average" server. In our case this device uses 2 rack units, weighs up to 50 lbs, has two power connections, consumes 400 watts, has up to 6 network connections, etc. Our baseline identified how many of these theoretical devices we currently had installed -- and gave people one number to quantify our current equipment portfolio -- and our growth projections revealed where the resource limits were in our infrastructure, when we would hit them and allowed us to discuss ways we might address the shortages. This was a very useful and informative model for everyone and allowed us to plan a major data center upgrade with very little frustration. Your standard building block will probably be different, but the concept may work for you, too.
Ken
Okay, glad to see someone else that was pretty much thinking what I had been thinking. We pretty much do the same thing here where we have a relatively standard plan where we provide quarterly audit projections on where we think capacity is. The introduction of doing mass virtualization introduces a new variable where it's difficult to adequately plan because no one is clear on the level of utilization for the various chassis.
What I did was map it on a worst case scenario but justifiably because we have a tendancy of taking things to the max and extreme in terms of application. In other words, we generally tend to push things to their limits in terms of interfaces. So if something has the capacity of 20 interfaces we pretty much use them all.
What I was thinking was establishing a baseline according to the power usage, BTU, and a set maximum number of connections allowed for each rack. The max connections may not be proportional to the power usage and BTU output, but that would provide me some ensurances that I won't have to deal with runaway bulk cabling.
What do you think about limiting the number of cable connections per rack? Let's say 48-72 (if it's even a good idea to begin with)? I'm more partial to 48.
What do you think about limiting the number of cable connections per rack? Let's say 48-72 (if it's even a good idea to begin with)? I'm more partial to 48.
I agree that you should establish a cabling limit and identify other limits you may run into as you grow. In our case, we set an absolute limit of 96 cables per rack, but recognized that all racks couldn't have that many cables without overloading the cable trays for the rows. You probably have limits in your rows or zones that introduce similar constraints.
We only run copper to the server racks at this point, and our 96 cable limit was based on Cat5E. Now that we see how recalcitrant Cat6A is, I think that limit will have to be lowered to remain practical.
