Wednesday, 6 June 2018

Geo-replication in SharePoint and SPO to the recue

Geo-Replication on SharePoint (Not covering email or OneDrive)

Problem: Over the past 7 years, I have worked on a few clients that require some form of Geo-Replication of share SharePoint farms.  Geo-replication is normally needed for compliance.  This post assumes you need to geo-replicate and not why you need to geo-replicate

Tip: Geo-replication can be used for performance but the complexity that it brings I feel is an added bonus and should not be undertaken for performance gains, there are easier better pragmatic answers to performance such as Riverbed devices, caching and CDN's to name a few.

Initial Hypothesis:  Large organisations existing in multiple geographic regions and need to abide by country regulations and often other industry standards bring the need to geo-replication capability.  I recently completed several high profile projects for a big four consultancy that needed to ensure SharePoint data does not leave its jurisdiction depending on its metadata.  Building on-prem Sharepoint farms were extremely complex and the 3 big services that needed to be centralised or copied are Search, MMS and the Content Type Hub.  There are more like AAD but for my situation, I needed to be able to have multiple SharePoint farms in specific regions that connected to centralised services.

Thoughts: MS has OneDrive and the email piece working in local geographies.
SharePoint is coming with multi-tenancy and users will get unified search results across geographic regions.
  1. Search each tenant holds their own index, not a central index for search - "good news for data location compliance".  Somehow MS are intermingling all the search results using federation - wow.  
  2. Profile Services (use to be UPS) gets core fields from central AAD and local fields are stored at a tenancy level (good news).  
  3. Taxonomy (MMS) is replicated downwards from the central MMS.
  4. Each tenant has it's own content type hub (I never liked this), the CTH uses a star topology to push the CTHub from the central tenant to the regional tenants so the copies including GUIDs are identical.
SPO to the Geo-Rescue (coming soon, in pre-beta as of 6 June 2018):
  • SPO is implementing multiple tenants across O365 like O365 previously did for OneDrive, you can specify where sites get created i.e. region/country.  Each region as it's data centres specified and the URL of the Sites clearly indicates where the site is hosted.
  • The search index is kept in-country and federated up to the central tenant for a seamless search experience across multiple region tenants.
  • Central taxonomy is automatically replicated to the regional tenant.  MMS us a star topology to distribute and keeps GUIDs in sync.
  • UPA holds only key data centrally and each region holds additional properties (good for GDPR and other DPA regulations).
  • AAD is controlled centrally and I believe AAD's have regional copies.
RoadMap:
OneDrive is multi-geo now.  > Circa Oct-Dec 2018 SharePoint will offer multi-geo (yeah).

http://blog.sharepointsite.co.uk/2013/08/stretched-farms-geo-replication-and.html

SharePoint Online Replacement Patterns in Diagrams

Overview: This Post highlights my default position for achieving Common SharePoint solutions using SharePoint Online, flow and Azure Functions.


Matt Wade has a great resource on the components making up O365.
https://app.jumpto365.com/