Exadata X9M Database Server の Disk Expansion Kit について

※本ページは、”Disk Expansion Kit for Exadata X9M Database Server – Under the Covers“の翻訳です

Exadata X9Mは最近発表されてたので、多くの情報を入手する必要があります。先日、ハイライトしたいと思った機能がありました。公表されていないExadata X9M の機能拡張についてです。実際、私たちが好奇心旺盛なタイプのプロダクトマネージャーでなければ、それは発表されないままだったでしょう…

これは、Exadataのストーリーをカプセル化しており、開発チームがExadataのビジョンに完全に関与していることを証明しているためです。

Exadata Database Server の Disk Expansion Kit のインストール手順についてです。

私は知っています、エキサイティングですよね？…

これを見たことがない（または必要としない）人のために説明すると、Exadata Database Server の Disk Expansion Kit とは、データベースサーバーのローカルストレージにスペースを追加できます。したがって、ORACLE_HOME の数を増やしたり、追加のロギングなどのためにVMにスペースを追加したりする場合は、 Disk Expansion Kit を利用できます。

（最近の）前世代では、データベースサーバーのローカルストレージは、冗長性と可用性を確保するためにRAID HBA デバイスを使用して RAID5 として構成された4×1.2 TB ハードドライブで構成されていました。拡張キットも 4×1.2 TBハードドライブでした。新しいドライブを追加すると、追加のディスクを使用して RAID5 が自動的に再構築され（もちろんすべてオンライン）、数時間で完了しました。

Exadata X9Mでは、NVMe SSDドライブ、標準で 2x ドライブ、および Disk Expansion Kit では追加で 2x ドライブを使用します。 RAID5 についてはデータシートから記載が無くなり、ハードウェアの部品表に RAID HBA の記載は無くなりました（これについては私を信頼してください）…では、ここで何が起こっているのでしょうか。

OOTB(Out-Of-The-Box) 構成（初期構成）から始めましょう。これは Exadata であるため、2x ドライブが何らかの形で高可用性構成になることが期待できます。この確認ではデータベースサーバーを使用しているため、dbmcliから開始します。

DBMCLI> list physicaldisk attributes name,devicename,luns,disktype,makemodel
     NVME_0     /dev/nvme0     0_2,0_1     FlashDisk     "Oracle 3.84 TB 2.5-inch NVMe PCIe 4.0 SSD"
     NVME_1     /dev/nvme1     1_2,1_1     FlashDisk     "Oracle 3.84 TB 2.5-inch NVMe PCIe 4.0 SSD"

2つのドライブがあり、それらの基盤となるデバイス名、関連するLUN、ディスクタイプ、および製造元/モデルを確認できます。 OSレイヤーから、さらに深く掘り下げましょう。

RAIDコントローラーを探しましょう：

[root@xdpm01adm01 ~]# lspci -s `lspci |grep -i raid |awk ' { print $1}'`
0000:64:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 04)

これは「ソフトウェアRAID」デバイスなので、標準のマルチデバイス管理ツール（mdadm）を使用して何が起こっているかを確認できるはずです。

[root@xdpm01adm01 ~]# cat /proc/mdstat |egrep "nvme[0|1]"|grep " active"
md25 : active raid1 nvme1n2[1] nvme0n2[0]
md24 : active raid1 nvme1n1[1] nvme0n1[0]

2つのデバイスがmd24とmd25として表示されました。彼らは何にマッピングしますか？

[root@xdpm01adm01 ~]# cat /etc/mdadm.conf |grep dev
ARRAY /dev/md/24 container=ffee1199:aa990000:a9a9a9a9:0aa999aa member=0 UUID=9991111a:aaa9a9a9:aa99aa99:ff0f00ff
ARRAY /dev/md/25  level=raid1 metadata=1.2 num-devices=2 UUID=1119999f:fff0f0f0:ff00ff00:ff0f00fe name=localhost:25

つまり、MDコンテナと標準のMDデバイスがあります。md24コンテナには / bootおよび/ boot / efiファイルシステムが格納されているため、関心がありません。

