Pages

Monday, July 6, 2009

Architecture Definition Guidance (Part I) [MOSS 2007]

As SharePoint Architect, often I have to deal with various MOSS 2007 installation and configuration scenarios for each of the clients I have consulted. Eventually I ended up with my quick cheat sheet. I ended up putting together two sets of information, one is more focused on Architecture Definition this post and then another one that is focused on Application Configuration focused (Part II). This is Part I of the series focused on Architecture. Most of the information I have collected and put together are from various Microsoft produced content. It was just easier for me to quickly look it up and have a very high level idea of the focused area.

In this post I have tried defining architecture for MOSS server implementations. This post covers the major technical approach topics and highlights the topics that need to be covered, and what kind of information needs to be collected, and reviews some of the known issues and workarounds.

1. MOSS Implementation Objective
  • Identify Objective of MOSS Implementation.
  • These objectives can be some or combination of the following:
    • Deployment Mode
      • Intranet
      • Extranet
      • Internet
    • Features
      • Web Content Management
      • Information Worker Collaboration.
      • Records Management.
      • Content Publishing
      • Workflows
    • Identify Content Types
      • Structure
      • Un Structured
    • Identify need for Governance and Manageability.
    • Identify Backup and Restore needs.
2. Environment Technical Requirements
2.1 Performance
  • Identify User Response Times requirement by using below table:

Response

Response Time

Response Characteristics

Slow

3-5 seconds

User response times can slow to this rate without issue

Recommended

1-2 seconds

The average user response time target

Fast

<1 second

For organizations whose businesses demand speed

  • Identify User Load based on below table:

User load

Request rate

Supported users

Light

20 requests per hour. An active user will generate a request every 180 seconds.

Each response per second of throughput supports 180 simultaneous users and 1,800 total users.

Typical

36 requests per hour. An active user will generate a request every 100 seconds.

Each response per second of throughput supports 100 simultaneous users and 1,000 total users.

Heavy

60 requests per hour. An active user will generate a request every 60 seconds.

Each response per second of throughput supports 60 simultaneous users and 600 total users.

Extreme

120 requests per hour. An active user will generate a request every 30 seconds.

Each response per second of throughput supports 30 simultaneous users and 300 total users.

  • Based on the user response time that most closely matches your client’s requirements; determine the throughput target based on the number of users.
  • Single-server deployment can capably serve up to 1,000 users, 500 users is the fewest listed.

Total users

Slow (RPS)

Recommended (RPS)

Fast (RPS)

500

.4

.5

.7

1,000

.7

1.0

1.2

5,000

4.0

5.0

6.0

10,000

9.0

10.0

12.0

20,000

18.0

20.0

24.0

50,000

40.0

50.0

60.0

100,000

90.0

100.0

120.0

  • You can estimate the performance of your starting-point topology by comparing your topology to the starting-point topologies.
  • The recommended starting point for most Windows SharePoint Services 3.0 deployments is at least two server computers:
    • Server 1: Front-end Web server and search server computer
    • Server 2: Dedicated SQL Server computer
  • Next determine if you need to scale your starting-point topology to meet your performance and capacity goals.
2.2 Availability

2.2.1 Uptime

  • To determine availability first determine the Uptime, and then choose the appropriate Server topology.
  • Uptime can be measured based on the following table.

Acceptable uptime percentage

Downtime per day

Downtime per month

Downtime per year

95

72.00 minutes

36 hours

18.26 days

99

14.40 minutes

7 hours

3.65 days

99.9

86.40 seconds

43 minutes

8.77 hours

99.99

8.64 seconds

4 minutes

52.60 minutes

99.999

0.86 seconds

26 seconds

5.26 minutes

2.2.2 Server Farm

  • To deploy a high-availability MOSS solution, you must deploy a server farm.
  • Comparing minimal Server Farm topologies:

#

Roles

Advantages

Disadvantages

Recommendation

3

Two Web Servers with Search on one server

One Dedicated SQL Server

Fewer Servers

Increases the overall performance of Web Server

Limited availability with no Database Redundancy

Use this topology when performance is more important than data redundancy.

3

One Web Server with Search server

Two SQL Server Clustered or Mirrored

Fewer Servers

Ensure availability of critical data

Limited availability with temporary loss of user access

Use this topology when availability of critical data is important than loss of user access.

4

