My ramblings about all things technical

Due to my decision to aim for my VCDX6-CMA this year and thereby to get it submitted in time for the only VCDX-CMA defence of the year (so far) I have had to sign up for the VCAP6-CMA Design beta exam. I’ve been working on a very large-scale vRA 6.2 project for the past 14 months and so I hope this experience of designing and building it as well as my preparations via these objectives breakdown(plus my study resources) and using some of my VCDX5-DCV knowledge will help me. So I thought I would slowly post up each objective for my own benefit but also hopefully help other people looking to pass the VCAP6-CMA Design exam (beta or GA).I will be consolidating all the objectives on my blog page here.

Knowledge

Associate a stakeholder with the information that needs to be collected.

This is down to the questions you need to ask and also who you need to ask these questions. These questions are ones you are going to ask during the design workshop for the design/project. For the workshop you need to make sure you have the applicable project participants/stakeholders who can join the workshops (depends if you want one big one where people come and go at certain points or multiple ones where you speak to each business unit/ team). For the stakeholder meetings/design workshops I personally like to try bring in the following people, this does vary depending on the project and what has been chosen but 9/10 times these are the people you want to speak to:

Virtualisation administrators (if applicable. If not already present then future administrators of the solution)

Server Hardware Administrators

Backup Administrators

Storage Administrators

Desktop/OS Administrators

Network Administrators

Application Administrators (these are very important as their applications may have very specific requirements)

Security Officer

Project Sponsors

End users/ Developers/ Help desk personnel (this I find is helpful to find out what are the current support desk tickets/problems the company are facing and if these will impact the project in any way. Also these discussions are easy to have in the hallway/over a coffee but have alerted me to unknown risks that would have severely impacted the design and delivery)

Utilize customer inventory and assessment data from the current environment to define a baseline state.

This is a really strange one for a vRA design as this normally applies for a vSphere design where you are possibly migrating workloads into a new environment but I’ll take this as possibly an assessment of the current vSphere estate and if it is a fit for the customers’ requirements from vRA. This is still conceptual so basic things like sites connectivity possibilities if they want off site DR or stretched clusters.

This could also mean the workloads being created on the vRA portal as catalogue items are currently workloads running somewhere and an analysis of these to determine possibly sizing metrics to have for example 1000 of a certain developer workstation in the vRA environment is a possibility. Also if the workstations all require isolation from each other for something like CD/CI then you will know you will need Level 4-8 capabilities to provide this isolation from NSX or Palo Alto for example.

· I think this is fairly straight forward as from the design workshops and interviews you have collected what their objectives are and also ensured from all the workshops there are no obvious conflicts of people’s plans for the solution they want you to design. A “normal” customer objectives piece would be:

Customer XYZ has embarked on a strategy to increase extensively the level of automation and the rate of virtualization of data centre services. The intention is to enable application and system owners to consume on demand services as a catalogue-based service through a web portal. By initiating this project, XYZ aims to create a platform for IT service delivery that:

Is cost-effective through improved resource utilization with the use of cloud management software.

Can host 1000 developer workloads.

Increases agility through the use of automation and virtualization provided by cloud management software.

Is accessible through the use of their custom XYZ-Cloud portal for the consumption of IT Services.

Customer XYZ has chosen VMware vRealize™ Automation™ to provide their Infrastructure as a Service (IaaS) and Platform as a Service (PaaS).

Given results of a requirements gathering survey, develop requirements for a conceptual design.

Again this should be relatively straight forward for anyone as you’ve now spoken to all the applicable people and have taken down all their requirements and ensured there are no requirements conflicts. Requirements have to be very precise so that there is no misinterpretation that could cause scope creep and it forces you to ensure you know exactly what the customer requires and that they validate this as correct before you start the logical design. For example a requirement of “Customer wants high availability” is far too vague as everyone might have a different understanding of what high availability means. Your requirement should be “Customer wants 99.99% availability for the front end portal and 99.9% availability for consumer workloads outside of scheduled maintenance windows”. You would also include RPO and RTO values for these in my opinion in subsequent requirements so that SLA mapping is clear.

Categorize business requirements by infrastructure quality to prepare for a logical design.

I’m glad this is mentioned here as for the VCDX they are very big advocates for mapping your requirements to the infrastructure qualities. If you don’t know what the infrastructure qualities are they are:

Availability

Manageability

Performance

Recoverability

Security

So for example my previous concise requirement would fall under Availability, application of PCI/SOX/Hardening guidelines would fall under security, and ability to run the 1000 developer workloads would be performance.

This is also very helpful if you are doing requirements mapping from the conceptual requirements to the logical design decisions to the physical design decisions.