Common VCDX Mistakes: A02: Enough bandwidth between Datacenters

Continuing on from yesterday’s post: Common VCDX Mistakes: R01: Customer Requires N+1 I have another common VCDX mistake for you.

A02: Enough bandwidth between Datacenters

I’m not limiting this post to just the assumption example above, however, this is an example I’ve seen soo many times in designs that contains more than a single datacenter.

If you have a multi-datacenter design and you rely on the flow of data between DatacenterA and DatacenterB, whether it’s for storage replication or for BC/DR or both, you CANNOT assume that the connectivity between the datacenters will be adequate. You have to ask yourself, “what will happen if there isn’t enough bandwidth between the datacenters?”.  I’m sure your answer to that question will be; “Data replication will fail” or “site failover will take longer than required the RTO” or something similarly detrimental to the success of the design.

It’s at this stage you actually need to do the groundwork to find out if there is indeed enough bandwidth between the datacenters. To figure out how much bandwidth you actually need, you need to consider many different data points including, but not limited to; data change rates, Recovery Time Objectives (how quickly do you need the data transferred). In addition, you should also factor in, other traffic utilizing the connection, is QoS/CoS configured? as this may limit your data flow speeds. It’s a difficult number to calculate. We don’t expect it to be perfect, but we need to see that you’ve actually given this critical aspect of the design some thought and haven’t just added it to the Assumptions table (AKA ‘Too difficult pile’)

Some other typical Assumption I see regularly include:

  • The customer has NTP running throughout the environment
  • Support staff will get the necessary training to support the new technologies implemented
  • Sufficient Rackspace, Cooling and Power is available within the Datacenter

If you have ANY assumptions in your design, ask yourself, “What would happen to my design if my assumption is incorrect”. If the answer to that question is, “your design might no longer meet the customer’s requirements”, as an Architect, it is your responsibility to find out. And once you know the answer to your assumption, it is no longer an assumption! For some futher reading on my thoughts around assumptions take a read of an earlier post I wrote: VCDX – Why Assume Anything?

As usual, these are my own thoughts, and may not be shared by other VCDX panellists. If you are interested in my thoughts, you can either subscribe to my blog or follow me on Twitter to keep an eye out for new posts.

Feel free to discuss in the comment section below.

  • Jeffrey Kusters

    I think a lot of people misinterpret assumptions in a design and use it to put certain elements of the project out of scope. If you specifically discussed the risk of the support staff not being properly trained but training is not in scope of your project, I think you should identify it as a risk and place it explicitly out of scope. Lots of times people just put in an assumption and be done with it.

    Speaking of risks, the question you stated about askingbyourself what would go wrong is a assumption is incorrect, should always be addressed in the risks table, with mitigation. After all assumptions are uncertainties and uncertainties lead to risks 😉

    Just my 2 cents!

  • Great points Jeffery. “all assumptions are uncertainties and uncertainties lead to risks”. Spot on.

 
Get Adobe Flash player