Veritas InfoScale™ 8.0.

2
Installation Guide - AIX
Last updated: 2023-06-05

Legal Notice
Copyright © 2023 Veritas Technologies LLC. All rights reserved.

Veritas and the Veritas Logo are trademarks or registered trademarks of Veritas Technologies
LLC or its affiliates in the U.S. and other countries. Other names may be trademarks of their
respective owners.

This product may contain third-party software for which Veritas is required to provide attribution
to the third-party (“Third-Party Programs”). Some of the Third-Party Programs are available
under open source or free software licenses. The License Agreement accompanying the
Software does not alter any rights or obligations you may have under those open source or
free software licenses. Refer to the third-party legal notices document accompanying this
Veritas product or available at:
https://www.veritas.com/about/legal/license-agreements

The product described in this document is distributed under licenses restricting its use, copying,
distribution, and decompilation/reverse engineering. No part of this document may be
reproduced in any form by any means without prior written authorization of Veritas Technologies
LLC and its licensors, if any.

THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED

CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED
WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR
NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH
DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. VERITAS TECHNOLOGIES LLC
SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN
CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS
DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS
SUBJECT TO CHANGE WITHOUT NOTICE.

The Licensed Software and Documentation are deemed to be commercial computer software
as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19
"Commercial Computer Software - Restricted Rights" and DFARS 227.7202, et seq.
"Commercial Computer Software and Commercial Computer Software Documentation," as
applicable, and any successor regulations, whether delivered by Veritas as on premises or
hosted services. Any use, modification, reproduction release, performance, display or disclosure
of the Licensed Software and Documentation by the U.S. Government shall be solely in
accordance with the terms of this Agreement.
Veritas Technologies LLC
2625 Augustine Drive
Santa Clara, CA 95054
http://www.veritas.com

Technical Support
Technical Support maintains support centers globally. All support services will be delivered
in accordance with your support agreement and the then-current enterprise technical support
policies. For information about our support offerings and how to contact Technical Support,
visit our website:
https://www.veritas.com/support

You can manage your Veritas account information at the following URL:
https://my.veritas.com

If you have questions regarding an existing support agreement, please email the support
agreement administration team for your region as follows:

Worldwide (except Japan) [email protected]

Japan [email protected]

Documentation
Make sure that you have the current version of the documentation. Each document displays
the date of the last update on page 2. The latest documentation is available on the Veritas
website:
https://sort.veritas.com/documents

Documentation feedback
Your feedback is important to us. Suggest improvements or report errors or omissions to the
documentation. Include the document title, document version, chapter title, and section title
of the text on which you are reporting. Send feedback to:
[email protected]

You can also see documentation information or ask a question on the Veritas community site:
http://www.veritas.com/community/

Veritas Services and Operations Readiness Tools (SORT)

Veritas Services and Operations Readiness Tools (SORT) is a website that provides information
and tools to automate and simplify certain time-consuming administrative tasks. Depending
on the product, SORT helps you prepare for installations and upgrades, identify risks in your
datacenters, and improve operational efficiency. To see what services and tools SORT provides
for your product, see the data sheet:
https://sort.veritas.com/data/support/SORT_Data_Sheet.pdf
 Contents

Section 1 Planning and preparation ...................................... 8

Chapter 1 Introducing Veritas InfoScale ........................................... 9
About the Veritas InfoScale product suite ............................................ 9
Components of the Veritas InfoScale product suite ................................ 9
About the co-existence of InfoScale products ..................................... 10

Chapter 2 Licensing Veritas InfoScale ........................................... 11

About Veritas InfoScale product licensing .......................................... 11

About InfoScale Core Plus license meter ........................................... 12
About telemetry data collection in InfoScale ....................................... 12
Licensing notes ............................................................................ 14
About managing InfoScale licenses .................................................. 16
About the vxlicinstupgrade utility ............................................ 17
Generating license report with vxlicrep command ............................. 18

Chapter 3 System requirements ....................................................... 19

Important release information .......................................................... 19

Disk space requirements ................................................................ 20
Hardware requirements ................................................................. 20
SF and SFHA hardware requirements ........................................ 21
SFCFS and SFCFSHA hardware requirements ............................ 21
SF Oracle RAC hardware requirements ...................................... 22
VCS hardware requirements ..................................................... 23
Virtual I/O Server (VIOS) requirements ....................................... 24
Supported operating systems and database versions .......................... 25
Number of nodes supported ........................................................... 25

Chapter 4 Preparing to install ............................................................ 26

Mounting the ISO image ................................................................ 26

Setting up ssh or rsh for inter-system communications ......................... 27
Obtaining installer patches ............................................................. 27
Disabling external network connection attempts .................................. 28
 Contents 5

Verifying the systems before installation ............................................ 29

Setting up the private network ......................................................... 29
Optimizing LLT media speed settings on private NICs .................... 32
Guidelines for setting the media speed for LLT interconnects
..................................................................................... 32
Guidelines for setting the maximum transmission unit (MTU) for
LLT interconnects in Flexible Storage Sharing (FSS)
environments .................................................................. 33
Setting up shared storage .............................................................. 33
Setting the SCSI identifier value ................................................ 33
Setting up Fibre Channel ......................................................... 35
Synchronizing time settings on cluster nodes ..................................... 35
Configuring LLT interconnects to use Jumbo Frames ........................... 35
Planning the installation setup for SF Oracle RAC systems ................... 36
Planning your network configuration ........................................... 37
Planning the storage ............................................................... 40
Planning volume layout ............................................................ 46
Planning file system design ...................................................... 47
Setting the umask before installation .......................................... 47
Updating the SCSI reserve ODM attribute settings for VIOS .................. 47

Section 2 Installation of Veritas InfoScale ...................... 49

Chapter 5 Installing Veritas InfoScale using the installer

........................................................................................... 50

Installing Veritas InfoScale using the installer ..................................... 50

Executive Order logging ................................................................. 52

Chapter 6 Installing Veritas InfoScale using response files

........................................................................................... 53

About response files ..................................................................... 53

Syntax in the response file ....................................................... 54
Installing InfoScale using response files ............................................ 54
Response file variables to install Veritas InfoScale .............................. 55
Sample response files for Veritas InfoScale installation ........................ 56
 Contents 6

Chapter 7 Installing Veritas Infoscale using operating

system-specific methods ........................................... 57
About installing InfoScale using operating system-specific methods
........................................................................................... 57
Installing InfoScale using NIM and the installer ................................... 57
Preparing the installation bundle on the NIM server ....................... 58
Installing InfoScale on the NIM client using SMIT on the NIM server
..................................................................................... 58
Installing InfoScale and the operating system on the NIM client
using SMIT ..................................................................... 59

Chapter 8 Completing the post installation tasks ......................... 61

Verifying product installation ........................................................... 61
Setting environment variables ......................................................... 62
Commands to manage the Veritas telemetry collector on your server
........................................................................................... 62
Next steps after installation ............................................................. 63

Section 3 Uninstallation of Veritas InfoScale ............... 65

Chapter 9 Uninstalling Veritas InfoScale using the installer

........................................................................................... 66

Preparing to uninstall a InfoScale product .......................................... 66

Moving volumes to physical disks .............................................. 67
Removing the Replicated Data Set ................................................... 69
Uninstalling InfoScale filesets using the installer ................................. 71
Removing Storage Foundation products using SMIT ............................ 72
Removing the Storage Foundation for Databases (SFDB) repository
........................................................................................... 74

Chapter 10 Uninstalling Veritas InfoScale using response

files .................................................................................. 76

Uninstalling InfoScale using response files ........................................ 76

Response file variables to uninstall Veritas InfoScale ........................... 77
Sample response file for Veritas InfoScale uninstallation ....................... 78
 Contents 7

Section 4 Installation reference .............................................. 79

Appendix A Installation scripts .............................................................. 80

Installation script options ................................................................ 80

Appendix B Tunable files for installation ............................................ 86

About setting tunable parameters using the installer or a response file
........................................................................................... 86
Setting tunables for an installation, configuration, or upgrade ................. 87
Setting tunables with no other installer-related operations ..................... 88
Setting tunables with an un-integrated response file ............................ 89
Preparing the tunables file .............................................................. 90
Setting parameters for the tunables file ............................................. 90
Tunables value parameter definitions ............................................... 91

Appendix C Troubleshooting installation issues .............................. 99

Restarting the installer after a failed network connection ....................... 99

Troubleshooting an installation on AIX .............................................. 99
Incorrect permissions for root on remote system ............................... 100
Resource temporarily unavailable .................................................. 101
Inaccessible system .................................................................... 101
 Section 1
Planning and preparation

■ Chapter 1. Introducing Veritas InfoScale

■ Chapter 2. Licensing Veritas InfoScale

■ Chapter 3. System requirements

■ Chapter 4. Preparing to install

 Chapter 1
Introducing Veritas
InfoScale
This chapter includes the following topics:

■ About the Veritas InfoScale product suite

■ Components of the Veritas InfoScale product suite

■ About the co-existence of InfoScale products

About the Veritas InfoScale product suite

The Veritas InfoScale product suite addresses enterprise IT service continuity
needs. They provide resiliency and software defined storage for critical services
across a data center in physical, virtual, and cloud environments. The clustering
solution provides high availability and disaster recovery for applications across
geographies.
The Veritas InfoScale product suite offers the following products:
■ Veritas InfoScale Foundation
■ Veritas InfoScale Storage
■ Veritas InfoScale Availability
■ Veritas InfoScale Enterprise

Components of the Veritas InfoScale product suite

Each new InfoScale product consists of one or more components. Each component
within a product offers a unique capability that you can configure for use in your
environment.
 Introducing Veritas InfoScale 10
About the co-existence of InfoScale products

Table 1-1 lists the components of each Veritas InfoScale product.

Table 1-1 Veritas InfoScale product suite

Product Description Components

Veritas InfoScale™ Veritas InfoScale™ Foundation Storage Foundation (SF)

Foundation delivers a comprehensive solution for Standard (entry-level
heterogeneous online storage features)
management while increasing storage
utilization and enhancing storage I/O
path availability.

Veritas InfoScale™ Veritas InfoScale™ Storage enables Storage Foundation (SF)

Storage organizations to provision and manage Enterprise including
storage independently of hardware Replication
types or locations while delivering
Storage Foundation
predictable Quality-of-Service, higher
Cluster File System
performance, and better
(SFCFS)
Return-on-Investment.

Veritas InfoScale™ Veritas InfoScale™ Availability helps Cluster Server (VCS)

Availability keep an organization’s information and including HA/DR
critical business services up and
running on premise and across globally
dispersed data centers.

Veritas InfoScale™ Veritas InfoScale™ Enterprise Cluster Server (VCS)

Enterprise addresses enterprise IT service including HA/DR
continuity needs. It provides resiliency
Storage Foundation (SF)
and software defined storage for
Enterprise including
critical services across your datacenter
Replication
infrastructure.
Storage Foundation and
High Availability (SFHA)

Storage Foundation
Cluster File System High
Availability (SFCFSHA)

Storage Foundation for

Oracle RAC (SF Oracle
RAC)

About the co-existence of InfoScale products

You cannot install an InfoScale product on a system where another InfoScale
product is already installed.
 Chapter 2
Licensing Veritas
InfoScale
This chapter includes the following topics:

■ About Veritas InfoScale product licensing

■ About InfoScale Core Plus license meter

■ About telemetry data collection in InfoScale

■ Licensing notes

■ About managing InfoScale licenses

■ Generating license report with vxlicrep command

About Veritas InfoScale product licensing

You must obtain a license to install and use Veritas InfoScale products.
You can choose one of the following licensing methods when you install a product:
■ Install product with a permanent license
When you purchase a Veritas InfoScale product, you receive a License Key
certificate. The certificate specifies the products and the number of product
licenses purchased.
■ Install product without a permanent license key (keyless licensing)
Installation without a license does not eliminate the need to obtain a license.
The administrator and company representatives must ensure that a server or
cluster is entitled to the license level for the products installed. Veritas reserves
the right to ensure entitlement and compliance through auditing.
 Licensing Veritas InfoScale 12
About InfoScale Core Plus license meter

■ Veritas collects licensing and platform related information from InfoScale products
as part of the Veritas Product Improvement Program. The information collected
helps identify how customers deploy and use the product, and enables Veritas
to manage customer licenses more efficiently. See “About telemetry data
collection in InfoScale” on page 12.
Visit the Veritas licensing Support website, for more information about the licensing
process.
www.veritas.com/licensing/process

About InfoScale Core Plus license meter

The Core Plus license meter (“Core Plus”) for InfoScale is an enhancement to its
traditional core-based license meter. This enhancement factors in the steady
advances of CPU technology and includes additional capabilities to simplify license
management. Core Plus helps you transition to an updated licensing model that
provides you with the tools to securely track and manage your InfoScale licenses
and simplify the renewal and purchase process.
Core Plus licenses can be purchased or subscribed to, are cross-platform and can
be deployed on any supported operating system. To order a new InfoScale license
for a server, you need to quote a Core Plus credit value. You determine this value
by multiplying the physical core count of each server CPU and the processor
coefficient performance rating number.
Veritas maintains a matrix of various chip types and their performance rating
numbers, called coefficients. This matrix is integrated into the SORT Data Collector,
the web-based license calculator, and the Veritas Usage Insights tools. Using these
tools, you can put together the required Core Plus information to generate a renewal
or a new software quote.
For details, refer to the Veritas InfoScale Core Plus License Meter Implementation
Overview document at:
https://www.veritas.com/support/en_US/doc/infoscale_licensing_service

About telemetry data collection in InfoScale

The Veritas Telemetry Collector is used to collect licensing and platform related
information from InfoScale products as part of the Veritas Product Improvement
Program. The information collected helps identify how customers deploy and use
the product, and enables Veritas to manage customer licenses more efficiently.
Veritas does not collect any private information and only uses information specific
 Licensing Veritas InfoScale 13
About telemetry data collection in InfoScale

to product, licensing, and platform (which includes operating system and server
hardware).

Table 2-1 Information sent by the collector

Category Information attributes

Product ■ Telemetry data version

■ Cluster ID
■ Product version
■ Time stamp

Licensing ■ Product ID
■ Serial number
■ Serial ID
■ License meter
■ Fulfillment ID
■ Platform
■ Version
■ SKU type
■ VXKEYLESS
■ License type
■ SKU

Operating system ■ Platform name

■ Version
■ TL number
■ Kernel/SRU

Server hardware ■ Architecture

■ CPU op-mode(s)
■ CPU(s)
■ Core(s) per socket
■ Thread(s) per core
■ Socket(s)
■ Vendor ID
■ CPU model name
■ CPU frequency
■ Hypervisor vendor
■ Memory

By default, the Veritas Telemetry Collector will collect telemetry data every Tuesday
at 1:00 A.M. as per the local system time. The time and interval of data collection
can be customized by the user if required.
 Licensing Veritas InfoScale 14
Licensing notes

