はじめに

こんにちは。SB C&Sの大塚です。

Cohesityは、オンプレミス、仮想基盤、クラウドなど、幅広い環境のデータ保護に対応するプラットフォームです。オンプレミスのアプライアンスであれば導入後の姿を想像しやすい一方、AWS上に構築するDataProtect for Cloudは、どのAWSリソースが必要なのか、CLIからどのようにクラスターを作るのかなど分かりにくいと感じる方も多いのではないでしょうか。

そこで今回は、Cohesity DataProtect for Cloud（以下、DataProtect for Cloud）を実際に検証でデプロイしてみましたので、AWS上へCLIでデプロイし、EC2インスタンスのバックアップとリストアまでを確認した流れをまとめます。単なる手順の羅列ではなく、各AWSリソースが何のために必要なのか、構築時にどこで迷いやすいのかもあわせて紹介しますので是非最後まで読んでいただけると幸いです。

Cohesity DataProtect for Cloudのデプロイ記事は2本立てとなっております。Heliosからのデプロイ記事では、GUIのCohesity Heliosからデプロイを行う流れを紹介しています。

この記事でわかること

• DataProtect for Cloud on AWSのデータ保管アーキテクチャと、3ノード構成の全体像
• CLIデプロイに必要なAMI、VPC、IAM、S3、Control VMの役割と準備条件
• 設定JSONの全項目と、入力する値・確認元・入力時の注意点
• デプロイ後の初期設定と、EC2バックアップ / リストアの確認方法
• 異なるVPCにある保護対象を扱う際のネットワーク設計上の注意点

本記事の前提と対象範囲

本記事は、AWSとCohesityの基本操作を理解しているものの、DataProtect for Cloudの構築は初めてという方を主な対象としています。以下の知識と操作方法を理解していることを前提に進めます。

• Cohesity DataProtectの基本概念と、ソース登録・Protection Group・バックアップ / リストアの基本操作
• AWSの基本概念と、VPC、EC2、IAM、S3、CloudFormationなどの基本操作
• ルーティング、DNS、NTP、ファイアウォールなど、ネットワークとセキュリティの基礎知識

VPCやサブネット、IAM、S3そのものの機能や作成方法、およびCohesity共通のProtection Group / Policy設計については詳しい解説を割愛します。一方、DataProtect for Cloudのデプロイに必要となるAWSリソースの条件、使用するIAMポリシー、設定JSONの各項目、Control VMからの実行手順は具体的に解説します。AWS側の構成や設定値は、本記事を参考に利用環境へ合わせてカスタマイズしてください。
本記事でのリストア確認は、CohesityのRecoveryジョブが正常終了し、指定した条件でEC2インスタンスが作成されることまでを対象とします。ゲストOSの起動、アプリケーション整合性、データ内容、業務接続性の検証は対象外です。

検証環境

項目	本検証の構成
Cohesityバージョン	DataProtect 7.4
デプロイ方法	CLI / IAMユーザー認証
クラスター構成	Next Generation / Entry（Intel） / 3ノード
ノードインスタンス	m6i.2xlarge × 3
ネットワーク	パブリックサブネット＋プライベートサブネット、NAT Gatewayを使用
S3への通信	本検証はNAT Gateway経由。推奨構成としてS3 Gateway Endpointも解説
保護対象	DataProtect for Cloudとは異なるVPCに配置したAmazon EC2
AWS環境	Cohesityクラスターとバックアップ対象は同一AWSアカウント 同一リージョン内での検証 それぞれ別のVPC上に構築されている

目次

1. DataProtect for Cloud on AWSの全体像

検証環境図

1.1 データはEBSを経由してS3へ保存される

DataProtect for Cloud on AWSのデータ保管は、Metadata Tier、Cache Tier、Data Tierの3階層で構成されます。保護データは、まずクラスターノードにアタッチされたEBSへ一時的にキャッシュされ、その後、永続保存先であるAmazon S3へダウンティアされます。
クラスターノードにはバックアップカタログなどのメタデータが保持されます。また、S3側にもCloudRetrieveで利用するためのメタデータのコピーが保存されます。オンプレミス版のCloudArchiveジョブを管理者が個別に作成するのではなく、AWS版のデータ保管アーキテクチャとして内部的に行われる点がポイントです。

1.2 本番環境では3ノード以上が必要

DataProtect for Cloudを本番環境で利用する場合、アップグレード時やノード障害時の可用性を確保するため、少なくとも3ノードが必要です。1ノード構成はデモや検証用途に限られます。本記事では、公式の最小本番構成である3ノードを使用します。

