Maximizing Availability for Mission Critical Applications update from April 2016

The availability of your mission critical applications is without a doubt the DBA and database professional’s most important priority. Although performance is always critical, it takes a back seat if the applications and the database aren’t available. If the database goes down, you know what you’ll be working on.

Michael Otey

April 8, 2016

3 Min Read
Maximizing Availability for Mission Critical Applications

The availability of your mission critical applications is without a doubt the DBA and database professional’s most important priority. Although performance is always critical, it takes a back seat if the applications and the database aren’t available.  If the database goes down, you know what you’ll be working on. High availability isn’t just an enterprise concern. Although they may not have the same level of resources, smaller and medium-sized business have many of the same needs for critical application availability.

Downtime is Expensive

For the enterprise and larger organizations that depend on their mission critical applications, downtime is far more than an inconvenience or an embarrassment. Downtime can be very expensive. While the actual costs of downtime vary between different businesses and the types of applications that they run, Gartner Research did an interesting survey that revealed that, on average, downtime costs approximately $5,600 per minute, which equates to over $300,000 per hour. While these are just averages, it clearly shows that downtime is costly for all organizations. For some businesses it can be even higher – much higher. For example, a 30 minute Amazon outage in 2013 was estimated to have cost Amazon $66,240 per minute in lost revenue or approximately $3 million dollars for the total outage. While downtime is clearly expensive, the repercussions of downtime are not only monetary. Downtime also costs organizations in terms of loss of reputation, lost customer and end user confidence and also the loss of efficiency as the organization recovers from the event.

Building Enterprise Availability on the HPE Superdome X Platform

Availability is not something that just happens. You need to build availability into your infrastructure from the ground up. For instance, as you build out your hardware infrastructure layer you need to be aware that in terms of availability, not all servers are created equal. When you select a server platform you need to look for built-in reliability from the component level up to the solution level. The HPE Superdome X is designed to provide five nines (99.999%) availability for protection from unplanned downtime. HPE studies showed the Superdome X provides a 60% reduction in downtime when compared to scale out solutions. Likewise, the HPE Superdome X’s unique nPar (hardware partitioning) capability delivers 20% more reliability then software-only virtualization.  At the firmware–level, the Superdome X provides a “firmware first” architecture that is able to contain errors in the firmware before any corrupted data can reach the OS. In addition, the built-in Error Analysis Engine (EAE) constantly analyzes all possible hardware faults, predicts errors and can automatically initiate recovery actions without any operator actions. This layered approach to reliability maximizes system uptime and availability.

Maximizing Database Availability with SQL Server AlwaysOn Availability Groups

Next, you need to plan your database protection strategy. SQL Server’s AlwaysOn Availability Groups (AGs) are SQL Server’s premier database availability technology and they can simultaneously provide both high availability and disaster recovery for multiple databases. AlwaysOn AGs provide database level protection and they can protect against planned and unplanned downtime. AGs can protect multiple databases all of which can be automatically failed over as a unit. They can perform automatic failover and the failover time is typically just a few seconds. SQL Server 2016 AlwaysOn AGs support up to eight secondary replicas, where each secondary replica is located on a separate Windows Failover Cluster node. AlwaysOn AGs can support both synchronous and asynchronous replicas simultaneously. Synchronous replicas are used in high availability scenarios where there is a requirement for fast automatic failover. Asynchronous replicas are typically used for disaster recovery scenarios where the replicas are in a different geographic location or in the cloud.

New for SQL Server 2016 AlwaysOn Availability Groups

SQL Server 2016 adds several important new capabilities to AGs. Two node AGs will be available in the SQL Server 2016 Standard Edition.  Next, SQL Server 2016 will support up to three synchronous replicas two of which can be used as automatic failover targets. SQL Server 2016 AGs will also support the Distributed Transaction Coordinator (DTC) for Windows Server 2016. In addition, SQL Server 2016 AGs will also provide load balancing across readable secondary replicas.

Sponsored by HPE and Microsoft

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like