Tag Archives: VMware

Sprint to VCIX (Part 4) — Determine Requirements, Constraints, Assumptions, and Risks

We are going to wrap up the conceptual design by categorizing the assessment findings into requirements, constraints, assumptions, and risks (RCARs).

Section 1 – Create a vSphere 6.5 Conceptual Design

Objective 1.3 for the VCAP-DCV Design exam is to Determine Requirements, Constraints, Assumptions, and Risks. vBrownBag hosted a 52-minute discussion on Objective 1.3 for the Design exam:

I think Rebecca Fitzhugh did a great job in the presentation. Personally, this is the most difficult part of the material to really lockdown. Throughout the vBrownBag series, many of the presenters do short quizzes on determining whether a statement is a requirement, constraint, assumption, or risk. Even at the writing of this article, I still spend quite a bit of time thinking about it. I have a management and design background and I still have to pay attention to the specific definitions of each concept.

“Determining the requirements, making and proving assumptions, determining constraints, and identifying risks forms the conceptual design and provides the foundation to build on for the logical design. Business and technical design factors that are identified as part of the conceptual design will be mapped to the resources that are necessary to satisfy them during the logical design process. The conceptual design phase is highlighted within the overall design and implementation flow diagram:”

VMware vSphere 6.7 Data Center Design Cookbook

The conceptual design is the combination of documented requirements, constraints, assumptions, and risks. It organizes design factors and qualities into a comprehensive reference for the rest of the design process. With a high-level diagram, the conceptual design is the foundation for design decisions.

Differentiate between the concepts of Requirements, Constraints, Assumptions, and Risks

Requirements

There are two types of requirements: functional requirements and nonfunctional requirements.

Hersey Cartwright, one of the authors of VMware vSphere 6.7 Data Center Design Cookbook, outlined a simple explanation of functional vs. nonfunctional requirements in a Reddit reply:

“From a very high level the way I look at it is a functional requirement is the WHAT and a non-functional requirement (or constraint) is the HOW the WHAT has to be accomplished. Functional requirements are the things the design must do. A non-functional requirement would be a constraint on HOW the design meets the functional requirements. A customer specifically noting something does not change the type of requirement (functional or non-functional). A design must satisfy both the functional requirements and non-functional requirements.

Providing N+2 redundancy to support a failure during a maintenance operations (one thing in maintenance and one thing fails) is functionality the design must provide. Splitting a hair or two here, the better way the requirement might be listed is: Provide the redundancy to support a failure during a maintenance operation(WHAT). Then you might list N+2(HOW) as a constraint due to the level of redundancy the design must provide (WHAT). In a customer design I (and this is a personal thing) probably would not separate it like that – though it would probably be more correct when aligning directly to the VMware Design methodology.”

Hersey Cartwright, Reddit

Functional

WHAT must be done? A functional requirement specifies a function that a system or component must accomplish. Rebecca gives an interesting perspective in the video above: “The business can’t function…without meeting this requirement.”

  • Business goals, rules, or policies
  • Legal, regulatory, certification, and compliance requirements
  • Reporting requirements
  • Data Retention
  • Audits Trails

For example:

  • The design will store and transact customer PHI so it must meet HIPAA compliance
  • The design should allow for auditing of all user actions within the compute systems
  • The design must allow for backups

Non-Functional

HOW must the WHAT be done? A nonfunctional requirement defines how the design accomplishes the functional requirements. These are descriptions, usually categorized as a design quality.

  • Availability
  • Manageability
  • Performance
  • Recoverability
  • Security

For example:

  • The patient PAC and EMR databases need to store up to 1000 patients’ records
  • The auditing system must be able to retain logs for at least 90 days
  • The backup storage system must be able to de-duplicate the data by at least 3x

Constraints

“Constraints limit design choices. If multiple options are not available to make a design decision, then it’s a constraint.”

VCAP6-DCV Design Objective 1.3 with Rebecca Fitzhugh