You can configure the Veritas Telemetry Collector while installing or upgrading the
product, See “Installing Veritas InfoScale using the installer” on page 50.. You can
also manage the Veritas Telemetry Collector on each of your servers by using the
/opt/VRTSvlic/tele/bin/TelemetryCollector command. For more information,
See “Commands to manage the Veritas telemetry collector on your server”
on page 62.
Configure the firewall policy such that the ports required for telemetry data collection
are not blocked. Refer to your respective firewall or OS vendor documents for the
required configuration.

Note: Ensure that you reboot the server after uninstalling the product to ensure
that all services related to the Veritas Telemetry Collector are stopped successfully.

Licensing notes
Review the following licensing notes before you install or upgrade the product.
■ If you use a keyless license option, you must configure Veritas InfoScale
Operations Manager within two months of product installation and add the node
as a managed host to the Veritas InfoScale Operations Manager Management
Server. Failing this, a warning message for non-compliance is displayed
periodically.
For more details, refer to Veritas InfoScale Operations Manager product
documentation.
■ Note the following limitation in case of InfoScale Availability and InfoScale
Storage co-existence:
If Keyless licensing type is selected during the product installation, checks
performed to monitor the number of days of product installation are based on
the InfoScale Storage component. As a result, if you do not enter a valid license
key file or do not add the host as a managed host within 60 days of InfoScale
Storage installation, a non-compliance error is logged every 4 hrs in the Event
Viewer.
■ The text-based license keys that are used in 7.3.1 and earlier versions are not
supported when upgrading to later versions. If your current product is installed
using a permanent license key and you do not have a permanent license key
file for the newer InfoScale version, you can temporarily upgrade using the
keyless licensing. Then you must procure a permanent license key file from the
Veritas license certificate and portal within 60 days, and upgrade using the
permanent license key file to continue using the product.
 Licensing Veritas InfoScale 15
Licensing notes

■ The license key file must be present on the same node where you are trying to
install the product.

Note: The license key file must not be saved in the root directory (/) or the
default license directory on the local host (/etc/vx/licesnes/lic). You can
save the license key file inside any other directory on the local host.

■ You can manage the license keys using the vxlicinstupgrade utility.
See “About managing InfoScale licenses” on page 16.
■ Before upgrading the product, review the licensing details and back up the older
license key. If the upgrade fails for some reason, you can temporarily revert to
the older product using the older license key to avoid any application downtime.
■ You can use the license assigned for higher Stock Keeping Units (SKU) to install
the lower SKUs.
For example, if you have procured a license that is assigned for InfoScale
Enterprise, you can use the license for installing any of the following products:
■ InfoScale Foundation
■ InfoScale Storage
■ InfoScale Availability
The following table provides details about the license SKUs and the
corresponding products that can be installed:

License Products that can be installed

SKU
procured

InfoScale InfoScale InfoScale InfoScale

Foundation Storage Availability Enterprise

InfoScale ✓ X X X
Foundation

InfoScale ✓ ✓ X X
Storage

InfoScale X X ✓ X
Availability

InfoScale ✓ ✓ ✓ ✓
Enterprise
 Licensing Veritas InfoScale 16
About managing InfoScale licenses

Note: At any given point in time you can install only one product.

About managing InfoScale licenses

After you have installed a Veritas InfoScale product, you may need to manage the
product license, for example, to switch from a keyless to a permanent license type.
You can manage your licenses by using the vxlicinstupgrade or vxkeyless
utilities which are located in the product installation directory.

Using the To add or update a permanent license, run the following

vxlicinstupgrade commands:

# cd /opt/VRTS/bin

# ./vxlicinstupgrade -k <key file path>

Where, the <key file path> is the absolute path of the .slf
license key file saved on the current node.

Example:

/downloads/InfoScale_keys/XYZ.slf

For more information on vxlicinstupgrade utility:

See “About the vxlicinstupgrade utility” on page 17.

Using the vxkeyless To add or update a keyless license, perform the following
steps:

1 Change your current working directory:

# export PATH=$PATH:/opt/VRTSvlic/bin

2 View the keyless product code for the product you want
to install:

# vxkeyless displayall

3 Enter the product code in the exact format as displayed

in the previous step:

# vxkeyless set <keyless license text-string>

Example:

# vxkeyless set ENTERPRISE

 Licensing Veritas InfoScale 17
About managing InfoScale licenses

About the vxlicinstupgrade utility

The vxlicinstupgrade utility enables you to perform the following tasks:
■ Upgrade to another Veritas InfoScale license
■ Update a keyless license to a permanent license
■ Manage co-existence of multiple licenses
On executing the vxlicinstupgrade utility, the following checks are done:
■ If the current license is keyless or permanent and if the user is trying to install
the keyless or permanent license of the same product.
Example: If the 8.0.2 Foundation Keyless license key is already installed on a
system and the user tries to install another 8.0.2 Foundation Keyless license
key, then vxlicinstupgrade utility shows an error message:

vxlicinstupgrade WARNING: The input License key and Installed key

are same.

■ If the current key is keyless and the newly entered license key file is a permanent
license of the same product
Example: If the 8.0.2 Foundation Keyless license key is already installed on a
system and the user tries to install 8.0.2 Foundation permanent license key file,
then the vxlicinstupgrade utility installs the new license at
/etc/vx/licenses/lic and the 8.0.2 Foundation Keyless key is deleted.

■ The vxlicinstupgrade utility in InfoScale does not support managing the

text-based license keys used in versions before 7.4.
■ If the current key is of a lower version and the user tries to install a higher version
license key.
Example: If 7.0 Storage license key is already installed on a system and the
user tries to install 8.0.2 Storage license key file, then the vxlicinstupgrade
utility installs the new license at /etc/vx/licenses/lic and the 7.0 Storage
key is deleted.

Note: When registering license key files manually during upgrade, you have to use
the vxlicinstupgrade command. When registering keys using the installer script,
the same procedures are performed automatically.
 Licensing Veritas InfoScale 18
Generating license report with vxlicrep command

Generating license report with vxlicrep command

The vxlicrep command generates a report of the product licenses in use on your
system.
To display a license report:
■ Enter the # vxlicrep command without any options to display the report of all
the product licenses on your system, or
■ Enter the # vxlicrep command with any of the following options to display the
type of report required:

-g default report

-k <key> print report for input key

-v print version

-h display this help

 Chapter 3
System requirements
This chapter includes the following topics:

■ Important release information

■ Disk space requirements

■ Hardware requirements

■ Supported operating systems and database versions

■ Number of nodes supported

Important release information

Review the Release notes for the latest information before you install the product.
Review the current compatibility lists to confirm the compatibility of your hardware
and software:
■ For important updates regarding this release, review the Late-Breaking News
TechNote on the Veritas Technical Support website:
https://www.veritas.com/content/support/en_US/article.100051899
■ For the latest patches available for this release, visit:
https://sort.veritas.com
■ The hardware compatibility list contains information about supported hardware
and is updated regularly. For the latest information on supported hardware, visit
the following URL:
https://www.veritas.com/support/en_US/doc/infoscale_hcl_8x_unix
■ The software compatibility list summarizes each Veritas InfoScale product stack
and the product features, operating system versions, and third-party products
it supports. For the latest information on supported software, visit the following
URL:
 System requirements 20
Disk space requirements

https://www.veritas.com/support/en_US/doc/infoscale_scl_802_aix

Disk space requirements

Table 3-1 lists the disk space requirements for each product when the /opt, /root,
/var, and /bin directories are created on the same disk.

Table 3-1 Disk space requirements

Product name Requirement

Veritas InfoScale Foundation 1298 MB

Veritas InfoScale Availability 1710 MB

Veritas InfoScale Storage 2497 MB

Veritas InfoScale Enterprise 2497 MB

Hardware requirements
This section lists the hardware requirements for Veritas InfoScale.
Table 3-2 lists the hardware requirements for each component in Veritas InfoScale.

Table 3-2 Hardware requirements for components in Veritas InfoScale

Component Requirement

Storage Foundation (SF) See “SF and SFHA hardware requirements” on page 21.

Storage Foundation for

High Availability (SFHA)

Storage Foundation See “SFCFS and SFCFSHA hardware requirements” on page 21.
Cluster File System
(SFCFS) and Storage
Foundation Cluster File
System for High
Availability (SFCFSHA)

Storage Foundation for See “SF Oracle RAC hardware requirements” on page 22.
Oracle RAC (SF Oracle
RAC)

Cluster Server (VCS) See “VCS hardware requirements” on page 23.

For additional information, see the hardware compatibility list (HCL) at:
 System requirements 21
Hardware requirements

https://www.veritas.com/content/support/en_US/doc/infoscale_hcl_8x_unix

SF and SFHA hardware requirements

Table 3-3 lists the hardware requirements for SF and SFHA.

Table 3-3 SF and SFHA hardware requirements

Item Requirement

Memory Each system requires at least 1 GB.

For DMP: 2.2.2.1 or later

Virtual I/O Server (VIOS)

requirements

SFCFS and SFCFSHA hardware requirements

Table 3-4 lists the hardware requirements for SFCFSHA.

Table 3-4 Hardware requirements for SFCFSHA

Requirement Description

Memory (Operating System) 2 GB of memory.

CPU A minimum of 2 CPUs.

Node Storage Foundation Cluster File System High Availability

supports mixed cluster environments with AIX 7.1 and 7.2
operating systems.

Shared storage Shared storage can be one or more shared disks or a disk
array connected either directly to the nodes of the cluster or
through a Fibre Channel Switch. Nodes can also have
non-shared or local devices on a local I/O channel. It is
advisable to have /, /usr, /var and other system partitions
on local devices.

In a Flexible Storage Sharing (FSS) environment, shared

storage may not be required.

Fibre Channel or iSCSI Each node in the cluster must have a Fibre Channel I/O
storage channel or iSCSI storage to access shared storage devices.
The primary component of the Fibre Channel fabric is the
Fibre Channel switch.
 System requirements 22
Hardware requirements

Table 3-4 Hardware requirements for SFCFSHA (continued)

Requirement Description

Cluster platforms There are several hardware platforms that can function as
nodes in a Veritas InfoScale cluster.

See the Veritas InfoScale 8.0.2 Release Notes.

For a cluster to work correctly, all nodes must have the same
time. If you are not running the Network Time Protocol (NTP)
daemon, make sure the time on all the systems comprising
your cluster is synchronized.

SAS or FCoE Each node in the cluster must have an SAS or FCoE I/O
channel to access shared storage devices. The primary
components of the SAS or Fibre Channel over Ethernet
(FCoE) fabric are the switches and HBAs.

SF Oracle RAC hardware requirements

Table 3-5 lists the hardware requirements for basic clusters.

Table 3-5 Hardware requirements for basic clusters

Item Description

DVD drive A DVD drive on one of the nodes in the cluster.

Disks All shared storage disks support SCSI-3 Persistent Reservations (PR).
Note: The coordinator disk does not store data, so configure the disk
as the smallest possible LUN on a disk array to avoid wasting space.
The minimum size required for a coordinator disk is 128 MB.

RAM Each system requires at least 2 GB.

Swap space For SF Oracle RAC: See the Oracle Metalink document: 169706.1
 System requirements 23
Hardware requirements

Table 3-5 Hardware requirements for basic clusters (continued)

Item Description

Network Two or more private links and one public link.

Links must be 100BaseT or gigabit Ethernet directly linking each node

to the other node to form a private network that handles direct
inter-system communication. These links must be of the same type;
you cannot mix 100BaseT and gigabit.

Veritas recommends gigabit Ethernet using enterprise-class switches

for the private links.

Oracle RAC requires that all nodes use the IP addresses from the same
subnet.

You can also configure aggregated interfaces.

Fiber Channel or At least one additional SCSI or Fibre Channel Host Bus Adapter per
SCSI host bus system for shared data disks.
adapters

VCS hardware requirements

Table 3-6 lists the hardware requirements for a VCS cluster.

Table 3-6 Hardware requirements for a VCS cluster

Item Description

DVD drive One drive in a system that can communicate to all the nodes in the
cluster.

Disks Typical configurations require that the applications are configured to

use shared disks/storage to enable migration of applications between
systems in the cluster.

The SFHA I/O fencing feature requires that all data and coordinator
disks support SCSI-3 Persistent Reservations (PR).

Note: SFHA also supports non-SCSI3 server-based fencing

configuration in virtual environments that do not support SCSI-3
PR-compliant storage.
 System requirements 24
Hardware requirements

Table 3-6 Hardware requirements for a VCS cluster (continued)

Item Description

Ethernet In addition to the built-in public Ethernet controller, VCS requires at

controllers least one more Ethernet interface per system. Veritas recommends two
additional interfaces.

You can also configure aggregated interfaces.

Veritas recommends that you turn off the spanning tree on the LLT
switches, and set port-fast on.

Fibre Channel or Typical VCS configuration requires at least one SCSI or Fibre Channel
SCSI host bus Host Bus Adapter per system for shared data disks.
adapters

RAM Each VCS node requires at least 1024 megabytes.

Virtual I/O Server (VIOS) requirements

To run DMP in VIOS, the minimum VIOS level that is required is 2.2.2.1 or later.
Before installing DMP on VIOS, confirm the following:
If any path to the target disk has SCSI reserve ODM attribute set, then change the
attributes to release the SCSI reservation from the paths, on a restart.
■ If a path has the reserve_policy attribute set, change thereserve_policy
attribute to no_reserve for all the paths.
# lsattr -E1 hdisk557 | grep res
reserve_policy single_path
Reserve Policy True
# chdev -l hdisk557 -a reserve_policy=no_reserve -P
hdisk557 changed

■ If a path has the reserve_lock attribute set, change the reserve_lockattribute

to no.
# lsattr -E1 hdisk558 | grep reserve_lock
reserve_lock yes
Reserve Device on open True
# chdev -l hdisk558 -a reserve_lock=no -P
hdisk558 changed
 System requirements 25
Supported operating systems and database versions

Supported operating systems and database

versions
For information on supported operating systems and database versions for various
components of InfoScale, see the Veritas InfoScale Release Notes.

Number of nodes supported

InfoScale supports cluster configurations up to 64 nodes.
SFHA, SFCFSHA, SF Oracle RAC: Flexible Storage Sharing (FSS) only supports
cluster configurations with up to 8 nodes.
SFHA, SFCFSHA: SmartIO writeback caching only supports cluster configurations
with up to 2 nodes.
 Chapter 4
Preparing to install
This chapter includes the following topics:

■ Mounting the ISO image

■ Setting up ssh or rsh for inter-system communications

■ Obtaining installer patches

■ Disabling external network connection attempts

■ Verifying the systems before installation

■ Setting up the private network

■ Setting up shared storage

■ Synchronizing time settings on cluster nodes

■ Configuring LLT interconnects to use Jumbo Frames

■ Planning the installation setup for SF Oracle RAC systems

■ Updating the SCSI reserve ODM attribute settings for VIOS

Mounting the ISO image

An ISO file is a disc image that must be mounted to a virtual drive for use. You must
have superuser (root) privileges to mount the Veritas InfoScale ISO image.
 Preparing to install 27
Setting up ssh or rsh for inter-system communications

To mount the ISO image

1 Log in as superuser on a system where you want to install Veritas InfoScale.
2 Create a loopback device to which you can bind the ISO image file:

# mkdev -c loopback -s node -t loopback

loop0 Available

