VCAP-DCD - Objective 2.1 and 2.2 on Logical Design

Objective 2.1 –Map Business Requirements to the Logical Design

Knowledge

·         List the fundamental components of the vSphere4 environment.

http://www.vmware.com/pdf/vsphere4/r41/vsp_41_intro_vs.pdf#page=8

·         List the fundamentals of the VMware virtualization architecture.

http://www.vmware.com/pdf/vsphere4/r41/vsp_41_intro_vs.pdf#page=12

·         List the phase of logical design.

·         List the detailed steps that go into the makeup of a logical design.

Skills and Abilities

·         Define a logical design.

·         Apply the detailed steps that go into the makeup of a logical design to a particular customer environment.

·         Distinguish between a logical and physical design.

·         Given a situation, translate given business requirements and the current state of a customer environment into a logical design.

Tools

·         Introduction to VMware vSphere

·         What’s New in VMware vSphere 4.1

·         VMware vSphere Evaluator’s Guide

The logical design includes the relationships between all major infrastructure components, while considering:

• The conceptual design

• Constraints and risks

The logical design is useful for understanding and evaluating the design of the infrastructure.

• Does it meet the goals and requirements, while staying within the constraints?

The logical design does not include physical details:

• For example, vendor models, host names, IP addresses, and port connections

The logical design is based on the information documented in the conceptual design and considers all constraints and risks. Where there are risks, they should be communicated to the organization along with a recommended action, so that a decision can be made and the design can move forward.

Use the logical design to create the physical design.

A physical design includes specific vendor and implementation details:

• Vendor models, host names, IP addresses, port connections, LUN sizes, number of CPUs, and other specific physical details

In the end, a good design:

• Involves the organization’s key stakeholders and SMEs

• Balances business goals and requirements with technical considerations and best practices

• Has documented rationales and considerations

• Includes enough detail to be unambiguous

• Is not unnecessarily complex

• Is repeatable

At the beginning of any design project you need to develop a high level vision for the project. This high-level vision includes the project

scope, goals, requirements, assumptions, and constraints.

The conceptual design focuses on achieving the organization’s business goals and requirements.

The logical design includes the relationships between all major infrastructure components and is useful for understanding and evaluating the design of the infrastructure.

A physical design includes specific vendor and implementation details.

Design criteria should include usability, manageability, security, and cost.

Educate key stakeholders and SMEs about vSphere and virtualization so that they can provide valuable input during the design project.

Designing is a balancing act between technical best practices and the organization’s goals, requirements, and constraints.

Objective 2.2 – Map Service Dependencies

Knowledge

·         Identify basic service dependencies for infrastructure and application services.

Skills and Abilities

·         Analyze service dependencies to determine requirements for the logical design of a multi site environment.

·         Identify the upstream/downstream service dependencies.

·         Having navigated logical components and their interdependencies, make decisions based upon all service relationships.

Tools

·         Timekeeping in VMware Virtual Machines

·         Virtualizing a Windows Active Directory Domain Infrastructure

·         Datacenter Operational Excellence Through Automated Application Discovery & Dependency Mapping

·         Product Documentation

Depending on the project, the optional installation and configuration document might include only high-level steps for implementing the design. On the other hand, the document might include step-by- step procedures for implementing the design. The level of detail typically depends on the cost of the project and whether the design is product-oriented or solution-oriented. A solution-oriented project typically includes more details specific to an organization’s needs.

In either case, these documents can refer to online VMware documentation for detailed step-by-step instructions as necessary. Assume that the reader is familiar with basic vSphere operation.

At a minimum, these documents should include the products listed above.

VCAP5-DCD - Hot Target - Objective - 1.3

Objective 1.3 – Determine Risks, Constraints, and Assumptions

Knowledge

·         Identify appropriate best practices related to a proposed design.                      

* Associate a role to the information that needs to be collected.

·         Differentiate between the general concepts of a risk, a requirement, a constraint, and an assumption.

Skills and Abilities

·         Given a business ask or request, determine whether it is a risk, a requirement, a constraint, or an assumption.

·         Given an organization, evaluate and respond to common inherent risks, constraints, and/or assumptions.

Tools

·         Developing Your Virtualization Strategy and Deployment Plan

Scope – Identify the project scope in detail

·         Properly identifying the scope prevents unintended project expansion.

·         Example: The virtualization project includes only the London datacenter’s test and development servers. At this time, it does not include any production servers or remote offices.

