Share This:


This article explains how to install TSIM on Windows Failover Cluster Instance (FCI) on Azure virtual machines in Resource Manager model. This solution uses Windows Server 2016 Datacenter edition Storage Spaces Direct (S2D) as a software-based virtual SAN that synchronizes the storage (data disks) between the nodes (Azure VMs) in a Windows Cluster. S2D is new in Windows Server 2016.

 

The following diagram shows the complete solution on Azure virtual machines:

    

                                                                                   

The preceding diagram shows:

  • Two Azure virtual machines in a Windows Failover Cluster. When a virtual machine is in a failover cluster it is also called a cluster node, or nodes.
  • Each virtual machine has two or more data disks.
  • S2D synchronizes the data on the data disk and presents the synchronized storage as a storage pool.
  • The storage pool presents a cluster shared volume (CSV) to the failover cluster.
  • The File Server cluster role uses the volume created on S2D.
  • An Azure load balancer to hold the IP address for the File Server role.
  • An Azure availability set holds all the resources.

Note:

All Azure resources are in the diagram are in the same resource group.

For details about S2D, see Windows Server 2016 Datacenter edition Storage Spaces Direct (S2D).

S2D supports two types of architectures - converged and hyper-converged. The architecture in this document is hyper-converged. A hyper-converged infrastructure places the storage on the same servers that host the clustered application.

 

Before you begin

There are a few things you need to know and a couple of things that you need in place before you proceed.

What to know

You should have an operational understanding of the following technologies:

One important difference is that on an Azure IaaS VM guest failover cluster, we recommend a single NIC per server (cluster node) and a single subnet. Azure networking has physical redundancy which makes additional NICs and subnets unnecessary on an Azure IaaS VM guest cluster. Although the cluster validation report will issue a warning that the nodes are only reachable on a single network, this warning can be safely ignored on Azure IaaS VM guest failover clusters.

Additionally, you should have a general understanding of the following technologies:

 

What to have

Before following the instructions in this article, you should already have:

  • A Microsoft Azure subscription.
  • A Windows domain on Azure virtual machines.
  • An account with permission to create objects in the Azure virtual machine.
  • An Azure virtual network and subnet with sufficient IP address space for the following components:
    • Both virtual machines.
    • The failover cluster IP address.
    • An IP address for File server cluster role.
  • DNS configured on the Azure Network, pointing to the domain controllers.

With these prerequisites in place, you can proceed with building your failover cluster. The first step is to create the virtual machines.

 

Step 1: Create virtual machines

  1. Log in to the Azure portal with your subscription.
  2. Create an Azure availability set.

The availability set groups virtual machines across fault domains and update domains. The availability set makes sure that your application is not affected by single points of failure, like the network switch or the power unit of a rack of servers.

If you have not created the resource group for your virtual machines, do it when you create an Azure availability set. If you're using the Azure portal to create the availability set, do the following steps:

  • In the Azure portal, click + to open the Azure Marketplace. Search for Availability set.
  • Click Availability set.
  • Click Create.
  • On the Create availability set blade, set the following values:
    • Name: A name for the availability set.
    • Subscription: Your Azure subscription.
    • Resource group: If you want to use an existing group, click Use existing and select the group from the drop-down list. Otherwise choose Create New and type a name for the group.
    • Location: Set the location where you plan to create your virtual machines.
    • Fault domains: Use the default (3).
    • Update domains: Use the default (5).
    • Click Create to create the availability set.

  3. Create the virtual machines in the availability set.

Provision two Windows 2016 Datacenter Edition virtual machines in the Azure availability set.

Place both virtual machines:

  • In the same Azure resource group that your availability set is in.
  • On the same network as your domain controller.
  • On a subnet with sufficient IP address space for both virtual machines, and all FCIs that you may eventually use on this cluster.
  • In the Azure availability set.

Important

You cannot set or change availability set after a virtual machine has been created.

  4. After Azure creates your virtual machines, connect to each virtual machine with RDP.

When you first connect to a virtual machine with RDP, the computer asks if you want to allow this PC to be discoverable on the network. Click Yes.

  5. Open the firewall ports.

On each virtual machine, open the following ports on the Windows Firewall.

Purpose

TCP Port

Notes

Health probe

59999

Any open TCP port. In a later step, configure the load balancer health probe and the cluster to use this port.

  6. Add storage to the virtual machine. For detailed information, see add storage.


