Create service profiles

A service profile is a predefined set of the service-related configuration that includes load balancing, back-end SSL, and health check settings. Every service must have a service profile associated with it.

The NetScaler App Delivery and Security service provides you two default service profiles, Default HTTP Profile and Default HTTPS Profile. While creating a service, you can associate one of these default profiles or create a profile according to your preference. If you select one of these default profiles then creating a service profile is not mandatory. If you create a service profile, you must create a load balancer. You can define other service-related settings as per your preference.

Configure load balancing

In a real-world scenario with a limited number of servers providing service to many clients, a server can become overloaded and degrade the performance of the server farm. Using load balancing algorithms, you can evenly distribute network traffic to avoid overloading any resource. The result is a better experience for end users in terms of improved performance and availability of your apps.

The load balancing module of the NetScaler App Delivery and Security distributes client requests across multiple app servers. For example, in an AWS environment, the client requests are distributed across EC2 instances, FQDN/IP address-based servers, and Autoscale groups. In an Azure environment, client requests are distributed across Virtual Machines, FQDN/IP address-based servers, and Virtual Machine Scale Sets.

When the NetScaler App Delivery and Security receives a client request, it selects a target server based on the specified rules or routes all traffic to the default server. It uses load balancing criteria to prevent bottlenecks by forwarding each client request to the server best suited to handle the request when it arrives.

Specifying the maximum number of requests per server ensures that a server is not overloaded. You can also specify a URL to redirect traffic, to avoid dropping requests if a server is not reachable.

Prerequisites

1. You have created an environment and a cloud access profile.
2. You have specified the basic details, such as the name of the application and environment by navigating to Applications > New Application. For more information, see Deliver an application.

Before you begin

Decide which algorithm and stickiness you plan to use for your load balancer. The following algorithms and stickiness are supported.

Algorithm

Algorithm is the method used to direct the client request to the server. In the HASH methods, the NetScaler App Delivery and Security extracts a predetermined portion of the request, creates a hash of the portion, and uses that value to select the server. The following methods are supported:

• Round Robin: Requests are distributed across the servers sequentially regardless of the load.
• Least Connection: Request is assigned to the server with the least number of active connections depending on the relative compute capacity of the server. This method is the most used method and is also the default method.
• Least Response Time: Request is assigned to the server with the lowest average response time.
• SOURCEIPHASH - Create a hash of the source IP address.
• DOMAINHASH - Create a hash of the domain name, or part of the domain name if it exceeds 80 characters, in the request. The domain name is taken from either the URL or the host header. If the domain name appears in both, the URL is preferred. If the request does not contain a domain name, the algorithm defaults to LEASTCONNECTION.
• URLHASH: Create a hash of the request URL, or part of the URL if it exceeds 80 characters.

Stickiness

The NetScaler App Delivery and Security uses the configured load balancing method for the initial selection of a server. It forwards all subsequent requests from the same client to that same server during a session. This setting is especially helpful in shopping cart and banking transactions. However, a server can become overloaded if it has too many open sessions or a specific session requires more resources.

The following stickiness types are supported:

• NONE - No stickiness is configured. Successive requests from the same client are directed to any server. This option is the preferred one for stateless applications. This value is the default value.
• SESSION COOKIE - The NetScaler App Delivery and Security inserts an HTTP cookie that is used to direct all requests to the same server during a session. This cookie uniquely identifies the session when a client accesses the application for the first time. It then refers to the cookie for subsequent requests from the same client. The HTTP cookie inserted by the service is a temporary cookie and is erased when the browser is closed. This type of stickiness is typically selected when the stickiness must be valid only until the browser is open.
• STICKY COOKIE - The NetScaler App Delivery and Security inserts an HTTP cookie that is valid for the configured duration. Default duration = 2 mins.
• SOURCEIP - Connections from the same IP address belong to the same stickiness session. That is, all requests from the same source IP address are forwarded to the same server for the configured duration. Default duration = 2 mins.
• SSLSESSION - Connections with the same SSL session ID belong to the same stickiness session. The back-end app server assigns an SSL session ID to each session. All requests with the same SSL session ID are forwarded to the same server for the duration configured. For example, use SSL session ID if you cannot use source IP stickiness because the device is behind a NAT gateway. As a result, the requests might not have the same source IP address. Default timeout= 2 mins.

Create a load balancer

A default load balancer is bound to all services through the service profile. If you create a service profile, you must create a load balancer.

1. Navigate to Applications > New Application.
2. Type a name for the application, and select an environment.
3. Click Next.
4. Click the Service Profiles tab.
5. Click Create.
6. In the Create Service Profile page, type a name for the profile and click Create.
7. In the Create Load Balancer page, specify values for the following parameters.
   • Name* - Name for the load balancer.
   • Algorithm*
   • Stickiness*
   • Stickiness Timeout - Time period, in minutes, for which stickiness is in effect. After the timeout expires, the request is treated as a new request and can be directed to any server depending on the configured load balancing algorithm.
   • Max Connections to Server - Maximum number of permissible simultaneous open connections per server. This number ensures that the server is not overloaded.

   • Redirect URL - If the server is DOWN or not reachable due to any reason, the requests are dropped. To avoid such a situation, you can specify a URL to redirect traffic to, if none of the servers are reachable. For example, the redirect might be to a page that simply states that “The servers are not reachable. Try after some time.” * Indicates a required parameter

     

8. Click Create.
9. Click Create.
10. Click Next.

