0% found this document useful (0 votes)
130 views39 pages

Dell SRDF/Metro vWitness Guide

The Dell SRDF/Metro vWitness Configuration Guide provides detailed instructions for configuring and managing the Virtual Witness (vWitness) option in SRDF/Metro environments to enhance high availability. It covers installation procedures for both Linux and virtual appliance deployments, as well as management and monitoring of vWitness instances. The guide also discusses the benefits of vWitness, including redundancy and secure connections, and outlines various failure scenarios to illustrate the system's resiliency features.

Uploaded by

murali79211
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
130 views39 pages

Dell SRDF/Metro vWitness Guide

The Dell SRDF/Metro vWitness Configuration Guide provides detailed instructions for configuring and managing the Virtual Witness (vWitness) option in SRDF/Metro environments to enhance high availability. It covers installation procedures for both Linux and virtual appliance deployments, as well as management and monitoring of vWitness instances. The guide also discusses the benefits of vWitness, including redundancy and secure connections, and outlines various failure scenarios to illustrate the system's resiliency features.

Uploaded by

murali79211
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Dell SRDF/Metro

vWitness Configuration Guide

March 2024
Rev. 11
Notes, cautions, and warnings

NOTE: A NOTE indicates important information that helps you make better use of your product.

CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid
the problem.

WARNING: A WARNING indicates a potential for property damage, personal injury, or death.

© 2016 - 2024 Dell Inc. or its subsidiaries. All rights reserved. Dell Technologies, Dell, and other trademarks are trademarks of Dell Inc. or its
subsidiaries. Other trademarks may be trademarks of their respective owners.
Contents

Figures..........................................................................................................................................4

Tables........................................................................................................................................... 5

Chapter 1: Product Overview.........................................................................................................6


Introduction........................................................................................................................................................................... 7
Virtual Witness (vWitness)................................................................................................................................................8
Functional overview...................................................................................................................................................... 9
vWitness benefits.........................................................................................................................................................10
Witness failure scenarios.................................................................................................................................................. 11

Chapter 2: Install and configure................................................................................................... 13


How to use this chapter................................................................................................................................................... 13
System architecture guidelines.......................................................................................................................................14
Configuration guidelines............................................................................................................................................. 14
Quantity of vWitness installations............................................................................................................................14
Linux deployment............................................................................................................................................................... 15
Hardware and software requirements.................................................................................................................... 15
Install the vWitness instances...................................................................................................................................19
Define the vWitness instances on the storage systems....................................................................................20
Replace the TLS certificates (optional)..................................................................................................................21
UTC time synchronization......................................................................................................................................... 22
Upgrade a vWitness instance................................................................................................................................... 22
Uninstall the vWitness instances............................................................................................................................. 23
vApp deployment...............................................................................................................................................................24
Preparation....................................................................................................................................................................24
Install the vWitness instances.................................................................................................................................. 27
Import TLS certificates (optional)...........................................................................................................................29
Define the vWitness instances on the storage systems....................................................................................30
UTC time synchronization......................................................................................................................................... 30
Update a vWitness instance..................................................................................................................................... 30

Chapter 3: Manage and monitor................................................................................................... 31


Manage and monitor vWitness definitions on a storage array............................................................................... 32
Unisphere for PowerMax...........................................................................................................................................32
Unisphere for VMAX...................................................................................................................................................34
SYMCLI commands..................................................................................................................................................... 36
Manage instances of vWitness...................................................................................................................................... 39
Create a vWitness....................................................................................................................................................... 39
Remove a vWitness.................................................................................................................................................... 39
Download vWLS log files................................................................................................................................................. 39

Contents 3
Figures

1 SRDF/Metro vWitness vApp and connections...................................................................................................8


2 SRDF/Metro Witness single failure scenarios....................................................................................................11
3 SRDF/Metro Witness multiple failure scenarios............................................................................................... 12

4 Figures
Tables

1 Deployment options................................................................................................................................................. 13
2 vWitness details........................................................................................................................................................ 14
3 Certificate files..........................................................................................................................................................16
4 Version number format............................................................................................................................................17
5 Site information.........................................................................................................................................................18
6 TCP ports.................................................................................................................................................................. 25
7 vWitness definition.................................................................................................................................................. 32
8 vWitness definition.................................................................................................................................................. 34

Tables 5
1
Product Overview
This chapter introduces SRDF/Metro and its resiliency features:
Topics:
• Introduction
• Virtual Witness (vWitness)
• Witness failure scenarios

6 Product Overview
Introduction
SRDF/Metro changes SRDF behavior to better achieve the high availability requirements of today's applications. In traditional
SRDF, only R1 (source) devices are Read/Write accessible to the host, while R2 (target) devices are Read Only/Write Disabled
to the host. With SRDF/Metro:
● R2 devices are Read/Write accessible to the host.
● Hosts can write to both the R1 and R2 side of the device pair.
● R2 devices assume the same external device identity (such as, geometry and device WWN) as their R1 partners.
This shared identity means that the R1 and R2 devices appear to hosts as a single virtual device.
If one or more device pairs become Not Ready (NR) or connectivity is lost between the arrays, SRDF/Metro must decide which
side of the pair remains accessible to the hosts. There are two mechanisms that SRDF/Metro can use to make this decision:
Device Bias and Witness.

Device Bias
Device pairs for SRDF/Metro are created with a bias attribute. By default, the create pair operation sets the bias to the R1
side of the pair. That is, if a device pair becomes Not Ready (NR) on the SRDF link, the R1 (bias side) remains accessible
to the hosts, and the R2 (nonbias side) becomes inaccessible. However, if there is a failure on the R1 side, the host loses all
connectivity to the device pair. The Device Bias method cannot make the R2 device available to the host.

Witness
A third party mediates between the two arrays helping to:
● Decide which side remains available to the host
● Avoid a "split brain" scenario where both arrays attempt to remain accessible to the host despite the failure
There are two forms of the Witness mechanism.
● Array Witness: The operating environment on a third array is the mediator.
● Virtual Witness: A daemon running on a separate, virtual machine is the mediator.
This method is available in PowerMaxOS 10 (6079), PowerMaxOS 5978 and HYPERMAX OS 5977.945.890 or later.

The Array Witness method provides the highest availability. However, the added requirement of a third array may prevent its use
in some environments. So, Virtual Witness provides similar functionality and availability as Array Witness, without the need for a
third array.
This guide shows how to configure and manage SRDF/Metro with the Virtual Witness option.
The Dell SRDF Introduction provides more information about SRDF/Metro.

Product Overview 7
Virtual Witness (vWitness)
Virtual Witness (vWitness) is a resiliency option that runs as a daemon on a Linux system (when either or both of the SRDF/
Metro arrays run PowerMaxOS 10) or in a virtual appliance (vApp) on a VMware ESXi server (when the arrays run PowerMaxOS
5978 or HYPERMAX OS 5977). There can be up to 32 daemons for Linux deployment or vApps, each providing a vWitness
instance.
NOTE:
● It is recommended to use the Linux deployment option when the SRDF/Metro arrays run PowerMaxOS 10 or in a mixed
environment.
● The daemon on a Linux system is backward-compatible.

Figure 1. SRDF/Metro vWitness vApp and connections

The R1 and R2 arrays each contain a user-defined list of vWitness definitions that identifies the vWitness instances that each
array can use. A vWitness definition consists of a user-specified name and the location of the instance (either the IP address or
the fully qualified DNS name). The lists of vWitness definitions on each array do not have to be identical. However, they must
have at least one definition in common. Initially, the R1 and R2 arrays negotiate which vWitness instance to use from the list of
vWitness definitions that both arrays have in common.
Unisphere for PowerMax, Unisphere for VMAX, and Solutions Enabler provide facilities to manage a vWitness configuration. The
user can:
● Add, modify, remove, enable, disable, and view vWitness definitions on the arrays.
● Add and remove vWitness instances.
To remove an instance, it must not be actively protecting any SRDF/Metro sessions.