Two Web Servers with Search on one server

Two SQL Servers Clustered or Mirrored

Ensures availability of both Web Servers and Data.

Need More servers

Use this topology when both performance and availability of critical data is important

5

Two Web Servers

One Search Server

Two SQL Servers Clustered or Mirrored

Optimizes the performance of the front-end Web server computers by offloading search to a dedicated server

More servers needed than the above server topologies

Most common highly available server farm topology

  • Use above chart to determine the most appropriate Farm Topology for your client.
2.2.3 Load Balancing
  • If Web server redundancy is required then plan for web server choosing Load Balancing technology.

Technology

How it works?

Advantages

Disadvantages

MS NLB

Runs on Web Servers by routing TCP/IP requests.

Free with Windows Server.

Handles up to 32 Nodes

Consumes fewer resources on Web Servers..

Hardware

Uses network to route traffic across web front-ends

Does not affect Web-Front End resources. Provide more than one port load balancing.

Expensive and can be complex to setup.

DNS Round-robin

DNS server round robins for each request among predefined DNS names by canonical order.

Use existing DNS server.

DNS server does not have any knowledge of Server availability.

This method is not recommended for MOSS.

  • When using MS-NLB be aware of the following:
    • When network card teaming is implemented, NLB may require special configurations.
    • When Virtual technology is used investigate for NLB compatibility.
  • When using Hardware load balancing be aware of the following:
    • SSL port load balancing
    • Load balancing multiple ports for the farm.
    • Note the number of VIPs that load balancer can support and plan accordingly.
  • While building your environments for Development, QA, UAT and Production, plan for considering Production equivalent load balancing in other environments to avoid the risk of Production only unique configuration.
2.2.4 Scale Out or Up
  • To support increased user load scale out your topology by adding more Front-end Web Servers.
  • For better performance maintain 1:8 ratios of DB Server to number of Front-End Web Servers.
  • To support increased data load scale up your database server.
  • Monitor following Performance counters to determine the need for scale out or up:

Performance Counter

Scope

Web Server

Database Server

% Processor Time

Total

% Memory Utilization

Application Pool

Identify correct application pool to monitor.

Identify peak memory usage, assign peak memory plush 10% to the application pool.

Total

2.2.5 Redundancy
  • Following server roles can be configured for redundancy
    • Query
    • Excel Calculation Services
    • Office Project Server 2007
  • Following server roles cannot be configured for redundancy
    • Index (Each server crawls different content)
    • WSS 3.0 Search
  • Windows SharePoint Services 3.0 search application role includes both the search and indexing components that cannot be divided.
    • Windows SharePoint Services 3.0 search is required to provide full text search of Help.
    • However if you are deploying MOSS-which is the most often case-using MOSS search should overcome this restriction.
  • MOSS Index and SSP relation:
    • The index role is associated with a Shared Services Provider (SSP).
    • The index role builds one index per SSP.
    • One index server can be associated with multiple SSPs.
    • However, indexes across SSPs cannot be combined.
    • You can deploy multiple index servers to improve capacity. In this case, each index server is associated with different SSPs.
    • If you are deploying a Office SharePoint Server 2007 farm, we recommend that you use the Office SharePoint Server 2007 query server and index server roles. This allows you to scale the query component out, achieving redundancy of the content indexes.

2.3 Performance Improvement
  • Consider implementing various caching mechanism support by MOSS. Refer below to choose appropriate chancing.

Caching Method

Scope

Notes

Output caching and cache profiles

Individual page level

Ideal for heavily accessed Web sites that do not need to present new content frequently.

Object caching

Individual Web Part control, field control, and content level

Includes cross-list query caching and navigation caching

Disk-based caching for Binary Large Objects (BLOBs)

Individual BLOB level and caches images, sound, movies, and code

Supports .gif, .jpg, .js, .css, and other image, sound, and code files that are stored as binary large objects

  • Consider using SharePoint test data load tool (WSSDW.exe ). This tool can help you to load test data based on an XML configuration file. The tool also supports to delete the test data from MOSS.

2.4 Capacity Planning
  • Consider following for storage requirements :
    • Database Server Disk Space requirements
    • Search Server Disk Space requirements.
    • Web Server Disk Space requirements.
  • Refer to below table for estimating disk space across your server Farm

Component

Size Estimate

Notes

Database Server