3 Bind the ISO image to the loopback device and mount the device:

# loopmount -i <ISO_image_path> -l loop0 \

-o "-V cdrfs -o ro" -m /mnt

Where <ISO_image_path> is the complete path to the ISO image

Setting up ssh or rsh for inter-system

communications
The installer uses passwordless Secure Shell (ssh) or Remote Shell (rsh)
communications among systems. During an installation, you choose the
communication method that you want to use. Or, you can run the installer
-comsetup command to set up ssh or rsh explicitly. When the installation process
completes, the installer asks you if you want to remove the password-less
connection. If installation terminated abruptly, use the installation script's
-comcleanup option to remove the ssh or rsh configuration from the systems.

In most installation, configuration, upgrade (where necessary), and uninstallation

scenarios, the installer configures ssh or rsh on the target systems. When you
perform installation using a response file, you need to set up ssh or rsh manually,
or use theinstaller -comsetup option to set up an ssh or rsh configuration from
the systems.
See “Installation script options” on page 80.

Obtaining installer patches

You can access public installer patches automatically or manually on the Veritas
Services and Operations Readiness Tools (SORT) website's Patch Finder page
at:
https://sort.veritas.com/patch/finder
 Preparing to install 28
Disabling external network connection attempts

To download installer patches automatically

◆ If you are running Veritas InfoScale version 7.0 or later, and your system has
Internet access, the installer automatically imports any needed installer patch,
and begins using it.
Automatically downloading installer patches requires the installer to make outbound
networking calls. You can also disable external network connection attempts.
See “Disabling external network connection attempts” on page 28.
If your system does not have Internet access, you can download installer patches
manually.
To download installer patches manually
1 Go to the Veritas Services and Operations Readiness Tools (SORT) website's
Patch Finder page, and save the most current patch on your local system.
2 Navigate to the directory where you want to unzip the file you downloaded in
step 1.
3 Unzip the patch tar file. For example, run the following command:

# gunzip cpi-8.0.2P2-patches.tar.gz

4 Untar the file. For example, enter the following:

# tar -xvf cpi-8.0.2P2-patches.tar

patches/
patches/CPI802P2.pl
README

5 Navigate to the installation media or to the installation directory.

6 To start using the patch, run the installer command with the -require option.
For example, enter the following:

# ./installer -require /target_directory/patches/CPI802P2.pl

Disabling external network connection attempts

When you execute the installer command, the installer attempts to make an
outbound networking call to get information about release updates and installer
patches. If you know your systems are behind a firewall, or do not want the installer
to make outbound networking calls, you can disable external network connection
attempts by the installer.
 Preparing to install 29
Verifying the systems before installation

To disable external network connection attempts

◆ Disable inter-process communication (IPC).
To disable IPC, run the installer with the -noipc option.
For example, to disable IPC for system1 (sys1) and system2 (sys2) enter the
following:

# ./installer -noipc sys1 sys2

Verifying the systems before installation

Use any of the following options to verify your systems before installation:
■ Option 1: Run Veritas Services and Operations Readiness Tools (SORT).
For information on downloading and running SORT:
https://sort.veritas.com

Note: To determine the preinstallation requirements, run the installation checklist

tool from SORT:
https://sort.veritas.com/checklist/install
From the drop-down lists, select the information for the Veritas InfoScale product
you want to install, and click Generate Checklist.

■ Option 2: Run the installer with the "-precheck" option as follows:

Navigate to the directory that contains the installation program.
Run the installation program to start the pre-check process:

# ./installer -precheck sys1 sys2

Here, sys1, sys2 are the names of the nodes in the cluster.
The program proceeds in a non-interactive mode, examining the systems for
licenses, filesets, disk space, and system-to-system communications. The
program displays the results of the pre-check and saves them in a log file. The
location of the log file is displayed at the end of the pre-check process.

Setting up the private network

This topic applies to VCS, SFHA, SFCFS, SFCFSHA and SF Oracle RAC
VCS requires you to set up a private network between the systems that form a
cluster. You can use either NICs or aggregated interfaces to set up private network.
 Preparing to install 30
Setting up the private network

You can use network switches instead of hubs.

Refer to the Cluster Server Administrator's Guide to review VCS performance
considerations.
Figure 4-1 shows two private networks for use with VCS.

Figure 4-1 Private network setups: two-node and four-node clusters

Public network Public network

Private
network

Private network switches or hubs

You need to configure at least two independent networks between the cluster nodes
with a network switch for each network. You can also interconnect multiple layer 2
switches for advanced failure protection. Such connections for LLT are called
cross-links.
Figure 4-2 shows a private network configuration with crossed links between the
network switches.

Figure 4-2 Private network setup with crossed links

Public network

Private networks

Crossed link

Veritas recommends one of the following two configurations:

■ Use at least two private interconnect links and one public link. The public link
can be a low priority link for LLT. The private interconnect link is used to share
cluster status across all the systems, which is important for membership
 Preparing to install 31
Setting up the private network

arbitration and high availability. The public low priority link is used only for
heartbeat communication between the systems.
■ If your hardware environment allows use of only two links, use one private
interconnect link and one public low priority link. If you decide to set up only two
links (one private and one low priority link), then the cluster must be configured
to use I/O fencing, either disk-based or server-based fencing configuration. With
only two links, if one system goes down, I/O fencing ensures that other system
can take over the service groups and shared file systems from the failed node.
To set up the private network
1 Install the required network interface cards (NICs).
Create aggregated interfaces if you want to use these to set up private network.
2 Connect the InfoScale private Ethernet controllers on each system.
3 Use crossover Ethernet cables, switches, or independent hubs for each
InfoScale communication network. Note that the crossover Ethernet cables
are supported only on two systems.
Ensure that you meet the following requirements:
■ The power to the switches or hubs must come from separate sources.
■ On each system, you must use two independent network cards to provide
redundancy.
■ If a network interface is part of an aggregated interface, you must not
configure the network interface under LLT. However, you can configure the
aggregated interface under LLT.
■ When you configure Ethernet switches for LLT private interconnect, disable
the spanning tree algorithm on the ports used for the interconnect.
During the process of setting up heartbeat connections, consider a case where
a failure removes all communications between the systems.
Note that a chance for data corruption exists under the following conditions:
■ The systems still run, and
 Preparing to install 32
Setting up the private network

■ The systems can access the shared storage.

4 Test the network connections. Temporarily assign network addresses and use
telnet or ping to verify communications.

LLT uses its own protocol, and does not use TCP/IP. So, you must ensure that
the private network connections are used only for LLT communication and not
for TCP/IP traffic. To verify this requirement, unplumb and unconfigure any
temporary IP addresses that are configured on the network interfaces.
The installer configures the private network in the cluster during configuration.
You can also manually configure LLT.

Optimizing LLT media speed settings on private NICs

For optimal LLT communication among the cluster nodes, the interface cards on
each node must use the same media speed settings. Also, the settings for the
switches or the hubs that are used for the LLT interconnections must match that of
the interface cards. Incorrect settings can cause poor network performance or even
network failure.
If you use different media speed for the private NICs, Veritas recommends that you
configure the NICs with lesser speed as low-priority links to enhance LLT
performance.

Guidelines for setting the media speed for LLT interconnects

Review the following guidelines for setting the media speed for LLT interconnects:
■ Veritas recommends that you manually set the same media speed setting on
each Ethernet card on each node.
If you use different media speed for the private NICs, Veritas recommends that
you configure the NICs with lesser speed as low-priority links to enhance LLT
performance.
■ If you have hubs or switches for LLT interconnects, then set the hub or switch
port to the same setting as used on the cards on each node.
Details for setting the media speeds for specific devices are outside of the scope
of this manual. Consult the device’s documentation or the operating system manual
for more information.
 Preparing to install 33
Setting up shared storage

Guidelines for setting the maximum transmission unit (MTU) for LLT
interconnects in Flexible Storage Sharing (FSS) environments
Review the following guidelines for setting the MTU for LLT interconnects in FSS
environments:
■ Set the maximum transmission unit (MTU) to the highest value (typically 9000)
supported by the NICs when LLT (both high priority and low priority links) is
configured over Ethernet or UDP. Ensure that the switch is also set to 9000
MTU.

Note: MTU setting is not required for LLT over RDMA configurations.

■ For virtual NICs, all the components—the virtual NIC, the corresponding physical
NIC, and the virtual switch—must be set to 9000 MTU.
■ If a higher MTU cannot be configured on the public link (because of restrictions
on other components such as a public switch), do not configure the public link
in LLT. LLT uses the lowest of the MTU that is configured among all high priority
and low priority links.

Setting up shared storage

This topic applies to VCS, SFHA, SFCFS, SFCFSHA and SF Oracle RAC
The sections describe how to set up the SCSI and the Fibre Channel devices that
the cluster systems share.

Setting the SCSI identifier value

SCSI adapters are typically set with a default identifier value of 7. Each device on
a SCSI bus must have a unique SCSI identifier value. When more than one system
is connected to a SCSI bus, you must change the SCSI identifier to a unique number.
You must make this change to one or more systems, usually the unique number is
5 or 6.
Perform the procedure if you want to connect to shared storage with shared SCSI
devices.
 Preparing to install 34
Setting up shared storage

Figure 4-3 Cabling the shared storage

SCSI bus

Termination
Termination
System A System B

Shared disks

To set the SCSI identifier value

1 Determine the SCSI adapters on each system:

north # lsdev -C -c adapter | grep scsi

scsi0 Available 11-08 Wide/Ultra-2 SCSI I/O Controller
scsi1 Available 11-09 Wide/Ultra-2 SCSI I/O Controller
south # lsdev -C -c adapter | grep scsi
scsi0 Available 11-08 Wide/Ultra-2 SCSI I/O Controller
scsi1 Available 11-09 Wide/Ultra-2 SCSI I/O Controller

2 Verify the SCSI ID of each adapter:

north # lsattr -E -l scsi0 -a id

id 7 Adapter card SCSI ID True
north # lsattr -E -l scsi1 -a id
id 7 Adapter card SCSI ID True
south # lsattr -E -l scsi0 -a id
id 7 Adapter card SCSI ID True
south # lsattr -E -l scsi1 -a id
id 7 Adapter card SCSI ID True

3 If necessary, change the SCSI identifier on each system so that it is unique:

south # chdev -P -l scsi0 -a id=5

scsi0 changed
south # chdev -P -l scsi1 -a id=5
scsi1 changed

4 Shut down all systems in the cluster.

 Preparing to install 35
Synchronizing time settings on cluster nodes

5 Cable the shared storage as illustrated in Figure 4-3.

6 Restart each system. After all systems have booted, use the lspv command
to verify that each system can see all shared devices needed by the application.

Setting up Fibre Channel

Perform the following steps to set up Fibre Channel.
To set up Fibre Channel
1 Connect the Fibre Channel adapters and the shared storage devices to the
same hub or switch.
All systems must see all the shared devices that are required to run the critical
application. If you want to implement zoning for a fibre switch, make sure that
no zoning prevents all systems from seeing all these shared devices.
2 Reboot each system:

# shutdown -Fr

3 After all systems have booted, use the lspv command to verify that each
system can see all shared devices needed by the application.

Synchronizing time settings on cluster nodes

Make sure that the time settings on all cluster nodes are synchronized. If the nodes
are not in sync, timestamps for change (ctime) and modification (mtime) may not
be consistent with the sequence in which operations actually happened.
For instructions, see the operating system documentation.

Configuring LLT interconnects to use Jumbo

Frames
You can configure LLT interconnects to enable Jumbo Frames by increasing the
maximum transmission unit (MTU) for physical systems and logical domains.
For physical systems enable Jumbo Frames at interface and LLT-level.
For logical domains enable jumbo Frames for LLT inside the logical domain. You
need to ensure that Jumbo Frames are enabled for the virtual network (vnet), virtual
switch (vsw) and the backend physical interface. If a physical switch is used between
any cluster nodes to connect the interconnect, ensure that MTU value of switch is
also set to a value that matches with other network components.
 Preparing to install 36
Planning the installation setup for SF Oracle RAC systems

Perform these steps on all nodes of the cluster

1 Enable Jumbo frames at interface level.
2 If its a physical machine, run these steps for all the interfaces to be used by
LLT
# chdev -Pl ifc-name -a jumbo_frames=yes

where, ifc-name is the interface name.

3 Run the command on physical as well as on LPARs.
# chdev -Pl ifc-name -a mtu=9000

where, ifc-name is the interface name.

4 Reboot the system
# shutdown -Fr

5 Modify llttab for 9000 MTU.

Llttab:

set-node <hostname>
set-cluster <clus-id>

link ent1 /dev/dlpi/en:1 - ether - 9000

link ent2 /dev/dlpi/en:2 - ether 9000

Planning the installation setup for SF Oracle RAC

systems
This section provides guidelines and best practices for planning resilient,
high-performant clusters. These best practices suggest optimal configurations for
your core clustering infrastructure such as network and storage. Recommendations
are also provided on planning for continuous data protection and disaster recovery.
Review the following planning guidelines before you install InfoScale:
■ Planning your network configuration
See “Planning your network configuration” on page 37.
■ Planning the storage
See “Planning the storage” on page 40.
■ Planning volume layout
See “Planning volume layout” on page 46.
 Preparing to install 37
Planning the installation setup for SF Oracle RAC systems

■ Planning file system design

See “Planning file system design” on page 47.

Planning your network configuration

The following practices are recommended for a resilient network setup:
■ Configure the private cluster interconnect over multiple dedicated gigabit Ethernet
links. All single point of failures such as network interface cards (NIC), switches,
and interconnects should be eliminated.
■ The NICs used for the private cluster interconnect should have the same
characteristics regarding speed, MTU, and full duplex on all nodes. Do not allow
the NICs and switch ports to auto-negotiate speed.
■ Configure non-routable IP addresses for private cluster interconnects.
■ The default value for LLT peer inactivity timeout is 32 seconds.
For SF Oracle RAC: The value should be set based on service availability
requirements and the propagation delay between the cluster nodes in case of
campus cluster setup. The LLT peer inactivity timeout value indicates the interval
after which InfoScale on one node declares the other node in the cluster dead,
if there is no network communication (heartbeat) from that node.
The default value for the CSS miss-count in case of InfoScale is 600 seconds.
The value of this parameter is much higher than the LLT peer inactivity timeout
so that the two clusterwares, VCS and Oracle Clusterware, do not interfere with
each other’s decisions on which nodes should remain in the cluster in the event
of network split-brain. Veritas I/O fencing is allowed to decide on the surviving
nodes first, followed by Oracle Clusterware. The CSS miss-count value indicates
the amount of time Oracle Clusterware waits before evicting another node from
the cluster, when it fails to respond across the interconnect.
For more information, see the Oracle Metalink document: 782148.1

Planning the public network configuration for Oracle RAC

Identify separate public virtual IP addresses for each node in the cluster. Oracle
RAC requires one public virtual IP address for the Oracle RAC listener process on
each node. Public virtual IP addresses are used by client applications to connect
to the Oracle RAC database and help mitigate TCP/IP timeout delays.
For SF Oracle RAC: For Oracle 11g Release 2 and later versions, additionally,
you need a Single Client Access Name (SCAN) registered in Enterprise DNS that
resolves to three IP addresses (recommended). Oracle Clusterware/Grid
Infrastructure manages the virtual IP addresses.
 Preparing to install 38
