Session hold solution and NetScaler session retention overview

Why do I need a session to keep

If we divide the backend Web server into two groups, one set is a static content server, and the other is a dynamic content server, then when we reverse proxy, the reverse proxy server decides to dispatch it to the back-end set of services by judging the name of the resource file suffix. If our back-end servers have multiple static and dynamic content, then the reverse proxy server needs to load balance it and then think that the resource is dispatched to that server. So for static content servers, because static content does not process sessions, we do not have to consider their session hold when load balancing. The simplest and most direct polling is good, if the server performance is not the same, do a weighted polling. Of course, if the back-end static server resource size difference is also very large, then polling the way to load balanced way, the effect is not particularly obvious, it may be necessary to use the least number of connections load balancing method to handle such resource situation, the least connection is to consider the current connection of the server load situation, can guarantee the result is fair. This is for static content servers, so for dynamic content servers, because dynamic content involves processing sessions, we need to consider the server's session hold between load balancers. Session hold refers to a mechanism on a load balancer that, while being load balanced, ensures that access requests from the same user are assigned to the same server.

For example, the Web Banking Service Portal. Users log in to the application by entering a user name and password, and once the login is successful, the user can do many business operations. For example, checking account balances, online transfers, etc.

If the session is not configured to maintain, then the situation may occur: when the user logged in, the system chose Server1 for authentication, after authentication, the user next business operations (such as transfer), at this time the system chose Server2 or Server3 to the user Service, The problem arises because there is no information on the user's trading status on the Server2 or Server3, so Server2 or Server3 will think that the user has not passed the authentication, thereby rejecting the user's action request.

If session hold is configured, then all subsequent operations of the user's login will be sent directly to the service selected at the time of authentication.

Second, the method of session retention:

1, Session Binding: Session binding refers to the use of an algorithm or a persistent connection, the request from the same IP always directed to the back end of the same back-end server. This method is easy to use, but has the following problems:

When the backend server goes down, the session is lost;

Clients from the same IP are forwarded to the same back-end server, which can lead to load imbalance;

Does not apply to cases where there is an agent in the previous paragraph.

2, Session replication: Also known as the session cluster, through the backend server's own components to build a similar session of the high-availability cluster, dynamic servers within the cluster through multicast communication, in these clustered servers, each server will be created by the multicast of the session to the other servers of the cluster. So each server maintains all the sessions in the current cluster, so the user's request can be dispatched to any server. Because our sessions are synchronized between the cluster servers, their sessions are present regardless of the user's connection to that server. But the problem with such a workaround is:

The bandwidth between the back-end servers is heavily occupied because of the session replication between servers;

Each server maintains all the sessions in the cluster, consumes and consumes a lot of resources on the server itself, which makes the server itself have limited concurrent load capacity.

But the advantage is that our load Balancer schedule can be any, and no one server failure will cause our session to be lost.

3, Session server: Because of the shortcomings of the session replication, we can find a high-performance server, storage streaming data, such as memcached, which is famous for the session cache server, Memcache can combine the memory of the Web server to become a "memory pool", Regardless of which server generated the session can be put into this "memory pool", other servers can be used. There are Redis (KEY-VALUE,KV store), key-value servers, key-value stores, and for the kind of storage, they can help us save our conversations on the front end. But there are drawbacks to this approach:

The server may become a performance bottleneck;

They are one of the single points of failure, so we have to deploy this kind of server and have to do the scaling and redundancy.

4. Other session retention techniques

As for the other technologies that use the database for session keeping and the use of client-side cookies for session retention, there is no direct recommendation, why? The database is inherently a bottleneck and is used for session retention, isn't it a burden on the database?

Using the client's cookie for session retention requires the client to open the cookie, and if the cookie is banned, it will not play. And the use of the client's cookie, vulnerable to attack, after all, cookie security is too low, too easy to forge.

Third, the NetScaler of the session hold

NetScaler supports a variety of session-saving technology types. For optimal server, network and NetScaler operational efficiencies, it is important to choose the appropriate session-preserving type for different deployment scenarios (load balancing, firewall load balancing, and so on) and traffic types. Some session save types (for example, source IP) require NetScaler memory to store information about session retention, while others persist in type (for example, cookie,urlpassive and custom Server IDs) The NetScaler memory is not required, and all relevant persistent information is derived from the customer request.

The following table is a common type of session hold and the supported protocols

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M02/7D/56/wKiom1bmVbOBEp2dAADuWbuiz-E187.png "title=" 1.png " alt= "Wkiom1bmvbobep2daaduwbuiz-e187.png"/>

Below is a brief description of the session hold type:

• Source IP: In this method, the connection from the same source IP is saved to the same server.

• Cookie insert: In this method, each client is given a cookie that contains the port of the service for that IP address and client access. The client uses cookies to maintain persistent connections for the same service.

• SSL session: The use of this method in the client's SSL sessions identifies persistence.

• Rule: This method is based on a custom rule.

• URL Passive: This method is based on a passive persistent URL query.

• Custom Server ID: In this method, the server gives a custom server ID number that can be used in a URL query.

• Destination IP: In this approach, a network connected to the same destination is connected to the same server.

• Source and destination IP addresses: In this method, sessions that are connected from the same source IP to the same IP are persisted.

• RTSP Session ID: This method is based on a session hold for the RTSP session ID.

• SIP Call ID: In this method, the session is persisted based on the same SIP calling ID.

In the above table, the section labeled "Yes" is the recommended session-saving type for the protocol and the recommended type of use, allowing the NetScaler to get the best CPU and memory usage. For example, a cookie-type session remains well-suited for the HTTP&HTTPS protocol, because NetScaler does not waste the details of the memory area storage session retention. All session-preserving details are stored in a cookie after being NetScaler encoded. For example, IP/TCP/UDP transmission, Source IP session hold is the best choice, it uses a portion of NetScaler memory to store the information held by the session.

This article is from "I take fleeting chaos" blog, please be sure to keep this source http://tasnrh.blog.51cto.com/4141731/1750852

Session hold solution and NetScaler session retention overview