Windows 2008 Server Clustering

Windows 2008 Server

Clustering

© [email protected]

mailto:[email protected]

Preparing the environment 1

Creating a backend cluster 2

Creating a new domain 2

Configuring shared storage 10

Creating the cluster nodes 13

Building the cluster 18

Creating a virtual File Server 23

Installing SQL Server 31

Destroying a backend cluster 40

Creating a frontend cluster 41

Installing NLB 42

Installing Reporting Services on a front end cluster 47

1 © [email protected] – Windows 2008 Clustering

Preparing the environment

Create a disk of at least 13 GB, setup a virtual server with 384 MB RAM, one local NIC, no sound card

or floppy disk. Install Windows 2008 enterprise edition on it.

Change password to Pa$$w0rd.

Close initial setup window and check the option “do not show this window at login”.

Close the server manager window and check the option “do not show me this console at logon”.

Shutdown the machine and copy the disk. This copy will be used as the disk for the domain

controller, the current disk will serve as a template for the other machines. Start the server when the

copy has been done.

Shutdown the machine with the sysprep command.

Copy the disk to folder SQL1 and move this current disk to SQL2. Rename the original copy of the disk

of this server so it can be booted from its original disk. Boot the server and install the virtual machine

additions.

On the disk for the domain controller, create a folder “sources” and copy the iSCSI Starwind,

NM32_x86_setup.exe, dotnetfx35.exe and SQL Server 2008 executables into this folder. Remove the

virtual machine additions software.

Shutdown the machine with the sysprep command and create two other virtual machines with one

local NIC, no sound card or floppy disk and 768 MB of memory. Use the disks created earlier.


Creating a backend cluster

Creating a new domain

A cluster can only exist in a Windows domain. So the first thing to do is to create a new domain

controller for our domain. This domain controller will also act as our storage box (iSCSI). This means

that two different network cards are necessary: one to connect to the storage and one for the

general network.

Open the settings of the domain controller and adjust following settings:

Memory = 384 MB

Disable soundcard and floppy disk

Add second network card

Set both network cards to “local”

Start the virtual machine. With ‘sysprep’ a server has already been prepared. You can leave the

default selected settings of the first window.


Do not fill in a serial number.

Accept the license agreement.

Type the name of the domain controller: DC


Change the administrator’s password to ‘Pa$$w0rd’.

Configure your server:

Install the virtual machine additions and reboot.

Change the display resolution for easier use and disable the screensaver password of the

administrator account.

Open network connections. Rename the second connection to iSCSI, to first network

connection name must not be changed. Right click on the iSCSI connection and choose

properties. Enter the address 172.0.0.1, disable features for this connection: IPv6, NetBIOS

and DNS registration and file and print sharing.

Change the properties of the second card too: disable the IPv6 protocol and enter following

address for IP4: 192.168.0.1. The subnet mask is filled in automatically.

Start DCPromo to turn this server into a domain controller.


The installation wizard starts. Select the advanced setup mode.

Click next.

DNS is needed to install Active Directory. Select the check box for a default installation of DNS.


Select the radio button to create a new forest.

Enter ‘educ.be’ as name for the new forest.

Accept the NetBIOS name. This name is used by pre-Windows2000 clients and applications that need

name servers for name resolution.


Set the domain level compatible to Windows 2008. A higher functional level of a domain enables

more features in Active Directory.

Click next. You cannot change any setting here because it is the first domain controller in the forest.

A warning is displayed, because the server cannot contact the DNS domain for ‘.be’, the parent

domain of our ‘educ.be’ domain. Click yes to continue.


Click next to accept the default locations for the active directory database and the sysfolder. In the

sysfolder you can save scripts and other files that will be automatically synchronized between all

domain controllers.

Enter the same password (Pa$$w0rd) for the restore mode.

Click next to start the active directory installation.


You can select the checkbox to reboot your server after completion.

Log on after the reboot. Now let’s change some little settings to easy administration:

Change the properties of the administrator account. Set “DomainAdmin” as display name

and change the account too (user logon name). Set “Password never expires”.

Click OK and rename the account as well, this will make sure there is no confusion between

the local administrator on the cluster nodes and the domain administrator. When you

rename the account, you must log off and log on (with [email protected]) again.

You can put the shortcuts for Computer and Network on the desktop.

Because we will have to shutdown and restart regularly, we will disable the Shutdown Event

Tracker. This can be done in the default domain policy. Start Group Policy Management in

the administrative tools menu, browse to the educ.be domain and right click on the default

