Administrator’s Command Line Guide
Table Of Contents
- Introduction
- Accessing Acronis Storage Clusters via iSCSI
- Preparing to Work with Acronis Storage iSCSI Targets
- Creating and Running Acronis Storage iSCSI Targets
- Listing Acronis Storage iSCSI Targets
- Transferring Acronis Storage iSCSI Targets Between Acronis Storage Nodes
- Stopping Acronis Storage iSCSI Targets
- Deleting Acronis Storage iSCSI Targets
- Configuring Multipath I/O for Acronis Storage iSCSI Targets
- Managing CHAP Accounts for Acronis Storage iSCSI Targets
- Managing LUN Snapshots
- Accessing Acronis Storage Clusters via S3 Protocol
- Monitoring Acronis Storage Clusters
- Managing Cluster Security
- Maximizing Cluster Performance
Chapter 3. Accessing Acronis Storage Clusters via S3 Protocol
The data is stored in a B-tree where to each object’s name corresponds that object’s metadata structure. S3
object metadata consists of three parts: information on object, user-defined headers (optional), and ACL for
the object. Files are stored in the corresponding directory on base shared storage (i.e. Acronis Storage).
Name server is responsible for a subset of S3 cluster object namespace. Each NS instance is a userspace
process that works in parallel with other processes and can utilize up to one CPU core. The optimal number of
name servers are 4-10 per node. We recommend to start with creating 10 instances per node during cluster
creation to simplify scalability later. If your node has CPU cores that are not utilized by other storage services,
you can create more NSes to utilize these CPU cores.
3.1.3.3 Object Server
Object server performs the following functions:
• Stores object data in pools (data containers).
• Provides an API for creating, reading (including partial reads), writing to, and deleting objects.
Object server consists of the following:
• information on object’s blocks stored on this OS,
• containers that store object data,
• asynchronous garbage collector that frees container sections after object delete operations.
Object data blocks are stored in pools. The storage uses 12 pools with blocks the size of the power of 2, ranging
from 4 kilobytes to 8 megabytes. A pool is a regular file on block storage made of fixed-size blocks (regions).
In other words, each pool is an extremely large file designed to hold objects of specific size: the first pool is for
4KB objects, the second pool is for 8KB objects, etc.
Each pool consists of a block with system information, and fixed-size data regions. Each region contains has
a free/dirty bit mask. The region’s data is stored in the same file with an object’s B-tree. It provides atomicity
during the block’s allocation and deallocation. Every block in the region contains a header and object’s data.
The header stores the ID of an object to which the data belong. The ID is required for a pool-level defrag-
mentation algorithm that does not have an access to the object’s B-tree. A pool to store an object is chosen
depending on object size.
For example, a 30KB object will be placed into the pool for 32KB objects and will occupy a single 32KB object.
A 129KB object will be split into one 128KB part and one 1KB part. The former will be placed in the pool for
128KB objects while the latter will go to the pool for 4KB objects. The overhead may seem significant in case
20