Microsoft some time back released “Streamlined Topology for SharePoint 2013”, new way to build & configure SharePoint 2013 farm. It’s really nice to see official documentation on new approach which I had first heard at SPC12 during SPC119 “Designing Your SharePoint Server 2013 Enterprise Deployment” Session. In that session Luca Bandinelli delivered prescriptive guidance to build SharePoint 2013 On-Premises farm similar to SharePoint Online based on Microsoft’s lessons learned and best practices while maintaining and building their own SharePoint online data centers.
As far as Physical Topology, We have three tiered approach since MOSS 2007 days. In MOSS 2007, we had Web Tier, Application Tier (Central Admin, Shared Service Providers – Search, Excel, Profile Import), and Database Tier. In SharePoint 2010, there wasn’t much changed and we had almost same 3-tier topology (except Application Tier dedicated for Service Applications instead of SSP) but dedicated servers can be added in application tiers for high preformat service applications like Search or PerformancePoint etc.
With SharePoint 2013, we had lot more service applications and many of these service applications can be grouped in similar groups either based on their CPU and RAM needs or either based on their latency, throughput, or workloads/resource utilization to optimize system resources and maximize performance for users. Even though we can get away with traditional 3-tier topology approach in SharePoint 2013, there are some new services may require additional tier and dedicated attention on Application tier. All the windows & WCF services can be divided into – very low, low, and high tolerant latency and this may require us dividing up application tier in multiple tiers for each type of latency tolerant service applications.
As shown in the diagram below, Microsoft provides us alternative farm design topology by redefining traditional web and application tier into multiple tiers.
Traditional webtier is redefined as Caching and Request Processing tier which would group similar web front end servers forend user request processing along with new service applications like Request Management and Distributed Cache which would require very low latency but very high throughout. Request Management is disabled by default and Distributed Cache is enabled by default. Since Request Manager is CPU intensive and Distributed Cache is memory intensive, both of these services can share same server without any major performance hit.
- Traditional Application tier is divided into two optimized tiers – Front End Servers and Batch Processing Servers.
- Front-End Servers would group similar service applications which would serve user requests with low latency, low resource utilization, and optimized for faster performance and response time. Services like Central Administration, Managed Metadata, User Profile, App Management, Search Query Role, and Business Data Connectivity are ideal for Front End Servers.
- Batch Processing Servers would group similar service applications which would typically require long running back ground processes, high latency, and high resource utilization, and optimized for higher workload by maximizing system resources. Services like User Profile Sync, Work Management, Search Crawl and Index Role, Workflow, Machine Translation etc. are ideal for Batch Processing Servers. For large scale farms, Batch processing tier can be divided further into specialized load servers for services like Search, PerformancePoint, or Excel Services which can cause high spikes in performance during peak time.
- Database tier stays same in both traditional and streamlined model. These servers can be either clustered, mirrored, or configured with Always On.
Ok, So, What’s your take on this new Model..
Having said that, my take on this new approach is what I used to say while designing SharePoint 2010 topologies. Even though you would ideally love to plan for 4-5 tier topology, it may not be possible in real world due to possible hardware funding issues. You are looking at nearly 10 high performing virtual machines or physical hardware, which may be daunting to get through budget approval process.
Depending on your situation, number of users, and size of farm, you may get away with running traditional three tiered approach as long as they have enough hardware resources like RAM and CPU allocated. With the traditional 3-tier approach, you can run Distributed Cache and Request Management on Web Servers, Central Admin and all the Service applications in Application tier as initial farm design and plan to scale out or add more dedicated servers for specific workloads like Search as needed.
Resources
Rana Omer Hussain's RegEdit 