Introduction¶
What is Object Storage?¶
Object Storage is an alternative way to store, organize and access units of data. It provides a reasonable balance between performance and functionality versus simplicity and scalability. Object Storage enables a minimal set of features: store, retrieve, copy, and delete objects. These basic operations are done via REST APIs that allow programmers to work with the objects. The HTTP interface to Object Storage systems allows fast and easy access to the data for users from anywhere in the world.
Object Storage vs. Block and File Storage¶
Object Storage is much more scalable than file storage because it is vastly simpler. Objects are not organized in hierarchical folders, but in a flat organization of containers or buckets. Each object is assigned a unique ID or key. Their keys, regardless of where the objects are stored, retrieve objects. Access is via APIs at the application level, rather than via OS at the file system level. As a result, Object Storage requires less metadata, and less management overhead than file systems. This means Object Storage can be scaled out with almost no limits. Object Storage is easier to use than block storage and overcomes the limitation of fixed size LUNs. It also removes file system limitations such as the folder size or path name length. Unlike block or file, Object Storage does not use RAID for data protection. It simply keeps a number of copies of each object.
NextGen Object Storage is Zadara’s object storage service. It is provided on Zadara clouds, side by side with the VPSA that provides block and file storage services.
A single Zadara Storage Cloud can host several virtual object stores and this makes it truly disruptive and unique, as each NextGen Object Storage has entirely provisioned resources of CPU/RAM/networking/disks & runs the object stack in isolated Virtual Machines (i.e. there is no sharing of resources anywhere across VPSAs) thereby providing complete performance and fault isolation.
NextGen Object Storage Components¶
NextGen Object Storage architecture is a scale out cluster of Virtual Controllers that together provides the object storage service.
Capacity & performance can independently scaled up/down by adding/removing disks and proxy-VCs respectively. The Object Storage is provisioned with an internal load-balancer to distribute REST API traffic across the Proxy REST API Layers. The Object Storage is a multi-tenant solution which allows creation of multiple accounts, where each account has its users who can work with the object interface (GET/PUT objects) and the management interface.
Object Storage Fault Domains¶
In order to ensure the Object Storage survival in case a complete storage node is lost, the data is distributed between Fault Domains. “Object Storage Fault Domains” are manually populated for the cloud Storage Nodes by the cloud admin.
Object Storage VCs are created in “VC-Sets” according to the desired policy protection type (2-way/Erasure Coding protection). Each VC in a Set is created in a different Fault Domain.
Drives are added to the the Object Storage in sets as well. And allocated only to VCs within the same Fault Domain.
The Ring¶
A ring represents a mapping between the names of entities stored on disk and their physical location. There are separate rings for accounts, containers, and one object ring per storage policy. When any components need to perform any operation on an object, container, or account, they need to interact with the appropriate ring to determine its location in the cluster.
The objects rings are stores in each Policy. The accounts and containers rings are stored in dedicated Policy named Metadata Policy.
One of the Virtual controllers (called Ring Master), runs the Rings, in addition to its other responsibilities. In case of failure of the Ring Master, another VC (called Ring Slave) will take its place.
Virtual Controller¶
A Virtual Controller (VC) is a Virtual Machine with dedicated CPUs & RAM, which runs the NextGen Object Storage IO stack and control stack. The number of VCs in a configuration is determined by the number of drives assigned, starting with a minimal configuration of 2 VCs, and can grow to hundreds.
With Zadara’s NextGen Object Storage, VCs are classified into three groups:
Cluster controller VC - mainly responsible for object storage administration services and cluster health. The controller VC also exposes the web management interface endpoint along with Zadara’s RestAPI server as well as managing authentication services and load-balancing services. Its main responsibilities are:
Query Cloud Controller and Storage Nodes for resource assignments and changes.
Provide Authentication/Authorization framework with which individual accounts/users can be managed and these account/users being able to work with objects within their account
Automatically reconfigure/redistribute object data across available disks on addition/removal of disks, failure/recovery
Provide management GUI and REST API to manipulate the system entities and also to work with the object store
Provide metering visibility in object request flows, capacity trend utilization
Billing based on capacity/throughput usage for each of the tenants
Provide internal load balancing service
Proxy VC - The Proxy layer is the interface to the users or the application using the data objects. Proxy VCs can be added/removed on-the-fly. The proxy exposes both S3 compatible API and Openstack Swift API.
Storage VC - The storage Layer is responsible for storing the objects on the drives, and updating the metadata in the databases. The physical drives allocated to the NextGen Object Storage instance will be attached to the Storage VC (up-to 12 drives). Storage VCs will be provisioned automatically by the system.
The following diagram describes the structure of Zadara’s NextGen Object Storage:
Dedicated Drives¶
The zStorage Cloud Orchestrator assigns dedicated drives for each each VPSA/Object Storage instance. The drives are provisioned from different Storage Nodes (SNs) for maximum redundancy and performance. Each drive is exposed as a separate iSCSI target from the SN and is LUN masked only to the VPSA’s VCs. The instance QoS is guaranteed, because neighbors, with provisioned drives adjacent to yours, cannot access your drives, impact your performance, or compromise your privacy and security.
Object Storage data policies¶
Zadara Object Storage has two data protection types:
2-Way Mirror - with 50% capacity utilization and oriented for performance. For small scale object storage deployments (up to 1 PiB).
Erasure-Code 4+2 - with 67% capacity utilization oriented for high-durability. For large scale object storage deployments.
The data protection will form the layout of the object storage instance. Each Object Storage instance supports only one data policy.
Important
Data policy type cannot be changed post creation.
Each Data Policy type has a unique set of characteristics in terms of performance, durability and scale, consider the following guidelines when you plan your Object Storage instance.
Display Name |
Performance |
Recommended Scale |
FD |
Utilization |
|---|---|---|---|---|
2-Way Mirror |
High |
Up To 1 PiB Of Usable Capacity |
2 |
50% |
4+2 Erasure Coding |
Moderate |
Beyond 1 PiB Of Usable Capacity |
3 |
67% |
Important
The availability of Data Protection policies may differ in different Zadara deployment, as it is dependent on the amount of nodes the cloud is structured from.
Minimal drives required for Data Policy creation¶
Policy type |
Drive count Required for creation |
Drive count Required for expansion |
|---|---|---|
2 Way Mirror |
2 |
2 |
Erasure Coding 4+2 |
6 |
6 |
NextGen Object Storage Hierarchy¶
The Object Storage system organizes data in a hierarchy, as follows:
Account (also referred to as Tenant). Represents the top-level of the hierarchy. Usually created by the service provider. The account admin owns all resources in that account. The account defines a namespace for containers. Containers in two different accounts, might have the same name. Accounts are also used to control users access to objects and containers.
Container (also referred to as Bucket). Defines a namespace for objects. Objects in two different containers, may have the same name. Each container can have a unique access rule policy (ACL) or inherit the account default policy.
Object Stores data content, such as documents, images, log files etc.
NextGen Object Storage Users and Roles¶
There are four types of Roles assigned to NextGen Object Storage Users:
Object Storage Administrator (zios_admin) responsible for the administration of the NextGen Object Storage. The user (registered in Zadara Provisioning Portal) that provisions the NextGen Object Storage will be set as its Administrator. By default, the NextGen Object Storage is created with one account (administrator account) and the NextGen Object Storage Administrator is a member of this account. NextGen Object Storage Administrators can add other users with the same role. NextGen Object Storage Administrator is a super-user with privileges to create accounts and users of any role. Users with NextGen Object Storage Administrator role can define policies, add/ remove drives and assign drives to policies. Users with the NextGen Object Storage Administrator role can perform containers and objects operations across accounts. The NextGen Object Storage administrator is also responsible for the NextGen Object Storage settings (like IP addresses, SSL certification, etc.), and has access to the metering and usage information.
Object Storage Administrator (zios_admin) - Read Only a dedicated Read-Only account for cross-accounts monitoring and reporting purposes. The Read-Only role is available for the zios_admin account only. A Read-Only user will have access to the NextGen Object Storage RestAPI, however it will not have data access. The user role is designated for monitoring and reporting purposes, such as:
Performance monitoring
Capacity monitoring
Usage reports & billing automation
Account Admin can create an account (using the Self Account Creation Wizard) and can manage their own accounts. They can perform any user management and containers/objects operations.
Member can do object storage operations according to the permission given by the account administrator, within the limits of that account. These operations include create/delete/list containers and create/delete/list objects.
Functionality differences between NextGen Object Storage and VPSA Object Storage¶
Data policy protection¶
VPSA Object Storage |
NextGen Object Storage |
|---|---|
2-Way Mirroring |
2-Way Mirroring |
Erasure Coding 2+1, 4+2 |
Erasure Coding 4+2 |
Erasure Coding 6+2, 9+3 |
|
Multizone High Availability |
Functionality¶
The following features are not included in NextGen Object Storage 23.0-SP1:
Account level rate limit
Container level replication
External authentication (Openstack Keystone integration)
The missing features will be added to NextGen Object Storage, based on Zadara’s zStorage roadmap.