InfoScale™ Operations Manager 9.0 User's Guide
- Section I. Getting started
- Introducing Arctera InfoScale Operations Manager
- Using the Management Server console
- About selecting the objects
- About searching for objects
- Examples for using Arctera InfoScale Operations Manager
- Example: Cluster Server troubleshooting using Arctera InfoScale Operations Manager
- Example: Ensuring the correct level of protection for volumes controlled by Storage Foundation
- Example: Improving the availability and the disaster recovery readiness of a service group through fire drills
- Examples: Identifying and reducing storage waste using Arctera InfoScale Operations Manager
- Section II. Managing Arctera InfoScale Operations Manager
- Managing user access
- Creating an Organization
- Modifying the name of an Organization
- Setting up fault monitoring
- Creating rules in a perspective
- Editing rules in a perspective
- Deleting rules in a perspective
- Enabling rules in a perspective
- Disabling rules in a perspective
- Suppressing faults in a perspective
- Using reports
- Running a report
- Subscribing for a report
- Sending a report through email
- Managing user access
- Section III. Managing hosts
- Overview
- Working with the uncategorized hosts
- Managing File Replicator (VFR) operations
- Managing disk groups and disks
- Creating disk groups
- Importing disk groups
- Adding disks to disk groups
- Resizing disks in disk groups
- Renaming disks in disk groups
- Splitting disk groups
- Moving disk groups
- Joining disk groups
- Initializing disks
- Replacing disks
- Recovering disks
- Bringing disks online
- Setting disk usage
- Evacuating disks
- Running or scheduling Trim
- Managing volumes
- Creating Storage Foundation volumes
- Encrypting existing volumes
- Deleting volumes
- Moving volumes
- Renaming volumes
- Adding mirrors to volumes
- Removing the mirrors of volumes
- Creating instant volume snapshots
- Creating space optimized snapshots for volumes
- Creating mirror break-off snapshots for volumes
- Dissociating snapshots
- Reattaching snapshots
- Resizing volumes
- Restoring data from the snapshots of volumes
- Refreshing the snapshot of volumes
- Configuring a schedule for volume snapshot refresh
- Adding snapshot volumes to a refresh schedule
- Removing the schedule for volume snapshot refresh
- Setting volume usage
- Enabling FastResync on volumes
- Managing file systems
- Creating file systems
- Defragmenting file systems
- Unmounting non clustered file systems from hosts
- Mounting non clustered file systems on hosts
- Unmounting clustered file systems
- Mounting clustered file systems on hosts
- Remounting file systems
- Checking file systems
- Creating file system snapshots
- Remounting file system snapshot
- Mounting file system snapshot
- Unmounting file system snapshot
- Removing file system snapshot
- Monitoring capacity of file systems
- Managing SmartIO
- About managing SmartIO
- Creating a cache
- Modifying a cache
- Creating an I/O trace log
- Analyzing an I/O trace log
- Managing application IO thresholds
- Managing replications
- Configuring Storage Foundation replications
- Pausing the replication to a Secondary
- Resuming the replication of a Secondary
- Starting replication to a Secondary
- Stopping the replication to a Secondary
- Switching a Primary
- Taking over from an original Primary
- Associating a volume
- Removing a Secondary
- Monitoring replications
- Optimizing storage utilization
- Section IV. Managing high availability and disaster recovery configurations
- Overview
- Managing clusters
- Managing service groups
- Creating service groups
- Linking service groups in a cluster
- Bringing service groups online
- Taking service groups offline
- Switching service groups
- Managing systems
- Managing resources
- Invoking a resource action
- Managing global cluster configurations
- Running fire drills
- Running the disaster recovery fire drill
- Editing a fire drill schedule
- Using recovery plans
- Managing application configuration
- Multi Site Management
- Appendix A. List of high availability operations
- Section V. Monitoring Storage Foundation HA licenses in the data center
- Managing licenses
- About Arctera licensing and pricing
- Assigning a price tier to a host manually
- Creating a license deployment policy
- Modifying a license deployment policy
- Viewing deployment information
- Managing licenses
- Monitoring performance
- About Arctera InfoScale Operations Manager performance graphs
- Managing Business Applications
- About the makeBE script
- Managing extended attributes
- Managing policy checks
- About using custom signatures for policy checks
- Managing Dynamic Multipathing paths
- Disabling the DMP paths on the initiators of a host
- Re-enabling the DMP paths
- Managing CVM clusters
- Managing Flexible Storage Sharing
- Monitoring the virtualization environment
- About discovering the VMware Infrastructure using Arctera InfoScale Operations Manager
- About the multi-pathing discovery in the VMware environment
- About discovering Solaris zones
- About discovering logical domains in Arctera InfoScale Operations Manager
- About discovering LPARs and VIOs in Arctera InfoScale Operations Manager
- About Microsoft Hyper-V virtualization discovery
- Using Web services API
- Arctera InfoScale Operations Manager command line interface
- Appendix B. Command file reference
- Appendix C. Application setup requirements
- Application setup requirements for Oracle database discovery
- Application setup requirements for Oracle Automatic Storage Management (ASM) discovery
- Application setup requirements for IBM DB2 discovery
- Application setup requirements for Sybase Adaptive Server Enterprise (ASE) discovery
- Application setup requirements for Microsoft SQL Server discovery
About deduplication chunk size
The deduplication chunk size, which is also referred to as deduplication granularity, is the unit at which fingerprints are computed. A valid chunk size is between 4k and 128k and power of two. Once set, the only way to change the chunk size is to remove and re-enable deduplication on the file system.
You should carefully select the chunk size, as the size has significant impact on deduplication as well as resource requirements. The size directly affects the number of fingerprint records in the deduplication database as well as temporary space required for sorting these records. A smaller chunk size results in a large number of fingerprints and hence requires a significant amount of space for the deduplication database.
While the amount of storage that you save after deduplication depends heavily on the dataset and distribution of duplicates within the dataset, the chunk size can also affect the savings significantly. You must understand your dataset to get the best results after deduplication. A general rule of thumb is that a smaller chunk size saves more storage. A smaller chunk size results in more granular fingerprints and in general results in identifying more duplicates. However, smaller chunks have additional costs in terms of database size, deduplication time, and, more importantly, fragmentation. The deduplication database size can be significantly large for small chunk sizes. Higher fragmentation normally results in more file system metadata and hence can require more storage. The space consumed by the deduplication database and the increased file system metadata can reduce the savings achieved via deduplication. Additionally, fragmentation can also have a negative effect on performance. The Veritas File System (VxFS) deduplication algorithms try to reduce fragmentation by coalescing multiple contiguous duplicate chunks.
Larger chunk sizes normally result in a smaller deduplication database size, faster deduplication, and less fragmentation. These benefits sometimes come at the cost of less storage savings. If you have a large number duplicate files that are small in size, you still can choose a chunk size that is larger than the file size. A larger chunk size does not affect the deduplication of files that are smaller than the chunk size. In such cases, the fingerprint is calculated on the whole file, and the files are still deduplicated.
The space consumed by the deduplication database is a function of the amount of data in the file system and the deduplication chunk size. The space consumed by the deduplication database grows with time as new data is added to file system. Additional storage is required for temporary use, such as sorting fingerprints. The temporary storage may be freed after the work completes. Ensure that sufficient free space is available for deduplication to complete successfully. The deduplication might not start if the file system free space is less than approximately 15%. The deduplication sometimes needs more than 15% free space for smaller chunk sizes. In general, the space consumed reduces significantly with larger chunk sizes. Arctera recommends that you have approximately 20% free space for 4k chunks.