Storage Gatewayのテープゲートウェイ入門

2021-12-182024-04-28

Storage Gatewayのテープゲートウェイ入門

AWS SOAの出題範囲の1つでもある、信頼性とビジネス継続性に関する内容です。

Storage Gatewayには4タイプありますが、今回はテープゲートウェイをご紹介します。
テープゲートウェイはVTL(Virtual Tape Library)およびテープアーカイブ機能を提供するものです。

テープゲートウェイは、既存のバックアップワークフローを変更することなく、オンプレミスの物理テープの使用から AWS の仮想テープに切り替えることができます。 (中略) テープゲートウェイが仮想テープを保存するのは、99.999999999% の耐久性を誇る Amazon S3、Amazon S3 Glacier、Amazon S3 Glacier Deep Archive といった AWS のサービスです。 (中略) テープゲートウェイは、すべての最新バックアップアプリケーションと統合可能です。そのため、これまで使用してきたバックアップやアーカイブのワークフローを何も変えることなく、クラウドストレージを使用したオンプレミスのバックアップやアーカイブを始めることができます。
テープゲートウェイ

またテープゲートウェイのプラットフォームは以下の5つから選択できます。

VMware ESXi
Microsoft Hyper-V
Linux KVM
Amazon EC2
ハードウェアアプライアンス
Snowball Edge

今回はEC2インスタンスをテープゲートウェイとして動作させます。

また今回の目的ですが、テープゲートウェイを通じて、VTLを操作するところまでを目標とします。

構築する環境

Diagram of introduction to Tape Gateway of Storage Gateway

プライベートサブネット内に2つのEC2インスタンスを作成します。

1つ目はテープゲートウェイとして動作します。
テープゲートウェイ用のAMIを使用して作成します。

2つ目はVTLを操作するクライアントとして動作します。
先述のテープゲートウェイを通じて、VTLにアクセスします。

テープゲートウェイインスタンス用に、Storage Gatewayエンドポイントを作成します。
本インスタンスがVPC外のVTLと接続するために使用します。

クライアントインスタンス用に、SSMとS3用のエンドポイントを作成します。
前者はSSM Session Manager経由で、本インスタンスにアクセスするために使用します。
後者はS3バケット上に構築されたyumリポジトリを通じて、テープデバイス操作用パッケージをインストールするために使用します。

環境構築用のCloudFormationテンプレートファイル

上記の構成をCloudFormationで構築します。
以下のURLにCloudFormationテンプレートを配置してます。

https://github.com/awstut-an-r/awstut-soa/tree/main/02/001

テンプレートファイルのポイント解説

テープゲートウェイインスタンス

インスタンス

Resources:
  StorageGatewayInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref PrivateSubnet
          GroupSet:
            - !Ref StorageGatewaySecurityGroup
Code language: YAML (yaml)

ImageIdプロパティでAMIを指定します。
今回は以下の値を指定することで、SSMパラメータストアに格納されているテープゲートウェイ用の最新AMI IDを取得します。

/aws/service/storagegateway/ami/VTL/latest

InstanceTypeプロパティでインスタンスクラスを指定します。
テープゲートウェイとして動作させるEC2インスタンスの要件の1つに、インスタンスクラスがあります。

AWS Storage Gateway は、特定の最小限の要件を満たしているインスタンスタイプでサポートされます。ゲートウェイが正しく機能するための最小要件を満たしている、m4.xlarge インスタンスタイプから始めることをお勧めします。
Amazon EC2 ホストにボリュームまたはテープゲートウェイをデプロイする

今回はm5a.xlargeを指定します。

EBS

Resources:
  StorageGatewayInstanceEBS1:
    Type: AWS::EC2::Volume
    Properties:
      AvailabilityZone: !Ref AZ
      Size: !Ref EBSSize
      VolumeType: gp3

  EBSAttachment1:
    Type: AWS::EC2::VolumeAttachment
    Properties:
      Device: /dev/sdf
      InstanceId: !Ref StorageGatewayInstance
      VolumeId: !Ref StorageGatewayInstanceEBS1

  StorageGatewayInstanceEBS2:
    Type: AWS::EC2::Volume
    Properties:
      AvailabilityZone: !Ref AZ
      Size: !Ref EBSSize
      VolumeType: gp3

  EBSAttachment2:
    Type: AWS::EC2::VolumeAttachment
    Properties:
      Device: /dev/sdg
      InstanceId: !Ref StorageGatewayInstance
      VolumeId: !Ref StorageGatewayInstanceEBS2
