Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 21 docx

MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-67 2. In the E:\Labfiles\Lab03\Starter\ folder, read the information under Dataset in the Right-Sizing SharePoint Server 2010 Deployments section of the SPServer2010CapacitySizingOverview.docx file. f Task 2: Complete the Capacity worksheet in the Performance and Capacity Planning Worksheet.xlsx file • In the Performance and Capacity Planning Worksheet.xlsx file, in the Capacity worksheet, complete the details to establish the database storage requirements. MCT USE ONLY. STUDENT USE PROHIBITED 3-68 Designing a Microsoft® SharePoint® 2010 Infrastructure Module Review and Takeaways Review Questions 1. What are the two tools that you can use to measure the performance of a WFE server in a SharePoint test farm? 2. When you calculate content database size, you must estimate the number of stored documents. Should you estimate the number of versions of documents that you will keep? 3. What is the maximum recommended size for a content database? 4. What is the BLOB cache? 5. Is the SharePoint search index stored in a database? MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-69 Best Practices Related to Performance and Capacity Planning Supplement or modify the following best practices for your own work situations: • Understand your user requirements. • Establish your organization’s performance and capacity requirements. • Deploy a test farm for performance testing on similar hardware to your production environment. • Estimate the content database size through calculation or from existing storage requirements. • Limit database size to 200 GB. • Limit site collection size to 100 GB. • Plan storage for transaction logs. • Plan storage for service application databases. • Enable BLOB caching for digital assets. MCT USE ONLY. STUDENT USE PROHIBITED MCT USE ONLY. STUDENT USE PROHIBITED Designing a Physical Architecture 4-1 Module 4 Designing a Physical Architecture Contents: Lesson 1: Designing Physical Components for SharePoint Deployments 4-4 Lesson 2: Designing Supporting Components for SharePoint Deployments 4-20 Lesson 3: SharePoint Farm Topologies 4-27 Lesson 4: Mapping a Logical Architecture Design to a Physical Architecture Design 4-37 Lab: Designing a Physical Architecture 4-47 MCT USE ONLY. STUDENT USE PROHIBITED 4-2 Designing a Microsoft® SharePoint® 2010 Infrastructure Module Overview When you design a Microsoft® SharePoint® 2010 deployment, you must carefully consider the hardware and farm topology requirements. Your choices of server hardware and the number of servers that you specify for the farm can have a significant impact on how the farm meets user requirements, how users perceive the SharePoint solution, and how long before the farm requires additional hardware. This module describes the factors that you should consider when you design the physical architecture of a SharePoint 2010 deployment. The physical architecture refers to the server design, farm topology, and supporting elements—such as network infrastructure—for your deployment. This physical architecture underpins the operations of your SharePoint 2010 environment, so it is essential that your physical design fully meets the operational requirements. MCT USE ONLY. STUDENT USE PROHIBITED Designing a Physical Architecture 4-3 Objectives After completing this module, you will be able to: • Describe the physical design requirements for SharePoint 2010. • Describe the supporting requirements for a successful SharePoint 2010 physical design. • Identify SharePoint farm topologies. • Map a logical architecture design to a physical architecture design. MCT USE ONLY. STUDENT USE PROHIBITED 4-4 Designing a Microsoft® SharePoint® 2010 Infrastructure Lesson 1 Designing Physical Components for SharePoint Deployments Before committing to specific numbers of servers, you must understand the basic hardware and software requirements. In addition, you should also consider options such as server virtualization and disk storage choices because these choices will have a fundamental effect on management options and the planning of high availability. You should also note that there may be nonfunctional, or implicit, requirements that the organization expects from the SharePoint deployment. Identifying these nonfunctional requirements is an important step toward establishing the best design and gaining user adoption. Objectives After completing the lesson, you will be able to: • Identify minimum hardware requirements. • Identify software requirements. MCT USE ONLY. STUDENT USE PROHIBITED Designing a Physical Architecture 4-5 • Identify server virtualization options. • Identify storage choices. • Identify database configuration options. • Map functional and nonfunctional requirements to your design. MCT USE ONLY. STUDENT USE PROHIBITED 4-6 Designing a Microsoft® SharePoint® 2010 Infrastructure Hardware Requirements Key Points The following table shows the hardware requirements for Web Front End (WFE) servers, application servers, and single-server installations. Component Minimum requirement Processor (CPU) 64 bit, four cores. Memory (RAM) 4 gigabytes (GB) for developer or evaluation use. 8 GB for production use (single-server or multiple-server farm). Hard disk 80 GB for the system drive. In production use, you will require additional disk space for daily operations. You should maintain twice as much free disk space as RAM. In multiple-server farms, database servers should use the minimum requirements that are shown in the following table. . Review and Takeaways Review Questions 1. What are the two tools that you can use to measure the performance of a WFE server in a SharePoint test farm? 2. When you calculate content database. PROHIBITED 4-2 Designing a Microsoft SharePoint 2 010 Infrastructure Module Overview When you design a Microsoft SharePoint 2 010 deployment, you must carefully consider the hardware and farm topology. database size to 200 GB. • Limit site collection size to 10 0 GB. • Plan storage for transaction logs. • Plan storage for service application databases. • Enable BLOB caching for digital assets.