Both virtual machines need at least two data disks.

Attach raw disks - not NTFS formatted disks.

Note:

If you attach NTFS-formatted disks, you can only enable S2D with no disk eligibility check.

Attach a minimum of two premium SSDs to each VM. Size of the Disk depends on the utilization. Please note S2D uses mirroring for fault-tolerance. Considering Windows cluster will have 2 nodes, 2-ways mirroring will allow only half of the pool size to be used for creating disks/volumes.

Set host caching to Read-only.

The storage capacity you use in production environments depends on your workload. The values described in this article are for demonstration and testing.

  7. Add the virtual machines to your pre-existing domain.

 

After the virtual machines are created and configured, you can configure the failover cluster.

 

 

Step 2: Configure the Windows Failover Cluster with S2D

The next step is to configure the failover cluster with S2D. In this step, you will do the following substeps:

  1. Add Windows Failover Clustering feature
  2. Validate the cluster
  3. Create the failover cluster
  4. Create the cloud witness
  5. Add storage

Add Windows Failover Clustering feature

  1. To begin, connect to the first virtual machine with RDP using a domain account that is a member of local administrators, and has permissions to create objects in Active Directory. Use this account for the rest of the configuration.
  2. Add Failover Clustering feature to each virtual machine.

To install Failover Clustering feature from the UI, do the following steps on both virtual machines.

  • In Server Manager, click Manage, and then click Add Roles and Features.
  • In Add Roles and Features Wizard, click Next until you get to Select Features.
  • In Select Features, click Failover Clustering. Include all required features and the management tools. Click Add Features.
  • Click Next and then click Finish to install the features.

To install the Failover Clustering feature with PowerShell, run the following script from an administrator PowerShell session on one of the virtual machines.

PowerShell:

$nodes = ("<node1>","<node2>")

Invoke-Command  $nodes {Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools}

For reference, the next steps follow the instructions under Step 3 of Hyper-converged solution using Storage Spaces Direct in Windows Server 2016.

Validate the cluster

This guide refers to instructions under validate cluster.

Validate the cluster in the UI or with PowerShell.

To validate the cluster with the UI, do the following steps from one of the virtual machines.

  1. In Server Manager, click Tools, then click Failover Cluster Manager.
  2. In Failover Cluster Manager, click Action, then click Validate Configuration....
  3. Click Next.
  4. On Select Servers or a Cluster, type the name of both virtual machines.
  5. On Testing options, choose Run only tests I select. Click Next.
  6. On Test selection, include all tests except Storage. See the following picture:

  7. Click Next.

  8. On Confirmation, click Next.

The Validate a Configuration Wizard runs the validation tests.

To validate the cluster with PowerShell, run the following script from an administrator PowerShell session on one of the virtual machines.

PowerShell:

Test-Cluster –Node ("<node1>","<node2>") –Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration"

After you validate the cluster, create the failover cluster.

Create the failover cluster

This guide refers to Create the failover cluster.

To create the failover cluster, you need:

  • The names of the virtual machines that become the cluster nodes.
  • A name for the failover cluster
  • An IP address for the failover cluster. You can use an IP address that is not used on the same Azure virtual network and subnet as the cluster nodes.

Windows Server 2008-2016

The following PowerShell creates a failover cluster for Windows Server 2008-2016. Update the script with the names of the nodes (the virtual machine names) and an available IP address from the Azure VNET:

PowerShell:

New-Cluster -Name <FailoverCluster-Name> -Node ("<node1>","<node2>") –StaticAddress <n.n.n.n> -NoStorage

Windows Server 2019

The following PowerShell creates a failover cluster for Windows Server 2019. For more information, review the blog Failover Cluster: Cluster network Object. Update the script with the names of the nodes (the virtual machine names) and an available IP address from the Azure VNET:

PowerShell:

New-Cluster -Name <FailoverCluster-Name> -Node ("<node1>","<node2>") –StaticAddress <n.n.n.n> -NoStorage -ManagementPointNetworkType Singleton

 

Create a cloud witness

Cloud Witness is a new type of cluster quorum witness stored in an Azure Storage Blob. This removes the need of a separate VM hosting a witness share.

  1. Create a cloud witness for the failover cluster.
  2. Create a blob container.
  3. Save the access keys and the container URL.
  4. Configure the failover cluster quorum witness. See, Configure the quorum witness in the user interface in the UI.

Add storage

