In DataStream, the NetScaler is placed in-line between the application and/or web servers and the database servers. On the NetScaler appliance, the database servers are represented by services
Figure 1. DataStream Entity Model
As shown in this figure, a DataStream configuration can consist of an optional content switching virtual server (CS), a load balancing setup consisting of load balancing virtual servers (LB1 and LB2) and services (Svc1, Svc2, Svc3, and Svc4), and content switching policies (optional).
The clients (application or web servers) send requests to the IP address of a content switching virtual server configured on the NetScaler appliance. The NetScaler, then, authenticates the clients using the database user credentials configured on the NetScaler appliance. The content switching virtual server applies the associated content switching policies to the requests. After evaluating the policies, the content switching virtual server routes the requests to the appropriate load balancing virtual server, which then distributes the requests to the appropriate database servers (represented by services on the NetScaler) based on the load balancing algorithm. The NetScaler uses the same database user credentials to authenticate the connection with the database server.
If a content switching virtual server is not configured on the NetScaler, the clients (application or web servers) send their requests to the IP address of a load balancing virtual server configured on the NetScaler appliance. The NetScaler authenticates the client by using the database user credentials configured on the NetScaler appliance, and then uses the same credentials to authenticate the connection with the database server. The load balancing virtual server distributes the requests to the database servers according to the load balancing algorithm. The most effective load balancing algorithm for database switching is the least connection method.
To track the state of each load balanced database server in real time, you need to bind a monitor to each service. The monitor is configured to test the service by sending periodic probes to the service. If the monitor receives a timely response to its probes, it marks the service as UP. If it does not receive a timely response to the designated number of probes, it marks the service as DOWN.
DataStream supports server versions 2000, 2005, 2008, 2008R2, 2012 with Kerberos Authentication Support.
The following deployments are supported by DataStream:
SQL Server Clustered Instances
SQL Server Mirroring
SQL Server 2012 AlwaysOn Availability Groups
SQL Server Replication
SQL Server SQL Server Replication
SQL Server Logshipping
Supported Microsoft SQL Server versions for the Site Configuration Database (which initially includes the Configuration Logging Database and the Monitoring Database):
SQL Server 2012 SP1 - Express, Standard, and Enterprise Editions. By default, SQL Server 2012 Express is installed when installing the Controller.
SQL Server 2008 R2 SP2 - Express, Standard, Enterprise, and Datacenter Editions.
The following database features are supported (except on SQL Server Express Edition, which supports only standalone mode).
SQL Server Clustered Instances
SQL Server Mirroring
SQL Server 2012 AlwaysOn Availability Groups
Windows authentication is required for connections between the Controller and the SQL Server database.
For using Windows Authentication the DNS server needs to be configured on NetScaler:
add dns nameServer <FQDN>
For example:
> add dns nameServer sqlad.com
Create SQL server entry on NetScaler:
add server <name> <domain>
For example:
> add server sqlserver1 sqlserver1.sqlad.com
> add server sqlserver2 sqlserver2.sqlad.com
> add server sqlserver3 sqlserver3.sqlad.com
add service <name> <server> MSSQL <port>
For example:
> add service sqlsvr1 sqlserver1 MSSQL 1433
> add service sqlsvr2 sqlserver2 MSSQL 1433
> add service sqlsvr3 sqlserver3 MSSQL 1433
To use Windows Authentication to SQL servers, add a Kerberos constrained delegation account on NetScaler:
add aaa kcdAccount <name> -keytab <path to keytab file>
For example:
> add aaa kcdAccount my_kcd_acct -keytab /var/mykcd.keytab
Add a new database profile on NetScaler to enable use of KCD Account:
add dbprofile <profile name> -kcdAccount <account>
For example:
> add dbProfile kcd –kcdaccount my_kcd_acct
add lb vserver <vservername> MSSQL <IP address> <port> -dbprofile <profile name>
For example:
> add lb vserver LB_read MSSQL 10.217.201.130 1433 –dbprofile kcd
> add lb vserver LB_write MSSQL 10.217.201.131 1433 –dbprofile kcd
bind lb vserver <vservername> <servicename>
For example:
> bind lb vserver LB_read sqlsvr1
> bind lb vserver LB_read sqlsvr2
> bind lb vserver LB_write sqlsvr3
add cs vserver <vservername> MSSQL <IP address> <port>
For example:
> add cs vserver MSSQL_CS MSSQL 10.217.201.19 1433
add cs policy <policyname> -rule <expression>
For example:
> add cs policy CS_Read –rule "MSSQL.REQ.QUERY.COMMAND.EQ(\"select\")"
The preceding content switching policy rule looks for the read intent queries.
bind cs vserver <vservername> -policy <policyname> -targetLBVserver <lbvservername> -priority <number>
For example:
> bind cs vserver MSSQL_CS –policy CS_Read –targetLBVserver LB_read –priority 1
> bind cs vserver MSSQL_CS LB_write
To track the state of each load balanced database server in real time, you need to bind a monitor to each service:
add lb monitor <monitor_name> MSSQL-ECV –sqlquery <sql query> -evalrule <expression> -database <DB name> -username <DB user> -kcdAccount <account>
For example:
add lb monitor lb_mon MSSQL-ECV
-sqlQuery "select * from sys.databases;" -evalrule "MSSQL.RES.ATLEAST_ROWS_COUNT(4)"
-database "NS" -userName "user3" -kcdAccount myacc
bind service <servicename> –monitorName <monitorname>
For example:
bind lb monitor lb_mon sqlsvr1