StarWind Virtual SAN:
Configuration Guide for Red Hat oVirt [KVM], VSAN Deployed as a Controller Virtual Machine (CVM) using Web UI

Annotation

Relevant Products 

StarWind Virtual SAN (VSAN)

Purpose 

This guide provides instructions for deploying and configuring StarWind Virtual SAN® Controller Virtual Machine (CVM) within the Red Hat oVirt [KVM] environment and creating StarWind devices using the Web UI. It encompasses essential aspects such as system requirements, RAID settings, best practices, and preliminary setup steps, ensuring a successful and efficient deployment. 

Audience 

Intended for IT specialists, system administrators, and professionals who are interested in deploying and configuring StarWind Virtual SAN CVM with Red Hat oVirt [KVM] 

Expected Result 

Upon completing this guide, users will possess a thorough understanding of the deployment and configuration process of StarWind Virtual SAN CVM within the Red Hat oVirt [KVM] environment.  

StarWind VSAN System Requirements

Prior to installing StarWind Virtual SAN, please make sure that the system meets the requirements, which are available via the following link:
https://www.starwindsoftware.com/system-requirements

Recommended RAID settings for HDD and SSD disks:
https://knowledgebase.starwindsoftware.com/guidance/recommended-raid-settings-for-hdd-and-ssd-disks/

Please read StarWind Virtual SAN Best Practices document for additional information:
https://www.starwindsoftware.com/resource-library/starwind-virtual-san-best-practices

Pre-configuring the KVM Hosts

The diagram below illustrates the network and storage configuration of the solution:

1. Make sure that a oVirt engine is installed on a separate host.
2. Deploy oVirt on each server and add them to oVirt engine.
3. Define at least 2x network interfaces on each node that will be used for the Synchronization and iSCSI/StarWind heartbeat traffic. Do not use ISCSI/Heartbeat and Synchronization channels over the same physical link. Synchronization and iSCSI/Heartbeat links can be connected either via redundant switches or directly between the nodes (see diagram above).
4. Separate Logical Networks should be created for iSCSI and Synchronization traffic based on the selected before iSCSI and Synchronization interfaces. Using oVirt engine Netowrking page create two Logical Networks: one for the iSCSI/StarWind Heartbeat channel (iSCSI) and another one for the Synchronization channel (Sync).
5. Add physical NIC to Logical network on each host and configure static IP addresses. In this document, the 172.16.10.x subnet is used for iSCSI/StarWind heartbeat traffic, while 172.16.20.x subnet is used for the Synchronization traffic.

NOTE: In case NIC supports SR-IOV, enable it for the best performance. Contact support for additional details.

Enabling Multipath Support

8. Connect to server via ssh.

9. Create file /etc/multipath/conf.d/starwind.conf with the following content:

10. Restart multipathd service.

11. Repeat the same procedure on the other server.

Creating NFS share

1. Make sure that each host has free storage to create NFS share.
2. Enable nfs server and rpcbind services.

3. Create directory for NFS share.

4. Change rights and owner of the share to KVM

5. Add NFS share to /etc/exports file.

6. Restart NFS server service.

7. Check that share has been exported.

8. Add firewall rules for NFS.

Deploying Starwind Virtual SAN CVM

1. Download StarWind VSAN CVM KVM: VSAN by StarWind: Overview 

2. Extract the VM StarWindCVM.ova file from the downloaded archive.

3. Upload StarWindCVM.ova file to the oVirt Host via any SFTP client.

4. Change owner of the StarWindCVM.ova.

5. Login to oVirt and open Compute -> Virtual Machines page. Choose Import.

6. Specify path to .ova file and choose VM to import. Click Next.

7. Verify VM settings and configure networks. Click OK.

8. Repeat all the steps from this section on other oVirt hosts.

Initial Configuration Wizard

1. Start StarWind Virtual SAN CVM.

2. Launch VM console to see the VM boot process and get the IPv4 address of the Management network interface.
NOTE: in case VM has no IPv4 address obtained from a DHCP server, use the Text-based User Interface (TUI) to set up a Management network.

3. Using the web browser, open a new tab and enter the VM IPv4 address to open StarWind VSAN Web Interface. Click “Advanced” and then “Continue to…”

4. StarWind VSAN web UI welcomes you, and the “Initial Configuration” wizard will guide you through the deployment process.

