John Arrasjid created a Twitter account and has been tweeting VCDX Tips over last week or so. These tips are valuable for everyone doing the VCDX Track and going for the defense. That’s the reason for archiving them on a blog post as tweets are bound to get lost in space while a blog post gets indexed by google. This is the list of Tips for you VCDX Defense / Application Form so far, but knowing John he will keep updating it for a while and so will I:
- Know you design inside out. Why, how, and impact are important! Understand the requirements, justification, and consequences.
- a) Consider lessons learned from Enterprise Architecture and Services Oriented Architecture for virtual cloud design.
b) See Thomas Erl books (SOA Design Patterns, and SOA Principles of Service Design), and Computing by Rittinghouse and Ransome.
note: books=support of cloud architecture design 4 VCDX, not to help pass test. SOA is a key piece for VMware based clouds.
- Practice what you preach and learn from others. Architects listen first. Don’t assume the answer before the discussion starts!
- Scenarios for VCDX defenses test journey to solution, not necessarily the final answer. Whiteboard, talk and ask questions.
- Troubleshooting scenarios – think of the architecture and implementation approach to resolution. Logs, design, SC commands.
- a) Application/Design Choice=(What decision was required? Don’t include simplistic choices that are standard ie: redundant NICs)
b) Include architecture decisions like use of active/standby layout in single vswitch design.
- Application/Justification=What compelling requirement/constraint/assumption/risk mitigation drove decision.
- Application/Impact=How did the decision affect other areas of the design w/r to technology/risk/schedule/skills/budget.
- Recruit peers to review VCDX design and application. Focus on architects and specialists 1st, implementers 2nd. Red ink please.
- Try a dry run on the defense. 75 minutes w/peers to grill you on design and choices made. Practice breeds confidence!
- a) Longer is not necessarily better. We have reviewed some designs over 500 pages total (8 docs) and some under 200 pages total.
b) Focus on content not length. Focus on customer requirements.
- a) What makes for a good design?
b) See other tips. Key answer = meeting requirements with appropriate technology to also match schedule and budget.
c) Understanding and documenting the reasons for each decision including meeting requirements, constraints, and technology.
- a) Blank application or missing areas in the application=immediate rejection. Application is a requirement.
b) Incomplete application form or referring the reviewer to the document where the form should be completed=rejection.
c) Application requires 5 requirements/constraints/assumptions. and four answers (3 parts each) in each design choice area.
- a) Core components of a VCDX submitted design include a design document with requirements and an architectural solution.
b) This design will include supporting information for the design choices. This is why the application mirrors what we look for.
c) The design also should include an assembly and configuration type document and a validation/test plan.
d) In the design you must touch the following areas: Network, storage, vCenter, ESX, VMs, security, disaster recovery, monitoring, upgrades, capacity planning, standard procedures, and areas related to the requirements.
- Current docs must be in English. Other languages will come as we grow the number of VCDX. If u translate, consider a reviewer
- Start early on application. Plan 8-24 hours to collect and update docs per blueprints and fill out app. Remember ‘no blanks!’
- Use VCDX application 2 identify new design patterns & new best practices in your design. Provide justification & impact.
- Considerations for design: SOA, Cloud, Enterprise Architecture, extending the boundaries. Think Elastic Sky… 🙂
- a) Example decision for ESX Clusters: N+2 Redundancy
b) Justification: Customer requirement of N+2 redundancy in cluster.
c) Impact: Lower utilization of resources in cluster to accommodate N+2 failure. Impact to ROI & TCO.
- Design Document must include requirements and an implementation to support them. It is not about diagrams alone.
- Validation/Test Plan typically will include test of virtualization platform/mgmnt tests, infrastructure, and adv features.
- Design Document includes conceptual model mapping requirements, logical design, and physical design.
- Installation & Configuration Guide includes details on assembly of the physical design components. Test Plan can be combined.
- Preparation for defense – Create presentation outlining design and include reference diagrams for discussion during defense.
- Getting started – take a design and red ink pen, then review for blueprint items and a match of decisions to requirements.
- Sleep well night before after studying design and decisions carefully, then take the test with confidence, best foot forward.
- Consider extensions to design to meet all blueprint requirements. This is allowed but must be defensible.
- a) Plan to include requirements/constraints/assumptions in a dedicated document or within the architecture design document.
b) Requirements table example: REQ-001 Customer requires that disaster recovery site supports the same SLAs as primary site.
c) Constraint table example: CON-001 Customer has budget to support recovery but not at the same SLA levels.
d) Assumptions table example: To quote Benny Hill “Never assume or you make an *** out of you and me.” Note follows…
e) Assumptions must be confirmed for risk mitigation.
f) Assumptions table: ASS-001 To mitigate risk, REQ-001&CON-001, client resolves conflict. The design will match resolution.
g) All architects will, at some point, have conflicts in pool of requirements/constraints/assumptions.
h) A VCDX must be able to address conflicts in their design during discussions and obtain signoff of the final decision.
i) Ensure that the decisions made around conflicts include justification, approval, and impact to other areas of the design.
- Validation/test plans should include functionality/performance/utilization considerations for testing on regular basis.
- Panelists spend approximately 4-8 hours reviewing application and submitted docs. We look for complete design as specified.
- Design documents do not have to be based on VMware deliverables but must meet content coverage. Blueprints & app provide detail.
- Having a good design without understanding all areas presented will limit scoring. Know the technology as you will be asked.
- Short answers without solid demonstration of technology or choices must be expanded to score.
- Panelists cannot provide positive scores in missing areas. Explaining what is missing does NOT score extra points.
- Cheat sites for vcdx won’t help.
- (@ywiskere) LISTEN to panel. When they ask to explain how you came to the design, do that and don’t just explain the facts.
- Sites that introduce design strategies and design patterns for virtualization that are supported by VMware will help.
- Liars claiming to be VCDX will be revealed as liars. Customers beware. If they lie on this then they will lie to you.
- HP blade virtual connect can utilize redundant back-end 10G uplinks, allowing creative perf and redundancy in vswitch design.
- Official VCDX certified individuals will, in the future, be listed by VMware so that customers can validate integrity.40. If the design references strategies from Mr. Hanky, do NOT submit. 🙂 (South Park anyone?)
- Don’t believe duplicate tip #s. Go with first one. 🙂
- “Panelists are experts in various virtualization areas. Don’t make technology claims that are incorrect.” – Duncan Epping
- Submitting and defending a design with “best practices”, know the background behind the best practice. You will be questioned!
- Example of bad design – Utilizing two NICs for vSphere FT that are shared with vMotion, Service Console, and VM traffic. BAD!
- Best practices for majority may not be best practice for some. Think first! Justify & show impact to support change.
- For partners especially – default VMware templates are only a baseline and do not constitute the minimal cutoff for VCDX.
- Customer defaults may be ok, but provide guidance in your discussions as well as recommendations for change in your design.
- Reminder – ‘Just because’ will cost points. Know justifications & impact of choice. If bad, provide recommendations.
- Defense presentation outlines your background, project background, key points, and reference materials.
- VCDX Presentation should not include birthday, age, religion, or other areas that are outside of virtualization project.
- a) vSphere designs have been accepted for the VCDX defense if they meet the criteria defined in the blueprints.
b) The differentiator between VCDX on VI3.x versus VCDX on vSphere 4.x is likely to be based on the test.
c) Note – for VCDX on vSphere 4 to work, the Enterprise test and the Design test must both be upgraded to vSphere 4. ETA TBD.
d) All aspects of a design are reviewed and validated. If you include vSphere features, you WILL be questions on them also.
- Enterprise Exam is a prerequisite to validate advanced skills and troubleshooting required by architects. Experience counts!
- Design exam tests architecture skills that include both technology and process. How do multiple parts fit together?
- Top VCDX candidates spent extra time on their application and design to fill in missing areas for complete scoring.
- Designs can adapt and modify best practices. Provide solid support for this and provide examples from experience.
- Design Exam – consider lessons learned from VCP and Enterprise tests. Know your weak spots and learn them.
- Design Exam – Integration is essential in a design. Know how to tie related items and understand their relationships.
- D.E. – covers design exam tips for future posts.
- D.E. Consider security, DR, DRS, Resource Pools, and other items that influence placement of disk/net/CPU/RAM/VM in cluster.
- D.E. (Tip from @jasonboche) – Pace yourself. Some areas require more time than others. Some have more weight than others.
- I plan on adding to the tips. If you have unique questions on VCDX I will post answers.
- Troubleshooting scenarios include multiple paths that can be taken. Think of this as a murder mystery role play. Journey=#1.
- Variation on an idea from Hugo Strydom “A VCDX should have a balanced lifestyle; family, training, exercise, work.”
- Add to tip 63 – Maintain a good mental state when working/presenting. Clear thinking in difficult/stressful situations.
- a) If planning on doing February VCDX defense at PEX, start planning now. Think of 4 major decisions made in each category.
b) Storage, Networking, Cluster, Resources, Security, Provisioning, BC/DR, next steps, and other areas tied to design.
c) Include the full design details, the justification on why a decision was made, and the impact as described previously.
d) Create presentation with the topology map(s), provide an overview of the design, and then include support info for defense.
e) Based on feedback, the VCDX Preparation Workshop will likely be offered at PEX. Mock defenses will be help.
f) Prerequisites include VCP, pass on Enterprise Test, and acceptance into program. Completion of design test gives priority.
- Get through the Design Test asap if you plan on submitting for a defense at Partner Exchange in February.
- For those asking about testing at PEX 2010, applications will be available in ~2 weeks.
- Update on PEX2010 – Development of the workshop is close to finished. Two hour sessions on Monday. Outline coming.
- Free 1/2 day VCDX workshops next month (Sydney/Melbourne/Singapore). Contact me offline. Space limited to partners.
- The VCDX Preparation Workshop has been approved for Partner Exchange ’10. Sunday from 1-3pm, February 7th.
- If you are coming to PEX 2010, the VCDX workshop is on Sunday and VCDX Panel Defenses are Monday and Friday.Ensure that you have 5 each of requirements, constraints, and assumptions.
- Ensure you have 4 design decisions for each of these categories: Storage, Network, Clusters, BCDR, Security, VM Config, Updates, Dependencies, Monitoring, Implementation & Next Steps, Installation Procs, Standard Procs such as P2V and VM Deployment and Testing/Validation. Also include two risks.
- For decisions, be complete and do not use acronyms. Focus on the outline of the decision, the design choice, the justification, and the Impact to other areas of the design and the project. Do not list the justification under the impact. Think about how
- The decision affects other design choices, budget, scheduling, technology choices, etc. Be as complete as possible.
- When you get the application, start moving forward with completing it per my previous posts. Time is of the essence!
- The application form specifies for item 7 “Disaster Recovery and Fault Tolerance Considerations”. It does NOT say VMware FT!
- VMware FT could be a consideration for a vSphere deployment maybe but the application specifies very clearly Fault Tolerance !FT.
- Please use full sentences and check for grammar when submitting your application for clarity when the panel reviews.
- VCDX Panel Defenses at PEX’10 – If you need to rework your application or design, you will have until January 15th I believe.
- Times up. End of day today is the deadline for VCDX Application rework for Partner Exchange defenses.
- Remember that the application must be 100% filled out. Justification != Impact. Application does not replace documentation.
- Based on feedback we will provide example ‘Table of Contents’ for the documentation required.
- VMware standard for design docs include: Architecture Design Document, Validation/Test Plan, Implementation Guide, (cont.)
- (cont) Blueprints (Visio), Next Steps, Operations Guide, and other docs where relevant to the project.
- VCDX submitted docs missing areas that are in the application cannot be scored on those areas, thus risking loss of points.
- Applications with incomplete sentences, acronyms without definition, same justification & impact entries risk rejection.
- Best wishes for those testing at Partner Exchange! Best wishes for those testing at future events.
- Upcoming VCDX testing anticipated for Munich and Sydney in Q2, and at VMworld 2010 and VMworld EMEA 2010.
- Those translating their design documents to English, please have someone validate the technical translation.
- bad translation example: “The ESX waiter will be implemented on a four-way quad-core waiter.” (Not all translators are equal)
- Practice defending your design in advance. Pick someone that will dig deep on your design choices and the docs you submit.
- Once again, justification does not equal impact. Impact can be both positive and negative.
- PEX2010 VCDX Preparation Workshop booked solid. Just opened more seating. Those on waiting list should get in.
- a) Rework of a VCDX application has a deadline to meet VMware req. If rework does not meet requirements, then it is rejected.
b) Given that we were overloaded with resubmissions by candidates we must limit future candidates to one resubmit of their app.
c) Why? Because of the time required to review an application and design documents.
d) Same applies for resubmit of a design that does not meet all requirements. Be sure to reread instructions before resubmit.
- VCDX documentation requirements reflect VMware’s stance on what is required for fully delivering a design.
- Partner Exchange 2011 is the final chance to become a VCDX3
Who said twitter is a waste of time? There’s valuable info to be found there!