The disks for S2D need to be empty and without partitions or other data. To clean disks follow the steps in this guide.

  1. Enable Store Spaces Direct (S2D).

The following PowerShell enables storage spaces direct.

PowerShell:

Enable-ClusterS2D

In Failover Cluster Manager, you can now see the storage pool.

 

   2. Create a volume.

One of the features of S2D is that it automatically creates a storage pool when you enable it. You are now ready to create a volume. The PowerShell commandlet New-Volume automates the volume creation process, including formatting, adding to the cluster, and creating a cluster shared volume (CSV). The following example creates an 250 gigabyte (GB) CSV.

PowerShell:

New-Volume -StoragePoolFriendlyName S2D* -FriendlyName tsdisk -FileSystem REFS -Size 100GB

After this command completes, 100 GB volume is mounted as a cluster resource.

The following diagram shows a disk:

Step 3: Test failover cluster failover

In Failover Cluster Manager, verify that you can move the storage resource to the other cluster node. If you can connect to the failover cluster with Failover Cluster Manager and move the storage from one node to the other, you are ready to configure the FCI.

Step 4: Create File Server Cluster Role

To create the File server cluster role, you need:

  • The names of the cluster virtual disk.
  • A NetBIOS name for the file server cluster role
  • An IP address for the file server cluster role. You can use an IP address that is not used on the same Azure virtual network and subnet as the cluster nodes.

After you have configured the failover cluster and all cluster components including storage, you can create File Server cluster role.

  1. Connect to one of cluster node and open Server Manager -> Tools -> Cluster Failover Manager
  2. In Failover Cluster Manager, right click Roles -> Configure Role. In the role list select ‘File Server’ and click Next. Select File server type ‘File server for general use’ and click Next.
  3. Provide NetBIOS name for role and click Next.
  4. Select Disk to be associated with this role and click Next.
  5. Click Next to and Finish role creation. This role will creation will fail (screenshot below) since in Azure by default it takes IP of the host (node) which is already in use.
  6. To assign static IP go to role IP address and click Properties. Select IP address and type in IP address. Saving role properties should change role Status to Online.

   7 .Change role Preferred Owners and Failback settings. Right click on role and select Properties.

In General tab Preferred Owners, select both nodes. Click on Failover tab and in Failback setting select ‘Allow Failback’.

 

Step 5: Install TrueSight Infrastructure Management Server

After you have configured the File System cluster role successfully, you can install TSIM server

  1. RDP to cluster Current Host server (we treat this as primary server)
  2. Extract TSIM installer and navigate to the Disk1 directory of the extracted folder. Run the installer using following command.
  3. install.cmd -J INSTALL_TYPE=PRIMARY
    1. Follow the default install instructions on most screen, installer will pick Installation directory on the drive which is mapped to disk associated to File server role.
    2. On Cluster group configuration page. Select Custom cluster group and provide NetBIOS FQDN of File System role created in Step 4 – “Create File Server Cluster Role.

   4. Primary install should complete successfully. Run the following command to verify the Infrastructure Management installation

Pw system status

   5. Update License files on primary TSIM server

   6. Go to TSIM_INSTALL_DIR/pw/custom/conf and add following entry to pronet.conf

   7. pronet.tsim.proxy.hosts=<comma_separated_list_of_Filesystem_cluster_role_NetBIOS_FQDN_and_FQDN_of_all_cluster_nodes>

Example: pronet.tsim.proxy.hosts=tsimvm3.bmcaaz.com,tsimvm4.bmcaaz.com,tsim-fs.bmcaaz.com

Error in TrueSight.log when you try to browse TSIM server without this configuration update.

------------------------------------------------------------------------------------------------------------------

ERROR 11/18 15:54:06 Invalid              [ajp-nio2-127.0.0.1-8009-exec-10] 600004 CSRF Filter - Header Referer is not matched. Blocking the call for TSPS UI console !!!

------------------------------------------------------------------------------------------------------------------

   8. Stop TSIM file server role using FCI console. And then move it to other cluster node (secondary).

   9. RDP to secondary server navigate to Disk1 directory and launch TSIM installer using following command.

          install.cmd -J INSTALL_TYPE=SECONDARY

   10. Follow default install instructions through install screen and install should succeed.

   11. Run the following command to verify the Infrastructure Management installation

Pw system status  

 

 

Step 6: Create Azure load balancer

