ECS - Cloud Storage

Pricing will be 1p/GB for life.

ECS can do detailed billing

Based on storage use only. No ingress/egress charges, unlike AWS.

It is recommended that a load balancer is used in front of ECS.

In addition to distributing the load across ECS cluster nodes, a load balancer provides High Availability (HA) for the ECS cluster by routing traffic to healthy nodes. Where network separation is implemented, and data and management traffic are separated, the load balancer must be configured so that user requests, using the supported data access protocols, are balanced across the IP addresses of the data network. ECS Management REST API requests can be made directly to a node IP on the management network or can be load balanced across the management network for HA.

The load balancer configuration is dependent on the load balancer type.

Configurations for availability, durability, and resilience.

Depending on the number of sites in the ECS system, different data protection schemes can increase availability and balance the data protection requirements against performance. ECS uses the replication group to configure data protection schemes.

Local Protection

Data is protected locally by using triple mirroring and erasure coding which provides resilience against disk and node failures, but not against site failure.

Full Copy Protection

When a replication group is enabled with the Replicate to All Sites property, the replication group makes a full readable copy of all objects to all sites within the replication group. Having full readable copies of objects on all VDCs in the replication group provides data durability and improves local performance at all sites at the cost of storage efficiency.

Geo-Active

Geo-Active is the default ECS configuration. When a replication group is configured as Geo-Active, data is replicated to federated sites and can be accessed from all sites with strong consistency. If you have two sites, full copies of data chunks are copied to the other site. If you have three or more sites, the replicated chunks are combined (XOR'ed) to provide increased storage efficiency. When data is accessed from a site that is not the owner of the data, until that data is cached at the non-owner site, the access time increases. Similarly, if the owner site that contains the primary copy of the data fails, and if you have a global load balancer that directs requests to a non-owner site, the non-owner site must recreate the data from XOR'ed chunks, and the access time increases.

Geo-Passive

The Geo-Passive configuration always includes exactly three sites and is available where you have at least three sites. In this configuration, two sites are active. The third site is passive and is a replication target. You can designate a specific site as the backup site and achieve the storage efficiency (2.0 times storage overhead) of three sites. The storage efficiency is the same as the Geo-Active three-site configuration. In the Geo-Passive configuration, all replication data chunks are sent to the passive site and XOR operations occur only at the passive site. In a Geo-Active configuration, the XOR operations occur at all sites. If all sites are on-premise, any of the three sites can be the replication target. An important use case for the Geo-Passive configuration is when the passive site is hosted by a third party and the hosted site is selected as the replication target. This configuration can be modified by using the ECS Management REST API to select an on-premise site as the replication target.

Storage engine

The storage engine component layer provides an unstructured storage engine that is responsible for storing and retrieving data, managing transactions, and protecting and replicating data. The storage engine provides access to objects ingested using multiple object storage protocols and the NFS and HDFS file protocols.

Fabric

The fabric component layer provides cluster health management, software management, configuration management, upgrade capabilities, and alerting. The fabric layer is responsible for keeping the services running and managing resources such as the disks, containers, firewall, and network. It tracks and reacts to environmental changes such as failure detection and provides alerts related to system health.

Infrastructure

The infrastructure component layer uses SUSE Linux Enterprise Server 12 as the base operating system for the ECS appliance, or qualified Linux operating systems for commodity hardware configurations. Docker is installed on the infrastructure to deploy the other ECS component layers. The Java Virtual Machine (JVM) is installed as part of the infrastructure because ECS software is written in Java.

Hardware

The hardware component layer is an ECS appliance or qualified industry-standard hardware.

The ECS platform is composed of the data services, portal, storage engine, fabric, infrastructure, and hardware component layers.

The ECS Portal component layer provides a Web-based GUI that allows you to manage, license, and provision ECS nodes. The portal has the following comprehensive reporting capabilities:

• Capacity utilization for each site, storage pool, node and disk
• Performance monitoring on latency, throughput, transactions per second, and replication progress and rate
• Diagnostic information, such as node and disk recovery status and statistics on hardware and process health for each node, which helps identify performance and system bottlenecks

• ECS has a feature called Namespaces. Namespaces provide a way to organize or group items for purposes of segregating the space for different uses or purposes. It allows for the multi-tenancy feature in ECS. Each client bucket is created in a separate Namespace and other clients cannot access buckets in a namespace that isn’t theirs.
• ECS provides several features to enable security of customer’s data such as platform lockdown and retention, etc. 
• ECS provides server-side encryption to protect data on disk. Key management is either done automatically or specified by the user. Enabling encryption is done at the namespace level or bucket level, allowing customers to have a level of control at what level to handle encryption
• ECS provides Audit Events – basically, it records a change in the system configuration, tracks logins, and sudo commands run on a node, bucket operations such as setting bucket permissions, and user operations such as set/delete the password.

Yes, we can setup test accounts for 1 Month to allow for performance testing to see what suits business needs, after this, the account will either be deleted or upgraded with added billing.

Veeam does say it supports S3 compatibility, however, this has not been tested but could be looked into at a later stage depending on demand.

There will be options for multiple sites for site-level redundancy.

Yes you can if you move from SFTP to S3.

This is API only. API documentation if required

https://www.emc.com/techpubs/api/ecs/v2-0-0-0/S3BucketListUploadsOperations_ba672412ac371bb6cf4e69291344510e_overview.htm

Yes, this can.

Yes, you can increase this in the future for the same price.

Different users can be created and each individual can be given different rights

Bucket ACLs can be set.

It supports S3 ATMOS SWIFT HDFS

We only have one region just now

Standard RapidSwitch SLAs as per our terms - https://myservers.rapidswitch.com/Terms.aspx

ECS storage is only in Maidenhead. However, there's a possibility to deploy a second unit in a different DC to provide geo-redundancy, as per demand

ECS network infrastructure consists of top of rack switches allowing for the following types of network connections:

• Public network – connects ECS nodes to your organization's network, providing data.
• Internal private network – manages nodes and switches within the rack and across racks.

ECS protects data within a site by mirroring the data onto multiple nodes, and by using erasure coding to break down data chunks into multiple fragments and distribute the fragments across nodes. Erasure coding (EC) reduces the storage overhead and ensures data durability and resilience against disk and node failures.

Yes it can, ECS calls these users

Supported by D@RE - EMC's Enterprise Encryption

Yes this is

We do not have anything like Storage Gateway in front of the ECS,

The ECS does have the ability to present NFS storage but setting this up was not in the original requirements so It has not been set up.

NFS would very much require more integration with the control panel as unlike the S3 protocol there would be no way for the user to handle permissions or modify the IPs that are able to mount the exports without having to go via support ticket.

ECS NFS mount point would not be encrypted however this has not been confirmed yet, still under testing, so the data would likely be transferred in clear text into the ECS array over the public DC5 networks

its recommended not to, as the request for new data written and then trying to access it will cause the platform to work incorrectly.

• Normal filesystems used with windows, for example, adding or editing simple text files and then opening after saving work perfectly fine with filesystems ontop of block devices.
• However, if this was the case with mounting the object storage to windows, this would cause instability and panic the file system. This is due to the object storage wanting to use different nodes each time when accessing it, so when you save something node A - will become aware of the change and take a few milliseconds for all nodes to update the change, however if a file is opened and a node has not updated correctly, the filesystem will panic, hence why we don't recommend mounting object storage to windows as shared storage.

Yes we do, we have created a simple guide on how to set up our storage with existing customers using S3 browsers and Winscp 5.16.2