I have been reading up on IIS 7.x shared configuration and WFF and wanted to get your input to make sure I understand the differences and similarities of these technologies. Please correct me if I'm wrong in any of my assumptions and feel free to add as
you think it's appropriate:
Content synchronization:
<div mce_keep="true">Shared Configuration - doesn't need to "sync" since it uses a centralized location (DFS/NFS) that is accessible by all servers at the same time. I think this would be the right option if a web application didn't use a back-end DB and
stored files locally. For example: an application that uploads a file to the "local drive" could be scaled out and load balanced by adding servers horizontally since all servers could see the same uploaded files immediately.
</div>
<div mce_keep="true">WFF - I believe WebDeploy is used to sync content that doesn't necessarily change very frequently or that happens in a controlled manner (web admin or developer). I don't think it would work out for the example above since an uploaded
file would not be immediately available to all servers.</div>
Installing new IIS modules
<div mce_keep="true">Shared Configuration - I found this
article for the steps that need to be taken to maintain service availability if new IIS modules need to be installed. It appears to be a manual process unless there's a better way to do it (can WebDeploy be used here without necessarily WFF?)
</div>
<div mce_keep="true">WFF - I found this
article that describes platform and application provisioning in an automated manner (at least that's what it looks like to me). However, I'm not clear on what happens once the primary server gets the updates... is there a way to update the other servers
in a controlled manner and with coordination on the load balancer to maintain service availability?</div>
High Availability
<div mce_keep="true">Shared Configuration - Scales horizontally relatively easy. Integrates with ARR and other hardware load balancers. No single point of failure.
</div>
<div mce_keep="true">WFF - Scales horizontally relatively easy. Integrates with ARR and other hardware load balancers. I have been trying to find out how to make the Controller and Primary server HA since it's my understanding that if either of them go
down the websites stop working. Haven't found anything. If this is true, well, it's not really highly available is it?</div>
Test / Development Environments
<div mce_keep="true">Shared Configuration - I think that a separate test/dev environment would be needed to avoid all of the manual steps as described in the Installing IIS modules section. Then follow those steps to take one server out and update via what?
Web Deploy? Manual configuration?
</div>
<div mce_keep="true">WFF - It sounds to me like a controller server could manage 2+ separate farms (prod/test) and have the ability to push the configuration from one farm (or server) to another. </div>
Integration with other windows technologies:
<div mce_keep="true">Windows Communication Foundation (WCF) / Windows Workflow Foundation (WFF) - SOA type of stuff
</div>
Visual Studio 2010
Can Shared Config and WFF work together in some type of nested configuration?
I would appreciate any other feedback to understand the differences, advantages, disadvantages between these two technologies and make an informed decision on what fits our environment the best.
The recommended solution appears to be a hybrid of Shared Config/NLB for ARR and Web Farm Framework for Content.
Rather than look at the features, it's better to look at the two sets of servers that need to be set up.
1. ARR Servers - NLB with Shared Configuration. Need to manually set up ARR servers. Install Web Farm Framework and ARR manually. The ARR Servers ARR are the WFF Control Servers. Then used shared config to manage multiple ARR servers.
2. Content Servers - Primary and Secondary Web Farm Framework - but the Web Farm is managed from an ARR server and the websites are managed on the Primary Server. Stuff on Secondary Servers occurs via WFF Magic (is kinda cool to watch it replicate without having
to do anything - BUT be patient while the Secondary Servers are first configured as software needs to be installed).
I'm in the process of experimenting. It appears that on the Content Servers you can use shared storage for the sites (DFS is ideal for further redundancy - we use 2 Primary Domain Controllers with DFS replicating files between them). In this case, WFF only
replicates the settings and not the files (which is a nice alternative to shared config). If you store the files locally on the Primary Server, then they are copied to all the secondary servers (WFF seems to take servers/sites offline while it does this which
is likely to have some advantages). Using local storage might make more sense as the files and sites are cleanly replicated. Updating the code base on a DFS share (and site settings) might be a violent approach - eg. Secondary Servers see the new files but
have not seen the site setting changes so you end up with some unpredictable results. Replicating files across multiple secondary servers will also provide redundant copies and reduce network load.
Your concern with a Primary Server failing? It doesn't matter. Just designate one of the Secondary Servers as the Primary Server and keep going. As long as you remember to always perform your admin on the Primary Server (which ever server that is), all settings
will be replicated to remaining Secondary Servers.
TIP: DO NOT setup ARR with Shared Config/NLB until you have 1 ARR server and 2 Content Servers working. Then create a 2nd ARR server, setup Shared Config and finally NLB.
TIP: DO NOT include the ARR Server as a Primary Server. I made this mistake because the MS documentation suggests it's possible but in practice it's a bad idea because it starts replicating ARR settings to content servers which messes everything up (In which
case, start with a fresh Windows install!). At a minimum, you should be planning for 2 ARR Servers and 2 Content Servers. The ARR Servers and WFF Control Servers ARE the same.
It seems the case for WFF on Content Servers is strong as WFF manages the installation of all the server automatically. The leaves managing the ARR servers manually - in most scenarios there will only be a few ARR servers.
Shared Hosting
The Shared Hosting (Host Affinity) stuff looks really interesting for scaling. The examples I have found discuss using Shared Config, but they are 3-4 years old and I would say that the new best practice is to use WFF to replicate all sites to all content servers,
then let ARR load balance between the web servers.
SSL Offloading
Setup on the ARR servers. Simple HTTP requests (non-SSL) are then sent through to the content servers. This means your content servers can be pure HTTP which simplifies management. This assume that your connection between ARR and Content servers is physically
secure. The only thing to be aware of here is that normally the ARR servers have no websites (except the default for handling ARR). When you implement SSL, you create a site on the ARR server with an appropriate SSL certificate for that domain (remember to
install cert on all ARR servers before playing with IIS shared config).
Example:
ARR Server has https://www.test.com
ARR forwards request to WFF Content Servers using HTTP.
I hope this helps someone as the material on ARR, WFF, etc. is somewhat confusing... until you try it!
I have set up two web farms with ARR and it shows load balancing is available for the servers in both. What I'm not clear on is if I stop IIS on the primary node it doesn't go to the secondary. Also I am not seeing statistics being incremented in monitoring
and management. So what is ARR actually load balancing? Do I need to also install NLB to see ARR work?
grigos
2 Posts
shared configuration vs web farm framework
Dec 29, 2011 09:35 PM|LINK
Hi all,
I have been reading up on IIS 7.x shared configuration and WFF and wanted to get your input to make sure I understand the differences and similarities of these technologies. Please correct me if I'm wrong in any of my assumptions and feel free to add as you think it's appropriate:
Content synchronization:
</div>
Installing new IIS modules
</div>
High Availability
</div>
Test / Development Environments
</div>
Integration with other windows technologies:
</div>
Can Shared Config and WFF work together in some type of nested configuration?
I would appreciate any other feedback to understand the differences, advantages, disadvantages between these two technologies and make an informed decision on what fits our environment the best.
shared configuration iis7 web farm framework
grigos
2 Posts
Re: shared configuration vs web farm framework
Jan 05, 2012 01:57 PM|LINK
Anyone?
jonsingh
8 Posts
Re: shared configuration vs web farm framework
Apr 09, 2012 03:54 PM|LINK
grantph
1 Post
Re: shared configuration vs web farm framework
Jul 19, 2012 06:42 AM|LINK
The recommended solution appears to be a hybrid of Shared Config/NLB for ARR and Web Farm Framework for Content.
Rather than look at the features, it's better to look at the two sets of servers that need to be set up.
1. ARR Servers - NLB with Shared Configuration. Need to manually set up ARR servers. Install Web Farm Framework and ARR manually. The ARR Servers ARR are the WFF Control Servers. Then used shared config to manage multiple ARR servers.
http://learn.iis.net/page.aspx/511/achieving-high-availability-and-scalability---arr-and-nlb/
2. Content Servers - Primary and Secondary Web Farm Framework - but the Web Farm is managed from an ARR server and the websites are managed on the Primary Server. Stuff on Secondary Servers occurs via WFF Magic (is kinda cool to watch it replicate without having to do anything - BUT be patient while the Secondary Servers are first configured as software needs to be installed).
I'm in the process of experimenting. It appears that on the Content Servers you can use shared storage for the sites (DFS is ideal for further redundancy - we use 2 Primary Domain Controllers with DFS replicating files between them). In this case, WFF only replicates the settings and not the files (which is a nice alternative to shared config). If you store the files locally on the Primary Server, then they are copied to all the secondary servers (WFF seems to take servers/sites offline while it does this which is likely to have some advantages). Using local storage might make more sense as the files and sites are cleanly replicated. Updating the code base on a DFS share (and site settings) might be a violent approach - eg. Secondary Servers see the new files but have not seen the site setting changes so you end up with some unpredictable results. Replicating files across multiple secondary servers will also provide redundant copies and reduce network load.
Your concern with a Primary Server failing? It doesn't matter. Just designate one of the Secondary Servers as the Primary Server and keep going. As long as you remember to always perform your admin on the Primary Server (which ever server that is), all settings will be replicated to remaining Secondary Servers.
TIP: DO NOT setup ARR with Shared Config/NLB until you have 1 ARR server and 2 Content Servers working. Then create a 2nd ARR server, setup Shared Config and finally NLB.
TIP: DO NOT include the ARR Server as a Primary Server. I made this mistake because the MS documentation suggests it's possible but in practice it's a bad idea because it starts replicating ARR settings to content servers which messes everything up (In which case, start with a fresh Windows install!). At a minimum, you should be planning for 2 ARR Servers and 2 Content Servers. The ARR Servers and WFF Control Servers ARE the same.
It seems the case for WFF on Content Servers is strong as WFF manages the installation of all the server automatically. The leaves managing the ARR servers manually - in most scenarios there will only be a few ARR servers.
Shared Hosting
The Shared Hosting (Host Affinity) stuff looks really interesting for scaling. The examples I have found discuss using Shared Config, but they are 3-4 years old and I would say that the new best practice is to use WFF to replicate all sites to all content servers, then let ARR load balance between the web servers.
SSL Offloading
Setup on the ARR servers. Simple HTTP requests (non-SSL) are then sent through to the content servers. This means your content servers can be pure HTTP which simplifies management. This assume that your connection between ARR and Content servers is physically secure. The only thing to be aware of here is that normally the ARR servers have no websites (except the default for handling ARR). When you implement SSL, you create a site on the ARR server with an appropriate SSL certificate for that domain (remember to install cert on all ARR servers before playing with IIS shared config).
Example:
ARR Server has https://www.test.com
ARR forwards request to WFF Content Servers using HTTP.
I hope this helps someone as the material on ARR, WFF, etc. is somewhat confusing... until you try it!
lborn
2 Posts
Re: shared configuration vs web farm framework
Jul 19, 2012 02:22 PM|LINK
I have set up two web farms with ARR and it shows load balancing is available for the servers in both. What I'm not clear on is if I stop IIS on the primary node it doesn't go to the secondary. Also I am not seeing statistics being incremented in monitoring and management. So what is ARR actually load balancing? Do I need to also install NLB to see ARR work?