Database Mirroring in SQL Server 2008

What is Database Mirroring?

Database mirroring is the feature in SQL Server 2005 and SQL Server 2008 that provides a high availability solution for Databases. This feature can be enabled and used only on a database with Full recovery models. The database can be mirrored from one SQL Server instance to another SQL Server instance. The source instance is called Principal server; the target instance is called Mirrored server. We could have one more server called Witness server--we will talk about that in later part of this article series.

How does database mirroring work?

The principle server sends the active transaction log record to the mirrored server. The mirrored server applies the transaction log record one by one in sequence.

Modes of Database Mirroring

Database mirroring can be configured in two different modes, High-Safety mode also known as synchronous mode and High-Performance mode also known as asynchronously. The term synchronous and asynchronous says it all.

In the synchronous mode, the principal server sends the transaction and waits until the transaction is committed on the mirrored server. Then the transaction is committed on the principal server.

In Asynchronous mode, the principal server sends the transaction to the mirrored server and does not wait for the transaction on the mirrored server to commit.

We will discuss transaction safety in detail in a future installment of this series.

Now let's setup database mirroring between the SQL Server instance PowerPC\SQL2008 [our principal server] and PowerPC\SQL2k8 [our mirrored server].

What are the Pre-Requisites of database mirroring?

The following are the pre-requisites for database mirroring.

• Edition of SQL Server should be Standard, Enterprise or Developer edition
• Principal Database involved in database mirroring should be in full recovery mode
• Before configuring database mirroring, take a full backup, transactional log backup on the principal server and restored it on the mirrored server with NORECOVERY option.

Now let's create a database DB1 on the principal server, PowerPC\SQL2008, using the following transact SQL statement. In this part of article series, we are going to discuss database mirroring with synchronous mode and with no witness server.

USE [master] GO  /****** Object:  Database [DB1]    Script Date: 06/20/2009 21:10:33 ******/ IF  EXISTS (SELECT name FROM sys.databases WHERE name = N'DB1') DROP DATABASE [DB1] GO   USE [master] GO  /****** Object:  Database [DB1]    Script Date: 06/20/2009 21:10:13 ******/ CREATE DATABASE [DB1] ON  PRIMARY  ( NAME = N'DB1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\DB1.mdf' , \  SIZE = 1280KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )  LOG ON  ( NAME = N'DB1_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\DB1_log.LDF' ,   SIZE = 504KB , MAXSIZE = 2048GB , FILEGROWTH = 10%) GO 

Now let's create a database DB1 on the mirrored server, PowerPC\SQL2K8, using the following transact SQL statement.

USE [master] GO  /****** Object:  Database [DB1]    Script Date: 06/20/2009 21:10:33 ******/ IF  EXISTS (SELECT name FROM sys.databases WHERE name = N'DB1') DROP DATABASE [DB1] GO   USE [master] GO  /****** Object:  Database [DB1]    Script Date: 06/20/2009 21:10:13 ******/ CREATE DATABASE [DB1] ON  PRIMARY  ( NAME = N'DB1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2K8\MSSQL\DATA\DB1.mdf' ,   SIZE = 1280KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )  LOG ON  ( NAME = N'DB1_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2K8\MSSQL\DATA\DB1_log.LDF' ,   SIZE = 504KB , MAXSIZE = 2048GB , FILEGROWTH = 10%) GO 

If the target server does not have the database with same name, you will get the following error when configuring database mirroring. [Refer Fig 1.0]

Fig 1.0

Note: Instead of creating the DB1 database on the mirrored server, you could restore the database backup and tranlog backup using the with replace option to create and restore at the same time.

Now let's backup the database and transaction on the principal server using the following transact SQL statement.

use master go Backup database DB1 to disk ='C:\Backups\DB1.Bak' with init go Backup log DB1 to disk ='C:\Backups\DB1.trn' with init go 

Restore the database on the target server using the following transact SQL statement.

