NetApp ConsoleでAmazon FSx for NetApp ONTAPの操作をしてみた
BlueXPからNetApp Consoleに変わったので触ってみたい
こんにちは、のんピ(@non____97)です。
皆さんはNetApp BlueXPからNetApp Consoleに変わったので触ってみたいしたいなと思ったことはありますか? 私はあります。
AWSマネジメントコンソールからFSxNについて操作、確認できる要素はAWS APIでサポートされている範囲のみです。そのためqtreeの作成やストレージクォータ、SnapMirrorの設定などのAWS APIがサポートしていなものについては操作することはできません。
CLIやAPIで管理する形で良いのであれば、ONTAP CLIやONTAP REST APIを使えば良いと思いますが、運用的にGUIでも管理できるようにしておきたい需要もあると思います。
従来はNetApp BlueXPというNEtAppが提供しているSaaSを用いることで各種操作、確認ができました。
このNetApp BlueXPがリブランドされてNetApp Consoleと現在はなっています。
また、NetApp Workload FactoryというFSxNで実行されるワークロードに特化したサービスも提供されています。
- NetApp Console: Offers a hybrid experience where you can manage your FSx for ONTAP file systems and workloads running on Amazon FSx for NetApp ONTAP in the same place.
- Workload Factory console: Offers a dedicated Workload Factory experience focused on workloads running on Amazon FSx for NetApp ONTAP.
NetApp ConsoleとNetApp Workload Factoryは以下のようにURLは異なります。
- NetApp Console : https://console.netapp.com/
- NetApp Workload Factory : https://console.workloads.netapp.com/
しかし、先にお伝えしておくと、NetApp Consoleの左ペインのWorkloadメニューの内容はNetApp Workload Factoryと完全一致しており、操作できる内容も同じです。。また、NetApp ConsoleとNetApp Workload Factoryの認証情報、テナントは共有されています。
そのため、普段使う際には「NetApp Consoleを使用している」とだけ認識しておくと良いでしょう。
検証環境
検証環境は以下のとおりです。
FSxNは以下のように作成しました。

NetApp Consoleへのログイン
まず、NetApp Consoleへのログインです。
https://console.netapp.com/ にアクセスします。
アカウントがない方は先述のNetApp BlueXPの紹介記事を参考にアカウントを作成してください。
以下NetApp公式ドキュメントも参考になります。
ログインすると以下のようになります。

プロジェクトの作成
私の過去検証時のリソースが混じらないように新規にプロジェクトを分離させます。
NetApp Consoleにおける管理階層は以下のとおりです。

抜粋 : NetApp Consoleのアイデンティティとアクセス管理について学ぶ
左ペインのメニューから管理-IDとアクセスをクリックします。

すると現在の組織やプロジェクトを確認できます。

フォルダまたはプロジェクトを追加をクリックします。
今回はnon-97-privateというプロジェクトを作成します。

プロジェクトが作成されたことを確認します。

以降操作をする際には新規作成したプロジェクトを切り替えてから行います。
ちなみにプロジェクトに割り当てられているメンバーは以下のとおりです。

AWSアカウントとの連携
作成したFSxNをNetApp Consoleから認識できるようにAWSアカウントとの連携を行います。
左ペインメニューから管理-クレデンシャルで組織のクレデンシャル一覧を表示します。新規のAWSアカウントなのでクレデンシャルの追加をクリックします。

FSxNに関する操作を行うのでFSx for ONTAPを選択します。

どのような操作を許可するかの選択を行います。ここで選択した内容を元に生成されるIAMロールに付与されるIAMポリシーが変動します。今回はFSxNのみ操作できれば良いのでDatabasesやVMwareなどにはチェックは入れません。

CloudFormationでデプロイしたいのでAdd via AWS CloudFormationを選択します。

