In a recent post, the case was made for companies with modest data center needs to explore co-location.
We made our case and the executive team agreed. Having an agreed upon direction, it was now time to do something. And the client was stumped.
“Let’s go visit them,” the enthusiastic client espoused.
We would recommend visiting a couple to ground yourself in some of the various dimensions…and then would quickly go back to a conference room to understand requirements.
“Our systems are important. We need to put everything in a Tier 4 data center.”
The ANSI/TIA-942 standard defines the concept of Tiering, as a way to distinguish design considerations. The standard is quite lengthy, and is summarized below. You’ll see “N” mentioned. “N” stands for NEED….and is always debated since everything else drives from it.
|
|
Tier 1 |
Tier 2 |
Tier 3 |
Tier 4 |
|
Delivery Paths |
One |
One |
One Active One Alternate |
Two Active |
|
Capacity Components of Support |
N |
N+1 |
N+1 |
N after any failure |
|
Points of Failure |
Many + Human Error |
Many + Human Error |
Some + Human Error |
Fire, EPO & Human Error |
|
Yearly Downtime |
28.8 Hours |
22.0 Hours |
1.6 Hours |
0.8 Hours |
|
Site Availability |
99.67% |
99.75% |
99.98% |
99.99% |
While there are some commercially available Tier 4 co-location facilities, unless there is a specific business requirement, we find most co-location facilities at a Tier 3 level provide the kind of availability one would expect for a paid service. The yearly projected downtime between a Tier 2 and a Tier 3 is substantial (don’t assume the “yearly downtime” happens once a year. For example, what if it worked out the 22 hours (Tier 2) was spread over a year in weekly increments? While the facility would be hitting its uptime goal, your systems outage time (quiescing applications, database, and systems, rebooting, then bringing up systems, databases and applications) could add to hours each week!)
With a good understanding of the capabilities available and your business needs, a Request for Proposal (RFP) can be put together.
Putting together an RFP can be a fun task, or maddening. The key to the RFP process is using the development period to driving alignment of the company parties.
At the most basic level, the RFP should cover:
There is a fine balance in writing RFPs. Companies need to be specific enough deliverable solutions can be proposed, yet broad enough to allow creativity.
For example, one area driving costs in RFPs is around power/cooling. The company needs to identify what the heat load is of the equipment envisioned to be placed, in kilowatts (kW).
If the company is running a dense environment, it is tempting to express this in watts per square foot (W/SF)
When W/SF are used, some providers may be automatically “disqualified.” How? A data center designed for 50W/SF can indeed support 100W/SF….it just takes twice the space and appropriate chilled air distribution!
So smart companies analyze their needs, and let the co-location providers respond.
Philosophically, we prefer shorter RFPs to longer ones. Providers need to have time to put together responses. If the RFP is “too big, too heavy,” some providers may not respond at all or will respond generically with their capabilities, while not answering the underlying questions in the RFP.
Once the RFPs hit the street, you need to put a cone of silence on vendor conversation at ALL levels.
Next week, we’ll talk about how to analyze the responses.
Have a favorite RFP story? Share it with the community. We’d suggest masking company names…