メニュー
Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

Linux の EBS ボリュームのサイズ、IOPS、またはタイプの変更

Amazon EBS ボリュームが現行世代の EC2 インスタンスタイプにアタッチされている場合は、それをデタッチすることなく、ボリュームサイズの増加、ボリュームタイプの変更、または (io1 ボリュームの場合) IOPS パフォーマンスの調整を行うことができます。これらの変更は、デタッチしたボリュームにも適用できます。現行世代のインスタンスタイプの詳細については、「現行世代のインスタンス」を参照してください。

前の世代のインスタンスタイプを使用している場合や、ボリュームの変更を試みているときにエラーが発生した場合は、「付録: EBS ボリュームを変更するためのインスタンスの起動と停止」の手順に従います。

一般的に、ボリュームの変更には以下のステップが必要です。

  1. 変更コマンドを発行します。詳細については、コンソールからの EBS ボリュームの変更 および コマンドラインからの EBS ボリュームの変更 を参照してください。

  2. 変更の進行状況をモニタリングします。詳細については、「ボリューム変更の進行状況のモニタリング」を参照してください。

  3. ボリュームのサイズが変更された場合、増加されたストレージ容量を利用するには、ボリュームのファイルシステムを拡張します。詳細については、「ボリュームサイズ変更後の Linux ファイルシステムの拡張」を参照してください。

さらに、Amazon CloudWatch EventsAWS CloudFormation を使用して、ボリュームの変更に関連付けられたアクションを自動化できます。

ボリュームの設定を変更するための料金は発生しません。変更を起動すると新しいボリューム設定料金が課金されます。詳細については、「Amazon EBS 料金表」ページの「Amazon Elastic Block Store」セクションを参照してください。

詳細については、「EBS ボリュームの変更に関する考慮事項」を参照してください。

重要

重要なデータを含むボリュームを変更する前に、変更をロールバックする必要がある場合に備えて、ボリュームのスナップショットを作成するのがベストプラクティスです。EBS スナップショットの詳細については、「Amazon EBS スナップショットの作成」を参照してください。

コンソールからの EBS ボリュームの変更

次の手順では、Amazon EC2 コンソールから利用可能なボリュームの変更を適用する方法を示します。

  1. https://console.aws.amazon.com/ec2/) にある Amazon EC2 コンソールを開きます。

  2. [Volumes] を選択し、変更するボリュームを選択して [Actions]、[Modify Volume] の順に選択します。

  3. [Modify Volume] ウィンドウに、ボリューム ID とボリュームの現在の設定 (タイプ、サイズ、IOPS など) が表示されます。これらの設定のいずれかまたはすべてを 1 回のアクションで変更できます。新しい設定値を以下のように設定します。

    • タイプを変更するには、[Volume Type] の値を選択します。

    • サイズを変更するには、許可された整数値を [Size] に入力します。

    • ボリュームタイプとして [Provisioned IOPS (IO1)] を選択した場合は、許可された整数値を [IOPS] に入力します。

  4. 適用する変更のすべてを指定したら、[Modify]、[Yes] の順に選択します。

注記

ボリュームサイズを変更しても、ボリュームのファイルシステムを拡張して新しいストレージ容量を利用するまでは、実際の効果はありません。詳細については、「ボリュームサイズ変更後の Linux ファイルシステムの拡張」を参照してください。

コマンドラインからの EBS ボリュームの変更

次の例では、AWS CLI を使用してコマンドラインから EBS ボリュームを変更する方法を示します。デフォルト設定によっては、リージョンやアベイラビリティーゾーンなどの情報を指定する必要があります。変更対象のソースボリュームの ID と、アクションを実行するための適切なアクセス許可が必要です。io1 ボリュームが変更対象である場合は、プロビジョンド IOPS のレベルを指定する必要があります。複数の変更アクション (容量、IOPS、タイプの変更) を 1 つのコマンドで実行できます。

たとえば、EBS ボリュームを次のように設定します。

  • ボリューム ID: vol-11111111111111111

  • ボリュームサイズ: 100 GiB

  • ボリュームタイプ: gp2

ボリューム設定を以下のように変更できます。

  • ボリュームサイズ: 200 GiB

  • ボリュームタイプ: io1

  • プロビジョニングレベル: 10,000 IOPS

