Veritas Access Appliance Administrator's Guide
- Section I. Introducing Access Appliance
- Section II. Configuring Access Appliance
- Managing users
- Configuring the network
- Configuring authentication services
- Configuring user authentication using digital certificates or smart cards
- Section III. Managing Access Appliance storage
- Configuring storage
- Managing disks
- Access Appliance as an iSCSI target
- Configuring storage
- Section IV. Managing Access Appliance file access services
- Configuring the NFS server
- Setting up Kerberos authentication for NFS clients
- Using Access Appliance as a CIFS server
- 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
- Using Access Appliance as an Object Store server
- Configuring the NFS server
- Section V. Managing Access Appliance security
- Section VI. Monitoring and troubleshooting
- Configuring event notifications and audit logs
- About alert management
- Appliance log files
- Configuring event notifications and audit logs
- Section VII. Provisioning and managing Access Appliance file systems
- Creating and maintaining file systems
- Considerations for creating a file system
- About managing application I/O workloads using maximum IOPS settings
- Modifying a file system
- Managing a file system
- Creating and maintaining file systems
- Section VIII. Provisioning and managing Access Appliance shares
- Creating shares for applications
- Creating and maintaining NFS shares
- About the NFS shares
- Creating and maintaining CIFS shares
- About the CIFS shares
- About managing CIFS shares for Enterprise Vault
- Integrating Access Appliance with Data Insight
- Section IX. Managing Access Appliance storage services
- Configuring episodic replication
- Episodic replication job failover and failback
- Configuring continuous replication
- How Access Appliance continuous replication works
- Continuous replication failover and failback
- Using snapshots
- Using instant rollbacks
- Configuring episodic replication
- Section X. Reference
S3 with NFS use case
Access Appliance supports multi-protocol support for NFS with S3. If an NFS share is present (and objects may be present in the exported path), the storage admin can map that path as an S3 bucket (S3 over NFS). In addition, a normal file system path can also be mapped as an S3 bucket. The buckets created by S3 APIs cannot be exported as an NFS share (NFS over S3).
The path has the following characteristics:
Path is the absolute path inside a file system.
The name of the bucket is the name of the directory of the path which should be S3 compliant.
The path can be either NFS exported path or any directory in the normal file system. You cannot use the ObjectAccess file systems (file system having S3 bucket created by S3 APIs).
No other bucket should exist with the same name.
No other bucket should be present either inside or outside the given path. You can verify this using the following command:
objectaccess> bucket show
NFS share should not be present before or after that directory. You can verify using the following command:
NFS> share show
You can configure the cluster with any authentication server like AD/LDAP/NIS. Then, all the users present in the authentication server can be used as S3 users.
The S3 user should be authorized to access the S3 bucket (access key and secret key should be present for that user). You can verify using the following command:
objectaccess> account user show
See Configuring the Object Store server.
You can map the path to a bucket. The path can be either a directory inside a file system or an NFS-exported path. If the specified path is not present, then the map command creates the directory and sets the default S3 bucket permissions.
You can map the path to the S3 bucket for the user using the following command:
objectaccess> map <path> <user>
The storage admin can verify the bucket creation using the following command:
objectaccess> bucket show
The storage admin can use the NFS share at the same time when the S3 user uses the bucket. Existing objects inside the bucket retain the permissions set by the owner of those objects.
In multi-protocol case, an S3 user can delete the bucket without deleting all the objects. Deleting the bucket is equivalent to unmapping or unreferencing the bucket.
The following limitations apply for multi-protocol support:
An S3 user cannot access a bucket if the bucket ownership or permissions from the NFS client is changed.
Permissions that are set or modified from protocols like NFS are not honored by S3 and vice versa.
Object ETag is inaccurate whenever object is created or modified from the NFS client. An incorrect ETag is corrected when a GET or HEAD request is performed on the object.
Accessing the same object from different protocol in exclusive mode is not supported.