| The same tenets that drive the makeup of the technical support organization also, not coincidentally, drive the overall solutions architecture. To reiterate, these are -
Functional or "capability" requirements -
Availability/high-availability requirements -
Performance requirements -
Scalability requirements -
Security requirements -
Administration requirements -
Other requirements Each of these becomes critical to the design and implementation of the individual server-based components within the overall SharePoint Portal Server solution. However, it makes good sense to step back a bit and analyze the portal solution from a holistic perspective prior to drilling down further. Overview ”the Portal System Landscape During the life of the SharePoint Portal Server implementation, a number of systems (sometimes referred to as instances or environments ) will be used to ensure the quality and availability of the Production Portal system. For example, the following four environments are quite common in large SPS deployments: -
Technical Sandbox ” a server system or environment where the technical folks can install, configure, integrate, back up, restore, and uninstall components of the portal solution. This is nearly always deployed first. -
Development system ” an environment used to develop and test changes to the dashboard. -
Test system ” may be deployed to test the impact that a certain load (referred to as load testing ) places on the overall solution, for example to determine the impact that different loads have on end- user search response times. -
Production system ” the system that end users leverage for the productive use and good of the company. This is the last system typically deployed. The sum total of all of these environments is typically referred to as the Portal System Landscape. Other environments exist as well, and provide different services or play different roles within the SPS landscape. We will go into more specifics of these systems in the next section, including when they might become a critical component of the landscape. In smaller deployments, a two- or possibly three-system landscape is architected and deployed, usually consisting of a combined Technical Sandbox/Development system and a Production system. Larger four- or five-system landscapes are not uncommon, however, in massive implementations, or implementations where the highest levels of availability are desired. Note the relationship between the number of systems in the landscape and the availability requirements of the solution ”more systems equates to higher availability. Why? Because more systems equate to incrementally greater quality assurance testing, testing that better guarantees improved availability of the ultimate production portal. Each of the systems in a system landscape actually consists of the following: -
A SharePoint Portal Server -
One or more representative SharePoint clients (for example, if the end-user population uses both Windows NT 4/SP6 Workstation with Internet Explorer 5.0, as well as W2K Pro with Internet Explorer 6, each of these clients should be maintained as a component of the "system") -
Any Integration-Points or server components that will play a role in the Production system (such as an Exchange server, dedicated Search and Crawl servers, SQL Server 2000, distributed IIS 5.0 servers, and so on) ”thus, additional servers or products may be installed as a component of each system. It's important to note that it makes little sense to save a few dollars by not including any of the above system landscape components. For example, if both Office 2000 and Office XP are deployed on different client platforms, then both must be included, as the integration functionality is slightly different between the two products. The SPS System Landscape Maintaining a number of discrete portal systems to support a single and perhaps small production portal implementation may seem like a lot of hardware, software, and resources to manage. Before justifying these expenses, though, let us drill down into the specific purpose or roles that each of these systems support, noting again that all of these systems ultimately support and help to maintain a well-performing production system. As we alluded to earlier, each of these systems is actually a mini-environment used for specific tasks related to the productive portal deployment: -
Technical Sandbox System ” This system is reserved for use by the technical implementation teams to practice and perfect Microsoft SharePoint Portal Server, IIS, W2K, and other software component installations, upgrades, integration with other solution components, setup/testing of data replication, backup and restore processes, server duplications processes, and so on. -
Development System ” This system is created and maintained for continued portal configuration and/or customization, maintenance, Microsoft SharePoint Portal Server upgrades, and bug fixes. This instance also serves as the originator of configurations and customizations that will eventually be "promoted" into production (although a Test/QA system, if it is in place, may be leveraged first). -
Training System ” Usually reserved for very large implementations, this system is maintained for ongoing internal training of end-user personnel ("How to use the SharePoint Finance Portal," Portal 101 classes, and so on). -
Test/QA System (a.k.a. Quality Assurance) ” Another optional system typically seen in the largest implementations, this system is maintained for integration and testing of configuration changes, customizations across multiple dashboards, and so on prior to promoting these changes into the Production Instance. -
Staging System ” Usually identical to Production, this system is used as the last stop for changes in a system. The Staging system is often subjected to stress/load tests so as to determine the expected impact of a change on the actual production system before this change is promoted to Production. -
Production System ” This system supports the business groups and supports the business needs addressed by Microsoft SharePoint Portal Server, and is the system the end users leverage for information sharing, content and document management, and so on. -
Disaster Recovery System ” This system is implemented when the cost of unplanned downtime exceeds the cost of implementing, maintaining, and supporting the Production system. DR systems, as they are generically referred to, are almost always located in different physical locations.  To read more about leveraging the concept of promoting changes within your SPS system to assist you in troubleshooting SPS-related issues, see "General Troubleshooting Approach," p. 618. In the case of ABC Company, it was determined by the technical support organization that a three-system landscape ”dedicated Technical Sandbox, Development, and Production systems ”made the most sense from an availability and financial perspective. They liked the idea of maintaining a Technical Sandbox system completely separate from all other systems, as it would allow them freedom to test new features, fixes, and updates up and down the solutions stack, without ever impacting the development or production systems. Additionally, they justified the incremental cost of a third portal landscape system under the umbrella of "disaster recovery," establishing the Development system at a location miles away from the Production and Technical Sandbox systems. Many companies are adopting strategies similar to that employed by ABC ”note also that the Technical Sandbox system is often referred to as the " best-kept secret" to maintaining a highly available production operating environment. That is, changes are introduced in the Production environment only after testing them in an identical (or as near identical as practical) technical sandbox environment, and then further ratified via the development system. Further, the promotion of configuration changes can also be tested in this manner, therefore ensuring that the promotion of changes from Development to Production is smooth. It is no wonder that a Technical Sandbox system was identified as a key element in ABC's Microsoft SharePoint Portal Server deployment and implementation strategy. Future Growth Versus Maximizing Approach Two schools of thought exist in regard to configuring servers, server components, and computing appliances. In the first case, sometimes called Future Growth Strategy or In the Box Growth, CPU, memory, disk, and peripheral I/O slot system configurations are designed to meet a minimal supported level of fault tolerance while allowing for future growth of the systems. That is, in configurations where the memory needed to meet the user requirements would require all disk drive bays, or all memory slots, or all CPU sockets of the computing platform expected to be used, a larger disk drive, higher density DIMM kit, and so on is actually used instead. In this way, the larger kit provides open slots/bays/and so forth to provide for future hardware upgrades. Such an approach to configuring allows for "built-in capacity growth" of the individual servers and appliances within a given solution ”an open /available drive bay/etc exists up front. A second school of thought for configuring individual servers and appliances within a solution suggests that a Maximizing strategy allows for lower total cost of ownership. Rather than leaving memory slots, CPU sockets, drive bays, and so on available ”and risking the ability to actually procure one of these components in the years to come ”defenders of the Maximizing strategy seek to provide maximum capability in (hopefully!) a fewer number of servers/appliances. In addition, proponents of this school of thought believe that the typical costs associated with "opening a box" ”planning for and taking down a server for hardware upgrades ”exceed the delta in cost between configuring it for future growth and "maxing it out." Note that neither school of thought seeks to sacrifice availability, though. Availability through redundancy ”maintaining "2x" or "1+x" servers when only "x" is required to address a given load ”still applies to both schools of thought. In the first case, though, three lightly configured servers may be specified, whereas in the latter, two heavily configured servers are preferred. ABC Company had subscribed to both schools of thought in the past. Through experience, though, they came to believe that it was more trouble than it was worth to find a new supported CPU, or additional supported RAM. Experience also told them that the downtime associated with bringing a server offline for a hardware upgrade was also not worth their effort. Therefore, they quickly decided that a "max out the box" approach would be their best bet for the SharePoint Portal Server implementation. |