Web Server

Search Server

OS Files

4GB

Swap file

Same as RAM

SQL Install

425MB

Log Files

Based on # of DBs and settings

Config DB

< 1.5GB

Content DB(s)

All Content DBs size x 1.3

Consider the initial content and x1.3.

Consider additional space if version is enabled.

.Net 1.1

100MB

Consider if you have components that are .Net 1.1 frame work based and will not be migrated to .Net 2.0

(Optional)

.Net 2.0

230MB

.Net 3.0

60MB

Temporary ASP.NET Files

100MB

WSS 3.0

700MB

MOSS 2007

400MB

MOSS Logs

~50MB

WSS Logs

~50MB

If Usage Reports is enabled, by default the logs will be stored under this location. Consider more space if you are going to use the default space.

You can also specify other drive locations.

Content Index

All Content DBs size / 2

Free Space

25%

  • For future growth at least consider twice the size of initial content DBs.
  • Consider minimum of 25-30% free space for each disk volume.
2.5 Recommended Guide lines for MOSS objects

Object

Scope

Guideline

Site collections

Database

50,000

Web sites

Site collection

250,000

(sub) Web sites

Web site

2,000

Lists

Web site

2,000

Items

List

10 M

Documents

Doc Library

2 M

Documents

Folder

2,000

Document size

File

2 GB

Indexed Documents (MOSS)

SSP

50 M

Search Scopes (MOSS)

Site Collection

1,000

# Profiles (MOSS)

SSP

5 M

Metric

Preferred

IT Max

Cap Guideline

Site Collections /DB

250

5,000

50,000

Database Size/DB

25-50GB

100 GB

Databases/SQL Instance

100

300

Database Size/SQL Instance

2TB

3TB

Child Portals/Farm (Web Apps)

10

100

100

Full Portals/Farm (SSPs)

1

10

App Pools/Server

2-4

10

Worker Processes/Server

1 per 800MB RAM

1 per 500MB RAM

Site Collection Max Quota

5GB

50GB (DB)

File Upload Size

50MB

100MB

2GB

2.6 Backup/Restore

  • Backup Components:
    • SQL Server Databases.
    • Files and state from all the Farm Servers.
    • Files and directories include: IIS Metabase, Web,.config, Custom assemblies, Customizations such as Master pages, Styles sheets, Javascript, Themes, Site and List Definitions. Logs from IIS, Events and SharePoint.
    • Index files.
  • Backup tools and methods:
    • SQL Server 2005 native Backup and Restore, Database Mirroring or Log Shipping, VSS Writer.
    • Backup restore from SharePoint Central Administration
    • Site Collection Level backup and Restore using STSADM, SharePoint Designer
    • Migration API
    • Data Protection Manager
  • SharePoint Recycle Bin
  • Third Party tools
    • EMC Backup Manager for SharePoint
    • AvePoint
    • CommVault
    • NeverFail
    • Quest
3. Hardware Requirements

Component

Stand Alone/Web Server

Application Server

Processor

Dual processors that are each 3 GHz or faster

Dual processors that are each faster than 2.5 GHz

RAM

More than 2 GB

4 GB

Disk

NTFS file system–formatted partition with 3 GB of free space plus adequate free space for your Web sites

NTFS file system–formatted partition with 3 GB of free space plus adequate free space for your data storage requirements

Drive

DVD drive or the source copied to a local or network-accessible drive

DVD drive or the source copied to a local or network-accessible drive

Display

1024 × 768 or higher resolution monitor

1024 × 768 or higher resolution monitor

Network

· 56 Kbps or faster connection between client computers and server

· For connections between computers in your server farm, 1 gigabit per second (Gbps) connection

· 56 Kbps or faster connection between client computers and server

· For connections between computers in your server farm, 1 gigabit per second (Gbps) connection

4. Software Requirements

  • Office SharePoint Server 2007 (any editions)
  • Following Windows Server 2003 editions with SP1 or later:
  • Windows Server 2003, Standard Edition
  • Windows Server 2003, Enterprise Edition
  • Windows Server 2003, Datacenter Edition
  • Windows Server 2003, Web Edition
  • Database
  • SQL Server 2000 with SP3a or later or SQL Server 2005 with SP1 or later (any editions)
  • Some advanced features may require SQL Server 2005 Analysis Services SP1 or later.
  • Note that SQL Server full editions cannot be installed on Windows Server 2003, Web Edition