Goals – Identify and list the overall project goals that the organization wants to achieve

·          The project goals should be derived from the business goals of the organization.

·          Each project goal should be specific, measurable, and actionable.

·          Example: The organization wants to achieve a 25 percent reduction in operational costs by the end of the year

Requirements – Identify and list the key business and technical requirements that must be achieved in the project

• Example: The organization must comply with Sarbanes-Oxley (SOX) regulations.

• Example: The underlying infrastructure for any service defined as strategic must support a minimum of four 9s of uptime (99.99 percent).

Assumptions – Identify and list the design assumptions

• Assumptions are design components that are assumed to be valid without proof.

• Example: The datacenter uses shared (core) networking hardware across production and nonproduction infrastructures.

• Example: The organization has sufficient network bandwidth between sites to facilitate replication.

• Example: Security policies dictate server hardware separation between DMZ servers and internal servers.

Constraints – Identify and list the design constraints

• Constraints limit the design choices.

• Example: Due to a preexisting vendor relationship, host hardware has already been selected. The hardware is …

A constraint could be a business process, a business policy, or a technical limitation. Clearly list the constraints so that they can be reviewed for accuracy and

referred to during the design project.

If a particularly goal, requirement, or constraint cannot be met or creates a risk, discuss the issue with the key stakeholders and SMEs. Discuss it as early as possible in the design project so that the best possible compromise can be reached early in the design process.

Discussing issues and risks early in the design project also reduces the number of surprises in the end design. Surprises in the end design increase the risk of not reaching an agreement to move forward with implementation.

Risks – Identify any risks that might prevent achieving the project goals

• Example: The organization's main datacenter contains only a single core router, which is a single point of failure.

• Example: The lack of executive sponsorship places at risk the goal of virtualizing 75 percent of the datacenter by the end of 2010

The conceptual design focuses on achieving the organization’s business goals and requirements.

• Determine the entities that are affected by the project:

- Lines of business, users, applications, processes, management methods, physical machines, and so on

• Determine how the goals, requirements, and constraints map to each entity.

• Design the infrastructure that will be necessary to achieve each entity’s goals and requirements, while staying within the constraints.

- For example, where will you need availability, scalability, performance, security, manageability, and so on, while staying within cost and other constraints?

Document the conceptual design with diagrams, tables, and text.

Gathering information about your organization’s situation is part of the design methodology presented in this course. Choosing, and then interviewing, key technical personnel and project stakeholders to determine your organization’s situation is just as important as gathering workloadsizing information. The organization’s situation will affect your design.

Use interviews early in the design process to uncover things that affect the end design, such as project goals, budget constraints, hardware policy choices, and department boundaries. Sometimes, organizational boundaries and politics affect the achievable consolidation ratio. Key stakeholder and SME interviews help to uncover this information.

For example, one organization’s primary goal might be to reduce its datacenter footprint and the associated costs, while another organization’s goal might be to virtualize to meet the business continuity and disaster recovery (BC/DR) initiatives of its business.

The first organization might be seeking to achieve 10:1, 20:1, or higher consolidation ratios. The second organization, on the other hand, might be entirely satisfied with a 5:1 consolidation ratio, so long as the virtual infrastructure meets its disaster recovery requirements.

Organizational and political factors often affect the design, yet they are not strictly technical. Sometimes, resistance to virtualization exists due to the preconceptions and fears of decision makers. A feeling of control often accompanies owning physical hardware. The loss of physical hardware might result in a sense of loss of control. Decision makers might also have concerns about performance issues as well as concerns about the return on investment and total cost of ownership associated with virtualization. Resolving the doubts and fears of the decision makers is necessary to move quickly through the design process.

VCAP5-DCD - The Hot Target for VCDX

I am thinking to start blogging about the Objectives of both the exams soon.


VCAP4-DCD  - yes that's right this is version 4 for now as version 5 is not GA yet (but will be soon)

VCAP5-DCD - Once it becomes GA then link will be available.

VCP5-DT 

All other certification details are available here.

You can also find out the blog posting by others on the similar subject.

All the discussion and material is purely made for my own study purpose so you can make the changes and use it accordingly.

Brain dumps people - this is not the place you should visit as there won't be any questions and answers here ;-)

Well lets get started.

I am going to start posting the objectives for the Design Exam as it will be GA in near future. If any one wants to do any guest posting, all are welcome to contribute and share the knowledge.

Just contact me offline through @mandivs

