Best practices for using ILM with FabricPool data
-
PDF of this doc site
-
Install and upgrade
-
Configure and manage
-
Maintain
-
Recover nodes and maintain your grid
-
-
![](https://docs.netapp.com/common/images/pdf-zip.png)
Collection of separate PDF docs
Creating your file...
If you are using FabricPool to tier data to StorageGRID, you must understand the requirements for using StorageGRID information lifecycle management (ILM) with FabricPool data.
|
FabricPool has no knowledge of StorageGRID ILM rules or policies. Data loss can occur if the StorageGRID ILM policy is misconfigured. For detailed information, see Create an ILM rule: Overview and Create an ILM policy: Overview. |
Guidelines for using ILM with FabricPool
When you use the FabricPool setup wizard, the wizard automatically creates a new ILM rule for each S3 bucket you create, adds that rule to a proposed policy, and prompts you to activate the new policy as part of completing the wizard. The automatically created rule follows the recommended best practices: it uses 2+1 erasure coding at a single site.
If you are configuring StorageGRID manually instead of using the FabricPool setup wizard, review these guidelines to ensure that your ILM rules and ILM policy are suitable for FabricPool data and your business requirements. You might need to create new rules and update your active ILM policy to meet these guidelines.
-
You can use any combination of replication and erasure-coding rules to protect cloud tier data.
The recommended best practice is to use 2+1 erasure coding within a site for cost-efficient data protection. Erasure coding uses more CPU, but offers significantly less storage capacity, than replication. The 4+1 and 6+1 schemes use less capacity than the 2+1 scheme. However, the 4+1 and 6+1 schemes are less flexible if you need to add Storage Nodes during grid expansion. For details, see Add storage capacity for erasure-coded objects.
-
Each rule applied to FabricPool data must either use erasure coding or it must create at least two replicated copies.
An ILM rule that creates only one replicated copy for any time period puts data at risk of permanent loss. If only one replicated copy of an object exists, that object is lost if a Storage Node fails or has a significant error. You also temporarily lose access to the object during maintenance procedures such as upgrades. -
If you need to remove FabricPool data from StorageGRID, use ONTAP to retrieve all data for the FabricPool volume and promote it to the performance tier.
To avoid data loss, do not use an ILM rule that will expire or delete FabricPool cloud tier data. Set the retention period in each ILM rule to forever to ensure that FabricPool objects aren't deleted by StorageGRID ILM. -
Don't create rules that will move FabricPool cloud tier data out of the bucket to another location. You can't use a Cloud Storage Pool to move FabricPool data to another object store. Similarly, you can't archive FabricPool data to tape using an Archive Node.
Using Cloud Storage Pools with FabricPool is not supported because of the added latency to retrieve an object from the Cloud Storage Pool target. -
Starting with ONTAP 9.8, you can optionally create object tags to help classify and sort tiered data for easier management. For example, you can set tags only on FabricPool volumes attached to StorageGRID. Then, when you create ILM rules in StorageGRID, you can use the Object Tag advanced filter to select and place this data.