Data availability

Data availability is 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 one of your storage endpoints, availability to it is affected, but durability is not. When the network is restored, availability to the data returns and the data is complete and intact.

The importance of data availability

This is determined by how critical access to that data is for your business.

For example, when you store media or software assets for on-demand access, if you customers can't access that content causes a direct service impact to your business. From a user's perspective, the effect depends on how long data is unavailable:

• Seconds. As applications retry downloads, which hurts performance.
• Minutes. The content isn't available when requested, which hurts service quality.
• Hours. The service is effectively down.

The availability level Object Storage provides

All Object Storage endpoints, regardless of type are supported by a 99.9% service level agreement (SLA). Each Object Storage endpoint is hosted within a single region.

Design your deployment for high-availability

In cases where your business objectives require greater than 99.9% availability, as defined by our SLA, you should use two or more Object Storage endpoints, each in an independent region. This ensures that content is stored in two or more physically independent locations, to maintain service continuity for any issues that could impact a single endpoint.

For example, when you store content in two separate endpoints, you can incorporate traffic splitting in an active-active configuration. With this in place, ​Akamai​ applies automatic failover if either endpoint is unavailable. Alternatively, you can use an active-standby configuration, with a primary and secondary storage location. When a failure happens on the primary, ​Akamai​ fails over access to the secondary.

Design your deployment for disaster recovery

For cloud deployments, disaster recovery (DR) is a set of policies, tools, and procedures you can use to enable the recovery or continuation of service following a natural or human-caused disaster. DR planning is typically guided by two key metrics: recovery time objective and recovery point objective.

Recovery time objective (RTO)

How much time can you 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, assume you use a DNS 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 you afford to lose if a disaster occurs? The RPO is the amount of delay between replication of your content between the primary and secondary storage locations.

For example, assume your content is uploaded simultaneously to two locations. The RPO will be zero because the data stored in both locations is identical. If you synchronize content 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 DR requirements, you should store your content in two or more Object Storage endpoints in independent regions. Or, you could use a secondary storage provider as backup, to ensure content is stored in two or more physically independent locations.