VMware vSAN combines local disks in clustered hosts into shared software-defined storage. This guide explains the architecture, disk groups, network and availability considerations, pre-deployment checks, capacity and failure-domain boundaries, and the monitoring records needed after handover. The diagrams are existing local technical material; versions, compatibility and performance must be validated in the actual environment.
Continue with the virtualization and storage solutions, service catalogue, technical articles。
Overall architecture
vSAN presents local host devices as a distributed datastore. The design boundary includes the cluster, disk groups, policies, network paths and operating responsibilities.
Figure 01: Architecture relationship diagram.
Use this view to confirm which hosts, storage resources and policy decisions belong to the proposed cluster; it is not a product performance claim.
Figure 02: Architecture relationship diagram.
Use this view to confirm which hosts, storage resources and policy decisions belong to the proposed cluster; it is not a product performance claim.
Figure 03: Architecture relationship diagram.
Use this view to confirm which hosts, storage resources and policy decisions belong to the proposed cluster; it is not a product performance claim.
Figure 04: Architecture relationship diagram.
Use this view to confirm which hosts, storage resources and policy decisions belong to the proposed cluster; it is not a product performance claim.
Nodes and disk groups
Each host contributes cache and capacity devices through its disk groups. Device roles, health and replacement procedures should be recorded before deployment.
Figure 05: Node and disk-group technical diagram.
The diagram helps separate host membership, device roles and the path used to add or replace capacity.
Figure 06: Node and disk-group technical diagram.
The diagram helps separate host membership, device roles and the path used to add or replace capacity.
Figure 07: Node and disk-group technical diagram.
The diagram helps separate host membership, device roles and the path used to add or replace capacity.
Figure 08: Node and disk-group technical diagram.
The diagram helps separate host membership, device roles and the path used to add or replace capacity.
Network and availability
Storage traffic depends on predictable host-to-host connectivity. VLANs, MTU, uplinks, routing boundaries and policy availability should be tested together.
Figure 09: Network and availability relationship diagram.
Treat the network path as part of the storage design; a topology picture alone does not prove latency, throughput or resilience.
Figure 10: Network and availability relationship diagram.
Treat the network path as part of the storage design; a topology picture alone does not prove latency, throughput or resilience.
Figure 11: Network and availability relationship diagram.
Treat the network path as part of the storage design; a topology picture alone does not prove latency, throughput or resilience.
Figure 12: Network and availability relationship diagram.
Treat the network path as part of the storage design; a topology picture alone does not prove latency, throughput or resilience.
Pre-deployment checks
Before creating a cluster, check hardware and firmware compatibility, vSphere versions, device state, network services, licensing and the business change window.
Figure 13: Pre-deployment and compatibility reference.
Record the source of each compatibility decision and the validation evidence that will be retained for handover.
Figure 14: Pre-deployment and compatibility reference.
Record the source of each compatibility decision and the validation evidence that will be retained for handover.
Figure 15: Pre-deployment and compatibility reference.
Record the source of each compatibility decision and the validation evidence that will be retained for handover.
Figure 16: Pre-deployment and compatibility reference.
Record the source of each compatibility decision and the validation evidence that will be retained for handover.
Figure 17: Pre-deployment and compatibility reference.
Record the source of each compatibility decision and the validation evidence that will be retained for handover.
| Check area | What to record |
|---|---|
| Nodes and disks | Host inventory, disk-group roles and health evidence. |
| Network | VLAN, MTU, uplink, routing and validation results. |
| Policies and capacity | Protection policy, slack space, rebuild and maintenance headroom. |
| Failure domains and recovery | Site/host boundaries, recovery steps and responsible owner. |
| Operations record | Alerts, thresholds, changes, resync and handover notes. |
Capacity and failure domains
Usable capacity is constrained by protection policy, slack space, maintenance needs and the failure domains available in the site design.
Figure 18: Capacity and failure-domain planning diagram.
Plan for rebuild and maintenance headroom rather than treating raw disk capacity as usable application capacity.
Figure 19: Capacity and failure-domain planning diagram.
Plan for rebuild and maintenance headroom rather than treating raw disk capacity as usable application capacity.
Figure 20: Capacity and failure-domain planning diagram.
Plan for rebuild and maintenance headroom rather than treating raw disk capacity as usable application capacity.
Figure 21: Capacity and failure-domain planning diagram.
Plan for rebuild and maintenance headroom rather than treating raw disk capacity as usable application capacity.
Figure 22: Capacity and failure-domain planning diagram.
Plan for rebuild and maintenance headroom rather than treating raw disk capacity as usable application capacity.
Operations monitoring
After handover, monitor health, capacity, policy compliance, resync activity, alerts and configuration changes, and keep the records tied to the cluster.
Figure 23: Operations and monitoring reference.
A repeatable monitoring and change log is more useful than a one-time screenshot when diagnosing a later storage event.
Figure 24: Operations and monitoring reference.
A repeatable monitoring and change log is more useful than a one-time screenshot when diagnosing a later storage event.
Figure 25: Operations and monitoring reference.
A repeatable monitoring and change log is more useful than a one-time screenshot when diagnosing a later storage event.
Figure 26: Operations and monitoring reference.
A repeatable monitoring and change log is more useful than a one-time screenshot when diagnosing a later storage event.
Fit boundaries
vSAN can suit workloads that fit the validated vSphere and storage-policy model. It is not a universal replacement for every array, backup or archive requirement.
Figure 27: Workload-fit and boundary reference.
Confirm workload, backup, recovery, latency and compliance requirements before selecting the storage architecture.
Figure 28: Workload-fit and boundary reference.
Confirm workload, backup, recovery, latency and compliance requirements before selecting the storage architecture.
Implementation reference
These final diagrams are checkpoints for a technical discussion, not a substitute for compatibility testing or a signed design.
Figure 29: Implementation discussion reference.
Use the image as a conversation aid and retain the final decisions in the project record.
Figure 30: Implementation discussion reference.
Use the image as a conversation aid and retain the final decisions in the project record.
FAQ
Is vSAN a replacement for every external storage array?
No. Confirm workload, protocol, backup, recovery, compliance and operational requirements before selecting the architecture.
What should be checked before deployment?
Validate the hardware and firmware matrix, vSphere version, disk health, network services, licensing and the change window.
How should capacity be planned?
Include policy overhead, slack space, rebuild and maintenance headroom, and the available failure domains rather than using raw disk totals.
What belongs in the handover record?
Keep the cluster inventory, policies, network checks, compatibility evidence, alert thresholds, change history and recovery notes.