domain policy. Go to Computer Configuration, Policies, Administrative Templates and select

System. Disable the policy Display Shutdown Event Tracker. Close the group policy.


Configuring shared storage

To create a failover cluster, we need shared storage. We will create a virtual SAN on our domain

controller. Start the starwind software executable in the “source” folder. A trial version of Starwind

can be downloaded from their website. Starwind can be used to offer iSCSI devices. Double click to

launch setup and click next on the welcome screen and the license agreement.

Accept all the default settings and click install. When installed, launch Starwind, a new icon appears

in the notification area of your server. Right click it and choose Start Management. Right click on your

host and select connect. The password is test.

Register the software via the “Help” menu. The key can be found in the “sources” folder.

We will now create 3 virtual iSCSI disks. One for the quorum disk of our cluster, a disk for file sharing

and a disk for SQL Server.

Click Add Device and select Image File Device.


Choose to create a new image.

Browse to the C drive and name the file ‘quorum.img’.

Change the size of the disk to 100 MB.


Deselect Asynchronous mode but select the concurrent iSCSI mode.

Enter ‘quorum’ as target name and click next and finish.

Repeat these steps to create 2 additional disks: files and sql of 100 MB.

You end up with a screen like this:


We will use a dedicated network connection for storage access. Right click on the connection and

choose ‘Edit Configuration’. Enter the interface 172.0.0.1.

Creating the cluster nodes

Time to create the two cluster nodes (SQL1 and SQL2). Do not start the nodes already, we will first

change the same settings as for the domain controller:

Memory: 768 MB

Network card: local only

Sound card & floppy disk: disable

Because a cluster node needs 2 network cards (one for inter cluster communication and one for

public communication) we will add another network card. The cluster nodes must also access the

iSCSI disks on the domain controller, add an extra network card for iSCSI communication. All cards

should have the ‘Local only’ setting. Make sure you do this for both nodes.


Start the first node SQL1.

Follow the same steps as for the domain controller:

Accept the language settings

Do not enter a serial number

Accept the license terms

Enter the computer name: SQL1

Change the administrator’s password into ‘Pa$$w0rd’

Install the virtual machine additions

Disable IPv6 on all network cards, rename them to iSCSI, private and public and assign the correct IP4

addresses (192.168.0.10 for public, 10.0.0.10 for private and 172.0.0.10 for iSCSI).

For the private en iSCSI connections, you do not have to specify a DNS server and you may disable

the NetBIOS over TCP/IP and File and printer sharing. Enter the DNS address and gateway for the

public card (192.168.0.1). Join the computer into the educ.be domain and reboot.

After the reboot, log on with the domain admin account.

Customize the desktop a little bit: put Computer and Network icons on the desktop and disable the

password for the screensaver.

We will connect to the iSCSI disks now. Start the iSCSI Initiator. Click ‘Yes’ to start the iSCSI service.

Click ‘Yes’ to unblock iSCSI communication in the Windows firewall.


Go to the tab ‘Discovery’ and click ‘Add Portal’. Enter the IP address of the domain controller (DC)

and leave the port number.

You’ll receive a connection failure because the Windows firewall on the domain controller will block

this connection.


Go to the domain controller and open the port to the iSCSI service (TCP port 3260).

Go to the ‘Targets’ tab and click refresh, you should see 3 disks. Log on to the quorum disk and select

the checkbox to restore the connection when the computer reboots.

The status changes from ‘Inactive’ to ‘Connected’.

Close the window and go to computer management to format the quorum disk.

Bring the disk online, initialize and format it and assign the volume letter Q for quorum.


Bring the second node online and perform the same actions:

Do not enter a serial number

Name the computer SQL2

Enter a new password: Pa$$w0rd

Install virtual machine additions and reboot

Set iSCSI (172.0.0.11), private (10.0.0.11) and public (192.168.0.11) networks, disable IPv6,

disable properties of the private card. Set DNS and gateway for the public card (192.168.0.1)

Join the server to the ‘educ.be’ domain and reboot

Log on with the domain admin account

Personalize your desktop and disable the password for the screen saver.

Connect to the iSCSI server and log on to the quorum disk.

Bring the quorum disk online, initialize it and assign letter Q.

Install the failover clustering feature on both nodes.

Close all windows on both nodes, they are ready to be clustered. On node A, go to the administrative

tools and start ‘Failover Clustering Management’.


Building the cluster

In the management window, click on ‘Validate a Configuration’.

