One of my customer (a huge company) is using MOSS 2007 in a stretched farm mode configuration (2 Data Centers); he recently decided to move to SharePoint 2013. Given the current SLA, the stretched farm configuration provides a good High Availability solution and the current Disaster recovery option is ok.
Since the SLA is the same, the first option to consider was to stick to the stretched farm configuration, which is a quite convenient architecture, at least on the high availability point of view ; the servers in the different DC can be used all the time and not only in case of disaster discovery –> this is less expensive (in term of servers & SharePoint license) than having 2 farms (1 in each DC).
But let’s put it like this : our customers love the stretched farm.
The problem is the requirement for the stretched farm is very strong.
Initially when SharePoint 2013 shipped (in January 2013), the stretched farm architecture was not supported anymore.
Then in May 2013 Microsoft changed his mind and started supporting stretched farm, but with very strong requirements :
in the Technet we can read this
“For a stretched farm architecture to work as a supported high-availability solution, the following prerequisites must be met:
There is a highly consistent intra-farm latency of <1ms one way, 99.9% of the time over a period of ten minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and the database servers.)
The bandwidth speed must be at least 1 gigabit per second.”
If you want to check it on your farm, use the great script developed by Eric Strachan (Microsoft).
Problem number 1 : not realistic
This is almost impossible to achieve, specially in a virtualized environments, believe me I’ve checked it with several customers; ok in labs we can, but rarely in the real world; the REAL WORLD, I really mean it : this means PRODUCTION environments and CUSTOMERS.
I’m even not sure that SharePoint farms in Office 365 meet this requirements…
Problem number 2 : and within the same DC ?
We don’t really understand this : why is this important when we have 2 Data centers ? what matters is the latency between ANY web server and the SQL servers, right ? so why is it now required in the stretched farm scenario (between 2 DC) and not within the same DC ? latency is latency…
Does that mean that single Data center SharePoint 2013 farms that don’t meet the latency requirements are not supported ?
Does this means that if we don’t meet the latency requirement, moving to a 2 farms architecture (1 in each DC) won’t solve our problem because the requirement is the same within the same DC… ???
Problem number 3 : OWA
There is something else : the Technet Documentation clearly specifies that OWA is not supported in stretched mode :
Stick to one data center. Servers in an Office Web Apps Server farm must be in the same data center. Don’t distribute them geographically. Generally you need only one farm, unless you have security needs that require an isolated network that has its own Office Web Apps Server farm
Sooo ? As far as I know, if you don’t meet this requirement, you’ll need several farms in several Data centers (this is more expensive) and you will have to rely on some synchronizations mechanism like log shipping, mirroring or our favorite technology : SQL Server Always On Availability groups which will make your Database Administrator ‘s life more confortable (we have many databases to synchronize in SharePoint 2013, so move then to the same availability group and synch the group as a whole).
Here is the lab that my partner Isabelle Van Campenhoudt and I successfully completed last year. We still have to test it in Azure, but last year Azure didn’t support the availability group listeners, now it does.
And to be honest I like the Sharepoint 2013 documentation that specifies (for Always On Availability groups) : “Replicas can be on different subnets as long as latency does not cause performance issues.”
So my (customer’s) message to Microsoft is : please clarify the situation and update the Technet documentation. SharePoint 2013 is a great product, we love it and some of our customers are not yet ready for Office 365. (But the way, my customers want a better SLA than what Office 365 provides, which is pretty much ok for most customers, believe me).
Message to my customers :
- NO, sharePoint is NOT dead, but its future is in the cloud : Office 365
- Microsoft will provide new versions of SharePoint On Premise.
- Office 365 is a nice product that you will use eventually (and yes your policy will change).