Last modified Aug, 10, 2017
Database servers

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. 
 

Tip

Before you begin configuring the database server, we recommend you read the section Best practices on this page.

To add a database server:

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

  2. Click Add Server.




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

    This option is greyed out if you have an Azure SQL Database cluster.



    Instance Name/Port

    The instance name/ port that the MS SQL server is listening to.

    This option does not appear if you have an Azure SQL Database cluster.

     


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

    This option is greyed out if you have an Azure SQL DB cluster.



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

    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 SQL servers can handle upwards of 30,000. See the recommended initial value of 10,000 max connections per server. Also, you may need to adjust the connection idle timeout and replication lag threshold from the defaults.

Delete a database server

Deleting a database server is very easy. 

  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.

 

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. 



     




On this page





Comments

    Add new comment