8 Product Overview
Functional overview
A vWitness instance is a daemon process, known as the vWitness Lock Service (or vWLS), running on a Linux system or in a
vApp. On each of the R1 and R2 arrays, another daemon, known as the vWitness manager (or vWM), runs on both management
guests (for redundancy). That process acts as a proxy between the arrays and the vWitness instances (the vWLS instances).

Selecting a vWitness instance


Activity between a pair of SRDF/Metro groups is known as a SRDF/Metro session. When a session starts, the R1 and R2
arrays negotiate which of the available vWitness instances to use to protect the session. Thus, an individual array could be
using several vWitness instances simultaneously. In the same way, an individual vWitness instance may be monitoring several
SRDF/Metro sessions simultaneously.

Monitoring the connections to vWitness instances


Both vWMs on each array polls all the vWitness instances in its definition list every second. Each vWLS daemon sends a reply.
This poll and response technique enables vWM to maintain the list of instances that are available and operational.
If an array detects that an instance has not responded for 10 seconds, it checks whether the instance is in use by any SRDF/
Metro session. If it is in use, the R1 and R2 arrays negotiate an alternative witness to use in its place. If there are no witnesses
available, the session uses Device Bias as a fallback.

Acting on a systems failure


If either array detects that a session has failed, it asks the vWM to request a lock from the vWitness instance that is allocated
to the SRDF/Metro session. A session fails when the array loses contact with its partner group either due to a failure of the
SRDF link or in the partner array.
On the R1 side (preferred winner), vWM sends the request to the vWitness instance for that session immediately. Typically,
vWM waits 5 seconds before sending the request from the R2 side. This delay allows time for the R1 side to request the lock.
That is, R1 has priority and gets the lock if it asks for it during this 5 second period.
The vWitness instance grants the lock in response to the first request it receives. The side that gains the lock remains available
to the host while the other side becomes unavailable.

Determining the preferred winner


Besides determining which vWitness instance to use, the arrays in each SRDF/Metro session also negotiate which of them is
the preferred winner. If a failure occurs, the preferred winner is the side that has priority when requesting the lock from the
vWitness instance. That is, the preferred winner is the R1 side.
When either side runs HYPERMAX OS 5977, SRDF/Metro uses the bias settings for the devices to determine the preferred
winner. That is, the devices that are defined as the being on the bias side, if Device Bias were in use, become the preferred
winners.
When both sides run PowerMaxOS, SRDF/Metro takes extra factors into account to determine the preferred winner (in priority
order):
1. The side that has host connectivity (requires PowerMaxOS 10 [Link] (6079)) or PowerMaxOS 5978.444.444 or later).
This functionality monitors the connections to the host that are mapped to SRDF/Metro devices to check that the
connections are operational.
2. The side that has a write pending (WP) value that is less than 80% of the System WP Limit (requires PowerMaxOS
5978.669.669 or later).
3. The opposite side from the side that has a dual RAID failure. That is two spindles are down in a RAID 5 group or 3 spindles
are down in a RAID 6 group, (requires PowerMaxOS 10 [Link] (6079)).
4. The side that has an SRDF DR leg.
5. Whether the SRDF/S DR leg is synchronized (requires PowerMaxOS 10 [Link] (6079)).
6. Whether the SRDF/A DR leg is synchronized.
7. The side that has an SRDF/A DR leg.
8. The side that has the SRDF DR link up.

Product Overview 9
9. The side that has a ready mirror on the SRDF DR leg.
10. The side that has more than 50% of the RA or FA directors that are available
11. The side that is the preferred side (if the user has set one).
From PowerMaxOS 10 [Link] (6079) the storage administrator can specify the preferred side of an SRDF/Metro pair. In
previous versions of the operating environment, or when the administrator has not specified a preferred side, the R1 side is
the winner. The first of these criteria that one array has, and the other does not, stops the selection.

The first of these criteria that one array has, and the other does not, stops the selection process. The side with that criteria is
the preferred winner.
The two sides regularly repeat this selection process for each SRDF/Metro group to ensure that the winning side remains the
one that is most preferable. So, the winning side may change during the SRDF/Metro session. SRDF/Metro always reports the
winning side as the R1 device and the losing side as R2. So each switch in the winning side causes an apparent swap of the R1
and R2 personalities in the session.
The assessment of the winning and losing side occurs separately for each SRDF/Metro group that exists between two arrays.
So, on a particular array, some devices could be R1 devices while others are R2 devices. Which are R1 and which are R2 depends
on the outcome of assessing their respective SRDF/Metro groups.

vWitness benefits
vWitness provides the following benefits:
● Provides a similar level of high availability as the Array Witness option, without requiring a third array.
● Multiple vWitnesses can be configured for redundancy.
● The IP connections between each vWitness instance and the management guests on arrays that the witness protects, are
secured using TLS/SSL.
● vWitness and Array Witness options can be used together.

10 Product Overview
Witness failure scenarios
These diagrams show how SRDF/Metro reacts to various failure scenarios when either Witness option is in use.

S1 R1 side of device pair


S1 S2 S1 S2
S2 R2 side of device pair

W Witness Array/vWitness X
SRDF links W X
W
SRDF links/IP connectivity*
S1 and S2 remain S1 and S2 remain
X Failure/outage accessible to host accessible to host
S2 wins future failures Move to bias mode
* Depending on witness type
S1 calls home S1 and S2 call home

X
S1 S2 S1 X S2 S1 S2

X
W W W

S1 failed S1 remains accessible S1 and S2 remain


S2 remains accessible to host accessible to host
to host S2 suspends S1 wins future failures
S2 calls home

S1 X
S2

S2 failed
S1 remains accessible to host
Figure 2. SRDF/Metro Witness single failure scenarios

Product Overview 11
S1 S2 S1 X S2 S1 X S2

X X X
W X
W W

S1 and S2 remain S1 and S2 suspend S1 remains


accessible to host S1 and S2 call home accessible to host
Move to bias mode S2 suspends
S1 and S2 call home S2 calls home

S1 X S2 X
S1 S2 S1 X
S2

X X X
W W W

S1 suspends S1 failed S1 suspends


S2 remains S2 suspends S2 failed
accessible to host S2 calls home S1 calls home
S2 calls home

X
S1 S2 S1 X
S2 S1 X S2

X X
X
W X
W W

S1 failed S1 suspends S1 suspends


S2 suspends S2 failed S2 suspends
S2 calls home S1 calls home S1 and S2 call home

Figure 3. SRDF/Metro Witness multiple failure scenarios

12 Product Overview
2
Install and configure
This chapter shows how to install and configure a vWitness instance:
Topics:
• How to use this chapter
• System architecture guidelines
• Linux deployment
• vApp deployment

How to use this chapter


This chapter shows how to install a vWitness instance and covers both deployment methods for a vWitness instance, a Linux
daemon and a vApp on an ESXi server.

Table 1. Deployment options


Operating environment running on the arrays in the Instructions
SRDF/Metro configuration
One or both arrays run PowerMaxOS 10 (6079). 1. Use the System architecture guidelines to determine the
appropriate number of vWitness instances for your site.
2. Recommended: Follow the instructions in Linux
deployment to install each instance.
3. Optional: Follow the instructions in vApp deployment to
install each instance.
The arrays run PowerMaxOS 5978 or HYPERMAX OS 5977. 1. Use the System architecture guidelines to determine the
appropriate number of vWitness instances for your site.
2. Recommended: Follow the instructions in vApp
deployment to install each instance.
3. Optional: Follow the instructions in Linux deployment to
install each instance.