構成	EC2インスタンス	CPU / メモリ	Metadata Tier	Cache Tier
Entry	m6i.2xlarge / m6a.2xlarge	8 vCPU / 32 GB	2 × 511 GB	2 × 512 GB
Core	m6i.4xlarge / m6a.4xlarge	16 vCPU / 64 GB	2 × 1 TB	2 × 1 TB
Archive	m6i.4xlarge / m6a.4xlarge	16 vCPU / 64 GB	2 × 2 TB	2 × 2 TB
Performance	m6i.8xlarge / m6a.8xlarge	32 vCPU / 128 GB	2 × 1 TB	2 × 1 TB

新規デプロイする7.3.1以降のクラスターでは、ブートディスクは250 GBです。実際に選択する構成は、Cohesityのサイジング結果と性能要件に基づいて決定してください。

1.3 CLIデプロイの流れ

CLIデプロイでは、Control VMを手動で起動した後、Control VM上の設定JSONとセットアップユーティリティを使用します。セットアップユーティリティはCloudFormationを呼び出し、3台のクラスターノード、EBS、ネットワークインターフェース、IAM関連リソースなどを自動展開します。

1. AWSアカウント、リージョン、Cohesityバージョンを指定してAMI利用を申請する
2. VPC、サブネット、ルートテーブル、セキュリティグループ、IAM、S3を準備する
3. 共有されたAMIからControl VMをプライベートサブネットへ起動する
4. Control VM上の設定JSONを編集し、検証コマンドを実行する
5. セットアップユーティリティからCloudFormationを実行し、3ノードクラスターを構築する
6. 初期設定後、AWS環境をソース登録してバックアップ / リストアを確認する

2. デプロイ前に確認しておきたいこと

デプロイコマンド自体はシンプルですが、事前条件が不足していると、CloudFormationの途中で失敗します。作業前に次の項目を確認しておくと、切り分けがしやすくなります。

確認項目	確認内容
AMIとライセンス	Control VM用AMIとクラスターノード用AMIの利用権限を取得し、クラスターライセンスを別途入手します。
EC2サービスクォータ	デプロイ先リージョンで、選択するインスタンスファミリーを3台起動できるOn-Demand vCPU枠を確認します。
VPC / サブネット / IP	Control VMとクラスターノードを配置するプライベートサブネットを用意し、3ノード分のIPアドレスを確保します。クラスターノードは同一AZ/サブネットへ配置します。
DNS / NTP	設定JSONへ入力するDNSとNTPを決め、クラスターから名前解決および 時刻同期できることを確認します。
AWS API / S3への到達性	IAM権限の確認、CloudFormation、EC2、S3、NTP、Heliosなど、利用する機能に必要なアウトバウンド通信を確保します。
セキュリティグループ	ノード間通信、Control VMからノードへのTCP 22/443、管理端末からCohesity UIへのTCP 443を許可します。
IAMとアクセスキー	クラスター構築用、S3アクセス用、バックアップ / リストア用のIAMユーザーとアクセスキーを準備します。
S3バケット	保護データのダウンティア先となるCohesity専用S3バケットを、クラスターと同じリージョンに用意します。
設定JSON用の値	リージョン、AZ、VPC ID、サブネットID、セキュリティグループID、AMI ID、DNS、NTPなどを事前に控えます。

3. Cohesity AMIの利用申請

3.1 CLI版では2種類のAMIを使用する

CLIでDataProtect for Cloudをデプロイするには、Cohesityが提供する2種類のAMIが必要です。AMIは一般公開されておらず、指定したAWSアカウントに対して利用権限が付与されます。

AMI	役割
Control VM用AMI	Control VMを起動するためのAMI。設定JSONとCLIを使用し、クラスター作成、開始、停止、再起動、破棄、ノード追加 / 削除などを制御する。
クラスターノード用AMI	Cohesityソフトウェアを含むノード用AMI。Control VMから呼び出され、CloudFormationによって複数のEC2インスタンスとして展開される。

3.2 AMIの利用をメールで申請する

次の情報を記載した英語メールをcloudedition@cohesity.com宛に送付します。AMIはリージョンごとに異なるため、デプロイ先リージョンを正しく記載しましょう。

記載項目	内容
AWS Account ID	DataProtect for CloudをデプロイするAWSアカウントID
Your Name and Company Name	申請者の氏名と会社名
Email Address	Cohesityからの案内を受け取るメールアドレス
AWS Region	クラスターを展開するAWSリージョン
Cohesity Software Version	デプロイするCohesityソフトウェアのバージョン

 リクエストが受理されると、Cohesityから指定したメールアドレス宛にデプロイに必要な情報が送付されます。あわせて、指定したAWSアカウントにAMIの利用権限が付与されるため、Control VMとクラスターノードを起動できるようになります。

