Wednesday, 6 June 2018

Geo-replication in SharePoint and SPO to the rescue

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 centralized 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 - so they appear as an ordered result set from multiple different Geo indexes.  
  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/private preview 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. Offered to large enterprises only, must have certain number of users.
Circa Q1 2019 SharePoint will offer multi-geo.

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

0 comments:

Post a Comment