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 hard core question. love it, lets see who can come up with best solution. i know a few candidates who could have a go..will invite.