|
General
|
|
|
- Fully Supported
- Limitation
- Not Supported
- Information Only
|
|
Pros
|
- + Extensive platform support
- + Extensive data protection capabilities
- + Flexible deployment options
|
- + Built for performance and robustness
- + Broad range of hardware support
- + Well suited for open private cloud platforms
|
- + Built for simplicity
- + Policy-based management
- + Cost-effectiveness
|
|
Cons
|
- - No native data integrity verification
- - Dedup/compr not performance optimized
- - Disk/node failure protection not capacity optimized
|
- - Only basic support for VMware and Hyper-V
- - No native dedup capabilities
- - No native encryption capabilities
|
- - Single hypervisor support
- - No stretched clustering
- - No native file services
|
|
|
|
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: 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.
|
Name: Hyperconvergence (HC3)
Type: Hardware+Software (HCI)
Development Start: 2011
First Product Release: 2012
Scale Computing was founded in 2007 and began to ship its first SAN/NAS scale-out storage product, in 2009. Mid 2011 development started on the Hyperconvergence (HC3) platform, which was to combine the 3 foundation layers, being compute, storage and virtualization, into a single hardware appliance. HC3 was built to provide ultra simple ease-of-use and initially targeted at the SMB market. The first HC3 models were released in August 2012.
In Januari 2019 the company had an install base of more than 3,500 customers worldwide. In January 2019 there were 130+ employees working for Scale Computing.
|
|
|
|
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
|
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)
|
GA Release Dates:
HCOS 8.6.5: mar 2020
HCOS 8.5.3: oct 2019
HCOS 8.3.3: jul 2019
HCOS 8.1.3: mar 2019
HCOS 7.4.22: may 2018
HCOS 7.2.24: sep 2017
HCOS 7.1.11: dec 2016
HCOS 6.4.2: apr 2016
HCOS 6.0: feb 2015
HCOS 5.0: oct 2014
ICOS 4.0: aug 2012
ICOS 3.0: may 2012
ICOS 2.0: feb 2010
ICOS 1.0: feb 2009
NEW
8th Generation Scale Computing software on proven Lenovo and SuperMicro server hardware.
Scale Computing HC3s maturity has been steadily increasing ever since the first iteration by expanding its feature set with both foundational and advanced capabilities. Due to its primary focus on small- and midsized organizations, the feature set does not (yet) incorporate some of the larger enterprise capabilities.
HCOS = HyperCore Operating System
ICOS = Intelligent Clustered Operating System
|
|
|
|
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/
|
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.
|
Per Node
Each Scale Computing HC3 appliance purchased consists of hardware (server+storage), software (all-inclusive) and 1 year of premium support. Optionally end-users can also request for TOR-switches as part of the solution and deployment.
In june 2018 Scale Computing introduced an Managed Service Providers (MSP) Program that offers these organizations a price-per node, per-month, OpEx subscription license.
TOR = Top-of-Rack
|
|
|
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).
|
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.
|
Per Node (all-inclusive)
There is no separate software licensing. Each node comes equiped with an all-inclusive feature set. This means that without exception all Scale Computing HC3 software capabilities are available for use.
In june 2018 Scale Computing introduced an Managed Service Providers (MSP) Program that offers these organizations a price-per node, per-month, OpEx subscription license.
HC3 Cloud Unity DRaaS requires a monthly subscription that is in part based on Google Cloud Platform (GCP) resource usage (compute, storage, network). The HC3 Cloud Unity DRaaS subscription includes:
- 6 days of Active Mode testing
- Runbook outlining DR procedures
- 1 Runbook failover test and 1 separate Declaration
- Network egress equal to 12.5% of Storage
- ScaleCare Support
In addition end-users and first-time service providers can purchase a DR Planning Service (one-time fee) for onboarding.
|
|
|
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
|
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.
|
Per Node
Each appliance comes with 1 year ScaleCare Premium Support that consists of:
- 24x7x365 by telephone (US and Europe)
- 2 hour response time for critical issues
- Live chat, email support, and general phone on Mo-Fr 8AM-8PM EDST.
- Next Business Day (NBD) delivery of hardware replacement parts
ScaleCare Premium Support also provides remote installation services on the initial deployment of ScaleComputing HC3 clusters.
In june 2018 Scale Computing introduced an Managed Service Providers (MSP) Program that offers these organizations a price-per node, per-month, OpEx subscription license.
|
|
|
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.
|
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.
|
Hypervisor
Compute
Storage
Networking (optional)
Data Protection
Management
Automation&Orchestration
Scale Computing is stack-oriented.
With the HC3 platform Scale Computing aims to provide all functionality required in a Private Cloud ecosystem.
|
|
|
|
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.
|
Standard Ethernet 10/25/40/50/100 GbE
Infiniband (EoL)
StorPool Distributed Storage (StorPool) supports ethernet connectivity using 10 GbE or faster network.
|
1, 10 GbE
Scale Computing hardware models include redundant ethernet connectivity in an active/passive setup.
|
|
|
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
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.
|
Low
Scale Computing HC3 was developed with simplicity in mind, both from a design and a deployment perspective. The HC3 platform architecture is meant to be applicable to general virtual server infrastructure (VSI) use-cases and seeks to provide important capabilities natively. There are only a few storage building blocks to choose from, and many advanced capabilities like deduplication are always turned on. This minimizes the amount of design choices as well as the number of deployment steps.
|
|
|
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
|
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/
|
N/A
No Scale Computing HC3 validated test reports have been published in 2016/2017/2018/2019.
|
|
|
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/
|
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.
|
Public Facing Clusters
Proof-of-Concept (PoC)
|
|
|
|
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
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.
|
Single-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.
|
|
|
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 (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.
|
Turnkey (very fast; highly automated)
Because of the ready-to-go Hyper Converged Infrastructure (HCI) building blocks and the setup wizard provided by Scale Computing, customer deployments can be executed in hours instead of days.
|
|
|
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.
|
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.
|
KVM User Space
SCRIBE runs in KVM user space. Scale Computing made a conscious decision not to make SCRIBE kernel integrated in order to avoid the risk that storage problems would cause a system panic meaning that an entire node could go down as a result.
|
|
|
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.
|
KVM
VMware ESXi
Hyper-V
XenServer
OracleVM
|
Linux KVM-based
NEW
ScaleComputing HC3 uses its own proprietary HyperCore operating system and KVM-based hypervisor.
SCRIBE is an integral part of the Linux KVM platform to enable it to own the full software stack. As VMware and Microsoft dont allow such a tight integration, SCRIBE cannot be used with any other hypervisor platform.
Scale Computing HC3 supports a single hypervisor in contrast to other SDS/HCI products that support multiple hypervisors.
The Scale Computing HC3 hypervisor fully supports the following Guest operating systems:
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows 10
Windows 8.1
CentOS Enterprise Linux
RHEL Enterprise Linux
Ubuntu Server
FreeBSD
SUSE Linux Enterprise
Fedora
Versions supported are versions currently supported by the operating system manufacturer.
SCRIBE = Scale Computing Reliable Independent Block Engine
|
|
|
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
|
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.
|
Libscribe
In order to read/write from/to Scale Computing HC3 block devices (aka Virtual SCRIBE Devices or VSD for short) the Libscribe component needs to be installed in KVM on each physical host. Libscribe is part of the QEMU process and presents virtual block devices to the VM. Because Libscribe is a QEMU block driver, SCRIBE is a supported device type and qemu-img commands work by default.
Although a virtIO driver doesnt need to be installed perse in each VM, it is highly recommended as I/O performance benefits greatly from it. IO submission takes place via the Linux Native Asynchronous I/O (AIO) that is present in KVM.
Shared storage devices in virtual Windows Clusters are supported.
QEMU = Quick Emulator
|
|
|
|
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.
|
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.
|
N/A
Scale Computing HC3 does not support any non-hypervisor platforms.
|
|
|
Bare Metal Interconnect
Details
|
iSCSI
FC
FCoE
|
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.
|
N/A
Scale Computing HC3 does not support any non-hypervisor platforms.
|
|
|
|
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.
|
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
|
|
Container Platform Compatibility
Details
|
Docker CE/EE 18.03+
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
|
|
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.
|
Standard block devices
StorPool provides standard block devices that can be used by Docker containers as any other block device or SAN.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
|
|
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.
|
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
|
|
Container Host OS Compatbility
Details
|
Linux
All Linux versions supported by Docker CE/EE 18.03+ or higher can be used.
|
Linux
All Linux versions supported by Kubernetes.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
|
|
Container Orch. Compatibility
Details
|
Kubernetes 1.13+
|
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
|
|
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 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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
|
|
|
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
So far StorPool has not published any Reference Architecture whitepapers on VMware Horizon or Citrix XenDesktop.
|
Citrix XenDesktop
Parallels RAS
Leostream
Scale Computing HC3 HyperCore is a Citrix Ready platform. XenDesktop 7.6 LTSR, 7.8 and 7.9 are officially supported.
Scale Computing HC3 also actively supports the following desktop virtualization software:
- Parallels Remote Application Server (RAS);
- Leostream (=connection management).
A joint Reference Configuration white paper for Parallels RAS on Scale Computing HC3 was published in June 2019.
A joint Quick Start with Scale Computing HC3 and Leostream white paper was released in March 2019.
Since Scale Computing HC3 does not support the VMware vSphere hypervisor, VMware Horizon is not an option.
|
|
|
|
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.
|
N/A
StorPool has not published any VDI reference architecture whitepapers with LoginVSI benchmark numbers.
|
Workspot: 40 virtual desktops/node
Workspot VDI 2.0: Load bearing number is based on Login VSI tests performed on hybrid HC2150 appliances using 2vCPU Windows 7 desktops and the Knowledge Worker profile.
For detailed information please view the corresponding whitepaper. Please note that this technical whitepaper is dated August 2016 and that Workspot VDI 2.0 no longer exists. Workspots current portfolio only includes cloud solutions that run in Microsoft Azure.
Scale Computing has not published any Reference Architecture whitepapers for the Citrix XenDesktop platform.
|
|
|
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.
|
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).
|
Lenovo (native and OEM)
SuperMicro (native)
Scale Computing leverages both Lenovo and SuperMicro server hardware as building blocks for is native HC3 appliances:
HC1200 is Supermicro server hardware
HC1250 is Supermicro server hardware
HC1250D is Lenovo server hardware
HC1250DF is Lenovo server hardware
HC5250D is Lenovo server hardware
Scale Computing has maintained a partnership with MBX Systems since 2012. MBX Systems is a hardware integrator based in the US, with headquarters both in Chicago and San Jose, that is tasked with assembling the native HC3 appliances.
In May 2018 Scale Computing and Lenovo entered in an OEM partnership to provide Scale Computing HC3 software on Lenovo ThinkSystem tower (ST250) or rack servers (SR630, SR650, SR250) with a wide variety of hardware choices (eg. CPU and RAM).
|
|
|
|
Many
SANsymphony runs on all server hardware that supports x86 - 64bit.
DataCore provides minimum requirements for hardware resources.
|
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).
|
4 Native Models
NEW
There are 4 native model series to choose from:
HE100 Edge Computing/Remote offices, stores, warehouses, labs, classrooms, ships
HE500 Edge Computing/Small remote sites/DR
HC1200 SMB/Midmarket
HC5000 Enterprise/Distributed Enterprise
There are 4 Lenovo model series to choose from:
ST250 Edge, Backup
SR250 Edge
SR630 Mid-market
SR650 Mid-market, High Capacity
|
|
|
|
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, 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.
|
1 node per chassis
NEW
Scale Computing HE100 appliances are Intel NUCs.
Scale Computing HE500 appliances are either 1U building blocks or Towers.
Scale Computing HC1200 appliances are 1U building blocks.
Scale Computing HC5000 appliances are 2U building blocks.
Lenovo HC3 Edge ST250 appliances are Towers.
Lenovo HC3 Edge SR250 appliances are 1U building blocks.
Lenovo HC3 Edge SR630 appliances are 1U building blocks.
Lenovo HC3 Edge SR650 appliances are 2U building blocks.
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.
NUC = Next Unit of Computing
|
|
|
|
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
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.
|
Yes
Scale Computing allows for mixing different server hardware in a single HC3 cluster, including nodes from different generations.
|
|
|
|
Components |
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
Flexible
StorPool provides minimal hardware requirements in its StorPool Distributed Storage (StorPool) documentation.
|
Flexible: up to 3 options (native); extensive (Lenovo OEM)
Scale Computing HE100-series CPU options:
HE150: 1x Intel i3-10110U (2 cores); 1x Intel i5-10210U (4 cores); 1x i7-10710U (6 cores)
Scale Computing HE500-series CPU options:
HE500: 1x Intel Xeon E-2124 (4 cores); 1x Intel Xeon E-2134 (4 cores); 1x Intel Xeon E-2136 (6 cores)
HE550: 1x Intel Xeon E-2124 (4 cores); 1x Intel Xeon E-2134 (4 cores); 1x Intel Xeon E-2136 (6 cores)
HE550F: 1x Intel Xeon E-2124 (4 cores); 1x Intel Xeon E-2134 (4 cores); 1x Intel Xeon E-2136 (6 cores)
HE500T: 1x Intel Xeon E-2124 (4 cores); 1x Intel Xeon E-2134 (4 cores); 1x Intel Xeon E-2136 (6 cores)
HE550TF: 1x Intel Xeon E-2124 (4 cores); 1x Intel Xeon E-2134 (4 cores); 1x Intel Xeon E-2136 (6 cores)
Scale Computing HC1200-series CPU options:
HC1200: 1x Intel Xeon Bronze 3204 (6 cores); 1x Intel Xeon Silver 4208 (8 cores)
HC1250: 1x Intel Xeon Silver 4208 (8 cores); 2x Intel Xeon Silver 4210 (10 cores); 2x Intel Xeon Gold 6242 (16 cores)
HC1250D: 2x Intel Xeon Silver 4208 (8 cores); 2x Intel Xeon Silver 4210 (10 cores); 2x Intel Xeon Gold 6230 (20 cores); 2x Intel Xeon Gold 6242 (16 cores); 2x Intel Xeon Gold 6244 (8 cores)
HC1250DF: 2x Intel Xeon Silver 4208 (8 cores); 2x Intel Xeon Silver 4210 (10 cores); 2x Intel Xeon Gold 6230 (20 cores); 2x Intel Xeon Gold 6242 (16 cores); 2x Intel Xeon Gold 6244 (8 cores)
Scale Computing HC5000-series CPU options:
HC5200: 1x Intel Xeon Silver 4208 (8 cores); 1x Intel Xeon Silver 4210 (10 cores); 1x Intel Xeon Gold 6230 (20 cores)
HC5250D: 2x Intel Xeon Silver 4208 (8 cores); 2x Intel Xeon Silver 4210 (10 cores); 2x Intel Xeon Gold 6230 (20 cores); 2x Intel Xeon Gold 6242 (16 cores)
Scale Computing HC1200 and HC5000 series nodes ship with 2nd generation Intel Xeon Scalable (Cascade Lake) processors.
Lenovo HC3 Edge CPU options:
ST250: 1x Intel Xeon E-2100
SR250: 1x Intel Xeon E-2100
SR630: 2x 1st or 2nd generation Intel Xeon Scalable (Skylake or Cascade Lake)
SR650: 2x 1st or 2nd generation Intel Xeon Scalable (Skylake or Cascade Lake)
|
|
|
|
Flexible
|
Flexible
StorPool provides minimal hardware requirements in its StorPool Distributed Storage (StorPool) documentation.
|
Flexible: up to 8 options
Scale Computing HE100-series memory options:
HE150: 8GB, 16GB, 32GB, 64GB
Scale Computing HE500-series memory options:
HE500: 16GB, 32GB, 64GB
HE550: 16GB, 32GB, 64GB
HE550F: 16GB, 32GB, 64GB
HE500T: 16GB, 32GB, 64GB
HE500TF: 16GB, 32GB, 64GB
Scale Computing HC1200-series memory options:
HC1200: 64GB, 96GB, 128GB, 192GB, 256GB, 384GB
HC1250: 64GB, 96GB, 128GB, 192GB, 256GB, 384GB
HC1250D: 128GB, 192GB, 256GB; 384GB, 512GB, 768GB
HC1250DF: 128GB, 192GB, 256GB; 384GB, 512GB, 768GB
Scale Computing HC5000-series memory options:
HC5200: 64GB, 128GB, 192GB, 256GB; 384GB, 512GB, 768GB
HC5250D: 128GB, 192GB, 256GB; 384GB, 512GB, 768GB, 1TB, 1.5TB
Lenovo HC3 Edge series memory options:
ST250: 16GB - 64GB
SR250: 16GB - 64GB
SR630: 64GB - 768GB
SR650: 64GB - 1.5TB
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
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.
|
Capacity: up to 5 options (HDD, SSD)
Fixed: Number of disks
Scale Computing HE100-series storage options:
HE150: 1x 250GB/500GB/1TB/2TB M.2 NVMe
Scale Computing HE500-series storage options:
HE500: 4x 1/2/4/8TB NL-SAS [magnetic-only]
HE550: 1x 480GB/960GB SSD + 3x 1/2/4TB NL-SAS [hybrid]
HE550F: 4x 240GB/480GB/960GB SSD [all-flash]
HE500T: 4x 1/2/4/8TB NL-SAS + 8x 4/8TB NL-SAS [magnetic-only]
HE550TF: 4x 240GB/480GB/960GB SSD [all-flash]
Scale Computing HC1200-series storage options:
HC1200: 4x 1/2/4/8/12TB NL-SAS [magnetic-only]
HC1250: 1x 480GB/960GB/1.92TB/3.84TB/7.68TB SSD + 3x 1/2/4/8/12TB NL-SAS [hybrid]
HC1250D: 1x 960GB/1.92TB/3.84TB/7.68TB SSD + 3x 1/2/4/8TB NL-SAS [hybrid]
HC1250DF: 4x 960GB/1.92TB/3.84TB/7.68TB SSD [all-flash]
Scale Computing HC5000-series storage options:
HC5200: 12x 8/12TB NL-SAS [magnetic-only]
HC5250D: 3x 960GB/1.92TB/3.84TB/7.68TB SSD + 9x 4/8TB NL-SAS [hybrid]
Lenovo HC3 Edge series storage options:
ST250: 8x 1/2/4/8TB NL-SAS [magnetic only]
ST250: 4x 960GB/1.92TB/3.84TB SSD [all-flash]
SR250: 4x 1/2/4/8TB NL-SAS [magnetic only]
SR250: 1x 960GB/1.92TB/3.84TB SSD + 3x 1/2/4/8TB NL-SAS [hybrid]
SR250: 4x 960GB/1.92TB/3.84TB SSD [all-flash]
SR630: 4x 1/2/4/8TB NL-SAS [magnetic only]
SR630: 1x 480GB/960GB/1.92TB/3.84TB/7.68TB SSD + 3x 1/2/4/8TB NL-SAS [hybrid]
SR630: 4x 1.92TB/3.84TB/7.68TB SSD [all-flash]
SR650: 3x 480GB/960GB/1.92TB/3.84TB/7.68TB SSD + 9x 1/2/4/8TB NL-SAS [hybrid]
The SSDs in all mentioned nodes are normal SSDs (non-NMVe).
SATA = NL-SAS = 7.2k RPM = High-capacity low-speed drives
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
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.
|
Fixed: HC1200/5000: 10GbE; HE150/500T: 1GbE
Flexible: HE500: 1/10GbE
Scale Computing HE100-series networking options:
HE150: 1x 1GbE
Scale Computing HE500-series networking options:
HE500: 4x 1GbE or 4x 10GbE SFP+
HE550: 4x 1GbE or 4x 10GbE SFP+
HE550F: 4x 1GbE or 4x 10GbE SFP+
HE500T: 2x 1GbE
HE550TF: 2x 1GbE
Scale Computing HC1200-series networking options:
HC1200: 4x 10GbE Base-T/SFP+ bonded active/passive
HC1250: 4x 10GbE Base-T/SFP+ bonded active/passive
HC1250D: 4x 10GbE Base-T/SFP+ bonded active/passive
HC1250DF: 4x 10GbE Base-T/SFP+ bonded active/passive
Scale Computing HC5000-series networking options:
HC5200: 4x 10GbE Base-T/SFP+ bonded active/passive
HC5250D:4x 10GbE Base-T/SFP+ bonded active/passive
Lenovo HC3 Edge series networking options:
ST250: 2x 1GbE
SR250: 4x 1GbE or 4x 10GbE SFP+
SR630: 4x 10GbE BaseT or 4x 10GbE SFP+
SR650: 4x 10GbE BaseT or 4x 10GbE SFP+
|
|
|
|
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
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.
|
N/A
Scale Computing HC3 currently does not provide any GPUs options.
|
|
|
|
Scaling |
|
|
|
|
CPU
Memory
Storage
GPU
The SANsymphony platform allows for expanding of all server hardware resources.
|
CPU
Memory
Storage
GPU
The StorPool Distributed Storage platform allows for expanding of all server hardware resources.
|
CPU
Memory
The Scale Computing HC3 platform allows for expanding CPU and Memory hardware resources. Storage resources (the number of disks within a single node) are usually not expanded.
|
|
|
|
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.
|
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.
|
Storage+Compute
Storage-only
Storage+Compute: Existing Scale Computing HC3 clusters can be expanded by adding additional nodes, which adds additional compute and storage resources to the shared pool.
Compute-only: N/A; A Scale Computing HC3 node always takes active part in the hypervisor (compute) cluster as well as the storage cluster.
Storage-only: A Scale Computing HC3 node can be configured as a storage-only node by setting a flag and has to be performed by Scale Computing engineering (end-user organizations cannot set the flag themselves).
|
|
|
|
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-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.
|
3-8 nodes in 1-node increments
There is a maximum of 8 nodes within a single cluster. Larger clusters do exist, but must be requested and are evaluated on a per use-case basis.
|
|
|
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.
|
3 Node minimum
StorPools smallest deployment contains 3 nodes, albeit these could be small cost-efficient servers.
|
1 Node minimum
|
|
|
Storage Support
|
|
|
|
|
|
|
General |
|
|
|
|
Block Storage Pool
SANsymphony only serves block devices to the supported OS platforms.
|
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.
|
Block Storage Pool
Scale Computing HC3 only serves block devices to the supported OS guest platforms. VMs running on HC3 have direct, block-level access to virtual SCRIBE devices (VSDs, aka virtual disks) in the clustered storage pool without the complexity or performance overhead introduced by using remote storage protocols.
A critical software component of HyperCore is the Scale Computing Reliable Independent Block Engine, known as
SCRIBE. SCRIBE is an enterprise class, clustered block storage layer, purpose built to be consumed by the HC3 embedded KVM based hypervisor directly.
SCRIBE discovers and aggregates all block storage devices across all nodes of the system into a single managed pool of storage. All data written to this pool is immediately available for read and write by any and every node in the storage system, allowing for sophisticated data redundancy, data deduplication, and load balancing schemes to be used by higher layers of the stack—such as the HyperCore
compute layer.
SCRIBE is a wide-striped storage architecture that combines all disks in the cluster into a single storage pool that is tiered between flash SSD and spinning HDD storage.
|
|
|
|
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.
|
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.
|
None
Scale Computing HC3 is based on a shared nothing storage architecture. Scale Computing HC3 enables every drive in every node throughout the cluster to contribute to the storage performance and capacity of every virtual disk (VDS) presented by the SCRIBE storage layer. When a VM is moved to another node, data remains in place and does not follow the VM because data is stored and available across all nodes residing in the cluster.
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)
Direct-attached: The software takes ownership of the unformatted physical disks available on each node – SATA/SAS/NVMe.
|
Direct-Attached (Raw)
Direct-attached: The software takes ownership of the unformatted physical disks available each host.
|
|
|
|
Magnetic-only
All-Flash
3D XPoint
Hybrid (3D Xpoint and/or Flash and/or Magnetic)
NEW
|
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.
|
Magnetic-only
Hybrid (Flash+Magnetic)
All-Flash
Scale Computing HC3 appliance models storage composition:
HC1200: Magnetic-only
HC1250: Hybrid
HC1250D: Hybrid
HC1250DF: All-flash
HC5250D: Hybrid
A Magnetic-only node is called a Non-tiered node and contains 100% HDD drives and no SSD drives.
A Hybrid node is called a Tiered node and contains 25% SSD drives and 75% HDD drives.
An All-Flash node contains 100% SSD drives and no HDD drives.
|
|
|
Hypervisor OS Layer
Details
|
SD, USB, DOM, SSD/HDD
|
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.
|
HDD or SSD (partition)
By default for each 1TB of data, 8MB is allocated for metadata. The data and metadata is stored on the physical storage devices (RSDs) and both are protected using mirroring (2N). Because metadata is this lightweight, all of the metadata of all of the online VSDs is cached in DRAM.
VSD = Virtual SCRIBE Device
RSD = Real SCRIBE Device
|
|
|
|
Memory |
|
|
|
|
DRAM
|
DRAM
StorPool uses RAM in servers for caching.
|
DRAM
|
|
|
|
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.
|
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.
|
Read Cache
Metadata structures
By default for each 1TB of data, 8MB is allocated for metadata. The data and metadata is stored on the physical storage devices (RSDs) and both are protected using mirroring (2N). Because metadata is this lightweight, all of the metadata of all of the online VSDs is cached in DRAM.
VSD = Virtual SCRIBE Device
RSD = Real SCRIBE Device
|
|
|
|
Up to 8 TB
The actual size that can be configured depends on the server hardware that is used.
|
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.
|
4GB+
4GB of RAM is reserved per node for the entire HC3 system to function. No specific RAM is reserved for caching but the system will use any available memory as needed for caching purposes.
|
|
|
|
Flash |
|
|
|
|
SSD, PCIe, UltraDIMM, NVMe
|
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.
|
SSD, NVMe
HyperCore-Direct for NVMe can be requested and is evaluated by Scale Computing on a per-customer scenario basis.
|
|
|
|
Persistent Storage
SANsymphony supports new TRIM / UNMAP capabilities for solid-state drives (SSD) in order to reduce wear on those devices and optimize performance.
|
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.
|
Persistent Storage
|
|
|
|
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.
|
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.
|
Hybrid: 1-3 SSDs per node
All-Flash: 4 SSDs per node
Flash devices are not mandatory in a Scale Computing HC3 solution.
Each HC1200 hybrid node has 1 SSD drive attached.
Each HC1250 all-flash node has 4 SSD drives attached.
Each HC5250 node has 3 SSD drives attached.
An HC1250 all-flash node can have a maximum of 15.36TB of raw SSD storage attached.
|
|
|
|
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
|
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
|
Hybrid: SATA
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
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).
|
Persistent Storage
|
|
|
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.
|
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.
|
Magnetic-only: 4 HDDs per node
Hybrid: 3 or 9 HDDs per node
Magnetic devices are not mandatory in a Scale Computing HC3 solution.
Each HC1200 magnetic-only node has 4 HDD drives attached.
Each HC1250 hybrid node has 3 HDD drives attached.
Each HC5250 hybrid node has 9 HDD drives attached.
An HC1200 magnetic-only node can have a maximum of 32TB of raw HDD storage attached.
An HC1250 hybrid node can have a maximum of 24TB of raw HDD storage attached.
An HC5250 hybrid node can have a maximum of 72TB of raw HDD storage attached.
|
|
|
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.
|
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.
|
Flash/HDD
The persisent write buffer depends on the type of the block storage pool (Flash or HDD).
|
|
|
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.
|
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.
|
2-way Mirroring (Network RAID-10)
Within a Scale Computing HC cluster all data is written twice to the block storage pool for redundancy (2N). It is equivalent to Network RAID-10, as the two data chunks are placed on separate physical disks of separate physical nodes within the cluster. This protects against 1 disk failure and 1 node failure at the same time, and aggregates the I/O and throughput capabilities of all the individual disks in the cluster (= wide striping).
Once an RSD fails, the system re-mirrors the data using the free space in the HC3 cluster as a hot spare. Because all physical disks contain data, rebuilds are very fast. Scale Computing HC3 is often to detect the deteriorated state of a physical storage device in advance and pro-actively copy data to other devices ahead of an actual failure.
Currently only 1 Replica (2N) can be maintained, as the setting is not configurable for end-users.
|
|
|
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.
|
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.
|
2-way Mirroring (Network RAID-10)
Within a Scale Computing HC cluster all data is written twice to the block storage pool for redundancy (2N). It is equivalent to Network RAID-10, as the two data chunks are placed on separate physical disks of separate physical nodes within the cluster. This protects against 1 disk failure and 1 node failure at the same time, and aggregates the I/O and throughput capabilities of all the individual disks in the cluster (= wide striping).
Once an RSD fails, the system re-mirrors the data using the free space in the HC3 cluster as a hot spare. Because all physical disks contain data, rebuilds are very fast. Scale Computing HC3 is often to detect the deteriorated state of a physical storage device in advance and pro-actively copy data to other devices ahead of an actual failure.
Currently only 1 Replica (2N) can be maintained, as the setting is not configurable for end-users.
|
|
|
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.
|
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.
|
Not relevant (1U/2U appliances)
|
|
|
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.
|
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.
|
N/A
|
|
|
Protection Capacity Overhead
Details
|
Mirroring (2N) (primary): 100%
Mirroring (3N) (primary): 200%
+ Hardware RAID5/6 overhead (optional)
|
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.
|
Mirroring (2N) (primary): 100%
|
|
|
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 (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.
|
Read integrity checks (software)
Disk scrubbing (software)
The HC3 system performs continuous read integrity checks on data blocks to detect corruption errors. As blocks are written to disk, replica blocks are written to other disks within the storage pool for redundancy. Disk are continuously scrubbed in the background for errors and any corruption found is repaired from the replica data blocks.
|
|
|
|
Points-in-Time |
|
|
|
|
Built-in (native)
|
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.
|
Built-in (native)
HyperCore snapshots use a space efficient allocate-on-write methodology where no additional storage is used at the time the snapshot is taken, but as blocks are changed the original content blocks are preserved, and new content written to freshly allocated space on the cluster.
|
|
|
|
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 + 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.
|
Local (+ Remote)
Manual snapshots are always created on the source HC3 cluster only and are never deleted by the system.
Without remote replication active on a VM, snapshots created using snapshot schedules are also created on the source HC3 cluster only.
With remote replication active, a snapshot schedule repeatedly creates a VM snapshot on the source cluster and then copies that snapshot to the target cluster, where it is retained for a specified number of minutes/hours/days/weeks/months. The default remote replication frequency of 5 minutes, combined with the default retention of 25 minutes, means that by default 5 snapshots are maintained on the target HC3 cluster at any given time.
A VM can only have one snapshot schedule assigned at a time. However, a schedule can contain multiple recurrence rules. Each recurrence rule consists of a replication snapshot frequency (x minutes/hours/days/weeks/months), an execution time (eg. 12:00AM), and a retention (y minutes/hours/days/weeks).
|
|
|
Snapshot Frequency
Details
|
1 Minute
The snapshot lifecycle can be automatically configured using the integrated Automation Scheduler.
|
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.
|
5 minutes
A snapshot schedule allows a minimum frequency of 5 minutes. However, ScaleCare Support recommends no less than every 15 minutes as a general best practice.
|
|
|
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 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).
|
Per VM
|
|
|
|
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.
|
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.
|
Built-in (native)
By combining Scale Computing HC3s native snapshot feature with its native remote replication mechanism, backup copies can be created on remote HC3 clusters.
A snapshot is not a backup:
1. For a data copy to be considered a backup, it must at the very least reside on a different physical platform (=controller+disks) to avoid dependencies. If the source fails or gets corrupted, a backup copy should still be accessible for recovery purposes.
2. To avoid further dependencies, a backup copy should reside in a different physical datacenter - away from the source. If the primary datacenter becomes unavailable for whatever reason, a backup copy should still be accessible for recovery purposes.
When considering the above prerequisites, a backup copy can be created by combining snapshot functionality with remote replication functionality to create independent point-in-time data copies on other SDS/HCI clusters or within the public cloud. In ideal situations, the retention policies can be set independently for local and remote point-in-time data copies, so an organization can differentiate between how long the separate backup copies need to be retained.
Apart from the native features, Scale Computing HC3 supports any in-guest 3rd party backup agents that are designed to run on Intel-based virtual machines on our supported OS platforms.
|
|
|
|
Local or Remote
All available storage within the SANsymphony group can be configured as targets for back-up jobs.
|
Local or Remote
StorPool can create snapshots on a frequent basis and send these snapshots between sites securely and efficiently.
|
Locally
To remote sites
|
|
|
|
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.
|
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.
|
5 minutes (Asynchronous)
VM snapshots are created automatically by the replication process as quickly as every 5 minutes (as long as the previous snapshot’s change blocks have been fully replicated to the target HC3 cluster). The remote replication default schedule will take a snapshot every 5 minutes and keep snapshots for 25 minutes.
|
|
|
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.
|
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.
|
Crash Consistent
File System Consistent (Windows)
Application Consistent (MS Apps on Windows)
For Windows VMs that require it, VSS snapshot integration is provided in the VIRTIO driver package.
|
|
|
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.
|
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.
|
Entire VM
Although Scale Computing HC3 uses block-storage, the platform is capable of attaining per VM-granularity.
|
|
|
| |