このとき生成されたCloudFormationテンプレートは以下のとおりです。
AWSTemplateFormatVersion: "2010-09-09"
Description: "This template deploys a package to AWS Lambda, which is an event-driven compute service that runs code in response to events. The package creates a link (Lambda function) in your AWS account, which enables connectivity from NetApp Workload Factory to the resources associated with the FSx for ONTAP workloads in a specific VPC. You will be charged for the number of Lambda requests and the time it takes for the code to execute."
Metadata:
AWS::CloudFormation::Interface:
ParameterGroups:
- Label:
default: "Lambda Function Configuration"
Parameters:
- VPCId
- SubnetIds
- SecurityGroupIds
- Tags
- Label:
default: "Custom Resource Configuration"
Parameters:
- LinkName
- LinkId
- AccountId
- AwsAccountId
- CreationTaskId
ParameterLabels:
VPCId:
default: "VPC ID"
SubnetIds:
default: "Subnet IDs"
SecurityGroupIds:
default: "Security Group IDs"
Tags:
default: "Tags"
LinkName:
default: "Link Name"
LinkId:
default: "Link ID"
AccountId:
default: "Account ID"
AwsAccountId:
default: "AWS Account ID"
JwtToken:
default: "JWT Token"
CreationTaskId:
default: "Creation Task ID"
Parameters:
VPCId:
Type: "AWS::EC2::VPC::Id"
Description: "VPC ID for Lambda-link function"
Default: vpc-08b84da1f793ed513
SubnetIds:
Type: "List<AWS::EC2::Subnet::Id>"
Description: "List of subnet IDs for Lambda-link function"
Default: subnet-08dc789896a48a3b4
SecurityGroupIds:
Type: "List<AWS::EC2::SecurityGroup::Id>"
Description: "List of security group IDs for Lambda-link function"
Default: sg-07d5a421d960151ea
JwtToken:
Type: "String"
Description: "JWT Token to grant access to update link resource"
Default: <省略>
NoEcho: true
LinkName:
Type: "String"
Description: "Name of the link that will be deployed"
Default: non-97-workload-factory-link
LinkId:
Type: "String"
Description: "ID of the link that will be deployed"
Default: <省略>
AccountId:
Type: "String"
Description: "BlueXP account ID"
Default: account-<省略>
AwsAccountId:
Type: "String"
Description: "Aws account ID"
Default: <AWSアカウントID>
CreationTaskId:
Type: "String"
Description: "Tracker creation task ID"
Default: <省略>
Resources:
TrackStackDeployment:
Type: "Custom::LinkAPICallStart"
Properties:
ServiceToken:
Fn::Sub:
- "arn:aws:lambda:${Region}:052582346341:function:custom-resource-link"
- Region:
Ref: "AWS::Region"
accessToken:
Ref: "JwtToken"
linkId:
Ref: "LinkId"
accountId:
Ref: "AccountId"
vpcId:
Ref: "VPCId"
subnetIds:
Ref: "SubnetIds"
securityGroupIds:
Ref: "SecurityGroupIds"
awsAccountId:
Ref: "AwsAccountId"
stackName:
Ref: "AWS::StackName"
linkName:
Ref: "LinkName"
region:
Ref: "AWS::Region"
type: "lambda"
creationTaskId:
Ref: "CreationTaskId"
LambdaRole:
Type: "AWS::IAM::Role"
Properties:
RoleName:
Fn::Sub:
- "LambdaLinkRole-${StackName}"
- StackName:
Ref: "AWS::StackName"
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Principal:
Service: "lambda.amazonaws.com"
Action: "sts:AssumeRole"
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
- "arn:aws:iam::aws:policy/service-role/AWSLambdaRole"
Policies:
- PolicyName: "LambdaPolicy"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "ec2:CreateNetworkInterface"
- "ec2:DescribeNetworkInterfaces"
- "ec2:DeleteNetworkInterface"
- "ec2:AssignPrivateIpAddresses"
- "ec2:UnassignPrivateIpAddresses"
Resource: "*"
- PolicyName: "SecretManagerPolicy"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "secretsmanager:GetSecretValue"
Resource:
Fn::Sub:
- "arn:aws:secretsmanager:${Region}:<AWSアカウントID>:secret:FSxSecret*"
- Region:
Ref: "AWS::Region"
LambdaFunction:
Type: "AWS::Lambda::Function"
Properties:
FunctionName: lambda-KwyTje5
Code:
ImageUri:
Fn::Sub:
- "052582346341.dkr.ecr.${Region}.amazonaws.com/fsx_link:production"
- Region:
Ref: "AWS::Region"
Role:
Fn::GetAtt: ["LambdaRole", "Arn"]
VpcConfig:
SecurityGroupIds:
Ref: "SecurityGroupIds"
SubnetIds:
Ref: "SubnetIds"
PackageType: "Image"
Timeout: 10
LambdaInvokePermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:InvokeFunction"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
GetFunctionPermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:GetFunction"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
UpdateFunctionCodePermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:UpdateFunctionCode"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
GetFunctionConfigurationPermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:GetFunctionConfiguration"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
PostStackDeployment:
Type: "Custom::LinkAPICallEnd"
Properties:
ServiceToken:
Fn::Sub:
- "arn:aws:lambda:${Region}:052582346341:function:custom-resource-link"
- Region:
Ref: "AWS::Region"
accessToken:
Ref: "JwtToken"
linkId:
Ref: "LinkId"
accountId:
Ref: "AccountId"
cloudResourceId:
Fn::GetAtt: ["LambdaFunction", "Arn"]
creationTaskId:
Ref: "CreationTaskId"
Outputs:
LambdaFunctionArn:
Description: "ARN of the Lambda function"
Value:
Fn::GetAtt:
- LambdaFunction
- Arn
Export:
Name:
Fn::Sub: "${AWS::StackName}-LambdaFunctionArn"
右側に表示されているCloudFormationテンプレート上部のRedirect to CloudFormationをクリックします。

