February 1, 2012 at 3:22 pm
The team that I am on is in the middle of building a solution for Project Server 2010. We are getting some push back from different angles on a few different points that are being considered. I am looking for some feedback from someone who has had some hands on with Project Server 2010 with the SQL Server in a VMWare environment.
Anyone have any experience in this configuration that might be able to take a few minutes to give me some opinions that are related to this sort of configuration?
Thanks,
Chris
February 1, 2012 at 6:33 pm
This response was quickly typed and might have errors in it. Oh, and I should add the usual disclaimer ... your mileage may vary.
I can only speak to the DBA role.
Our all-virtual configuration on a new-ish VMWare Enterprise multi-server host was implemented as specified by an MS Gold Partner that our internal client fired a few months after they had hired them on MS's recommendation. Our client's new MS Gold Partner consultants, upon arriving and seeing the performance of the configuration, refused to do any work on it until the DB was moved to a physical server (2008R2 64-bit for both Windows and SS, same as the virtual was). They described the difference in performance as "amazing". From what I could see when I worked on the DB server with a local copy of SSMS, they were right.
The same thing happened with Visual Studio TFS 2010 and this time the consultant was the guy who wrote the MS book on TFS - someone you would expect would support MS's visible push to virtualization. Even the DBS for the test environments for MOPS and TFS had to be moved to dedicated physical boxes, and they do not have much traffic.
NOTE: We run a "tight" VMWare configuration and try to let the built-in software manage it auto-magically, so your experience might be different.
You can use standard edition, but enterprise edition is needed for features like Excel PowerPivot and to keep indexes on-line while defragmenting them. We went with SE, but will are looking at switching to EE because of those differences.
Put a clamp in the sharepoint site and don't loosen it. Our client was not under our control, so they had their own sharepoint administrator, who, as an individual, decided to let a nearby engineering team use the MOPS server's sharepoint site. Two weeks later, that other team opened a request for a terabyte of space ... "for starters". :w00t: They were preparing to upload hundreds of maps the next week, and then twice as many again over the coming year, in four bursts or maybe in a steady stream - they would decide that later. :crazy:
We had just finished a capacity plan for that server, but they had not been invitied to the table for those plans because we did not know they using the server. Our SAN admin must have gone ballistic because this was the fourth short-term request for a terabyte that day - and none of it was on the 3-month-old annual capacity plan. I joked that we needed another MOPS server to manage the never-ending SAN expansion project. I then wondered whether any of those requestors mentioned they were moving documents, not creating new ones, and thus would be freeing up an equivalent amount of space on file share servers's LUNs once as the migration progressed.
We did not install teh SQL Server Remote Blob Service because we were not expecting many (or huge) documents on the MOPS sites. That was a mistake. There are times when the activity on the underlying sharepoint sites really slows SQL Server down and MOPS users sometimes really feel the hit. (RBS lets blobs be streamed by the OS, which lightens the load on SS). If you are going to put any sizeable amount of documents/versions into the Sharepoint site, get RBS installed - and proven - before you release the MOPS server to the users (you need the Sharepoint 2010 RBS package, not the SS 2008R2 one)
Unless MS Project is already heavily used, avoid being drawn in by grand plans. Companies used to using spreadsheets and documents and various other PM tools might not actually make much use of MOPS. We had a grand plan, but a year later, our client is considering switching to Primavera because it is more widely used in their industry and because MOPS was not being user very much. (and because their counterparts at other companies liked to sneer at MS Project and call it a toy. They might be wrong, but they are influencing our clients and they may end paying for a MOPS infrastructure that is only used by a few small projects).
:hehe:
February 2, 2012 at 12:35 am
😀
I have no experiance at this field but show this link may help you man
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply