When Netscaler DataStream was first announced, it introduced something that no other ADC was able to offer to the market……an intelligent way to accelerate, optimize and give full visibility to native SQL traffic. Fast forward, a year later, we’ve received a tremendous amount of field adoption and validation, allowing us to continue to add functionality to what appears to be the next frontier in the ADC market.

The recent Landmark release of Netscaler v10 continues to re-define the way people deploy and deliver services to their end users. In this release, we’ve added significant features to DataStream, which further improves upon the functionality in several dimensions.

 

Performance: DataStream Caching

In addition to the current optimizations that we offer for native SQL traffic, we’ve now introduced caching for database traffic. This means responses to database queries now can be serviced directly out of cache, dramatically improving performance and offloading the back-end databases.  We’ve leveraged our already ‘rock solid’ , in-memory cache infrastructure that has been in place for many years, along with full advanced policy support now for native SQL traffic.

All the same concepts of Netscaler IC we had for http apply here, including the cache content groups for ease of management, granular policy control and cache expiry. Below is a simple example of a SQL cache config using the cli. The example includes both a cache policy as well as an invalidation policy. The cache policy is based on a ‘select’ operation and invalidation which will occur when there is an ‘insert’ function as it will mark that there has been a change to the data. Note that you can make your cache policies as granular as needed based on parameters associated with the query.

 

Add Cache Selectors:

  • add cache selector sel1 mssql.req.query.text
  • add cache selector inval_sel “MSSQL.REQ.QUERY.TEXT.AFTER_STR(\”from \”).BEFORE_STR(\”;\”) ALT MSSQL.REQ.QUERY.TEXT.AFTER_STR(\”into \”).BEFORE_STR(\” \”)”

Define Cache Content Group:

  • add cache contentGroup cg1 -hitselector sel1 -invalselector inval_sel -relExpiry 50

Add Cache Policies:

  • add cache policy cp1 -rule “mssql.req.query.command.contains(\”select\”)” -action CACHE -storeInGroup cg1
  • add cache policy cp2 -rule “mssql.req.query.text.contains(\”insert\”)” -action INVAL -invalObjects cg1

Bind to Vservers:

  • bind lb vserver lb1 -priority 2 -policyName cp1 -type REQUEST
  • bind lb vserver lb1 -priority 1 -policyName cp2 -type REQUEST

 

 

Load balancing: Token LB for SQL

Along with all of the previously available load balancing algorithms that are available for DataStream, we’ve now introduced Token based LB for SQL. Tokens can now be defined and assigned based on incoming SQL queries. Policies can be defined using the following parameters:

 

 

 

Tokens are assigned and used to make server selections for subsequent requests/queries for the given session. Dynamic re-selection of backend services will happen if connection limits are reached or services become unavailable. The end result is more efficient internal cache utilization on the database server as it is now servicing similar queries or stored procedures.

 

 

Visibility: Auditlog, Appflow and Responder for DataStream

Another key benefit that DataStream brings to the table is real time, comprehensive visibility of all your database traffic. Allowing for ‘top-down’ reporting statistics, DataStream can help identify everything from potential application coding issues thru security threats and backdoors that may have been left open. DataStream offers a complete auditlog of all transactions with the ability to access granular information down to a query level including parameters like connection ID, username, dbname, ipaddress, etc…..

All of this information can also be exposed via AppFlow to third party utilities such as Splunk, Solarwinds, Lancope, etc.. using new predefined templates or creating your own as needed.

NetScaler, newly introduced Action Analytics can also consume this Appflow data, giving the administrator quick and easy access to graphical format of all the pertinent information. Real time decisions can then be made and appropriate policies can be added on the fly. Using NetScaler Responder functionality, we can construct these policies allowing us to filter queries as needed, adding additional security to the Database tier. An example use case here may be a Responder policy that never allows a ‘drop database’ query to be passed to the database servers. Netscaler would block the request and can either return a user defined message or simply drop the query. The Database would never see the request and would be protected against the action.

 

This is just a glimpse into some of the new features v10. If you haven’t explored the capabilities of DataStream yet, I urge you to do so now more than ever. Using DataStream effectively has clearly demonstrated that the bottleneck which once existed on the back-end can be lifted, giving your application new levels of performance, scalability and visibility that never existed before.