Cohesityから案内される情報	内容
Control VM AMI ID	Control VMを起動するAMI ID
Control VM Password	Control VMのcohesityアカウントで使用するパスワード
Cluster Instance AMI ID	クラスターノードを起動するAMI ID

3.3 Control VMはデプロイ後に停止できる

クラスターのデプロイが完了した後、Control VMは停止または削除できます。ただし、追加クラスターのデプロイや既存クラスターへのノード追加を行う可能性がある場合は、使用した設定JSONを安全な場所へ保管してください。Control VMを削除した場合、将来の操作時に新しいControl VMを起動し直す必要があります。

4. VPCとネットワークの準備

4.1 Cohesity側から見たVPCの構築条件

DataProtect for Cloudは、新規または既存のVPCへデプロイできます。本記事ではAWSネットワークの具体的な作成手順は扱いません。次のいずれかの構成を用意し、Control VM、クラスターノード、S3、AWS API、DNS、NTP、および保護対象との通信が成立するように設計してください。

パターン	構成と利用条件
A：パブリック＋プライベート	外部NTPやHelios、AWSサービスへのアウトバウンド通信をNAT Gateway経由で確保する構成。Control VMとクラスターノードはプライベートサブネットへ配置します。
B：プライベートのみ	社内DNS / NTP、VPN、Direct Connect、Transit Gateway、VPC Endpointなどを利用し、必要な宛先へプライベートに到達できる構成。

 本検証ではパターンAを採用し、NAT Gatewayをパブリックサブネットへ、Control VMと3台のクラスターノードをプライベートサブネットへ配置しました。利用環境で本記事と同じ構成を再現する必要はなく、Cohesityに必要な通信が成立していれば問題ありません。

4.2 DataProtect for Cloudで必要となる通信

通信	Cohesity側で確認する内容
クラスターノード間	同一クラスターを構成する全てのノードが相互に通信できること。セキュリティグループで全トラフィックを許可するか、公式のノード間通信ポート要件を参照して、適切に許可します。
Control VM → クラスターノード	クラスター作成およびトラブルシューティングのため、TCP 443とTCP 22で到達できること。
管理端末 / 踏み台 → Cohesity UI	クラスターノードのプライベートIPへTCP 443で到達できること。
Control VM / クラスターノード → AWSサービス	IAM権限確認、CloudFormation、EC2、S3など、デプロイおよびデータ保護で使用するAWS APIへ到達できること。
クラスターノード → DNS / NTP / Helios	設定JSONで指定したDNSとNTPへ到達できること。Heliosを利用する場合は必要なアウトバウンド通信を許可します。
Cohesityクラスター→保護対象 / 管理コンポーネント	保護方式に応じて、Cohesityクラスターから保護対象、または保護対象を管理するコンポーネントへ必要な通信が成立すること。必要な通信方向とポートは、保護対象ごとの公式要件をご確認ください。

クラスターノードは同一VPC・同一AZ・同一プライベートサブネットへ配置します。VPCのDNS解決を有効にし、設定JSONで指定するDNSからNTPサーバーや必要なAWSエンドポイントを名前解決できることも確認してください。

4.3 S3通信はGateway Endpointを推奨

本検証では、プライベートサブネットからNAT Gatewayを経由してAmazon S3へ通信しました。一方、S3 Gateway Endpointを利用すると、S3宛ての通信をNAT GatewayやInternet Gatewayへ出さずにAWSネットワーク内で完結させられます。NAT Gatewayのデータ処理コストや経路依存を抑えられるため、本番環境ではS3 Gateway Endpointの利用を検討してください。

4.4 保護対象が別VPCにある場合

実際の環境では、DataProtect for Cloudと保護対象が同じVPCにあるとは限りません。本検証でも、DataProtect for CloudをVPC A、保護対象のEC2をVPC Bへ配置しました。
接続方式に指定はありません。VPC Peering、Transit Gateway、VPN、Direct Connectなど、利用環境に適した方法で通信経路を用意し、ルートテーブル、セキュリティグループ、Network ACL、DNSを含めて、保護方式で必要となるコンポーネント間の到達性を確認してください。必要な通信先は保護対象によって異なります。具体的なAWSネットワークの構築方法は本記事の対象外です。

4.5 セキュリティグループの考え方

検証環境であっても、SSHやRDPを0.0.0.0/0へ開放する構成は避けることが望ましいです。本記事では、用途ごとにセキュリティグループを分け、送信元をセキュリティグループ参照または管理端末の許可IPへ限定する前提で整理します。

