Verifying the Configuration
The first set of test cases validated the successful integration of NetScaler into the ACI fabric and the use of APIC to define NetScaler configurations. Several test cases were run to verify NetScaler compatibility and configuration, including:
- Compatibility tests. The following compatibility tests executed successfully without displaying any errors or warning messages.
– Using APIC to import NetScaler device package
– Using APIC to create 4 device clusters for NetScaler instances
– Using APIC: delete 4 device clusters for NetScaler instances
– Using APIC: re-create 2 device clusters for NetScaler instances
- Configuration tests. The following configuration tests executed successfully. All settings were pushed to the NetScaler VPX instance as expected and the appropriate services and virtual IPs (VIPs) were available.
– Using APIC to configure L2/L3 settings for a NetScaler VPX instance.
– Using APIC to configure LB settings for a NetScaler VPX instance.
– Using APIC to configure CS settings for a NetScaler VPX instance.
– Using APIC to configure AppFW settings for a NetScaler VPX instance.
– Using APIC to configure GSLB settings for a NetScaler VPX instance in a data center.
Figure 5-1 shows the APIC dashboard for the system solution configuration. The dashboard summarizes configuration health, helping to confirm (in addition to the traffic flow tests) that the NetScaler VPX instances have been deployed and configured successfully.
Figure 5-1 Control Switching Service Topology
Validating Traffic Flows with NetScaler
The following sections describe validating traffic flows with NetScaler:
Validating General Traffic Flows with NetScaler
Additional tests verified the ability of a NetScaler instance to perform traffic management for general traffic on the ACI fabric. All ACI traffic (HTTP/TCP on port 80; SSL/TCP on port on port 443; TCP/TCP on port 8080; and DNS/UDP on port 53) is subject to Load Balancing and SSL Offloading. Tests were run to validate these traffic flows:
- Load Balancing. HTTP, TCP, DNS traffic was processed using the Load Balancing VIPs configured for the NetScaler instance.
- SSL Offloading. SSL traffic was directed to LB VIPs to accelerate SSL Offloading in NetScaler SDX hardware.
Validating SharePoint Traffic Flows with NetScaler
To validate that SharePoint traffic flows through the NetScaler VPX instances securely and correctly, the SharePoint server farm was configured with two SharePoint sites, Engineering and Marketing, to simulate a large enterprise organization. In this way, it was possible to examine how NetScaler applied Content Switching policies to direct SharePoint client requests as well to SQL database requests. Based on the specified URL in the request (for example, https://sp2013.test.ctx/sites/Eng/… or https://sp2013.test.ctx/sites/Mkt/…), the NetScaler VPX instance directed the request to the Load Balancing VIP bound to the Content Switching VIP.
Figure 5-2 and Figure 5-3 shows Content Switching functionality across the two SharePoint sites. Each site was accessed by different users, user aaa and bbb, respectively. The user login authentication occurred on the SharePoint server that received the user request.
Figure 5-2 Content Switching Across Two SharePoint Sites (user aaa)
Figure 5-3 Content Switching Across Two SharePoint Sites (user bbb)
Validating Microsoft SQL Server Flows with NetScaler
The test environment configures NetScaler instances to manage traffic for Microsoft SQL Server 2012 cluster. NetScaler performs Content Switching for database requests as well as load balancing. Since there are multiple secondary databases in an AlwaysON Availability Group, the NetScaler LB VIP distributes database read traffic based on the defined load-balancing algorithm. These test cases validated traffic flows for database requests:
- Microsoft SQL Server Load Balancing —As expected, the NetScaler instance directed database requests to the Content Switching virtual server (vserver) for load balancing.
- Microsoft SQL Server Content Switching for Read/Write Split —For an SQL query that writes to the database, the NetScaler instance directs it to the LB VIP that routes it to the appropriate primary database. For read operations, the query is sent to the LB VIP that routes it to a secondary replica database.
- Intelligent Monitoring for Microsoft SQL Server Health Check —Native MS-SQL monitors configured in the NetScaler instance query a particular field in a database table to determine which node is the current secondary. The monitor probe queries the database for the secondary replica and marks the primary replica service as down in the NetScaler instance.
Validating AppFW Functionality with NetScaler
As a part of the NetScaler configuration process, an administrator should import the Microsoft SharePoint signature file prior to configuring the AppFW service graph and parameters. Using a Citrix account, the administrator can download a signature file from the site: https://www.citrix.com/downloads/netscaler-adc/components/application-signature-protection-for-application-firewall.html. For this system solution, the signature file for the NetScaler 10.5 release (sig-r10.5b0v8s5.xml) was downloaded and customized.
The following test cases validate the successful configuration of AppFW functionality:
- AppFW blocks the sites that are not specified in the startURL. In the test environment, access is permitted to two SharePoint sites only: https://sp2013.test.ctx/sites/Eng and https://sp2013.test.ctx/sites/Mkt. Access to https://sp2013.test.ctx/sites/Financial, however, is blocked.
- AppFW blocks SQL injection attacks. The NetScaler instance successfully blocks access to a site that attempts to inject SQL queries, such as the URL: https://sp2013.test.ctx/sites/Eng/SitePages/Home.aspx?select;
- AppFW blocks XSS (Cross-Site-Scripting) attacks. In this test case the NetScaler instance successfully blocks XSS attacks. NetScaler blocked access to this URL: https://sp2013.test.ctx/sites/test/_layouts/15/start.aspx#/SitePages/Home.aspx?<script>.
- AppFW blocks Denial of Service (DoS) vulnerability in MS SharePoint. In this test case, NetScaler blocked access for a known XSS attack when accessing this URL: https://sp2013.test.ctx/sites/test/_layouts/15/start.aspx#/SitePages/Home.aspx?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN.
Validating Solution High Availability and Failover
The topology for this system solution provides redundancy and failover for NetScaler VPX instances, NetScaler SDX appliances, fabric nodes, and APIC servers. In addition to redundancy and failover features in the tested solution, an enterprise SharePoint deployment should include monitoring to foster high service levels. In NetScaler deployments, SNMP and syslog monitoring are usually performed out-of-band to detect and proactively resolve problems. These methods can be used in-band through the ACI fabric as well.
NetScaler VPX Instance Failover
NetScaler VPX instances are configured in an HA device cluster in Active-Standby mode. (NetScaler Active-Active configuration is not yet supported because Dynamic Routing is required, which is forthcoming in a future Cisco ACI software release.)
To validate the HA configuration and failover of NetScaler VPX instances, an administrator forced a failover scenario by entering “force failover –force” to the Primary NetScaler VPX instance. The process was repeated to force a failover again on the Primary HA node. Immediately after each forced failover, traffic was directed and processed by the new Primary HA node as expected.
In addition to failover testing, administrators added and removed VPX instances on the NetScaler SDX appliance. Other instances were not impacted and continued to manage traffic on the fabric.
NetScaler SDX Appliance Failover
An additional test case was performed to validate failover in the event of an unavailable NetScaler SDX appliance. In particular, the test case validated continued operation after a simulated failure of the appliance hosting the HA Primary NetScaler VPX instance. For this test case, APIC configured the HA device cluster in Active-Standby. When the SDX unit with the primary instance was made unavailable, the standby HA instance on the other unit became the Primary HA node. Traffic management continued as expected.
Fabric and APIC Failover Scenarios
For this system solution, a number of failover scenarios were validated to demonstrate SharePoint application continuity. The following failover scenarios were successfully validated in testing the system solution environment within a single data center:
- Single link in LACP channel failure. Fabric traffic continues to flow using all other physical links.
- Single vPC leg failure. Fabric traffic continues to flow using the other vPC leg.
- Single leaf failure. Fabric traffic flows using an alternate leaf.
- Single spine failure. Fabric traffic continues to flow on the fabric using an alternate spine.
- Single APIC failure. An alternate APIC server from the APIC cluster is still available. As expected, fabric traffic continues to flow.
Configuring NetScaler GSLB for Multiple data centers
When configured for global server load balancing (GSLB, Figure 5-4), NetScaler appliances support disaster recovery and enable continuous application availability, protecting against single points of failure in a WAN deployment. GSLB enables intelligent load distribution, by directing client requests to the closest or best performing data center, or to an available and online data center in the case of an outage.
Figure 5-4 GSLB Across Two Data Centers
When GSLB is configured, NetScaler appliances use the DNS infrastructure to connect client requests to the data center that best meets the set distribution criteria. NetScaler devices keep track of the location, performance, load, and availability of each data center and use these factors to select the data center for the client request.
An ADNS service is a special kind of service that responds only to DNS requests for domains for which the NetScaler appliance is authoritative. When an ADNS service is configured, the appliance owns that IP address and advertises it. Upon receipt of a DNS request by an ADNS service, the appliance checks for a GSLB virtual server bound to that domain. If a GSLB virtual server is bound, it’s queried for the best IP address to which to send the DNS response. (Note: On a public DNS server, configure the IPs of ADNS services from both data centers as authoritative DNS servers for the domain.)
NetScaler GSLB capabilities were implemented and tested for this system solution using the XML files listed in Appendix C, “Configurations.”
After configuring GSLB in the system solution environment, this functionality was tested by simulating a data center link failure. As expected, NetScaler successfully redirected traffic to the remaining available data center. Various GSLB distribution scenarios were also configured and tested. For example, NetScaler instances can distribute client load across data centers according to different algorithms. This system solution successfully validated three GSLB distribution scenarios:
- Dynamic Proximity— A delay injector was used to simulate a data center with less proximity. The NetScaler instance tracks Round Trip Time (RTT) and distributes load based on this value. Clients connected only to the data center with the least RTT value.
- Static Proximity— Based on the VLANs, the NetScaler instance directs traffic to the closest data center. In this way, clients connect to the data center in the same region.
- Even Distribution— The NetScaler instance tracks the number of connections and distributes the client request to the data center with the lowest number of connections. This method spreads out load across configured data centers.