I've done some research though this site and can't seem to come up with a conclusive answer. So I thought I'd ask the question and see what others are doing.
Based on the install docs, it sounds like to have multiple front-end servers, you rely on a single SQL server and "shared folder" for the data and you point each IIS "site" to this shared folder and SQL server. To me, that screams that your SQL server (which could also house the file share) becomes a single point of failure.
Discussing the file share and SQL server seperately:
A) can you install Sitefinity files on each front-end IIS server and use file replication to keep the front-end server directories in sync? If Sitefinity is configured for storing everything in the database, does the file system have to be in a shared folder (or replicated)?
B) For SQL replication does Sitefinity support SQL Mirroring?
If you have built a highly available web farm, what are you using? I'd like to rely on NLB (I've had no problem with it for Exchange and other services) and may or may not use multiple SQL boxes.
1. Yes, you can have Sitefinity installed on several different (physical) servers that will be load balanced and all of them can point to the same database for retrieving the data. Please note that besides the Network Load Balancing Sitefintiy will support any load balancing configuration, where the nodes can message each other, which is a requirement so content changes can be properly reflected on all nodes. The only thing you'll need to take care of is keeping the files in sync (e.g. Configuration folder, Search index folder, and Sitefinity license)
2. Yes, Sitefinity has a full support for working with mirrored SQL servers in a cluster environment. The database layer Open Access ORM supports failover connection string that will redirect all SQL CRUD tasks to the back-up server in the cases when the main server fails to respond. Sitefinity comes with options for Load balancing or running on SQL Azure. Both methods provide you with geographical failover protection. With the Load Balanced environment employed, if one server fails, other servers take over the load and your users never experience any problems. This can also be accomplished for the Sitefinity’s SQL database.
the Telerik team
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking
system and vote to affect the priority of the items
I have an identical copy of the files on two WebServers. I have set the MachineKey and the WebServerUrls for both webservers. I have pinged each server from the other and pings are successful. The changes that I make on one side does not get picked up on the other side though. What am I missing? How do I troubleshoot it? I have read the documentation.
Just to say that the problem was the Authentication Mode. It seems that the default has changed from Forms-Based to Claims-Based. That threw me off, and I was unable to figure it out. Its funny when the defaults change and all of a sudden, what used to work does not work any longer.
Does Sitefinity 4 require the NLB licence for SQL mirroring support?
We are thinking of setting up mirroring without NLB, because we have mirroring licences but not Sitefinity NLB licence. I appreciate this is not an ideal solution since our web server becomes a single point of failure requiring manual intervention to failover, but the site is not a core service of our business, just a shop window and so does not justify the cost of Sitefinity NLB licence. I am investigating whether we can manually fail over our site to a DR environment where we have a stopped (in IIS) website and a mirrored SQL instance.
In the event we lose our whole live site, we would failover the web server manually, start the website, and have it pointing at the mirrored SQL instance.
In the event we just lose our SQL server the live webserver would automatically failover to the mirror.In the event we just lose our web server we would fail over manually and point it to the live SQL instance.
I would like to know if this will be possible without a Sitefinity NLB licence.
I think NLB is only to do with the WebServer not the SQL Serever, so yes you should be fine defining a Failover Partner in your Connection String. Telerik will no doubt correct me. If I were you, I would give it a quick test. Should not take too long.
How and where to define the fail-over connection string? Does it needs to go in data.config? what is the syntax?
We do not want to use NLB but a mirrored database has to be configured and used in failure scenarios.
Yes go to the DataConfig.config file and in there you should already have a connection string. The correct syntax is this:
Hope this helps,
"data source=SQL-SERVER-A;Failover Partner=SQL-SERVER-B;Integrated Security=SSPI;initial catalog=DatabaseName"
Thanks for the advice, we have set up SQL mirroring and it seems to work fine without the NLB licence. As for the web server though, does anyone know if we can have a manual web server failover set up like this:
1. No NLB licence as our site does not warrant the cost.
2. Copy web server to DR site.
3. Sync folder structures between live server and DR server using a third party tool.
4. Set up website under IIS on DR server.
5. In the event of losing principal server, manually re-ip the DR server to have the same ip as the failed principal.
I realise this is less ideal than having NLB as we will inevitably incur a downtime while we manually reconfigure the failover site, however I want to know if it's possible to do it this way. So far we have tried steps 1 through 4 and we get a 503 error when we try to start the site on the failover because sitefinity (or is it some other problem? ) seems to have force-stopped the application pool for the site on the failover. Admittedly this was tested while the principal server was still live, we have yet to do a true test where we actually bring the live server down and try to bring up the failover web server.
Our environment doesn't use the load balancing license from Telerik either. We use the Windows built in load balancing NLB to keep both servers live (ie; not having to move an IP from one server to the other) and Windows folder replication to keep the inetpub folders in sync. We don't replicate the IIS configs (as that changes rarely) so the "site" has to be manually created on the other servers. We point to a single remote database as we are only running SQL Express but will look at doing database mirroring in the future.