Veritas Access Administrator's Guide
- Section I. Introducing Veritas Access
- Section II. Configuring Veritas Access
- Adding users or roles
- Configuring the network
- About configuring the Veritas Access network
- About bonding Ethernet interfaces
- Bonding Ethernet interfaces
- Configuring DNS settings
- About Ethernet interfaces
- Displaying current Ethernet interfaces and states
- Configuring IP addresses
- Configuring Veritas Access to use jumbo frames
- Configuring VLAN interfaces
- Configuring NIC devices
- Swapping network interfaces
- Excluding PCI IDs from the cluster
- About configuring routing tables
- Configuring routing tables
- Changing the firewall settings
- IP load balancing
- Configuring Veritas Access in IPv4 and IPv6 mixed mode
- Configuring authentication services
- Section III. Managing Veritas Access storage
- Configuring storage
- About storage provisioning and management
- About configuring disks
- About configuring storage pools
- Configuring storage pools
- About quotas for usage
- Enabling, disabling, and displaying the status of file system quotas
- Setting and displaying file system quotas
- Setting user quotas for users of specified groups
- About quotas for CIFS home directories
- About Flexible Storage Sharing
- Limitations of Flexible Storage Sharing
- Workflow for configuring and managing storage using the Veritas Access CLI
- Displaying information for all disk devices associated with the nodes in a cluster
- Displaying WWN information
- Importing new LUNs forcefully for new or existing pools
- Initiating host discovery of LUNs
- Increasing the storage capacity of a LUN
- Formatting or reinitializing a disk
- Removing a disk
- Configuring data integrity with I/O fencing
- Configuring ISCSI
- Veritas Access as an iSCSI target
- Configuring storage
- Section IV. Managing Veritas Access file access services
- Configuring the NFS server
- About using the NFS server with Veritas Access
- Using the kernel-based NFS server
- Accessing the NFS server
- Displaying and resetting NFS statistics
- Configuring Veritas Access for ID mapping for NFS version 4
- Configuring the NFS client for ID mapping for NFS version 4
- About authenticating NFS clients
- Setting up Kerberos authentication for NFS clients
- Using Veritas Access as a CIFS server
- About configuring Veritas Access for CIFS
- About configuring CIFS for standalone mode
- Configuring CIFS server status for standalone mode
- Changing security settings
- About Active Directory (AD)
- About configuring CIFS for Active Directory (AD) domain mode
- Setting NTLM
- About setting trusted domains
- Specifying trusted domains that are allowed access to the CIFS server
- Allowing trusted domains access to CIFS when setting an IDMAP backend to rid
- Allowing trusted domains access to CIFS when setting an IDMAP backend to ldap
- Allowing trusted domains access to CIFS when setting an IDMAP backend to hash
- Allowing trusted domains access to CIFS when setting an IDMAP backend to ad
- About configuring Windows Active Directory as an IDMAP backend for CIFS
- Configuring the Active Directory schema with CIFS-schema extensions
- Configuring the LDAP client for authentication using the CLI
- Configuring the CIFS server with the LDAP backend
- Setting Active Directory trusted domains
- About storing account information
- Storing user and group accounts
- Reconfiguring the CIFS service
- About mapping user names for CIFS/NFS sharing
- About the mapuser commands
- Adding, removing, or displaying the mapping between CIFS and NFS users
- Automatically mapping UNIX users from LDAP to Windows users
- About managing home directories
- About CIFS clustering modes
- About migrating CIFS shares and home directories
- Setting the CIFS aio_fork option
- About managing local users and groups
- Enabling CIFS data migration
- Configuring an FTP server
- About FTP
- Creating the FTP home directory
- Using the FTP server commands
- About FTP server options
- Customizing the FTP server options
- Administering the FTP sessions
- Uploading the FTP logs
- Administering the FTP local user accounts
- About the settings for the FTP local user accounts
- Configuring settings for the FTP local user accounts
- Using Veritas Access as an Object Store server
- Configuring the NFS server
- Section V. Monitoring and troubleshooting
- Section VI. Provisioning and managing Veritas Access file systems
- Creating and maintaining file systems
- About creating and maintaining file systems
- About encryption at rest
- Considerations for creating a file system
- Best practices for creating file systems
- Choosing a file system layout type
- Determining the initial extent size for a file system
- About striping file systems
- About creating a tuned file system for a specific workload
- About FastResync
- About fsck operation
- Setting retention in files
- Setting WORM over NFS
- Manually setting WORM-retention on a file over CIFS
- About managing application I/O workloads using maximum IOPS settings
- Creating a file system
- Bringing the file system online or offline
- Listing all file systems and associated information
- Modifying a file system
- Managing a file system
- Destroying a file system
- Upgrading disk layout versions
- Creating and maintaining file systems
- Section VII. Provisioning and managing Veritas Access shares
- Creating shares for applications
- Creating and maintaining NFS shares
- About NFS file sharing
- Displaying file systems and snapshots that can be exported
- Exporting an NFS share
- Displaying exported directories
- About managing NFS shares using netgroups
- Unexporting a directory or deleting NFS options
- Exporting an NFS share for Kerberos authentication
- Mounting an NFS share with Kerberos security from the NFS client
- Exporting an NFS snapshot
- Creating and maintaining CIFS shares
- About managing CIFS shares
- Exporting a directory as a CIFS share
- Configuring a CIFS share as secondary storage for an Enterprise Vault store
- Exporting the same file system/directory as a different CIFS share
- About the CIFS export options
- Setting share properties
- Displaying CIFS share properties
- Hiding system files when adding a CIFS normal share
- Allowing specified users and groups access to the CIFS share
- Denying specified users and groups access to the CIFS share
- Exporting a CIFS snapshot
- Deleting a CIFS share
- Modifying a CIFS share
- Making a CIFS share shadow copy aware
- Using Veritas Access with OpenStack
- Integrating Veritas Access with Data Insight
- Section VIII. Managing Veritas Access storage services
- Compressing files
- About compressing files
- Use cases for compressing files
- Best practices for using compression
- Compression tasks
- Compressing files
- Showing the scheduled compression job
- Scheduling compression jobs
- Listing compressed files
- Uncompressing files
- Modifying the scheduled compression
- Removing the specified schedule
- Stopping the schedule for a file system
- Removing the pattern-related rule for a file system
- Removing the modified age related rule for a file system
- Configuring episodic replication
- About Veritas Access episodic replication
- How Veritas Access episodic replication works
- Starting Veritas Access episodic replication
- Setting up communication between the source and the destination clusters
- Setting up the file systems to replicate
- Setting up files to exclude from an episodic replication unit
- Scheduling the episodic replication
- Defining what to replicate
- About the maximum number of parallel episodic replication jobs
- Managing an episodic replication job
- Replicating compressed data
- Displaying episodic replication job information and status
- Synchronizing an episodic replication job
- Behavior of the file systems on the episodic replication destination target
- Accessing file systems configured as episodic replication destinations
- Episodic replication job failover and failback
- Configuring continuous replication
- About Veritas Access continuous replication
- How Veritas Access continuous replication works
- Starting Veritas Access continuous replication
- Setting up communication between the source and the target clusters
- Setting up the file system to replicate
- Managing continuous replication
- Displaying continuous replication information and status
- Unconfiguring continuous replication
- Continuous replication failover and failback
- Using snapshots
- Using instant rollbacks
- About instant rollbacks
- Creating a space-optimized rollback
- Creating a full-sized rollback
- Listing Veritas Access instant rollbacks
- Restoring a file system from an instant rollback
- Refreshing an instant rollback from a file system
- Bringing an instant rollback online
- Taking an instant rollback offline
- Destroying an instant rollback
- Creating a shared cache object for Veritas Access instant rollbacks
- Listing cache objects
- Destroying a cache object of a Veritas Access instant rollback
- Compressing files
- Section IX. Reference
- Index
Configuring OpenStack Cinder
To copy a Cinder driver from Veritas Access to an OpenStack Cinder node
- Browse to the location of the Cinder driver on Veritas Access:
/opt/VRTSnas/pysnas/openstack/
- Copy the complete
veritas_accessdirectory from the driver location on Veritas Access to the Cinder node:/usr/lib/python2.7/site-packages/cinder/volume/drivers/
To create a new backend volume called ACCESS_ISCSI in OpenStack Cinder
- Add the following configurations in the
/etc/cinder/cinder.conffile on your OpenStack controller node.enabled_backends= va-iscsi [va-iscsi] volume_driver = cinder.volume.drivers.veritas_access.veritas_iscsi.ACCESSIscsiDriver volume_backend_name = ACCESS_ISCSI iscsi_protocol = iscsi reserved_percentage = 0 vrts_iscsi_port = 3260 vrts_lun_sparse = false vrts_target_config = /etc/cinder/vrts_target.xml vrts_server_ip = 10.182.168.90 vrts_port = 14161 vrts_user = <master_user>
You can obtain the configuration details for adding to the
/etc/cinder/cinder.conffile by executing the following command:Openstack> cinder iscsi configure <target_list>
Note:
To create a sparse LUN, you need to set the vrts_lun_sparse option to true.
- Append the following to the
/etc/cinder/vrts_target.xmlfile on your OpenStack controller node:<?xml version="1.0" ?> <VRTS> <VrtsTargets> <Target> <Name>iqn.2018-02.com.veritas:target02 <PortalIP>10.182.174.189 <Authentication>0 </Target> </VrtsTargets> </VRTS>If authentication is used for the target, the user name and password should to be mentioned in the
/etc/cinder/ vrts_target.xmlfile.Example:
<?xml version="1.0" ?> <VRTS> <VrtsTargets> <Target> <Name>iqn.2018-02.com.veritas:target02 <PortalIP>10.182.174.189 <Authentication>1 <Auth_username>user1 <Auth_password>user123 </Target> </VrtsTargets> </VRTS>Note:
Make sure that every target added to the
/etc/cinder/vrts_target.xmlfile is in the online state in Veritas Access. - Restart the Cinder volume and Cinder scheduler services by using the following commands:
service openstack-cinder-volume restart service openstack-cinder-scheduler restart
- On the OpenStack controller node, create a volume type such as
vrts_vol_type.This volume type is used to link to the volume backend.
[root@openstack01 ~(keystone_admin)]# cinder type-create vrts_vol_type +--------------------------------------+------------------+ | ID | Name | +--------------------------------------+------------------| | d854a6ad-63bd-42fa-8458-a1a4fadd04b7 | vrts_vol_type | +--------------------------------------+------------------+
- Link the volume type with the
ACCESS_ISCSIback-end.[root@openstack01 ~(keystone_admin)]# cinder type-key vrts_vol_type set volume_backend_name= ACCESS_ISCSI [root@openstack01 ~(keystone_admin)]# cinder create --volume-type vrts_vol_type --display-name vol1 1 +--------------------------------+--------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2018-02-27T14:56:57.000000 | | description | None | | encrypted | False | | id | 4964b42a-896c-4bf1-bd4e-326671d2171d | | metadata | {} | | migration_status | None | | multiattach | False | | name | vol1 | | os-vol-host-attr:host | None | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 9822b2763c82400e9f597f0860e5a5cb | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | creating | | updated_at | None | | user_id | 79cf5163433d46788bf124b918fa16f9 | | volume_type | vrts_vol_type | +--------------------------------+--------------------------------------+ [root@openstack01 ~(keystone_admin)]#Note:
You can create individual volumes by using the following command: cinder create --volume-type vrts_vol_type --display-name vol1 --metadata dense=True 2
- Extend the volume to 2 GB.
[root@openstack01 ~(keystone_admin)]# cinder extend vol1 2 [root@openstack01 ~(keystone_admin)]# [root@openstack01 ~(keystone_admin)]# cinder list +-----------------------+-----------+------+------+---------------+----------+-------------+ |ID | Status | Name | Size | Volume Type | Bootable | Attached to | +-----------------------+-----------+------+------+---------------+----------+-------------+ |4964b42a-896c- |4bf1-bd4e-326671d2171d | available | vol1 | 2 | vrts_vol_type | false | | +-----------------------+-----------+------+------+---------------+----------+-------------+ [root@openstack01 ~(keystone_admin)]#
- Create a snapshot.
[root@openstack01 ~(keystone_admin)]# cinder list +-----------------------+-----------+------+------+---------------+----------+-------------+ |ID | Status | Name | Size | Volume Type | Bootable | Attached to | +-----------------------+-----------+------+------+---------------+----------+-------------+ |4964b42a-896c- |4bf1-bd4e-326671d2171d | available | vol1 | 2 | vrts_vol_type | false | | +-----------------------+-----------+------+------+---------------+----------+-------------+ [root@openstack01 ~(keystone_admin)]# [root@openstack01 ~(keystone_admin)]# [root@openstack01 ~(keystone_admin)]# cinder snapshot-create --display-name vol1-snap vol1 +-------------+--------------------------------------+ | Property | Value | +-------------+--------------------------------------+ | created_at | 2018-02-27T14:59:54.424693 | | description | None | | id | 0e095ca8-bfa3-4d2a-a83d-e0de91ea0db2 | | metadata | {} | | name | vol1-snap | | size | 2 | | status | creating | | updated_at | None | | volume_id | 4964b42a-896c-4bf1-bd4e-326671d2171d | +-------------+--------------------------------------+ [root@openstack01 ~(keystone_admin)]#