Pre-existing vendor relationship/contract seems like a common stated constraint in the vBrownBag series and other resources. The vendor lock-in eliminates many design possibilities and features that could be made with freedom to go with another vendor.

Personal Thought: To me, most constraints are rooted in cost. If there was an unlimited budget, then you could forgo most constraints. This is how I differentiate between a nonfunctional requirement (often a constraint-ish statement desiring a specific quality — AMPRS) and a true constraint — the cost origin. The nonfunctional requirement is usually a constraint on the design with a feature or quality requirement that has room for decisions, whereas a constraint is a fixed limitation due to some unacceptable cost to the business.

In my mind, that alludes to the largest constraint, project budget. Every project will have a budget and the design will be constrained by how much money can be spent on the solution.

Other constraints I’ve seen have to do with business policies that dictate very specific technical methods: must use VPN to access internal resources, encryption standard/key lengths.

This is where I think people talk themselves into fitting things into one category or another while applying their own assumptions about a statement without being able to ask questions. As a test-taking strategy, I think it is important to make sure you do not read into the question too much and get yourself confused.

  • I think, on the test, the statement “External access must be through the standard corporate VPN,” by itself, is a constraint. Take it for face value and do not add your assumptions or experience.
  • In an actual customer engagement, I would ask if this is a security policy, compliance issue, or another factor that may give insight as to why we are being constrained in this way. The business is making this decision for a reason and the reason may be an arbitrary interpretation of a policy, standard, etc. turning this into a requirement that we can design around. If the reason is they don’t have the resources to have a new solution or it is out of scope (for whatever reason), then it is a constraint.

Assumptions

Assumptions are statements about the environment or design that are necessary to continue through the design process but have not been validated to be true. Many things at the beginning of the design will be assumed to be a certain way but need to be validated as true or false before implementation.

We need to document these assumptions and who we talked to about that assumption. Continuous assessment during the design process, ideally, gets us an assumption-free implementation.

For example:

  • The organization has sufficient bandwidth and low enough latency between sites to support replication.
  • The server closet HVAC can cool the new infrastructure.

Risks

Anything that may prevent you from meeting business or application requirements is a risk. All risks should be mitigated and documented in your design.

As we work through the design process and identify requirements, constraints, and assumptions; inherent risks will be identified. Limited choices and unknown variables introduce risk. These could be not having the resources to implement a best practice or not having the information required to design properly.

The vBrownBag had a great discussion on this risk: the organization’s main datacenter contains only a single core router, which is a single point of failure. This was identified in discovery but poses a risk to the virtual infrastructure and should be mitigated. The best practice would be to add core networking components, but that may be out of scope/budget. Identify, document, and reengage with stakeholders to try to mitigate the risk. Maybe they have a support contract with their vendor to do a 1-for-1 swap in less than 48hrs. Is that an acceptable amount of downtime for their datacenter? Perhaps the DC is in a COLO and they have a support SLA with them to mitigate lost revenue during downtime.

Given a statement, determine whether it is a risk, requirement, constraint, or an assumption

I think this is a pure test-taking objective and if we are solid in our understanding of RCARs then we should be able to read a statement or drag and drop statements in the test.

Analyze the impact of VMware best practices to identified risks, constraints, and assumptions

We need to be familiar with the VMware best practices so we can identify what constraints, assumptions, and risk will have impact on our design and know what we can do to mitigate those risks. This is from the VMware Networking Best Practices concerning recommended service bandwidth and limiting broadcast domain traffic:

Constraint: The project scope and budget do not allow for the purchasing of new networking devices. In-place 1Gbps network must be incorporated into the design.

Risk: VMware services and VM traffic will be limited to 1Gbps physical network

Impact: Possible network resource contention

Risk mitigation: LACP/LAGs, greater port density on hosts, teaming/failover, Network I/O Control, etc

Conceptual Design Diagram