Continueをクリックすると、AWSマネジメントコンソールが起動します。

そのままスタックの作成を行います。
スタックの作成が完了してNetApp Consoleの画面に戻るとクレデンシャル一覧にクレデンシャルが一つ追加されていました。

FSxNの確認
これでFSxNの各種情報をNetApp Consoleから確認することができます。
左ペインのメニューのストレージ-管理をクリックします。

現時点では特にFSxNは確認できません。上部の+追加をクリックしてFSxNを検出します。
FSxN横の既存を検出をクリックします。

用意したFSxNを確認できました。Discoverをクリックします。

するとダッシュボードで選択したFSxNがロード中となりました。

数分待つとFSxNを認識できました。現時点ではSystem Managerは確認できません。

システムに入るをクリックすると詳細な情報を確認できました。

Volumesをクリックすると、以下のようにSSDやキャパシティプールストレージ、ボリュームごとの使用量、ARPが有効になっているボリューム数点などを確認できます。

NetApp Consoleの Storage 探索
Dashboard
NetApp ConsoleのStorageについて探索を行います。
まずはDashboardです。他メニューの内容を一覧できるページのようですが、現時点ではNetApp Console AgentもしくはWorkload Factory linkがFSxNファイルシステムに関連付けされていないことから情報はほぼ確認できません。

Well-architected
次にWell-architectedです。
ここではFSxNにおけるWell-architectedに準拠されているかを確認することが可能です。
現時点ではWorkload Factory linkがFSxNファイルシステムに関連付けされていないことから一部データは確認できなさそうです。あとで確認しましょう。


Explorer savings
次にExplorer savingsです。
ここではEBSボリューム、FSxW、EFSについてのコスト削減効果を検証することが可能です。

Cost
CostではFSxNにおけるコストの詳細を確認することが可能です。

NetApp Workload Factoryにログイン
NetApp Workload Factoryにログインしてみましょう。
すると、左ペインのメニューがNetApp Consoleにて左メニューでWorkloadを選択したときと内容が一致していることが分かります。




操作できる内容も同じです。
Workload Factory linkの作成
Workload Factory linkを行います。
FSxNの内部情報の取得や操作をする際、今までは以下で紹介されているようにNetApp Console AgentのEC2インスタンスをデプロイする必要がありました。
そのため、EC2インスタンスのランニングコストが発生します。
コスト削減のためにNetApp Console上で確認をするときに都度EC2インスタンスを起動させるというのも中々に手間です。
一方、Workload Factory linkはLambda関数を用いています。
Lambda関数がNetApp Consoleからの操作に基づいて動作します。コストはLambda関数が動作した分だけ請求されるので、NetApp Console Agentと比べて非常にコスト効率が良いです。
link作成前にNetApp Workload FactoryのSaaSエンドポイントへの経路とセキュリティグループに十分なルールがあるか確認しましょう。
- リンク接続のために、FSx for ONTAP ファイル システムに関連付けられたセキュリティ グループで次のポートが開いている必要があります。
- Workload Factory コンソールの場合: ポート 443 (HTTPS)
- CloudShell および FSx for ONTAP緊急管理システム (EMS) イベント分析の場合: ポート 22 (SSH)
- リンクは次のエンドポイントに接続できる必要があります: https://api.workloads.netapp.com.Webベースのコンソールは、このエンドポイントに接続して Workload Factory API と対話し、FSx for ONTAPワークロードを管理および操作します。
それではAssociate linkをクリックします。新規にリンクを作成および関連付けを行います。

AWSアカウントとの関連付けと同じような画面になります。
以下文言があることからVPC Lambdaが作成されるようですね。
AWS Lambda is an event-driven compute service that runs code in response to events. When you create a link, a package is deployed to Lambda in the VPC where your FSx for ONTAP file systems reside. This package enables connectivity from Workload Factory to the resources associated with your FSx for ONTAP workloads. No outbound connectivity from Lambda is required. Lambda links interacts with FSx for ONTAP file systems via HTTPS (TCP port 443) and SSH (TCP port 22).
リンク名やSecrets Managerへの権限有無などを選択します。

