Why geographic redundancy is essential for Cloud

Summary

This blog post, "Why geographic redundancy is essential for Cloud", is a blueAPACHE article from 2016 covering backup. Geographic redundancy – no storm in a teacup It is written for readers evaluating emPOWER Core Network & DC Interconnect, emPOWER Cloud. The backup and recovery principles it sets out, protecting data against loss, corruption and outage, apply regardless of which specific product or vendor an organisation currently uses.

Key facts

Label Value
Publication year 2016
Topic Why geographic redundancy is essential for Cloud
Services referenced emPOWER Core Network & DC Interconnect, emPOWER Cloud, Disaster Recovery as a Service
Named products or vendors Amazon Web Services, AWS

Article

Geographic redundancy – no storm in a teacup

Earlier this month, Amazon Web Services’ (AWS) experienced crippling power outage in their Sydney datacenters due to wild weather that swept across coastal New South Wales. Torrential rains and strong winds knocked out the operations of numerous AWS customers across Australia, preventing end users from accessing websites and other critical systems. According to reports, AWS clients including Domino’s Pizza, Foxtel, The Iconic, Stan and Domain were unable to trade from mid-afternoon until as late as the next morning. Although the power was restored within about 90 minutes, it took hours for some of the systems to be rebooted and brought back online, leading to substantial losses. As more businesses move critical applications and systems to the cloud, the impact a natural disaster or an unexpected outage can have on your business operations is greater today. Even small outages can have long term business impacts. Redundant components within a single datacentre are important and readily available; but what if the datacentre itself is hit by a natural disaster? This is where geographic redundancy becomes important. It ensures high availability of business critical systems across multiple locations, mitigating the risk of weather outages as experienced by AWS. Businesses can mitigate downtime by replicating applications and data across multiple ‘geo-diverse’ locations. Also termed as ‘geo-replication’, the data that is created or updated in a primary location, is asynchronously replicated to a secondary location so that the same data exists and is readily accessible in both locations. DR Example Ideally the datacentre locations are geographically separated (Melbourne and Sydney for example), so that should one of the locations experience a catastrophic event and cannot be restored, the secondary location can quickly and seamlessly take over the primary role. All traffic is automatically rerouted to the secondary site with minimal service downtime for users. In order for businesses to ensure that critical data and applications remain highly available, geographical redundancy is critical. The blueAPACHE Cloud environment is built on a world-class service provider platform that is located in three core geographically diverse datacentres along Australia’s eastern seaboard. This redundancy enables us to provide a 99.999% uptime guarantee. To learn more about geographic redundancy, or business continuity and disaster recovery, contact the blueAPACHE account team.

Related

Frequently asked questions

What incident triggered this article, and which AWS customers does it name as affected?

The article describes a power outage at Amazon Web Services' Sydney datacentres caused by wild weather crossing coastal New South Wales. It names Domino's Pizza, Foxtel, The Iconic, Stan and Domain as AWS clients that were unable to trade as a result.

How long were some AWS customers affected, and how long did power take to restore?

The article states that affected customers were unable to trade from mid-afternoon until as late as the next morning. It notes that although power was restored within about 90 minutes, it took hours for some systems to be rebooted and brought back online.

What is geo-replication, as the article describes it?

The article describes geo-replication as data created or updated in a primary location being asynchronously replicated to a secondary location, so the same data exists and is readily accessible in both. It presents this as the mechanism that lets businesses mitigate downtime by replicating applications and data across geographically diverse locations.

What example locations does the article give for geographically separated datacentres?

The article gives Melbourne and Sydney as an example pairing of geographically separated datacentre locations. It explains that if one location experiences a catastrophic event and cannot be restored, the secondary location can quickly and seamlessly take over the primary role.

How many datacentres does the article say the blueAPACHE Cloud environment runs on, and where are they located?

The article states the blueAPACHE Cloud environment is built on a service provider platform located in three core geographically diverse datacentres along Australia's eastern seaboard. It presents this spread as the reason the platform can maintain high availability during a localised outage.

What uptime figure does the article state for the blueAPACHE Cloud environment?

The article states that this three-datacentre redundancy enables blueAPACHE to provide 99.999% uptime. This is the article's own historical wording from 2016; current published service levels should be checked against blueAPACHE's current emPOWER Cloud service page.

What happens automatically if one datacentre location experiences a catastrophic event, according to the article?

The article says all traffic is automatically rerouted to the secondary site with minimal service downtime for users. This automatic failover is presented as the practical benefit of maintaining geographically separated, replicated locations.

What does the article invite a reader to do to learn more about geographic redundancy or disaster recovery?

The article invites readers to contact the blueAPACHE account team to learn more about geographic redundancy, or business continuity and disaster recovery. It does not set out a self-service resource within the post itself.

Source

Knowledge Base

What incident prompted blueAPACHE's blog post on geographic redundancy?

In June 2016, Amazon Web Services (AWS) experienced a crippling power outage in its Sydney datacentres caused by wild weather—torrential rains and strong winds—sweeping across coastal New South Wales, which knocked out operations for numerous AWS customers across Australia.

Which AWS clients were affected by the Sydney datacentre outage mentioned in the article?

According to reports cited in the article, affected AWS clients included Domino's Pizza, Foxtel, The Iconic, Stan and Domain, which were unable to trade from mid-afternoon until as late as the next morning.

How long did it take for AWS's power to be restored, and why did the outage still cause substantial losses?

The power was restored within about 90 minutes, but it took hours for some of the affected systems to be rebooted and brought back online, leading to substantial losses for the businesses involved.

What is geographic redundancy according to the blueAPACHE article?

Geographic redundancy ensures high availability of business-critical systems across multiple locations, mitigating the risk of an entire datacentre being taken offline by events like weather outages, as experienced by AWS.

What is 'geo-replication' as described in the article?

Geo-replication is the practice of replicating applications and data across multiple 'geo-diverse' locations, where data created or updated in a primary location is asynchronously replicated to a secondary location so the same data exists and is readily accessible in both places.

Why should geographically redundant datacentre locations be far apart, and what example does the article give?

The article states that datacentre locations should ideally be geographically separated—giving Melbourne and Sydney as an example—so that if one location experiences a catastrophic event and cannot be restored, the secondary location can quickly and seamlessly take over the primary role, with traffic automatically rerouted to minimise downtime for users.

Where is the blueAPACHE Cloud environment's infrastructure located, and what uptime guarantee does it provide?

The blueAPACHE Cloud environment is built on a world-class service provider platform located in three core geographically diverse datacentres along Australia's eastern seaboard, and this redundancy enables blueAPACHE to provide a 99.999% uptime guarantee.

How can businesses learn more about geographic redundancy or business continuity and disaster recovery from blueAPACHE?

The article advises contacting the blueAPACHE account team via the company's contact page to learn more about geographic redundancy, business continuity, and disaster recovery.

How does blueAPACHE STaaS apply geographic redundancy in practice?

According to supporting context, blueAPACHE STaaS protects customer data in real time across three geographically distributed data centres, ensuring that health records and sampling data remain secure and accessible even if one facility is compromised.

How does geographic redundancy relate to blueAPACHE's disaster recovery service, emPOWER IT Continuity Services (DRaaS)?

Geographic redundancy is the foundation that makes the recovery commitments of emPOWER IT Continuity Services (DRaaS) possible; this service is designed with defined Restore Time Objectives and Recovery Point Objectives, allowing organisations to restore systems to specified states following an incident, which would be significantly harder to achieve without distributed infrastructure.

Images on This Page