Administrator’s Guide
Table Of Contents
- Introduction
- Managing Acronis Storage
- Configuring Node Network Interfaces
- Creating Acronis Storage Clusters
- Releasing Nodes from Cluster
- Removing Nodes from the Unassigned List
- Managing Tier Encryption
- Managing Acronis Storage Users
- Managing Acronis Storage Updates
- Allowing root Access to Cluster Nodes Over SSH
- Backing Up and Restoring Management Node
- Managing Acronis Storage Licenses
- Monitoring Acronis Storage Clusters
- Monitoring Acronis Storage Nodes
- Exporting Acronis Storage Cluster Data
- Exporting Data via iSCSI
- Creating Acronis Storage iSCSI Targets
- Listing, Stopping, and Deleting Acronis Storage iSCSI Targets
- Configuring Acronis Storage iSCSI Targets
- Accessing Acronis Storage iSCSI Targets
- Accessing Acronis Storage iSCSI Targets from CentOS 6
- Accessing Acronis Storage iSCSI Targets from Microsoft Windows Server 2012 R2
- Accessing Acronis Storage iSCSI Targets from VMware ESXi
- Accessing Acronis Storage iSCSI Targets from Citrix XenServer 6.2
- Accessing Acronis Storage iSCSI Targets from Microsoft Hyper-V
- Managing iSCSI Users
- Exporting Data via S3
- Using Acronis Storage with Acronis Backup Cloud
- Exporting Data via iSCSI
Chapter 5. Exporting Acronis Storage Cluster Data
that describes it as well as a unique identifier that allows finding the object in the storage. Object storage
is optimized for storing billions of objects, in particular for application storage, static web content hosting,
online storage services, big data, and backups. All of these uses are enabled by object storage thanks to a
combination of very high scalability and data availability and consistency.
Compared to other types of storage, the key difference of object storage is that parts of an object cannot be
modified, so if the object changes a new version of it is spawned instead. This approach is extremely important
for maintaining data availability and consistency. First of all, changing an object as a whole eliminates the issue
of conflicts. That is, the object with the latest timestamp is considered to be the current version and that is it.
As a result, objects are always consistent, i.e. their state is relevant and appropriate.
Another feature of object storage is eventual consistency. Eventual consistency does not guarantee that reads
are to return the new state after the write has been completed. Readers can observe the old state for an unde-
fined period of time until the write is propagated to all the replicas (copies). This is very important for storage
availability as geographically distant data centers may not be able to perform data update synchronously (e.g.,
due to network issues) and the update itself may also be slow as awaiting acknowledges from all the data repli-
cas over long distances can take hundreds of milliseconds. So eventual consistency helps hide communication
latencies on writes at the cost of the probable old state observed by readers. However, many use cases can
easily tolerate it.
5.2.1 Object Storage Infrastructure Overview
The infrastructure of the object storage consists of the following entities: object servers (OS), name servers
(NS), and the S3 gateways (GW).
These entities run as services on the Acronis Storage nodes. Each service should be deployed on multiple
Acronis Storage nodes for high availability.
60