use master go restore database DB1 from disk ='C:\Backups\DB1.Bak' with norecovery,  replace, move 'DB1' to 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2K8\MSSQL\DATA\DB1.mdf', move 'DB1_log' to 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2K8\MSSQL\DATA\DB1_log.ldf' go restore log DB1 from disk ='C:\Backups\DB1.trn' with norecovery, replace, move 'DB1' to 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2K8\MSSQL\DATA\DB1.mdf', move 'DB1_log' to 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2K8\MSSQL\DATA\DB1_log.ldf' go 

On the target server, if the database is not in restore mode you will get the following error. [Refer Fig 1.2]

Fig 1.2

Configure the database DB1 on the principal server for database mirroring. Using SQL Server management studio, expand the databases and click on the Database DB1. Right click on the database DB1 and select properties. In the properties window select the "Mirroring" option as shown below. [Refer Fig 1.3]

Fig 1.3

Now click on the "Configure Security" button and you will see the following screen. Since we are not going to setup the witness server, select the option "No" and click next. [Refer Fig 1.4]

Fig 1.4

Select the default port and the endpoint name chosen by the SQL server management studio and click Next. [Refer Fig 1.5] If you are choosing some other port, then make sure that port is open and available.

Fig 1.5

Now select the mirrored server name, click on the "Connect" button and make sure you can connect to the mirrored server. Select the default port and the endpoint name chosen by the SQL server management studio and click Next. [Refer Fig 1.6] If you are choosing some other port, then make sure that port is open and available.

Fig 1.6

Type the appropriate service account you want to use for the database mirroring. [Refer Fig 1.7]

Fig 1.7

Double check the summary details and click finish. This will configure database mirroring. [Refer Fig 1.8, 1.9, 1.10]

Fig 1.8

\
Fig 1.9

\
Fig 1.10

On the next screen, click on the button "Start Mirroring". [Refer Fig 1.11]

Fig 1.11

On the next screen, click on the "Yes" button. [Refer Fig 1.12]

\
Fig 1.12

The following screen shows that database mirroring is configured and running. [Refer Figure 1.13]

Fig 1.13

Click OK and refresh the databases. You can see the caption of the DB1 database has changed in both principal and mirrored server. [Refer Fig 1.14]

\
Fig 4

SQL Server 2008 LOG Shipping

Log shipping technology is one of the methods for implementing High Availability solution. Log shipping is easy to set up, standby database can be available for reporting purpose, easy to maintain and troubleshoot, and multiple standby databases can be configured for log shipping in the same server or instance. One of the main issues or concern with log shipping is adding overhead to the disk subsystem because of frequent transaction log backup. More frequent the transaction log backup taken, the more overhead will be added to the server disk subsystem, and this leads system slow down.

In SQL Server, transaction log provides an ability to recover a database to a point in time. Log shipping is a process of copying the transaction log back up from a source server to a destination server and restore on the destination server. The main objective of implementing log shipping is to maintain two SQL Server database synchronized in separate locations for high availability.

Basic Components of Log shipping are:

1. Primary server

2. Secondary Server

3. Monitor Server

Primary Server:

· Server where the primary database resides.

· It is the main database server and the primary database will be accessible for the applications.

· Database in this server should be either in full recovery model or bulk-logged recovery model for the transaction log shipping.

· Full backup of the database is taken on this server and copied over to stand by server.

· Transaction log backup are taken on periodic basis and copied over to the secondary server.

Secondary Server:

· This is another server used in the log shipping technology.

· This server will have a back up copy of the primary database used for log shipping.

· Secondary database server can be one or more than one as per the need of the business.

· Secondary database can be in Standby Mode or No Recovery mode.

· Secondary database is not accessible during the transaction log shipping process.

· Always, NO RECOVERY mode should be used so that transaction logs can be restored on the secondary database since in Standby mode users can use SELECT command and logs will not be restored if the users are connected to the database which is in restoring state.

Monitor Server:

· This is another database engine server that tracks the log shipping process.

· It contains set of jobs and sends alert if the transaction log shipping sessions is perceived to be out of sync.

· This server is an optional component of log shipping.

Log Shipping Demo:

In this example, I have used two instances for log shipping.

Primary Server Instance: ABI-PC

Secondary Server Instance: ABI-PC\SQLINSTANCE

Monitor Server Instance: ABI-PC\SQLINSTANCE

1. Go to the Primary Instance Management Studio.

2. Point to the UserDB database, Right Click on UserDB and Click on Tasks and then click on Ship Transaction Logs….

3. In Database Properties Window, Click on Enable this as a Primary database in a log shipping configuration, as shown below.

4. Click on Backup Settings…. Here you can schedule the transaction log back up in the primary server.

5. Provide the backup folder where you can store the Transaction Log Backup of UserDB database on the primary server (in my case this is just one server but have different instance for Primary and Secondary database and have different drive for the backups). You can either keep in a Local Drive or Network Path. It is shown below.

6. Click on Schedule tab to schedule the transaction Log Back up on the Primary Server. I have scheduled this backup to run every 15 minutes as shown in the figure below.

7. Few things to note in Job Schedule Properties Window and they are:

· Name: This is a job name which is LSBackupSchedule_ABI-PC1

· Schedule Type: Recurring

· Frequency: Runs daily that runs every 15 minutes.

8. Click OK.

9. Click OK on Transaction Log Backup Settings window.

Adding Secondary Database Server in Mirroring Session:

10. In the Database Properties Window, Click on Add button as shown below.

11. When you click Add, the Secondary Database Settings window comes where the secondary database instance comes, as shown below

12. Click Connect button on this Connect to Server Window and will be connected to the Secondary Instance.

13. There are three options on the Secondary Database Settings window as shown in the figure below.

In Initialize Secondary Database, restore of the primary database on the secondary database is initializing. In my case, I have generated full database backup on the Primary Server UserDB database and apply that backup in the Secondary Instance. In this option, if the secondary database does not exist, it will create a new UserDB database.

14. In the Second Tab, Copy files options will enable to copy the Transaction Log backup from the primary server to the secondary server. In my case, I have the same sever but kept another drive for this purpose. This will be a destination folder for the copied files, and usually this folder will be in the secondary server. Copy job will run to copy the transaction log backup to copy the files to the secondary server and it scheduled to run in every 15 minutes. Figure is shown below:

15. Restore transaction Log tab will have the transaction log backup details. There are two modes: No Recovery Mode and Standby Mode. Always, NO RECOVERY mode should be selected because in standby mode, SELECT statement can be used to retrieve some data from the UserDB database tables, therefore the restore will fail since the database will be in use. When the restore mode is in NO RECOVERY MODE users will not be able to connect to the database and transaction log restore will not fail. Restore of transaction log is scheduled to run every 15 minutes.

To add Monitor Server Instance:

16. In the database properties window, add the Monitor Server Instance, Check the Use Monitor Server Instance Check Box and then click on Settings as shown in the figure below. I have used my Secondary Server Instance as the Monitor Server Instance (ABI-PC\SQLINSTANCE). Monitor server is an optional server instance.

17. After you click Settings, Log Shipping Monitor Settings Window will come. In this Window, Click on Connect button, Monitor Server Instance comes, in my case, ABI-PC\SQLINSTANCE, is the monitor server instance, as shown in the figure below.

18. Backup, copy and restore jobs are connected on this server instance. Alert job alerts to the users or database administrators if the log shipping fails. Connection used in monitor server is by Impersonating the Proxy Account of the job. Alert job starts automatically when the SQL Server Agent starts.

19. Click OK on the Monitor Server Instance Settings.

20. Finally, Click OK on Database Properties window to initiate Log Shipping session, final window will look like the following:-

Finally, log shipping is set up and it should up and running now.

How to Check Log Shipping Status:

MSDB database tables on secondary store the information. SQL Server 2005 has a capability to provide a report on log shipping status on both primary and secondary servers. Following approach is used to check the log shipping status:

· Connect to the Secondary Server/Instance from Management Studio

· Right click on the server name (Primary/Secondary) in the object explorer

· Navigate to Reports and then to Standard Reports

· Click on “Transaction Log Shipping Status”

Fail Over to Secondary Server:

In the event of any hardware or Operating system failure in the primary server, following steps will be implemented to bring the secondary server database online. This process will be implemented in real disaster recovery scenario. Follow the following steps:

· Restore UserDB on secondary database using the following command in the query analyzer:

RESTORE DATABASE [UserDB] WITH RECOVERY