5. In the following step, upload the license file.

6. Read and accept the End User License Agreement to proceed.

7. Review or edit the Network settings and click Next.
NOTE: Static network settings are recommended for the configuration.

8. Specify the hostname for the virtual machine and click Next.

9. Create an administrator account. Click Next.

10. Review your settings selection before setting up StarWind VSAN.

11. Please standby until the Initial Configuration Wizard configures StarWind VSAN for you.

12. The appliance is set and ready. Click on the Done button to install the StarWind vCenter Plugin right now or uncheck the checkbox to skip this step and proceed to the Login page.

13. Repeat the initial configuration on other StarWind CVMs that will be used to create 2-node or 3-node HA shared storage.

Add Appliance

To create 2-way or 3-way synchronously replicated highly available storage, add partner appliances that use the same license key.

1. Add StarWind appliance(s) in the web console, on the Appliances page.
NOTE: The newly added appliance will be linked to already connected partners.

2. Provide credentials of partner appliance.

3. Wait for connection and validation of settings.

4. Review the summary and click “Add appliance”.

Configure HA networking

1. Launch the “Configure HA Networking” wizard.

2. Select appliances for network configuration.
NOTE: the number of appliances to select is limited by your license, so can be either two or three appliances at a time.

3. Configure the “Data” network. Select interfaces to carry storage traffic, configure them with static IP addresses in unique networks, and specify subnet masks:

• assign and configure at least one interface on each node
• for redundant configuration, select two interfaces on each node
• ensure interfaces are connected to client hosts directly or through redundant switches

4. Assign MTU value to all selected network adapters, e.g. 1500 or 9000. Ensure the switches have the same MTU value set.

5. Click Next to validate Data network settings.

6. Configure the “Replication” network. Select interfaces to carry storage traffic, configure them with static IP addresses in unique networks, and specify subnet masks:

• assign and configure at least one interface on each node
• for redundant configuration, select two interfaces on each node
• ensure interfaces are connected to client hosts directly or through redundant switches

7. Assign MTU value to all selected network adapters, e.g. 1500 or 9000. Ensure the switches have the same MTU value set.

8. Click Next to validate the Replication network settings completion.

9. Review the summary and click Configure.

Add physical disks

Attach storage to StarWind Virtual SAN Controller VM:

• the physical hosts have all the drives connected through an HBA or RAID controller
• HBA or RAID controller will be added via a DirectPath I/O passthrough device to a StarWind CVM.  Follow the instructions from the VMware on how to add a RAID controller as a PCI device to StarWind VM:
  https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-host-client/GUID-2B6D43A6-9598-47C4-A2E7-5924E3367BB6.html
• StarWind CVM is installed on each server that is used to configure highly available storage.
• it is recommended to install StarWind CVM on a separate storage device available to the hypervisor host (e.g. SSD, HDD, etc.).
• for VMware vSphere environments, the disks can be added to StarWind VM as RDM. The link to VMware documentation is below:
  https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-4236E44E-E11F-4EDD-8CC0-12BA664BB811.html

NOTE: In order to make RDM and VMDK disks available for StarWind devices in StarWind CVM Version 20231016 (build 15260), please follow the steps below.

• stop service

  sudo systemctl stop starwind-san-and-nas-console

  1	sudo systemctl stop starwind-san-and-nas-console

• get VMDK/RDM/ device letter using lsblk command

  lsblk |grep -v sda # sda - is excluded system drive.

  1	lsblk |grep -v sda # sda - is excluded system drive.

• edit config file

  sudo nano /opt/starwind/starwind-san-and-nas-console/appsettings.json

  1	sudo nano /opt/starwind/starwind-san-and-nas-console/appsettings.json

• add lines to the file, previously setting the disk letters to config (e.g. sdb, sdc)

  "HardwareRaidImulation": {"PhysicalDisks": [ "sdb", "sdc" ] },

  1	"HardwareRaidImulation": {"PhysicalDisks": [ "sdb", "sdc" ] },

• start service

  sudo systemctl start starwind-san-and-nas-console

  1	sudo systemctl start starwind-san-and-nas-console

Create Storage Pool

1. Click the “Add” button to create a storage pool.

2. Select two storage nodes to create a storage pool on them simultaneously.

3. Select physical disks to include in the storage pool name and click the “Next” button.
NOTE: Select identical type and number of disks on each storage node to create identical storage pools.

