Best Practice SharePoint Architecture

  • Published on
    28-Nov-2014

  • View
    25.181

  • Download
    0

DESCRIPTION

Slide deck used at the India SharePoint User Groups in Pune, Chennai, and Bangalore, September 2009.

Transcript

  • 1. Best Practice SharePoint Farm Architecture
    Michael Noel
    Convergent Computing
    Twitter: @MichaelTNoel
  • 2. Farm Architecture
    Virtualised Farm Architecture
    High Availability Design
    Logical Architecture
    Hardware and Software
    SharePoint Installation
    Kerberos Authentication
    Session Agenda
  • 3. Farm Architecture
    Best Practice SharePoint Designs
  • 4. Farm ArchitectureAll-in-one Server
    All Roles and SQL on one server
    Often seen in small farms
    SQL contention with SharePoint
    Easy to deploy, but not best practice
    No ability for test environment
    NOTE: Do not use SQL Express in Production!
  • 5. Farm ArchitectureDedicated SQL Database Server
    Dedicated SQL Server
    All SharePoint roles on single box
    Less Disk IO
    Greater Performance
    Still no test environment
  • 6. Farm ArchitectureSmallest Highly Available Farm
    2 Web/Query/Application /Central Admin/Inbound Email Servers
    1 Dedicated Index Server (With Web role to allow it to crawl content)
    2 SQL Standard Edition Cluster Nodes (Active/Passive) Mirror also option
    Smallest highly available farm
  • 7. Farm ArchitectureScalability
    Scale up and Scale out
  • 8. Virtualised Farm Architecture
    Less Hardware, less cost
  • 9. Virtualised Farm ArchitectureEasy and Supported
    Microsoft Hyper-V (R2 recommended) or Vmware ESX supported (KB 897615)
    Great Windows Licensing Options (Ent = 4 licenses, Datacenter = unlimited)
    Allows for multiple farms, more servers
    Less cost, more failover options (Live Migration / Vmotion)
    Do not overcommit resources!
  • 10. Virtualised Farm ArchitectureCost Effective Farm / No HA
    • Allows organisations that wouldnt normally be able to have a test environment to run one
    • 11. Allows for separation of the database role onto a dedicated server
    • 12. Can be easily scaled out in the future