Install and configure 13


System architecture guidelines
This section provides guidance on deploying vWitness facilities with SRDF/Metro.

Configuration guidelines
● Put the primary (R1) and secondary (R2) arrays on separate sites with each array in its own fault domain (to include network
and power domains).
● Have at least two vWitness instances, where the second instance is used for improved resiliency for each SRDF/Metro
configuration on separate sites:
○ Place each instance in a separate fault domain (to include hardware, network and power domains).
NOTE: If two separate fault domains are unavailable for vWitness, it is possible to place the two vWitnesses on a
third fault domain but on different Linux or ESX servers. This would provide hardware fault separation and some
degree of protection. However, sharing power and network domains means any impact to either domain would also
impact both witnesses.

NOTE: If two fault events occur impacting the vWitness and one side of SRDF/Metro within the timeframe that
SRDF/Metro requires to renegotiate to use the second witness, an outage would still occur.
○ Avoid placing any instance in the same fault domain as the SRDF/Metro configuration it protects. Never configure a
witness to access both sites through a single site in an "L" configuration.
● Ensure that the vWitness instances have independent network connectivity (latency less than 40 ms) to both the primary
and secondary sites.
This configuration can withstand most failures including communications failure between the primary and secondary sites. It also
prevents a split brain scenario from occurring.
NOTE: vWitness is a fully autonomous process and users have no influence on the vWitness selection process. To remove a
vWitness instance it must not be actively monitoring SRDF/Metro activities.
For extra resilience, consider enhancing this minimum configuration with more vWitness installations (see Quantity of vWitness
installations).

Quantity of vWitness installations


● Have at least two vWitness instances for every SRDF/Metro configuration. The second vWitness provides witness resiliency
and helps to avoid a single point of failure if the vWitness is impacted.
● Spread vWitness instances over multiple servers, where possible, to avoid having them all run on one server (which creates a
single point of failure).
● Where possible, have the vWitness installations at sites separate from the arrays that participate in SRDF/Metro sessions.
This helps to ensure that a failure at one site affects only one of the arrays or a vWitness.
● Ensure that there are sufficient witnesses to protect the number of SRDF/Metro groups that you intend to have active. The
maximum number of arrays, array pairs, and SRDF/Metro groups that a single vWitness instance can serve are:

Table 2. vWitness details


vWitness details Number
Arrays: 64
Array pairs: 32
SRDF/Metro groups: 2048

14 Install and configure


Linux deployment
Linux deployment is the recommended vWitness deployment type in an SRDF/Metro context where at least one of the
co-operating arrays is running PowerMaxOS 10 (6079).

Hardware and software requirements


Ensure that the storage systems and servers that are to run the vWitness instances meet the following requirements. In
addition, gather the items and information that you need to carry out the installation.

Storage systems
The requirements for storage systems in each SRDF/Metro configuration are:
● A pair of storage arrays that either:
○ Both run PowerMaxOS 10 (6079). Or
○ One array runs PowerMaxOS 10 (6079) and the other a compatible version of PowerMaxOS 5978 or HYPERMAX OS
5977. Or
○ Both arrays run a compatible version of either PowerMaxOS 5978, or HYPERMAX OS 5977. The SRDF and NDM
Interfamily Connectivity Information defines the versions of PowerMaxOS 5978 and HYPERMAX OS 5977 that can make
up a SRDF/Metro pair.
NOTE: The recommended vWitness deployment in this scenario is the vApp deployment.
● An SRDF/Metro license is installed on each array.
● There is RA (Fibre/SAN) or RE (Ethernet/IP) connectivity between the paired arrays.
● There is Ethernet/IP connectivity between each array and each Linux system that contains a vWitness instance that the
arrays are to use.

Linux systems and related software


A host system for a vWitness instance has:
● An x86 system with a 64-bit architecture that runs any of:
○ RHEL 7
○ RHEL8
○ Oracle Linux 6
○ Oracle Linux 7
○ SLES 12
○ SLES 15
You cannot install a vWitness instance on a system that runs, or previously ran, either of:
● Solutions Enabler
● Unisphere for PowerMax

Install and configure 15


vWitness instances
Before installing vWitness instances:
● Determine the quantity of instances required and the Linux systems they are to run on.
● Ensure that the required TCP ports are open on each of the Linux systems.
● Gather the necessary TLS certificates for each instance.
● Download the vWitness installation kit.

Quantity of vWitness instances


Decide on the quantity of vWitness instances for your site. For each instance:
● Decide on a Linux system to host the instance.
● Gather the IP address or fully qualified DNS name of the Linux system.
● Decide on a name for the instance:
○ The name has up to 12 characters.
○ The first character of the name is an alphabetic character.
○ The remainder of the name can contain alphanumeric characters, underscores, and hyphens.
○ The name is not case-sensitive, but the system preserves the case.

TCP ports
On each Linux system that is to host a vWitness instance, ensure that TCP port 10123 is open. If the default port of 10123 is not
suitable, an alternate port may be used. See Alternate Port Configuration for more information.

TLS certificates
One or more clients running Unisphere or Solutions Enabler (collectively called management clients) can manage a vWitness
instance. Each connection between a client and the instance can be secured using TLS certificates.
The vWitness installation kit includes a set of self-signed certificates. These provide adequate security for test installations. In a
production environment, replace these certificates with ones that are signed by a customer-managed root certificate authority
(using the appropriate X.509 version 3 Basic Constraints and X. 509 version 3 Key Usage extensions), or by a commercial
certification authority. Such certificates provide a higher degree of security.

Table 3. Certificate files


System Required certificate files
vWitness instance ● Public key for the vWitness instance
● Private key for the vWitness instance
● Certificate authority public key for all client management
certificates
Management client ● Public key for the management client
● Private key for the management client
● Certificate authority public key for all vWitness instance
certificates

Ensure that you have certificate files for all vWitness instances and management clients on a storage media (for example, USB
storage).

16 Install and configure


Installation kit
Obtain the installation kit for the Linux vWitness instances from Dell Technologies Online Support. Put a copy of the kit in a
temporary directory on each Linux system that is to host a vWitness instance.
The format of the name for the installation kit is:
vwitness<version>-Linux-x86_64-[Link]
In the name, <version> is a representation of the version of Solutions Enabler that the installer is related to (a vWitness instance
includes elements of Solutions Enabler). The format of the version number is:
[Link]

Table 4. Version number format


Variable Details
MA is the major version number
MI is the minor version number
PI is the point number
PA is the patch or build number

For example, when the version of Solutions Enabler is [Link] the name of the installer kit is vwitness1000408-Linux-
x86_64-[Link].
The kit is a compressed archive. During the installation procedure, you unpack this archive and run the installation script that is
part of the archive's contents. The name of this script is:
vwitnessMAMIPIPA_install.sh
For example: vwitness1000408_install.sh

Other software
To manage vWitness instances running on Linux systems and their corresponding vWitness definitions on storage systems
requires the following software:
● Solutions Enabler 10.0 or later
● Unisphere for PowerMax 10.0 or later
In addition, to be able to install a vWitness instance remotely from the Linux system it runs on requires a remote access tool
such as PuTTY or Remote Desktop Connection.

Gather installation information and materials


During the installation, you can define certain locations and values:
● The directories that hold the vWitness executable files and its datafiles
● The password of the lockbox
● The directory permissions and runtime user of the daemon processes

File directories
A vWitness instance uses two directories that hold its executable files (the installation directory) and datafiles (the data
directory). The default directories that a vWitness instance uses are:
● Executable files: /opt/emcvw
● Data files: /usr/emcvw
You can use an alternative location of either or both of these directories.

