NetApp StorageGRID对象存储集群中的某个Storage节点，其Distributed Data Store（DDS）服务出现LOST (Lost Object): Over 0警告。此警告表示该节点上校验出对象存在于当前元数据记录中，但实际不存在或不可读的情况。
1. SSH登陆到StorageGRID集群的Admin节点。
2. 切换至集群审计日志的保存路径：
NetApp StorageGRID对象存储集群针对每个租户使用的Bucket，在应用端发起S3请求（GET或PUT）时，可以设置一致性等级。通过配合StorageGRID的多副本机制，来确保数据的安全性及高可用性。针对不同的应用场景及副本保存需求，可以在Bucket上灵活调整这一参数。
要声明对象的一致性等级，需要在发起S3请求时添加x-ntap-sg-consistency标签。
PUT /bucket?x-ntap-sg-consistency=default HTTP/1.1 Date: Wed, 13 Feb 2019 16:39:17 GMT Authorization: AWS 9MOYPG9ACWPAJA1SXXXX:jUGbYkLdBApjCWBgK4TxvOjxxxx= Host: imno.one
HTTP/1.1 200 OK
Date: Wed, 13 Feb 2019 16:44:00 GMT
Connection: CLOSE
Server: StorageGRID/10.3.0
x-amz-request-id: 12345
Content-Length: 127
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<Consistency xmlns="http://s3.imno.one/demo/">default</Consistency>1. All提供最高的一致性保证。所有节点都会立即接收数据，否则请求失败
对于一个日常数据变化量较大的分布式存储服务集群（比如NetApp StorageGRID），其Cassandra元数据表SSTable中堆积大量过期数据是在所难免的。一般而言，当SSTable大小到达一定值时，便会自动触发元数据压缩任务，这个压缩操作会将标记为过期的key从SSTable中清理掉，进而释放可用空间。
随着数据量变化幅度的增加，有时会出现元数据压缩任务十分缓慢的情况。元数据压缩无法完成，便会影响所在节点的存储服务性能（因为压缩也会占用一定的I/O及CPU资源）。此时可以尝试通过孤立节点的方式，临时缓解元数据压缩速度。
1. 节点的整体存储服务性能下降
对于NetApp StorageGRID对象存储集群，如果单一节点上的对象数量过大时，可能导致Cassandra服务在执行元数据（metadata）压缩任务时Java可用内存不足的情况，进一步导致Cassandra服务频繁崩溃。
查询Server Manager日志，可以发现大量Cassandra服务重启记录：
2018-12-14 02:03:58 +0000 | cassandra | starting cassandra 2018-12-14 02:03:36 +0000 | cassandra | cassandra ended 2018-12-14 01:44:21 +0000 | cassandra | starting cassandra 2018-12-14 01:44:01 +0000 | cassandra | cassandra ended 2018-12-14 01:06:29 +0000 | cassandra | starting cassandra 2018-12-14 01:06:08 +0000 | cassandra | cassandra ended
查询Cassandra日志，可以发现大量Java内存溢出的Error错误：