Keeping SharePoint Always On

Antonio Maio
Protiviti, Senior SharePoint Architect & Senior Manager
Microsoft SharePoint Server MVP
Keeping SharePoint Always On
Email: Antonio.maio@protiviti.com
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

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

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/

• 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: Antonio.maio@protiviti.com
Blog: www.trustsharepoint.com
Slide share: http://www.slideshare.net/AntonioMaio2
Twitter: @AntonioMaio2

Keeping SharePoint Always On

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a Keeping SharePoint Always On

Semelhante a Keeping SharePoint Always On (20)

Mais de AntonioMaio2

Mais de AntonioMaio2 (20)

Último

Último (20)

Keeping SharePoint Always On