Install and configure 17


Lockbox password
A vWitness installation includes a lockbox that contains sensitive data such as key values for security certificates. The lockbox
has an associated password. The default password is:
● hostname@SELockbox1
hostname is the name of the Linux system.

Do not use the default password in a production environment. Instead, use a password that cannot be easily guessed but that
you can remember.
A valid password contains at least:
● Eight characters
● One upper case letter
● One lower case letter
● One numeric digit
● One special character
Special characters are: !@#%&

Daemon process permissions and runtime user


A vWitness instance uses several daemon processes. The executable files for these daemon processes are in a protected
directory. In addition, the processes use a specific runtime user:
● Directory protection code: 755
● Runtime user: root
You can change either or both of these characteristics.

Site information
Use this table to record the values for your vWitness installation:

Table 5. Site information


Item Default Your value
Installation directory /opt/emcvw -
Data directory /usr/emcvw -
Lockbox password hostname@SELockbox1 -
Daemon directory permissions 755 -
Daemon runtime user root -

Materials
Finally, check that you have all the materials necessary to successfully install the vWitness instance:
● Installation kit
● TLS certificate files (if you are replacing the default certificates with CA-generated ones).
● Management software
● Remote access tool

18 Install and configure


Install the vWitness instances
The vWitness installer can run in either of two ways:
● Interactive
● Silent
Follow the instructions for the method you wish to use for each vWitness instance.

Interactive installation
1. Log in to the Linux system and select the directory that holds the installation kit.
2. Unpack the installation kit using a suitable utility.
3. Check that you have all the information you need for the installation, then start the installation script. For example:
./vwitness1000408_install.sh -install
The script displays some introductory information.
4. The script asks if you want to change the installation directories:

Do you want to change Install root Directory. [N] :

To use custom installation directories:

a. Enter Y.
b. The script prompts for the names to use:

Install root directory:


Working root directory:

c. In reply to each prompt, enter the name of the appropriate directory.


To use the existing directories, enter N or press Return.
5. Next, the script asks if you want to run the vWitness daemons as a nonroot user:

Following daemons can be set to run as a non-root user:


storevntd, storgnsd, storrdfd, storsrvd, storstpd, storwatchd
Do you want to run these daemons as a non-root user? [N]:

To change the runtime user:

a. Enter Y.
b. When prompted, enter the user to use as the runtime user for the daemons.
To continue to run the daemons under the root user, enter N or press Return.
6. The script asks if you want to change the permissions of the daemon directory:

Do you want to change default permission on /var/symapi directory from [755]? [N]:

To change the directory permissions:

a. Enter Y.
b. When prompted, enter the permission code to use for the directory.
To leave the permissions unchanged, enter N or press Return.
7. The script asks if you want to change the default password of the lockbox:

Do you want to use the default Lockbox Password ? [N]:

To change the password:

a. Enter N.
b. When prompted enter the new password for the lockbox?
c. Confirm the new password when prompted.

Install and configure 19


To use the default password:
a. Enter Y.
b. When prompted confirm that you want to use the default password.
The script installs the vWitness components and applies the choices that you made. On completion, the script displays this
message:

#-----------------------------------------------------------------------------
# The following HAS BEEN INSTALLED in /opt/emcvw via the rpm utility.
#-----------------------------------------------------------------------------
ITEM PRODUCT VERSION
01 Dell EMC Solutions Enabler <DSV version >
vWITNESS KIT
#-----------------------------------------------------------------------------

Silent installation
1. Log in to the Linux system and navigate to the directory that holds the installation kit.
2. Unpack the installation kit using a suitable utility.
3. Check that you have all the information you need for the installation, then start the installation script using options to specify
the values specific to your installation. For example:
./vwitness1000408_install.sh -install -silent -homedir=filepath -datadir=filepath
-daemonuid=username -lockboxpassword=password
Include the options applicable to the values you want to change. To use a default value, omit the corresponding option.
The script installs the vWitness instance, displaying messages that shows its progress.

This example uses the default settings for the installation directories and the daemon directory permissions. However, It sets the
runtime user of the daemons to daemon_user and the lockbox password to my#P@3s8&d:

./vwitness1000408_install.sh -install -silent daemonuid=daemon_user


-lockboxpassword=my#P@3s8&d

NOTE: If IPv6 connections are used from the array, the following definition must be added to /var/symapi/config/
daemon_options on the storvwlsd side (the lock service side):

storvwlsd:ipv6 = force

Alternate Port Configuration


If the default port of 10123 is not suitable, an alternate port may be used. To configure an alternate port:
1. Log in to the vWitness Lock Service host and edit the /var/symapi/config/daemon_options file.
2. Change the default storvwlsd port storvwlsd:PORT = 10123 to a suitable port number.
NOTE: Ensure that you configure the lock service on all relevant arrays to use this alternate port. For example, when
using the symcfg add command for the lock service definition, use the alternate port, use the alternate port

symcfg -sid <SymmID> add -witness <WitnessName> -location <DNSorIPAddr> [-port


port]

Define the vWitness instances on the storage systems


Follow the instructions in Manage and monitor vWitness definitions on a storage array to create vWitness definitions on each
storage array that runs SRDF/Metro. You can use Unisphere or SYMCLI.

20 Install and configure


Replace the TLS certificates (optional)
To replace the supplied certificates with ones that are customer signed or from a commercial certificate authority:
1. Check that you have all the certificates that are listed in TLS certificates.
2. Replace the certificates on the vWitness instance.
3. Replace the certificates on each management client.
NOTE:

Other vWitness instances that are managed by these eMGMT instances with new certificates also require updating.

Replace the certificates on a vWitness instance


1. Open a terminal session on the Linux system that hosts the vWitness instance and navigate to:
/var/symapi/config/cert
2. Remove all files with the .pem extension and the soft links in the directory.
The name of a soft link usually consists of a hash value and has a numeric extension.
3. Copy the certificate files for the vWintess into this directory:
● Public key for the vWitness instance
● Private key for the vWitness instance
● Certificate authority public key for all management client certificates
4. Enter:

manage_server_cert update

This command recreates the hash links that the instance requires.

5. Navigate to /var/symapi/config and open the daemon_options file in a text editor.


6. Locate and edit the lines:

storsrvd:SECURITY_ALT_CERT_FILE = <SERVER_CERT.pem>
storsrvd:SECURITY_ALT_KEY_FILE = <SERVER_KEY.pem>

Replace:
<SERVER_CERT.pem> with the name of the public key for the vWitness instance
<SERVER_KEY.pem> with the name of the private key for the vWitness instance
Use the file names only. Do not include the directory paths.

7. Start, or restart, the vWitness daemon storvwlsd.

Replace the certificates on a management client


1. Open a terminal session on the management client and navigate to:
/var/symapi/config/cert
2. Remove all files with the .pem extension and the soft links in the directory.
The name of a soft link usually consists of a hash value and has a numeric extension.
3. Copy the certificate files for the client into this directory:
● Public key for the management client
● Private key for the management client
● Certificate authority public key for all vWitness instance certificates
4. Enter:

manage_server_cert update

This command recreates the hash links that the client requires.

Install and configure 21


5. Navigate to /var/symapi/config and open the options file in a text editor.
6. Locate and edit the lines:

SYMAPI_SECURITY_ALT_CERT_FILE = <CLIENT_CERT.pem>
SYMAPI_SECURITY_ALT_KEY_FILE = <CLIENT_KEY.pem>

Replace:
<CLIENT_CERT.pem> with the name of the public key for the management client
<CLIENT_KEY.pem> with the name of the private key for the management client
Use the file names only. Do not include the directory paths.

7. Start, or restart, the vWitness daemon storvwmd.

UTC time synchronization