Planning the installation setup for SF Oracle RAC systems

Planning the private network configuration for Oracle RAC

Oracle RAC requires a minimum of one private IP address on each node for Oracle
Clusterware heartbeat.
For a11g and later versions, you must use UDP IPC for the database cache fusion
traffic.
Veritas recommends using multiple private interconnects for load balancing the
cache fusion traffic.

Note: The private IP addresses of all nodes that are on the same physical network
must be in the same IP subnet.

The following practices provide a resilient private network setup:

■ Configure Oracle Clusterware interconnects over LLT links to prevent data
corruption.
In an InfoScale cluster, the Oracle Clusterware heartbeat link MUST be
configured as an LLT link. If Oracle Clusterware and LLT use different links for
their communication, then the membership change between VCS and Oracle
Clusterware is not coordinated correctly. For example, if only the Oracle
Clusterware links are down, Oracle Clusterware kills one set of nodes after the
expiry of the css-misscount interval and initiates the Oracle Clusterware and
database recovery, even before CVM and CFS detect the node failures. This
uncoordinated recovery may cause data corruption.
■ Oracle Clusterware interconnects need to be protected against NIC failures and
link failures. For Oracle RAC 11.2.0.1 versions, the PrivNIC or MultiPrivNIC
agent can be used to protect against NIC failures and link failures, if multiple
links are available. Even if link aggregation solutions in the form of bonded NICs
are implemented, the PrivNIC or MultiPrivNIC agent can be used to provide
additional protection against the failure of the aggregated link by failing over to
available alternate links. These alternate links can be simple NIC interfaces or
bonded NICs.
An alternative option is to configure the Oracle Clusterware interconnects over
bonded NIC interfaces.
See “High availability solutions for Oracle RAC private network” on page 39.

Note: The PrivNIC and MultiPrivNIC agents are no longer supported in Oracle
RAC 11.2.0.2 and later versions for managing cluster interconnects.
For 11.2.0.2 and later versions, Veritas recommends the use of alternative
solutions such as bonded NIC interfaces or Oracle High Availability IP (HAIP).
 Preparing to install 39
Planning the installation setup for SF Oracle RAC systems

■ Configure Oracle Cache Fusion traffic to take place through the private network.
Veritas also recommends that all UDP cache-fusion links be LLT links.
For Oracle RAC 11.2.0.1 versions, the PrivNIC and MultiPrivNIC agents provide
a reliable alternative when operating system limitations prevent you from using
NIC bonding to provide high availability and increased bandwidth using multiple
network interfaces. In the event of a NIC failure or link failure, the agent fails
over the private IP address from the failed link to the connected or available
LLT link. To use multiple links for database cache fusion for increased bandwidth,
configure the cluster_interconnects initialization parameter with multiple IP
addresses for each database instance and configure these IP addresses under
MultiPrivNIC for high availability.
Oracle database clients use the public network for database services. Whenever
there is a node failure or network failure, the client fails over the connection, for
both existing and new connections, to the surviving node in the cluster with
which it is able to connect. Client failover occurs as a result of Oracle Fast
Application Notification, VIP failover and client connection TCP timeout. It is
strongly recommended not to send Oracle Cache Fusion traffic through the
public network.
■ Use NIC bonding to provide redundancy for public networks so that Oracle RAC
can fail over virtual IP addresses if there is a public link failure.

High availability solutions for Oracle RAC private network

Table 4-1 lists the high availability solutions that you may adopt for your private
network.

Table 4-1 High availability solutions for Oracle RAC private network

Options Description

Using link Use a native NIC bonding solution to provide redundancy, in case of
aggregation/ NIC NIC failures.
bonding for Oracle
Make sure that a link configured under a aggregated link or NIC bond
Clusterware
is not configured as a separate LLT link.
When LLT is configured over a bonded interface, do one of the
following steps to prevent GAB from reporting jeopardy membership:

■ Configure an additional NIC under LLT in addition to the bonded

NIC.
■ Add the following line in the /etc/llttab file:

set-dbg-minlinks 2
 Preparing to install 40
Planning the installation setup for SF Oracle RAC systems

Table 4-1 High availability solutions for Oracle RAC private network
(continued)

Options Description

Using HAIP Starting with Oracle RAC 11.2.0.2, Oracle introduced the High
Availability IP (HAIP) feature for supporting IP address failover. The
purpose of HAIP is to perform load balancing across all active
interconnect interfaces and fail over existing non-responsive interfaces
to available interfaces. HAIP has the ability to activate a maximum of
four private interconnect connections. These private network adapters
can be configured during the installation of Oracle Grid Infrastructure
or after the installation using the oifcfg utility.

Planning the public network configuration for Oracle RAC

Public interconnects are used by the clients to connect to Oracle RAC database.
The public networks must be physically separated from the private networks.
See Oracle RAC documentation for more information on recommendations for
public network configurations.

Planning the private network configuration for Oracle RAC

Private interconnect is an essential component of a shared disk cluster installation.
It is a physical connection that allows inter-node communication. Veritas
recommends that these interconnects and LLT links must be the same. You must
have the IP addresses configured on these interconnects, persistent after reboot.
You must use solutions specific to the operating System.
See Oracle RAC documentation for more information on recommendations for
private network configurations.

Planning the storage

InfoScale provides the following options for shared storage:
■ CVM
CVM provides native naming (OSN) as well as enclosure-based naming (EBN).
Use enclosure-based naming for easy administration of storage. Enclosure-based
naming guarantees that the same name is given to a shared LUN on all the
nodes, irrespective of the operating system name for the LUN.
■ CFS
■ For SF Oracle RAC: Local storage
 Preparing to install 41
Planning the installation setup for SF Oracle RAC systems

With FSS, local storage can be used as shared storage. The local storage can
be in the form of Direct Attached Storage (DAS) or internal disk drives.
■ For SF Oracle RAC:Oracle ASM over CVM
The following recommendations ensure better performance and availability of
storage.
■ Use multiple storage arrays, if possible, to ensure protection against array
failures. The minimum recommended configuration is to have two HBAs for
each host and two switches.
■ Design the storage layout keeping in mind performance and high availability
requirements. Use technologies such as striping and mirroring.
■ Use appropriate stripe width and depth to optimize I/O performance.
■ Use SCSI-3 persistent reservations (PR) compliant storage.
■ Provide multiple access paths to disks with HBA/switch combinations to allow
DMP to provide high availability against storage link failures and to provide load
balancing.

Planning the storage

Table 4-2 lists the type of storage required for SF Oracle RAC.

Table 4-2 Type of storage required for SF Oracle RAC

Files Type of storage

SF Oracle RAC binaries Local

SF Oracle RAC database Shared

storage management
repository

Planning the storage for Oracle RAC

Review the storage options and guidelines for Oracle RAC:
■ Storage options for OCR and voting disk
See “Planning the storage for OCR and voting disk” on page 42.
■ Storage options for the Oracle RAC installation directories (ORACLE_BASE,
CRS_HOME or GRID_HOME (depending on Oracle RAC version), and
ORACLE_HOME)
See “Planning the storage for Oracle RAC binaries and data files” on page 44.
 Preparing to install 42
Planning the installation setup for SF Oracle RAC systems

Planning the storage for OCR and voting disk

Depending on the Oracle RAC version and the type of redundancy you want for
the OCR and voting disks, use one of the following storage options:

External redundancy Oracle RAC 11g Release 2 and later versions:

■ Clustered File System

■ ASM disk groups created using CVM raw volumes

See “ OCR and voting disk storage configuration for external

redundancy” on page 42.

Normal redundancy Clustered File System

See “ OCR and voting disk storage configuration for normal

redundancy” on page 43.
Note: It is recommended that you configure atleast resource
dependency for high availability of the OCR and voting disk
resources.

Review the following notes before you proceed:

■ Set the disk detach policy setting to (local) with ioship off for OCR and voting
disk.
■ Configure OCR and voting disk on non-replicated shared storage when you
configure global clusters.
■ If you plan to use FSS, configure OCR and voting disk on SAN storage.

OCR and voting disk storage configuration for external redundancy

Figure 4-4 illustrates the OCR and voting disk storage options for external
redundancy.
 Preparing to install 43
Planning the installation setup for SF Oracle RAC systems

Figure 4-4 OCR and voting disk storage configuration for external
redundancy

Option 1: OCR and voting disk on CFS Option 2: OCR and voting disk on CVM raw volumes
with two-way mirroring with two-way mirroring

ocrvol votevol
(CVM volume mirrored (CVM volume mirrored
on Disk1 and Disk 2) on Disk1 and Disk 2)
/ocrvote/vote /ocrvote/ocr

ocrvotevol
(CVM volume mirrored
on Disk1 and Disk 2)

Disk 1 Disk 2 Disk 1 Disk 2

ocrvotedg ocrvotedg

■ If you want to place OCR and voting disk on a clustered file system (option 1),
you need to have two separate files for OCR and voting information respectively
on CFS mounted on a CVM mirrored volume.
■ If you want to place OCR and voting disk on CVM raw volumes or on ASM disk
groups that use CVM raw volumes (option 2), you need to use two CVM mirrored
volumes for configuring OCR and voting disk on these volumes.
For both option 1 and option 2:
■ The option External Redundancy must be selected at the time of installing
Oracle Clusterware/Grid Infrastructure.
■ The installer needs at least two LUNs for creating the OCR and voting disk
storage.
See the Oracle RAC documentation for Oracle RAC's recommendation on the
required disk space for OCR and voting disk.

OCR and voting disk storage configuration for normal redundancy

Figure 4-5 illustrates the OCR and voting disk storage options for normal
redundancy.
 Preparing to install 44
Planning the installation setup for SF Oracle RAC systems

Figure 4-5 OCR and voting disk storage configuration for normal redundancy

OCR on CFS Voting disk on CFS

/ocr1/ocr /ocr2/ocrmirror /vote1/votedisk1 /vote2/votedisk2 /vote3/votedisk3

V V
O O
L L
U U
M M
E Vol1 Vol2 E Vol1 Vol2 Vol3
S S

D D
I I
S S
Disk 1 Disk 2 Disk 1 Disk 2 Disk 3
K K
S S

The OCR and voting disk files exist on separate cluster file systems.
Configure the storage as follows:
■ Create separate filesystems for OCR and OCR mirror.
■ Create separate filesystems for a minimum of 3 voting disks for redundancy.
■ The option Normal Redundancy must be selected at the time of installing
Oracle Clusterware/Grid Infrastructure.

Note: It is recommended that you configure atleast resource dependency for

high availability of the OCR and voting disk resources.

Planning the storage for Oracle RAC binaries and data files
The Oracle RAC binaries can be stored on local storage or on shared storage,
based on your high availability requirements.

Note: Veritas recommends that you install the Oracle Clusterware and Oracle RAC
database binaries local to each node in the cluster.

Consider the following points while planning the installation:

■ Local installations provide improved protection against a single point of failure
and also allows for applying Oracle RAC patches in a rolling fashion.
 Preparing to install 45
Planning the installation setup for SF Oracle RAC systems

■ CFS installations provide a single Oracle installation to manage, regardless of

the number of nodes. This scenario offers a reduction in storage requirements
and easy addition of nodes.
Table 4-3 lists the type of storage for Oracle RAC binaries and data files.

Table 4-3 Type of storage for Oracle RAC binaries and data files

Oracle RAC files Type of storage

Oracle base Local

Oracle Clusterware/Grid Local

Infrastructure binaries
Placing the Oracle Grid Infrastructure binaries on local disks
enables rolling upgrade of the cluster.

Oracle RAC database Local

binaries
Placing the Oracle RAC database binaries on local disks enables
rolling upgrade of the cluster.

Database datafiles Shared

Store the Oracle RAC database files on CFS rather than on raw
device or CVM raw device for easier management. Create
separate clustered file systems for each Oracle RAC database.
Keeping the Oracle RAC database datafiles on separate mount
points enables you to unmount the database for maintenance
purposes without affecting other databases.

If you plan to store the Oracle RAC database on ASM, configure

the ASM disk groups over CVM volumes to take advantage of
dynamic multi-pathing.

Database recovery data Shared

(archive, flash recovery)
Place archived logs on CFS rather than on local file systems.

Planning for Oracle RAC ASM over CVM

Review the following information on storage support provided by Oracle RAC ASM:

Supported by ASM ASM provides storage for data files, control files, online redo
logs and archive log files, and backup files. Starting with Oracle
RAC 11g Release 2, ASM also supports storage for OCR and
voting disk.

Not supported by ASM Oracle RAC 11g Release 2 and later versions:

ASM does not support Oracle binaries, trace files, alert logs,
export files, tar files, core files, and application binaries on ASM.
 Preparing to install 46
Planning the installation setup for SF Oracle RAC systems

The following practices offer high availability and better performance:

■ Use CVM mirrored volumes with dynamic multi-pathing for creating ASM disk
groups. Select external redundancy while creating ASM disk groups.
■ The CVM raw volumes used for ASM must be used exclusively for ASM. Do
not use these volumes for any other purpose, such as creation of file systems.
Creating file systems on CVM raw volumes used with ASM may cause data
corruption.
■ Do not link the Veritas ODM library when databases are created on ASM. ODM
is a disk management interface for data files that reside on the Veritas File
System.
■ Use a minimum of two Oracle RAC ASM disk groups. Store the data files, one
set of redo logs, and one set of control files on one disk group. Store the Flash
Recovery Area, archive logs, and a second set of redo logs and control files on
the second disk group.
For more information, see Oracle RAC's ASM best practices document.
■ Do not configure DMP meta nodes as ASM disks for creating ASM disk groups.
Access to DMP meta nodes must be configured to take place through CVM.
■ Do not combine DMP with other multi-pathing software in the cluster.
■ Do not use coordinator disks, which are configured for I/O fencing, as ASM
disks. I/O fencing disks should not be imported or used for data.
■ Volumes presented to a particular ASM disk group should be of the same speed
and type.

Planning volume layout

The following recommendations ensure optimal layout of VxVM/CVM volumes:
■ Mirror the volumes across two or more storage arrays, if using VxVM mirrors.
Keep the Fast Mirror Resync regionsize equal to the database block size to
reduce the copy-on-write (COW) overhead. Reducing the regionsize increases
the amount of Cache Object allocations leading to performance overheads.
■ Distribute the I/O load uniformly on all Cache Objects when you create multiple
Cache Objects.
■ Implement zoning on SAN switch to control access to shared storage. Be aware
that physical disks may be shared by multiple servers or applications and must
therefore be protected from accidental access.
■ Choose DMP I/O policy based on the storage network topology and the
application I/O pattern.
■ Exploit thin provisioning for better return on investment.
 Preparing to install 47
Updating the SCSI reserve ODM attribute settings for VIOS

■ For SF Oracle RAC:

