Establishing Environmental Best Practices. Brendan Flamer.co.nz/spag/

Transcription

1 Establishing Environmental Best Practices Brendan Flamer.co.nz/spag/

2 Agenda Active Directory Service Accounts Database Platform Windows Platform Data Storage Planning Virtualisation Farm Topologies 2

3 Introduction The trick is finding the right balance between: Ease of Use Manageability vs Security Performance There are often many solutions to the same problem Not meant as prescriptive guidance, but these are examples of how I have got it to work Keen to hear about others experiences 3

4 ACTIVE DIRECTORY 4

5 Active Directory Corporate Intranet or Internal Only SharePoint Create Service Accounts in existing corporate domain Use a naming convention for easy identification Place accounts in Service Accounts OU Use strong passwords/password generator tool 5

6 Active Directory Internet Publishing or External Collaboration Consider setting up a separate DMZ Domain Results in increased security Adds to administrative overhead (slightly) Set up one way trust so that internal users can authenticate with their existing credentials DMZ domain trusts Internal domain 6

7 Service Accounts Administrator - Install Account Can be a domain admin, or in local administrators group on the box Setup can be run from your domain account Only used for the install and configuration of SharePoint SharePoint Service Account Requires DBCreator and SecurityAdmin roles on the SQL Server Should be a standard domain user, not an administrator This is the account you put into the Configuration Wizard Runs the Central Admin App Pool, and Farm Services Search Crawl Account This is the low privilege account used to crawl content on your web apps Needs no specific permissions, SharePoint will assign them for you Used for WSS Crawl and MOSS Crawl 7

8 Service Accounts Search Service Account Used to run the Search Services (not used to access content during crawls) Web Application Pool Accounts A separate account should be used for each SharePoint Web Application Central Admin Main Web Application At a minimum, the main content application pool credential should be different to the one running the Central Admin application pool Shared Service Provider Service Account Used for the SSP specific services SQL Service Account Shared Service Provider(s) My Sites (if separate) Used to run the MSSQLSERVER Service on your Database Server 8

9 DATABASE PLATFORM 9

10 Database Platform Awesome! New Dedicated SQL Server or Cluster 64 bit Plenty of RAM (8GB +) Physical Server Either 2005 or 2008 Fast RAID 5/10 disks or SAN attached DB Storage Maintenance Plans Well maintained Backups 10

11 Database Platform Good New SQL Instance, or underutilised shared SQL Server Preferably 64 bit (a must if you are planning to deploy 2010) Adequate RAM (4GB +) or more if Shared Physical or Virtual 2005 or 2008 Fast mirrored local disks Or, if virtual, SAN attached DB Storage Maintenance Plans Backups 11

12 Database Platform Bad Old or over utilised shared SQL server 32 bit Heavy page file utilisation due to inadequate RAM Old Physical server, or under resourced Virtual SQL 2000 or MSDE/SSEE Slow local disks, no redundancy No maintenance plans/not maintained No backups HUGE log files, drives running out of space No one takes responsibility for maintenance 12

13 WINDOWS PLATFORM 13

14 Patches and Service Packs Patch Windows! Make sure windows updates are running Test WSUS functionality Patch SQL Server SQL 2000 SP4 required for install Another good reason to have a dedicated SQL install Slipstream latest MOSS Service Pack SP2 patch has now been released Delete WSSSetup.dll from Updates directory 14

15 Partitioning SharePoint Servers System Partition C:\ Where the Windows, Program Files folders live 30GB+ Disk space usage can blow out during Service Pack installation Can be on a locally attached disk Data Partition D:\ Where everything else is, Logs, Indexes, Web Site Files Source/Install for storage of installed binaries Deployment folder for solution packages Should be on a SAN/RAID disk for performance 15

16 Partitioning Database Servers System Partition C:\ Where Windows, and SQL application files live 30GB+ Disk space usage can blow out during Service Pack installation Can be on a locally attached disk Data Partition D:\ Stores all the mdf files for SharePoint databases Ensure it is large enough to accommodate future growth Should be on SAN/RAID disk for redundancy 16

17 Partitioning Database Servers (continued) Logs Partition E:\ Stores all the ldf files for SharePoint databases Needs to be fast, put on SAN/RAID disk or dedicated spindle Backup Partition F:\ Stores backups from your SQL maintenance plans Optional, if you have a separate backup server/storage method Needs to be redundant, put on RAID or Mirrored Partition 17

