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
-
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
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]