通信	代表的な許可方法
クラスターノード間	クラスター用セキュリティグループ自身を送信元に指定し、全トラフィックを許可する。または公式のノード間通信ポート要件を参照して適切に許可する。
Control VM → ノード	TCP 443とTCP 22を、Control VM用セキュリティグループから許可する。
管理端末 / 踏み台 → Cohesity UI	TCP 443を、管理用セキュリティグループまたは限定した管理元CIDRから許可する。
踏み台へのSSH / RDP	管理者の固定IP、VPN、社内ネットワークなど、信頼できる送信元に限定する。
その他のワークロード通信	保護対象やリストア方式に応じ、CohesityのManage Firewall Portsを参照して追加する。

5. IAMとS3の準備

5.1 本記事で使用するIAMユーザー

本記事では、CLIデプロイからS3登録、EC2のバックアップ / リストア確認までをIAMユーザー方式で進めます。DataProtect for Cloudでは用途ごとに必要な権限が異なるため、次のIAMユーザーを用意します。
デプロイ前に必要なのは「クラスター構築用」と「S3アクセス用」の2ユーザーです。最後にEC2のバックアップ / リストアを確認するため、「保護ソース用」のユーザーも別途用意します。

IAMユーザー	用意する タイミング	役割	認証情報を使用する場所
クラスター構築用	デプロイ前	Control VMからCloudFormation、EC2、EBS、IAM関連リソースを 作成・管理する。	設定JSONの aws_credentials_access_key_id / aws_credentials_secret_access_key
S3アクセス用	デプロイ前	保護データのダウンティア先S3をExternal Targetとして 登録し、オブジェクトを読み書きする。	設定JSONの cohesity_aws_external_target 内
保護ソース用	バックアップ確認前	AWS環境をソース登録し、EC2などの対応リソースを 検出・保護・リストアする。	Cohesity UIのAWSソース登録画面

5.2 公式ポリシーからIAMユーザーを作成する

IAMポリシーとIAMユーザーの作成方法自体はAWSの基本操作となるため、ここではDataProtect for Cloudで使用する公式の権限定義と作成の流れを整理します。

1. 利用目的に対応するCohesity公式の権限定義を開き、ポリシーJSONを確認します。
2. AWS IAMでポリシーを作成し、JSONエディターへ公式JSONを貼り付けて保存します。
3. IAMユーザーを作成し、「ポリシーを直接アタッチする」から作成したポリシーを割り当てます。

用途	参照する公式権限定義	本記事での使い方
クラスター構築用	NGCEAWS_Deployment_Helios_Regular.json	設定JSONへ アクセスキーを入力し、Control VMからクラスターをデプロイします。
S3アクセス用	Minimum Permissions for Registering External Targets（S3）	設定JSONの cohesity_aws_external_target へアクセスキーを入力します。
バックアップ用	AWS and AWS GovCloud Permissions	AWSソース登録画面へアクセスキーを入力します。

公式JSONをIAMポリシーへ設定

作成したポリシーをIAMユーザーへ直接アタッチ

5.3 アクセスキーは安全に保管する

各IAMユーザーでアクセスキーIDとシークレットアクセスキーを作成します。シークレットアクセスキーを確認できるのは作成直後のみです。用途が分かる説明タグを付け、安全なパスワード管理基盤などへ保存してください。

IAMユーザー	アクセスキーの入力先
クラスター構築用	設定JSON：aws_credentials_access_key_id / aws_credentials_secret_access_key
S3アクセス用	設定JSON：cohesity_aws_external_target 内の access_key_id / secret_access_key
保護ソース用	Cohesity UI：AWSソース登録時のAccess Key ID / Secret Access Key

アクセスキーの保存

5.4 保護データ用S3バケットを作成する

DataProtect for Cloudへ取り込まれたデータは、クラスターノードのEBSへ一時的にキャッシュされた後、Amazon S3へダウンティアされます。保護データ用バケットは、次の条件で作成します。

• DataProtect for Cloudクラスターと同じAWSリージョンに作成する
• 他用途と共用せず、Cohesity専用のバケットとする
• S3 Gateway Endpointを利用する場合は、バケットポリシーとEndpointポリシーも確認する

6. 設定JSONの作成

6.1 編集前に設定値を集める

Control VMに用意されている dpcloud_cluster_config_params.json を編集する前に、入力に必要な値をAWS環境とCohesityからの案内メールから集めます。AWS側の作成方法は問いませんが、次の情報がそろっていないと設定JSONを完成させることができません。

