Amazon Web Services ブログ

OracleデータベースでのAmazon EBS調整可能な容量の使用(パート1):紹介

昨年、私たちは調整可能なボリュームと呼ばれる新しいAmazon EBS 機能を開始しました。Amazon EBSの調整可能なボリュームを使用すると、ボリュームの使用中に、EBSボリュームのサイズを増やしたり、IOPSまたはボリュームのタイプを変更したりすることができます。この変更は操作に影響を与えなく、行うことができます。

この3つのブログ記事のシリーズでは、Oracleデータベースでの調整可能なボリュームを使用するメリットを検討します。また、調整可能なボリュームを使用してデータベースストレージを増やし、データベースの可用性または性能に影響を与えなく、準備されたIOPSを変更する方法についても説明します。

1番目の記事では、データベースストレージマネジメント用のロジカルボリュームマネージャー(LVM)のないオペレーティングシステムファイルシステムを使用して、Oracleデータベースで調整可能なボリュームを使用する方法について説明します。2番目の記事では、データベースストレージマネジメントにLVMを使用するOracleデータベースについて説明します。3番目の記事では、Oracle自動ストレージマネージャー(Oracle ASM)を使用するOracleデータベースについて説明します。

Amazon EBSの調整可能なボリュームの概要

調整可能なボリュームを使用すると、EBSボリュームの使用中に、EBSボリュームのサイズを増やしたり、準備されたIOPSを調整したり、EBSボリュームのタイプを変更したりすることができます。データベースはオンラインのままで、変更が有効になっている間に使用可能となっています。

AWS マネジメントコンソールから、簡単なAPI呼び出しを使用して、またはAWSコマンドラインインターフェース(AWS CLI)を使用して、ボリュームの変更を要求することができます。変更されるEBSボリュームは一連の状態を経過します。ボリュームの変更を要求すると、ボリュームは変更 状態になり、次に最適化状態になり、最後に完了状態になります。

EBSのボリュームのサイズの変更は、完了するまでに通常だと数秒がかかり、ボリュームが最適化状態になってから有効となります。パフォーマンス(IOPS)の変更には数分から数時間かかることがあり、構造の変更が行われたかどうかで決まります。EBSボリュームは最適化 状態になっていますが、ボリュームのパフォーマンスはソースとターゲットの構成仕様の間にあります。

Amazon EC2におけるOracleデータベースストレージレイアウト

Amazon EC2でOracleデータベースを実行する場合は、EBSボリュームをデータベースストレージに使用します。一般的に、高性能のデータベースワークロード用のio1ボリュームと、それよりもあまり要求のないその他のワークロード用のgp2ボリュームを選択します。IO1ボリュームは、遅延の影響を受けやすい取引ワークロード用に設計されており、ボリュームにあたり最大32,000 IOPSまで提供します。GP2ボリュームは、価格と性能のバランスが優れており、ベースラインIOPSは3 IOPS/GB、ボリュームにあたり最大10,000 IOPSを提供します。

Oracleデータベースの物理ストレージには、ディスクに格納されているファイルのセット(データ、一時的なファイル、再実行ファイル、制御ファイルなど)が含まれています。これらのファイルの作成および管理には、オペレーティング・システムのファイル・システム、LVM、またはOracle ASMを使用することができます。

単純なデータベースストレージ操作

このセクションでは、単一のEBSボリュームとオペレーティングシステムファイルシステム(LVMなし)をデータベースストレージに使用する単純なOracleデータベース用のAmazon EC2におけるストレージレイアウトについて簡単に説明します。次に、準備されたストレージを増やしたり、準備されたIOPSを変更したりすることなどといったOracleデータベースのストレージの変更が調整可能なボリュームの導入前にどのように行われたかについて説明します。私たちは、この変更に関連する問題点を説明します。最後に、調整可能なボリュームを例に、これらの問題点のいくつかを解決する方法をお教えします。

単純なデータベースのストレージレイアウト

単純なデータベースについて、データベースストレージ用に単一のEBSボリュームのみを使用する場合があります。データベースファイルを格納するには、データベースファイルを分割してファイルシステムを作成します。このシナリオでは、LVMを使用しません。次の図は、この単純なデータベースストレージレイアウトを示しています。