[root@xdpm01adm01 ~]# df |grep md24
/dev/md24p1             7546828      85560    7461268   2% /boot
/dev/md24p2              260094       7596     252498   3% /boot/efi

どのボリュームグループが物理mdデバイスにマップされているかを簡単に確認します。

[root@xdpm01adm01 ~]# pvs
  PV         VG      Fmt  Attr PSize PFree  
/dev/md25  VGExaDb lvm2 a--  3.48t       0

単一のボリュームグループ（ここにないことで/ dev / md24に関する私の考えを証明します）。ボリュームグループを見てみましょう。

[root@xdpm01adm01 ~]# vgs
  VG      #PV #LV #SN Attr   VSize VFree
  VGExaDb   1  11   0 wz--n- 3.48t 39.75g

したがって、単一のボリュームグループ（VG）があり、1つの物理ボリューム（PV）、11の論理ボリューム（LV）、3.48t（VSize）が割り当てられ、最大40gの空き容量（VFree）が割り当てられます。 lvsを使用して論理ボリュームを確認できます。

[root@xdpm01adm01 ~]# lvs
  LV                 VG      Attr       LSize
  LVDbExaVMImages    VGExaDb -wi-ao----  3.37t
  LVDbHome           VGExaDb -wi-ao----  4.00g
  LVDbSwap1          VGExaDb -wi-ao---- 16.00g
  LVDbSys1           VGExaDb -wi-ao---- 15.00g
  LVDbSys2           VGExaDb -wi-a----- 15.00g
  LVDbTmp            VGExaDb -wi-ao----  3.00g
  LVDbVar1           VGExaDb -wi-ao----  2.00g
  LVDbVar2           VGExaDb -wi-a-----  2.00g
  LVDbVarLog         VGExaDb -wi-ao---- 18.00g
  LVDbVarLogAudit    VGExaDb -wi-ao----  1.00g
  LVDoNotRemoveOrUse VGExaDb -wi-a-----  2.00g

すべてが期待どおりに見えます。これはKVMホストであるため、VMImages論理ボリュームがあり、Oracle および GridHome 論理ボリュームはありません。

結局のところ、これが私たちが知っていることです：

Exadataは、X9M 世代のローカルデータベースサーバーストレージ用に2つの NVMe ドライブを実装します
ソフトウェアRAIDは、冗長性を確保するために使用され、RAID1（データミラーリング）として構成されます。
単一のボリュームグループがこのRAIDデバイス上に構築されています
論理ボリュームはボリュームグループ上に構築され、スペースを満たすサイズになっています（pvs “PFree” = 0）
上記のすべては出荷後すぐに使用でき、構成は必要ありません。

概略的には、次のようになります。

Disk Expansion Kit で2つのドライブを追加するとどうなるか見てみましょう。

ディスクを物理的に挿入した後、dbmcliを使用してディスクが表示されているかどうかを確認します。

DBMCLI> list physicaldisk attributes name,deviceName,luns,diskType,makeModel
     NVME_0     /dev/nvme0     0_2,0_1     FlashDisk     "Oracle 3.84 TB 2.5-inch NVMe PCIe 4.0 SSD"
     NVME_1     /dev/nvme1     1_2,1_1     FlashDisk     "Oracle 3.84 TB 2.5-inch NVMe PCIe 4.0 SSD"
     NVME_2     /dev/nvme2     2_1         FlashDisk     "Oracle 3.84 TB 2.5-inch NVMe PCIe 4.0 SSD"
     NVME_3     /dev/nvme3     3_1         FlashDisk     "Oracle 3.84 TB 2.5-inch NVMe PCIe 4.0 SSD"

追加のドライブ（NVME_2とNVME_3）、それらの基盤となるデバイス名、今回は元の2とは異なり、各ドライブに1つのLUNがあることがわかります。

上記と同じように見えない出力に出くわすと少し混乱するかもしれないので、これについての簡単な補足説明をします…

デバイスのDBMCLI名（つまりNVME_1）は、OS上のデバイス名のマッピングと必ずしも一致しません。したがって、NVME_1は OS 上で /dev/ nvme3として表示される可能性があります。

これはエラーでも問題でもありません。

