Overview
In the previous post of this series we touched on different AWS storage options available with Cloud Volumes ONTAP (CVO) and how FabricPools allows you to leverage S3 storage, a lower cost option than EBS. How much lower? It depends on which S3 storage class you choose. In this post we’ll look at choosing storage classes from NetApp’s Cloud Manager, the management system and API endpoint for CVO. We’ll explore the method FabricPools uses to write to different S3 classes and we’ll show you how to work around a current Cloud Manager limitation* that prevents the selection of multiple S3 storage classes from a single CVO instance.
Cloud Manager
Cloud Manager is where a CVO deployment begins. You can create a Cloud Manager instance or access existing instances from NetApp’s Fabric View. Once Cloud Manager is up and running, it can be used to manually provision and manage CVO through a UI, or automate through its API. It can also be used to manage NetApp appliances on-prem and their replication relationships to the cloud.
Cloud Manager provides a more straightforward and easy to navigate interface when compared to ONTAP’s primary management interface, Systems Manager. For example, replication relationships are created with a simple drag and drop in Cloud Manager, where Systems Manager requires a multi-step process to create Cluster and SVM peers before replication can be setup. It also supports a subset of ONTAP functions such as volume and aggregate management, as well as snapshot and clone operations.
During CVO instance creation you can enable tiering to S3 and select which S3 Storage class to tier to. If you chose S3 standard but decided later to use S3 IA, it’s a simple point and click in Cloud Manager. But what if you want to use S3 standard for some data sets and S3 IA for others? There’s no point-n-click for that, but it is possible. Read on.
FabricPools and S3 Storage Classes
Before we dive into the how-to, let’s quickly examine how FabricPools supports different S3 storage classes. When Cloud Manager creates an instance with tiering enabled, it creates an S3 bucket with three lifecycle rules: IA, IA-Single and Intelligent.
When IA, One-Zone IA, or Intelligent Tiering is selected in Cloud Manager, the appropriate lifecycle rule is enabled. If the S3 Standard class is selected, they’re all disabled (as seen above).
Note: There’s an important cost implication here. Since FabricPools doesn’t write directly into the specified storage class and depends on lifecycle rules, all data must reside in the S3 Standard class for 30 days before it’s moved to the specified class. Be sure to factor this into your cost estimates.
FabricPools works at the aggregate level. Each aggregate can only have a single object-store configuration. This configuration includes the S3 bucket, auth method, port number, etc. Once a configuration is attached to an aggregate, it cannot be detached. Some config parameters can be changed, but the most important one, container-name (S3 bucket name), cannot be changed.
When a CVO instance is created from Cloud Manager, three things happen in AWS to enable S3 tiering:
- An S3 bucket is created in the same region as the instance.
- Lifecycle rules for each storage class are created on the bucket.
- An IAM policy permitting read-write access to the S3 bucket is attached to the IAM role that is attached to the CVO instance.
An object-store configuration applied to the default data aggregate (aggr1) and the three steps above result in a CVO instance that tiers to S3. To tier to another S3 storage class, we just need to conduct the same three steps, create a new object-store configuration, and create a new aggregate.
Create a New Aggregate with a Different S3 Storage Class
Start by creating an S3 bucket with the defaults. Click on the bucket, select the management tab, and create lifecycle rules that match the rules on the S3 bucket created by Cloud Manager when the CVO instance was deployed. If you’re not sure which bucket was created by Cloud Manager and is in use, ssh to your CVO instance and run this command:
storage aggregate object-store config show
The “container name” in the output is the name of the S3 bucket currently in use.
Note: Be cautious when examining this bucket. It’s part of an active file system and should not modified in any way!
Alternatively, run these commands from the aws cli (be sure to specify your own bucket name and the correct region). You can see the contents of rules.json here. Be sure to change one of your rules to enabled if you plan to use an S3 class other than Standard:
aws s3api create-bucket --bucket p1tech-cvo-example1 --region us-west-2 --create-bucket-configuration LocationConstraint=us-west-2
aws s3api put-public-access-block --bucket p1tech-cvo-example1 --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
aws s3api put-bucket-lifecycle-configuration --bucket p1tech-cvo-example1 --lifecycle-configuration file://rules.json
Next we need to add an inline IAM policy and attach it to the role used by the CVO instance. This will authorize the CVO instance to read and write to the bucket.
From the EC2 console, select your CVO instance, scroll down in the description tab to IAM role, and select it. You can add an inline policy from here using json like this and substituting your own bucket name.
Now that the bucket, lifecycle rules, and permissions have been setup, a new object-store configuration can be created from the CVO instance. ssh to CVO and run this command substituting your object-store-name (a label for the new object-store cofig) and container-name (name of your bucket):
storage aggregate object-store config create -object-store-name p1ManualS3Bucket -provider-type AWS_S3 -server s3.amazonaws.com -is-ssl-enabled true -port 443 -container-name p1tech-cvo-example1 -ipspace Default -use-http-proxy false -auth-type EC2-IAM
Now that everything’s in place, you can create a new aggregate from Cloud Manager and it will attach the object-store configuration you just created to it.
Once the aggregate has been created, you can check the configuration with this command substituting your aggregate name:
storage aggregate object-store show -aggregate aggr_new
Verify the “Object Store Name” in the output. Done.
Further Cost Optimization
So far we’ve examined several AWS storage configuration and cost optimization options when deploying CVO. In our next post, we’ll cover some other ways to cost optimize, specifically around compute and licensing.
*NOTE: The NetApp support matrix does not state that multiple storage classes in a single CVO instance is a supported configuration. We believe that the absence of an explicit statement of support is not necessarily a clear indication that it’s unsupportable or that it won’t work. We have implemented it, and we know it works and works well. Our suggestion if you’d like to consider deploying it in this manner is to have a conversation with your NetApp account team, or call us at p1 and let us help you with that conversation with NetApp. Once you are comfortable proceeding, we’ll be there to help you set it up.
[…] the next section of the series we’ll look at some of the limitations of Cloud Manager, the management system and […]