Click ‘Next’ on the welcome page and add both nodes.

Choose to run all tests. When the process is finished, verify that the configuration passed all tests. If

you see errors on some tests, analyze and correct them and rerun the specific test.

When the configuration validation is ok, you can click on the link ‘Create a cluster’. Click ‘Next’ on the

welcome screen and add both nodes to the configuration.

If you had warnings, you will see a notice that the cluster won’t be supported by Microsoft if you

continue.


In the next screen you must specify a name for your cluster and assign an IP address. The cluster

must have a public address, so unselect the private network. Enter ‘brussels’ as cluster name and

assign the address 192.168.0.20 to the cluster and click ‘Next’.

The last window is the confirmation. Verify that all settings are correct and click ‘Next’.

When the installation process has finished you should see the screen below.


Go to the domain controller and verify if the cluster node has been added to Active Directory.

Exploring the new cluster. In the left column we see different cluster items.

You see that there are no services or applications installed. The cluster group with the quorum drive

is still present but is hidden in the manager.

The two nodes are up and running. When you select storage, you see that disk Q is online and runs

on node B. There are three networks from which one is for internal cluster communication only.

There is a list of cluster events, these are filtered warning and error events from both cluster nodes.

A nice overview is shown when you select ‘brussels.educ.be’.

The quorum configuration is important and has changed significantly since Windows 2008. These are

the quorum configurations that can be set (right click cluster, More Actions):

One option is to use Node majority. In this option, a vote is given to each node of the cluster

and the cluster will continue to run so long as there are a majority of nodes up and running.

A second option is to use both the nodes and the standard quorum disk. In this option, a

common option for two node clusters, each node gets a vote and the quorum, now called a

witness disk) also gets a vote. So as long as two of the three are running, the cluster will

continue. In this situation, the cluster can actually lose the witness disk and still run.

A third option is to use the classic/legacy model and assign a vote to the witness disk only.

This type of quorum equates to the well known, tried, and true model that has been used for

years.

A fourth option, is, of course, to use the MNS model with a file share witness.


Let’s explore every item in more detail now.

The ‘Services and applications’ list is empty because there are none installed. The cluster group is not

shown anymore, but you can visualize it with command line.

When you select a node you get a little overview about system and hardware information.

In the disk overview you can see the disks that are in use by a cluster service or application and other

disks that are present but that are still available for other services or applications. In our case, only

disk Q is present and is used by the cluster as a witness disk, it can therefore not be used by other

services or applications.

In the network tab we can see three networks.

Two are used for internal cluster communication, the other is used for all communications. You can

rename the networks, which can aid to clarify their functions. When you right click on a network, you

can see the functions of the selected network card.


The checkbox ‘Allow clients to connect through this network’ determines if the network connection

is public or not. Because one network card is dedicated for iSCSI communication, we will set that the

cluster cannot use this network.

After these modifications, your network panel should look like this:

Let’s look at the network communication with a network monitor.

Drag the file ‘NM32_x86_setup.exe’ on the desktop of node A and start the typical installation. When

done, start the network monitor.

In the left corner you see the different network cards, you can check them all, or select only those

you want to monitor Let’s check them all.

Click ‘New Capture’ and the start button. You should see a lot of traffic on port 3343 on the private

and the public network, which is reserved for internal cluster communication. The data is sent with

the UDP (user datagram protocol), which is much faster than the TCP protocol. (In a virtual

environment, you must select the virtual adapters too).


Close the network monitor, do not save the trace file.

Creating a virtual File Server

We will now create a fileserver on our cluster. Bring the ‘file’ disk online on both nodes and assign

the letter F. In the cluster manager, add the disk to the cluster configuration. In the storage tab we

see that there is now 1 disk (F:) available.

Go to the cluster manager on node A and choose to configure a new service or application.

Click ‘Next’ on the welcome page, you get a list of services and applications that can be installed.

Choose ‘File Server’.


Give the new virtual file server a name (you can keep the default name) and assign it an IP address

(192.168.0.30).

In the next window we must select a storage, there should be one disk available. Click ‘Next’, verify

the confirmation screen and continue to create the fileserver.

When the file server is created, you get a confirmation screen.


Select the newly created file server in the left pane.

You can also see that there is one file share available, which is the administrative share. Let’s create a

new share.

Before we can do this, we must create a folder on the F-drive. Create the folder ‘userdata’.

Right click on the file server and choose the option ‘Add a shared folder’.

If you receive an error message, verify that the fileserver is running on node A. If not, right click on it