The UTC time of each storage array and vWitness instance needs to be synchonized. The daemon that contains a vWitness
synchronizes its time with the Linux host. So the UTC time setting on the physical host and on the storage arrays must be
synchronized. Use a facility such as the Network Time Protocol (NTP) to achieve this.
On the Linux host, use an NTP product to connect to an NTP server that provides time synchronization. On the storage arrays
use Unisphere to set up NTP:
1. Log in to Unisphere and on the home dashboard, select an SRDF/Metro storage array.
2. Select Servicability in the left-hand panel and then click the NTP Server tab.
3. Enter the address of the NTP server in the IP Address text box.
Make sure that a vWitness Linux server and all the storage arrays that use it connect to the same NTP server.
4. Click Save.
NOTE: If the array runs PowerMaxOS 5978 or HYPERMAX OS 5977 set up NTP on the array using the vApp Manager (see
UTC time synchronization).

Upgrade a vWitness instance


Dell Technologies distributes updates to vWitness as new distribution kits, with a revised version number. Install the upgrade in
the same way as you installed the initial instance (see Install the vWitness instances).
In an interactive installation, the prompts and responses are the same as an initial installation except that the script prompts to
stop the vWitness daemons. In a silent installation, the script stops the daemons without prompting you.

22 Install and configure


Uninstall the vWitness instances
The vWitness uninstaller can run in either of two ways:
● Interactive
● Silent
Follow the instructions for the method that you want to use for each vWitness instance.

Interactive uninstall of a vWitness instance


1. Log in to the Linux system and navigate to the directory that holds the installation kit.
2. Verify the installation script used, then start the uninstallation script. For example:
./vwitness1000408_install.sh -uninstall
The script displays some introductory information.
3. The script asks if you want to continue the uninstall:

Would you like to uninstall Solutions Enabler vWitness (Y/N)? [Y]:

Enter Y.

4. The script asks if you want to shutdown the SYMCLI daemons or exit the setup.

Do you want to shutdown SYMCLI daemons [Y] or Exit setup [X]? [Y]:

Enter Y.

5. The script shutdowns symcli daemons and uninstalls the vwitness from your system.

Solutions Enabler vWitness successfully uninstalled from your system.

Silent uninstall of a vWitness instance


1. Log in to the Linux system and navigate to the directory that holds the installation kit.
2. Verify the installation script used, then start the uninstallation script. For example:
./vwitness1000408_install.sh -uninstall
3. The script shutdowns symcli daemons and uninstalls the vwitness from your system. The completed script displays:

Solutions Enabler vWitness successfully uninstalled from your system.

Install and configure 23


vApp deployment
vApp deployment is the recommended vWitness deployment type in an SRDF/Metro context where both arrays run either
PowerMaxOS 5978, or HYPERMAX OS 5977.

Preparation

Hardware and software requirements

Gather the storage systems, VMware ESXi servers, and software necessary to create a vWitness configuration.

Storage systems
The requirements for storage systems are:
● Two storage arrays running PowerMaxOS 10, PowerMaxOS 5978, or HYPERMAX OS 5977.945.890 and later.
● SRDF/Metro license installed on each array.
● eManagement guest for Unisphere on each array. eManagment is standard on PowerMax and VMAX All Flash arrays, and
can be added to VMAX3 arrays in the field. Contact your Dell Technologies representative for more information.
● RA (Fibre or SAN) or RE (Ethernet or IP) connectivity between the paired arrays.
● Ethernet or IP connectivity between each array and each vWitness instance it uses.

VMware ESXi servers


Ensure that each ESXi server you want to use for vWitness operations meets these requirements:
● VMware ESX 4.0 or higher
● Depending on the vApp, the host must meet the following:
○ Solution Enabler Virtual Appliance: Single processor with 2 GB of memory; dual disks, with 16 GB of disk space and 5 GB
of expandable disk space.
○ Unisphere for PowerMax or Unisphere for VMAX: Dual core processor with 16 GB of memory and 120 GB of disk space.
In addition, you require a client system that you use to access the ESX servers, with the following:
● VMware vSphere Client
● Any of the following browsers
○ Internet Explorer 9.0 through 11.0 (Desktop only)
○ Firefox 30 or later
○ Chrome 21.0.1180 or later
Browsers should have Flash Player 11.2 plug-in installed. If the browser has an older version of Flash Player, you are
prompted to download the latest version when you start the web console.

Before you begin


Before you begin to install the Solutions Enabler Virtual Appliance, be sure to complete the tasks that are listed:
1. Verify that you are installing the latest version of the appliance by checking the Dell Technologies Support website for
updates.
2. Verify that the client is running:
● VMware vSphere Client
● Any of the supported browsers with cookies and JavaScript enabled.
3. Verify that VMware ESXi Server meets the following minimum requirements:
● Version 6.0 or later
● Dual disk, 16 GB of disk space and another 5 GB (expandable) disk space
● 2 GB memory

24 Install and configure


● One CPU

Other software
To install and manage a vWitness configuration requires the following additional software:
● Solutions Enabler 8.3 or later
● Unisphere for PowerMax 9.0 or later
● Unisphere for VMAX 8.3 or later
Unisphere is necessary only if you want to manage the vWitness configuration using a GUI. Use Unisphere for PowerMax to
manage a configuration that includes one or more arrays that run PowerMaxOS.

vWitness instances
Decide on the number of instances of vWitness for your site. For each instance:
● Decide which ESXi server the instance runs on.
● Gather the IP address or the fully qualified DNS name of the vApp that runs the instance.
● Decide on a name for the instance.
○ The name has up to 12 characters.
○ The first character of the name is an alphabetic character.
○ The remainder of the name can contain alphanumeric characters, underscores, and hyphens.
○ The name is not case-sensitive, but the system preserves the case.

TCP ports
Ensure that the following TCP ports are open and available for use by vWitness instances and the SRDF/Metro storage
systems. The following table lists the required TCP ports:

Table 6. TCP ports


System Software component Port Used by
number
VMware ESXi host vWitness vApp 10123 vWitness Lock Service
vWitness vApp 5480 vApp Manager
Storage system in a SRDF/Metro Embedded Element Manager 5480 vApp Manager for VMAX
configuration

NOTE: The listed ports are destinations where the specified object receives information. For example, port 10123 on
vWitness vApp that runs on the VMware ESXi host is the port that the vWitness Lock Service receives information from
the Embedded Element Managers in the SRDF/Metro storage systems.

TLS certificates
Each vWitness instance is supplied with TLS security certificates. However, you can replace all these with site-specific
certificates if required. To apply custom certificates, gather the following files in Privacy Enhanced Mail (PEM) format:
● Certificate
● Key
● Trust certificate
Store the files at /var/symapi/config/cert on the client system.
Use the same trust certificate to generate all custom certificates.

Install and configure 25


Installation kit
Obtain the installation kit for the vWitness instances from Dell Technologies Online Support. You need one of:
● The Solutions Enabler Virtual Appliance (vApp)
● The Unisphere for PowerMax vApp
● The Unisphere for VMAX vApp
The virtual appliance runs on the ESXi server creating the vWitness instance.
Put the OVF archive file (*.ova) in a temporary directory on the system that runs the vSphere Client.

26 Install and configure


Install the vWitness instances
NOTE: This section shows one way of installing the vWitness instances that use the Solutions Enabler Virtual Appliance.
The Virtual Appliance Manager Installation Guide shows other ways of installing the instances packaged in either Virtual
Appliance.
For each vWitness instance that your site requires:
1. Import the Virtual Appliance.
2. Power on and configure the Virtual Appliance.

Import the Virtual Appliance


