Since SQL 2012 is coming with so many advanced features, is there a way to leverage the features and confingure one single SharePoint farm to be deployed across the globe?
Here is the design I have in mind but I am not sure how the SQL 2012 new features can help or how well they can Fit in this scenario to be precise…
| Item | Location 1 | Location 2 | Advantage/Disadvantage/Challenges |
| Site | http://site1 | http://site2 | Advantage for local sites reducing latency |
| Site DB | Content_DB1 | Content_DB2 | |
| StandBy DB (For High Availability) | Content_DB2 | Content_DB1 | Which SQL Technology to use to sync the DBs? Log Shipping, Always On, Geo Clustering |
| Central Admin | http://CA | http://CA (For Backup) | How do you manage DNS switching if one CA Server goes down? |
| Central Admin DB | ConfigDB | ConfigDB | Which SQL Technology to use to sync the DBs? Log Shipping, Always On, Geo Clustering |
| Web Front Ends | WFE1 | WFE2 | What will be the impact of deploying a global solution which updates GAC folder and does IISReset on all WFEs? |
| App Servers | APP1 | APP2 | Should we go with Location specific App Services with their Databases in local SQL Servers (makes more sense but adds more manageability overhead) or have single default group associated with all Web Applications? |
| App DBs | Apps_DB1 | App_DB2 | This would depend on above mentioned decision |
| DB Servers | SQL1 | SQL2 | How to sync DBs so one locaion can also act as a standby Farm for another location? |
| PreferredServer for Timer Job | APP1 | APP2 | This should be straight forward for Content DB related timer jobs. Custom timer jobs however need to carefully written so they select the respective location based App Server to run on |
What are your thoughts? Please share….
My understanding is that SP2010 (and I believe it hasn’t changed in SP2013) doesn’t support a geo-dispersed farm.
The critical bit is latency between the SP machines (in particular the WFEs) and the SQL DBs and if the WFEs are connecting to different SQL Servers, you have to ensure that any replication at the DB layer is transaction safe, which depending on the distance (and network latency) between the SQL Servers, is likely to be an issue.
There are a number of third party products out there for doing what you want, as they provide transaction safe replication at the SharePoint level (even before it hits the DB). Though I’ve also heard results/reliability tend to vary somewhat from what the marketing blurb states.
Some of the players in this space are: AvePoint, MetaLogix, iOra, RepliWeb and Syntergy.
I’ve not used any of these products, though longer term I’m likely to be wanting to use something in this space.
Note: if your remote WFE is read-only, you can probably get away with SQL2012 DB mirroring, but even this is a fudge…
You might need to start asking yourself why you need a single farm to be geo-dispersed and potentially look at two (or more) farms with location specific content and then use agregated search to pull the content together…
Just my 2c
Later’ish
Craig