単純なデータベースストレージアーキテクチャ

調整可能ボリュームではないストレージ操作

データベースストレージ用の単一のEBSボリューム(LVMなし)を使用してストレージを増やしたり、またはシステム用に準備されたIOPSを変更したりすることができます。これを行うには、現在のEBSボリュームのスナップショットから目的のサイズとIOPSで新しいEBSボリュームを作成し、EBSボリュームをスワップします。この操作を行うには、次の手順を実行します。この操作には、データベースを停止する時間が必要です。

  • データベースを停止し、EBSボリュームのスナップショットを作成します。
  • スナップショットから求めたサイズとIOPSで新しいEBSボリュームを作成します。
  • 古いEBSボリュームをEC2インスタンスから切り離し、新しいEBSボリュームをEC2インスタンスに接続します
  • ファイルシステムのサイズを変更し(EBSのボリュームサイズが変更されている場合)、データベースを起動します。

調整可能なボリュームによる保管作業

EBSボリュームを変更するには、AWS CLIからの変更 - ボリュームコマンドまたはAWS マネジメントコンソールからの変更 – ボリュームオプションを使用します。その場合は、新しいボリュームサイズとIOPSを指定します。ボリュームサイズを変更せずに準備されたIOPSのみ変更する場合は、オペレーティングシステムレベルで変更する必要はありません。EBSボリュームのサイズを変更する場合は、ボリュームの変更後にファイルシステムのサイズを変更する必要があります。

EBSボリュームのサイズまたはIOPSを変更すると、データは自動的に複数のバックエンドデバイスに分散され、ホットスポットが発生しないようにしたり、準備されたIOPSを取得するようにします。

例:LVMを使用せずに単純なデータベースのストレージを増やす

このセクションでは、停止時間が無くても、オペレーティングシステムファイルシステムをストレージマネジメントに使用するOracleデータベース用に準備されたストレージを増やす方法を示します。このデモでは、Amazon Linuxの上で動作するOracle 12cデータベースを使用します。30-GiB EBSボリュームがインスタンスに接続され、Oracleデータベースストレージ用のファイルシステムが作成されます。このデモでは、停止時間がなく、30 GiBから60 GiBに準備されたストレージを増やします。

サイズ変更がデータベースの停止時間なしに実行されたことを示すため、evtestprocというデータベースストアドプロシージャを作成しました。このプロシージャは、レコードを10秒間隔でevtesttabというテーブルに挿入します。このプロシージャは、サイズ変更操作の実行中に行われます。レコードが10秒間隔でevtesttabテーブルに挿入されていることを確認して、データベースの停止時間なしにサイズ変更が完了したことを確認できます。

ステップ1:現在の設定を確認する

AWSマネジメントコンソールから、EBSボリュームのサイズを確認します。現在、次のスクリーンショットが示すように30 GiBです。

30GBのボリュームサイズを確認するコンソールスクリーンショット

注意:Amazon EBSボリュームを作成してEC2 インスタンスにアタッチする方法の詳細については、Amazon EC2ドキュメントを参照してください。

データファイルを格納するために、次のようにcustomdfというディレクトリを作成します。

[root@ip-172-31-55-62 ~]# mkdir -p /u01/app/oracle/oradata/cdb1/pdb1/customdf

以下に示すように、ファイルシステムを作成し、/u01/app/oracle/oradata/cdb1/pdb1/customdf/にマウントします。

[root@ip-172-31-59-102 ~]# mkfs -t ext4 /dev/nvme2n1
mke2fs 1.42.12 (29-Aug-2014)
7864320 4kブロックと1966080 iノードでファイルシステムを作成する
Filesystem UUID: f9702847-e6c5-4409-a710-139c15ee5043
ブロックに格納されたスーパーブロックバックアップ: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000

グループテーブルの割り当て:完了                            
iノードテーブルの作成:完了                            
ジャーナルの作成(32768ブロック):完了
スーパーブロックとファイルシステムアカウンティング情報の作成:完了   

 [root@ip-172-31-55-62 ~]# mount /dev/nvme2n1 /u01/app/oracle/oradata/cdb1/pdb1/customdfs/

ここでは、次のようにSQL * Plusを使用してEVテストテーブルスペースという20GBのテーブルスペースを作成します。

