keeping sharepoint always on

Antonio Maio Protiviti, Senior SharePoint Architect & Senior Manager Microsoft SharePoint Server MVP

Keeping SharePoint Always On

Email: [email protected] Blog: www.trustsharepoint.com Slide share: http://www.slideshare.net/AntonioMaio2 Twitter: @AntonioMaio2

© 2014 Protiviti Consulting Private Ltd. An Equal Opportunity Employer.

About Protiviti

INDIA (3)

Protiviti (www.protiviti.com) is a global consulting firm that helps companies solve problems in finance, technology, operations, governance, risk and internal audit. Through our network of more than 70 offices in over 20 countries, we have served more than 35 percent of FORTUNE® 1000 and Global 500 companies. We also work with smaller, growing companies, including those looking to go public, as well as with government agencies.

Protiviti is a wholly owned subsidiary of Robert Half International Inc. (NYSE: RHI). Founded in 1948, Robert Half International is a member of the S&P 500 index.

• 3,200+ professionals

• 1,000+ clients

• 70+ offices

• Over 20 countries in the Americas, Europe and Asia-Pacific

Protiviti is one of the fastest growing consulting firms worldwide. Our revenues have increased from US $15 million in 2002, to US $423.8 million in 2011.


Goal

Educate on Building a SharePoint Environment to Optimize Performance and

Resilience


Agenda

• Baseline

– Front End, Back End, Network, Bandwidth, User Access

– Time to 1st Byte

• Infrastructure Considerations

– System Architecture

– Topology

– SQL Server

• High Availability

• Disaster Recovery


Baseline Architecture: Front End

• Memory: 50-60% Utilization (Memory/Available Bytes Counter)

• CPU Usage: 30-50% Average Usage

• Disk I/O: Disk Queue Length (Differs Per Environment)

• Concurrent Connections: Depends on user base, 150-250 per server

– Larger total number of users

– Dependent on what users are doing (public site vs intranet very different)


Baseline Architecture: Back End

• Memory: 30-60% Utilization (Memory/Available Bytes Counter)

• CPU Usage: 30-50% Average Usage

• Disk I/O: Disk Queue Length = Physical Disk(_Total)/Current Disk

Queue Length Counter

• Concurrent Connections / SQL Blocking: SQL Server: Locks

(_Total)\Number of Deadlocks/sec counter

– Acceptable: < 1 per second

• Fragmentation: < 8% per server

• Traffic: Realistic Number of Page Hits

– MS IT caters to 6 million hits per day


Baseline Architecture: Data Center

• Cross Data Center Farm • High Bandwidth

• Fiber Optic Connection

– >= 1 gigabit per second bandwidth

– <1 millisecond one-way ping response

• Load Balanced End User Requests

• Single Data Center Farm • High Network Speed: Gigabit Speeds Ideal

• <= 1 millisecond response between all servers

• Load Balance End User Requests


Baseline Architecture: Network • Use Case:

• Server: Receive and Process initial Request

• Server: Request and Transfer

• Client: Response rendered

• Bandwidth: Amount of data that can be sent through the wire

• Latency: Time taken to travel from source to destination


#Users # Concurrent Users Local Network Access WAN/Remote Access

100 – 5000 10 – 500 Bandwidth: = 3Mbps Latency: < 100 ms

Bandwidth: = 1.5Mbps Latency: < 100 ms

10,000 1,000 Bandwidth: >3Mbps Latency: <250 ms

Bandwidth: >1.5Mbps Latency: <250 ms

100,000 10,000 Bandwidth: > 3Mbps Latency: < 250 ms

Bandwidth: > 1.5Mbps Latency: < 250 ms

Baseline Architecture: User Access

• Bandwidth Table

1.5 MB data per second < 100 ms latency


Baseline Architecture: Network User Access

• Test Ping Access

- Ping each of the server in the “server list” to ensure that all servers are reachable

- Connect to the SQL server to verify DB connectivity

- Run a 10 minute ping test against each to ensure that the environment meets the <1 ms latency requirement

- Generate output to show the percentage of pings that complete in 5 ms, 4 ms, 3 ms, 2 ms and 1 ms respectively

• Test Network Latency – http://blogs.msdn.com/b/erica/archive/2013/11/11/sharepoint-2013-network-latency-test-script.aspx

http://blogs.msdn.com/b/erica/archive/2013/11/11/sharepoint-2013-network-latency-test-script.aspx












Baseline Architecture: Time to 1st Byte

• See TechNet: http://technet.microsoft.com/en-

us/library/cc964305.aspx