VCAP5-DCD

Objective 1.1 – Gather and analyze business requirements 

(e.g. current availability, manageability)

Skills and Abilities

·         Determine the relevant data set required to understand the current customer environment.

·         Given a design requirement and data set within a multi site environment, determine which components would be included in a design.

·         Given results of a requirement gathering survey, identify the business requirements.

·         Given one or more business requirements, analyze and determine the impact of the requirements on the design.

Tools 

VMware Virtualization Case Studies                                 

Cloud Readiness Self-Assessment Too

Five Steps to Determine When to Virtualize Your Servers

-          A good  VMware design matches products, features, and capabilities to business needs

-          Business need is the combination of many things summarized by: requirements, constraints, assumptions

-          Resulting in the identification of – design decisions, justifications, impacts, risks

Architecture vision

-          Scope – project boundaries, eliminate creep

-          Goals – business problems we’re solving with measurable results

-          Requirements – must meet

-          Assumptions - valid but not proven, as few as possible

-          Constraints – limit design choices

-          Risks- every design will have them, find them and communicate them

The vision will guide the project through its phases

Which may not fall into requirements and constraints are fall in to assumptions

Take the assumptions from customer and get the clarity – valid but not proven

e.g. customer budgetary concern, don’t have enough infrastructure but will purchase additional hosts in future

Wrote categories on the board

Requirements, assumptions, constraints and risks (which are not conveyed properly or not clear)

Five steps of design

1)      Initial Design meeting – scope, goals, requirements, constraints, who should be invited?

2)      Current state analysis – complete datacenter inventory, virtualization candidates, tools, constraints, assumptions

3)      Stake holder and SME training educate SMEs who can help make informed design decisions

4)      Design sessions – design decisions with stakeholders/SMEs, no surprises later

5)      Design deliverable – documentation capacity analysis, hosts, vCenters, clusters, network, storage, monitoring, patching, backup, restore, DR, security, installation, operations, scalability, support, logical, physical etc.

Current state Analysis and vApps

-          Identify virtualization candidates and applications (identify non-virtualization candidates)

-          Capture baseline performance metrics including average and peak loads (feeds into capacity requirements, feeds into consolidation rations, can be used for comparison purposes)

-          Identify unique dependencies

-          Identify reusable hardware for the design

Design best practice Gems

-          Avoid known problems and achieve predictable results

-          Use as flexible guidelines, not rigid rules

-          Blend with the business unit goals and requirements

-          Evolve with technological advances

-          VCDX defense caution (Requirements, constraint, Assumption or Risk?

Managing downtime

-          So while major disasters may be infrequent events, the risk of downtime is still constant and costly.  The graph shown here breaks down the average cost of downtime by industry, but you can see that the average is around $1.5 million dollars per hour.  This includes not only lost revenue to the company, but also lost employee productivity and damage to a company’s relationship with partners and suppliers.  

-          Another key fact to point out is that downtime is common.  More than half of companies experience some amount of downtime in a given year, and some analysts have found that around a quarter of companies have had to declare a disaster at least once in the past five years.  Often these events are due to causes like an extended power outage, something you wouldn’t normally think of as being a disaster.  Companies who weren’t prepared to handle such disaster recovery situations would stand to lose millions of dollars and, if recovery takes long enough or is ultimately unsuccessful, could also lose their business.

Recovery Risk

-          So while major disasters may be infrequent events, the risk of downtime is still constant and costly.  The graph shown here breaks down the average cost of downtime by industry, but you can see that the average is around $1.5 million dollars per hour.  This includes not only lost revenue to the company, but also lost employee productivity and damage to a company’s relationship with partners and suppliers.  

-          Another key fact to point out is that downtime is common.  More than half of companies experience some amount of downtime in a given year, and some analysts have found that around a quarter of companies have had to declare a disaster at least once in the past five years.  Often these events are due to causes like an extended power outage, something you wouldn’t normally think of as being a disaster.  Companies who weren’t prepared to handle such disaster recovery situations would stand to lose millions of dollars and, if recovery takes long enough or is ultimately unsuccessful, could also lose their business.

 Additional Reading

http://www.vmworld.com/docs/DOC-4831  

http://www.vmworld.com/docs/DOC-4645 

   

Recovery Time Objective (RTO) is the period of time within which systems, applications, or functions must be recovered after an outage. This defines the amount of downtime that a business can endure, and survive. Recovery time includes: fault detection, data recovery, and bringing applications back online.

Recovery Point Objective (RPO) is the point in time to which systems and data must be recovered after an outage. This defines the amount of data loss a business can endure. Different business units within an organization may have varying RPOs.

Business Continuity is a holistic approach to planning, preparing, and recovering from an adverse event. The focus is on prevention, identifying

risks, and developing procedures to ensure the continuity of business function.

Disaster recovery planning should be included as part of business continuity.

Objectives of Business Continuity:

- Facilitate uninterrupted business support despite the occurrence of problems.

- Create plans that identify risks and mitigate them wherever possible.

- Provide a road map to recover from any event.

Disaster Recovery is more about specific cures, to restore service and damaged assets after an adverse event. In our context, Disaster Recovery is the coordinated process of restoring systems, data, and infrastructure required to support key ongoing business operations.

Business Continuity Planning (BCP) is a risk management discipline. It involves the entire business--not just IT. BCP proactively identifies vulnerabilities and risks, planning in advance how to prepare for and respond to a business disruption. A business with strong BC practices in place is better able to

continue running the business through the disruption and to return to “business as usual.”

BCP actually reduces the risk and costs of an adverse event because the process often uncovers and mitigates potential problems.

In summary you have 3 major complications in a traditional DRP that is based on physical systems:

First, a variety of information and data that needs to be protected. All of which needs to be available to ensure recovery. These different kinds of data require different processes and tools. For example, backing up system disks (which are typically on internal storage) uses a different process than backing up data disks. Tracking hardware configuration requirements is also difficult. A common approach is to use spreadsheets, which easily become out of date or get lost. And backups used to protect data can be easily misplaced or corrupted.

Second, a very complex recovery process. Organizations are also faced with a complex recovery process with lots of steps, which can cause recovery to fail. For example, it is easy to miss a hardware dependency that leads to a failure and additional steps. Given the number of manual steps, it is easy for the staff who are executing recovery to make errors that impede recovery. All in all, the process can easily take days, and maybe even longer.

Third, DRPs are very difficult to test. Organizations face significant difficulties testing recovery plans. Tests may require additional servers and storage arrays so that the recovery environment is not disturbed. It is also very difficult to test without disrupting production systems and protecting the process.

Disaster protection for services tends to be tiered. Tier one includes services for which no downtime at all can be tolerated. These services tend to be deployed from the start in active-active configurations. For the remaining services, however, disaster recovery plans are typically in a three-ring binder to be used in the event of a disaster. Instructions in the binder describe how to recover a particular server, configure particular hardware, reinstall the operating system, recover from tape, and so forth.

Of course, these steps are very manual, and they are often very difficult to test.

A Recovery Point Objective is the point in time restored systems have to be started with. A Recovery Time Objective is the amount of time allowed between the disaster and the time when you will have recovered systems to match the RPO. The terms “recovery point objective” and “recovery time objective” will be discussed in more depth later in this course.

Disaster recovery planning  and business continuity planning  are two different things. A DRP is designed to be a plan or a set of procedures that guides employees during the chaos of a disaster and the time immediately following a disaster. It is focused on safeguarding assets and personnel and it is procedure-oriented. It will include things like a step by step procedure on how to get critical systems back online fast at the recovery site. By nature, it is designed to provide a temporary safe harbor for the business. This involves failover planning. Failover is the process by which key business systems are transitioned rapidly during an emergency to a remote recovery site. In contrast business continuity is the process of keeping daily operations running after the disaster.

A Business continuity plan, or BCP  provides guidance on how to keep day to day business operations going at the recovery site. Business continuity planning also changes depending on perspective. For example, the IT department might be concerned mainly about data backups. (Data backups must continue to be made even while operating at the recovery site.) Other departments might have a wider view. To get a call center back online, you not only need your customer data, you also need a facility with desks and phones.

BCPs  should specifically address three things. First, how to run business operations with the smaller capacity of the recovery site. Second, how to prevent interference between recovery operations and the production operations that were formally run at the site. And third, how to eventually failback to the original primary site.

Talk about RPO (recovery point objective) – which is about how much data is lost, i.e., since the last BU.  We can handle most anything, from minutes to years.

Also talk about RTO (recovery time objective) – which is about how quick we can get back to work.  We cannot do real time or near real-time.  Hours is generally what we can do, but it is very important to understand we must test to determine exactly what is possible 

Continued .......

Objective 1.2 – Gather and analyze application requirements [soon]