上記の変更を次のコマンドで適用します。

Copy
aws ec2 modify-volume --region us-east-1 --volume-id vol-11111111111111111 --size 200 --volume-type io1 --iops 10000

このコマンドにより、以下のような出力が返されます。

{
    "VolumeModification": {
        "TargetSize": 200,
        "TargetVolumeType": "io1",
        "ModificationState": "modifying",
        "VolumeId": "vol-11111111111111111",
        "TargetIops": 10000,
        "StartTime": "2017-01-19T22:21:02.959Z",
        "Progress": 0,
        "OriginalVolumeType": "gp2",
        "OriginalIops": 300,
        "OriginalSize": 100
    }
}

注記

ボリュームサイズを変更しても、ボリュームのファイルシステムを拡張して新しいストレージ容量を利用するまでは、実際の効果はありません。詳細については、「ボリュームサイズ変更後の Linux ファイルシステムの拡張」を参照してください。

ボリューム変更の進行状況のモニタリング

変更対象の EBS ボリュームは以下の状態を経過します。コンソール、CLI、API、SDK を問わず、ModifyVolume ディレクティブを発行すると、ボリュームは最初に Modifying 状態になり、次に Optimizing 状態になって、最後は Complete 状態になります。この時点で、ボリュームは追加の変更を適用できる状態になります。まれに、一時的な AWS エラーのために Failed 状態になる場合があります。この場合は、変更を再試行します。

通常、ボリュームが Optimizing 状態になってから、サイズの変更が完了して反映されるまでには数秒かかります。

パフォーマンス (IOPS) の変更は、設定の変更内容に応じて、完了するまでに数分から数時間かかる場合があります。

新しい設定が有効になるには最大 24 時間かかり、場合によっては (ボリュームが完全に初期化されていない場合など) それ以上かかることがあります。通常、完全に使用された 1 TiB ボリュームが新しいパフォーマンス設定に移行するまでには約 6 時間かかります。

ボリュームが optimizing 状態である場合、ボリュームのパフォーマンスはソースとターゲットの設定仕様の中間にあります。過渡的なボリュームのパフォーマンスは、ソースボリュームのパフォーマンスより劣ることはありません。 IOPS をダウングレードする場合、過渡的なボリュームのパフォーマンスは、ターゲットボリュームのパフォーマンス以上になります。

変更の進行状況をモニタリングするには、AWS マネジメントコンソール を確認するか、AWS EC2 API/CLI でボリュームの状態をクエリするか、Amazon CloudWatch Events に送信されるメトリクスにアクセスします。以下の手順で、これらのアプローチを示します。

コンソールから変更の進行状況をモニタリングするには

  1. https://console.aws.amazon.com/ec2/) にある Amazon EC2 コンソールを開きます。

  2. [Volumes] を選択し、確認するボリュームを選択します。ボリュームのステータスは、[State] 列に表示されます。次の例では、変更の状態が [completed] になっています。この状態情報は、詳細ペインの [State] フィールドにも表示されます。

  3. [State] フィールドの横にある情報アイコンを開いて、以下に示すように、最新の変更アクションに関する完了前と完了後の情報を表示します。

コマンドラインから変更の進行状況をモニタリングするには

  • describe-volumes-modifications を使用して変更の進行状況を表示します。この例では、上の vol-11111111111111111 ボリュームと別の vol-22222222222222222 ボリュームが呼び出されます。

    Copy
    aws ec2 describe-volumes-modifications --region us-east-1 --volume-id vol-11111111111111111 vol-22222222222222222

    このコマンドでは、以下のような出力が返されます。

    {
        "VolumesModifications": [
            {
                "TargetSize": 200,
                "TargetVolumeType": "io1",
                "ModificationState": "modifying",
                "VolumeId": "vol-11111111111111111",
                "TargetIops": 10000,
                "StartTime": "2017-01-19T22:21:02.959Z",
                "Progress": 0,
                "OriginalVolumeType": "gp2",
                "OriginalIops": 300,
                "OriginalSize": 100
            },
            {
                "TargetSize": 2000,
                "TargetVolumeType": "sc1",
                "ModificationState": "modifying",
                "VolumeId": "vol-22222222222222222",
                "StartTime": "2017-01-19T22:23:22.158Z",
                "Progress": 0,
                "OriginalVolumeType": "gp2",
                "OriginalIops": 300,
                "OriginalSize": 1000
            }
        ]
    }

