Capacity is split into silos
Hosts and workloads reserve capacity separately, leaving utilization low and allocation inflexible.
Solves: organize local disks into a policy-driven shared pool.Platform view
Data platform relationships
- 01 Data path
- 02 Storage pool
- 03 Fault domain
- 04 Protection
02 / System integration and infrastructure
SAN and Storage Virtualization
Organize local disks, storage policies, failure domains and capacity into one resource pool, reducing the complexity, low utilization and unclear failure boundaries of traditional SAN expansion.
Storage objectsHosts / disk groups / pools
Technical focusPolicies / failure domains / capacity
Delivery resultUnified / redundant / operable
01 / Problem profile
Storage virtualization is not about putting disks together, but making a resource pool predictably carry workloads
In traditional storage environments, capacity, performance, controllers, links and failure domains are managed separately. Expansion requires redesign, and capacity or performance gaps only appear after workload growth; incident impact is also hard to predict.
The core is to place local disks, disk groups, policies and failure domains in one resource model, so workloads receive storage that matches performance, capacity and redundancy requirements.
Implementation checks hardware compatibility, network bandwidth, disk types, growth, rebuild windows and operating tools so structural issues do not appear after the pool goes live.
Three core integration gaps
Reduce recurring delivery, connectivity and handover problems to three core gaps before sequencing the technical work.
Performance and redundancy cannot be checked together
Capacity or individual disk metrics alone do not show the real performance and protection level of a policy.
Solves: validate policy, performance, redundancy and failure domains together.Node or disk failure impact is unpredictable
Rebuilds, degraded states and headroom are not in the operating plan, leaving incidents to improvisation.
Solves: define failure domains, rebuild windows and recovery conditions.Storage policies do not reach handover records
Later operators see capacity but not which policy each workload should use.
Solves: hand over policy, capacity, alerts and operating baselines.02 / Architecture
Make the boundary visible from host disks to the unified pool
Storage virtualization connects physical disks, disk groups, hosts, networks and policies into a manageable resource model.
The architecture explains data placement, policy protection, failure-domain isolation and how hosts and storage networks carry read/write and rebuild traffic.
This makes it possible to judge whether workloads remain within acceptable performance and protection boundaries during growth, maintenance or disk failure.
Four relationship layers
Trace the chain from site connectivity to business operations
A system needs to be read in its relationships to understand which links, access rules, applications and operating actions a device change will affect. These four layers form one path from facility conditions to business outcomes.
Hosts and disk groups
Confirm disk types, cache, capacity and host distribution.
Policies and protection
Define replica, erasure, performance and availability policies by workload.
Networks and failure domains
Isolate storage traffic and confirm node, rack and link failure boundaries.
Capacity and operations
Continuously monitor capacity, rebuilds, alerts and policy compliance.
03 / Technical scope
Break the vSAN solution into five verifiable technical surfaces
The scope cannot stop at “build a resource pool”; it must explain how hardware, networking, policy, capacity and handover are implemented.
From compatibility to operating policy, each surface determines whether the pool can scale and recover reliably.
Breaking them down turns platform capability into executable installation, configuration and acceptance tasks.
Hardware compatibility
Verify hosts, disks, controllers, firmware and version compatibility.
Hosts / disks / firmware / versionsNetwork connectivity
Confirm storage bandwidth, latency, MTU, redundancy and port configuration.
Bandwidth / latency / MTU / redundancyStorage policies
Define replicas, performance, space efficiency and failure response by workload tier.
Replicas / performance / space / availabilityCapacity and rebuilds
Reserve growth, rebuilds and maintenance windows so the pool is not exhausted.
Growth / rebuild / headroom / windowsOperations handover
Hand over capacity, policy, alerts, nodes, disks and daily operating instructions.
Capacity / policy / alerts / operations04 / Connectivity and resources
The storage network sets the pool’s performance ceiling and failure radius
vSAN read/write, synchronization and rebuilds depend on stable paths, so networking must be validated with storage policy.
Consider throughput, latency, link redundancy, switch configuration and isolation so peak workloads and rebuild traffic do not interfere.
Real read/write, failover and rebuild tests reveal the pool’s actual boundary under abnormal conditions.
Paths and redundancy
Confirm dual paths between hosts, switches and nodes.
Traffic isolation
Separate storage, management, business and migration traffic.
Performance validation
Validate bandwidth, latency, packet loss and pool behavior at peak.
Failover
Test business impact across link, switch, node and disk failures.
05 / Capacity and operations
The pool must keep answering whether capacity, policy and failure headroom remain sufficient
After go-live, capacity, policy compliance, node state, disk health and alerts need a continuous operating view.
A resource pool keeps changing as workloads grow, nodes expand, disks are replaced and policies change, altering usable capacity and rebuild boundaries.
Daily checks, capacity trends, alert levels and change records turn platform state into signals operators can act on quickly.
Capacity trend
Calculate usable capacity around growth and protection policy.
Policy compliance
Find gaps between workload policy and actual storage configuration.
Nodes and disks
Monitor health, temperature, performance, rebuilds and replacements.
Changes and expansion
Expand only after capacity, versions and maintenance windows are clear.
06 / Delivery and handover
Deliver the pool as a maintainable platform from compatibility to policy acceptance
A vSAN project connects hardware, networks, platform, policy, workloads and operations in one delivery chain.
- 01
Compatibility and baseline
Review hardware, versions, networks, disks and workloads.
- 02
Cluster and network
Configure hosts, disk groups, switching and redundancy.
- 03
Policy and pool
Build the pool, storage policies, capacity and failure domains.
- 04
Workload testing
Validate performance, failover, rebuild, alerts and workload access.
- 05
Operations handover
Hand over policies, capacity, nodes, disks and daily checks.
07 / Handover records
Make storage policy, capacity and failure boundaries reusable records
The operating value of storage virtualization continues through records for policy, capacity, alerts and incident handling.
Cluster and disks
Keep hosts, disk groups, disk types, nodes and failure domains.
Policy and capacity
Record workload tiers, storage policy, usable capacity and growth headroom.
Networks and tests
Save ports, MTU, bandwidth, latency, failover and rebuild results.
Alerts and operations
Describe checks, alert levels, disk replacement, expansion and rollback.
FAQ
Frequently asked questions
Confirm the service boundary and current conditions before deciding delivery scope and ongoing support.
What is the core difference between vSAN and traditional SAN?
Traditional SAN usually provides storage through a dedicated array. vSAN organizes local disks across cluster hosts into a shared pool governed by policy.
Does storage virtualization only require software attention?
No. Hardware compatibility, disks, network bandwidth, MTU, failure domains, capacity headroom and operations all affect the result.
Does pool expansion require downtime?
It depends on the architecture, versions, workload window and expansion method. Dependencies, rollback and validation must be confirmed first.