右側のCloudFormationテンプレート上部のRedirect to CloudFormationをクリックし、CloudFormationスタックを作成します。

ここでサブネット、セキュリティグループを選択します。
CloudFormationテンプレートは以下のとおりです。
AWSTemplateFormatVersion: "2010-09-09"
Description: "This template deploys a package to AWS Lambda, which is an event-driven compute service that runs code in response to events. The package creates a link (Lambda function) in your AWS account, which enables connectivity from NetApp Workload Factory to the resources associated with the FSx for ONTAP workloads in a specific VPC. You will be charged for the number of Lambda requests and the time it takes for the code to execute."
Metadata:
AWS::CloudFormation::Interface:
ParameterGroups:
- Label:
default: "Lambda Function Configuration"
Parameters:
- VPCId
- SubnetIds
- SecurityGroupIds
- Tags
- Label:
default: "Custom Resource Configuration"
Parameters:
- LinkName
- LinkId
- AccountId
- AwsAccountId
- CreationTaskId
ParameterLabels:
VPCId:
default: "VPC ID"
SubnetIds:
default: "Subnet IDs"
SecurityGroupIds:
default: "Security Group IDs"
Tags:
default: "Tags"
LinkName:
default: "Link Name"
LinkId:
default: "Link ID"
AccountId:
default: "Account ID"
AwsAccountId:
default: "AWS Account ID"
JwtToken:
default: "JWT Token"
CreationTaskId:
default: "Creation Task ID"
Parameters:
VPCId:
Type: "AWS::EC2::VPC::Id"
Description: "VPC ID for Lambda-link function"
Default: vpc-08b84da1f793ed513
SubnetIds:
Type: "List<AWS::EC2::Subnet::Id>"
Description: "List of subnet IDs for Lambda-link function"
Default: subnet-08dc789896a48a3b4
SecurityGroupIds:
Type: "List<AWS::EC2::SecurityGroup::Id>"
Description: "List of security group IDs for Lambda-link function"
Default: sg-07d5a421d960151ea
JwtToken:
Type: "String"
Description: "JWT Token to grant access to update link resource"
Default: <省略>
NoEcho: true
LinkName:
Type: "String"
Description: "Name of the link that will be deployed"
Default: non-97-workload-factory-link
LinkId:
Type: "String"
Description: "ID of the link that will be deployed"
Default: <省略>
AccountId:
Type: "String"
Description: "BlueXP account ID"
Default: <省略>
AwsAccountId:
Type: "String"
Description: "Aws account ID"
Default: <AWSアカウントID>
CreationTaskId:
Type: "String"
Description: "Tracker creation task ID"
Default: <省略>
Resources:
TrackStackDeployment:
Type: "Custom::LinkAPICallStart"
Properties:
ServiceToken:
Fn::Sub:
- "arn:aws:lambda:${Region}:052582346341:function:custom-resource-link"
- Region:
Ref: "AWS::Region"
accessToken:
Ref: "JwtToken"
linkId:
Ref: "LinkId"
accountId:
Ref: "AccountId"
vpcId:
Ref: "VPCId"
subnetIds:
Ref: "SubnetIds"
securityGroupIds:
Ref: "SecurityGroupIds"
awsAccountId:
Ref: "AwsAccountId"
stackName:
Ref: "AWS::StackName"
linkName:
Ref: "LinkName"
region:
Ref: "AWS::Region"
type: "lambda"
creationTaskId:
Ref: "CreationTaskId"
LambdaRole:
Type: "AWS::IAM::Role"
Properties:
RoleName:
Fn::Sub:
- "LambdaLinkRole-${StackName}"
- StackName:
Ref: "AWS::StackName"
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Principal:
Service: "lambda.amazonaws.com"
Action: "sts:AssumeRole"
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
- "arn:aws:iam::aws:policy/service-role/AWSLambdaRole"
Policies:
- PolicyName: "LambdaPolicy"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "ec2:CreateNetworkInterface"
- "ec2:DescribeNetworkInterfaces"
- "ec2:DeleteNetworkInterface"
- "ec2:AssignPrivateIpAddresses"
- "ec2:UnassignPrivateIpAddresses"
Resource: "*"
- PolicyName: "SecretManagerPolicy"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "secretsmanager:GetSecretValue"
Resource:
Fn::Sub:
- "arn:aws:secretsmanager:${Region}:<AWSアカウントID>:secret:FSxSecret*"
- Region:
Ref: "AWS::Region"
LambdaFunction:
Type: "AWS::Lambda::Function"
Properties:
FunctionName: lambda-CLA0itT
Code:
ImageUri:
Fn::Sub:
- "052582346341.dkr.ecr.${Region}.amazonaws.com/fsx_link:production"
- Region:
Ref: "AWS::Region"
Role:
Fn::GetAtt: ["LambdaRole", "Arn"]
VpcConfig:
SecurityGroupIds:
Ref: "SecurityGroupIds"
SubnetIds:
Ref: "SubnetIds"
PackageType: "Image"
Timeout: 10
LambdaInvokePermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:InvokeFunction"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
GetFunctionPermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:GetFunction"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
UpdateFunctionCodePermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:UpdateFunctionCode"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
GetFunctionConfigurationPermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:GetFunctionConfiguration"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
PostStackDeployment:
Type: "Custom::LinkAPICallEnd"
Properties:
ServiceToken:
Fn::Sub:
- "arn:aws:lambda:${Region}:052582346341:function:custom-resource-link"
- Region:
Ref: "AWS::Region"
accessToken:
Ref: "JwtToken"
linkId:
Ref: "LinkId"
accountId:
Ref: "AccountId"
cloudResourceId:
Fn::GetAtt: ["LambdaFunction", "Arn"]
creationTaskId:
Ref: "CreationTaskId"
Outputs:
LambdaFunctionArn:
Description: "ARN of the Lambda function"
Value:
Fn::GetAtt:
- LambdaFunction
- Arn
Export:
Name:
Fn::Sub: "${AWS::StackName}-LambdaFunctionArn"
スタック作成の中でLambda関数のENIが生えてきたらEIPを関連付けます。従来であればNAT Gatewayを経由してインターネットに出れるようにするべきでしょうが、今回はコスト削減です。

