Chapter 4, Disk Configuration for High Availability, covered one of the main pieces of the foundation: your disk subsystem. This chapter helps to complete that foundation by providing information about configuring the true software base for Microsoft SQL Server: the operating system. This chapter covers both Microsoft Windows 2000 Server and Microsoft Windows Server 2003.
Before delving into the specific high availability options for the base operating system, there are some basic ideas you need to think about before you install the bits.
Choosing an operating system for SQL Server is no longer as clear-cut as it used to be. The operating system you choose affects the performance you get as your requirements grow. The need to make systems last longer these days makes your operating system choice that much more important.
Your operating system choice should match your SQL Server needs for processor and memory. Table 5-1 outlines the memory and processor support for editions of Windows 2000 Server and Windows Server 2003.
Windows Server 2003 Web Edition is not recommended for use with SQL Server 2000.
Windows Datacenter licenses allow you to run as many instances of Datacenter as you have physical processors through hardware or virtual partitioning. If you think you will ever need to use more than eight processors, a Datacenter version is your only choice, and the price premium is not that great when compared to the overall cost of an eight-processor system. Make sure you work with your preferred original equipment manufacturer to purchase expandable hardware or modular systems to prevent inadvertently being unable to expand the system at some later time.
As you have already seen, Windows Server 2003 (in both Enterprise and Datacenter editions) can be found in both 32- and 64-bit versions. Cosmetically, all versions of Windows Server 2003 look and feel the same, but they are not the same inside because of the different architecture of the 64-bit chips.
What does this mean to you, the SQL Server consumer? There are two main areas that immediately come to mind: processor and memory. From a processor standpoint, even though a 64-bit chip might have double the amount of address bits and might be faster in terms of clock speed than the current Pentium-class machines, that does not guarantee you double the performance. A 64-bit machine should perform better than its 32-bit counterpart , as long as the application was coded to work with the 64-bit version of Windows Server 2003 and the 64-bit version of Microsoft SQL Server 2000. As with most applications, you should test against the 64-bit version of SQL Server 2000 to see what performance gains might be garnered from implementing this chip.
The 64-bit operating system requires a 64-bit version of SQL Server ”you cannot install the 32-bit version of SQL Server on the 64-bit editions of Windows Server 2003.
From a SQL Server perspective, the main benefit of going to 64-bit is how memory is handled: all memory is dynamic under 64-bit, and you can address more than 4 GB of memory without setting any special options in your Boot.ini file. Under 32-bit operating systems, this is not the case. Under 32-bit operating systems, any addressable memory above 4 GB can be accessed only after configuration switches are placed in a system file, and then the application must be coded to recognize that additional amount of memory (which is why you turn on Address Windowing Extensions [AWE] support within SQL Server).
|More Info|| |
Chapter 14, Administrative Tasks to Increase Availability, covers SQL Server 2000 and memory usage in greater detail in the section Memory Management for SQL Server 2000, as it is an aspect of SQL Server administration and configuration that affects all installations.
For SQL Server 2000, when you install the 64-bit edition, you do not get all features and utilities that come with the 32-bit version. For a complete list, see the topic Differences Between 64-bit and 32-bit Releases (64-bit) in the 64-bit SQL Server Books Online.
For information on options, especially tools, that might not be available to you under 64-bit operating systems, see the topic Features unavailable on 64-bit versions of the Windows Server 2003 family in TechNet at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/entserver/unsupported64BitFeatures.asp or in your Windows Server 2003 documentation. If anything on this list is crucial for your environment to run on the same server as SQL Server 2000, you might not be able to use the 64-bit version of Windows Server 2003. For example, at launch time, the .NET Framework is not yet available under 64-bit.
Also, consult the Windows Catalog at http://www.microsoft.com/windows/catalog/server2 for information on 64-bit applications.
For those considering upgrading or doing a new installation of a 32-bit edition of Windows Server 2003, you can only use SQL Server 2000 RTM or Release A with SQL Server 2000 Service Pack 3 or later applied immediately after installing the base SQL Server 2000 software.
If you are upgrading your operating system, you must install SQL Server 2000 Service Pack 3 or later on all of the instances that will run in your server cluster or on the stand-alone server prior to upgrading the operating system.
Windows Server 2003 does not support any other versions of SQL Server ”including Microsoft SQL Server 6.5, Microsoft SQL Server 7.0, and SQL Server 2000 with SQL Server 2000 Service Pack 2 or earlier. You will see the warning shown in Figure 5-1 pop up prior to the installation of SQL Server 2000. During an upgrade, you will see a message similar to that shown in Figure 5-2.
For an operating system configuration that will support applications, you need to configure your disks properly. This involves proper capacity planning, as well as configuring components like the page file and making sure the operating system can see the disks and access them without errors.
Whether you are implementing a server cluster or not, your system disk must be configured properly. It should be of sufficient size to accommodate all of the program files (and other files) you might place on it, the operating system, and potentially the page file. You might even want to make it part of a RAID stripe set to ensure you have redundancy in the event of a disk failure.
|More Info|| |
For information on configuring your page file, see the section Page File Size and Location in Chapter 14, Administrative Tasks for High Availability.
With both Windows 2000 Server and Windows Server 2003, you also have the option to boot from a storage area network (SAN). The storage vendor must support this configuration; otherwise , do not attempt this because you might invalidate your support contract. If you encounter problems booting your Windows system, the storage vendor should be the first point of contact for support. You should take into account the following issues if you want to boot from a SAN, but talk to your storage vendor to get a complete list.
Fibre Channel “Arbitrated Loop (FC “AL) is not supported if you want to boot from a SAN. The SAN must be in a switched environment or directly connected to the servers.
The server must get exclusive access to the disk it will be booting from. No other server should be able to access or see the bootable logical unit (LUN). This means that you need to use zoning, masking, or a combination of the two.
Redundancy can ensure that your system will always be able to see the system disk. This means that using multipathing and multiple host bus adapters (HBAs) will help greatly. However, ensure that the multipath software is on the Microsoft Hardware Compatibility List (HCL) or in the Windows Catalog for your solution.
In a clustered scenario, the SAN needs to be on the multicluster device list if the individual nodes will be booting from a SAN.
For Windows Server 2003, the HBA driver must be a Storport driver, which is new to Windows Server 2003. The manufacturer must code the driver to this.
Booting from a SAN might limit your scalability and recoverability options by putting all of your eggs in one proverbial basket . For example, if you have a two-node cluster and have the shared cluster disks as well as the boot partitions on the SAN, if you lose the SAN, you literally lose everything.
You need to ensure there will not be any I/O performance issues, especially if it is a cluster, because all disk I/O will be going through the same channels to get to the disks.
If you are implementing a server cluster, you might need to take into account the quorum disk, a disk resource for Microsoft Distributed Transaction Coordinator (MS DTC), as well as any application data (such as SQL Server data and log files).
For security, you can encrypt your file system. This is fully supported with a server cluster only on Windows Server 2003. To do this, you must enable Kerberos, and all cluster node computer accounts and the cluster server service account must be trusted.
The security of any server that runs SQL Server should be of paramount concern in your planning and, ultimately, your deployment of that server. You should not put any features on your server that you will not need, and you should uninstall ones you are not using. For example, if you are not using the Web-based query features of SQL Server 2000, you should not configure ”or at least you should disable ” Internet Information Services (IIS) so that it does not consume resources and you will not have anyone trying to access your server.
To assess your security, you can use the Microsoft Baseline Security Analyzer, which is located at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/Tools/MBSAhome.asp . You can download this free utility and run it on your systems to scan for potential vulnerabilities.
|More Info|| |
Security is a topic that can obviously constitute a book (or books) of its own. Use the information provided in this book as a primer and then do more research on your own. See Chapter 2, The Basics of Achieving High Availability, for information on how to think about security in a high availability environment, as well as Chapter 14 for some SQL Server “specific topics. For an excellent resource on configuring secure applications, including securing your operating system, consult the Microsoft Press book Designing Secure Web-Based Applications for Microsoft Windows 2000 . Although this was written for Windows 2000 Server, its usage can certainly be applied to Windows Server 2003. For information on securing your Windows servers, this link for Windows has many links to security- related documents:
Here you can find such topics as Windows Security, Best Practices, Tools and Checklists, and more.
Remember to consider how people will eventually access the server in a production environment. One way to do this is to configure Terminal Services, whereby people can log into your server remotely and do what they need to without physical access to the server. However, if you are going to be employing Terminal Services on a server cluster under Windows 2000 Server, there are a few points you need to consider:
In the event you fail over to another node, all of the information held at the local node is lost, including the Remote Desktop Connection from the client computer. Although Terminal Services and a server cluster can coexist, they are blind to each other.
Terminal Services must be installed only in Remote Administration mode on a cluster node.
Remote Administration mode only allows up to two connections.
Using Disk Management, you might see the following behavior:
If you change a drive letter, the change might not be reflected immediately.
If you create or remove a partition, if you view its properties you will see either the label of the partition is not accurate or the partition is claiming it is only 0 bytes.
If a failover occurs, you might not be able to access a shared cluster disk, or a question mark might be displayed.
To solve the display issues, log out and log back into Terminal server.
Under Windows Server 2003, you should use Remote Desktop Administration to access the nodes. You should not install Terminal Services directly on your cluster nodes when using it with SQL Server 2000 failover clustering.
Any administrator will want to be aware of some new features of Windows Server 2003. These features are described next .
The concept of a server role, which allows your installation to be more geared to a specific use, is new to Windows Server 2003. Server roles that are configured are displayed in Manage Your Server, as shown in Figure 5-3. By default, no server roles are configured when Windows Server 2003 is installed.
|More Info|| |
For more information on server roles in Windows Server 2003, see the documentation that comes with the operating system.
Unless you have a specific need to enable server roles (such as Application Server if you need IIS for some SQL Server features you might be using), you should disable all roles not in use to ensure not only a proper configuration but also to remove any unnecessary components that could cause a security risk to the SQL Server. To disable the roles, follow these steps:
Log on as someone with administrative privileges to the local server.
If Don t Display This Page At Logon has not been selected in the past, the Manage Your Server application appears (as in Figure 5-3). If this screen does not appear, select Start, then Manage Your Server, or under Start, Administrative Tools, select Manage Your Server. Select the Add Or Remove A Role option.
If you want to bypass the Manage Your Server screen, select Start, Administrative Tools, and then Configure Your Server Wizard. When you select Add Or Remove A Role, this is where you are directed.
In the Welcome To The Configure Your Server Wizard page, shown in Figure 5-4, click Next.
Figure 5-4: Welcome To The Configure Your Server Wizard page.
In the Preliminary Steps page, shown in Figure 5-5, click Next. The wizard gathers information about your Windows Server 2003 configuration.
Figure 5-5: Preliminary Steps wizard page.
In the Server Role wizard page, shown in Figure 5-6, all of the server roles that are configured are designated with a Yes next to the name of the server role. To select a server role to remove, select it and click Next.
Figure 5-6: Server Role wizard page.
In the Role Removal Confirmation wizard page, shown in Figure 5-7, make sure that the Summary reflects the operations you would like to perform. When ready, select the Remove The < name of role > Role check box and click Next.
Figure 5-7: Role Removal Confirmation wizard page.
Once the role is removed, a final wizard page confirms the removal, as shown in Figure 5-8. Click Finish to close the Configure Your Server Wizard.
Figure 5-8: Final confirming wizard page.
Repeat this process for all unnecessary server roles.
In your Windows Server 2003 installation directory, there is a directory called Debug. This directory contains a file called Configure Your Server.log that stores any changes made to Windows server roles. There are other log files in the Debug directory that you might also want to audit from time to time.
When you shut down or restart a Windows Server 2003 server, you are asked what you want to do (log off the user , shut down, or restart), as shown in Figure 5-9. You must now select the reason you are stopping or restarting your Windows server in the Option drop-down list, and you must enter a Comment. These will show up in Event Viewer, as shown in Figure 5-10. From a high availability and a security standpoint, these help you assess what has been done on the server. This provides you with an audit trail that can be analyzed later to improve processes and procedures and indicate where more training is needed or how you need to change how you do your work. It might seem annoying for administrators who are used to just shutting down or restarting your servers, but it helps force process into your organizations.
It cannot be said enough: technology is only a small portion of the answer to availability. The largest portion of all possible downtime is related to how you deal with process, procedure, and people.
Figure 5-9: Windows Server 2003 Shut Down Windows dialog box.
Figure 5-10: Entry in Event Viewer.
If you experienced an unexpected shutdown, when Windows Server 2003 restarts, it prompts you to enter what happened , as shown in Figure 5-11. The entry also appears in Event Viewer.