Data availability

Data availability describes the ability to provide reliable access to data. When considering the design of a storage solution, availability is typically evaluated with (and sometimes confused with) another very important concept: data durability.

For example, if a network outage prevents access to a storage endpoint, availability is affected, but durability is not. When the network is restored, availability to the data returns and the data is complete and intact.

Importance of data availability

The level of importance for data availability within a deployment is determined by the importance of access to that data for your business.

For example, when storing media or software assets for on-demand access, inability to access that content results in a direct service impact to your business. When viewed from a user perspective, data inaccessible for seconds can result in service performance concerns as applications retry to download content, minutes of downtime can result in service quality concerns due to an inability to access content when it is requested, and hours of downtime can result in a complete service outage.

What level of availability does Akamai Object Storage provide?

All Akamai Object Storage endpoints, regardless of type, are supported by a 99.9% SLA. Each Akamai Object Storage endpoint is hosted within a single data center.

Designing a deployment to meet High-Availability requirements

In cases where your business objectives require greater than 99.9% availability, as defined by our SLA, the use of two or more Akamai Object Storage endpoints in independent regions is recommended. The use of two or more endpoints in independent regions ensures that content is stored in two or more physically independent locations to maintain service continuity for any issues impacting a single endpoint.

For example, when content is stored in two separate endpoints, traffic splitting can be used in an active-active configuration with automatic failover if either endpoint is unavailable. Alternatively, an active-standby configuration using a primary and secondary storage location can be used with failover to the secondary when issues with the primary are detected.

Designing a deployment to meet Disaster Recovery (DR) requirements

For Cloud deployments, Disaster Recovery (DR) is a term used to define the set of policies, tools, and procedures used to enable the recovery or continuation of service following a natural or human-caused disaster such as earthquakes, floods, or fires. DR planning is typically guided by two key metrics: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

Recovery Time Objective (RTO)

How much time can I afford to be offline if a disaster occurs? The RTO is the amount of time it takes to execute a switch from the primary storage location to the secondary storage location when an event occurs.

For example, if DNS is used to switch traffic between the primary and secondary storage location, the RTO would include any time from the start of the event until the DNS change has been applied and for traffic to be terminated on the secondary storage location.

Recovery Point Objective (RPO)

How much data can I afford to lose if a disaster occurs? The RPO is the amount of delay between replication of content between the primary and secondary storage locations.

For example, in the case where content is uploaded simultaneously to two locations, the RPO will be zero because the data stored in both locations is identical. If you use a model where content is synchronized from the primary to the secondary endpoint, using a tool like rclone every 24 hours, then the RPO would be up to 24 hours.

To meet Disaster Recovery requirements, it is recommended that content must be stored in two or more Akamai Object Storage endpoints in independent regions, or using a secondary storage provider as backup, to ensure content is stored in two or more physically independent locations.