NetApp Consoleに戻ると以下のように5分程度でかかる旨が書いてありましました。

そのまま大人しくして待っていましたが、linkの作成は完了しません。

EIPをVPC LambdaのENIアタッチする方式が悪いのかと思い、NAT Gatewayを用意してインターネットへの通信経路を確保した上で再度作成しなおしましたが、結果は変わらずです。

4回ほどトライしましたが、30分以上経過してもデプロイが完了しません。
デプロイタイムラインを確認すると、いずれのスタックも以下リソースが完了していません。
- PostStackDeployment
- TrackStackDeployment

いずれのカスタムリソースも恐らくNetApp管理のLambda関数を呼び出しているものかと考えます。一時的な不調でこのカスタムリソースの動作していないようです。
対応として手動で作成を行います。

生成されたCloudFormationテンプレートを元にスタックを作成します。

生成されたCloudFormationテンプレートは以下です。
AWSTemplateFormatVersion: "2010-09-09"
Description: "This template deploys a package to AWS Lambda, which is an event-driven compute service that runs code in response to events. The package creates a link (Lambda function) in your AWS account, which enables connectivity from NetApp Workload Factory to the resources associated with the FSx for ONTAP workloads in a specific VPC. You will be charged for the number of Lambda requests and the time it takes for the code to execute."
Metadata:
AWS::CloudFormation::Interface:
ParameterGroups:
- Label:
default: "Lambda Function Configuration"
Parameters:
- VPCId
- SubnetIds
- SecurityGroupIds
- Tags
ParameterLabels:
VPCId:
default: "VPC ID"
SubnetIds:
default: "Subnet IDs"
SecurityGroupIds:
default: "Security Group IDs"
Tags:
default: "Tags"
Parameters:
VPCId:
Type: "AWS::EC2::VPC::Id"
Description: "VPC ID for Lambda-link function"
Default: vpc-08b84da1f793ed513
SubnetIds:
Type: "List<AWS::EC2::Subnet::Id>"
Description: "List of subnet IDs for Lambda-link function"
Default: subnet-08dc789896a48a3b4
SecurityGroupIds:
Type: "List<AWS::EC2::SecurityGroup::Id>"
Description: "List of security group IDs for Lambda-link function"
Default: sg-07d5a421d960151ea
Resources:
LambdaRole:
Type: "AWS::IAM::Role"
Properties:
RoleName:
Fn::Sub:
- "LambdaLinkRole-${StackName}"
- StackName:
Ref: "AWS::StackName"
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Principal:
Service: "lambda.amazonaws.com"
Action: "sts:AssumeRole"
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
- "arn:aws:iam::aws:policy/service-role/AWSLambdaRole"
Policies:
- PolicyName: "LambdaPolicy"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "ec2:CreateNetworkInterface"
- "ec2:DescribeNetworkInterfaces"
- "ec2:DeleteNetworkInterface"
- "ec2:AssignPrivateIpAddresses"
- "ec2:UnassignPrivateIpAddresses"
Resource: "*"
- PolicyName: "SecretManagerPolicy"
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "secretsmanager:GetSecretValue"
Resource:
Fn::Sub:
- "arn:aws:secretsmanager:${Region}:<AWSアカウントID>:secret:FSxSecret*"
- Region:
Ref: "AWS::Region"
LambdaFunction:
Type: "AWS::Lambda::Function"
Properties:
FunctionName: lambda-kfLMqGg
Code:
ImageUri:
Fn::Sub:
- "052582346341.dkr.ecr.${Region}.amazonaws.com/fsx_link:production"
- Region:
Ref: "AWS::Region"
Role:
Fn::GetAtt: ["LambdaRole", "Arn"]
VpcConfig:
SecurityGroupIds:
Ref: "SecurityGroupIds"
SubnetIds:
Ref: "SubnetIds"
PackageType: "Image"
Timeout: 10
LambdaInvokePermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:InvokeFunction"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
GetFunctionPermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:GetFunction"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
UpdateFunctionCodePermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:UpdateFunctionCode"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
GetFunctionConfigurationPermission:
Type: "AWS::Lambda::Permission"
Properties:
FunctionName:
Ref: "LambdaFunction"
Action: "lambda:GetFunctionConfiguration"
Principal: "arn:aws:iam::052582346341:user/proxy-forwarder"
Outputs:
LambdaFunctionArn:
Description: "ARN of the Lambda function"
Value:
Fn::GetAtt:
- LambdaFunction
- Arn
Export:
Name:
Fn::Sub: "${AWS::StackName}-LambdaFunctionArn"
すると、今度は正常に作成完了しました。

