Today’s Requirement: Delivering Continuous App Availability
Late last week, we hosted a webinar with our SI partner Pragmatic works to discuss how to architect for Continuous Availability. The audience asked a ton of great questions about the role of a modern database in improving app uptime and how to complement that database with other techniques to enable a zero downtime environment.
We’re also offering a great assessment offer to help you architect continuous availability into your IT stack – read on for more details.
Polling at the start showed some interesting characteristics about the audience:
- Solid use of AlwaysOn – 40% are already using AlwaysOn – that jibes with anecdotal findings from the Ignite and PASS conferences
- Big plans for SQL Server 2016 – 53% plan to upgrade, and another 26% are investigating doing so
- 74% have maintenance windows – those windows give them an opportunity for tasks like patching the database servers, but it also means app downtime
- nearly 80% run multiple data centers – running operations across multiple data centers improves the foundation for continuous availability but introduces its own challenges in managing failover across the sites
The Pragmatic Works team talked through options for enabling app uptime in various parts of the technology stack:
- in the code – you can build in logic for retries and for user/device locality, but it takes complicated engineering
- in the network – redundancy at the network layer is essential, but it’s also not enough
- using the cloud – the cloud can provide additional capacity and infrastructure, but not all apps are ready to use the smaller database instances in the cloud
- at the data tier – modern databases, with horizontal scale out, can boost uptime, but the challenge is having apps ready to take advantage of it
Pragmatic Works then highlighted how database load balancing software can complement the capabilities of a modern database such as SQL Server 2016 and make it easier to deliver continuous availability for applications. Then the ScaleArc team then highlighted how our database load balancing software prevents app downtime during unplanned database failovers, enables zero downtime maintenance, and supports connection management and app-transparent caching to improve application uptime.
The audience had a constant stream of fantastic questions about how the two technologies – modern database and database load balancing software – work together to enable continuous availability:
Why doesn’t AlwaysOn always revert back to the original primary node after failover? Different organizations apply different processes following failovers, and often the DBA wants to manage that process manually to ensure replication state, identify the failure reason, etc.
What is the SQL licensing for primary and secondary servers? If you direct workload at the secondary, including making it a readable secondary, you have to pay for a license on that SQL Server.
What happens if ScaleArc fails? Does it become my new single point of failure? The ScaleArc software deploys in HA pairs, linked via Heartbeat. If the primary ScaleArc instance fails, failover to the secondary is sub-second – it has all the credentials and cache entries configured already and immediately takes over.
What happens to transactions in play during database failover? The ScaleArc software is ACID compliant, so when transactions bound for the primary have passed the ScaleArc device and then the primary fails, we’ll relay the failure notice and the app will handle the retry. Any transactions that come after the failover starts, the ScaleArc software will queue – once the failover completes, we’ll drain the queue in a FIFO manner, preserving transactional integrity. So the apps will see delay but not get error messages on those later transactions.
Can ScaleArc help us avoid DoS attacks? Yes – in a couple ways. You can set the max number of connections ScaleArc will allow into the database server. We’ll queue the rest when you hit that max, avoiding overloading the server. We also provide extensive analysis on queries – you can use the ScaleArc software to then firewall certain queries, based on app, sending address, or other parameters. One customer used this technique to block a SQL injection attack – you can block any query with no code changes.
How does ScaleArc work with ETL jobs? Those jobs tend to drive a huge volume of traffic that can tie up the primary database server. Often our customers, for ETL jobs, will do bulk inserts directly to the database server. ScaleArc also supports query routing, so you can designate a secondary to always take reporting requests and avoid interfering with transactional traffic.
How does ScaleArc handle authentication between applications and databases? The ScaleArc software integrates with Active Directory, so we can handle authentication that way, or you can load credentials directly onto the ScaleArc software.
If you need app credentials and not just database credentials, how does ScaleArc handle that? The ScaleArc software passes all those credentials directly through to the database. The database will think it’s a direct connection from the client, so we will relay Windows or SQL Server credentials.
To help our customers design their technology stack for continuous availability, we’re teaming with Pragmatic Works to offer an assessment – you can request your personal consultation and assessment here. Thanks again to the audience for such a great discussion!
comments powered by Disqus