SQL> create tablespace  EVTestTableSpace datafile '/u01/app/oracle/oradata/cdb1/pdb1/customdfs/evtest.dbf' size 20000M;
作成されたテーブルスペース

次のようにdfコマンドを使用して、OSレベルでディスク使用率を確認できます。

[root@ip-172-31-59-102 ~]# df –h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         16G   48K   16G   1% /dev
tmpfs            16G     0   16G   0% /dev/shm
/dev/nvme0n1p1   40G   16G   24G  39% /
/dev/nvme2n1 30G 20G 8.4G 71% /u01/app/oracle/oradata/cdb1/pdb1/customdfs 

次に、新しく作成されたテーブルスペースのサイズとデータファイルの場所を次のスクリーンショットで示すように確認します。

サイズと場所を確認するスクリーンショット

ステップ2:ストアドプロシージャを設定する

以下は、evtesttabおよびその他の関連テーブルを作成、そして初期化するスクリプト、およびevtestprocストアドプロシージャの定義です。

//テストデータを格納するテーブルを作成する
CREATE TABLE evtesttab(counter NUMBER, seconds_elapsed NUMBER, data VARCHAR2(50));

//エラーメッセージを格納するテーブルを作成する
CREATE TABLE evtesterrortab(err_msg VARCHAR2(2000), time DATE);

//別のSQLセッションからのPL / SQLプロシージャの実行を中断するフラグを格納したテーブルを作成する 
CREATE TABLE flagtab(delflag VARCHAR2(2));

INSERT INTO flagtab VALUES('N'); //最初のレコードを挿入する

COMMIT;

 

/*****************************************************
PL / SQLは、「調整可能なボリューム」機能を使用してOracleデータベースストレージに使用されるAmazon EBSボリュームのライブサイズ変更をテストするためのプロシーシャを格納しました。

名前: evtestproc
******************************************************/

CREATE OR REPLACE PROCEDURE evtestproc
IS
  l_flag varchar2(2);
  l_cntr number default 1;
  l_sec number default 10;
  l_errmsg varchar2(350);
BEGIN
  WHILE true LOOP
    SELECT delflag into l_flag FROM flagtab;
    IF l_flag = 'Y'
    THEN
      EXIT;
    END IF;
    INSERT INTO evtesttab VALUES(l_cntr, l_sec, 'Record inserted at ' || to_char(SYSDATE, 'DD-MM-YY HH:MI:SS'));
    COMMIT;
    l_cntr := l_cntr + 1;
    l_sec := l_sec + 10;
    DBMS_LOCK.SLEEP(10);
  END LOOP;
EXCEPTION
  WHEN others THEN
    l_errmsg := SUBSTR(SQLERRM, 1, 300);
    INSERT INTO evtesterrortab VALUES(l_errmsg , SYSDATE);
    COMMIT;
END;

evtestprocストアドプロシージャを起動して、データベースに提供されたストレージを増やしながら、evtesttabテーブルにレコードを挿入します。

begin
  evtestproc(); // 10秒間隔
でレコードをEVTESTTABテーブルに挿入するPLSQLプロシージャ。

SQL Workbenchからテーブルを検索して、レコードが挿入されていることを確認します。

ステップ 3:EBSボリュームのサイズを変更する

AWS CLIを使用して、EBSボリュームのサイズを30 GiBから60 GiBに増やします。

$ aws ec2 modify-volume --region us-east-1 --volume-id vol-07c198d593a9dfae5 --size 60
{
    "VolumeModification": {
        "TargetSize": 60,
        "TargetVolumeType": "io1",
        "ModificationState": "modifying",
        "VolumeId": "vol-07c198d593a9dfae5",
        "TargetIops": 1000,
        "StartTime": "2018-03-01T13:11:33.224Z",
        "Progress": 0,
        "OriginalVolumeType": "io1",
        "OriginalIops": 1000,
        "OriginalSize": 30
    }
}

変更-ボリュームコマンドを出すと 、ボリュームはそれぞれ変更最適化完了 状態になります。この時点で、ボリュームは再び変更できる状態になります。サイズの変更は、完了するまでに通常だと数秒かかり、ボリュームが 最適化 状態になってから有効となります。

