Before you enable OSS-HDFS, understand how it interacts with other OSS features to prevent operational issues and data loss.
-
After you enable OSS-HDFS for a bucket, the service stores its data in the
.dlsdata/directory of the bucket. Do not perform write operations, such as renaming or deleting, on this directory or the objects within it except through OSS-HDFS. Such actions can disrupt the service or cause data loss. -
If issues affecting HDFS operations occur, such as overdue payments or the deletion of the dependent RAM role
AliyunOSSDlsDefaultRole, the HDFS background service may enter a safe mode. In this mode, all background tasks, such as audit logging, asynchronous deletion, and tiered storage, are paused. The service automatically resumes after these issues are resolved.
The following table describes the risks and considerations for operations on the.dlsdata/ directory after you enable OSS-HDFS.
|
Feature |
Risk |
Description |
References |
|
retention policy |
Data cannot be deleted |
We recommend that you do not enable OSS-HDFS and set a retention policy on the same bucket. If you do, deleting data from the |
|
|
lifecycle rule |
Data loss |
When you create or update a lifecycle rule for a bucket with OSS-HDFS enabled, use the
After you enable OSS-HDFS, if you need to manage the lifecycle of HDFS data, use thetiered storage feature provided by the service. |
|
|
versioning |
Data cannot be automatically deleted, service exceptions |
Do not enable OSS-HDFS and versioning on the same bucket. This combination can cause exceptions in the OSS-HDFS service. To ensure service stability, suspend versioning as soon as possible and configure a lifecycle rule to clean up delete markers. |
|
|
Delete directories |
Data loss |
To avoid disrupting the OSS-HDFS service or causing data loss, do not delete the |
|
|
Delete objects |
Data loss |
To avoid disrupting the OSS-HDFS service or causing data loss, do not delete any object from the |
|
|
Rename a directory |
Data loss |
To avoid disrupting the OSS-HDFS service or causing data loss, do not rename the |
|
|
Rename objects |
Data loss |
To avoid disrupting the OSS-HDFS service or causing data loss, do not rename any object in the |
|
|
Upload objects |
Data loss |
To avoid disrupting the OSS-HDFS service or causing data loss, do not upload objects to the |
|
|
Change the storage class of objects |
Data becomes inaccessible, billing rules change |
In an OSS-HDFS-enabled bucket, we recommend that you do not change the storage class of objects in the
Proceed with caution to avoid affecting data access or incurring extra costs. |
|
|
bucket policy |
Data becomes inaccessible, automatic deletion fails, and billing continues |
To ensure that OSS-HDFS can access the.dlsdata/ directory and its objects, do not create a bucket policy that includes a deny action. A deny policy will prevent OSS-HDFS from reading from or writing to the bucket. If you must configure a deny policy for security reasons, such as restricting access by IP address or VPC, you must add the following condition to all
|
|
|
RAM |
Data becomes inaccessible, automatic deletion fails, and billing continues |
When you enable OSS-HDFS for a bucket, a RAM role named |
|
|
bucket inventory |
Data contamination |
To avoid disrupting the OSS-HDFS service or causing data contamination, do not set the inventory report directory to |
|
|
logging |
Data contamination |
To avoid disrupting the OSS-HDFS service or causing data contamination, do not set the Log Prefix to |
|
|
zip package decompression |
Data contamination, data loss |
To avoid disrupting the OSS-HDFS service or causing data contamination and data loss, do not set the Destination Directory to |
OSS-HDFS uses an OSS bucket to store HDFS data and auxiliary data. This data is stored under the.dlsdata/ path in the bucket and consumes OSS storage capacity, which is metered and billed accordingly. For more information, see Storage capacity usage.
