harbar.net component based software & platform hygiene

SharePoint 2016 Nugget #1: Topology Service in MinRole Farms

Print | posted on Monday, April 04, 2016 8:43 PM

Whilst I have some much more in depth coverage of SharePoint 2016 coming soon, this is the first in a mini series of “nuggets” – tidbits of information on the new release. Unlike with previous releases I decided against publishing a lot of material whilst the product was in public preview and to wait until the RTM. This decision was driven by a number of factors I won’t bore you with.

Many will be of the opinion that not a great deal has changed in SharePoint 2016. That is somewhat true, especially in respect to visible end user or administrator capabilities. However there are a significant number of small but important things to be aware of, and this series will catalogue many of them over the next few weeks. This doesn’t mean I won’t also be providing some “all up” coverage in the near future.

In previous versions of SharePoint (i.e. 2010 and 2013) the Application Discovery and Load Balancing Service (aka the Topology Service) was deployed to every server in the farm. This service amongst other things is responsible for maintaining a list of addresses of service application endpoints. These are used for Web Application <-> Service Application and Service Application <-> Service Application communication. In the previous versions, it would be extremely likely to go to another machine even if the requested service was running locally. It was a basic round robin style approach.

In SharePoint 2016 this has been changed to always “prefer local”. In other words if the requested service is running locally, go there. Instead of hoping over to another machine. If that isn't possible then it will go to a remote server. This change was implemented after the Product Group was able to measure the positive impact of the “prefer local” model whilst running SharePoint Online. And the change has been baked into SharePoint 2016. This is one of a number of small but significant changes under the hood, which mean SharePoint 2016 can perform significantly better than SharePoint 2013. This is *exactly* the sort of engineering improvement needed across the product in broader terms.

The “prefer local” model is used within both farms leveraging MinRole Server Roles, and farms where every machine is of role Custom (aka Opting out of MinRole, or a 2013 style topology).

In addition to the “prefer local” model, the Topology service in SharePoint 2016 is no longer deployed on every server in the farm. It is only deployed to the Application, Search and Custom roles. In a MinRole farm there is no need to have the IIS Web Application present on servers of role DistributedCache or WebFrontEnd so it’s not deployed. Note the term IIS Web Application - don't confuse this with a SharePoint Web Application whose counterpart in IIS is a Web Site. Here’s a WebFrontEnd in my farm after the servers have been joined to the farm, but *before* any service applications have been created (with MinRole service instances are provisioned automatically when service applications are created):

image

No-one wants to be pointing and clicking around across a bunch of boxes (and hitting that annoying WPI pop up!). The following Windows PowerShell will display the IIS Web Applications under the SharePoint Web Services IIS Web Site for every server in the farm:

 # Show the Service Application Endpoints across the farm
 # ignores Outging Email and Database servers
 ForEach ($Server in (Get-SPServer | ? {$_.Role -ne "Invalid"})) {
    Write-Host "$($server.Address): $($server.Role)"
    Invoke-Command $Server.Address { 
            Import-Module WebAdministration;
            Get-ChildItem "IIS:\Sites\SharePoint Web Services" | 
            ? {$_.NodeType -eq "application"} |
            Select Name | Format-Table -HideTableHeaders
    } 
 }

And here’s the output of the above (I’ve filtered to show only one machine per role):

DistributedCache
----------------
SecurityTokenServiceApplication

WebFrontEnd
-----------
SecurityTokenServiceApplication

Application
-----------
SecurityTokenServiceApplication
Topology                       

Search
------
SecurityTokenServiceApplication
Topology                       

Custom
------
SecurityTokenServiceApplication
Topology

But what about after some service applications have been created? No big surprises here, the endpoints are only deployed on the roles that are hosting the service instances. Just like SharePoint 2013, but due to the topology model that MinRole enforces it’s worth covering a few aspects of this.

On the DistributedCache role we don’t care about endpoints. We’ll never use them. Even if we were (stupidly) running Request Management on that role we still would never need them. We certainly don’t want to advertise services to other roles.

On the WebFrontEnd role, if we need to call the low latency service applications like BDC, MMS, UPA etc we prefer local but we can go to another machine if necessary. If we need to call “not so low” latency apps such as Word Automation or PowerPoint Automation etc we go across to the Application server as we did in SharePoint 2013. On this role there is no desire to advertise services to the other roles.