and choose to move the service to node A. you must confirm this action the first time.

When you confirm the action, you will see that the resource goes offline for a few seconds.

Retry to add a shared folder, it should work now and you get the window below:


Type the folder name (F:\userdata) and click ‘Next’ to set security. You can leave the default security.

On the next screen, accept the SMB setting and go the next window where you can set a description

for your share and specify caching options in the advanced tab. You can also limit the number of

concurrent users that can access the share.


In the next screen you can set the share or SMB permissions. A best practice remains that you limit

access on NTFS level and that you grant full access on share level. You can customize the share

permissions and give the group ‘Authenticated Users’ full access. This is a little bit more secure than

giving everyone full access, because the guest account is not considered to be an authenticated user.

We do not have a DFS namespace, so you can skip the next window. You will see an overview of the

settings and you can create the share. When the share is created, you see a confirmation window.

Close this window. Let’s test our share. On the domain controller, open a session to this share and

create a text file in it.


Do a failover of the fileserver and retry to access the file from the domain controller.

When you have multiple resources in a group, you can set dependencies between these resources.

This can be necessary sometimes.

If you look at the dependencies of the fileserver, you will see that it is dependent from the network

name and the disk. Indeed, as long as there is no storage or no network name to connect to, the

fileserver cannot be available. This is a so called forked dependency.

You can alter the dependencies and make the IP address dependent from the disk. You can than say

that there is no need to bring the network name online as long as the disk is not available.

Remove the disk dependency from the fileserver and add it as a dependency for the IP address.


Simulate a failover, you should see that first the disk comes on line, followed by the IP address and

the network name.

Until now, we only had simulated failovers. Let’s now try a real failover by simulating hardware or

software problems. Let’s see how the cluster behaves when the public network card of the active

node loses its connection.

Disable the public network card of node B. You should see that a failover occurs towards node A.

Cluster services and applications have possible and preferred owners. Possible owners are nodes

where the software can run on. If we add a third node in our example that cannot connect to disk F,

the node can’t be a possible owner of the service or application.

Services and applications can have a preferred owner, if multiple possible owners are available, the

services or application will run on its preferred owner. By default all nodes are equal, but it can be

useful to set preferred owners on active-active clusters. Be careful however, having a preferred

owner can cause unexpected downtime.


Set the preferred owner of our fileserver to node B.

Next, move the fileserver to node A and stop the cluster service on node B.

Start the cluster service again on node B, you will see that the application makes another failover. To

control this behavior, you can specify when the failback can be done in the failback tab of the service

or application.

A last setting we have to discuss is the option ‘affect group’. When a resource fails, Windows will first

try to restart the failed resource. When this is not successful, a failover the whole group occurs. You

can set for each resource that no failover must happen when this particular resource fails.


Disabling the network card does not mean that the fileserver fails over to the other node, but only

the affected resource and the resources that are dependent go offline. This can be preferable if you

have an independent resource in your group that is not necessary for your main service or

application (eg: MSDTC in SQL Server group).

Installing SQL Server

SQL Server is a so called cluster aware program. This means that it will recognize that it is installed on

a cluster and that it will automatically create the necessary resources to build a virtual SQL Server.

Before we can install SQL Server, we will add a new cluster disk (S). Add the disk to the cluster

storage.

Connect to the source folder on the domain controller (map the folder and check the box to

reconnect at next log on).

Install .NET framework 3.5 on both nodes, you need to reboot after the installation, launch SQL

Server setup.

Launch SQL Server 2008 setup. First some prerequisites must be installed.


Accept the license agreement.

When the installation is successful, a second prerequisite must be installed: an update for Windows

installer. With a reboot again.

Install the prerequisites on the second node wile installing SQL Server on the first.

Choose ‘New SQL Server failover cluster installation’. The setup program will do some tests like if

there is a restart pending, version of the OS, … When finished you should see an overview.


Choose the enterprise edition to install and accept the license agreement in the next window.

Install the SQL Server setup support files.


When the support files are installed, a bunch of tests are run. If one test fails, you cannot install SQL

Server. Look at the warnings carefully to avoid potential risks.

You get warnings when the cluster has warnings, when you are not connected to the internet, when

msdtc is not installed or when the network binding order is not optimal. The last one doesn’t always

report correctly, if you have a disabled network card or a physical removed card (a ghost card) this

test gives a warning. If you need to change the binding order, go to network settings and choose the

advanced settings in the menu bar:

Select the database engine.


Enter then name of the virtual SQL Server: brusselsSQL