On Azure virtual machines, clusters use a load balancer to hold an IP address that needs to be on one cluster node at a time. In this solution, the load balancer holds the IP address for the File Server role.

Create and configure an Azure load balancer.

Create the load balancer in the Azure portal

To create the load balancer:

  1. In the Azure portal, go to the Resource Group with the virtual machines.
  2. Click + Add. Search the Marketplace for Load Balancer. Click Load Balancer.
  3. Click Create.
  4. Configure the load balancer with:
    • Subscription: Your Azure subscription.
    • Resource Group: Use the same resource group as your virtual machines.
    • Name: A name that identifies the load balancer.
    • Region: Use the same Azure location as your virtual machines.
    • Type: The load balancer can be either public or private. A private load balancer can be accessed from within the same VNET. Most Azure applications can use a private load balancer SKU: The SKU for the load balancer should be standard.
    • Virtual Network: The same network as the virtual machines.
    • IP address assignment: The IP address assignment should be static.
    • Private IP address: The same IP address that you assigned to the File Server cluster role. See the following picture:

Configure the load balancer backend pool

  1. Return to the Azure Resource Group with the virtual machines and locate the new load balancer. You may have to refresh the view on the Resource Group. Click the load balancer.
  2. Click Backend pools and click + Add to add a backend pool.
  3. Associate the backend pool with the availability set that contains the VMs.
  4. Under Target network IP configurations, check VIRTUAL MACHINE and choose the virtual machines that will participate as cluster nodes. Be sure to include all virtual machines that will host the Windows FCI.
  5. Click OK to create the backend pool.

Configure a load balancer health probe

  1. On the load balancer blade, click Health probes.
  2. Click + Add.
  3. On the Add health probe blade, Set the health probe parameters:
    • Name: A name for the health probe.
    • Protocol: TCP.
    • Port: Set to the port you created in the firewall for the health probe. In this article, the example uses TCP port 59999.
    • Interval: 5 Seconds.
    • Unhealthy threshold: 2 consecutive failures.
  4. Click OK.

Set load balancing rules

  1. On the load balancer blade, click Load balancing rules.
  2. Click + Add.
  3. Set the load balancing rules parameters:
    • Name: A name for the load balancing rules.
    • Frontend IP address: Use the IP address file system cluster role.
    • Port: Set TCP port to 80.
    • Backend port: This should be same as port (80).
    • Backend pool: Use the backend pool name that you configured earlier.
    • Health probe: Use the health probe that you configured earlier.
    • Session persistence: None.
    • Idle timeout (minutes): 4.
    • Floating IP (direct server return): Disabled
  4. Click OK.
  5. Repeat step 3 and add load balancing rules for 80,443,8093,1099,1100,3084,1828,11590,10590,1839,1851 ports which are required for TSIM configuration.

Step 7: Configure cluster for probe

Set the cluster probe port parameter in PowerShell.

To set the cluster probe port parameter, update variables in the following script with values from your environment. Remove the angle brackets <> from the script.

PowerShell:

$ClusterNetworkName = "<Cluster Network Name>"

$IPResourceName = "<File Server cluster role IP Address Resource Name>"

$ILBIP = "<n.n.n.n>"

[int]$ProbePort = <nnnnn>

 

Import-Module FailoverClusters

 

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

 

In the preceding script, set the values for your environment. The following list describes the values:

  • <Cluster Network Name>: Windows Server Failover Cluster name for the network. In Failover Cluster Manager > Networks, right-click on the network and click Properties. The correct value is under Name on the General tab.
  • <File Server cluster role IP Address Resource Name>: File Server cluster role IP address resource name. In Failover Cluster Manager > Roles, under the File Server cluster role, under Server Name, right click the IP address resource, and click Properties. The correct value is under Name on the General tab.
  • <ILBIP>: The ILB IP address. This address is configured in the Azure portal as the ILB front-end address. This is also the File Server cluster role IP address. You can find it in Failover Cluster Manager on the same properties page where you located the < File Server cluster role IP Address Resource Name >.
  • <nnnnn>: Is the probe port you configured in the load balancer health probe. Any unused TCP port is valid.

Note: Verify SubnetMask and EnableDhcp values for you cluster are same. If not change it.

 

 

Important

After you set the cluster probe you can see all of the cluster parameters in PowerShell. Run the following script:

PowerShell:

Get-ClusterResource $IPResourceName | Get-ClusterParameter

 

 

References: