Introduction
For a product environment, whether the database-driven key task client / server application, or e-commerce Web site, the continuous normal running time in the environment is increasingly a basic business requirement. A method of implementing high availability in this white paper - Microsoft® SQL ServerTM 2000 failover cluster is introduced. This failover cluster is only available for SQL Server 2000 Enterprise Edition.
The failover cluster is such a process: the operating system and SQL Server 2000 provide availability by working together when an error, hardware failure, or operating system is wrong. Failover clusters provide hardware redundancy by special configuration. Under this configuration, the resource of the key task will automatically transfer from the failed machine to the equivalent configuration. At the same time, the fault transfer cluster also allows system maintenance of the computer to keep the computer in the case where other nodes remain. This can also keep the system shutdown due to normal maintenance at a lowest level. For more information on optimizing the database, how to avoid the skills that can lead to performance issues that may be unavailable, refer to Chapter 33 of Microsoft SQL Server 2000 Resource Kit (Resource Kit) "Database Optimization Method".
The failover group is intended to provide high availability for a comprehensive scalability solution, which provides backup, redundancy, and performance. If the software and / or hardware have trouble, fail-moving clusters, and other high availability methods (for example, SQL Server 2000 Log delivery) can set up a product environment and put it into operation in a short period of time.
However, the failover cluster is not a load balancing solution that cannot protect your system from external attacks, and you cannot avoid all cluster nodes encountered a catastrophic software failure, single-point failure (for example: no redundant hardware) or natural disaster . For more information on SQL Server 2000 high availability, please refer to Chapter 16, "99.999%: High Availability" of Microsoft SQL Server 2000 Resource Kit.
Improvement of failover cluster
Microsoft SQL Server 2000 Enterprise Edition failover cluster provides a variety of improvements that transcend SQL Server Version 7.0 Enterprise Edition. Some improvements in the cluster feature in SQL Server 2000 include:
· The installation and uninstall of the SQL Server 2000 failover cluster is done through the SQL Server 2000 installer, not by setting up the database server and subsequent wizard programs. Installation and clusters are completed in one process. The SQL Server 2000 fault cluster is a permanent option that deletes the only way to uninstall the cluster instance of SQL Server.
· SQL Server 2000 supports multiple instances, allows you to synchronize up to 16 SQL Server instances.
· SQL Server 2000 extends support for fault recovery for server nodes from clusters, including single-node clusters. If a node is malfunction, you can delete it and reinstall it, then re-add to the cluster while keeping all other nodes to continue working properly. Add a new server to a virtual server definition is a very simple operation for the SQL Server 2000 installer.
• SQL Server 2000 running on Microsoft Windows® 2000 DataCenter Server can support up to 4 server nodes in a cluster.
· Now, all nodes have SQL Server tools (including performance counters) and local copies of executable programs that may be used in the event of a fault; you can manage the server from a remote system or cluster node itself. • SQL Server 2000 Failover Cluster Supports Microsoft Search Services.
· The configuration of the SQL Server 2000 failover cluster can be updated by re run the installer.
· SQL Server 2000 supports multiple network addresses. This allows SQL Server 2000 to listen for multiple IP addresses in different subnets.
· Now, database administrators can start and stop SQL Server using SQL Server Service Manager or SQL Server Enterprise Manager without having to start and stop SQL Server services using Cluster Manager (Cluster Administrator).
· Service package can be applied directly to SQL Server 2000 virtual servers. When using SQL Server 7.0, you must release the server from the cluster before the application service package.
· SQL Server 2000 is a fully supported application, allowing SQL Server 2000 to interact with cluster services, and other more advantages, such as avoiding creating a database on an invalid logic drive.
What is a Windows cluster?
Microsoft SQL Server 2000 Failover Cluster integrates with Windows Clustering. In the Windows environment, there are two types of clusters:
· Server cluster
SQL Server 2000 Failover Cluster is based on Windows 2000 Advanced Server or Datacenter Server cluster. The Windows 2000 server cluster combines four servers. When the hardware fault, natural and human disaster, software failure, the cluster can maintain access to the application and server resources, enable high availability, scalability, and management of resources and applications. Sex. Unlike network load balancing clusters, when a server, resource, or support cluster in the cluster cannot be used, it will be transferred to another available server.
· Network load balancing cluster
Network Load Balancing clusters provide high availability and scalability based on TCP / IP services, including web servers, FTP servers, other critical task, and COM applications. In a network load balancing scheme, multiple servers run independently of each other, without sharing any resources. The client's request is assigned to each server. When one of the servers fails, the network load balancing cluster detects this issue and reassigns the load to other servers. SQL Server 2000 failover cluster does not belong to this type, but can be part of the overall architecture. In this architecture, the web farm and fault transfer cluster are connected using a network load balancing cluster. Since you will deploy a network load balancing cluster based on the needs of the application, you must consider network load balancing in the application planning and configuration phase.
Hardware required for Windows cluster
The Windows Cluster (one of the features of Microsoft Windows 2000 ADVANCED Server and Windows 2000 DataCenter Server) and the Microsoft Cluster Services (MSCS, one of the features of MSCS, Microsoft Windows NT® 4.0, Enterprise Edition) use the following various hardware components:
· Cluster node
The node is a server in the cluster. Windows NT Server 4.0, Enterprise Edition, and Windows 2000 Advanced Server supports dual-node clusters, Windows 2000 DataCenter Server can support up to 4 node clusters.
· Heartbeat
Heartbeat is a dedicated network setting between the clustered nodes for checking if the server is set up and can run normally. Heartbeats usually operate at a certain time interval, which is called a time slice. If the heartbeat does not work properly, the failover will be started, and the service is taken over the other node in the cluster.
· External network
In addition to the heartbeat private network, at least one public network needs to be enabled, so that the cluster has an external connection function.
· Shared cluster disk array
A shared cluster disk array is a physical disk (SCSI RAID or FIBRECHANNEL) that can be accessed. Windows clusters support non-shared disk arrays. Non-Shared Disk Arrays is a mode that has a given resource at any given time. All other nodes cannot be accessed before having resources. This model prevents data when the two computers have access to the same driver.
· Arbitration Drive
The arbitration driver is a logical drive specified in the shared disk array of Windows clusters. The drive is constantly updating, including information about the cluster status. If this drive is erroneous or destroyed, the cluster installation will also be erroneous or destroyed.
operating system
The following is a set of operating system level components, also known as cluster resources:
· Cluster name
This name refers to the cluster itself, not the SQL Server virtual server, all Windows NT or Windows 2000 external connections use this name; not pointing to a single node.
· Cluster IP address
All external connections use this IP address to contact the failover cluster itself, not the SQL Server virtual server.
· Cluster administrator account
This account is used to manage and have a fault transfer cluster. The cluster administrator account must be created at the domain level, and must belong to the administrator of all nodes in the cluster.
· Cluster resource type
Cluster resources include a variety of services, software, or hardware that can be configured in clusters, including: DHCP, file type, universal application, general service, Internet protocol, network name, physical disk, background printing, and WINS.
· Cluster Group
The cluster group is a group of group-based resources based on certain logical organizations, which can include application services that support clusters, such as SQL Server 2000. Conceptually, the cluster group is a folder on your hard disk, which contains related information.
virtual server
Understanding the concept of virtual servers is the key to understanding the failover cluster. For a client or application, the virtual server is a server name or IP address for access. Establish a connection from the client to the virtual server does not need to know which node of the current cluster hosts the virtual server. The cluster SQL Server is called the SQL Server virtual server.
What is the SQL Server 2000 failover cluster?
SQL Server 2000 is built on a Windows cluster or MSCS, is an application that supports cluster. In Figure 1, the virtual server of SQL Server 2000 is located on the existing MSCS installation.
Figure 1: Schematic diagram of SQL Server 2000 Virtual Server. This example includes two server nodes and a SQL Server 2000 virtual server.
SQL Server virtual server components
Examples are a fully independent SQL Server installation with several underlying shared components that affect the running mode of the SQL Server 2000 in the cluster environment. The SQL Server virtual server is a clustered SQL Server instance. Each virtual server consists of the following resource: • SQL Server network name
This is the name of the user and application to connect to the SQL Server.
· SQL Server IP address
Users and applications will connect to SQL Server using this TCP / IP address. This address is different from the IP address of the cluster.
· SQL Server
Used to control the SQL Server 2000 service instance.
· SQL Server Agent
Used to control the SQL Server Agent service instance.
· SQL Server 2000 full-text search
In addition to SQL Server and SQL Server Agent resources, each virtual server also has a full-text resource; each instance points to shared Microsoft Search services. When there is a fault, it is different from other services; only the data file is flexible, not a service.
· Microsoft Distributed Transaction Coordinator (MS DTC)
Some installations of SQL Server use MS DTC. If you have this situation in your installation, all instances in the cluster will share this MS DTC.
· SQL Server Virtual Server Administrator Account
This is the SQL Server service account. This account can be similar to the cluster administrator account mentioned earlier. If you use Windows NT 4.0 Enterprise Edition, this service account must also have administrator privileges on all nodes; but do not need to use Windows 2000. For more information on creating this account, please refer to the "Setup Windows Service Account" of SQL Server 2000 Books Online.
As mentioned in the "Improvement of Fault Transfer Cluster", SQL Server 2000 can support multiple instances on each server - a default instance and up to 15 specified instances, or 16 specified instances. SQL Server can be installed as a default instance or a specified instance. SQL Server 2000 virtual servers can also have multiple local specified instances or a SQL Server 7.0 default instance, but these instances cannot be seen in the Windows cluster. It belongs to the local instance of the server.
Important: The instance of SQL Server 2000 cannot be run on the SQL Server 6.5 or SQL Server 7.0 cluster.
After the concept of joining an example, two new concepts of two failover clusters are derived:
· Single Example Cluster: Alternate / Passive Cluster. A single instance cluster means a SQL Server 2000 virtual server is installed.
· Multiple Usset Cluster: Alternate / Active Cluster. A multi-solid cluster means multiple SQL Server 2000 virtual servers have been installed. Since this implementation of the cluster is not the same as SQL Server 2000, the term "activity / activity" is not really reflected.
Single instance set
Single-instance clusters have only one SQL Server activity instance, all of which have a single server node, all other nodes of the cluster are in the waiting state. Another node is enabled when the active node is faulty or when manual failover is performed for daily maintenance.
Multi-solid set
A multi-instance cluster has up to 4 server nodes, supports up to 16 instances (1 default and 15 specified instances, or 16 specified instances). Each SQL Server 2000 virtual server requires disk resources that have other instances that cannot be used. These disk resources refer to the logical drive name (for example, drive f: /), SQL Server uses this resource to store data and log files. To set this logical drive, you need multiple independent physical disks unless your disk subsystem supports multiple logical drives on the same physical disk. Considering the IP port, the behavior of SQL Server in the cluster environment is also different from the specified instance of the stand-alone. During the installation process, a dynamic port may be configured, which may be other ports other than 1433, 1433 The port number is preserved for this instance. In the failover cluster, multiple instances can be configured to share the same port, such as 1433. This is because the fault transfer cluster only listens to the IP address assigned to the SQL Server virtual server, so the proportion of instances and ports does not require 1: 1. However, for security considerations and possible add availability, you may need to specify its own separate ports, or keep the configuration constant when installing. The principle of operation of the fault transfer cluster
The cluster node uses heartbeat to check if each node is working properly, which is simultaneously at two levels at the operating system and SQL Server. At the operating system level, the node is paid in the cluster. The main node checks one resource every 3 seconds and the stronger node checks once every 5 seconds. This process lasts for 25 seconds and then start again. For example, if a node with an instance is in 19 seconds due to a problem (network, disk waiting) fault, the contention node detects this fault in 20 seconds, if it determines that the primary node no longer has resource control, So the contention node will take over the resource.
At the SQL Server level, the node hosting the SQL Server resource is checked for every 5 seconds checks for a looks-alive check. This is a lightweight check that the service is still running, even when the instance of SQL Server stops running smoothly. In comparison, isalive checks more comprehensive, it needs to issue a "Select @@ servername transact SQL" query on the server to determine if the server itself can respond to requests; but still cannot guarantee the normal operation of the user database. If this query fails, isalive check will try five times, then try to reconnect to an instance of SQL Server. If all five attempts have failed, then the SQL Server resource has failed. According to the failover threshold setting of the SQL Server resource, the Windows cluster will try to restart this resource on the same node or transfer to another available node. This query can accept a small amount of errors, such as a license issue or a paused SQL Server instance, but if the threshold will eventually fail to fail.
During the failover process from one node to another, the Windows cluster will launch the SQL Server service for this instance on the new node and then start the database by the recovery process. The failover of the SQL Server virtual server requires a small amount of time (may be a few seconds). After the service is started, the SQL Server resource is considered to be launched. Next, the user database will perform a regular recovery process, which means all transactions that have been completed in the transaction log will roll forward, and unfinished transactions will roll back. The length of the recovery process depends on the number of activities that must be in front of the rollback or rollback. You can set the recovery interval of the server to a lower value, which avoids too long recovery times and can accelerate the failover process. Client connection and SQL Server 2000 virtual server
End users and applications Access SQL Server 2000 virtual servers via SQL Server network name or IP address of the SQL Server 2000 virtual server. There is no need to connect with the cluster name, cluster IP address, or a single node. From the perspective of client or application prospects, don't need to consider which node has these resources, connect to the SQL Server 2000 virtual server just like a normal SQL Server. During failover, all activities will be interrupted. For web browser users, a simple web page refresh can create a new database connection. For more traditional client / server applications, or specifically dependent on the intermediate layer, the application's designer may need to consider checking if the connection is present. If there is no connection, you need to re-connect. Therefore, the user may not be completed regardless of the type of transaction in the server, unless the transaction has been executed before the server has been executed before the server is faulty, or the transaction is processed within the application.
For more information, please refer to the Knowledge Base article "Q273673 - Virtual server client connection must be controlled by client":
http://support.microsoft.com/support/kb/articles/q273/6/73.asp
Configure SQL Server 2000 failover cluster
In the issue of successfully installed SQL Server 2000 Failover Cluster, the most important thing is to ensure that the correct hardware and software is deployed for applications that are designed to run in a fault transfer cluster. These hardware should have high performance and can be scaled in a special need to access the SQL Server application.
Design your app for the failover cluster
Before you start designing hardware, you should consider behavior that may occur during the failover process. When using a failover cluster, you must consider the items that should be considered when designing application design.
· Try to narrow all your transactions, submit reasonable workload. Since the virtual server is to pass the startup process, including transaction logs, rollback or front roll transactions through each database, the larger transactions will extend the failover time.
• If an application uses the Windows Cluster Server Cluster API, it will be considered to support the cluster. For more information on the Windows Cluster API, please refer to the link below the MSDN Developer Center.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mscs/hh/mscs/win_clus_9nfr.asp
• Set the timeout value in the application, turn off the connection correctly or make other correct responses, such as friendly information, etc., thereby achieving a good user experience. End users don't have to worry about database issues.
• Is associated with the previous point, if the connection is interrupted, the user can retry the logic, reconnect the database. The programming model of some applications includes retry logic, such as Microsoft BizTalk Server. But if there is no such product, you may need to design a custom solution, for example: use a certain type of middleware. Administrator Account and SQL Server 2000 Failover Cluster
Before installing the server cluster and the SQL Server 2000 virtual server, you need to configure several Windows level accounts.
· Create an account for the management and ownership of the server cluster. It must be an effective domain administrator account. At the same time, this account should also be used during the installation of the SQL Server 2000 virtual server.
• At least one account must be created to manage SQL Server and SQL Server Agent. This can be two different accounts, not necessarily a domain administrator, but must be an effective domain account. If necessary, you can use the same account above, but use different accounts better.
Although this account will automatically give appropriate priority levels during the installation process, but if you want to change this account, you must meet the following conditions (or the administrator group must meet the following conditions):
· Must be a member of the local administrator group (for Windows NT 4.0, Enterprise Edition).
· It must be given "Some of the operating system", "as a service login" and "Replace Process Level Token" policy.
• Cluster service account must have permissions to log in to SQL Server. If you accept the default setting, the account [NThority / System] must have SQL Server login permissions, so the SQL Server resource DLL can send Isalive queries to SQL Server.
Note, any enterprise policy that requires changes to the account password (for example, modifying a password every 90 days) may affect the availability of the virtual server, because you will need to reconfigure each SQL Server 2000 virtual server, including stop and restart To make changes to the change. This requires this when planning the availability of your environment and weighs it with the security of the company.
Important: If you need to change the account password related to the SQL Server virtual server (SQL Server or SQL Server Agent), use SQL Server Enterprise Manager. This program can change the service password on all nodes and give the permissions required to select the selected user account. If you do not use SQL Server Enterprise Manager to change your password, use Windows-based service tools to modify the underlying service, then you may not be able to start SQL Server after shutdown or failover, and a full-text search function may not function properly.
safety
If you include advanced security such as Kerberos, SSL, or IPSec, consider the following questions when planning failover clusters:
· Currently, Kerberos cannot be used to authenticate the connection of cluster virtual servers; the client will try to use NTLM authentication. Other information or related content changes, please refer to the Limitations of the MSCS Virtual Server in the Q235529 -Windows 2000 domain environment:
http://support.microsoft.com/support/kb/articles/q235/5/29.asp
• IPsec is not supported in the cluster environment. · If the installed SSL certificate is the same as the name of your SQL Server virtual server, then this SQL Server instance may not start. For more information, please refer to Knowledge Base Article "Q283794 -" related issues associated with virtual names in the cluster SQL Servers ":
http://support.microsoft.com/support/kb/articles/q283/7/94.asp
Software requirements
SQL Server 2000 failover cluster requires one of SQL Server 2000 Enterprise Edition and one of the following operating systems:
· Microsoft Windows NT Server 4.0, Enterprise Edition (at least Service Pack 5)
· Microsoft Windows 2000 Advanced Server
· Microsoft Windows 2000 Datacenter Server
Hardware requirements
The SQL Server 2000 virtual server should not be just a highly available SQL Server instance, and should be a SQL Server instance with high performance and high scalability. You can determine hardware requirements through two main factors:
· What is the current application or web site workload? What is the expected workload in the next 6 months, one year, or even two years?
This is the information that most people have not mastered when implementing the solution. Getting to Master the application or Web site running is critical to determining what operating systems and hardware purchases. Assessing the best way to apply is to place it in a laboratory environment. The use of the appropriate tool can establish a performance trend diagram, such as the system monitor (Windows NT 4.0 Performance Monitor). But it is difficult to determine the exact needs. It is also necessary to pay attention to all applications that affect performance, regardless of these issues are in the current product version or in a programned update version.
· What is the project's budget?
Although funds should not be an obstacle to availability, it is necessary to consider budget issues in reality. Before purchasing a cluster solution, you can evaluate your hardware requirements according to the following questions:
· How long does you want these servers how long?
· Do you have enough disk space to maintain this period?
· Do you have enough memory and CPU capacity during this period?
This plan can avoid exceeding the expected ideas in the growth of hardware in performance and capacity. This way you will not need to upgrade frequently, so your solution will be more available.
Important note: All nodes in the failover cluster are configured, which is at least consistent with each other. However, if you plan to configure a node, you have more virtual servers than other nodes, then configure this node to handle all virtual server capacity that may host. Node performance may affect availability.
For high availability solutions, consider implementing a fault transfer cluster. But if you can't afford the complete cluster solution required in the Microsoft Hardware Compatibility List (HCL), you can consider other high availability alternatives, such as log delivery. Although this solution requires HCL compatibility equipment, do not need to purchase a complete solution or purchase specialized hardware for Windows clusters.
Hardware compatibility list
Query the Microsoft Hardware Compatibility List (HCL) before deciding all the final hardware selection. A complete hardware solution must be included in the server configuration in the Cluster classification. Buy separate components, even if the purchased components are listed in the HCL, you cannot create a supported solution. If the solution is not listed in the HCL, its cluster configuration will not be supported. For more information on supported cluster configuration, please refer to Knowledge Base Articles "Q264476 - Support clusters only in HCL authentication": http://support.microsoft.com/support/kb/articles/q264/4/4/4/ 76.asp
And "Q224971 - Microsoft Cluster Server Hardware Compatibility List and Test":
http://support.microsoft.com/support/kb/articles/q224/9/71.asp
HCL can be found on http://www.microsoft.com/hcl.
processor
Depending on the operating system you choose, you can use a different number of processors.
Operating system processor number upper limit Windows NT 4.0, Enterprise Edition 8 Windows 2000 Advanced Server 8 Windows 2000 Datacenter Server 32
If you test the performance of your application in a laboratory or other controlled environment, you should first determine the basic processing capability required. One way to determine the required basic processing capabilities is to analyze your system over time, regularly record relevant statistics, and then draw this information into a chart. This is a very important step, the configuration of the product server should consider the current workload and the growth of workloads over time.
From the perspective of operating system, the cluster requires Windows NT 4.0 Server, Enterprise Edition, Windows 2000 Advanced Server, or Windows 2000 DataCenter Server. Windows 2000 Datacenter Server provides the most complete solutions; it is designed for high availability and requires a service level agreement (Service Level Agreement). If the operating system is not listed in the above table, it means that this operating system cannot support more than 4 processors.
Note that Windows 2000 DataCenter Server is part of the Windows Data Center Program (WDP). You cannot get Windows 2000 DataCenter Server by getting the same way as purchasing most of the Microsoft products, but must be purchased from the developer participating in the WDP program as part of the overall solution. For more information, please contact your certification developer, or refer to the Windows 2000 Datacenter Server Web site: http://www.microsoft.com/windows2000/guide/datacenter/overview/default.asp
RAM
Depending on the operating system used, the maximum memory capacity that SQL Server 2000 can be utilized is not the same. Installing SQL Server 2000 Enterprise Edition can support 32GB of memory on Windows Datacenter Server without enabling an address window extension (AWE). The following table lists the maximum amount of memory available to SQL Server 2000 in each operating system.
Operating system maximum Windows NT 4.0, Enterprise Edition 3 GB Windows 2000 Advanced Server 8 GB (Enable AWE) Windows 2000 DataCenter Server 64 GB (Enable AWE) Address Window Extension and Physical Addressing Extension Memory
With AWE, the memory cage application can be run more efficiently in SQL Server 2000, thereby improving performance. Both Windows 2000 Advanced Server and Windows 2000 DataCenter Server have introduced the improved AWE API, which allows applications to access a large number of physical memory. Due to the limitations of 32-bit memory addressing, Windows NT 4.0 and Windows 2000 that are not enabled can only be used to use up to 4 GB of physical memory. By default, 2 GB is assigned to the operating system, and the other 2 GB is assigned to the application. If you add an / 3GB switch in the Boot.ini used in the operating system, you can access up to 3 GB of memory such as SQL Server, but the number of memory used by the operating system is reduced to 1 GB. Therefore, even if the server is configured with 8 GB of memory, all more 4 GB of memory is actually unused. AWE is a support in the operating system that enables WIN32®-based applications to extend memory.
AWE requires applications (for example: SQL Server 2000) to write code for AWE. The AWE support in SQL Server 2000 must be configured via the AWE Enabled option in sp_configure, and you need to set up each instance. By default, AWE enabled is set to 0 or off. Enable AWE support in SQL Server 2000 also requires some other operating system configuration. For more information, please refer to "AWE Memory" of SQL Server Books Online.
There is also a way to enable you to use more memory, which is the physical addressing extension (PAE). PAE enables 32-bit operating systems to address memory or more memory. For information on PAE, including specific settings, please refer to Knowledge Base Articles "Q268363 - Intel Physical Addressing Extensions (PAE) in Windows 2000: http://support.microsoft.com/support/kb/articles/q268/3 /63.asp
Note If PAE is enabled, you may experience backup and recovery errors for Windows 2000 or SQL Server 2000 backup. Please refer to the Knowledge Base Article "Q280793 - Unable to view SQL Server 2000 or Windows 2000 Backup when running in PAE mode: http://support.microsoft.com/support/kb/articles/q280/7/93.asp
When you select hardware for your cluster solution, if you plan to use big memory, please confirm that the configuration can support the hardware that supports large memory. You can search for the "massive memory" in all hcl all categories.
The following table summarizes the extended memory settings that you should configure when you set a large amount of memory.
4 GB or less 4 GB to 16 GB 16GB / 3GB switch Enable / 3GB Disable / 3GB Enable AWE Enable AWE Enable PAE (Boot.ini) Enable PAE (Boot.ini)
Note If you enable AWE or PAE memory, we strongly recommend testing the configuration before using the server.
The enabled of these three memory options has two different mechanisms.
/ 3GB
The / 3GB option is a switch enabled by the boot.ini file. After you have installed Windows 2000 Advanced Server, modify the Boot.ini file, add / 3GB parameters in the ARC path, format the black body part listed in the following example:
Multi (0) DISK (0) RDisk (0) Partition (2) / Winnt = "Windows 2000 Advanced Server" / 3GB / Basevideo / SOS
PAE
PAE is also enabled by one switch in Boot.ini. Open the Boot.ini file, add / PAE parameters in the ARC path, format the black body part listed in the following example:
Multi (0) Disk (0) rdisk (0) Partition (2) / Winnt = "Windows 2000 Advanced Server" / PAE / Basevideo / SOS
AWE
AWE is enabled by calling sp_configure in the SQL Server 2000 query, the method is as follows:
EXEC SP_CONFIGURE 'AWE ENABED', 1
Reconfigure
When implementing AWE memory, please pay attention to the following questions:
· The SQL Server instance cannot dynamically manage the memory address space used.
When AWE is enabled in SQL Server 2000, if the MAX Server Memory configuration option is not set, SQL Server will capture all available memory (except for the 128 MB of memory that is allowed to perform basic operations) This may cause the operating system and all other processes to run on the same server.
• After the initialization is completed, the AWE memory has all physical memory obtained at startup until it is closed.
If AWE is enabled and too much memory, you must turn off the SQL Server to reconfigure it, which will result in downtime (so that the availability of high availability schemes is lowered, for example: failover cluster). Since the memory page used by the SQL Server instance is extracted from an inable-page pool, these memory cannot be exchanged. This means that once the physical memory is full, SQL Server will not be able to use the remaining memory using the page files set on the physical disk.
· If the Max Server Memory option is configured, set the workspace size to 0.
For more information on configuring the AWE memory on the server, please refer to "Using AWE Memory in Windows 2000" in SQL Server Books Online, and the following:
· "PAE Server Settings", including some white paper (including "supporting PAE memory in Windows 2000"): http://www.microsoft.com/hwdev/pae
· "Address Window Extension and Windows 2000 Datacenter Server" White Paper: http://www.microsoft.com/hwdev/ntdrivers/aw.htm
The internet
The automatic feeling of the NIC should be set to comply with your LAN or WAN network static speed. For example, if your network is configured to 100 megabytes full duplex, all NIC is configured to 100 MB. SQL Server 2000 supports multiple IP addresses (for each subnet) and NIC. If a larger bandwidth is required, SQL Server 2000 supports a larger bandwidth network through GigaNet or Compaq Servernet II technology. If these techniques are used, higher performance can be achieved between multiple SQL Server servers. GigaNet is a built-in support, and the update of the Servernet II is located at: http://www.microsoft.com/sql/downloads/servernet.asp. Node location
Due to various restrictions, such as: SCSI or FibRechannel supported by physical limits on the distance supported by FibRechannel, each node in the failover group must be placed in a relatively close place. But server clusters don't focus on the distance, so it is theory that these nodes can be placed anywhere. If you want to configure a geographic location, consider the following:
• Dedicated and public network connections between cluster nodes must be a separate routes of LAN (LAN), using virtual LAN (VLAN) and other technologies. In this case, the network must ensure that the maximum loop waiting time between the node connection must be less than 500 ms. Cluster interconnects must belong to a standard LAN connection.
· All geographically replicated storage technologies must retain single disk semantics, such as fixed arbitration of logical units of Windows clusters. The arbitration disk must be replicated in real time and synchronize in all sites.
Configuring a cluster that is scattered in a geographic location is complicated and needs carefully planned. Please consult your hardware developer before implementing your cluster solution. The same hardware and software configuration must be listed in the hardware compatibility list and to purchase as a cluster solution, so that Microsoft support is available. You can find supportive geographic dispersion clusters in the "Cluster / Geographic" classification of HCL. For more information on geographic dispersion clusters, please refer to Q280743 "Windows Cluster and Geographical Sites":
http://support.microsoft.com/support/kb/articles/q280/7/43.asp
Another method of high availability between different geographic locations is to deliver a log delivery, which is one of the features of SQL Server 2000 Enterprise Edition. Log delivery is such a process: according to the set schedule, apply the transaction log from one server to another in another server. The log delivery supports the location of the physical dispersion such that it is ideal for eliminating a single point of failure, protecting data loss caused by incidents such as natural disasters. For more information on log delivery, please refer to SQL Server 2000 Books Online (online book) or Chapter 13 "Log Delivery" on Microsoft SQL Server 2000 Resource Kit.
Which option is best for you? Even a third-party solution is used, you need to carefully plan and debug your network when configuring a log delivery. Although log delivery requires connectivity between locations, it is not subject to 500 milliseconds; therefore there is a longer waiting time, for example, you can achieve log delivery from London to San Francisco. But both solutions require an appropriate plan used in troubleshooting. Compared to the cluster solution, log delivery requires more artificial intervention and management. This is because log delivery cannot automatically perform role changes, and role changes are necessary to implement hot standby.
Configuring best practices
In addition to understanding the basic principles of failover clusters, you will also find that the following skills and best practices are very useful for configuring your server. Disk configuration and file laying
The main components of all database systems are memory - it contains important data for applications and insertions. In order to achieve high availability, SQL Server is used to store data and logs that must be part of an error redundant external array. These disks must be high-speed while supporting a large number of I / O and huge storage space, allowing your database to expand over time. What needs to be remembered is that in a fault transfer group, the shared cluster disk array is a single point of failure. One way to alleviate this risk is that it is secretly reserved the spare hard drive for use in the event of a fault.
These disks can be configured as a small machine account system interface (SCSI) or FibRechannel (Fiber Channel). When implementing a shared disk array, we recommend FIBRECHANNEL. FibRechannel is designed for high bandwidth and high capacity. Storage Zone Network (SAN) is a disk array that performs all I / O using a network protocol on the FibRechannel. If you include a cluster / multi-clustered device in the full cluster solution, you can support SAN usage when using a failed transfer cluster.
You can use a Windows cluster in a SAN environment. A set of storage devices that can use SAN are listed in the HCL cluster / multi-cluster classification device. These devices are supported and have passed the test of SAN storage units that connect multiple MSCS clusters. You may be able to deploy a set of Windows servers and clusters on shared storage devices supported by Microsoft by matching the complete cluster configuration defined in the HCL cluster class. For more information on SAN support for clusters, please refer to Knowledge Base Articles "Q304415 - Supports multiple clusters connected to the same SAN device": http://support.microsoft.com/support/kb/articles/q304/4/4/4/ 15.ASP.
Note that the Windows 2000 DataCenter Server cluster does not support SCSI, you must use FibRechannel.
Note that the network direct connection (NAS) device is not supported in the cluster environment. For more information, please refer to Knowledge Base Article "Q304261 - Support Network Database File": http://support.microsoft.com/support/kb/articles/q304/2/61.asp
Data and log devices and TEMPDB should be placed in different disks and use more different channels as much as possible. However, this will limit the number of instances that can be installed on the cluster. If your system is very huge, or have a hot zone, you may decide to use the file group as a method of dividing disk I / O. The file group is then placed on different disks and different channels, which will further divide the disk I / O, which will help improve system performance. When you analyze high availability design, focus on file placing and channel use is quite important. Because the performance problem caused by bottlenecks may be mistakenly considered as availability. Physical file / disk layout issues may need to stop to solve, which will reduce your system availability.
The data drive should use the RAID configuration of the strip image to achieve the highest availability. This means that these drives are first mapped one by one, and then the entire system is striped. The strip mirror is sometimes referred to as RAID 1 0. Another way to use beneficial use is the mirror strip, and the performance it provides is slightly better than the strip mirror, sometimes referred to as RAID 0 1. The mirror strip means that a set of disks are striped into a collection and then map. Like the belt mirror, both cannot achieve fault. These years are very popular RAID 5 unable to provide the highest availability and performance. However, if the strip mirroring or mirror strip cannot be implemented, the RAID 5 is a nice choice regardless of the cost or hardware restrictions.
The log drive can be configured using RAID 1 (normal mirror) or strip mirror / mirror strip. The log requires key protection, so you need to select the appropriate disk availability for your high availability. Note that terms that have different developers, strip mirroring and mirror strips (that are, 0 1 and 1 0) may vary.
The following is a reminder to use the disk in the server cluster:
• Windows clusters do not support dynamic disks. For more information, please refer to the Knowledge Base article "Q237853 - Server cluster disk cannot be dynamically configured", address is http://support.microsoft.com/support/kb/articles/q237/8/53.asp
• Cluster Database Server does not support file compression.
· The cluster does not support software RAID; the hardware RAID must be used.
Other information and configuration worksheets, please refer to Appendix C "Shared Cluster Disk Partition Configuration Worksheet" and "SQL Server 2000 Failover Disk Configuration Worksheet".
Arbitrate disk
Do not place any database files in the arbitration disk, for example: data or log files. By default, SQL Server 2000 installation does not adopt an arbitration disk unless there is no other disk available. From a physical disk perspective, if possible, the arbitration disk should be placed on a separate spindle and separate drives, separated from SQL Server data.
Controller configuration
Select a logical group with a card with sufficient channel to divide the disk, thereby reducing I / O. But this will limit the number of virtual servers you can install. If the FIBRECHANNEL / RAID controller is in the node, the backup cache should be disabled in the shared disk array. Because even if the backup battery is used, once the resource failure is transferred to another node, there may still be a project reside in the cache. If the service is rebounded back to this node, it may cause an error due to the content of the controller attempt to override the disk. If the transaction is not processed in the cache, data loss may occur in the failover.
Using multiple RAID controllers may not only improve performance and reduce I / O contention (this will increase availability), and such hardware-level redundancy capabilities can provide high availability in the event of a RAID controller failure.
Make sure the virtual server can see logical disks
In the failover cluster, if the virtual server cannot "see" disk resource (ie, logical drive letter), the virtual server will not function properly. There may be two reasons for this happening:
· There may be no correct disk drive installed.
Make sure the disk drive is installed correctly. In some cases (for example, the operating system is upgraded from Windows NT 4.0, Enterprise Edition to Windows 2000 Advanced Server), Windows 2000 has some special drive, but the old drive may still be in the system.
· Drive may not be a slave drive for the SQL Server 2000 virtual server. During the installation of the virtual server, you can only select a data drive. So if the SQL Server 2000 virtual server requires multiple drives, you need to add a slave drive after the installation is complete. To check if the drive is a virtual server's dependent drive, please refer to the "SQL Server 2000 Failover Group and Substation" section later in this white paper.
Add logic disk to the cluster configuration
Since the Windows cluster does not support dynamic disk, some downtime will be added to the configuration after the initial configuration is completed. Please refer to Knowledge Base Article "Q175278 - How to install additional drives on shared SCSI bus" to learn about the contents of adding drives in the cluster configuration. You can find this article in the address:
http://support.microsoft.com/support/kb/articles/q175/2/78.ASP Once the drive is identified at the Windows cluster level, the SQL Server cluster resource will be offline, and then in the cluster manager The drive is added as a slave device. After re-recovering the SQL Server resource online, the SQL Server virtual server will be able to use this new drive.
Extend existing logical disks in a cluster configuration
You can extend existing disk spaces in the hardware level in the hardware level in the defined cluster disks. Please refer to Knowledge Base Article "Q263590 - How to extend the disk space of existing shared disk" through the Windows cluster "to learn how to extend the drive in the cluster configuration. You can find this article in the address:
Http://support.microsoft.com/support/kb/articles/q263/5/90.asp
Keep in mind that this may result in a certain downtime, and must be planned to be planned so as not to affect the availability of end users.
Cluster node and windows domain
All nodes in the cluster must be members of the same domain, and must be able to access domain controllers and domain name system (DNS) servers and WINS servers. If you want to install SQL Server, these nodes should not be configured as domain controllers, or you may have some problems. In fact, domain controller functions (such as: Active Directory) do not support clusters, so all information is local. This will affect some things, for example, because the computer object of the virtual server cannot run in the cluster, the publishing capability of the program that has a directory function will be affected under the virtual server's computer object. In a cluster environment, Windows 2000 / SQL Server 2000 still requires a WINS server. For more information, please refer to the Knowledge Base Article "Q235529 - Windows 2000 Domain Limitations":
http://support.microsoft.com/support/kb/articles/q235/5/29.asp
Use multiple IP addresses
When configuring the network card to prepare the cluster, you should consider the available schemes based on the number of new network cards, and the number of network types that must be supported. At the same time, you need to know if you allocate more IP addresses to allow connections to SQL Server, which will affect the availability of failover clusters. This is because in some cases, you may not be able to control the router to reroute the network.
For example, you may try to configure a network card for all communications to maximize your network card for all communication activities:
· All external clients are connected to and between nodes.
· Internal cluster (only for private networks between cluster nodes).
· Only client access (a public network that allows client connection).
Even if you only need a network card in the cluster, you can handle all clusters of network communication, and don't do this, because this will be a single point of failure. The best configuration is to use different NIC to handle different types of connections.
Ideally, each SQL Server has three IP addresses and three network cards in different subnets:
· Heartbeat
This should be configured to "Internal Cluster Communication Only", allowing nodes to communicate with each other without providing additional traffic from the external client and should be on an opposite IP class. For more information, please refer to Knowledge Base Article "Q258750 - The dedicated 'heartbeat" configured on the cluster server, the address is http://support.microsoft.com/support/kb/articles/q258/7/50. ASP · Client connection
If you use only IP addresses to access it for client access, then configure it as "all communication", so you can provide redundancy capabilities for internal communications when you have failed. If you have multiple IP addresses that can be used by the client, you can configure them as "all communications" or "client access".
· Different private networks
This is different from the heartbeat and should be configured to "only client access". It should be configured to enable the server in the cluster to access this particular IP address. This configuration will enable file transfer, or in the most ideal case, allowing log delivery to be configured without affecting heartbeat or client network traffic.
All three IP addresses cannot be in the same subnet. If more than one IP address uses the same subnet, a connection problem may occur. Even if this IP address is not used in the cluster, there will be a problem. For example, the following table lists some of the correct and wrong server configurations.
NIC correctly configures error configuration 1 - Configured as public network 172.21.10.1 172.22.10.1 2 - Configured for public network 172.22.10.2 172.22.2.23 - Configured to be dedicated network 172.23.7.3 172.23.7.3 4 - Configure Heartbeat 10.10.10.1 172.24 .2.5
In addition, some NIC can support the binding of multiple IP addresses. Although this makes the failover cluster to communicate with multiple networks, this may be a single point of failure. This should be avoided in a high availability solution. Therefore, always make sure you configure at least one network card for each required feature, even if this network card can support multiple IP addresses.
For more information, please refer to Knowledge Base Article "Q175767 - Expected Behavior of Multiple Adapters in the same network": http://support.microsoft.com/support/kb/articles/q175/7/67.asp
Memory configuration
This section describes the precautions for memory usage in the SQL Server 2000 failover cluster.
Single instance failover cluster
In a single instance SQL Server 2000 failover group, the situation of failover is very simple: if the primary node is faulty, all processes will be transferred to the specified second node (refer to this white paper "configuration node failover priority"). From the hardware, the configuration of the second node and node A should always be exactly the same. If there are differences in the two, the fault transfer nodes are different from the main nodes, especially in memory (can be seen in the sample 2), then some issues may occur. You need to consider other processes that may run on the server node and consider the overhead of the operating system.
Example 1: Two nodes, the same configuration
You can make the cluster node more than two cups of water. Two cups can store 4 ounces of water. A cup has 3 ounces of water, while B cup has no water. If you pour water from A to B, there will be no problem. In the SQL Server 2000 failover group, the resource can be run as normal as the primary node. The figure below shows this situation.
Example 2: Two nodes, different configurations
We once again compare two cluster nodes for two glasses. A cup can accommodate 4 ounces, now 3 ounces of water. B cup can accommodate 2 oz. If you pour the water from A to B, the water will overflow because the B cup cannot install all the water in the a cup. Therefore, if your failover cluster does not have enough physical memory to support SQL Server instance, SQL Server is looking for more memory beyond the available physical memory, and it is assigned to disk. This way the server will lack resources, which may cause the node to be unable to respond. Figure 3 explains this situation. Multi-instance failover cluster
In a multi-instance SQL Server 2000 failover group, the situation is more complicated. At the same time, there are up to 16 instances at the same time, how can I manage the memory at this time? First, it is also the most important, you should make sure that all servers have the same amount of memory, enough to handle instances that may have faults. Another important consideration is to use MAX Server Memory to limit the upper limit of SQL Server 2000 instance memory usage (refer to "Address Window Extension and Physical Addressing Extension Memory" in front of this article). In particular, when the AWE memory is enabled, Max Server Memory must be set in the multi-substantial cluster to prevent the server node lack resources. In the example II of the following example, there will be a presentation. You need to consider other processes that may run on the server node and consider the overhead of the operating system.
Example 1: Two SQL Server instances, no upper limit
We will explain again in two glasses. The maximum capacity of two cups is 4 oz. A cup and B cups are equipped with 3 oz water. If you put the water in the B cup into a cup. Only 1 ounce can be installed, while the remaining 2 oz will overflow. As with the previous example, if the failover node does not have enough physical memory to support the second SQL Server 2000 instance, SQL Server is looking for more memory beyond the available physical memory, and it is assigned to disk. This way the server will lack resources, which may cause the node to be unable to respond. The figure below explains this situation.
Example 2: Two SQL Server 2000 instances, memory has the upper limit
We continue to compare the two cluster nodes than the cups of water. The maximum capacity of each cup is 8 ounces. A cup and B cup each stored 3 oz water. If you pour the water in the B cup into a cup, the a cup can store all the water without overflow. From the SQL Server perspective, in order to make this example normally, the AWE memory must be enabled, and each instance must use the sp_configure store Max Server Memory option to limit the memory of each instance to 3 GB. This still has 2 GB of memory remaining when failover, and all other processes can still run. The figure below explains this situation.
Processor capacity
For SQL Server 2000, there is no special requirement for the number of processors required. Nonetheless, since this depends on the case of using SQL Server, each cluster node must be configured to process any workload that may be running on the node. All instances will share the processor in the server unless the association of the processor is set to a virtual server. The best way to determine how much processing power is to load the application before formally running and use the system monitor to monitor.
For example, you have an application that uses a virtual server. This is an OLTP application that always uses all 4 processors in the server. The processor's usage is approximately 75%. If the second virtual server in the failover cluster has the same processor usage, it is set to replace the same node as the first virtual server. At this point, this server may be slower or may not respond because it cannot process two system workloads. In addition to the probation of memory, you will also encounter a problem with your CPU.
Use more than two nodes
When you use more than two nodes in the SQL Server 2000 failover cluster, you need to consider the following questions:
· How much memory is needed for each instance?
· Which node is a fault transfer cluster node for a particular instance? What is the preferred order?
· Is there enough disk space and memory to support instances of each configuration to be transferred to a specific node?
· Is the hardware configured to support a fault transfer cluster without affecting other instances?
In the case of operating system support, SQL Server 2000 can use 4 nodes (the number of virtual servers is not only limited by operating system selection and hardware capacity), up to 16 instances. Therefore, as the key task system is increasing, these considerations become more important. Although SQL Server can support up to 16 instances, this value is not recommended greater than 4 (in Windows 2000 DataCenter Server cluster, the proportion of virtual servers and nodes is 1: 1). Another consideration is the number of logical drives that can be allocated - because each instance requires its own driver disk. Due to the limitations of the English alphabet, the number of available drive discs is limited. If multiple driver disks are assigned to each independent instance, it is possible to greatly reduce the number of instances that can be created.
As mentioned above, you may need to assign a specified unique port to the SQL Server 2000 virtual server after installation. By default, SQL Server 2000 will automatically allocate a port during the virtual server installation. To manually change this port, use the server network tool.
Scenary 1: 4 Nodes Multi-instance SQL Server 2000 Failover Cluster, Three Event Nodes, One Alternate Node (N 1)
With 4 node support, Windows 2000 DataCenter Server provides greater flexibility for cluster configuration. When using a 4-node Windows 2000 DataCenter Server cluster in the SQL Server environment, we recommend that three nodes have a SQL Server 2000 instance, and the fourth node is in a hot standby state. This difference is different from the log delivery scheme, and is different from a single-real-alone failover cluster, at least one node waits for work in this case. This situation is called N 1. You need to configure your failover cluster to allow instances to first shift to another node that runs SQL Server 2000 instances, in addition to this, in addition to this, the fourth node should be configured as a main failover. This can reduce the problem caused by too many instances lacking resources. In this case, AWE memory should be enabled, allowing each SQL Server instance to address the operation 1 GB of memory. This allows your application to telescopic when you exceed the memory allocation of SQL Server, rather than limiting them.
Solution 2: 4 Nodes Multi-instance SQL Server 2000 Failover Cluster, all four nodes are active
Running four SQL Server 2000 instances on the four nodes requires careful planning, so another instance does not lack resources due to depletion of memory and processor during failover. The problem caused by memory is not as serious as the processor resources. For example, if the workload of the production online transaction (OLTP) system typically occupies 50% of resources, all four active SQL Server 2000 instances exhibit similar behavior, and memory can only be given to certain compensation support for processors; More processors must be added.
Other configuration problems
• Disable or do not install anti-virus software in the cluster. For more information, please refer to the Q250355 "Cluster service can cause problems in the anti-virus software":
http://support.microsoft.com/support/kb/articles/q250/3/55.aSP does not recommend simultaneously host SQL Server 2000 and Microsoft Exchange 2000 in the same cluster.
• Make sure all SQL Server has its own unique network name and IP address.
• When configuring replication on a cluster server, create a MSCS file share for copying and configured to access the copy when all clusters when failover.
· It is not recommended to use any file sharing on a cluster disk running in SQL Server.
· NetBIOS name resolution of all virtual resources requires WINS.
· Solving any application problems that may occur, can cause availability, such as locking and blocking operations, etc.
For other considerations, please refer to SQL Server 2000 Books Online.
SQL Server 2000 Failover Cluster Configuration Instance
Of course, in accordance with your system requirements and available hardware, there are a variety of different ways to configure your fault transfer cluster. When you understand the average and peak throughput of the system, you can usually plan your server capacity. For details on capacity planning techniques, please refer to the Microsoft SQL Server 2000 Administrator's Guide.
OLTP system server planning
This design is a typical OLTP application. The transaction log is divided into a set of disk, which can support a lot of transactions per second. The two servers have the same configuration:
· Operating system: Windows 2000 Advanced Server
· Number of nodes: 2
· The number of processors (each server): 8
· Memory (per server): 4 GB
· SQL Server Memory configuration: upper limit is 3 GB
• Built-in disk configuration of the operating system: 2 to 4 built-in drivers (each having 9 GB capacity), use RAID 1. For 4 or more drives, RAID 0 1 is used.
Shared FIBRECHANNEL SAN configuration
GB (total capacity) total disk (external; each has 18 GB capacity; RAID 0 1) drive Document DRIVE Q 36 4 Arbitration Drive Drive R 54 6 Transaction Log Drive S 216 24 SQL Server Data File, Tempdb Drive T 36 4 Backup / Imported data file (large disk)
Multi-instance failover clusters equipped with alternate servers that enable log delivery
In a general high availability program, people use a failover cluster as a preferred method. Alternatively, the transaction log can also be sent to another completely different servers to use this as another disaster recovery method. This server (called hot spare server) should be located within another geographic data center, away from failover clusters, thereby avoiding single point failure. However, a good network connection is required between these two locations. Log delivery is one of the features of SQL Server 2000 Enterprise Edition. For more information on log delivery, please refer to Chapter 13, "Log Delive" and SQL Server Books Online, Microsoft SQL Server 2000 Resource Kit.
Multi-instance failover cluster
In order to support future expansion, you can choose an 8-way computer, but only add 4 processors. Two instances support OLTP applications. Example 1 is copied to a report server (not described here). Example 2 Extract from the data warehouse once a week and does not copy it. Due to this difference, a mirror group is added to the Example 1 transaction log. · Operating system: Windows 2000 Advanced Server
· Number of nodes: 2
· The number of processors (each server): 4
· SQL Server 2000 instance quantity: 2
· Memory (each server): 4 GB, SQL Server limits each instance at 1.5 GB
• Built-in disk allocation: 2 to 4 built-in drives (each 9 GB), use RAID 1. For 4 or more drives, RAID 0 1 is used.
Shared FIBRECHANNEL SAN configuration
GB (total capacity) total disk (external; each with 18 GB capacity) drive Document DRIVE Q 36 4 Arbitration Drive Drive R 54 6 Example 1: Transaction Log Drive S 36 4 Example 2: Transaction Log Drive T 72 8 Example 1: Data Document Drive U 72 8 Example 2: Data Document Drive V 36 4 Example 1: Tempdb Drive W 36 4 Example 2: Tempdb Drive X 54 6 Backup / Imported Data File (You can use a large disk)
Hot spare server configuration
The standby server must have sufficient memory and processing capabilities, enough to support all database workloads during failover.
· Operating system: Windows 2000 Advanced Server
· The number of processors: 4
· Memory: 4 GB, where 3 GB is assigned to SQL Server.
Disk configuration (RAID 1)
GB RAID partition total disk file DRIVE C 18 A 2 (built-in) operating system, page file, SQL Server executable, system database Drive Z 54 C 6 (built-in) backup / imported data file Drive T 36 E 4 (built-in) Transaction Log Drive i 180 D 12 (external) Data file, TEMPDB
In this case, the computer can be used less. Data can be easier to transfer to the standby system, and throughput requirements do not increase product driver capacity. But in fact, you should test this to ensure that the hot spare system can handle all workloads. Not only should you do a good job in disaster recovery programs, but also update the standby server when you ask for changes.
Multi-instance Windows 2000 Datacenter Cluster (N 1)
In this scenario, there are four servers with similar built-in disk configured, share an external FIBRECHANNEL SAN. In the failover cluster, there are three SQL Server 2000 instances in the active state. The requirements for CPU and RAM depends on the role played in the server in the cluster. 3 fail-moving cluster nodes are the same, and each node has an instance. The fourth node is the specified fault transfer node, enough to cope with all three instances of failure. The program uses AWE memory. Failover clusters require meticulous considerations and through authenticated hardware solutions. For more information on failed transition clusters, AWE memory, and N 1 configuration, please refer to "Use more than two nodes" in front of this article. All instances
· Operating system: Windows 2000 Datacenter Server
Activity example
· Number of nodes: 3
· The number of processors (each server): 8
· Memory (each server): 6 GB, SQL Server is limited to 4 GB
· Built-in disk configuration of the operating system: 2 to 4 built-in drives (each 9 GB), use RAID 1. For 4 or more drives, RAID 0 1 is used.
Failover node
This failover node must have enough memory and CPU to support all three active instances at the same time failover.
· The number of processors: 32
· Memory: 16 GB
· Built-in disk configuration of the operating system: 2 to 4 built-in drives (each 9 GB), use RAID 1.
Shared FIBRECHANNEL SAN configuration
GB (total capacity) total disk (external; each with 18 GB capacity) drive Document DRIVE Q 36 4 Arbitration Drive Drive T 36 4 Example 1: Transaction Log Drive U 36 4 Example 2: Transaction Log Drive V 36 4 Example 3: Transaction Log Drive I 90 10 Example 1: Data File Example 1: Tempdb Drive J 108 12 Example 2: Data File Example 2: Tempdb Drive K 162 18 Example 3: Data Document Drive L 72 8 Instance 1: Data File, May include Index Drive M 72 8 Example 2: Data file, may include Index Drive N 72 8 Example 3: Tempdb Drive Z 36 4 Backup / Imported Data File
In this example, Examples 1 and 2 are OLTP applications with similar access methods. Example 3 is a decision support system (DSS) instance, a large number of TEMPDBs, so you need to migrate it to another drive containing multiple quick disks. Note that instance 3 does not need to configure more than two standard disks for the transaction log drive. For more information, please refer to the SQL Server 2000 insider (Microsoft Press® Publishing) written by Kalen Delaney, and Chapter 33 of Microsoft SQL Server 2000 Resource Kit "Data Library Optimization Method".
Since the server resources used by the reporting system are different from the OLTP system, it is important to consider the characteristics of each workload. When failover, a failover cluster node may have two SQL Server 2000 virtual servers, and can I support two virtual servers from the perspective of memory, processor, and disk I / O? One node may be able to handle two virtual servers at the same time in a short time. However, a disaster recovery program may need to return an instance of failed transfer to its initial node as soon as possible. Another alternative is to assign enough CPU and memory resources for each system and then restrict the resource usage of each instance. Implement SQL Server 2000 failover cluster
This section describes the implementation considerations when configuring failed transition clusters. To learn the installation guide installation guide, please refer to http://www.microsoft.com/windows2000/techinfo/planning/server/clustersteps.asp
It is recommended to restart the server after installing SQL Server 2000. This will release the locked resource and complete all unforced files rename.
You can use Windows NT 4.0, Enterprise Edition or Windows 2000 Advanced Server to set a single-node cluster for development items, please refer to Knowledge Base article "Q245626 - Information: Install a single-node MSCS cluster using the '-localquorum' switch":
http://support.microsoft.com/support/kb/articles/q245/6/26.asp
Precondition
Before installing SQL Server 2000, please sure that there is no error in the event viewer, the error may affect if the cluster can be installed smoothly. Determine that only the services necessary for the operating system is still running. All other services should stop, they may interfere with the installation process. These services include SNMP, World Wide Web Publishing services, and developers's specific programs. The most convenient way to start and stop multiple servers is to create two batch files: one containing multiple NET STOP commands, and the other contains the corresponding NET START command.
The following table lists the services that should be kept.
Windows NT 4.0 Server, Enterprise Edition
· ALERTER · Cluster Service (Cluster Service) · Computer Browser · Event Log · License Logging Service (License Log Service) · Messenger (Real Time Communication) · Net Logon (Network Login) ) · Windows NT LM Security Support Provider (Windows NT LM Security Support Provider) · Plug and Play · Remote Procedure Call (RPC) Locator (Remote Process Call (RPC) Locator) · Remote Procedure Call (RPC) Service (Remote Process Call (RPC) Service) · Server · Spooler · TCP / IP NetBIOS Helper · TIME Service · Workstation (Workstation) Windows 2000 Advanced Server and Windows 2000 Datacenter Server
· Alerter · Cluster Service (Cluster Service) · Computer Browser (Computer Browser) · Distributed File System · Distributed Link Tracking Client · Distributed Link TRACKING Server Distributed Link Tracking Server) · DNS Client (DNS Client) · Event Log · License Logging Service (License Log Service) · Logical Disk Manager (Logical Disk Manager) · Messenger (Real Time Communication) · Net Logon (Network Login) · Windows NT LM Security Support Provider (Windows NT LM Security Support Supply) · Network Connectors · Plug and Play · Process Control (Process Control) · Remote Procedure Call (RPC) Locator (Remote Process Call (RPC) Locator) · Remote Procedure Call (RPC) Service (Remote Procedure Call (RPC) Service) · Remote Registry Service · Removable Storage · Security Accounts Manager · Server (Server) · Spooler · TCP / IP NetBIOS Helper (TCP / IP NetBIOS Help) · Windows Management Instrumentation (Win DOWS Management Specification) · Driver Extensions · Windows Time Service · Workstation (Workstation) Installation Sequence
This section describes the order of installation of the operating system and SQL Server 2000.
Windows NT 4.0 Server, Enterprise Edition
· Install Windows NT 4.0 Server, Enterprise Edition (do not install Microsoft Internet Information Server).
· Create domain users.
· Install Windows NT 4.0 Service Pack 3.
· Install Microsoft Internet Explorer 5.
• Disable NetBIOS in an internal private network.
· Install MSCs on both nodes.
· Manually create MS DTC cluster resources, refer to "Create MS DTC Resources (for Windows NT 4.0, Enterprise Edition).
· If you need to install Windows NT 4.0 Option Pack, do not install MSMQ.
• Install the Windows NT Service Pack 5 or updated version.
· Pause all unwanted services.
· Install SQL Server 2000 (Refer to Appendix B "-" The Steppring of the Install New Virtual Server ").
Windows 2000 Advanced Server and Windows 2000 Datacenter Server
· Install Windows 2000 Advanced Server (if you choose Windows 2000 Datacenter Server, then the operating system is installed by the developer).
· Install Microsoft Internet Explorer 5 Update (if needed).
· Create domain users.
• Disable NetBIOS in an internal private network.
• Install Windows cluster on a node.
• Add other nodes to this cluster.
• Run COMCLUST.EXE on all nodes to create a cluster MS DTC resource. (For more information, please refer to the "Failover Cluster" of SQL Server 2000 Books Online).
· Pause all unwanted services.
· Install SQL Server 2000 (Refer to Appendix B - "Install the New Virtual Server Step by Stepline").
Create a MS DTC resource (only for Windows NT 4.0, Enterprise Edition)
This section explains how to configure MS DTC resources to run Windows NT 4.0, Enterprise Edition, and its installation process is more complicated than Windows 2000 Advanced Server or Windows 2000 Datacenter Server.
Configure MS DTC IP Address
1. In the Cluster Manager, select the disk group that contains the arbitral disk resource. Right click on this disk group and then rename it.
2. Select the disk group you need. In the File menu, click New, then click Resources. In the "Name" box of the New Resource dialog, enter "MDSTC IP Address"; in the Resource Type box, select "IP Address"; in the Group box, select the group you want . Click Next.
3. The two nodes of the cluster should be the owner. If not, you need to add a node and click Next.
4. In the Subordinate dialog box, select Disk Resources in your Selected Group from the Available Resources box, and then click Add. At this point, the disk resource will appear in the "Resource Bind" box. Click Next.
5. In the TCP / IP Address Parameters dialog box, enter TCP / IP information. In the Address box, enter a static IP address (for example: 10.1.14.131); in the Subnet Mask box, enter an IP subnet address (for example: 255.255.255.0); in "Network" In the box, select the cluster network you want. Click Finish. 6. A message will appear to confirm that the IP address is configured successfully.
7. In the Cluster Manager window, this new resource will appear in the right pane. To launch this resource (now in offline status), right click on this resource and click Online.
Configure the MS DTC network name
1. From the File menu of the Cluster Manager, point to "New" and click Resources.
2. In the "Name" box of the New Resource dialog, enter the "MSDTC Network Name"; in the Resource Type box, select Network Name; in the Group box, select you The group you need; click Next.
3. In the Possible Owner dialog, two nodes of the cluster should be displayed as possible owners. If not, you need to add a node and click Next.
4. In the Subordinate dialog, the MS DTC IP address resource configured in front should be displayed in the Available Resources box. Select this resource, and then click Add. This resource will be displayed in the Resource Binding box. Click Next.
5. In the Network Name Parameters dialog box, enter "MSDTC" and click Finish.
6. A message will appear to confirm that the IP address is configured successfully.
7. In the Cluster Manager window, this new resource will appear in the right pane. To start this resource (now is offline), right click on this resource and click Online.
Implement best practice
This section will introduce some best practices on implementing SQL Server 2000 failover clusters.
Configure node failover priority
When you use more than two nodes in the failover cluster, you need to consider which node should have a SQL Server process when you fail. This is very important. Since up to 4 nodes can be used, you need to design a logical order for the product environment. This failover cluster priority should be set for groups that contain all SQL Server instance resources (not just virtual servers), ensuring that all resources can be transferred to the same node. For example, in the n 1 configuration, each group should have an idle node in the preferred owner list. This means that no matter which node has failed, the resources on this node can be migrated on the idle node.
Important: Do not use the Cluster Manager to remove the node from the resource definition, you should use the SQL Server Settings to implement this function. For instructions, please refer to "Add or delete cluster nodes from the virtual server definition" later.
Preferred failover order for node configuration
1. Start "Cluster Manager". On the group containing the SQL Server 2000 virtual server, click "Properties".
2. In the General tab, the Preferred Owner list box lists the cluster nodes that may have these processes in this group, as well as the current order of failover. To change this order, click "Modify".
3. In the "Modify Preferences Owner" dialog box, you will modify the preferred failover order. All nodes configured as possible owners are displayed in the right pane and install the failover order. For example, there are 4 nodes in a cluster: Dennis, Tommy, James, and Chuck. All nodes of these four clusters can be possible, the order is: If Dennis fails, transfer to James, then Tommy, and finally if James or Tommy is unavailable. Select Chuck. Failover / fault recovery strategy
It is recommended to establish an overall cluster failover / fault recovery strategy. Failover can be controlled by a threshold, that is, the resource will not perform failover when not exceeding this value. There are now two levels of threshold: resources and clusters. Depending on the configuration of the resource, the policy can affect the group that shifts to another node.
When the failover is transferred, the cluster group containing the SQL Server resource can be configured: if the node is reused, resume resource is restored to the primary node. By default, this option is closed. This is because it is often not possible to run on the second node. This setting provides an opportunity to analyze and repair problems with the fault node.
Automatic fault recovery for cluster groups
1. Start "Cluster Manager". On the group containing the SQL Server 2000 virtual server, click "Properties".
2. In the Properties dialog box, click the "Fault Recovery" tab.
3. To block automatic failure recovery, select "Prevent failure recovery". To allow automatic failure recovery, select Allow Fault Recovery, then select one of the following options:
· Restore immediately
This means that all resources immediately resume when the second Windows cluster node detects the preferred cluster node online. This is not very reasonable because it may interfere with the client and application, especially at the peak period of working day.
· Perform fault recovery in a certain period of time
This option allows the failure to restore the fault to the preferred node (if it is on the online state) controls within a specific period of time. The time here can be all integers of 0 to 23.
Configuring threshold for resource
1. Start "Cluster Manager". Select the correct group with the SQL Server 2000 virtual server, right-click the resource and click Properties.
2. In the Properties dialog box, click the Advanced tab.
3. If the cluster service will not attempt to restart or allow the resource to be in a fault state, select "Do not restart". The "Restart" option is selected by default.
4. If "Restart" is selected, configure the reboot policy:
· Impact group
In order to avoid malfunction of the SQL Server group after the resource selected after the specified retry number (threshold) is over, do not select the "Impact Group" checkbox.
· Threshold is the number of times the cluster service attempts to restart resources, and the cycle is the length of time (unit: second) between twice. Set these two values based on your requirements for availability.
For example, if the threshold is set to 0, and select "Impact Group", the entire group and resources are transferred to another node when detecting a fault.
5. Do not modify "Looks Alive" and "IS Alive" settings.
6. Do not modify "hanging hours" unless necessary. This value is in seconds, and the resource used in the offline pending or the online pending state determines the time used by its own state, and the cluster service sets it offline or expired. 7. Click Apply, and then click OK.
Configure failover threshold for groups
1. Start "Cluster Manager". On the group containing the SQL Server 2000 virtual server, click "Properties".
2. In the Properties dialog box, click the Failover tab.
3. To configure a failed transfer policy, enter the number of times the group allows the group to make a failover within the set period of time in the threshold box. In the "cycle" box, enter the set period of time.
For example, if the "threshold" is set to 10, "cycle" is set to 6. Then the cluster service can perform 10 failover within 6 hours. The Windows cluster will set this group to offline when the 11th failover occurs within 6 hours. This only works on the resource of the failed transfer; so if the SQL Server cluster has a 11th fault, it will be set to offline, and IP still keeps online.
SQL Server 2000 Failover Cluster and MS DTC
There are two different ways when designing a server cluster using MS DTC:
· Use the default configuration. In this case, the MS DTC is configured to use the arbitral driver. This is the most popular and most common solution, we recommend you to adopt this program.
· Pre-planning, create a separate cluster driver for MS DTC use. Although the use of MS DTCs in the cluster may reduce the arbiter of the arbiter drive, it will also result in a number of drivers that do not have enough drivers to the SQL Server instance. At the same time, it will also cause the steps to configure the cluster to become more. For example, the BizTalk Server configuration of the cluster requires MS DTC being placed in a separate cluster group. For more information on BizTalk Server cluster considerations, please refer to the link to the BizTalk Server cluster white paper with "Appendix A".
No matter which method, it is necessary to ensure that the drive assigned to the MS DTC is approximately 500MB. This drive does not require a few GB space. If the MS DTC is placed on the Arbitration Server, make sure there is still enough space to provide a cluster file. Even if the MS DTC is not currently used, the configuration will be simpler during the initial installation process, and it may be used at any time.
If for some reason, the server's cluster design needs to set another cluster disk for MS DTC. Please refer to Knowledge Base Articles "Q294209 - INF: Re-build and move the MSDTC used by the Failover cluster SQL Server":
http://support.microsoft.com/support/kb/articles/q294/2/09.asp
Other information about MS DTC and Windows clusters can refer to Knowledge Base Articles "Windows 2000 Cluster Server Microsoft Distributed Transaction Coordinator Recovery Technology":
http://support.microsoft.com/support/kb/articles/q243/2/04.asp
SQL Server 2000 cluster group configuration
When using the cluster manager setting group, there is no requirement for any maximum and minimum. Conceptually, the similar entry is placed in a group will be effective, for example:
• Place the cluster IP address, cluster name, and arbitration disks in a group.
• The MS DTC should remain at its default position by default.
• Place the SQL Server IP address of a particular instance, SQL Server Network Name, SQL Server, SQL Server Agent, and SQL Server Full-text resources in their respective instances. The MS DTC can be placed in a group having a primary cluster IP, an arbitration disk, or in a group having a disk having an MS DTC configuration. MS DTC is a shared resource that rely on disk it configures it. However, we recommend not placing SQL Server or any other cluster application with the arbitration disk in the same group. The MS DTC will be an exception because the operating system is placed in this group by default.
SQL Server 2000 failover cluster
Cluster resources can be started on other resources before implementing online. The default installation has the following subordinates (the following table does not mean a group; only lists the default slave of each resource).
Resource slave cluster IP address No group name cluster IP address arbitration without MS DTC cluster name, disk resource (arbitration disk is the default configuration) SQL Server IP address without SQL Server network name SQL Server IP address SQL Server (virtual server itself) SQL Server network Name, Disk Resources associated with this example SQL Server Agent SQL Server SQL Server Full-text index SQL Server
You can add other subordinates to these resources, but in order to make the SQL Server 2000 failover cluster can run normally, there is a basic configuration that cannot be changed. Keep in mind that if there is no correct configuration cluster, any customization exceeds this basic settings may result in a planned failover.
Check the subordinates of resources
1. Start "Cluster Manager", right click on the resource, and then click Properties.
2. In the Properties dialog box, click the Subject tab, and then click Modify.
3. In the "Modify the Benus" dialog, the available resources in the cluster will be displayed in the "Available Resources" list. Select the drive you want to add, click the arrow to move the resource into the "Dependent" list, and then click OK.
4. To verify this resource is now a dependent object, in the Properties dialog box, click the Subjects tab.
SQL Server 2000 Analysis Service and Failover Cluster
The failover cluster does not support SQL Server 2000 Analysis Services (OLAP, and Data Mining) components. For more information, please refer to Knowledge Base Articles "Q254321 - Warnings for Cluster SQL Server":
http://support.microsoft.com/support/kb/articles/q254/3/21.asp
For information on how to implement SQL Server 2000 analysis services, please refer to the White Paper "Creating a large-scale height-available OLAP site": http://www.microsoft.com/sql/techinfo/bi/creatingolapsites.asp.
SQLMAIL and failover cluster
SQL Server 2000 virtual servers do not fully support SQL Mail (SQL mail) because the basic MAPI protocol used does not support clusters. For more information, please refer to Knowledge Base Articles "Q263556 - How to configure SQL Mail":
http://support.microsoft.com/support/kb/articles/q263/5/56.asp
Upgrade from earlier versions of SQL Server clusters to SQL Server 2000 failover cluster
In a highly available environment, upgrading your existing SQL Server may affect availability. Designing a plan that causes the minimum downtime time is a key task. Although it is impossible to ensure 100% of the normal running time during the upgrade process, there are some ways to provide you with more normal runtime. First, consider these issues: • Windows 2000: Is your selected solution still listed in the HCL? If you are not limited to considering SQL Server upgrades, and consider operating system upgrades, then this solution may have been tested and certified for Windows NT 4.0, but may not be tested for Windows 2000.
· If you use replication, you will need to disable / release the feature / release configuration before the upgrade is performed. You need to archive the copy configuration, and write a feet so that you can re-set after the upgrade is complete. For more information on copying, refer to "Backup and Recovery Replicate Database" in SQL Server 2000 Books Online, "Reproduction Writing Scripts" and "Copy and Upgrade".
At the same time, do you also upgrade all the servers participating in the copy? Although this is not required, all work will be better to maximize your work and minimize downtime.
· What is your accident plan? Reliable backups with operating systems and SQL Server databases are important. It is best to buy new hardware and make a new configuration, which can minimize the risk and shutdown time of the production environment. In this case, the hardware needs to be configured, the application, or the Web site will only cause downtime when the database is upgraded. Even you can eliminate downtime. For example, use the previous night backup, then apply changes to the server to the server (if possible). The last point, your upgrade policy must consider the availability of the application and the normal runtime protocol that is reached with the system user.
Upgrade the operating system
Windows 2000 Advanced Server and Windows 2000 DataCenter Server provides some new features to enhance SQL Server 2000, such as: AWE memory and better scalability (for example, more processors and more basic memory). If you upgrade from Windows NT 4.0, Enterprise Edition, you can upgrade directly to Windows 2000 Advanced Server, but you can't upgrade directly to Windows 2000 Datacenter Server. Please refer to the Hardware Compatibility List, check your current cluster solution and component if you are authenticated for use in Windows cluster.
Upgrading from Windows NT 4.0, Enterprise Edition to Windows 2000 Advanced Server is considered a "scroll upgrade". You don't need to disable failover clusters; you only need to transfer all service failures to another cluster node before upgrading the server.
Please upgrade according to the steps given below: //www.microsoft.com/windows2000/server/howtobuy/upgrading/path/winnt4ent.asp
This is a permanent change that cannot be uninstalled. In a development environment, Windows 2000 Advanced Server can be used to test your application for the final Windows 2000 DataCenter Server upgrade.
For more information, please refer to the following resources:
· General upgrade information: http://www.microsoft.com/windows2000/server/howtobuy/upgrading/default.asp · For more information on scrolling upgrade, please refer to: http://windows.microsoft.com/windows2000/ EN / Advanced / Help /
· Knowledge Base Article "Q249735] Error message for upgrading server cluster nodes to Windows 2000: http://support.microsoft.com/support/kb/articles/q249/7/35.asp
· Information about Active DirectoryTM and clusterings, please refer to Knowledge Base Articles "Q235529 - Windows 2000 Domain]: http://support.microsoft.com/support/ KB / Articles / Q235 / 5 / 29.ASP
Upgrade from SQL Server 6.5
SQL Server 6.5 clusters and SQL Server 2000 computers cannot be configured on the same hardware. Unlike the operating system, you cannot scroll up SQL Server. You will inevitably cause downtime. After the version is upgraded, we recommend that all client computers accessing SQL Server 2000 are upgraded to the Microsoft Data Access Component (MDAC) version 2.6, which is a version installed on the server.
To upgrade from SQL Server 6.5, consider the following strategies:
· Rise in the same hardware
If you want to use the same hardware, and determine the hardware used for the operating system you are still listed in the HCL, then refer to SQL Server 2000 Books Online, which gives two upgrade descriptions: activity / passive upgrade and activity / Activity upgrade. The SQL Server 6.5 cluster needs to be released, install the local instance of SQL Server 2000, use the Upgrade Wizard to upgrade the data from SQL Server 6.5, and then upgrade the local instance to the cluster instance. During this upgrade, make sure you use the correct cluster disk for data. Make sure you have a complete list of database server configurations (for example, how to build a database segment, place files, etc.), which you can re-build this server when needed - no need to reinstall the operating system and SQL Server 6.5.
· Start using the new Windows 2000 Advanced Server or Windows 2000 Datacenter Server configuration. Install SQL Server 6.5 (more information, please refer to Knowledge Base article "Q192710 - Install the basic guide to install SQL Server Version 6.5 or 7.0: http://support.microsoft.com/support/kb/articles/q192/7/10. ASP), restore your 6.5 database on a new server and follow the steps described in the previous point. But in the previous point is that this is a better accident plan to cope with the upgrade process. Event, because your old hardware is still in configuration, you can use it at any time.
· Use the new Windows 2000 Advanced Server or Windows 2000 DataCenter Server configuration to start, install the cluster instance of SQL Server 2000. Create an empty database, use Data Transfer Service (DTS) or other methods (such as Bulk INSERT) or overall replication (BCP)) to import data from SQL Server 6.5 into this new database. Same as the previous point, this is a reliable accident plan that can be imported into the SQL Server 2000 that cannot be imported into SQL Server 2000. This may also minimize downtime, because the old server is still completed when the old server is still in use. You should test this method to determine if it will reduce performance or availability. · Consider upgrading SQL Server 6.5 database to SQL Server 7.0, as a transition step, then operate according to the method of upgrading SQL Server 7.0 configuration below.
Upgrade from SQL Server 7.0
Like SQL Server 6.5, SQL Server 7.0 cluster and SQL Server 2000 failover clusters cannot be configured on the same hardware, SQL Server cannot scroll upgrade - this will result in downtime. After the version is upgraded, we recommend that all client computers accessing SQL Server 2000 are upgraded to the Microsoft Data Access Component (MDAC) version 2.6, and the latter is a version installed on the server.
To upgrade from SQL Server 7.0, consider the following strategies:
· Use log delivery. This method assumes that the SQL Server 2000 failover cluster is located on the new hardware. You can manually configure log delivery, upgrade from SQL Server 7.0 configured at least SQL Server 7.0 to SQL Server Enterprise Edition. For more information, please refer to the documentation about the server package. There are a few things to point out here:
· In SQL Server 7.0, sp_dboption must be set to True using the "Pending Upgrade" option using sp_dboption. However, this user will not be able to create indexes or statistics in the database, and errors are generated. This is why the log delivery from SQL Server 7.0 to SQL Server 2000 must be completed within a certain period of time.
• Use Norecovery to restore the database in SQL Server 2000 when returning to the correct point of time database to apply subsequent transaction log backups.
• There is no graphic way to monitor this log delivery, while you can use graphical mode when you implement log delivery between two SQL Server 2000 Enterprise Edition servers. You must query the log delivery table directly.
For these considerations, we recommend that you do not use log delivery between SQL Server 7.0 and SQL Server 2000 because it consumes more time in the product environment.
Log delivery provides the longest normal working time. When upgrading the SQL Server 2000 virtual server, it will be a new production database, and the current production database will be allowed to run and process the request. At the same time, this also provides an unexpected event plan because you don't affect the current production hardware.
To enable the new SQL Server 2000 database, do the following steps:
• Decrease access to the current production database at a given point in time.
• Once all connections are stopped, make sure all transaction logs are applied to this SQL Server 2000 database. • Use the use of the Restore of Transact SQL to implement the database online. This operation can be done on the database after completing the latest transaction log. Or will place it directly at the end of the last transaction log recovery statement.
• Redirect all clients to new databases and servers.
· Test, make sure everything is working properly, open the database for normal use.
· Rise in the same hardware
This process is more direct than similar upgrades in SQL Server 6.5. But you still have to check the operating system you use to determine if this hardware solution is still listed in the HCL. Guides for upgrading activities / passive or activity / activity configurations can refer to "Upgrade to SQL Server 2000 Failover Clusters" in SQL Server 2000 Books Online. If your shared cluster disk does not have the correct logical drive for data, you may have some problems.
If you choose this method, you need special reminders: MDAC 2.6 installed with SQL Server 2000 cannot be compatible with SQL Server 7.0 clusters. So you have to return to SQL Server 7.0 and MDAC 2.5, testing this process in the test environment, and you can re-bound in the production environment. For more information, please refer to the Knowledge Base article "Q239473 PRB: 70Rebind.exe for Windows 2000 and MDAC upgrades on the cluster SQL Server 7.0 server: http://support.microsoft.com/support/kb/articles/ Q239 / 4 / 73.ASP
· Use the new Windows 2000 Advanced Server or Windows 2000 DataCenter Server configuration to start, install a cluster instance of SQL Server 2000. Back up and restore SQL Server 7.0 databases on SQL Server 2000, or use replicate databases. This can also keep SQL Server 7.0 databases complete and implement a reliable accident plan.
· Use the new Windows 2000 Advanced Server or Windows 2000 DataCenter Server configuration to start, install a cluster instance of SQL Server 2000. Create an empty database, use Data Transfer Service (DTS) or other methods (such as Bulk INSERT) or overall replication (BCP)) to import data from SQL Server 7.0 into this new database. Since the old server is still in a configuration, it is also a reliable accident plan that can be imported into the SQL Server 2000 that cannot be imported into SQL Server 2000. This method can also solve any problems with any file or file group location.
Upgrade order
After you understand and evaluate it, after you have the next question, the next question encounters this upgrade in what kind of order? If you perform an operating system and SQL Server upgrade on the same hardware, please upgrade your operating system first. Because you can scroll upgrade, you can still serve the request for the database. During the process of upgrading from Windows NT 4.0 to Windows 2000, make sure to pay attention to each detail, such as running Comclust.exe on each node to ensure a cluster of MS DTC. Even if you use the same hardware and keep the current operating system, you should make sure that it meets the requirements of SQL Server 2000 (eg, a service package version). Upgrading to SQL Server 2000 should be the last step, including recovering all custom configurations (such as copy). Important: Before upgrading the product database, test this process in the test / temporary environment. Before you upgrade in the product environment, you should be sure that all possible problems can be found. Because in a highly available environment, downtime is critical - every minute is important. The most important thing you need to know is how long this upgrade process will take up. Even if you can't test on the cluster, you should also test the upgrade on a single machine, which is better than you don't test.
Upgrade an independent (local) SQL Server 2000 instance to SQL Server 2000 virtual server
Upgrading from a local instance to a cluster instance is achievable. However, you need to pay attention to two points:
· If your hardware is not configured as a cluster, you don't convert it into a cluster. As mentioned earlier here (refer to the "Hardware Compatibility List" section), this solution must be purchased as a cluster.
· If your data is not on the correct cluster disk, or the drive array is not configured correctly, you will encounter the same problem as SQL Server 6.5 and 7.0 upgrades. Before installation, you must ensure that the data is on the correct drive, or can be moved by some way, for example: additional and separation.
If these considerations are not a problem, make sure the Windows computer has been configured, and then upgrade this instance to the cluster instance. For example, how to upgrade, please refer to the default cluster instance from the default instance to SQL Server 2000 (SETUP) in SQL Server Books Online.
Test the installation of the fault transfer cluster
This section provides some methods that can be used to verify that your fault transfer cluster has been properly configured. Please perform these tests before using the fault transfer cluster. We recommend that you avoid interference availability due to tests when ensuring the client connection. For information on information and checklists, please refer to the last appendix d: "Checklist before and after installation".
Test connection and name analysis
To verify that dedicated and public networks are normal communication, do the following steps. Understanding the IP address of each network adapter in the cluster is mandatory, and you need to know the IP address of all IP cluster resources (you can enter this information in the worksheet of this Appendix C).
Version connection and name analysis from server node
This way, describes how to test the IP connectivity and name resolution at the server level.
1. In the "Start" menu of a node, click Run and enter CMD in the text box. Click OK.
2. Enter ping ipaddress / servername, where iPadDress / ServerName is the IP address of the network adapter corresponding to other nodes or the virtual server name of your cluster.
3. Repeat the above operation on each node.
For example, assume that the setting of the IP address is shown in the table below. Node Detection Project Value 1 Public Cluster Connection 199.1.3.16 1 Special Cluster Connection 10.1.1.1 2 Public Cluster Connection 193.1.2.199 2 Special Cluster Connection 10.1.1.2 Uncommon IP Address 199.2.6.4 No SQL Server IP Address 199.6.6 No group name MyCluster
In this example, you can enter ping 193.1.2.199 and ping 10.1.1.2 on node 1, enter ping 199.1.3.16 and ping 10.1.1.1 on node 2. Both nodes should be able to test "Cluster IP Address", "Cluster Name", and "SQL Server IP Address".
Connecting connection and name analysis from client node
This means describes how to test IP connectivity and name resolution on the client.
1. In the "Start" menu on the client computer, click Run and enter CMD in the text box. Click OK.
2. Enter ping ipaddress / servername, where iPadDress / ServerName is the IP address of the network adapter corresponding to other nodes or the virtual server name of your cluster.
In this example, if you still follow the configuration of the above table, you can enter ping 193.2.6.4 and ping mycluster to detect the connectivity of the cluster. To detect the IP address of SQL Server, type ping 199.10.3.6. To detect the connection to the SQL Server using the specified connection or IP to SQL Server, set an ODBC connection or use the client network tool.
Failover confirmation
Finally, execute failover of all SQL Server virtual servers, ensuring that all resources have successfully implemented failover and restart on another node without affecting the normal operation of other groups. There is an exception, that is, if SQL Server uses the arbitrated drive, not the previous recommendation configuration. This test is done through the cluster manager.
1. In the Start menu, execute Programs and Administrative Tools, and then click Cluster Manager.
All nodes configured for failover clusters should appear below the left pane of the cluster manager.
2. Right-click on the group containing the SQL Server resource (such as: SQL Server INS1), and then click Move. This selected group and its resources will move to the preferred failover node. This change will be reflected in the cluster manager.
Inspection service account
In order to make SQL Server can correctly manage and execute its resources, the service account must be part of the cluster ACL. To ensure that the service account is configured correctly, perform the following command in the SQL query analyzer window:
Select * from :: fn_virtualservernodes ()
If there is no output activity, the account that SQL Server runs is part of the cluster ACL.
Maintain SQL Server 2000 Failover Cluster
Maintaining a failover cluster is a very challenging job. For example, how to create a seamless environment, can you work normally no matter which node has a SQL Server process? This section will introduce some items that need to be noted when maintaining a cluster environment.
Manage SQL Server Virtual Server
There are four ways you can use to manage your SQL Server virtual server. It is important to understand the similarities between these tools and different points, so you can choose the most appropriate tool.
· SQL Server tool, especially SQL Server Enterprise Manager
SQL Server Enterprise Manager and other SQL Server tools should be used to manage the database. All accounts and passwords associated with SQL Server and SQL Server Agent should be modified in Enterprise Manager. If you need to change the port number, use the server network tool. Other SQL Server tools are used as for non-clustered examples. · SQL Server installer
To uninstall a virtual server, add or remove nodes participating in a failover cluster, or change or add a failover cluster, use the SQL Server installer.
· Cluster Manager
This is an operating system level tool located in the management tool. Prior to SQL Server 2000, most of the configuration changes for SQL Server clusters are done in the Cluster Manager. Please use the cluster manager only in this article, to ensure the correct use of SQL Server 2000 failover clusters. Do not use the Cluster Manager to add the node to the resource definition, or to change the IP address.
· Command line Cluster utility
The Cluster command line tool is basically an operating system command line interface that most of the cluster manager. Like the cluster manager, this tool is only used when necessary.
Windows 2000 Datacenter Process Control and SQL Server 2000 Failover Cluster
Important: Do not use process control to modify the SQL Server virtual server configuration. Process control is not a application that supports cluster. When failover, the virtual server modified on a node will not be able to automatically inherit the limit control from the fault node. Use the tools provided by SQL Server Enterprise Manager and other SQL Server to modify the SQL Server virtual server configuration.
For more information, please refer to Knowledge Base Article "Q296382 - Windows Datacenter Server Process Control Service does not support cluster":
http://support.microsoft.com/support/kb/articles/q296/3/82.asp
Backup and recovery
Although the backup of the database in the cluster environment is not completely different from the backups in the regular server, it is undoubtedly more complicated. Then how should you handle this situation? When a cluster is configured, it is usually applied to a large-scale task database. Backup and recovery databases in the range of thousands of Bikhai can not be like you to handle 10 MB databases, although many people try to be equal. Here is a few common best practices:
· Frequent backup.
• Store backup files, such as saved on a tape or other medium.
• Test all backups and understand the time required for backup recovery. This is when there is an emergency, you don't know how this backup is intact, but also knows how long it takes to recover. Understanding this information is critical when some server failures appear.
Important: Do not use the arbitral drive to store backups.
Back up to disk and tape
In general, the first backup to the disk is the easiest. Create a cluster disk share so that all nodes can access this backup share when there is a failover. Do not attempt to back up to any local drive. After backing the database backup, it should be copied to another, back up to other media (eg tape), and then stored in a separate position after testing and inspection. Backup in a high-reliability environment is to eliminate single point failure. So if you have backed up and just save it on a location of the drive, use RAID, what should you do when you encounter an array failure? Although this happens is small, we must consider the worst situation.
Another method is to perform two steps in the backup work. Two backup methods (for example, tape drives, and shared cluster disks). Set your maintenance plan and then change the backup task. If the backup is successfully completed on the steps, then exits; however, if the backup fails (for some reason), the second method is enabled. This will ensure that there is no single point failure in your backup policy. Snapshot backup
One of the backup and recovery clusters SQL Server methods is to use snapshot backups. SQL Server 2000 supports this backup method. First, mirror your disk, then interrupt the entire group disk image, and use them as a backup. Snapshot backup requires a special hardware; SQL Server 2000 supports this backup.
Example
TerraServer (http://www.terraserver.com/default.asp) is a WEB site that provides a geographic aerial photograph and a map of the map, which is provided by the US Geological Survey. Now their database has data close to 2 megabytes, using the SQL Server 2000 failover cluster of Windows 2000 DataCenter Server and N 1 scenarios. You can imagine that this large-scale database (VLDB) backup must be carefully planned.
TerraServer chose snapshot backup. In addition to RAID, they also have 3 disk mirrors (like 3 neatly arranged magnetic rolls). That is to say, the hardware has three synchronized data copies. But at a moment, one of the mirror groups were interrupted, and eventually became a backup of the database. When the mirror is interrupted, it will no longer keep synchronization, and SQL Server can't see it again. SQL Server 2000 has sufficient intelligence that can respond to this situation and reasonably handle its memory buffer. Then they use tape solutions to back up this magnetic roll. At some point, put this disk back so that you have three images. Then constantly repeat this process.
Back up the entire cluster system
It is not enough to back up your SQL Server 2000 database. You must back up the entire system at the same time. It is also important to back up the system status of the Windows cluster. When you need to recover, the system status is restored after the operating system is installed on your computer. This backup requires a backup program that supports cluster. Some third-party developers provide this service.
Consider the following native tools:
· NTBACKUP.EXE: This tool backup and recovers the cluster configuration, including arbitration disks and system status. This tool does not apply to the remote server. If the server is running a cluster service, the system status data should also include all resource registry checkpoints and arbitration resource recovery logs. In this log include the latest cluster database information.
· ClusRest.exe: This tool restores the backup arbitration log content to the active arbitral disk.
• Clustool.exe: This tool backs up and restores some parts of the cluster configuration. It also includes a tool for transferring single-alone files and print sharing to a cluster, but cannot resume some core resources, such as cluster IP addresses, cluster names, and arbitral disks. You can get this tool from Windows 2000 Server Resource Kit (/ Apps / ClustOOL /). This tool replaces Clusconb.exe.
• Dumpcfg.exe: This tool backs up and recovers disk signature, which is part of Windows 2000 Server Resource Kit.
• Cluster Automation Server: This is a series of ActiveX® controls for assisting cluster services, part of Windows 2000 (MSClus.dll). If you use Windows NT 4.0, you can get this tool from the Windows 2000 SDK installation CD (Redist / Cluster / NT4 / i386). The previous mentioned considerations on backup to disk and tape should still adopt: Make sure that there is no free failure, all nodes can access the same device in the same way.
Make sure the virtual server does not fail because other services fail
In order to avoid failures of certain services, the SQL Server group is faulty, please use the Cluster Manager to properly configure these services. Please refer to step 4 in the "Resource Configuration Threshold" section in the previous article. For example, if you do not use SQL Server full-text indexing function in your solution, you should make sure that the "Impact Group" parameter is not selected in this resource attribute.
Add, modify or update TCP / IP addresses
Before SQL Server 2000, if the SQL Server cluster is implemented, the modification of the TCP / IP address needs to be released in the SQL Server cluster. To modify the TCP / IP address in SQL Server 2000, run the installer again. In addition, since SQL Server 2000 has added support for multi-NIC / IP addresses, more TCP / IP addresses can be configured for instances. However, you must limit that each subnet can only have an IP address. For example, if you have internal and external users accessing this instance, you can assign both different IP addresses for SQL Server to maximize network applications, and simplify tracking of SQL Server instance usage.
To add, modify or update TCP / IP addresses
1. Insert the SQL Server 2000 Enterprise Edition installation CD in the CD-ROM drive, select "Install SQL Server 2000 Components".
2. Click Install SQL Server 2000 Components, click Install Database Server, and then click Next.
3. In the Computer Name dialog, select "Virtual Server", enter the name of the existing SQL Server 2000 cluster instance
4. In the Installation Selection dialog box, select Advanced Options, and then click Next.
5. In the Advanced Options dialog box, select "To Fault Transfer Cluster Maintenance Virtual Server", then click Next.
6. In the Failover Cluster dialog, you can add or delete the TCP / IP address from the selected SQL Server 2000 instance.
To delete a TCP / IP address, select this address, and then click Delete.
Note that the SQL Server 2000 instance in the failover cluster requires a TCP / IP address to work properly. Remove only when there is more than one TCP / IP address, and to make sure it does not affect the user or application to access SQL Server.
To add a TCP / IP address, enter the new TCP / IP address in the IP Address box, select the network used, and then click Add. This newly added IP address will appear behind the IP address.
7. In the Cluster Administration dialog box, click Next.
8. In the Remote Information dialog box, enter the username and password for the domain administrator account for the SQL Server 2000 cluster instance, and then click Next.
9. After ending this process, click Finish.
Add or delete cluster nodes from a virtual server
Another new feature of the SQL Server 2000 failover cluster is to be able to add or delete cluster nodes from the SQL Server virtual server definition. Add a node to an existing SQL Server virtual server definition that requires all necessary an operations on a new node (including installing new binary, system components, and creation services) and requires the necessary modifications to the cluster configuration. To add or delete a node
1. Insert the SQL Server 2000 Enterprise Edition installation CD in the CD-ROM drive, select "Install SQL Server 2000 Components".
2. Click Install SQL Server 2000 Components, click Install Database Server, and then click Next.
3. In the Computer Name dialog box, select Virtual Server to enter the name of the existing SQL Server 2000 cluster instance.
4. In the Installation Selection dialog box, select Advanced Options, and then click Next.
5. In the Advanced Options dialog box, select "To Fault Transfer Cluster Maintenance Virtual Server", then click Next.
6. In the Failover Cluster dialog box, click Next.
7. In the Cluster Administration dialog, select the appropriate node you want to add or remove from the cluster, and then click Next after you complete.
8. In the Remote Information dialog box, enter the username and password for the domain administrator account for the SQL Server 2000 cluster instance, and then click Next.
9. After ending this process, click Finish.
Rename SQL Server 2000 Virtual Server
Rename the SQL Server 2000 virtual server is neither possible and is not supported. The only way to delete the virtual server is to uninstall it.
Apply SQL Server 2000 service pack
As mentioned earlier, SQL Server 2000 no longer requires you to release the SQL Server cluster when applying the service package. We recommend that you read its documentation file before installing the service pack, which may contain special information about this service pack. For example, SQL Server 2000 Service Pack 1 needs to restart after installation, which will affect availability. In addition, please consider the following questions before installing the service pack on the virtual server:
· Using a service package to upgrade the virtual server and upgrade a separate SQL Server. You must repeat the installation process of this service package on all virtual servers in the Windows cluster. The installer will upgrade the basic components of all nodes in the virtual server definition.
· The failover cluster resource of the selected virtual server must be in the online status and run successful service pack installation.
· In the upgrade process, the selected virtual server will not be able to respond to the client request. An additional service pack may also need to restart the failover cluster node. Please plan to plan this habitat, so that your end user knows so that they can specify their plan according to your plan.
· Read instructions, understand which components have been upgraded in the service package. However, if the MS DTC is one of the upgrade components, more than one virtual server in the cluster uses MS DTC, then other virtual servers may be affected during the selected virtual server upgrade process. This is because MS DTC is a shared resource in the cluster.
· Before installing the service pack, back up all systems and user databases and confirm that the system database has sufficient free space.
· To restore the SQL Server version before the service package installation, you need to uninstall the virtual server, reinstall SQL Server 2000, and then recreate your user database by additional or resume.
Troubleshooting of SQL Server 2000 Failover Clusters Troubleshooting the fault transfer cluster configuration in SQL Server 2000 is different from the standalone server. First, you need to check if hardware, operating system, and Windows clusters work normally. Then, if all of these are in a good condition, check SQL Server. For more information, please refer to "Fault Transfer Cluster Trouble Diagnosis" in SQL Server Books Online.
Service level agreement
Please confirm that your service level protocol (SLA) between your hardware and software developers satisfy the level of support you need. Since the failover cluster is usually a key task production system, the SLA that is guaranteed to achieve reduction in 48 hours may not be so effective. The price that supports the contract will also be different depending on the length of the downtime. In a production environment, you must first call support before troubleshooting. Because troubleshooting may increase downtime, for example, in a state where the server is stopped.
first step
Check the application, system, and security log in the Operating System Event Viewer. Sometimes the problem is obvious, such as disk or network card failure, or operating system or SQL Server may give relevant error messages. Then, check the cluster log that these logs are set in the system variable% clusterlog% (usually // WinNT / Cluster). These files contain these files:
· SQLSTPN.LOG. SQL Server installed log, where n is the number of installation attempts.
· Sqlclstr.log. The log of the SQL Server cluster instance.
Cluster log owner file.
For complete instructions for enabling and disable logs, refer to Knowledge Base Articles Q168801 "How to Enable Cluster Logs in Microsoft Cluster Server: http://support.microsoft.com/support/kb/articles/q168/8/01.asp.
This information is also valuable to call your hardware developer or Microsoft product support service. The more information you provide, the more you will be able to help you solve the problem faster.
Repair single node fault and arbitration disk failure
If a node in the cluster has a fault (due to hardware issues) or the arbitration disk has failed, follow the steps below to rebuild this node, then add it to the cluster:
1. First determine all the cluster resource groups have been successfully moved to another node of the cluster, and then use the SQL Server installer to remove this node from the SQL Server virtual server definition (refer to "from the virtual server definition from the virtual server definition or Delete cluster node "). The installer should be able to detect this deleted node and then automatically move it into the Unavailable Node list.
2. Use the Cluster Manager to expel the server node.
3. Fix this cluster node. This process may need to build a new cluster node or recover from the current backup.
4. Re-add to the cluster.
5. If you use the MS DTC, run Comclust.exe on this node.
6. Run the SQL Server 2000 installer on the node without a problem. From the "Available Node" list, select the projectped node to add it to the "configured node" list.
Note If you try to project a node from a cluster definition from a cluster definition before deleting a node from a SQL Server virtual server definition, it will cause some problems. If a node is expelable, it will not be displayed in the SQL Server installer, so it will not be removed from the virtual server definition from the virtual server definition. If this SQL Server resource DLL remains on the deported node, the cluster may not be correctly added to the possible owner of SQL Server resources after it re-adds to the cluster. This happens is small, but you should still pay attention. Also, if you try not to add this node before you first delete it from a Windows cluster, the SQL Server 2000 failover cluster may be interrupted. Multi-node failure
If multiple nodes fail, but not all nodes, then repeat the front steps to fix all nodes. However, if all nodes are faulty, and the arbitration disk cannot be repaired, you have to re-build all nodes of the group collection. This is also why it is critical for testing and frequent backups.
Re-build Master database in a cluster environment
If you need to rebuild the Master database in the SQL Server 2000 failover cluster, follow these steps:
1. Enter the current node with this SQL Server resource.
2. Use the Cluster Manager to expel the SQL Server virtual server.
3. Make sure you have the original shared installation file or SQL Server installation CD.
4. If you use the SQL Server installation disc, copy all files from the disc to your local hard drive. After copying to the hard disk, the read-only properties of all files are released.
5. Execute RebuildM.exe. Point it to the original shared installation file or copy it from the CD to the local hard disk.
6. Select Windows or SQL proofreading.
7. In RebuildM.exe, confirm that the resource can be set to online, and they have successfully transferred.
8. Execute the sp_helpsort checking process.
These steps do not include the steps required to process the user database. In this case, SQL Server 2000 is newly installed, including only databases loaded with SQL Server. If you have the current backup of the Master database, you may be able to recover it now. If you don't have a backup, you will have to recover or attach the user database.
Common trouble diagnosis
In this section, some common issues and solutions that implement failed transfer clusters are described.
Q: When the installer tries to install SQL Server binary on other nodes, the result failed (possibly with an error message that failed with a login request). Why is that?
A: If you install it from the web share, confirm that all nodes can access the sharing, and do not need to specify the network password (for example, you should not need to specify a certificate to view). If you installed on the CD-ROM drive from Node A, confirm that the cluster node is configured to perform normal communication, each node has a correct account, and other nodes are set to perform Windows authentication. Maping a drive letter does not work, even if all nodes use the same drive letter, this is because the installation process needs to access the shared UNC path.
Q: After installing and restarting the server, SQL Server installation seems to still have not completed it. why?
A: Sometimes because the lock starter (such as: MDAC) can cause the file to rename; therefore, if the file is still read-only, then the installation process will not be completed.
Q: MSCs cannot connect to my SQL Server virtual server. why? A: This may be because the process used to perform Isalive checks run in the MSCS service account environment. This account must have SQL Server sysadmin permissions. If this is not this, use the cluster log to check all logins and before and after, check if there is Isalive check.
Q: There is a problem when changing the network name of SQL Server after installation. How to solve it?
A: SQL Server is bound to the network name used by itself with the installation. If you need to modify for some reason, a complete reinstallation is required in the current situation.
Q: After the new SQL Server virtual server is installed, the client cannot connect to this server, especially when using a graphical user interface (GUI) tool. why?
A: You need to refresh the DNS and WINS servers to identify new SQL Server 2000 virtual server installations, which requires some time. In some cases, you need to manually insert the relevant entry in the DNS and WINS profiles.
Q: Microsoft Exchange 2000 and SQL Server 2000 are installed in "My Cluster"; but it seems that the full-text service of SQL Server cannot be run. why?
A: If both must coexist in the same cluster (although we do not recommend this), first install Exchange 2000, then install SQL Server 2000.
Q: I have encountered some problems in the full installation of the fault cluster. What is wrong?
A: In some cases, the installation process may fail because there is no basic Microsoft search service. If this is the case, you may need to create this type and install it next time. To create this resource, perform the following commands in the command prompt:
CD% windir% / cluster
Regsvr32 Gathercl.dll
Please confirm that this file is registered on all nodes. You can re-run the installer, everything should work properly.
to sum up
SQL Server 2000 Failover Cluster is a primary approach to providing high availability for your database, providing full transaction consistency and automatically failing to other nodes. You can get up to 99.999% availability by eliminating a single point failure (software level and hardware level) and specifying the right process and disaster recovery program.
Appendix A - Other information
For more information on failed transition clusters, please refer to the following resources:
· Microsoft SQL Server Home: http://www.microsoft.com/sql/
· Microsoft SQL Server 2000 Operation Guide: http://www.microsoft.com/technet/treeview/default.asp? URL = / TechNet / Prodtechnol / SQL / Maintain / Operate / Opsguide / Default.asp
· More information about Windows clusters, please refer to "Windows Cluster Technology: Cluster Service Architecture": http://www.microsoft.com/windows2000/techinfo/howitworks/cluster/clusterarch.asp
• For more information on failed transfer clusters and SQL Server 2000, please refer to SQL Server 2000 Books Online. · More information about Windows NT 4.0, Enterprise Edition Server, please refer to httserver/productinfo/enterprise/default.asp; information about Windows 2000 Advanced Server and Datacenter Server Please refer to http://www.microsoft.com/windows2000/technologies/clustering/default.asp
· For information on the Windows NT Server 4.0 High Availability Operation Guide, please refer to http://www.microsoft.com/ntserver/techresources/deployment/ntserver/highavail1.asp.
· More information about BizTalk and clusters, please refer to White Paper "Deploy BizTalk Server: Cluster Consideration":
Http://www.microsoft.com/biztalk/techinfo/deployment/wp_clusteringconsiderations.asp
· MSDN® Developer Program: http://msdn.microsoft.com/
· More information about SQL Server 2000 capacity planning, please refer to Microsoft SQL Server 2000 Administrator Guide: http://www.microsoft.com/mspress/books/4519.asp
· Microsoft supports service Web site (including technical articles and downloadable updates): http://support.microsoft.com
Appendix B - Step by installation of new virtual servers into the guide
This section describes how to install a new SQL Server 2000 virtual server.
1. Definition according to the module, close all unnecessary possibilities to interfere with the service. You can create two batch scripts that can start and stop these servers if needed.
2. Insert the SQL Server 2000 Enterprise Edition installation disc in the CD-ROM drive.
3. When the disc menu appears, click SQL Server 2000 Components, and then click Install Database Server.
4. In the Welcome dialog box, click Next.
5. In the Computer Name dialog box, click the Virtual Server, type the network name of your cluster virtual machine, and then click Next.
6. In the "Name" box of the User Information dialog, type your name; in the "Company" box, enter your company name. Click Next.
7. In the Software License Agreement dialog box, review the End User License Agreement, and then click Yes.
8. Enter the "IP address" for the virtual server, select the cluster network from the "Network" drop-down list. After completing, click Add. Your entry will be displayed in the window at the bottom of this window. You can add multiple IP addresses at once. Click "Next" to continue installing.
9. In the Cluster Disk Selection dialog box, select the disk that places the data file. Adding an additional drive must be completed before installation, which has been introduced in the "Add Logical Disk in Cluster Configuration" in this white paper. Click "Next" to continue installing. If you configure a single-node cluster using the "-localquorum" switch, the only available drive is an arbitration disk. At the same time, you will see a message similar to the following. In the product environment, don't use the arbitration disk for data or logs.
10. In the Cluster Administration dialog, you can add or delete the cluster node from the virtual server definition. Click Next.
11. In the Remote Information dialog box, enter account information for configuring and manage server clusters. Click Next.
12. In the Examples dialog box, click Default, install the default instance, or do not select this item, enter a unique name for this instance in the Example Name input box. Click "Next" to continue installing.
13. In the Target Folder area area of the Set Type dialog, confirm that the Program Files locations on each node are set to a valid local drive (for example, C: / Program Files / Microsoft SQL Server), And confirm the "Data File" location is configured to be selected in the "Cluster Disk Selection" dialog box. If you need to specify a directory on the data configuration drive, click the Browse button. Click Next.
14. In the Service Account dialog, select "Each service uses the same account" or "customize each service". Enter your password in the Password box. Confirm "User Name", "Password", and "Domain" set the correct value. If you have selected "all services custom settings", you need to enter "User Name", "Password", "Domain" for SQL Server and SQL Server Agent services. Click Next.
15. In the Authentication Mode dialog, select "Windows Authentication Mode" or "Mixed Mode". If "Mixed Mode" is selected, you need to enter the password for the SA account. Click Next.
16. In the Start Replication File dialog box, click Next.
17. In the Select Licensing Mode dialog box, select the correct license scheme, enter the correct value, click Continue.
18. A installation prompt box is displayed during the SQL Server 2000 virtual server installation process.
19. In the Installation Complete dialog box, click Finish. If you try to restart your server, verify that you restart all the nodes in the cluster.
Appendix C - Configuration Worksheet
Server cluster configuration worksheet
The server cluster has at least two nodes, up to 4 nodes (only for Windows 2000 Datacenter Server). When configuring a server cluster using the Cluster Services Configuration Wizard, you can configure a worksheet using the server cluster.
Parameter Value Cluster Name Cluster Area Administrator Account Group Square Administrator Password DNS Server WINS Server Cluster IP Address Cluster IP Subnet MS DTC Network Name (NT 4) MS DTC IP Address (NT 4) MS DTC Subnet (NT 4) The number of arbitration driver dispense nodes is used by the bus reference "SQL Server 2000 Failover Capacity Disk Configuration Works"
Node configuration worksheet
This worksheet can be used to configure each individual server before clustering. When using the Cluster Services Configuration Wizard to configure a server cluster, use this worksheet with the server cluster configuration worksheet.
Parameter Value Node Memory Processor Quantitative Server Name Public IP Address 1 Common IP 1 Subnet Public IP 1 (Supply of Cluster Network Configuration Wizard) Network Name: Allow Client Access (Public Network) All Communications (Special and Public Network) Applicable to NIC speed 10 100 for public IP 1: Public IP Address 2 Public IP 2 Subnet Public IP 2 (Supply Cluster Network Configuration Wizard) Network Name: Allow Client Access (Public Network) All Communications (Special And public networks) Suitable for public IP 2 NIC speed 10 100 other values: dedicated IP address dedicated IP subnet dedicated IP (for cluster network configuration wizard) Network name: Allow internal cluster communication (private network) to apply to private networks NIC speed 10 100 Other values: SQL Server 2000 Virtual Server Configuration Worksheet
Currently, up to 16 instances on a server cluster (1 default, 15 specified or 16 specified). The information in this worksheet is arranged in the order in the setup process.
Parameter Value Example Number Virtual Server Name IP Address 1 Network (IP 1) IP 2 Subnet Used Network (IP 2) Data / Log Disk Location (One Used During the Settings;) ) Cluster definition / preferred owner order (virtual server-defined node section) Cluster Administration Information User Name: Password: Instance Type The default specified specified If it is formulated, please give an instance name: Program file location (in all nodes) The same location of the built-in drive) SQL Server Administrator Account SQL Server Administrator Password SQL Server Agent Administrator Account SQL Server Agent Administrator Password Authentication mode Windows mixed if it is mixed, please give a SA password: license mode Position Each processor value: The required SQL service (resource "affected group" attribute; modified after installation) SQL Server Agent Service SQL Server Full-text Service Allocated to the instance of memory (modified after installation) will be used for mobile To other disks of the SQL Server group, then add a slave disks (after installation)
Shared Cluster Disk Partition Configuration Worksheet
This worksheet will help you configure your shared cluster disk array at the hardware level. It should be noted that the disk arrays used by various developers may vary, but the concept is usually the same.
"RAID Partition" is a disk logic combination in a shared cluster disk array. "RAID Configuration" is a RAID configuration type used when configuring the disk. "Disk Type" is the basic drive size of each drive as part of the RAID partition. The "number of disk" is the number of physical drivers that form the RAID partition. "Partition Size" is the space size that the operating system can use.
Example:
RAID partition RAID Configuring Disk Type Disk Quantity Partition Size A Band Mirror (1 0) 18 GB 6 54 GB
RAID partition RAID hierarchical disk type disk quantity partition size
SQL Server 2000 Failover Cluster Disk Configuration Worksheet This worksheet will be a brief reference as an operating system configuration. This operating system should not be placed in a shared cluster disk. At least two logical disks are required here: an arbitration, another for SQL Server data (at least one per instance). All other configurations depends on the specific needs you are configured. At the same time, you need to remember that when you fill in this worksheet, consider configuring all mapped / shared drives, CD-ROMs, etc. All disks must be configured to basically, rather than dynamic, must be formatted as NTFS format. Please use this worksheet with the Shared Cluster Disk Partition Configuration Worksheet.
"Logical Disk" is the drive device that the operating system will use, which is SQL Server to resolve. "Size" is the size of the logical disk. "RAID Partition" is the RAID partition used (refer to "Shared Cluster Disk Partition Configuration Worksheet") - You can set multiple logical disks on a RAID partition. "Owner" is used to enter the owner of a particular logical disk. "Use" is used to input the drive.
Example entry:
Logical Disk Size RAID Partition Owners Uses C: / 18 GB A Local System OS, Page File, SQL Server Executioner - Built-in Drive Q: / 500 MB B Server Cluster Arbitration - No Consider Physical Partitions R: / 54 GB C Example 1 Transaction Log S: / 162 GB D Instance 1 Data File
This example shows that the drive S: / will format it into a 162 GB of data partition. I don't need to create a device for your SQL Server 2000 database to populate this 162 GB entry. Correctly set your device size and plan it for its extension.
Logical Disk Size RAID Partition Owners Uses C: / D: / D: / F: / G: / H: / i: / J: / K: / L: / M: / N: / o: / P: / Q: / r: / s: / t: / u: / v: / w: / x: / y: / z: /
Appendix D - Checklist before and after installation
WINDOWS cluster installation checklist before installation
This check will help determine if you have prepared to install server clusters.
Activity passes the Node 2 (for Datacenter) Node 2 (for Datacenter) Node 2 (for Datacenter) (only for Datacenter only) Node 3 (for Datacenter) (only for Datacenter) Node Terfeter Each Network Adapter 1 Node 2 Node 3 (For Datacenter) Node 4 (For Datacenter) Node 1 Node 2 (for Datacenter) Node 4 (for Datacenter only) Never in the cluster Computer Verify the address of each network adapter on each node to verify each node 1 Node 2 Node 2 Node 2 Node 2 Node 2 (for Datacenter) Nodes 1 Node 2 (for Datacenter) Node 1 Node 3 (For Datacenter) Node 4 (for Datacenter only) Name 1 Node 1 Node 1 Node 1 Node 2 Node 2 Node 2 Node 1 Node 2 Node 2 (only for Datacenter) node 3 (for Datacenter) nodes in all nodes 4 (For Datacenter) Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter only) Check if all nodes can see if the cluster disk (one server starting a server) Node 1 2 Node 3 (only Datacenter) Node 4 (for Datacenter) Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter only) Test if the cluster disk is formatted to the domain-level administrator account created for the management server cluster WINS server already Configuring the DNS Server has configured to add / 3GB or / PAE settings in Boot.ini (if you use extended memory) to your heartbeat NIC NetBIOS Node 1 Node 2 (for Datacenter) Node 4 (for Datacenter) Node 1 2 Node 3 (For Datacenter) Node 4 (for Datacenter only) Enable NetBIOS Node 2 Node 2 (for Datacenter) Node 4 for public NICs (For Datacenter) Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) NIC settings (speed, dual work, etc.) have configured node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) Datacenter) Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) WINDOWS cluster installation checklist
This check will help you check your server cluster.
Activity passed the Node 2 (for Datacenter) Node 2 (for Datacenter) Node 2 (for Datacenter) Node 4 (only for Datacenter) Node 4 (for Datacenter) Node 4 (for Datacenter) (only for Datacenter) Computer Calibration Cluster IP Address from Cluster All Node Calibrator Network Name Nodes 1 Node 2 Node 3 (DataCenter) Node 4 (for Datacenter) Node 1 Node 2 Node 2 Node 2 Node 2 Node 2 (for Datacenter) Node 4 (only for Datacenter) Never in a cluster computer calibration cluster network name from the cluster All Node Authentic Heartbeat IP Address Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter only) (if Windows 2000, running on each node) Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) Transfer MS DTC to Other Node 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) Node 2 Node 3 (only For Datacenter Node 4 (for Datacenter only) Transfer cluster disk resources to other node nodes 1 Node 2 Node 3 (for Datacenter) Node 4 (for Datacenter) Node 1 2 Node 3 (for Datacenter) Node 4 ( Checklist before installing SQL Server 2000 virtual server only for Datacenter
This check list will help verify that you have prepared to install the SQL Server 2000 virtual server.
Activity passes that there is no interrupt installed in the Event Viewer to be able to move to the SQL Server Management All resources (not required to be domain administrators) all resources will be moved to all nodes on nodes that start execution of SQL Server installation. Access the installation path (if you use a network sharing)
Checklist after installing the SQL Server 2000 virtual server
This check will help you verify the installation of the SQL Server 2000 virtual server.