Specify a name for the cluster group (SQLServer)

Only one disk is available for the storage of the databases.

Deselect the DHCP option and enter the IP address and subnet mask for SQL Server (192.168.0.40).


Service Security IDs are available in SQL Server 2008 on Windows Server 2008. Using SIDs enables

service isolation which provides services a way to access objects without having to run in a high

privileged account. A SQL Service can use this identity to restrict access to its resources by other

services or applications.

When installing SQL Server, setup creates a service group for each component of SQL Server, and the

service SID is added to the local group. This differs from Windows 2003 where domain accounts are

needed and added to the local groups.

The next step is to provide an account for SQL Server and SQL Server Agent. Create the account

SQLService on the domain controller. Assign the password Pa$$w0rd and select the option that the

password does not expire.

If want this account to be able to register its SPN (service principal name), than we must grant it

additional rights. Having the SPN registered allows SQL Server to use Kerberos authentication instead

of NTLM. It is possible to create the SPN manually with the SetSPN command.


Open the properties of the educ.be domain in the Active Directory Users and Computers MMC,

select the security tab and click the “Advanced” button.

In the “Advanced Settings” window, add the SQLService account. A new window pops up to grant

privileges. Select the “Descendant Computer Objects” in the drop down list.

Select the permission “Validate to write service principal name” and confirm all the windows.

Enter this account for both services.

If this account does not work, enter the domain admin account. It can be changed afterwards.


Select Windows Authentication mode and add the domain admin as SQL Server admin.

Click next a few times to start the installation. When done, open the cluster management console. A

new group is available: SQLServer. Right click to open the properties of the SQL Server service. In the

advanced policies tab you can see that only SQL1 can own this group.

If the SQL services run under the domain admin account, you can change the account to SQLService

now with the SQL configuration manager.

Don’t forget to restart the SQL Server Agent with the cluster management console afterwards.


Start the cluster installation on the second node.

1. Install .NET framework 3.5 SP1

2. Reboot

3. Install SQL Server – hotfix – reboot

4. Continue SQL Server installation, choose to add a node to the SQL cluster

5. Choose to add this node to the existing cluster:

6. Give the password for the SQLService account (Pa$$w0rd)

When the cluster is installed, install the management console on the domain controller. Open he

management console and connect to brusselsSQL. The connection will fail because the Windows

Firewall will block this connection. Allow port 1433 on both cluster nodes.

You can query SQL Server to know if it is a cluster installation or not:

SELECT ServerProperty(‘IsClustered’)

Execute a query and turn off one node, retry the query after a while, after the transport error

message, it should work.


Destroying a backend cluster

Before we can install our webfarm, we will destroy our cluster, because you cannot combine a

backend and a frontend cluster.

Before we can destroy our cluster, all installed services and applications must be removed. To

deinstall SQL Server from a cluster, start Installation Center in the SQL Server program group. Go to

the maintenance group and select to remove a node from an existing cluster. Do this on both nodes.

When done, check the cluster management program and verify that the virtual SQL Server is

removed.

You can directly delete the application in the cluster. By doing this, the application will not be a part

of the cluster anymore however, installation files and services will stay on the cluster nodes. For a

proper deinstall, you must use the Installation Center.

Delete the fileserver from the cluster.

Look to the users and computers snap-in on the domain controller, the virtual names are not

removed automatically. Check the share on the userdata folder in the windows explorer, it does not

exist anymore.

Destroy the cluster.


Remove the iSCSI disks from both nodes: open the iSCSI initiator delete the discovery server and

open the details of each target. Select the disk and choose Log Off.

Creating a frontend cluster

Reporting services is a web based program and is not cluster aware, it can however be installed on a

webfarm for performance or high availability reasons.

With webfarms, we do not speak of private and public network cards but of frontend and backend.

The backend adapter connects to the database, the frontend is accessed by the clients. Rename the

private adapter to frontend on both nodes and the public adapter to backend. The iSCSI connection

can be disabled.

Install IIS on both nodes: go to server manager and choose to add a role. Select Web Server and

agree to add all required features.


Open the management console for IIS on both nodes and edit the iisstart file with notepad:

Boot the client PC and try to connect to both web servers, this should succeed, because anonymous

authentication is enabled by default.

Installing NLB

Before we can configure NLB, we must add this feature to both nodes.

Once this is installed, you can start the NLB Manager on the SQL1 node. Right click on the title

Network Load Balancing Clusters and choose to create a new cluster.

