Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Thayer York 5 posts 54 karma points
    Aug 29, 2014 @ 02:18
    Thayer York
    0

    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).

    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:

    • 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?

    Thanks for any and all feedback!

      -> Thayer

  • Nick 6 posts 84 karma points
    Sep 02, 2014 @ 09:19
    Nick
    0

    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

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Sep 04, 2014 @ 03:26
    Shannon Deminick
    0

    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.

  • Thayer York 5 posts 54 karma points
    Sep 04, 2014 @ 03:39
    Thayer York
    0

    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.

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Sep 04, 2014 @ 03:43
    Shannon Deminick
    0

    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.

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Sep 04, 2014 @ 03:45
    Shannon Deminick
    0

    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.

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Sep 04, 2014 @ 03:46
    Shannon Deminick
    0

    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.

  • Thayer York 5 posts 54 karma points
    Sep 04, 2014 @ 22:20
    Thayer York
    0

    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.)

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Sep 05, 2014 @ 01:24
    Shannon Deminick
    0

    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.

  • Thayer York 5 posts 54 karma points
    Sep 05, 2014 @ 02:36
    Thayer York
    0

    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.

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Sep 05, 2014 @ 02:38
    Shannon Deminick
    0

    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/

  • Nick 6 posts 84 karma points
    Sep 05, 2014 @ 11:25
    Nick
    0

    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

  • Thayer York 5 posts 54 karma points
    Sep 05, 2014 @ 23:05
    Thayer York
    0

    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?

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Sep 08, 2014 @ 07:51
    Shannon Deminick
    0

    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

    • but those are 100% legacy and not really used but won't hurt to redirect them
  • Matthew Kirschner 323 posts 611 karma points
    Feb 17, 2015 @ 17:36
    Matthew Kirschner
    0

    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.

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Feb 19, 2015 @ 13:24
    Shannon Deminick
    0

    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).

Please Sign in or register to post replies

Write your reply to:

Draft