Global SharePoint Deployment Partner Solutions

I may have previously told you I was working on a "GEO" whitepaper.  One section that I signed up to work on was all the various partners in this space.  I know a lot of partners and took on the task.  I can't say this is perfect, so I ask any partners to include their information in the comments on the blog so I can be more comprehensive.  Note this is a tiny preview of what the paper itself will contain.  It will contain guidance on how to deploy SharePoint in a geographically distributed deployment.  It also includes metrics and charting with test data to show performance at varying bandwidths, latencies, etc...

Overcoming SharePoint WAN Challenges with Partners

WAN Accelerators

This category of WAN acceleration is a space that has existed for a long time.  There has been network equipment in this space for a long time.  Shortest path algorithms and compression for example has existed for decades.  The biggest innovations have happened in recent years as TCP/IP stacks are optimized and SMB is revisited.

Most WAN Accelerators work with the design of an device in the datacenter next to the SharePoint server or web server, with another device in the branch office.  The two devices use caching, compression, differencing, and proprietary methods to optimize the packets that are sent optimizing the network traffic.  Whether these are inline devices or simply network equipment with upgrades for cache the approach is similar.  You will find different devices focusing on different levels within the network stack.

We recommend you do your research as security requirements such as IP Sec or HTTPS may differentiate what you can use.  If you’re looking for a device that works to provide optimization for Exchange and File Share traffic this may influence your decision as well. 

Examples:

Cisco, Citrix, Packeteer, Certeon, F5, Riverbed

Offloading and Cache Devices

Where with the WAN Accelerators as devices in the enterprise, when your goal is to surface the information securely over the internet where bandwidth and latency are unknowns, and control over the branch office which could be an internet café in Cambodia, you need to do this with a device in the data center or a set of devices for failover or load balancing.  If you are hosting your site over the internet and looking to optimize your traffic and reduce the amount of requests that hit your servers then these partners were designed to help you.  Serving information as quickly as possible on slim devices or simple servers that act as devices that likely provide both load balancing or global distribution can be had for a price.  Researching what the big players in the internet space do for optimizing would give you an idea of what is possible.

Caching and related proprietary techniques, offloaded compression with varying algorithms, and warm ups and pre-fetching are strategies in this space.  Shopping cart techniques could also be employed here to improve the user experience.

Also in the internet arena there are global caching, network optimization routing techniques for reducing dropped packets and reducing latency are employed to ensure optimum experience.  Only the deltas would end up as requests to the server.  Caching techniques in SharePoint could obviously be used to reduce unnecessary backend traffic.  That’s really what these techniques are about is pushing the requests as far forward as possible to optimize the workload of the server as minimal.  Serving things out of RAM or extremely fast disks is what this is all about.  Intelligence at the speed of light, or such is the goal.

As with ISA, some provide offloaded or delegated authentication or a gateway for accessing information adding a layer of security.  This is definitely a benefit which provides a firewall, load balancing, plus some intelligence for offloading and caching.  Expect to see even more consolidation of these types of features in the future.

Examples: Cisco, F5, Inktomi, Microsoft’s ISA & IAG

Clients (Nearline, Offline and Online)

With all the optimization that takes place between the devices why can’t the optimization take place where the user can control it?  Ever seen the ads for the ISP selling that their browser add-ons will make browsing the internet 2-3X or even 15X faster?  These techniques are often about pre-fetching, background synchronization, compression, add blockers, and image filters.  If all you care about is text, browsing the internet can be much faster since the page request payload itself is small, it’s the images within it that make up often way more than 99%.

Centralized deployments of SharePoint have challenges with user experience.  If you can move the “slowness” to background processing then you’ve accomplished your goal of user experience.  If a user clicks to grab a document that has already been synchronized to their desktop it will be so much faster than fetching it over the wire.  If there are few sites that users use, and the documents themselves can be cached to the disk.  What’s on the client can easily be synchronized when online in the background transparently.  It still uses the WAN to copy and/or download the files so they are ready when the user needs them.  If they are needing to save the file up, they again save it locally and it is send back up to the server in the background.  The client software would then handle any conflicts and surface them so the user could manage the conflicts.  Some clients handle this experience better than others.  Some do it for just files, some do it for both lists and files.  You likely won’t find offline Wikis, but you can find RSS readers for consuming most lists locally or offline.  The Outlook 2007 experience is an example of a client that could allow you to consume your SharePoint blogs or lists offline by consuming the RSS with RSS reader such as Outlook 2007.  The synchronization of the SharePoint document library to Outlook could happen in the background, but the upload wouldn’t.  No caching or compression algorithms are used in the case of outlook, but Groove does have methods for taking SharePoint files offline and it’s peer to peer mechanisms could provide the files from another user on the LAN rather than from a remote location.  There is some user education and training that would be required to help users create the necessary connections to the lists and libraries they use to ensure they are taking advantage of the best experience for what they have.