1. Start the vSphere Client and log in to the ESX Server virtual machine on which you are installing the appliance.
2. Click Ignore in the security warning message.
3. From the File menu, select Deploy OVF Template.
4. Browse to the OVF archive file, which is located in the temporary directory you created earlier. Select the OVF archive file
with the suffix *vappxxx_xxx_OVF10.ova.
5. Click Next.
6. On the Details page, verify the details about the appliance and click Next.
7. On the End User License Agreement page, select Accept all license agreements and click Next.
8. On the Name and Location page, specify a name for the appliance and click Next.
9. If a resource pool is available, the Resource Pool page is displayed. Select the resource pool of the choice and click Next.
Otherwise, the Resource Pool page is skipped.
10. On the Datastore page, select the datastore of the choice and click Next.
11. On the Disk Format page, select the format in which to store the virtual machine virtual disks and click Next.
12. On the Network Mapping page, map the source network to the appropriate destination network.
13. On the Ready to Complete page, verify the information and click Finish.
14. In the Completed Successfully message, click Close.

Install and configure 27


Power on and configure the Virtual Appliance
1. On the Summary page of the Virtual Infrastructure Client, click Power On.
2. Click the Console tab and watch as the appliance starts up.
3. At the following prompts, type static IP configuration information:

Please select your static network configuration.


For IPv4: Enter 1
For IPv6: Enter 2
Enter your choice [1]/2:

Please enter static IP configuration:


● IP Address [ ]:
Type the address that is assigned to the appliance, and then type y when asked to Confirm [y]/n and continue with
the configuration.
NOTE: The Virtual Appliance uses this IP address to query the DNS server and get its hostname. Therefore, you
must ensure that the IP address has a hostname mapping in the DNS server.
● Netmask [ ]:
Type the mask of the network on which the appliance will be running, and then type y when asked to Confirm [y]/n
and continue with the configuration.
● Gateway [ ]:
Type the gateway address to the network on which the appliance will be running, and then type y when asked to
Confirm [y]/n and continue with the configuration.

● DNS1 [ ]:
Type the first DNS server address, and then type y when asked to Confirm [y]/n and continue with the
configuration.
● DNS2 [ ]:
Type the second DNS server address, and then type y when asked to Confirm [y]/n and continue with the
configuration.
● Is a proxy server necessary to reach the Internet? y/n [n]:
A [y]es response enables you to specify the IP address of the proxy server and the port.

The network is now configured.

4. At the following prompt, specify whether you want to set the time zone:

Do you want to set the time zone? y/[n] :

A [n]o response continues the configuration. If you select this option, you can use the appliance console to specify the time
zone later.
A [y ]es response produces the following series of prompts that enable you to set the time zone:
● Please select a continent or ocean
Type the number that corresponds to the time zone location and press Enter.
● Please select a country
Type the number that corresponds to the country-specific time zone you want to set and press Enter.
● Please select one of the following time zone regions
Type the number that corresponds to regional time zone you want to set and press Enter.

The time zone is now set.

28 Install and configure


5. At the following prompt, specify whether you want to type the host ESX Server information:

Do you want to set the host ESX Server y/[n]? :

● A n response continues the configuration. If you select this option, you can use the Configuration Manager to add the
host ESX Server details later. For instructions, see the Configuration Manager online help.
● A y response prompts you for the ESX Server hostname. In this case, you should type the fully qualified hostname of ESX
Server and press Enter.
When prompted for the root password, type the root password of the ESX Server virtual machine and confirm it by
typing it again.

A Welcome screen is displayed. You have now finished installing the Solutions Enabler Virtual Appliance.

Enable SSH
1. Launch the vApp Manager by typing the following URL in a browser:
[Link]
Replace appliance with the IP address or fully qualified DNS name of the appliance.
The vApp Manager main window opens.

2. Log in to vApp Manager using seconfig for both the user name and password.
3. When prompted, change the password.
4. Select Command Execution > Host and click Enable SSH.

Import TLS certificates (optional)


To use custom TLS certificates for any vWitness instance, import them. Complete this procedure for each vWitness instance
that has custom certificates. Carry out the procedure on both the Virtual Appliance and the eManagement guests.

Start the certificate management utility


1. Start and log in to vApp Manager on the vWitness instance.
2. Click Appliance Info and in the Operations panel click Certificate management for Solutions Enabler.
The tool to import certificates starts and displays an introductory screen.
3. Click Next.
4. Select Import certificate and click Next.
5. Click Yes in the restart confirmation dialog.
The Import Alternate Private Key window opens.

Import the certificate files


1. Click Import to open a file browser.
2. Navigate to the location of the certificate files, select the file that contains the private key and click Open.
vApp Manager validates the key file.

3. Click Next.
The Import Alternate Certificate window opens.
4. Click Import to open a file browser.
5. Navigate to the location of the certificate files, select the file that contains the alternate certificate, and click Open.
vApp Manager validates the certificate file.

6. Click Next.

Install and configure 29


The Import Custom Trust Certificate window opens.

7. Click Import to open a file browser.


8. Navigate to the location of the certificate files, select the file that contains the trust certificate and click Open.
vApp manager validates the trust certificate.

9. Click Next.
vApp Manager imports the certificate files and restarts the storsrvd and storvwlsd daemons.
10. Click Finish.

Define the vWitness instances on the storage systems


Follow the instructions in Manage and monitor vWitness definitions on a storage array to create vWitness definitions on each
storage array that runs SRDF/Metro. You can use Unisphere or SYMCLI.

UTC time synchronization


The UTC time of each storage array and vWitness instance needs to be synchronized. The vApp that contains a vWitness
synchronizes its time with the VMware ESXi server. So, the UTC time setting on the physical host of that server and on the
storage arrays must be synchronized. Use a facility such as the Network Time Protocol (NTP) to achieve this.
On the server host, use an NTP product to connect to an NTP server that provides time synchronization. On the storage arrays,
use the vApp Manager for eManagement web interface to enable NTP:
1. In a web browser, go to [Link]
Replace emanage-ip-addr with the IP address of the eManagement facility on the storage array.
2. Log in to the vApp Manager for eManagement.
3. Click IP configuration and then click the NTP tab.
4. In the NTP box, type the address of the NTP server and then click Set Config.
More information about using vApp Manager for eManagement is available from its online help.

Update a vWitness instance


The Virtual Appliance Manager Installation Guide shows how to install updates to a vWitness instance that uses the Solutions
Enabler Virtual Appliance.
NOTE: In configurations that include storage arrays running HYPERMAX OS, the version of the Solutions Enabler Virtual
Appliance that runs a vWitness instance must be the same or greater than the version of the eManagement Solutions
Enabler that runs on the storage array. So, if you are performing an upgrade to HYPERMAX OS that includes an upgrade to
the eManagement Solutions Enabler, upgrade the Solutions Enabler Virtual Appliance beforehand. This requirement does not
apply to storage arrays that run PowerMaxOS.

30 Install and configure


3
Manage and monitor
This chapter shows how to manage and monitor a vWitness configuration:
Topics:
• Manage and monitor vWitness definitions on a storage array
• Manage instances of vWitness
• Download vWLS log files

Manage and monitor 31


Manage and monitor vWitness definitions on a storage
array
This section shows how to set up, manage, and monitor a storage array's access to vWitness instances. You can use Unisphere
or SYMCLI commands.
NOTE: When you create a vWitness definition, the system does not check whether the final IP address of the instance is
reachable from the array that holds that definition.

Unisphere for PowerMax


User roles
● To create, enable, modify, delete, or disable a vWitness definition, you require the StorageAdmin or Administrator roles.
● To view vWitness definitions, you require at least the PerformanceMonitor role.
Procedure
1. Select the storage array from the System Selector on the Home Dashboard.
2. Select DATA PROTECTION > Virtual Witness.
3. Follow the instructions for the vWitness definition task that you want to complete:

