Object Storage overview#
OpenStack Object Storage (swift) is a multi-project object storage system. It is highly scalable, can manage large amounts of unstructured data, and provides a RESTful HTTP API.
Rackspace Private Cloud Powered By OpenStack (RPCO) includes the use of OpenStack Object Storage for redundant, scalable object storage using clusters of standardized servers that are capable of storing petabytes of data.
Object Storage includes the following components:
- Account server (
Manages the accounts that are defined with Object Storage.
Accounts are the root storage location for data.
A group of servers.
- Container server (
Manages the mapping of containers or folders, within Object Storage.
Containers are user-defined segments of the account namespace that provides the storage location where objects are placed.
A host machine that runs one or more OpenStack Object Storage services.
- Object servers (
Manages objects, such as files, on the storage nodes.
Objects are the actual data stored in Object Storage.
- Proxy node
A host machine that runs proxy services.
- Proxy server (
Accepts OpenStack Object Storage API and raw HTTP requests to upload files, modify metadata, and create containers. The proxy server also serves file or container listings to web browsers. The proxy server takes each request and looks up locations for the account, container, or object and routes the requests correctly. The proxy server also handles API requests. To improve performance, the proxy server can use an optional cache that is usually deployed with Memcached.
- Region (optional)
A logically separate section of the cluster representing distinct physical locations such as cities or countries. Regions are similar to zones, but regions represent the physical locations of portions of the cluster.
A copy of an object. By default, three copies are maintained in the cluster.
A set of hash tables that associate each object to a specific physical device. There is one ring per type of data manipulated by Object Storage (objects, containers, and accounts). The set of rings are shared among every Object Storage node (storage and proxy). Each ring determines the physical devices (hard disks) where each object, container, and account are stored. The number of devices on which an object is stored depends on the number of replicas (copies) specified for the Object Storage cluster. If the zones are greater than or equal to the replica count, the ring guarantees that every replica is stored in a separate zone.
- Storage node
A host machine that runs account, container, and object services. The storage node contains the SQLite databases.
- Various periodic processes
Perform housekeeping tasks on the large data store. The replication services ensure consistency and availability through the cluster. Other periodic processes include auditors, updaters, and reapers.
- WSGI middleware
Handles authentication (usually OpenStack Identity).
A logically separate section of the cluster. A zone is a group of nodes that are as isolated as possible from other nodes—separate servers, network, power, and even geography—to create independent failure characteristics.
Object Storage integrates with the Compute layer and can be used as a back end for the Image service (glance), providing a horizontally scalable store for all image and snapshot data. Object Storage focuses on storing nontransactional data. Object Storage data (the accounts, containers, and objects) are resources that are stored on physical hardware.
Object Storage proxy containers are installed on specific infrastructure nodes. The other Object Storage nodes are storage nodes and can have any combination (at a device or drive level) of object, container, or account servers running on them. For example, given two servers with five drives in each, each drive can be part of the ring for any combination of object, account, or container (including each having different storage policies within the object server).
Object Storage uses the following nodes:
Three existing infrastructure nodes run the
swift-proxy-serverprocesses. The proxy servers route requests to the appropriate storage nodes.
Multiple storage nodes that run the
swift-object-serverprocesses, which control storage of the account databases, the container databases, and the actual stored objects.
The following Object Storage features are not supported in Object Storage in RPCO:
Ring management and ring storage repositories
Drive detection, formatting, mounting, and unmounting
To run the Object Storage service for RPCO, your system must meet the following requirements.
Each node in the cluster should meet the following minimum specifications:
Six SAS drives of at least 1 TB capacity each
One core for every 3 TB of drive capacity
Two GB RAM, plus an additional 250 MB RAM for every TB of drive capacity
The amount of disk space depends on how much can fit into the rack efficiently.
Object Storage is designed to run on commodity hardware. At Rackspace, storage servers are generic 4U servers with 24 2-TB SATA drives and 8 cores of processing power. RAID on the storage drives is not required and is not recommended. The disk usage pattern of Object Storage is unsuitable for RAID.
- Operating system
Object Storage in RPCO runs on the Ubuntu operating system.
Object Storage in RPCO requires the following components of Rackspace Private Cloud 14.0:
Infrastructure services (SQLite database, Memcached, and RabbitMQ)
One Gbps or 10 Gbps is suggested internally. An external network should connect anything external to the proxy servers. The storage network is intended to be isolated on a private network or multiple private networks.
A SQLite database is part of the Object Storage for RPCO container and account management process.
Object Storage for RPCO can be installed with either root permissions or as a user with sudo permissions if the
sudoersfile is configured to enable all the permissions.