Separate the Oracle recovery structures from the database files to ensure high
availability when you design placement policies.
Separate redo logs and place them on the fastest storage (for example, RAID
1+ 0) for better performance.
Use "third-mirror break-off" snapshots for cloning the Oracle log volumes. Do
not create Oracle log volumes on a Space-Optimized (SO) snapshot.
Create as many Cache Objects (CO) as possible when you use Space-Optimized
(SO) snapshots for Oracle data volumes.

Planning file system design

The following recommendations ensure an optimal file system design for databases:
■ Create separate file systems for Oracle RAC binaries, data, redo logs, and
archive logs. This ensures that recovery data is available if you encounter
problems with database data files storage.
■ Always place archived logs on CFS file systems rather then local file systems.
■ For SF Oracle RAC: If using VxVM mirroring, use ODM with CFS for better
performance. ODM with SmartSync enables faster recovery of mirrored volumes
using Oracle resilvering.

Setting the umask before installation

The topic applies to SF Oracle RAC.
Set the umask to provide appropriate permissions for InfoScale binaries and files.
This setting is valid only for the duration of the current session.

# umask 0022

Updating the SCSI reserve ODM attribute settings

for VIOS
This step applies to DMP.
If any path to the target disk has SCSI reserve ODM attribute set, then change the
attributes to release the SCSI reservation from the paths, on a restart.
■ If a path has the reserve_policy attribute set, change thereserve_policy
attribute to no_reserve for all the paths.
# lsattr -E1 hdisk557 | grep res
reserve_policy single_path
 Preparing to install 48
Updating the SCSI reserve ODM attribute settings for VIOS

Reserve Policy True

# chdev -l hdisk557 -a reserve_policy=no_reserve -P
hdisk557 changed

■ If a path has the reserve_lock attribute set, change the reserve_lockattribute

to no.
# lsattr -E1 hdisk558 | grep reserve_lock
reserve_lock yes
Reserve Device on open True
# chdev -l hdisk558 -a reserve_lock=no -P
hdisk558 changed
 Section 2
Installation of Veritas
InfoScale

■ Chapter 5. Installing Veritas InfoScale using the installer

■ Chapter 6. Installing Veritas InfoScale using response files

■ Chapter 7. Installing Veritas Infoscale using operating system-specific methods

■ Chapter 8. Completing the post installation tasks

 Chapter 5
Installing Veritas InfoScale
using the installer
This chapter includes the following topics:

■ Installing Veritas InfoScale using the installer

■ Executive Order logging

Installing Veritas InfoScale using the installer

The product installer is the recommended method to license and install Veritas
InfoScale.
To install Veritas Infoscale
1 Load and mount the software disc. If you downloaded the software, navigate
to the top level of the download directory and skip the next step.

2 Move to the top-level directory on the disc.

# cd /mnt/cdrom

3 From this directory, type the following command to start the installation on the
local system.

# ./installer

4 Press I to install and press Enter.

 Installing Veritas InfoScale using the installer 51
Installing Veritas InfoScale using the installer

5 The list of available products is displayed. Select the product that you want to
install on your system.

1) Veritas InfoScale Foundation

2) Veritas InfoScale Availability
3) Veritas InfoScale Storage
4) Veritas InfoScale Enterprise
b) Back to previous menu
Select a product to install: [1-4,b,q]

6 The installer asks whether you want to configure the product.

Would you like to configure InfoScale Enterprise after installation?

[y,n,q]

If you enter y, the installer configures the product after installation. If you enter
n, the installer quits after the installation is complete.
7 At the prompt, specify whether you accept the terms of the End User License
Agreement (EULA).

Do you agree with the terms of the End User License Agreement as
specified in the EULA/en/EULA.pdf file
present on media? [y,n,q,?] y

8 The installer performs the pre-checks. If it is a fresh system, the product is set
as the user defined it. If the system already has a different product installed,
the product is set as Veritas InfoScale Enterprise with a warning message after
pre-check.

Veritas InfoScale Availability is installed. Installation of two

products is not supported, Veritas InfoScale Enterprise will be
installed to include Veritas InfoScale Storage and Veritas
InfoScale Availability on all the systems.
 Installing Veritas InfoScale using the installer 52
Executive Order logging

9 Specify whether you want to configure the REST server.

The install program needs to make the following configuration

changes to enable REST server support:
Configure the clusters in Secure mode.

Do you want to configure REST API Server? [y,n,q,?] (n)

If you enter y, the cluster is automatically configured in the secure mode. At a

later point, the installer prompts you to provide further input that is required for
the REST server configurations. For details, refer to the Veritas InfoScale
Solutions Guide.
10 Check the log file to confirm the installation. The log files, summary file, and
response file are saved at: /opt/VRTS/install/logs directory.

Executive Order logging

InfoScale EO compliant logging option helps to configure InfoScale components to
provide logging as per standard security requirements and also to stop the InfoScale
Enterprise processes. In case of interactive deployment, CPI prompts for the EO
compliant logging consent to enable logging of all the components. You can also
configure the stop process by answering stop process question. If the option to
enable the logging is not selected at the time of deployment, CPI provides options
such as -eocompliantlogging, which can be used to enable or disable the logging
with the following commands:
■ # /opt/VRTS/install/installer -eocompliantlogging on

■ # /opt/VRTS/install/installer -eocompliantlogging off

 Chapter 6
Installing Veritas InfoScale
using response files
This chapter includes the following topics:

■ About response files

■ Installing InfoScale using response files

■ Response file variables to install Veritas InfoScale

■ Sample response files for Veritas InfoScale installation

About response files

The installer script or product installation script generates a response file during
any installation, configuration, upgrade, or uninstall procedure. The response file
contains the configuration information that you entered during the procedure. When
the procedure completes, the installation script displays the location of the response
files.
You can use the response file for future installation procedures by invoking an
installation script with the -responsefile option. The response file passes
arguments to the script to automate the installation of that product. You can edit
the file to automate installation and configuration of additional systems.
You can also use -makeresponsefile option to generate a responsefile. This
response file is used for unattended installations in the future. Run ./installer
-makeresponsefile with the option you want.

Note: Veritas recommends that you use the response file created by the installer
and then edit it as per your requirement.
 Installing Veritas InfoScale using response files 54
Installing InfoScale using response files

Syntax in the response file

The syntax of the Perl statements that is included in the response file variables
varies. It can depend on whether the variables require scalar or list values.
For example, in the case of a string value:

$CFG{Scalar_variable}="value";

or, in the case of an integer value:

$CFG{Scalar_variable}=123;

or, in the case of a list:

$CFG{List_variable}=["value 1 ", "value 2 ", "value 3 "];

Installing InfoScale using response files

Typically, you can use the response file that the installer generates after you perform
InfoScale installation on a system to install InfoScale on other systems..
To install InfoScale using response files
1 Make sure the systems where you want to install InfoScale meet the installation
requirements.

2 Make sure that the preinstallation tasks are completed.

3 Copy the response file to the system where you want to install InfoScale.

4 Edit the values of the response file variables as necessary.

5 Mount the product disc and navigate to the directory that contains the installation
program.
6 Start the installation from the system to which you copied the response file.
For example:

# ./installer -responsefile /tmp/response_file

Where /tmp/response_file is the response file’s full path name.

7 Complete the InfoScale post-installation tasks.
For instructions, see the chapter Performing post-installation tasks in this
document.
 Installing Veritas InfoScale using response files 55
Response file variables to install Veritas InfoScale

Response file variables to install Veritas InfoScale

Table 6-1 lists the response file variables that you can define to install InfoScale.

Table 6-1 Response file variables for installing InfoScale

Variable Description

CFG{opt}{install} Installs InfoScale filesets. Configuration can be performed

at a later time using the -configure option.

List or scalar: scalar

Optional or required: optional

CFG{activecomponent} Specifies the component for operations like precheck,

configure, addnode, install and configure(together).

List or scalar: list

Optional or required: required

CFG{accepteula} Specifies whether you agree with the EULA.pdf file on

the media.

List or scalar: scalar

Optional or required: required

CFG{systems} List of systems on which the product is to be installed or

uninstalled.

List or scalar: list

Optional or required: required

CFG{prod} Defines the product to be installed or uninstalled.

List or scalar: scalar

Optional or required: required

CFG{opt}{keyfile} Defines the location of an ssh keyfile that is used to

communicate with all remote systems.

List or scalar: scalar

Optional or required: optional

CFG{opt}{tmppath} Defines the location where a working directory is created

to store temporary files and the filesets that are needed
during the install. The default location is /opt/VRTStmp.

List or scalar: scalar

Optional or required: optional

 Installing Veritas InfoScale using response files 56
Sample response files for Veritas InfoScale installation

Table 6-1 Response file variables for installing InfoScale (continued)

Variable Description

CFG{opt}{rsh} Defines that rsh must be used instead of ssh as the

communication method between systems.

List or scalar: scalar

Optional or required: optional

CFG{opt}{logpath} Mentions the location where the log files are to be copied.
The default location is /opt/VRTS/install/logs.

List or scalar: scalar

Optional or required: optional

Sample response files for Veritas InfoScale

installation
The following example shows a response file for installing Veritas InfoScale using
a keyless license.

our %CFG;
$CFG{accepteula}=1;

$CFG{opt}{gco}=1;
$CFG{opt}{install}=1;
$CFG{prod}="ENTERPRISE802";
$CFG{systems}=[ qw(system1 system2) ];
1;

The following example shows a response file for installing Veritas InfoScale using
a permanent license.

our %CFG;
$CFG{accepteula}=1;

$CFG{opt}{gco}=1;
$CFG{opt}{install}=1;
$CFG{prod}="ENTERPRISE802";
$CFG{systems}=[ qw(system1 system2) ];
1;
 Chapter 7
Installing Veritas Infoscale
using operating
system-specific methods
This chapter includes the following topics:

■ About installing InfoScale using operating system-specific methods

■ Installing InfoScale using NIM and the installer

About installing InfoScale using operating

system-specific methods
On AIX, you can install InfoScale using the following methods:
■ You can use the product installer along with Network Installation Manager (NIM)
to install the InfoScale product, or to install the operating system with the
InfoScale product.
See “Installing InfoScale using NIM and the installer” on page 57.

Installing InfoScale using NIM and the installer

You can use the installer together with the NIM to install the InfoScale product, or
to install the operating system and the InfoScale product.
The instructions in this section assume a working knowledge of the Network
Installation Management process. See the operating system documentation for
detailed information on Network Installation Management.
 Installing Veritas Infoscale using operating system-specific methods 58
Installing InfoScale using NIM and the installer

In the following samples, the LPP resource uses LPP-80200-up2date and its relevant
SPOT resource is spot-80200-up2date.

Preparing the installation bundle on the NIM server

You need to prepare the installation bundle on the NIM server before you use NIM
to install InfoScale filesets. The following actions are executed on the NIM server.

Note: Make sure that the appropriate NIM LPP_SOURCE and SPOT resources
are present on the NIM server.

To prepare the installation bundle

1 Insert and mount the installation media.
2 Choose an LPP source:

# lsnim |grep -i lpp_source

LPP-80200-up2date resources lpp_source

3 Navigate to the product directory on the installation media and run the following
command to prepare the bundle resource:

# ./installer -nim LPP-80200-up2date

The installation program copies the necessary filesets and patches to the LPP
resource directory.
4 Enter a name for the bundle.
5 Run the lsnim -l command to check that the installp_bundle resource and
install_scripts resource are both created successfully.

Installing InfoScale on the NIM client using SMIT on the NIM server
You can install InfoScale on the NIM client using the SMIT tool on the NIM server.
Perform these steps on each node to have InfoScale installed in a cluster.
To install InfoScale
1 On the NIM server, start SMIT.

# smitty nim

2 In the menu, select Perform NIM Software Installation and Maintenance

Tasks.
 Installing Veritas Infoscale using operating system-specific methods 59
Installing InfoScale using NIM and the installer

3 In the menu, select Install and Update Software.

4 In the menu, select Install Software Bundle.
5 Select the systems from the list on which to install the software bundle.
6 In the menu, select the LPP_SOURCE. In this example, specify
LPP-80200-up2date.
7 In the menu, select the bundle.
8 For the installp flags, specify that the ACCEPT new license agreements flag
has a yes value.
9 If you want to use NIM to upgrade to another Veritas InfoScale product, make
sure that the Customization SCRIPT to run after installation flag has the
value [install_scripts].
10 Press the Enter key to start the installation. Note that it may take some time
to finish.
11 After the installation completes, configure InfoScale.

Installing InfoScale and the operating system on the NIM client using
SMIT
You can install InfoScale and the operating system on the NIM client using the
SMIT tool.
Perform these steps on each node to have InfoScale and AIX installed in a cluster.
To install InfoScale and the operating system
1 On the NIM server, start smitty for a NIM and operating system installation.

# smitty nim_bosinst

2 In the menu, select the standalone target.

3 In the menu, select spot - Install a copy of a SPOT resource.
4 In the menu, select the spot resource spot-80200-up2date.
5 In the menu, select the LPP_SOURCE. In this example, select
LPP-80200-up2date.
6 In the menu, select the following options:
■ For the ACCEPT new license agreements option, specify yes.
 Installing Veritas Infoscale using operating system-specific methods 60
Installing InfoScale using NIM and the installer

7 For the installp flags, specify that the ACCEPT new license agreements flag
has a yes value.
8 After the installation completes, configure InfoScale.
 Chapter 8
Completing the post
installation tasks
This chapter includes the following topics:

■ Verifying product installation

■ Setting environment variables

■ Commands to manage the Veritas telemetry collector on your server

■ Next steps after installation

Verifying product installation

After the InfoScale products are installed, the packages should be in the
COMMITTED state, as indicated by a C in the output:
To verify the version of the installed product, use the following command:

# /opt/VRTS/install/installer -version

To find out about the installed filesets and its versions, use the following command:

# /opt/VRTS/install/showversion

After every product installation, the installer creates an installation log file and a
summary file. The name and location of each file is displayed at the end of a product
installation, and are always located in the /opt/VRTS/install/logs directory.
Veritas recommends that you keep the files for auditing, debugging, and future use.
The installation log file contains all commands that are executed during the
procedure, their output, and the errors generated by the commands.
 Completing the post installation tasks 62
Setting environment variables

The summary file contains the results of the installation by the installer or the product
installation scripts. The summary includes the list of the packages, and the status
(success or failure) of each package, and information about the processes that
were stopped or restarted during the installation. After installation, refer to the
summary file to determine whether any processes need to be started.

Setting environment variables

Most of the commands which are used in the installation are present in the /sbin
or /usr/sbin directory. Add these directories to your PATH environment variable
as necessary.
After installation, InfoScale commands are in /opt/VRTS/bin. InfoScale manual
pages are stored in /opt/VRTS/man.
Some VCS custom scripts reside in /opt/VRTSvcs/bin. If you want to install a high
availability product, add /opt/VRTSvcs/bin to the PATH also.
Add the following directories to your PATH and MANPATH environment variable:
■ If you want to use Bourne or Korn shell (sh or ksh), enter the following:

$ PATH=$PATH:/usr/sbin:/sbin:/usr/bin:/opt/VRTS/bin
$ MANPATH=/usr/share/man:/opt/VRTS/man:$MANPATH
$ export PATH MANPATH

■ If you want to use a C shell (csh or tcsh), enter the following:

% set path = ( $path /usr/sbin /sbin/ /usr/bin/ /opt/VRTS/bin )

% setenv MANPATH /usr/share/man:/opt/VRTS/man:$MANPATH

The nroff versions of the online manual pages are not readable using the man
command if the bos.txt.tfs fileset is not installed. However, the VRTSvxvm and
VRTSvxfs filesets install ASCII versions in the /opt/VRTS/man/cat* and
/opt/VRTS/man/man* directories that are readable without the bos.txt.tfs fileset.

Commands to manage the Veritas telemetry

collector on your server
You can manage the Veritas telemetry collector on each of your servers by using
the/opt/VRTSvlic/tele/bin/TelemetryCollector command. See the following
table for a list of operations that you can perform to manage the Veritas telemetry
collector along with examples of each of the commands.
 Completing the post installation tasks 63
Next steps after installation

Table 8-1 Commands used to manage the collector

Operation Description

Start the collector (if Use the following command if you want to start a collector that is not
the collector is not sending telemetry data to the edge server.
already running)
/opt/VRTSvlic/tele/bin/TelemetryCollector -start

Restart the collector Use the following command to restart the collector that is sending
(if the collector is telemetry data to the edge server.
already running)
/opt/VRTSvlic/tele/bin/TelemetryCollector -restart

Check whether the Use the following command to check the status of the collector on
collector is running or your server.
not
/opt/VRTSvlic/tele/bin/TelemetryCollector -status

Next steps after installation

Once installation is complete, you can configure a component of your choice.
Table 8-2 lists the components and the respective Configuration and Upgrade
guides that are available.

Table 8-2 Guides available for configuration

Component Document name

Storage Foundation See Storage Foundation Configuration and

Upgrade Guide

See Storage Foundation Administrator's

Guide

Storage Foundation and High Availability See Storage Foundation and High Availability
Configuration and Upgrade Guide

Storage Foundation Cluster File System HA See Storage Foundation Cluster File System
High Availability Configuration and Upgrade
Guide

See Storage Foundation Cluster File System

High Availability Administrator's Guide

Cluster Server See Cluster Server Configuration and

Upgrade Guide

See Cluster Server Administrator's Guide

 Completing the post installation tasks 64
Next steps after installation

Table 8-2 Guides available for configuration (continued)

Component Document name

Storage Foundation for Oracle RAC See Storage Foundation for Oracle RAC
Configuration and Upgrade Guide

See Storage Foundation for Oracle RAC

Administrator's Guide
 Section 3
Uninstallation of Veritas
InfoScale

■ Chapter 9. Uninstalling Veritas InfoScale using the installer

■ Chapter 10. Uninstalling Veritas InfoScale using response files

 Chapter 9
Uninstalling Veritas
InfoScale using the
installer
This chapter includes the following topics:

■ Preparing to uninstall a InfoScale product

■ Removing the Replicated Data Set

■ Uninstalling InfoScale filesets using the installer

■ Removing Storage Foundation products using SMIT

■ Removing the Storage Foundation for Databases (SFDB) repository

Preparing to uninstall a InfoScale product

Complete the following preparations to uninstall a InfoScale product.

Warning: Failure to follow the preparations that are outlined in this chapter can
result in loss of data.

To remove InfoScale, complete the following preparations before the uninstallation:

■ Back up all VxFS file systems in full and move the files in all VxFS file systems
to native file systems backed with LVM logical volumes. Raw application data
stored in VxVM logical volumes must be moved to LVM logical volumes.
■ Remove all but one copy of file systems and databases.
 Uninstalling Veritas InfoScale using the installer 67
Preparing to uninstall a InfoScale product

■ Remove all but one plex from volumes that contain multiple plexes (mirrors).
To display a list of all volumes, use the command:

# vxprint -Ath

To remove a plex, use the command:

# vxplex -g diskgroup -o rm dis plex

■ If a remaining plex contains multiple subdisks, consolidate the subdisks into a

single subdisk using the commands:

# vxassist -g diskgroup mirror volume layout=contig

# vxplex -g diskgroup -o rm dis plex

Sufficient space on another disk is required for this operation to complete.

■ Modify /etc/filesystems to remove or change entries for VxFS file systems
that were moved to native file systems.
■ Move all data from volumes created from multiple regions of storage, including
striped or spanned volumes, onto a single disk or appropriate LVM logical
volume. This can be done using one of the following three methods:
■ Back up the system to tape or other media and recover the system from this.
■ Move volumes incrementally (evacuate) onto logical volumes. Evacuation
moves subdisks from the source disks to target disks. The evacuated disks
provide the initial free disk space for volumes to be moved to LVM volumes.
See “Moving volumes to physical disks” on page 67.

Moving volumes to physical disks

You can use the following steps to move data off of VxVM volumes.
To move data off of VxVM volumes
1 Evacuate as many disks as possible by using one of the following methods:
■ the "Remove a disk" option in vxdiskadm
■ the Veritas Enterprise Administrator
 Uninstalling Veritas InfoScale using the installer 68
Preparing to uninstall a InfoScale product

■ the vxevac script from the command line.

2 Remove the evacuated disks from Veritas Volume Manager control using the
following commands:

# vxdg -g diskgroup rmdisk disk_media_name

# /usr/lib/vxvm/bin/vxdiskunsetup -C disk_access_name
# vxdisk rm disk_access_name

For example:

# vxdg -g mydg rmdisk mydg01

# /usr/lib/vxvm/bin/vxdiskunsetup -C hdisk1
# vxdisk rm hdisk1

3 Decide which volume to move first. If the volume to be moved is mounted,

unmount it. If the volume is being used as a raw partition for database
applications, make sure that the application is not updating the volume and
that data on the volume has been synchronized.
4 On the free disk space, create an LVM logical volume that is the same size as
the VxVM volume. If there is not enough free space for the logical volume, add
a new disk to the system for the first volume to be removed. For subsequent
volumes, you can use the free space generated by the removal of the first
volume.
5 Copy the data on the volume onto the newly created LVM logical volume using
the following command:

# dd if=/dev/vx/dsk/diskgroup/volume of=/dev/vgvol

where diskgroup is the name of a VxVM disk group, volume is the old volume
in that disk group, and vgvol is a newly created LVM volume.
If the volume contains a VxFS file system, the user data managed by VxFS in
the volume must be backed up or copied to a native AIX file system in an LVM
logical volume.
6 The entries in /etc/filesystems for volumes holding VxFS file systems, that
were copied to native file systems in step 5, must be modified according to the
change in step 5.
7 Mount the disk if the corresponding volume was previously mounted.
8 Remove the volume from VxVM using the following command:

# vxedit -g diskgroup -rf rm volume

 Uninstalling Veritas InfoScale using the installer 69
Removing the Replicated Data Set

9 Remove any disks that have become free (have no subdisks defined on them)
by removing volumes from VxVM control. To check if there are still some
subdisks remaining on a particular disk, use the following command:

# vxprint -g diskgroup -F "%sdnum" disk_media_name

10 If the return code is not 0, there are still some subdisks on this disk that must
be subsequently removed. If the return code is 0, remove the disk from VxVM
control using the following commands:

# vxdg -g diskgroup rmdisk disk_media_name

# vxdisk rm disk_access_name

11 Copy the data in the next volume to be removed to the newly created free
space.
12 Reboot the system after all volumes have been converted successfully. Verify
that no open volumes remain after the system reboot using the following
command:

# vxprint -Aht -e v_open

13 If any volumes remain open, repeat the steps listed above.

Removing the Replicated Data Set

If you use VVR, you need to perform the following steps. This section gives the
steps to remove a Replicated Data Set (RDS) when the application is either active
or stopped.

Note: If you are upgrading Volume Replicator, do not remove the Replicated Data
Set.
 Uninstalling Veritas InfoScale using the installer 70
Removing the Replicated Data Set

To remove the Replicated Data Set

1 Verify that all RLINKs are up-to-date:

# vxrlink -g diskgroup status rlink_name

If the Secondary is not required to be up-to-date, proceed to 2 and stop

replication using the -f option with the vradmin stoprep command.
2 Stop replication to the Secondary by issuing the following command on any
host in the RDS:
The vradmin stoprep command fails if the Primary and Secondary RLINKs
are not up-to-date. Use the -f option to stop replication to a Secondary even
when the RLINKs are not up-to-date.

# vradmin -g diskgroup stoprep local_rvgname sec_hostname

The argument local_rvgname is the name of the RVG on the local host and
represents its RDS.
The argument sec_hostname is the name of the Secondary host as displayed
in the output of the vradmin printrvg command.
3 Remove the Secondary from the RDS by issuing the following command on
any host in the RDS:

# vradmin -g diskgroup delsec local_rvgname sec_hostname

The argument local_rvgname is the name of the RVG on the local host and
represents its RDS.
The argument sec_hostname is the name of the Secondary host as displayed
in the output of the vradmin printrvg command.
4 Remove the Primary from the RDS by issuing the following command on the
Primary:

# vradmin -g diskgroup delpri local_rvgname

When used with the -f option, the vradmin delpri command removes the
Primary even when the application is running on the Primary.
The RDS is removed.
5 If you want to delete the SRLs from the Primary and Secondary hosts in the
RDS, issue the following command on the Primary and all Secondaries:

# vxedit -r -g diskgroup rm srl_name

 Uninstalling Veritas InfoScale using the installer 71
Uninstalling InfoScale filesets using the installer

Uninstalling InfoScale filesets using the installer

Use the following procedure to remove InfoScale products.
Not all filesets may be installed on your system depending on the choices that you
made when you installed the software.

Note: After you uninstall the product, you cannot access any file systems you
created using the default disk layout version in InfoScale 8.0.2 with a previous
version of InfoScale.

To shut down and remove the installed InfoScale filesets

1 Disable DMP native support, if it is enabled. Run the following command to
disable DMP native support

# vxdmpadm settune dmp_native_support=off

# shutdown -Fr

2 Comment out or remove any Veritas File System (VxFS) entries from the file
system table /etc/filesystems. Failing to remove these entries could result
in system boot problems later.
3 Unmount all mount points for VxFS file systems.

# umount /mount_point

4 If the VxVM package (VRTSvxvm) is installed, read and follow the uninstallation
procedures for VxVM.
See “Preparing to uninstall a InfoScale product” on page 66.

5 Make sure you have performed all of the prerequisite steps.

6 In an HA configuration, stop VCS processes on either the local system or all
systems.
To stop VCS processes on the local system:

# hastop -local

To stop VCS processes on all systems:

# hastop -all
 Uninstalling Veritas InfoScale using the installer 72
Removing Storage Foundation products using SMIT

7 Move to the /opt/VRTS/install directory and run the uninstall script.

# cd /opt/VRTS/install

# ./installer -uninstall

8 The uninstall script prompts for the system name. Enter one or more system
names, separated by a space, from which to uninstall InfoScale.

Enter the system names separated by spaces: [q?] sys1 sys2

9 The uninstall script prompts you to stop the product processes. If you respond
yes, the processes are stopped and the filesets are uninstalled.
The uninstall script creates log files and displays the location of the log files.
10 Most filesets have kernel components. In order to ensure complete removal,
a system reboot is recommended after all filesets have been removed.
11 In case the uninstallation fails to remove any of the VRTS packages, check
the installer logs for the reason for failure or try to remove the packages
manually using the following command:

# installp -u VRTSvxvm

Removing Storage Foundation products using

SMIT
Use the following procedure to remove Storage Foundation products using SMIT.
 Uninstalling Veritas InfoScale using the installer 73
Removing Storage Foundation products using SMIT

To remove the packages using SMIT

1 Stop the following SFCFSHA modules: VCS, VxFEN, ODM, GAB, and LLT.
Run the following commands to stop the SFCFSHA modules:

# hastop -all

# /etc/methods/glmkextadm unload

# /etc/rc.d/rc2.d/s99odm stop

# /etc/methods/gmskextadm unload

# /etc/init.d/vxfen.rc stop

# /etc/init.d/gab.rc stop

# /etc/init.d/llt.rc stop

Run the following commands to check if all the modules have been stopped:

# gabconfig -a

# lltconfig

2 Disable DMP native support, if it is enabled. Run the following command to

disable DMP native support

# vxdmpadm settune dmp_native_support=off

# shutdown -Fr

3 Enter this command to invoke SMIT:

# smit

4 In SMIT, select Software Installation and Maintenance > Software

Maintenance and Utilities > Remove Installed Software.
5 Under the SOFTWARE name menu, press F4 or Esc-4 to list all the software
that is installed on the system.
6 Enter "/" for Find, type "VRTS" to find all filesets, and select the filesets that
you want to remove.
 Uninstalling Veritas InfoScale using the installer 74
Removing the Storage Foundation for Databases (SFDB) repository

7 Restart the system after removing all Storage Foundation filesets.

8 Depending on the choices that were made when Storage Foundation was
originally installed, you may find that not all of the listed Storage Foundation
filesets are installed on the system. You may also choose to remove the
VRTSvlic licensing package unless some other Veritas InfoScale software
requires it.

Removing the Storage Foundation for Databases

(SFDB) repository
After removing the product, you can remove the SFDB repository file and any
backups.
Removing the SFDB repository file disables the SFDB tools.
 Uninstalling Veritas InfoScale using the installer 75
Removing the Storage Foundation for Databases (SFDB) repository

To remove the SFDB repository

1 Identify the SFDB repositories created on the host.
Oracle:

# cat /var/vx/vxdba/rep_loc

{
"sfae_rept_version" : 1,
"oracle" : {
"SFAEDB" : {
"location" : "/data/sfaedb/.sfae",
"old_location" : "",
"alias" : [
"sfaedb"
]
}
}
}

2 Remove the directory identified by the location key.

Oracle:

# rm -rf /data/sfaedb/.sfae

DB2 9.5 and 9.7:

# rm -rf /db2data/db2inst1/NODE0000/SQL00001/.sfae

DB2 10.1 and 10.5:

# rm -rf /db2data/db2inst1/NODE0000/SQL00001/MEMBER0000/.sfae

3 Remove the repository location file.

# rm -rf /var/vx/vxdba/rep_loc

This completes the removal of the SFDB repository.

 Chapter 10
Uninstalling Veritas
InfoScale using response
files
This chapter includes the following topics:

■ Uninstalling InfoScale using response files

■ Response file variables to uninstall Veritas InfoScale

■ Sample response file for Veritas InfoScale uninstallation

Uninstalling InfoScale using response files

Typically, you can use the response file that the installer generates after you perform
InfoScale uninstallation on one system to uninstall InfoScale on other systems.
To perform an automated uninstallation
1 Make sure that you meet the prerequisites to uninstall InfoScale.
2 Copy the response file to the system where you want to uninstall InfoScale.

3 Edit the values of the response file variables as necessary.

4 Start the uninstallation from the system to which you copied the response file.
For example:

# /opt/VRTS/install/installer -responsefile
/tmp/response_file

Where /tmp/response_file is the response file’s full path name.

 Uninstalling Veritas InfoScale using response files 77
Response file variables to uninstall Veritas InfoScale

Response file variables to uninstall Veritas

