• Preetam Zare

My VVDS - Physical Design Considerations

Updated: Dec 13, 2019


pmz.local refers to their server rooms as Landside and Cityside. There is history for these names. If that interests you, you can check here (pending update).

Cityside DC has recently invested datacentre but it is not modern even if the name suggests as it was done without much planning. Landside was the first server room and has therefore always considered strategic.

How many zones and regions are considered in this project?

Can we fulfill the VVDS Zone criteria?

First design decision we need to make on the Physical Infrastructure design. pmz.local has two server rooms. These server rooms are separated by the distance of approx 1 KM and connectivity to each other with 10 Gbps links. The latency is 5 ms or RTT. Considering the benefits we get from Availability Zones (AZ) and since it meets the AZ requirement it is strongly recommended to use AZ.

As of today, there is no short term plan for the 2nd Region. But this design should focus on the ability to extend the Region. I have covered the characteristics of Region and Zone in this post.

Decision Decision

PDES001: Two AZ will be created

Decision Justification

To protect against

  • 1st level of failure of Landside DC / CitySide.

  • To Protect against the building/area where Landside DC / Cityside is located.

  • Increases your Service uptime.

  • Meets the requirements of the Firewall drill done twice in a year.

Design Impact

  • While provisioning VMs (SQL Always ON, Domain Controllers) we must separate the VMs using affinity rules. This is an operational overhead and will be covered in an operational Guide in detail.

  • Increases the solution Footprint as with two AZ, you must reserve 50% for the possible failure of AZ. This can be mitigated by categorizing VM availability. e.g. if these VMs are must be available in case site failure.

  • Categorizing of VMs is required and consequently, vSphere HA configuration needs to be modified.

  • Witness site is required to detect split-brain situation.

  • vSAN Stretch cluster, Enterprise license must be considered

  • SMP-FT VMs cannot be deployed as vSAN do not support this configuration on stretched clusters.

Additional Impacts

Following PDES001, it was decided to use AZ, we found the following challenges in Cityside DC

  1. No Proper cabling

  2. Limited Space

  3. No Rack Layout

The following section describes the problem in detail.

PD stands for Problem Discovered

PD01: No Rack Layout

Possible Solution: Without existing Rack layout, optimization is not possible. As a first step, the Rack layout needs to be prepared

Impact on the Project: Timeline is impacted

PD02: Devices are not racked in particular order

Possible Solution: Space optimization is required. Standard Rack layout framework needs to be proposed which could be aligned in VVDS where possible.

Impact on the Project: If we do not optimize Rackspace, the VVDS design principle to keep ToRs (Top of the Rack) are the exit of DC might not be met.

PD03: No Proper cabling

Possible Solution: Risk is associated with the Device movement. Labeling cabling is the third step to optimize racks by moving devices in the right places

Impact on the Project: Timeline is impacted

PD04: Limited Space

Possible Solution: Servers may not be properly stacked. After we complete the above 3 steps, we can find better options.

Impact on the Project: Timeline is impacted. Also, it is not possible to get Readymades Solution (e.g. VxRack) in CitySide DC due to limited space.

Decision Decision

PDES002: No Region to be considered

Design Justification

At this stage focus is on AZ, the region i.e. DR scope will be considered in the future. Design decision which can add constraints to extend or add Region for DR must be highlighted during the business cycle.

#VVDSPost01, #VVDS


Recent Posts

See All

©2019 by virtual2Cloud. Proudly created with