Code language: YAML (yaml)

テープゲートウェイとして動作させるEC2インスタンスの要件の1つに、追加ディスクの指定があります。
公式サイトでは、以下のように2つのディスクを用意する必要があるとされています。

キャッシュ(最小)：150GiB
アップロードバッファ(最小)：150GiB
Amazon EC2 ホストにファイルゲートウェイをデプロイする

それぞれEBSを作成し、テープゲートウェイインスタンスにアタッチします。
ただし今回は動作検証ということで、EBSのサイズを8GBに指定します。
最小要件を満たしてはいませんが、テープゲートウェイとして動作します。

セキュリティグループ

Resources:
  StorageGatewaySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-StorageGatewaySecurityGroup"
      GroupDescription: Allow Storage Gateway Traffic.
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: !Ref HTTPPort
          ToPort: !Ref HTTPPort
          SourceSecurityGroupId: !Ref InstanceSecurityGroup
        - IpProtocol: tcp
          FromPort: !Ref iSCSIPort
          ToPort: !Ref iSCSIPort
          SourceSecurityGroupId: !Ref InstanceSecurityGroup
Code language: YAML (yaml)

AWS公式によりますと、EC2インスタンスをテープゲートウェイとして動作させる場合、セキュリティグループで許可するべきインバウンド通信が2つ定められています。

iSCSI(3260/tcp)：インスタンスがVTLを操作する際に使用する。
HTTP(80/tcp)：EC2インスタンスをテープゲートウェイとしてアクティベーションするために使用する。

2つの通信の送信元には、後述のクライアントインスタンス用のセキュリティグループを指定します。

クライアントインスタンス

インスタンス

Resources:
  Instance:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref InstanceProfile
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref PrivateSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup
      UserData: !Base64 |
        #!/bin/bash -xe
        yum update -y
        yum install -y iscsi-initiator-utils
        yum install -y mt-st
        yum install -y mtxCode language: PHP (php)

ポイントはUserDataプロパティです。
ユーザーデータと呼ばれる機能で、インスタンス生成時に実行する処理を指定することができます。
ユーザーデータの詳細につきましては、以下のページをご確認ください。

今回は本プロパティに初期化処理として実行するコマンドを定義します。
実行する内容ですが、テープデバイスを操作するために必要なパッケージをインストールする処理となります。
以下のパッケージをインストールします。

iscsi-initiator-utils
mt-st
mtx

これらのパッケージをS3バケット上に構築されたyumリポジトリからインストールします。
詳細につきましては、以下のページをご確認ください。

セキュリティグループ

Resources:
  InstanceSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-InstanceSecurityGroup"
      GroupDescription: Deny All.
      VpcId: !Ref VPC
Code language: YAML (yaml)

特に何も設定しません。
今回の要件では、本インスタンスに対するインバウンド通信は発生しません。
あくまで本インスタンスからテープゲートウェイへのアウトバウンド通信のみです。

Storage Gateway用VPCエンドポイント

VPCエンドポイント

Resources:
  StorageGatewayEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PrivateDnsEnabled: true
      SecurityGroupIds:
        - !Ref StorageGatewayEndpointSecurityGroup
      ServiceName: !Sub "com.amazonaws.${AWS::Region}.storagegateway"
      SubnetIds:
        - !Ref PrivateSubnet
      VpcEndpointType: Interface
      VpcId: !Ref VPC
Code language: YAML (yaml)

VpcEndpointTypeプロパティには「Interface」を指定します。
VPCエンドポイントタイプにはゲートウェイタイプとインターフェースタイプがあります。
前者はS3およびDynamoDBと通信するために使用します。
後者はそれ以外のAWSサービスと通信するために使用します。
よって今回はStorage Gatewayと通信しますので、インターフェースタイプを意味する「Interface」となります。

PrivateDnsEnabledおよびServerNameプロパティですが、AWS公式サイトに従い設定します。

[サービス名] には [com.amazonaws.region.storagegateway] を選択します。例 com.amazonaws.us-east-2.storagegateway.

プライベート DNS 名を有効にする] が選択されていないことを確認します。
VPC でゲートウェイをアクティベートする

セキュリティグループ