Lambda関数のARNをNetapp Consoleで入力します。

正常にlinkの作成ができました。

現状ではまだlinkが作成されただけでFSxNへの関連付けは行われていません。Associate linkをクリックして関連付けを行います。

先ほど作成したlinkを選択します。

FSxNファイルシステムのfsxadminのパスワードを入力します。linkにSecrets Managerの権限を付与している場合はSecrets ManagerのARNを渡しましょう。

linkとの関連付けが正常に完了すると、先ほどまでグレーアウトしていたタブを選択できるようになりました。

Workload Factory link関連付け完了後のFSxN確認
Block devices
Workload Factory link関連付け完了後のFSxNを確認します。
Block devicesを確認すると、iSCSIのブロックデバイスを確認できます。

Well-architected status
Well-architected statusタブを選択して、Analyze nowをクリックします。

数分で分析が完了しました。22件ほどチェック項目があるようですね。Storage EfficiencyやARP/AIの有効化などの項目がありますね。

Analysis
AnalysisタブではFSxNでは発生したイベントについて確認できるようです。現時点では何もイベントは発生していないので試しようはないのですがAIでイベント分析することも可能なようです。

System Manager
ダッシュボード
System Managerで各種情報を確認しましょう。
FSxNを選択してSystem Manager横の開くをクリックします。

するとSystem Managerのダッシュボードが開きます。

ボリューム
ボリュームを確認します。

vol1をクリックします。

以下のようにvol1をマウントして、何回か書き込みます。
$ sudo mount -t nfs svm-0871b7be53bf283de.fs-00c8fbb914b449f64.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/
$ sudo mkdir /mnt/fsxn/test
$ echo test.txt | sudo tee -a /mnt/fsxn/test/test.txt > /dev/null
$ cat /mnt/fsxn/test/test.txt
test.txt
$ sudo dd if=/dev/urandom of=/mnt/fsxn/random_pattern_binary_block_1GiB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.27413 s, 171 MB/s
$ sudo dd if=/dev/urandom of=/mnt/fsxn/random_pattern_binary_block_1GiB_2 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.34548 s, 169 MB/s
$ sudo dd if=/dev/urandom of=/mnt/fsxn/random_pattern_binary_block_1GiB_3 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.55637 s, 164 MB/s
$ sudo dd if=/dev/urandom of=/mnt/fsxn/random_pattern_binary_block_1GiB_4 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.42817 s, 167 MB/s
この状態でファイルシステムタブを選択します。

特に情報は表示されませんね。十分ホットスポットではあると思うので謎です。

エクスプローラーを選択すると、先ほど作成したファイルやディレクトリを確認できました。

なお、右側のファイル一覧からファイルの削除をすることができます。誤って削除してしまわないように気をつけましょう。

使用量をクリックすると、ディレクトリ数やファイル数、最大のディレクトリのサイズを確認することができます。