· Disable the Log shipping jobs on the secondary server by right clicking each job and click disable on Copy, Alert, and Restore job.

Conclusion:

Log shipping technology is one of the methods for implementing High Availability solution. Log shipping is easy to set up, standby database can be available for reporting purpose, easy to maintain and troubleshoot, and multiple standby databases can be configured for log shipping in the same server or instance. One of the main issues or concern with log shipping is adding overhead to the disk subsystem because of frequent transaction log backup. More frequent the transaction log backup taken, the more overhead will be added to the server disk subsystem, and this leads system slow down.

List of the bugs that are fixed in SQL Server 2005 Service Pack 4

or more information about the bugs that are fixed in SQL Server 2005 Service Pack 4, click the following article numbers to view the articles in the Microsoft Knowledge Base:

VSTS bug number	KB article number	Description
294192	2445326	FIX: 0xC02020A1, 0xC020902A, 0xC0202092, and 0xC0047038 errors may occur at the same time when you try to run an SSIS 2005 package if you use multi-character column delimiters in a Flat File source
396531	980671	Correcting the lack of cryptographic salt variation on SQL Server sa login hash
308002	968749	SQL Server 2005 setup fails when MSXML Core Services 6.0 Service Pack 2 has already been installed

Back to the top

Additional issues that are fixed in this service pack

Resolutions to the following issues are also included in SQL Server 2005 Service Pack 4:

VSTS bug number	Description
297747	The multimedia timer frequency does not increase when you use Windows Internal Database.
555409	An access violation error may occur during the execution of Extended Stored Procedures under high stress conditions.

Back to the top

Geo-Replication Performance Gains with Microsoft SQL Server 2008 Running on Windows Server 2008

http://msdn.microsoft.com/en-us/library/dd263442(v=SQL.100).aspx

Step-by-Step: Configuring a 2-node multi-site cluster on Windows Server 2008 R2

Configure your replication

Deploying a multi-site cluster will require that you work very closely with your replication vendor during this part of the configuration. Each vendor will have very specific instructions on how to set up the replication and create the storage resources to be used in your cluster. For the purposes of this demonstration, I will use SteelEye DataKeeper Cluster Edition to replicate the E drive from the server named PRIMARY to the server named SECONDARY. The E drive on PRIMARY and SECONDARY are just local attached volumes and not part of any SAN. As long as the E drive shows up as a local attached disk, DataKeeper can replicate it from one server to another. You can mix and match SAS, iSCSI, SAN, VHD, or any other storage type as DataKeeper is storage agnostic.

After you have configured your basic cluster as described in Part 1 of my series, run the DataKeeper setup.exe to install SteelEye DataKeeper Cluster Edition on both nodes of the cluster. You will be prompted to enter your license key at the end of the install. Enter your license and reboot your servers when prompted. You are now ready to create your mirror. Launch the DataKeeper GUI and follow the instructions below to create your mirror.

Click on “Connect to Server”.

Figure 1 – Connect to your source and target servers

Enter the name of the first server. Click Connect.

Enter the name of the second server, click Connect

Now click Create Job. That will launch the Create Job wizard.

Figure 2 – Create your Job

Give your job a name and description. These can be anything you like.

Figure 3 – Give your Job a name and description

Choose the following:

• Source Server – where the data will be replicated from
• Network adapter – the network where the replication traffic will travel
• Volume – the volume you want to replicate

Click Next to continue.

Figure 4 – Choose you source server and network to use for replication

Choose the following:

• Target Server – where the data will be replicated to
• Network adapter – the network where the replication traffic will travel
• Volume – the volume you want to replicate

Click Next to continue.

Figure 5 – Choose your target server

Choose the following:

• Compression Level – If you have a 100 Mbps or faster network for replication, leave it set to none. If you have a WAN that is less that 100 Mbps, you may benefit from enabling compression. Settings somewhere in the middle tend to give you the best performance of compression vs. CPU overhead associated with enabling compression.
• Asynchronous vs. Synchronous – Asynchronous replication is generally acceptable in most environments and is definitely required in high-latency WAN environments. I wrote a whole blog post on this topic, so if you have any questions, check out my article on Asynchronous vs. Synchronous replication.
• Maximum bandwidth – you can think of this as a “poor man’s” QOS. If you want to ensure that replication never exceeds a certain threshold of your WAN capacity, you can put a limiter on the amount of bandwidth it can consume. Unless you have a good reason to set it, it is better off leaving it set to 0.

