This is the last column on the Clusters control panel.
In ScaleArc, the term servers refers to your database servers. Every cluster should have at least one server associated with it. ScaleArc uses the listed servers in its load balance rotation. Additionally, ScaleArc validates the integrity of each server and the consistency of the database as it relates to replication.
The number of clusters ScaleArc supports is determined by the license file applied to ScaleArc. A single cluster supports a maximum of ten servers. ScaleArc benchmarks performance for listing adequate resources to match traffic, application behavior, and database performance.
About load balancing
ScaleArc’s load balancing functionality allows it to be dynamic for availability. ScaleArc removes the database from the load balance rotation if the database server becomes unavailable or is out of replication or time sync with the principal server. The system indicates database server status using a green or red status icon next to its IP address. An active red icon should be treated as an alert for further investigation as it indicates that the database server is not being included in the load balance rotation.
Add a database server
Once a cluster is created, you can modify the underlying servers supporting the cluster in many ways:
- Add servers into the cluster
- Delete a server from a cluster
- Modify a server’s properties in a cluster
Let’s add a server into the cluster and explore the options in more detail. All options are available for modification, once the server has been added to a cluster.
To add a database server:
- On the ScaleArc dashboard, click Clusters > Database Servers (last column).
The control panel displays the list of servers configured for the cluster. This example shows two server for the cluster. The server was added when you first created the cluster through the create a cluster wizard. Once created, you can modify the underlying servers supporting the cluster. Or you can add or delete a cluster from this screen. - Click Add Server.
Configure the server as follows:
Field Description Default/user input DNS Address/DNS Name IP address of the database server or the Fully Qualified Domain Name (FQDN) of the MS SQL server.
Instance Name/Port The instance name/ port that the MS SQL server is listening to.
Server Role Lets ScaleArc know what servers support reads or reads and writes. Use this parameter to transparently split Read/ Write queries between the various clusters on the server.
The roles are as follows:
Read + Write (Typically a principal database server.)
Read (Typically a slave/replica database server.)
Standby + Read
Standby + NoMaximum Concurrent Server Connection Lets ScaleArc know the maximum number of connections a database server can accept. This supports SQL surge queue and affects the load balance rotation scheme ScaleArc uses to distribute traffic across multiple servers.
Server Status Specifies whether the server is online/offline.
Ignore replication lag time Sends queries to the server even if it is lagging behind the primary server. Set to ON to enable option. Replication time Specifies the replication lag (in seconds) before this server is marked inactive in this cluster. Weightage Sets the number of connections the database server can handle. The higher the weightage, the larger the number of connections the database server can receive.
Adjust the slider to set required number of connections.
Delete a database server
Deleting a database server is very easy.
- On the ScaleArc dashboard, click Clusters > Database Servers (last column).
- Click the red Delete icon for the selected database server to remove it from the cluster.
Best practices
A few things to remember:
- Read/Write split requires two or more enabled servers. ScaleArc automatically adjusts and offers options based on whether there is a single server or multiple servers in the cluster configuration. You can turn off Read/Write split in the cluster properties.
A change in the Read/Write split status requires a cluster restart. See edit a cluster section of this guide for more information.
- Max Concurrent Client Connections should not exceed the configured value supported on the database server. ScaleArc provides a warning if the setting in ScaleArc exceeds the threshold configured on the database server. We recommend configuring ScaleArc slightly below the maximum connection count by 80%-90%.
- Do not reduce the Max Concurrent Client Connections to 0. If you need to remove a server from the ScaleArc load balance rotation, delete it or just take the database offline. If you take the database server offline, ScaleArc adjusts dynamically.
- Read/Write split settings in ScaleArc and its impact on server roles within ScaleArc clusters: For Typical – Principal Standby environments Read/Write split has to be turned ON so that ScaleArc can send reads to slaves and everything else (+ some read traffic) to principal server.
Configuring a MS SQL server as a slave does not prevent the slave server from receiving write traffic and acting on it (if Read/Write split is OFF). ScaleArc warns against such configurations only at configuration time and not at runtime when the traffic is passing.
Here is a matrix with the Read/Write split and its impact on server roles/types, along with the corresponding ScaleArc behavior.
Server types in the cluster Read/Write split ON Read/Write split OFF All servers in the cluster are read-only Writes will go to the surgeQ and reads will go to read-only. This mode should be used when switching between principals and there is a short window of time where all servers will be read-only. Not advised for any production traffic.
In this mode all servers in the cluster are treated equal. Writes coming in can be sent to any server in the cluster. Use only when the application traffic is truly complete read-only traffic.
One Read/Write and Multiple read-only slaves Typical deployment for production traffic. ScaleArc sends reads to slaves and everything else (+ some read traffic) to principal server (Read/Write server).
In this mode all servers in the cluster are treated equal. Writes coming in can be sent to any server in the cluster, including read-only servers. Not advised for any production traffic.
Multiple Read/Write servers. No read-only servers No impact of Read/Write split. All traffic is sent to all servers.
No impact of Read/Write split. All traffic is sent to all servers.
Multiple Read/Write servers and multiple read-only servers ScaleArc sends reads to slaves and everything else (+ some read traffic) to principal (Read/Write server).
All traffic is sent to all servers. Not advised for any production traffic.
Comments