1. Architecting the Network for SharePoint 20102007
Presented by
Michael Koyfman
Solution Architect

2. Q110 Gartner ADC Market Share
F5 Continues to be #1 in the WW Application Delivery Controller Market for Q110
Q110 Gartner ADC Market Share
Q110 ADC* Market Share Leaders
F5 : 44.2%
Cisco: 22.4%
Citrix: 10.6%
Q110 ADC Market Share Revenue Leaders
F5: $126.4 Million
Cisco: $64 Million
Citrix: $30.4 Million
Q110 ADC Q/Q Revenue Growth
F5: 12.5%
Cisco: -8.6%
Citrix: -15%
Q110 ADC Total Market Numbers
Revenue: $285.7 Million
Q/Q Revenue Growth: 1%
*Application Delivery Controller (ADC) Segment Includes: Server Load Balancing/Layers 4-7 Switching and Advanced (Integrated) Platforms
Citrix
10.6%
Radware
8.8%
Cisco
22.4%
Others
13.9%
F5 NETWORKS
44.2%
SOURCE: Gartner

3. F5 Dominates in Advanced Platform ADC Segment for Q110
Q110 Gartner Advanced Platform ADC Market Share
Q110 Advanced Platform ADC* Market Share Leaders
F5: 61%
Citrix: %
Radware: 10.5%
Q110 Advanced Platform ADC Market Share Revenue Leaders
F5: $126.4 Million
Citrix: $30.4 Million
Radware: $21.7 Million
Q110 Advanced Platform ADC Q/Q Revenue Growth
F5: %
Citrix: -15%
Radware: 2.4%
Q110 Advanced Platform ADC Total Market Numbers
Revenue: $207.1 Million
Q/Q Revenue Growth: 4.3%
*Advanced Platform Segment Includes: ADCs that integrate several functions (typically more than four) on a single platform (for example, load balancing, TCP, connection management, SSL offload, compression and caching)
Radware
10.5%
Others
13.8%
Citrix
15.7%
F5 NETWORKS
61%
SOURCE: Gartner

