New Best Practices for SharePoint 2013 Farm Design – Streamlined Topology

Microsoft has just 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.

SP2013 Traditional to Streamlined Model

SP2013 Server Roles

  • Traditional web tier is redefined as Caching and Request Processing tier which would group similar web front end servers for end 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

About these ads
This entry was posted in SP2013 Admin. Bookmark the permalink.

3 Responses to New Best Practices for SharePoint 2013 Farm Design – Streamlined Topology

  1. on1tw2thr3 says:

    Hi Nik, I too am intrigued by MS’s new streamlined approach to the 2013 topology. And at the same time it leaves me wondering, what is the best approach for SP 2010? All of the SharePoint 2010 documentation points to utilizing the traditional 3 tier approach, with essentially all service applications running on the application tier. And that’s more or less how I’ve usually done things. Now with 2013 they hint towards recommending varied approach. Would that variation not potentially apply to SharePoint 2010 as well? This is what I am struggling with a bit in terms of how best to optimize my SP 2010 architecture. What are your throughts?

    • Nik Patel says:

      Thanks for comments and sorry not getting back to you.. As far as SP2010, this streamlined topology still applies and you can move services like Search or User Profile as batch processing tier.. In fact, this streamlined topology is based on MS’s own experience running SharePoint Online 2010/Office 365 environment.. For SP2010, I would run web application & search query role on WFE/front end tier, search index & user profile sync on batch processing tier, and all others services on application tier..

  2. Hi Nik.
    Just planning my first deployment for 30,000 users. I was somewhat disappointed with 3 tier and 10,000, so i’m very interested in that new approach. I’m wondering thou, about :
    – the request management. If it handles load balancing, it’d mean we use the regular load balancer on RM dedicaced servers, and then route via powershell RM to the “WFE”s? I mean, no more direct route from the HLB to the WFEs?
    – The dist cache. MS seems to say dedicaced mode is better, but in that case you can’t have fault tolerance. Are they talking about a “dedicaced collocated” mode on those two servers?
    The subject itself is very interesting. I notice MS expect one front end to serve more than 5,000 users. For 30,000 i wouldn’t go under 4 WFEs, unless the Dcache greatly alleviate the load on the server themselves. But caching has it’s limits, even for a read only visitor :)

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s