CTERA Portal can write your data to storage nodes from many different vendors. The Storage Nodes page in the global administration view enables you to easily add new storage nodes, dedicate storage nodes to virtual portals, stop and start writing to different storage nodes, and migrate data seamlessly from one storage node to another storage node.
Note
CTERA recommends that whenever you create a new S3 bucket to use as the backend storage for a storage node, you enable object lock when creating the bucket and disable the default retention. For most S3 buckets, after the bucket is populated with content, you cannot set object lock. With AWS S3 buckets, you can set object lock after the bucket is populated with content.
What Storage Node to Use
Storage considerations include company policy, cost, and total size required.
CTERA provides a storage node with the installation, Local Filesystem, which can be used up to a maximum of 20TB.
NFS storage, EMC Isilon (NFS), Generic (NFS), and NetApp (NFS), storage nodes can be used for storage up to 100TB.
All other storage nodes, such as Amazon S3 and IBM Cloud Object Storage (S3), support unlimited storage.
Using Multiple Storage Nodes
You can define multiple storage nodes. When there are multiple storage nodes, CTERA manages the writes so that the nodes are balanced in the following cases:
When multiple storage nodes are defined that are not dedicated to specific virtual portals. If a storage node is down, data is not written to that node, but to the other storage nodes that are up.
When multiple storage nodes are dedicated to the same virtual portal. If a storage node dedicated to the virtual portal is down, data is not written to that node, but to the other storage nodes dedicated to the same virtual portal, that are up.
Notes
Each block is written to a single storage node. If you want the same block to be written to another location, you have to use the storage provider functionality, such as Amazon Cross-Region Replication (CRR).
When there are storage nodes of different types, for example, Amazon S3 and Microsoft Azure Blob Storage, a block from a single file can be written to one storage node while another block from the same file is written to another storage node of a different type.
Grouping Storage Nodes: Cloud Storage Routing
Cloud storage routing uses storage classes, which represent a group of one or more storage nodes that share a similar business requirement, such as location. For example, a storage class can consist of a number of storage nodes all in the same location. Each cloud folder group can be assigned to a storage class to enable the cloud folder group content to be written to a specific storage node.
Storage classes can be used to provide the following main benefits:
Data sovereignty (GDPR)
Cost savings
Business efficiency
Data Sovereignty
Data sovereignty has become critical as strict rules dictate where data is stored and how it is moved, including differing laws and regulations across countries and regions. With CTERA Cloud Storage Routing, organizations can maintain data sovereignty, as well as compliance with GDPR and other regulations.
Cost Savings
By being able to select the cloud provider that exists nearest where the data creation is, huge cost savings can be achieved. Also, you can configure the routing to ensure that folder group content that is not accessed regularly, such as archived data, is always written to cheaper storage.
Business Efficiency
Your organization needs quick access to data in order to function efficiently. Until now, this has not always been possible, with data often stored in different places and especially when utilizing cloud data storage providers. CTERA Cloud Storage Routing provides low-latency access to data, ensuring that your teams always have access to the data they need.
The team portal administrator can define cloud folder groups to write to a specific storage class, optimizing use of that cloud folder group with one or more of the benefits outlined above.
Storage classes are defined using CLI. The storage nodes are assigned initially to a default storage class. The storage class can be changed from the default when the storage node is defined. After the storage node is defined the storage class cannot be changed.
Defining a Storage Class
Storage classes are defined using CLI. To run the CLI from the portal user interface, see Execute CLI Commands from the Global Administrator User Interface. Use the following CLI to create a storage class: add /storageClasses/ name <name>
where <name> is the name you call the storage class.
Assigning a Storage Class to a Storage Node
After defining the storage class, as described above in Defining a Storage Class, you can assign it to a specific storage node as part of the general storage node definition, described in Adding and Editing Storage Nodes
Changing the Name of a Storage Class
After defining a storage class, as described above in Defining a Storage Class, you can change the name using the following CLI: set /storageClasses/<currentSCName>/ name <newSCName> where <currentSCName> is the name of the storage class to change and <newSCName> is the name to change it to.
Object Lock Support: WORM Propagation
CTERA supports the seamless propagation of the portal cloud folder compliance settings to an S3 bucket, for all files in the cloud folder, extending protection from the application level through to the block-level on the storage.
Notes
CTERA recommends that whenever you create a new S3 bucket to use as the backend storage for a storage node, you enable object lock when creating the bucket and disable default retention. For most S3 buckets, after the bucket is populated with content, you cannot set object lock. With AWS S3 buckets, you can set object lock after the bucket is populated with content.
For CTERA Object Lock support, object lock must be enabled on the S3 bucket and the retention mode for the bucket must be disabled.
As long as the cloud folders that will write to the bucket have compliance set, as described in Folder (WORM) Compliance: CTERA Vault, setting object lock on the S3 bucket ensures the following:
Files within dedicated WORM folders are immutable, preventing any modifications or deletions once written.
Retention settings are automatically propagated to the S3 bucket.
Customizable retention periods can be set for files within dedicated WORM folders.
Notes
Object locking is supported for S3 buckets with governance (enterprise) retention mode, both on-premise and in the cloud. S3 buckets with compliance retention mode only are not supported.
The following storage nodes support object locking: Amazon (S3), Hitachi Vantara HCP (S3).
The following tables shows the different scenarios and their outcomes when setting Use S3 Object Lock on a storage node.
When Use S3 Object Lock flag is checked for the storage node
Object lock set on the S3 bucket | Default retention set on the S3 bucket | Result | Notes |
|---|---|---|---|
Yes | No | Folder compliance is set on all objects written to the bucket | – |
Yes | Yes | Bucket cannot be accessed | Unset the bucket default retention policy |
No | – | Bucket cannot be accessed | Either uncheck Use S3 Object Lock for the storage node unless the storage node is Amazon (S3), in which case, set the object lock on the bucket and disable default retention. |
When Use S3 Object Lock flag is unchecked for the storage node
Object lock set on the S3 bucket | Default retention set on the S3 bucket | Result | Notes |
|---|---|---|---|
Yes | Yes | Bucket retention policy is applied to all the objects written to the bucket | – |
Yes | No | No bucket retention policy is applied to the objects written to the bucket | – |
No | – | No bucket retention policy is applied to the objects written to the bucket | – |
When Use S3 Object Lock flag status changed for the storage node
Use S3 Object Lock setting | Object lock set on the S3 bucket | Default retention set on the S3 bucket | Result | Notes |
|---|---|---|---|---|
Checked and then unchecked at a later date | Yes | No | All objects written before Use S3 Object Lock was unchecked keep their folder compliance settings. New writes are written to the bucket without a retention policy being applied. | – |
Unchecked and then checked at a later date | Yes | Yes | Bucket cannot be accessed | Either uncheck Use S3 Object Lock for the storage node or disable default retention. |
Unchecked and then checked at a later date | Yes | No | Retroactively apply the folder compliance settings on all the bucket objects. | – |