収集する情報	確認元	対応する主なJSON項目
デプロイ先リージョン / AZ	AWSコンソール、 AMI利用申請内容	cohesity_aws_region / cohesity_aws_zone
クラスター構築用IAM のアクセスキー	IAMユーザーのセキュリティ認証情報	aws_credentials_access_key_id / aws_credentials_secret_access_key
S3アクセス用IAMの アクセスキー	IAMユーザーのセキュリティ認証情報	cohesity_aws_external_target 内
クラスターノード用AMI ID	Cohesityからの返信メール	cohesity_aws_ami_id
VPC ID / プライベート サブネットID	AWS VPC	cohesity_aws_vpn_vpc_id / cohesity_aws_vpn_subnet_id
セキュリティグループID	Amazon EC2 / VPC	cohesity_aws_security_group_id
クラスター名 / ノード名 プレフィックス	任意の命名規則	cohesity_aws_cluster_name / cohesity_aws_vm_prefix
ノード数 / IP割り当て方式	構成設計 / サブネット	cohesity_aws_num_vms / cohesity_aws_vm_ip_addresses
DNS / NTP / ドメイン / ホスト名	組織のネットワーク設定	cohesity_aws_dns_server / cohesity_aws_ntp_servers など
アプリ基盤用サブネット / マスク	利用環境のアドレス設計	cohesity_aws_apps_subnet / cohesity_aws_apps_subnet_mask
構成ID / Intel・AMD / 暗号化方針	サイジング結果 / セキュリティ方針	cohesity_aws_cluster_config_id など
保護データ用S3バケット名 / リージョン / Tier	Amazon S3	cohesity_aws_external_target
IAMリソース名 プレフィックス / タグ	組織の命名・タグ規則	cohesity_aws_iam_resources_prefix / cohesity_aws_tags

6.2 各プロパティに入力する値

ここからは、サンプルJSONに含まれる主なプロパティを用途別に整理します。「確認元 / 注意点」まで確認し、単に値を埋めるのではなく、利用環境の構成と一致していることを確認してください。

認証・リージョン・ノード情報

プロパティ	入力する値	確認元 / 注意点
aws_credentials_access_key_id	クラスター構築用IAMユーザーのAccess Key ID。	クラスターノードを作成する際に使用。本記事のIAMユーザー方式で設定します。
aws_credentials_secret_access_key	クラスター構築用IAMユーザーのSecret Access Key。	JSONへ平文で記載されるため、ファイルの管理に注意します。
aws_credentials_iam_role_arn	IAMロール方式で使用するCohesityCERoleなどのARN。	本記事のIAMユーザー方式では使用しません。
cohesity_aws_region	クラスターを稼働させるAWSリージョン。	AMI利用申請で指定したリージョンと一致させます。
cohesity_aws_zone	クラスターノードを配置するAvailability Zone。	指定するプライベートサブネットのAZと一致させます。
cohesity_aws_cluster_name	Cohesity UI / CLIへ表示するクラスター名。	最大63文字。英数字とハイフンを使用でき、ハイフンは先頭・末尾に使用しません。
cohesity_aws_num_vms	クラスターを構成するノード数。	本記事は3。本番用途は3ノード以上が必要です。
cohesity_aws_vm_ip_addresses	固定割り当てするノードIPを カンマ区切りで指定。	ノード数と同じ数を指定。動的割り当てでは値を空にせず、プロパティを行ごと削除します。
cohesity_aws_vm_prefix	クラスターノードのEC2名に使用するプレフィックス。	後ろにVM01、VM02、VM03のような文字列が付加されます。
cohesity_aws_ami_id	Cohesityから案内された クラスターノード用AMI ID。	Control VM用AMI IDと混同しないでください。

VPC・DNS・NTP・内部ネットワーク

プロパティ	入力する値	確認元 / 注意点
cohesity_aws_vpn_vpc_id	クラスターノードを配置するVPC ID。	AWS VPCの詳細画面から 確認します。
cohesity_aws_vpn_subnet_id	クラスターノードを配置する プライベートサブネットID。	指定したAZと一致し、3ノード分のIPを確保できることを確認します。
cohesity_aws_security_group_id	クラスターノードへ適用する セキュリティグループID。	ノード間通信、Control VMからのTCP 22/443、管理用TCP 443などを許可します。
cohesity_aws_dns_server	クラスターが使用する DNSサーバーのIPアドレス。	複数の場合はカンマ区切り。AD DNSを使う場合は先頭に指定します。NTPや必要な名前を解決できることを確認します。
cohesity_aws_ntp_servers	クラスターが使用する NTPサーバーのIPまたはFQDN。	外部NTPは複数指定。内部NTPを使う場合は内部サーバー1台のみとし、外部NTPと混在させません。
cohesity_aws_domain_name	クラスターで使用するドメイン名。 今回の検証では"aws.local"を使用しました。	利用環境のドメイン設計に合わせて入力します。
cohesity_aws_host_name	クラスターノードIPに解決されるホスト名、またはノードのIP。	FQDNを用意する場合はDNS登録と解決を確認します。
cohesity_aws_apps_subnet	Kubernetesアプリ基盤で使用する内部オーバーレイ用のプライベートIPv4ネットワーク。 検証では"192.168.0.1"を入力しました。	AWSの配置先サブネットとは別の用途です。VPC、接続先VPC、オンプレミスなど既存ネットワークと重複しない範囲を指定します。
cohesity_aws_apps_subnet_mask	上記アプリ基盤用サブネットのサブネットマスク。 検証では"255.255.255.0"を入力しました。	cohesity_aws_apps_subnetと対になる値を入力します。

