Dell SRDF/Metro vWitness Guide
Dell SRDF/Metro vWitness 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
Contents 3
Figures
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.
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).
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.
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 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 X S2 X
S1 S2 S1 X
S2
X X X
W W W
X
S1 S2 S1 X
S2 S1 X S2
X X
X
W X
W W
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
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).
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.
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.
Ensure that you have certificate files for all vWitness instances and management clients on a storage media (for example, USB
storage).
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.
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.
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: !@#%&
Site information
Use this table to record the values for your vWitness installation:
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
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:
a. Enter Y.
b. The script prompts for the names to use:
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]:
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:
a. Enter N.
b. When prompted enter the new password for the lockbox?
c. Confirm the new password when prompted.
#-----------------------------------------------------------------------------
# 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:
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
Other vWitness instances that are managed by these eMGMT instances with new certificates also require updating.
manage_server_cert update
This command recreates the hash links that the instance requires.
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.
manage_server_cert update
This command recreates the hash links that the client requires.
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.
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.
Preparation
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.
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:
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.
● 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.
4. At the following prompt, specify whether you want to set the time zone:
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.
● 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.
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.
9. Click Next.
vApp Manager imports the certificate files and restarts the storsrvd and storvwlsd daemons.
10. Click Finish.
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.
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.
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:
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:
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:
Example
To enable the vWitness definition named metrovw1:
Example
To change the IP address of a vWitness definition with the name metrovw1 on storage array 1234 to [Link]:
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.
Examples
Display information about all vWitness instances on the storage array 1234:
Display information about vWitness definition named metrovw1 on storage array 1234:
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.
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 .