InfoScale
Table 10-1 lists the response file variables that you can define to configure InfoScale.

Table 10-1 Response file variables for uninstalling InfoScale

Variable Description

CFG{systems} List of systems on which the product is to be installed or

uninstalled.

List or scalar: list

Optional or required: required

CFG{prod} Defines the product to be installed or uninstalled.

List or scalar: scalar

Optional or required: required

CFG{opt}{keyfile} Defines the location of an ssh keyfile that is used to

communicate with all remote systems.

List or scalar: scalar

Optional or required: optional

CFG{opt}{tmppath} Defines the location where a working directory is created

to store temporary files and the filesets that are needed
during the install. The default location is /opt/VRTStmp.

List or scalar: scalar

Optional or required: optional

CFG{opt}{logpath} Mentions the location where the log files are to be copied.
The default location is /opt/VRTS/install/logs.

List or scalar: scalar

Optional or required: optional

CFG{opt}{uninstall} Uninstalls InfoScale filesets.

List or scalar: scalar

Optional or required: optional

 Uninstalling Veritas InfoScale using response files 78
Sample response file for Veritas InfoScale uninstallation

Sample response file for Veritas InfoScale

uninstallation
The following example shows a response file for uninstalling Veritas InfoScale

our %CFG;

$CFG{opt}{uninstall}=1;
$CFG{opt}{vr}=1;
$CFG{prod}="ENTERPRISE802";
$CFG{systems}=[ qw("system1", "system2") ];

1;
 Section 4
Installation reference

■ Appendix A. Installation scripts

■ Appendix B. Tunable files for installation

■ Appendix C. Troubleshooting installation issues

 Appendix A
Installation scripts
This appendix includes the following topics:

■ Installation script options

Installation script options

Table A-1 shows command line options for the installation script. For an initial install
or upgrade, options are not usually required. The installation script options apply
to all Veritas InfoScale product scripts, except where otherwise noted.

Table A-1 Available command line options

Command Line Option Function

-allpkgs Displays all filesets required for the specified

product. The filesets are listed in correct installation
order. The output can be used to create scripts for
command line installs, or for installations over a
network.

-comcleanup The -comcleanup option removes the secure

shell or remote shell configuration added by
installer on the systems. The option is only required
when installation routines that performed
auto-configuration of the shell are abruptly
terminated.

-comsetup The -comsetup option is used to set up the ssh

or rsh communication between systems without
requests for passwords or passphrases.

-configure Configures the product after installation.

 Installation scripts 81
Installation script options

Table A-1 Available command line options (continued)

Command Line Option Function

-disable_dmp_native_support Disables Dynamic Multi-pathing support for the

native LVM volume groups and ZFS pools during
upgrade. Retaining Dynamic Multi-pathing support
for the native LVM volume groups and ZFS pools
during upgrade increases package upgrade time
depending on the number of LUNs and native LVM
volume groups and ZFS pools configured on the
system.

-fqdn Specifies the fully qualified hostname to be set and

used while configuring the product on the system
if the hostname of the system is set as a fully
qualified hostname.

–hostfile full_path_to_file Specifies the location of a file that contains a list

of hostnames on which to install.

-install Used to install products on system

-online_upgrade Used to perform online upgrade. Using this option,

the installer upgrades the whole cluster and also
supports customer's application zero down time
during the upgrade procedure. Now this option is
supported only in VCS.

-patch_path Defines the path of a patch level release to be

integrated with a base or a maintenance level
release in order for multiple releases to be
simultaneously installed .

-patch2_path Defines the path of a second patch level release

to be integrated with a base or a maintenance level
release in order for multiple releases to be
simultaneously installed.

-patch3_path Defines the path of a third patch level release to

be integrated with a base or a maintenance level
release in order for multiple releases to be
simultaneously installed.

-patch4_path Defines the path of a fourth patch level release to

be integrated with a base or a maintenance level
release in order for multiple releases to be
simultaneously installed.
 Installation scripts 82
Installation script options

Table A-1 Available command line options (continued)

Command Line Option Function

-patch5_path Defines the path of a fifth patch level release to be

integrated with a base or a maintenance level
release in order for multiple releases to be
simultaneously installed.

–keyfile ssh_key_file Specifies a key file for secure shell (SSH) installs.
This option passes -I ssh_key_file to every
SSH invocation.

-license Registers or updates product licenses on the

specified systems.

–logpath log_path Specifies a directory other than

/opt/VRTS/install/logs as the location
where installer log files, summary files, and
response files are saved.

-noipc Disables the installer from making outbound

networking calls to Veritas Services and Operations
Readiness Tool (SORT) in order to automatically
obtain patch and release information updates.

-nolic Allows installation of product filesets without

entering a license key. Licensed features cannot
be configured, started, or used when this option is
specified.

-pkgtable Displays product's packages in correct installation

order by group.

–postcheck Checks for different HA and file system-related

processes, the availability of different ports, and
the availability of cluster-related service groups.

-precheck Performs a preinstallation check to determine if

systems meet all installation requirements. Veritas
recommends doing a precheck before installing a
product.

-prod Specifies the product for operations.

-component Specifies the component for operations.

-redirect Displays progress details without showing the

progress bar.
 Installation scripts 83
Installation script options

Table A-1 Available command line options (continued)

Command Line Option Function

-require Specifies an installer patch file.

-requirements The -requirements option displays required OS

version, required filesets and patches, file system
space, and other system requirements in order to
install the product.

–responsefile response_file Automates installation and configuration by using

system and configuration information stored in a
specified file instead of prompting for information.
The response_file must be a full path name. You
must edit the response file to use it for subsequent
installations. Variable field definitions are defined
within the file.

-rolling_upgrade Starts a rolling upgrade. Using this option, the

installer detects the rolling upgrade status on
cluster systems automatically without the need to
specify rolling upgrade phase 1 or phase 2
explicitly.

-rollingupgrade_phase1 The -rollingupgrade_phase1 option is used

to perform rolling upgrade Phase-I. In the phase,
the product kernel filesets get upgraded to the
latest version.

-rollingupgrade_phase2 The -rollingupgrade_phase2 option is used

to perform rolling upgrade Phase-II. In the phase,
VCS and other agent filesets upgrade to the latest
version. Product kernel drivers are rolling-upgraded
to the latest protocol version.

-rsh Specify this option when you want to use rsh and
RCP for communication between systems instead
of the default ssh and SCP.

–serial Specifies that the installation script performs install,

uninstall, start, and stop operations on each system
in a serial fashion. If this option is not specified,
these operations are performed simultaneously on
all systems.
 Installation scripts 84
Installation script options

Table A-1 Available command line options (continued)

Command Line Option Function

-settunables Specify this option when you want to set tunable

parameters after you install and configure a
product. You may need to restart processes of the
product for the tunable parameter values to take
effect. You must use this option together with the
-tunablesfile option.

-start Starts the daemons and processes for the specified

product.

-stop Stops the daemons and processes for the specified

product.

-timeout The -timeout option is used to specify the

number of seconds that the script should wait for
each command to complete before timing out.
Setting the -timeout option overrides the default
value of 1200 seconds. Setting the -timeout
option to 0 prevents the script from timing out. The
-timeout option does not work with the -serial
option

–tmppath tmp_path Specifies a directory other than /opt/VRTStmp

as the working directory for the installation scripts.
This destination is where initial logging is
performed and where filesets are copied on remote
systems before installation.

-tunables Lists all supported tunables and create a tunables

file template.

-tunablesfile tunables_file Specify this option when you specify a tunables

file. The tunables file should include tunable
parameters.

-uninstall This option is used to uninstall the products from

systems

-upgrade Specifies that an existing version of the product

exists and you plan to upgrade it.
 Installation scripts 85
Installation script options

Table A-1 Available command line options (continued)

Command Line Option Function

-version Checks and reports the installed products and their

versions. Identifies the installed and missing
packages and patches where applicable for the
product. Provides a summary that includes the
count of the installed and any missing filesets and
patches where applicable. Lists the installed
patches, patches, and available updates for the
installed product if an Internet connection is
available.

-makeresponsefile The -makeresponsefile option is used to

generate a response file to install, uninstall,
configure, or upgrade in the future.
 Appendix B
Tunable files for
installation
This appendix includes the following topics:

■ About setting tunable parameters using the installer or a response file

■ Setting tunables for an installation, configuration, or upgrade

■ Setting tunables with no other installer-related operations

■ Setting tunables with an un-integrated response file

■ Preparing the tunables file

■ Setting parameters for the tunables file

■ Tunables value parameter definitions

About setting tunable parameters using the

installer or a response file
You can set non-default product and system tunable parameters using a tunables
file. With the file, you can set tunables such as the I/O policy or toggle native
multi-pathing. The tunables file passes arguments to the installer script to set
tunables. With the file, you can set the tunables for the following operations:
■ When you install, configure, or upgrade systems.

# ./installer -tunablesfile tunables_file_name

See “Setting tunables for an installation, configuration, or upgrade” on page 87.

■ When you apply the tunables file with no other installer-related operations.
 Tunable files for installation 87
Setting tunables for an installation, configuration, or upgrade

# ./installer -tunablesfile tunables_file_name -settunables [

sys1 sys2 ...]

See “Setting tunables with no other installer-related operations” on page 88.

■ When you apply the tunables file with an un-integrated response file.

# ./installer -responsefile response_file_name -tunablesfile

tunables_file_name

See “Setting tunables with an un-integrated response file” on page 89.

See “About response files” on page 53.
You must select the tunables that you want to use from this guide.
See “Tunables value parameter definitions” on page 91.

Setting tunables for an installation, configuration,

or upgrade
You can use a tunables file for installation procedures to set non-default tunables.
You invoke the installation script with the tunablesfile option. The tunables file
passes arguments to the script to set the selected tunables. You must select the
tunables that you want to use from this guide.
See “Tunables value parameter definitions” on page 91.

Note: Certain tunables only take effect after a system reboot.

To set the non-default tunables for an installation, configuration, or upgrade

1 Prepare the tunables file.
See “Preparing the tunables file” on page 90.
2 Make sure the systems where you want to install InfoScale meet the installation
requirements.
3 Complete any preinstallation tasks.
4 Copy the tunables file to one of the systems where you want to install, configure,
or upgrade the product.
5 Mount the product disc and navigate to the directory that contains the installation
program.
 Tunable files for installation 88
Setting tunables with no other installer-related operations

6 Start the installer for the installation, configuration, or upgrade. For example:

# ./installer -tunablesfile /tmp/tunables_file

-settunables [sys1 sys2 ...]

Where /tmp/tunables_file is the full path name for the tunables file.
7 Proceed with the operation. When prompted, accept the tunable parameters.
Certain tunables are only activated after a reboot. Review the output carefully
to determine if the system requires a reboot to set the tunable value.
8 The installer validates the tunables. If an error occurs, exit the installer and
check the tunables file.

Setting tunables with no other installer-related

operations
You can use the installer to set tunable parameters without any other installer-related
operations. You must use the parameters described in this guide. Note that many
of the parameters are product-specific. You must select the tunables that you want
to use from this guide.
See “Tunables value parameter definitions” on page 91.

Note: Certain tunables only take effect after a system reboot.

To set tunables with no other installer-related operations

1 Prepare the tunables file.
See “Preparing the tunables file” on page 90.
2 Make sure the systems where you want to install InfoScale meet the installation
requirements.
3 Complete any preinstallation tasks.
4 Copy the tunables file to one of the systems that you want to tune.
5 Mount the product disc and navigate to the directory that contains the installation
program.
6 Start the installer with the -settunables option.

# ./installer -tunablesfile tunables_file_name -settunables [

sys123 sys234 ...]

Where /tmp/tunables_file is the full path name for the tunables file.
 Tunable files for installation 89
Setting tunables with an un-integrated response file

7 Proceed with the operation. When prompted, accept the tunable parameters.
Certain tunables are only activated after a reboot. Review the output carefully
to determine if the system requires a reboot to set the tunable value.
8 The installer validates the tunables. If an error occurs, exit the installer and
check the tunables file.

Setting tunables with an un-integrated response

file
You can use the installer to set tunable parameters with an un-integrated response
file. You must use the parameters described in this guide. Note that many of the
parameters are product-specific. You must select the tunables that you want to use
from this guide.
See “Tunables value parameter definitions” on page 91.

Note: Certain tunables only take effect after a system reboot.

To set tunables with an un-integrated response file

1 Make sure the systems where you want to install InfoScale meet the installation
requirements.
2 Complete any preinstallation tasks.
3 Prepare the tunables file.
See “Preparing the tunables file” on page 90.
4 Copy the tunables file to one of the systems that you want to tune.
5 Mount the product disc and navigate to the directory that contains the installation
program.
6 Start the installer with the -responsefile and -tunablesfile options.

# ./installer -responsefile response_file_name -tunablesfile

tunables_file_name

Where response_file_name is the full path name for the response file and
tunables_file_name is the full path name for the tunables file.
7 Certain tunables are only activated after a reboot. Review the output carefully
to determine if the system requires a reboot to set the tunable value.
8 The installer validates the tunables. If an error occurs, exit the installer and
check the tunables file.
 Tunable files for installation 90
Preparing the tunables file

Preparing the tunables file

A tunables file is a Perl module and consists of an opening and closing statement,
with the tunables defined between. Use the hash symbol at the beginning of the
line to comment out the line. The tunables file opens with the line "our %TUN;" and
ends with the return true "1;" line. The final return true line only needs to appear
once at the end of the file. Define each tunable parameter on its own line.
You can use the installer to create a tunables file template, or manually format
tunables files you create.
To create a tunables file template
◆ Start the installer with the -tunables option. Enter the following:

# ./installer -tunables

You see a list of all supported tunables, and the location of the tunables file
template.
To manually format tunables files
◆ Format the tunable parameter as follows:

$TUN{"tunable_name"}{"system_name"|"*"}=value_of_tunable;

For the system_name, use the name of the system, its IP address, or a wildcard
symbol. The value_of_tunable depends on the type of tunable you are setting. End
the line with a semicolon.
The following is an example of a tunables file.

#
# Tunable Parameter Values:
#
our %TUN;

$TUN{"tunable1"}{"*"}=1024;
$TUN{"tunable3"}{"sys123"}="SHA256";

1;

Setting parameters for the tunables file

Each tunables file defines different tunable parameters. The values that you can
use are listed in the description of each parameter. Select the tunables that you
want to add to the tunables file and then configure each parameter.
 Tunable files for installation 91
Tunables value parameter definitions

See “Tunables value parameter definitions” on page 91.

Each line for the parameter value starts with $TUN. The name of the tunable is in
curly brackets and double-quotes. The system name is enclosed in curly brackets
and double-quotes. Finally define the value and end the line with a semicolon, for
example:

$TUN{"dmp_daemon_count"}{"node123"}=16;

In this example, you are changing the dmp_daemon_count value from its default
of 10 to 16. You can use the wildcard symbol "*" for all systems. For example:

$TUN{"dmp_daemon_count"}{"*"}=16;

Tunables value parameter definitions

When you create a tunables file for the installer you can only use the parameters
in the following list.
Prior to making any updates to the tunables, refer to the Storage Foundation Cluster
File System High Availability Administrator's Guide for detailed information on
product tunable ranges and recommendations.
Table B-1 describes the supported tunable parameters that can be specified in a
tunables file.