クラスター構成・暗号化・セキュリティ

プロパティ	入力する値	確認元 / 注意点
cohesity_aws_permission_boundary_arn	IAM Permissions Boundaryを使用する場合のARN。	使用しない場合は""と入力します。
cohesity_aws_enable_cluster_encryption	クラスター全体のソフトウェア暗号化をtrue / falseで指定。	引用符で囲みません。有効化後は無効にできないため、作成前に方針を決めます。
cohesity_aws_cluster_size	nextGen を指定。	DataProtect for Cloud on AWSの固定値です。
cohesity_aws_cluster_config_id	Entry=1、Core=2、Archive=3、Performance=4。	本記事のEntry構成は1です。サイジング結果に合わせて選択します。
aws_cluster_instance_family_type	intel または amd。	本記事はintel。空欄時はintelが選択されます。
cohesity_aws_iam_resources_prefix	クラスター作成時に生成されるIAMリソース名のプレフィックス。	組織の命名規則に合わせます。既存リソースとの重複を避けます。
cohesity_aws_enforce_imdsv2	IMDSv2を強制する場合はtrue。	引用符で囲みません。セキュリティの観点からtrueを推奨します。
aws_instance_deletion_protection	EC2インスタンスの削除保護を有効化する場合はtrue。	引用符で囲みません。検証後に削除する場合は運用を考慮して選択します。
aws_gov_cloud	AWS GovCloudへデプロイするかをtrue / falseで指定。	通常のAWSリージョンではfalse。引用符で囲みません。

S3・タグ

プロパティ	入力する値	確認元 / 注意点
cohesity_aws_s3_bucket_name	21ノード以上の大規模CloudFormationテンプレートを一時配置する既存S3バケット名。	20ノード以下では空文字 ""。保護データのダウンティア先ではありません。
cohesity_aws_tags	クラスターノードへ付与するAWSタグのkey / value。	組織のタグ規則に合わせ、JSON配列で指定します。
cohesity_aws_external_target.access_key_id	S3アクセス用IAMユーザーのAccess Key ID。	クラスター構築用IAMのキーではありません。
cohesity_aws_external_target.secret_access_key	S3アクセス用IAMユーザーのSecret Access Key。	編集済みJSONの管理に注意します。
cohesity_aws_external_target.region_name	ダウンティア先S3バケットのリージョン名。	クラスターと同じリージョンを推奨します。
cohesity_aws_external_target.bucket_name	保護データのダウンティア先となるCohesity専用S3バケット名。	cohesity_aws_s3_bucket_nameとは用途が異なります。
cohesity_aws_external_target.tier_type	Amazon-S3-standard または Amazon-S3-Intelligent。	利用バージョンでサポートされるStorage Tierを確認します。

6.3 入力時に迷いやすいポイント

動的IP割り当てでは、cohesity_aws_vm_ip_addresses を空文字にしない 値を空にするとノード数とIP数が一致しないエラーになります。動的割り当てではプロパティ自体を削除します。

IAMユーザー方式とIAMロール方式の項目を混在させない 本記事ではIAMロールARNは使用しません。

true / falseは引用符で囲まない 暗号化、IMDSv2、削除保護、GovCloudなどの真偽値はJSONのtrueかfalseとして入力します。

cohesity_aws_s3_bucket_nameはダウンティア先ではない 20ノード以下の本記事では "" を指定します。ダウンティア先は cohesity_aws_external_target で設定します。

apps_subnetはAWSのプライベートサブネットではない Cohesity内部のKubernetesアプリ基盤用です。既存のネットワークと重複しないアドレス範囲を選択します。

Control VM同梱サンプルを最優先する プロパティはDataProtectのバージョンで追加・変更されることがあります。

7. Control VMの起動とクラスターのデプロイ

7.1 Control VMをプライベートサブネットへ起動する

AWSマネジメントコンソールでEC2の「インスタンスを起動」を開き、「自分のAMI」からCohesityに共有されたControl VM用AMIを選択します。クラスターノード用AMIではないことを確認してください。

