Umbraco 7 in Server 2008 R2 NLB with IIS shared configuration
I've searched the forums and while I've seen at least one post similar to this, I haven't seen our particular questions addresses elsewhere.
We are in the process of setting up Umbraco 7 in the following environment:
Two Windows Server 2008 R2 Web Server edition systems in a Windows Network Load Balanced (NLB) cluster (two NICs each with unique private management IP addresses)
Nodes use an IIS 7.5 shared configuration
Content is maintained on a clustered Windows file server and accesed by the web servers via a UNC share
We are planning on hosting the Umbraco files/content on the network share (as opposed to the extra overhead of setting up a file replication system).
1) Since there’s no mention in the documentation of operating in an IIS shared configuration, I see some potential problems, especially regarding the section that talks about assigning unique host headers to each server in the cluster:
With an IIS shared configuration host headers are shared among the participating hosts
Host headers don’t really mean anything in an HTTPS environment anyway (we are planning to operate the site as 100% HTTPS)
It’s not clear how much this matters because each cluster node *does* have a unique backend IP address which, as far as I can tell, is the important part.
2) The documentation stresses designating a single server as the “back office server” for administration of content and states that this is even more important when using a shared content arrangement like we are planning to do. The issue seems to be with preventing file locks from interfering with each other.
Could this be handled in the NLB configuration by making sure the admin traffic site is only ever handled by a single host at any given time? (This would be similar to how we manage SMTP traffic in the cluster – when the first node is up it always handles SMTP traffic. If that node is down at any point, the second node handles SMTP traffic until the first node rejoins the cluster.)
Or is it crucial that one node *always* handles admin/content update traffic and content updating will simply not be available if that node is down at any given time?
How is the admin server identified? What prevents a secondary server from providing access to the administration pages?
It states that you have 2 options: File replication or a shared centralized storage
As the docs mention file replication is the recommended setup and from a lot of experience with setting these things up, IMO replicated environments are far easier to setup and manage.
It is absolutely required that one and only one server is used for back office administration, regardless of what setup you go with. The easiest way to do this is just create another DNS entry for administrators and point that to the single server you wish to use as a the back office server. Many admins will actually dedicate one server for admin and not use it as part of the NLB cluster.
It's the requirement that only one server be used for back office administration that I've been having trouble reconciling with the option of using shared centralized stoarge. Even if admin traffic is consistently directed to a single server, if the Umbraco files (including the /umbraco subfolder) are on shared storage then all the servers accessing that shared storage would be able to serve the admin folder and bad things (like file locks) ensue. Sure it's an option to have a standalone server act as the back end, but that somewhat defeats the purpose of using the simpler shared storage setup.
At the moment I'm looking into using IIS' URLRewrite module to make sure that all access to the /umbraco folder (except for /umbraco/masterpages and /umbraco/webservices) gets redirected to the node that we've designated as the back office server.
The point of a single server for admin is that there is only one server writing to files. If only one server is writing to the files, you will not get file locks. This flag in the config is important too:
which ensures that the umbraco xml cache file is actually stored on the individual server's temp files on it's local hard disk.
It's worth noting that nothing in the /umbraco folder is written to , except for some package installs. The folder you need to be concerned about is /App_Data/TEMP and /media
If you have one admin server (one server that does all the file writing) you are safe. Lucene is the biggest issue with shared storage environments, if you have more than one server writing indexes you will absolutely have problems.
Normally people will just create a DNS entry like:
admin.yoursite.com
which points specifically to your single server. You don't have to worry about url rewrite rules or anything like that. You can also have this server accept from end requests on your normal dns entry.
First, we are trying to avoid setting up an additional server whose only purpose would be to fill the Umbraco admin role. We will be able to restrict access to the admin interface through other methods, so the need to have an additional server behind our firewall is not necessary.
Second, even if we set up an admin-only server, it would still be accessing the same Umbraco files via shared storage. (If it wasn't, wouldn't we need to set up file replication anyway, which the documentation indicates isn't required?) For the admin server to function properly, the shared storage would need to have the UI files present in the /umbraco and /umbraco_client - what's then to prevent the NLB nodes from inappropriately accessing the UI? In this situation, rewrite rules (or some other method) seem needed to prevent such an occurrence.
BTW - we have a DNS entry set up to make sure all admin traffic goes to the back office server - it's currently an alias that points to the NLB node we have designated to fill this role. However, while we can tell people that they should use https://admin.yoursite.com/umbraco/ to update content, as described in my second point above, we still need to prevent (intentional or accidental) access via https://www.yoursite.com/umbraco/. ; Preventing this access is what I'm using the rewrite rules for (with exceptions for the masterpages and websevices subfolders so as not to interfere with cache sync'ing between the nodes.)
I didn't say you required an admin-only server, I just mentioned that is what many people do.
There's quite a few different ways to try to do what you want. A custom DNS entry to point to a single server in your LB environment is generally what is done.
If you want to ensure admins to access www.yoursite.com/umbraco, then yes you could use rewrite rules and ensure you just redirect any access to www.yoursite.com/umbraco to admin.yoursite.com/umbraco. As you mentioned you need to be careful about what you redirect, all surface controllers for the front-end are routed to the /umbraco/surface path as well. Since you really just care about the login screen, you might as well just redirect specifically these:
and nothing else, or if you are concerned about other specific paths you could redirect those too.
Some people use ARR for this type of thing as well or as part of rules on their load balancers. Really depends on your setup but sounds like you've got it covered.
Sorry, I realize that my "first ..., second ..." wording probably came across as sounding rather annoyed which was not my intent,
I'm still concerned that I'm redirecting too much by doing everything in the /umbraco folder except the two subfolders that I mentioned. (Clearly I should be as I missed the /umbraco/surface subfolder, although I don't currently see such a folder in our installation.) It's a good tip to focus on redirecting only access to the /umbraco folder itself and not its subfolders - I'll play around with the rewrite rules to achieve that.
Surface controllers and all mvc controllers are based on routes, not based on physical files, so /umbraco/surface/* is a route, there are no files there.
I'd recommend simply redirecting the 2 mentioned above:
Unfortunately, although I have a similar setup to Thayer, this thread is going off on a different tangent to the issue I am having so as not to hijack this thead I have created my own. Would you mind taking a look please?
I believe I've gotten my URLRewrite module rules tightened up to only get the paths you mention. My (hopefully) final question has to do with the individual files in the root of the /umbraco folder. At the moment I have access to those files getting redirected to the back office server, and while this seems appropriate for some of them (for example /umbraco/umbraco.aspx) it might be undesirable for others (for example /umbraco/ping.aspx). Do I need to be more careful on how I'm handling redirects for those individual files?
Yes you do, things like /umbraco/ping.aspx and other web services need to be able to be contactable by it's own server. The ping.aspx is for keep alive, so a server pings itself. Then there's things like scheduled tasks which a server needs to be able to ping itself - but for LB that is taken care of with the new config settings: http://our.umbraco.org/documentation/Installation/load-balancing#Correctconfigforscheduledpublishing&tasks
I'd suggest that you should really just keep it as simple as:
I'm currently struggling with my NLB setup and also found the documentation confusing when it came to restricting backoffice access to a single server. It seems to me that since our nodes are already named, then we don't need to create a new DNS entry for the admin section. We could instead redirect backoffice users from server2/umbraco to server1/umbraco. Is this the case?
If so, how is this for a server redirect pattern:
^/umbraco(.?)(default(.?))?$
It seems to catch only the routes directing to /umbraco(/) and /umbraco/default(/). Leaving the nodes the ability to ping themselves.
It's up to you how you want to direct your admins to your servers, creating a sub domain is generally an easy and fail safe way for most admins to do it, doesn't require URL rewriting and guarantees all admin requests go to the correct server. (i.e. admin.mysite.com would point to your single server)
If you don't want to do that, then sure you can go down the URL rewriting route and so long as your server 'names' like server1/umbraco are accessible for you admins then that should be fine, but you should really test to make sure when you are using the back office that all requests are going to that same server (you could verify with fiddler or something).
Umbraco 7 in Server 2008 R2 NLB with IIS shared configuration
I've searched the forums and while I've seen at least one post similar to this, I haven't seen our particular questions addresses elsewhere.
We are in the process of setting up Umbraco 7 in the following environment:
We are planning on hosting the Umbraco files/content on the network share (as opposed to the extra overhead of setting up a file replication system).
I have followed this document - http://our.umbraco.org/documentation/installation/load-balancing - as best I could, but it doesn't directly address the issue of using an IIS shared configuration. Given that, can anyone help with the following questions?
1) Since there’s no mention in the documentation of operating in an IIS shared configuration, I see some potential problems, especially regarding the section that talks about assigning unique host headers to each server in the cluster:
2) The documentation stresses designating a single server as the “back office server” for administration of content and states that this is even more important when using a shared content arrangement like we are planning to do. The issue seems to be with preventing file locks from interfering with each other.
Thanks for any and all feedback!
-> Thayer
I am having the same issues with pretty much the same setup so would be interested to see if anyone can help with this!? I'm using umbraco 7.1.6
There is mention of this setup in the docs:
http://our.umbraco.org/documentation/installation/load-balancing#FileStorageonSANNASClusteredFileServerNetworkShare
It states that you have 2 options: File replication or a shared centralized storage
As the docs mention file replication is the recommended setup and from a lot of experience with setting these things up, IMO replicated environments are far easier to setup and manage.
It is absolutely required that one and only one server is used for back office administration, regardless of what setup you go with. The easiest way to do this is just create another DNS entry for administrators and point that to the single server you wish to use as a the back office server. Many admins will actually dedicate one server for admin and not use it as part of the NLB cluster.
It's the requirement that only one server be used for back office administration that I've been having trouble reconciling with the option of using shared centralized stoarge. Even if admin traffic is consistently directed to a single server, if the Umbraco files (including the /umbraco subfolder) are on shared storage then all the servers accessing that shared storage would be able to serve the admin folder and bad things (like file locks) ensue. Sure it's an option to have a standalone server act as the back end, but that somewhat defeats the purpose of using the simpler shared storage setup.
At the moment I'm looking into using IIS' URLRewrite module to make sure that all access to the /umbraco folder (except for /umbraco/masterpages and /umbraco/webservices) gets redirected to the node that we've designated as the back office server.
The point of a single server for admin is that there is only one server writing to files. If only one server is writing to the files, you will not get file locks. This flag in the config is important too:
which ensures that the umbraco xml cache file is actually stored on the individual server's temp files on it's local hard disk.
It's worth noting that nothing in the /umbraco folder is written to , except for some package installs. The folder you need to be concerned about is /App_Data/TEMP and /media
If you have one admin server (one server that does all the file writing) you are safe. Lucene is the biggest issue with shared storage environments, if you have more than one server writing indexes you will absolutely have problems.
Normally people will just create a DNS entry like:
admin.yoursite.com
which points specifically to your single server. You don't have to worry about url rewrite rules or anything like that. You can also have this server accept from end requests on your normal dns entry.
First, we are trying to avoid setting up an additional server whose only purpose would be to fill the Umbraco admin role. We will be able to restrict access to the admin interface through other methods, so the need to have an additional server behind our firewall is not necessary.
Second, even if we set up an admin-only server, it would still be accessing the same Umbraco files via shared storage. (If it wasn't, wouldn't we need to set up file replication anyway, which the documentation indicates isn't required?) For the admin server to function properly, the shared storage would need to have the UI files present in the /umbraco and /umbraco_client - what's then to prevent the NLB nodes from inappropriately accessing the UI? In this situation, rewrite rules (or some other method) seem needed to prevent such an occurrence.
BTW - we have a DNS entry set up to make sure all admin traffic goes to the back office server - it's currently an alias that points to the NLB node we have designated to fill this role. However, while we can tell people that they should use https://admin.yoursite.com/umbraco/ to update content, as described in my second point above, we still need to prevent (intentional or accidental) access via https://www.yoursite.com/umbraco/. ; Preventing this access is what I'm using the rewrite rules for (with exceptions for the masterpages and websevices subfolders so as not to interfere with cache sync'ing between the nodes.)
Hi,
I didn't say you required an admin-only server, I just mentioned that is what many people do.
There's quite a few different ways to try to do what you want. A custom DNS entry to point to a single server in your LB environment is generally what is done.
If you want to ensure admins to access www.yoursite.com/umbraco, then yes you could use rewrite rules and ensure you just redirect any access to www.yoursite.com/umbraco to admin.yoursite.com/umbraco. As you mentioned you need to be careful about what you redirect, all surface controllers for the front-end are routed to the /umbraco/surface path as well. Since you really just care about the login screen, you might as well just redirect specifically these:
www.yoursite.com/umbraco www.yoursite.com/umbraco/
and nothing else, or if you are concerned about other specific paths you could redirect those too.
Some people use ARR for this type of thing as well or as part of rules on their load balancers. Really depends on your setup but sounds like you've got it covered.
Sorry, I realize that my "first ..., second ..." wording probably came across as sounding rather annoyed which was not my intent,
I'm still concerned that I'm redirecting too much by doing everything in the /umbraco folder except the two subfolders that I mentioned. (Clearly I should be as I missed the /umbraco/surface subfolder, although I don't currently see such a folder in our installation.) It's a good tip to focus on redirecting only access to the /umbraco folder itself and not its subfolders - I'll play around with the rewrite rules to achieve that.
Surface controllers and all mvc controllers are based on routes, not based on physical files, so /umbraco/surface/* is a route, there are no files there.
I'd recommend simply redirecting the 2 mentioned above:
www.yoursite.com/umbraco
www.yoursite.com/umbraco/
The other one that can access the back office is:
www.yoursite.com/umbraco/default
www.yoursite.com/umbraco/default/
Hi Shannon,
Unfortunately, although I have a similar setup to Thayer, this thread is going off on a different tangent to the issue I am having so as not to hijack this thead I have created my own. Would you mind taking a look please?
http://our.umbraco.org/forum/getting-started/installing-umbraco/56309-Load-balancing-distributed-call-not-updating-cache-(716)
Thanks
I believe I've gotten my URLRewrite module rules tightened up to only get the paths you mention. My (hopefully) final question has to do with the individual files in the root of the /umbraco folder. At the moment I have access to those files getting redirected to the back office server, and while this seems appropriate for some of them (for example /umbraco/umbraco.aspx) it might be undesirable for others (for example /umbraco/ping.aspx). Do I need to be more careful on how I'm handling redirects for those individual files?
Yes you do, things like /umbraco/ping.aspx and other web services need to be able to be contactable by it's own server. The ping.aspx is for keep alive, so a server pings itself. Then there's things like scheduled tasks which a server needs to be able to ping itself - but for LB that is taken care of with the new config settings: http://our.umbraco.org/documentation/Installation/load-balancing#Correctconfigforscheduledpublishing&tasks
I'd suggest that you should really just keep it as simple as:
/umbraco /umbraco/ /umbraco/default /umbraco/default/
you can also do /umbraco/umbraco.aspx you can also do /umbraco/default.aspx
I'm currently struggling with my NLB setup and also found the documentation confusing when it came to restricting backoffice access to a single server. It seems to me that since our nodes are already named, then we don't need to create a new DNS entry for the admin section. We could instead redirect backoffice users from server2/umbraco to server1/umbraco. Is this the case?
If so, how is this for a server redirect pattern:
It seems to catch only the routes directing to /umbraco(/) and /umbraco/default(/). Leaving the nodes the ability to ping themselves.
It's up to you how you want to direct your admins to your servers, creating a sub domain is generally an easy and fail safe way for most admins to do it, doesn't require URL rewriting and guarantees all admin requests go to the correct server. (i.e. admin.mysite.com would point to your single server)
If you don't want to do that, then sure you can go down the URL rewriting route and so long as your server 'names' like server1/umbraco are accessible for you admins then that should be fine, but you should really test to make sure when you are using the back office that all requests are going to that same server (you could verify with fiddler or something).
is working on a reply...