Filed under: Digital Era, SharePoint 2010, Social Computing
One of the significant improvements in SharePoint 2010 is in the Social Computing section. Whilst I don’t want to contradict myself with my post on SharePoint 2010 and the Lost Generation I do believe that there have been some significant improvements over SharePoint 2007. At the end of the day what we have in SharePoint 2010 is what we have. If I think social computing then my SharePoint expert would be Dan McPherson who owns Zevenseas, a SharePoint consultancy in Holland. I heard him speak last year and have since started to look at ways we can link up with SharePoint for educational use. Last week he was talking with his team at Microsoft SharePoint Connections 2010 and their presentation has become available online. Take a look at what SharePoint 2010 can do for your organisation. If you are short on time you could miss the intro to social computing and start at 17 minutes on the video.
Click here to go to the SharePoint 2010 Social Computing Overview video.
To finish off our series on virtualisation Robin Meure has provided his defence of his SharePoint 2010 solution. Robin justifies his build as follows:
Personally I have had some bad experiences with virtualised DC’s so there’s my reason to have a physical DC. The reason why I choose for two WFE’s which could be load balanced is that in most scenarios this is sufficient, especially if you have some proper load balancers in place. Then two application servers because SP2010 has a lot of Service Applications. It makes sense for me to have dedicated servers for those meaning that the WFE’s really just are for the web requests and nothing else. The DB cluster with an active/active configuration is both for making sure it’s a) fast and b) failover safe.
I hope you have enjoyed this series. If you would like to suggest an alternative architecture design please send it to me firstname.lastname@example.org
In defence of project Pearce
Finishing off today with SharePoint MVP Alex Pearce explaining the reason for his deployment architecture.
The SharePoint 2010 application servers are important – they do a lot more now than they have ever. From the old Shared Service Provider in SharePoint 2007, 2010 has given you the opportunities to spread your infrastructure. Scaling up to scale out is important, have your 3 level done from the start even if its only 1 Web Front End, 1 Application Server and 1 SQL Server. As the services are used more and more you can spread the services to multiple application servers.
Baring this in mind, there are 2 application servers in this infrastructure, but why already? One of the first application add-ons for SharePoint 2010 is the Office Web Apps, this should be separate from the start with all the multiple services such as the metadata and user profile service kept on the first application server with the search and indexing, this is why the first application is a physical server.
The SQL Server should only be a virtual machine should the speed of the iSCSI and IO rate of the SAN be past excellent. Remember this if you are looking at deploying a system like this.
Pearce architecture design
Vote for your preferred architecture below:
In defense of project Coleman
Earlier in the day I received Dave Coleman’s argument for running with his virtualised SharePoint 2010 solution. This is Dave’s argument:
My rationale for the physical servers in my deployment are that I would never totally trust a VHD to run all the domain controllers and global catalogue servers. If for instance you had a major problem with the SAN this would stop all services running in your domain.
As the SAN is the biggest single point of failure if you lose the SAN storage then you lose it all! As for the TMG server this is more debatable but I think the firewall should be separate from the rest of the domain and preferably on a physical server as there is also potential for failure. Here I think I would also P2V the TMG server and have it ready but turned off as a VHD.
Coleman architecture design
Vote for your preferred architecture below:
Following on from efforts by Chris Mckinley, Dave Coleman and Alex Pearce we have a fourth option in our virtualisation debate. Robin Meure of Zevenseas fame tweeted me this morning with some thoughts and I managed to persuade him to throw his hat into the ring. His tweet simply said ‘from personal experience, Id recommend DB cluster (active/active), one physical DC. Robin’s architecture diagram is here for your to peruse:
Bearing in Mind Robin Meure is joining the debate late please place your vote below.
In defence of project Mckinley
Following on from the design architecture Chris Mckinley, Dave Coleman and Alex Pearce kindly created I have asked them each to put together a brief defence of their plans. This is intended really to flesh out their rationale and Chris Mckinley has submitted his first so it appears below.
The argument for going fully virtual is based around the whole architecture being designed for hosting SharePoint sites. There is no requirement for a domain to be available for people to get to. If SharePoint is down then as far as the end user is concerned everything is down. With adequate vhd backups then all of the servers can just be copied to another iSCSI (or any storage device). In the case of physical hardware failure your downtime is just the length of time to install at least one Hyperv server. Thats it, just one OS. Fire up your vhds, you have your domain and SharePoint (which to the end user is all they want). Second hyperv nodes can then be added to the cluster at a leisurely rate to regain performance and fault tolerance.
With multiple physical servers you suddenly have much more work to do before your SharePoint (the end users universe) can be up and running. It’s also cheaper and better for the environment
Mckinley architecture deisgn
As a side note, please note that both Dave and I have set up our camps and are sitting quite firmly in them. This is purely for the purpose of creating an interesting collaborative debate across the community. Not because we are stubborn and cannot see the downsides of both our plans!
Please vote on your preffered architecture below: