Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1122 Part VI Enterprise Data Management Windows failover clustering is not designed to do the following: ■ Provide continuous connectivity: During the failover process, any active SQL Server client connections are broken. Therefore, all noncommitted transactions need to be performed again unless the transactions are handled within the application. If the application is cluster-aware, the failover is completely transparent. ■ Protect data: Implementing SQL Server 2008 failure clustering does not obviate the need to take backups or run consistency checks ( DBCC CHECKDB). Because failover clustering does not protect data, it is still necessary to run backups and restore them on another server, run DBCC CHECKDB ,etc. ■ Protect a shared disk array from failing: Failover clustering is not designed to pro- tect against a disk failure. It is recommended to combine failover clustering with hardware redundancy such as SAN to provide data loss protection. ■ Prevent hack attacks ■ Prevent network failures ■ Protect the server from other potentialdisasters,suchaspoweroutages ■ Provide load balancing: Failover clustering is not like network load balancing. It does not provide any automatic balancing, although DBAs can manually balance the load using Cluster Administrator. Microsoft SQL Server 2008 failover clustering is part of an entire strategy needed to help reduce downtime. Having a failover cluster does not mean that you have a complete high- availability solution. How SQL Server 2008 failover clustering works The clustered nodes use a heartbeat signal to check whether each node is alive, at both the Windows and SQL Server levels. At the Windows level, the cluster nodes are in constant communication, thereby validating the health of all the nodes. After installing SQL Server 2008 failover clustering, the nodes that run the SQL Server resource perform two types of checks: ■ LooksAlive: Every five seconds, it checks whether the SQL Server service is running. ■ IsAlive: Every 60 seconds, it runs a simple Transact-SQL command SELECT @@servername against the SQL Server to determine whether the server can respond. If the LooksAlive check fails, then the IsAlive check is performed immediately. If the IsAlive check fails, then, by default, it will try to restart the SQL Server 2008 resource on the same node once. If it fails to restart, then it will failover the SQL Server 2008 group to another node and restart it on the other node. During failover, Windows Clustering Services stops the SQL Server service on the current node and starts it on the failover node. SQL Server goes through the recovery process to start the databases on the failover node. After the SQL Server service is started and the master database is recovered, the SQL Server resource is considered to be online. The LooksAlive and IsAlive setting should not be touched, and the query select @@servername that IsAlive runs against the SQL Server cannot be changed. Even after a SQL Server resource is online, it may not be ready to accept connections yet, as user databases may still be in recovery. Just like in a stand-alone SQL Server recovery, the length of the 1122 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1123 Clustering 48 recovery process depends on how much activity needs to be rolled forward and rolled back on startup. SQL Server 2008 has two important features, fast recovery and instant file initialization, that can reduce these delays. Fast recovery makes the database available after the REDO phase and during the UNDO phase before it completes. Instant file initialization allows initializing the data files instantly without filling the space with zeros. This feature helps TEMPDB initialization time, as it is recreated every time SQL Server is started. The fast recovery feature is available only in SQL Server 2008 Enterprise Edition. SQL Server 2008 Standard edition does not let users access the database until recovery completes both of the REDO and UNDO phases. Instant file initialization is available in all editions of SQL Server 2008. To use this feature, assign the Windows Perform Volume Maintenance Tasks security privilege to the SQL Server 2008 service account. SQL Server 2008 failover clustering topologies SQL Server 2008 failover clustering supports many topologies, as shown in Figure 48-2. FIGURE 48-2 SQL Server 2008 failover cluster topologies Single-instance cluster N+1 cluster ∗ indicates the active node N+M cluster Multiple-instance cluster Inst1 ∗ Inst2 Inst3 Inst1 ∗ ∗ ∗ Inst2 Inst1 ∗ ∗ ■ Single-instance cluster: Replaces the Active/Passive terminology. A single-instance cluster has only one active instance of SQL Server owned by a single cluster node, and all other nodes of the cluster are in a wait state. Another node is enabled either in the event of a failure on the active node or during a manual failover for maintenance. 1123 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1124 Part VI Enterprise Data Management ■ Multiple-instance cluster: Replaces the Active/Active terminology and has more than one SQL Server instance. SQL Server 2008 Enterprise Edition supports up to 25 instances on the same cluster, and SQL Server 2008 Standard Edition is limited to 16 instances on the same cluster. Although 25 instances is the maximum number supported (in the Enterprise Edition), I have not seen any cluster with that many instances. I have seen a two-node cluster with 13 SQL Server instances, and that cluster had many performance issues because it was not prop- erly designed and did not have enough resources for all the instances. The maximum number of instances will be limited to the resources (processor and memory) on the cluster nodes. A multiple-instance cluster is sometimes misunderstood to represent some kind of load- balancing solution for SQL Server 2008. However, this is not true, as the different instances have distinct sets of databases, and there is no shared state between the SQL Server 2008 instances. ■ N+1 cluster: Has N active nodes and one passive node. For example, if you need three SQL Server 2008 failover clustering instances, then the best scaling solution would require a four-node cluster. Three of the four nodes would run one SQL Server 2008 failover clustering instance, while the fourth node would provide the failover. This configuration enables each of the SQL Servers to use the maximum resources on each node, still providing failover in case one node goes down. SQL Server 2008 Enterprise Edition supports up to 16 nodes on a Windows Server 2008 failover cluster, and SQL Server 2008 Standard Edition is limited to two nodes. ■ N+M cluster: A variation of the N+1 cluster that has more than one passive node, which could be used in the event of failover. The N+M cluster has N nodes hosting applications and M passive nodes that are spare. Enhancements in SQL Server 2008 Failover Clustering SQL Server 2008 failover clustering has a lot of enhancements compared to previous versions of SQL Server failover clustering: ■ Reliable setup experience: The setup process in SQL Server 2008 failover clustering has changed significantly. The fragile remote execution has been removed, which means there is no need for Task Scheduler on remote nodes. By removing the remote execution, Microsoft has simplified the installation process and eliminated the possibility of installation failures due to Task Scheduler issues. ■ Integrated OS and SQL checks: Before actually installing a SQL Server 2008 failover cluster- ing instance, the setup executes many OS and SQL rules on all the cluster nodes to determine whether any common issues can cause the setup to fail. If an issue is found, then it clearly displays the issue along with recommendations. This enables failures to be corrected and the setup to continue. This feature eliminates more than 50 percent of failed installations that Microsoft has seen with previous versions of SQL Server failover clustering. ■ Multiple drive selection: SQL Server 2000 and 2005 failover clustering allows the selection of only one drive for the databases during setup. After setup, additional drives need to be added, which requires taking the SQL Server resource offline, thereby introducing downtime. With SQL Server 2008 failover clustering, the setup allows selecting multiple drives and specifying different drives for SQL Server data files, log files, tempdb, and backup. 1124 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1125 Clustering 48 ■ Independent of MSDTC: Unlike SQL Server 2005, a SQL Server 2008 failover clustering installation does not require configuring MSDTC as a clustered resource. SQL Server 2008 setup checks for MSDTC and displays a warning if it does not find it run- ning on the node where setup is running. If you are not using distributed transactions, then you do not need to configure MSDTC and can safely ignore this warning. People have varying opinions about MSDTC. Some believe that MSDTC should be configured as a clustered resource before installing SQL Server 2008 failover clustering — perhaps because of their experience with SQL Server 2005, which required this. Or maybe they saw the warning and interpreted it as a requirement. However, if it were mandatory, then the setup would display a failure and not a warning. To configure MSDTC as a clustered resource, a unique IP address resource, a unique Network Name resource, and a unique shared disk (min size 500 MB) are required. Why waste these resources if you know you won’t be using distributed transactions? If at a later date you need distributed transactions, then you can configure MSDTC at that time. Full-text and r eplication installed as part of the database engine: There is no option to uncheck full-text and replication on a cluster. This is really nice, as in previous versions of SQL Server failover clustering it was very difficult, if not impossible, to add full-text and replication after the installation on a cluster. Full-text has undergone considerable changes and is integrated within the SQL Server service itself. This means that full-text service is no longer installed as a separate service; rather, it is part of the SQL Server 2008 engine itself. Therefore, there is no full-text resource in a SQL Server 2008 cluster group after the setup is completed. Also, when upgrading a SQL Server 2005 failover cluster to SQL Server 2008, full-text resource is removed during the upgrade. ■ Positioned to enable Sysprep and slipstream: With previous versions of SQL Server, this was not even possible. With the new SQL Server 2008 setup architecture, Microsoft will be able to add this frequently requested feature in the future. The slipstream feature is made available in SQL Server 2008 Service Pack 1. This feature provides the capability to merge RTM and patches (service packs and cumulative updates) and perform a single install. Sysprep is still not supported in RTM or SP1. ■ High availability with Add/Remove node operations: Starting with SQL Server 2008, adding or removing a node from the SQL Server 2008 failover clustering instance does not affect the node on which SQL Server 2008 is running. This increases the availability of the SQL Server 2008 failover clustering instance. ■ Reduced downtime with rolling upgrade and patching: For the first time, SQL Server 2008 failover clustering allows rolling upgrade and patching, which significantly increases SQL Server availability. In client tests, in-place SQL Server 2008 failover clustering rolling upgrade processes incurred an average of approximately two to three minutes of downtime. This is a huge improvement compared to previous versions of SQL Server. ■ Integration with Windows Server 2008 failover clustering features: SQL Server 2008 failover clustering depends on Windows failover clustering, and with the introduction of Win- dows Server 2008, numerous features have been added. SQL Server 2008 failover clustering is integrated with Windows Server 2008 features, offering the following key benefits: ■ Certified cluster solution not required: All the components need to be logoed for Win- dows Server 2008 and the cluster needs to pass all the Cluster Validation tests included in Windows Server 2008 failover cluster. If any of the cluster validation tests fail, SQL Server 2008 failover clustering will detect it before the actual install, and setup will proceed only after the issue is fixed and all the cluster validation tests have passed. 1125 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1126 Part VI Enterprise Data Management If you are implementing SQL Server 2008 failover clustering on a Windows Server 2003 failover cluster, then you still need a certified cluster solution in the Windows Server Catalog. ■ Domain groups not required for setup: To install SQL Server 2005 failover clustering, you first needed to ask your network administrator to create a domain group and place the SQL service accounts in that group. Only then could you proceed with installing SQL Server 2005 failover clustering. Now there is no need for domain groups in order to install SQL Server 2008 failover clustering on Windows Server 2008. You may instead choose to opt for Service Security IDs (SIDs). SIDs is a Windows Server 2008 feature. This means that installing SQL Server 2008 failover clustering on Windows Server 2003 still requires domain groups. ■ DHCP and IPv6 are supported by SQL Server 2008: The new features of Windows Server 2008 failover clustering, such as DHCP support and IPv6, are supported by SQL Server 2008. Although DHCP is supported in Windows Server 2008 failover clustering, I still recommend using static IP addresses. ■ Node support: SQL Server 2008 failover clustering supports the maximum number of nodes (16) supported by Windows Server 2008 failover clustering. SQL Server 2008 failover clustering does not support having OR dependency between IP addresses (that is, nodes in different subnets) even though Windows Server 2008 failover clustering supports it. This basically leaves the same support for geographically dispersed clusters in SQL Server 2008 failover clustering on Windows Server 2008 as SQL Server 2005 failover clustering on Win- dows Server 2003. SQL Server 2008 Failover Clustering Setup There are two options for installing a SQL Server 2008 failover clustering instance: ■ Integrated installation ■ Advanced/Enterprise installation Integrated installation consists of two steps: 1. Create a single-node SQL Server 2008 failover cluster — During this step, setup is run on the first node of the cluster to create a single-node SQL Server 2008 failover clustering instance. After this step, the SQL Server 2008 service is up and running and is ready to accept client connections. A single-node SQL Server 2008 failover cluster is a fully functional cluster except that it does not provide high availability, as it has only one cluster node. 2. Add the nodes — During this step, setup is run again on each additional cluster node that needs to be added to the single-node failover cluster. Advanced/Enterprise installation also consists of two steps: 1. Prepare step — During this step, all cluster nodes are defined and prepared. After this step, SQL Server 2008 is not functional and cannot accept client connections. 2. Complete step — After the prepare step is run, the complete step is run on the cluster node that owns the shared disk to complete the SQL Server 2008 failover clustering instance and make it operational. After this step, SQL Server 2008 service is fully functional. 1126 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1127 Clustering 48 Either option can be used to install a multi-node SQL Server 2008 failover cluster. Integrated installation is the most popular option for installing SQL Server 2008 failover clustering, espe- cially when an operational SQL Server 2008 failover clustering instance is needed after installing on the node. Additional nodes can be added at any time without causing any downtime. Planning SQL Server 2008 failover clustering Before installing a new SQL Server 2008 failover clustering instance, I highly recommend spending a significant amount of time on planning to achieve a high-availability solution. Just installing a SQL Server 2008 failover cluster does not guarantee a high-availability solution. It is just one component of your solution. Because a SQL Server 2008 failover cluster runs on top of a Windows Server failover cluster, ensure that you have a fully functional Windows Server failover cluster and that there are no errors in the Windows event logs (Application and System logs) on any cluster nodes. Refer to the following Microsoft’s whitepapers for creating and configuring the Windows Server failover cluster. A step-by-step guide for a Windows Server 2003 failover cluster: www.microsoft.com/downloads/ details.aspx?familyid=96F76ED7-9634-4300-9159-89638F4B4EF7&displaylang=en A step-by-step guide for a Windows Server 2008 failover cluster: www.microsoft.com/ windowsserver2008/en/us/clustering-resources.aspx A SQL Server 2008 failover clustering instance can run on either a Windows Server 2003 SP2 or Windows Server 2008 failover cluster. SQL Server 2008 failover clustering is not supported on Windows Server 2000. If you are installing a new Windows failover cluster, I recommend implementing a Windows Server 2008 failover cluster because it has more enhancements than a Windows Server 2003 failover cluster. For example, with a Windows Server 2008 failover cluster, you no longer need to purchase a certified cluster solution. Now you can build your own cluster with the hardware you might already have purchased. To be supported, all cluster components must be individually certified for Windows Server 2008, and the cluster must pass all tests in the Cluster Validation Wizard. Once you have a fully functional Windows Server failover cluster, make sure that you have everything you need to install a SQL Server 2008 failover clustering instance. A single SQL Server 2008 failover clustering instance requires the following: ■ Unique IP address: This is the SQL Server IP address that the clients will use to connect to the SQL Server. SQL Server 2008 allows using multiple IP addresses on separate networks, butitdoesnotallow OR dependency even though Windows Server 2008 failover clustering supports OR dependency. SQL Server 2008 supports AND dependency. This means that if multiple IP addresses are used, then all IP addresses must be online in order for SQL Server to be online. If any one of the IP addresses goes offline, then SQL Server will go offline, too. As mentioned earlier, a SQL Server 2008 failover cluster installed on a Windows Server 2008 failover cluster supports DHCP. A dedicated IP is still recommended, though. ■ Unique network name: This is the SQL network name that the clients will use to connect to the SQL Server. If this is a named instance of SQL Server, then you also need the instance name. For example, consider SQL2008\INST1, where SQL2008 is the SQL network name and INST1 is the instance name. Clients will need to use SQL2008\INST1 to connect to this SQL Server named instance. 1127 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1128 Part VI Enterprise Data Management ■ At least one unique shared disk: This shared disk will be used for storing the SQL Server databases. Ideally, you should have at least three shared disks: one for data files, one for log files, and a third for tempdb files. For important databases, you may want to have separate drives for their log files. I do not recommend using the Quorum drive for storing SQL Server databases. If you are planning to have multiple SQL Server instances, then each instance will need its own dedicated shared disk. SQL Server failover clustering instances cannot use the same shared disk, as it is possible to do with stand-alone SQL Server instances. Also, each shared disk needs a drive letter. ■ Mount points: With large databases (usually databases that are more than a terabyte in size) and with multiple SQL Server instances, multiple disks are usually needed, and it is very easy to run out of drive letters. In such situations, you can use mount points, as SQL Server 2008 failover cluster supports mount points. A mount point is a drive that is mapped to a folder and is assigned a drive path instead of a drive letter. Therefore, you can surpass the 26 drive-letter limitation by using mount points. When using mount points, note the following: ■ Make sure that each mount point appears as a cluster resource. ■ The root disk must be added as a dependency for the mount points. ■ Each mount point must be added as a SQL Server dependency. Failure to do this may result in data corruption during failover. ■ Do not use the root directory of the mounted drive to store SQL Server databases. Instead, create another folder on the root directory and then place the databases in that directory. Similarly, do not install SQL Server 2008 on the root directory of the mounted drive. Otherwise, SQL Server may not start. ■ SQL Server service accounts: Each SQL Server clustered service account needs a domain account. For security reasons, it is best to use a separate domain account for each SQL Server service account. Table 48-1 lists the required permissions for SQL Server service accounts. Best Practice Do not give domain administrator or local administrator rights to SQL Server service accounts. It is neither necessary nor recommended. The Lock Pages in Memory policy is disabled by default. This policy determines which accounts can use a process to keep data in physical memory, thereby preventing the system from paging the data to virtual memory on disk. This policy should be enabled on 32-bit SQL Server 2008 only when you need to use AWE memory. On 64-bit SQL Server 2008, only Enterprise Edition can use the Lock Pages in Memory policy. On 64-bit SQL Server 2008, enable Lock Pages in Memory only after thorough testing. 1128 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1129 Clustering 48 TABLE 48-1 Security Requirements for SQL Server Service Accounts Local Security Policy SQL Server SQL Server Agent Analysis Services Adjust memory quotas for a process Yes Yes No Bypass traverse checking Yes Yes No Log on as a batch job Yes Yes No Log on as a service Yes Yes Yes Replace a process-level token Yes Yes No Lock Pages in Memory Yes 11 No No Perform Volume Maintenance Tasks Yes 22 No No 1 For 32-bit SQL Server, Lock Pages in Memory is required for a SQL Server service account only if you are using Address Windowing Extensions (AWE) memory. 2 This is required only if you want to use ‘‘instant file initialization.’’ ■ Domain groups: If you are installing a SQL Server 2008 failover cluster on Windows Server 2003, you need domain groups for the SQL Server service accounts. The domain groups control access to registry keys, files, SQL Server objects, and other cluster resources. SQL Server service accounts must be manually added to domain groups before the setup. There is no rule as to how many domain groups need to be created. Some clients choose to use one domain group for all the SQL Server service accounts for simplicity, while others use separate domain groups for each SQL Server service account for security isolation. It is recommended to add the domain groups to the local permissions on the cluster nodes and not give the local permissions directly to the SQL Server service accounts. If you are installing a SQL Server 2008 failover clustering instance on a Windows Server 2008, you can now use Service SIDs instead of domain groups. Service SIDs functionality was introduced in Windows Vista and Windows Server 2008. It allows the provisioning of access control lists (ACLs) to resources and permissions directly to a Windows service. ■ Domain controller: A SQL Server 2008 failover clustering instance needs a domain controller and is not supported on a cluster node that is a domain controller. It is recommended to have redundant domain controllers, as a single domain controller is a single point of failure; and in a high-availability solution we want to eliminate all single points of failure. ■ Installation media: The SQL Server 2008 failover clustering feature is available in Enterprise Edition, Developer Edition, Enterprise Evaluation Edition, and Standard Edition. Developer and Enterprise Editions have the same features, but Developer Edition can be used for devel- opment purposes only. Enterprise Evaluation Edition is used for short-term testing, as it expires after 180 days. Standard Edition and Enterprise Edition can be used for production purposes. 1129 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1130 Part VI Enterprise Data Management ■ Standard Edition is limited to only two nodes, whereas Enterprise Edition supports the maximum of 16 nodes on a Windows Server 2008 failover cluster. Also, Enterprise Edition supports up to 25 instances of SQL Server 2008 on the same cluster, while Standard Edition is limited to 16 instances. Apart from these limitations, SQL Server 2008 Standard Edition does not have a lot of high-availability features such as fast recovery, online index- ing, online restore, data compression, backup compression, and many more features that are available only in SQL Server 2008 Enterprise Edition and are very important for highly available clustering solutions. ■ SQL Server 2008 failover clustering is supported on x86, x64, and IA64 platforms. The platform for SQL Server 2008 will depend on the Windows Server platform. If you have a Windows Server 2008 x64 failover cluster, then you need SQL Server 2008 x64. SQL Server 2008 x32 failover clustering is not supported on Windows Server 2008 x64. Sim- ilarly, if you have a Windows Server 2008 IA64 cluster, then you will need SQL Server 2008 IA64. SQL Server 2008 prerequisites Before actually starting the SQL Server 2008 failover cluster setup, the following SQL Server 2008 pre- requisites need to be installed on all the cluster nodes: ■ Microsoft .NET Framework 3.5 SP1 ■ Microsoft Windows Installer (MSI) 4.5 ■ Microsoft Windows hotfix 937444 for FILESTREAM (only for Windows Server 2003 cluster) The first two prerequisites (.NET Framework and MSI) are located in the installation media under the redist folder under the respective platforms. For example, .NET Framework 3.5 SP1 ( dotNetFx35setup.exe) for the x64 platform is located in the SQL Server 2008 Developer Binaries\x64\redist\DotNetFrameworks folder. Microsoft .NET Framework 3.5 SP1 needs to be pre-installed on all platforms except for Windows Server 2003 Itanium (IA64). For Windows Server 2003 IA64, install .NET Framework 2.0 SP2, which is also located in the installation media. If you are installing a SQL Server 2008 failover cluster on a Windows Server 2003, you need to download hotfix 937444 from http://support.microsoft.com/kb/937444 and install it on all cluster nodes prior to installing SQL Server 2008 failover clustering. Best Practice To minimize downtime, I recommend the following: Install the prerequisites on passive cluster nodes (meaning nodes where no services are running) first, reboot the node, failover the services to a recently updated cluster node, and then install them on the remaining passive cluster node. For example, say you have a three-node Windows Server 2008 failover cluster with SQL1 and SQL2 running on Node1 and Node2, respectively. First install the prerequisites on the passive node (Node3), reboot Node3, and then move either continued 1130 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1131 Clustering 48 continued SQL1 or SQL2 to Node3. Suppose you move SQL2 to Node3, install the prerequisites on Node2, and reboot. Then move SQL1 to Node2, install the prerequisites on Node1, and reboot. This technique will minimize the downtime and give you more control over moving the services from one node to another. Each failover will incur a downtime of approximately 15 seconds, but because you are controlling the failover, you can schedule it properly. Apart from the prerequisites listed previously, I highly recommend installing the latest SQL Server 2008 Setup Support files. This will enable you to take advantage of known setup fixes that are available and avoid any known issues. To install the latest SQL Server 2008 Setup Support files, download the latest cumulative update for SQL Server 2008 and install it. Note that installing the cumulative update before installing SQL Server 2008 installs only the latest SQL Server 2008 Setup Support files and not the full cumulative update. The next time you are installing SQL Server 2008, setup will see the latest setup support files and use them. As the slipstream feature is available in SQL Server 2008 Service Pack 1 (SP1), you can slipstream SP1 with SQL Server 2008 RTM and install both of them in a single installation. This approach is even better than installing the latest cumulative update, as with a slipstream install of SQL Server 2008 + SP1 you proactively have the fixes not only to the setup but also in other components of SQL Server 2008. There is no need to reboot the cluster node after installing each prerequisite. To minimize the number of reboots, apply all the prerequisites on the cluster node and then reboot it once. Creating a single-node SQL Server 2008 failover cluster After you have finished planning and have applied the prerequisites, you are ready to install a SQL Server 2008 failover cluster. As discussed earlier, a SQL Server 2008 failover cluster setup performs local installation; it has removed remote execution. So the first step is to create a single-node SQL Server 2008 failover cluster. Here are the step-by-step instructions: 1. Launch the SQL Server Installation Center on the cluster node that owns the shared disk resources that you want to use for SQL Server 2008 databases. To launch the SQL Server Installation Center, double-click setup.exe on the root of the SQL Server 2008 installa- tion media. 2. The following message will be displayed if Microsoft .NET Framework 3.5 is not installed: SQL Server 2008 Setup requires Microsoft .NET Framework 3.5 to be installed. Download and install .NET Framework from http://www.microsoft.com/net/ and then rerun Setup OK. 3. Click OK and install all the prerequisites that were discussed in the previous section. 4. Once all the prerequisites are installed, SQL Server Installation Center, shown in Figure 48-3, will be displayed. 1131 www.getcoolebook.com . Windows Server 2008 x64. Sim- ilarly, if you have a Windows Server 2008 IA64 cluster, then you will need SQL Server 2008 IA64. SQL Server 2008 prerequisites Before actually starting the SQL Server 2008. The platform for SQL Server 2008 will depend on the Windows Server platform. If you have a Windows Server 2008 x64 failover cluster, then you need SQL Server 2008 x64. SQL Server 2008 x32 failover. by SQL Server 2008: The new features of Windows Server 2008 failover clustering, such as DHCP support and IPv6, are supported by SQL Server 2008. Although DHCP is supported in Windows Server 2008