In order to use the FILESTREAM in a clustered environment on a Windows 2003 Cluster you must install hotfix KB937444 from the Microsoft Knowledge Base.. The final difference you will see
Trang 1It is recommended that the domain accounts that will be running the services are put into the domain groups before you run the SQL Server installer Even though the SQL Installer allows you to select the NT AUTHORITY\
NETWORK SERVICE and NT AUTHORITY\SYSTEM accounts to run the services under, the only service that can actually run under these accounts is the SQL Server Browser All clustered services must run under a domain account
On the next page you select your authentication mode, set your sa password, and specify yourself as a member of the fixed server role The Data Directories tab
is the same for a clustered install with the exception that the Data Root Drive and all the other folders listed will be based on the first drive letter selected on the Cluster Disk Selection screen Although the UI will allow you to select from any drive on the system, you will get a validation warning if you attempt to continue past this screen using any drive letters for any fields that are not selected on the Cluster Disk Configuration
If you enable use of the FILESTREAM you will notice that the Allow Remote Clients To Have Streaming Access To FILESTEAM Data check box is checked and grayed out It is disabled because having this access is a requirement of using the FILESTREAM in a clustered environment
In order to use the FILESTREAM in a clustered environment on a Windows
2003 Cluster you must install hotfix KB937444 from the Microsoft Knowledge Base This is not a public hotfix so you will need to open a ticket with Microsoft CSS in order to get the hotfix This hotfix must be installed before the SQL 2008 installer
is run because the hotfix requires a reboot The need for this hotfix is detected only
on the Cluster Installation Rules page and not at the beginning of the process The final difference you will see when installing SQL Server 2008 in a clustered environment is that the Installation Rules page is called Cluster Installation Rules This will check various requirements against the system to ensure that you meet all the required items At this point in the installer the process is the same as the stand-alone installer
After you have completed the installer on the first node of the cluster you must then complete the installation on the other nodes of the cluster Launch the installer from the SQL Server 2008 DVD and return to the screen shown in Figure 6.10 Then
select the Add node to a SQL Server failover cluster option on the menu selecting the
correct instance you wish to install the second node for (if there are multiple instances installed on the primary node) This will install the binaries and registry settings on the other node This action should be taken on all the other nodes of the cluster
Unlike SQL Server 2005 and prior, SQL Server 2008 no longer pushes the installers to each node in the cluster Along these same lines the hotfixes and service packs will also need to be manually installed on each server of the cluster When
Trang 2patching this gives the advantage of being able to perform what is called a rolling
upgrade This allows you to patch the cluster with only two to three minutes of
downtime as each instance is patched separately
The recommended method for installing patches on a SQL Server 2008 cluster
is to patch your active node, test the patch giving you the option of failing over to
an un-patched node if there is an issue Once you are sure that the active node is
working as you expect it to, you can continue to patch the other nodes in the
cluster This new technique gives you the obvious advantage of being able to test
the hot fixes and service packs on one node before deploying them to all the nodes
in the cluster The downside to this technique is that much more work is required
when patching a large multinode cluster
Special Hardware Requirements
Using the Microsoft Cluster Service is a very high-end solution It requires some
fairly specialized equipment, which has a very high buy-in price because of the
costs involved in setting up the shared storage solution There are some less expensive
solutions available but they are far less flexible in the number of servers that can be
attached to them, and the number of machines that you can put in each cluster
The operating system you select also has a large impact on the number of nodes
that you can set up in each cluster
If you use a SCSI storage solution for Windows 2003, you can configure only
a two-node cluster Windows 2008 no longer supports clustering using SCSI disks
If you are using a local fiber channel storage solution or SAN solution, Table 6.1
will show you the maximum number of nodes supported in a Windows Cluster
Operating System Maximum Number of Nodes
Windows 2003 Enterprise Edition 4 nodes
Windows 2003 Data center Edition 8 nodes
Windows 2008 Itanium 8 nodes
Windows 2008 ×86 / ×64 16 nodes
Table 6.1 Nodes Supported in a Windows Cluster
Special Software Requirements
Not all Editions of SQL Server can be clustered using the Microsoft Cluster Service Until SQL Server 2005 only the Enterprise Edition of SQL Server supported
Trang 3clustering Starting with SQL Server 2005 clustering was available under the
Standard Edition The ability to cluster SQL Server using the Standard Edition has been extended into SQL Server 2008 as well This greatly reduces your software licensing costs while still giving you the option to cluster your SQL Server
If you wish to increase your Standard Edition cluster to a three-node cluster or higher, then you will need to upgrade the software version to the Enterprise
Edition of SQL Server before you can increase the size of the cluster
Beyond the two-node limit of SQL Server standard edition, most of your design choices when designing your cluster will be dictated by the version of the operating system you select When configuring your Windows 2003 cluster, you must use static IP addresses, which are all on the same subnet When configuring a cluster under Windows 2008, you may use a DHCP address While Windows 2008 clusters support having the nodes of different subnets, the SQL Server 2008 installer does not have room for a second set of IP addresses, so it is recommended to use a single subnet for your cluster
EXERCISE 6.4
SEt Up SQL SERvER In a CLUStER
If you have access to a SAN, VMware, or Hyper-V, set up two Windows
2003 Enterprise or Windows 2008 Enterprise servers and cluster them Install SQL Server in a clustered configuration.
If you are using VMware and Windows 2003 guest OSes to host your Windows Cluster, there is an excellent walkthrough that will help you set up the shared server stored in the virtual environment without
needing access to a SAN This site assumes that you have ESX server available, but this technique should work with VMware Server, which is
a free download at http://exchangeexchange.com/blogs/bkeane/
archive/2007/07/30/mscs-clustering-invmware.aspx.
If you are using Windows 2008 guest OSes to host your Windows cluster, you will need to present iSCSI LUNs to your guests OSes You can either present LUNs to your guest OSes through a physical iSCSI solution
of by using a software iSCSI target such as Starwind iSCSI target by RocketDivision.
When you are installing SQL Server in a clustered environment, special attention must be paid to the SQL Server Integration Service (SSIS) If you wish to use SSIS
on your cluster you will need to manually install SSIS on each node of the cluster
Trang 4After you install SSIS on each node of the cluster you will need to edit the
config-uration file for SSIS to tell it where the MSDB database is By default SSIS looks
for the default local instance for the location of the MSDB database to which it
wants to connect Because the location of the SQL Instance is a different name, or
possibly has an instance name, you will need to edit the MsDtsSrvr.ini.xml file By
default it is found in the C:\Program Files\Microsoft SQL Server\100\DTS\Binn
folder Open the file in your favorite XML editor (NOTEPAD will do fine) and
find the branch with the xsi:type = “SqlServerFolder” and change the ServerName
child from “.” to your virtual host name that you configured during the SQL Server
Installation The relevant portion of the XML file is shown here
<Folder xsi:type="SqlServerFolder">
<Name>MSDB</Name>
<ServerName>.</ServerName>
</Folder>
TEsT Day Tip
Be familiar with the name of this configuration file The editing of this
file was left out of the SQL Server 2005 exams, but there are questions
about it in the SQL Server 2008 exams.
Manually moving an instance of SQL Server from one node of a cluster to
another is a very simple procedure Simply open the Cluster Administrator and
connect to the cluster Right-click on the Resource Group or any resource within
the group and select the Move option This will Move all the resources within the
Resource Group to another node in the cluster (Do not do this on a production
cluster as there is a short outage while the service is started on the remote
machine.)
If you will be using MSDTC in a clustered environment some changes should
be made to the MSDTC configuration within the Component Services applet in
the Administrative Tools menu Navigate to My Computer and right-click on it
and select Properties Select the MSDTC tab, and click the Security Options
button In order for MSDTC to work correctly in a clustered environment be sure
to select the No Authentication Required option Each server that will be
perform-ing a distributed transaction must be set in this way This will not allow users to
connect to the database without providing authentication credentials, it simply
Trang 5allows a machine to begin a distributed transaction with the coordinator without authenticating against the machine This is a requirement of a cluster only
If you will be using MSDTC on a server, through a firewall you will need to specify the number of TCP ports that RPC can use by following MSKB 250367 (http://support.microsoft.com/kb/250367) In a clustered environment when following this MSKB article you will need to increase the number of TCP ports available to RPC This setting not only sets the number of ports that MSDTC used to talk
through the firewall, but it restricts all RPC communication to the server to these ports The MSDTC monitoring page of the Component Services uses RPC to query the MSDTC services, and the Cluster Administrator also uses RPC to manage the cluster, as does the SQL Server Instance when communicating with the MSDTC service It is recommended that in a clustered environment you increase this number
to at least 100 (from the 20 shown in the MSKB article) if not higher
When considering clustering for your high-availability solution, you need to license only the nodes of the cluster that are actively running SQL Server If you have a two-node cluster and are running a single instance then you need to purchase licenses for only a single node (whichever one has more CPUs if the number of CPUs is different between the nodes) If you have a four-node cluster with three instances and each instance is running on a separate node then you would need licenses for three of the nodes You do not need to license the passive node because
it is considered a cold standby, because the services are not actively running on the machine at the time When the cluster fails over, since it is a single instance that is failing over, Microsoft considers the license to transfer to the now active machine from the formally active machine
Geo-Clustering
Geo-Clustering is a special setup of Windows Clustering where you are spreading the nodes of your Windows cluster between two different data centers usually in two different cities Setting up a geographically dispersed cluster requires extremely expensive storage solutions to configure This is because your storage solution must
be able to automatically replicate the data from the storage solution at the local site
to the storage solution at the remote site This data transfer not only needs to be done, but it must be done in an asynchronous manner in order to keep both sites completely up to date
Under Windows 2003 and prior, setting up a geographically dispersed cluster was even more complex This is because each node of the cluster had to be on the same IP address subnet This creates a problem in most facilities because typically each data center will have a different IP address subnet assigned to them The technique