These are really just some notes I took during a recent training event. Most of this is probably common knowledge or on Technet somewhere, but this is a quick, conslidated list of some top system architecture concerns I have found important in desiging SharePoint deployments.
Server Architecture
Processors
When looking at SP architecutre keep in mind issues with 64 bit systems. Ideally, Index servers would be 64 Bit and big box type systems. You usually will have only one index server per farm (and can only have one/SSP). The only problem there is that many of the iFilters (must be on the index server) are not yet 64 bit compliant. So, keep it in mind.
The other thing to consider with 64 versus 32 is that systems must be consistent across a class of SharePoint servers. So, WFEs must all be either 32 or 64. Then you have query servers, index server, etc. Each class of server can be different than the other classes, so you can have 64 bit index and DB boxes, but still run cheaper 32 bit systems for WFEs.
Disk (see storage heading a little further down too)
Need to review I/O, index sizes, growth rate, version control, etc.
Be sure there is at least 25% free space on drives
High read speed is desired on Index server, but not really on WFEs.
Memory
WFE's depend on mem for caching
Index servers need big mem to speed the process, as they load the docs into memory as they are indexed
Network
Geo Issues
Let's say you have locations in both the US and UK. You REALLY want to setup two distinct farms to handle your portal information. Even if you manage all systems from one location, you would want to have separate farms. This is because of the fact that only one CA is allowed per farm. The CA runs a ton of jobs that are data intensive. Running these across an expensive or low bandwidth WAN is going to end up being hurtful to the portal environments. By having one farm in each GEO, you can instead just setup crawls or use other ways to get at the data that needs to be shared between them.
Another possible approach (though not recommended) would be to just host local SSPs. You will probably be doing that anyway, but still need to make sure to metnion it.
Database Concerns
- Physical/Logical arch
- Transaction logs
- Disk system
- SharePoint databases (where are they and how many)
- Log shipping and other backup/restore issues
The databases used in SharePoint:
- Config (CA)
- Content DBs
- Central Admin content DB
- Search DBs
Stoarge
Fullt text index data = 5%-10% of Total searchable content
Search DB = 10%-20% of Total searchable content
General Capacity Planning Issues
Spec out each of the following as separate systems
- Search
- Collaboration
- Excel Services
- Internet/Intranet Solutions