Partners in this space have essentially focused on the user experience with the WAN and mobile and disconnected experiences in mind.  Caching (local copies), compression, and removing the synchronization to be a background experience can make it seem like you’re on the LAN with the server.  Training on top of this is something I recommend to ensure they are using the tools properly to take advantage of them.

Partners: Colligio, Microsoft: Outlook 2007, Groove 2007

Data Replication, Multi Master Synchronization, and Configuration Management

Whether it’s slow WAN links between two main offices or disaster recovery requirements with a multi master requirement, replication comes up in deployments.  For disaster recovery or site failover there are options in SQL 2005 for using log shipping or database mirroring, but when the requirement is 2 separate deployments that both need to be up, that both need to provide a read/write experience we have partners that provide solutions.

Some partners in this space also have a server cache similar to a WAN accelerator but with the idea of what if a WAN link goes down.  This branch office cache would then serve the users.  The branch office might be a ship at sea even.  When they doc for 6 months they can synchronize their data.

Some partners focus on providing an interface using the SharePoint UI to configure replication for a web application, a site collection, a list to then pair it up with another.

The publishing features in the product around content deployment were not designed to be used over the WAN, but more between two farms for authoring and production.  As a result this untested scenario, might provide some means of having an authoring environment publish to two read only environments, but without test we’re unable to provide any guidance on this scenario.

Partners: Syntergy, WinApp Technologies, Casahl, Infonic

Multi Farm Manageability and Reporting

In a global deployment such as a regional or branch office deployments, having multiple farms poses a challenge of managing settings across the thousands of sites across many farms.  Although this paper is focused on the partners with solutions around WAN, there are management tools designed for making permissions management, effective user rights, and settings and configuration easier.  If you decide that a centralized farm isn’t for you, but having multiple farms is the answer, then I recommend looking at the various management tools for making your job easier.

Some partners focus on helping you push out settings across farms and multiple environments.  The SharePoint Cross Site Configurator, a tool on codeplex.com designed by the solution accelerator team is designed to push out auditing, expiration, master pages, and content types for consistency across a web application.

Partners:  Quest Software, WinApp Technologies, Idevfactory, AvePoint , Corasworks,  Barracuda Tools

Byte level or Hardware Based Replication

When your goal is to eliminate the hardware as the potential for failure you might start with Microsoft Cluster Services.  MSCS provides hardware based fault tolerance.  If you have shared disk such as a SAN then that LUN or disk becomes that point of failure.  Hardware vendors have various methods for having redundant channels, redundant fiber, redundant disks, and various array configurations providing varying levels of fault tolerance.  Software based failover solutions such as SQL logshipping and SQL mirroring provide hardware fault tolerance, but neither of these in the case of SharePoint is automatic.  Partners in this space with hardware or byte level replication make it very easy to fail over and to synchronize environments between data centers.  Replication such as in the previous example gets you around hardware or software level failures, but going even lower level can provide solutions to the challenges that you face.

Byte level replication which in a sense creates a clone or mirror of the primary environment can create a secondary environment to fail over to.  This continuous byte level replication can provide a means for either automatic or manual failover.  I caution anyone purchasing solutions like this to understand that server names and web application names and accounts are hard coded in the configuration database.  This means any service that all of a sudden is on a different server with a different name would not work.  If the server name can remain the same with everything the previous server had, then you have something.

No matter what the solution, if it’s happening outside of the knowledge of the application, it needs to understand that the application does assume certain things.  It doesn’t store IP addresses, but even DNS or WINS resolves to an IP with some level of caching. 

Partners: Neverfail, Doubletake

There are other solutions built right into the hardware such as SAN Based Replication.

Partners: HP, EMC, Hitachi