Category Archives: Architectural Decisions

How much detail to include in a VCDX Submission

Posted on by
Reply

Today I saw a conversation on Twitter where a VCDX candidate was asking about how much depth to go into for a VCDX submission (see tweet below)

vcdxdetail

I think this is a great question and one which I am asked regularly as a VCDX mentor. I responded with the follow tweets.

Tweet 1:

vcdxdetail3

Tweet 2:

vcdxdetail4

Since the information I provided was well received (see below), I thought a quick post was in order so others can benefit.

vcdxdetail2

My advise to VCDX candidates is as follows:

1. For any significant design decision made, document the decision in an Appendix in a similar format to the examples in my VMware Architectural Decision Register. This includes “Problem Statement”, “Assumptions” , “Motivation” , “Decision” , “Justification”, “Alternatives”, “Implications” and “Related Decisions”.

2. Include cross references in the design to the detailed design decision in the appendix.

3. Ensure each design decision has multiple “Alternatives”

4. Ensure you have thought through each “Alternative” and have a deep (and equal) understanding of the Pros/Cons of each.

5. Cross reference the design decision back to customer Requirement/s , Risk/s , Constraint/s , Assumption/s.

6. Ensure you know each of the design decisions like the back of your hand before the defence.

7. Pick 3 to 5 key design decisions to cover off in detail during the defence which allow you to demonstrate expertise, for example, a decision which goes against best practice and can be justified would be a good place to start.

Best of luck with your VCDX journey!

Related Articles:

1. My VCDX Journey

2. The VCDX Application process

3. The VCDX candidates advantage over the panellists.

4. VCDX Defence Essentials – Part 1 – Preparing for the Design Defence

5. VCDX Defence Essentials – Part 2 – Preparing for the Design Scenario

6. VCDX Defence Essentials – Part 3 – Preparing for the Troubleshooting Scenario

Example Architectural Decision – Port Binding Setting for a dvPortGroup

Posted on by
7

Problem Statement

In a VMware vSphere environment using Virtual Distributed Switches (VDS) where all VMs including vCenter is hosted on the VDS, What is the most suitable Port Binding setting for dvPortgroups to ensure maximum performance and availability?

Assumptions

1. Enterprise Plus Licensing
2. vCenter is hosted on the VDS

Requirements

1. The environment must have central management of vNetworking
2. All VMs must be able to be powered on in the event of a vCenter outage
3. Network connectivity must not be impacted if vCenter is down.

Motivation

1. Reduce complexity where possible.
2. Maximize the availability of the infrastructure

Architectural Decision

Use the default dvPortGroup Port Binding setting of “Static Binding”

Justification

1. A dvPortGroup port is assigned to a VM and reserved when a VM is connected to the dvPortGroup. This ensures connectivity at all times including when vCenter is down.
3. Using “Static Binding” ensures the vCenter VM can be powered on and connected to the dvPortGroup even after a failure/outage.
4. “Static Binding” is the default setting and there is no reason to modify this setting.

Implications

1. The number of VMs supported on the dvPortGroup / VDS is limited to the number ports on the VDS (not overcommitment of ports is possible).
2. Number of ports configured on a dvPortGroup should be greater than the maximum number of VMs required to be supported.
3. Port Allocation should be left at the default of “Elastic” to ensure the number of ports is automatically expanded if/when required.
4. New Virtual machines cannot be powered on and connected to a dvPortGroup (VDS) when vCenter is down.

Alternatives

1. Set dvPortGroup Port Binding to “Dynamic binding”
2. Set dvPortGroup Port Binding to “Ephemeral binding”

Related Articles

1. Distributed vSwitches and vCenter outage, what’s the deal? – @duncanyb (VCDX #007)

2. Choosing a port binding type in ESX/ESXi (1022312)

Example Architectural Decision – Horizon View Desktop Power Policy for Linked Clones (1 of 2)

Posted on by
Reply

Problem Statement

In a VMware Horizon View environment using persistent Linked Clones, Disposable disks are being used to redirect transient paging and  temporary files to a separate VMDK.

What is the most suitable Desktop Pool setting to ensure storage overheads are reduced?

Assumptions

1. VMware View 4.5 or later
2. Recompose / Refresh cycles are infrequent
3. Desktop Usage concurrency within the pool is less than 100%
4. Memory Reservations are not being used.

Requirements

1. The environment must deliver consistent performance
2. Minimize the cost/utilization of shared storage

Motivation

1. Reduce complexity where possible.
2. Maximize the efficiency of the infrastructure

Architectural Decision

Set the Power Policy for all Linked Clone desktop pools to “Power Off”

Justification

1. Using disposable disks can save storage space by slowing the growth of linked clones and reducing the space used by powered off virtual machines.
2. Using the “Power Off” policy for the pool means at user logoff (or shutdown) the disposable disk will be refreshed, therefore reducing the capacity usage at the storage layer.
3. “Powered Off” VMs do not have a Virtual Machine SWAP file which will also reduce storage consumption.

Implications

1. Setting the policy to “Power Off” will result in more frequent power operations which may impact the performance of the storage and vCenter.
2. When a user attempts to login to a desktop which has been powered off, there will be a delay while the VM is powered on and booting up before the user will be logged in.
3. The peak concurrency rate of users will need to be understood to allow accurate storage planning for the VSWAP file.

Alternatives

1. Increase the frequency of Recompose / Refresh / Rebalance operations
2. Set the Policy to “Take no power action” and schedule an Administrator task to periodically change the Power Policy to “Powered Off” during a maintenance window.
3. Set the Policy to “Ensure desktops are always powered on” and schedule an Administrator task to periodically change the Power Policy to “Powered Off” during a maintenance window.
4. Set the Policy to “Suspend”  and schedule an Administrator task to periodically change the Power Policy to “Powered Off” during a maintenance window, however this will consume extra storage for the Suspend File.
5. Use Memory Reservations to reduce storage requirements for vSwap and leave Power Policy to “Always On”.

Related Articles:

The example architectural decision was contributed to by Travis Wood (@vTravWood) and was inspired by the following article:

1. Understanding View Disposable Disks by @vTravWood (Double VCDX #97 Desktop/Datacenter Virtualization)

1. Transparent Page Sharing (TPS) Configuration for VDI (1 of 2)

2. Transparent Page Sharing (TPS) Configuration for VDI (2 of 2)