©2019 by virtual2Cloud. Proudly created with Wix.com

Search
  • Preetam Zare

My VVDS - ESXi Host Physical Design Specifications

In the last two posts (Post01, Post02), we discussed the physical designs aspect and Servers and Clusters placement in Racks. Here we are discussing Hardware selection for ESXi host and other critical aspects.


Like many implementations, this is not a greenfield environment. The IT Infrastructure is already present and few of the infrastructure hardly a year old. We have to make a decision on how the existing infrastructure could be utilized optimally. In VVDS, vSAN is the default choice but it also states you can design the infrastructure using other storage types.


Customer Environment

The customer has built Virtual infrastructure on VCE vBlock 240. The popular vBlock240 is running both VDI and Server infrastructure. For VDI Infrastructure customer has XtremIO 20TB Brick and for Server Infrastructure VNX 5800.


Design Decision

PDES005: New VI Infrastructure will use vSAN Ready Nodes

Design Justification -vSAN

  • Existing Hardware is out of support and hence cannot be reuse.

  • Also, the new VVDS AZ design cannot be met by Existing Hardware. As mentioned earlier Cityside was a pure expansion of Landside DC. Workloads are placed in Cityside only because Landside DC did not have adequate space.

  • The choice of vSAN based HCI was more a vendor choice. Nutanix option could not be considered as existing foot print ist mostly VMware based. With Nutanix, steep learning curve would be involved.

  • Journey to Hybrid cloud is uncomplicated with VVDS design Framework.

  • For AZ total 4 Fiber Channel Switches would be required stretched across AZs. Complicating Zoning and dedicated traffic between AZ1. We would require a new storage design to meet AZs requirements e.g. Metrocluster. With vSAN, this is comparatively simple to design, implement and operate.

Design Implication

  • VSAN becomes a default HCI platform for future.

  • The traditional FC model will eventually get decommissioned. Hence the existing resources need to be trained on vSAN. This will be considered under operationalise phase of vSAN.

Other Options Possible

  • Continue to use Traditional FC model with metro cluster design

  • Using other HCI technology

Design Justification -vSAN Ready Nodes

  1. Ready Nodes are tested by the vendor and ensure it meets vSAN requirements on various aspects like controllers, SSD and Network card

  2. Standard sizing tool available on VVDS. It will reducing the design cycle time.

Design Implication -vSAN Ready Nodes

  1. Ready Nodes comes you cannot change all parts, it limits expansion of nodes. The specific guidelines must be followed to remain support

  2. vSAN Ready nodes, especially in this Dell, do not support LCAP on ToR.

  3. vSAN Ready nodes when deploying NSX-T dedicated NICs must be used as VDS and VDS-T must go on separate NICs. Reference: Here

More to come, I will update on implications

4 views