Click Done to create your mirror.

Figure 6 – Choose your mirror settings

Now if you take a look at your DataKeeper GUI, it will look similar to the following.

Figure 7 – Your mirror is now created

Once you have created your mirror, you need to make your mirror available in the Microsoft Cluster “Available Storage”. There are a few ways to do this, but the most straight forward way is to use the Windows PowerShell CLI. Below is an example that shows how to take the existing mirror we just created on the E drive and add it to the cluster “Available Storage”, move it to the PRIMARY node and bring it in-service

Import-Module FailoverClusters

Add-ClusterResource -Name “DataKeeper Volume E” -ResourceType “DataKeeper Volume” -Group “Available Storage”

Get-ClusterResource “DataKeeper Volume E” | Set-ClusterParameter VolumeLetter E

Move-ClusterGroup “Available Storage” -Node primary

Start-ClusterResource “DataKeeper Volume E”

For more information on PowerShell and the available commands for use with Failover Clustering, check out this great blog post from Symon Perriman of the Microsoft Failover Clustering Team.

http://blogs.msdn.com/clustering/archive/2008/12/20/9243367.aspx

You are now going to repeat the above steps to add any additional mirrors that you will use in your cluster. In our case, we are going to create a mirror of the F drive and use it to cluster the MSDTC. After you have added your additional mirrors and added them to Available Storage, your DataKeeper GUI should look something like this.

Figure 8 – After adding the second Job for the MSDTC resource

And your Failover Cluster Manager GUI should look like this.

Figure 9 – After adding the second DataKeeper resource

Clustering MSDTC

IMPORTANT NOTE – There is a hotfix that is required in order to support DTC with 3rd party disk resources. Please see the following KB article and apply the howfix to all cluster nodes. http://support.microsoft.com/kb/978476

SQL 2008 is very dependent upon MSDTC, so it is highly recommended that you cluster the MSDTC resource before you cluster your SQL resource. The following articles are provided for your reference for configuration and management of your MSDTC resource.

http://technet.microsoft.com/en-us/library/cc770748(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc771540(WS.10).aspx

You will start by opening the Failover Cluster Manager GUI and then choose “Configure a Service or Application”.

Figure 10 – Creating a MSDTC resource

You will then choose “Distributed Transaction Coordinator” and click Next

Figure 11 – Choose your Service or Application

Give the MSDTC resource a name and unique IP address. These should be unique to MSDTC and not the same as you will use later when you create your SQL resource.

Figure 12 – Choose a name and IP address

Choose the volume where you will store the data for the MSDTC resource. In our case we are choosing the replicated F drive.

Figure 13 – Choose a dedicated volume for the MSDTC resource

Confirm your information and click Next to continue.

Figure 14 – Click Next to configure the DTC resource

Congratulations, you have succesfully configured the DTC resource. Click Finish.

Figure 15 – A successfully configured DTC resource

We are just about ready to begin the installation of the first node of the SQL Server Cluster, however, there is one thing we need to do in preparation – Slip Stream SQL 2008 SP1 onto the SQL Server 2008 RTM install media.

Slip stream SQL SP1 onto your SQL 2008 install media

What I have discovered is that SQL Server 2008 will not install on Windows Server 2008 R2 without first slipstreaming SQL Server 2008 SP1 onto your SQL 2008 install media. Here is a great article that describes how toslipstream SQL Server 2008 RTM and Service Pack 1. After I read that article and successfully slipstream SP1 onto SQL 2008 RTM, I found the following Microsoft KB article that describes the same procedure. You may get an error that looks like the following if you try to install SQL without first slipstreaming SP1 onto the media.

There was an error setting private property ‘RequireKerberos’ to value ’1′

I followed the instructions detailed in the first article and copied my SQL 2008 with SP1 install to the C:\ drive of both nodes in my cluster. In the instructions below, I will do the installation from the local disk of each cluster node.