Some of the vBrownBags use a rainbow blob as their conceptual diagram but the one above is pulled from the VMware SDDC Architecture Overview Documentation. I have given similar diagrams and briefs to Directors and non-technical leaders. I would add blocks representing each requirement and be prepared to discuss constraints, assumptions, and risks with business leaders.

I found another example from Craig Kilborn at VMFOCUS

This conceptual design will have the requirements represented as well as documented with the constraints, assumptions, and risks. This can sometimes be in a spreadsheet.

Section 1 Conclusion

This finishes up Section 1 from the VMware VCAP-DCV Design Exam guide. Next, we will start with Section 2 and start mapping conceptual design components to logical design components.

Sprint to VCIX (Part 3) — Gather and Analyze Application Requirements

We are still working with the conceptual design but now looking at application requirements. What does the business want to accomplish with their applications, what requirements do they have for each application, and what dependencies exist that need to be accounted for in our design?

Section 1 – Create a vSphere 6.5 Conceptual Design

Objective 1.2 for the VCAP-DCV Design exam is to gather and analyze application requirements. vBrownBag hosted a 45-minute discussion on Objective 1.2 for the Design exam:

In the first five minutes, Mark Gabryjelski states the most important thing to keep in mind is that the design is not always about what is cool, but meeting business requirements.

Scope

During interviews and workshops, we need to define which applications are in scope for the vSphere design. The business may not want to virtualize certain parts of the business, they have a migration plan in place where some apps are going to the cloud, or applications are being replaced by a SaaS.

Application Functional Requirements

Identify the functional requirements the applications support — WHAT do the applications do for the business? Do they run back up software that supports their environment? What processes and tools do they use for collaboration? Are they a hybrid cloud shop and if so, what business connections and integration requirements exist?

HOW should business applications run?

“Of course, they should run [great, fast, responsive, securely, etc.].” Well, those are subjective assessments from a business leader. What they are describing is a user experience or function of the application. We need to drill down and identify specific metrics that will help us identify nonfunctional requirements for their application.

These specific metrics are going to be identified through a few techniques, most of which are similar to what we discussed in Objective 1.1. We will gain insights into the application requirements when we engage in interviews/workshops with the subject matter experts (SMEs) that own, operate, and administer the business’s specific applications. Existing documentation and the amount of detail done in the current state analysis will capture performance and data characteristics that will drive our design decisions.

Metrics gathered will inform our decisions when it comes to designing for Availability, Manageability, Performance, Recoverability, and Security (AMPRS). Keep in mind that I will be separating concepts and features into the design qualities, but they are all interdependent. We need to be sure to keep a holistic view when designing for applications.

Availability

In most of the resources I have read through and watched, availability requirements usually boil down to some type of uptime SLA. These could be business-critical applications like a revenue-generating service, internal applications, or application dependencies. The business will have an idea of what availability means to them and each application will be different based on its function. This is also going to be tied to cost. The business justification for running a fault-tolerant application with 99.999% (five-nines) must be rooted in a quantifiable loss to the business. This is usually stated as an SLA that they are obligated to meet for their external or internal customers. This consideration will be unique to each application as well. A business’s eCommerce web server availability requirement is different from its internal knowledgebase server.

AvailabilityDowntime/YearDowntime/MonthDowntime/Week
99%3.65 days7.2 hours1.68 hours
99.9%8.76 hours43.2 minutes10.1 minutes
99.99%52.6 minutes4.32 minutes1.01 minutes
99.999%4.26 minutes25.9 seconds6.05 seconds
99.9999%31.5 seconds2.59 seconds.605 seconds
Uptime Service Level Agreements (SLAs)

If SMEs do not have SLAs or cannot agree, I like Mark Gabryjelski’s recommendation to make your own SLA. The business will most likely refine but at least we were able to get the conversation started. Having business SLAs and business requirements will help us justify availability design decisions and what type of components may be put into the design.

