Cluster Control Panel - Configuring Database Servers

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 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

The load balancing functionality allows ScaleArc to be dynamic while managing 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 primary 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.

Once a cluster is created, you can modify the underlying servers supporting the cluster in the following ways:

• Add servers into the cluster
• Delete a server from a cluster
• Modify a server’s properties in a cluster

Add a database server

Let’s add a server into the cluster and explore the options in more detail. 

To add a database server:

1. On the ScaleArc dashboard, navigate to CLUSTERS > Database Servers (last column). 
   
   
   
   The control panel displays the list of servers configured for the cluster. The above example shows two servers for the cluster. The servers were added when you first created the cluster through the create a cluster wizard. Once created, you can modify the underlying servers supporting the cluster.
   
   
2. Click Add Server.
   
   

3. Configure the server as follows:

   Field	Description	Default/user input
   IP Address/FQDN	The IP address of the database server or the Fully Qualified Domain Name (FQDN) of the MSSQL server.
   Instance Name/Port	The port that the MySQL server is listening to.	Default: 1433
   Server Role	Let's ScaleArc know what servers support reads or reads & 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 + No This option is greyed out if you have an Azure SQL DB cluster.
   Max Concurrent Server Connection	Let's ScaleArc know the maximum number of connections a database server can accept.	Default: 300
   Idle Connection Timeout	Specify the idle connection timeout setting configured in this Server. ScaleArc will send keep-alive probes to this server within this timeout (at every n/2 interval).	Default: 30s
   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 the option.
   Replication time	Specifies the replication lag (in seconds) before this server is marked inactive in this cluster.	Default: 30s
   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 the required number of connections.

    

   Note: You can adjust the individual server settings using the gear icon displayed after the server role. The default maximum connections value of 300 is typically too low for production environments. Most MSSQL servers can handle upwards of 30,000. Set the recommended initial value of 10,000 max connections per server. In addition, you may need to adjust the connection idle timeout and replication lag threshold from the defaults.

Delete a database Server

Delete a database server by following these steps: 

1. On the ScaleArc dashboard, click CLUSTERS > Database Servers (last column).
    
2. Click the red Delete icon for the selected database server to remove it from the cluster.

Modify a server's properties in a cluster

Editable options that were configured while Adding the database server to the cluster are available for modification after the server has been added by clicking on the gear icon next to the server name to open the Edit Server Settings page.

Update the settings as desired then click on the Update Server button to save the changes.

Best practices 

Some important guidelines 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 the 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 equally. 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 the principal server (Read/Write server).	In this mode, all servers in the cluster are treated equally. 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 the principal (Read/Write server).	All traffic is sent to all servers. Not advised for any production traffic.