Resources:
  StorageGatewayEndpointSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${Prefix}-StorageGatewayEndpointSecurityGroup
      GroupDescription: Allow Storage Gateway Traffic.
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: !Ref HTTPSPort
          ToPort: !Ref HTTPSPort
          SourceSecurityGroupId: !Ref StorageGatewaySecurityGroup
        - IpProtocol: tcp
          FromPort: !Ref StorageGatewayPort1
          ToPort: !Ref StorageGatewayPort1
          SourceSecurityGroupId: !Ref StorageGatewaySecurityGroup
        - IpProtocol: tcp
          FromPort: !Ref StorageGatewayPort2
          ToPort: !Ref StorageGatewayPort2
          SourceSecurityGroupId: !Ref StorageGatewaySecurityGroup
        - IpProtocol: tcp
          FromPort: !Ref StorageGatewayPort3
          ToPort: !Ref StorageGatewayPort3
          SourceSecurityGroupId: !Ref StorageGatewaySecurityGroup
        - IpProtocol: tcp
          FromPort: !Ref StorageGatewayPort4
          ToPort: !Ref StorageGatewayPort4
          SourceSecurityGroupId: !Ref StorageGatewaySecurityGroup
        - IpProtocol: tcp
          FromPort: !Ref StorageGatewayPort5
          ToPort: !Ref StorageGatewayPort5
          SourceSecurityGroupId: !Ref StorageGatewaySecurityGroup
Code language: YAML (yaml)

以下のAWS公式サイトに従い、合計6つのポートに対するインバウンド通信を許可します。

次の TCP ポートがすべてセキュリティグループで許可されていることを確認します。

TCP 443
TCP 1026
TCP 1027
TCP 1028
TCP 1031
TCP 2222
VPC エンドポイントを使用したゲートウェイの作成

許可する通信の送信元には、先述のゲートウェイインスタンス用のセキュリティグループを指定します。

環境構築

CloudFormationを使用して、本環境を構築し、実際の挙動を確認します。

CloudFormationスタックを作成し、スタック内のリソースを確認する

CloudFormationスタックを作成します。
スタックの作成および各スタックの確認方法については、以下のページをご確認ください。

各スタックのリソースを確認した結果、今回作成された主要リソースの情報は以下の通りです。

クライアントインスタンスのID：i-0205370d5c210e708
テープゲートウェイインスタンスのID：i-0f2d46c571fdd8b22
テープゲートウェイインスタンスのプライベートDNS名：ip-10-0-2-143.ap-northeast-1.compute.internal
Storage Gateway用のVPCエンドポイント：vpce-02536f2b50d39f32a-inqvg1ig.storagegateway.ap-northeast-1.vpce.amazonaws.com

AWS Management Consoleからもリソースを確認します。
テープゲートウェイインスタンスです。

Details of the EC2 instance acting as a Tape Gateway.

確かに2つのEBSがアタッチされていることがわかります。

テープゲートウェイからアクティベーションキーを取得する

CloudFormationによって、テープゲートウェイとなるEC2インスタンスの作成自体は完了しました。
ただし現在、インスタンスはテープゲートウェイとしては動作していません。
AWS公式サイトによりますと、インスタンスをゲートウェイとして動作させるためには、アクティベーションキーを取得する必要があるとされています。

ゲートウェイに接続するには、最初にゲートウェイ VM の IP アドレスまたはアクティベーションキーを取得します。IP アドレスまたはアクティベーションキーを使用して、ゲートウェイをアクティブ化します。 (中略) Amazon EC2 インスタンスにデプロイしてアクティブ化したゲートウェイの場合、Amazon EC2 コンソールから IP アドレスまたはアクティベーションキーを取得できます。
ゲートウェイへの接続

アクティベーションキーの取得方法ですが、対象インスタンスの特定のURLに、HTTPリクエストすることで取得できます。

ゲートウェイのアクティベーションキーを取得するには、ゲートウェイ VM にウェブリクエストを行います。アクティベーションキーが格納されているリダイレクトが返されます。
ゲートウェイのアクティベーションキーを取得する

アクティベーションキー取得のポイントが整理されましたので、実際に取得します。
以下の流れでアクティベーションキーを取得します。

クライアントインスタンスにアクセスする。
クライアントインスタンスからテープゲートウェイインスタンスにHTTPリクエストし、アクティベーションキーを取得する。