Installing your first cluster node

Now that you have your SQL Server 2008 SP1 installation media ready to go, you are ready to install your first SQL node. There is one major “gotcha” when it comes to installing SQL on a multi-node cluster. In order for you to install SQL on a multi-node cluster, you must first pass the Windows Server 2008 Failover Cluster validate process. Unfortunately, a multi-site cluster is exempt from passing the storage related test, so you never are able to actually “pass” the validation as far as SQL is concerned. It took a little investigation on my part, but what I have come to find is that there is a command line parameter that allows you to skip the validation test on the SQL 2008 installation. Here is the command line.

Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

To launch the SQL setup, open a Command window, browse to your SQL 2008 with SP1 install directory and type the command as shown below.

If everything goes as planned, you should see the screen below. Click OK to continue.

Enter your product key and click Next

Figure 17 – Enter your product key

Accept the license agreement and click Next

Click Install to install the Setup Support Files

At the end of the Setup for the Support Files you will receive a warning. Click on Show details and you will see the message below. You can click Next, ignoring this message since it is expected in a multi-site or non-shared storage cluster.

Figure 18 – The warning is expected in a multi-site or non-shared storage cluster

Choose the features you would like to install and click Next. Leave the “Shared Feature” directory set to the C drive as the SQL binaries should not be installed on the replicated volume.

Figure 19 – Choose your features

On the next screen, you will choose a network name for your SQL Server. This will be the name that all of the clients will connect to. Assuming this is the default instance, leave the Instance ID and Instance root directory set to the defaults. Do not move the instance root directory to the replicated volume.

Figure 20 – Choose your SQL Network Name

It is recommended that you have separate domain accounts for SQLServer and SQLAgent. You can take the time to create these accounts now if you have not already done so. These accounts require no special permissions, as this install process will give them the permissions that they require.

Confirm you have enough disk space and click Next to continue.

Choose the default settings to allow a new cluster resource group named “SQL Server (MSSQLSERVER)” to be created.

Figure 21 – Allow the wizard to create a new cluster resource group for you

Choose a replicated volume that is still available, in our case the E:\ drive. Click Next to continue.

Figure 22 – Choose your replicated volume

Now you will choose the IP address you want associated with the SQL cluster resource. You could leave it set to use DHCP if you wish.

Figure 23 – Choose your SQL cluster IP address

Choose your security settings and click Next

Add any SQL Server administrators and choose your authentication mode and then click Next

Choose your Error and Usage Reporting options and click Next

You will once again see some warnings related to the validation process. You can ignore those messages as they are to be expected in a multi-site SQL Server cluster.

Click Install to begin the installation process

If everything installs as expected, you should see the following screens. Click Next then Close to finish the installation.

Congratulations, you have successfully installed the first node of your multi-site SQL Server Cluster. Now we will install the second node of the cluster.

Install the second cluster node

Installing the second cluster node is similar to installing the first node. We need to run SQL Setup once again from the command line so that we can skip the Validate process. So, from the 2^nd node, open up your command prompt and run the following command.

1. Install SQL 2008 SP1 (merged setup) on the 2^nd node using the following command:
   

   Setup /SkipRules=Cluster_VerifyForErrors /Action=AddNode /INSTANCENAME=”MSSQLSERVER”
   

*Note: This assumes you installed the default instance on the 1^st node

That will launch the install wizard as shown below. Click OK to continue.

Enter your product key and click next.

Accept the license terms and click Next

Click install to install the Setup Support files.

You can once again ignore the warning that some cluster validation tests have been skipped. This is to be expected in a multi-site cluster and non-shared storage clusters.

Verify you are adding the node to the righ instance and click Next.

Add the passwords to the service accounts and click Next

Choose your Error and Usage Reporting options and click Next

Once again, ignore the warning about the skipped operations.

Click Install to begin the installation process.

If everything goes as expected, you should see the following screen.

Now that you have a fully functional two node cluster, you probably should testing things out by doing some manual switchovers. Right click on the resource and choose “Move to node SECONDARY”.

If everything is configured properly, your Failover Cluster GUI should look as follows.