Session Notes – VCDX Prep Session – VMware Partner Exchange

Summary = it’s doable but a long hard road.

Note: as with all my session notes this is a mix of what’s on the screen, what the presenters are saying, and my own thoughts. If something doesn’t sound like what the presenters would say, assume it’s just my opinion. 😉 Or ask in the comments if not sure…

Everything covered today relates to VCDX4 & VCDX5.

People on panel = Mostafa, Chris Colotti, and more that I didn’t catch.

More after the jump…

  • Selection of a Design
    • The design you must submit for an infrastructure…
      • where business requirements drive design and implementation decisions
      • suited for mission-critical applications
      • in a managed environment
    • The design you submit may be partially fictitious
      • You must defend fictitious components as if they were real.
    • If your design is based on an actual project, you must have played an architect role in that project.
      • But not necessarily the sole architect.
    • vSphere must be the primary design component.
    • Side comments/questions.
      • to your benefit to submit a comprehensive design
      • focus/embellish on areas that are your strengths
      • you have 75 minutes….so put out a design that can fill up the time well
      • if you don’t present designs, practice presentation beforehand
      • anything you submit may come into question (i.e. if have View pieces in the design) — focus is on vSphere pieces but will hit on other pieces
      • if you submit a View desktop design, don’t focus totally on View
      • make sure that infrastructure has relevant resources to match the design in a real world, practical way (not just theoretically enough resources)
      • need to understand all components of design (hardware, infrastructure) even if you didn’t design those pieces originally
      • if submit a design with extra components, be careful that you don’t miss including the core design areas (that do affect your score the most)
      • don’t have to include specific products (example = vShield) but have to cover the general area (security)
        • Example: you wouldn’t get marked down for not including vShield but would get marked down if didn’t consider security at all.
      • If have older design and submitting it, consider how you would design it today when considering which products to add fictitiously.
  • VCDX Process
    • Showing flowchart of how the process works.
    • Need to cite everyone who participated in the design (in case they want to submit the same design later on a separate application).
    • Can use solution toolkits but best to modify so it doesn’t feel canned and better understand everything you’re including (whether from the kit or your own changes).
    • The kits are not VCDX quality submissions – there are things missing in them and VMware knows what those are….you had better know that too.
    • This is not a technical defense process – we assume you’ve got the technical pieces by having passed the VCP5 and VCAP-DCA.
    • What makes VCDX unique – both very deep technical and very deep business mapping.
  • VCDX Applications – Components
    • Completed Application Form
    • Signed Attestation and Statement of Conduct
    • Mandatory Documentation
      1. Architectural Design
      2. Installation Guide
      3. Implementation Plan – consideration for training, timeline and/or process for deployment
      4. Testing Plan – system-level testing, unit-level testing, do vSwitch setup make sense from an HA perspective?
      5. Standard Operating Procedures
    • Registration Fee
    • Ensure your submission is free of technical inconsistencies.
    • Side Comments
      • Andrew – Everyone does a lot with the Architectural Design…there’s a lot of space to show VCDX value in the Implementation Plan design.
        • Would love to see more creativity in the bottom 4 bullets below.
      • Remember that your design is your first impression to the panelists — better design in whatever way makes your defense easier.
      • All pieces above in one big doc? Doesn’t have to be….make it easy to follow. Some mention of splitting it into separate docs.
  • VCDX Interview Day
    • Approved applicants are invited to interview.
      • Interview is on-site meeting with panel of VCDX certified architects.
    • Interview process consists of 3 parts:
      • VCDX Defense – 75 minutes
        • Deliver short presentation (15 minutes) that introduces your design. Call out highlights, unique good stuff, etc.
        • Answer questions from panelists about the design you submitted.
        • Provide further insight into your design decisions and rationales.
      • Design Scenario – 30 minutes
        • Demonstrate that you can begin to work through design issues in a methodical and logical manner.
      • Troubleshooting Scenario – 15 minutes
        • Demonstrate that you can begin to work through design or operational problems in a methodical and logical manner.
  • VCDX Defense – Format
    • Panel
      • 3 Panelists – VCDX Certified, interact with candidate, record scores.
      • 1 Facilitator – ensures rules and timelines are adhered to.
      • Observers – VCDX certified, learning how to conduct defense, no interaction with candidate, assist in adjudication process.
    • Environment
      • Room with whiteboard, 1-2 projects, and presentation laptop
        • Personal laptops or PDAs not permitted in room
        • Bags stored in secured area.
    • Timer (only pauses between sections)
  • VCDX Defense – What we’re looking for
    • From Conceptual Requirements to Logical Model
    • Differentiate between logical architecture and physical architecture (calls out specific vendors, brands, etc.)
    • Better to start with requirements, move to logical architecture, move to physical architecture/vendors/brands.
    • Map the above into one or more infrastructure design qualities…
      • Availability
      • Manageability
      • Performance
      • Recoverability
      • Security
    • Build relationship models among design entities to create solutions based on those mappings.
    • Side Comments
      • Constraints – make sure to call out constraints and how/where they affect things in the logical design.
      • Simplest way to know difference between logical and physical is that logical does allow you to swap vendors under the covers.
      • Logical design = capture business requirements of the customer, what’s important to the customer
  • From Logical Design to Physical Design
    • Propose detailed specifications for the technology stack, showing the components’ mapping to the entities in the logical design.
      • Fault Tolerance stuff.
    • Virtual Machines – Including backup/recovery.
    • Compute Resources – Including hosts and clusters
    • Storage Resources
    • Network
    • VI Management
  • Candidate Characteristics – show mastery of….
    • Do Design Work
    • Know how to implement and guide on that.
    • Identify and mitigate risks inherent in the design.
    • Complete, clear and organized technical communication.
  • Tips
    • Before your defense session…
      • Make personal commitment to budget time for preparation.
      • Plan an working a minimum of 30-40 hours to complete the application and supporting docs (not including the design itself)
      • Consider forming study partnerships or groups.
      • Know your design thoroughly!
        • Review your design beforehand so it’s fresh on your mind.
    • During defense….
      • Use time wisely.
      • Allow for time in all design areas.
    • Talk and think out loud – panelists can’t hear what you’re thinking.
    • Use diagrams frequently.
  • Design Scenario – Format
    • Design exercise role play
      • Given a situation/scenario that requires you to begin to architect a design.
      • During the scenario, the panelists are your peers.
        • Focus is on the journey to the solution, not finished design.
        • Think out-loud. Talk through the process to let the panelists see you work the problem.
        • Ask questions to gather additional information for consideration.
        • Go through the steps to demonstrate your strategy and thought process.
        • Try to follow a thread to build your deisng on.
        • Use diagrams.
        • You might not finish in the time and that’s fine.
    • Duration – 30 minutes total.
  • More Tips
    • Sketch your ideas – walk through topology for the design on the whiteboard.
    • Think – Do I have all the information needed? What are the requirements, constraints, assumptions, and risks? Am I meeting all the business requirements?
    • Do – Ask questions! What is your strategy? What information do you need? What clarification? Is risk mitigation required due to some of the business requirements?
    • Don’t – Be silent as you work the design.
  • Design Scenario – Sample
    • Poke at constraints, do they really need to be there?
    • What servers are dev vs. prod vs. QA? What SLA’s on the workloads?
    • What were the compelling events that caused you to start this project much less run Capacity Planner in the environment?
  • Troubleshooting Scenario
    • Don’t necessarily try to figure out how to fix the problem (maybe) but definitely who should fix the problem.
    • Ask about what changed recently.
    • What is the PSP selection policy? Active/passive array? LUN trespass? Boot from SAN?
    • Start out with questions but try to have some kind of recommendation by the end.
      • Something on the whiteboard – diagram, thoughts, recommendations.
    • Don’t get stopped by short answers – I asked AV question and shouldn’t have taken the short answer.
  • Other Q&A
    • Design Length – have had short and long pass. Explore constraints and what might need to change.
      • Really about having traceability through the whole design.
      • Need more details in the design than being short.
      • Don’t need as much time describing features and technology – “how DRS works”.
    • Include scripts –
    • Minimum size – doesn’t need to be multi-site but that helps. Make sure to use features on the blueprint.
      • 50 VM’s could work as long as you cover everything in the blueprint.
      • Most designs have reviewed have hundred’s of VMs and 8 or more ESX servers.

2 thoughts on “Session Notes – VCDX Prep Session – VMware Partner Exchange

  1. Pingback: Think Meta » Session Notes Compendium – VMware Partner Exchange

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s