クライアントインスタンスへのアクセスはSSM Session Managerを使用します。
SSM Session Managerの詳細につきましては、以下のページをご確認ください。

% aws ssm start-session --target i-0205370d5c210e708

Starting session with SessionId: root-0b4a067cd35e64034
sh-4.2$
Code language: Bash (bash)

クライアントインスタンスにアクセスすることができました。

AWS公式ページを参考にして、クライアントインスタンスからテープゲートウェイインスタンスにHTTPリクエストを送ります。

sh-4.2$ curl 'http://ip-10-0-2-143.ap-northeast-1.compute.internal/?gatewayType=VTL&activationRegion=ap-northeast-1&vpcEndpoint=vpce-02536f2b50d39f32a-inqvg1ig.storagegateway.ap-northeast-1.vpce.amazonaws.com&no_redirect'
Q229E-KD8FM-FFHRR-6IU8I-K0VPU
Code language: Bash (bash)

レスポンスがありました。
「Q229E-KD8FM-FFHRR-6IU8I-K0VPU」がアクティベーションキーです。

テープゲートウェイをアクティベーションする

前項でアクティベーションキーを取得できましたので、テープゲートウェイ用インスタンスをアクティベーションします。
アクティベーションは、Storage Gatewayに関する権限を付与されたローカルマシンで実行します。

$ aws storagegateway activate-gateway \
--activation-key Q229E-KD8FM-FFHRR-6IU8I-K0VPU \
--gateway-name soa-02-001 \
--gateway-timezone "GMT+9:00" \
--gateway-region ap-northeast-1 \
--gateway-type VTL \
--tape-drive-type IBM-ULT3580-TD5 \
--medium-changer-type AWS-Gateway-VTL
Code language: Bash (bash)

重要なパラメータを取り上げます。
activation-keyには、先ほど取得したアクティベーションキーを指定します。
gateway-typeには、テープゲートウェイを意味する「VTL」を指定します。
tape-drive-typeおよびmedium-changer-typeはデフォルトの値である「IBM-ULT3580-TD5」と「AWS-Gateway-VTL」を指定します。

AWS Management Consoleでテープゲートウェイの作成状況を確認します。

ゲートウェイインスタンスがアクティベーションされ、テープゲートウェイが作成されています。

キャッシュ/アップロードバッファ設定

アクティベーションが済んだテープゲートウェイインスタンスに対して、ディスクの設定を行います。
テープゲートウェイとして動作させるために設定する必要があるディスクは、キャッシュ用とアップロードバッファ用の2つです。
対象となるストレージ自体はCloudFormationにてEBSを作成し、インスタンスにアタッチ済みです。

AWS Management Consoleからキャッシュおよびバッファの設定を行います。

「Configure cache storage」を押下します。

2つのディスクにそれぞれ「Cache」「Upload buffer」を指定します。
指定後、「Save changes」を押下します。

テープを作成する

最後にデータを保存する仮想テープを定義します。
今回は動作検証ということで、最小構成である100GiB(107374182400byte)のテープを1つ作成します。

AWS Management Consoleからテープを作成します。
テープページにアクセスします。

「Create tapes」を押下します。

「Gateway」に先ほど作成したテープゲートウェイを選択後、1つテープが作成されるように設定します。
「Pool」は通常のGlacierに保存されるように「Clacier Flexible Retrieval Pool」を選択します。

確かに1つのテープが作成されました。

仮想テープを操作する

準備が整いましたので、改めてクライアントインスタンスにアクセスします。

仮想テープを操作するために必要なパッケージ類のインストール状況を確認します。

sh-4.2$ yum list installed | grep mtx
mtx.aarch64                           1.3.12-14.amzn2.0.2            @amzn2-core

sh-4.2$ yum list installed | grep mt-st
mt-st.aarch64                         1.1-14.amzn2.0.2               @amzn2-core

sh-4.2$ yum list installed | grep iscsi
iscsi-initiator-utils.aarch64         6.2.0.874-7.amzn2              @amzn2-core
iscsi-initiator-utils-iscsiuio.aarch64
Code language: Bash (bash)

正常にインストールされています。
続けてテープゲートウェイを通じて、VTLにアクセスします。
以降の手順は、AWS公式で紹介されている手順に従い実行します。

まずiscsidを起動します。

sh-4.2$ sudo systemctl start iscsid