4. Select one of the preconfigured storage profiles or create a redundancy layout for the new storage pool manually according to your redundancy, capacity, and performance requirements.

Hardware RAID, Linux Software RAID, and ZFS storage pools are supported and integrated into the StarWind CVM web interface. To make easier the storage pool configuration, the preconfigured storage profiles are provided to configure the recommended pool type and layout according to the direct-attached storage:

• hardware RAID – configures Hardware RAID’s virtual disk as a storage pool. It is available only if a hardware RAID controller is passed through to the CVM
• high performance – creates Linux Software RAID-10 to maximize storage performance while maintaining redundancy
• high capacity – creates Linux Software RAID-5 to maximize storage capacity while maintaining
  redundancy
• better redundancy – creates ZFS Stripped RAID-Z2 (RAID 60)) to maximize redundancy while maintaining high storage capacity
• manual – allows users to configure any storage pool type and layout with attached storage

5. Review “Summary” and click the “Create” button to create the pools on storage servers simultaneously.

Create Volume

1. To create volumes, click the “Add” button.

2. Select two identical storage pools to create a volume simultaneously.

3. Specify volume name and capacity.

4. Select the Standard volume type.

5. Review “Summary” and click the “Create” button to create the pool.

Create HA LUN

The LUN availability for StarWind LUN can be Standalone and High availability (2-way or 3-way replication) and is narrowed by your license.

1. To create a virtual disk, click the Add button.

2. Select the protocol.

3. Choose the “High availability” LUN availability type.

4. Select the appliances that will host the LUN. Partner appliances must have identical hardware configurations, including CPU, RAM, storage, and networking.

5. Select a volume to store the LUN data. Selected volumes must have identical storage configurations.

6. Select the “Heartbeat” failover strategy.
NOTE:  To use the Node witness or the File share witness failover strategies, the appliances should have these features licensed.

7. Specify the HA LUN settings, e.g. name, size, and block size. Click Next.

8. Review “Summary” and click the “Create” button to create the LUN.

Creating StarWind HA LUNs using PowerShell

1. Open PowerShell ISE as Administrator.

2.  Open StarWindX sample CreateHA_2.ps1 using PowerShell ISE. It can be found here:
C:\Program Files\StarWind Software\StarWind\StarWindX\Samples\

2.  Configure script parameters according to the following example:

Detailed explanation of script parameters:

-addr, -addr2 — partner nodes IP address.
Format: string. Default value: 192.168.0.1, 192.168.0.1
allowed values: localhost, IP-address
-port, -port2 — local and partner node port.
Format: string. Default value: 3261
-user, -user2 — local and partner node user name.
Format: string. Default value: root
-password, -password2 — local and partner node user password.
Format: string. Default value: starwind

#common
-initMethod –
Format: string. Default value: Clear
-size – set size for HA-devcie (MB)
Format: integer. Default value: 12
-sectorSize – set sector size for HA-device
Format: integer. Default value: 512
allowed values: 512, 4096
-failover – set type failover strategy
Format: integer. Default value: 0 (Heartbeat)
allowed values: 0, 1 (Node Majority)
-bmpType – set bitmap type, is set for both partners at once
Format: integer. Default value: 1 (RAM)
allowed values: 1, 2 (DISK)
-bmpStrategy – set journal strategy, is set for both partners at once
Format: integer. Default value: 0
allowed values: 0, 1 – Best Performance (Failure), 2 – Fast Recovery (Continuous)

#primary node
-imagePath – set path to store the device file
Format: string. Default value: My computer\C\starwind”. For Linux the following format should be used: “VSA Storage\mnt\mount_point”
-imageName – set name device
Format: string. Default value: masterImg21
-createImage – set create image file
Format: boolean. Default value: true
-targetAlias – set alias for target
Format: string. Default value: targetha21
-poolName – set storage pool
Format: string. Default value: pool1
-aluaOptimized – set Alua Optimized
Format: boolean. Default value: true
-cacheMode – set type L1 cache (optional parameter)
Format: string. Default value: wb
allowed values: none, wb, wt
-cacheSize – set size for L1 cache in MB (optional parameter)
Format: integer. Default value: 128
allowed values: 1 and more
-syncInterface – set sync channel IP-address from partner node
Format: string. Default value: “#p2={0}:3260”
-hbInterface – set heartbeat channel IP-address from partner node
Format: string. Default value: “”
-createTarget – set creating target
Format: string. Default value: true
Even if you do not specify the parameter -createTarget, the target will be created automatically.
If the parameter is set as -createTarget $false, then an attempt will be made to create the device with existing targets, the names of which are specified in the -targetAlias (targets must already be created)
-bmpFolderPath – set path to save bitmap file
Format: string.