基本的に、dbmcli で使用される名前はサーバー内の物理的な場所にマップされるため、ドライブを交換する必要がある場合は、適切なデバイスを選択しているので、どれがどれであるかを掘り下げる必要はありません。（便利ですよね？!!）。

参考までに、データベースサーバーの前面を次に示します（よく見ると、オレンジ色の線で位置IDを確認できます）。

このブログでは、（NVME_A から /dev/nvmeAへの）直接マッピングを使用して、理解しやすくしました。OK、話を戻しましょう。

OSを深く掘り下げて、RAID デバイスに関して何が行われたかを確認します。

[root@xdpm01adm01 ~]# cat /proc/mdstat |grep "nvme"|grep " active"
md24 : active raid1 nvme1n1[1] nvme0n1[0]
md25 : active raid1 nvme1n2[1] nvme0n2[0]
md26 : active raid1 nvme3n1[1] nvme2n1[0]

nvme2 および nvme3 デバイスはすでにパーティション化されており、3番目の RAID1 デバイスが作成されています。結果のデバイスは /dev/md26 です。物理ボリュームのマッピングを見てみましょう。

[root@xdpm01adm01 ~]# pvs
  PV         VG      Fmt  Attr PSize PFree
  /dev/md25  VGExaDb lvm2 a--  3.48t     0
  /dev/md26  VGExaDb lvm2 a--  3.49t 3.49t

したがって、/dev/md26 はすでにボリュームグループに追加されています。さらにいくつかの詳細を見てみましょう：

[root@xdpm01adm01 ~]# pvscan
  PV /dev/md25   VG VGExaDb         lvm2 [3.48 TiB / 39.75 GiB free]
  PV /dev/md26   VG VGExaDb         lvm2 [3.49 TiB / 3.49 TiB free]
  Total: 2 [<6.98 TiB] / in use: 2 [<6.98 TiB] / in no VG: 0 [0   ]

したがって、理論的には、ボリュームグループを見ると、md26 の追加によってサイズが大きくなっていることがわかります。

[root@xdpm01adm01 ~]# vgs
  VG      #PV #LV #SN Attr   VSize  VFree
  VGExaDb   2  11   0 wz--n- <6.98t 3.53t

これで、VGExaDb ボリュームグループに2つの物理ボリューム（PV）があり、合計6.98 t が割り当てられ、3.53 t が空き容量で割り当て可能になりました（実際にはまだ何もする必要はありません！）

実行する唯一のことは（これは自動的には実行されません-正当な理由で）、スペースを追加するファイルシステムの論理ボリュームを増やすことです。

私の場合、KVMホストであるため、/ExaVMImages ファイルシステムに（ほぼ）すべての新しいスペースを割り当てたいと思います。

現状を再度確認すると、これが私たちが現在持っているものです：

[root@xdpm01adm01 ~]# lvs
  LV                 VG      Attr       LSize  
  LVDbExaVMImages    VGExaDb -wi-ao----  3.37t
  LVDbHome           VGExaDb -wi-ao----  4.00g
  LVDbSwap1          VGExaDb -wi-ao---- 16.00g
  LVDbSys1           VGExaDb -wi-ao---- 15.00g
  LVDbSys2           VGExaDb -wi-a----- 15.00g
  LVDbTmp            VGExaDb -wi-ao----  3.00g
  LVDbVar1           VGExaDb -wi-ao----  2.00g
  LVDbVar2           VGExaDb -wi-a-----  2.00g
  LVDbVarLog         VGExaDb -wi-ao---- 18.00g
  LVDbVarLogAudit    VGExaDb -wi-ao----  1.00g
  LVDoNotRemoveOrUse VGExaDb -wi-a-----  2.00g

標準のlvm コマンドを使用して、LVDbExaVMImages ボリュームを拡張できるようになりました。

[root@xdpm01adm01 ~]# lvm lvextend -l +98%FREE /dev/VGExaDb/LVDbExaVMImages
  Size of logical volume VGExaDb/LVDbExaVMImages changed from <3.37 TiB (882669 extents) to <6.83 TiB (1790003 extents).
  Logical volume VGExaDb/LVDbExaVMImages successfully resized.