Table 7. vWitness definition


Task What to do
Create a. Decide on a name for the definition.
● The name has up to 12 characters.
● The first character of the name is an alphabetic character.
● The remainder of the name can contain alphanumeric characters, underscores, and hyphens.
● The name is not case-sensitive, but the system preserves the case.
b. Obtain the IP address or the fully qualified DNS name of the system where the vWitness instance is
installed. The address or name has a maximum of 128 characters.
c. Click Create.
d. Type the Virtual Witness Name and the IP/DNS.
NOTE: Create only one definition for each vWitness instance, specifying either the IP address or
the fully qualified DNS name of the instance.
e. To simultaneously add this definition to other arrays, select the Add Virtual Witness checkbox and
select the other arrays.
f. Expand the list in the Add to Job List button and click Run Now.
Unisphere creates the definition and enables it.

Enable a. Select the vWitness definition and then click Set State.
b. Expand the list in the Add to Job List button and click Run Now.
Unisphere enables the definition.

Modify a. Disable the definition.


b. Select the vWitness definition and click Delete.
c. Check that the confirmation dialog identifies the correct vWitness definition.
d. Expand the list in the Add to Job List button and click Run Now.
e. Click Add.
f. Type the modified Virtual Witness Name and IP/DNS.
NOTE: Create only one definition for each vWitness instance, specifying either the IP address or
the fully qualified DNS name of the instance.
g. Expand the list in the Add to Job List button and click Run Now.
Delete a. Disable the definition.
b. Select the vWitness definition and click DELETE.

32 Manage and monitor


Table 7. vWitness definition (continued)
Task What to do
c. Check that the confirmation dialog identifies the correct vWitness definition.
d. Expand the list in the Add to Job List button and click Run Now.
Disable a. Select the vWitness definition and then click Set State.
b. If necessary, click Advanced Options and set one of:
● Use Force if the selected vWitness instance is in use and there is another witness (physical or
virtual) available to take over.
● Use SymForce if the selected vWitness instance is in use and there is no other witness (physical
or virtual) to take over.
c. Expand the list in the Add to Job List button and click Run Now.

View When you select a vWitness definition, Unisphere displays the definition's properties :
● Name
● State
● Indicators of whether the definition is in alive and in use.

Click to view more detailed information:


● Name
● IP address or DNS name
● Port
● State
● Indicators if whether the definition is alive and in use.
● The number of SRDF groups that are using the instance

Manage and monitor 33


Unisphere for VMAX
User roles
● To add, enable, modify, remove, or disable a vWitness definition, you require the StorageAdmin or Administrator roles.
● To view vWitness definitions, you require at least the PerformanceMonitor role.
Procedure
1. Select the storage array from the System Selector on the Home Dashboard.
2. Select Data Protection > Replication Groups and Pools.
3. On the Replication Groups and Pools page click SRDF Virtual Witnesses.
4. Follow the instructions for the vWitness definition task that you want to complete:

Table 8. vWitness definition


Task What to do
Add a. Decide on a name for the definition.
● The name has up to 12 characters.
● The first character of the name is an alphabetic character.
● The remainder of the name can contain alphanumeric characters, underscores, and hyphens.
● The name is not case-sensitive, but the system preserves the case.
b. Obtain the IP address or the fully qualified DNS name of the system where the vWitness instance is
installed. The address or name has a maximum of 128 characters.
c. Click Add.
d. Type the Witness Name and the IP/DNS.
NOTE: Create only one definition for each vWitness instance, specifying either the IP address or
the fully qualified DNS name of the instance.
e. Click Run now.
Unisphere creates the definition and enables it.

Enable a. Either:
● Select the vWitness definition and then click Set Status.
● Right click on the vWitness definition and select Set Status on the context menu.
b. Click OK.
Modify a. Disable the definition.
b. Select the vWitness definition and click Remove.
c. Check that the confirmation dialog identifies the correct vWitness definition, then click OK.
d. Click Add.
e. Type the modified Witness Name and IP/DNS.
NOTE: Create only one definition for each vWitness instance, specifying either the IP address or
the fully qualified DNS name of the instance.
f. Click Run Now.
Remove a. Select the vWitness definition and click Remove.
b. Check that the confirmation dialog identifies the correct vWitness definition, then click OK.
Disable a. Either:
● Select the vWitness definition and then click Set Status.
● Right click on the vWitness definition and select Set Status on the context menu.
b. If necessary, set one of:
● Use force if the selected vWitness instance is in use and there is another witness (physical or
virtual) available to take over.
● Use SymForce if the selected vWitness instance is in use and there is no other witness (physical
or virtual) to take over.
c. Click Run Now.

View When you click SRDF Virtual Witnesses, Unisphere displays a list of the vWitness definitions on the
selected storage system. For each vWitness definition, the system displays its properties including:

34 Manage and monitor


Table 8. vWitness definition (continued)
Task What to do
● Name
● IP address or DNS name
● State
● Indicators of whether the definition is in alive and in use.
In addition you can view the details of a vWitness definition and the SRDF groups that are associated
with it:
a. Select a vWitness definition.
b. Click View details.
The details of the vWitness definition are in the Properties panel, and the SRDF groups that are
associated with this vWitness definition are in the Related Objects panel.

Manage and monitor 35


SYMCLI commands
You can use SYMCLI commands to set up, manage, and view vWitness definitions.

Command syntax convention


The sections showing the syntax of the commands use square brackets [ and ] to enclose optional parts of a command.

Value of command options


The commands use various options and these sections use the following conventions to denote their values in syntax definitions:
SymmID
The local storage system.
WitnessName
A name for a vWitness definition.
● The name has up to 12 characters.
● The first character of the name is an alphabetic character.
● The remainder of the name can contain alphanumeric characters, underscores, and hyphens.
● The name is not case-sensitive, but the system preserves the case.
IPorDNS
The IP address or the fully qualified DNS name of a vWitness instance. The address or name has a
maximum of 128 characters.

Array access rights and user authorization


All the commands, except for list and show, require array access rights of SYMCFG and user authorization of Storage Admin.

Add a vWitness definition


To add a vWitness definition to a storage array:

symcfg -sid SymmID add -witness WitnessName -location IPorDNS


[-port port] <Port Number>

NOTE: See Alternate Port Configuration for more information.

This command also enables the definition automatically, but you can disable it using symcfg disable as described in Disable
the use of a vWitness definition.
NOTE: Create only one definition for each vWitness instance, specifying either the IP address or the fully qualified DNS
name of the instance.

NOTE: The default port is 10123, use the -port option to specify the listening port of the vWitness Lock Service Daemon
if the default port was changed.

Example
To add and enable a vWitness definition named metrovw1 that refers to a vWitness instance at IP address [Link] on the
storage array 1234:

symcfg -sid 1234 add -witness metrovw1 -location [Link]

36 Manage and monitor


Disable the use of a vWitness definition
To disable the use of a vWitness definition:

symcfg -sid SymmID disable -witness WitnessName [-force|-symforce]

Use the -force option when the definition is in use (protecting a Metro configuration), and there is another Witness (either an
Array or a Virtual Witness) available to take over from this one.
Use the -symforce when the definition is in use and there is no other Witness available to take over from this one.

Example
To disable (suspend) the availability of the vWitness definition named metrovw1 on storage array 1234 when there is no other
Witness available:

symcfg -sid 1234 disable -witness metrovw1 -symforce

Enable a vWitness definition


To enable a vWitness definition after it has been suspended:

symcfg -sid SymmID enable -witness WitnessName

Example
To enable the vWitness definition named metrovw1:

symcfg -sid 1234 enable -witness metrovw1

Modify a vWitness definition


