1 / 31

Example Topologies

Example Topologies. Single Server All components installed on one server. Small Farm Components scaled to two tiers (at least two servers) with either a dedicated front-end Web server or dedicated database. Medium Farm

abby
Télécharger la présentation

Example Topologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Example Topologies • Single Server • All components installed on one server. • Small Farm • Components scaled to two tiers (at least two servers) with either a dedicated front-end Web server or dedicated database. • Medium Farm • Components scaled to all three tiers with multiple front-end Web servers or search servers. • Large Farm • Scales the Windows SharePoint Services databases across multiple dedicated servers.

  2. Single Web Server Choose which type of database for single server installation • WMSDE • Installed by Windows SharePoint Services setup • Does not require additional server licenses • Performance is improved over MSDE • Can be migrated to SQL Server. • SQL Server • Required for all scale-out operations • Performance can be slightly lower than WMSDE if Windows SharePoint Services search features are enabled.

  3. Small Web Farm Use Small Farm when your capacity outgrows single server or you want capacity of separate SQL Server. • Scale for Page Rendering • Add additional Front-End Web Servers • Install Search on one of the WFEs • Use this when performance is more important than data redundancy • Building in Data Redundancy • Add a second SQL Server for clustering • Use this when you are satisfied with performance of your WFEs and want to add data redundancy

  4. Small Web Farm Use Small Farm when your capacity outgrows single server or you want capacity of separate SQL Server. • Scale for Page Rendering • Add additional Front-End Web Servers • Install Search on one of the WFEs • Use this when performance is more important than data redundancy

  5. Small Web Farm Use Small Farm when your capacity outgrows single server or you want capacity of separate SQL Server. • Scale for Page Rendering • Add additional Front-End Web Servers • Install Search on one of the WFEs • Use this when performance is more important than data redundancy • Building in Data Redundancy • Add a second SQL Server for clustering • Use this when you are satisfied with performance of your WFEs and want to add data redundancy

  6. Medium FarmBase • This topology represents a good overall balance of server components for general use. • From this topology, you can easily scale to meet increasing user demands or to accommodate larger volumes of data.

  7. Medium FarmScaling for Growing Numbers of Users • This topology represents a good overall balance of server components for general use. • Add additional front-end Web servers to accommodate a larger number of users and to increase page rendering

  8. Medium FarmMaximizing Performance and Availability • This topology represents a good overall balance of server components for general use. • Add additional front-end Web servers to accommodate a larger number of users and to increase page rendering • This topology is optimized for a large number of search queries. Search servers are dedicated to individual content databases. This topology works well when the database is accessed primarily for read-only transactions.

  9. Large FarmBase • The base large farm topology adds multiple dedicated SQL Server computers, in addition to multiple front-end Web servers. Scale to or use this topology as a starting point when you need to accommodate a large volume of data relative to your user load.

  10. Large FarmHighly Scaled • This topology works well for both: • Large number of users. • Large volume of data. • The farm is served by a single search server. Monitor the performance of the search server to ensure that it does not become a bottleneck before you are able to scale out.

  11. Large FarmPartition Content and Increase Search Performance • To increase search performance or limit access to content, add additional search severs and assign each to a dedicated database.

  12. Large FarmOptimizing for both large numbers of users and large volumes of data • Continue to add front-end Web servers and dedicated search servers to accommodate increasing demands of a farm.

  13. Upgrade and Migration Options

  14. Understand Upgrade Options In-Place Upgrade Updates existing databases and servers Easiest approach, environment offline while it runs Gradual Upgrade: Upgrade Site Collections Granular control: one to many site collections at a time Run old & new versions side-by-side; rollback to v2/SPS03 supported More complex & resource intensive Content DB Migration: Upgrade Into Separate Farm Attach v2/SPS03 content db to v3/MOSS07 farm & upgrade runs v2/SPS03 stays available and untouched by upgrade Content only, requires new farm, has many manual steps

  15. Before UpgradeHandling FrontPage Customizations Important consideration: keep customizations or move to v3/MOSS07 Custom pages kept by default during upgrade v2/SPS03 Themes are not preserved Be aware: customized pages do not match rest of site “Reset to Site Definition” Returns page to layout in site definition Option exists to reset all pages during upgrade Gets users to clean v3/MOSS07 environment sooner Available in site settings or within SharePoint Designer Works for any page edited in SharePoint Designer / FP

  16. Maintaining Customizations Example Pre-upgrade Upgraded

  17. Maintaining Customizations Example • Does not match rest of site • Lacks new features: • Navigation • Site actions menu • Security trimmed UI • Recycle bin • Etc…

  18. Before UpgradeCustom Site Definitions Existing sites based on custom v2/SPS03 site definitions should work in v3/MOSS07 v3/MOSS07 site definition needed to create new sites Upgrade your custom site definitions Create new v3/MOSS07 site definition Craft upgrade mapping – v2/SPS03 to v3/MOSS07 site definition Deploy mapping file & v3/MOSS07 site definition to v3/MOSS07 install directory, and run upgrade Can be done post-upgrade using command line

  19. Before UpgradeCustom Web Parts Most will work post-upgrade Must re-build custom parts if you used ASP.Net 1.1 “obfuscation” tools Must re-deploy web parts if Moving to a new server farm (content DB migration) Web part in the Bin & not upgrading in-place

  20. In-Place Upgrade Steps Follow pre-upgrade steps Run setup and choose upgrade Install language packs if needed Upgrade one web server Review log files & resolve any issues Issues should be rare, upgrade docs will have recommended workarounds for common issues Logs in: program files\common files\microsoft shared\web server extensions\12\logs After completion on first server, repeat setup & upgrade on each server in the farm Review results Reset pages to (v3/MOSS07) site definition versions

  21. Gradual UpgradeURL Redirects • Upgrade moves v2/SPS03 virtual server to new URL domain • v3/MOSS07 takes over original URL domain • Redirect is created for all sites to new v2/SPS03 location • As site is upgraded, redirect is dropped • Browse access to original URL always works • New URL domain is needed until upgrade is complete

  22. Gradual Upgrade StepsCreate v3/MOSS07 Infrastructure On existing hardware Run standard pre-upgrade steps Prepare secondary domain for each web app Run setup, choose Gradual Upgrade on 1 Web Server Creates v3 Central Admin site, Config DB Performs local-server upgrade actions Run setup & gradual on all other farm servers Upgrades all sever-local data Review log files

  23. Gradual Upgrade StepsUpgrade v2/SPS03 “virtual server” Provide domain v2/SPS03 will use during upgrade Recommendation: Automatically create databases May be manually configured if necessary Need one v3/MOSS07 content db for each v2/SPS03 content db, plus one temporary db per SQL server. Need extra 30-50% additional SQL disk space Redirect created for all sites at this time v2/SPS03 IIS site reconfigured to use new domain or port v3/MOSS07 web application created using the original domain Choose SSP for web application Re-deploy any web parts located in the v2/SPS03 bin

  24. Gradual Upgrade StepsUpgrade Content Choose if resetting files to template version Can change selection with each group of sites upgraded Select first group of sites to upgrade Must include the root site of the domain in first group Note storage (number of MB) to be upgraded During upgrade, redirect to v2/SPS03 URL is removed V3/O2 site is now live Automatic - no admin action needed Review log files after each upgrade group Tip: Upgrade duration is in logs. Number of MB / duration is good approximation for subsequent upgrade durations Repeat steps 1-3 for all sites Command line available to automate

  25. Gradual Upgrade StepsRevert to v2 When upgrade result is undesirable, “revert” deletes v3& resets redirect to v2 Confirm v2 site still exists before reverting to it Make copy of v3 using stsadm Export / Import commands Revert to v2 via UI or command line UI: Select Sites for Upgrade > Revert Site Command line: stsadm –o upgrade –revert Additional considerations for Portal/MySites Fix copy of v3 using SharePoint Designer Once complete, re-upgrade original Use SharePoint designer to merge changes from “fixed”& re-upgraded versions

  26. Content DB Migration Steps Perform standard pre-upgrade steps Create new v3/MOSS07 farm on clean hardware Configure farm-level settings Create a new web application for each v2/SPS03 virtual server Manually re-apply customizations Deploy all custom site definitions Deploy custom web parts to GAC or BIN

  27. Content DB Migration Steps Back up v2/SPS03 content database using SQL Restore backup to copy in v3 farm Add content db to web application via GUI or command line Ensure root site is included in first database UI: Application Management > Manage Content Databases > Add Content Database Command line is stsadm –o addcontentdb Upgrade triggers automatically, runs until it completes For large databases, command line preferable Review log files for any issues Repeat for all content and search/user profile databases

  28. Content DB Migration Steps Other Considerations Set v2/SPS03 content DBs to read-only Avoids manual merging of updates post-upgrade Note: Users will see warnings when DB is read-only Internally used ISA Server to re-map URLs As content db upgraded, remapped URLs to v3 farm Work-intensive – redirects all added manually

  29. Common Upgrade Challenges Pre-scan cannot update locked or over-quota sites or database orphans Impact of redirects Office client applications Gradual upgrade hardware & disk requirements Database sizes Application pools & accounts V2 and v3 central admin account should be the same Create new v3 app pools: ASP.Net 1.1 & 2.0 conflict Avoiding content updates during upgrade

  30. Summary And Tradeoffs

More Related