（どこか別の場所にスペースが必要な場合に備えて、98％を割り当てます）。

論理ボリュームの新しいサイズを確認します。

[root@xdpm01adm01 ~]# lvs
  LV                 VG      Attr       LSize
  LVDbExaVMImages    VGExaDb -wi-ao---- <6.83t
  LVDbHome           VGExaDb -wi-ao----  4.00g
  LVDbSwap1          VGExaDb -wi-ao---- 16.00g
  LVDbSys1           VGExaDb -wi-ao---- 15.00g
  LVDbSys2           VGExaDb -wi-a----- 15.00g
  LVDbTmp            VGExaDb -wi-ao----  3.00g
  LVDbVar1           VGExaDb -wi-ao----  2.00g
  LVDbVar2           VGExaDb -wi-a-----  2.00g
  LVDbVarLog         VGExaDb -wi-ao---- 18.00g
  LVDbVarLogAudit    VGExaDb -wi-ao----  1.00g
  LVDoNotRemoveOrUse VGExaDb -wi-a-----  2.00g

次に、それを終了するには、xfs_growfs コマンドを使用してファイルシステムを拡張します。

[root@xdpm01adm01 ~]# xfs_growfs /EXAVMIMAGES/
meta-data=/dev/mapper/VGExaDb-LVDbExaVMImages isize=512    agcount=4, agsize=225963264 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0
spinodes=0 rmapbt=0          =                       reflink=1
data     =                       bsize=4096   blocks=903853056, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=441334, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 903853056 to 1832963072

それだけです、2つのコマンド！ lvm lvextend コマンドと xfs_growfs コマンドがあれば、完了です。

私たちが見たように、舞台裏ではかなりの数のことが自動化されていました。簡単にまとめてみます：

新しいドライブがマシンに物理的に挿入されたことを認識しました
2つのドライブが正しいことを確認しました
ドライブの初期化とパーティション化
ソフトウェアRAIDテクノロジーを使用してRAID1デバイスを作成
このRAID1デバイスを使用して物理ボリュームを作成しました
物理ボリュームをボリュームグループに割り当てました
Exadata Management Serverは、上記のすべてを調整します

これが図式的な結果です。

上記で自動化されたタスクのタイミングについて言及するのを忘れました。

基本的に、Oracleフィールドエンジニアが「ちょっと待ってください。電話を置いて新しいドライブを挿入します…… OKです」と言うのにかかる時間でそれはすべて完了し、論理ボリュームを拡張する準備ができます。

冒頭で述べたように。私の考えでは、この手順は、「管理の自動化-Exadataのエンドツーエンド管理を完全に自動化および最適化する」というExadata のビジョンステートメントの1つの本質をカプセル化したものです。

ディスク拡張の追加は一部のお客様にのみへのアピールとなるか、必要となる場合がありますが、Exadata System Softwareの奥深くに隠されているこの手順は、Exadata プラットフォームを世界で最高のデータベースプラットフォームにするために開発チームが細部に注意を払っていることを示しています。

これについて助けてくれたAnnaとRyanに大いに感謝します（このプラットフォームをそれが何であるかを作るために働いている私たちの素晴らしい開発チームの一員です）。

私たちは常にあなたのフィードバックに興味を持っています。 Twitter @ExadataPM、@GavinAtHQ、または @alex_blyth を介して私たちと交流することを歓迎します。

Exadata X9M Database Server の Disk Expansion Kit について

Takeshi Maruyama

[お客様事例] NECネクサソリューションズ: 小売業向け販売管理システム提供基盤をOracle Cloud Infrastructureで構築し、性能および信頼性を向上

Oracle Cloud Infrastructure 新機能ハイライト - 2021/11/17

Exadata X9M Database Server の Disk Expansion Kit について

Authors

Takeshi Maruyama

[お客様事例] NECネクサソリューションズ: 小売業向け販売管理システム提供基盤をOracle Cloud Infrastructureで構築し、性能および信頼性を向上

Oracle Cloud Infrastructure 新機能ハイライト - 2021/11/17