describe-volumes-modificationsコマンドは、1 つ以上の VolumesModification オブジェクトを返します。この例で示す 2 つのうち最初の 1 つは、上に示した最初の modify-volume コマンドとほぼ同じです。ただし、追加の変更は適用されていません。

次の例では、リージョン内で変更の状態が optimizing または completed であるすべてのボリュームをクエリし、その結果をフィルタリングおよびフォーマットして 2017 年 2 月 1 日以降に開始された変更のみを表示します。

Copy
aws ec2 describe-volumes-modifications --filters Name=modification-state,Values="optimizing","completed" --region us-east-1 --query "VolumesModifications[?StartTime>='2017-02-01'].{ID:VolumeId,STATE:ModificationState}"

この場合、クエリは 2 つのボリュームに関する情報を返します。

[
    {
        "STATE": "optimizing",
        "ID": "vol-06397e7a0eEXAMPLE"
    },
    {
        "STATE": "completed",
        "ID": "vol-bEXAMPLE"
    }
]

CloudWatch イベント で変更の進行状況をモニタリングするには

CloudWatch イベント では、ボリューム変更イベントの通知ルールを作成してテキストメッセージを送信するか、Lambda 関数を実行することができます。

  1. https://console.aws.amazon.com/cloudwatch/にある CloudWatch コンソールを開きます。

  2. [Events]、[Create rule] の順に選択します。

  3. [Build event pattern to match events by service] で、[Custom event pattern] を選択します。

  4. [Build custom event pattern] で、コンテンツを次のコードに置き換えます。

    Copy
    { "source": [ "aws.ec2" ], "detail-type": [ "EBS Volume Notification" ], "detail": { "event": [ "modifyVolume" ] } }

    終了したら、[Save] を選択します。

    一般的なイベント出力は次のようになります。

    Body:
    {
       "version": "0",
       "id": "1ea2ace2-7790-46ed-99ab-d07a8bd68685",
       "detail-type": "EBS Volume Notification",
       "source": "aws.ec2",
       "account": "065441870323",
       "time": "2017-01-12T21:09:07Z",
       "region": "us-east-1",
       "resources": [
          "arn:aws:ec2:us-east-1:065441870323:volume/vol-03a55cf56513fa1b6"
       ],
       "detail": {
          "result": "optimizing",
          "cause": "",
          "event": "modifyVolume",
          "request-id": "auto-58c08bad-d90b-11e6-a309-b51ed35473f8"
       }
    }

ルールを使用して Amazon SNS で通知メッセージを生成するか、一致したイベントに応答して AWS Lambda 関数を呼び出します。

ボリュームサイズ変更後の Linux ファイルシステムの拡張

ファイルシステム固有のコマンドを使用して、ファイルシステムのサイズを、新しいボリュームの拡大したサイズに変更します。これらのコマンドは、拡張するボリュームがルートボリュームである場合にも機能します。ext2ext3、および ext4 ファイルシステムの場合、このコマンドは resize2fs です。XFS ファイルシステムの場合、このコマンドは xfs_growfs です。その他のファイルシステムの場合、ファイルシステムの拡張については、これらのファイルシステムに関する特定のドキュメントを参照してください。

使用しているファイルシステムが不明の場合は、file -s コマンドを使用して、デバイスのファイルシステムデータをリストできます。次の例は、Linux ext4 ファイルシステムと SGI XFS ファイルシステムを示しています。

Copy
[ec2-user ~]$ sudo file -s /dev/xvd* /dev/xvda1: Linux rev 1.0 ext4 filesystem data ... /dev/xvdf: SGI XFS filesystem data ...

注記

拡張するボリュームがパーティション分割されている場合は、ファイルシステムのサイズを変更する前に、パーティションのサイズを拡大する必要があります。この時点で追加のパーティションを割り当てることもできます。詳細については、「Linux パーティションを拡張する」を参照してください。