Table B-1 Supported tunable parameters

Tunable Description

autoreminor (Veritas Volume Manager) Enable reminoring

in case of conflicts during disk group import.

autostartvolumes (Veritas Volume Manager) Enable the

automatic recovery of volumes.

dmp_cache_open (Dynamic Multi-Pathing) Whether the first open

on a device performed by an array support
library (ASL) is cached.

dmp_daemon_count (Dynamic Multi-Pathing) The number of kernel

threads for DMP administrative tasks.

dmp_delayq_interval (Dynamic Multi-Pathing) The time interval for

which DMP delays the error processing if the
device is busy.
 Tunable files for installation 92
Tunables value parameter definitions

Table B-1 Supported tunable parameters (continued)

Tunable Description

dmp_fast_recovery (Dynamic Multi-Pathing) Whether DMP should

attempt to obtain SCSI error information
directly from the HBA interface. This tunable
must be set after Dynamic Multi-Pathing is
started.

dmp_health_time (Dynamic Multi-Pathing) The time in seconds

for which a path must stay healthy.

dmp_log_level (Dynamic Multi-Pathing) The level of detail to

which DMP console messages are displayed.

dmp_low_impact_probe (Dynamic Multi-Pathing) Whether the low

impact path probing feature is enabled.

dmp_lun_retry_timeout (Dynamic Multi-Pathing) The retry period for

handling transient errors.

dmp_monitor_fabric (Dynamic Multi-Pathing) Whether the Event

Source daemon (vxesd) uses the Storage
Networking Industry Association (SNIA) HBA
API. This tunable must be set after Dynamic
Multi-Pathing is started.

dmp_monitor_ownership (Dynamic Multi-Pathing) Whether the dynamic

change in LUN ownership is monitored.

dmp_native_support (Dynamic Multi-Pathing) Whether DMP does

multi-pathing for native devices.

dmp_path_age (Dynamic Multi-Pathing) The time for which

an intermittently failing path needs to be
monitored before DMP marks it as healthy.

dmp_pathswitch_blks_shift (Dynamic Multi-Pathing) The default number

of contiguous I/O blocks sent along a DMP
path to an array before switching to the next
available path.

dmp_probe_idle_lun (Dynamic Multi-Pathing) Whether the path

restoration kernel thread probes idle LUNs.

dmp_probe_threshold (Dynamic Multi-Pathing) The number of paths

will be probed by the restore daemon.
 Tunable files for installation 93
Tunables value parameter definitions

Table B-1 Supported tunable parameters (continued)

Tunable Description

dmp_restore_cycles (Dynamic Multi-Pathing) The number of cycles

between running the check_all policy when
the restore policy is check_periodic.

dmp_restore_interval (Dynamic Multi-Pathing) The time interval in

seconds the restore daemon analyzes the
condition of paths.

dmp_restore_policy (Dynamic Multi-Pathing) The policy used by

DMP path restoration thread.

dmp_restore_state (Dynamic Multi-Pathing) Whether kernel thread

for DMP path restoration is started.

dmp_retry_count (Dynamic Multi-Pathing) The number of times

a path reports a path busy error consecutively
before DMP marks the path as failed.

dmp_scsi_timeout (Dynamic Multi-Pathing) The timeout value for

any SCSI command sent via DMP.

dmp_sfg_threshold (Dynamic Multi-Pathing) The status of the

subpaths failover group (SFG) feature.

dmp_stat_interval (Dynamic Multi-Pathing) The time interval

between gathering DMP statistics.

fssmartmovethreshold (Veritas Volume Manager) The file system

usage threshold for SmartMove (percent). This
tunable must be set after Veritas Volume
Manager is started.

max_diskq (Veritas File System) Specifies the maximum

disk queue generated by a single file. The
installer can only set the system default value
of max_diskq. Refer to the tunefstab(4) manual
page for setting this tunable for a specified
block device.
 Tunable files for installation 94
Tunables value parameter definitions

Table B-1 Supported tunable parameters (continued)

Tunable Description

read_ahead (Veritas File System) The 0 value disables

read ahead functionality, the 1 value (default)
retains traditional sequential read ahead
behavior, and the 2 value enables enhanced
read ahead for all reads. The installer can only
set the system default value of read_ahead.
Refer to the tunefstab(4) manual page for
setting this tunable for a specified block
device.

read_nstream (Veritas File System) The number of parallel

read requests of size read_pref_io that can be
outstanding at one time. The installer can only
set the system default value of read_nstream.
Refer to the tunefstab(4) manual page for
setting this tunable for a specified block
device.

read_pref_io (Veritas File System) The preferred read

request size. The installer can only set the
system default value of read_pref_io. Refer to
the tunefstab(4) manual page for setting this
tunable for a specified block device.

reclaim_on_delete_start_time (Veritas Volume Manager) Time of day to start

reclamation for deleted volumes. This tunable
must be set after Veritas Volume Manager is
started.

reclaim_on_delete_wait_period (Veritas Volume Manager) Days to wait before

starting reclamation for deleted volumes. This
tunable must be set after Veritas Volume
Manager is started.

same_key_for_alldgs (Veritas Volume Manager) Use the same

fencing key for all disk groups. This tunable
must be set after Veritas Volume Manager is
started.

sharedminorstart (Veritas Volume Manager) Start of range to

use for minor numbers for shared disk groups.
This tunable must be set after Veritas Volume
Manager is started.
 Tunable files for installation 95
Tunables value parameter definitions

Table B-1 Supported tunable parameters (continued)

Tunable Description

storage_connectivity (Veritas Volume Manager) The CVM storage

connectivity type. This tunable must be set
after Veritas Volume Manager is started.

usefssmartmove (Veritas Volume Manager) Configure

SmartMove feature (all, thinonly, none). This
tunable must be set after Veritas Volume
Manager is started.

vol_checkpt_default (Veritas File System) Size of VxVM storage

checkpoints (kBytes). This tunable requires a
system reboot to take effect.

vol_cmpres_enabled (Veritas Volume Manager) Allow enabling

compression for Volume Replicator.

vol_cmpres_threads (Veritas Volume Manager) Maximum number

of compression threads for Volume Replicator.

vol_default_iodelay (Veritas Volume Manager) Time to pause

between I/O requests from VxVM utilities
(10ms units). This tunable requires a system
reboot to take effect.

vol_fmr_logsz (Veritas Volume Manager) Maximum size of

bitmap Fast Mirror Resync uses to track
changed blocks (KBytes). This tunable
requires a system reboot to take effect.

vol_max_adminio_poolsz (Veritas Volume Manager) Maximum amount

of memory used by VxVM admin I/O's (bytes).
This tunable requires a system reboot to take
effect.

vol_max_nmpool_sz (Veritas Volume Manager) Maximum name

pool size (bytes).

vol_max_rdback_sz (Veritas Volume Manager) Storage Record

readback pool maximum (bytes).

vol_max_wrspool_sz (Veritas Volume Manager) Maximum memory

used in clustered version of Volume Replicator
.
 Tunable files for installation 96
Tunables value parameter definitions

Table B-1 Supported tunable parameters (continued)

Tunable Description

vol_maxio (Veritas Volume Manager) Maximum size of

logical VxVM I/O operations (kBytes). This
tunable requires a system reboot to take effect.

vol_maxioctl (Veritas Volume Manager) Maximum size of

data passed into the VxVM ioctl calls (bytes).
This tunable requires a system reboot to take
effect.

vol_maxparallelio (Veritas Volume Manager) Number of I/O

operations vxconfigd can request at one time.
This tunable requires a system reboot to take
effect.

vol_maxspecialio (Veritas Volume Manager) Maximum size of

a VxVM I/O operation issued by an ioctl call
(kBytes). This tunable requires a system
reboot to take effect.

vol_min_lowmem_sz (Veritas Volume Manager) Low water mark for

memory (bytes).

vol_nm_hb_timeout (Veritas Volume Manager) Volume Replicator

timeout value (ticks).

vol_rvio_maxpool_sz (Veritas Volume Manager) Maximum memory

requested by Volume Replicator (bytes).

vol_stats_enable (Veritas Volume Manager) Enable VxVM I/O

stat collection.

vol_subdisk_num (Veritas Volume Manager) Maximum number

of subdisks attached to a single VxVM plex.
This tunable requires a system reboot to take
effect.

voldrl_max_drtregs (Veritas Volume Manager) Maximum number

of dirty VxVM regions. This tunable requires
a system reboot to take effect.

voldrl_max_seq_dirty (Veritas Volume Manager) Maximum number

of dirty regions in sequential mode. This
tunable requires a system reboot to take effect.
 Tunable files for installation 97
Tunables value parameter definitions

Table B-1 Supported tunable parameters (continued)

Tunable Description

voldrl_min_regionsz (Veritas Volume Manager) Minimum size of a

VxVM Dirty Region Logging (DRL) region
(kBytes). This tunable requires a system
reboot to take effect.

voldrl_volumemax_drtregs (Veritas Volume Manager) Max per volume

dirty regions in log-plex DRL.

voldrl_volumemax_drtregs_20 (Veritas Volume Manager) Max per volume

dirty regions in DCO version 20.

voldrl_dirty_regions (Veritas Volume Manager) Number of regions

cached for DCO version 30.

voliomem_chunk_size (Veritas Volume Manager) Size of VxVM

memory allocation requests (bytes). This
tunable requires a system reboot to take effect.

voliomem_maxpool_sz (Veritas Volume Manager) Maximum amount

of memory used by VxVM (bytes). This tunable
requires a system reboot to take effect.

voliot_errbuf_dflt (Veritas Volume Manager) Size of a VxVM

error trace buffer (bytes). This tunable requires
a system reboot to take effect.

voliot_iobuf_default (Veritas Volume Manager) Default size of a

VxVM I/O trace buffer (bytes). This tunable
requires a system reboot to take effect.

voliot_iobuf_limit (Veritas Volume Manager) Maximum total size

of all VxVM I/O trace buffers (bytes). This
tunable requires a system reboot to take effect.

voliot_iobuf_max (Veritas Volume Manager) Maximum size of

a VxVM I/O trace buffer (bytes). This tunable
requires a system reboot to take effect.

voliot_max_open (Veritas Volume Manager) Maximum number

of VxVM trace channels available for vxtrace
commands. This tunable requires a system
reboot to take effect.

volpagemod_max_memsz (Veritas Volume Manager) Maximum paging

module memory used by Instant Snapshots
(Kbytes).
 Tunable files for installation 98
Tunables value parameter definitions

Table B-1 Supported tunable parameters (continued)

Tunable Description

volraid_rsrtransmax (Veritas Volume Manager) Maximum number

of VxVM RAID-5 transient reconstruct
operations in parallel. This tunable requires a
system reboot to take effect.

vx_bc_bufhwm (Veritas File System) VxFS metadata buffer

cache high water mark. This tunable requires
a system reboot to take effect.

vxfs_ninode (Veritas File System) Number of entries in the

VxFS inode table. This tunable requires a
system reboot to take effect.

write_nstream (Veritas File System) The number of parallel

write requests of size write_pref_io that can
be outstanding at one time. The installer can
only set the system default value of
write_nstream. Refer to the tunefstab(4)
manual page for setting this tunable for a
specified block device.

write_pref_io (Veritas File System) The preferred write

request size. The installer can only set the
system default value of write_pref_io. Refer
to the tunefstab(4) manual page for setting
this tunable for a specified block device.
 Appendix C
Troubleshooting
installation issues
This appendix includes the following topics:

■ Restarting the installer after a failed network connection

■ Troubleshooting an installation on AIX

■ Incorrect permissions for root on remote system

■ Resource temporarily unavailable

■ Inaccessible system

Restarting the installer after a failed network

connection
If an installation is aborted because of a failed network connection, restarting the
installer will detect the previous installation. The installer prompts to resume the
installation. If you choose to resume the installation, the installer proceeds from the
point where the installation aborted. If you choose not to resume, the installation
starts from the beginning.

Troubleshooting an installation on AIX

Save a copy of /var/adm/ras/errtmplt and /etc/trcfmt files before you install
the product. If the filesets fail to install due to the template file is corrupted
error message, replace /var/adm/ras/errtmplt file and /etc/trcfmt file with the
ones that you had saved, uninstall all the filesets installed.
See “Preparing to uninstall a InfoScale product” on page 66.
 Troubleshooting installation issues 100
Incorrect permissions for root on remote system

Then reinstall.

Incorrect permissions for root on remote system

The permissions are inappropriate. Make sure you have remote root access
permission on each system to which you are installing.

Failed to setup rsh communication on 10.198.89.241:

'rsh 10.198.89.241 <command>' failed
Trying to setup ssh communication on 10.198.89.241.
Failed to setup ssh communication on 10.198.89.241:
Login denied

Failed to login to remote system(s) 10.198.89.241.

Please make sure the password(s) are correct and superuser(root)
can login to the remote system(s) with the password(s).
If you want to setup rsh on remote system(s), please make sure
rsh with command argument ('rsh <host> <command>') is not
denied by remote system(s).

Either ssh or rsh is needed to be setup between the local node

and 10.198.89.241 for communication

Would you like the installer to setup ssh/rsh communication

automatically between the nodes?
Superuser passwords for the systems will be asked. [y,n,q] (y) n

System verification did not complete successfully

The following errors were discovered on the systems:

The ssh permission denied on 10.198.89.241

rsh exited 1 on 10.198.89.241
either ssh or rsh is needed to be setup between the local node
and 10.198.89.241 for communication

Suggested solution: You need to set up the systems to allow remote access using
ssh or rsh.

Note: Remove remote shell permissions after completing the InfoScale installation
and configuration.
 Troubleshooting installation issues 101
Resource temporarily unavailable

Resource temporarily unavailable

If the installation fails with the following error message on the console:

fork() failed: Resource temporarily unavailable

The value of maximum number of processes allowed per user may not be large
enough. This kernel attribute is a tunable and can be changed on any node of the
cluster.
To determine the current value of "Maximum number of PROCESSES allowed per
user", enter:

# lsattr -H -E -l sys0 -a maxuproc

To see the default value of this tunable and its valid range of values, enter:

# odmget -q "attribute=maxuproc" PdAt

If necessary, you can change the value of the tunable using the smitty interface:

# smitty chgsys

You can also directly change the CuAt class using the following command:

# chdev -l sys0 -a maxuproc=600

Increasing the value of the parameter takes effect immediately; otherwise the change
takes effect after a reboot.
See the smitty and chdev manual pages.

Inaccessible system
The system you specified is not accessible. This could be for a variety of reasons
such as, the system name was entered incorrectly or the system is not available
over the network.

Verifying systems: 12% ....................................

Estimated time remaining: 0:10 1 of 8
Checking system communication .............................. Done
System verification did not complete successfully
The following errors were discovered on the systems:
cannot resolve hostname host1
Enter the AIX system names separated by spaces: q,? (host1)
 Troubleshooting installation issues 102
Inaccessible system

Suggested solution: Verify that you entered the system name correctly; use the
ping(1M) command to verify the accessibility of the host.