To modify a vWitness definition:
1. Disable (Disable the use of a vWitness definition) and remove the existing definition (Remove a vWitness definition).
2. Add a definition with the modified values (Add a vWitness definition).

Example
To change the IP address of a vWitness definition with the name metrovw1 on storage array 1234 to [Link]:

symcfg -sid 1234 disable -witness metrovw1 -force


symcfg -sid 1234 remove -witness metrovw1
symcfg -sid 1234 add -witness metrovw1 -loction [Link]

Remove a vWitness definition


First, disable the vWitness definition (Disable the use of a vWitness definition) and then remove it:

symcfg -sid SymmID remove -witness WitnessName

Manage and monitor 37


Example
To remove the vWitness definition named metrovw1 from storage array 1234:

symcfg -sid 1234 disable -witness metrovw1 -force


symcfg -sid 1234 remove -witness metrovw1

View vWitness definitions

View summary information about all vWitness definitions

symcfg -sid SymmID list -witness [-v] [-out xml] [-offline]

The -v option produces detailed information, similar to that produced by the show argument, but for all vWitness definitions.
Output is available in text or XML format. Use -out xml to generate XML.
Use the -offline option to display information from the data cached in the Solutions Enabler database file.

View detailed information about a single vWitness definition

symcfg -sid SymmID show -witness WitnessName [-out xml] [-offline]

Examples
Display information about all vWitness instances on the storage array 1234:

symcfg -sid 1234 list -witness

Display information about vWitness definition named metrovw1 on storage array 1234:

symcfg -sid 1234 show -witness metrovw1

38 Manage and monitor


Manage instances of vWitness
The following sections show how to create and remove instances of vWitness.

Create a vWitness
Follow the instructions in Install the vWitness instances to add the new vWitness instance. Then add a definition of the instance
to each storage array that can use that instance.

Remove a vWitness
To remove a vWitness, remove its definition from all storage arrays that use the instance. Then stop the storvwlsd daemon and
prevent it from automatically starting.
1. Make sure that the vWitness instance is not in use by any storage array.
2. Remove the definition of the instance from each storage array that has one (using Unisphere or SYMCLI command).
3. If the instance is a vApp:
a. Launch and log in to vApp Manager on the system that runs the vWitness instance.
b. Click Manage Daemons.
c. In the Action column, click Stop next to the storvwlsd daemon.
d. In the Autostart column, click Unset next to the storvwlsd daemon.
4. If the instance is a Linux daemon, see Uninstall the vWitness instances.
NOTE: The vWitness definitions must be removed or set to disabled if a vWitness daemon is decommissioned. If this is
not done, the vWMD daemons on all relevant arrays continuously attempt to connect to the non-existent vWitness.

Download vWLS log files


Each vWitness instance maintains a log file. Should problems arise, the log file can help locate the cause.
1. If the instance is a vApp:
a. Launch and log in to vApp Manager on the system running the vWitness instance.
b. Click Appliance Data/Log.
c. On the Daemon/Log Files panel, select storvwlsd from the Select Daemon list.
d. Click Download storvwlsd Logs.
e. In the file browser dialog, select a location for the downloaded file.
f. Click Save.
2. If the instance is a Linux daemon:
a. Select the directory: cd /var/symapi/log.
b. List the contents: ls -l.
c. The file is called storvwlsd.log0 or storvwlsd.log1. Type more storvwlsd.log0 or more storvwlsd.log1 to
view the file contents.

Manage and monitor 39

Common questions

Powered by AI

Unisphere allows users with adequate permissions to modify vWitness definitions by disabling a definition, making changes such as renaming or changing IP/DNS information, and then enabling it again. It provides real-time state and usage indicators for vWitness instances, allowing performance monitoring and ensuring the definitions align with current needs. Unisphere captures detailed configuration data, making it easier to diagnose issues and optimize settings for performance and reliability .

The Device Bias method inherently creates a dependency on the R1 side of the device pair, such that if the R1 side fails, host connectivity is lost. This creates a potential single point of failure. Mitigating this involves implementing the Witness mechanism, which provides a tertiary decision-making process to manage accessibility, thus preventing total failure when one side becomes inaccessible. By incorporating Array or Virtual Witness, the system can maintain operational continuity without relying solely on the R1 side .

Unisphere provides comprehensive tools for managing vWitness configurations by enabling users to add, modify, remove, enable, disable, and view vWitness definitions on SRDF/Metro setups. Users can establish definitions by specifying names and IP addresses or DNS names for vWitness instances. Unisphere also facilitates the tracking of vWitness properties such as state, whether they are alive and in use, and details on SRDF groups associated with each instance. This management capability is integral to maintaining robust data replication and availability in virtualized environments .

The Device Bias mechanism in SRDF/Metro assigns a bias to the R1 side of a device pair, meaning that if communication is lost on the SRDF link, the R1 side remains accessible while the R2 becomes inaccessible. However, if the R1 side fails, connectivity to the device pair is lost entirely. In contrast, the Witness mechanism involves a third-party mediator that helps decide which side continues to operate, preventing both arrays from attempting accessibility simultaneously in a split-brain scenario. The Witness can be either an Array Witness, which requires a third array, or a Virtual Witness, which operates on a virtual machine, offering high availability without needing additional physical equipment .

Deploying a vWitness instance on a Linux system requires x86 hardware with a 64-bit architecture capable of running RHEL 7, RHEL 8, Oracle Linux 6, Oracle Linux 7, SLES 12, or SLES 15. TCP ports must be open, necessary TLS certificates gathered, and the vWitness installation kit downloaded. Deployment involves running a silent installation script, specifying key options like the home directory, data directory, daemon user ID, and lockbox password. The default port for the lock service is 10123, but it can be altered if needed by modifying the daemon_options file .

Using SYMCLI commands to establish a vWitness definition requires specifying the storage system identifier (SymmID), a name for the vWitness (WitnessName), and its location either as an IP address or a fully qualified DNS name (IPorDNS). You can also specify an alternate listening port, if different from the default, using the -port option. These parameters enable precise management and integration of vWitness instances within complex storage configurations, maintaining consistency and alignment with network policies .

Placing vWitness instances on sites separate from the SRDF arrays is critical to mitigate the impact of localized failures. If both a vWitness instance and one of the paired arrays reside at the same site, a failure could potentially incapacitate the entire system. By distributing vWitness instances geographically, the infrastructure ensures that a site-specific issue affects only part of the overall configuration, thus maintaining system resilience and operational continuity .

When deploying multiple vWitness instances, it is essential to avoid creating a single point of failure by ensuring instances are spread across multiple servers. Each server should ideally be located at a different site from the SRDF arrays to provide geographic diversity. Additionally, the total number of vWitness instances must be sufficient to cover all active SRDF/Metro groups, and the configurations must support the maximum number of arrays and groups that a vWitness can serve. This approach optimizes system resiliency and load balancing .

To replace the default TLS certificates in a vWitness installation, one must first gather customer-signed certificates including the public key, private key, and certificate authority public key. These certificates are then copied to the /var/symapi/config/cert directory on the host system of the vWitness instance after removing existing .pem files and soft links. Running the ‘manage_server_cert update’ command recreates necessary hash links. Subsequently, lines are edited in the daemon_options file to include Security Alternative Certificate File paths for the new certificates .

The Virtual Witness method enhances redundancy and high availability by allowing SRDF/Metro configurations to use up to 32 vWitness daemon instances. It is recommended to deploy these instances over multiple servers and at sites separate from the main SRDF/Metro arrays. This distribution reduces the risk of a single point of failure impacting the entire system. Furthermore, having at least two vWitness instances per configuration ensures resiliency, allowing the system to maintain function even if one instance fails .

You might also like