How to Simplify an Upgrade to SQL Server 2014
Last week, Microsoft hosted a webinar on how to simplify the upgrade to SQL Server 2014. Microsoft’s senior services engineer, Michael Schaeffer, led off the discussion, highlighting how ScaleArc helped his team upgrade to SQL Server 2014 for the answers.microsoft.com website. Then ScaleArc’s founder and CTO, Varun Singh, gave a demo of the ScaleArc database load balancing software. Both presenters got some great questions along the way.
Does the application connect to ScaleArc first?
A: Yes – the ScaleArc database load balancing software drops in between the apps or websites and the SQL database, so the ScaleArc software is the connection point for the SQL connection string.
Q: What happens if ScaleArc is down?
A: Organizations deploy ScaleArc in HA mode to enable failover.
Q: Will ScaleArc work with SQL Server 2012 or just 2014?
A: ScaleArc supports SQL Server 2005, 2008, 2008/R2, 2012, and 2014.
Q: To Michael at Microsoft: Thanks for speaking. Was any functionality of your project specific to SQL Server 2014, or would 2012 support it as well?
A: We could have just as easily used 2012. We just needed the additional readable secondaries that 2014 supports [up to eight vs. the four in 2012].
Q: Was there any code refactoring required to support Scale Arc owning read/write split?
A: No – it is handled on the ScaleArc layer.
Q: Is there a response time or performance hit?
A: Because of its connection management capabilities, the ScaleArc software typically increases performance, even with no specific performance capabilities enabled. When customers leverage features such as caching, performance increases 5x to 60x.
Q: Is ScaleArc software or a VM or a service in Azure? Where does it run?
A: ScaleArc is software – it can run on bare metal or VM or Azure – or in other cloud provider infrastructure. For Microsoft’s deployment, ScaleArc runs on VM pairs.
Q: How does ScaleArc make apps “instantly Azure ready”?
A: ScaleArc can aggregate multiple smaller database instances to act like one large one, so you don’t have rewrite apps to run on smaller cloud devices. ScaleArc also enables multi-region operation with no app changes, including failover that spans different regions.
Q: How is SQL Server + ScaleArc stronger than Oracle's RAC?
A: ScaleArc failover, complementing AlwaysOn, has a number of advantages over Oracle RAC:
failover happens without application errors or restarts – the ScaleArc software queues inbound queries during failover and then forwards them on to the new primary
failover can span multiple data centers – with no shared storage component, an AlwaysOn cluster can run globally
ScaleArc + SQL Server can run in the cloud – with the requirement for multi-mountable shared storage, Oracle RAC cannot run in the cloud
replication and failover come with a much lower price tag – SQL Server customers can avoid the high cost of Oracle to get strong failover
Q: Is there any intelligence built based on what is cached into memory, which influences what server to redirect a query to to minimize disk read operation?
A: ScaleArc is not functioning at this low level on a server. It’s operating at the SQL layer. We direct queries to servers based on time to first byte, enabling geo-aware load balancing.
Q: My .NET layer and SQL access layer is HIPPA compliant. Now if I introduce this new load balancing layer, am I still HIPPA compliant?
A: Yes – ScaleArc maintains HIPPA compliance.
Q: We have an app (IBM Maximo) that cannot handle any kind of underlying SQL Server interruptions, even a brief cluster failover. Will ScaleArc insulate the app's connection pools from failovers and such so we don't have to restart our app tiers?
A: Yes. Because the app connects to ScaleArc instead of the database, the ScaleArc software maintains client connections during failover, waiting for the promotion of the secondary and queuing inbound transactions and queries during the delay.
Q: What happens when I am in middle of a transaction and the Primary stops? In normal failover, the transaction is rolled back and the user needs to resubmit the transaction. Does ScaleArc change this behavior?
A: No – ScaleArc preserves the write commitment behavior of the database and never commits a write on behalf of the database. Transactions in flight, beyond ScaleArc, when the primary fails will fail – transactions that come in after the failure will go into the ScaleArc queue, waiting for the secondary to be promoted.
Q: I’ve got some major concerns with architectures that use a high number of nolock hints (read uncommitted) in isolation. Depending on the latency of the replication of the transaction and which server it hits, we could get different values for concurrent queries selecting the same data.
A: In addition to not committing writes on behalf of the database, the ScaleArc software monitors replication lag. Users set the threshold for how much delay is acceptable, and ScaleArc will not send reads to any servers whose replication is out of synch longer than that threshold.
comments powered by Disqus