18 DATA STORAGE PLANNING 18

19 Data Planning What is the SharePoint site going to be used for? Internet Publishing Site Performance Redundancy File Share Replacement Large Storage Needs Multiple Content Databases Set initial database size for planned growth in the next year 19

20 Content Databases One For both Intranet Content and My Sites Easier to manage My Site content can cause database to expand If hosted in the same content DB Use quotas to manage site collection size 20

21 Content Databases Split My Sites and Business Content Business content can be backed up separately My Site content database size is less of a concern How: Create a new content database for my sites Set original content database to offline 21

22 Content Databases Purpose based Content Databases For large document migration projects Or for differing backup/restore needs Increases database flexibility/scalability New site collections need to be created by an administrator 22

23 Maintenance Plans Set up on the SQL Server Easy automated database maintenance Requirements vary based on environment Backup plans are optional if 3rd party backup software used 23

24 Sample Maintenance Plans Backup User Databases Daily With clean up task.bak files should then be copied to secondary storage Backup System Databases Weekly As these don't change as often as user databases Backup Transaction Logs hourly If up to the hour restores are required Only for databases with full recovery model Reindex Databases Weekly Helps with performance Shrinking databases causes file system fragmentation 24

25 Virtualisation Decide what to Virtualise Web Front Ends Search Server Application Server Database Server Physical Infrastructure for Production Virtual for Test/Dev/Staging Backups are simplified, backup entire VHD/VMDK Restore as a group, Title at of presentation same point in time 25

26 FARM TOPOLOGIES 26

27 Topology Basic Intranet Best performance achieved on two servers: 1x Database Server 1x SharePoint Server Majority of my SharePoint installs have been in this configuration If database server is not well maintained, consider all in one server But not a 'stand-alone' install 27

28 Topology - Search Optimised Intranet Enables better performance for search and indexing 1x Database Server 1x Web Front End 1x Search Server Search Server hosts SSP, Central Admin and a Web Front End - Indexer can then be configured to crawl local web front end Query role on Index Server -No propagation of Full Text Catalog -Search will need to be rebuilt to accommodate additional search servers Query role on Web Front End -Full Text Catalog propagation will occur -Useful if more search servers are planned -Search still works if Index server doesn t 28

29 Topology Extranet Purpose: To collaborate with other organisations Host SharePoint Farm in DMZ Use forms based authentication Stand alone (windows service accounts) Or joined to DMZ Active Directory domain Publish through firewall with SSL 29

30 Topology Extranet Purpose: Publish Intranet to Remote Workers Host one Web Front End in DMZ Use ISA for external user authentication Terminate SSL on ISA too Need to allow traffic through the firewall SQL Active Directory 30

31 Topology - Internet Publishing Two Farms: Production SharePoint Farm -This is the one the world sees -Separate AD Domain in DMZ -Performance optimisations turned on -Accepts content deployment jobs Content Staging Farm -Used for updating content -Can be separate Web Application on Intranet Farm -Use content approval as needed Firewall needs to be configured to allow deployment jobs between farms 31

32 Topology Load Balancing Multiple Web Front Ends/Query Servers to handle large volumes of traffic Use System Centre Capacity Planner to work out how many you ll need Web Front Ends can be easily built and added to the farm to handle extra load as needed 32

33 Topology Load Balancing Methods DNS Round Robin Simply switches the between servers in a IP address pool Can cause problems with user s sessions and authentication Windows Load Balancing Good method for less sophisticated deployments Hardware Load Balancing Need specialised hardware Can determine load on each server and route requests appropriately Best in high load/mission critical Internet applications 33

34 Topology High Availability Stretched Farm 1x SharePoint + 1x SQL Server located off site Needs to be connected via 1GB link Using standard tools, failover is manual Need to switch the SQL Alias DR Farm can also be used for load balancing 34

35 Topology Disaster Recovery SQL Mirroring Second SQL box has 'mirror' of SharePoint data Should production SQL fail, mirror takes over Failover can be automatic with a witness SQL server Doubles SQL Hardware requirements 35

36 Topology Third Party Tools Disaster Recovery NeverFail WAN Acceleration Riverbed Site Output Compression - Aptimize 36

37 Conclusion Many solutions to the same challenges Best practice is not to cut corners We want our users to have the best possible experience Lots of information and many more Groups: OzMoss Blogs, Forums, Search Questions? 37

38 Thanks! Brendan Flamer.co.nz/spag/