sh-4.2$ sudo systemctl status iscsid
● iscsid.service - Open-iSCSI
   Loaded: loaded (/usr/lib/systemd/system/iscsid.service; disabled; vendor preset: disabled)
   Active: active (running) since Sat 2022-06-11 02:14:22 UTC; 3s ago
     Docs: man:iscsid(8)
           man:iscsiadm(8)
  Process: 972 ExecStart=/usr/sbin/iscsid (code=exited, status=0/SUCCESS)
 Main PID: 974 (iscsid)
   CGroup: /system.slice/iscsid.service
           ├─973 /usr/sbin/iscsid
           └─974 /usr/sbin/iscsid

Jun 11 02:14:22 ip-10-0-2-11.ap-northeast-1.compute.internal systemd[1]: Starting Open-iSCSI...
Jun 11 02:14:22 ip-10-0-2-11.ap-northeast-1.compute.internal iscsid[972]: iSCSI logger with pid=973 started!
Jun 11 02:14:22 ip-10-0-2-11.ap-northeast-1.compute.internal systemd[1]: Failed to parse PID from file /var/run/iscsid.pid: Invalid argument
Jun 11 02:14:22 ip-10-0-2-11.ap-northeast-1.compute.internal systemd[1]: Started Open-iSCSI.
Jun 11 02:14:23 ip-10-0-2-11.ap-northeast-1.compute.internal iscsid[973]: iSCSI daemon with pid=974 started!
Code language: Bash (bash)

「active (running)」とありますので、正常に起動しました。

次にVTLデバイスターゲットを検索します。

sh-4.2$ sudo /sbin/iscsiadm \
--mode discovery \
--type sendtargets \
--portal ip-10-0-2-143.ap-northeast-1.compute.internal:3260
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-09
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-mediachanger
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-08
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-05
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-04
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-07
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-06
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-01
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-03
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-02
10.0.2.143:3260,1 iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-10

正常にメディアチェンジャーとテープドライブが検出されました。

続けてメディアチェンジャーとテープドライブの1つ(tapedrive-01)に接続します。

sh-4.2$ sudo /sbin/iscsiadm \
--mode node \
--targetname iqn.1997-05.com.amazon:sgw-3c52bb55-mediachanger \
--portal 10.0.2.143:3260,1 \
--login
Logging in to [iface: default, target: iqn.1997-05.com.amazon:sgw-3c52bb55-mediachanger, portal: 10.0.2.143,3260] (multiple)
Login to [iface: default, target: iqn.1997-05.com.amazon:sgw-3c52bb55-mediachanger, portal: 10.0.2.143,3260] successful.

sh-4.2$ sudo /sbin/iscsiadm \
--mode node \
--targetname iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-01 \
--portal 10.0.2.143:3260,1 \
--login
Logging in to [iface: default, target: iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-01, portal: 10.0.2.143,3260] (multiple)
Login to [iface: default, target: iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-01, portal: 10.0.2.143,3260] successful.Code language: JavaScript (javascript)

2デバイスのアタッチ状況を確認します。

sh-4.2$ ls -l /dev/tape/by-path
total 0
lrwxrwxrwx 1 root root  9 Jun 11 02:18 ip-10.0.2.143:3260-iscsi-iqn.1997-05.com.amazon:sgw-3c52bb55-mediachanger-lun-0-changer -> ../../sg0
lrwxrwxrwx 1 root root  9 Jun 11 02:19 ip-10.0.2.143:3260-iscsi-iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-01-lun-0 -> ../../st0
lrwxrwxrwx 1 root root 10 Jun 11 02:19 ip-10.0.2.143:3260-iscsi-iqn.1997-05.com.amazon:sgw-3c52bb55-tapedrive-01-lun-0-nst -> ../../nst0
Code language: Bash (bash)

正常にアタッチされていることがわかります。
/dev/sg0や/dev/st0等へのシンボリックリックであることがわかります。
以下のコマンドでデバイスIDを確認することができます。

sh-4.2$ ls -l /dev/tape/by-id
total 0
lrwxrwxrwx 1 root root  9 Jun 11 02:19 scsi-2334335324242353530310000 -> ../../st0
lrwxrwxrwx 1 root root 10 Jun 11 02:19 scsi-2334335324242353530310000-nst -> ../../nst0
lrwxrwxrwx 1 root root  9 Jun 11 02:18 scsi-2414d5a4e5f5347572d334335 -> ../../sg0
Code language: Bash (bash)