• $siteUrls = @( “http://sharepoint.com”,

“http://my.sharepoint.com”)

• $siteUrls | Ping-Url

http://technet.microsoft.com/en-us/library/cc964305.aspx



http://sharepoint.com/

http://my.sharepoint.com/


Infrastructure: Server Specifications

Size Matters!


Infrastructure: Server Specifications

Small Farm

• RAM: => 8 GB

• Processor: 64-bit, => 4 cores

• Hard Disk Space

• 80 GB (system drive)

• Other disk space as needed

Medium Farm

• RAM: => 16 GB


• Hard Disk Space



Large Farm

• RAM:

• Up to 2 TB Data = 32 GB

• Between 2 TB and 5 TB = 64 GB

• > 5 TB = 64 GB or higher


• Hard Disk Space




Infrastructure: SQL Server

• Cluster

– Expensive, Complex (Single Node), Shared Storage, Fiber / SCSI

• Mirroring

– Isolated Storage, Single Mirrors, Not Grouped and needs Snapshots

• Log Shipping

– Complex, Database unusable until recovery state and logs applied /

updated

• Always On Availability Groups

– Multiple Copies of Databases, Isolated Storage, Off Server Backup,

Readable Secondary's and Grouped Databases


Infrastructure: Topology



One Server Farm Two Tier farm



Four Server Farm



Six Server Farm



Six Server Farm

Load Balancer



Large Farm

Web servers for all incoming requests Dedicated web server(s) for crawling and administration

Query and index servers All other search components Servers for running sandboxed codeAll other services (use these servers for the Central Admin site)

Content databases and configuration database

All other SharePoint databasesSearch databases



Hybrid Farm

Load Balancer



Always On – Availability Group

On-PremiseCOLO

10.10.1.106/24 10.10.1.107/24 192.168.1.103/24

192.168.1.102/24

192.168.1.101/24

192.168.1.100/24

10.10.1.103/24 10.10.1.104/24

10.10.1.101/24 10.10.1.102/24

10.10.1.100/24

10.10.1.254/24 192.168.1.254/24

192.168.1.120/24

10.10.1.120/24

VIP Address


High Availability & Disaster Recovery


High Availability & Disaster Recovery

• Goal of a high availability - to minimize or mitigate downtime

• High Availability measured by end user’s experience and expectations

• Business impact of downtime – Measured in the cost of information loss, property damage, decreased productivity,

opportunity costs, or contractual damages

– Availability = Actual uptime/Expected uptime X 100%


A Disaster Recovery strategy must be based on metrics, defined by determining the risks and

downtime cost to the business if a disaster occurs, metrics such as:

Recovery Time Objective (RTO) The duration of an outage. Initial goal is to get the system back online in (at least) a read-only state to allow for investigation of the failure. The ultimate goal is to restore full service of the system or application.

1

Recovery Point Objective (RPO) A measurement of the amount of data which the organization is prepared to lose in the event of an outage.

2

3 Recovery Level Objective (RLO) The granularity with which data must be recoverable. If the recovery objective requires the entire farm, web application, site collection, site, list/library, item or version.

Disaster Recovery


Determining downtime costs is a key to identifying the metrics needed to meet the business goals

related to disaster recovery, and the strategy and systems required to achieve those metrics.

Downtime costs can be calculated by identifying the major aspects of an outage.

• Root Cause Analysis of Downtime

• Types of Loss Expected by the Business

• Impacts and Related Business Factors

• Direct and Indirect Causes

• Appropriate Response Activities

Determining Downtime Costs


Selecting a standby data center is a critical decision in developing a Disaster Recovery strategy. Its

required when local redundant systems and backups cannot be used to recover an outage at a primary

data center.

Cold Standby A secondary data center providing availability within hours or days.

Warm Standby A secondary data center providing availability within minutes or hours.

Hot Standby A secondary data center providing availability within seconds or minutes.

Selecting a Standby Data Center Best Practices


Baseline Architecture: Thoughts • Front End

– Run IIS version 7.0+ on 64-bit servers

– Use a front-end and back-end NIC configuration for IIS

– Load balance client traffic

– Use IIS compression for static content

– Enable caching (BLOB cache)

• Back End

– Limit database size to enhance manageability

– Allocate storage for versioning and the recycle bin

– Manage large lists for performance

– Separate and prioritize data among disks and create disk groups for specific

data


Final Thoughts • Establish a baseline for performance comparison

• Make data-driven decisions

• Simplify topologies

• Periodically standardize environment configuration

• Plan strategy for High Availability and Disaster Recovery

• Routinely verify and audit system configuration

– Use different teams or individuals for auditing

• Monitor all aspects of the environment

– System Center /

http://gallery.technet.microsoft.com/scriptcenter/2d537e5c-

b5d4-42ca-a23e-2cbce636f58d/

http://gallery.technet.microsoft.com/scriptcenter/2d537e5c-b5d4-42ca-a23e-2cbce636f58d/











• 7th Annual Conference • 6 SharePoint MVPs presenting • Full-Day Training Workshops pre and post conference • Separate tracks for Business Users, Technical Users & UX Professionals • Government, Association, Nonprofit & Group Discounts Available

Get 15% off! Use: PRO15 when registering

Learn More & Register at SharePointConference.org

Dallas, TX October 20, 2014

Antonio Maio Protiviti, Senior SharePoint Architect & Senior Manager Microsoft SharePoint Server MVP

Thank You!

Email: [email protected] Blog: www.trustsharepoint.com Slide share: http://www.slideshare.net/AntonioMaio2 Twitter: @AntonioMaio2

keeping sharepoint always on

Software