Enter SQL1, the two networks appear. Select the frontend network (10.0.0.10) and click Next.


Accept the next screen, we do not want to add extra addresses. Enter the cluster address of

10.0.0.100.

The virtual address will receive a virtual MAC address that you cannot change. When you select

Multicast, a new MAC address is added on top of the physical MAC address. If you choose Unicast,

the physical MAC address is replaced by the virtual address, this is better for performance, because

with Multicast you must resolve the virtual and the physical.

The virtual MAC address is not random:

02 = Unicast

03 = Multicast

bf = means a virtual MAC address

rest = the virtual IP address in hexadecimal characters.

10 = a, 0 stays 0 and 100 is 64

Because unicast can cause some problems on virtual machines, we choose the multicast option.

Accept the port settings, the wizard starts making the necessary configuration settings.

Right click on the cluster and choose to add a second node.


Enter SQL2 and choose the frontend network connection.

Accept the port rules and wait until the conversion has finished.

Test the cluster by browsing the default web page on IP 10.0.0.100 from the client. One of both

servers should respond. Test the high availability by disabling the frontend access of the responding

server. Refresh the page on the client, it should be redirected to the other node. Re-enable the

network card. Let’s put some stress on our website.

Install the webstress tool on the client PC. Make following configuration settings:

Other settings: IE browser, 10.0.0.100 URL and no detailed logging or report.

On the domain controller capture following counter of both nodes: Web Service – Get requests per

sec – Default Website. Start the stress test on the client.

You’ll notice that only one server takes all the request, disable the frontend NIC of this server.


When disabled, a short time no connection requests are possible, because the hash function must be

recalculated. When you re-enable the card, the node takes all the requests back.

The reason why one node processes all the requests is called affinity or sticky keys and can be set

with port rules on the frontend cluster. It means that a client always tries to go to the same server.

This can be useful when using server side cookies.

To change this affinity: right click on the cluster in the NLB manager and choose properties. Click on

the port rules tab and change the affinity.

Redo the stress test after both nodes are converged.

You can see that both nodes divide the load now. But what if you have a heavy server in the farm

that can handle more load? You can edit the port settings (in host properties) of the host and assign

more load to it (eg 100 to SQL1). The total of all loads must not be 100. The node takes it load divided

by the sum of all the loads of all the nodes in the farm.


In the graph you can see that SQL1 takes now more load than the other node. Reset the load to be

equally divided.

There is always a short time of connectivity loss when hosts are added or suddenly crash, because

the hash function must be recalculated, let’s try by disabling the frontend NIC of one of the nodes.

If you need to withdraw a node from the farm, there is however a nicer method than to execute a

shutdown or disconnecting the network. You can execute a drainstop, which means that current

connections are handled, but that no new connections are accepted:


Installing Reporting Services on a front end cluster

To install SQL Server on a front end cluster, you must first install Reporting Services on both nodes.

So first action: destroy our frontend cluster.

Second step is to install the database services on the domain controller, we will use it as a central

store for our two reporting services nodes.

Installation options:

Only database engine (the management console is already installed)

SQLService account

Add current user (domain admin) as system administrator

Default data folders

Time to install reporting services on the first node. Before you start the installation, remove the

default web site. This allows the reporting services site to work on port 80.

Installation options:

Only reporting services

SQLService account

Configure Reporting Services by opening the Configuration Manager.

Set the Web Service URL:

Database: try to connect to the domain controller, if this fails, check if TCP is enabled and that the

firewall on the DC allows communication through port 1433.


Apply the reportserver directory.

Test the connection by browsing to http://10.0.0.10/reports, enter domain credentials (do this on

the SQL1 node first, on the client afterwards). When successful, it is time to install and configure the

second node:

Remove the default web site from IIS

Install only reporting services

SQLService account

When installed, configure this node too:

Connect to an existing database:

Test the connection on the node, you receive an error message that the report server is not

initialized.

To join this server to the existing installation, you must go to the first node and open the reporting

services configuration manager. Select the second node and click Add Server.

http://10.0.0.10/reports


Refresh the web page on the second node, it should succeed now, do the same on the client. Now

we can re-establish our front end cluster to make the report server configuration high available.

Cluster address = 10.0.0.100

Do not forget to adapt the report settings of both nodes if they listen to a specific port. You must

adapt both Web Service and Report Manager URLs.

Try to connect with the client, it should succeed, try once with the first node’s NIC disabled and with

the second node’s NIC disabled.

Documents

Windows 2008 Server Clustering