設定項目	本検証の設定
インスタンスタイプ	t2.small
VPC / サブネット	DataProtect for Cloud用VPCのプライベートサブネット
パブリックIP	割り当てない
セキュリティグループ	踏み台からのSSH、クラスターノードへのTCP 22/443、必要なアウトバウンドを許可
キーペア	Control VM AMIに組み込まれたcohesityアカウントとCohesityから案内されたパスワードを使用するため、キーペアなしで起動

共有AMIからControl VMを選択

VPC、プライベートサブネット、セキュリティグループを設定

7.2 踏み台からControl VMへSSH接続する

Control VMにパブリックIPは付与しないため、同じネットワークから到達可能なLinux踏み台、VPN、Session Manager相当の管理経路などを利用して接続します。本検証ではLinux踏み台を使用しました。

接続時に、Cohesityから案内されたControl VMのcohesityアカウント用パスワードを入力します。設定JSONの編集が完了したら保存します。

7.3 事前検証後にクラスターを作成する

create_clusterコマンドを実行する前に、validate_clusterコマンドで設定JSONを検証します。入力ミスを完全に防げるわけではありませんが、設定値の不整合を早い段階で確認できます。

コマンドを実行すると、Control VM上のセットアップユーティリティがCloudFormationスタックを作成し、クラスターノードやEBSなどの展開を開始します。AWSマネジメントコンソールのCloudFormationから、スタックのEventsとResourcesを確認すると、どのリソースまで作成されたかを追跡できます。

7.4 3台のクラスターノードとIPアドレスを確認する

CloudFormationの処理が完了したら、EC2のインスタンス一覧を開きます。cohesity_aws_vm_prefixで指定したプレフィックスにVM01、VM02、VM03を組み合わせた3台のクラスターノードが作成されていることを確認します。

3台のクラスターノードを確認

3台すべてのステータスチェックが完了したら、いずれかのノードを選択してプライベートIPv4アドレスを確認します。このIPアドレスを、Cohesity UIへの初回アクセスに使用します。

ノードのプライベートIPv4アドレスを確認

8. 初回ログイン後の設定

8.1 EULA、ライセンス、管理者パスワード