#secondary node
-imagePath2 – set path to store the device file
Format: string. Default value: “My computer\C\starwind”. For Linux the following format should be used: “VSA Storage\mnt\mount_point”
-imageName2 – set name device
Format: string. Default value: masterImg21
-createImage2 – set create image file
Format: boolean. Default value: true
-targetAlias2 – set alias for targetFormat: string.
Default value: targetha22
-poolName2 – set storage pool
Format: string. Default value: pool1
-aluaOptimized2 – set Alua Optimized
Format: boolean. Default value: true
-cacheMode2 – set type L1 cache (optional parameter)
Format: string. Default value: wb
allowed values: wb, wt
-cacheSize2 – set size for L1 cache in MB (optional parameter)
Format: integer. Default value: 128
allowed values: 1 and more
-syncInterface2 – set sync channel IP-address from partner node
Format: string. Default value: “#p1={0}:3260”
-hbInterface2 – set heartbeat channel IP-address from partner node
Format: string. Default value: “”
-createTarget2 – set creating target
Format: string. Default value: true
Even if you do not specify the parameter -createTarget, the target will be created automatically.If the parameter is set as -createTarget $false, then an attempt will be made to create the device with existing targets, the names of which are specified in the -targetAlias (targets must already be created)
-bmpFolderPath2 – set path to save bitmap file
Format: string.

Selecting the Failover Strategy

StarWind provides 2 options for configuring a failover strategy:

Heartbeat

The Heartbeat failover strategy allows avoiding the “split-brain” scenario when the HA cluster nodes are unable to synchronize but continue to accept write commands from the initiators independently. It can occur when all synchronization and heartbeat channels disconnect simultaneously, and the partner nodes do not respond to the node’s requests. As a result, StarWind service assumes the partner nodes to be offline and continues operations on a single-node mode using data written to it.
If at least one heartbeat link is online, StarWind services can communicate with each other via this link. The device with the lowest priority will be marked as not synchronized and get subsequently blocked for the further read and write operations until the synchronization channel resumption. At the same time, the partner device on the synchronized node flushes data from the cache to the disk to preserve data integrity in case the node goes down unexpectedly. It is recommended to assign more independent heartbeat channels during the replica creation to improve system stability and avoid the “split-brain” issue.
With the heartbeat failover strategy, the storage cluster will continue working with only one StarWind node available.

Node Majority

The Node Majority failover strategy ensures the synchronization connection without any additional heartbeat links. The failure-handling process occurs when the node has detected the absence of the connection with the partner.
The main requirement for keeping the node operational is an active connection with more than half of the HA device’s nodes. Calculation of the available partners is based on their “votes”.
In case of a two-node HA storage, all nodes will be disconnected if there is a problem on the node itself, or in communication between them. Therefore, the Node Majority failover strategy requires the addition of the third Witness node or file share (SMB) which participates in the nodes count for the majority, but neither contains data on it nor is involved in processing clients’ requests. In case an HA device is replicated between 3 nodes, no Witness node is required.
With Node Majority failover strategy, failure of only one node can be tolerated. If two nodes fail, the third node will also become unavailable to clients’ requests.
Please select the required option:

Provisioning StarWind HA Storage to oVirt Hosts

1. Login to oVirt engine and open Storage -> Domain. Clock New Domain.

2. Choose Storage Type – iSCSI, Host and Name of Storage Domain. Discover targets via iSCSI links, which were previously configured. Click Login All.
3. Add LUN from each iSCSI target. Click OK.

4. Storage Domain will be added to the list of Domain and can be used as a storage for VMs.

5. Login to each host and verify that multipathing policy has been applied using the following command.

Conclusion

Setting up StarWind Virtual SAN CVM within the Red Hat oVirt [KVM] environment is significant for organizations looking for a robust, VM-centric and highly-avaialble storage solution. This guide ensures that IT professionals are armed with the essential knowledge and resources for a seamless deployment and configuration.