As we have discussions and workshops to identify the level of availability per application, we should start to think of the tools vSphere provides to support those requirements. vMotion and Storage vMotion allows us to reduce planned downtime and enables transparent host maintenance. vSphere HA leverages multiple ESXi hosts configured as a cluster to provide rapid recovery from outages. vSphere Fault Tolerance provides continuous availability. vCenter High Availability (vCenter HA) protects not only against host and hardware failures but also against vCenter Server application failures. Predictive HA works with DRS to provide early detection and VM evacuation to a healthy host.

Availability considerations can also be impacted by hardware choices and single points of failure. We need to identify component, host, cluster, rack, and datacenter levels of availability to meet uptime SLAs. Current hardware configurations could be constraints or risks to the design.

vCenter

Manageability

Manageability requirements come in many forms and can impact our design. The business may need to manage all the virtual infrastructure in one place. vCenter is the core product for managing vSphere and controls datacenter, cluster, and host resources. Integrating with VMware Site Recovery Manager (SRM) centralizes part of their Business Continuity Plan (BCP).

Platform management is becoming more important with hybrid cloud deployments and VMware Validated Designs for SDDCs. If the business is needing unified management to provision, configure, and administer its multi-cloud platforms then the vRealize Suite may become part of the design.

Provisioning, configuration, and automation tools may be in place such as Ansible, Terraform, or SaltStack. How these integrate into vSphere will be part of the design.

Distributed and cloud-native applications bring unique management problems. If a business is currently using something like Kubernetes, the management of the virtual infrastructure, K8s management, and cluster provisioning can get blurred between business roles. Platform and resource consumption by application clusters should be considered. Not part of the 6.5 exam, but vSphere 7 brings Tanzu to solve some of these challenges for Kubernetes.

VMware SDDC

Performance

Like availability, most performance requirements will come from some type of metric. This time it will be linked to your datacenter resources in the form of a non-functional requirement for compute, storage, or networking performance. Customer-facing API latency needs to be less than 500ms, SharePoint needs to support 1000 users, storage will exceed 100,000 IOPS for short periods of time, and top-or-rack switches routinely pass 80+Gbps on uplinks are all performance requirements.

These requirements will be rooted in a business justification either providing a level of service to customers or defined by the performance monitoring and current state analysis we did before. Remember to consider the growth of performance needs in your design. A business may be serving one million web requests today but what will they look like in 5 years?

Some applications may have compute, storage, or network requirements that need special attention such as latency-sensitive applications. Take a look at Deploying Extremely Latency-Sensitive Applications in VMware vSphere.

Cluster design will directly impact the performance of the application. Is the application monolithic and need to scale up or is it distributed and has 1000 small VMs across many hosts? This will inform your cluster scaling strategy.

Business policies can also drive performance requirements. Perhaps management and development environments should not impact production performance. This may mean that we use Network/Storage IO Control and Resource Pools to guarantee resources to production workloads or those management/development workloads reside in different clusters altogether.

Different business units have different needs and depending on the organization you can use logical structures like vApps and Resource Pools to manage resources. We will be digging into the resource management guide in Sections 2 and 3.

Disaster Recovery Timeline

Recoverability

The disaster recovery timeline is a critical part of the business as is understanding their business continuity plan. Every business needs a plan to continue operations if their primary site has a disaster. Business goals and application requirements need to be quantified into the main segments in the DR timeline so we can design a proper vSphere environment. This Disaster Recovery 101 post has a great outline of the timeline above and its elements.

Failures happen and we need to plan for them. Based on 2019 revenue data from online store sales, Amazon.com would lose $4,480 of revenue every second their website was unavailable. That does not include 3rd party stores hosted on Amazon or subscription services. Availability and Recoverability are usually tied due to cost constraints. Every business has limited resources and 100% uptime is very expensive. Application availability and recovery should be driven by a business objective and sized appropriately.

RPO, RTO, WRT, and MTD will dictate your backup schedule, location, for which applications, and method of failover and fail-back. Identify third-party backup tools in place.

VMware Site Recovery Manager is the primary VMware product providing automated disaster recovery failover, planned migration and disaster avoidance, and seamless workflow automation with centralized recovery plans. The technical overview of SRM is a great way to get familiar with the technology.

vSphere Replication is another tool included in vSphere Essentials Plus and higher that provides flexible recovery options, ensures consistent application and virtual machine data, and integrates with the VMware product stack.

Security –

Security has a huge impact on the conceptual design of a vSphere design. Application security requirements range from business policies on OS configurations, security software installed, and ports and protocols running through subnets. We need to identify application-specific requirements that the business needs to accomplish its goals.

Remembering Confidentiality, Integrity, and Availability can help us engage with SMEs about securing their virtual environments; VM encryption may be a requirement, policies on network segmentation, and workload separation at the host or cluster level.

Backups are part of the recovery plan but also a way to mitigate some security risk in the case of ransomware or other data loss.

The business may follow standardized security frameworks or are responsible for meeting security compliance standards like PCI DSS, HIPAA, or DISA STIGs. All these requirements for applications, data flow, and resource placement will have heavy impacts on the design.

Hybrid and multi-cloud cloud deployments face even more difficult challenges as more data moves out of and between on-premises datacenters and cloud IaaS, PaaS, and SaaS providers.

Application Dependencies

What infrastructure services do business applications depend on; AD, DNS, DHCP, NTP? These should be part of the current state analysis and listing application dependencies as well as vSphere dependencies will lay a foundation for a successful design. If you introduce new services or components, make sure they are identified.

Some vendors and software require access to the internet for updates and management while some security policies and compliance demand applications are air-gapped. We need to make sure we are identifying those applications and develop a plan to address those requirements.

Clustered VMs and distributed applications are becoming more common as the drive for higher availability continues. Clustered platforms will have internal dependencies that we need to understand.

Some applications may have specific hardware they need to function; hardware tokens, PCI Passthrough devices, direct I/O connections, and GPUs are just a few.

vSphere Upgrades and Migrations

I’ve seen other blog posts reviewing the DCV6 and 6.5 exams stress that you need to know the upgrade paths between sphere versions and component interoperability. I would place this in the conceptual design portion of needing to know what versions of vSphere the business is on and if they need to make upgrades for any of the design quality reasons.

In our logical design, we will look at the specific vSphere version upgrades and component changes like vCenter and the PSC. In line with this, we should know what licensing the business has which will inform us of any constraints on the design and engage with the business about license upgrades for their design.

VMware Product Upgrade path and Interoperability of VMware Products

Design Impacts

Once all application requirements are identified we can assess the impact they will have on the design. Many requirements will have second and third-order effects that need to be addressed. Below are some major vendor application virtualization best practices to start identifying:

If you only have time for one then I recommend this whitepaper: Virtualizing Business-Critical Applications on vSphere

When engaging business leaders, having vSphere ROI and adoption trends discussions may be beneficial to helping them understand the business value of a VMware solution:

Use this whitepaper, Business and Financial Benefits of Virtualization, and the VMware TCO calculator to understand the financial benefits of virtualizing applications.

Prepare your Conceptual Design

In the next article we will take the business and application requirements from Objectives 1.1 and 1.2; identify risks, constraints, assumptions, and risks; and develop our conceptual design.

Sprint to VCIX (Part 2) — Gather and Analyze Business Requirements

Originally published December 29, 2020 on LinkedIn.

