Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Caveats of migrating from medium to large farm architecture??

  Asked By: Johnpaul    Date: Nov 16    Category: Sharepoint    Views: 834

I have been warned that there are some 'sticky points' with migrating
a medium sps farm to a large one. From all the documentation, I don't
see any major caveats. Does anyone have an insights or items to watch
out for? (i.e. if I am deploying a new medium farm that I know will
need to scale to a large farm in time...)

Share: 

 

3 Answers Found

 
Answer #1    Answered By: Deonte Stein     Answered On: Nov 16

I almost think a bigger consideration before going from a medium  to large  Farm is how to manage your SITE Db(s). One Portal can have multiple SITE Dbs.

Go to Central Admin, WSS, Configure virtual server settings, Default Web Site, Manage content databases…

You can set a maximum number of Sites per Site DB. If you don’t want additional Sites in a Site DB, you can set the warning/max to 1 (if you currently have 100 Sites and set the max to 100, and a Site is later deleted, the current will go down to 99 and the next time  you create a Site, it might be created in that Site Db). If you have 2 SITE databases available for growth, SPS will create new Sites in a round robin fashion.

BTW, this is great to know incase you get a corrupt Site Db – we are dealing with that now, it’s working, but it ain’t quite right. We’re planning an outage to export all Sites from our current Site db, then we’ll set the warning/max to 1, create a new Site Db, import all the Sites… once all of the Sites are migrated to the new SITE db, we’ll delete the old (corrupted) SITE Db.

Database Name

Database Status

Current Number of Sites

Site Level Warning

Maximum Number of Sites

TestRecr1_SITE2

Ready

82

999

1000

TestRecr1_SITE3

Ready

10

1

1

TestRecr1_SITE

Ready

83

999

1000

 
Answer #2    Answered By: Stephon Valentine     Answered On: Nov 16

Can you give me more details of what you are running into? or any
suggestions/best practices you have? This is for a very early pilot
that will have 3k users eventually.

 
Answer #3    Answered By: Leif Cardenas     Answered On: Nov 16

Sure. The ITG at Microsoft recommended a SITE database no larger than 50Gb – they lock down a SITE database for new top level Sites once it gets to 30Gb (stop allowing new top level Sites to be created in that SITE database), because the existing Sites in that SITE database will continue to grow. FWIW, I’ve read documentation  on the Web where MS recommends SITE databases no larger than 25Gb, so YMMV.

Once you start looking at medium/large sps  Farms, you’re probably getting to the point where your SITE database is getting rather large.

We went to a large  Farm for redundancy and performance; now that we’ve dealt with the server farm  size, we’ve started to have to deal with the size of our SITE database. We have ~200 top level Sites (800 webs) using ~32Gb of space. We expect our Sites to continue to grow until our SITE Database is larger than 50Gb. So *before* we get to 50Gb (and to resolve a database integrity problem), we’ve decided to migrate our Sites into a few different SITE databases. Basically, five smaller SITES databases instead of one large one.

This is new to us, so we don’t feel like we have a ‘best practices’ method for doing this yet, but here’s how we plan to do it for now until we learn of a better way.

SPS Central Admin > SPS > Configure virtual server settings > Default Web Site > Manage content databases

You should see your current SITE database and be able to create new ones. If you click on your existing SITE database, you can change settings, such as the status (Ready/Offline), max number of Sites, warn, etc. If you set the maximum number of Sites to be LESS than the current number of Sites in that SITE database, SPS will not allow you to create additional top level Sites in that SITE database. If you create additional SITE databases, your new Sites will be created round-robin in your SITE databases (first top level Site you create will go into the first SITE database, the second Site in the second SITE database, repeat).

We’re planning on creating ~5 SITE databases and then migrating  our existing 200 top level Sites into those 5 SITE databases based up department. For instance, we’ll move all of our existing “training” Sites into the “training” SITE database. Once we’ve migrated all of the training Sites into the Training SITE database, we’ll set the max to 1, that way SPS will not create additional Sites in that database. We can then migrate the next departments Sites into the next departments SITES database (this is necessary, because as far as we can tell, STSADM does not allow you to specify which SITE database you want to –restore the Site into).

We’re going to leave the original SITE database open for new Sites, then occasionally migrate the Sites to a specific SITE database – to keep any one SITE database from getting too large.

Managing multiple SITE databases has additional benefits, like allocating a SITE database for more risky custom code development, or different SOX levels, etc.

 




Tagged: