As I am moving close to the VCDX design defense final lap, I have started working out on the documentation. During the first phase of the design, I figured out that I have not seen a standard post which can qualify the design factors and how does some one strengthen their design qualities that derives from design factors. I thought that is going to be the base or foundation for any design. In this post I am going to discuss the design factors and design qualities. So before I jump straight to it, let me make create a base here by knowing the design factorial terminology first.
- Requirements – A mandatory condition that must be satisfied, which can be Functional or Non Functional
- Risks – Anything that could potentially prevent the design from satisfying the requirement
- Assumptions – Any aspect of the design that is accepted as a fact and is not backed by a requirement or a constraint
- Constraints – Anything that restricts the vSphere architects options in satisfying the requirement
- Design Factors – Term used to describe the four factors that influence a vSphere design
Requirement (Functional & Non Functional)
Functional Requirements are the one that define what should the design do. An example could be whether the design must be capable of supporting additional growth in the environment.
Non-Functional Requirements are the one that would state how would the design meet the functional requirements. An example could be the fact that the design must provide sufficient capacity to handle current workloads and account for 20% growth in the number of workloads over the next year. However some times it also lead to Constraints.
Risks are broadly categorized as anything that potentially block the design from achieving it’s goal. For an example, the existing staff does not have the necessary skills or experience to manage the vSphere environment or the existing storage array does not have the sufficient capacity to meet the projected growth requirements. They are also categorized in three distinctive areas:
Requirements come from the client where as normally assumptions come from the architect for some unclear or undecided situations.
For an example, this design assumes that the environment would grow by approximately 20% year on year. Another example could be, It is assumed that the customer would use the existing monitoring and management solution in the new vSphere environment.
Constraints are the mirrored image of Non Functional Requirements. For example, Cisco would be the chosen vendor for all networking equipments.
Determining the Design Factors
A picture is worth 1000 words.
Design Qualities that derived from the Design factors
The architecture framework uses a common model to describe the key design qualities of a well-designed VMware infrastructure. These qualities are used to categorize requirements and design decisions and to assess infrastructure maturity.
Availability indicates the effect of a design choice on the ability of a technology and the related infrastructure to achieve highly available operation. Key metrics: % of uptime.
Availability = (Uptime / (Uptime +Downtime)) x 100
Availability = (Elapsed Time – Downtime) / Elapsed Time) x 100
Example: For example, in the last 30 days (43, 200 minutes), a system that has been online and available for 29 days 23 hours and 34 minutes (43,174 minutes). In other words it has been offline for 26 minutes within in a 30 day (43,200 min) period due to an unscheduled outage:
Elapsed Time (Minutes in Month) =43200
Downtime Minutes = 26
Availability = (43,174/(43174 + 26)) x 100 = 99.9%
Availability = ((43,200 – 26)/43,200) x 100 = 99.9%
Manageability indicates the effect of a design choice on the flexibility of an environment and the ease of operations in its management. Sub-qualities might include scalability and flexibility. Higher ratios are considered better indicators.
- Servers per administrator
- Clients per IT personnel
- Time to deploy new technology
Performance indicates the effect of a design choice on the performance of the environment. This does not necessarily reflect the impact on other technologies within the infrastructure.
- Response time
Response time = total time taken/total number of requests
Example: In a grocery store the cashier takes 2 minutes to checkout each customer. For 10 customers, total time taken would be 20 minutes.
Response time= 20/10 minutes/requests
Response time = 1200/10 seconds/request
Note: Doesn’t mean that throughput = 1/Response Time
Example: In the same grocery store what if 10 people used this same checkout lane, but each person arrived in line 1 minute after the last person was done checking out? The cashier is just twiddling his thumbs, waiting for a customer for 1 minute. The cashier is still capable of checking out a customer in 2 minutes, so the average response time is still 2 minutes / customer, but the throughput of people coming out of the checkout lane is not the same.
Response time = 20 minutes / 10 checkout= 2 minutes / checkout
Latency = 0 minutes / 10 checkouts = 0 minutes / checkout
Throughput = 10 checkouts / 29 minutes = .34 checkouts / minute
Recoverability indicates the effect of a design choice on the ability to recover from an unexpected incident, which affects the availability of an environment.
- RTO – Recovery Time Objective
- RPO – Recovery Point Objective
Security indicates the ability of a design choice to have a positive or negative impact on overall infrastructure security. Can also indicate whether a quality has an impact on the ability of a business to demonstrate or achieve compliance with certain regulatory policies.
- Unauthorized access prevention
- Data integrity and confidentiality
- Forensic capabilities in case of a compromise