# 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.
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% |
#### Minimal drives required for Data Policy creation
| Policy type | Drive count Required for creation | Drive count Required for expansion |
|--------------------|-------------------------------------|--------------------------------------|
| 2 Way Mirror | 24\* | 2 |
| Erasure Coding 4+2 | 36\* | 6 |
* The system does not enforce a minimum drive count configuration. However,
to ensure optimal service levels and alignment with standard deployment
practices, we recommend adhering to the documented minimum configuration
footprint for object storage. In special cases where a lower configuration
is needed, please coordinate with your Zadara representative. Exceptions
may be granted following a review and approval by Zadara’s support team.
## 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.