We will start our IIS adventure by discussing the general architecture behind building a scalable web tier. As with many things in life it is easy to start something yet difficult to finish. This topic will consist of a multitude of blog posts where we break each task down into its components and help you put them back together. Let's get started...
This is part of a multiple article series, take a read through the other articles:
- Scalable IIS Infrastructure
- Architecting IIS Farms
- Using PowerShell to Provision IIS
- Using Powershell to Implement DFS (Coming Soon)
- Full IIS Powershell Solution (Coming Soon)
- Windows Active Directory
- Windows Server 2016
These concepts are platform agnostic; you can apply these ideas to AWS, Azure, Google Compute and even your own datacenter.
As you can see below, we have divided the problem into four tiers: App, Data, File, and Network.
- App tier houses one or more IIS web farm(s).
- Data tier serves a combination of SQL, NoSQL, Redis etc.
- File tier manages file replication using DFS.
- Network tier directs public traffic to our private hosts.
To get the most stability and performance out of each tier requires us to understand the strengths and limitations of each. In this segment, we will be focusing on the App and File tiers.
The most important aspect to the App tier is that the operating system, roles, features and modules must be consistent across each node. It is best to have a cripted method for creating and updating nodes. (We will dive into an actual PowerShell script to achieve this soon).
I like to think of the App and File tiers as completely separate, yet in reality, there is no clearly defined line and they are highly integrated. The reason for this is that the IIS hosts are actually, part of the file tier by having the DFS role installed.
You must ensure that the site content is an exact copy across every host in a load balanced App tier. Imagine if you were presented with a different web page version every time you reloaded a page? It would be bad to say the least but that is where DFS shines. By joining all of the web hosts to the DFS namespace, you can configure uni/bi-directional replication.
Another key component to making IIS into a farm is the Shared Configuration setting. By replicating a shared configuration file, you can make changes on one IIS host and have that change quickly replicated to all other hosts. This works beautifully for creating sites, bindings, altering application pools, etc.
Our next set of articles will be focused on actually provisioning IIS nodes, managing roles, installing certificates and tacking DFS replication through Powershell scripting. In the meantime, take a look at this great article on DFS. How to set up DFS Namespaces in Windows Server 2016.