Top 5 Frequently Asked Questions About ScaleArc - Now Answered
ScaleArc's database load balancing software offers a very compelling value proposition for anyone who wants 100% uptime, transparent failover, zero downtime maintenance, database scalability and easy database upgrades without downtime, and much more.
Since database load balancing software is a new concept, we get many of the same questions each time we present our software. On a recent live demo, we covered these top 5 frequently asked questions:
Q: Is ScaleArc a single point of failure?
For production implementations, ScaleArc strongly recommends that customers install a clustered pair of ScaleArc servers in high availability (HA) mode. That architecture, similar to an F5 or a NetScaler load balancer, gives you a backup instance should the primary one fail. Cloud installs, such as AWS customers, can have two or more ScaleArc instances load balanced by ELB (elastic load balancer).
Single-instance deployments of ScaleArc are not recommended. Any infrastructure component deployed in single instance without high availability acts as a single point of failure.
Q: How many connections can a ScaleArc node support?
A ScaleArc instance can support up to 64,000 client connections (TCP limit per IP:Port) per cluster/endpoint.
Q: a) How big is the queue? b) How does timeouts work in relation to queuing for writes?
Because of the nature of the SQL language and its serial approach to handling queries (i.e. it waits for the last one to complete before it sends the next one), the write queue cannot hold more requests than there are active connections between the app server and the ScaleArc server. In short, the queue can hold as many as 64,000 (client connection limit) connections per ScaleArc cluster/endpoint.
Since database failovers create a delay, the associated application could time out during the process. As part of the ScaleArc implementation, you should understand how long it takes for your database servers to complete failover, and you should set your timeout durations appropriately so they do not affect the app during a failover. Typical application timeouts for an established database connection range from 30 seconds to 600 seconds.
Q: Is ScaleArc doing the replication, or is this happening at the database level?
ScaleArc does not perform database replication – it only monitors replication status to determine replication lag and server health. Each DBMS we support offers many good replication tools, and we recommend using them for replication. You can choose to implement replication at the database, storage, or OS level, whichever makes the most sense for your environment.
Q: Is ScaleArc handling the failover?
For SQL Server with AlwaysOn Availability Groups, AlwaysOn (AO) handles the database failover. ScaleArc communicates with AO so that it understands the state of the cluster at all times and handles the client connection failover. With MySQL and SQL Server without AO, ScaleArc initiates and manages the process to perform failover.
And here's a bonus question and answer that came from our recent live demo session:
Q: Can't "zero downtime maintenance" (ZDM) be achieved using AlwaysOn with automatic failover, assuming appropriate DNS TTL values on AG Listener?
With AlwaysOn, the virtual network name (VNN) is associated only to the primary. If the primary node in AlwaysOn fails, then the client connections must be redirected to different database server(s) as the VNN gets moved with the database failover.
As a SQL proxy, ScaleArc maintains separate connections to both the database and the application. As a result, we can enable uninterrupted connectivity between the applications and the database.
If you should have further questions about ScaleArc, please contact us at sales@scalearc.com. You can also sign up for our next live demo webinar to get your questions answered and see it in action!
comments powered by Disqus