Enterprise OCVS Sizing Deep Dive

A Structured vCPU-Based Architecture Framework

1. Introduction

Sizing Oracle Cloud VMware Solution (OCVS) is not a spreadsheet exercise.

It is a controlled architectural decision balancing:

• Performance
• Resiliency
• Failure tolerance
• Licensing exposure
• Growth modeling
• Financial discipline

Incorrect sizing results in either:

• Performance degradation and instability
  or
• Significant unnecessary cost

This document defines a disciplined, enterprise-grade sizing framework using a vCPU-based modeling approach, validated against failure-state capacity and memory constraints.

This methodology is suitable for:

• Enterprise migrations
• Data center exit programs
• Consolidation initiatives
• Disaster recovery transformations
• Architecture review boards

2. Understanding What OCVS Really Is

Before modeling begins, architecture must align with platform reality.

OCVS is:

• Dedicated bare-metal infrastructure
• Fixed-core ESXi hosts
• Fixed physical memory per node
• vSAN-based storage (or OCI Block)
• Cluster-based failure domain

You are not sizing elastic cloud abstraction.

You are engineering physical host clusters.

Every sizing decision must survive host failure.

3. Data Acquisition – RVTools as Baseline

Sizing must begin with validated workload inventory.

Export from RVTools:

• vCPU tab
• vMemory tab
• vPartition
• vDatastore
• vHost

Clean the dataset before modeling:

• Remove powered-off VMs
• Remove zombie workloads
• Flag old snapshots
• Identify oversized allocations
• Normalize obvious over-provisioning

Rightsizing before migration frequently reduces OCVS footprint by 20–40%.

Do not skip normalization.

4. Workload Segmentation (Mandatory Step)

Enterprise estates are heterogeneous.

Apply workload classification before calculating consolidation.

Define three baseline categories:

• Mission Critical
• General Production
• Dev/Test

This classification drives consolidation ratio, headroom policy, and failure tolerance requirements.

Applying one ratio globally is architectural malpractice.

5. CPU Modeling – vCPU Consolidation Framework

This deep dive intentionally uses a vCPU-based modeling approach for clarity, workshop defensibility, and executive transparency.

Recommended Baseline Consolidation Ratios

These are starting points, not targets.

Core Calculation

For each workload class:

Required Physical Cores = Total vCPU / Consolidation Ratio

Example:

Mission Critical:
120 vCPU / 2 = 60 cores

General Production:
400 vCPU / 4 = 100 cores

Dev/Test:
240 vCPU / 6 = 40 cores

Total steady-state core requirement = 200 cores

6. Mapping to OCVS Host Specification

Assume:

64 physical cores per OCVS node

Steady-state nodes required:

200 / 64 = 3.125 → 4 nodes

This is incomplete.

Steady-state modeling is insufficient.

7. Failure-State Validation (N+1 Is Not Optional)

Clusters must survive loss of one host.

If 4 nodes are deployed:

Failure-state available cores = 3 × 64 = 192

But required cores = 200

Cluster fails under host loss.

Therefore, 4 nodes are insufficient.

Minimum safe design = 5 nodes.

Failure-state:

4 × 64 = 256 cores available → safe margin restored.

Failure-state modeling is mandatory in enterprise design.

Consolidation must hold under degraded capacity.

8. Memory Discipline – The Real Constraint

In OCVS environments, memory pressure is usually more dangerous than CPU oversubscription.

From RVTools:

Use Memory Active (not allocated).

Apply:

• 20% growth factor
• 15–20% cluster headroom

Total Required Memory = Active × Growth × Headroom

Avoid aggressive memory overcommit in production.

Production clusters should not rely on ballooning or swap during steady-state.

Memory frequently determines final node count before CPU.

9. Storage Modeling – vSAN Reality

From RVTools:

Use actual used storage.

Apply:

• 20% growth
• 25–30% vSAN slack space

Usable Capacity = (Used × 1.2) / (1 - 0.25)

For FTT=1:

Raw Capacity Required = Usable × 2

Never design vSAN above 70–75% effective utilization.

Storage headroom protects performance and rebuild operations.

10. Final Cluster Sizing Logic

At this stage you have:

• Nodes required for CPU
• Nodes required for Memory
• Nodes required for Storage

Final cluster size = Maximum of the three.

Then revalidate failure-state again.

This prevents CPU-only bias.

11. Disaster Recovery Alignment

DR sizing must reflect business RTO and RPO — not symmetry.

Define DR mode:

DR Required Cores = Production Required Cores × DR Factor

Never blindly mirror production unless justified.

DR architecture must align with business continuity objectives.

12. Broadcom Licensing Impact

Core-based licensing models may influence consolidation strategy.

Higher consolidation reduces node count, but increases per-host density.

Sizing and licensing must be reviewed together.

Ignoring licensing during sizing creates downstream friction.

13. What vCPU-Based Modeling Does Not Capture

This approach does not inherently model:

• CPU Ready %
• Latency sensitivity
• NUMA alignment
• Burst-heavy applications
• Co-Stop behavior

Therefore:

Pilot migration and performance validation remain mandatory.

vCPU modeling is structured abstraction — not telemetry replacement.

14. Common Enterprise Sizing Failures

• Applying 4:1 globally
• Ignoring host failure state
• Overcommitting memory
• Ignoring vSAN slack
• No growth modeling
• Copying on-prem oversubscription blindly
• Designing DR as 1:1 without SLA validation

These mistakes either inflate cost or create operational instability.

15. Architectural Principle

OCVS sizing is not about density.

It is about predictable degradation under failure.

2:1 protects critical systems.
4:1 optimizes enterprise production.
6–8:1 extracts lab efficiency.

The correct consolidation ratio is the one that survives host loss without operational instability.

Density without failure validation is risk accumulation.

Predictability is architecture discipline.