qtree
qtreeを確認してみましょう。

適当に2GiBのストレージクォータが適用されているqtreeを作成します。

作成すると以下のようになります。

まだ何も書き込んでいないので使用量は0%です。

クォータルールやボリュームステータスは以下のとおりです。


qtreeに対して3GiB書き込んでみます。
$ sudo dd if=/dev/urandom of=/mnt/fsxn/test-qtree/random_pattern_binary_block_3GiB bs=1M count=3096
dd: error writing '/mnt/fsxn/test-qtree/random_pattern_binary_block_3GiB': No space left on device
2161+0 records in
2160+0 records out
2264924160 bytes (2.3 GB, 2.1 GiB) copied, 13.6621 s, 166 MB/s
2.1GiBで書き込みがストップしてしまいましたね。ストレージクォータが効いているようです。
System Managerからも使用率100%であることが確認できました。

クライアント
クライアントでは接続してきているクライアントのIPアドレスやプロトコル、接続先ボリューム、SVMを確認できます。

イベントとジョブ
イベントではEMSイベントを確認することができます。現時点では特に発行されていないため確認できませんでした。

ジョブでは裏側で実行されていた処理が確認できているようです。

監査ログも確認できます。

保護
保護では主にSnapshot、SnapMirrorに関する情報の確認、設定が可能です。

SnapshotポリシーやSnapMirrorポリシー、クラスターやSVMで設定されているジョブスケジュールを確認できます。



現時点ではSnapMirror relationshipを作成していないため、レプリケーション一覧を確認しても空です。

クラスタ設定
クラスタ全般の設定も行えます。

なお、通知の管理とありますが、これはあくまでFSxN上のリソースに対しての設定です。
私は以下記載を見てNetApp Consoleへの監視通知を行えるかと早合点してしまいましたが、そうではありません。
ワークロード ファクトリーでは、情報を表示したりタスクを実行したりするためのリンクが必要です。リンクを必要とする操作を実行しようとしたが、FSx for ONTAPファイル システムにリンクが関連付けられていない場合、Workload Factory は操作にリンクが必要であることを通知します。
リンクが必要な機能は次のとおりです。
- プロアクティブなメンテナンス、信頼性、コストパフォーマンスの最適化を実現する FSx for ONTAPファイルシステム構成の適切なアーキテクチャの状態
- ONTAP EMSイベント監視とアラート
- NetApp自律型ランサムウェア保護 (ARP/AI)
- FSx for ONTAPファイルシステム全体の容量の総合的な観測性が強化されました
- ボリュームおよびストレージ VM データのレプリケーション、管理、および監視
- SMB/CIFS共有およびNFSエクスポートポリシーのプロビジョニングと管理
- FSx for ONTAPファイルシステムでのiSCSIボリュームの管理
- カスタム保護 SLA のスナップショット ポリシーの作成と管理
- 自動容量管理のためのiノード管理の強化
- 弾力的なスケーリングのためのボリューム自動拡張
- クローンの作成と管理により、即時にインプレースでデータのクローンを作成できます。
- ONTAPバージョンなどの追加メトリックをONTAPから直接表示する
アラートというメニューもありますが、こちらはオンプレONTAPのみです。

NetApp SaaS上に情報を吸い上げて、条件に当てはまるものを通知したい場合はNetApp Data Infrastructure Insightsを採用することになります。
Well-architectedの指摘事項に基づいた設定変更
Well-architectedの指摘事項に基づいた設定変更を行なってみます。
Storage Efficiencyが無効であることが先ほどの分析で指摘されていたので有効化をします。有効化したいボリュームのfixをクリックします。

内容を確認してContinueをクリックします。

しばらく待つと有効化が完了したようです。

すると、先ほど66%だったスコアが68%となりました。

ちなみにトラッカーから、いつ、誰が、どのような操作を行なったのか後追いすることも可能です。

Workload Factory linkのLambda関数のモニタリング
Workload Factory linkのLambda関数のモニタリングを確認します。
呼び出し回数を見たところ、約1850回と結構な回数呼び出しがされていました。

なお、NetApp Consoleから何も操作をしていない場合でも30分ごとにLambda関数が実行されていました。

