共用方式為

From app_offline.htm to Failover Farm. SharePoint High Availability Scenarios

  • 發行項

Hi again,

Last months this has been one of our main tracks we have been working on. As useful reading in order to get previous concepts, you may start reading the Plan for redundancy guide. Here you will get the idea that there are several roles that can be redundant, and others not; and traditional ways to set up server redundancy.

Here I will point out, that although it is said that Index rol is not redundant, you can achieve multiple index servers roles in different SSPs indexing the same content with a cost:

  • Double size for the same content (Property store - DB and index catalog - File)
  • Double size in your Query Servers (Both copies of the indexes)
  • Additional capacity in your backup, IIS logs and network planning

(some details in the next guide [Single farm with two SSPs  section] and more complex scenarios)

In this scenario you could move manually your Web Applications from one SSP to another, in order to get updates from that index server (remember that you really get results from your queries servers); under a power outage, server crash or index corrupt.

How can you meet a specific level of availability?

We do have a guide on this (complemented with the whitepaper about mirroring), quite complete so I would not comment much on it. Just that content updates may be evil. In our scenario content was queued in order to update the main farm after failover.

I would take the summary as my own:

"Carefully review your availability requirements. The higher the level of availability and the more systems you protect, the more complex and costly an availability solution is likely to be.

The costs of attaining availability should be evaluated based on business needs. Not all solutions within an organization are likely to require the same level of availability. You can offer different levels of availability for different sites, different services (for example, search and business intelligence), or different farms."

Yes, but I would like something easier, is it possible?

One of the many good things of our platform, is that we boost an ecosystem of partners so you will find a lot of scenarios extended. I have not deployed myself these solutions (I did more on the backup scenario), but you may contact each of them and find the best for your needs:

and always a good reference, the old Joel blog

Ok, but I would like something really easy...

Well :) (not really HA), SharePoint is a ASP.NET application at the end (yes SharePoint IS a platform, so if you are using it from within other technology this will not work for you), so you may follow ASP.NET steps to tell your users in a friendly way that you are updating or changing the platform.

It is true that from the guides available, they indicate to stop the World Wide Web Publishing Service (W3SVC) on all Web servers; but as long as you achieve the objective (Disconnect users from the server farm) with other options, why not using the app_offline.htm?

What is the app_offline.htm option? it is a new feature included in ASP.NET 2.0 (time ago :)). This basically will let ASP.NET 2.0 to shut-down the application, unload the application domain from the server, and stop processing any new incoming requests for that application, sending back all requests for dynamic pages in the application to the app_offline.htm page.

Some reading I would recommend:

  1. Walkthrough: Deploying an ASP.NET Web Application Using XCOPY
  2. App_Offline.htm and working around the "IE Friendly Errors" feature

Finally, it would be great to have a solution to be deployed in order to be able to activate a feature in your sharepoint farm and copy that file in your web applications. isn't it?

Bye!