ボリュームが Optimizing 状態になり次第、ファイルシステムのサイズ変更を開始できます。

重要

重要なデータを含むファイルシステムを拡張する前に、変更をロールバックする必要がある場合に備えて、ファイルシステムを含むボリュームのスナップショットを作成するのがベストプラクティスです。EBS スナップショットの詳細については、「Amazon EBS スナップショットの作成」を参照してください。

ボリュームのパーティションのサイズ変更が必要かどうかを確認するには

  • インスタンスにアタッチされたブロックデバイスを一覧表示するには、lsblk コマンドを使用します。以下の例は、/dev/xvda/dev/xvdb/dev/xvdf という 3 つのボリュームを示しています。

    Copy
    [ec2-user ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 30G 0 disk └─xvda1 202:1 0 30G 0 part / xvdb 202:16 0 30G 0 disk /mnt xvdf 202:80 0 35G 0 disk └─xvdf1 202:81 0 8G 0 part

    ルートボリュームである /dev/xvda1 は、/dev/xvda のパーティションです。どちらもサイズが 30 GiB であることに注意してください。この場合、パーティションはデバイスの領域をすべて占有するので、サイズを変更する必要はありません。

    ボリューム /dev/xvdb は、パーティション分割されていないので、サイズを変更する必要はありません。

    ただし、/dev/xvdf1 は、35 GiB のデバイスに含まれる 8 GiB のパーティションであり、このボリュームには他にパーティションがありません。この場合、ボリュームの残りの領域を使用するには、パーティションをサイズ変更する必要があります。詳細については、「Linux パーティションを拡張する」を参照してください。パーティションのサイズを変更した後、次の手順に従って、パーティションのすべての領域を占有するようにファイルシステムを拡張できます。

Linux ファイルシステムを拡張するには

  1. SSH クライアントを使用して Linux インスタンスにログインします。Linux インスタンスへの接続の詳細については、「SSH を使用した Linux インスタンスへの接続」を参照してください。

  2. df -h コマンドを使用して、既存のファイルシステムディスク領域の使用状況をレポートします。この例では、/dev/xvda1 デバイスを 70 GiB に拡張済みですが、オペレーティングシステムには依然として元の 7.9 GiB ext4 ファイルシステムのみが表示されます。同様に、/dev/xvdf デバイスを 100 GiB に拡張済みですが、オペレーティングシステムには依然として元の 1.0 GiB XFS ファイルシステムのみが表示されます。

    Copy
    [ec2-user ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 8.0G 943M 6.9G 12% / tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/xvdf 1014M 33M 982M 4% /mnt
  3. ファイルシステム固有のコマンドを使用して、各ファイルシステムのサイズを新しいボリューム容量に変更します。

    Linux ext2ext3、または ext4 ファイルシステムの場合は、次のコマンドを使用して、拡張するデバイスの名前に置き換えます。

    Copy
    [ec2-user ~]$ sudo resize2fs /dev/xvda1 resize2fs 1.42.3 (14-May-2012) Filesystem at /dev/xvda1 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 5 Performing an on-line resize of /dev/xvda1 to 18350080 (4k) blocks. The filesystem on /dev/xvda1 is now 18350080 blocks long.

    XFS ファイルシステムの場合、まず XFS ユーザースペースツールをインストールします。

    Copy
    [ec2-user ~]$ sudo yum install xfsprogs

    その後、次のコマンドを使用して、ファイルシステムのマウントポイントに置き換えます (XFS ファイルシステムのサイズを変更するには、マウントする必要があります)。

    Copy
    [ec2-user ~]$ sudo xfs_growfs -d /mnt meta-data=/dev/xvdf isize=256 agcount=4, agsize=65536 blks = sectsz=512 attr=2 data = bsize=4096 blocks=262144, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 262144 to 26214400

    注記

    xfsctl failed: Cannot allocate memory エラーを受け取った場合、インスタンスの Linux カーネルの更新が必要になることがあります。詳細については、特定のオペレーティングシステムのドキュメントを参照してください。

    "The filesystem is already nnnnnnn blocks long. Nothing to do!" というエラーが発生した場合は、「Linux パーティションを拡張する」を参照してください。

  4. df -h コマンドを使用して、既存のファイルシステムディスク領域の使用状況をレポートします。この時点で、ext4 ファイルシステムについては 70 GiB、XFS ファイルシステムについては 100 GiB の完全な容量が示されます。

    Copy
    # df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 70G 951M 69G 2% / tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/xvdf 100G 45M 100G 1% /mnt

ヒント

ボリュームで増えた利用可能な領域がシステムに表示されない場合は、「Amazon EBS ボリュームの初期化」の説明に従ってボリュームを再初期化してみてください。

付録: EBS ボリュームを変更するためのインスタンスの起動と停止

前世代の Amazon EC2 を使用していて、ルート (ブート) ボリュームの変更が必要になった場合は、インスタンスを停止して変更を適用し、その後でインスタンスを再起動する必要があります。次に示す手順に従って、すべてのインスタンスタイプのすべての EBS ボリュームを変更できます。

インスタンスを停止して再度起動するときは、以下に注意してください:

  • インスタンスが VPC で実行されていてパブリック IPv4 アドレスがある場合には、このアドレスは解放されて、新しいパブリック IPv4 アドレスになります。インスタンスのプライベート IPv4 アドレスと Elastic IP アドレスは保持されます。

  • インスタンスを EC2-Classic で実行している場合、新しいパブリック IP アドレスとプライベート IPv4 アドレスが与えられ、インスタンスに関連付けられている Elastic IP アドレスの関連付けが解除されます。インスタンスを再起動したら、Elastic IP アドレスを再度関連付ける必要があります。

  • インスタンスが Auto Scaling グループにある場合、Auto Scaling はインスタンスを異常と判断して停止し、場合によってはそれを終了して代わりのインスタンスを起動します。これを防止するには、一時的にグループの Auto Scaling プロセスを停止できます。詳細については、Auto Scaling ユーザーガイド の「Auto Scaling プロセスの停止と再開」を参照してください。

  1. https://console.aws.amazon.com/ec2/) にある Amazon EC2 コンソールを開きます。

  2. ナビゲーションペインで [Instances] を選択し、ボリュームを拡張する対象のインスタンスを選択します。

  3. [Shutdown Behavior] が [Terminate] ではなく、[Stop] に設定されていることを確認します。

    1. インスタンスを選択します。

    2. コンテキスト (右クリック) メニューで、[Instance Settings]、[Change Shutdown Behavior] の順に選択します。

    3. [Shutdown behavior] を [Terminate] に設定した場合は、[Stop]、[Apply] の順に選択します。

      [Shutdown Behavior] が [Stop] に設定済みである場合は、[Cancel] を選択します。

  4. インスタンスを停止します。詳細については、「インスタンスの停止と起動」を参照してください。

    警告

    インスタンスを停止すると、インスタンスストアボリューム上のデータは消去されます。したがって、インスタンスストアボリューム上に維持したいデータがある場合は、必ず永続的ストレージにバックアップしてください。

  5. コンソールからの EBS ボリュームの変更」または「コマンドラインからの EBS ボリュームの変更」の説明に従って EBS ボリュームを変更します。

  6. インスタンスを再起動します。

    1. ナビゲーションペインで、[Instances] を選択し、再起動するインスタンスを選択します。

    2. コンテキスト (右クリック) メニューで、[Instance State]、[Start] の順に選択します。

    3. [Start Instances] ダイアログボックスで、[はい、開始します] を選択します。インスタンスが起動に失敗し、拡張したボリュームがルートボリュームの場合、元のボリュームと同じデバイス名 (例: /dev/sda1) を使用して、拡張したボリュームをアタッチしていることを確認してください。

インスタンスが起動したら、ファイルシステムのサイズを確認して、拡大したボリュームスペースをインスタンスが認識しているかどうか表示できます。Linux では、df -h コマンドを使用してファイルシステムのサイズを確認します。

Copy
[ec2-user ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 7.9G 943M 6.9G 12% / tmpfs 1.9G 0 1.9G 0% /dev/shm

新しく拡張したボリュームがサイズに反映されていない場合は、デバイスのファイルシステムを拡張して、インスタンスで新しいスペースを使えるようにします。詳細については、「ボリュームサイズ変更後の Linux ファイルシステムの拡張」を参照してください。