The design aspect of MOSS is the most frequently faced and least discussed subject area. Recently, I had been posed towards issues that relate to decision criteria for the selection of number and organization of servers in a server farm design for MOSS. I looked over the factors that rule the decision making in this context and after some research; the answers were no different than expected. The answers were:
Each of the above factors, in my point of view, is important to consider while trying to achieve a workable design for MOSS based solutions. This is why this post has been suffixed with the title ‘Part 1’ as I will be discussing each of these factors in next parts of this post and will also examine the effect of topology design over these factors. However, before moving to the optimization factors, let’s focus on the baseline server farm configuration for a typical MOSS installation.
A recommended MOSS 2007 deployment topology is composed of three virtual layers:
· Web Front End Layer
· Application Layer
· Database Layer.
I said virtual because nobody enforces that there need to be all these layers isolated and separate server(s) attached to each layer. OK, so we are faced with scenarios here. Let’s simplify it a bit. Based on the above mentioned factors, let’s say we conclude that the layers (roles), all of them aggregate in a single physical server which of course is not recommended for production scenarios. This results in a single server farm.
Single Server Farm
Single Server Farm, as the name suggests is deprived of the luxury of a lot of hardware and everything resides in a single box. This can be used for demonstration, proof of concept or evaluation purposes. Although this topology is not recommended for production environment, but still in cases where there are low number of users and performance bottlenecks are tolerable to a large extent, this configuration can be useful.
Two Server FarmThere might be cases where due to some of the factors (mentioned above), one or more of the layers be represented by separate servers (one or more for each role based on the redundancy requirements). The least recommended starting topology for most of the scenarios is a two server farm where one server acts as a database server and the other serves WFE and Application Server Roles.
This topology is typically useful when the data needs to be isolated and flexible enough to be scaled to multiple servers in future.
Three Server Farm (Adding the Application Layer)
This topology typically introduces another layer and hence the three layers now are isolated and each represented by one or more servers. Each of these roles may also introduce redundancy by adding redundant hardware and using the load balancing techniques.
What is important to note is that the server farms depicted above are differentatied by the number of layers and not the number of servers to use in a particular farm topology. Each of the above farm configuration is different from the other due to the introduction of roles and representation of roles at different tier levels. A three-server farm, for instance, may also be achieved by adding a redundant database server to the above-discussed two-server farm or by adding a redundant WFE server. So there is much to think over for a good design and we are yet to examine the factors that affect the number of servers in each of the server farms discussed above.
I hope this post was helpful to understand the typical server farm tiers available with MOSS. In the next posts, I will be discussing the extension of these baseline topologies that include redundant hardware to fulfill varied client requirements based on Availability, Performance and Capacity.