A few months ago I was designing a MOSS 2007 infrastructure for a client who had originally intended to implement a SharePoint Portal Server 2003 solution, but based on their heavy reliance on forms and workflow discovered during Envisioning interviews, decided to take the plunge and use Microsoft Office SharePoint Server 2007 instead. The product was in the Beta 1 stage at the time and their system was scheduled for implementation sometime around the Beta 2 TR timeframe. One of the big decisions to make was the server farm topology, but there was very little guidance from Microsoft at that time and no real-world experience with the product to inform my design.
MOSS 2007 isn’t an entirely new software product, however. Despite all the new features and the major cleanup work Microsoft did on the code base, it was still SharePoint and the basic operating principles could be taken as an invariant. We would therefore need multiple front-end web servers to provide redundancy in rendering and search and we would need multiple back-end database servers to provide redundancy in data services. Indexing wasn’t required to be redundant because if the crawler goes offline for a while, it doesn’t interfere with user requests being serviced – it just means the indexes won’t be refreshed until the crawler comes back online. After arriving at a preliminary server farm topology with 2 NLB WFEs, 1 index server, and 2 MCS SQL 2005 database servers, I found preliminary server farm topology diagrams from Microsoft that validated my design.
The database redundancy issue was interesting. A typical configuration is to use Microsoft Clustering Services to provide hot database failover and this continued to be Microsoft’s recommendation for data layer redundancy in MOSS 2007 and WSS v3 server farms. However, there is a new feature in SQL Server 2005 called database mirroring, very similar to transaction log shipping in SQL Server 2000, where transactions are shipped from a primary machine (referred to as the Principle) to a secondary machine (referred to as the Mirror). Database mirroring can be configured to be synchronous, where transactions on the principle are not committed until the mirror confirms it has received the transactions, or asynchronous, where the principle does not hold transactions pending confirmation by the mirror. If a third SQL Server, referred to as a Witness, is present, failure of the principle can result in automatic failover to the mirror, which then becomes the new principle, while the old principle is now the mirror. When the new mirror machine comes back online, it “catches up” on all the processing that happened on the new principle while the mirror was down. Database mirroring was disabled in the original release of SQL Server 2005 and had to be explicitly enabled; database mirroring is fully supported and turned on by default in SQL Server 2005 SP1.
It occurred to me that SQL Server 2005 database mirroring operating in synchronous mode with a witness could be perfectly serviceable data layer redundancy option instead of SQL Server clustering, but I could find no references to this actually being done with MOSS 2007. A couple advantages of using mirroring would be the ability to replicate data over a WAN, the need not to use hardware fulfilling the stringent requirements of Microsoft Clustering Service, faster hot failover, and a SAN not being necessary. Eliminating the SAN and the hardware meeting stringent clustering service requirements means a redundant database solution could be had for less money. But again, there was no guidance whatsoever from Microsoft on this, so I ended up going the safe route and recommending clustering in my design.
In May 2006 I attended the SharePoint Conference 2006 in Bellevue, Washington, and had the opportunity to attend some very interesting lectures and demonstrations on all aspects of MOSS 2007. I made a point to attend a number of infrastructure-centric sessions, where issues of redundancy were discussed. During lectures no mention was made of database mirroring as a potential data redundancy option, but after one of the presentations I got the opportunity to speak to Arjun Ohri, WSS Program Director at Microsoft. I posed my question about database mirroring as a potential option besides clustering and he explained that the product team is very interested in this as another redundancy option for customers and was actively working with it in their lab. He said advice on how to leverage it and best practices would be forthcoming on the use of the SQL Server 2005 feature in MOSS 2007 and WSS v3 installations.