The VCAP-DCV 6.5 Design exam blueprint and a great updated reference link list provided by Jeffrey Kusters (Double VCDX #252) will get us in the right direction for the content and depth VMware expects Advanced Professionals and Implementation Experts to be.

Conceptual design is the owner’s view. What does the business want to accomplish, what problems are we solving, and what value does our design bring to them?

Section 1 – Create a vSphere 6.5 Conceptual Design

Objective 1.1 for the VCAP-DCV Design exam is to gather and analyze business requirements. vBrownBag hosted a 45-minute discussion on Objective 1.1 for the Design exam:

VMware uses a design methodology when creating a conceptual design centered on business drivers and two conceptual frameworks: Design Factors – Requirements, Constraints, Assumptions, and Risks (RCARs); and Design Qualities – Availability, Manageability, Performance, Recoverability, and Security (AMPRS). Jeffrey Kusters, again, has a helpful breakdown of these frameworks. We will get more into RCARs and AMPRS later in the series but as we move through the design process and determine business requirements, we will categorize information into design factors and qualities. Design qualities should be the main considerations when identifying and categorizing requirements during stakeholder engagements.

Identify Stakeholders and Information Needed

“Gathering and analyzing business requirements starts with identifying the business justification for the project, business problems that they’re trying to solve, and the goals of the projects as it relates to those goals.”

– Jeffrey Kusters

The business leaders and the project charter should outline these goals and give you an idea of the stakeholders that need to be engaged to identify business requirements. These stakeholders will hold various roles in the organization; each will have input into the design and will have some information needed to analyze the business requirements. IT Director, Network Admins, Storage Admins, Infrastructure Admins, C-level executives, LOB directors/managers, application owners, and end-users can all have input on a vSphere design.

Engaging in workshops and interviews with stakeholders will identify business requirements, constraints, assumptions, and risks. Driving business value is closely tied to making sure you identify requirements and validate they support the business’s goals. In VMware vSphere 6.7 Design Cookbook and VMware vSphere Design, the authors have chapters dedicated to the discovery process and design factors. The primary source of information will be your stakeholder interviews, reviewing documentation, current inventory, and current state analysis that can be done with available tools. Each stakeholder has different views of the project so identifying what questions to ask and whom to ask those questions is important.

Inventory Assessments and Current State Analysis

After we engage with stakeholders we need to start assessing the current baseline state of the environment. This can be done through services and tools like Active Directory, LDAP directories, network-management tools, logging solutions, IP addressing documentation (IPAM), equipment configurations, and historical performance data. Vendor and community tools can be used such as VMware Capacity Planner, Windows Performance Monitor, vSphere Optimization Assessment (VOA) in vRealize Operations Manager, etc.

During our current state analysis, we are essentially answering: what does the customer have and how do we find it? The baseline state will help define requirements like capacity, consolidation ratios, measuring KPIs, identifying unique dependencies, and what infrastructure can be reused.

Business Objectives and Priorities

When we have our customer interview data and knowledge of the current state, we can explicitly define customer requirements, state the objectives, and determine customer priorities for our vSphere conceptual design.

Below is a sample customer objective list pulled from the vBrownBag video:

  • Virtual infrastructure capable of consolidating country-wide workloads
  • Highly available, disaster recovery solution
  • Common, standardized infrastructure
  • Simplified and improved support model
  • DR with VMware SRM and EMC RecoverPoint
  • Provide virtual infrastructure that can provide 99.9% availability or higher
  • Automatic VM failover in the event of a host failure
  • DR of critical systems with a 99.9% availability
  • DR of non-critical systems with a 99% availability
  • Management simplicity where possible
  • Resilient and provide the highest level of availability where possible while keeping costs to a minimum
  • 30% growth of VMs and storage over the next four years

These objectives should map to the design qualities mention at the beginning of this article, Availability, Manageability, Performance, Recoverability, and Security (AMPRS).

  • Virtual infrastructure capable of consolidating country-wide workloads – Availability, Manageability, Performance, Recoverability, and Security
  • Highly available, disaster recovery solution – Availability and Recoverability
  • Common, standardized infrastructure – Manageability
  • Provide virtual infrastructure that can provide 99.9% availability or higher – Availability, Performance, Recoverability
  • 30% growth of VMs and storage over the next four years – Performance

Identify & Categorize Requirements

With an approved objective list and business requirements we can refine precise requirements to prevent scope creep and define exactly what the customer requires. Requirements can be broken down into two different types, functional and non-functional requirements.

“Functional requirements specify the objectives or functions that a design must meet. Nonfunctional requirements define how the design accomplishes the functional requirements.”

VMware vSphere 6.7 Design Cookbook

Personal note: I feel like this is one of the hardest concepts in the VMware design methodology and requires a bit of a vocabulary redefinition, especially if you come from the technical/admin side of vSphere. When VMware says functional it is relating to the business’s functions, specifically. One might say storage IOPs are a function of the storage array but IOPs are not a business function in the sense of supporting a business’s needs. So in that sense, IOPs are a performance-based, non-functional requirement. A storage focused functional requirement could be the infrastructure design should simplify storage administration and increase application availability.

Put another way, a functional requirement is describing the behavior of the system as it relates to the system’s functionality. A non-functional requirement elaborates a performance characteristic or quality of the system.

Typical functional requirements include the following:

  • Business goals
  • Business rules
  • Legal, regulatory, and compliance requirements
  • Application system requirements
  • Technical requirements
  • Administrative functions

For example, “The business processes credit card data in a web application. The virtual infrastructure will be PCI DSS compliant.”

Another example, “Our systems administrators have spent a significant amount of time automating our infrastructure change management process. They need to be able to programmatically access and administer the virtual infrastructure.”

Typical nonfunctional requirements include the following:

  • Performance
  • Security
  • Capacity
  • Availability
  • Manageability
  • Recoverability

For example, a specific set of requirements might read, “Our revenue-generating web application processes 95% of our requests during business hours (9am-6pm). We must fulfill a 99.99% availability SLA for that application during business hours. Critical internal applications need to be 99.9% available and non-critical applications need to be 99% available during business hours.” These would be categorized as Performance and Availability non-functional requirements.

We will dive deeper into the details of functional and non-functional requirements in Objectives 1.3.and 2.1. They are introduced here since they are integral to the vSphere design and provide justification for each design decision. For now, having the business requirements gathered and mapped will help us later when we bring it all together into the conceptual design and in Objective 2 when we map the conceptual design to the logical design.

Detailed reading on Objective 1.1

Sprint to VCIX-DCV (Part 1)

Originally published December 26, 2020 on LinkedIn.

I am coming hot off passing the AWS-SAA certification and very excited to pivot back into VMware, this time taking it to the next level — VCIX-DCV. This series of articles is going to serve as:

  1. The mechanism I use to reinforce the material I am using to study for each VCAP. I learn new material best through my own system, which will be detailed in the series, but presenting information is a reinforcing technique I use for myself and my team.
  2. Create a forcing function and means for my peers and mentors to keep me accountable to my aggressive timeline. I am aiming for many goals inside the next 6 months and sometimes I may lose sight of where I want to be in 6-12months. This will help me keep myself on pace or adjust as needed as well as give my peers and mentors a way to track my progress. This also allows people to correct anything I have written or add to the conversation here since this is part of my learning phase.
  3. Start to give back to the community. Over the years I have taken a lot out of the community. Thousands of articles, forum posts, GitHub repos, videos, and blogs have helped me as an IT professional and I want to start to help those coming behind me.

Why Now?

I am transitioning out of the US Army and my organization has been gracious enough to allow me time to upskill before my separation and to participate in a corporate fellowship. I have been accepted into VMware’s Corporate Fellowship Program and will be starting in January 2021. I have learned a lot about myself in the last few years and with the help of mentors and peers, I have focused on virtualization, hybrid cloud deployment, and software-defined networking.

I plan to use the holiday season to prepare for the VCAP-DCV Design and take that certification the week before I start with VMware. I am already in the design mindset coming from the AWS-SAA and having spent the last couple of years working on design and architecture projects for the Federal Government. From the time I started to study, to the day of my planned VCAP Design exam will be ~30 days.

Immediately after the VCAP-DCV Design, I will start the push for VCAP-DCV Deploy using the experience and time working with my team at VMware as well as labbing at home to prepare. I am optimistic that my time with VMware will result in a successful VCAP Deploy and the VCIX-DCV designation before I start full-time employment.

The large risks with my timeline are the team and workload that I will have at VMware, military transition requirements, job hunting/interviewing within 90 days of my separation, and preparing my family for potential relocation. All of these major commitments are occurring around the same time and could potentially change my VCIX timeline. I have made some assumptions about the commitment for each and I will adjust as I start to validate. The aggressive push for the Design before I start at VMware, as well as a longer time frame (2-3 months) for Deploy, reflect the demand for my time in early 2021.

Series Outline

This is going to be a long series with each post focusing on a major exam objective from each of the exam guides (VCAP-DCV DesignVCAP-DCV Deploy). I will be studying vSphere 6.5 well as including considerations for newer versions. VMware has extended the general support for vSphere 6.5 five years from the date of release, which means the general support for vSphere 6.5 will end on November 15, 2021. The Design exam (3V0-624) is still on 6.5 while the 2018 Deploy exam (3V0-21.18t) is being expired in December 2020 for an updated 6.7 version (3V0-21.20). As I publish more sections they will be added here for quick reference:

  • Part 1 — VCAP-DCV Design Plan of Attack

Part 1 — VCAP-DCV Design Plan of Attack

I will be following the VMware VCAP exam guides for my study structure — VCAP-DCV DesignVCAP-DCV Deploy

I will be using the VCAP-DCV Design series from vBrown Bag as my starting point. I have found that my learning improves when I do a video primer followed by an in-depth study on documentation and key points.

I have picked up copies of VMware vSphere DesignFoundation In the Art of Infrastructure Design, and VMware vSphere 6.7 Data Center Design Cookbook as references to start.

I will be starting with Rene Van Den Bedem‘s VCDX Deep-Dive Series.

As I work through my studies, I will add the references/resources for specific sections/objectives in the outline below as a one-stop-shop for anyone on the same journey. Each subsequent article will be a summary of the VMware Design objective, resources used to learn, and a summary of the content.

Section 1. Create a vSphere 6.5 Conceptual Design.

Objective 1.1 – Gather and analyze business requirements.

Objective 1.2 – Gather and analyze application requirements.

Objective 1.3 – Determine risks, requirements, constraints, and assumptions.

Section 2. Create a vSphere 6.x Logical Design from an Existing Conceptual Design.

Objective 2.1 – Map business requirements to a vSphere 6.x logical design.

Objective 2.2 – Map service dependencies.

Objective 2.3 – Build availability requirements into a vSphere 6.x logical design.

Objective 2.4 – Build manageability requirements into a vSphere 6.x logical design.

Objective 2.5 – Build performance requirements into a vSphere 6.x logical design.

Objective 2.6 – Build recoverability requirements into a vSphere 6.x logical design.

Objective 2.7 – Build security requirements into a vSphere 6.x logical design.

Section 3. Create a vSphere 6.x Physical Design from an Existing Logical Design.

Objective 3.1 – Transition from a logical design to a vSphere 6.x physical design.

Objective 3.2 – Create a vSphere 6.x physical network design from an existing logical design.

Objective 3.3 – Create a vSphere 6.x physical storage design from an existing logical design.

Objective 3.4 – Determine appropriate computer resources for a vSphere 6.x physical design.

Objective 3.5 – Determine virtual machine configuration for a vSphere 6.x physical design.

Objective 3.6 – Determine data center management options for a vSphere 6.x physical design.

Please let me know if there is anything I need to add or change during the course of my series. Any advice and study recommendations are greatly appreciated.