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….
This is a really interesting topic!! SharePoint farms are not supported over WAN, with different geographic locations. So to avoid really slow connections to a worldwide company intranet the only solution is using Replication (maybe there are products that can optimize connections but I still think there will be some latency and cannot be compared to have it locally). So if this could be solved by using SQL 2012 features, that would be awesome… But to replicate one intranet with 7 nodes, how would that work? And would the built in SQL replication fix that? Is that feature called Sync? And will it send the least amount of data if updated? And is it possible to optimize/encrypt/compress the data packages being sent?
I can do this today, because I have setup Metalogix for replication between our intranet and seven vessels, which works fine. The only downside is replication of webparts, and of course third party tools. Our vessel users has to surf into our office server to use (for example) DocRead, since it is not possible to replicate these. It is fine, but it would be cool if the DocRead webparts could replicate information and also replicate the DocRead db. I have never used the built-in SQL “replication” (sync) tools, maybe that could be enough? Our vessel users move around between vessels, so it is very important that the DocRead db’s are in sync at all instances. That might be hard to achieve with the SQL replication? Would be very cool to hear if someone has used the SQL replication and if that works between several nodes.