A content-archive platform needs to place objects on the new Data D…

Question

A content-archive platform needs to place objects on the new Data Domain using S3-style PUT operations against buckets. One engineer proposes carving out a CIFS share instead and having the platform's gateway drop files onto it, calling that close enough to object storage. What does the scenario actually require on the appliance side?

Accepted Answer

Recognize that the appliance does not serve S3 to clients — it speaks S3 only outbound, to Cloud Tier object storage — so the platform needs a real object store, or must write through NFS, CIFS, or DD Boost. — Don't go hunting for an S3 switch on your Data Domain — the box only talks S3 outward, to its Cloud Tier. Your archive platform either gets a genuine object store, or it writes through a protocol the appliance actually serves, like NFS, CIFS, or DD Boost. And a CIFS share isn't a bucket in disguise, so don't let anyone sell it as one.

Answer

Enable the appliance's built-in S3 object store service, create the bucket and the access keys, and point the platform at the object endpoint, since object connectivity is a service to switch on, not a share to fake.

Answer

A CIFS mount is functionally equivalent, since every object GET or PUT ultimately reduces to ordinary file reads and writes on some underlying share somewhere.

Answer

Present an iSCSI LUN for the platform to format and manage entirely on its own, because block storage hands an object store the most faithful low-level foundation on which to build its namespace, right down to deciding its own metadata layout.

Short Explanation

Full Explanation