Go to: SharePoint Portal Server resizing and deployment

From: http://www.cnfan.net/microsoft/sharepoint/2007-3/7/20070307380.html

To meet the growing needs of enterprises, the scale-up deployment of SharePoint Portal Server expands the system promotion of SharePoint Portal Server (hereinafter referred to as SPS) in enterprises, to meet the needs of most enterprises to migrate from a small or single server farm to a medium-sized server farm, and to ensure the integrity of the original SPS system data, the whole system is securely and effectively resized and migrated. Now, it simulates the access and file sharing work for more than 6000 people in an enterprise, and simulates the real existing SPS system architecture in the experimental environment, conduct effective architecture expansion tests on AP and SQL. This SPS test assumes that an enterprise uses the SPS system within a single department and serves as the daily document sharing, version control, and internal portal within the Department. The existing SPS architecture is as follows:

From the perspective of the existing architecture, both the SPS database and the SPS site adopt a single server architecture and belong to the small-scale field SPS architecture. One of the two servers runs the SQL Server 2000 Server, another server is running the SPS (Web, search, job, and index service. Due to the large amount of data in the original system, expansion will be carried out on the basis of this architecture to meet the needs of all organizations to transfer relevant documents to the portal of each department in the future, this prevents the SPs' servers from taking on too much work and increases server instability. Considering the security, stability, and high availability, the simulation architecture is an SPS medium-sized field. The following are suggestions for expanding the topology:

According to the recommended topology of the above medium-sized server farm, we recommend that you expand the SPS site architecture:
This test will also simulate the small-scale field SPS architecture and expand it to the expected future SPS medium-sized field architecture to achieve the overall expansion of the SPS site, ensuring the security, stability and high availability of the enterprise portal site. The following lists the Servers configured for this test:

Before the scale-out test, it is assumed that the SPS portal site already exists (SharePoint web is installed on sps01, database is installed on spssql01), and relevant data is available. We will not describe how to deploy small servers here. I. Backup of SPS data
To completely back up the SPS site data, you need to use the SharePoint Portal Server data backup and recovery tool, which is installed with SPs. Because the SPS site and SQL do not exist on the same server, before using this tool, you must first install the SQL Server tool (SQL SP3 or above); otherwise, the following prompt will appear:

Figure 1 prompt before using the Backup Tool

Figure 2 install the SQL Server Client
After installing the SQL Server Client, install the SP4 patch and click Start> All Programs> SharePoint Portal Server ", select "SharePoint Portal Server data backup and recovery" to back up the SPS site.

Figure 3 backup using the SPS Backup Tool
Note: The shared file address must be used in the backup location and name. You cannot directly specify the local backup path. After the backup path of the SPS site is specified, click "all server farm components". By default, all backup items in the right box are selected, and click Backup To start backup of the SPS server component, this includes site backup and database backup. After the backup is complete, we will return a backup result. If there is a problem in the backup process, please check the relevant settings and options to check whether the problem is normal, and then back up the relevant components again.
Figure 4 backup completed
The backed up SPS component has five data items:

Figure 5 complete SPS components after backup
In addition, you also need to back up the web. config file, which is stored in the root directory of the SPS site by default. The path is c: \ Inetpub \ wwwroot, the purpose is to back up the added security control items and the list of custom web parts of the SPS site, to prevent the restored SPS site-related controls from being re-registered.
Figure 6 back up the web. config file

2. Back up data in the SQL Server database
After the SPS-related components are backed up using the SharePoint Portal Server data backup and recovery tool, the sps SQL database is backed up to ensure data integrity. Open the SQL Server Enterprise Manager and expand the database items. Here you can see four SPS-related databases: portalsitename _ PROF: user-configured database; portalsitename _ serv: Service database; portalsitename _ site: content database; sps_config_db: SharePoint Portal Server 2003 configuration database; complete backup of the four databases respectively:

Figure 7 portalsitename _ Prof backup

Figure 8 portalsitename _ serv backup

Figure 9 portalsitename _ site backup

Figure 10 sps01_config_db backup
The backup of the SPS database is to prevent exceptions when using the SPS backup and recovery tool, or the SPS server components that are backed up later cannot be restored. In either case, you can directly restore the database to restore the SPS site and ensure data integrity. SQL database backup is generally used only as data backup.

3. Delete portal sites
After completing the preceding backup, go to the SharePoint management center on the sps01 server, select portal website and virtual server configuration, and click list and manage portal website ".
Figure 11 go to The sps01 SPS Management Center
Go to the "manage portal website" Page and create Http: // sps01 You can view the site and edit the website attributes. Here, we need to click "delete portal website" to completely clear all information about the original portal site and delete the database associated with the portal site.
Figure 12 portal Deletion

Figure 13 delete all databases
After the portal site and portal site database are deleted, click "go to SharePoint Portal Server Management Center" to return to the SPS management interface.

Figure 14 portal website deleted
After returning to the portal site, because the email server is configured with the Exchange Server when you create the portal site in the early stage, you must enable "Configure email server settings" under "server configuration ", delete all related email settings.

Figure 15 Delete email server settings
After deleting the email server settings, select "configure Server Topology" under "server configuration" and click "change component" in this interface, delete "Web", "Search", and "Index" in the component allocation, select "NONE" in "job server", and remove the job server sps01.

Figure 16 Delete component allocation and job server
After the portal site, email configuration, and component allocation are deleted, only the sps_config_db database is stored in the database. The other three databases are deleted and the SPS site is deleted. In the future, all database links will be disconnected to delete all portal sites. [Url =] 4. Disconnect the server and configure the database connection [/url] After completing the above operations, check whether the database is deleted normally, make sure that the portal services related to server expansion are not stored on any server. After confirming the relevant configuration, go to "Server Settings" in the SPS management center and click "specify database server configuration" to go to the "specify Database Configuration Settings" interface. You can view the configuration database server linked to the original site, select "disconnect from the configuration database", and click "OK" to start disconnecting from the related server settings of spssql01.

Figure 17 disconnect from configuring a database
After the connection to the configuration database is disconnected, the page will automatically go to the "configure Server Farm account settings" page, that is, an interface that appears after the initial installation of SPs, here, we need to re-enter "Default content access account" and "portal application pool ID ". This parameter is not provided for the time being. After the new database architecture is completed, the related settings and database connection will be configured again.

5. install and configure an SQL Server Cluster
Because the SQL Server database is critical to the SPS site, the first consideration for planning and deploying the SPS is the high availability and Stability of the SQL server used to store data. So far, in this Guide, the SPS portal site is planned to take this role as an SQL database cluster, ensuring the security, stability, and high performance of servers and related data, and realizing the ideal expansion of the SPS site database. In this virtual simulation test, two servers spssql01 and spssql02 are used to build an SQL Server Cluster with two nodes. Create a new server cluster on spssql01 and set the cluster IP address to 192.168.67.31.
Figure 18 enter "cluster service account" in cluster IP settings. This account must be the local administrator account for all nodes and use administrator here.
Figure 19 cluster service account settings
Check whether the disk Q is selected correctly to avoid using local arbitration.

Figure 20 select the arbitration Q disk, select the arbitration disk, and click "Next" to start cluster creation, here, we will analyze the cluster in detail, configure the cluster service, configure the resource type, and configure related resources (including IP addresses, network names, disks, and so on ).

Figure 21 creates a cluster for a period of time. After all the configurations are completed, the cluster creation result is returned.
Figure 22 cluster created
After the cluster is created, click "Next" to create the cluster at the first node. Then, add the second node (spssql02) to the cluster based on the existing cluster.

Figure 23 add the second node
Enter the Cluster Server account in the cluster creation to determine whether the cluster can be added.

Figure 24 enter the cluster service account

After entering and verifying the cluster service account, formally add the second node to the cluster.

Figure 25 add the second node to the Cluster
After the configuration is complete, you can see in the cluster manager that the two nodes configured are in the running state, and the related cluster groups and some resources have been created. At this time, the related services are running at the first node, that is, on spssql01.

Figure 26 the cluster is configured
After the cluster configuration is complete, we can start configuring the SQL Server 2000 cluster. Run the SQL Server 2000 installer on spssql01 and enter the virtual SQL server name msspssql of SQL Server 2000 cluster service in the computer name field. Next, go to the SQL Server 2000 "failover cluster" Settings page, where you can see the newly created virtual server name msspssql, and fill in the IP address of the virtual SQL Server 2000 IP address, and select the network settings to be used. After Entering the fields, click "add" and click "Next" to continue.