1 / 39

Health Checks for Citrix Services Using Advanced Monitors

faris
Download Presentation

Health Checks for Citrix Services Using Advanced Monitors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Health Checks for Citrix Services Using Advanced Monitors Improving Fault Tolerance for a Citrix Presentation Server Farm using Citrix NetScaler Application Switch

    2. Application Enumeration with Web Interface 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server. 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server.

    3. Application Enumeration with Web Interface 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server. 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server.

    4. Application Enumeration with WI 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server. 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server.

    5. Load Balancing the XML Services with the NetScaler Application Switch

    6. Using a NetScaler Application Switch to Monitor and Load Balance Citrix Servers 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server. 1 Client initiates request for application through WI VIP on NetScaler Application Switch. 2 WI Server selected by NetScaler Application Switch and HTTP request sent to WI Server 3 WI Server receives request and sends XML request to XML VIP on NetScaler Application Switch 4 NetScaler Application Switch selects XML Broker and XML request sent to XML Service 5 XML Service receives request and forwards it to its own (local) IMA Service 6 Local IMA Service contacts IMA Service on Zone Data Collector. 7 Zone Data Collector checks Dynamic Store, for the Least Loaded Server with the requested application in the Presentation Farm, sends IMA ping to the LLS target, and returns the HostID of that server. 8 HostID of Least Loaded Server is received by the XML Service. 9 XML Service looks up the HostID in its Local Host Cache, contacts the STA for a session ticket, and sends XML response back to the NetScaler Application Switch. 10 Netscaler Application Switch passes XML response back to appropriate WI Server based on COOKIEINSERT persistencetype 11 WI Server receives XML response and packages ICA file with template and send ICA file back to the NetScaler Application Switch 12 NetScaler Application Switch receives ICA file from WI Server and passes it back to the Client 13 Client receives ICA file from NetScaler Application Switch. 14 Client initiates ICA session directly to the Least Loaded MetaFrame Server.

    7. Agenda How to create Monitors, Services and LB VServers on a NetScaler Application Switch How to use the NetScaler Application Switch to load balance traffic across the XML Brokers and Web Interface servers How to use Monitors to perform health checks that control Service membership in Load Balancing VServers

    8. Basic Citrix NetScaler LB Concept Thanks Dave. Before we dive into how to perform health checks for citrix services, an overview of the terms used in this discussion and how to configure the netscaler application switch for load balancing is helpful. While some detail is provided in this presentation, it is not intended to be a comprehensive technical introduction. The Virtual Server is where client connections arrive, also termed the VServer. The Services are bound to the VServer and represent the services running on the servers on the back-end A Monitor is bound to each service to verify the health of the service running on the back-end server. The outcome of the health check determines whether the service stays in the load balanced rotation.Thanks Dave. Before we dive into how to perform health checks for citrix services, an overview of the terms used in this discussion and how to configure the netscaler application switch for load balancing is helpful. While some detail is provided in this presentation, it is not intended to be a comprehensive technical introduction. The Virtual Server is where client connections arrive, also termed the VServer. The Services are bound to the VServer and represent the services running on the servers on the back-end A Monitor is bound to each service to verify the health of the service running on the back-end server. The outcome of the health check determines whether the service stays in the load balanced rotation.

    9. What is a VServer? An IP that receives client connections / requests Distributes client requests among bound services Traditionally a public IP, but can also be private IP if a device upstream performs NAT Can be used internally to improve fault tolerance

    10. Creating a LB VServer

    11. What is a Service? Network endpoint Server IP Server Port Protocol Services are bound to a VServer In our examples a Service will represent: A server running Web Interface A server running as a dedicated XML Broker

    12. Creating a Service

    13. Monitors What is a Monitor? Periodic probe of a server or service What does it do? Checks the health of the service it’s bound to Provides feedback to NetScaler kernel Two Types: Kernel Monitor Advanced Monitor Also termed as: Scriptable monitor User Monitor Monitors are Bound to Services

    14. What is a Kernel Monitor? A basic high-performance probe originates from the kernel Several Types: Based on Protocol Example Types: TCP, UDP, ICMP, HTTP, HTTP-ECV ECV (Extended Content Verification) monitor is used for verifying content in HTTP, TCP, or UDP payload Limited by: One request/response 127 characters in probe request Only first 24K of probe response is parsed ping Response time is the time difference between the ICMP ECHO REQUEST and ICMP ECHO REPLY. tcp Response time is the time difference between SYN and SYN+ACK. http Response time is the time difference between http request (after tcp connection is established) and the http response. Here till we get the http response code. tcp-ecv Response time is the time difference between time data is sent (send string) and time you receive the data(recv string). For a tcp-ecv monitor without a send and a receive string would again be treated as a mis-configuration because we are trying to measure the time since the send string and the receive string, so both not been given is a mis-configuration where the response timeout ~0. http-ecv Response time is the time difference between time data is sent (HTTP request) and the time response data is received. udp-ecv monitor Response time is the time difference between time data is sent (send string) and the time data is received. Udp-ecv string with no receive is a mis-configuration. dns monitor Response time is the time difference between dns query and dns response. tcps Response time is the time difference between SYN and ssl handshake completion. ftp Response time is the time difference from the time the user name is sent and user authentication is completed. https This is the same as http monitor. https-ecv This is the same as http-ecv monitor. User Response time is the time difference between a HTTP POST request to the dispatcher and the corresponding HTTP response.ping Response time is the time difference between the ICMP ECHO REQUEST and ICMP ECHO REPLY. tcp Response time is the time difference between SYN and SYN+ACK. http Response time is the time difference between http request (after tcp connection is established) and the http response. Here till we get the http response code. tcp-ecv Response time is the time difference between time data is sent (send string) and time you receive the data(recv string). For a tcp-ecv monitor without a send and a receive string would again be treated as a mis-configuration because we are trying to measure the time since the send string and the receive string, so both not been given is a mis-configuration where the response timeout ~0. http-ecv Response time is the time difference between time data is sent (HTTP request) and the time response data is received. udp-ecv monitor Response time is the time difference between time data is sent (send string) and the time data is received. Udp-ecv string with no receive is a mis-configuration. dns monitor Response time is the time difference between dns query and dns response. tcps Response time is the time difference between SYN and ssl handshake completion. ftp Response time is the time difference from the time the user name is sent and user authentication is completed. https This is the same as http monitor. https-ecv This is the same as http-ecv monitor. User Response time is the time difference between a HTTP POST request to the dispatcher and the corresponding HTTP response.

    15. Health Checking the Web Interface Kernel Monitor Type: TCP-ECV -send “GET /Citrix/MetaFrame/auth/login.aspx\r\n\r\n” -recv “Set-Cookie” When a Service is created, default monitors are bound to it. The protocol determines what default monitor is bound. For instance, a Service of a protocol type TCP gets a TCP-Default monitor…This monitor merely verifies that the host is available on the network and that the port is reponding, but it doesn’t verify that the Service running on that port is responding properly to client requests. A Service of protocol type gets a HTTP-Default monitor which verifies that the response code from the web server is 200 OK. While this is an improvement, there are other response codes that are acceptable like 302 redirect, 100 Continue, and 206, etc. What we’re more interested in verifying is that the code behind the web application is functioning correctly, and one way to do this for Web Interface is to verify that the Set-Cookie header is being returned. This implies that the web server has correctly processed the request and has successfully initiated the web application code that prepares the Web Interface for a new user session. Here we have our send request, and the recv string is simply the string “Set-Cookie”.When a Service is created, default monitors are bound to it. The protocol determines what default monitor is bound. For instance, a Service of a protocol type TCP gets a TCP-Default monitor…This monitor merely verifies that the host is available on the network and that the port is reponding, but it doesn’t verify that the Service running on that port is responding properly to client requests. A Service of protocol type gets a HTTP-Default monitor which verifies that the response code from the web server is 200 OK. While this is an improvement, there are other response codes that are acceptable like 302 redirect, 100 Continue, and 206, etc. What we’re more interested in verifying is that the code behind the web application is functioning correctly, and one way to do this for Web Interface is to verify that the Set-Cookie header is being returned. This implies that the web server has correctly processed the request and has successfully initiated the web application code that prepares the Web Interface for a new user session. Here we have our send request, and the recv string is simply the string “Set-Cookie”.

    16. Creating a Web Interface Monitor For Web Interface 3.x > add monitor wi_4.2 tcp-ecv -send "GET /Citrix/MetaFrame/default/default.aspx\r\n\r\n" -recv "Set-Cookie“ For Web Interface 4.x > add monitor wi_4.2 tcp-ecv -send "GET /Citrix/MetaFrame/auth/login.aspx\r\n\r\n" -recv "Set-Cookie“ For Web Interface 3.x > add monitor wi_4.2 tcp-ecv -send "GET /Citrix/MetaFrame/default/default.aspx\r\n\r\n" -recv "Set-Cookie“ For Web Interface 4.x > add monitor wi_4.2 tcp-ecv -send "GET /Citrix/MetaFrame/auth/login.aspx\r\n\r\n" -recv "Set-Cookie“

    17. Advanced Monitors What is an Advanced Monitor? A script or executable that performs a health check from the NetScaler Application Switch Can be written in different scripting / programming languages Shell Perl Requirement: Returns 0 for success Example: Citrix XML Service

    18. Why do we need Advanced Monitors for XML Service? XML Request for Citrix XML Service is >127 Characters Provide visibility into the upper layers of OSI Stack Limited only by imagination More about Advanced Monitors

    19. NetScaler Advanced Monitor Process User-mode monitoring process nsumond Called “The Dispatcher” Invokes Advanced Monitors Communicates with Kernel over 127.0.0.1 Runs in 2 modes Regular: iterative script execution Keep Alive Scripting (KAS): script put to sleep

    20. How nsumond works Kernel sends HTTP request to nsumond on 127.0.0.1 Name of script to execute IP Port scriptArgs Nsumond invokes the Advanced Monitor Advanced Monitor executes and passes back exit code Nsumond sends back HTTP response to kernel Kernel makes decision based on exit code Repeat

    21. Advanced Monitor Execution Flow The Kernel is “The Decider”The Kernel is “The Decider”

    22. Example: XML Service Monitor Advanced Monitor Written in Perl Sends XML Request Healthy Response Contains: <TicketTag>, Host ID of LLS Implies Presentation Farm health because multiple actions must succeed to fulfill request The XML Service Monitor will be included in future releases of the NetScaler Application Switch

    24. XML Request <!DOCTYPE NFuseProtocol SYSTEM NFuse.dtd"> <NFuseProtocol version="4.1"> <RequestAddress> <Flags>no-load-bias</Flags> <Name> <AppName>notepad</AppName> </Name> </RequestAddress> </NFuseProtocol>

    25. XML Broker Script - Perl The Setup my $url = "http://" . . ":" . . "/scripts/wpnbr.dll"; my $xml_request = '<?xml version="1.0" encoding="UTF-8"?>' . '<!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd">' . '<NFuseProtocol version="4.1">' . '<RequestAddress>' . '<Flags>no-load-bias</Flags>' . '<Name>' . '<AppName>' . . '</AppName>' . '</Name></RequestAddress>' . '</NFuseProtocol>';

    26. XML Response <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"> <NFuseProtocol version="4.1"> <ResponseAddress> <ServerAddress addresstype="dot">5.214.10.14</ServerAddress> <ServerType>win32</ServerType> <ConnectionType>tcp</ConnectionType> <ClientType>ica30</ClientType> <FarmLoadHint>0</FarmLoadHint> </ResponseAddress> </NFuseProtocol>

    27. XML Broker Script - Perl Finding the string pattern if ($response->content =~ / /i) { return 0 } else { return 1; }

    28. Creating an Advanced Monitor

    29. Live Demo How to create a Monitor How to create Services and bind a Monitor to each How to create a VServer and bind Services to it Demonstrate the monitors in action

    30. How it all fits together Web Interface Sites are configured to point at XML VIP User requests are pointed at Web Interface VIP Monitors control Service membership in LB VServers

    31. Configuring Web Interface with XML VIP

    32. A Bigger Picture

    33. Other Advanced Monitors PNAgent Custom Monitor Test Application Enumeration AAC Custom Monitor Tests from AG POV AG HTTP-ECV HTTP Response String Validation

    34. In Review Introduced Monitors, Services and LB VServers and how to configure them on a NetScaler Application Switch Showed how to use Monitors to perform health checks Demonstrated how Monitors can control membership of services in load balancing rotation of a VServer. Increased fault tolerance of the Citrix Presentation Server Farm Improved end user experience

    35. More Information Whitepaper : Health Checking Citrix Services with Advanced Monitors from the NetScaler Application Switch (CTX111462) Bino Gopal & Brian Mirrotto’s iForum Session Session 213 Sunday 4:00-4:50pm, Southern Hemisphere Ballroom II Monday 2:30pm - 3:20pm , Southern Hemisphere Ballroom V

    36. CSEIT Survey Win an iPod! Here’s your chance to win an iPod! Please take the time to fill out the CSEIT survey which will be emailed to all attendees If you complete the survey, your name will be entered to win an Apple iPod The winner will be announced in November

    37. We want to thank… Mike Stringer Rene Alfonso Daniel Romano

    38. Questions ????

More Related