Veritas Access Administrator's Guide
- Section I. Introducing Veritas Access
- Section II. Configuring Veritas Access
- Adding users or roles
- Configuring the network
- Configuring authentication services
- Section III. Managing Veritas Access storage
- Configuring storage
- 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
- Setting up Kerberos authentication for NFS clients
- Using Veritas Access as a CIFS server
- About Active Directory (AD)
- About configuring CIFS for Active Directory (AD) domain mode
- About setting trusted domains
- About managing home directories
- About CIFS clustering modes
- About migrating CIFS shares and home directories
- About managing local users and groups
- Configuring an FTP server
- 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
- Considerations for creating a file system
- Modifying a file system
- Managing a file system
- Creating and maintaining file systems
- Section VII. Configuring cloud storage
- Section VIII. Provisioning and managing Veritas Access shares
- Creating shares for applications
- Creating and maintaining NFS shares
- Creating and maintaining CIFS shares
- Using Veritas Access with OpenStack
- Integrating Veritas Access with Data Insight
- Section IX. Managing Veritas Access storage services
- Compressing files
- About compressing files
- Compression tasks
- Configuring SmartTier
- Configuring SmartIO
- Configuring episodic replication
- Episodic replication job failover and failback
- Configuring continuous replication
- How Veritas Access continuous replication works
- Continuous replication failover and failback
- Using snapshots
- Using instant rollbacks
- Compressing files
- Section X. Reference
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_access
directory 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.conf
file 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.conf
file 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.xml
file 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.xml
file.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.xml
file 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_ISCSI
back-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)]#