5. Licensing Requirements

  • Apart from Windows Server and SQL Server licenses, you need MOSS licenses as following:
    • For intranet hosting:
      • MOSS Server License per server in the Farm.
      • Client Access License as necessary for your client.
    • For internet hosting:
      • This install requires MOSS Internet licensing (MOSSFIS)
      • No Client Access Licensing is required.
    • Now both Server License and Internet License can be combined and installed under single deployment where client wants to use the same deployment as Intranet and Internet hosting.
6. Service Accounts
  • MOSS supports more granular set up of account for various services, application pools, search craw and so on.
  • You can also use single universal account to both install and configure every account aspect of MOSS install and configuration.
  • Below are the recommended individual accounts recommended.

For Production

For Stage

Example Account

Example Account

Account Permission

Purpose

MOSSAdmin

MOSSAdminStage

Domain User

Installation and configuration of the MOSS 2007 servers

MOSSSearch

MOSSSearchStage

Domain User

Search Service Account and Search Access

MOSSSSP

MOSSSSPStage

Domain User

SSP and App Pool Account

MOSSFarm

MOSSFarmStage

Domain User

Used to install and configure the MOSS 2007 Database

MOSSSQLSvc

MOSSSQLSvcStage

Local SQL Server account

SQL Server Service Account

7. Physical Architecture
  • When designing environments for MOSS deployment, along with Production environment consider implementing Development and Staging/QA/UAT Environments.
  • For the Development and Staging/QA/UAT environments consider Virtual technology.
  • Based on the Production environment, try to simulate as much possible in Staging environment, by matching the servers in the Farm and server topology, Load Balancing configurations, DNS, Security settings etc.
  • Consider recoding your hardware details in table format as below.

Server Name

IP

Role

Environment

Physical/Virtual

Proc

RAM

Space

Platform

Front-End

Dev

Physical

2GHz

4GB

C:20GB

D:100GB

x32

App

Stage

Virtual

2GHz

4GB

C:20GB

D:100GB

X64

SQL

UAT

2GHz

4GB

X64

  • For large deployments pre-calculate the storage requirements that may be required to support your Staging/QA environments.
  • Identify data file copy across network, SQL backup/restore time estimates.

8. Technical Issues and Constraints

  • Max List Items
    • Product team recommends that a single list should not have more than 2,000 items per list container.
    • You may be able to manage larger lists to some extent by using views within Office SharePoint Server 2007 that are filtered such that there are never more than 2,000 items returned.
    • The maximum number of items supported in a list with recursive folders is 5 million items
  • Search
    • Search in Windows SharePoint Services 3.0 is designed to work only with NTLM. More specifically, the index component in Search requires NTLM. Therefore, in order for Search to be used with any other authentication mechanism, there are certain workarounds that are needed.
    • Search on https is not support. But by building a custom HttpModule that replaces the https with http in the query string.
    • Also be aware that Search in Windows SharePoint Services does not work with FBA and custom authentication providers.
  • Windows NT 4.0 Domain
    • Office SharePoint Server 2007 requires Active Directory directory services for farm deployments. Therefore Office SharePoint Server 2007 cannot be installed in a farm on a Windows NT 4.0 domain
  • Not supported Server Topologies
    • If the query role is deployed to the same server that hosts the index role, the query role cannot be deployed to any other server computers. This is because the index role recognizes that the query role is on the same server and, consequently, does not attempt to propagate the index.
  • x64 bit Platform Considerations
    • .net 1.1 is not installed by default on x64 bit Windows. If you need to run components based on .net 1.1, then IIS needs to be switch to run in 32-bit mode.
    • So check for applications that may be depended on .net 1.
    • Check for availability of x64 bit iFilters for the customer document types.
    • You can mix and math x32 bit and x64 bit servers in a singe server farm.
  • Application Level Issues and Constraints:
    • Identify customer implementation specific Issues and constraints.
    • For a given feature identify current usage model if one exists.
    • Identify integration issues if integration with LOB apps, such as security, speed, impact of accessing.
    • Ask if consistence is important over flexibility for certain features.

(I will keep this updated as I find more relevant information….)

1 comment:

ChinaBabu said...

Hello:

Thanks a lot man.I am new to share point, I like your effort ....