4. Leadership Position
Magic Quadrant for Application Delivery Controllers, 2009
F5 Networks - Strengths
F5 Networks has a broad and comprehensive vision with industry-leading understanding of the needs of application development, deployment and management.
The vendor has a comprehensive feature set with a full range of extensibility delivered through iRules and iControl, and integration with popular integrated development environments (IDEs), such as Eclipse and .NET/Visual Basic.
F5 has developed a very large community of committed users (using F5's DevCentral portal) that helps fuel the use of iRules to solve unique data center application challenges, creating a loyal and engaged user base.
F5 has a solid financial position and continued market-leading position.
SOURCE Link

5. The Leader in Application Delivery Networking
Users
Application
Delivery
Network
Datacenter
At Home
In the Office
On the Road
SAP
Microsoft
Oracle

6. Purpose: How can the Network be Leveraged to achieve:
Scalability
Building the Right Infrastructure to Meet the Current User Load, and Also Allow for Future Growth.
High Availability
Architecting the “Bullet Proof” SharePoint Deployment
Eradicating the Single Points of Failure
Performance
Building a SharePoint Deployment with the Best Possible End User Experience

7. Load Balancing Concepts
User Requests
The Typical Single Server Deployment
Users connect directly to the open IP:Port of the Server
No redundancy, little scalability
Single
Server

8. Load Balancing Concepts
Introduction of the Load Balancer
Hardware Device
Different models for capacity
Sits in front of the server farm, accepting the user connections, and then dispatching the connection to a chosen server.
Most modern LBs are multi-function
(caching, compression, rate shaping, firewalling, etc…)
Most LBs can load balance multiple types of traffic
User Requests
Farm of
Servers
Instead of a single server, a Load Balancer allows you to scale the number of available servers

9. Load Balancing Concepts
How it works:
A properly configured Load Balancer is constantly monitoring the health and availability of the servers in the farm. It will use this information to help it make a load balancing decision.
Instead of the User making the connection directly to the server, the User makes a connection to the Virtual Server, which resides on the external facing side of the Load Balancer
The Load Balancer will send the connection to a specific server based upon
The LB algorithm selected
Health & Availability of the servers
User Requests
Farm of
Servers

10. Load Balancing Concepts
Load Balancing Methods:
Some are static
Round Robin
Ratio
Some are dynamic, and try to take certain network and server characteristics into account
Least Connections
Fastest Server
Trending
User Requests
Farm of
Servers
Historically, static methods were preferred, as they tended to have the lightest impact on the Load Balancer, however today’s Load Balancers are capable of handling even complex LB algorithms without any performance degradation. F5 recommends using a dynamic LB method with SharePoint.

11. Load Balancing Concepts
Persistence:
Once a user is sent to a specific server, do follow on connections/requests need to be sent to the same server?
Common Persistence Methods:
Source IP Based
Cookie Based
SSL ID
Custom Methods
User Requests
Farm of
Servers
Most SharePoint deployments do not require persistence, however since a SharePoint front end can build an object cache, there is benefit to enabling it. It’s recommended to use a combination of Cookie & Source IP based persistence.

12. Load Balancing Concepts
Leveraging a Load Balancer to Eliminate the Single Points of Failure
Redundant Load Balancers
Instant failover
Share state
Redundant & Meshed Switch Architecture
No single path out to the next hop
Spanning Tree support
Multihomed Networks
Multiple ISP links into the Data Center
Multiple Data Centers
“Global” load balancing
User Requests
Farm of
Servers
Is it possible to eliminate all the Single Points of Failure?
Is ‘5 9s of uptime’ achievable? Realistic?

13. What Else Can My Load Balancer Do?
*Differs by vendor, but most include technologies to alleviate server load, accelerate traffic, and minimize bandwidth utilization.
User Requests
SSL termination
Compression
Content Spooling
TCP multiplexing
TCP optimizations
Browser optimizations
Rate shaping
Intelligent Browser Referencing (caching at the browser)
Results from using these features with SharePoint 2007 can be found here
Farm of
Servers

14. Real-World Performance
350 Million Page Hits in 1 Week
1/3 Reduction in Servers
1/3 Reduction in Licenses
1/3 Reduction in Management Time
114.8
Million 5
95% Fewer Connections
1.87
Terabyte
621
Gigabytes
66%
Reduction in
Bandwidth 3
Seconds 1
200% Faster
End-to-End
Page Load
Time 14

15. On to SharePoint………

16. The Single SharePoint Server Deployment
User Requests
No Redundancy
Complete failure with any piece
No Scalability
Measurable maximum capacity
50 to 75 Requests per second max
Performance Concerns
Early performance degradation
Single Server:
Web Server
Application Server
Database
No Direct Upgrade from a stand alone to a farm
MSFT – SSD is good for evaluation, deployments with minimal number of sites and you want to minimize overhead
Microsoft on the Single Server Deployment
Good for evaluation
Good for very small deployments
Benefit of minimal overhead

17. Scaling Out The Deployment
“The Small Server Farm”
Common initial deployment
Database split from Front End Servers
Meets requirements for HA
Allows for future scalability
175 to 250 RPS Maximum
Front End Servers are responsible for
Servicing web requests
Application Services, such as
Searching
Indexing
User Requests
Each Server Running
Web Server
Application Roles
Clustered or Mirrored
SQL Database
Source :

18. Scaling Out The Deployment
“The Medium Server Farm”
Same as the Small Server Farm, however the Application Server has been split from the Web Servers
175 to 250 RPS Maximum
Allows the Application Server’s CPU intensive functionality (search, excel services, etc) to have dedicated CPU cycles
User Requests
Web Servers
Application Server
Clustered or Mirrored
SQL Database
Source:

19. Scaling Out The Deployment
“The Large Server Farm”
All Servers, including Web, Application, and DB are scaled to meet demand
Can scale to support “Hundreds of thousands of users”
Availability Work Sheet from Microsoft
User Requests
Web Servers
Load Balancing of Application Servers is also possible
Application Servers
Clustered or Mirrored
SQL Database
Source:

20. Scalability – The Art of Sizing
The Challenge is to size the deployment appropriately
How many servers are needed?
How are the server roles split?
What type of hardware should be used?
The 2 Sided Sizing Dilemma
Microsoft can’t give precise sizing guidelines
Customers can’t precisely profile their user base
Fortunately, the amount of accurate and reliable sizing information is dramatically increasing

21. Scaling the Network vs. Scaling the Servers
What needs to be considered when sizing? Is scaling a server infrastructure linear with scaling the network?
Considerations for server sizing include
How many total users?
How many concurrent users on average?
Typical behavior of users? Posting, searching…. Etc.
How many page views per person?
How many users at peak times?
How many sites are planned?
What hardware architecture is being used?
Considerations for network sizing include
What are the peak new connections per second?
What is the peak number of users/connections?
What is the peak bandwidth being consumed?
How many servers is the Load Balancer responsible for monitoring?
What else will the Load Balancer be doing? Caching, Compression……etc

22. BIG-IP Hardware Line-up
2 x Hex core CPU
16 10/100/ x 10 SFP+ 10Gbps
2x 320 GB HD (S/W RAID) + 8GB CF
32 GB memory
100K TPS / 15Gb bulk
12 Gbps max software compression
40 Gbps Traffic
BIG-IP 8950
BIG-IP 8900
2 x Quad core CPU
16 10/100/ x 1GB SFP + 2x 10Gb SFP+
2x 320 GB HD (S/W RAID) + 8GB CF ?
16 GB memory
56K TPS / 9.6Gb bulk
8 Gbps max software compression
20 Gbps Traffic
BIG-IP 6900
2 x Quad core CPU
16 10/100/ x 1Gb SFP + 2x 10Gb SFP+
2x 320 GB HD (S/W RAID) + 8GB CF
16 GB memory
58K TPS / 9.6Gb bulk
8 Gbps max hardware compression
12 Gbps Traffic
BIG-IP 3900
2 x Dual core CPU
16 10/100/ x 1Gb SFP
2x 320 GB HD (S/W RAID) + 8GB CF
8 GB memory
25K TPS / 4 Gb bulk
5 Gbps max hardware compression
6 Gbps Traffic
Quad core CPU
8 10/100/ x 1Gb SFP
1x 300 GB HD + 8GB CF
8 GB memory
15K TPS / 3.8 Gb bulk
3.8 Gbps max software compression
4 Gbps Traffic
BIG-IP 3600
Dual core CPU
8 10/100/ x 1Gb SFP
1x 160 GB HD + 8GB CF
4 GB memory
10K TPS / 2 Gb bulk
1 Gbps max software compression
2 Gbps Traffic
BIG-IP 1600
Dual core CPU
4 10/100/ x 1Gb SFP
1x 160GB HD
4 GB memory 5K TPS / 1 Gb Bulk
1 Gbps max software compression
1 Gbps Traffic

23. Sizing – Rough Guidelines
A single server deployment can handle between 50 to 75 RPS.
When scaling out Web Front Ends, assume each one can handle roughly 100 RPS. Assume 85 RPS if Query Search is running on the WFE.
According to Microsoft, use the following to determine how many RPS a user will make
Light user, access every 180 secs (20/hr), 1 RPS = 180 active users
Typical user, access every 100 secs (36/hr), 1 RPS = 100 active users
Heavy user, access every 60 secs (60/hr), 1 RPS = 60 active users
Extreme user, access every 30 secs (120/hr), 1 RPS = 30 active users
References:

24. Sizing Resources Microsoft SharePoint 2007 Development
Hoffman, Foster. Sams Publishing
Part I dives into some sizing exercises
Microsoft Office SharePoint Server 2007 Administrator’s Companion
Bill English. Microsoft Press.
Chapters 2 & 3 discusses sizing in detail
Microsoft Technet
Good information with sizing worksheets
Microsoft SharePoint Products and Technologies Team Blog
Joel Oleson & Mike Watson’s Blog Entries – MS IT Case Study

25. Sizing Resources
HP Sizing and Configuration Tool for Microsoft Office SharePoint Server 2007
Plug in various information about user base, and it returns a full suggested hardware package
One of the most comprehensive sizing guides out there.

26. Sizing Guidelines
Sizing the SQL cluster for Performance and Availability
Is there a strategy to maintaining a certain maximum size to a specific SP database? Should I create separate DB’s or SQL instances for different SP sites?
There is a strategy for SP DB implementation, but it has more to do with making administration (i.e. backups & restores) easier than performance.
Database Clustering
High Availability and Scalability of SQL back end is achieved via SQL clustering technology.
No Load Balancer needed.
For replication, both data mirroring and log shipping is supported.

27. Sizing Guidelines
Sizing the SQL cluster for Performance and Availability
As a guideline, what is the recommended number of Web Front Ends to SQL servers?
Best Practices
HA Minimum of 2
Authenticated Traffic “4:1”*
Anonymous Traffic “6:1”*
Suggested Limit “8:1”**
Database Clustering
High Availability and Scalability of SQL back end is achieved via SQL clustering technology.
No Load Balancer needed.
For replication, both data mirroring and log shipping is supported.
*Source
**Source

28. Sizing vs. Performance Docs
2 Great Resources that compare how sizing affects performance
Microsoft Office SharePoint Server 2007 on HP ProLiant servers – performance summary
Discusses when to scale up vs. out (more cores vs. more servers)
Plan for performance and capacity (Office SharePoint Server)
Discusses acceptable performance limits

29. High Availability
Health Monitoring: How does the appliance determine if the servers are up/down?
Load Balancing: How does the appliance distribute traffic to the Front Ends?
Persistence: Can (and should) the appliance keep a user attached to the same Front End that they initially attached to?

30. Multiple Data Center Challenge
Client
Site 1
Site 2
Router
Router
BIG-IP LTM
BIG-IP LTM
SharePoint Farm SQL DB
SharePoint Farm SQL DB
Can I deploy SharePoint in Active/Active Redundant DataCenters?

31. Multiple DataCenter Challenge
Router
BIG-IP LTM
SharePoint Farm SQL DB
Site 1
Client
SharePoint Farm SQL DB
Site 2
Can SharePoint be deployed with Active/Active Redundant DataCenters?
Not in any way supported by Microsoft.
Reasoning: SQL replication engine (mirroring/log shipping) just isn’t ready to handle real time replication with concurrent SharePoint user access

32. Multiple Data Center Challenge
Strategies to replace the Active/Active Deployment
Active/Standby Data Centers
Splitting SharePoint Sites, using both Data Centers
Data Center Multihoming

33. Multiple Data Center Challenge
Router
BIG-IP LTM
SharePoint Farm
Site 1 (Active)
Client
SharePoint Farm SQL DB
Site 2 (Standby)
Solution 1: Active/Standby DataCenter
All users sent to DC1, unless it is no longer accessible.
Then all users will be sent to mirrored instanced in DC2
Good solution, the main drawback is the expense.

34. Multiple DataCenter Challenge
Client
Solution 2: Multiple SharePoint Sites
DC 1 (Active for Site A)
(Standby for Site B)
DC 2 (Active for site B)
(Standy for site A)
SharePoint split into multiple sites, each using different SQL instances
Site A uses Data Center 1 as its primary DC, and Data Center 2 as its backup
Router
Router
BIG-IP LTM
BIG-IP LTM
SharePoint Farm
SharePoint Farm SQL DB
Site A = humanresources.intranet.net
Site B = development.intranet.net
Multiple Benefits, including no ‘dark fiber’.

35. Multiple Data Center Challenge
Strategy 3: Multihoming the Data Center
Clustered or Mirrored
SQL Database
Application Server
Web Servers
ISP (Link) Load Balancing
Routing (BGP) Solution

36. Multihoming the Data Center BGP Solution
Use 2 or more separate ISPs to peer with each other, creating a single ‘virtual’ ISP link.
Benefits:
ISP Links share IP space, so DNS caching not an issue
Drawbacks:
Convergence time can be long.
Difficult to fully leverage all available bandwidth
Web Servers
Application Server
Clustered or Mirrored
SQL Database
Routing (BGP) Solution

37. Multiple Data Center Challenge
ISP Load Balancing
Multiple ISP links are used.
DNS used to direct users in via ISP1, ISP2, ISP3, etc..
Benefits:
Performance based usage of ISP links
Better Bandwidth Utilization
Drawbacks:
DNS caching
Web Servers
Application Server
Clustered or Mirrored
SQL Database
ISP (Link) Load Balancing

38. Performance
Problem: How Can The Content Be Delivered To The End User In The Most Efficient Way Possible?
Combination of Technologies

39. SSL Acceleration SSL/TLS Encrypted Clear Text HTTP
SSL Connections to a server can eat up as much as 30% of available CPU cycles.
SSL on NT/IIS means up to 37x fewer connections/second
SSL Acceleration Devices typically have specialized ASIC processors for terminating SSL.
SharePoint officially supports SSL offloading
SSL/TLS
Encrypted
Clear Text
HTTP
* Source: Networkshop Scaling eCommerce Infrastructure

40. Control Bandwidth Usage
The F5 Solution
Business Benefit
Control bandwidth usage and spending
Minimize impact on business-critical applications
Get more bandwidth from the same size pipe
Control traffic spikes
Rate Shaping + iRules - Bandwidth management to prioritize high-priority applications over P2P traffic and other low-priority applications
Packet Filtering - Selective filtering of P2P sites based on protocol, addresses, and/or ports
KaZaa &
Video Conferencing
Oracle
HTTP Traffic 4x 3x 2x 1x
Client
The Rate Shaping Module allows for per-application, per-protocol and per-user basis to help determine what’s actually on the network and how it is behaving and affecting other traffic. Based on this information, administrators can classify, queue, shape, and rate-control traffic with policies to ensure better application response time for priority traffic, by eliminating bandwidth congestion and competition for their priority applications.
The Rate Shaping module:
Ensures that critical applications are not impacted by non-priority traffic
Delivers optimal application performance by allocating more bandwidth for higher priority applications
Eliminates special purpose Rate Shaping products for simplified, centralized traffic management capabilities
Provides flexible bandwidth limits, bandwidth borrowing, and traffic queuing
Controls rate classes based on any traffic variable
Enables application bandwidth to be shared across similar priority applications for better resource sharing
Ensures that specific types of application traffic stay within authorized boundaries
At a high level, the Rate Shaping feature allows for traffic limiting, prioritization and borrowing, for maintaining enough bandwidth and fast service for high priority applications and traffic.
BIG-IP users can define traffic and application limits, control the rate at which those resources are allowed to spike or burst, provide queuing to prioritize traffic types, and define relationships where certain traffic types can borrow from other traffic types.
Control per application, per protocol, per user 40

41. Fast Cache Unmatched Flexibility Provides Superior Application Offloading
Intelligent memory based cache
Full support for static and dynamic content
Exclusive “Multi-Store” caching for prioritized application service
Superior caching of pre-compressed content
Most advanced cache controls - iRules 41

42. HP / F5 Joint SharePoint 2007 Best Practices & Deployment Guide
Joint performance testing to determine best practices for accelerating SharePoint 2007 & 2010
Over 100 separate tests ran & recorded, with varying network conditions, such as latency, packet loss, & bandwidth
Whitepaper (results) posted:

43. HP Results
Internet – asymmetric BIG-IP LTM with WebAccelerator solution
While not able to provide all the capabilities and benefits of a symmetric solution, results show that deploying a single BIG-IP LTM with WebAccelerator appliance in this scenario will have measurable benefits in terms of increased throughput and in providing users with an improved experience.
• Typical throughput improvements for the 6Mbps and 1536Kbps tests approached a factor of 2 (double the throughput). Again, it was not possible to emulate sufficient load for the 44Mbps tests to drive the accelerated WAN to capacity, but the trends are similar to the 6Mbps tests and the same degree of improvement should be expected.
• The hits-per-page ratio dropped from 3:1 (un-accelerated) to about 1.2:1 (accelerated) showing a good degree of protocol optimization.
• Average page (response) times showed improvements ranging from factors of between 3 and 5 (that is, some functions took one fifth of the time).
• Client LAN traffic was reduced to 75% of the un-accelerated cases.
• A good level of compression was achieved, but note that the users’ browsers are used to un-compress the data and need to be set to do so.

44. Branch Office Scenario Results
Average time for a Document Open decreased 12x
Average time for a Page Open decreased by over 6x

45. Internet Scenario Results
Average Page Open Time decreased by over 60%
Average Search Time decreased by over 40%

46. Questions to ask ANY vendor
Give me your SharePoint Story
What testing have you done with SharePoint?
What SharePoint specific development efforts have you undertaken?

47. Questions to ask ANY vendor
How do you determine server availability and health?
What’s the recommended method of distributing traffic?
What methods does the appliance have for persisting users?

48. F5 Resources F5 SharePoint 2010 Deployment Guide
HP F5 SharePoint Acceleration Doc
F5 Microsoft Business Development Team
Jeff Bellamy–Business Development Director for the Microsoft Partnership – –
Ryan Korock – Senior Solutions Architect – –
James Hendergart – Business Development Manager – –
Helen Johnson – Solutions Engineer – –