Update on Stretch Farm Support in SharePoint 2013

Per http://technet.microsoft.com/en-us/library/cc262485(v=office.15).aspx#hwLocServers, support for stretch farm topologies SharePoint 2013 was unsupported. As a result of our continuous efforts to review and update our product performance and capacity boundaries, we are pleased to announce supportability for a
limited set of stretch farm topologies under the definition of distributed topologies. All of these topologies are based on a prerequisite of minimal (< 1ms) latency between components of the farm (see also https://technet.microsoft.com/en-us/library/cc748824(v=office.15).aspx#CfgStretchedFarm).
Topologies that do not meet this definition remain unsupported and are not under consideration for review at this time.
 
Frequently Asked Questions 

Q1 My customer wants to distribute their topology across one or more distinct geographic boundaries (i.e. between cities, states, provinces), is this supported?
A1 No.
Q2 My customer maintains a logical datacenter comprised of one or more physical buildings on a single site.  Is this supported?
A2 Yes, providing there is a highly consistent intra-farm latency of <1ms, 99.9% of the time over a period of ten
minutes. (Intra-farm latency is commonly defined as the latency between the web front-end and database servers)
Q3 My customer’s latency exceeds 1ms – what can I do to get them to a supported configuration?
A3 See http://technet.microsoft.com/en-us/library/cc263031.aspx for documentation detailing high availability and disaster recovery topologies possible with SharePoint Server 2013.

Be aware that it will take a couple of weeks till the the SharePoint 2013 article will be updated as it will have to got through official review and approval process.
 
For SharePoint 2016 see these articles:

 

4 Comments


  1. Re A1 and A2.

    But what if the second physical building (A2) just happens to be in a different city because the border goes between the two !

    Surely the restriction to "highly consistent intra-farm latency of <1ms, 99.9% of the time over a period of ten

    minutes." is enough a requirement (and by extension bringing "distinct geographic boundaries" into it is nonsense).

    Reply

  2. Hi,
    Thanks for the article. This is useful information.
    I do have a few follow up questions:
    1. What’s the rationale behind the geographically disperse locations not being supported?
    2. If the latency to the database can be achieved, why wouldn’t it be supported?
    3. The above note appears to be related to the SharePoint nodes back to the database nodes. What about having SharePoint nodes in the same Farm, in different data centers?
    Thanks.

    Reply

  3. Hi, we utilized proxy groups to keep stretch farm communication to a minimum, we had a second data centre a block away – would probably respond in 2-3ms as their is a fibre link. The stretched topology proved successful in maintaining high availability during the Brisbane, Australia floods, I would like to see Microsoft support this configuration as it is proven….perhaps lift the 1ms to

    Reply

  4. Does WFE and database server imply application server and database server?

    We're working with search farms where federation isn't acceptable – largely because the result sets must be merged. We'd like to build out a single farm with several regional datacenters hosting completely independent index partitions, crawl nodes/dbs, document processing and indexing, and query servers for locally accessed content (not SharePoint content.)

    Latency would meet the requirements in these datacenters with two notable exceptions: The SharePoint configuration database and central admin would be remote to all but one of the datacenters. Searches would be referred to the search farm from the distributed SharePoint farms.

    What kind of issues would we be expected to run into in this sort of distributed environment? Has anything changed in the year since your post to allow for a more tolerant framework.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.