Benefits and Risk involved in having multiple web applications in SharePoint 2010
Answers:
--
Here are some points to consider if you are adding additional web applications to your SharePoint Farm:
1. IIS setup and configuration is required for the new web application. Additional setup is required if the Web Application needs to load balanced behind a hardware load-balancer like F5 BIG IP. These changes can include VIP setup on the Load balancer for the new web application Host IP address and DNS configuration.
2. You would need separate content databases for the new web app. These content databases would need to be added into your Farm's SharePoint database backup processes.
3. Deployment of custom or third-party solutions is much easier in a single web app versus repeating the process across multiple web apps.
4. Security is easier to manage for a single web application rather than multiple web applications.
5. Additional Enterprise search configuration is required for the new web application.
--
Multiple web applications provide you a number of benefits. 1) You can have a different URL for the sections you wish to differentiate, intranet.company.com and teams.company.com. 2) You can provide different authentication methods to the content you are accessing. 3) You can apply different policy to the content you are accessing. 4) And the big one, by separating into different web applications you are isolating your content such that if something causes the web application to crash, you don't lose access to everything, just that one web application.
To address the other points raised - new applications are automatically added to the default content source for search, and as such are automatically part of your crawl. no extra configuration needed.
Additional content databases are recommended if you are going to be working with a large amount of data, whether it be attached to one web application or several.
Security is managed at the Site Collection level, not the web application level.
Yes, you are correct in that you want to keep the size of your content databases below 200GB, mostly for recovery reasons. You need to plan your Site Collections accordingly because you cannot span a Site Collection across multiple databases.
--
Look at http://technet.microsoft.com/en-us/library/cc263199.aspx; there is a diagram for Corporate Portal with Classic Authentication ... where a number of web app urls are listed.
--
In your case I don't think creating multiple webapplication is a good idea, simply think that each webapp will have a different URL, but I think companywide you better follow the same topmost URL.
I think for different department, it's a good idea to create different sitecollection, so the url will be like mycompany.com\HR, mycompany.com\Finance etc.
It's better to create separate content DB for each site collection, this will help you to implement a better archival policy in future.
Having said that, there is no easy way to supply different content DB for different site collections, cause you can only add content DB in the webapp level.
But there is a trick there. Say you are creating two different site collection as 'HR' and 'Finance', try to follow below steps
1> before creating these site collection, attach two content DB in the web application, say HR_WSS_Content_DB and Fianance_WSS_Content_DB
2> Now, other that HR_WSS_Content_DB, make all other content databases as offline in the central admin.
3> Create ‘HR’ sitecollection, as HR_WSS_Content_DB is the only active DB, the site collection will be created inside it.
4> Now take HR_WSS_Content_DB offline and make Fianance_ WSS_Content_DB online
5< Create Finance site collection, it will be created within Fianance_ WSS_Content_DB
This way you can segregate content DBs for site collection and this is one time job only
--
Microsoft recommended limit is 200GB per content Database
--
Since SharePoint 200 SP1 the limit has increased from 200gb to 4TB. Having said this no SQL admin would want to have to look after a database that large.
--
The big thing here is application pools. If you look at this link on software boundaries http://technet.microsoft.com/en-us/library/cc262787.aspx you are going to hit the best practice limit of 10 very quickly just having one web application due to the amount of service applications that are available within SharePoint 2010.
--
One thing not mentioned (only touched upon) is that SharePoint groups cannot be referenced across site collections or web apps so if your expecting to have groups of users with access across site collections and web apps then consider using AD groups for this purpose.And where licensing is concerned consider using an AD group for this. You can restrict the people picker to one or more AD groups thus restricting access to the chosen few with user CALS.
Kaynak:
Hiç yorum yok:
Yorum Gönder