What each design quality means, with example requirements and the VCF 9.0 design choices that serve them.
From Ultra Transcenders 2V0-13.25 by Tony Rough
Objective 1.4 asks you to tell availability, manageability, performance, recoverability and security apart, which in practice means sorting each non-functional requirement into the quality it serves.
| Quality | What it is about | Typical measures |
|---|---|---|
| Availability | Service keeps running through component failures | Uptime %, failures tolerated (host, rack, zone) |
| Manageability | Ease of operating, changing, scaling and sizing | Admin effort, consoles, upgrade effort, headroom |
| Performance | How well workloads run under load | Latency, throughput, IOPS, response time |
| Recoverability | Restoring service and data after loss or disaster | RPO, RTO, restore success |
| Security | Protecting confidentiality, integrity and access | Authentication, isolation, encryption, compliance |
Availability and recoverability are the pair most often confused. Availability means the service rides through a failure the design anticipated, usually automatically. Recoverability means restoring service after an outage or data loss, measured by two objectives that the Design Blueprints describe for disaster recovery: the recovery point objective (RPO), the delay between data being written in one location and being replicated to the other, and the recovery time objective (RTO), the time for workloads to be running at the second location once the manually started failover begins. The blueprints also note that a stretched cluster is technically an availability model rather than a recovery model, because writes are replicated to the other site instantly, although it can help with some recovery scenarios.
The exam objectives place scalability, lifecycle management and capacity management under manageability (objective 3.6), not under performance.
| Requirement statement | Quality | Reason |
|---|---|---|
| Management components keep running if one host fails | Availability | Rides through a failure |
| A single rack failure must not take workloads offline | Availability | Failure tolerance |
| Lose no more than 15 minutes of data in a disaster | Recoverability | An RPO |
| Services run in the second region within 4 hours | Recoverability | An RTO |
| Patch every cluster from one console | Manageability | Operating effort |
| Grow to twice today’s VM count without redesign | Manageability | Scalability |
| Forecast when clusters will run out of memory | Manageability | Capacity management |
| vMotion must not starve vSAN traffic under contention | Performance | Traffic behaviour under load |
| Database storage latency stays below the agreed threshold | Performance | Latency target |
| Tenants cannot see each other’s networks | Security | Isolation |
| Administrators sign in with corporate identities only | Security | Authentication |
The blueprint design profiles map onto the same qualities: their Availability and Recoverability attributes match directly, Isolation (hypervisor-based, network traffic type, cluster-based, tenant-to-tenant) is mostly a security concern that also protects performance, and Expansion is a manageability concern.
| Quality | Example VCF design choices | Covered in |
|---|---|---|
| Availability | vSphere HA, HA NSX Manager, multi-rack or stretched clusters | Chapter 8: Designing for availability |
| Manageability | VCF Operations lifecycle, vSphere Lifecycle Manager images, password rotation | Chapter 9: Designing for manageability |
| Performance | vSAN ESA, 25GbE for vSAN, jumbo frames, traffic separation | Chapter 10: Designing for performance |
| Recoverability | Scheduled backups to an SFTP target, replication with VMware Live Recovery | Chapter 11: Designing for recoverability |
| Security | VCF Identity Broker with the corporate IdP, CA-signed certificates | Chapter 12: Designing for security |
Common trap: Treating a stretched cluster as the disaster recovery design - it is an availability construct within one region; writes reach both sites at once, so logical corruption is replicated instantly, and a region-wide event needs a separate recovery strategy.
Common trap: Filing scalability under performance - in this exam scalability, lifecycle and capacity management sit under manageability; performance is about how well workloads run, not how far the platform can grow.
This note is one section of Ultra Transcenders 2V0-13.25: VMware Cloud Foundation 9.0 Architect, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Broadcom TechDocs.
Free to read with Kindle Unlimited. Opens Amazon in a new tab.
About the book · 2V0-13.25 terms in the glossary · All 2V0-13.25 study notes
How to tell the five apart, what each obliges the architect to do, and worked classifications.
What belongs in a conceptual model, what doesn't, and how it traces back to business objectives.
How to record a design decision so it traces to a requirement and states its implications, the way VCF design elements do.
The requirements that call for a separate workload domain, and when another cluster in an existing domain is enough.
Prerequisites, latency and bandwidth limits, the vSAN witness, host counts and what fails over automatically.
Bulk, vMotion, Replication Assisted vMotion, Cold and OS Assisted Migration compared by downtime, scale and source platform.