WFS dynamically provisions NetScaler VPX for SAP Load Balancing
In a previous post I discussed some use cases around the automatic provisioning of load balancing on a Citrix NetScaler using Citrix Workflow Studio.
We recently completed the follow-on project of creating a Workflow Studio script to perform a "Loop" to check the SAP Status Server on a regular basis, and dynamically Enable or Disable server load balancers in the NetScaler.
Drawing on the use cases from the previous post, we decided to build one WFS script to dynamically handle everything:
- Auto-configure new SAP services
- Graceful shutdown of SAP services
The latest script reads the SAP Status Server every x minutes or seconds, and based on the information in the SAP Status file, determines if a load balancing service should be enabled or disabled. This is useful for when SAP Servers are marked as "Down" and the NetScaler needs to reflect this change, dynamically. When the SAP Server comes back online, WFS enables the service in the NetScaler.
The WFS program that was designed to read the SAP Status Server is based on the SAP Message Server API specification, which can be found by clicking here.
SAP Status Message file format
<server-list> = "version" <major>"."<minor> CRLF
<sap-server-name> CRLF
<protocol-type> <host> <port> <description> CRLF
...
<protocol-type> <host> <port> <description> CRLF
CRLF
<sap-server-name> CRLF
<protocol-type> <host> <port> <description> CRLF
...
<protocol-type> <host> <port> <description> CRLF
SAP Message field to NetScaler Config Mapping
WFS Use Case
Read the file http://10.217.105.139/SAPStatus.htm
Skip 1st line. (version 1.2).
Loop1:
Read the sap-server-name, create Citrix NS Service.
Loop2:
Read message line.
If Description LB=0, shutdown the service.
If Description LB<>0 && doesn't already exists the service, add the server and service:
Server = host
Port = port
Protocol = HTTP if J2EE, HTTPS if J2EES.
Sleep 30 seconds
End Loop2. (if line = blank).
End Loop1. (eof)
Sample SAPStatus.htm file used in this POC
version 1.2
J2EE187834720
J2EE Server1 51800 LB=2
J2EES Server1 51801 LB=2
P4 Server1 51804 LB=2
P4S Server1 51805 LB=2
IIOP Server1 51806 LB=2
IIOPS Server1 51807 LB=2
TELNET Server1 51808 LB=2
J2EE187834721
J2EE Server2 55000 LB=1
P4 Server2 55004 LB=1
IIOP Server2 55007 LB=1
TELNET Server2 55008 LB=1
J2EE187834722
J2EE Server3 56000 LB=0
P4 Server3 56004 LB=0
IIOP Server3 56007 LB=0
TELNET Server3 56008 LB=0
Where:
Server1 is the Citrix NS Service Name
J2EE indicates use the HTTP Protocol
J2EES indicates use the HTTPS Protocol also.
51800 is the port number to use on the backend
LB=2 indicates the service is up and running (LB<>0)
Get your own and try it
Download NetScaler config file here
Download Sample SAPStatus.htm file here
If your not running XenServer yet, you should be, its free
Dynamic Load Balancing in action
Tap into the power of AppExpert!
Wavemaker integrates with Citrix NetScaler seamlessly for web services.
WaveMaker Visual Ajax Studio is an easy-to-use visual builder that enables the drag & drop assembly of scalable, web-applications using Ajax widgets, web services and databases. WaveMaker Studio will look and feel especially familiar to client/server developers who are used to working with visual tools. Check out the Wavemaker specifications here.
WaveMaker has helped customers reduce development costs by 67% and cut the lines of code written by 98%. Less code makes WaveMaker applications cheaper to maintain and easier to manage. The NetScaler REST API's are going to be released soon. Today, the API provides web services in the form of Java. We, at Citrixlabs, have recently been using the Java Services and the examples in our API Documentation, with Wavemaker, to built a Proof of Concept.
Wavemaker allows you to build a GUI interface, consume web services through a .wsdl definition, save it to a WAR file, and then run that WAR file against a Tomcat web server. All of this is done using Drag & Drop functionality in the Wavemaker interface. Running a WAR file, allows interaction with the NetScaler for several types of services such as configuring load balancing services, or gathering statistics.
Possible uses
Users can create their own interface/GUI to the NetScaler for configuration and monitoring. Multi-tenancy has come up in discussions, as a way to manage multiple configurations through a single interface, perhaps on several NetScaler VPX devices, either in a XenServer deployment or in the cloud.
Current Proof of Concept
Having said that, using Wavemaker, we were able to successfully ...
- Create a GUI user interface to NetScaler
- Consume the NSConfig web services from the examples in the NetScaler API Documentation
- Configure the NetScaler with a new Load Balancing VIP and associated backend servers
If you have a NetScaler, the API's are already there. Connect to your NetScaler, select downloads, and navigate to XML API.
The best part about Wavemaker is it is Open Source.
Tap into the power of AppExpert!
Netscaler 9.1
Citrix NetScaler 9.1 Classic and nCore are now RTW - Release to Web, and are available to all customers via the Downloads section of the citrix.com support site.
What's New:
NetScaler Licensing Update - Starting May 25, all NetScaler appliances that are shipped from Citrix no longer contain pre-installed licenses. Reference "How To License NetScaler Appliances using the Activation System/Manage Licenses Tool on MyCitrix.com" in the Knowledge Base (CTX121062) or contact Customer Service.
Release 9.1 Classic only:
- Support of New MPX 5500, 7500 platforms (8.1 build 65.5 and later are also supported on these new platforms)
- NetScaler Web 2.0 Push
- GSLB
- AppFW
Release 9.1 nCore only:
- NetScaler nCore software (9.1.nc) is currently intended only for use on the NetScaler MPX 15000 and MPX 17000 appliances. All other NetScaler appliances should use Release 9.1 Classic.
Citrix® NetScaler® nCore™ technology is a high performance, parallel-processing architecture that efficiently leverages multi-core technology to scale to meet the requirements of the most demanding Web applications.
The performance and scalability benefits enabled by nCore technology have significance for both current and future Web application delivery requirements. nCore technology provides:
- Better performance for Web 2.0 and rich Internet applications
- Improved ability to handle large traffic spikes
- Expanded capacity to support more users and more applications
- An all-in-one platform for Web application delivery requirements: L4-7 load balancing, caching, GSLB, compression, SSL VPN, SSL offload, application security, performance monitoring and more.
For complex layer 7 workloads that tend to be more CPU intensive, nCore technology provides up to a sixfold improvement. Applications needing to support many concurrent users will benefit from a sevenfold improvement in concurrent connections.
For more information on the NetScaler 9.1 product release, especially for 9.1 Classic and nCore supported features, visit the Release Notes under General Documentation section at http://support.citrix.com.
If further assistance is required, contact the Customer Service representative in your area.
Download Details:
The FCS build is available for download from the following locations:
Via MyCitrix: www.MyCitrix.com > Home > Support > Downloads > NetScaler
Employees and customers with valid ANG maintenance contracts who have requested/received MyCitrix login credentials will be able to view and retrieve files from this location.
Via FTP: ftp.netscaler.com
If you do not have access to this folder, login credentials for this site are available through Technical Support.
Tap into the power of AppExpert!
Netscaler nCore
Already announced at iForum, but worthy of buzz, is the new multi-core, parallel processing architecture for the Citrix NetScaler released in version 9.1 - nCore Technology. Applications are becoming more dynamic and demanding as we have seen in recent community, social networking and Web 2.0 advancements. Browser request and server response is the old model. Rich interactive applications that provide real-time information require real-time connections between browser and server. Enterprise software vendors such as SAP, Microsoft, Oracle and others understand the need to push toward highly interactive applications that enrich the functionality and user experience.
The richness of experience manifests in several ways:
- Protocols: New protocols such as Ajax, Comet, Ruby, etc.
- Connections: Web 2.0 protocols generate more connections between client and server.
- Chattiness: Web 2.0 protocols initiate more requests between the client and server.
- Applications: Rich Internet applications such as Flash, Flex and Silverlight make applications engaging and interactive.
- Clients: Clients are always connected and content needs to be optimized for them (iPhone, Symbian, Blackberry, Palm, Windows Mobile, Internet Explorer, Firefox, Safari).
ADC's need to deliver greater performance and scalability by supporting higher levels of throughput, HTTP requests, concurrent connections and SSL Transactions. ADC's need to handle the increase in connections and requests to offload the demands placed on back-end web servers. The demands for caching, compression and application firewalls will increase as well.
In order to meet the increasing demand in application delivery environments, you need the Citrix NetScaler nCore technology.
Tap into the power of AppExpert!
Secure Selected Pages
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
In situations where you want to make sure that for some selected pages only the secure server is used, the following can be used.
Apache rewrite:
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/?(page1|page2|page3|page4|page5)$ https://www.example.com/%1 [R,L]
AppExpert rewrite example 1:
Add responder action res_redirect redirect '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.REGEX_MATCH(re/page[1-5]/)' res_redirect
Bind responder global pol_redirect 100 END
AppExpert rewrite example 2:
Add patset pat1 Bind patset pat1 page1 Bind patset pat1 page2 Bind patset pat1 page3 Bind patset pat1 page4 Bind patset pat1 page5 Add responder action res_redirect redirect '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.CONTAINS_ANY("pat1")' res_redirect Bind responder global pol_redirect 100 END
Tap into the power of AppExpert!
Redirecting a URI to a new format
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Let's say, for example, that you've got a set of working URLs that look like this: /index.php?id=nnnn. However, you'd really like to change them to /nnnn and make sure search engines update their indexes to the new URI format. First, you'd have to redirect the old URIs to the new ones so that search engines update their indexes, but you still have to rewrite the new URI back to the old one so that the index.php script would run.
Example: The trick here is to place into the query string a marker code that will not be seen by visitors. We redirect from the old link to the new format only if the "marker" is not present in the query string. Then we rewrite the new format link back to the old format, and add a marker to the query string.
Apache rewrite:
RewriteCond %{QUERY_STRING} !marker
RewriteCond %{QUERY_STRING} id=([-a-zA-Z0-9_+]+)
RewriteRule ^/?index\.php$ %1? [R,L]
RewriteRule ^/?([-a-zA-Z0-9_+]+)$ index.php?marker&id=$1 [L]
AppExpert rewrite:
Add responder action act_redirect redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("index.php")+HTTP.REQ.URL.QUERY.VALUE("id")' -bypassSafetyCheck yes Add responder policy pol_redirect '!HTTP.REQ.URL.QUERY.CONTAINS("marker")&& HTTP.REQ.URL.QUERY.VALUE("id").REGEX_MATCH(re/[-a-zA-Z0-9_+]+/) && HTTP.REQ.URL.PATH.CONTAINS("index.php")' act_redirect Bind responder global pol_redirect 100 END Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"index.phpmarker&id="+HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' -bypassSafetyCheck yes Add rewrite policy pol1 '!HTTP.REQ.URL.QUERY.CONTAINS("marker")' act1 Bind rewrite global pol1 100 END
Tap into the power of AppExpert!
Creating Extensionless links
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Sometimes you may want to support extension less links, either to hide extensions from end users or to make URLs easy to remember.
Example 1: add .php extension to all requests
Apache rewrite:
RewriteRule ^/?([a-z]+)$ $1.php [L]
AppExpert rewrite:
Add rewrite action act1 insert_after 'HTTP.REQ.URL' '".php"'
Add rewrite policy pol1 'HTTP.REQ.URL.PATH.REGEX_MATCH(re#^/([a-z]+)$#)' act1
Bind rewrite global pol1 100
Example 2: if we have a mixture of both .html and .php files, the following can be used
Apache rewrite:
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.php [L]
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.html [L]
AppExpert rewrite:
Here HTTPCallout would be used, script file_check.cgi hosted on 10.102.59.101 is used to check wether provided argument is avalid file name or not.
add HTTPCallout Call_html add HTTPCallout Call_php set policy httpCallout Call_html -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url+".html" set policy httpCallout Call_php -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url+".php" Add patset pat1 Bind patset pat1 .html Bind patset pat1 .php Bind patset pat1 .asp Bind patset pat1 .cgi Add rewrite action act1 insert_after 'HTTP.REQ.URL.PATH' '".html"' Add rewrite action act2 insert_after "HTTP.REQ.URL.PATH" '".php"' Add rewrite policy pol1 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_html)' act1 Add rewrite policy pol2 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_php)' act2 Bind rewrite global pol1 100 END Bind rewrite global pol2 101 END
Tap into the power of AppExpert!
Blocking Inline Images
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume you have under http://www.quux-corp.de/~quux/ some pages with in lined GIF graphics. These graphics are nice, so others directly incorporate them via hyperlinks to their pages. you don't like this practice because it adds useless traffic to your server.
Example : You can restrict the cases where the browser sends a HTTP Referer header.
Apache rewrite:
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$
RewriteRule .*\.gif$ - [F]
AppExpert rewrite:
Add patset pat1 Bind patset pat1 .gif Bind patset pat1 .jpeg add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"' add responder policy pol1 '!HTTP.REQ.HEADER("Referer").EQ("") && !HTTP.REQ.HEADER("Referer").STARTSWITH("http://www.quux-corp.de/~quux/")&&HTTP.REQ.URL.ENDSWITH_ANY("pat1")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Blocking Robots
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
You can block a really annoying robot from retrieving pages of a specific webarea. This way you can ease up the traffic at some directories.
Example : This could be done by using a rule set which forbids the URLs of the web area /~quux/foo/arc/. This could also be accomplished by matching the User-Agent HTTP header information. In this example, the ip address to be blocked is 123.45.67.8 & 123.45.67.9.
Apache rewrite:
RewriteCond %{HTTP_USER_AGENT} ^NameOfBadRobot.*
RewriteCond %{REMOTE_ADDR} ^123\.45\.67\.[8-9]$
RewriteRule ^/~quux/foo/arc/.+ - [F]
AppExpert rewrite:
add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"' add responder policy pol1 'HTTP.REQ.HEADER("User_Agent").STARTSWITH("NameOfBadRobot")&&CLIENT.IP.SRC.EQ(123.45.67.8)&&CLIENT.IP.SRC.EQ(123.45.67.9) && HTTP.REQ.URL.STARTSWITH("/~quux/foo/arc")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Browser Dependent Content
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
At least for important top-level pages it is sometimes necessary to provide the optimum of browser dependent content, i.e. one has to provide a maximum version for the latest Netscape variants, a minimum version for the Lynx browsers and an average feature version for all others.
Example : We will act on the HTTP header "User-Agent". The following config does the following: If the HTTP header "User-Agent" begins with "Mozilla/3", the page foo.html is rewritten to foo.NS.html and the rewriting stops. If the browser is "Lynx" or "Mozilla" of version 1 or 2 the URL becomes foo.20.html. All other browsers receive page foo.32.html. This is done by the following rule set:
Apache rewrite:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.*
RewriteRule ^foo\.html$ foo.NS.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx/.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[12].*
RewriteRule ^foo\.html$ foo.20.html [L]
RewriteRule ^foo\.html$ foo.32.html [L]
AppExpert rewrite:
Add patset pat1 Bind patset pat1 Mozilla/1 Bind Patset pat1 Mozilla/2 Bind patset pat1 Lynx Bind Patset pat1 Mozilla/3 add rewrite action act1 insert_before 'HTTP.REQ.URL.SUFFIX' '"NS."' add rewrite action act2 insert_before 'HTTP.REQ.URL.SUFFIX' '"20."' add rewrite action act3 insert_before 'HTTP.REQ.URL.SUFFIX' '"32."' add rewrite policy pol1 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").EQ(4)' act1 add rewrite policy pol2 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").BETWEEN(1,3)' act2 add rewrite policy pol3 '!HTTP.REQ.HEADER("User-Agent").STARTSWITH_ANY("pat1")' act3 bind rewrite global pol1 101 END bind rewrite global pol2 102 END bind rewrite global pol3 103 END
Tap into the power of AppExpert!
Old to New External URL Rewrite
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume that you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. But this time you want the users of the old URL to see new one, i.e. their browsers Location field should change too.
Example : The following rules can force an HTTP redirect to the new URL which leads to a change of the URL in the users browser:
Apache rewrite:
RewriteEngine on RewriteBase /~quux/ RewriteRule ^foo\.html$ bar.html [R]
AppExpert rewrite: (There are two ways to do this)
add responder action act1 redirect 'HTTP.REQ.URL.BEFORE_STR("foo.html")+"bar.html"' -bypassSafetyCheck yes add responder policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1 bind responder global pol1 100
add responder action act1 redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("foo.html")+"bar.html"+HTTP.REQ.URL.AFTER_STR("foo.html")' -bypassSafetyCheck yes add responder policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Old to New Internal URL Rewrite
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. Actually you want users of the old URL to not recognize that the pages were renamed.
Example : Rewrite the old URL to the new one internally via the following rule, let the base directory be /~quux/.
Apache rewrite:
RewriteEngine on RewriteBase /~quux/ RewriteRule ^foo\.html$ bar.html
AppExpert rewrite: (There are two ways to do this)
add rewrite action act1 replace 'HTTP.REQ.URL.AFTER_STR("/~quux").SUBSTR("foo.html")' '"bar.html"' add rewrite policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1 bind rewrite global pol1 100
Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"bar.html"' Add rewrite policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1 Bind rewrite global pol1 100
Tap into the power of AppExpert!
Time Dependent Rewriting
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
We can rewrite a URL based on time.
Example : Changing the request foo.html to foo.day.html or foo.night.html according to time.
Apache rewrite:
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.day.html [L]
RewriteRule ^foo\.html$ foo.night.html
AppExpert rewrite:
Add rewrite action act1 insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"day."' Add rewrite action act2 insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"night."' add rewrite policy pol1 'SYS.TIME.WITHIN(LOCAL 07h 00m,LOCAL 18h 59m)' act1 add rewrite policy pol2 'true' act2 bind rewrite global pol1 101 bind rewrite global pol2 102
Tap into the power of AppExpert!
Failed URL Redirect
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
In case the current url is not valid & the request needs to be redirected to another web server, the following steps could be taken.
Example : We will check weather the request filename exists on the server or not, in case it fails then redirection is done to another webserver (for example, webServerB.com). In the case of AppExpert, HTTPCallout is used to check the presence of the file on the server by running a script file_check.cgi on the server. The returned value from HTTPCallout is used to validate the policy.
The Script file_check.cgi takes the url as the argument, checks for its presence on the server & returns True or False accordingly.
Apache rewrite:
RewriteCond /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule ^(.+) http://webserverB.com/$1 [R]
AppExpert rewrite: (There are two ways to do this)
add HTTPCallout Call set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url.path -headers Name("ddd") add responder action act1 redirect '"http://webserverB.com"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS && !SYS.HTTP_CALLOUT(call)' act1 bind responder global pol1 100
add HTTPCallout Call set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url.path -headers Name("ddd") add responder action act1 respondwith '"HTTP/1.1 302 Moved Temporarily\r\nLocation: http://webserverB.com"+HTTP.REQ.URL+"\r\n\r\nHTTPCallout Used"' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS && !SYS.HTTP_CALLOUT(call)' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Structured Homedirs
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Some sites with thousands of users usually use a structured homedir layout, i.e. each homedir is in a subdirectory which begins for instance with the first character of the username. So, /~foo/anypath is /home/f/foo/.www/anypath while /~bar/anypath is /home/b/bar/.www/anypath.Following rules could be used to implement this.
Apache rewrite:
RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/.www$3
AppExpert rewrite:
Add rewrite action act1 replace 'HTTP.REQ.URL' '"/home/"+ HTTP.REQ.URL.AFTER_STR("~").PREFIX(1)+"/"+ HTTP.REQ.URL.AFTER_STR("~").BEFORE_STR("/")+"/.www"+HTTP.REQ.URL.SKIP(\'/\',1)' -bypassSafetyCheck yes Add rewrite policy pol1 'HTTP.REQ.URL.PATH.STARTSWITH("/~")' act1 Bind rewrite global pol1 100
Tap into the power of AppExpert!
Move Homedirs to Different Web Server
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
There are cases when you want to redirect requests for homedirs on one web server to another web server. The typical use case for this arises when establishing a newer web server which will replace the old one over time. i.e. you need to redirect all the requests for a particular homedir to another web server.
Example : Let the hostname for new webserver be newserver.
Apache rewrite:
RewriteRule ^/(.+) http://newserver/$1 [R,L]
AppExpert rewrite: (There are two ways to do this)
Add responder action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.REGEX_MATCH(re#^/(.+)#)' act1
Bind responder global pol1 100 END
Add responder action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.LENGTH.GT(1)' act1
Bind responder global pol1 100 END
Tap into the power of AppExpert!
New NetScaler Technology Speeds Applications that Push Data to Users, Achieving Greater Real-time Interactivity with Fewer Servers Required
This groundbreaking new capability was specifically designed to address the demands that today's interactive Web 2.0 applications are placing on server infrastructures. While Web 2.0 applications are ushering in a new era of enhanced functionality and responsiveness for end users, they are highly inefficient when it comes to server computing resources. In order to create a rich interactive experience, Web 2.0 applications need to maintain a one-to-one user connection to backend servers for extended periods, which severely taxes datacenter resources and adversely impacts performance and scalability. NetScaler is the first application delivery controller to streamline this process by "pushing" data directly to thousands of users concurrently, offloading web servers from this burdensome task. As a result, server costs for delivering Web 2.0 applications can be reduced by five to ten times.
Rich Web Experience at a Fraction of the Cost
These new capabilities allow NetScaler to free up backend servers from inefficient connection management tasks, thus shrinking the number of servers needed. This reduced server footprint in the datacenter improves server utilization and allows a smaller set of servers to accomplish the same business tasks, cutting server costs by up to 90 percent by decreasing power, cooling and operational overhead.
Its powerful - AppExpert!
SharePoint Template
AppExpert Templates are nothing new for NetScaler. However, with a new release of NetScaler comes an updated, new and improved NetScaler AppExpert Template for use with Microsoft SharePoint applications.
AppExpert Templates are a simple approach to configuration management for complex enterprise applications. In one simple view, you can view what is most important to you in terms of application delivery. No more confusing and complex rules to define, reducing the time to deploy, easing management and improving the bottom line.
Improvements to the template include additional optimizations for Image Management, Scripts, SOAP and FrontPage. Caching and Compression policies have been optimized, along with the addition of a section for rewrite. There is a redirect policy for converting HTTP to HTTPS on the fly, to enable secure traffic to/from the Microsoft SharePoint applications.
All of these improvements can be found in the new Microsoft SharePoint template, and a description of the template can be found in the updated SharePoint Deployment Guide.
Download the updated Microsoft SharePoint AppExpert Template here (NS v9.0 b66 required).
Download the updated Microsoft SharePoint Deployment Guide here.
Its Powerful - AppExpert!
Load Balancing Auto-Configuration for SAP using Workflow Studio and NetScaler
At the tail end of our certification process at SAP, Citrix engaged in a unique opportunity to make use of the SAP APIs, using Workflow Studio to auto-configure the Citrix NetScaler for Load Balancing. The way it works is, Workflow Studio polls the SAP API, reads the response, and then based on the results in the response, configures the NetScaler Load Balancing groups that map directly to the SAP servers running in the server farm.
SAP has a community group dedicated to the development of their APIs, please reference the latest blog post Catching Up with Deployment and Operations Automation, describes the SAP APIs.
The SAP Community Definition Group (CDG) - titled "PCDG 97 NetWeaver Infrastructure APIs for Network Solutions" - is focused on automation of network-application integrated configuration and operation. As the group title implies, the SAP NetWeaver technology platform includes APIs, which are used by the NetScaler ADCs (load balancers) to auto-configure themselves as proxies for multi-instance SAP application systems. Using Citrix Workflow Studio, the SAP APIs are polled on a regular basis so that the NetScaler ADCs can react to SAP application instance changes during production runtime.
If another application instance is brought up, let's say for providing more computing capacity for an increasing end-user load, or if an instance is brought down temporarily for maintenance, Workflow Studio communicates with the NetScaler ADC to adjust load balancing automatically without any manual administrator intervention. There is no more wait, or lengthy change management required to provision applications.
Workflow Studio, NetScaler and SAP API Use Cases:
Use Case 1: (auto-configure new SAP services).
Workflow Studio sends a URL request to the SAP Message Server, and receives a response. Workflow Studio parse's the response, looking for specific SAP generated patterns. WFS then uses this information to configure a Load Balancing Virtual Server inside of the Citrix NetScaler.
Use Case 2: (dynamic configuration).
Workflow Studio repeatedly queries the SAP API. WFS studio can determine hostnames, ip addresses, port numbers, and whether an SAP server is coming online or going down. When a SAP server comes online/goes down - WFS detects this change, and then takes action on the Citrix NetScaler, to add/remove the SAP service from the Load Balancing group - automatically.
Use Case 3: (graceful shutdown).
Workflow Studio queries the SAP API, determines a SAP server is going down, and based on the response, waits until all existing sessions have been retired, before removing the server from the Load Balancing group . During the shutdown period, no new sessions are added to that SAP server, providing a graceful shutdown of the SAP service. This way, there are no TCP resets sent to existing sessions. New logins are routed to a different server.
Read the SAP article here.
Tap into the power of AppExpert!
Canonical Hostnames
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
The goal of the following rule is to force the use of a particular hostname, in preference to other hostnames which may be used to reach the same site. For example, if you wish to force the use of www.example.com instead of example.com, you might use a variant of the following rules.
Example : changing example.com to www.example.com
Apache rewrite:
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*) http://www.example.com:%{SERVER_PORT}/$1 [L,R]
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.example.com/$1 [L,R]
AppExpert rewrite:
add responder action act1 redirect '"http://www.example.com:"+CLIENT.TCP.DSTPORT+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&!HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
add responder action act1 redirect '"http://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
Tap into the power of AppExpert!
Follow on Twitter