Post to Twitter
New Tolly report shows that NetScaler 9.1 with nCore technology significantly outperforms F5's latest software release, BIG-IP v10. The results were astounding. Tolly conducted a battery of standard load balancing and acceleration tests and found that F5 introduces at least 3X more latency than NetScaler across all test scenarios. The report details the impressive performance NetScaler's nCore technology and highlights a significant deficiency with F5's architecture, namely latency. For example, it takes F5 2533.4 milliseconds to deliver an 8KB object versus 1.5 milliseconds for NetScaler. That's a significant negative impact to the end user experience and productivity, which can directly affect a company's bottom line.
To view the full Tolly report, click here
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!
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!
Canonical URLs
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. On some Apache web servers there is more than one URL for a resource. Usually there are canonical URLs (which should be used and distributed as a best practive) and those which are just shortcuts, internal ones, etc. Independent of which URL was supplied with the request, the user should only see the canonical one URL in the response.
Example : converting URL /~user to /u/user.
Apache rewrite:
RewriteRule ^/~([^/]+)/?(.*) /u/$1/$2[R]
AppExpert rewrite:
Add responder action act1 redirect '"/u/"+HTTP.REQ.URL.AFTER_STR("/~")' -bypassSafetyCheck yes Add responder policy pol1 'HTTP.REQ.URL.STARTSWITH("/~") && HTTP.REQ.URL.LENGTH.GT(2)' act1 Bind responder global pol1 100
Tap into the power of AppExpert!
SAP certifies NetScaler v9.0 and Branch Repeater/WANScaler v4.5 solution
On 3/31/2009, SAP certified Citrix NetScaler v9.0 and Citrix Branch Repeater/WANScaler v4.5 as an integral solution to improve the delivery of the SAP applications. For SAP Portal, the Citrix NetScaler & Branch Repeater/WANScaler solution improved response time to clients. For downloads and backend operations from SAP Composite and ERP servers, response time was also improved.
SAP customers have hundreds of branch offices with a mixture of small and large offices, and a global distribution. It is important to have a solution which optimizes, simplifies and accelerates the delivery of the SAP applications. During certification testing it was proven that the NetScaler and Branch Repeater/WANScaler products improve performance of SAP applications through acceleration, provide security through HTTPS connections, and provide reliability & high availability through load balancing.
Read more about NetScaler here.
Read more about Branch Repeater/WANScaler here.
Tap into the power of AppExpert!
Cost Savings, Green Benefits and Improved Server Management.
Citrix Systems, Inc. (NASDAQ: CTXS), the global leader in application delivery, recently announced that leading enterprise resource planning (ERP) manufacturer SAP AG will be virtualizing an estimated 500 servers with Citrix® XenServer™ by the middle of 2009. SAP has also deployed Citrix® XenApp™ application virtualization technology to deliver applications to both SAP employees and external partners. In addition, SAP expects to receive the benefits that a combined XenServer and XenApp solution provides - such as streaming standardized workload images and superior management functionality - which the company anticipates will generate a 35 percent savings in terminal server costs.
SAP was looking to consolidate its server infrastructure and also wanted to create a much more flexible and dynamic computing architecture. Following an extensive test of XenServer, the company decided to move forward with a multi-stage roll-out of the server virtualization solution onto 500 servers, initially in the company's Saint Leon Rot, Germany office. In the next phase of the project, the servers that power the worldwide training centers will be virtualized, followed by the project management division with several hundred development, test, and support environments. After the server virtualization project in Germany is complete, the roll-out will continue at the end of 2009 to SAP's offices in Asia and the United States.
SAP has also deployed Citrix XenApp application virtualization technology to deliver more than 40 applications, including Microsoft Office and the SAP Business Suite software, to its entire user base. In total, there are more than 50,000 end users who access the XenApp infrastructure to work on tasks such as product development and support.
Its powerful AppExpert!
HTTP Callouts
New in NetScaler 9.0 is the ability to perform a callout using HTTP to an external server. An HTTP Callout is a means to process incoming packets on the NetScaler using an external service that can be a virtual server on the NetScaler itself, a back-end server, or an third party service.
Traditionally, the NetScaler used to verify these packets internally using in-built policies but with specialized services being available for validation, they can be integrated with the NetScaler using this feature.
An HTTP callout will consist of a NetScaler policy expression that can send a simple HTTP request to an external service, wait for the response and then parse the response to produce a simple result. The result will then be used like any other policy expression evaluation result.
The HTTP callout expression:
SYS.HTTP_CALLOUT(<name of HTTP Callout>)
To define the HTTP callout:
set policy httpCallout <name>
[-IPAddress < ip_addr|ipv6_addr>]
[-port <port>]
[-vServer <string>]
[-returnType <returnType>]
[-httpMethod ( GET | POST )]
[-hostExpr <string>]
[-urlStemExpr <string>]
[-headers <name(value)> ...]
[-parameters <name(value)> ...]
[-fullReqExpr <string>]
[-resultExpr <string>]
Where:
-returnType must be one of TEXT, NUM or BOOL.
-IPAddress IP address of the server to which callout is made
-port Port of the server to which callout is made
-vserver must be one of the vservers added using the "add lb/cs/cr vserver" command. The service type of the vserver must be HTTP.
-httpMethod could be GET or POST.
-hostExpr Complex PI string expression for value of the Host header.
-urlStemExpr Complex PI string expression for generating the URL stem.
-headers Every header name must have a corresponding value. These headers will be inserted in the request. Header name is string. Header values are Complex PI Expressions.
-parameters Every parameter name must have a corresponding value. These parameter names are put in the URL query if the request has a GET method or they are put in the body if the request has a POST method. One must not rely on the order in which the parameters are inserted. Parameter name is a string. The parameter values can be computed using Complex PI String expressions. The parameter values will be URL encoded.
-fullReqExpr A complex PI String expressions computes the entire request. It is the user's responsibility to provide a well formed and sane HTTP request. The system will not do any sanity checking. If full request is specified then none of the other arguments can be specified.
HTTP callouts are available with HTTP or TCP Content Switching, Responder and Rewrite functionality.
The basic communication flow for HTTP callout is:
1. User sends request
2. Policy sends HTTP request to an external service
3. Result used like any other policy evaluation result
4. Available for multiple features
HTTP Callout Deployment Scenarios
The examples in this section illustrate how to use HTTP callouts to perform various tasks. In all cases, the NetScaler performs a callout to an external server where a callout agent is configured to respond to the request from the NetScaler based on the data that is present on the external server.
This section describes how to configure HTTP callouts in the following scenarios:
1. Filter clients based on an IP blacklist.
2. Fetch and update content on the fly using Edge Side Includes (ESI) markup language.
3. Authenticate users and control access to resources.
4. Filter Outlook Web Access (OWA) spam.
Filtering clients based on an IP blacklist
HTTP callouts can be used to block requests from clients that are blacklisted by the administrator. This list of clients can either be a publicly known blacklist or one that is maintained specifically by the administrator or a combination of both.
The source IP address of the incoming client request is checked against the external pre-configured blacklist and based on whether the IP address has been blacklisted or not, the transaction is either blocked by the NetScaler or the NetScaler continues to process the transaction normally.
The HTTP callout feature facilitates this by allowing the NetScaler to communicate with the external server that maintains a database of such blacklisted IP addresses.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
ESI support for fetching and updating content dynamically
Edge Side Includes (ESI) is a markup language for edge-level dynamic Web content assembly. It helps in accelerating dynamic Web-based applications by defining a simple markup language to describe cacheable and non-cacheable Web page components that can be aggregated, assembled, and delivered at the network edge.
Using HTTP callouts on the NetScaler, you can read through the ESI constructs and aggregate or assemble content dynamically.
The following outlines the requirements to implement this configuration:
1. Enable Rewrite on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Rewrite action to replace the ESI content with the callout response body.
4. Bind the Rewrite action to a Rewrite policy.
5. Bind the Rewrite policy globally on the NetScaler.
Access Control and Authentication
In high security environments, it may be mandatory to externally authenticate a user before a resource is accessed by clients. On the NetScaler, you can use HTTP callouts to externally authenticate a user based on supplied credentials. There are different ways that authentication credentials might be supplied; the client could be sending the user name and password in HTTP headers in the request, or, the credentials could be fetched from the URL or the HTTP body.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
OWA-based spam filtering
Spam filtering is the ability to dynamically block emails that are not from a known or trusted source or has inappropriate content. Spam filtering requires business logic that indicates a particular kind of message is a spam.
Using HTTP callouts, you can take out any portion of the incoming message and check with the configured external callout server that has the rules to detect if the message is a legitimate email or spam. In case of a spam email, the sender will not be notified that the email is marked as spam because it will only alert spammers to modify their messages.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
Read about the Citrix Application Switch with Version 9.0 here.
Try the Citrix Application Switch with Version 9.0 here.
Tap into the power of AppExpert!
Recently I was asked about the performance and scalability of XenApp from our CSA. And I got the following reports or informaitons. It will be helpful to everyone to check these reports and informations at single site.
XenApp 5.0
XenApp 5 Scalability Analysis
http://support.citrix.com/article/CTX119108
Citrix Presentation Server 4.5
Scalability - Number of Users per Presentation Server
http://support.citrix.com/article/CTX114848
Effects of Varying the Number of CPUs of a Citrix Presentation Server
http://support.citrix.com/article/ctx114844
Citrix Presentation Server 4.0
Citrix Presentation Server for Windows Server 2003 x64 Editions - Performance and Scaling Capability
http://support.citrix.com/article/CTX107341
MetaFrame XP
How Hyper-Threading Affects User Capacity of Metaframe XP Servers
http://support.citrix.com/article/ctx101880
Advanced Concepts Guide for MetaFrame XP with Feature Release 3 - P79
Effects of Varying the Number of CPUs and Hyper-Threading on MetaFrame XP Servers
http://support.citrix.com/article/ctx102497
MetaFrame 1.8
Windows 2000 Terminal Service Capacity and Scaling
http://support.citrix.com/article/ctx9354
Other sources
http://h71019.www7.hp.com/ERC/downloads/4AA0-9214ENW.pdf
http://www.dell.com/downloads/global/power/ps1q07-20070244-Citrix.pdf
http://www.brianmadden.com/blogs/brianmadden/archive/2004/02/19/the-4gb-windows-memory-limit-what-does-it-really-mean.aspx
Test tools
Citrix Server Test Kit Users Guide 2.1
http://support.citrix.com/article/ctx101744
EdgeSight for Load Testing 3.0
http://support.citrix.com/product/es/ltv3.0