VCAP-DCD 5 Study Blue Print Section 1 – Create a vSphere Conceptual Design

Objective 1.1 – Gather and analyze business requirements

  • Associate a stakeholder with the information that needs to be collected
    • A Stakeholder is a person with an interest in the project. They include:
      • Application Owners
      • Network Team/Admin
      • Storage Team/Admin
      • Server Team/Admin
      • security Team/Admin
      • Actual Users of the system
      • C Level executives – CTO, CEO etc
  • Utilize customer inventory and assessment data from a current environment to define a baseline state.
    • This means: what does the customer already have. To determine this:
      • Perform a current state analysis. Tools include – VMware Capacity Planner – Quest performance and capacity management – etc
      • Review current customer documentation. This has a downside as documentation is not always updated.
      • Collect this information during interviews with stakeholders and system experts.
    • Try and collect capacity information for at least a month in the business cycle.
    • If a current system is bottlenecked this may give inaccurate information and the system may need more resources when the bottleneck is removed.
  • Analyze customer interview data to explicitly define customer objectives for a conceptual design.
    • From the Interviews determine:
    • Goals
      • Why are we doing this?
      • When do we need this done by?
    • Scope
      • What is in scope? – What is included
      • What is out of scope? – what is not included
    • Requirements
      • Business requirements (e.g. cost saving musts)
      • Technical requirements (e.g. consolidation, DR, VDI)
      • Legislative framework requirements (e.g. compliance)
    • Assumptions – accepted as true but not tested
      • Power and cooling for hardware is adaquate
      • There may be things the customer is doing
    • Contraints – Customer says that things must be done
      • reuse of hardware
      • Budget
    • Risks – may prevent project completion
      • Not enough executive sponsorship
      • is the budget approved
      • Is there a dependency on other projects
  • Identify the need for and apply requirements tracking
    • The Conceptual Design goals and requirements should include a table or list mapped to each stakeholder/SME. Best to number each for tracking.
  • Given results of a requirements gathering survey, identify requirements for a conceptual design.
    • Use the current state analysis and requirements from interviews to contribute to the high-level design.
  • Categorize requirements by infrastructure qualities to prepare for logical design requirements.
    • Application requirements
    • Infrastructure requirements
      • CPU – Memory
      • Network
      • Storage
    • Business requirements
    • Backup/disaster recovery

Objective 1.2 – Gather and analyze application requirements

  • Given a scenario, gather and analyze applicaton requirements
    • Use capacity monitoring tools like Perfmon, Top or a central tool like capacity planner to determine application resource requirements – look at peaks and averages.
    • Pay attention to the following and capture baselines for peak and averages.
      • CPU – %RDY, %Used
      • Memory – %Active
      • Disk – IOPs, bandwidth and latency
      • Network – bandwidth and packet loss.
    • Decide on virtualization candidates and non-virtualization candidates.
    • Identify non-standard implementations of the applications
    • Identify re-usable hardware
    • Identify if any appliactions have any dependencies.
  • Given a set of applications within a physical environment, determine the requirements for virtualization.
    • Capture and review baselines for average and peak resource usage for 1 month.
    • Identify non-standard implementations of the applications
    • Identify re-usable hardware
    • Identify if any appliactions have any dependencies.
    • Additional rules for the average application
      • Reserve Memory on Java Apps
      • Does the app use large Paging tables
      • What is the Disk I/O requirement
      • Is any storage mode required? e.g. RDM
    • databases like SQL and Oracle use large Memory pages
    • MSCS use RDMs in physical compatibility mode
    • Exchange can use RDMs for migrations
    • Does the software/application Vendor have resource requirments sepcifications
  • Gather information needed in order to identify application dependencies
    • May require well documented application diagrams or tools like RUM (Real User Monitoring) or VIN (Vmware infrastructure navigator) to map out appliactions and what/who they talk to.
    • Collect workload for appliactions for long enough to determine true peak and average loads.
  • Given one or more application requirements, determine the impact of the requirements on the design.
    • This is very specific to the applications but some examples are:
      • MSCS will require RDM physical compatibility mode
      • VLANs require trucking on the physical switches
      • SRM requires 2 vCenters and 2 Databases
      • Some SAN replication technologies require RDM to be used
      • Java based appliactions require memory reservations and may affect over allocation of RAM.

Objective 1.3 – Determine Risks, Constraints and Assumptions

  • Differentiate between the general concepts of a risk, a requirement, a constraint and an assumption.
    • A risk is an item that may prevent a goal or requirement from completing successfully. An example of a risk is that current staff aren’t trained to manage the environment.
    • Requirements are mandatory conditions that the design needs to satisfy. They come in 2 types:
      • Functional: Functional requirements mandate what the design must do. An example of this is that the new infrastructure must provide virtualized desktops in place of desktop hardware.
      • Non Functional: Non functional requirememts mandate how the system must behave. An example is that the new infrastructure must perform with similar user experience as to physical hardware.
    • A constraint is any item that limits design choices. An example is that the new infrastructure must use existing hardware.
    • An Assumption is an item that is considered to be true but is not tested. An example is that the power and cooling capacity in the server room is adaquate.
  • Given a statement, determine whether it is a risk, a requirement, a constraint or an assumption.
    • Basically put into practice what is defined in the previous item.
  • Analyze impact of VMware best practices to identified risks, constraints and assumptions
    • When making a design desicion, don’t blindly implement VMware best practice because it is “The best practice”. Ensure that the best practice meets the business requirements and use best practice when you don’t know what else to do.