AWS CLIからの記述-ボリューム-変更 コマンドを使用して、ボリュームの変更状態を確認することができます。ボリュームが現在最適化状態になっていることを把握できます。

$ aws ec2 describe-volumes-modifications --region us-east-1 --volume-id vol-07c198d593a9dfae5
{
    "VolumesModifications": [
        {
            "TargetSize": 60,
            "TargetVolumeType": "io1",
            "ModificationState": "optimizing", 
            "VolumeId": "vol-07c198d593a9dfae5",
            "TargetIops": 1000,
            "StartTime": "2018-03-01T13:11:33.224Z",
            "Progress": 0,
            "OriginalVolumeType": "io1",
            "OriginalIops": 1000,
            "OriginalSize": 30
        }
    ]
}

AWSマネジメントコンソールに新しいサイズが反映されており(次のスクリーンショットを参照)、ボリュームは、使用できる状態になりました。

ステップ 4:ファイルシステムのサイズ変更

ファイルシステムのサイズを変更するには、resize2fsコマンドを使用します。

[root@ip-172-31-59-102 ~]# resize2fs /dev/nvme2n1
resize2fs 1.42.12 (29-Aug-2014)
/dev/nvme2n1のファイルシステムは、/u01/app/oracle/oradata/cdb1/pdb1/customdfs;にマウントされています。 オンラインでのサイズ変更が必要
old_desc_blocks = 2, new_desc_blocks = 4
/dev/nvme2n1上のファイルシステムは15728640(4k)ブロックになりました。

dfコマンドを使用して、ファイルシステムのサイズが変更されていることを確認します。

[root@ip-172-31-59-102 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         16G   48K   16G   1% /dev
tmpfs            16G     0   16G   0% /dev/shm
/dev/nvme0n1p1   40G   16G   24G  39% /
/dev/nvme2n1 59G 20G 37G 35% /u01/app/oracle/oradata/cdb1/pdb1/customdfs 

ステップ5:データベースストレージを増やす

テーブルスペースにデータファイルを作成したり追加するか、既存のデータファイルのサイズを増やすことによって、使用可能なデータベースストレージを増やすことができます。

この例では、evtest_02.dbfという20GBのデータファイルをEVTestTableSpaceテーブルスペースに追加して、次のスクリーンショットに示すようにデータベースストレージを増やしています。

データベースストレージは40GBで、次のスクリーンショットに示すように2つのデータファイルに分割されています。

ステップ6:ストレージのサイズ変更中にデータベースの停止時間がないことを確認する

evtesttabテーブルにクエリして、PL / SQLプロシージャの実行が途切れていないことを確認します。次のスクリーンショットに示すように、レコードが10秒間隔で挿入されていることを確認するために、このテーブルを照会します。

この例を使用して、ストレージ用にLVMなしで1つのEBSボリュームを使用する、Oracleデータベースに割り当てられたストレージを増やす方法を示します。この増加は、データベースの可用性に影響を与えることなく行えます。調整可能なボリュームを使用して、データベースに提供されたIOPSを変更したり、EBSボリュームタイプ(io1からgp2など)を変更することもできます。データベースの可用性やパフォーマンスに影響を与えることなく行うことができます。

次回の記事では、ストレージマネジメントのためにLVMを使用するOracleデータベース用のAmazon EC2のストレージレイアウトについて説明します。可用性に影響を与えることなく、これらのデータベースのデータベースストレージをどのように拡張できるかを示します。


著者について

アショク・サンムガ・スンダラームは、アマゾン ウェブ サービスのグローバルシステムインテグレーター(GSI)チームのパートナーソリューションアーキテクトです。彼はGSIと協力して、エンタープライズクラウドの採用、移行、戦略に関するガイダンスを提供しています。

 

 

 

 

エジャズ・サイードは、アマゾン ウェブ サービスのグローバルシステムインテグレーター(GSI)チームのパートナーソリューションアーキテクトです。彼がフォーカスしている分野は、AWSデータベースサービスと、AWS上のデータベースとデータウェアハウスの移行です。

 

 

 

 

ニール・ハダッドは、アマゾン ウェブ サービスのElastic Block Store(EBS)チームのシニアプロダクトマネージャーです。彼は、複数のEBS製品の提供に関連する新機能を推進しています。