|
General
|
|
|
- Fully Supported
- Limitation
- Not Supported
- Information Only
|
|
Pros
|
- + Extensive platform support
- + Extensive data protection capabilities
- + Flexible deployment options
|
- + Built for simplicity
- + Policy-based management
- + Cost-effectiveness
|
- + Extensive QoS capabilities
- + Considerable data protection integration
- + Built for performance
|
|
Cons
|
- - No native data integrity verification
- - Dedup/compr not performance optimized
- - Disk/node failure protection not capacity optimized
|
- - Single hypervisor support
- - No stretched clustering
- - No native file services
|
- - 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: 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.
|
Name: Acuity (AC)
Type: Hardware+Software (HCI)
Development Start: 2016
First Product Release: 2017
Pivot3 was founded in 2002 and began to ship its first hyper-converged storage (HCI) platform, Serverless Computing, in 2008. The first Pivot3 appliances were primarily positioned for storing video surveilance data.
Early 2016 Pivot3 acquired external storage system company NexGen Storage and with it its mature N5 operating system that leveraged strong storage QoS capabilities. Pivot3 succesfully combined the N5 OS with its own vSTAC (Virtual Storage and Compute) OS, into a new software stack called Acuity. The Acuity platform was launched in April 2017, although the technology features and software were available in 2016 as part of the Pivot3 SLX product. In July 2018 Pivot3 also switched to the Acuity codebase for its video surveillance appliances.
Pivot3 pursues a vision to radically simplify the datacenter by collapsing storage, compute and network resources onto a powerful, easy to deploy solution that reduces cost, risk and complexity. Pivot3 has by far the longest track-record when it comes to hyper-converged infrastructure, when comparing to the other SDS/HCI vendors in the WhatMatrix.
In July 2018 the company had an install base of more than 2,600 customers worldwide and there were more than 300 employees working for Pivot3.
|
|
|
|
GA Release Dates:
SSY 10.0 PSP12: jan 2021
SSY 10.0 PSP11: aug 2020
SSY 10.0 PSP10: dec 2019
SSY 10.0 PSP9: jul 2019
SSY 10.0 PSP8: sep 2018
SSY 10.0 PSP7: dec 2017
SSY 10.0 PSP6 U5: aug 2017
.
SSY 10.0: jun 2014
SSY 9.0: jul 2012
SSY 8.1: aug 2011
SSY 8.0: dec 2010
SSY 7.0: apr 2009
.
SSY 3.0: 1999
NEW
10th Generation software. DataCore currently has the most experience when it comes to SDS/HCI technology, when comparing SANsymphony to other SDS/HCI platforms.
SANsymphony (SSY) version 3 was the first public release that hit the market back in 1999. The product has evolved ever since and the current major release is version 10. The list includes only the milestone releases.
PSP = Product Support Package
U = Update
|
GA Release Dates:
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
|
GA Release Dates:
AC 10.6.1: feb 2019
AC 10.6: dec 2018
AC 10.5.1: oct 2018
AC 10.4: jun 2018
AC 2.3.3: mar 2018
AC 2.3.2: jan 2018
AC 2.2: oct 2017
AC 2.1.1: aug 2017
AC 2.1: apr 2017
NEW
5th Generation software. Pivot3 currently has the most experience when it comes to HCI technology, when comparing Pivot3 technology to other SDS/HCI platforms.
|
|
|
|
Pricing |
|
|
|
Hardware Pricing Model
Details
|
N/A
SANsymphony is sold by DataCore as a software-only solution. Server hardware must be acquired separately.
The entry point for all hardware and software compatibility statements is: https://www.datacore.com/products/sansymphony/tech/compatibility/
On this page links can be found to: Storage Devices, Servers, SANs, Operating Systems (Hosts), Networks, Hypervisors, Desktops.
Minimum server hardware requirements can be found at: https://www.datacore.com/products/sansymphony/tech/prerequisites/
|
Per Node
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
|
Per Node
There is no separate software licensing. Each node comes equiped with an all-inclusive feature set. This means that without exception all Acuity software capabilities are available for use.
|
|
|
Software Pricing Model
Details
|
Capacity based (per TB)
NEW
DataCore SANsymphony is licensed in three different editions: Enterprise, Standard, and Business.
All editions are licensed per capacity (in 1 TB steps). Except for the Business edition which has a fixed price per TB, the more capacity that is used by an end-user in each class, the lower the price per TB.
Each edition includes a defined feature set.
Enterprise (EN) includes all available features plus expanded Parallel I/O.
Standard (ST) includes all Enterprise (EN) features, except FC connections, Encryption, Inline Deduplication & Compression and Shared Multi-Port Array (SMPA) support with regular Parallel I/O.
Business (BZ) as entry-offering includes all essential Enterprise (EN) features, except Asynchronous Replication & Site Recovery, Encryption, Deduplication & Compression, Random Write Accelerator (RWA) and Continuous Data Protection (CDP) with limited Parallel I/O.
Customers can choose between a perpetual licensing model or a term-based licensing model. Any initial license purchase for perpetual licensing includes Premier Support for either 1, 3 or 5 years. Alternatively, term-based licensing is available for either 1, 3 or 5 years, always including Premier Support as well, plus enhanced DataCore Insight Services (predictive analytics with actionable insights). In most regions, BZ is available as term license only.
Capacity can be expanded in 1 TB steps. There exists a 10 TB minimum per installation for Business (BZ). Moreover, BZ is limited to 2 instances and a total capacity of 38 TB per installation, but one customer can have multiple BZ installations.
Cost neutral upgrades are available when upgrading from Business/Standard (BZ/ST) to Enterprise (EN).
|
Per Node (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.
|
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 Acuity software capabilities are available for use.
|
|
|
Support Pricing Model
Details
|
Capacity based (per TB)
Support is always provided on a premium (24x7) basis, including free updates.
More information about DataCores support policy can be found here:
http://datacore.custhelp.com/app/answers/detail/a_id/1270/~/what-is-datacores-support-policy-for-its-products
|
Per Node
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.
|
Per Node
Software support is mandatory at initial purchase and available in 1-, 3-, and 5-year increments.
Support Offerings:
7 day x 24 hour phone | parts onsite/same day
7 day x 24 hour phone | parts next business day
5 day x 9 hour phone | parts next business day
Pivot3 Proactive Diagnostics is an optional service that when enabled, provides:
- Actionable alerts and notifications
- Integrated phone-home telemetry.
|
|
|
Design & Deploy
|
|
|
|
|
|
|
Design |
|
|
|
Consolidation Scope
Details
|
Storage
Data Protection
Management
Automation&Orchestration
DataCore is storage-oriented.
SANsymphony Software-Defined Storage Services are focused on variable deployment models. The range covers classical Storage Virtualization over Converged and Hybrid-Converged to Hyperconverged including a seamless migration between them.
DataCore aims to provide all key components within a storage ecosystem including enhanced data protection and automation & orchestration.
|
Hypervisor
Compute
Storage
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.
|
Compute
Storage
Data Protection
Management
Automation&Orchestration
With the Acuity platform Pivot3 aims to provide key components within a Private Cloud ecosystem as well as integration with existing hypervisors and applications. Pivot3 also leverages several data protection capabilities.
|
|
|
|
1, 10, 25, 40, 100 GbE (iSCSI)
8, 16, 32, 64 Gbps (FC)
The bandwidth required depends entirely on the specifc workload needs.
SANsymphony 10 PSP11 introduced support for Emulex Gen 7 64 Gbps Fibre Channel HBAs.
SANsymphony 10 PSP8 introduced support for Gen6 16/32 Gbps ATTO Fibre Channel HBAs.
|
1, 10 GbE
Scale Computing hardware models include redundant ethernet connectivity in an active/passive setup.
|
10 GbE (or 1GbE)
Pivot3 Acuity hardware models include redundant ethernet connectivity using SFP+ or Base-T. Pivot3 recommends 10GbE to avoid the network becoming a performance bottleneck.
The 1GbE Base-T ports in the hardware models are left unused in almost all cases. They can be activated and used, but it is only on Exceptional, and Approved Opportunities.
|
|
|
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.
|
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.
|
Low
Pivot3 Acuity was developed with simplicity in mind, both from a design and a deployment perspective. Pivot3 Acuitys uniform platform architecture is meant to be applicable to a wide variety of use-cases and seeks to provide important capabilities natively. Many advanced capabilities like deduplication and compression 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
No Scale Computing HC3 validated test reports have been published in 2016/2017/2018/2019.
|
ESG Lab (dec 2017)
ESG Lab (Dec 2017)
Title: 'Pivot3 Acuity: A High-performance Hyperconverged Platform with Advanced QoS'
Workloads: MSSQL OLTP, VDI, Generic
Benchmark Tools: HammerDB (MSSQL), Login VSI (VDI), IOmeter (generic)
Hardware: All-flash Acuity X5-6500/X5-6000, 3-node cluster, AC 2.1 (MSSQL, generic); All-flash+Hybrid Acuity, 6-node cluster, AC 2.1 (VDI)
|
|
|
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/
|
Public Facing Clusters
Proof-of-Concept (PoC)
|
Cloud Edition (forever)
Online Labs
Proof-of-Concept (PoC)
Partner Driven Demo Environment
Pivot3 Acuity Cloud Edition provides a non-intrusive way to test the product and its feature set.
Pivot3 organizes remote demos via VPN access to one of Pivot3s demo labs. In addition hands-on in-person demos/testing can be arranged in one of Pivot3s Executive Briefing Center (EBC) labs.
Pivot 3 provides both remote and on-site Proof-of-Concepts (PoC). PoCs are properly prepared by first agreeing on a set of success criteria. The length of a PoC is determined on a case-by-case basis. Under normal conditions Pivot3 PoCs are executed at no cost to the end-user.
Several Pivot3 partners provide an Acuity demo enviroment for customers to explore.
|
|
|
|
Deploy |
|
|
|
Deployment Architecture
Details
|
Single-Layer
Dual-Layer
Single-Layer = servers function as compute nodes as well as storage nodes.
Dual-Layer = servers function only as storage nodes; compute runs on different nodes.
Single-Layer:
- SANsymphony is implemented as virtual machine (VM) or in case of Hyper-V as service layer on Hyper-V parent OS, managing internal and/or external storage devices and providing virtual disks back to the hypervisor cluster it is implemented in. DataCore calls this a hyper-converged deployment.
Dual-Layer:
- SANsymphony is implemented as bare metal nodes, managing external storage (SAN/NAS approach) and providing virtual disks to external hosts which can be either bare metal OS systems and/or hypervisors. DataCore calls this a traditional deployment.
- SANsymphony is implemented as bare metal nodes, managing internal storage devices (server-SAN approach) and providing virtual disks to external hosts which can be either bare metal OS systems and/or hypervisors. DataCore calls this a converged deployment.
Mixed:
- SANsymphony is implemented in any combination of the above 3 deployments within a single management entity (Server Group) acting as a unified storage grid. DataCore calls this a hybrid-converged deployment.
|
Single-Layer
Single-Layer = 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 (primary)
Dual-Layer (secondary)
Single-Layer: Pivot3 Acuity is meant to be used as a storage platform as well as a compute platform at the same time. This effectively means that applications, hypervisor and storage software are all running on top of the same server hardware (=single infrastructure layer).
Pivot3 Acuity can also serve in a dual-layer model by providing storage to non-Acuity hypervisor hosts (Please view the compute-only scale-out option for more information).
|
|
|
Deployment Method
Details
|
BYOS (some automation)
BYOS = Bring-Your-Own-Server-Hardware
DataCore SANsymphony is made easy by providing a very straightforward implementation approach.
|
Turnkey (very fast; highly automated)
Because of the ready-to-go Hyper Converged Infrastructure (HCI) building blocks and the setup wizard provided by Scale Computing, customer deployments can be executed in hours instead of days.
|
Turnkey (very fast; highly automated)
Because of the ready-to-go Hyper Converged Infrastructure (HCI) building blocks and the setup wizard provided by Pivot3, 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.
|
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.
|
Virtual Storage Controller
The Pivot 3 Virtual Storage Controller is deployed as a pre-configured Virtual Machine on top of each server that acts as a part of the Pivot3 Acuity storage solution and commits its internal 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. Pivot3 leverages its patented MPIO driver and VMwares DirectPath I/O framework to maximize storage performance.
MPIO Driver: Pivot3 has a patented MPIO driver in Acuity that allows an application server to see and, more importantly, read and write down every path available to the data. This improves both performance and storage resiliency.
DirectPath I/O (VMDirectPath) is a VMware framework that allows Acuity to directly communicate with the
underlying storage controllers, NVMe devices and disks for optimal performance benefit. Pivot3’s patented implementation against this framework allows for improved overall I/O performance for the
application layer and VMs.
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.
|
|
|
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.
|
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
|
VMware vSphere ESXi 6.5-6.7
Pivot3 Acuity hardware models are officially listed in the Storage/SAN section of the online VMware Compatibility Guide.
Pivot3 Acuity only supports the VMware vSphere hypervisor at this time.
|
|
|
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
|
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
|
iSCSI
The Pivot3 Acuity platform supports the industry-standard iSCSI protocol to present storage to both hypervisor and non-hypervisor environments.
The iSCSI protocol can also be leveraged to present storage directly to VMs, which is often referred to as 'in-guest iSCSI'.
|
|
|
|
Bare Metal |
|
|
|
Bare Metal Compatibility
Details
|
Microsoft Windows Server 2012R2/2016/2019
Red Hat Enterprise Linux (RHEL) 6.5/6.6/7.3
SUSE Linux Enterprise Server 11.0SP3+4/12.0SP1
Ubuntu Linux 16.04 LTS
CentOS 6.5/6.6/7.3
Oracle Solaris 10.0/11.1/11.2/11.3
Any operating system currently not qualified for support can always be individually qualified with a specific SANsymphony version and will get full support after passing the self-qualification process.
SANsymphony provides virtual disks (block storage LUNs) to all of the popular host operating systems that use standard disk drives with 512 byte or 4K byte sectors. These hosts can access the SANsymphony virtual disks via SAN protocols including iSCSI, Fibre Channel (FC) and Fibre Channel over Ethernet (FCoE).
Mainframe operating systems such as IBM z/OS, z/TPF, z/VSE or z/VM are not supported.
SANsymphony itself runs on Microsoft Windows Server 2012/R2 or higher.
|
N/A
Scale Computing HC3 does not support any non-hypervisor platforms.
|
Many
Because Pivot3 leverages the industry-standard iSCSI protocol, it enables hosts and physical workloads that reside outside of a Pivot3 cluster to access Pivot3 volumes by providing highly available block storage as iSCSI LUNs. The physical workloads can be stand-alone servers, Windows Failover Clusters (including MSSQL) or Oracle RAC. Also hypervisor workloads are supported to run on these separate hosts, such as Hyper-V and KVM.
Pivot3 quality engineering teams have so far qualified Acuity with external hosts running VMware ESX 6.x, Windows Server 2012/2016 and various flavors of Linux.
|
|
|
Bare Metal Interconnect
Details
|
iSCSI
FC
FCoE
|
N/A
Scale Computing HC3 does not support any non-hypervisor platforms.
|
iSCSI
The Pivot3 Acuity platform supports the industry-standard iSCSI protocol to present storage to both hypervisor and non-hypervisor environments.
The iSCSI protocol can also be leveraged to present storage directly to VMs, which is often referred to as 'in-guest iSCSI'. Pivot3 recommends utilizing a modern iSCSI initiator that supports MPIO ALUA in Round-Robin policy.
MPIO ALUA = Multipath Input/Output Asymmetric Logical Unit Access
|
|
|
|
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
N/A
Pivot3 Acuity relies on the container support delivered by the hypervisor platform.
|
|
|
Container Platform Compatibility
Details
|
Docker CE/EE 18.03+
Docker EE = Docker Enterprise Edition
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
Docker CE 17.06.1+ for Linux on ESXi 6.0+
Docker EE/Docker for Windows 17.06+ on ESXi 6.0+
Docker CE = Docker Community Edition
Docker EE = Docker Enterprise Edition
|
|
|
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
Docker Volume Plugin (certified) + VMware VIB
vSphere Docker Volume Service (vDVS) can be used with VMware vSAN, as well as VMFS datastores and NFS datastores served by VMware vSphere-compatible storage systems.
The vSphere Docker Volume Service (vDVS) installation has two parts:
1. Installation of the vSphere Installation Bundle (VIB) on ESXi.
2. Installation of Docker plugin on the virtualized hosts (VMs) where you plan to run containers with storage needs.
The vSphere Docker Volume Service (vDVS) is officially 'Docker Certified' and can be downloaded from the online Docker Store.
|
|
|
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
Virtualized container hosts on VMware vSphere hypervisor
Because the vSphere Docker Volume Service (vDVS) and vSphere Cloud Provider (VCP) are tied to the VMware Sphere platform, they cannot be used for bare metal hosts running containers.
|
|
|
Container Host OS Compatbility
Details
|
Linux
All Linux versions supported by Docker CE/EE 18.03+ or higher can be used.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
Linux
Windows 10 or 2016
Any Linux distribution running version 3.10+ of the Linux kernel can run Docker.
vSphere Storage for Docker can be installed on Windows Server 2016/Windows 10 VMs using the PowerShell installer.
|
|
|
Container Orch. Compatibility
Details
|
Kubernetes 1.13+
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
Kubernetes 1.6.5+ on ESXi 6.0+
|
|
|
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.
|
N/A
Scale Computing HC3 does not officially support any container platforms.
|
Kubernetes Volume Plugin
vSphere Cloud Provider (VCP) for Kubernetes allows Pods to use enterprise grade persistent storage. VCP supports every storage primitive exposed by Kubernetes:
- Volumes
- Persistent Volumes (PV)
- Persistent Volumes Claims (PVC)
- Storage Class
- Stateful Sets
Persistent volumes requested by stateful containerized applications can be provisioned on vSAN, VVol, VMFS or NFS datastores.
|
|
|
|
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.
|
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 Horizon
Citrix XenDesktop
Pivot3 has published an Acuity X5 Reference Architecture whitepaper for VMware Horizon.
Pivot3 has not (yet) published an Acuity X5 Reference Whitepaper for Citrix XenDesktop.
|
|
|
|
VMware: 110 virtual desktops/node
Citrix: 110 virtual desktops/node
DataCore has not published any recent VDI reference architecture whitepapers. The only VDI related paper that includes a Login VSI benchmark dates back to december 2010. There a 2-node SANsymphony cluster was able to sustain a load of 220 VMs based on the Login VSI 2.0.1 benchmark.
|
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.
|
VMware: 272-317 virtual desktops/node
Citrix: 167 virtual desktops/node
NEW
VMware Horizon 7.0.2: Load bearing numbers are based on Login VSI tests performed on an Acuity X5 hybrid configuration consisting of two Pivot3 X5-2500 Accelerator nodes and one Pivot3 X5-2000 Standard node, and an Acuity X5 all-flash configuration consisting two Acuity X5-6500 Accelerator nodes and one Pivot3 X5-6000 Standard node. In both cases each of the Acuity accelerator nodes had 1.6TB of NVMe flash storage and 2vCPU Windows 7 desktops and the Knowledge Worker profile were used.
Citrix Virtual Apps and Desktops 7 1808: Load bearing numbers are based on Login VSI tests performed on an Acuity X5 all-flash configuration consisting of two Pivot3 X5-6500 Accelerator nodes and one Pivot3 X5-6000 Standard node. Each of the Acuity accelerator nodes had 2.0TB of NVMe flash storage and 2vCPU Windows 10 1709 desktops and the Knowledge Worker profile were used.
For detailed information please view the corresponding whitepapers.
|
|
|
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.
|
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).
|
Dell
Lenovo
For Pivot3 Acuity Datacenter Edition end-users may choose either Dell-base or Lenovo-based server hardware should it matter to them.
Pivot3 Acuity Lenovo and Dell servers may be mixed and matched, so switching between server hardware vendors is allowed. The only prerequisite for mixing is that the persistent media type (SSD or Hybrid), drive capacity and the number of drives per node are the same. When mixing, nodes are allowed to have varying memory and CPU sizes.
|
|
|
|
Many
SANsymphony runs on all server hardware that supports x86 - 64bit.
DataCore provides minimum requirements for hardware resources.
|
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
|
8 compute+storage models:
X5-2000, X5-2500, X5-6000, X5-6500, X3-2000, X3-2500, X3-6000, X3-6500
4 compute-only models:
X3-2000, X3-2500, X3-6000, X3-6500
4 storage-only models:
X3-2000s, X3-6000s, X5-2000s, X5-6000s
NEW
Different models are available for different workloads and use cases:
X5-6500 - HCI Flash Accelerator Node 2U
X5-6000 - HCI Flash Standard Node 2U
X5-6000s - STO Flash Storage-only Node 2U
X5-2500 - HCI Hybrid Accelerator Node 2U
X5-2000 - HCI Hybrid Standard Node 2U
X5-2000s - STO Hybrid Storage-only Node 2U
X3-6500 - HCI Flash Accelerator Node 1U
X3-6000 - HCI Flash Standard Node 1U
X3-6000s - STO Flash Storage-only Node 1U
X3-2500 - HCI Hybrid Accelerator Node 1U
X3-2000 - HCI Hybrid Standard Node 1U
X3-2000 - STO Hybrid Storage-only Node 1U
A Pivot3 Acuity cluster always has to include 2 Accelerator nodes (either X5-6500, X5-2500, X3-6500 or X3-2500), because NMVe PCIe is used as write-buffer and all writes are mirrored between these two nodes.
Pivot3 X-Series Storage Appliances are combined with Pivot3 X-Series HCI Appliances to form a Virtual Performance Group (vPG).
|
|
|
|
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 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
|
1 node per chassis
Pivot3 Acuity X5-Series appliances are 2U building blocks. Pivot3 Acuity X3-Series appliances are 1U 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.
|
|
|
|
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
Scale Computing allows for mixing different server hardware in a single HC3 cluster, including nodes from different generations.
|
Partial
A Pivot3 Acuity 'cluster' is called a Pivot3 virtual Performance Group (vPG). vPGs can only consist of like platforms (Hybrid nodes vs. All-flash nodes).
However, Pivot3 Acuity Hybrid (2x00) and All-flash (6x00) nodes can co-exist within the same Pivot3 Domain (aka 'Federation'). All nodes in the Domain can be managed via a single pane of glass.
|
|
|
|
Components |
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
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: up to 7 options
NEW
HCI Appliances: By default both X3 and X5 series models are equiped with 1st generation Intel Xeon Scalable processors (Skylake):
Intel Xeon Scalable 4114 2x 10-cores (X3-2000/2500)
Intel Xeon Scalable 5118 2x 12-cores (X3-6000/6500; X5-2000/2500/6000/6500)
Intel Xeon Scalable 6138 2x 20-cores (X3-6000/6500; X5-2000/2500/6000/6500)
Other Intel Xeon CPUs are available on request. The following CPU configurations are supported in Pivot3 Acuity appliances:
Dual Xeon 6138 20-cores
Dual Xeon 5118 12-cores
Dual Xeon 4114 10-cores
Single Xeon 3104 12-cores
Dual Xeon 4116 12-cores
Single Xeon 4116 12-cores
Single E3-1270 4-cores
Storage Appliances: By default both X3 and X5 series models are equiped with 1st generation Intel Xeon Scalable processors (Skylake):
Intel Xeon Scalable 3104 1x 6-cores (X3-2000s/6000s; X5-2000s/6000s)
Pviot3 Acuity X-Series nodes do not yet ship with 2nd generation Intel Xeon Scalable (Cascade Lake) processors.
|
|
|
|
Flexible
|
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: up to 4 options
NEW
HCI Appliances:
X5-series storage nodes: 256GB, 512GB, 768GB or 1536GB per node. 1536GB per node is available only on request.
X3-series storage nodes: 192GB, 384GB or 768GB per node.
X3-series compute-only nodes: 256GB, 768GB or 1536GB per node.
Each Acuity node has 24 DIMM slots that are populated with multiples of 32GB or 64GB DIMMs to reach the different memory capacity points.
Storage Appliances:
X5s-series and X3s-series storage nodes: 32GB per node
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
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: disk capacity
NEW
X5-2000 (Hybrid Standard):
2x 400GB SSD - used primarily for Erasure Coding write acceleration
12x 1TB/2TB/4TB/8TB/10TB/12TB NL-SAS = 12TB/24TB/48TB/96TB/120TB/144TB raw capacity
X5-2500 (Hybrid Accelerator):
1x 3.8TB/4.0TB NVMe PCIe
2x 400GB SSD - used primarily for Erasure Coding write acceleration
12x 1TB/2TB/4TB/8TB/10TB/12TB NL-SAS = 12TB/24TB/48TB/96TB/120TB/144TB raw capacity
X3-2000 (Hybrid Standard):
1x 400GB SSD - used primarily for Erasure Coding write acceleration
8x 1TB/2TB NL-SAS = 8TB/16TB raw capacity
X3-2500 (Hybrid Accelerator):
1x 960GB 2.5' PCIe SSD (U.2) or 1.6TB NVMe PCIe
2x 400GB SSD - used primarily for Erasure Coding write acceleration
8x 1TB/2TB NL-SAS = 8TB/16TB raw capacity
X5-6000 (All-Flash Standard):
8x 400GB/480GB/800GB/960GB/1.6TB/1.9TB/3.8TB = 3.2TB/3.8TB/6.4TB/7.6TB/12.8TB/15.3TB/30.7TB raw capacity
X5-6500 (All-Flash Accelerator):
1x 1.6TB NVMe PCIe
8x 400GB/480GB/800GB/960GB/1.6TB/1.9TB/3.8TB = 3.2TB/3.8TB/6.4TB/7.6TB/12.8TB/15.3TB/30.7TB raw capacity
X3-6000 (All-Flash Standard):
8x 960GB/1.9TB/3.8TB = 7.6TB/15.3TB/30.7TB raw capacity
X3-6500 (All-Flash Accelerator):
1x 960GB 2.5' PCIe SSD (U.2) or 1.6TB NVMe PCIe
8x 960GB/1.9TB/3.8TB = 7.6TB/15.3TB/30.7TB raw capacity
There is no difference in storage capacity options between Pivot3 X-series HCI appliances and Pivot3 X-series Storage appliances.
|
|
|
|
Flexible
Minimum hardware requirements need to be fulfilled.
For more information please go to: https://www.datacore.com/products/sansymphony/tech/compatibility/
|
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+
|
Flexible: 2 or 3 options
NEW
HCI Appliances:
X5-6500: 6x 10 GbT + 2x1GbT OR 8x 10 GbT / GbE SFP+
X5-6000: 4x 10 GbT + 2x1GbT OR 6x 10 GbT / GbE SFP+
X5-2500: 6x 10 GbT + 2x1GbT OR 8x 10 GbT / GbE SFP+
X5-2000: 4x 10 GbT + 2x1GbT OR 6x 10 GbT / GbE SFP+
X3-6500: 8x 10 GbT OR 8x 10 GbE SFP+
X3-6000: 6x 10 GbT OR 6x 10 GbE SFP+
X3-2500: 8x 10 GbT OR 8x 10 GbE SFP+
X3-2000: 6x 10 GbT OR 6x 10 GbE SFP+
Storage Appliances:
X5-6000s: 4x 10 GbT OR 4x 10 GbE SFP+
X5-2000s: 4x 10 GbT OR 4x 10 GbE SFP+
X3-6000s: 4x 10 GbT OR 4x 10 GbE SFP+
X3-2000s: 4x 10 GbT OR 4x 10 GbE 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.
|
N/A
Scale Computing HC3 currently does not provide any GPUs options.
|
X5: NVIDIA Tesla
X3: N/A
The following NVIDIA GPU card configurations can be ordered along with the Pivot3 X5-6000/6500 models:
1x NVIDIA Tesla M10
1x NVIDIA Tesla M60
1x NVIDIA Tesla P40
1x NVIDIA Tesla V100
|
|
|
|
Scaling |
|
|
|
|
CPU
Memory
Storage
GPU
The SANsymphony 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.
|
Memory
Network
The system memory of a Pivot3 Acuity node may be expanded after initial purchase.
Each Acuity node has 24 DIMM slots that are populated with multiples of 32GB or 64GB DIMMs to reach the different memory capacity points.
It is possible to expand the number of available network ports within a node through the addition of an extra PCIe 10Gbe network card, or to upgrade an existing network card from dual-port to quad-port configurations.
|
|
|
|
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
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).
|
Compute+storage
Compute-only (iSCSI)
Storage-only
NEW
Storage+Compute: Existing Pivot3 Acuity clusters can be expanded by adding additional X5-Series nodes, which adds additional compute and storage resources to the shared pool.
Compute-only: Because Pivot3 Acuity leverages a common block protocol (iSCSI), storage can be presented to hypervisor hosts not participating in the Pivot3 Acuity storage cluster, as long as these hosts are connected to the storage iSCSI network. This is also beneficial to migrations, since it allows for online storage vMotions between Pivot3 Acuity and non-Pivot3 Acuity storage platforms.
Storage-only: With the release of Acuity 10.6.1 Pivot3 introduces Storage appliances next to its HCI appliances. The Storage appliances have minimal CPU and Memory resources on board and only take part in the storage cluster so they can contribute to the shared storage pool of the HCI appliances. They do not take part in the hypervisor (compute) cluster, so no VMware vSphere licenses are required.
|
|
|
|
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-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.
|
X5 Hybrid: 3-12 nodes in 1-node increments
X5 All-Flash: 3-16 nodes in 1-node increments
X3 Hybrid: 3-8 nodes in 1-node increments
X3 All-Flash: 3-8 nodes in 1-node increments
At maximum a Pivot3 Acuity X5 Hybrid vPG (aka 'cluster') consists of 12 X5-2x00 nodes. The maximum configuration consists of 2 Flash Accelerator nodes + 10 non-accelerator nodes.
At maximum a Pivot3 Acuity X5 All-Flash vPG (aka 'cluster' ) consists of 16 X5-6x00 nodes. The maximum configuration consists of 2 Flash Accelerator nodes + 14 non-accelerator nodes.
At maximum a Pivot3 Acuity X3 Hybrid vPG (aka 'cluster') consists of 8 X3-2x00 nodes. The maximum configuration consists of 2 Flash Accelerator nodes + 6 non-accelerator nodes.
At maximum a Pivot3 Acuity X3 All-Flash vPG (aka 'cluster' ) consists of 8 X3-6x00 nodes. The maximum configuration consists of 2 Flash Accelerator nodes + 6 non-accelerator nodes.
A Pivot3 Acuity vPG (aka 'cluster' ) always needs to include 2 Flash Accelerator nodes, because the NMVe PCIe cards are used as write-buffer and all writes have to be mirrored between these two nodes to protect the incoming data streams.
A Pivot3 Domain can include multiple vPGs and therefore can have an unlimited number of nodes. All vPGs can be managed as one pool of resources from a single management pane. VMs can have data stored on multiple clusters and vMotion between any cluster works seamlessly.
|
|
|
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.
|
1 Node minimum
|
3 Node minimum (data center)
1 Node minimum (ROBO)
Pivot3 Acuity supports a minimum of 3 X-series nodes when local High Availability (HA) is required. The minimum base configuration consists of 2 Flash Accelerator nodes + 1 non-accelerator node. Two Accelerator nodes are required, because the NMVe PCIe cards are used as write-buffer and all writes are mirrored between these two nodes.
Pivot3 Acuity also supports 1-node configurations when local HA is not required, eg. in ROBO deployments.
|
|
|
Storage Support
|
|
|
|
|
|
|
General |
|
|
|
|
Block Storage Pool
SANsymphony only serves block devices to the supported OS platforms.
|
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.
|
Block Pool
Pivot3 Acuity serves block devices as storage volumes to the supported OS platforms. The Block Pool is wide striped and load balanced across all resources in the cluster.
|
|
|
|
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
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.
|
None
Pivot3 Acuity enables every drive in every node throughout the vPG (virtual performance group or cluster) to contribute to the storage performance and capacity of every volume presented by Acuity. After a VM is moved to another Acuity X5 node, data remains in place and does not follow the VM because data is wide-striped and available across all nodes.
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 require 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 each host.
|
Direct-attached (Raw)
Direct-attached: The software takes ownership of the unformatted physical disks available each X5-Series node.
External SAN/NAS Storage: Pivot3 Acuity does not support the connection to external Fiber Channel (FC), Fiber Channel over Ethernet (FCoE), iSCSI and/or NFS storage directly or through the Fabric Interconnect (FI) switches.
|
|
|
|
Magnetic-only
All-Flash
3D XPoint
Hybrid (3D Xpoint and/or Flash and/or Magnetic)
NEW
|
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.
|
Hybrid (Flash+Magnetic)
All-Flash
Depending on the chosen X5-series appliance model, Pivot3 Acuity can be deployed using different compositions:
- Hybrid (NVMe PCIe/Performance SSD + Capacity HDD)
- All-Flash (NVMe PCIe/Performance SSD + Capacity SSD)
|
|
|
Hypervisor OS Layer
Details
|
SD, USB, DOM, SSD/HDD
|
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
|
USB, SSD, SD
Dell: ESXi is booted from an internal, enterprise grade M.2 SSD drive or from dual SDs.
Lenovo: ESXi is booted from an internal, ultra-high performance, enterprise grade USB drive.
|
|
|
|
Memory |
|
|
|
|
DRAM
|
DRAM
|
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.
|
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
|
Read Cache and Write Buffer
DRAM is used by Acuitys Dynamic Data Path Engine to provide read-ahead cache acceleration. Data is copied
from NVMe PCIe flash or disk (HDD or SSD) into DRAM to provide faster access to the data.
GlobalCache: Pivot3 Acuity also uses the DRAM inside each node as a high performance cache to provide an initial landing point for data as it is passed from the NVMe PCIe flash tier to the erasure coded persistent storage tier (HDD or SSD).
|
|
|
|
Up to 8 TB
The actual size that can be configured depends on the server hardware that is used.
|
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.
|
Configurable
Between 24-128GB of physical memory (DRAM) in each Pivot3 Acuity node is assigned to the local Pivot3 Virtual Storage Controller (VSC) and as such is not available to the hypervisor software (ESXi).
The local Pivot3 Acuity VM can be assigned more memory, however there is little to no benefit to performance by doing so.
By default, 24GB of the memory (DRAM) that is assigned to the local Pivot3 Acuity VM is used as GlobalCache.
GlobalCache: A high performance cache that provides an initial landing point for data as it is passed from the NVMe PCIe flash tier to the erasure coded persistent storage tier (HDD or SSD).
|
|
|
|
Flash |
|
|
|
|
SSD, PCIe, UltraDIMM, NVMe
|
SSD, NVMe
HyperCore-Direct for NVMe can be requested and is evaluated by Scale Computing on a per-customer scenario basis.
|
NVMe, SSD
|
|
|
|
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
|
NVMe PCIe: Read/Write Cache
SSD: Persistent Storage
Pivot3 Acuity X5 Accelerator nodes have either a 1.6TB/1.92TB (X5-6500) or 3.2TB/3.8TB (X5-X2500) NVMe PCIe Flash card.
The 1.6TB NVMe PCIe Flash card in an Acuity X5 Accelerator node (X5-6500) is segmented in:
Write Cache Primary: 560GB
Write Cache Partner Replica: 560GB
Read-Warm Cache: 480GB
The 3.2TB NVMe PCIe Flash card in an Acuity X5 Accelerator node (X5-X2500) is segmented in:
Write Cache Primary: 1,120GB
Write Cache Partner Replica: 1,120GB
Read-Warm Cache: 960GB
X5 Hybrid SSDs: 2x 400GB are a caching tier as part of the Erasure Coding process
X5 All-Flash SSDs: 400GB/480GB/800GB/960GB/1.6TB/1.9TB/3.8TB
A Pivot3 Acuity X5 Hybrid node holds 2 SSDs and 12 HDDs.
A Pivot3 Acuity X5 All-Flash node holds 8 SSDs.
Pivot3 Acuity X3 Accelerator nodes (X3-2500; X3-6500) have either an 960GB 2.5-inch PCIe SSD (U.2) or an 1.6TB NVMe PCIe Flash card.
X3 Hybrid SSD: 1x 400GB is a caching tier as part of the Erasure Coding process
X3 All-Flash SSDs: 960GB/1.9TB/3.8TB
A Pivot3 Acuity X3 Hybrid node holds 1 SSD and 8 HDDs.
A Pivot3 Acuity X3 All-Flash node holds 8 SSDs.
|
|
|
|
No limit, up to 1 PB per device
The definition of a device here is a raw flash device that is presented to SANsymphony as either a SCSI LUN or a SCSI disk.
|
Hybrid: 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.
|
All-flash:
X5-6500: 1x NVMe AIC/PCIe +16x SSD
X3-6500: 1x NVMe U.2 + 8x SSD
X5-6000: 16x SSD
X3-6000: 8x SSD
Hybrid:
X5-2500: 1x NVMe AIC/PCIe + 2x SSD
X3-2500: 1x NVMe U.2/PCIe + 1x SSD
X5-2000 2x SSD
X3-2000 1x SSD
Pivot3 Acuity X5 Accelerator nodes have either a 1.6TB or 3.2TB NVMe Flash device.
The 1.6TB NVMe PCIe Flash card in an Acuity X5 Accelerator node is segmented in:
Write Cache Primary: 560GB
Write Cache Partner Replica: 560GB
Read-Warm Cache: 480GB
The 3.2TB NVMe PCIe Flash card in an Acuity X5 Accelerator node is segmented in:
Write Cache Primary: 1,120GB
Write Cache Partner Replica: 1,120GB
Read-Warm Cache: 960GB
X5 Hybrid SSDs: 2x 400GB are a caching tier as part of the Erasure Coding process
X5 All-Flash SSDs: 400GB/480GB/800GB/960GB/1.6TB/1.9TB/3.8TB
A Pivot3 Acuity X5 Hybrid node holds 2 SSDs and 12 HDDs.
A Pivot3 Acuity X5 All-Flash node holds 16 SSDs.
Pivot3 Acuity X3 Accelerator nodes have either a 960GB 2.5-inch or a 1.6TB NVMe Flash device.
X3 Hybrid SSD: 1x 400GB is a caching tier as part of the Erasure Coding process
X3 All-Flash SSDs: 960GB/1.9TB/3.8TB
A Pivot3 Acuity X3 Hybrid node holds 1 SSD and 8 HDDs.
A Pivot3 Acuity X3 All-Flash node holds 8 SSDs.
|
|
|
|
Magnetic |
|
|
|
|
SAS or SATA
SAS = 10k or 15k RPM = Medium-capacity medium-speed drives
SATA = NL-SAS = 7.2k RPM = High-capacity low-speed drives
In this case SATA = NL-SAS = MDL SAS
|
Hybrid: SATA
SAS = 10k or 15k RPM = Medium-capacity medium-speed drives
SATA = NL-SAS = 7.2k RPM = High-capacity low-speed drives
|
Hybrid: SATA
SATA = NL-SAS = 7.2k RPM = High-capacity low-speed drives
|
|
|
|
Persistent Storage
|
Persistent Storage
|
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.
|
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.
|
X3 Hybrid: 12 SATA HDDs per host/node
X5 Hybrid: 8 SATA HDDs per host/node
A Pivot3 Acuity X5 Hybrid node holds 2 SSDs for caching and 12 HDDs for storage of persistent data.
A Pivot3 Acuity X3 Hybrid node holds 1 SSD for caching and 8 HDDs for storage of persistent data.
|
|
|
Data Availability
|
|
|
|
|
|
|
Reads/Writes |
|
|
|
Persistent Write Buffer
Details
|
DRAM (mirrored)
If caching is turned on (default=on), any write will only be acknowledged back to the host after it has been succesfully stored in DRAM memory of two separate physical SANsymphony nodes. Based on de-staging algorithms each of the nodes eventually copies the written data that is kept in DRAM to the persistent disk layer. Because DRAM outperforms both flash and spinning disks the applications experience much faster write behavior.
Per default, the limit of dirty-write-data allowed per Virtual Disk is 128MB. This limit could be adjusted, but there has never been a reason to do so in the real world. Individual Virtual Disks can be configured to act in write-through mode, which means that the dirty-write-data limit is set to 0MB so effectively the data is directly written to the persistent disk layer.
DataCore recommends that all servers running SANsymphony software are UPS protected to avoid data loss through unplanned power outages. Whenever a power loss is detected, the UPS automatically signals this to the SANsymphony node and write behavior is switched from write-back to write-through mode for all Virtual Disks. As soon as the UPS signals that power has been restored, the write behavior is switched to write-back again.
|
Flash/HDD
The persisent write buffer depends on the type of the block storage pool (Flash or HDD).
|
NVMe PCIe (mirrored)
NVMe PCIe serves as a very performant storage medium for a read/write mirrored journal that is split between two accelerator nodes.
When an application sends a write request, it is mirrored between the NVMe PCIe flash cards on two Acuity X3/X5 Accelerator nodes for high availability and redundancy. Once both copies are stored, the receiving node acknowledges the write completion to the host. Once the write is acknowledged, the system will copy the data from NVMe PCIe flash to disk (HDD or SSD). Reads, writes, and modifies of the original copy occur in NVMe PCIe flash. At this point, the copy on disk is only used in the event that a rebuild on the NMVe PCIe flash tier is required. Lastly, if the data that is stored in NVMe PCIe flash is not being accessed frequently, the Acuity X5 node will evict it to make room for more active data based on the QoS priorities and targets. The decision to evict data is made in real-time based on access patterns, current performance levels and data-reduction ratios.
NVMe flash is able to deliver 2x the performance of 12Gbps SAS and up to 6x the performance of 6Gbps SATA.
Pivot3 Acuitys platform architecture requires two Flash Accelerator nodes to be part of any virtual Performance Group (vPG aka 'cluster'), regardless if SSD or HHD is placed underneath.
NVMe = Non-volatile memory express
PCIe = Peripheral Component Interconnect Express
|
|
|
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.
|
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.
|
Erasure Coding (EC1/EC3/EC5)
Global Virtual Sparing
The Pivot3 Acuity platform leverages patented Erasure Coding technology. Pivot3 Acuity Erasure Coding requires at least 3 nodes in a vPG. Pivot3 Acuity Erasure Coding is configured on a per volume basis, so EC levels can be mixed within the same vPG.
Configurable Erasure Coding levels:
EC1: Protects against 1 disk failure event OR 1 node failure event.
EC3: Protects against 3 simultaneous disk failure events OR 1 drive failure event + 1 node failure event.
EC5: Protects against 5 simultaneous disk failure events OR 2 drive failure events + 1 node failure event.
The Pivot3 Acuity platform also leverages a patented Global Virtual Sparing methodology. Whenever a volume is created, it is known what the required capacity for sparing is. Therefore, a small percentage of every drive is reserved for this capacity, meaning that a virtual spare spanning the entirety of the cluster, is created for each volume.
Global Virtual Sparing has two major advantages:
- The overall net capacity is significantly improved, since there is no longer the requirement for a single drive per node to be reserved for sparing. Also, as the system scales, the percentage required for sparing on each
drive decreases and more capacity is made available for application data.
- Since every drive has a small amount of sparing reservation, the performance impact of the failure and the
subsequent data migration or rebuild is distributed across all of the other drives in the vPG. This significantly improves rebuild times and reduces the performance impact on the system during failure conditions.
|
|
|
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.
|
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.
|
Erasure Coding (N+1/N+3/N+5)
The Pivot3 Acuity platform leverages patented Erasure Coding technology. Pivot3 Acuity Erasure Coding requires at least 3 nodes in a vPG. Pivot3 Acuity Erasure Coding is configured on a per volume basis, so EC levels can be mixed within the same vPG.
Configurable Erasure Coding levels:
EC1: Protects against 1 disk failure event OR 1 node failure event.
EC3: Protects against 3 simultaneous disk failure events OR 1 drive failure event + 1 node failure event.
EC5: Protects against 5 simultaneous disk failure events OR 2 drive failure events + 1 node failure event.
|
|
|
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.
|
Not relevant (1U/2U appliances)
|
Not relevant (1-node chassis only)
Pivot3 Acuity X5 compute+storage building blocks are based on 1-node 2U (X5) or 1-node 1U (X3) chassis only. Therefore multi-node block (appliance) level protection is not relevant for this solution as Node Failure Protection applies.
|
|
|
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.
|
N/A
|
N/A
|
|
|
Protection Capacity Overhead
Details
|
Mirroring (2N) (primary): 100%
Mirroring (3N) (primary): 200%
+ Hardware RAID5/6 overhead (optional)
|
Mirroring (2N) (primary): 100%
|
EC1: 9%-51%
EC3: 25%-72%
EC5: 36%-92%
The EC configuration depends on the storage setup (hybrid vs. all-flash) as well as the number of nodes in the Pivot3 Acuity cluster. Storage efficiency increases with scale, up to 16 nodes with only 9% capacity overhead for EC1 protection.
|
|
|
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 (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.
|
Metadata verification (software)
Predictive drive analysis (software)
Disk scrubbing (software)
The Pivot3 Acuity platform utilizes the following mechanisms to prevent data corruption:
- Metadata verification via checksums. Metadata is replicated across nodes. Metadata is also replicated within the node.
- Metadata validation on load. Self-check and version control.
- Predictive drive failure analysis.
- Background disk scrub with error recovery from EC.
- Write-error will fail drive.
Pivot3 Acuity has a built-in predictive drive analysis function to monitor a number of aspects around drive performance within the virtual Performance Group (vPG). By proactively monitoring disk health for CRC errors, drive seek times, IO response times and a host of Smart Drive Functions, it is possible to predict, and therefore proactively, fail a drive within the vPG.
|
|
|
|
Points-in-Time |
|
|
|
|
Built-in (native)
|
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.
|
Built-in (native)
Pivot3 Acuity provides:
- VSS integrated snapshots.
- VMware integrated snapshots.
|
|
|
|
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)
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).
|
Local + Remote
Pivot3 Acuity data protection capabilities are integrated in its approach to snapshot-based remote replication, so there is no need for additional Point-in-Time (PiT) capabilities.
Traditional snapshots can still be created using the features natively available in the hypervisor platform (eg. VMware Snapshots).
|
|
|
Snapshot Frequency
Details
|
1 Minute
The snapshot lifecycle can be automatically configured using the integrated Automation Scheduler.
|
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.
|
GUI: 15 minutes (Policy-based)
Timing options of the Pivot3 Acuity native snapshot capacility include:
- Minutes
- Hours
- Days
- Weeks
- Months
Snapshots can be taken every 'x' minutes/hours/days/weeks/months and 1-50 or unlimited snapshot copies can be retained.
|
|
|
Snapshot Granularity
Details
|
Per VM (Vvols) or Volume
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
Although DataCore SANsymphony uses block-storage, the platform is capable of attaining per VM-granularity if desired.
In Microsoft Hyper-V environments, when a VM with vdisks is created through SCVMM, DataCore can be instructed to automatically carve out a Virtual Disk (=storage volume) for every individual vdisk. This way there is a 1-to-1 alignment from end-to-end and snapshots can be created on the VM-level. The per-VM functionality is realized by installing the DataCore Storage Management Provider in SCVMM.
Because of the per-host storage limitations in VMware vSphere environments, VVols is leveraged to provide per VM-granularity. DataCore SANsymphony Provider v2.01 is certified for VMware ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
|
Per VM
|
Per Volume
Pivot3 Acuity provides:
- Volume recovery from snapshot clone
- File/Folder recovery from snapshot clone
Cloning from a snapshot requires only a single click in the GUI.
|
|
|
|
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)
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.
|
Built-in (native)
By combining Pivot3 Acuitys native snapshot feature with its native remote replication mechanism, backup copies can be created on remote Pivot Acuity vPGs (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, Pivot3 Acuity can be used in conjuntion with external data protection solutions like VMwares free-of-charge vSphere Data Protection (VDP) backup software, as well as any hypervisor compatible 3rd party backup application. VDP is part of the vSphere license and requires the deployment of virtual backup appliances on top of vSphere.
No specific integration exists between Pivot3 Acuity and VMware VDP.
|
|
|
|
Local or Remote
All available storage within the SANsymphony group can be configured as targets for back-up jobs.
|
Locally
To remote sites
|
To local and remote clusters
To remote cloud object stores (Amazon S3)
Pivot3 Acuity supports remote replication of storage snapshots to another Acuity vPG (cluster) within the same datacenter or in a remote datacenter.
Pivot3 Acuity supports remote replication of storage snapshots to a Pivot3 Acuity appliance hosted on Amazon Web Services (AWS). Pivot3 Cloud Edition is an Amazon EC2 instance that uses Amazon S3 storage for storing incoming data from on-premises Pivot3 Acuity deployments. It can serve as an off-site repository for short-term and long-term backups, as well as hosting a DR copy. Pivot3 Cloud Edition is deployed as an Amazon Machine Image (AMI) so there is no manual installation involved.
All Pivot3 AWS appliances are currently deployed as t2.2xlarge (8 vCPUs; 32GB RAM) EC2 instances with EBS st1 (2/4/8/16TB HDD) for data storage and EBS gp2 (200GB SSD) for journal space.
Pivot3 AWS cloud appliances can be managed from the vCenter Plugin.
EBS = Elastic Block Storage
|
|
|
|
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.
|
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.
|
15 minutes (Asynchronous)
In the Pivot3 Acuity platform the backup/restore function is integrated with remote replication. This means that the minimum backup frequency is the same as the minimum remote replication frequency which is 15 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
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.
|
File System Consistent (Windows); Application Consistent (MS Apps on Windows)
Pivot3 Acuity provides the option to enable Microsoft VSS integration when configuring a backup policy. This ensures application-consistent backups are created for MS Exchange and MS SQL database environments.
Pivot3 Acuity also integrates with VMware vCenter to create software snapshots of VMs before taking hardware snapshots of volumes in order to maintain data consistency.
|
|
|
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 VM
Although Scale Computing HC3 uses block-storage, the platform is capable of attaining per VM-granularity.
|
Entire Volume (snapshots/backups)
In the Pivot3 Acuity platform the backup/restore function is integrated with remote replication. This means that the granularity of both is tied to the volume level.
|
|
|
Restore Ease-of-use
Details
|
Entire VM or Volume: GUI
Single File: Multi-step
Restoring VMs or single files from volume-based storage snapshots requires a multi-step approach.
For file-level restores a Virtual Disk snapshot needs to be mounted so the file can be read from the mount. Many simultaneous rollback points for the same Virtual Disk can coexist at the same time, allowing end-users to compare data states. Mounting and changing rollback points does not alter the original Virtual Disk.
|
Entire VM: Multi-step
Single File: Multi-step
Restoring VMs or single files from HC3 storage snapshots requires a multi-step approach.
For file-level restores a VM snapshot needs to be cloned and mounted so the file can be read from the mount. Cloning and mounting does not alter the original VM snapshot.
|
Entire VM: GUI
Single File: Multi-step
Snapshots can be recovered as complete volumes.
To be able to peer into a volume snapshot in order to recover individual files/folders/VMs, the snapshot must first be mounted to a recovery host (not the live host).
|
|
|
|
Disaster Recovery |
|
|
|
Remote Replication Type
Details
|
Built-in (native)
DataCore SANsymphonys remote replication function, Asynchronous Replication, is called upon when secondary copies will be housed beyond the reach of Synchronous Mirroring, as in distant Disaster Recovery (DR) sites. It relies on a basic IP connection between locations and works in both directions. That is, each site can act as the disaster recovery facility for the other. The software operates near-synchronously, meaning that it does not hold up the application waiting on confirmation from the remote end that the update has been stored remotely.
|
Built-in (native)
All HC3 source and target clusters that will be participating in remote replication must run the same HCOS version. It is possible to replicate between a tiered and non-tiered HC3 cluster.
HC3 remote replication uses network compression by default.
|
Built-in (native)
Pivot3 Acuity is capable of protecting individual volumes and groups of volumes by using a-synchronous remote replication techniques.
Once protection has been set up for a volume, Pivot3 Acuity periodically takes a replication snapshot of storage volume on the local cluster and replicates (copies) the snapshot to the paired remote cluster. In the event of a disaster at the local cluster, the most recently replicated snapshot of each protected volume is recovered at the remote cluster.
Optionally Pivot3 Acuity can quiesce the virtual machines through VMware vCenter integration before taking the replication snapshot.
|
|
|
Remote Replication Scope
Details
|
To remote sites
To MS Azure Cloud
On-premises deployments of DataCore SANsymphony can use Microsoft Azure cloud as an added replication location to safeguard highly available systems. For example, on-premises stretched clusters can replicate a third copy of the data to MS Azure to protect against data loss in the event of a major regional disaster. Critical data is continuously replicated asynchronously within the hybrid cloud configuration.
To allow quick and easy deployment a ready-to-go DataCore Cloud Replication instance can be acquired through the Azure Marketplace.
MS Azure can serve only as a data repository. This means that VMs cannot be restored and run in an Azure environment in case of a disaster recovery scenario.
|
To remote sites
To Google Cloud Platform (GCP)
Network latency between the source and HC3 target clusters should be below 2,000ms (2 seconds).
Scale Computing HC3 Cloud Unity DRaaS: This disaster recovery as a service offering provides an HC3 DR target running securely in Google Cloud Platform (GCP). Workloads can be replicated to the Google cloud for failover or recovery on a per VM basis. HC3 Cloud Unity DRaaS uses L2 networking to provide seamless connectivity between on-prem and remote hosted VMs in the event of failover. HC3 Cloud Unity DRaaS includes ScaleCare support at every stage to assist in setup, testing, failover, and recovery. The service also comes with a runbook to assist with both planning and execution. When needed, all protected VMs can be failed over and running in the cloud and then failed back once the on-prem resources are restored. The Recovery Point Objective (RPO) is 4 hours for recovery of the first VM on GCP.
HC3 Cloud Unity DRaaS requires a monthly subscription that is in part based on GCP resource usage (compute, storage, network).
|
To remote sites
To AWS Cloud
Pivot3 Acuity provides Data Protection QoS Policies for easily configuring enhanced remote replication. Remote replication can be leveraged for off-site backup needs and disaster recovery requirements.
Currently AWS can only serve as a data repository. This means that VMs cannot be restored and run in the AWS environment in case of a disaster recovery scenario.
Pivot3 Cloud Edition is an Amazon EC2 instance that uses Amazon S3 storage for storing incoming data from on-premises Pivot3 Acuity deployments. It can serve as an off-site repository for short-term and long-term backups, as well as hosting a DR copy. Pivot3 Cloud Edition is deployed as an Amazon Machine Image (AMI) so there is no manual installation involved.
|
|
|
Remote Replication Cloud Function
Details
|
Data repository
All public clouds can only serve as data repository when hosting a DataCore instance. This means that VMs cannot be restored and run in the public cloud environment in case of a disaster recovery scenario.
In the Microsoft Azure Marketplace there is a pre-installed DataCore instance (BYOL) available named DataCore Cloude Replication.
BYOL = Bring Your Own License
|
DR-site (GCP)
All protected VMs can be failed over and running in the cloud and then failed back once the on-prem resources are restored.
Scale Computing HC3 Cloud Unity DRaaS leverages Google Cloud Platform (GCP) as a DR-site. All traffic between the on-premises HC3 environment and GCP utilizes an encrypted connection, authenticated via pre-shared key. Only changed blocks are transmitted. Replicated data remains solely in the zone chosen to run the HC3 Cloud instance in.
Current HC3 Cloud Unity/Google Datacenter Locations:
- United States: Iowa, South Carolina, Oregon
- Canada: Montreal
- Europe: Belgium, London, Frankfurt
|
Data repository (AWS)
Currently AWS can only serve as a data repository. This means that VMs cannot be restored and run in the AWS environment in case of a disaster recovery scenario.
|
|
|
Remote Replication Topologies
Details
|
Single-site and multi-site
Single Site DR = 1-to-1
Multiple Site DR = 1-to many, many-to 1
|
Single-site and multi-site
Single Site DR = 1-to-1
Multiple Site DR = 1-to many, many-to 1
Scale Computing HC3 supports 1-to-1 replication as well as many-to-1 replication. 1-to-1 replication includes support for cross-replication between two systems, meaning source-to-target and target-to-source. 1-to-many replication means that different VMs from one system can be replicated to different remote systems; with HC3 the same VM cannot be replicated to different remote systems. Many-to-1 means that multiple source systems can replicate VMs to the same target system. A maximum of 25 HC3 source systems can replicate to a single HC3 target system.
|
Single-site and multi-site
Single Site DR = 1-to-1
Multiple Site DR = 1-to many, many-to 1
Pivot3 Acuity supports many replication relationships:
1:1 - Source/Target
1:1 - Self (same vPG)
1:N - Fan Out
N:1 - Fan In
N:N - Matrixed
Up to 5 simultaneous replication targets can be configured per volume.
|
|
|
Remote Replication Frequency
Details
|
Continuous (near-synchronous)
SANsymphony Asynchronous Replication is not checkpoint-based but instead replicates continuously. This way data loss is kept to a minimum (seconds to minutes). End-users can inject custom consistency checkpoints based on CDP technology which has no minimum time slot/frequency.
|
5 minutes
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.
ScaleCare Support recommends a snapshot frequency of 15 minutes as a general best practice.
|
15 minutes (Asynchronous)
The minimum frequency per replication task is 15 minutes.
|
|
|
Remote Replication Granularity
Details
|
VM or Volume
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
Although DataCore SANsymphony uses block-storage, the platform is capable of attaining per VM-granularity if desired.
In Microsoft Hyper-V environments, when a VM with vdisks is created through SCVMM, DataCore can be instructed to automatically carve out a Virtual Disk (=storage volume) for every individual vdisk. This way there is a 1-to-1 alignment from end-to-end and snapshots can be created on the VM-level. The per-VM functionality is realized by installing the DataCore Storage Management Provider in SCVMM.
Because of the per-host storage limitations in VMware vSphere environments, VVols is leveraged to provide per VM-granularity. DataCore SANsymphony Provider v2.01 is VMware certified for ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
|
VM
Excluding virtual disks from VM is a feature that is still in testing and must currently be done by engaging Support and discussing the options and considerations required.
|
Volume
Up to five protection policies can be assigned to a single volume. A single protection policy can have up to 3 Tasks.
The idea of multiple Tasks is similar to setting up backup retention policies using a grandfather-father-son approach, each with different snapshotting frequencies and number recovery points that need to be retained.
|
|
|
Consistency Groups
Details
|
Yes
SANsymphony provides the option to use Virtual Disk Grouping to enable end-users to restore multiple Virtual Disks to the exact same point-in-time.
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
|
No
|
Yes
Pivot3 Acuity supports application-aware consistency groups (VSS/vCenter) where the Pivot3 software sorts out the consistency group relationships. Pivot3 Acuity also support user-defined groupings that will group together multiple volumes for coordinated recovery point creation.
|
|
|
|
VMware SRM (certified)
DataCore provides a certified Storage Replication Adapter (SRA) for VMware Site Recovery Manager (SRM). DataCore SRA 2.0 (SANsymphony 10.0 FC/iSCSI) shows official support for SRM 6.5 only. It does not support SRM 8.2 or 8.1.
There is no integration with Microsoft Azure Site Recovery (ASR). However, SANsymphony can be used with the control and automation options provided by Microsoft System Center (e.g. Operations Manager combined with Virtual Machine Manager and Orchestrator) to build a DR orchestration solution.
|
HC3 Cloud Unity (native)
HC3 Cloud Unity DRaaS is a complete cloud service that provides a Disaster Recovery (DR) runbook outlining DR procedures.
DR testing involves cloning a replicated VM snapshot on a remote cluster and booting the clone.
Cloud Unity DRaaS is available in the following Google Regions:
United States: Iowa, South Carolina, Oregon
Canada: Montreal
Europe: Brussels, London, Frankfurt
HyperCore 8.5.1 introduced a bulk action allowing the cloning of Replication Target VMs.
|
VMware SRM (certified)
NEW
Pivot3 provides a certified Storage Replication Adapter (SRA) for VMware Site Recovery Manager (SRM). Pivot3 SRA 10.6.1 shows official support for SRM 8.2 and 8.1.
The Pivot3 SRA is compatible with Acuity X3/X5 2000/2500/6000/6500 nodes.
|
|
|
Stretched Cluster (SC)
Details
|
VMware vSphere: Yes (certified)
DataCore SANsymphony is certified by VMware as a VMware Metro Storage Cluster (vMSC) solution. For more information, please view https://kb.vmware.com/kb/2149740.
|
N/A
At this time Scale Computing does not support HC3 clusters that are stretched across data centers.
|
N/A
At this time Pivot3 does not support Acuity X5 clusters that are stretched across data centers.
|
|
|
|
2+sites = two or more active sites, 0/1 or more tie-breakers
Theoretically up to 64 sites are supported.
SANsymphony does not require a quorum or tie-breaker in stretched cluster configurations, but can be used as an optional component. The Virtual Disk Witness can provide a tie-breaker role if for instance redundant inter site paths are not implemented. The tie-breaker node (server or device) must be other than the two nodes presenting a virtual disk. Access to the Virtual Disk Witness is leading for storage node behavior.
There are 3 ways to configure the stretched cluster without any tie-breakers:
1. Default: in a split-brain scenario both sides stay active allowing upper infrastructure layers (OS/database/application) to make a decision (eg. clustering principles). In any case SANsymphony prevents a merge when there is a risk to data integrity, and the end-user has to make the choice on how to proceed next (which side is true)
2. Select one side to go inaccessible
3. Select both sides to go inaccessible.
|
N/A
At this time Scale Computing does not support HC3 clusters that are stretched across data centers.
|
N/A
At this time Pivot3 does not support Acuity X5 clusters that are stretched across data centers.
|
|
|
|
<=5ms RTT (targeted, not required)
RTT = Round Trip Time
In truth the user/app with the least tolerated write latency defines the acceptable RTT or distance. In practice
|
N/A
At this time Scale Computing does not support HC3 clusters that are stretched across data centers.
|
N/A
At this time Pivot3 does not support Acuity X5 clusters that are stretched across data centers.
|
|
|
|
<=32 hosts at each active site (per cluster)
The maximum is per cluster. The SANsymphony solution can consist of multiple stretched clusters with a maximum of 64 nodes each.
|
N/A
At this time Scale Computing does not support HC3 clusters that are stretched across data centers.
|
N/A
At this time Pivot3 does not support Acuity X5 clusters that are stretched across data centers.
|
|
|
SC Data Redundancy
Details
|
Replicas: 1N-2N at each active site
DataCore SANsymphony provides enhanced stretched cluster availability by offering local fault protection with In Pool Mirroring. With In Pool Mirroring you can choose to mirror the data inside the local Disk Pool as well as mirror the data across sites to a remote Disk Pool. In the remote Disk Pool data is then also mirrored. All mirroring happens synchronously.
1N-2N: With SANsymphony Stretched Clustering, there can be either 1 instance of the data at each site (no In Pool Mirroring) or 2 instances of the data a each site (In Pool RAID-1 Mirroring).
|
N/A
At this time Scale Computing does not support HC3 clusters that are stretched across data centers.
|
N/A
At this time Pivot3 does not support Acuity X5 clusters that are stretched across data centers.
|
|
|
Data Services
|
|
|
|
|
|
|
Efficiency |
|
|
|
Dedup/Compr. Engine
Details
|
Software (integration)
NEW
SANsymphony provides integrated and individually selectable inline deduplication and compression. In addition, SANsymphony is able to leverage post-processing deduplication and compression options available in Windows 2016/2019 as an alternative approach.
|
Software
Scale Computing HC3 is able to leverage native background data deduplication to reduce the physical space occupied by virtual disks.
The storage details available in the HC3 Web interface provide information on efficiency gains resulting from deduplication.
|
Software
Pivot3 Acuity includes data reduction technology, an inline pattern recognition engine that compresses and deduplicates incoming data. Acuity software recognizes common patterns in the data stream and immediately strips them at an individual block level.
|
|
|
Dedup/Compr. Function
Details
|
Efficiency (space savings)
Deduplication and compression can provide two main advantages:
1. Efficiency (space savings)
2. Performance (speed)
Most of the time deduplication/compression is primarily focussed on efficiency.
|
Efficiency (space savings)
Deduplication and compression can provide two main advantages:
1. Efficiency (space savings)
2. Performance (speed)
Most of the time deduplication/compression is primarily focussed on efficiency.
|
Efficiency and Performance
Deduplication and compression can provide two main advantages:
1. Efficiency (space savings)
2. Performance (speed)
Most of the time deduplication/compression is primarily focussed on efficiency.
Pivot3 focusses on both aspects.
|
|
|
Dedup/Compr. Process
Details
|
Deduplication: Inline (post-ack)
Compression: Inline (post-ack)
Deduplication/Compression: Post-Processing (post process)
NEW
Deduplication can be performed in 4 ways:
1. Immediately when the write is processed (inline) and before the write is ackowledged back to the originator of the write (pre-ack).
2. Immediately when the write is processed (inline) and in parallel to the write being acknowledged back to the originator of the write (on-ack).
3. A short time after the write is processed (inline) so after the write is acknowleged back to the originator of the write - eg. when flushing the write buffer to persistent storage (post-ack)
4. After the write has been committed to the persistent storage layer (post-process).
The first and second methods, when properly integrated into the solution, are most likely to offer both performance and capacity benefits. The third and fourth methods are primarily used for capacity benefits only.
DataCore SANSymphony 10 PSP12 and above leverage both inline deduplication and compression, as well as post process deduplication and compression techniques.
With inline deduplication incoming writes first hit the memory cache of the primary host and are replicated to the cache of a secondary host in an un-deduplicated state. After the blocks have been written to both memory caches, the primary host acknowledges the writes back to the originator. Each host then destages the written blocks to the persistent storage layer. During destaging, written blocks are deduplicates and/or compressed.
Windows Server 2019 deduplication is performed outside of IO path (post-processing) and is multi-threaded to speed up processing and keep performance impact minimal.
|
Post-Processing
Deduplication can be performed in 4 ways:
1. Immediately when the write is processed (inline) and before the write is ackowledged back to the originator of the write (pre-ack).
2. Immediately when the write is processed (inline) and in parallel to the write being acknowledged back to the originator of the write (on-ack).
3. A short time after the write is processed (inline) so after the write is acknowleged back to the originator of the write - eg. when flushing the write buffer to persistent storage (post-ack)
4. After the write has been committed to the persistent storage layer (post-process).
The first and second methods, when properly integrated into the solution, are most likely to offer both performance and capacity benefits. The third and fourth methods are primarily used for capacity benefits only.
The Scale Computing HC3 data deduplication feature is considered a post-process implementation that works with existing background processes to identify duplicate 1 MiB blocks of data on a given physical disk. The process leverages the SCRIBE metadata reference count mechanism by finding independently written blocks that are the same. This duplicate review is for each physical disk on a given node to ensure as little a footprint as possible while providing all of the benefits of full deduplication.
The deduplication process is broken into two steps. The first step reviews VM data blocks by creating a hash index of each block and storing the hash in the nodes RAM. The hashing algorithm will be able to scan the system data for deduplication candidates at roughly 1 MiB/s of data on HDDs and 4 MiB/s of data on SSDs, both of these estimates per node. The second process occurs during low system utilization. The system will work through the queue of hashed blocks in RAM. It will search for matching hashes until the background disk scan regenerates them. When the process finds two blocks with a matching hash it will verify the underlying blocks are in fact duplicates before incrementing the reference count in metadata on the block it is planning to free. Updating the metadata count for the block essentially releases the space of the duplicate block. The block then returns to the system’s free storage pool. This secondary process can progress much faster than 1 MiB/s; the speed is dependent on the current system load.
The SCRIBE metadata reference count mechanism is the same architecture utilized by snapshots and clones in SCRIBE to allow quick, efficient, low-impact thin-provisioning on the HC3 system. Shared blocks are referenced and a count to the block stored in the metadata.
SCRIBE = Scale Computing Reliable Independent Block Engine
|
Deduplication: Inline (on-ack)
Compression: Inline (on-ack)
Deduplication can be performed in 4 ways:
1. Immediately when the write is processed (inline) and before the write is ackowledged back to the originator of the write (pre-ack).
2. Immediately when the write is processed (inline) and in parallel to the write being acknowledged back to the originator of the write (on-ack).
3. A short time after the write is processed (inline) so after the write is acknowleged back to the originator of the write - eg. when flushing the write buffer to persistent storage (post-ack)
4. After the write has been committed to the persistent storage layer (post-process).
The first and second methods, when properly integrated into the solution, are most likely to offer both performance and capacity benefits. The third and fourth methods are primarily used for capacity benefits only.
In the case of Pivot3 the inline on-ack method has both performance and capacity benefits by reducing write amplification by coalescing written data before destaging and by accelerating reads.
Pivot3 uses IO pattern matching as its method of deduplication and compression. This process is inline and happens on IO block acknowledgment; it is performed entirely in memory. As soon as the data is ingested into memory and determined to be a duplicate or compressible, the system adds a metadata pointer to the reference in memory and acknowledges to the host immediately, so processes can continue.
Pivot3 deduplication ans compression is a feature present in both All-flash and Hybrid systems.
|
|
|
Dedup/Compr. Type
Details
|
Optional
NEW
By default, deduplication and compression are turned off. For both inline and post-process, deduplication and compression can be enabled.
For inline deduplication and compression the feature can be turned on per node. The entire node represents a global deduplication domain. Deduplication and compression work across pools and across vDisks. Individual pools can be selected to participate in capacity optimization. Either deduplication or compression or both can be selected per individual vDisk. Pools can host both capacity optimized and non-capacity optimized vDisks at the same time. The optional capacity optimization settings can be added/changed/removed during operation for each vDisk.
For post-processing the feature can be enabled per pool. All vDisks in that pool would be deduplicated and compressed. Each pool is an independent deduplication domain. This means only data in the pool is capacity optimized, but not across pools. Additionally, for post-processing capacity optimization can be scheduled so admins can decide when deduplication should run.
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
|
Always-on
By default Scale Computing HC3 data deduplication is turned on. The platform has been designed to prioritize running workloads over the deduplication tasks to prevent any negative performance impact. As such, the process piggybacks on pre-existing background structures - such as the background disk scrubber - for the hashing process.
|
Always-on
Pivot3 Acuitys data deduplication and compression features are always on and cannot be disabled as it is an integral component of the platform architecture providing both performance and efficiency. It also provides end-user simplicity.
|
|
|
Dedup/Compr. Scope
Details
|
Persistent data layer
|
Persistent data layer
|
Read and Write caches + Persistent data layers
Deduplication and compression is used for optimizing read/write cache and persistent storage capacity.
|
|
|
Dedup/Compr. Radius
Details
|
Pool (post-processing deduplication domain)
Node (inline deduplication domain)
NEW
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
For inline deduplication and compression raw physical disks are added to a capacity optimization pool. The entire node represents a global deduplication domain. Deduplication and compression work across pools and across vDisks. Individual pools can be selected to participate in capacity optimization.
The post-processing capability provided through Windows Server 2016/2019 is highly scalable and can be used with volumes up to 64 TB and files up to 1 TB in size. Data deduplication identifies repeated patterns across files on that volume.
|
Per Node
Scale Computing HC3 data deduplication works on a per node basis. All blocks that are directly written or replicated from another node are deduplicated by the indiviual node independent from other nodes within the same cluster. This way data integrity is ensured for every single node.
|
Storage Cluster (vPG)
Pivot3 Acuity inline deduplication works globally, which means that deduplication happens across all nodes in a vPG (=storage cluster).
A vPG should not be confused with a vSphere cluster. For example: an 8-node vPG can be split into two 4-node vSphere clusters; two 8-node vPGs can be combined to form a 16-node vSphere cluster.
|
|
|
Dedup/Compr. Granularity
Details
|
4-128 KB variable block size (inline)
32-128 KB variable block size (post-processing)
NEW
With inline deduplication and compression, the data is organized in 128 KB segments. Depending on the optimization setting, a write into such a segment first gets compressed (when compression is selected) and then a hash is generated. If the hash is unique, the 128 KB segment is written back and the hash is added to the deduplication hash-table. If the hash is not unique, the segment is referenced in the deduplication hash table and discarded. The smallest chunk in the segment can be 4 KB.
For post-processing the system leverages deduplication in Windows Server 2016/2019, files within a deduplication-enabled volume are segmented into small variable-sized chunks (32–128 KB), duplicate chunks are identified, and only a single copy of each chunk is physically stored.
|
1 MiB
Scale Computing HC3 post-process data deduplication uses 1 MiB fixed block segments.
|
256 KB - 1.5 MB variable block size
Pivot3 Acuity deduplication uses 256K - 1.5MB variable block segments.
|
|
|
Dedup/Compr. Guarantee
Details
|
N/A
Microsoft provides the Deduplication Evaluation Tool (DDPEVAL) to assess the data in a particular volume and predict the dedup ratio.
|
N/A
|
N/A
At this time Pivot3 does no guarantee a minimum savings. Pivot3 states that reduction rates will vary per workload and use case.
|
|
|
|
Full (optional)
Data rebalancing needs to be initiated manually by the end-user. It depends on the specific use case and end-user environment if this makes sense. When end-users want to isolate new workloads and corresponding data on new nodes, data rebalancing is not used.
|
Full (optional)
Data rebalancing needs to be initiated manually by the end-user. It depends on the specific use case and end-user environment if this makes sense.
|
Full
Data is automatically redistributed evenly across all Pivot3 Acuity nodes in the virtual Performance Group (vPG aka 'cluster') when a node is added.
When a node is removed from a Pivot3 Acuity vPG (aka 'cluster'), the Erasure Code calculations are redone in CPU and the data is redistributed as a background process (throttled to minimise impact on performance). Because of the data protections distributed nature, it avoids the pain associated with rebuilding traditional RAID groups.
There is no user-intervention required for any the redistribution activities.
|
|
|
|
Yes
DataCore SANsymphonys Auto-Tiering is a real-time intelligent mechanism that continuously positions data on the appropriate class of storage based on how frequently the data is accessed. Auto-Tiering leverages any combination of Flash and traditional disk technologies, whether it is internal or array based, with up to 15 different storage tiers that can be defined.
As more advanced storage technologies become available, existing tiers can be modified as necessary and additional tiers can be added to further diversify the tiering architecture.
|
Yes
Scale Computing HC3s HyperCore Enhanced Automated Tiering (HEAT) is an extension of the SCRIBE storage layer that is available to HC3 hybrid clusters with 3 nodes or more.
HEAT allows virtual disk level, priority data placement for allocated data (actual consumed capacity on a VM virtual disk). This is accomplished through a real-time heat map of virtual disk I/O in order to “tier” the data. Data blocks that are “hot” (=accessed regularly by the virtual disk) are stored at the SSD level while “colder” data blocks are stored at the HDD level.
There are 4 basic HEAT principles:
1. All VMs have access to SSDs, no matter what node the VM may actually be running on.
2. SSDs are additional capacity for VM disks (subvirtual tiering), not a cache for system data.
3. Administrators have granular control of SSD access at the VM virtual disk level.
4. Administrators are able to mix and match Tiered HC3 nodes with standard HC3 nodes and Storage Only nodes without any extra work or requirements.
The HC3 web interface provides an easy-to-use slide bar on the property page of an individual virtual disk in order to set the flash priority level of a VM’s virtual disk data:
0 Off
1 Minimum
2 Very Low
3 Low
4 Normal (default)
5 High
6 Very High
7 Extreme
8 Absurd
9 Hyperspeed
10 Ludicrous Speed
11 These go to 11
When the flash priority level is set to 0, no data on the virtual disk ever gets promoted to the SSD layer. When the flash priority level is set to 11, all data on the virtual disk is promoted to the SSD layer.
Altering HEAT priority will effect all VM virtual disks within the HC3 cluster. Each increase in flash priority access will dedicate roughly twice as much flash capacity for the VM virtual disk, and consequently reduce the flash capacity available for other VM virtual disks on the system.
|
N/A
The Pivot Acuity storage architecture does not include multiple persistent storage layers, but rather consists of a caching layer (fastest storage devices) and a persistent layer (slower/most cost-efficient storage devices).
|
|
|
|
Performance |
|
|
|
|
vSphere: VMware VAAI-Block (full)
Hyper-V: Microsoft ODX; Space Reclamation (T10 SCSI UNMAP)
DataCore SANsymphony iSCSI and FC are fully qualified for all VMware vSphere VAAI-Block capabilities that include: Thin Provisioning, HW Assisted Locking, Full Copy, Block Zero
Note: DataCore SANsymphony does not support Thick LUNs.
DataCore SANsymphony is also fully qualified for Microsoft Hyper-V 2012 R2 and 2016/2019 ODX and UNMAP/TRIM.
Note: ODX is not used for files smaller than 256KB.
VAAI = VMware vSphere APIs for Array Integration
ODX = Offloaded Data Transfers
UNMAP/TRIM support allows the Windows operating system to communicate the inactive block IDs to the storage system. The storage system can wipe these unused blocks internally.
|
KVM: IOVirt
|
vSphere: VMware VAAI-Block (full)
Pivot3 Acuitys iSCSI is fully qualified for all VMware vSphere VAAI-Block capabilities that include: Thin Provisioning, HW Assisted Locking, Full Copy, Block Zero, UNMAP.
There are some functionality exceptions:
- Boot from SAN is not supported.
- Gaps in LUN sequence is not supported.
- VAAI Thin Provisioning Space Reclamation is not supported.
VAAI = VMware vSphere APIs for Array Integration
|
|
|
|
IOPs and/or MBps Limits
QoS is a means to ensure specific performance levels for applications and workloads. There are two ways to accomplish this:
1. Ability to set limitations to avoid unwanted behavior from non-critical clients/hosts.
2. Ability to set guarantees to ensure service levels for mission-critical clients/hosts.
SANsymphony currently supports only the first method. Although SANsymphony does not provide support for the second method, the platform does offer some options for optimizing performance for selected workloads.
For streaming applications which burst data, it’s best to regulate the data transfer rate (MBps) to minimize their impact. For transaction-oriented applications (OLTP), limiting the IOPs makes most sense. Both parameters may be used simultaneously.
DataCore SANsymphony ensures that high-priority workloads competing for access to storage can meet their service level agreements (SLAs) with predictable I/O performance. QoS Controls regulate the resources consumed by workloads of lower priority. Without QoS Controls, I/O traffic generated by less important applications could monopolize I/O ports and bandwidth, adversely affecting the response and throughput experienced by more critical applications. To minimize contention in multi-tenant environments, the data transfer rate (MBps) and IOPs for less important applications are capped to limits set by the system administrator. QoS Controls enable IT organizations to efficiently manage their shared storage infrastructure using a private cloud model.
More information can be found here: https://docs.datacore.com/SSV-WebHelp/quality_of_service.htm
In order to achieve consistent performance for a workload, a separate Pool can be created where selected vDisks are placed. Alternatively 'Performance Classes' can be assigned to differentiate between data placement of multiple workloads.
|
N/A
Quality-of-Service (QoS) is a means to ensure specific performance levels for applications and workloads. There are two ways to accomplish this:
1. Ability to set limitations to avoid unwanted behavior from non-critical VMs.
2. Ability to set guarantees to ensure service levels for mission-critical VMs.
Scale Computing HC3 currently does not offer any QoS mechanisms.
|
IOPs/MBps/Latency Guarantees (minimums)
QoS is a means to ensure specific performance levels for applications and workloads. There are two ways to accomplish this:
1. Ability to set limitations to avoid unwanted behavior from non-critical clients/hosts.
2. Ability to set guarantees to ensure service levels for mission-critical clients/hosts.
Pivot3 Acuity supports the second method through pre-defined performance policies per volume. These policies can be changed manually on-the-fly or automatically by configuring and assigning schedules.
Available QoS Policies on All-Flash Acuity X5 models:
Policy 1 – Mission Critical – 125,000IOPs 1,000MB/s 1ms
Policy 2 – Business Critical – 75,000IOPs 500MB/s 3ms
Policy 3 – Business Critical – 50,000IOPs 250MB/s 10ms
Policy 4 – Non-Critical – 25,000IOPs 100MB/s 20ms
Policy 5 – Non-Critical – 10,000IOPs 50MB/s 40ms
Available QoS Policies on Hybrid Acuity X5 models:
Policy 1 – Mission Critical – 100,000IOPs 750MB/s 5ms
Policy 2 – Business Critical – 50,000IOPs 375MB/s 10ms
Policy 3 – Business Critical – 20,000IOPs 150MB/s 25ms
Policy 4 – Non-Critical – 10,000IOPs 75MB/s 50ms
Policy 5 – Non-Critical – 2,000IOPs 37.5MB/s 100ms
The pre-defined service levels govern how the QoS engine treats the targets in order to maintain Mission Critical performance, then Business Critical performance and then Non-critical performance.
The pre-defined service levels also govern how the read-warm cache is getting populated:
Policy 1 – Mission Critical – 1 hit per 1MB Region
Policy 2 – Business Critical – 4 hits per 1MB Region
Policy 3 – Business Critical – 16 hits per 1MB Region
Policy 4 – Non-Critical – read-warm disabled
Policy 5 – Non-Critical – read-warm disabled
The pre-defined service levels also govern how read-ahead is used:
Policy 1 – Mission Critical – enabled
Policy 2 – Business Critical – enabled
Policy 3 – Business Critical – enabled
Policy 4 – Non-Critical – read-ahead disabled
Policy 5 – Non-Critical – read-ahead disabled
|
|
|
|
Virtual Disk Groups and/or Host Groups
SANsymphony QoS parameters can be set for individual hosts or groups of hosts as well as for groups of Virtual Disks for fine grained control.
In a VMware VVols (=Virtual Volumes) environment a vDisk corresponds 1-to-1 to a virtual disk (.vmdk). Thus virtual disks can be placed in a Disk Group and a QoS Limit can then be assigned it. DataCore SANsymphony Provider v2.01 has VVols certification for VMware ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
In Microsoft Hyper-V environments, when a VM with vdisks is created through SCVMM, DataCore can be instructed to automatically carve out a Virtual Disk (=storage volume) for every individual vdisk. This way there is a 1-to-1 alignment from end-to-end and QoS Limits can be applied on the virtual disk level. The 1-to-1 allignment is realized by installing the DataCore Storage Management Provider in SCVMM.
|
N/A
Quality-of-Service (QoS) is a means to ensure specific performance levels for applications and workloads. There are two ways to accomplish this:
1. Ability to set limitations to avoid unwanted behavior from non-critical VMs.
2. Ability to set guarantees to ensure service levels for mission-critical VMs.
Scale Computing HC3 currently does not offer any QoS mechanisms.
|
Per volume
Because Pivot3 Acuity presents block-based storage volumes, QoS Policies can be applied to VMware datastores and in-guest iSCSI disks.
|
|
|
|
Per VM/Virtual Disk/Volume
With SANsymphony the rough hierarchy is: physical disk(s) or LUNs -> Disk Pool -> Virtual Disk (=logical volume).
In SANsymphony 'Flash Pinning' can be achieved using one of the following methods:
Method #1: Create a flash-only pool and migrate the individual vDisks that require flash pinning to the flash-only pool. When using a VVOL configuration in a VMware environment, each vDisk represents a virtual disk (.vmdk). This method guarantees all application data will be stored in flash.
Method #2: Create auto-tiering pools with at least 1 flash tier. Assign the Performance Class “Critical” to the vDisks that require flash pinning and place them in the auto-tiering pool. This will effectively and intelligently put as much of the data that resides in the vDisk in the flash tier as long that the flash tier has enough space available. Therefore this method is on a best-effort basis and dependent on correct sizing of the flash tier(s).
Methods #1 and #2 can be uses side-by-side in the same DataCore environment.
|
Per virtual disk
Scale Computing HC3s native HEAT feature allows for data of an individual virtual disk to reside completely in flash storage. This can be administered on-the-fly by setting the Flash priority in the virtual disks properties to 11. The new HEAT priority setting will be immediately activated on the VMs virtual disk.
For more information on HEAT please view the information provided with the 'Data Tiering' capability.
HEAT = HyperCore Enhanced Automated Tiering
|
N/A
|
|
|
|
Security |
|
|
|
Data Encryption Type
Details
|
Built-in (native)
SANsymphony 10.0 PSP9 introduced native encryption when running on Windows Server 2016/2019.
|
N/A
Although the design of the SCRIBE storage management layer provides some general protection for data stored on a
single hard drive, it is not the same as data encryption. If data encryption is required it is recommended to use in-guest encryption tools to ensure data protection.
|
Built-in (native)
Pivot3 Acuity 10.6 introduced native data encryption capabilities for storage volumes, however encryption keys need to be generated by 3rd party security tools (currently only HyTrust KeyControl is supported).
With Acuity data encryption volumes can be encrypted on creation through policy configuration. Pivot3 designed its data encryption algorithms to leverage Intel Xeon CPUs AES New Instructions (AES NI) to ensure minimal performance impact and low overhead. However, as encrypting a volume does cause a small degradation in performance, Pivot3 recommends encrypting only those volumes that contain sensitive information.
Data encryption can also be established using 3rd party security software.
|
|
|
Data Encryption Options
Details
|
Hardware: Self-encrypting drives (SEDs)
Software: SANsymphony Encryption
Hardware: In SANsymphony deployments the encryption data service capabilities can be offloaded to hardware-based SED offerings available in server- and storage solutions.
Software: SANsymphony provides software-based data-at-rest encryption that is XTS-AES 256bit compliant.
|
Hardware: N/A
Software: HyTrust KeyControl + Client (validated); WinMagic SecureDoc CloudVM (validated)
Hardware: N/A
Software: Scale Computing partners with HyTrust to encrypt the drives of Windows and Linux VMs running on a HC3 system. The HyTrust client software that is installed on all VMs that require encryption, can encrypt both boot drives and data drives. Scale Computing has also validated the interoperability of WinMagic SecureDoc CloudVM for encryption of drives of Windows VMs with its HC3 platform.
|
Hardware: N/A
Software: Pivot3 Acuity data encryption; HyTrust DataControl (validated)
Pivot3 Acuity 10.6 introduced native data encryption capabilities for storage volumes, however encryption keys need to be generated by 3rd party security tools (currently only HyTrust KeyControl is supported).
Pivot3 also resells Hytrust software for data encryption.
|
|
|
Data Encryption Scope
Details
|
Hardware: Data-at-rest
Software: Data-at-rest
Hardware: SEDs provide encryption for data-at-rest; SEDs do not provide encryption for data-in-transit.
Software: SANsymphony provides encryption for data-at-rest; it does not provide encryption for data-in-transit. Encryption can be enabled per individual virtual disk.
|
Hardware: N/A
Software: Data-at-rest
|
Hardware: N/A
Software: Data-at-rest (Pivot3); Data-at-rest + Data-in-transit (HyTrust)
Hardware: N/A
Software: Pivot3 Acuity data encryption provides encryption for data-at-rest. The HyTrust encryption solution does provide both encryption for data-at-rest and encryption for data-in-transit.
|
|
|
Data Encryption Compliance
Details
|
Hardware: FIPS 140-2 Level 2 (SEDs)
Software: FIPS 140-2 Level 1 (SANsymphony)
FIPS = Federal Information Processing Standard
FIPS 140-2 defines four levels of security:
Level 1 > Basic security requirements are specified for a cryptographic module (eg. at least one Approved algorithm or Approved security function shall be used).
Level 2 > Also has features that show evidence of tampering.
Level 3 > Also prevents the intruder from gaining access to critical security parameters (CSPs) held within the cryptographic module.
Level 4 > Provides a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.
|
Hardware: N/A
Software: FIPS 140-2 Level 1 (HyTrust; WinMagic)
|
Hardware: N/A
Software: FIPS 140-2 Level 1 (Pivot3;HyTrust)
FIPS = Federal Information Processing Standard
FIPS 140-2 defines four levels of security:
Level 1 > Basic security requirements are specified for a cryptographic module (eg. at least one Approved algorithm or Approved security function shall be used).
Level 2 > Also has features that show evidence of tampering.
Level 3 > Also prevents the intruder from gaining access to critical security parameters (CSPs) held within the cryptographic module.
Level 4 > Provides a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.
|
|
|
Data Encryption Efficiency Impact
Details
|
Hardware: No
Software: No
Hardware: Because data encryption is performed at the end of the write path, storage efficiency mechanisms are not impaired.
Software: Because data encryption is performed at the end of the write path, storage efficiency mechanisms are not impaired.
|
Hardware: N/A
Software: Yes (HyTrust; WinMagic)
FIPS = Federal Information Processing Standard
FIPS 140-2 defines four levels of security:
Level 1 > Basic security requirements are specified for a cryptographic module (eg. at least one Approved algorithm or Approved security function shall be used).
Level 2 > Also has features that show evidence of tampering.
Level 3 > Also prevents the intruder from gaining access to critical security parameters (CSPs) held within the cryptographic module.
Level 4 > Provides a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.
|
Hardware: N/A
Software: No (Pivot3); Yes (HyTrust)
Hardware: N/A
Software: Because Pivot3 Acuity data encryption is a platform-native solution, encryption of data takes place after data deduplication and compression.
Because HyTrust is an end-to-end solution, encryption is performed at the start of the write path and some efficiency mechanisms (eg. deduplication and compression) are effectively negated.
|
|
|
|
Test/Dev |
|
|
|
|
Yes
Support for fast VM cloning via VMware VAAI and Microsoft ODX.
|
Yes
Scale Computing HC3 leverages block reference counting to avoid having to copy blocks of data when creating a clone of a virtual machine. Because block reference counting is integrated in both the storage protocol as well as the RSDs, it is very fast and eliminates a round-trip when performing copy-on-write actions.
The clone feature on a HC3 cluster will create an identical VM to the parent, but with its own unique name and description. The clone VM will be completely independent from the parent VM once it is created.
|
Yes
Native clone creation is VAAI-integrated.
Native clone creation is thin provisioned.
Pivot3 Cloning is a storage technology that enables the rapid creation and customization of multiple cloned VMs from a source VM. The clones can then be used as standalone VMs.
|
|
|
|
Portability |
|
|
|
Hypervisor Migration
Details
|
Hyper-V to ESXi (external)
ESXi to Hyper-V (external)
VMware Converter 6.2 supports the following Guest Operating Systems for VM conversion from Hyper-V to vSphere:
- Windows 7, 8, 8.1, 10
- Windows 2008/R2, 2012/R2 and 2016
- RHEL 4.x, 5.x, 6.x, 7.x
- SUSE 10.x, 11.x
- Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS
- CentOS 6.x, 7.0
The VMs have to be in a powered-off state in order to be migrated across hypervisor platforms.
Microsoft Virtual Machine Converter (MVMC) supports conversion of VMware VMs and vdisks to Hyper-V VMs and vdisks. It is also possible to convert physical machines and disks to Hyper-V VMs and vdisks.
MVMC has been offcially retired and can only be used for converting VMs up to version 6.0.
Microsoft System Center Virtual Machine Manager (SCVMM) 2016 also supports conversion of VMs up to version 6.0 only.
|
HC3 Move
HC3 Move is powered by Carbonite (formerly Double-Take) and allows the migration of physical or virtual Windows and Linux-based server workloads with real-time replication and zero-downtime.
HC3 Move requires the purchase of a one-time-use license per server that needs to be migrated to the Scale Computing HC3 platform.
HC3 Move does not support desktop operating systems.
|
Hyper-V to ESXi (external)
ESXi to Hyper-V (external)
VMware Converter 6.2 supports the following Guest Operating Systems for VM conversion from Hyper-V to vSphere:
- Windows 7, 8, 8.1, 10
- Windows 2008/R2, 2012/R2 and 2016
- RHEL 4.x, 5.x, 6.x, 7.x
- SUSE 10.x, 11.x
- Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS
- CentOS 6.x, 7.0
The VMs have to be in a powered-off state in order to be migrated across hypervisor platforms.
Microsoft Virtual Machine Converter (MVMC) supports conversion of VMware VMs and vdisks to Hyper-V VMs and vdisks. It is also possible to convert physical machines and disks to Hyper-V VMs and vdisks.
MVMC has been offcially retired and can only be used for converting VMs up to version 6.0.
Microsoft System Center Virtual Machine Manager (SCVMM) 2016 also supports conversion of VMs up to version 6.0 only.
|
|
|
|
File Services |
|
|
|
|
Built-in (native)
SANsymphony delivers out-of-box (OOB) file services by leveraging Windows native SMB/NFS and Scale-out File Services capabilities. SANsymphony is capable of simultaneously handling highly-available block and file level services.
Raw storage is provisioned from within the SANsymphony GUI to the Microsoft file services layer, similar to provisioning Storage Spaces Volumes to the file services layer. This means any file services configuration is performed from within the respective Windows service consoles e.g. quotas.
More information can be found under: https://www.datacore.com/products/features/high-availability-nas-cluster-file-sharing.aspx
|
N/A
Scale Computing HC3 does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
N/A
Pivot3 Acuity does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Compatibility
Details
|
Windows clients
Linux clients
Because SANsymphony leverages Windows Server native CIFS/NFS and Scale-out File services, most Windows and Linux clients are able to connect.
|
N/A
Scale Computing HC3 does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
N/A
Pivot3 Acuity does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Interconnect
Details
|
SMB
NFS
Because SANsymphony leverages Windows Server native CIFS/NFS and Scale-out File services, Windows Server platform compatibility applies:
SMB versions1,2 and 3 are supported, as are NFS versions 2, 3 and 4.1.
|
N/A
Scale Computing HC3 does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
N/A
Pivot3 Acuity does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Quotas
Details
|
Share Quotas, User Quotas
Because SANsymphony leverages Windows Server native CIFS/NFS and Scale-out File services, all Quota features available in Windows Server can be used.
|
N/A
Scale Computing HC3 does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
N/A
Pivot3 Acuity does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
Fileserver Analytics
Details
|
Partial
Because SANsymphony leverages Windows Server native CIFS/NFS, Windows Server built-in auditing capabilities can be used.
|
N/A
Scale Computing HC3 does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
N/A
Pivot3 Acuity does not provide any file serving capabilities of its own.
Inside a Guest VM all native file service features of the Microsoft Windows and/or Linux operating system can be leveraged to host network shares.
Linux requires Samba Server components to provide SMB file shares.
Depending on the OS of the Guest VM providing file services, quotas can been set on the share or the filesystem level.
|
|
|
|
Object Services |
|
|
|
Object Storage Type
Details
|
N/A
DataCore SANsymphony does not provide any object storage serving capabilities of its own.
|
N/A
Scale Computing HC3 does not provide any object storage serving capabilities of its own.
|
N/A
Pivot3 Acuity does not provide any object storage serving capabilities of its own.
|
|
|
Object Storage Protection
Details
|
N/A
DataCore SANsymphony does not provide any object storage serving capabilities of its own.
|
N/A
Scale Computing HC3 does not provide any object storage serving capabilities of its own.
|
N/A
Pivot3 Acuity does not provide any object storage serving capabilities of its own.
|
|
|
Object Storage LT Retention
Details
|
N/A
DataCore SANsymphony does not provide any object storage serving capabilities of its own.
|
N/A
Scale Computing HC3 does not provide any object storage serving capabilities of its own.
|
N/A
Pivot3 Acuity does not provide any object storage serving capabilities of its own.
|
|
|
Management
|
|
|
|
|
|
|
Interfaces |
|
|
|
GUI Functionality
Details
|
Centralized
SANsymphonys graphical user interface (GUI) is highly configurable to accommodate individual preferences and includes guided wizards and workflows to simplify administration. All actions available from the GUI may also be scripted with PowerShell Commandlets to orchestrate workflows with other tools and applications.
|
Centralized
Scale Computing HC3 management, capacity monitoring, performance monitoring and efficiency reporting is performed through the HC3 HTML5 web-based user interface.
|
Centralized
Management of the Pivot3 Acuity platform, capacity monitoring, performance monitoring and efficiency reporting can be performed through the Pivot3 vSphere Web Client plug-in.
Other functionality such as snapshots and snapshot schedules are also managed from the Pivot3 vSphere Web Client plug-in.
Pivot3 AWS cloud appliances (Pivot3 Cloud Edition) can also be managed from the Pivot3 vSphere Web Client plug-in.
|
|
|
|
Single-site and Multi-site
|
Single-site and Multi-site
Up to 25 clusters can be manage centrally using the Scale Computing HC3 web-based user interface.
|
Single-site and Multi-site
|
|
|
GUI Perf. Monitoring
Details
|
Advanced
SANsymphony has visibility into the performance of all connected devices including front-end channels, back-end channels, cache, physical disks, and virtual disks. Metrics include Read/write IOPs, Read/write MBps and Read/Write Latency at all levels. These metrics can be exported to the Windows Performance Monitoring (Perfmon) utility where other server parameters are being tracked.
The frequency at which performance metrics can be captured and reported on is configurable, real-time down to 1 second intervals and long term recording at 2 minutes granularity.
When a trend analysis is required, an end-user can simply enable a recording session to capture metrics over a longer period of time.
|
Basic
|
Advanced
The Performance Monitor view provides a view of the activity within the domain that can consist of multiple clusters and each volume within an Acuity Virtual Performance Group (vPG). Metrics that can be viewed are: IOPS, Throughput (MBps) and Latency (ms) for Reads/Writes, Queue Depth and Block Size.
The Performance Diagnostics view provides an in-depth look into the performance metrics of network connections and disk usage for the selected Acuity vPG.
All metrics can be viewed from within the Pivot3 VMware vSphere Web Client plug-in.
|
|
|
|
VMware vSphere Web Client (plugin)
VMware vCenter plug-in for SANsymphony
SCVMM DataCore Storage Management Provider
Microsoft System Center Monitoring Pack
DataCore offers deep integration with VMware vSphere and Microsoft Hyper-V, as well as their respective systems management tools, vCenter and System Center.
SCVMM = Microsoft System Center Virtual Machine Manager
|
Not relevant (Unified interface)
Because Scale Computing HC3 controls the entire Hyperconvergence stack (hypervisor, compute, storage), the HC3 web-based user interface provides all the required management functionality.
|
VMware HTML5 vSphere Client (plugin)
VMware vSphere Web Client (plugin)
The Pivot3 Acuity VMware vSphere Web Client plug-in enabes performing daily storage provisioning and maintance tasks, including:
- viewing local and global system health and statistics
- provisioning and managing storage and performance (QoS policies)
- providing storage protection (QoS policies)
- viewing Acuity storage cluster node details.
The Pivot3 UI is not yet supported on VMware vCenter 6.7.
|
|
|
|
Programmability |
|
|
|
|
Full
Using DataCores native management console, Virtual Disk Templates can be leveraged to populate storage policies. Available configuration items: Storage profile, Virtual disk size, Sector size, Reserved space, Write-trough enabled/disabled, Storage sources, Preferred snapshot pool, Accelerator enabled/disabled, CDP enabled/disabled.
Virtual Disk Templates integrate with System Center Virtual Machine Manager (SCVMM), VMware Virtual Volumes (VVol) and OpenStack. Virtual Disk Templates are also fully supported by the REST-API allowing any third-party integration.
Using Virtual Volumes (VVols) defined through DataCore’s VASA provider, VMware administrators can self-provision datastores for virtual machines (VMs) directly from their familiar hypervisor interface. This is possible even for devices in the DataCore pool that don’t natively support VVols and never will, as SANsymphony can be used as a storage-virtualization layer for these devices/solutions. DataCore SANsymphony Provider v2.01 has VVols certification for VMware ESXi 6.5 U2/U3, ESXi 6.7 GA/U1/U2/U3 and ESXi 7.0 GA/U1.
Using Classifications and StoragePools defined through DataCore’s Storage Management Provider, Hyper-V administrators can self-provision virtual disks and pass-through LUNS for virtual machines (VMs) directly from their familiar SCVMM interface.
|
Full
Scale Computing HC3 leverages Storage Policy-Based Management (SPBM) that allows administrators to build a profile for each VM with regard to protection and for each virtual disk with regard to data tiering.
|
Full
Pivot3 Acuity leverages Storage Policy-Based Management (SPBM) that allows administrators to build a profile for each volume consisting of Virtual Performance Group (vPG), Performance QoS and Protection QoS.
|
|
|
|
REST-APIs
PowerShell
The SANsymphony REST-APIs library includes more than 200 new representational state transfer (REST) operations, so automation can be leveraged more extensively. RESTful interfaces are used by products such as Lenovo XClarity, Cisco Embedded Resource Manager and Dell OpenManage to manage infrastructure in the enterprise.
SANsymphony provides its own Powershell cmdlets.
|
REST-APIs
Apache Thrift
Python executables
Both Scale Computing end-users and ecosystem partners can programmatically manage the HC3 platform by using either REST-APIs, Apache Thrift and/or Python executables.
|
REST-APIs
CLI
|
|
|
|
OpenStack
OpenStack: The SANsymphony storage solution includes a Cinder driver, which interfaces between SANsymphony and OpenStack, and presents volumes to OpenStack as block devices which are available for block storage.
Datacore SANsymphony programmability in VMware vRealize Automation and Microsoft System Center can be achieved by leveraging PowerShell and the SANsymphony specific cmdlets.
|
N/A
Scale Computing HC3 does not provide tight integration with either OpenStack or any automation/orchestration platforms.
|
VMware vRealize Automation (vRA)
Pivot3 provides an Acuity integration package for VMware vRealize Automation (vRA)
|
|
|
|
Full
The DataCore SANsymphony GUI offers delegated administration to secondary users through fine-grained Role-based Access Control (RBAC). The administrator is able to define Virtual Disk ownership as well as privileges associated with that particular ownership. Owners must have Virtual Disk privileges in an assigned role in order to perform operations on the virtual disk. Access can be very refined. For example, one owner may have the privilege to create a snapshot of a virtual disk, but not have the ability to serve or unserve the same virtual disk. Privilege sets define the operations that can be performed. For instance, in order for an owner to perform snapshot, rollback, or replication operations, they would require those privilege sets in an assigned role.
|
Partial
The Scale Computing HC3 GUI offers delegated administration to secondary users through Role-based Access Control (RBAC). The user access level can be changed to “Admin” with full administrator access or customized with a variety of role options that fall in between Read-only and Admin.
The following optional functional roles that represent groupings of funtional tasks, can be assigned:
- Backup - Clone, Export, Import, Add/Pause Replication to a VM, Create/Delete snapshots, and Create/Delete/Modify snapshot schedules.
- Cluster Settings - Create/Modify all settings within Control Center, except for User Management and Control (system/cluster shutdown).
- Cluster Shutdown - Shutdown the system/cluster and any running VMs.
- VM Create/Edit - Import VMs and Create, Modify, Clone, and Add/Modify VM block (virtual disk) and network devices.
- VM Delete - Delete VMs and their associated snapshots and devices.
- VM Power Controls - Start, Shutdown/Power Off, and Live Migrate VMs.
A user can be assigned any number of these optional roles.
|
N/A
Pivot3 Acuity does not provide any end-user self service capabilities of its own.
A self service portal enables end-users to access a portal where they can provision and manage VMs from templates, eliminating administrator requests or activity.
Self-Service functionality can be enabled by leveraging for instance VMware vRealize Automation (vRA). This requires a separate VMware license.
|
|
|
|
Maintenance |
|
|
|
|
Unified
All storage related features and functionality are built into the DataCore SANsymphony platform. The consolidation means, that only one product needs to be installed and upgraded and minimal dependencies exist with other software.
Integration with 3rd party systems (e.g. OpenStack, vSphere, System Center) are delivered seperately but are free-of-charge.
|
Unified
All storage related features and functionality are built into the Scale Computing HC3 platform. The consolidation means, that only one product needs to be installed and upgraded and minimal dependencies exist with other software.
|
Partially Distributed
For a number of features and functions the Pivot3 Acuity platform relies on other components that need to be installed and upgraded next to the core vSphere platform. Examples are backup/restore and remote replication software. As a result some dependencies exist with other software.
|
|
|
SW Upgrade Execution
Details
|
Rolling Upgrade (1-by-1)
Each SANsymphony update is packaged in an installation Wizard which contains a fully guided upgrade process. The upgrade process checks all system requirements and performs a system health before starting the upgrade process and before moving from one node to the next.
The user can also decide to upgrade a SANsymphony cluster manually and follow all steps that are outlined in the Release Notes.
|
Rolling Upgrade (1-by-1)
Scale Computing provides one-click software and firmware upgrades of HC3 nodes that typically takes minutes to complete, while all VMs remain online during the entire upgrade procedure.
|
Rolling Upgrade (1-by-1)
Pivot3 provides GUI-based non-disruptive rolling upgrades of the Acuity platform as well as the underlying server firmware.
The upgrade only gets committed once all nodes within the vPG (aka cluster) are at the same state and the update is stable.
|
|
|
FW Upgrade Execution
Details
|
Hardware dependent
Some server hardware vendors offer rolling upgrade options with their base software or with a premium software suite. With some other server vendors, BIOS and Baseboard Management Controller (BMC) updated have to be performed manually and 1-by-1.
DataCore provides integrated firmware-control for FC-cards. This means the driver automatically loads the required firmware on demand.
|
1-Click
Scale Computing provides one-click software and firmware upgrades of HC3 nodes that typically takes minutes to complete, while all VMs remain online during the entire upgrade procedure.
|
1-Click
Pivot3 provides GUI-based non-disruptive rolling upgrades of the Acuity platform as well as the underlying server firmware.
|
|
|
|
Support |
|
|
|
Single HW/SW Support
Details
|
No
With regard to DataCore SANsymphony as a software-only offering (SDS), DataCore does not offer unified support for the entire solution. This means storage software support (SANsymphony) and server hardware support are separate.
|
Yes
|
Yes
The entire HW/SW solution is owned by Pivot3, so support for all solution components can be provided by a single company.
|
|
|
Call-Home Function
Details
|
Partial (HW dependent)
With regard to DataCore SANsymphony as a software-only offering (SDS), DataCore does not offer call-home for the entire solution. This means storage software support (SANsymphony) and server hardware support are separate.
|
Full
When the Scale Computing HC3 state machines detect failure modes or significant issues, they notify the Scale Computing support group (by default settings) via SNMP. Also, the state machines themselves automatically remediate the issue if possible.
|
Full
Pivot3 Proactive Diagnostics (PPD) is an optional service that allows our products to report diagnostic system metadata to Pivot3 Support. Reported information includes Node health, Protection Group performance, logical volume operational errors, and vSMS reported error diagnostics. No confidential or secure data is conveyed through this feature, and using it is optional. Critical alerts reported as part of the service will generate a Pivot3 Support initiated effort to coordinate remediation with the customer.
|
|
|
Predictive Analytics
Details
|
Partial
Capacity Management: DataCore SANsymphony Analysis and Reporting supports depletion monitoring of the capacity, complements pool space threshold warnings by regularly evaluating the rate of capacity consumption and estimating when space will be depleted. The regularly updated projections give you a chance to add more storage to the pool before you run out of storage. It also helps you do a better job of capacity planning with fewer surprises. To help allocate costs, especially in private cloud and hosted cloud services, SANsymphony generates reports quantifying the storage resources consumed by specific hosts or groups of hosts. The reports tally several parameters.
Health Monitoring: A combination of system health checks and access to device S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) alerts help to isolate performance and disk problems before they become serious.
DataCore Insight Services (DIS) offers additional capabilites including log-analytics for predictive failure analysis and actionable insights - including hardware.
DIS also provides predictive capacity trend analysis in order to pro-actively warn about licensing limitations being reached within x days and/or disk pools running out of capacity.
|
N/A
Scale Computing HC3 does not natively have predictive analytics capabilities.
|
Full
Pivot3 Acuity includes predictive analytics specific to the following areas:
- Proactive supportability: sensor data from multiple components (flash, disk, node, etc) within the system is analysed for predictive failures and self-healing of the system. For instance, if a drive is failing (not yet failed), system will automatically spare it out and phone home order a new one. Also, we analyse and predict when flash wear-out may occur and display/alarm this information to the customer and phone home.
- Capacity and Performance Planning: complete suite of metrics and dashboards available to the customer for capacity (current and predictive future) and performance to aid with expansion planning. All these metrics are included in a daily phone-home package sent to Pivot3 support cloud.
- Realtime IO Path/Data Placement manipulation: every IO is tracked and analysed in order to meet the SLAs defined by the customer via the built-in policy engine. Data placement in the system (RAM, NVMe, SSD, HDD) is governed by policy. The system uses predictive analytics and automation to make sure right IO path queueing and data placement is in effect to meet SLAs. Policy changes can be automated via built-in scheduler and CLI/APIs.
|
|
