Set multiple instances of a Web site in Windows Azure Web site

Setting multiple instances of a site in a Windows http://www.aliyun.com/zixun/aggregation/13357.html >azure site is a great way to extend your site horizontally, Azure Maximize the use of application requests to route IIS expansion packs to assign users who are connected to your site between active instances. ARR by providing a special cookie to the connected user (that is, the associated cookie), you can subtly track the connected user by knowing which server instance they are communicating with when the user makes a subsequent request. This allows us to ensure that clients always communicate with the same server when the session is active when the client has a session with a specific server instance. This is particularly important for applications that use sessions, also known as stateless applications, because the session-specific data itself is not moved from one server to another. Applications can be designed to do this (typically by storing data in some shared storage, such as SQL), but most applications do not, so we usually have to connect each user to the specified server. If a user moves to another server, a new session is started, and the data is lost regardless of the session data the application uses (for example, shopping cart content). The following is a brief description of the process:

1. Client connects to Azure Web site

2. ARR runs and receives requests on the front-end Azure server

3. ARR determines which available instance should be sent to the request

4. ARR forwards the request to the selected server, creates the Arraffinity Cookie, and attaches it to the request

5. Responses containing arraffinity cookies are returned to the client

6. When the client receives a response, the cookie is stored for later use (the browser will do this for cookies received from the server)

7. This Cookie will be included when the client submits a subsequent request

8. When the ARR receives the request, it looks up the Cookie and decodes it

9. The decoded Cookie holds the instance name previously used so that ARR forwards the request to the same instance rather than selecting from the pool

10. The same steps are repeated for each subsequent request to the same site before the user closes the browser (that is, when the Cookie is purged) (step 7-9)

However, there is also a case where the association does not need to be retained. For example, some users do not close their browsers and remain connected for a long time. In this case, the associated Cookie will remain in the browser, keeping the user connected to the server, which can last for hours, days, or even longer (theoretically open-ended!). ）。 The computer is open and the browser is open, which is already commonplace, many people do (especially the computer in the workspace). In fact, this will result in a loss of balance for each instance's user allocation (this is the same as when some of the checkout counters in the supermarket are occupied by one user and the waiting time for other users becomes longer).

Depending on your application and its functionality, you can selectively focus on connecting users to a fixed server. If this is not important or completely unimportant, you can disable this association to choose better load balancing, and we have introduced this feature for you to control.

Associations are controlled by the associated Cookie, so you only need to make sure that Azure does not distribute cookies to disable the association. When disabled, subsequent requests from users will be treated as "new requests" and ARR will use normal load-balancing behavior to route requests to the best server instead of trying to route them to their own servers.

The associated Cookie looks like this:

You can disable associations in the following two ways:

1. In the application

2. In the Site configuration

To control this behavior in your application, you need to write code to emit a special HTTP header to instruct the application to request that the router delete the associated Cookie. This header is arr-disable-session-affinity, and if you set it to True,arr, the Cookie is eliminated. For example, you can add a row similar to this header to your application code:

Headers. ADD ("Arr-disable-session-affinity", "True");

* This example is for C #, but can be easily implemented with any other language or platform.

Setting this header in the application's code is ideal if you want to keep the association in most cases and only reset the association on a specific application page. However, if you want to disable the association completely, you can always make ARR delete cookies by inserting IIS itself directly into the header. This can be achieved through the Customheaders configuration section in Web.config. Simply add the following to the Web.config and upload the web.config to the root of the site:

However, keep in mind that the configuration in Web.config is very sensitive, and if the file is malformed, it may cause the site to not function correctly. If you have not used Web.config files before, read this Getting Started guide.

Troubleshooting

If you plan to implement this scenario, you may want to know how to verify its operation and troubleshoot it. ARR associated cookies are normally included in the 1th response of any Azure Web site, followed by any requests sent by the client and responses received from the server. To see if it is running, you can use either of several HTTP troubleshooting and diagnostics tools. Some of the more commonly used options are listed below:

1. Fiddler

2. HTTPWATC

3. Receptacle Monitor

4. WireShark

5. Firebug

This is where you can find information about other tools. The 1th tool listed above Fiddler is one of the most common tools, because it can interact with any browser and is provided free of charge. After you install Fiddler, it records any URLs you browse to, and then you can click the Inspector tab of the request or response to view the details. For example, you can view the HTTP Headers tab below to display the associated cookies that the server uses with Set-cookie hair:

If you add a arr-disable-session-affinity header to disable the association Cookie,arr The Cookie is not set, but it also deletes the arr-disable-session-affinity header itself, so if your process is working correctly , you will not see cookies and headers. If you see a Cookie and a header, it means that you set the header in a wrong way. The text that might be the header name or the header value is wrong. If you only see cookies and do not see headers, this may mean that your changes to Web.config are not valid, or that your header insertion code is not running, you can try to confirm by adding other moments. In general, using Web.config to set headers is easier than using code, so if you have questions, you should simplify the settings to narrow the scope of your investigation.

Finally, it should be noted that disabling associations should not be taken lightly. Static content is rarely problematic, but if you are running applications that are not specifically designed to handle users jumping from one server to another, the program may fail. This new feature is no doubt a good news for the situation where correlation leads to imbalances.