以降はメディアチェンジャーの操作を行います。
メディアチェンジャーの操作はmtxコマンドで行います。
まずメディアチェンジャー本体の状態を確認します。

sh-4.2$ sudo mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d334335 inquiry
Product Type: Medium Changer
Vendor ID: 'AWS     '
Product ID: 'Gateway-VTL     '
Revision: '0100'
Attached Changer API: No
Code language: Bash (bash)

確かに物理デバイスのようにアクセスできることがわかります。

次にテープドライブの状況を確認します。

sh-4.2$ sudo mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d334335 status | grep 'Data Transfer Element'
Data Transfer Element 0:Empty
Data Transfer Element 1:Empty
Data Transfer Element 2:Empty
Data Transfer Element 3:Empty
Data Transfer Element 4:Empty
Data Transfer Element 5:Empty
Data Transfer Element 6:Empty
Data Transfer Element 7:Empty
Data Transfer Element 8:Empty
Data Transfer Element 9:Empty
Code language: Bash (bash)

全てのドライブが空であることがわかります。

未使用のテープを確認します。

sh-4.2$ sudo mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d334335 status | grep -v Empty
  Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d334335:10 Drives, 3200 Slots ( 1600 Import/Export )
      Storage Element 1601 IMPORT/EXPORT:Full :VolumeTag=TESTD67E76
Code language: Bash (bash)

1601番目に未使用のテープがあることがわかります。
VolumeTagが「TEST67E76」であるからも、作成したテープであることがわかります。

未使用テープを0番目(tapedrive-01)のドライブに挿入します。

sh-4.2$ sudo mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d334335 load 1601 0
Loading media from Storage Element 1601 into drive 0...done
Code language: Bash (bash)

改めて全体のドライブの状況を確認します。

sh-4.2$ sudo mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d334335 status | grep -v Empty
  Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d334335:10 Drives, 3200 Slots ( 1600 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = TESTD67E76
Code language: Bash (bash)

確かに0番目のドライブが「Full」となり、先ほどのテープが挿入されていることがわかります。

テープが挿入されましたので、以降の手順はテープの操作に移ります。
テープへのアクセスはmtコマンドで行います。
まずテープの現状を確認します。テープへアクセスするためには、先ほど確認したpathのデバイス名を指定します。
今回は0番目のテープドライブ(tapedrive-01)にアクセスしますので、「/dev/st0」となります。

sh-4.2$ sudo mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 65536 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_ENCode language: JavaScript (javascript)

未使用ですので、もちろん何も書き込まれていません。

書き込み用のファイルを用意します。

sh-4.2$ echo 'hogehoge' > /home/ssm-user/test.txt
sh-4.2$ cat /home/ssm-user/test.txt
hogehoge
Code language: Bash (bash)

テープへのデータの書き込み/読み込みはtarコマンドで行います。
用意したファイルをテープに書き込みます。

sh-4.2$ sudo tar -cv --record-size=65536 -f /dev/st0 /home/ssm-user/test.txt
tar: Removing leading `/' from member names
/home/ssm-user/test.txt
Code language: Bash (bash)

書き込む際のポイントはrecord-sizeオプションです。これを指定しない場合、エラーが発生します。
指定するべき値はmtコマンでテープの状況を確認した際に「Tape block size 65536 bytes.」とありますので、これを指定します。
次にテープに書き込まれているファイルを確認します。

sh-4.2$ sudo tar -tv --record-size=65536 -f /dev/st0
-rw-r--r-- ssm-user/ssm-user 9 2022-06-11 02:25 home/ssm-user/test.txt
Code language: Bash (bash)

書き込まれたファイルの情報が確認できます。

最後にテープからデータを読み込みます。

sh-4.2$ sudo tar xvf /dev/nst0
home/ssm-user/test.txt

sh-4.2$ cat home/ssm-user/test.txt
hogehoge
Code language: Bash (bash)

取得することができました。
物理テープに対する操作と同様に、仮想テープにアクセスできました。

まとめ

Storage Gatewayの1種であるテープゲートウェイを作成しました。
EC2インスタンスから同ゲートウェイを通じて、VTLにアクセスし、物理テープと同様の操作で仮想テープに読み書きできることを確認しました。