FJcloud実践
LVMでFJcloud-Vのディスク容量制限2,000GBを回避する方法
この記事は、ニフクラブログで2023-11-01に公開された記事を移転したものです。
こんにちは、CRE部 技術支援チームです。
現在、FJcloud-V(旧ニフクラ)では単一で2,000GBまでの増設ディスクを提供しています。
しかし、単一で2,000GB以上の大容量ボリュームを利用したいと思われたことはないでしょうか。
そのようなときにLVMを利用すると、2,000GB以上の大容量ボリュームを作成することが可能です。
LVMは「logical volume manager」の略で、複数のハードディスクやパーティションを論理的に１つのボリュームとして扱うことができるディスク管理機能となります。
主にLinuxなどのUNIX系OSで利用することができる機能です。
しかし、LVMを利用して作成したボリュームでは性能劣化などは発生しないのでしょうか。
そこで今回は、LVMで作成したボリュームと通常のボリュームの性能比較を実施してみます！
前提条件
本ブログは、以下の前提知識がある方を想定しています。
- FJcloud-V(旧ニフクラ)の基本的なコントロールパネルの操作、サービスを利用する知識
- Linuxサーバーの基本的な操作、知識
検証概要
今回はFJcloud-V(旧ニフクラ)上に作成したサーバーに、以下の2つのボリュームをマウントし性能比較を実施します。
- 1つのディスクから構成したボリューム
- LVMで2つのディスクから構成したボリューム
性能比較にはfioというツールを利用します。
fioはディスクにI/Oを発行してディスク性能を測ることができるツールです。
利用リソース
検証準備
まずは検証準備として、通常のボリュームとLVMで構成した論理ボリュームを作成します。
後の検証では、検証時の合計サイズを最大10GBにすることを想定しているため、少しバッファを持たせた12GBでそれぞれのボリュームを作成します。
通常ボリューム作成
はじめに12GBの通常ボリュームを作成していきます。
増設ディスクはこちらを参考に作成します。
作成が完了したら、こちらを参考にボリューム作成、サーバーマウントまでを実施します。
マウントが完了したら、dfコマンドで確認してみます。
# df -hT
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 32G 0 32G 0% /dev
tmpfs tmpfs 32G 0 32G 0% /dev/shm
tmpfs tmpfs 32G 8.9M 32G 1% /run
tmpfs tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/sdd1 xfs 12G 112M 12G 1% /normaldisk
/dev/sda3 xfs 28G 2.5G 25G 10% /
/dev/sda1 xfs 507M 337M 170M 67% /boot
tmpfs tmpfs 6.3G 0 6.3G 0% /run/user/0
下から4行目が通常のボリュームをマウントしたものです。
12GBのボリュームが「normaldisk」というマウントポイントへマウントされていることを確認できました。
LVMを利用した 論理ボリューム作成
続いてLVMを利用した論理ボリュームの作成・マウントを行います。
以下の流れで実施します。
- 1. 増設ディスクの作成・追加
- 2. パーティション作成
- 3. 物理ボリューム作成
- 4. ボリュームグループ作成
- 5. 論理ボリューム作成
- 6. 論理ボリュームのマウント
論理ボリューム作成の詳細な手順です。
1. 増設ディスクの作成・追加
1.1 増設ディスク作成・追加
まずはじめに通常ディスクと同様にこちらを参考に増設ディスクを2つ作成します。
作成できたら以下のコマンドでサーバーにディスクを追加します。
# for i in $(find /sys/class/scsi_host -name 'scan') $(find /sys/devices -name 'scan') ;do echo "- - -" > $i ; done
1.2 増設ディスク確認
fdiskコマンドで増設ディスクの確認を実施します。
# fdisk -l
～中略～
Disk /dev/sdb: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sdc: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
追加した増設ディスクを2つ確認できました。
今回はこの2つの増設ディスクからパーティションを切り出して、1つの論理ボリュームを作成します。
2. パーティション作成
fdiskコマンドを使ってパーティションを作成していきます。
12GBのボリュームを作成するため、2つのディスクにそれぞれ6GBのパーティションを作成します。
# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-209715199, default 2048): 2048
Last sector, +sectors or +size{K,M,G,T,P} (2048-209715199, default 209715199): +6GB
Created a new partition 2 of type 'Linux' and of size 954 MiB.
Command (m for help): w
3. 物理ボリューム作成
2で作成した2つのパーティションに物理ボリュームを作成します。
# pvcreate /dev/sdb1
# pvcreate /dev/sdc1
4. ボリュームグループ作成
3で作成した物理ボリュームからボリュームグループを作成します。
# vgcreate vg_test /dev/sdb1 /dev/sdc1
5. 論理ボリューム作成
4で作成したボリュームグループから論理ボリュームを作成します。
# lvcreate -n lv_test -l 100%FREE vg_test
6. 論理ボリュームのマウント
6.1 論理ボリュームのフォーマット
5で作成した論理ボリュームをフォーマットします。
# mkfs -t xfs /dev/vg_test/lv_test
6.2 マウントポイント作成
論理ボリュームをマウントするためのマウントポイントを作成します。
# mkdir /lvdisk
6.3 論理ボリュームマウント
論理ボリュームを作成したマウントポイントへマウントします。
# mount /dev/vg_test/lv_test /lvdisk
dfコマンドで正しくマウントできているか確認します。
# df -hT
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 32G 0 32G 0% /dev
tmpfs tmpfs 32G 0 32G 0% /dev/shm
tmpfs tmpfs 32G 8.9M 32G 1% /run
tmpfs tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/sdd1 xfs 12G 112M 12G 1% /normaldisk
/dev/sda3 xfs 28G 2.5G 25G 10% /
/dev/sda1 xfs 507M 337M 170M 67% /boot
tmpfs tmpfs 6.3G 0 6.3G 0% /run/user/0
/dev/mapper/vg_test-lv_test xfs 12G 112M 12G 1% /lvdisk
一番下の行が今回マウントしたボリュームです。
LVM構成の論理ボリューム(lv_test)がマウントポイント(lvdisk)へマウントされていることを確認できました。
以上で事前準備は完了です。
検証①
検証用の以下の2つのボリュームがマウントできたので、計測を実施していきます。
- 1つの増設ディスクから12GBを切り出して、作成したボリューム
- 2つの増設ディスクから6GBずつ切り出して、LVMで作成した12GBの論理ボリューム
計測条件・項目
まず1回目の検証では、1つのディスクに収まるデータ量で検証を実施してみます。
今回、LVMのボリュームは6GB×2で作成しているため、6GBに収まるデータ量の1GBで検証します。
それを踏まえて、以下の組み合わせの検証パターンを作成しました。
計測に使用するfioコマンドは以下のとおりオプションを指定します。
上記図の検証パターンに合わせて対象ボリューム、ブロックサイズを書き換えて実行していきます。
fio --filename=/<対象ボリュームのマウントポイント> /1G.dummy --size=1G --direct=1 --rw=<Read,Write比率> --bs=<ブロックサイズ> --ioengine=libaio --iodepth=256 --numjobs=5 --runtime=180 --time_based --name=<ジョブ名> --group_reporting
それぞれのパターンの検証を複数回実施しその平均値を取得し、結果を確認します。
結果
計測して取得した値を、レイテンシー・スループット・IOPSの項目でグラフ化しました。
それぞれ項目ごとのグラフを確認していきます。
レイテンシー
まずはレイテンシーから確認します。
レイテンシーでは、LVM構成のディスクと通常のディスクでほとんど差がみられない結果となりました。
スループット
続いてスループットを確認します。
スループットでは、LVM構成のディスクの方が少しですが数値が高い結果となりました。
IOPS
最後にIOPSを確認します。
IOPSでは、LVM構成のディスクの方が少しですが数値が高い結果となりました。
まとめ
1GBの実施結果では以下のとおりとなりました。
- 複数の項目(レイテンシー、スループット、IOPS)で比較したが、通常のボリュームとLVM構成の論理ボリュームで大きな性能差は見られなかった
- ブロックサイズの違いによる傾向の違いも見られなかった
以上からLVM構成の論理ボリュームの場合でも性能劣化は見られないことがわかりました。
検証②
計測条件・項目
続いてはデータサイズを大きくして検証してみたいと思います。
データ量は論理ボリュームの6GB×2の両ディスクが使われるように10GBとします。
1GBでの検証と同様に、以下の組み合わせを各複数回実施しその平均値を取得し、結果を確認します。
結果
こちらも検証①と同様に計測して取得した値を、レイテンシー・スループット・IOPSの項目でグラフ化しました。
それぞれ項目ごとのグラフを確認していきます。
レイテンシー
まずはレイテンシーから確認します。
レイテンシーでは、通常のボリュームよりもLVM構成の論理ボリュームの方が遅延が少ない結果となりました。
スループット
続いてスループットを確認します。
スループットでも、LVM構成の論理ボリュームの方が数値が高い結果となりました。
IOPS
最後にIOPSを確認します。
IOPSでも、LVM構成の論理ボリュームの方が数値が高い結果となりました。
まとめ
10GBの実施結果では以下のとおりとなりました。
- 複数の項目(レイテンシー、スループット、IOPS)で比較した結果、LVM構成の論理ボリュームの方が性能が良い結果となった
- ブロックサイズの違いによる傾向の違いは見られなかった
最後に
今回はLVMを利用した論理ボリュームと通常ボリュームの性能比較を実施しました。
今回実施した条件下では、検証①と検証②のどちらもLVM利用による性能劣化は見られないことがわかりました。
検証②の場合のみLVM構成の論理ボリュームの方が性能が良い結果となりましたが、こちらの要因については別途検証してみたいと思います！
この結果が、FJcloud-V(旧ニフクラ)で2,000GB以上の単一ボリュームが必要な場合に、LVMを利用する際の参考になれば幸いです。
最後までお読みいただきありがとうございました！
注意事項
- 本計測は、あくまで筆者の環境を使った計測時点での値であり、計測環境・計測時間によって異なる場合あります。参考程度に留めてください。
- 本記事ではOS上の操作についても記載していますが、FJcloud-V(旧ニフクラ)ではOS以上はご利用者様の責任範囲となりますのでご留意ください。
- 本記事に記載されている会社名、製品名等の固有名詞は各社の商号、登録商標または商標です。
- 本記事は、2023年10月時点の情報です。
