This was one of those strange ones I came across recently. Should we be using Active/Passive, or should we go for an Active Active stack when deploying MOSS to a cluster? In reality, I should be talking about Nodes her, not active passive, but for you old timers out there I'll stick to that where its easiest.
Guess what, there is no easy answer to this one! There's a surprise - go ask a SAN engineer what they think and they'll likely say Active Active, gives you a scale out option! However, digging deeper into this you ask a MOSS architect (which I did - a few very credible MVP's in this field in fact) and the answer is "why would you want to do that then?", usually accompanied by "thats not really a good idea! - or don't you have much budget spare!"
I have recently chosen an Active/Passive SQL Cluster as the configuration of choice for some rather large farms, mainly because I've seen an awful lot of MOSS deployments done succesfully to this and you typically stick with what you know works well, primarily because I have yet to see CPU throughput on the cluster merit a different choice. But what about Active/Active. I now know of one large consulting company using a four Active/Active node to SAN for their own internal system, and MSFT allegedly have an A/A/A/P/P design for an internal instance, that must have took some planning, but two other very large consultancies (with large or massive farms) I know of have chosen Active/Passive and very common among small businesses is just virtualised large capacity Active alone.
Most architects I've spoken to appear to be defaulting to Active/Passive and I have not seen a single best practice paper or book that states either choice is the better choice, or MOSS works better this way or that. I do have some unresolved concerns for Active/Active however around MOSS in particular and the fact that Exchange historically was not recommended for deployment to Active Active sticks in my throat still! Certainly with Exchange 2003 performance, availability, and scalability reasons, Active/Passive cluster configurations were a better option than Active/Active configurations and Active/Active is dropped for 2007. Ok, thats a different product set, I'll give you that one! However, HP guidance on MOSS best practice doesn't appear to mention Active/Active anywhere.
http://h71019.www7.hp.com/ERC/downloads/4AA2-1456ENW.pdf
EMC virtual architecture testing was also carried out using Active/Passive, although the farm itself was spread across a Active/Active/Active virtual cluster in one test instance.
http://www.emc.com/collateral/hardware/technical-documentation/h4456-emc-vrtl-arch-ms-sharepoint-srvr-2007-ref-arch.pdf
This is not to say that either of these companies (both very credible in this space) would not choose to architect Active/Active in, its certainly do-able. As a side note, most of the storage vendors are doing geo-replicated database solutions that ae worth looking at.
Scale out should be a convincing argument and it should be a significant a factor in your choice, but what if your Active\Passive cluster is appropriately scaled to start with and you do not expect performance issues? Scale out then has no intrinsic value except perhaps to offer additional redundancy. Is the default choice then to stick with Active/Passive because you can switch in the future to Active/Active should you need to grow differently. Of course there is a cost to this switch, so the lesson is to make sure your calculations on RPS (Request Per Second) can be met by Active/Passive, or indeed by Active/Active. A big question is around planning, simply put the more nodes you add, the more complications you have in planning your DB placement, planning recovery and testing node failure. Its probably going to cost you more to put it in.
Also, what if your virtualising - once you start virtualising SQL clusters backed off to SAN, the active nodes then just become devices in memory anyway, so is using lower spec Active/Active devices and having a lot of them better than having a high spec Active/Passive option in memory? Again, this is a relatively subjective argument as moving images from failed hardware to an alternative stable device is not really rocket science and planning Active/Passive is easier than Active\Active.
For example: You have decide that your clever enoiugh to split out your sharepoint databases into various instances of the cluster, and you have two active nodes, each one an instance on a single SQL server. You were clever enough to rack both instances into the same rack and not put one in London and the other in Cape Town, and they are both on the same VLAN, not bridged across busy network segements.
Node instance 1 points to database file 1 on the SAN (Drive J) - and you have your configuration database here, and your SSP databases. Node instance 2 points to database file 2 on the SAN (Drive K) - and you have your site collection databases here. Along came your boss and said you had to make it redundent, and add in passive failure.
Failing either or both active Nodes to Node instance 3 means Node 3 will access both file 1 and 2 (Drive J and K), means you will now need to run 2 passive SQL instances on node 3, 1 for node 1 and 1 for node 2. Where you thought you had a good DB split, you don't have the rackspace for instance 3, so it goes on another rack to consider and any latency between those two racks in addition to latency between the inital two Active nodes of any inter database communication in MOSS, never mind SQL compound your planning. So, you now have to also work out how to run 2 instances of SQL server on that passive node and make sure that the server itself can cope with the load of both Active devices failing at the same time. To complicate matters, you now need to add in a new drive letter, because you have secure data that will reside in a secure site collection in MOSS and you need a new SSP which needs to load balance between Application Servers residing on, so you have to add a new active node which is racked on a different LAN segment. If only you'd stuck with a simple Active/Passive configuration. Of course thats not esseentially all correct and the scenario is totally fabricated, you could equally make a shambles of planning your MOSS DB's with any configuration of SQL if you don't give it some up front thought.
So, I'm not going to be able to state with certainty that Active/Passive is a better choice over Active/Active, but its the one I always tend to use as default for most implementations should I get the performance expectations from it on both the active and passive node instances, whihc should never be on the same piece of kit, even virtually. The only concern with Active/Active designs appears to be that they sacrifice performance to save money and when improperly designed, they may reduce availability due to complication. A poorly designed Active/Active SQL cluster in an MOSS farm under failure could see all the instances ending up on the same node, so any single node has to be scaled to cope with substantial traffice as it is. The added complication of which active node you place which MOSS databases, how your VLANs and firewalling might affect this and how these nodes access the Content DB, or how you gauge performance on cross site content lookups when you have more than one active node and databases split across them, or what the impact on the Index servers may be doesn't appear well documented. Seems there will be a lot of additional testing cost, and planning cost to choosing Active/Active and getting it working.
As to systems, well WIndows Enterprise Edition supports any number of nodes and is the only OS that supports clustering. That is true for WIndows 2000, 2003, and 2008. SQL Standard Edition 2005 and 2008 will install on two-node clusters only. SQL Enterprise Edition 2005 and 2008 will install on pretty much any number of nodes. Microsoft apparently stopped testing around 16 nodes for SQL 2005. If you are building a new cluster you should be going with the Windows 2008 Operating System and looking at SQL 2008.
It may be a while until I see myself passing the performance limits of a Active/Passive clusters to merit going for Active\Active as my default choice in the farms I'm planning. The lesson here is get a good storage or SAN engineer to assist with palnning, one that has expereicne of MOSS DB configurations. Hens Teeth spring to mind!