CloudWatch Logsには以下のようなログが記録されていました。
START RequestId: 4aea4365-00e6-4125-87ee-803699de86de Version: $LATEST
2026-05-23T03:25:56.416Z 4aea4365-00e6-4125-87ee-803699de86de INFO lambda input: method=GET, queryParams=
{
"top_metric": "throughput.read",
"fields": "throughput.error,svm,volume,path",
"return_timeout": "120"
}
, url=/api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2/top-metrics/directories, requestType=https
2026-05-23T03:25:56.975Z 4aea4365-00e6-4125-87ee-803699de86de ERROR (node:2) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use `node --trace-warnings ...` to show where the warning was created)
2026-05-23T03:25:57.257Z 4aea4365-00e6-4125-87ee-803699de86de INFO
{
"message": "GET call to /api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2/top-metrics/directories took 558ms",
"method": "GET",
"endpoint": "10.0.1.69",
"request_url": "/api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2/top-metrics/directories",
"ontap_response_duration": 558,
"timestamp": "2026-05-23T03:25:57.257Z"
}
END RequestId: 4aea4365-00e6-4125-87ee-803699de86de
REPORT RequestId: 4aea4365-00e6-4125-87ee-803699de86de Duration: 916.29 ms Billed Duration: 1502 ms Memory Size: 128 MB Max Memory Used: 98 MB Init Duration: 584.86 ms
START RequestId: 185b3caf-888f-40a7-935b-d60cccc29f5a Version: $LATEST
2026-05-23T03:25:57.411Z 185b3caf-888f-40a7-935b-d60cccc29f5a INFO lambda input: method=GET, queryParams=
{
"fields": "size,name,accessed_time,constituent.name",
"max_records": "40",
"order_by": "size desc",
"return_timeout": "120",
"type": "!directory"
}
, url=/api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2/files//, requestType=https
2026-05-23T03:25:57.455Z 185b3caf-888f-40a7-935b-d60cccc29f5a INFO
{
"message": "GET call to /api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2/files// took 44ms",
"method": "GET",
"endpoint": "10.0.1.69",
"request_url": "/api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2/files//",
"ontap_response_duration": 44,
"timestamp": "2026-05-23T03:25:57.455Z"
}
END RequestId: 185b3caf-888f-40a7-935b-d60cccc29f5a
REPORT RequestId: 185b3caf-888f-40a7-935b-d60cccc29f5a Duration: 46.22 ms Billed Duration: 47 ms Memory Size: 128 MB Max Memory Used: 98 MB
START RequestId: 159993cb-1012-47e3-91c1-b8766f6670a1 Version: $LATEST
2026-05-23T03:26:14.765Z 159993cb-1012-47e3-91c1-b8766f6670a1 INFO lambda input: method=GET, queryParams=
{
"fields": "uuid,name,svm,nas,state,space,metric,type,snapshot_policy,flexcache_endpoint_type,snapmirror,is_svm_root,quota,clone,snaplock,style,encryption,application,consistency_group,create_time,guarantee,movement,aggregates,qos,autosize,efficiency,tiering,size,analytics,analytics.supported,access_time_enabled,space.block_storage_inactive_user_data,files,activity_tracking,cloud_retrieval_policy,snapshot_count,language,comment,snapshot_locking_enabled,granular_data,granular_data_mode,anti_ransomware.state,scheduled_snapshot_naming_scheme,snapshot_directory_access_enabled,rebalancing.max_constituent_imbalance_percent,rebalancing.state,rebalancing.max_threshold,rebalancing.stop_time,rebalancing.start_time",
"return_timeout": "120"
}
, url=/api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2, requestType=https
2026-05-23T03:26:14.867Z 159993cb-1012-47e3-91c1-b8766f6670a1 INFO
{
"message": "GET call to /api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2 took 102ms",
"method": "GET",
"endpoint": "10.0.1.69",
"request_url": "/api/storage/volumes/705b51c6-564c-11f1-b984-b37fdb60e3e2",
"ontap_response_duration": 102,
"timestamp": "2026-05-23T03:26:14.867Z"
}
END RequestId: 159993cb-1012-47e3-91c1-b8766f6670a1
REPORT RequestId: 159993cb-1012-47e3-91c1-b8766f6670a1 Duration: 111.47 ms Billed Duration: 112 ms Memory Size: 128 MB Max Memory Used: 98 MB
NetApp Consoleを使用するときにはWorkload Factory linkもセットで使用しよう
NetApp ConsoleでAmazon FSx for NetApp ONTAPの操作をしてみました。
基本的にNetApp Consoleを使用する動機はGUIでAWS APIが未サポートの操作をするときだと思います。そのため、NetApp Consoleを使用するときにはWorkload Factory linkもセットで使用する形になるかと思います。
個人的にはNetApp BlueXP時代と比べるとAWSアカウントとの連携が楽になったり、FSxNの操作のみであればWorkload Factory linkというEC2インスタンスが不要な構成が取れたりと進化を実感できました。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!








