|
General
|
|
|
- Fully Supported
- Limitation
- Not Supported
- Information Only
|
|
Pros
|
- + Extensive platform support
- + Extensive data protection capabilities
- + Flexible deployment options
|
- + Fast streamlined deployment
- + Strong VMware integration
- + Policy-based management
|
- + Built for performance and robustness
- + Broad range of hardware support
- + Well suited for open private cloud platforms
|
|
Cons
|
- - No native data integrity verification
- - Dedup/compr not performance optimized
- - Disk/node failure protection not capacity optimized
|
- - Single hypervisor and server hardware
- - No bare-metal support
- - Very limited native data protection capabilities
|
- - Only basic support for VMware and Hyper-V
- - No native dedup capabilities
- - No native encryption capabilities
|
|
|
|
Content |
|
|
|
|
WhatMatrix
|
WhatMatrix
|
WhatMatrix
|
|
|
|
Assessment |
|
|
|
|
Name: SANsymphony
Type: Software-only (SDS)
Development Start: 1998
First Product Release: 1999
NEW
DataCore was founded in 1998 and began to ship its first software-defined storage (SDS) platform, SANsymphony (SSY), in 1999. DataCore launched a separate entry-level storage virtualization solution, SANmelody (v1.4), in 2004. This platform was also the foundation for DataCores HCI solution. In 2014 DataCore formally announced Hyperconverged Virtual SAN as a separate product. In May 2018 integral changes to the software licensing model enabled consolidation because the core software is the same and since then cumulatively called DataCore SANsymphony.
One year later, in 2019, DataCore expanded its software-defined storage portfolio with a solution especially for the need of file virtualization. The additional SDS offering is called DataCore vFilO and operates as scale-out global file system across distributed sites spanning on-premises and cloud-based NFS and SMB shares.
Recently, at the beginning of 2021, DataCore acquired Caringo and integrated its know how and software-defined object storage offerings into the DataCore portfolio. The newest member of the DataCore SDS portfolio is called DataCore Swarm and together with its complementary offering SwarmFS and DataCore FileFly it enables customers to build on-premises object storage solutions that radically simplify the ability to manage, store, and protect data while allowing multi-protocol (S3/HTTP, API, NFS/SMB) access to any application, device, or end-user.
DataCore Software specializes in the high-tech fields of software solutions for block, file, and object storage. DataCore has by far the longest track-record when it comes to software-defined storage, when comparing to the other SDS/HCI vendors on the WhatMatrix.
In April 2021 the company had an install base of more than 10,000 customers worldwide and there were about 250 employees working for DataCore.
|
Name: VxRail
Type: Hardware+Software (HCI)
Development Start: 2015
First Product Release: feb 2016
VCE was founded late 2009 by VMware, Cisco and EMC. The company is best known for its converged solutions VBlock and VxBlock. VCE started to ship its first hyper-converged solution, VxRack, late 2015, as part of the VMware EVO:RAIL program. In February 2016 VCE launced VxRail on Quanta server hardware. After completion of the Dell/EMC merger however, VxRail became part of the Dell EMC portfolio and the company switched to Dell server hardware.
VMware was founded early 2002 and began to ship its first Software Defined Storage solution, Virtual SAN (vSAN), in 2014. The vSAN solution is fully integrated into the vSphere Hypervisor platform. In 2015 VMware released major updates in the second itiration of the product and continues to improve the software ever since.
In August 2017 VxRail had an install base of approximately 3,000 customers worldwide.
At the end of May 2019 the company had a customer install base of more than 20,000 vSAN customers worldwide. This covers both vSAN and VxRail customers. At the end of May 2019 there were over 30,000 employees working for VMware worldwide.
|
Name: StorPool Distributed Storage (StorPool Storage)
Type: Software-only (SDS)
Development Start: 2011
First Product Release: Nov 2012
StorPool was founded in 2011 and began to ship its first software-defined storage (SDS) platform, StorPool Distributed Storage, towards the end of 2012 to early access customers. In October 2013 the StorPool solution became Generally Available (GA). StorPool combines direct-attached storage drives from multiple standard servers to create a single pool of shared block storage. StorPool leverages a fully-distributed, shared-nothing architecture. All storage functions are performed by all servers that are part of the cluster on an equal peer-to-peer basis. StorPool can be used with any industry standard x86 server hardware.
StorPool is a mature SDS offering that has been running in production environments for over 7 years now and up to multi-petabyte scale.
The platforms customer install base is unknown. There are currently more than 30 employees working for StorPool.
|
|
|
|
GA Release Dates:
SSY 10.0 PSP12: jan 2021
SSY 10.0 PSP11: aug 2020
SSY 10.0 PSP10: dec 2019
SSY 10.0 PSP9: jul 2019
SSY 10.0 PSP8: sep 2018
SSY 10.0 PSP7: dec 2017
SSY 10.0 PSP6 U5: aug 2017
.
SSY 10.0: jun 2014
SSY 9.0: jul 2012
SSY 8.1: aug 2011
SSY 8.0: dec 2010
SSY 7.0: apr 2009
.
SSY 3.0: 1999
NEW
10th Generation software. DataCore currently has the most experience when it comes to SDS/HCI technology, when comparing SANsymphony to other SDS/HCI platforms.
SANsymphony (SSY) version 3 was the first public release that hit the market back in 1999. The product has evolved ever since and the current major release is version 10. The list includes only the milestone releases.
PSP = Product Support Package
U = Update
|
GA Release Dates:
VxRail 7.0.100 (vSAN 7.0 U1: nov 2020
VxRail 7.0 (vSAN 7.0): apr 2020
VxRail 4.7.410 (vSAN 6.7.3): dec 2019
VxRail 4.7.300 (vSAN 6.7.3): sep 2019
VxRail 4.7.212 (vSAN 6.7.2): jul 2019
VxRail 4.7.200 (vSAN 6.7.2): may 2019
VxRail 4.7.100 (vSAN 6.7.1): mar 2019
VxRail 4.7.001 (vSAN 6.7.1): dec 2018
VxRail 4.7.000 (vSAN 6.7.1): nov 2018
VxRail 4.5.225 (vSAN 6.6.1): oct 2018
VxRail 4.5.218 (vSAN 6.6.1): aug 2018
VxRail 4.5.210 (vSAN 6.6.1): may 2018
VxRail 4.5 (vSAN 6.6): sep 2017
VxRail 4.0 (vSAN 6.2): dec 2016
VxRail 3.5 (vSAN 6.2): jun 2016
VxRail 3.0 (vSAN 6.1): feb 2016
NEW
7th Generation VMware software on 14th Generation Dell server hardware.
VxRail is fueled by vSAN software. vSANs maturity has been increasing ever since the first iteration by expanding its range of features with a set of advanced functionality.
|
Release Dates:
SP 19.01: Jun 2019
SP 18.02: Jan 2018
SP 18.01: Dec 2017
SP 16.03: Dec 2016
SP 16.02: Aug 2016
SP 16.01: Mar 2016
SP 15.03: Nov 2015
SP 15.02: Mar 2015
SP 15.01: Jan 2015
SP 14.12: Dec 2014
SP 14.10: Oct 2014
SP 14.08: Aug 2014
SP 14.04: Apr 2014
SP 14.02: Feb 2014
SP 13.10: Oct 2013 (GA)
SP 20121217: Dec 2012 (Early access)
SP 20121119: Nov 2012 (Early access)
|
|
|
|
Pricing |
|
|
|
Hardware Pricing Model
Details
|
N/A
SANsymphony is sold by DataCore as a software-only solution. Server hardware must be acquired separately.
The entry point for all hardware and software compatibility statements is: https://www.datacore.com/products/sansymphony/tech/compatibility/
On this page links can be found to: Storage Devices, Servers, SANs, Operating Systems (Hosts), Networks, Hypervisors, Desktops.
Minimum server hardware requirements can be found at: https://www.datacore.com/products/sansymphony/tech/prerequisites/
|
Per Node
|
N/A
StorPool is sold as a software-only solution. Server hardware must be acquired separately.
Hardware is either procured by the customer, as per Hardware Compatibility List (HCL), or as a complete software+hardware solution from selected StorPool technology partners.
Hardware from any vendor can be used, as the HCL is on a component level (CPU, SSD, etc.) basis.
|
|
|
Software Pricing Model
Details
|
Capacity based (per TB)
NEW
DataCore SANsymphony is licensed in three different editions: Enterprise, Standard, and Business.
All editions are licensed per capacity (in 1 TB steps). Except for the Business edition which has a fixed price per TB, the more capacity that is used by an end-user in each class, the lower the price per TB.
Each edition includes a defined feature set.
Enterprise (EN) includes all available features plus expanded Parallel I/O.
Standard (ST) includes all Enterprise (EN) features, except FC connections, Encryption, Inline Deduplication & Compression and Shared Multi-Port Array (SMPA) support with regular Parallel I/O.
Business (BZ) as entry-offering includes all essential Enterprise (EN) features, except Asynchronous Replication & Site Recovery, Encryption, Deduplication & Compression, Random Write Accelerator (RWA) and Continuous Data Protection (CDP) with limited Parallel I/O.
Customers can choose between a perpetual licensing model or a term-based licensing model. Any initial license purchase for perpetual licensing includes Premier Support for either 1, 3 or 5 years. Alternatively, term-based licensing is available for either 1, 3 or 5 years, always including Premier Support as well, plus enhanced DataCore Insight Services (predictive analytics with actionable insights). In most regions, BZ is available as term license only.
Capacity can be expanded in 1 TB steps. There exists a 10 TB minimum per installation for Business (BZ). Moreover, BZ is limited to 2 instances and a total capacity of 38 TB per installation, but one customer can have multiple BZ installations.
Cost neutral upgrades are available when upgrading from Business/Standard (BZ/ST) to Enterprise (EN).
|
Per Node
NEW
Every VxRail 7.0.100 node comes bundled with:
- Dell EMC VxRail Manager 7.0.100
- VxRail Manager Plugin for VMware vCenter
- VMware vCenter Server Virtual Appliance (vCSA) 7.0 U1
- VMware vSphere 7.0 U1
- VMware vSAN 7.0 U1
- VMware vRealize Log Insight 8.1.1.0
- ESRS 3.46
As of VxRail 3.5 VMware vSphere licenses have to be purchased separately. VxRail nodes come pre-installed with VMware vSphere 6.7 U3 Patch01 and require a valid vSphere license key to be entered. VMware vSphere Data Protection (VDP) 6.1 is included as part of the vSphere license and is downloadable through the VxRail Manager.
VMware vSAN licenses have to be purchased separately as well. As of VxRail 4.7 there is a choice of either vSAN 6.7 U3 Standard, Advanced or Enterprise licenses.
Dell EMC VxRail 7.0.100 supports VMware Cloud Foundation (VCF) 4.1. VMware Cloud Foundation (VCF) is a unified SDDC platform that brings together VMware ESXi, VMware vSAN, VMware NSX, and optionally, vRealize Suite components, VMware NSX-T, VMware Enterprise PKS, and VMware Horizon 7 into one integrated stack.
Dell EMC VxRail 7.0 does not support VMware vLCM; vLCM is disabled in vCenter.
Dell EMC VxRail 7.0 does not support appliances based on the Quanta hardware platform.
Dell EMC VxRail 7.0 does not support RecoverPoint for Virtual Machines (RP4VM).
|
Capacity based (per TB)
Both OPEX (monthly recurring) and CAPEX (perpetual) options are available.
StorPool standard licensing is on a pay-as-you-grow monthly recurring basis and is “all inclusive”. This means it includes the right to use the software, 24/7 support, managed services, new versions & updates, pre-deployment consulting, fine tuning and proactive monitoring.
StorPool also provides perpetual licensing with 1-year and 3-year prepay packages at considerable discounts.
Per TB licensing is based on the amount of data within two separate performance tiers: HDD and SSD. The capacity of these two tiers can be mixed within the same solution.
|
|
|
Support Pricing Model
Details
|
Capacity based (per TB)
Support is always provided on a premium (24x7) basis, including free updates.
More information about DataCores support policy can be found here:
http://datacore.custhelp.com/app/answers/detail/a_id/1270/~/what-is-datacores-support-policy-for-its-products
|
Per Node
Dell EMC offers two types of VxRail Appliance Support:
- Enhanced provides 24x7 support for production environments, including around-the-clock technical support, next business day onsite response, proactive remote monitoring and resolution, and installation of non customer replaceable units.
- Premium provides mission critical support for fastest resolution, including 24x7 technical support and monitoring, priority onsite response for critical issues, installation of operating environment updates, and installation of all replacement parts.
|
Capacity based (per TB)
Support is either bundled with OPEX or separately offered with CAPEX. in both cases the price is capacity based (per TB).
Support always includes 24/7 software support as well as proactive monitoring and managed services.
|
|
|
Design & Deploy
|
|
|
|
|
|
|
Design |
|
|
|
Consolidation Scope
Details
|
Storage
Data Protection
Management
Automation&Orchestration
DataCore is storage-oriented.
SANsymphony Software-Defined Storage Services are focused on variable deployment models. The range covers classical Storage Virtualization over Converged and Hybrid-Converged to Hyperconverged including a seamless migration between them.
DataCore aims to provide all key components within a storage ecosystem including enhanced data protection and automation & orchestration.
|
Hypervisor
Compute
Storage
Network (limited)
Data Protection (limited)
Management
Automation&Orchestration
VMware is stack-oriented, whereas the VxRail platform itself is heavily storage-focused.
With the vSAN/VxRail platforms VMware aims to provide all functionality required in a Private Cloud ecosystem.
|
Compute
Storage
Data Protection (limited)
Automation&Orchestration (limited)
StorPool provides primary, shared block-storage, consolidating all storage into one solution. StorPool is commonly used to build Hyper-Converged Infrastructure (HCI), as about half of the field deployments combine compute+storage within a single-layer architecture.
|
|
|
|
1, 10, 25, 40, 100 GbE (iSCSI)
8, 16, 32, 64 Gbps (FC)
The bandwidth required depends entirely on the specifc workload needs.
SANsymphony 10 PSP11 introduced support for Emulex Gen 7 64 Gbps Fibre Channel HBAs.
SANsymphony 10 PSP8 introduced support for Gen6 16/32 Gbps ATTO Fibre Channel HBAs.
|
1, 10, 25 GbE
VxRail hardware models include redundant ethernet connectivity using SFP+ or Base-T. Dell EMC recommends at least 10GbE to avoid the network becoming a performance bottleneck.
VxRail 4.7 added automatic network configuration support for select Dell top-of-rack (TOR)
switches.
VxRail 4.7.211 added support for Qlogic and Mellanox NICs, as well as SmartFabric support for Dell EMC S5200 25Gb TOR switches.
|
Standard Ethernet 10/25/40/50/100 GbE
Infiniband (EoL)
StorPool Distributed Storage (StorPool) supports ethernet connectivity using 10 GbE or faster network.
|
|
|
Overall Design Complexity
Details
|
Medium
DataCore SANsymphony is able to meet many different use-cases because of its flexible technical architecture, however this also means there are a lot of design choices that need to be made. DataCore SANsymphony seeks to provide important capabilities either natively or tightly integrated, and this keeps the design process relatively simple. However, because many features in SANsymphony are optional and thus can be turned on/off, in effect each one needs to be taken into consideration when preparing a detailed design.
|
Medium
Dell EMC VxRail was developed with simplicity in mind, both from a design and a deployment perspective. VMware vSANs uniform platform architecture, running at the core of VxRail, is meant to be applicable to all virtualization use-cases and seeks to provide important capabilities either natively or by leveraging features already present in the VMware hypervisor, vSphere, on a per-VM basis. As there is no tight integration involved, especially with regard to data protection choices need to made whether to incorporate 1st party of 3rd party solutions into the overall technical design.
|
Medium
StorPool is provided as a fully deployed working solution with 24/7 support and managed service included in the fee. The managed service covers solution design, hardware selection, deployment and help wirth the integration with 3rd party systems.
StorPool customers can choose to use StorPools integrated data protection functionality or to work with specialized backup solution providers.
|
|
|
External Performance Validation
Details
|
SPC (Jun 2016)
ESG Lab (Jan 2016)
SPC (Jun 2016)
Title: 'Dual Node, Fibre Channel SAN'
Workloads: SPC-1
Benchmark Tools: SPC-1 Workload Generator
Hardware: All-Flash Lenovo x3650, 2-node cluster, FC-connected, SSY 10.0, 4x All-Flash Dell MD1220 SAS Storage Arrays
SPC (Jun 2016)
Title: 'Dual Node, High Availability, Hyper-converged'
Workloads: SPC-1
Benchmark Tools: SPC-1 Workload Generator
Hardware: All-Flash Lenovo x3650, 2-node cluster, FC-interconnect, SSY 10.0
ESG Lab (Jan 2016)
Title: 'DataCore Application-adaptive Data Infrastructure Software'
Workloads: OLTP
Benchmark Tools: IOmeter
Hardware: Hybrid (Tiered) Dell PowerEdge R720, 2-node cluster, SSY 10.0
|
StorageReview (dec 2018)
Principled Technologies (jul 2017, jun 2017)
StorageReview (Dec 2018)
Title: 'Dell EMC VxRail P570F Review'
Workloads: MySQL OLTP, MSSQL OLTP, Generic profiles
Benchmark Tools: Sysbench (MySQL), TPC-C (MSSQL), Vdbench (generic)
Hardware: All-Flash Dell EMC VxRail P570F, vSAN 6.7
Principled Technologies (Jul 2017)
Title: 'Handle more orders with faster response times, today and tomorrow'
Workloads: MSSQL OLTP
Benchmark Tools: DS2 (MSSQL)
Hardware: All-Flash Dell EMC VxRail P470F, 4-node cluster, VxRail 4.0 (vSAN 6.2)
Principled Technologies (Jun 2017)
Title: 'Empower your databases with strong, efficient, scalable performance'
Workloads: MSSQL OLTP
Benchmark Tools: DS2 (MSSQL)
Hardware: All-Flash Dell EMC VxRail P470F, 4-node cluster, VxRail 4.0 (vSAN 6.2)
|
N/A (one internally-validated)
No externally validated test reports have been published in past years (2016-2020).
However, in May 2019 StorPool did publish an internally validated performance benchmark test:
Intel Data Center Builders (Jun 2019)
Title: 'The IOPS challenge is over. StorPool holds the new world record – 13.8 mln IOPS'
Workloads:
Benchmark Tool: FIO
Hardware: All-Flash x86-based servers, 12-node cluster, 25Gb Ethernet connected, SP v19, 4x Intel SSD DC P4510 8TB NVMe per node
For more information please go to:
https://storpool.com/blog/the-iops-challenge-is-over-storpool-holds-the-new-world-record-13-8-mln-iops
or
https://builders.intel.com/blog/the-iops-challenge-is-over-new-world-record-is-hit-13-8-million-iops/
|
|
|
Evaluation Methods
Details
|
Free Trial (30-days)
Proof-of-Concept (PoC; up to 12 months)
SANsymphony is freely downloadble after registering online and offers full platform support (complete Enterprise feature set) but is scale (4 nodes), capacity (16TB) and time (30 days) restricted, what all can be expanded upon request. The free trial version of SANsymphony can be installed on all commodity hardware platforms that meet the hardware requirements.
For more information please go here: https://www.datacore.com/try-it-now/
|
Proof-of-Concept (POC)
vSAN: Free Trial (60-days)
vSAN: Online Lab
VxRail 7.0 runs VMware vSAN 7.0 software at its core. vSAN Evaluation is freely downloadble after registering online. Because it is embedded in the hypervisor, the free trial includes vSphere and vCenter Server. vSAN Evaluation can be installed on all commodity hardware platforms that meet the hardware requirements. vSAN Evaluation use is time-restricted (60-days). vSAN Evaluation is not for production environments.
VMware also offers a vSAN hosted hands-on lab that lets you deploy, configure and manage vSAN in a contained environment, after registering online.
|
Evaluation license (30-days)
StorPool offers evaluation licenses for 30-days. These licenses can be used in non-production environments.
A StorPool evaluation license provides full functionalty and unlimited capacity. It is provided with a 'best effort' level of support.
|
|
|
|
Deploy |
|
|
|
Deployment Architecture
Details
|
Single-Layer
Dual-Layer
Single-Layer = servers function as compute nodes as well as storage nodes.
Dual-Layer = servers function only as storage nodes; compute runs on different nodes.
Single-Layer:
- SANsymphony is implemented as virtual machine (VM) or in case of Hyper-V as service layer on Hyper-V parent OS, managing internal and/or external storage devices and providing virtual disks back to the hypervisor cluster it is implemented in. DataCore calls this a hyper-converged deployment.
Dual-Layer:
- SANsymphony is implemented as bare metal nodes, managing external storage (SAN/NAS approach) and providing virtual disks to external hosts which can be either bare metal OS systems and/or hypervisors. DataCore calls this a traditional deployment.
- SANsymphony is implemented as bare metal nodes, managing internal storage devices (server-SAN approach) and providing virtual disks to external hosts which can be either bare metal OS systems and/or hypervisors. DataCore calls this a converged deployment.
Mixed:
- SANsymphony is implemented in any combination of the above 3 deployments within a single management entity (Server Group) acting as a unified storage grid. DataCore calls this a hybrid-converged deployment.
|
Single-Layer
Single-Layer: VMware vSAN is meant to be used as a storage platform as well as a compute platform at the same time. This effectively means that applications, hypervisor and storage software are all running on top of the same server hardware (=single infrastructure layer).
VMware vSAN can partially serve in a dual-layer model by providing storage also to other vSphere hosts within the same cluster that do not contribute storage to vSAN themselves or to bare metal hosts. However, this is not a primary use case and also requires the other vSphere hosts to have vSAN enabled (Please view the compute-only scale-out option for more information).
|
Single-Layer
Dual-Layer
Single-Layer = servers function as compute nodes as well as storage nodes.
Dual-Layer = servers function only as storage nodes; compute runs on different nodes.
Single-Layer:
- StorPool Distributed Storage (StorPool) is a service running on a Linux OS, next to the KVM hypervisor, containers or applications. This is a hyper-converged deployment (compute+storage offered by a single layer).
Dual-Layer:
- StorPool is running on dedicated Linux servers and provides virtual disks to external compute hosts – bare metal and / or hypervisors.
Mixed:
- Some of the servers are hyper-converged (compute+storage offered by a single layer), while other servers are dedicated storage nodes or dedicated compute nodes.
|
|
|
Deployment Method
Details
|
BYOS (some automation)
BYOS = Bring-Your-Own-Server-Hardware
DataCore SANsymphony is made easy by providing a very straightforward implementation approach.
|
Turnkey (very fast; highly automated)
Because of the ready-to-go Hyper Converged Infrastructure (HCI) building blocks and the setup wizard provided by Dell EMC, customer deployments can be executed in hours instead of days.
|
Turnkey (remote install)
StorPool delivers a working software defined storage (SDS) solution. This includes testing of the customers hardware, installing and configuring the software, tuning and assisting in integrations with other applications. The goal is to provide a hassle-free solution that is guaranteed to be effective and efficient while delivering high performance.
|
|
|
Workload Support
|
|
|
|
|
|
|
Virtualization |
|
|
|
Hypervisor Deployment
Details
|
Virtual Storage Controller
Kernel (Optional for Hyper-V)
The SANsymphony Controller is deployed as a pre-configured Virtual Machine on top of each server that acts as a part of the SANsymphony storage solution and commits its internal storage and/or externally connected storage to the shared resource pool. The Virtual Storage Controller (VSC) can be configured direct access to the physical disks, so the hypervisor is not impeding the I/O flow.
In Microsoft Hyper-V environments the SANsymphony software can also be installed in the Windows Server Root Partition. DataCore does not recommend installing SANsymphony in a Hyper-V guest VM as it introduces virtualization layer overhead and obstructs DataCore Software from directly accessing CPU, RAM and storage. This means that installing SANsymphony in the Windows Server Root Partition is the preferred deployment option. More information about the Windows Server Root Partition can be found here: https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/hyper-v-server/architecture
The DataCore software can be installed on Microsoft Windows Server 2019 or lower (all versions down to Microsoft Windows Server 2012/R2).
Kernel Integrated, Virtual Controller and VIB are each distributed architectures, having one active component per virtualization host that work together as a group. All three architectures are capable of delivering a complete set of storage services and good performance. Kernel Integrated solutions reside within the protected lower layer, VIBs reside just above the protected kernel layer, and Virtual Controller solutions reside in the upper user layer. This makes Virtual Controller solutions somewhat more prone to external actions (eg. most VSCs do not like snapshots). On the other hand Kernel Integrated solutions are less flexible because a new version requires the upgrade of the entire hypervisor platform. VIBs have the middle-ground, as they provide more flexibility than kernel integrated solutions and remain relatively shielded from the user level.
|
Kernel Integrated
Virtual SAN is embedded into the VMware hypervisor. This means it does not require any Controller VMs to be deployed on top of the hypervisor platform.
Kernel Integrated, Virtual Controller and VIB are each distributed architectures, having one active component per virtualization host that work together as a group. All three architectures are capable of delivering a complete set of storage services and good performance. Kernel Integrated solutions reside within the protected lower layer, VIBs reside just above the protected kernel layer, and Virtual Controller solutions reside in the upper user layer. This makes Virtual Controller solutions somewhat more prone to external actions (eg. most VSCs do not like snapshots). On the other hand Kernel Integrated solutions are less flexible because a new version requires the upgrade of the entire hypervisor platform. VIBs have the middle-ground, as they provide more flexibility than kernel integrated solutions and remain relatively shielded from the user level.
|
Next to Hypervisor (KVM)
None (ESXi, Hyper-V, XenServer, OracleVM)
StorPool storage nodes can be deployed on bare metal only. The storage is presented to the compute nodes through a native StorPool block device driver for Linux-based clients or via iSCSI interface for non-Linux workloads.
StorPool Distributed Storage (StorPool) is accessed through the native StorPool client (initiator, block device driver) for Linux-based hypervisors (KVM).
VMware ESXi, Hyper-V, Xen, XenServer, OracleVM and other OS/hypervisors access storage presented by StorPool through iSCSI.
StorPool also features deep integrations with a number of Cloud Management Systems (OpenStack, CloudStack, OpenNebula, OnApp, etc). Kubernetes is connected to StorPool through K8S CSI driver.
|
|
|
Hypervisor Compatibility
Details
|
VMware vSphere ESXi 5.5-7.0U1
Microsoft Hyper-V 2012R2/2016/2019
Linux KVM
Citrix Hypervisor 7.1.2/7.6/8.0 (XenServer)
'Not qualified' means there is no generic support qualification due to limited market footprint of the product. However, a customer can always individually qualify the system with a specific SANsymphony version and will get full support after passing the self-qualification process.
Only products explicitly labeled 'Not Supported' have failed qualification or have shown incompatibility.
|
VMware vSphere ESXi 7.0 U1
NEW
VMware Virtual SAN is an integral part of the VMware vSphere platform; As such it cannot be used with any other hypervisor platform.
Dell EMC VxRail and vSAN support a single hypervisor in contrast to other SDS/HCI products that support multiple hypervisors.
|
KVM
VMware ESXi
Hyper-V
XenServer
OracleVM
|
|
|
Hypervisor Interconnect
Details
|
iSCSI
FC
The SANsymphony software-only solution supports both iSCSI and FC protocols to present storage to hypervisor environments.
DataCore SANsymphony supports:
- iSCSI (Switched and point-to-point)
- Fibre Channel (Switched and point-to-point)
- Fibre Channel over Ethernet (FCoE)
- Switched, where host uses Converged Network Adapter (CNA), and switch outputs Fibre Channel
|
vSAN (incl. WSFC)
VMware uses a propietary protocol for vSAN.
vSAN 6.1 and upwards support the use of Microsoft Failover Clustering (MSFC). This includes MS Exchange DAG and SQL Always-On clusters when a file share witness quorum is used. The use of a failover clustering instance (FCI) is not supported.
vSAN 6.7 and upwards support Windows Server Failover Clustering (WSFC) by building WSFC targets on top of vSAN iSCSI targets. vSAN iSCSI target service supports SCSI-3 Persistent Reservations for shared disks and transparent failover for WSFC. WSFC can run on either physical servers or VMs.
vSAN 6.7 U3 introduced native support for SCSI-3 Persistent Reservations (PR), which enables Windows Server Failover Clusters (WSFC) to be directly deployed on native vSAN VMDKs. This capability enables migrations from legacy deployments on physical RDMs or external storage protocols to VMware vSAN.
|
Block device driver (KVM)
iSCSI (ESXi, Hyper-V, XenServer, OracleVM)
StorPool storage nodes can be deployed on bare metal only. The storage is presented to the compute nodes through a StorPool native block device driver for Linux-based clients or via iSCSI interface for non-Linux workloads.
StorPool Distributed Storage (StorPool) is accessed through the native StorPool client (initiator, block device driver) for Linux-based hypervisors (KVM).
VMware ESXi, Hyper-V, Xen, XenServer, OracleVM and other OS/hypervisors access storage presented by StorPool through iSCSI.
|
|
|
|
Bare Metal |
|
|
|
Bare Metal Compatibility
Details
|
Microsoft Windows Server 2012R2/2016/2019
Red Hat Enterprise Linux (RHEL) 6.5/6.6/7.3
SUSE Linux Enterprise Server 11.0SP3+4/12.0SP1
Ubuntu Linux 16.04 LTS
CentOS 6.5/6.6/7.3
Oracle Solaris 10.0/11.1/11.2/11.3
Any operating system currently not qualified for support can always be individually qualified with a specific SANsymphony version and will get full support after passing the self-qualification process.
SANsymphony provides virtual disks (block storage LUNs) to all of the popular host operating systems that use standard disk drives with 512 byte or 4K byte sectors. These hosts can access the SANsymphony virtual disks via SAN protocols including iSCSI, Fibre Channel (FC) and Fibre Channel over Ethernet (FCoE).
Mainframe operating systems such as IBM z/OS, z/TPF, z/VSE or z/VM are not supported.
SANsymphony itself runs on Microsoft Windows Server 2012/R2 or higher.
|
N/A
Dell EMC VxRail does not support any non-hypervisor platforms.
|
Microsoft Windows Server 2012R2-2019
CentOS 7, 8
Debian Linux 9
Ubuntu Linux 16.04 LTS, 18.04 LTS
Other Linux distributions (eg. RHEL, OEL, SuSE)
StorPool supports all 64-bit Linux distributions. The following platform versions have been tested thoroughly and are thus supported by default:
- CentOS 7, 8
- Debian Linux 9
- Ubuntu Linux 16.04 LTS, 18.04 LTS
Other Linux distributions (eg. RHEL, OEL, SuSE) can be supported.
The Windows Server OS is supported through iSCSI.
StorPool HCI nodes as well as StorPool storage-only nodes run one of the supported Linux distributions.
|
|
|
Bare Metal Interconnect
Details
|
iSCSI
FC
FCoE
|
N/A
Dell EMC VxRail does not support any non-hypervisor platforms.
|
Block device driver (Linux)
iSCSI (Windows Server)
The StorPool Block Device Driver for Linux (storpool_block) component is installed on application servers that are going to consume storage.
Additionally, storage can be exposes through iSCSI for consumption by Linux and non-Linux operating systems.
|
|
|
|
Containers |
|
|
|
Container Integration Type
Details
|
Built-in (native)
DataCore provides its own Volume Plugin for natively providing Docker container support, available on Docker Hub.
DataCore also has a native CSI integration with Kubernetes, available on Github.
|
Built-in (Hypervisor-based, vSAN supported)
VMware vSphere Docker Volume Service (vDVS) technology enables running stateful containers backed by storage technology of choice in a vSphere environment.
vDVS comprises of Docker plugin and vSphere Installation Bundle which bridges the Docker and vSphere ecosystems.
vDVS abstracts underlying enterprise class storage and makes it available as docker volumes to a cluster of hosts running in a vSphere environment. vDVS can be used with enterprise class storage technologies such as vSAN, VMFS, NFS and VVol.
vSAN 6.7 U3 introduces support for VMware Cloud Native Storage (CNS). When Cloud Native Storage is used, persistent storage for containerized stateful applications can be created that are capable of surviving restarts and outages. Stateful containers orchestrated by Kubernetes can leverage storage exposed by vSphere (vSAN, VMFS, NFS) while using standard Kubernetes volume, persistent volume, and dynamic provisioning primitives.
|
Hypervisor: None
Bare metal (Linux): Block device driver
For containers in virtual machines StorPool relies on the container support delivered by the hypervisor platform.
With regard to bare metal container environments StorPool provides linux block devices that can be used as persistent storage for containers.
|
|
|
Container Platform Compatibility
Details
|
Docker CE/EE 18.03+
Docker EE = Docker Enterprise Edition
|
Docker CE 17.06.1+ for Linux on ESXi 6.0+
Docker EE/Docker for Windows 17.06+ on ESXi 6.0+
Docker CE = Docker Community Edition
Docker EE = Docker Enterprise Edition
|
Most container platforms
StorPool can be used by any container platform that can leverage standard block devices as persistent storage.
|
|
|
Container Platform Interconnect
Details
|
Docker Volume plugin (certified)
The DataCore SDS Docker Volume plugin (DVP) enables Docker Containers to use storage persistently, in other words enables SANsymphony data volumes to persist beyond the lifetime of both a container or a container host. DataCore leverages SANsymphony iSCSI and FC to provide storage to containers. This effectively means that the hypervisor layer is bypassed.
The Docker SDS Volume plugin (DVP) is officially 'Docker Certified' and can be downloaded from the Docker Hub. The plugin is installed inside the Docker host, which can be either a VM or a Bare Metal Host connect to a SANsymphony storage cluster.
For more information please go to: https://hub.docker.com/plugins/datacore-sds-volume-plugin
The Kubernetes CSI plugin can be downloaded from GitHub. The plugin is automatically deployed as several pods within the Kubernetes system.
For more information please go to: https://github.com/DataCoreSoftware/csi-plugin
Both plugins are supported with SANsymphony 10 PSP7 U2 and later.
|
Docker Volume Plugin (certified) + VMware VIB
vSphere Docker Volume Service (vDVS) can be used with VMware vSAN, as well as VMFS datastores and NFS datastores served by VMware vSphere-compatible storage systems.
The vSphere Docker Volume Service (vDVS) installation has two parts:
1. Installation of the vSphere Installation Bundle (VIB) on ESXi.
2. Installation of Docker plugin on the virtualized hosts (VMs) where you plan to run containers with storage needs.
The vSphere Docker Volume Service (vDVS) is officially 'Docker Certified' and can be downloaded from the online Docker Store.
|
Standard block devices
StorPool provides standard block devices that can be used by Docker containers as any other block device or SAN.
|
|
|
Container Host Compatibility
Details
|
Virtualized container hosts on all supported hypervisors
Bare Metal container hosts
The DataCore native plug-ins are container-host centric and as such can be used across all SANsymphony-supported hypervisor platforms (VMware vSphere, Microsoft Hyper-V, KVM, XenServer, Oracle VM Server) as well as on bare metal platforms.
|
Virtualized container hosts on VMware vSphere hypervisor
Because the vSphere Docker Volume Service (vDVS) and vSphere Cloud Provider (VCP) are tied to the VMware Sphere platform, they cannot be used for bare metal hosts running containers.
|
Bare-metal container hosts
The Kubernetes worker node participates as a client (initiator) in the StorPool cluster. Both dual-layer architectures and single-layer architectures are supported, meaning that StorPool can be leveraged as a storage-only or as a hyperconverged (compute+storage) node when serving storage to containers.
|
|
|
Container Host OS Compatbility
Details
|
Linux
All Linux versions supported by Docker CE/EE 18.03+ or higher can be used.
|
Linux
Windows 10 or 2016
Any Linux distribution running version 3.10+ of the Linux kernel can run Docker.
vSphere Storage for Docker can be installed on Windows Server 2016/Windows 10 VMs using the PowerShell installer.
|
Linux
All Linux versions supported by Kubernetes.
|
|
|
Container Orch. Compatibility
Details
|
Kubernetes 1.13+
|
VCP: Kubernetes 1.6.5+ on ESXi 6.0+
CNS: Kubernetes 1.14+
vSAN 6.7 U3 introduced support for VMware Cloud Native Storage (CNS).
When Cloud Native Storage (CNS) is used, persistent storage for containerized stateful applications can be created that are capable of surviving restarts and outages. Stateful containers orchestrated by Kubernetes can leverage storage exposed by vSphere (vSAN, VMFS, NFS, vVols) while using standard Kubernetes volume, persistent volume, and dynamic provisioning primitives.
VCP = vSphere Cloud Provider
CSI = Container Storage Interface
|
Kubernetes v1.13+
StorPool support for Kubernetes has been there since the container orchestration platform officially introduced their implementation of the Container Storage Interface (CSI) back in January 2019.
|
|
|
Container Orch. Interconnect
Details
|
Kubernetes CSI plugin
The Kubernetes CSI plugin provides several plugins for integrating storage into Kubernetes for containers to consume.
DataCore SANsymphony provides native industry standard block protocol storage presented over either iSCSI or Fibre Channel. YAML files can be used to configure Kubernetes for use with DataCore SANsymphony.
|
Kubernetes Volume Plugin
The VMware vSphere Container Storage Interface (CSI) Volume Driver for Kubernetes leverages vSAN block storage and vSAN file shares to provide scalable, persistent storage for stateful applications.
Kubernetes contains an in-tree CSI Volume Plug-In that allows the out-of-tree VMware vSphere CSI Volume Driver to gain access to containers and provide persistent-volume storage. The plugin runs in a pod and dynamically provisions requested PersistentVolumes (PVs) using vSAN block storage and vSAN native files shares dynamically provisioned by VMware vSAN File Services.
The VMware vSphere CSI Volume Driver requires Kubernetes v1.14 or later and VMware vSAN 6.7 U3 or later. vSAN File Services requires VMware vSAN/vSphere 7.0.
vSphere Cloud Provider (VCP) for Kubernetes allows Pods to use enterprise grade persistent storage. VCP supports every storage primitive exposed by Kubernetes:
- Volumes
- Persistent Volumes (PV)
- Persistent Volumes Claims (PVC)
- Storage Class
- Stateful Sets
Persistent volumes requested by stateful containerized applications can be provisioned on vSAN, vVol, VMFS or NFS datastores.
|
Kubernetes CSI plugin
The Kubernetes CSI plugin provides several plugins for integrating storage into Kubernetes for containers to consume.
StorPool support for Kubernetes has been there since the container orchestration platform officially introduced their implementation of the Container Storage Interface (CSI) back in January 2019.
|
|
|
|
VDI |
|
|
|
VDI Compatibility
Details
|
VMware Horizon
Citrix XenDesktop
There is no validation check being performed by SANsymphony for VMware Horizon or Citrix XenDesktop VDI platforms. This means that all versions supported by these vendors are supported by DataCore.
|
VMware Horizon
Citrix XenDesktop
Dell EMC has published Reference Architecture whitepapers for both VMware Horizon and Citrix XenDesktop platforms.
Dell EMC VxRail 4.7.211 supports VMware Horizon 7.7
|
VMware Horizon
Citrix XenDesktop
So far StorPool has not published any Reference Architecture whitepapers on VMware Horizon or Citrix XenDesktop.
|
|
|
|
VMware: 110 virtual desktops/node
Citrix: 110 virtual desktops/node
DataCore has not published any recent VDI reference architecture whitepapers. The only VDI related paper that includes a Login VSI benchmark dates back to december 2010. There a 2-node SANsymphony cluster was able to sustain a load of 220 VMs based on the Login VSI 2.0.1 benchmark.
|
VMware: up to 160 virtual desktops/node
Citrix: up to 140 virtual desktops/node
VMware Horizon 7.7: Load bearing number is based on Login VSI tests performed on hybrid VxRail V570F appliances using 2 vCPU Windows 10 desktops and the Knowledge Worker profile.
Citrix XenDesktop 7.15: Load bearing number is based on Login VSI tests performed on hybrid VxRail V570F-B appliances using 2 vCPU Windows 10 desktops and the Knowledge Worker profile.
For detailed information please view the corresponding reference architecture whitepapers.
|
N/A
StorPool has not published any VDI reference architecture whitepapers with LoginVSI benchmark numbers.
|
|
|
Server Support
|
|
|
|
|
|
|
Server/Node |
|
|
|
Hardware Vendor Choice
Details
|
Many
SANsymphony runs on all server hardware that supports x86 - 64bit.
DataCore provides minimum requirements for hardware resources.
|
Dell
Dell EMC uses a single brand of server hardware for its VxRail solution. Since completion of the Dell/EMC merger, Dell EMC has shifted from Quanta to Dell PowerEdge server hardware. This coincides with the VxRail 4.0 release (dec 2016).
In november 2017 Dell refreshed its VxRail hardware base with 14th Generation Dell PowerEdge server hardware.
|
Many
StorPool maintains a component-level HCL, including the most common current and previous generation server components (SSDs, NICs, CPUs). Servers from all major server OEMs comply with StorPools System Requirements (HCL).
|
|
|
|
Many
SANsymphony runs on all server hardware that supports x86 - 64bit.
DataCore provides minimum requirements for hardware resources.
|
5 Dell (native) Models (E-, G-, P-, S- and V-Series)
Different models are available for different workloads and use cases:
E Series (1U-1Node) - Entry Level
G Series (2U-4Node) - High Density
V Series (2U-1Node) - VDI Optimized
P Series (2U-1Node) - Performance Optimized
S Series (2U-1Node) - Storage Dense
E-, G-, V- and P-Series can be acquired as Hybrid or All-Flash appliance. S-Series can only be acquired as Hybrid appliance.
|
Many
StorPool maintains a component-level HCL, including the most common current and previous generation server components (SSDs, NICs, CPUs). Servers from all major server OEMs comply with StorPools System Requirements (HCL).
|
|
|
|
1, 2 or 4 nodes per chassis
Note: Because SANsymphony is mostly hardware agnostic, customers can opt for multiple server densities.
Note: In most cases 1U or 2U building blocks are used.
Also Super Micro offers 2U chassis that can house 4 compute nodes.
Denser nodes provide a smaller datacenter footprint where space is a concern. However, keep in mind that the footprint for other datacenter resources such as power and heat and cooling is not necessarily reduced in the same way and that the concentration of nodes can potentially pose other challenges.
|
1 or 4 nodes per chassis
The VxRail Appliance architecture uses a combination of 1U-1Node, 2U-1Node and 2U-4Node building blocks.
|
1, 2 or 4 nodes per chassis
Because StorPool Distributed Storage (StorPool) is hardware agnostic, customers can opt for multiple server densities. Common configurations include 1 node per chassis and 4 nodes per chassis.
|
|
|
|
Yes
DataCore does not explicitly recommend using different hardware platforms, but as long as the hardware specs are somehow comparable, there is no reason to insist on one or the other hardware vendor. This is proven in practice, meaning that some customers run their productive DataCore environment on comparable servers of different vendors.
|
Yes
Dell EMC allows mixing of different VxRail Appliance models within a cluster, except where doing so would create highly unbalanced performance. The first 4 cluster nodes do not have to be identical anymore (previous requirement). All G Series nodes within the same chassis must be identical. No mixing is allowed between hybrid and all-flash nodes within the same storage cluster. All nodes within the same cluster must run the same version of VxRail software.
|
Yes
StorPool Distributed Storage (StorPool) follows these hardware/software mixing rules:
1. Different server brands, models, generations with different hardware (eg. HDDs or SSDs) are supported within the same StorPool cluster.
2. Different hypervisors are supported within the same StorPool cluster.
3. Different deployment methods (eg. compute-only, storage-only and hyperconverged nodes) are supported within the same StorPool cluster.
|
|
|
|
Components |
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
Flexible
VxRail offers multiple CPU options in each hardware model.
E-Series can have single or dual socket, and up to 28 cores/CPU.
G-Series can have single or dual socket, and up to 28 cores/CPU.
P-Series can have dual or quad socket, and up to 28 cores/CPU.
S-Series can have single or dual socket, and up to 28 cores/CPU.
V-Series can have dual socket, and up to 28 cores/CPU.
VxRail on Dell PowerEdge 14G servers are equiped with Intel Xeon Scalable processors (Skylake and Cascade Lake).
Dell EMC VxRail 4.7.211 introduced official support for the 2nd generation Intel Xeon Scalable (Cascade Lake) processors.
|
Flexible
StorPool provides minimal hardware requirements in its StorPool Distributed Storage (StorPool) documentation.
|
|
|
|
Flexible
|
Flexible
The amount of memory is configurable for all hardware models. Depending on the hardware model Dell EMC offers multiple choices on memory per Node, maxing at 3TB for E-, P-, S-, V-series and 2TB for G-Series. VxRail Appliances use 16GB RDIMMS, 32GB RDIMMS, 64GB LRDIMMS or 128GB LRDIMMS.
|
Flexible
StorPool provides minimal hardware requirements in its StorPool Distributed Storage (StorPool) documentation.
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
Flexible: number of disks (limited) + capacity
A 14th generation VxRail appliance has 24 disk slots.
E-Series supports 10x 2.5' SAS drives per node (up to 2 disk groups: 1x flash + 4x capacity drives each).
G-Series supports 6x 2.5' SAS drives per node (up to 1 disk group: 1x flash + 5x capacity drives each).
P-Series supports 24x 2.5' SAS drives per node (up to 4 disk groups: 1x flash + 5x capacity drives each).
V-Series supports 24x 2.5' SAS drives per node (up to 4 disk groups: 1x flash + 5x capacity drives each).
S-Series supports 12x 2.5' + 2x 3,5' SAS drives per node (up to 2 disk groups: 1x flash + 6 capacity drives each).
|
Flexible
StorPool Distributed Storage (StorPool) supports magnetic disks (HDD), solid-state drives (SSD) as well as NVMe. Different types, models and size of storage devices can be mixed in a storage node.
Each StorPool node can have up to a maximum of 500TB of storage attached. The storage capacity can be entirely based on magnetic disks, solid-state drives, or a mix of both storage media types. Typically an StorPool NVMe storage node has 10x 8 TB NVMe, resulting in 80 TB raw per node.
StorPool provides minimal hardware requirements in its StorPool Distributed Storage (StorPool) documentation.
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
Flexible (1, 10 or 25 Gbps)
E-Series supports 2x 25 GbE (SFP28), 4x 10GbE (RJ45/SFP+) or 4x 1GbE (RJ45) per node.
G-Series supports 2x 25 GbE (SFP28) or 2x 10GbE (RJ45/SFP+) per node.
P-Series supports 2x 25 GbE (SFP28), 4x 10GbE (RJ45/SFP+) or 4x 1GbE (RJ45) per node.
S-Series supports 2x 25 GbE (SFP28), 4x 10GbE (RJ45/SFP+) or 4x 1GbE (RJ45) per node.
V-Series supports 2x 25 GbE (SFP28), 4x 10GbE (RJ45/SFP+) per node.
1GbE configurations are only supported with 1-CPU configurations.
Dell EMC VxRail 4.7.300 provides more network design flexibility in creating VxRail clusters across multiple racks. It also provides the ability to expand a cluster beyond one rack using L3 networks and L2 networks.
|
Flexible
StorPool Distributed Storage (StorPool) fully supports 10/25/40/100Gbps Ethernet networks. For production workloads a dual-redundant network is required (2 switches and 2 ports per node). Management and data storage traffic can be performed across the same IP network or across separate IP networks.
StorPool provides minimal hardware requirements in its StorPool Distributed Storage (StorPool) documentation.
|
|
|
|
NVIDIA Tesla
AMD FirePro
Intel Iris Pro
DataCore SANsymphony supports the hardware that is on the hypervisor HCL.
VMware vSphere 6.5U1 officially supports several GPUs for VMware Horizon 7 environments:
NVIDIA Tesla M6 / M10 / M60
NVIDIA Tesla P4 / P6 / P40 / P100
AMD FirePro S7100X / S7150 / S7150X2
Intel Iris Pro Graphics P580
More information on GPU support can be found in the online VMware Compatibility Guide.
Windows 2016 supports two graphics virtualization technologies available with Hyper-V to leverage GPU hardware:
- Discrete Device Assignment
- RemoteFX vGPU
More information is provided here: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-graphics-virtualization
The NVIDIA website contains a listing of GRID certified servers and the maximum number of GPUs supported inside a single server.
Server hardware vendor websites also contain more detailed information on the GPU brands and models supported.
|
NVIDIA Tesla
Dell EMC offers multiple GPU options in the VxRail V-series Appliances.
Currently the following GPUs are provided as add-on in PowerEdge Gen14 server hardware (V-model only):
NVIDIA Tesla M10 (up to 2x in each node)
NVIDIA Tesla M60 (up to 3x in each node)
NVDIA Tesla P40 (up to 3x in each node)
|
NVIDIA Tesla
AMD FirePro
Intel Iris Pro
StorPool does not restrict the use of GPUs; end-user organizations are free to leverage any GPUs that are available on the market.
|
|
|
|
Scaling |
|
|
|
|
CPU
Memory
Storage
GPU
The SANsymphony platform allows for expanding of all server hardware resources.
|
Memory
Storage
Network
GPU
At the moment CPUs are not upgradeable in VxRail.
|
CPU
Memory
Storage
GPU
The StorPool Distributed Storage platform allows for expanding of all server hardware resources.
|
|
|
|
Storage+Compute
Compute-only
Storage-only
Storage+Compute: In a single-layer deployment existing SANsymphony clusters can be expanded by adding additional nodes running SANsymphony, which adds additional compute and storage resources to the shared pool. In a dual-layer deployment both the storage-only SANsymphony clusters and the compute clusters can be expanded simultaneously.
Compute-only: Because SANsymphony leverages virtual block volumes (LUNs), storage can be presented to hypervisor hosts not participating in the SANsymphony cluster. This is also beneficial to migrations, since it allows for online storage vMotions between SANsymphony and non-SANsymphony storage platforms.
Storage-only: In a dual-layer or mixed deployment both the storage-only SANsymphony clusters and the compute clusters can be expanded independent from each other.
|
Compute+storage
Storage+Compute: Existing VxRail clusters can be expanded by adding additional VxRail nodes, which adds additional compute and storage resources to the shared pool.
Compute-only: VMware does not allow non-VxRail hosts to become part of a VxRail cluster. This means that installing and enabling the vSAN VMkernel on hosts in a VxRail cluster that is not contributing storage, so vSAN datastores can be presented to these hypervisor hosts as well, is not an option at this time.
Storage-only: N/A; A VxRail node always takes active part in the hypervisor (compute) cluster as well as the storage cluster.
|
Storage+Compute
Compute-only
Storage-only
StorPool implements a fully distributed shared nothing architecture, where all nodes are equal. By adding nodes, the cluster scales linearly in both capacity and performance.
Storage+Compute: In a single-layer deployment existing StorPool clusters can be expanded by adding additional nodes running StorPool, which adds additional compute and storage resources to the shared pool. In a dual-layer deployment both the storage-only StorPool clusters and the compute clusters can be expanded simultaneously.
Compute-only: Because StorPool leverages virtual block volumes (LUNs), storage can be presented to hypervisor hosts not participating in the StorPool cluster. This is also StorPool and non-StorPool storage platforms.
Storage-only: In a dual-layer or mixed deployment both the storage-only StorPool clusters and the compute clusters can be expanded independent from each other.
|
|
|
|
1-64 nodes in 1-node increments
There is a maximum of 64 nodes within a single cluster. Multiple clusters can be managed through a single SANsymphony management instance.
|
3-64 storage nodes in 1-node increments
At minimum a VxRail deployment consists of 3 nodes. From there the solution can be scaled one or more nodes at a time. The first 4 cluster nodes must be identical.
Scaling beyond 32 nodes no longer requires a Request for Product Qualification (RPQ). However, an RPQ is required for Stretched Cluster implementations
If using 1GbE only, a storage cluster cannot expand beyond 8 nodes.
For the maximum node configuration hypervisor cluster scale-out limits still apply: 64 hosts for VMware vSphere.
VxRail 4.7 introduces support for adding multiple nodes in parallel, speeding up cluster expansions.
|
3-63 nodes in 1-node increments
There is a maximum of 63 StorPool nodes within a single cluster, meaning there could be several Petabytes of data in a single cluster. Up to 64 clusters can be connected to a federation for larger capacity use-cases. Clusters can be scaled in 1-node increments.
|
|
|
Small-scale (ROBO)
Details
|
2 Node minimum
DataCore prevents split-brain scenarios by always having an active-active configuration of SANsymphony with a primary and an alternate path.
In the case SANsymphony servers are fully operating but do not see each other, the application host will still be able to read and write data via the primary path (no switch to secondary). The mirroring is interrupted because of the lost connection and the administrator is informed accordingly. All writes are stored on the locally available storage (primary path) and all changes are tracked. As soon as the connection between the SANsymphony servers is restored, the mirror will recover automatically based on these tracked changes.
Dual updates due to misconfiguration are detected automatically and data corruption is prevented by freezing the vDisk and waiting for user input to solve the conflict. Conflict solutions could be to declare one side of the mirror to be the new active data set and discarding all tracked changes at the other side, or splitting the mirror and merge the two data sets into a 3rd vDisk manually.
|
2 Node minimum
VxRail 4.7.100 introduced support for 2-node clusters:
- The deployment is limited to VxRail Series E-Series nodes.
- Only 1GbE and 10GbE are supported. Inter-cluster VxRail traffic utilizes a pair of network cables linke between the physical nodes.
- A customer-supplied external vCenter is required that does not reside on the 2-node cluster.
- A Witness VM that monitors the health of the 2-node cluster is required and does not reside on the 2-node cluster.
2-node clusters are not supported when using the VxRail G410 appliance.
|
3 Node minimum
StorPools smallest deployment contains 3 nodes, albeit these could be small cost-efficient servers.
|
|
|
Storage Support
|
|
|
|
|
|
|
General |
|
|
|
|
Block Storage Pool
SANsymphony only serves block devices to the supported OS platforms.
|
Object Storage File System (OSFS)
|
Block Storage Pool
StorPool only serves block devices to the supported OS platforms.
StorPool aggrates direct-attached storage from multiple x86 servers into one or more pools. There can be multiple pools in each StorPool cluster, eg. an SSD pool and a HDD-only pool.
Volumes are striped widely across many drives in the pool. Copies (replicas) are guaranteed to be on different servers or different chassis; this ensures high availablity of data access. Thus StorPool aggregates the capacity and performance of all drives in each pool.
StorPool uses a shared-nothing architecture where all servers participate on an equal basis - there are no meta data servers or active-standby roles, just servers on a flat network.
|
|
|
|
Partial
DataCores core approach is to provide storage resources to the applications without having to worry about data locality. But if data locality is explicitly requested, the solution can partially be designed that way by configuring the first instance of all data to be stored on locally available storage (primary path) and the mirrored instance to be stored on the alternate path (secondary path). Furthermore every hypervisor host can have a local preferred path, indicated by the ALUA path preference.
By default data does not automatically follow the VM when the VM is moved to another node. However, virtual disks can be relocated on the fly to other DataCore node without losing I/O access, but this relocation takes some time due to data copy operations required. This kind of relocation usually is done manually, but we allow automation of such tasks and can integrate with VM orchestration using PowerShell for example.
Whether data locality is a good or a bad thing has turned into a philosophical debate. Its true that data locality can prevent a lot of network traffic between nodes, because the data is physically located at the same node where the VM resides. However, in dynamic environments where VMs move to different hosts on a frequent basis, data locality in most cases requires a lot of data to be copied between nodes in order to maintain the physical VM-data relationship. The SDS/HCI vendors today that choose not to use data locality, advocate that the additional network latency is negligible.
|
Partial
Each node within a VxRail appliance has a local memory read cache that is 0.4% of the hosts memory, up to 1GB. The read cache optimizes VDI I/O flows for example. Apart from the read-cache VxRail only uses data locality in stretched clusters to avoid high latency.
Whether data locality is a good or a bad thing has turned into a philosophical debate. Its true that data locality can prevent a lot of network traffic between nodes, because the data is physically located at the same node where the VM resides. However, in dynamic environments where VMs move to different hosts on a frequent basis, data locality in most cases requires a lot of data to be copied between nodes in order to maintain the physical VM-data relationship. The SDS/HCI vendors today that choose not to use data locality, advocate that the additional network latency is negligible.
|
None
Data locality is not used by default but is partially supported. In most cases it is statistically better to not use data locality due to the higher performance of the large pool available from the whole pool of drives in all servers. This can be configured on a per-volume basis.
Physical drives are grouped in one or more pools called placement groups. One disk can participate in more than one placement group. In the simplest configuration all disks reside in a single placement group. By default StorPool will distribute user data across all the disks in the cluster proportional to their size.
If for a particular volume it is preferred that data is stored only on a subset of the disks, then a separate placement group that includes the target disks only can be created and the volume can be configured to store one or all three copies of the data using this placement group.
Placement groups used by the volumes can be changed in realtime, which causes the data to be migrated from one set of disks to another in the background, while the volume is in use, and without a noticeable performance impact.
There is no automated mechanism that changes data locality based on the current usage because limiting the data only to a subset of disks usually doesnt add any performance benefits. However, such functionality can be achieved by external logic through the StorPool API to change the volume settings in realtime.
Whether data locality is a good or a bad thing has turned into a philosophical debate. Its true that data locality can prevent a lot of network traffic between nodes, because the data is physically located at the same node where the VM resides. However, in dynamic environments where VMs move to different hosts on a frequent basis, data locality in most cases requires a lot of data to be copied between nodes in order to maintain the physical VM-data relationship. The SDS/HCI vendors today that choose not to use data locality, advocate that the additional network latency is negligible.
|
|
|
|
Direct-attached (Raw)
Direct-attached (VoV)
SAN or NAS
VoV = Volume-on-Volume; The Virtual Storage Controller uses virtual disks provided by the hypervisor platform.
|
Direct-attached (Raw)
Remote vSAN datatstores (HCI Mesh)
NEW
The software takes ownership of the unformatted physical disks available inside the host.
VMware vSAN 7.0 U1 introduces the HCI Mesh concept. With VMware HCI Mesh a vSAN cluster can leverage the storage of remote vSAN clusters for hosting VMs without sacrificing important features such as HA and DR. Up to 5 remote vSAN datastores can be mounted by a single vSAN cluster. HCI Mesh works by using the existing vSAN VMkernel ports and transport protocols. It is full software-based and does not require any specialized hardware.
|
Direct-attached (Raw)
Direct-attached: The software takes ownership of the unformatted physical disks available on each node – SATA/SAS/NVMe.
|
|
|
|
Magnetic-only
All-Flash
3D XPoint
Hybrid (3D Xpoint and/or Flash and/or Magnetic)
NEW
|
Hybrid (Flash+Magnetic)
All-Flash
Hybrid hosts cannot be mixed with All-Flash hosts in the same VxRail cluster.
|
Magnetic-Only
Hybrid
All-Flash
Pools of different storage types (magnetic-only, hybrid and all-flash) can be created within the same StorPool Distributed Storage (StorPool) cluster.
|
|
|
Hypervisor OS Layer
Details
|
SD, USB, DOM, SSD/HDD
|
SSD
Each VxRail Gen14 node contains 2x 240GB SATA M.2 SSDs with RAID1 protection to host the VMware vSphere hypervisor software.
|
SD, USB, DOM, SSD/HDD
StorPool storage nodes are Linux servers and thus any boot drive supported by Linux is supported by StorPool for root/boot.
|
|
|
|
Memory |
|
|
|
|
DRAM
|
DRAM
Each node within a VxRail appliance has a local memory read cache that is 0.4% of the hosts memory, up to 1GB. The read cache optimizes VDI I/O flows for example.
|
DRAM
StorPool uses RAM in servers for caching.
|
|
|
|
Read/Write Cache
DataCore SANsymphony accelerates reads and writes by leveraging the powerful processors and large DRAM memory inside current generation x86-64bit servers on which it runs. Up to 8 Terabytes of cache memory may be configured on each DataCore node, enabling it to perform at solid state disk speeds without the expense. SANsymphony uses a common cache pool to store reads and writes in.
SANsymphony read caching essentially recognizes I/O patterns to anticipate which blocks to read next into RAM from the physical back-end disks. That way the next request can be served from memory.
When hosts write to a virtual disk, the data first goes into DRAM memory and is later destaged to disk, often grouped with other writes to minimize delays when storing the data to the persistent disk layer. Written data stays in cache for re-reads.
The cache is cleaned on a first-in-first-out (FiFo) basis. Segment overwrites are performed on the oldest data first for both read- and write cache segment requests.
SANsymphony prevents the write cache data from flooding the entire cache. In case the write data amount runs above a certain percentage watermark of the entire cache amount, then the write cache will temporarily be switched to write-through mode in order to regain balance. This is performed fully automatically and is self-adjusting, per virtual disk as well as on a global level.
|
Read Cache
|
Metadata
Read Cache
Write-back Cache (optional)
Memory is used by StorPool for storing metadata, read caching, and proprietary write back-caching (WBC).
When HDDs are used, write operations are usually processed through a write-back cache to reduce the write latency and sequence the write operations to maximize the performance of each disk drive. In typical deployments, this write-back cache is implemented with a persistent storage layer such as power-loss protected memory in RAID controllers or an Optane NVMe drive. This approach guarantees consistent data and data-loss protection in unlikely events such as simultaneous power loss of the entire site.
In non-critical deployments with lower requirements, the write-back cache can be configured to be stored in the DRAM. This can reduce the hardware cost by eliminating the RAID controller with power-loss protected memory or Optane NVMe drive.
|
|
|
|
Up to 8 TB
The actual size that can be configured depends on the server hardware that is used.
|
Non-configurable
Each node within a VxRail appliance has a local memory read cache that is 0.4% of the hosts memory, up to 1GB. The read cache optimizes VDI I/O flows for example.
|
Configurable
StorPool Distributed Storage (StorPool) is designed to take a minimal and fixed amount of DRAM. As a rule of thumb 1 GB of DRAM is used per 1 TB of raw data per server. Additional DRAM in the server can be configured for caching. The remaining DRAM is available for use by other applications or virtual machines in single-layer deployments.
|
|
|
|
Flash |
|
|
|
|
SSD, PCIe, UltraDIMM, NVMe
|
SSD; NVMe
VxRail Appliances support a variety of SSDs.
Cache SSDs (SAS): 400GB, 800GB, 1.6TB
Cache SSDs (NVMe): 800GB, 1.6TB
Capacity SSDs (SAS/SATA): 1.92TB, 3.84TB, 7.68TB
Capacity SSDs (NVMe): 960GB, 1TB, 3.84TB, 4TB
VxRail does not support mixing SAS/SATA SSDs in the same disk group.
|
SSD, PCIe, NVMe
StorPool Distributed Storage (StorPool) supports industry-standard datacenter-grade SATA, SAS and NVMe SSDs for delivering sub-millisecond performance. StorPool does not support consumer-grade SSDs.
|
|
|
|
Persistent Storage
SANsymphony supports new TRIM / UNMAP capabilities for solid-state drives (SSD) in order to reduce wear on those devices and optimize performance.
|
Hybrid: Read/Write Cache
All-Flash: Write Cache + Storage Tier
In all VxRail configurations 1 separate SSD per disk group is used for caching purposes. The other disks in the disk group are used for persistent storage of data.
For All-flash configurations, the flash device(s) in the cache tier are used for write caching only (no read cache) as read performance from the capacity flash devices is more than sufficient.
Two different grades of flash devices are used in an All-flash VxRail configuration: Lower capacity, higher endurance devices for the cache layer and more cost effective, higher capacity, lower endurance devices for the capacity layer. Writes are performed at the cache layer and then de-staged to the capacity layer, only as needed.
|
Persistent Storage
Write-back Cache
StorPool Distributed Storage (StorPool) does not use flash as partial read cache, only as full primary storage. NVMe devices (including Intel Optane) can be used for write-back caching purposes in order to accelerate writes to HDDs.
|
|
|
|
No limit, up to 1 PB per device
The definition of a device here is a raw flash device that is presented to SANsymphony as either a SCSI LUN or a SCSI disk.
|
Hybrid: 4 Flash devices per node
All-Flash: 2-24 Flash devices per node
Each VxRail node always requires 1 high-performance SSD for write caching.
In Hybrid VxRail configurations the high-performance SSD in a disk group is also used for read caching. Per disk group 3-5 HDDs can be used as persistent storage (capacity drives).
In All-Flash VxRail configurations the high-performance SSD in a disk group is only used for write caching. Per node 1-5 SSDs can be used for read caching and persistent storage (capacity drives).
|
No limit
There is no technological limit within the StorPool software architecture to the number of flash drives used, just a best practice of deployment. Typical building blocks (storage nodes) have 10-24 drives installed, typically using 4-8TB NVMe. The number and capacity are tailored to the requirements of the specific end-user organizationss use case.
In general StorPool advices to use small nodes with 10-12 SSDs each, rather than small number of nodes with 36 or more drives each. The storage density and the overall cost are about the same, however a StorPool storage cluster build of smaller nodes is both faster and safer. It takes less time to rebuild a single node in case it fails.
|
|
|
|
Magnetic |
|
|
|
|
SAS or SATA
SAS = 10k or 15k RPM = Medium-capacity medium-speed drives
SATA = NL-SAS = 7.2k RPM = High-capacity low-speed drives
In this case SATA = NL-SAS = MDL SAS
|
Hybrid: SAS or SATA
VxRail Appliances support a variety of HDDs.
SAS 10K: 1.2TB, 1.8TB, 2.4TB
SATA 7.2K: 2.0TB, 4.0TB
VMware vSAN supports the use of 512e drives. 512e magnetic hard disk drives (HDDs) use a physical sector size of 4096 bytes, but the logical sector size emulates a sector size of 512 bytes. Larger sectors enable the integration of stronger error correction algorithms to maintain data integrity at higher storage densities.
VMware vSAN 6.7 introduces support for 4K native (4Kn) mode.
SAS = 10k or 15k RPM = Medium-capacity medium-speed drives
SATA = NL-SAS = 7.2k RPM = High-capacity low-speed drives
|
SAS or SATA
StorPool supports HDDs in magnetic-only as well as hybrid storage configurations.
SAS = 10k or 15k RPM = Medium-capacity medium-speed drives
SATA = NL-SAS = 7.2k RPM = High-capacity low-speed drives
|
|
|
|
Persistent Storage
|
Persistent Storage
|
Persistent Storage
The magnetic tier is either used as primary storage of data, or as secondary storage for storing backups (fault recovery) or remote replicas (disaster recovery).
|
|
|
Magnetic Capacity
Details
|
No limit, up to 1 PB (per device)
The definition of a device here is a raw flash device that is presented to SANsymphony as either a SCSI LUN or a SCSI disk.
|
3-5 SAS/SATA HDDs per disk group
In the current configurations there is a choice between 1.2/1.8/2.4TB 10k SAS drives and 2.0/4.0TB 7.2k NL-SAS drives.
The current configuration maximum for a single host/node is 4 disk groups consisting of 1 NVMe drive + 5 HDDs for hybrid configurations or 1 NVMe drive + 5 capacity SSDs for all-flash configurations = total of 24 drives per host/node.
Since a single VxRail G-Series chassis can contain up to 4 nodes, theres a total of 6 drives per node.
|
No limit
StorPool is a highly scalable platform, so supports an extensive amount of magnetic storage. Magnetic devices (HDDs) are not mandatory in a StorPool Distributed Storage (StorPool) solution.
The number and capacity of HDDs depend on the storage requirements. For example, when needed 36x 16TB HDDs can be installed in a single storage node.
|
|
|
Data Availability
|
|
|
|
|
|
|
Reads/Writes |
|
|
|
Persistent Write Buffer
Details
|
DRAM (mirrored)
If caching is turned on (default=on), any write will only be acknowledged back to the host after it has been succesfully stored in DRAM memory of two separate physical SANsymphony nodes. Based on de-staging algorithms each of the nodes eventually copies the written data that is kept in DRAM to the persistent disk layer. Because DRAM outperforms both flash and spinning disks the applications experience much faster write behavior.
Per default, the limit of dirty-write-data allowed per Virtual Disk is 128MB. This limit could be adjusted, but there has never been a reason to do so in the real world. Individual Virtual Disks can be configured to act in write-through mode, which means that the dirty-write-data limit is set to 0MB so effectively the data is directly written to the persistent disk layer.
DataCore recommends that all servers running SANsymphony software are UPS protected to avoid data loss through unplanned power outages. Whenever a power loss is detected, the UPS automatically signals this to the SANsymphony node and write behavior is switched from write-back to write-through mode for all Virtual Disks. As soon as the UPS signals that power has been restored, the write behavior is switched to write-back again.
|
Flash Layer (SSD, NVMe)
|
Hybrid configurations (optional): Intel Optane NVMe, "Pool" NVMe drive, Broadcom/LSI CacheVault or BBU
Write buffering (aka write-back cache) is optionally used with magnetic HDDs. StorPool supports Intel Optane drives for persistent write-back cache, the use of a small partition on large capacity Pool NVMe drives, or the use of an LSI CacheVault(supercap) or BBU. This effectively protects against data loss even in the events of full power outage of the entire data center.
In low cost / low performance use-cases write buffering for HDDs can be disabled, thus removing the requirement for a write-back cache device, at the cost of increased write latency (write operations wait for the HDD media).
Datacenter-grade SSDs and NVMe have integrated power-loss protection which StorPool uses, so for these types of devices StorPool doesnt require external write buffering.
|
|
|
Disk Failure Protection
Details
|
2-way and 3-way Mirroring (RAID-1) + opt. Hardware RAID
DataCore SANsymphony software primarily uses mirroring techniques (RAID-1) to protect data within the cluster. This effectively means the SANsymphony storage platform can withstand a failure of any two disks or any two nodes within the storage cluster. Optionally, hardware RAID can be implemented to enhance the robustness of individual nodes.
SANsymphony supports Dynamic Data Resilience. Data redundancy (none, 2-way or 3-way) can be added or removed on-the-fly at the vdisk level.
A 2-way mirror acts as active-active, where both copies are accessible to the host and written to. Updating of the mirror is synchronous and bi-directional.
A 3-way mirror acts as active-active-backup, where the active copies are accessible to the host and written to, and the backup copy is inaccessible to the host (paths not presented) and written to. Updating of the mirrors active copies is synchronous and bi-directional. Updating of the mirrors backup copy is synchronous and unidirectional (receive only).
In a 3-way mirror the backup copy should be independent of existing storage resources that are used for the active copies. Because of the synchronous updating all mirror copies should be equal in storage performance.
When in a 3-way mirror an active copy fails, the backup copy is promoted to active state. When the failed mirror copy is repaired, it automatically assumes a backup state. Roles can be changed manually on-the-fly by the end-user.
DataCore SANsymphony 10.0 PSP9 U1 introduced System Managed Mirroring (SMM). A multi-copy virtual disk is created from a storage source (disk pool or pass-through disk) from two or three DataCore Servers in the same server group. Data is synchronously mirrored between the servers to maintain redundancy and high availability of the data. System Managed Mirroring (SMM) addresses the complexity of managing multiple mirror paths for numerous virtual disks. This feature also addresses the 256 LUN limitation by allowing thousands of LUNs to be handled per network adapter. The software transports data in a round robin mode through available mirror ports to maximize throughput and can dynamically reroute mirror traffic in the event of lost ports or lost connections. Mirror paths are automatically and silently managed by the software.
The System Managed Mirroring (SMM) feature is disabled by default. This feature may be enabled or disabled for the server group.
With SANsymphony 10.0 PSP10 adds seamless transition when converting Mirrored Virtual Disks (MVD) to System Managed Mirroring (SMM). Seamless transition converts and replaces mirror paths on virtual disks in a manner in which there are no momentary breaks in mirror paths.
|
Hybrid/All-Flash: 0-3 Replicas (RAID1; 1N-4N)
All-Flash: Erasure Coding (RAID5-6)
VMwares implementation of Erasure Coding only applies to All-Flash configurations and is similar to RAID-5 and RAID-6 protection. RAID-5 requires a minimum of 4 nodes (3+1) and protects against a single node failure; RAID-6 requires a minimum of 6 nodes and protects against two node failures. Erasure Coding is only available in vSAN Enterprise and Advanced editions, and is only configurable for All-flash configurations.
VMwares implementation of replicas is called NumberOfFailuresToTolerate (0, 1, 2 or 3). It applies to both disk and node failures. Optionally, nodes can be assigned to a logical grouping called Failure Domains. The use of 0 Replicas within a single site is only available when using Stretched Clustering, which is only available in the Enterprise editions.
Replicas: Before any write is acknowledged to the host, it is synchronously replicated on an adjacent node. All nodes in the cluster participate in replication. This means that with 2N one instance of data that is written is stored on one node and another instance of that data is stored on a different node in the cluster. For both instances this happens in a fully distributed manner, in other words, there is no dedicated partner node. When an entire node fails, VMs need to be restarted and data is read from the surviving instances on other nodes within the vSAN cluster instead. At the same time data re-replication of the associated replicas needs to occur in order to restore the desired NumberOfFailuresToTolerate.
Failure Domains: When using Failure Domains, one instance of the data is kept within the local Failure Domain and another instance of the data is kept within another Failure Domain. By applying Failure Domains, rack failure protection can be achieved as well as site failure protection in stretched configuration.
vSAN provides increased support for locator LEDs on vSAN disks. Gen-9 HPE controllers in pass-through mode support vSAN activation of locator LEDs. Blinking LEDs help to identify and isolate specific drives.
vSAN 6.7 introduces the Host Pinning storage policy that can be used for next-generation, shared-nothing applications. When using Host Pinning, vSAN maintains a single copy of the data and stores the data blocks local to the ESXi host running the VM. This policy is offered as a deployment choice for Big Data (Hadoop, Spark), NoSQL, and other such applications that maintain data redundancy at the application layer. vSAN Host Pinning has specific requirements and guidelines that require VMware validation to ensure proper deployment.
|
0-2 Replicas (1N-3N)
StorPool uses replicas to guarantee data redundancy.
StorPools implementation of replicas is called Copies:
- Maintaining 1 copy/replica (1N) means that data is kept only once and is not protected by another copy/replica.
- Maintaining 2 copies/replicas (2N) means that data is protected by writing 2 copies of the data to the StorPool cluster. Protection applies to both disk and node failures.
- Maintaining 3 copies/replicas (3N) means that data is protected by writing 3 copies of the data to the StorPool cluster. Protection applies to both disk and node failures.
StorPool recommends using 3 copies/replicas as a standard and using 2 copies/replicas for data that is less critical. Using the standard (3N) means that the StorPool Distributed Storage (StorPool) platform can withstand a failure of any two disks or any two nodes within the storage cluster.
Before any write is acknowledged to the host, it is synchronously replicated to the prescribed number of nodes. All nodes in the cluster participate in replication. This means that with 3N one instance of data that is written is stored on one node and other instances of that data are stored on two different nodes in the cluster. For all instances this happens in a fully distributed manner, in other words, there is no dedicated partner node. When a disk fails, it is marked offline and data is read from another instance instead. At the same time data re-replication of the associated copies/replicas is initiated in order to restore the desired number of copies/replicas.
|
|
|
Node Failure Protection
Details
|
2-way and 3-way Mirroring (RAID-1)
DataCore SANsymphony software primarily uses mirroring techniques (RAID-1) to protect data within the cluster. This effectively means the SANsymphony storage platform can withstand a failure of any two disks or any two nodes within the storage cluster. Optionally, hardware RAID can be implemented to enhance the robustness of individual nodes.
SANsymphony supports Dynamic Data Resilience. Data redundancy (none, 2-way or 3-way) can be added or removed on-the-fly at the vdisk level.
A 2-way mirror acts as active-active, where both copies are accessible to the host and written to. Updating of the mirror is synchronous and bi-directional.
A 3-way mirror acts as active-active-backup, where the active copies are accessible to the host and written to, and the backup copy is inaccessible to the host (paths not presented) and written to. Updating of the mirrors active copies is synchronous and bi-directional. Updating of the mirrors backup copy is synchronous and unidirectional (receive only).
In a 3-way mirror the backup copy should be independent of existing storage resources that are used for the active copies. Because of the synchronous updating all mirror copies should be equal in storage performance.
When in a 3-way mirror an active copy fails, the backup copy is promoted to active state. When the failed mirror copy is repaired, it automatically assumes a backup state. Roles can be changed manually on-the-fly by the end-user.
DataCore SANsymphony 10.0 PSP9 U1 introduced System Managed Mirroring (SMM). A multi-copy virtual disk is created from a storage source (disk pool or pass-through disk) from two or three DataCore Servers in the same server group. Data is synchronously mirrored between the servers to maintain redundancy and high availability of the data. System Managed Mirroring (SMM) addresses the complexity of managing multiple mirror paths for numerous virtual disks. This feature also addresses the 256 LUN limitation by allowing thousands of LUNs to be handled per network adapter. The software transports data in a round robin mode through available mirror ports to maximize throughput and can dynamically reroute mirror traffic in the event of lost ports or lost connections. Mirror paths are automatically and silently managed by the software.
The System Managed Mirroring (SMM) feature is disabled by default. This feature may be enabled or disabled for the server group.
With SANsymphony 10.0 PSP10 adds seamless transition when converting Mirrored Virtual Disks (MVD) to System Managed Mirroring (SMM). Seamless transition converts and replaces mirror paths on virtual disks in a manner in which there are no momentary breaks in mirror paths.
|
Hybrid/All-Flash: 0-3 Replicas (RAID1; 1N-4N)
All-Flash: Erasure Coding (RAID5-6)
VMwares implementation of Erasure Coding only applies to All-Flash configurations and is similar to RAID-5 and RAID-6 protection. RAID-5 requires a minimum of 4 nodes (3+1) and protects against a single node failure; RAID-6 requires a minimum of 6 nodes and protects against two node failures. Erasure Coding is only available in vSAN Enterprise and Advanced editions, and is only configurable for All-flash configurations.
VMwares implementation of replicas is called NumberOfFailuresToTolerate (0, 1, 2 or 3). It applies to both disk and node failures. Optionally, nodes can be assigned to a logical grouping called Failure Domains. The use of 0 Replicas within a single site is only available when using Stretched Clustering, which is only available in the Enterprise editions.
Replicas: Before any write is acknowledged to the host, it is synchronously replicated on an adjacent node. All nodes in the cluster participate in replication. This means that with 2N one instance of data that is written is stored on one node and another instance of that data is stored on a different node in the cluster. For both instances this happens in a fully distributed manner, in other words, there is no dedicated partner node. When an entire node fails, VMs need to be restarted and data is read from the surviving instances on other nodes within the vSAN cluster instead. At the same time data re-replication of the associated replicas needs to occur in order to restore the desired NumberOfFailuresToTolerate.
Failure Domains: When using Failure Domains, one instance of the data is kept within the local Failure Domain and another instance of the data is kept within another Failure Domain. By applying Failure Domains, rack failure protection can be achieved as well as site failure protection in stretched configuration.
vSAN provides increased support for locator LEDs on vSAN disks. Gen-9 HPE controllers in pass-through mode support vSAN activation of locator LEDs. Blinking LEDs help to identify and isolate specific drives.
vSAN 6.7 introduces the Host Pinning storage policy that can be used for next-generation, shared-nothing applications. When using Host Pinning, vSAN maintains a single copy of the data and stores the data blocks local to the ESXi host running the VM. This policy is offered as a deployment choice for Big Data (Hadoop, Spark), NoSQL, and other such applications that maintain data redundancy at the application layer. vSAN Host Pinning has specific requirements and guidelines that require VMware validation to ensure proper deployment.
|
0-2 Replicas (1N-3N)
Node failure is not a critical event in StorPool Distributed Storage (StorPool) when using multiple copies/replicas (3N or 2N) for data protection. A node failure does not cause downtime or even partial unavailability. The system is self-healing: the StorPool cluster rebuilds only the changed/missing data when the failed node returns or just creates a new copy of the missing data when the failed node is not back within a pre-set time (eg. 5 minutes as most failures are transient).
StorPool uses replicas to guarantee data redundancy.
StorPools implementation of replicas is called Copies:
- Maintaining 1 copy/replica (1N) means that data is kept only once and is not protected by another copy/replica.
- Maintaining 2 copies/replicas (2N) means that data is protected by writing 2 copies of the data to the StorPool cluster. Protection applies to both disk and node failures.
- Maintaining 3 copies/replicas (3N) means that data is protected by writing 3 copies of the data to the StorPool cluster. Protection applies to both disk and node failures.
StorPool recommends using 3 copies/replicas as a standard and using 2 copies/replicas for data that is less critical. Using the standard (3N) means that the StorPool Distributed Storage (StorPool) platform can withstand a failure of any two disks or any two nodes within the storage cluster.
Before any write is acknowledged to the host, it is synchronously replicated to the prescribed number of nodes. All nodes in the cluster participate in replication. This means that with 3N one instance of data that is written is stored on one node and other instances of that data are stored on two different nodes in the cluster. For all instances this happens in a fully distributed manner, in other words, there is no dedicated partner node. When a disk fails, it is marked offline and data is read from another instance instead. At the same time data re-replication of the associated copies/replicas is initiated in order to restore the desired number of copies/replicas.
|
|
|
Block Failure Protection
Details
|
Not relevant (usually 1-node appliances)
Manual configuration (optional)
Manual designation per Virtual Disk is required to accomplish this. The end-user is able to define which node is paired to which node for that particular Virtual Disk. However, block failure protection is in most cases irrelevant as 1-node appliances are used as building blocks.
SANsymphony works on an N+1 redundancy design allowing any node to acquire any other node as a redundancy peer per virtual device. Peers are replacable/interchangable on a per Virtual Disk level.
|
Failure Domains
Block failure protection can be achieved by assigning nodes in the same appliance to different Failure Domains.
Failure Domains: When using Failure Domains, one instance of the data is kept within the local Failure Domain and another instance of the data is kept within another Failure Domain. By applying Failure Domains, rack failure protection can be achieved as well as site failure protection in stretched configurations.
|
Fault Sets
StorPool protects data by keeping number of copies (1, 2 or 3) in different servers or racks. The default is 3N. This means that for example in a 5-node cluster any 2 nodes can be lost without impacting availability.
In larger StorPool clusters (e.g. 12 nodes in 3 chassis), StorPool can be configured to store replicas (copies) in different racks or different chassis, tolerating entire chassis or rack failure.
Fault Sets: By default StorPool uses a placement policy that distributes user’s data on as many physical drives and servers as possible in order to increase performance and minimize the impact in case of a node failure. When some storage nodes are interrelated and there is a higher chance to fail simultaneously, the placement policy can be tuned by defining 'Fault Sets' - a set of nodes that have a higher probability to fail simultaneously. When fault sets are defined, StorPool will place data on different Fault Sets - in other words there is only one copy of the data in a particular Fault Set. By leveraging Fault Sets a storage cluster can be arranged for example in racks, where each rack represents a separate Fault Set. If an entire rack fails, the placement policy will guarantee there are at least two available copies of the data that reside on the remaining racks.
|
|
|
Rack Failure Protection
Details
|
Manual configuration
Manual designation per Virtual Disk is required to accomplish this. The end-user is able to define which node is paired to which node for that particular Virtual Disk.
|
Failure Domains
Rack failure protection can be achieved by assigning nodes within the same rack to different Failure Domains.
Failure Domains: When using Failure Domains, one instance of the data is kept within the local Failure Domain and another instance of the data is kept within another Failure Domain. By applying Failure Domains, rack failure protection can be achieved as well as site failure protection in stretched configurations.
|
Fault Sets
StorPool protects data by keeping number of copies (1, 2 or 3) in different servers or racks. The default is 3N. This means that for example in a 5-node cluster any 2 nodes can be lost without impacting availability.
In larger StorPool clusters (e.g. 12 nodes in 3 chassis), StorPool can be configured to store replicas (copies) in different racks or different chassis, tolerating entire chassis or rack failure.
Fault Sets: By default StorPool uses a placement policy that distributes user’s data on as many physical drives and servers as possible in order to increase performance and minimize the impact in case of a node failure. When some storage nodes are interrelated and there is a higher chance to fail simultaneously, the placement policy can be tuned by defining 'Fault Sets' - a set of nodes that have a higher probability to fail simultaneously. When fault sets are defined, StorPool will place data on different Fault Sets - in other words there is only one copy of the data in a particular Fault Set. By leveraging Fault Sets a storage cluster can be arranged for example in racks, where each rack represents a separate Fault Set. If an entire rack fails, the placement policy will guarantee there are at least two available copies of the data that reside on the remaining racks.
|
|
|
Protection Capacity Overhead
Details
|
Mirroring (2N) (primary): 100%
Mirroring (3N) (primary): 200%
+ Hardware RAID5/6 overhead (optional)
|
Replicas (2N): 100%
Replicas (3N): 200%
Erasure Coding (RAID5): 33%
Erasure Coding (RAID6): 50%
RAID5: The stripe size used by vSAN for RAID5 is 3+1 (33% capacity overhead for data protection) and is independent of the cluster size. The minimum cluster size for RAID5 is 4 nodes.
RAID6: The stripe size used by vSAN for RAID6 is 4+2 (50% capacity overhead for data protection) and is independent of the cluster size. The minimum cluster size for RAID6 is 6 nodes.
RAID5/6 can only be leveraged in vSAN All-flash configurations because of I/O amplification.
|
Mirroring (2N) (primary): 100%
Mirroring (3N) (primary): 200%
StorPool implements 3-way or 2-way synchronous replication, meaning multiple full copies/replicas of the data exist.
With 3N the raw storage capacity is approximately 300% of the stored data capacity, not accounting for space saving features that reduce space usage and not including overhead that increases space usage.
For each data copy/replica there is 10% capacity overhead that includes checksums (for end-to-end data integrity), metadata and copy-on-write/thin provisioning overheads and safety. The capacity overheads are taken into account when performing StorPool sizing exercises. When a StorPool quote states a solution supports 100TB of stored data, it is really able to store 100TB of data.
|
|
|
Data Corruption Detection
Details
|
N/A (hardware dependent)
SANsymphony fully relies on the hardware layer to protect data integrity. This means that the SANsymphony software itself does not perform Read integrity checks and/or Disk scrubbing to verify and maintain data integrity.
|
Read integrity checks
Disk scrubbing (software)
End-to-end checksum provides automatic detection and resolution of silent disk errors. Creation of checksums is enabled by default, but can be disabled through policy on a per VM (or virtual disk) basis if desired. In case of checksum verification failures data is fetched from another copy.
The disk scrubbing process runs in the background.
|
Read integrity checks (end-to-end checksums)
Disk scrubbing
StorPool has incorporated a checksum based end-to-end data integrity feature. StorPool Distributed Storage (StorPool) protects data and guarantees data integrity by leveraging a 64-bit checksum and a version number for each sector maintained by StorPool. The mechanism is more extensive than those used by (many) other platforms. It checksums data in the initiator, i.e. it protects against errors in both hardware and the full software stack, not just the storage system itself. The checksum based end-to-end data integrity feature has been designed not to impact storage performance.
If a corrupted copy of data is detected, the copy is invalidated and restored by an undamaged copy of the data.
Data at rest is regularly checked (scrubbed) for errors and recovered in case any corruption is detected.
|
|
|
|
Points-in-Time |
|
|
|
|
Built-in (native)
|
Built-in (native)
VMware vSAN uses the 'vSANSparse' snapshot format that leverages VirstoFS technology as well as in-memory metadata cache for lookups. vSANSparse offers greatly improved performance when compared to previous virtual machine snapshot implementations.
|
Built-in (native)
StorPool Distributed Storage (StorPool) supports instantaneous, copy-on-write (CoW) storage snapshots and clones. Creating snapshots can be performed on a per volume basis with deep chains (eg. 100+ snaps of an individual volume) without having a tangible impact on the performance.
|
|
|
|
Local + Remote
SANsymphony snapshots are always created on one side only. However, SANsymphony allows you to create a snapshot for the data on each side by configuring two snapshot schedules, one for the local volume and one for the remote volume. Both snapshot entities are independent and can be deleted independently allowing different retention times if needed.
There is also the capability to pair the snapshot feature along with asynchronous replication which provides you with the ability to have a third site long distance remote copy in place with its own retention time.
|
Local
|
Local + Remote
StorPool snapshots can be replicated to a remote StorPool cluster over an encrypted site-to-site (internet) link. After the first sync, StorPool only copies new or changed data rather than the entire data set. There is no fixed primary-secondary relationship between clusters. Snapshots and volumes on individual clusters have independent lifecycles and can be created and deleted not affecting other clusters or data on them.
|
|
|
Snapshot Frequency
Details
|
1 Minute
The snapshot lifecycle can be automatically configured using the integrated Automation Scheduler.
|
GUI: 1 hour
vSAN snapshots are invoked using the existing snapshot options in the VMware vSphere GUI.
To create a snapshot schedule using the Dell EMCnter (Web) Client: Click on a VM, then inside the Monitoring tab select Tasks & Events, Scheduled Tasks, 'Take Snapshots…'.
A single snapshot schedule allows a minimum frequency of 1 hour. Manual snapshots can be taken at any time.
|
Seconds (workload dependent)
Snapshots are created on request via CLI or API. There is no default frequency.
There is a separate service that can create regular snapshots and apply retention policies on the local or remote cluster. There is no default frequency, as is defined in the snapshot policy. While StorPool can create snapshots with no performance degradation, practical use cases are with hourly and daily snapshots.
|
|
|
Snapshot Granularity
Details
|
Per VM (Vvols) or Volume
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
Although DataCore SANsymphony uses block-storage, the platform is capable of attaining per VM-granularity if desired.
In Microsoft Hyper-V environments, when a VM with vdisks is created through SCVMM, DataCore can be instructed to automatically carve out a Virtual Disk (=storage volume) for every individual vdisk. This way there is a 1-to-1 alignment from end-to-end and snapshots can be created on the VM-level. The per-VM functionality is realized by installing the DataCore Storage Management Provider in SCVMM.
Because of the per-host storage limitations in VMware vSphere environments, VVols is leveraged to provide per VM-granularity. DataCore SANsymphony Provider v2.01 is certified for VMware ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
|
Per VM
|
Per Volume (LUN)
Per VM/container (eg. OpenStack, Kubernetes)
StorPool supports per-volume (LUN) snapshots that are fine-grained (4KB) and crash-consistent by default. Higher levels of data consistency can be achieved by orchestration e.g. you can get application-consistent snapshots by first instructing the application to freeze, then taking the snapshot and unfreezing the application.
In many deployments where cloud orchestration platforms are used, there is 1-to-1 relationship between a virtual disk and a volume. In these cases snapshots are being created per virtual disk. Examples of relevant cloud orchestration platforms are OpenStack, CloudStack with KVM, OnApp, OpenNebula and Kubernetes (for persistent volumes).
StorPool also supports crash-consistent snapshots of multiple volumes (LUNs).
|
|
|
|
Built-in (native)
DataCore SANsymphony incorporates Continuous Data Protection (CDP) and leverages this as an advanced backup mechanism. As the term implies, CDP continuously logs and timestamps I/Os to designated virtual disks, allowing end-users to restore the environment to an arbitrary point-in-time within that log.
Similar to snapshot requests, one can generate a CDP Rollback Marker by scripting a call to a PowerShell cmdlet when an application has been quiesced and the caches have been flushed to storage. Several of these markers may be present throughout the 14-day rolling log. When rolling back a virtual disk image, one simply selects an application-consistent or crash-consistent restore point from just before the incident occurred.
|
External (vSAN Certified)
VMware vSAN does not provide any backup/restore capabilities of its own. Therefore it relies on existing data protection solutions like Dell EMC Avamar Virtual Edition (AVE) backup software or any other vSphere compatible 3rd party backup application. AVE is not part of the licenses bundled with VxRail and thus needs to be purchased separately. AVE requires the deployment of virtual backup appliances on top of vSphere.
No specific integration exists between VMware vSAN and Dell EMC AVE.
VMwares free-of-charge backup software that comes with any vSphere license, VMware vSphere Data Protection (VDP), has been declared End-of-Availability and is not supported for VMware vSphere 6.7 and up.
VMware is working on native vSAN data protection, which is currently still in beta and was expected to go live in the first half of 2019. vSAN 7.0 also did not introduce native data protection.
The following 3rd party Data Protection partner products are certified with vSAN 6.7:
- Cohesity DataProtect 6.1
- CommVault 11
- Dell EMC Avamar 18.1
- Dell EMC NetWorker 18.1
- Hitachi Data Instance Director 6.7
- Rubrik Cloud Data Management 4.2
- Veeam Backup&Replication 9.5 U4a
- Veritas NetBackup 8.1.2
|
Built-in (native)
StorPool Distributed Storage (StorPool) provides integrated backup/restore functionality controlled through REST-API or CLI.
For backup purposes commands in the API/CLI can be used to create a crash-consistent snapshot and send the snapshot to a remote site that is also running a StorPool cluster.
For restore purposes commands in the API/CLI can be used to create a volume in the local StorPool cluster based on the contents of a local or remote (backed up) snapshot.
Some of the end-user organizations that leverage StorPool rely entirely on maintaining local and remote snapshots for data protection purposes and thus do not use an external backup/restore application. They have built their own scripting or orchestration around the StorPool API. Other end-user organizations that leverage StorPool leverage an independent backup/restore solution fpr data protection purposes.
Remote snapshots are fully independent of local storage and snapshots stored on it. Snapshots on the remote site can have an independent retention polity. There is no need to keep any snapshot on the local site in order to have a backup (snapshot) on the remote site.
|
|
|
|
Local or Remote
All available storage within the SANsymphony group can be configured as targets for back-up jobs.
|
N/A
VMware vSAN does not provide any backup/restore capabilities of its own. Therefore it relies on existing data protection solutions like Dell EMC Avamar Virtual Edition (AVE) backup software or any other vSphere compatible 3rd party backup application. AVE is not part of the licenses bundled with VxRail and thus needs to be purchased separately. AVE requires the deployment of virtual backup appliances on top of vSphere.
No specific integration exists between VMware vSAN and Dell EMC AVE.
VMwares free-of-charge backup software that comes with any vSphere license, VMware vSphere Data Protection (VDP), has been declared End-of-Availability and is not supported for VMware vSphere 6.7 and up.
VMware is working on native vSAN data protection, which is currently still in beta and expected to go live in the first half of 2019.
The following 3rd party Data Protection partner products are certified with vSAN 6.7:
- Cohesity DataProtect 6.1
- CommVault 11
- Dell EMC Avamar 18.1
- Dell EMC NetWorker 18.1
- Hitachi Data Instance Director 6.7
- Rubrik Cloud Data Management 4.2
- Veeam Backup&Replication 9.5 U4a
- Veritas NetBackup 8.1.2
|
Local or Remote
StorPool can create snapshots on a frequent basis and send these snapshots between sites securely and efficiently.
|
|
|
|
Continuously
As Continuous Data Protection (CDP) is being leveraged, I/Os are logged and timestamped in a continous fashion, so end-users can restore to virtually any-point-in-time.
|
N/A
VMware vSAN does not provide any backup/restore capabilities of its own. Therefore it relies on existing data protection solutions like Dell EMC Avamar Virtual Edition (AVE) backup software or any other vSphere compatible 3rd party backup application. AVE is not part of the licenses bundled with VxRail and thus needs to be purchased separately. AVE requires the deployment of virtual backup appliances on top of vSphere.
No specific integration exists between VMware vSAN and Dell EMC AVE.
VMwares free-of-charge backup software that comes with any vSphere license, VMware vSphere Data Protection (VDP), has been declared End-of-Availability and is not supported for VMware vSphere 6.7 and up.
VMware is working on native vSAN data protection, which is currently still in beta and expected to go live in the first half of 2019.
The following 3rd party Data Protection partner products are certified with vSAN 6.7:
- Cohesity DataProtect 6.1
- CommVault 11
- Dell EMC Avamar 18.1
- Dell EMC NetWorker 18.1
- Hitachi Data Instance Director 6.7
- Rubrik Cloud Data Management 4.2
- Veeam Backup&Replication 9.5 U4a
- Veritas NetBackup 8.1.2
|
Seconds (workload dependent)
Snapshots are created on request via CLI or API. There is no default frequency.
There is a separate service that can create regular snapshots and apply retention policies on the local or remote cluster. There is no default frequency, as is defined in the snapshot policy. While StorPool can create snapshots with no performance degradation, practical use cases are with hourly and daily snapshots.
|
|
|
Backup Consistency
Details
|
Crash Consistent
File System Consistent (Windows)
Application Consistent (MS Apps on Windows)
By default CDP creates crash consistent restore points. Similar to snapshot requests, one can generate a CDP Rollback Marker by scripting a call to a PowerShell cmdlet when an application has been quiesced and the caches have been flushed to storage.
Several CDP Rollback Markers may be present throughout the 14-day rolling log. When rolling back a virtual disk image, one simply selects an application-consistent, filesystem-consistent or crash-consistent restore point from (just) before the incident occurred.
In a VMware vSphere environment, the DataCore VMware vCenter plug-in can be used to create snapshot schedules for datastores and select the VMs that you want to enable VSS filesystem/application consistency for.
|
N/A
VMware vSAN does not provide any backup/restore capabilities of its own. Therefore it relies on existing data protection solutions like Dell EMC Avamar Virtual Edition (AVE) backup software or any other vSphere compatible 3rd party backup application. AVE is not part of the licenses bundled with VxRail and thus needs to be purchased separately. AVE requires the deployment of virtual backup appliances on top of vSphere.
No specific integration exists between VMware vSAN and Dell EMC AVE.
VMwares free-of-charge backup software that comes with any vSphere license, VMware vSphere Data Protection (VDP), has been declared End-of-Availability and is not supported for VMware vSphere 6.7 and up.
VMware is working on native vSAN data protection, which is currently still in beta and expected to go live in the first half of 2019.
The following 3rd party Data Protection partner products are certified with vSAN 6.7:
- Cohesity DataProtect 6.1
- CommVault 11
- Dell EMC Avamar 18.1
- Dell EMC NetWorker 18.1
- Hitachi Data Instance Director 6.7
- Rubrik Cloud Data Management 4.2
- Veeam Backup&Replication 9.5 U4a
- Veritas NetBackup 8.1.2
|
Crash Consistent (also Group Consistency)
All snapshots in StorPool are crash consistent. StorPool supports atomic snapshots of multiple volumes – e.g. all virtual disks of a VM can be snapshotted at a single point of time, providing consistent backup and restore for multi-disk systems.
The StorPool REST-API allows creating a snapshot of multiple volumes with a single call by specifying the names of the volumes. The snapshots created in this way store the respective volumes at exactly the same point in time thus preserving data consisteny across an application. There is no requirement to group volumes in advance.
|
|
|
Restore Granularity
Details
|
Entire VM or Volume
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
Although DataCore SANsymphony uses block-storage, the platform is capable of attaining per VM-granularity if desired.
In Microsoft Hyper-V environments, when a VM with vdisks is created through SCVMM, DataCore can be instructed to automatically carve out a Virtual Disk (=storage volume) for every individual vdisk. This way there is a 1-to-1 alignment from end-to-end and snapshots can be created on the VM-level. The per-VM functionality is realized by installing the DataCore Storage Management Provider in SCVMM.
Because of the per-host storage limitations in VMware vSphere environments, VVols is leveraged to provide per VM-granularity. DataCore SANsymphony Provider v2.01 is VMware certified for ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
When configuring the virtual environment as described above, effectively VM-restores are possible.
For file-level restores a Virtual Disk snapshot needs to be mounted so the file can be read from the mount. Many simultaneous rollback points for the same Virtual Disk can coexist at the same time, allowing end-users to compare data states. Mounting and changing rollback points does not alter the original Virtual Disk.
|
N/A
VMware vSAN does not provide any backup/restore capabilities of its own. Therefore it relies on existing data protection solutions like Dell EMC Avamar Virtual Edition (AVE) backup software or any other vSphere compatible 3rd party backup application. AVE is not part of the licenses bundled with VxRail and thus needs to be purchased separately. AVE requires the deployment of virtual backup appliances on top of vSphere.
No specific integration exists between VMware vSAN and Dell EMC AVE.
VMwares free-of-charge backup software that comes with any vSphere license, VMware vSphere Data Protection (VDP), has been declared End-of-Availability and is not supported for VMware vSphere 6.7 and up.
VMware is working on native vSAN data protection, which is currently still in beta and expected to go live in the first half of 2019.
The following 3rd party Data Protection partner products are certified with vSAN 6.7:
- Cohesity DataProtect 6.1
- CommVault 11
- Dell EMC Avamar 18.1
- Dell EMC NetWorker 18.1
- Hitachi Data Instance Director 6.7
- Rubrik Cloud Data Management 4.2
- Veeam Backup&Replication 9.5 U4a
- Veritas NetBackup 8.1.2
|
Entire Volume
Commands in the API/CLI can be used to create a volume in the local cluster that is based on the contents of a local or remote (backed up) snapshot.
In addition snapshots can be instantiated (copy-on-write cloned) as read-write volumes. When doing so an end-user gains file-level access to the backed-up filesystem of a specific volume.
|
|
|
Restore Ease-of-use
Details
|
Entire VM or Volume: GUI
Single File: Multi-step
Restoring VMs or single files from volume-based storage snapshots requires a multi-step approach.
For file-level restores a Virtual Disk snapshot needs to be mounted so the file can be read from the mount. Many simultaneous rollback points for the same Virtual Disk can coexist at the same time, allowing end-users to compare data states. Mounting and changing rollback points does not alter the original Virtual Disk.
|
N/A
VMware vSAN does not provide any backup/restore capabilities of its own. Therefore it relies on existing data protection solutions like Dell EMC Avamar Virtual Edition (AVE) backup software or any other vSphere compatible 3rd party backup application. AVE is not part of the licenses bundled with VxRail and thus needs to be purchased separately. AVE requires the deployment of virtual backup appliances on top of vSphere.
No specific integration exists between VMware vSAN and Dell EMC AVE.
VMwares free-of-charge backup software that comes with any vSphere license, VMware vSphere Data Protection (VDP), has been declared End-of-Availability and is not supported for VMware vSphere 6.7 and up.
VMware is working on native vSAN data protection, which is currently still in beta and expected to go live in the first half of 2019.
The following 3rd party Data Protection partner products are certified with vSAN 6.7:
- Cohesity DataProtect 6.1
- CommVault 11
- Dell EMC Avamar 18.1
- Dell EMC NetWorker 18.1
- Hitachi Data Instance Director 6.7
- Rubrik Cloud Data Management 4.2
- Veeam Backup&Replication 9.5 U4a
- Veritas NetBackup 8.1.2
|
Entire Volume: API or CLI
Single File: Multi-step
Backed up snapshots are read-only when accessed from the original site. Restoring a volume from a backup is a matter of instantiating (cloning) the snapshot in the original site. This is controlled through API or CLI.
Backed up snapshots can also be transferred to a remote site when needed. This is controlled through API or CLI as well.
|
|
|
|
Disaster Recovery |
|
|
|
Remote Replication Type
Details
|
Built-in (native)
DataCore SANsymphonys remote replication function, Asynchronous Replication, is called upon when secondary copies will be housed beyond the reach of Synchronous Mirroring, as in distant Disaster Recovery (DR) sites. It relies on a basic IP connection between locations and works in both directions. That is, each site can act as the disaster recovery facility for the other. The software operates near-synchronously, meaning that it does not hold up the application waiting on confirmation from the remote end that the update has been stored remotely.
|
Built-in (Stretched Clusters only)
External
VMware vSAN does not have any remote replication capabilities of its own. Stretched Clustering with synchronous replication is the exception.
Therefore in non-stretched setups it relies on external remote replication mechanisms like VMwares free-of-charge vSphere Replication (VR) or any vSphere compatible 3rd party remote replication application (eg. Zerto VR).
vSphere Replication requires the deployment of virtual appliances. No specific integration exists between VMware vSAN and VMware vSphere VR.
As of vSAN 7.0 vSphere Replication objects are visible in the vSAN capacity view. Objects are recognized as vSphere replica type, and space usage is accounted for under the Replication category.
|
Built-in (native)
StorPool Distributed Storage (StorPool) provides a native remote replication capability for disaster recovery (DR) purposes. This capability uses the same snapshot and transfer techniques as the backup functionality, but differs in terms of what snapshots stored in the DR location are used for.
When a DR event occurs, snapshots are instantiated as volumes and compute workloads (VMs/containers) are started from those volumes. Fail-over is typically triggered manually and the exact DR procedure depends on the application landscape and cloud management platform (CMP) in use.
|
|
|
Remote Replication Scope
Details
|
To remote sites
To MS Azure Cloud
On-premises deployments of DataCore SANsymphony can use Microsoft Azure cloud as an added replication location to safeguard highly available systems. For example, on-premises stretched clusters can replicate a third copy of the data to MS Azure to protect against data loss in the event of a major regional disaster. Critical data is continuously replicated asynchronously within the hybrid cloud configuration.
To allow quick and easy deployment a ready-to-go DataCore Cloud Replication instance can be acquired through the Azure Marketplace.
MS Azure can serve only as a data repository. This means that VMs cannot be restored and run in an Azure environment in case of a disaster recovery scenario.
|
VR: To remote sites, To VMware clouds
vSAN allows for replication of VMs to a different vSAN cluster on a remote site or to any supported VMware Cloud Service Provider (vSphere Replication to Cloud). This includes VMware on AWS and VMware on IBM Cloud.
|
To remote sites
Single Site DR = 1-to-1
Multiple Site DR = 1-to many, many-to 1
|
|
|
Remote Replication Cloud Function
Details
|
Data repository
All public clouds can only serve as data repository when hosting a DataCore instance. This means that VMs cannot be restored and run in the public cloud environment in case of a disaster recovery scenario.
In the Microsoft Azure Marketplace there is a pre-installed DataCore instance (BYOL) available named DataCore Cloude Replication.
BYOL = Bring Your Own License
|
VR: DR-site (VMware Clouds)
Because VMware on AWS and VMware on IBM Cloud are full vSphere implementations, replicated VMs can be started and run in a DR-scenario.
|
DR-site (several cloud providers)
Several, mostly European, cloud providers such as MetaNet, CloudSigma, Amito and Dustin leverage StorPool. Therefore on-premises StorPool clusters operated by end-user organizations are able to replicate to the StorPool clusters operated by these public cloud providers. This allows for setting up Disaster Recovery scenarios.
|
|
|
Remote Replication Topologies
Details
|
Single-site and multi-site
Single Site DR = 1-to-1
Multiple Site DR = 1-to many, many-to 1
|
VR: Single-site and multi-site
Single Site DR = 1-to-1
Multiple Site DR = 1-to many, many-to 1
|
Single-site and multi-site
Single Site DR = 1-to-1
Multiple Site DR = 1-to many, many-to 1
|
|
|
Remote Replication Frequency
Details
|
Continuous (near-synchronous)
SANsymphony Asynchronous Replication is not checkpoint-based but instead replicates continuously. This way data loss is kept to a minimum (seconds to minutes). End-users can inject custom consistency checkpoints based on CDP technology which has no minimum time slot/frequency.
|
VR: 5 minutes (Asynchronous)
vSAN: Continuous (Stretched Cluster)
The 'Stretched Cluster' feature is only available in the Enterprise edition.
|
Seconds (workload dependent)
There is no default frequency. For the minimum RPO on a particular data set a continuous remote snapshot can be created. This means that after the transfer of the last snapshot completes, the next snapshot is created immediately. Depending on the size of the cluster, size of the volumes, amount of write operations and bandwidth of the link to the remote cluster, the time between snapshots can be from several seconds to several minutes.
This Backup/DR process can be implemented by the customer with external automation tools leveraging the StorPool REST-API or configured in the included snapshot/remote backup scheduling and retention module.
|
|
|
Remote Replication Granularity
Details
|
VM or Volume
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
Although DataCore SANsymphony uses block-storage, the platform is capable of attaining per VM-granularity if desired.
In Microsoft Hyper-V environments, when a VM with vdisks is created through SCVMM, DataCore can be instructed to automatically carve out a Virtual Disk (=storage volume) for every individual vdisk. This way there is a 1-to-1 alignment from end-to-end and snapshots can be created on the VM-level. The per-VM functionality is realized by installing the DataCore Storage Management Provider in SCVMM.
Because of the per-host storage limitations in VMware vSphere environments, VVols is leveraged to provide per VM-granularity. DataCore SANsymphony Provider v2.01 is VMware certified for ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
|
VR: VM
|
Per Volume (LUN)
Remote replication can be setup for an individual volume or a volume set containing multiple volumes.
StorPool detects and sends only the deltas, referring to the data that has been changed since the last succesful remote application run. Deltas are discovered by examining the metadata in RAM, so the remote replication mechanism is a very lightweight operation to the primary StorPool cluster.
|
|
|
Consistency Groups
Details
|
Yes
SANsymphony provides the option to use Virtual Disk Grouping to enable end-users to restore multiple Virtual Disks to the exact same point-in-time.
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
|
VR: No
Protection is on a per-VM basis only.
|
Yes
All snapshots in StorPool are crash-consistent. StorPool supports atomic snapshots of multiple volumes – e.g. all virtual disk of a VM can be snapshotted at a single point of time, providing consistent backup and restore for multi-disk systems.
The StorPool REST-API allows creating a snapshot of multiple volumes with a single call by specifying the names of the volumes. The snapshots created in this way store the respective volumes at exactly the same point in time thus preserving data consisteny across an application. There is no requirement to group volumes in advance.
|
|
|
|
VMware SRM (certified)
DataCore provides a certified Storage Replication Adapter (SRA) for VMware Site Recovery Manager (SRM). DataCore SRA 2.0 (SANsymphony 10.0 FC/iSCSI) shows official support for SRM 6.5 only. It does not support SRM 8.2 or 8.1.
There is no integration with Microsoft Azure Site Recovery (ASR). However, SANsymphony can be used with the control and automation options provided by Microsoft System Center (e.g. Operations Manager combined with Virtual Machine Manager and Orchestrator) to build a DR orchestration solution.
|
VMware SRM (certified)
VMware Interoperability Matrix shows official support for SRM 8.3.
|
N/A
StorPool does not provide any native DR orchestration tooling and is not supported by VMware Site Recovery Manager (SRM).
|
|
|
Stretched Cluster (SC)
Details
|
VMware vSphere: Yes (certified)
DataCore SANsymphony is certified by VMware as a VMware Metro Storage Cluster (vMSC) solution. For more information, please view https://kb.vmware.com/kb/2149740.
|
VMware vSphere: Yes (certified)
There is read-locality in place preventing sub-optimal cross-site data transfers.
vSAN 7.0 introduces redirection for all VM I/O from a capacity-strained site to the other site, untill the capacity is freed up. This feature improves the uptime of VMs.
|
Linux KVM: Yes
Stretched StorPool clusters are possible in both single-layer (compute+storage) deployments and dual-layer (storage-only) deployments.
Stretched clusters have very strict requirements with regard to latency and reliability of the network between cluster nodes. Stretched clusters are created on a case-by-case basis after examining the exact network properties.
|
|
|
|
2+sites = two or more active sites, 0/1 or more tie-breakers
Theoretically up to 64 sites are supported.
SANsymphony does not require a quorum or tie-breaker in stretched cluster configurations, but can be used as an optional component. The Virtual Disk Witness can provide a tie-breaker role if for instance redundant inter site paths are not implemented. The tie-breaker node (server or device) must be other than the two nodes presenting a virtual disk. Access to the Virtual Disk Witness is leading for storage node behavior.
There are 3 ways to configure the stretched cluster without any tie-breakers:
1. Default: in a split-brain scenario both sides stay active allowing upper infrastructure layers (OS/database/application) to make a decision (eg. clustering principles). In any case SANsymphony prevents a merge when there is a risk to data integrity, and the end-user has to make the choice on how to proceed next (which side is true)
2. Select one side to go inaccessible
3. Select both sides to go inaccessible.
|
3-sites: two active sites + tie-breaker in 3rd site
NEW
The use of the Stretched Cluster Witness Appliance automates failover decisions in order to avoid split-brain scenarios like network partitions and remote site failures. The witness is deployed as a VM within a third site.
vSAN 6.7 introduced the option to configure a dedicated VMkernel NIC for witness traffic. This enhances data security because witness traffic is isolated from vSAN data traffic.
vSAN 7.0 U1 introduces the vSAN Shared Witness. This feature allows end-user organizations to leverage a single Witness Appliance for up to 64 stretched clusters. This is especially useful in scenarios where many edge locations are involved. The size of the Witness Appliance determines the maximum number of cluster and components that can be managed.
|
2+sites = two or more active sites
A single StorPool cluster can be stretched to more than one physical location, provided there is high-bandwidth, low-latency connectivity between the nodes. Two, three, or more sites are possible. When a stretched cluster is designed, maintaining the cluster quorum in case of site or network failure is considered. This means that more than 50% of the storage nodes have to be available when such a failure occurs.
|
|
|
|
<=5ms RTT (targeted, not required)
RTT = Round Trip Time
In truth the user/app with the least tolerated write latency defines the acceptable RTT or distance. In practice
|
<=5ms RTT
|
<=1ms RTT (targeted, not required)
Typical use cases for StorPool are where high-performance storage with minimal latency is required. While StorPool can tolerate higher network latency this will inevitably impact the performance of the storage system with the added latency. In the typical use cases, latency between nodes is kept below 100 microseconds round-trip-time.
|
|
|
|
<=32 hosts at each active site (per cluster)
The maximum is per cluster. The SANsymphony solution can consist of multiple stretched clusters with a maximum of 64 nodes each.
|
<=15 nodes at each active site
For Dell EMC VxRail the minimum stretched cluster configuration is 3+3+1, meaning 3 nodes on the first site, 3 nodes on the second site and 1 tie-breaker VM on a third site. The maximum stretched cluster configuration is 15+15+1, meaning 15 nodes on the first site, 15 nodes on the second site and 1 tie-breaker VM on a third site.
|
<=32 nodes in each site part of a synchronous stretched cluster configuration
Maximum number of nodes per cluster is 63, max 64 clusters in federation.
Two different technologies can be used to deploy a storage system over multiple sites.
The first is a simple stretched cluster where nodes of one cluster are installed at different sites. This requires persistent reliable low-latency connectivity between all nodes. This is used in small deployments, typically with 3 sites with 3, 6, or 9 nodes.
When a larger storage system is needed a 'federated' deployment is used. This is a federation of multiple storage clusters that can operate independently, but with a common namespace. This allows all clusters to operate like one large cluster. This mode allows up to 64 clusters with 63 nodes each. (The supported maximum is 4032 nodes = 64 clusters by 63 nodes). Depending on the specific requirement a single cluster or a federation of multiple clusters can be better.
|
|
|
SC Data Redundancy
Details
|
Replicas: 1N-2N at each active site
DataCore SANsymphony provides enhanced stretched cluster availability by offering local fault protection with In Pool Mirroring. With In Pool Mirroring you can choose to mirror the data inside the local Disk Pool as well as mirror the data across sites to a remote Disk Pool. In the remote Disk Pool data is then also mirrored. All mirroring happens synchronously.
1N-2N: With SANsymphony Stretched Clustering, there can be either 1 instance of the data at each site (no In Pool Mirroring) or 2 instances of the data a each site (In Pool RAID-1 Mirroring).
|
Replicas: 0-3 Replicas (1N-4N) at each active site
Erasure Coding: RAID5-6 at each active site
VMware vSAN 6.6 and up provide enhanced stretched cluster availability with Local Fault Protection. You can provide local fault protection for virtual machine objects within a single site in a stretched cluster. You can define a Primary level of failures to tolerate for the cluster, and a Secondary level of failures to tolerate for objects within a single site. When one site is unavailable, vSAN maintains availability with local redundancy in the available site.
In the case of stretched clustering, selecting 0 replicas means that there is only one instance of the data available at each of the active sites.
Local Fault Protection is only available in the Enterprise edition of vSAN.
|
Replicas: 1N-2N at each active site
Although two-way replication (2N) is supported, it is recommended only in limited use cases due to the lower data protection level.
Stretched clusters behave exactly the same as non-stretched clusters. Replication policies and data locality can be managed using Fault Sets and Placement Groups. Fault Sets can be defined to store copies of the data on nodes in different sites.
|
|
|
Data Services
|
|
|
|
|
|
|
Efficiency |
|
|
|
Dedup/Compr. Engine
Details
|
Software (integration)
NEW
SANsymphony provides integrated and individually selectable inline deduplication and compression. In addition, SANsymphony is able to leverage post-processing deduplication and compression options available in Windows 2016/2019 as an alternative approach.
|
All-Flash: Software
Hybrid: N/A
Deduplication and compression are only available in the VxRail All-Flash ('F') appliances.
|
N/A
StorPool Distributed Storage (StorPool) does not have any native deduplication and/or compression capabilities. StorPool has implemented only those space saving features that do not compromise storage performance or take significant amounts of RAM/CPU. This means performance is the primary consideration.
StorPool provides the following space saving features:
- thin provisioning;
- TRIM/discard;
- zeroes detection.
The measured level of space saving delivered by these features is up to 6 times (minimum measured gain is 2 times) for virtualized public/private environments.
|
|
|
Dedup/Compr. Function
Details
|
Efficiency (space savings)
Deduplication and compression can provide two main advantages:
1. Efficiency (space savings)
2. Performance (speed)
Most of the time deduplication/compression is primarily focussed on efficiency.
|
Efficiency (Space savings)
Deduplication and compression can provide two main advantages:
1. Efficiency (space savings)
2. Performance (speed)
Most of the time deduplication/compression is primarily focussed on efficiency.
|
N/A
StorPool Distributed Storage (StorPool) does not have any native deduplication and/or compression capabilities.
|
|
|
Dedup/Compr. Process
Details
|
Deduplication: Inline (post-ack)
Compression: Inline (post-ack)
Deduplication/Compression: Post-Processing (post process)
NEW
Deduplication can be performed in 4 ways:
1. Immediately when the write is processed (inline) and before the write is ackowledged back to the originator of the write (pre-ack).
2. Immediately when the write is processed (inline) and in parallel to the write being acknowledged back to the originator of the write (on-ack).
3. A short time after the write is processed (inline) so after the write is acknowleged back to the originator of the write - eg. when flushing the write buffer to persistent storage (post-ack)
4. After the write has been committed to the persistent storage layer (post-process).
The first and second methods, when properly integrated into the solution, are most likely to offer both performance and capacity benefits. The third and fourth methods are primarily used for capacity benefits only.
DataCore SANSymphony 10 PSP12 and above leverage both inline deduplication and compression, as well as post process deduplication and compression techniques.
With inline deduplication incoming writes first hit the memory cache of the primary host and are replicated to the cache of a secondary host in an un-deduplicated state. After the blocks have been written to both memory caches, the primary host acknowledges the writes back to the originator. Each host then destages the written blocks to the persistent storage layer. During destaging, written blocks are deduplicates and/or compressed.
Windows Server 2019 deduplication is performed outside of IO path (post-processing) and is multi-threaded to speed up processing and keep performance impact minimal.
|
All-Flash: Inline (post-ack)
Hybrid: N/A
Deduplication can be performed in 4 ways:
1. Immediately when the write is processed (inline) and before the write is ackowledged back to the originator of the write (pre-ack).
2. Immediately when the write is processed (inline) and in parallel to the write being acknowledged back to the originator of the write (on-ack).
3. A short time after the write is processed (inline) so after the write is acknowleged back to the originator of the write - eg. when flushing the write buffer to persistent storage (post-ack)
4. After the write has been committed to the persistent storage layer (post-process).
The first and second methods, when properly integrated into the solution, are most likely to offer both performance and capacity benefits. The third and fourth methods are primarily used for capacity benefits only.
|
N/A
StorPool provides the following space saving features:
- thin provisioning;
- TRIM/discard;
- zeroes detection.
Discard commands are initated by the user of the storage system.
Write operations containing zeroes are detected as early as possible and converted to a metadata-only write operation.
Thin provisioning is on all the time.
|
|
|
Dedup/Compr. Type
Details
|
Optional
NEW
By default, deduplication and compression are turned off. For both inline and post-process, deduplication and compression can be enabled.
For inline deduplication and compression the feature can be turned on per node. The entire node represents a global deduplication domain. Deduplication and compression work across pools and across vDisks. Individual pools can be selected to participate in capacity optimization. Either deduplication or compression or both can be selected per individual vDisk. Pools can host both capacity optimized and non-capacity optimized vDisks at the same time. The optional capacity optimization settings can be added/changed/removed during operation for each vDisk.
For post-processing the feature can be enabled per pool. All vDisks in that pool would be deduplicated and compressed. Each pool is an independent deduplication domain. This means only data in the pool is capacity optimized, but not across pools. Additionally, for post-processing capacity optimization can be scheduled so admins can decide when deduplication should run.
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
|
All-Flash: Optional
Hybrid: N/A
NEW
Compression occurs after deduplication and just before the data is actually written to the persisent data layer.
In vSAN 7.0 U1 and onwards there are three settings to choose from: 'None', 'Compression Only' or 'Deduplication'.
When choosing 'Compression only' deduplication is effectively disabled. This optimizes storage performance, resource usage as well as availability. When using 'Compression only' a single disk failing no longer impacts the entire disk group.
|
N/A
Data reduction features don’t have negative performance impact.
|
|
|
Dedup/Compr. Scope
Details
|
Persistent data layer
|
Persistent data layer
Deduplication and compression are not used for optimizing read/write cache.
|
N/A
StorPool Distributed Storage (StorPool) does not have any native deduplication and/or compression capabilities.
|
|
|
Dedup/Compr. Radius
Details
|
Pool (post-processing deduplication domain)
Node (inline deduplication domain)
NEW
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
For inline deduplication and compression raw physical disks are added to a capacity optimization pool. The entire node represents a global deduplication domain. Deduplication and compression work across pools and across vDisks. Individual pools can be selected to participate in capacity optimization.
The post-processing capability provided through Windows Server 2016/2019 is highly scalable and can be used with volumes up to 64 TB and files up to 1 TB in size. Data deduplication identifies repeated patterns across files on that volume.
|
Disk Group
Deduplication and compression is a cluster-wide setting and is performed within each disk group. Redundant copies of a block within the same disk group are reduced to one copy. However, redundant blocks across multiple disk groups are not deduplicated.
|
N/A
StorPool Distributed Storage (StorPool) does not have any native deduplication and/or compression capabilities.
|
|
|
Dedup/Compr. Granularity
Details
|
4-128 KB variable block size (inline)
32-128 KB variable block size (post-processing)
NEW
With inline deduplication and compression, the data is organized in 128 KB segments. Depending on the optimization setting, a write into such a segment first gets compressed (when compression is selected) and then a hash is generated. If the hash is unique, the 128 KB segment is written back and the hash is added to the deduplication hash-table. If the hash is not unique, the segment is referenced in the deduplication hash table and discarded. The smallest chunk in the segment can be 4 KB.
For post-processing the system leverages deduplication in Windows Server 2016/2019, files within a deduplication-enabled volume are segmented into small variable-sized chunks (32–128 KB), duplicate chunks are identified, and only a single copy of each chunk is physically stored.
|
4 KB fixed block size
vSANs deduplication algorithm utilizes a 4K-fixed block size.
|
N/A
StorPool Distributed Storage (StorPool) does not have any native deduplication and/or compression capabilities.
|
|
|
Dedup/Compr. Guarantee
Details
|
N/A
Microsoft provides the Deduplication Evaluation Tool (DDPEVAL) to assess the data in a particular volume and predict the dedup ratio.
|
N/A
Enabling deduplication and compression can reduce the amount of storage consumed by as much as 7x (7:1 ratio).
|
N/A
StorPool Distributed Storage (StorPool) does not have any native deduplication and/or compression capabilities.
|
|
|
|
Full (optional)
Data rebalancing needs to be initiated manually by the end-user. It depends on the specific use case and end-user environment if this makes sense. When end-users want to isolate new workloads and corresponding data on new nodes, data rebalancing is not used.
|
Full
Data can be redistributed evenly across all nodes in the cluster when a node is either added or removed.
For VMware vSAN data redistribution happens is two ways:
1. Automated: when physical disks are between 30% and 80% full and a node is added to the vSAN cluster, a health alert is generated that allows the end-user to execute an automated data rebalancing run. For this VMware uses the term 'proactive'.
2. Automatic: when physical disks are more than 80% full, vSAN executes an data rebalancing fully automatically, without requiring any user intervention. For this VMware uses the term 'reactive'.
As data is written, all nodes in the cluster service RF copies even when no VMs are running on the node which ensures data is being distributed evenly across all nodes in the cluster.
VMware vSAN 6.7 U3 includes proactive rebalancing enhancements. All rebalancing activities can be automated with cluster-wide configuration and threshold settings. Prior to this release, proactive rebalancing was manually initiated after being alerted by vSAN health checks.
|
Full
When one or more nodes or drives are added or removed from the cluster, data is automatically redistributed evenly across all available nodes and drives.
|
|
|
|
Yes
DataCore SANsymphonys Auto-Tiering is a real-time intelligent mechanism that continuously positions data on the appropriate class of storage based on how frequently the data is accessed. Auto-Tiering leverages any combination of Flash and traditional disk technologies, whether it is internal or array based, with up to 15 different storage tiers that can be defined.
As more advanced storage technologies become available, existing tiers can be modified as necessary and additional tiers can be added to further diversify the tiering architecture.
|
N/A
The VMware vSAN storage architecture does not include multiple persistent storage layers, but rather consist of a caching layer (fastest storage devices) and a persistent layer (slower/most cost-efficient storage devices).
|
Yes
Volumes can be moved online (no service interruption) between storage tiers and disk pools.
|
|
|
|
Performance |
|
|
|
|
vSphere: VMware VAAI-Block (full)
Hyper-V: Microsoft ODX; Space Reclamation (T10 SCSI UNMAP)
DataCore SANsymphony iSCSI and FC are fully qualified for all VMware vSphere VAAI-Block capabilities that include: Thin Provisioning, HW Assisted Locking, Full Copy, Block Zero
Note: DataCore SANsymphony does not support Thick LUNs.
DataCore SANsymphony is also fully qualified for Microsoft Hyper-V 2012 R2 and 2016/2019 ODX and UNMAP/TRIM.
Note: ODX is not used for files smaller than 256KB.
VAAI = VMware vSphere APIs for Array Integration
ODX = Offloaded Data Transfers
UNMAP/TRIM support allows the Windows operating system to communicate the inactive block IDs to the storage system. The storage system can wipe these unused blocks internally.
|
vSphere: Integrated
VMware vSAN is an integral part of the VMware vSphere platform and as such is not a separate storage platform.
VMware vSAN 6.7 adds TRIM/UNMAP support: space that is no longer used can be automatically reclaimed, reducing the overall capacity needed for running workloads.
|
OpenNebula, OnApp, OpenStack, CloudStack
StorPool has deep integrations with OpenNebula, OnApp, OpenStack, CloudStack and other cloud orchestration platforms. Cloning and snapshotting are performed in the StorPool storage system and offloaded from the cloud orchestration platform.
SCSI UNMAP is supported for block device driver and iSCSI.
|
|
|
|
IOPs and/or MBps Limits
QoS is a means to ensure specific performance levels for applications and workloads. There are two ways to accomplish this:
1. Ability to set limitations to avoid unwanted behavior from non-critical clients/hosts.
2. Ability to set guarantees to ensure service levels for mission-critical clients/hosts.
SANsymphony currently supports only the first method. Although SANsymphony does not provide support for the second method, the platform does offer some options for optimizing performance for selected workloads.
For streaming applications which burst data, it’s best to regulate the data transfer rate (MBps) to minimize their impact. For transaction-oriented applications (OLTP), limiting the IOPs makes most sense. Both parameters may be used simultaneously.
DataCore SANsymphony ensures that high-priority workloads competing for access to storage can meet their service level agreements (SLAs) with predictable I/O performance. QoS Controls regulate the resources consumed by workloads of lower priority. Without QoS Controls, I/O traffic generated by less important applications could monopolize I/O ports and bandwidth, adversely affecting the response and throughput experienced by more critical applications. To minimize contention in multi-tenant environments, the data transfer rate (MBps) and IOPs for less important applications are capped to limits set by the system administrator. QoS Controls enable IT organizations to efficiently manage their shared storage infrastructure using a private cloud model.
More information can be found here: https://docs.datacore.com/SSV-WebHelp/quality_of_service.htm
In order to achieve consistent performance for a workload, a separate Pool can be created where selected vDisks are placed. Alternatively 'Performance Classes' can be assigned to differentiate between data placement of multiple workloads.
|
IOPs Limits (maximums)
QoS is a means to ensure specific performance levels for applications and workloads. There are two ways to accomplish this:
1. Ability to set limitations to avoid unwanted behavior from non-critical VMs.
2. Ability to set guarantees to ensure service levels for mission-critical VMs.
The vSAN software inside VxRail currently supports only the first method and focusses on IOPs. 'MBps Limits' cannot be set. It is also not possible to guarantee a certain amount of IOPs for any given VM.
|
IOPs and/or MBps Limits
Fair-sharing (built-in)
QoS is a means to ensure specific performance levels for applications and workloads. There are two ways to accomplish this:
1. Ability to set limitations to avoid unwanted behavior from non-critical VMs.
2. Ability to set guarantees to ensure service levels for mission-critical VMs.
StorPool supports only the first method currently and focusses on setting IOPS and MB/s limits per volume. It is not possible to guarantee a certain amount of IOPS for any given volume, unless all volumes in the system are IOPS-limited.
Furthermore, in StorPool there is built-in fairness between volumes. There are no privileged volumes and all IOPS operations are completed as fast as possible.
The QoS in StorPool is achieved by templates by which it is possible to set various limitations (IOPS and MB/s) for volumes.
StorPool Distributed Storage can apply hard limits on IOPS and bandwidth (MB/s) per volume. For example, if there are 10 virtual machines (VMs) connected to 10 virtual disks, you can configure IOPS and MB/s QoS limits for all 10 virtual disks. As long as there is sufficient storage/network capacity to handle the total IOPS and MB/s set for all the virtual disks, StorPool Distributed Storage fairly shares the available storage/network resources between the volumes. However, if components of the network equipment or underlying hardware used for storage fail, StorPool cannot guarantee that these limits will be kept.
Next to IOPS and MB/s StorPool provides volume-based QoS settings for Size, # of replicas and data placement policy.
|
|
|
|
Virtual Disk Groups and/or Host Groups
SANsymphony QoS parameters can be set for individual hosts or groups of hosts as well as for groups of Virtual Disks for fine grained control.
In a VMware VVols (=Virtual Volumes) environment a vDisk corresponds 1-to-1 to a virtual disk (.vmdk). Thus virtual disks can be placed in a Disk Group and a QoS Limit can then be assigned it. DataCore SANsymphony Provider v2.01 has VVols certification for VMware ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
In Microsoft Hyper-V environments, when a VM with vdisks is created through SCVMM, DataCore can be instructed to automatically carve out a Virtual Disk (=storage volume) for every individual vdisk. This way there is a 1-to-1 alignment from end-to-end and QoS Limits can be applied on the virtual disk level. The 1-to-1 allignment is realized by installing the DataCore Storage Management Provider in SCVMM.
|
Per VM/Virtual Disk
Quality of Service (QoS) for vSAN is normalized to a 32KB block size, and treats reads the same as writes.
|
Per volume
Per vdisk (CMPs)
Because StorPool presents block-based storage volumes, QoS Policies can be applied to VMware datastores as well as Raw Device Mappings (RDMs). This also extends to individual vdisks when Cloud Management Platforms (eg. OpenNebula, OpenStack, CloudStack, and OnApp) are leveraged. For a demonstration of this please view: https://www.youtube.com/watch?v=WZ6UggyVEfg
|
|
|
|
Per VM/Virtual Disk/Volume
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
In SANsymphony 'Flash Pinning' can be achieved using one of the following methods:
Method #1: Create a flash-only pool and migrate the individual vDisks that require flash pinning to the flash-only pool. When using a VVOL configuration in a VMware environment, each vDisk represents a virtual disk (.vmdk). This method guarantees all application data will be stored in flash.
Method #2: Create auto-tiering pools with at least 1 flash tier. Assign the Performance Class “Critical” to the vDisks that require flash pinning and place them in the auto-tiering pool. This will effectively and intelligently put as much of the data that resides in the vDisk in the flash tier as long that the flash tier has enough space available. Therefore this method is on a best-effort basis and dependent on correct sizing of the flash tier(s).
Methods #1 and #2 can be uses side-by-side in the same DataCore environment.
|
Cache Read Reservation: Per VM/Virtual Disk
With VxRail the Cache Read Reservation policy for a particular VM can be set to 100% to allow all data to also exist entirely on the flash layer. The difference with Nutanix 'VM Flash Mode' is, that with 'VM Flash Mode' persistent data of the VM resides on Flash and is never destaged to spinning disks. In contrast, with VxRails Cache Read Reservation data exists twice: one instance on persistent magnetic disk storage and one instance within the SSD read cache.
|
Yes
Every volume(LUN) can be dynamically re-assigned to different performance tiers.
Every volume in StorPool is associated to a 'template'. The template specifies the replication level, which drive pools (aka placement groups) and default IOPS and MB/s limits. Multiple templates can be configured in a StorPool storage system. For example one template could be created for a NVMe storage pool, another template could be for a SSD-HDD hybrid pool (with 1-2 copies on SSDs and 1-2 copies on HDDs) and yet another template could be for HDD-only storage.
A volume can be moved between templates online, without interrupting the storage service. In most cases a volume (LUN) in StorPool corresponds to one virtual disk of a VM or one persistent volume of a container/pod.
Drive pools (placement groups) can be changed online, without interrupting the service, for example to add or remove storage nodes and individual drives (SSDs, HDDs) from them. Templates can also be changed to refer to different drive pools. For example if the user decides that a large group of volumes needs to be moved to different media.
|
|
|
|
Security |
|
|
|
Data Encryption Type
Details
|
Built-in (native)
SANsymphony 10.0 PSP9 introduced native encryption when running on Windows Server 2016/2019.
|
Built-in (native)
|
N/A
StorPool does not have native data encryption capabilities. Adding data encryption capabilities requires encryption storage hardware.
|
|
|
Data Encryption Options
Details
|
Hardware: Self-encrypting drives (SEDs)
Software: SANsymphony Encryption
Hardware: In SANsymphony deployments the encryption data service capabilities can be offloaded to hardware-based SED offerings available in server- and storage solutions.
Software: SANsymphony provides software-based data-at-rest encryption that is XTS-AES 256bit compliant.
|
Hardware: N/A
Software: vSAN data encryption; HyTrust DataControl (validated)
NEW
Hardware: vSAN does no longer support self-encrypting drives (SEDs).
Software: vSAN supports native data-at-rest encryption of the vSAN datastore. When encryption is enabled, vSAN performs a rolling reformat of every disk group in the cluster. vSAN encryption requires a trusted connection between vCenter Server and a key management server (KMS). The KMS must support the Key Management Interoperability Protocol (KMIP) 1.1 standard. In contrast, vSAN native data-in-transit encryption does not require a KMS server. vSAN native data-at-rest and data-in-transit encryption are only available in the Enterprise edition.
vSAN encryption has been validated for the Federal Information Processing Standard (FIPS) 140-2 Level 1.
VMware has also validated the interoperability of HyTrust DataControl software encryption with its vSAN platform.
|
Hardware: Self-encrypting drives (SEDs)
Software: N/A
Hardware: In StorPool deployments the encryption data service capabilities can be offloaded to hardware-based SED offerings available in server- and storage solutions.
|
|
|
Data Encryption Scope
Details
|
Hardware: Data-at-rest
Software: Data-at-rest
Hardware: SEDs provide encryption for data-at-rest; SEDs do not provide encryption for data-in-transit.
Software: SANsymphony provides encryption for data-at-rest; it does not provide encryption for data-in-transit. Encryption can be enabled per individual virtual disk.
|
Hardware: N/A
Software vSAN: Data-at-rest + Data-in-transit
Software Hytrust: Data-at-rest + Data-in-transit
NEW
Hardware: N/A
Software: VMware vSAN 7.0 U1 encryption provides enhanced security for data on a drive as well as data in transit. Both are optional and can be enabled seperately. HyTrust DataControl encryption also provides encryption for data-at-rest and data-in-transit.
|
Hardware: Data-at-rest
Software: N/A
Hardware: SEDs provide encryption for data-at-rest; SEDs do not provide encryption for data-in-transit.
|
|
|
Data Encryption Compliance
Details
|
Hardware: FIPS 140-2 Level 2 (SEDs)
Software: FIPS 140-2 Level 1 (SANsymphony)
FIPS = Federal Information Processing Standard
FIPS 140-2 defines four levels of security:
Level 1 > Basic security requirements are specified for a cryptographic module (eg. at least one Approved algorithm or Approved security function shall be used).
Level 2 > Also has features that show evidence of tampering.
Level 3 > Also prevents the intruder from gaining access to critical security parameters (CSPs) held within the cryptographic module.
Level 4 > Provides a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.
|
Hardware: N/A
Software: FIPS 140-2 Level 1 (vSAN); FIPS 140-2 Level 1 (HyTrust)
FIPS = Federal Information Processing Standard
FIPS 140-2 defines four levels of security:
Level 1 > Basic security requirements are specified for a cryptographic module (eg. at least one Approved algorithm or Approved security function shall be used).
Level 2 > Also has features that show evidence of tampering.
Level 3 > Also prevents the intruder from gaining access to critical security parameters (CSPs) held within the cryptographic module.
Level 4 > Provides a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.
|
Hardware: FIPS 140-2 Level 2 (SEDs)
Software: N/A
FIPS = Federal Information Processing Standard
FIPS 140-2 defines four levels of security:
Level 1 > Basic security requirements are specified for a cryptographic module (eg. at least one Approved algorithm or Approved security function shall be used).
Level 2 > Also has features that show evidence of tampering.
Level 3 > Also prevents the intruder from gaining access to critical security parameters (CSPs) held within the cryptographic module.
Level 4 > Provides a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.
|
|
|
Data Encryption Efficiency Impact
Details
|
Hardware: No
Software: No
Hardware: Because data encryption is performed at the end of the write path, storage efficiency mechanisms are not impaired.
Software: Because data encryption is performed at the end of the write path, storage efficiency mechanisms are not impaired.
|
Hardware: N/A
Software: No (vSAN); Yes (HyTrust)
Hardware: N/A
Software vSAN: Because data encryption is performed at the end of the write path, storage efficiency mechanisms are not impaired.
Software Hytrust: Because HyTrust DataControl is an end-to-end solution, encryption is performed at the start of the write path and some efficiency mechanisms (eg. deduplication and compression) are effectively negated.
|
Hardware: No
Software: N/A
Hardware: Because data encryption is performed at the end of the write path, storage efficiency mechanisms are not impaired.
|
|
|
|
Test/Dev |
|
|
|
|
Yes
Support for fast VM cloning via VMware VAAI and Microsoft ODX.
|
No
Dell EMC VxRail does not include fast cloning capabilities.
Cloning operations actually copy all the data to provide a second instance. When cloning a running VM on VxRail, all the VMDKs on the source VM are snapshotted first before cloning them to the destination VM.
|
Yes
|
|
|
|
Portability |
|
|
|
Hypervisor Migration
Details
|
Hyper-V to ESXi (external)
ESXi to Hyper-V (external)
VMware Converter 6.2 supports the following Guest Operating Systems for VM conversion from Hyper-V to vSphere:
- Windows 7, 8, 8.1, 10
- Windows 2008/R2, 2012/R2 and 2016
- RHEL 4.x, 5.x, 6.x, 7.x
- SUSE 10.x, 11.x
- Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS
- CentOS 6.x, 7.0
The VMs have to be in a powered-off state in order to be migrated across hypervisor platforms.
Microsoft Virtual Machine Converter (MVMC) supports conversion of VMware VMs and vdisks to Hyper-V VMs and vdisks. It is also possible to convert physical machines and disks to Hyper-V VMs and vdisks.
MVMC has been offcially retired and can only be used for converting VMs up to version 6.0.
Microsoft System Center Virtual Machine Manager (SCVMM) 2016 also supports conversion of VMs up to version 6.0 only.
|
Hyper-V to ESXi (external)
VMware Converter 6.2 supports the following Guest Operating Systems for VM conversion from Hyper-V to vSphere:
- Windows 7, 8, 8.1, 10
- Windows 2008/R2, 2012/R2 and 2016
- RHEL 4.x, 5.x, 6.x, 7.x
- SUSE 10.x, 11.x
- Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS
- CentOS 6.x, 7.0
The VMs have to be in a powered-off state in order to be migrated across hypervisor platforms.
|
Hyper-V/ESXi/XenServer to KVM (external)
Migration between hypervisors depends on the cloud orchestration platform or external tools.
StorPool provides free tools for migrating VMs with minimal downtime from Hyper-V, VMWare ESXi and XenServer to KVM.
|
|
|
|
File Services |
|
|
|
|
Built-in (native)
SANsymphony delivers out-of-box (OOB) file services by leveraging Windows native SMB/NFS and Scale-out File Services capabilities. SANsymphony is capable of simultaneously handling highly-available block and file level services.
Raw storage is provisioned from within the SANsymphony GUI to the Microsoft file services layer, similar to provisioning Storage Spaces Volumes to the file services layer. This means any file services configuration is performed from within the respective Windows service consoles e.g. quotas.
More information can be found under: https://www.datacore.com/products/features/high-availability-nas-cluster-file-sharing.aspx
|
Built-in (native)
External (vSAN Certified)
NEW
vSAN 7.0 U1 has integrated file services. vSAN File Services leverages scale-out architecture by deploying an Agent/Appliance VM (OVF templates) on individual ESXi hosts. Within each Agent/Appliance VM a container, or “protocol stack”, is running. The 'protocol stack' creates a file system that is spread across the VMware vSAN Virtual Distributed File System (VDFS), and exposes the file system as an NFS file share. The file shares support NFSv3, NFSv4.1, SMBv2.1 and SMBv3 by default. A file share has a 1:1 relationship with a VDFS volume and is formed out of vSAN objects. The minimum number of containers that need to be deployed is 3, the maximum 32 in any given cluster. vSAN 7.0 Files Services are deployed through the vSAN File Service wizard.
vSAN File Services currenty has the following restrictions:
- not supported on 2-node clusters,
- not supported on stretched clusters,
- not supported in combination with vLCM (vSphere Lifecycle Manager),
- it is not supported to mount the NFS share from your ESXi host,
- no integration with vSAN Fault Domains.
The alternative to vSAN File Services is to provide file services through Windows guest VMs (SMB) and/or Linux guest VMs (NFS) on top of vSAN. These file services can be made highly available by using clustering techniques.
Another alternative is to use virtual storage appliances from a third-party to host file services on top of vSAN. The following 3rd party File Services partner products are certified with vSAN 6.7:
- Cohesity DataPlatform 6.1
- Dell EMC Unity VSA 4.4
- NetApp ONTAP Select vNAS 9.5
- Nexenta NexentaStor VSA 5.1.2 and 5.2.0VM
- Panzura Freedom Filer VSA 7.1.9.3
However, none of the mentioned platforms have been certified for vSAN 7.0 or 7.0U1 (yet).
|
N/A
StorPool does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Compatibility
Details
|
Windows clients
Linux clients
Because SANsymphony leverages Windows Server native CIFS/NFS and Scale-out File services, most Windows and Linux clients are able to connect.
|
Windows clients
Linux clients
NEW
vSAN 7.0 U1 File Services supports all client platforms that support NFS v3/v4.1 or SMB v2.1/v3. This includes traditional use cases as well as persistent volumes for Kubernetes on vSAN datastores.
vSAN 7.0 U1 File Services supports Microsoft Active Directory and Kerberos authentication for NFS.
VMware does not support leveraging vSAN 7.0 U1 File Services file shares as NFS datastores on which VMs can be stored and run.
|
N/A
StorPool does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Interconnect
Details
|
SMB
NFS
Because SANsymphony leverages Windows Server native CIFS/NFS and Scale-out File services, Windows Server platform compatibility applies:
SMB versions1,2 and 3 are supported, as are NFS versions 2, 3 and 4.1.
|
SMB
NFS
NEW
vSAN 7.0 U1 File Services supports all client platforms that support NFS v3/v4.1 or SMB v2.1/v3. This includes traditional use cases as well as persistent volumes for Kubernetes on vSAN datastores.
vSAN 7.0 U1 File Services supports Microsoft Active Directory and Kerberos authentication for NFS.
VMware does not support leveraging vSAN 7.0 U1 File Services file shares as NFS datastores on which VMs can be stored and run.
|
N/A
StorPool does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Quotas
Details
|
Share Quotas, User Quotas
Because SANsymphony leverages Windows Server native CIFS/NFS and Scale-out File services, all Quota features available in Windows Server can be used.
|
Share Quotas
vSAN 7.0 File Services supports share quotas through the following settings:
- Share warning threshold: When the share reaches this threshold, a warning message is displayed.
- Share hard quota: When the share reaches this threshold, new block allocation is denied.
|
N/A
StorPool does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Analytics
Details
|
Partial
Because SANsymphony leverages Windows Server native CIFS/NFS, Windows Server built-in auditing capabilities can be used.
|
Partial
vSAN 7.0 File Services provide some analytics capabilities:
- Amount of capacity consumed by vSAN File Services file shares,
- Skyline health monitoring with regard to infrastructure, file server and shares.
|
N/A
StorPool does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
|
Object Services |
|
|
|
Object Storage Type
Details
|
N/A
DataCore SANsymphony does not provide any object storage serving capabilities of its own.
|
N/A
Dell EMC VxRail does not provide any object storage serving capabilities of its own.
|
N/A
StorPool does not provide any object storage serving capabilities of its own.
Inside a Guest VM an object storage service could be leveraged to provide these services to the clients.
|
|
|
Object Storage Protection
Details
|
N/A
DataCore SANsymphony does not provide any object storage serving capabilities of its own.
|
N/A
VMware vSAN does not provide any object storage serving capabilities of its own.
|
N/A
StorPool does not provide any object storage serving capabilities of its own.
Inside a Guest VM an object storage service could be leveraged to provide these services to the clients.
|
|
|
Object Storage LT Retention
Details
|
N/A
DataCore SANsymphony does not provide any object storage serving capabilities of its own.
|
N/A
Dell EMC VxRail does not provide any object storage serving capabilities of its own.
|
N/A
StorPool does not provide any object storage serving capabilities of its own.
Inside a Guest VM an object storage service could be leveraged to provide these services to the clients.
|
|
|
Management
|
|
|
|
|
|
|
Interfaces |
|
|
|
GUI Functionality
Details
|
Centralized
SANsymphonys graphical user interface (GUI) is highly configurable to accommodate individual preferences and includes guided wizards and workflows to simplify administration. All actions available from the GUI may also be scripted with PowerShell Commandlets to orchestrate workflows with other tools and applications.
|
Centralized
Management of the vSAN software, capacity monitoring, performance monitoring and efficiency reporting can be performed through the vSphere Web Client interface.
Other functionality such as backups and snapshots are also managed from the vSphere Web Client Interface.
|
Centralized
StorPool provides a dashboard with a high-level view of the cluster status, real time statistics as well as information about the components, services and resources.
For all counters both real time data and historic data is captured; data is stored with up to 1 second granularity.
The information is provided through StorPools REST-API and short historical data is captured in the GUI.
The following information can be found in the StorePool Management GUI:
- Real-time at-a-glance status
- Detailed status, list/filter volumes, snapshots, etc.
- Performance Statistics
|
|
|
|
Single-site and Multi-site
|
Single-site and Multi-site
Centralized management of multicluster environments can be performed through the vSphere Web Client by using Enhanced Linked Mode.
Enhanced Linked Mode links multiple Dell EMCnter Server systems by using one or more Platform Services Controllers. Enhanced Linked Mode enables you to log in to all linked Dell EMCnter Server systems simultaneously with a single user name and password. You can view and search across all linked Dell EMCnter Server systems. Enhanced Linked Mode replicates roles, permissions, licenses, and other key data across systems. Enhanced Linked Mode requires the Dell EMCnter Server Standard licensing level, and is not supported with Dell EMCnter Server Foundation or Dell EMCnter Server Essentials.
|
Single-site and Multi-site (read-only)
The GUI is capable of displaying data from different StorPool clusters. The data is read-only as the GUI is currently not for management purposes.
|
|
|
GUI Perf. Monitoring
Details
|
Advanced
SANsymphony has visibility into the performance of all connected devices including front-end channels, back-end channels, cache, physical disks, and virtual disks. Metrics include Read/write IOPs, Read/write MBps and Read/Write Latency at all levels. These metrics can be exported to the Windows Performance Monitoring (Perfmon) utility where other server parameters are being tracked.
The frequency at which performance metrics can be captured and reported on is configurable, real-time down to 1 second intervals and long term recording at 2 minutes granularity.
When a trend analysis is required, an end-user can simply enable a recording session to capture metrics over a longer period of time.
|
Advanced
NEW
Performance information can be viewed on the cluster level, the Host level and the VM level. Per VM there is also a view on backend performance. Performance graphs focus on IOPS, MB/s and Latency of Reads and Writes. Statistics for networking, resynchronization, and iSCSI are also included.
End-users can select saved time ranges in performance views. vSAN saves each selected time range when end-users run a performance query.
There is also a VMware vRealize Operations (vROps) Management Pack for vSAN that provides additional options for monitoring, managing and troubleshooting vSAN.
The vSphere 6.7 Client includes an embedded vRealize Operations (vROps) plugin that provides basic vSAN and vSphere operational dashboards. The vROps plugin does not require any additional vROps licensing. vRealize Operations within vCenter is only available in the Enterprise and Advanced editions of vSAN.
vSAN observer as of vSAN 6.6 is deprecated but still included. In its place, vSAN Support Analytics is provided to deliver more enhanced support capabilities, including performance diagnostics. Performance diagnostics analyzes previously executed benchmark tests. It detects issues, suggests remediation steps, and provides supporting performance graphs for further insight. Performance Diagnostics requires participation in the Customer Experience Improvement Program (CEIP).
vSAN 6.7 U3 introduced a vSAN CPU metric through the performance service, and provides a new command-line utility (vsantop) for real-time performance statistics of vSAN, similar to esxtop for vSphere.
vSAN 7.0 introduces vSAN Memory metric through the performance service and the API for measuring vSAN memory usage.
vSAN 7.0 U1 introduces vSAN IO Insight for investigating the storage performance of individual VMs. vSAN IO Insight generates the following performance statistics which can be viewed from within the vCenter console:
- IOPS (read/write/total)
- Throughput (read/write/total)
- Sequential & Random Throughput (sequential/random/total)
- Sequential & Random IO Ratio (sequential read IO/sequential write IO/sequential IO/random read IO/random write IO/random IO)
- 4K Aligned & Unaligned IO Ratio (4K aligned read IO/4K aligned write IO/4K aligned IO/4K unaligned read IO/4K unaligned write IO/4K unaligned IO)
- Read & Write IO Ratio (read IO/writeIO)
- IO Size Distribution (read/write)
- IO Latency Distribution (read/write)
|
Advanced
Real-time as well as historical data are available graphically, in a table format and through the REST-API interface. Data is available at different levels – aggregated for the storage cluster, per node, per client, per volume, per drive, per CPU. User defined queries and reports can be generated.
Some of the most important metrics are:
- CPU and memory - usage per service, node
- Per drive statstics - drive utilization, IOPS, bandwidth, busy/free time, ops latency, request size
- Per volume statistics - IOPS, bandwidth, latency, request size, queue size
- Network utilization - per node and per interface
- Per client load - CPU, memory, requests, latency, requests in flight, IOPS, bytes/sec
- Aggregated cluster metrics - IOPS, BW, latency, request in flight, used and available space
|
|
|
|
VMware vSphere Web Client (plugin)
VMware vCenter plug-in for SANsymphony
SCVMM DataCore Storage Management Provider
Microsoft System Center Monitoring Pack
DataCore offers deep integration with VMware vSphere and Microsoft Hyper-V, as well as their respective systems management tools, vCenter and System Center.
SCVMM = Microsoft System Center Virtual Machine Manager
|
VMware vSphere Web Client (integrated)
VxRail 4.7.300 adds full native vCenter plug-in support for all core day to day operations including physical views and Life Cycle Management (LCM).
VxRail 4.7.100 and up provide a VxRail Manager Plugin for VMware vCenter. The plugin replaces the VxRail Manager web interface. Also full VxRail event details are presented in vCenter Event Viewer.
vSAN 6.7 provides support for the HTML5-based vSphere Client that ships with vCenter Server. vSAN Configuration Assist and vSAN Updates are available only in the vSphere Web Client.
vSAN 6.6 and up provide integration with the vCenter Server Appliance. End-users can create a vSAN cluster as they deploy a vCenter Server Appliance, and host the appliance on that cluster. The vCenter Server Appliance Installer enables end-users to create a one-host vSAN cluster, with disks claimed from the host. vCenter Server Appliance is deployed on the vSAN cluster.
vSAN 6.6 and up also support host-based vSAN monitoring. This means end-users can monitor vSAN health and basic configuration through the ESXi host client. This also allows end-users to correct configuration issues at the host level.
|
OpenStack
CloudStack
OnApp
OpenNebula
Kubernetes
StorPool integrates with a number of private cloud platform interfaces.
StorPool does not integrate with the GUI of hypervisor platforms such as VMware and Hyper-V.
|
|
|
|
Programmability |
|
|
|
|
Full
Using DataCores native management console, Virtual Disk Templates can be leveraged to populate storage policies. Available configuration items: Storage profile, Virtual disk size, Sector size, Reserved space, Write-trough enabled/disabled, Storage sources, Preferred snapshot pool, Accelerator enabled/disabled, CDP enabled/disabled.
Virtual Disk Templates integrate with System Center Virtual Machine Manager (SCVMM), VMware Virtual Volumes (VVol) and OpenStack. Virtual Disk Templates are also fully supported by the REST-API allowing any third-party integration.
Using Virtual Volumes (VVols) defined through DataCore’s VASA provider, VMware administrators can self-provision datastores for virtual machines (VMs) directly from their familiar hypervisor interface. This is possible even for devices in the DataCore pool that don’t natively support VVols and never will, as SANsymphony can be used as a storage-virtualization layer for these devices/solutions. DataCore SANsymphony Provider v2.01 has VVols certification for VMware ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
Using Classifications and StoragePools defined through DataCore’s Storage Management Provider, Hyper-V administrators can self-provision virtual disks and pass-through LUNS for virtual machines (VMs) directly from their familiar SCVMM interface.
|
Full
Storage Policy-Based Management (SPBM) is a feature of vSAN that allows administrators to create storage profiles so that virtual machines (VMs) dont need to be individually provisioned/deployed and so that management can be automated. The creation of storage policies is fully integrated in the vSphere GUI.
|
Partial
StorPool does not provide a policy-based experience for every storage-related function, but offers an extensive REST-API/CLI instead.
|
|
|
|
REST-APIs
PowerShell
The SANsymphony REST-APIs library includes more than 200 new representational state transfer (REST) operations, so automation can be leveraged more extensively. RESTful interfaces are used by products such as Lenovo XClarity, Cisco Embedded Resource Manager and Dell OpenManage to manage infrastructure in the enterprise.
SANsymphony provides its own Powershell cmdlets.
|
REST-APIs
Ruby vSphere Console (RVC)
PowerCLI
Dell EMC VxRail 4.7.100 and up include RESTful API enhancements.
Dell EMC VxRail 4.7.300 and up provide full VxRail manager functionality using RESTful API.
|
REST-API
CLI
All StorPool Distributed Storage (StorPool) features are exposed through the JSON API and end-user organizations usually leverage bash/shell/other scripts to automate operational workflows.
|
|
|
|
OpenStack
OpenStack: The SANsymphony storage solution includes a Cinder driver, which interfaces between SANsymphony and OpenStack, and presents volumes to OpenStack as block devices which are available for block storage.
Datacore SANsymphony programmability in VMware vRealize Automation and Microsoft System Center can be achieved by leveraging PowerShell and the SANsymphony specific cmdlets.
|
OpenStack
VMware vRealize Automation (vRA)
OpenStack integration is achieved through VMware Integrated OpenStack v2.0
vRealize Automation 7 integration is achieved through vRA 7.0.
|
OpenStack
CloudStack
OnApp
OpenNebula
Kubernetes
OpenStack: StorPool storage solution provides Cinder block storage component to use the StorPool distributed storage as a backend for volumes of OpenStack.
CloudStack: StorPool deeply integrates with CloudStack and has a native driver in the host OS which provides block devices as raw disk images for qemu/KVM.
OnApp: StorPool provides and maintains integration with OnApp; each VM disk becomes a separate volume in the StorPool storage system. The integration replaces the traditional LVM layer in OnApp.
OpenNebula: StorPool enables OpenNebula to use a StorPool storage system for storing disk images by leveraging its native datastore driver.
Kubernetes - StorPool provides persistent volumes for bare-metal Kubernetes clusters through its CSI driver.
|
|
|
|
Full
The DataCore SANsymphony GUI offers delegated administration to secondary users through fine-grained Role-based Access Control (RBAC). The administrator is able to define Virtual Disk ownership as well as privileges associated with that particular ownership. Owners must have Virtual Disk privileges in an assigned role in order to perform operations on the virtual disk. Access can be very refined. For example, one owner may have the privilege to create a snapshot of a virtual disk, but not have the ability to serve or unserve the same virtual disk. Privilege sets define the operations that can be performed. For instance, in order for an owner to perform snapshot, rollback, or replication operations, they would require those privilege sets in an assigned role.
|
N/A (not part of VxRail license bundle)
VMware vSAN does not provide any end-user self service capabilities of its own.
A self service portal enables end-users to access a portal where they can provision and manage VMs from templates, eliminating administrator requests or activity.
Self-Service functionality can be enabled by leveraging VMware vRealize Automation (vRA). This requires a separate VMware license.
|
N/A
StorPool Distributed Storage (StorPool) does not provide any end-user self service capabilities of its own.
A self service portal enables end-users to access a portal where they can provision and manage VMs from templates, eliminating administrator requests or activity.
Self-Service functionality can be enabled by leveraging a Cloud Management Platform (CMP). When not using an open-source CMP, this requires separate licenses.
|
|
|
|
Maintenance |
|
|
|
|
Unified
All storage related features and functionality are built into the DataCore SANsymphony platform. The consolidation means, that only one product needs to be installed and upgraded and minimal dependencies exist with other software.
Integration with 3rd party systems (e.g. OpenStack, vSphere, System Center) are delivered seperately but are free-of-charge.
|
Partially Distributed
For a number of features and functions the vSAN software inside the VxRail appliances relies on other components that need to be installed and upgraded next to the core vSphere platform. Examples are Avamar Virtual Edition (AVE), vSphere Replication (VR) and RecoverPoint for VMs (RPVM). As a result some dependencies exist with other software.
|
Unified
All storage related features and functionality are built into the StorPool platform. The consolidation means, that only one product needs to be installed and upgraded and minimal dependencies exist with other software.
|
|
|
SW Upgrade Execution
Details
|
Rolling Upgrade (1-by-1)
Each SANsymphony update is packaged in an installation Wizard which contains a fully guided upgrade process. The upgrade process checks all system requirements and performs a system health before starting the upgrade process and before moving from one node to the next.
The user can also decide to upgrade a SANsymphony cluster manually and follow all steps that are outlined in the Release Notes.
|
Rolling Upgrade (1-by-1)
The Dell EMC VxRail Manager software provides one-click, non-disruptive patches and upgrades for the entire solution stack.
End-user organizations no longer need professional services for stretched cluster upgrades when upgrading from VxRail 4.7.300 to the next release.
vSAN 7.0 native File Services upgrades are also performed on a rolling basis. The file shares remain accessible during the upgrade as file server containers running on the virtual machines which are undergoing upgrade fail over to other virtual machines. During the upgrade some interruptions might be experienced while accessing the file shares.
|
Rolling Upgrade (1-by-1)
StorPool does in-service rolling upgrades: StorPool performs upgrades node-by-node while the workloads maintain accessible and storage operations keep on running. Usually the software upgrade does not impact performance noticeably.
|
|
|
FW Upgrade Execution
Details
|
Hardware dependent
Some server hardware vendors offer rolling upgrade options with their base software or with a premium software suite. With some other server vendors, BIOS and Baseboard Management Controller (BMC) updated have to be performed manually and 1-by-1.
DataCore provides integrated firmware-control for FC-cards. This means the driver automatically loads the required firmware on demand.
|
1-Click
The Dell EMC VxRail Manager software provides one-click, non-disruptive patches and upgrades for the entire solution stack.
VxRail 7.0 does not support vSphere Lifecycle Manager (vLCM); vLCM is disabled in VMware vCenter.
|
Hardware dependent
Some server hardware vendors offer rolling upgrade options with their base software or with a premium software suite. With some other server vendors, BIOS and Baseboard Management Controller (BMC) updated have to be performed manually and 1-by-1.
|
|
|
|
Support |
|
|
|
Single HW/SW Support
Details
|
No
With regard to DataCore SANsymphony as a software-only offering (SDS), DataCore does not offer unified support for the entire solution. This means storage software support (SANsymphony) and server hardware support are separate.
|
Yes
Dell EMC VxRail provides unified support for the entire native solution. This means Dell EMC is the single point-of-contact for both software and hardware issues. Prerequisite is that the separate VMware vSphere licenses have not been acquired through an OEM vendor.
|
Yes (limited)
There are bundles available at selected channel partners where the end-user organization can procure a complete hardware/software solution, eg.: https://s3s.eu/solutions/storpool
|
|
|
Call-Home Function
Details
|
Partial (HW dependent)
With regard to DataCore SANsymphony as a software-only offering (SDS), DataCore does not offer call-home for the entire solution. This means storage software support (SANsymphony) and server hardware support are separate.
|
Full
VxRail uses EMC Secure Remote Services (ESRS). ESRS maintains connectivity with the VxRail hardware components around the clock and automatically notifies EMC Support if a problem or potential problem occurs.
VxRail is also supported by Dell EMC Vision. Dell EMC Vision offers Multi-System Management, Health monitoring and Automated log collection for a multitude of products from the Dell EMC family.
|
Yes
StorPool has live monitoring enabled on StorPool Distributed Storage (StorPool) production clusters. StorPool reacts proactively on incidents to prevent issues. For example, if StorPool detects a drive failure or latency peaks, the impacted end-user organization is alerted or StorPool can step in to tackle the issue before it escalates. For end-user organizations that do not want StorPool to have full access to their clusters, StorPool aligns with these organizations and schedules updates and troubleshoots when there is an open support ticket.
|
|
|
Predictive Analytics
Details
|
Partial
Capacity Management: DataCore SANsymphony Analysis and Reporting supports depletion monitoring of the capacity, complements pool space threshold warnings by regularly evaluating the rate of capacity consumption and estimating when space will be depleted. The regularly updated projections give you a chance to add more storage to the pool before you run out of storage. It also helps you do a better job of capacity planning with fewer surprises. To help allocate costs, especially in private cloud and hosted cloud services, SANsymphony generates reports quantifying the storage resources consumed by specific hosts or groups of hosts. The reports tally several parameters.
Health Monitoring: A combination of system health checks and access to device S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) alerts help to isolate performance and disk problems before they become serious.
DataCore Insight Services (DIS) offers additional capabilites including log-analytics for predictive failure analysis and actionable insights - including hardware.
DIS also provides predictive capacity trend analysis in order to pro-actively warn about licensing limitations being reached within x days and/or disk pools running out of capacity.
|
Full (not part of VxRail license bundle)
vRealize Operations (vROps) provides native vSAN support with multiplay dashboards for proactive alerting, heat maps, device and cluster insights, and streamlined issue resolution. Also vROps provides forward trending and forecasting to vSAN datastore as well as any another datastore (SAN/NAS).
vSAN 6.7 introduced 'vRealize Operations (vROps) within vCenter'. This provides end users with 6 dashboards inside vCenter console, giving insights but not actions. Three of these dashboards relate to vSAN: Overview, Cluster View, Alerts. One of the widgets inside these dasboards displays 'Time remaining before capacity runs out'. Because this provides only some very basic trending information, a full version of the vROps product is still required.
'vRealize Operations (vROps) within vCenter' is included with vSAN Enterprise and vSAN Advanced.
The full version of vRealize Operations (vROps) is licensed as a separate product from VMware vSAN.
In June 2019 an early access edition (=technical preview) of VxRail Analytical Consulting Engine (ACE) was released to the public for test and evaluation purposes. VxRail ACE is a cloud service that runs in a Dell EMC secure data lake and provides infrastructure machine learning for insights that can be viewed by end-user organizations on a Dell EMC managed web portal. On-premises VxRail clusters send advanced telemetry data to VxRail ACE by leveraging the existing SRS secyure transport mechanism in order to provide the cloud platform with raw data input. VxRail ACE is built on Pivotal Cloud Foundry.
VxRail ACE provides:
- global vizualization across all VxRail clusters and vCenter appliances.
- simplified health scores at the cluster and node levels;
- advanced capacity and performance metrics charting so problem areas (CPU, memory, disk, networking) can be pinpointed up to the VM level;
- future capacity planning by analyzing the previous 180 days of storage use data, and projecting data usage for the next 90 days.
VxRail ACE supports VxRail 4.5.215 or later, as well as 4.7.0001 or later. Sending advanced telemetry data to VxRail ACE is optional and can be turned off. The default collection frequency is once every hour.
VxRail ACE is designed for extensibility so that future visibility between VxRail ACE and vRealize Operations Manager is possible.
Because VxRail ACE is not Generally Available (GA) at this time, it is not yet considered in the WhatMatrix evaluation/scoring mechanism.
|
Partial
As part of the the real-time monitoring system, automatic notifications are generated based on metrics that can predict hardware failures such as the increase of the read/write error rate or increased disk latency over time. Automatic notifications are also generated on storage depletion which covers almost-full states for individual disks.
|
|