クラスターノードへ到達できる管理端末から、ブラウザーで[https://<クラスターノードのプライベートIP>]を開きます。初回はデフォルトの管理者アカウント [admin / admin]でログインします。

初回ログイン画面

ログイン後、EULAへ同意し、事前に入手したライセンスを適用します。その後、adminアカウントのパスワード変更が求められるため、組織のパスワードポリシーに沿った値へ直ちに変更します。

adminパスワードを変更

8.2 管理方法を選択する

クラスターはローカルのCohesity UIから管理できます。必要に応じてHeliosへ接続し、SaaSから統合管理することも可能です。本検証ではHeliosへの接続を選択しましたが、Heliosへの接続はクラスターを利用するための必須条件ではありません。組織の接続ポリシーと運用方式に合わせて選択してください。

クラスターの管理方法を選択

DataProtect for Cloudのダッシュボード

8.3 設定したS3がExternal Targetとして登録されていることを確認する

設定JSONの cohesity_aws_external_target へ指定したS3バケットが、Infrastructure > External Targets に登録されていることを確認します。本記事ではDataProtect共通のStorage Domain設計やExternal Targetの運用設定までは扱いません。S3が表示されない場合は、JSONのバケット名・リージョン・S3アクセス用IAMの認証情報と権限を確認してください。

External Targetの確認

9. EC2のバックアップ / リストア確認

ここからは、構築したDataProtect for CloudでEC2のバックアップ / リストアが行えることを確認します。Cohesity共通のProtection GroupやPolicyの設計は前提知識として扱い、AWS環境のソース登録、バックアップの成功、EC2としてのリストア結果のみを確認します。

9.1 EC2バックアップの処理イメージ

本検証で確認したEC2バックアップでは、CohesityはAWSのEBSスナップショットを利用してデータを取得します。保護対象EC2にアタッチされたEBSボリュームのスナップショットを取得し、スナップショットから一時的なEBSボリュームを作成します。そのボリュームを、データ読み取りを担うFleetインスタンスへアタッチし、FleetインスタンスがデータをCohesityクラスターへ転送します。

EBSボリュームは同一AZのEC2インスタンスへアタッチする必要があるため、Fleetインスタンスの配置やAWS側の到達性もバックアップ処理に影響します。ワークロードや保護方式に応じた詳細なネットワーク要件を確認してください。

9.2 AWS環境をソースとして登録する

Data Protection > Sources > Virtual MachinesからAWS環境を登録します。本検証ではSource Typeに「AWS: IAM User/Role」、Authentication Methodに「IAM User」を選択し、事前に作成しておいたバックアップ用IAMユーザーの認証情報を設定しました。

AWSをIAMユーザー方式でソース登録

Cohesityは設定されたIAMの権限を使用してAWSへアクセスし、その権限で参照可能かつDataProtect for CloudがサポートするEC2などのリソースを検出します。登録後は、Cohesity UIに表示されたリソースから、保護したい対象を個別に選択できます。

IAM権限の範囲で検出されたAWSリソース

9.3 Protection Groupを作成する

New ProtectionからAWSソースを開き、バックアップ対象のEC2を選択します。

保護対象に設定するEC2 / EBSを選択

通常はアタッチされたすべてのEBSボリュームが対象になりますが、編集アイコンからバックアップするボリュームを個別に選択することもできます。

バックアップ対象のボリュームを選択

Protection GroupとPolicyを設定

対象の配下へ今後追加されるリソースも自動保護したい場合は、Auto Protectを利用することもできます。リージョンやアカウント単位で保護範囲を設計する際に有効ですが、意図しないリソースまで保護しないよう対象範囲を確認してください。

Protection Group名とPolicyを設定し、Protectをクリックします。初回バックアップが開始され、本検証ではAWS上にFleetインスタンスが一時的に自動で起動することも確認できました。

バックアップ中に起動したFleetインスタンス

バックアップジョブの成功を確認

9.4 EC2としてリストアする

Recoveryから対象のスナップショットを選び、復元先、EC2インスタンス名、起動状態、ネットワーク、セキュリティグループなどのRecovery Optionsを設定します。設定内容を確認し、Recoverを実行します。

Recovery Optionsを設定

RecoveryのStatusがSucceededへ変わった後、AWSマネジメントコンソールで、指定した条件のEC2インスタンスが作成されていることを確認しました。本検証ではEC2インスタンスの作成までを確認していますが、本番導入前にはOS起動、アプリケーション整合性、データ内容、接続性まで含めた復旧テストを行ってください。

RecoveryがSucceededになったことを確認

10. 実際に構築して感じたポイント

必要なAWSリソースと設定値がそろっていれば、Control VM上で設定JSONを整え、セットアップユーティリティを実行することで、3台のクラスターノードとEBSがCloudFormationから自動展開されます。ノードを一台ずつ手作業で構築する必要はなく、デプロイの仕組みそのものはシンプルです。

また、デプロイ後のソース登録、Protection Group、バックアップ、リストアといった基本操作は、オンプレミス版のCohesityを利用したことがある方であれば、大きな違和感なく扱えると感じました。

一方、今回の検証で最も時間を要したのは、DataProtect for Cloudそのものではなく、その周辺となるAWSネットワークの設計でした。

クラスターを配置するVPCとサブネットを用意するだけでなく、AWS API、Amazon S3、DNS、NTP、Helios、さらに保護方式に応じて利用されるコンポーネントまで含め、必要な通信を全体として整理する必要があります。

本検証では、DataProtect for Cloudと保護対象EC2を異なるVPCに配置しました。このような構成では、VPC間の接続方式だけを確認すればよいわけではありません。双方のルートテーブル、セキュリティグループ、Network ACL、名前解決を順番に確認し、デプロイ、バックアップ、リストアの各処理で必要となるコンポーネント間の通信が成立していることを確認する必要があります。

Cohesity UIへログインできることは、あくまで管理経路が確保されていることを示すものです。デプロイやデータ保護に必要なすべての通信が成立しているとは限らないため、処理ごとに必要となる通信先と経路を確認することが重要です。

実運用では、Cohesity管理者とAWS管理者が別の担当者となるケースも少なくありません。Cohesity管理者がAWS環境のすべてを自ら構築できる必要はありませんが、必要なAWSリソース、通信先、通信方向、ポート、名前解決、S3の要件を整理し、保護方式とあわせてAWS管理者へ正確に伝えられることが、スムーズな導入につながります。

11. おわりに

長編の記事となりましたが、最後までお読みいただきありがとうございました。

本記事を参考に、Cohesity管理者とAWS管理者が要件を整理し、それぞれの環境に合った構成でDataProtect for Cloudのデプロイを進めていただければ幸いです。

本記事と併せておすすめ記事に記載のHeliosを用いたデプロイ記事もチェックいただくことでどちらが作業しやすいかなど比較いただけるかと思います。

C&S ENGINEER VOICEでは、Cohesityをはじめ、さまざまな製品の技術情報を発信しています。
気になる製品や技術について情報収集される際には、ぜひC&S ENGINEER VOICEもご活用ください。