Configure back-end SSL settings

SSL settings on the NetScaler App Delivery and Security service contain settings related to SNI, server authentication, cipher suites, and protocol versions configured on a back-end SSL application server.

Support for SNI on the back-end application servers

The NetScaler App Delivery and Security service supports dynamic SNI on the back-end TLS connections. SNI helps to enable SSL encryption on multiple domains if the domains are controlled by the same organization and share the same second-level domain name. For example, *.sports.net can be used to secure domains such as login.sports.net and help.sports.net.

If the back-end server is configured for multiple domains, the server can respond with the correct certificate based on the SNI received in the Client Hello message. The service learns the SNI in the client connection and uses it in the server-side connection. In other words, the common name received in the SNI extension of the Client Hello message is forwarded to the back-end SSL connection.

When server authentication is enabled, the server certificate is verified by the CA certificate and the common name/SAN entries in the server certificate are matched with the SNI. Therefore, the CA certificate must be bound to the service.

1. Navigate to Applications > New Application.
2. Type a name for the application, and select an environment.
3. Click Next.
4. Click the Service Profiles tab.
5. Click Create.
6. In the Create Service Profile page, type a name for the profile and click Backend SSL.
7. Click Configure SSL Settings.

8. In the Create SSL Policy page, type a name for the policy, select SNI, and click Create.

   

   The policy is listed on the Backend SSL tab in the Create Service Profile page.

9. Click Create.
10. Click Next.

Configure server authentication

Since the NetScaler App Delivery and Security service performs SSL offload and acceleration on behalf of an application server, the service does not usually authenticate the origin application server’s certificate. However, you can authenticate the server in deployments that require end-to-end SSL authentication.

In such a situation, the service becomes the SSL client and carries out a secure transaction with the back-end application server. It verifies that a CA whose certificate is bound to the service has signed the server certificate, and checks the validity of the server certificate.

To authenticate the server, enable server authentication and select the certificate of the CA that signed the server’s certificate to the SSL service.

1. Navigate to Applications > New Application.
2. Type a name for the application, and select an environment.
3. Click Next.
4. Click the Service Profiles tab.
5. Click Create.
6. In the Create Service Profile page, type a name for the profile and click Backend SSL.
7. Click Configure SSL Settings.

8. In the Create SSL Policy page, type a name for the policy, select Server Authentication, and click Create.

   

   The policy is listed on the Backend SSL tab in the Create Service Profile page.

9. Click Bind CA Certificates.

10. Click Create SSL Certificate.

11. Specify a name for the certificate and choose a certificate file. CA certificates don’t need a key.

    

12. Click Create. The certificate is listed on the SSL certificates page.

    

13. Click Create.
14. Click Next.

Configure SSL cipher suites and protocol

SSL cipher suites help to establish a secure connection between your app servers and the client. Select the cipher suites to use in your setup.

Protocol version is used during an SSL handshake. Select one or more protocol versions that your app servers support. By default, the highest protocol version that both peers support is selected.

1. Navigate to Applications > New Application.
2. Type a name for the application, and select an environment.
3. Click Next.
4. Click the Service Profiles tab.
5. Click Create.
6. In the Create Service Profile page, type a name for the profile and click Backend SSL.
7. Click Configure SSL Settings.
8. In the Create SSL Policy page, type a name for the policy.
9. Click Select All Cipher or select individual cipher suites from the list. You can expand each group to view the ciphers that are part of the group and, select or unselect individual ciphers.
10. Select the Protocol Version.

11. Click Create.

    

    The policy is listed in the Backend SSL tab on the Create Service Profile page.

12. Click Create.
13. Click Next.

Configure health checks

Health checks monitor the health of servers by sending probes to the back-end app servers. If the server responds within the specified time interval, the state of the server is set to UP. That is, the server can accept traffic. If the server does not respond to the designated number of probes within the specified time period, the server is set to DOWN. No requests are forwarded to this server until its state changes to UP. Traffic is distributed only among healthy servers.

1. In the Create Service Profile page, click Health Checks.
2. Click Add Health Check.
3. Specify values for the following parameters:
   • Name* - Name for the health check.
   • Protocol - Protocol of the health check and port number used by the server in your EC2 instance or Virtual Machine.
   • Port - Destination port where the health checks are sent. If this parameter is not configured, the health checks are sent to the same port as regular traffic.
   • Interval - Time interval, in seconds, between two successive health checks to the server. Must be greater than the “Response Timeout” value.
   • Response Timeout - The time, in seconds, within which a response must be received from the server. Must be less than the “Interval” value.
   • Unhealthy Time Interval - Time interval, in seconds, between two successive health checks to an unhealthy server.
   • Failed Check Count- Number of failed health checks after which a server is marked unhealthy.
   • Request URL Path* - HTTP request URL path to which health checks are sent. Applicable only to HTTP/HTTPS health checks. A “/” specifies that the monitor checks the server. To check a specific endpoint, specify the URL for the endpoint. For example, if the server is “example.com” then a specific endpoint might be “/example.com/comments.html”.
   • Request Header - HTTP header to be sent in the health checks. Applicable only to HTTP/HTTPS health checks.
   • Response Type* - Expected HTTP response code or text to be present in the HTTP response body to mark the server as healthy. Applicable only to HTTP/HTTPS health checks. * Indicates a required parameter

   

4. Click Add. The configured health checks are displayed in a tabular format.
5. Click Create.
6. Click Next.