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
Best practices for creating file systems
The following are the best practices for creating file systems:
Ensure all the disks (LUNs) in each storage pool have an identical hardware configuration.
Best performance results from a striped file system that spans similar disks. The more closely you match the disks by speed, capacity, and interface type, the better the performance you can expect. When striping across several disks of varying speeds, performance is no faster than that of the slowest disk.
Create striped file systems rather than simple file systems when creating your file systems.
In a given storage pool, create all the file systems with the same number of columns.
Ensure that the number of disks in each storage pool is an exact multiple of the number of columns used by the file systems created in that storage pool.
Consider how many disks you need to add to your storage pool to grow your striped file systems.
A 5-TB file system using five columns cannot be grown in a storage pool containing 8*1-TB disks, despite having 3 TB of disk space available. Instead create the file system with either four or eight columns, or else add 2*1-TB disks to the pool. See further examples in the table.
Use case
Action
Result
storage pool with eight disks of the same size (1 TB each)
Create a 5 TB striped file system with five columns.
You cannot grow the file system greater than 5 TB, even though there are three unused disks.
storage pool with eight disks of the same size (1 TB each)
Create a 5 TB striped file system with eight columns.
You can grow the file system to 8 TB.
storage pool with eight disks of the same size (1 TB each)
Create a 4 TB striped file system with four columns.
You can grow the file system to 8 TB.
storage pool with eight disks of the same size (1 TB each)
Create a 3 TB striped file system with three columns.
You cannot grow the file system to 8 TB.
storage pool with eight disks of the different sizes (3 are 500 GB each, and 5 are 2 TB each)
Create an 8 TB striped file system with eight columns.
You cannot create this 8-TB file system.
Consider the I/O bandwidth requirement when determining how many columns you require in your striped file system.
Based on the disks you have chosen, I/O throughput is limited and potentially restricted. Figure: LUN throughput - details on the LUN throughput restrictions describes the LUN throughput restrictions.
Consider populating each storage pool with the same number of disks from each HBA. Alternatively, consider how much of the total I/O bandwidth that the disks in the storage pool can use.
If you have more than one card or bus to which you can connect disks, distribute the disks as evenly as possible among them. That is, each card or bus must have the same number of disks attached to it. You can achieve the best I/O performance when you use more than one card or bus and interleave the stripes across them.
Use a stripe unit size larger than 64 KB. Performance tests show 512 KB as the optimal size for sequential I/O, which is the default value for the stripe unit. A greater stripe unit is unlikely to provide any additional benefit.
Do not change the operating system default maximum I/O size of 512 KB.
Veritas recommends that you do not create a file system whose name format is such as <file system name_integer>. This is because such file names are reserved for internal objects and may lead to file system creation errors.