Likewise on the Application role, we will also go local if we can or otherwise via the Topology service Application Addresses.  This is an important aspect to really understanding MinRole. This is why all those service instances are deployed on the Application role as well as the WebFrontEnd role. In addition we do wish to advertise our services to other roles.

It seems a little strange at first, but this is a key part of changing the approach to Farm Topology. MinRole in many ways could be: the making of min changes for max effect.

On the Search role, we’ll pretty much go via the Topology service in the uncommon scenarios where we need to call out to the other service instances. The only endpoints on the Search role, are wait for it, the Search ones!

Here’s the output after every service application has been created in the farm:

DistributedCache
----------------
SecurityTokenServiceApplication

WebFrontEnd
-----------
0e2a2a21d68f48e5ac6e5212386c68a1
65bac1dee73a45d980e8a727ecded730
7e5c51e5c9644e20acfb0ebfe9e1932c
86e16014fa714b2482fe61558f47f4c8
872ceab28a38461781b492e8d0cd246b
8e1c5639ec3f4ef988064f210f23fd46
9abc0e641df14da283b794ca5951a54c
a8f3b8c8fab44a1a98fb66d85865362f
da9a134d441e4d109ad9b76beee38fc5
SecurityTokenServiceApplication 

Application
-----------
0e2a2a21d68f48e5ac6e5212386c68a1
343877e231ee4bac8a6ad9450fd9a3c9
65bac1dee73a45d980e8a727ecded730
7e5c51e5c9644e20acfb0ebfe9e1932c
86e16014fa714b2482fe61558f47f4c8
8e1c5639ec3f4ef988064f210f23fd46
a8f3b8c8fab44a1a98fb66d85865362f
bf5d1dc0e3964dd99a96542d20b7f097
da9a134d441e4d109ad9b76beee38fc5
SecurityTokenServiceApplication 
Topology                        

Search
------
74fbbb18d6fe49e6bdec58bdca9178f2
d55ae60a84b649c28b9022baedecb2fa
SecurityTokenServiceApplication 
Topology                        

Custom
------
SecurityTokenServiceApplication
Topology        

Ahh, I love me some GUIDs, can’t get enough of ‘em. Could be worse, could be Octet strings. Let’s sort that out. Unfortunately this means using the SharePoint Snap-in. Sadly that’s not something that’s been fixed in SharePoint 2016!

$Credential = Get-Credential $ShellAdminAccountName
ForEach ($Server in (Get-SPServer | ? {$_.Role -ne "Invalid"})) {
    echo ""
    echo (Get-SPServer -Identity $Server | % {$_.Role})
    echo "-----------------------"
    icm $Server { 
            Import-Module WebAdministration
            Add-PSSnapin -Name "Microsoft.SharePoint.PowerShell"
            $Apps = Get-ChildItem "IIS:\Sites\SharePoint Web Services" | ? {$_.NodeType -eq "application"} | Select Name
            ForEach ($app in $apps) {
                If ($app.Name -eq "SecurityTokenServiceApplication" -or $app.Name -eq "Topology") { $app.Name }
                Else { (Get-SPServiceApplication | ? {$_.Id -eq $app.Name}).DisplayName }
            } 
    } -Credential $Credential -Authentication Credssp
}

Note, there’s lots of aliases and such like in the above script. You wouldn’t really ever do this for real, it’s just for demonstration purposes. Here’s the output:

DistributedCache
-----------------------
SecurityTokenServiceApplication

WebFrontEnd
-----------------------
Machine Translation Service Application
App Management Service Application
Secure Store Service Application
User Profile Service Application
Visio Graphics Service Application
Managed Metadata Service Application
Access Service Application
Business Data Connectivity Service Application
Subscription Settings Service Application
SecurityTokenServiceApplication

Application
-----------------------
Machine Translation Service Application
PowerPoint Automation Service Application
App Management Service Application
Secure Store Service Application
User Profile Service Application
Managed Metadata Service Application
Business Data Connectivity Service Application
Word Automation Service Application
Subscription Settings Service Application
SecurityTokenServiceApplication
Topology

Search
-----------------------
Search Service Application
Search Administration Web Service for Search Service Application
SecurityTokenServiceApplication
Topology

Custom
-----------------------
SecurityTokenServiceApplication
Topology

And that’s all there is to it. Pretty simple stuff. But again, these seemingly trivial changes have a significant positive impact on overall farm performance. As always with SharePoint, the devil is in the detail. As much legacy gunk is still in the product, there are some extremely smart cookies working hard to make it better for all of us. Respect due.

I will leave you with this:

cola1

s.