(2016年時点での内容をアーカイブとして掲載しているため、一部の掲載内容が最新情報とは異なる場合がありますので、ご了承ください。最新のIBM Cloudのアップデート情報はIBM Cloud アップデート情報 や 柔らか層本をご参照ください。)
概要
エンデュランス・ストレージは、これまでのiSCSIストレージ(Legacy Block Storage)や性能提供型ストレージ(Performance)の後継にあたる新しいストレージです。 この特徴は「IOPS/GB」の単位で契約容量(GB)に応じて性能が高くなることで、3つの性能タイプから選択できます。 またiSCSIとNFSの二つのアクセス手段があります。 本章ではiSCSIを基本に、契約容量(GB)と性能(IOPS)と必要帯域(Mbps)の関係を解説し、Linuxの設定方法をご紹介します。
エンデュランス・ストレージの概要
このエンデュランス・ストレージは、SoftLayerのプライベート・ネットワークに提供され、IPアドレス、ユーザーID、パスワードを指定してアクセスします。 もちろん仮想サーバー、物理サーバーの両方からアクセスできます。
次の表は、このストレージの3つの性能タイプを把握するために、カスタマーポータルのオーダー画面から契約容量(GB)と価格($)の関係を拾い集め、容量単価と性能値を計算したものです。 例えば、2 IOPS/GBのストレージを20GBを購入した場合、2 IOPS/GB x 20GB = 40 IOPS の性能を得ることができます。 ストレージ容量を大きく確保するほど、高いIOPS値が得られるストレージです。
このストレージの特性として、オーダーした容量(GB)が小さい場合、運用上必要な性能が得られないことを意味しています。この点を整理するため、以下の表に他方式ストレージとエンデュランス・ストレージのIOPSを対比しました。 この表の 500 IOPS 未満の領域では、個人で利用するノート型パソコンの磁気ディスク程度の性能値しか得られないことが分かります。このため「性能の目安」の列で「SATA HDD並み」以上の容量(GB)の範囲がおすすめです。例えば0.25 IOPS のストレージでは 2TB、2 IOPS では 250GB、4 IOPS では 100GB を最小購入単位とするのがおすすめです。
エンデュランス・ストレージには、同じ論理ユニット(LUN)に対して、マルチパスI/Oが提供されます。このマルチパスI/Oの設定方法は、この章の後半でご紹介します。
このエンデュランス・ストレージには、スナップショット機能、他データセンターへのレプリケーション機能、フェイルオーバーとフェールバック機能が提供されています。 スナップショット機能は、最小1時間単位で取得でき、保存されている任意の世代に戻すことができます。 また、スケジュールされていない時間でも好きな時に手動でスナップショットを作成することも可能です。レプリケーション機能は、スナップショットの取得間隔で同期されるため、災害対策用に適用できますが、高可用性用には適さないので注意が必要です。
既存のストレージ・サービスとの対比
次の表に、既存のほかのブロック・ストレージの種類ごとに、容量(GB)、月額料金($)、容量単価($/GB)、性能値(IOPS)を整理しました。この表を使って、エンデュランス・ストレージの使い分けを整理します。
上段のエンデュランス・ストレージについて、サーバー用のSATAディスクより低速な 500 IOPS 以下にあたる容量(GB)では、本番サービスとして実用的ではないと見なすことができます。(図内*1)
その右隣のポータブル・ストレージは、最も容量単価の安いSANのブロック・ストレージですが、物理サーバーからアクセスできません。また、ベスト・エフォート型の性能で、スナップショットやレプリカの機能も無いものです。 将来、能力アップのために物理サーバーへ移行する構想があれば、最初からエンデュランス・ストレージにするのも良いでしょう。(図内*3)
下段右端の性能提供型ストレージ (Performance Storage)は、容量(GB)とIOPS値を指定してオーダーできるストレージです。 最大性能は 6000 IOPS となり、スナップショットやレプリカの機能はありません。このため少し安い価格設定になっています。(図内*4)
上段のエンデュランス・ストレージの 0.25 IOPS/GB のストレージは、容量単価が安く、大容量で利用すれば、1000 IOPS 以上の性能になります。 アクティブなログ用エリアやアーカイブなどの領域として適用できます。(図内*5)
エンデュランス・ストレージのIOPS値で16K IOPS 以上の領域は、相応して月額費用も高額になりますが、物理サーバーにSSDでRAIDを構成した場合と比較して高い書込性能が得られます。 アクティブ・スタンバイのHAクラスタ構成の共用ディスクとしての利用に最適です。(図内*6)
エンデュランス・ストレージの2IOPS/GBと4IOPS/GBの性能タイプの 4000〜8000 IOPSの範囲は、データベース用途に適していると考えられます。(図内*7)
エンデュランス・ストレージの 1000〜2000 IOPSの範囲は、月額$350以下で利用可能で容量(GB)と性能(IOPS)でバランスの取れた領域と言えます。(図内*8)
IOPS/GB パフォーマンスとは
IOPS/GBという購入単位の振る舞いを具体的に確認していきます。このストレージの性能は、購入した容量によって決まるため、2 IOPS/GBのクラスを20GBを確保したとしたら、キッチリ40 IOPSで制限されます。例えば、SANやLOCALディスクで数秒で終了するようなケースでも、非常に時間がかかると感じることがあります。
次のケースは、仮想サーバーのLOCALディスクでファイルをコピーする時間を測ったものです。78Mバイトのファイルをコピーするのに、0.3 秒かかったことが分かります。
# time cp linux-4.0-rc5.tar.xz test.xz
real 0m0.329s
user 0m0.003s
sys 0m0.168s
一方、2 IOPS/GB 20GBのエンデュランス・ストレージで同じことをした場合、次のように 21 秒かかっています。 新型ストレージなのに、なんと! 60倍も遅くなっていることになります。
# time cp linux-4.0-rc5.tar.xz test.xz
real 0m21.366s
user 0m0.003s
sys 0m0.177s
この場合の性能値は、2 IOPS/GB x 20GB ですから、40 IOPSとなります。 次のコピー実行中のiostatの結果 tps列では、1秒間あたりのディスク操作のコマンド数を表していますが、sda行では、その値が 39.8、つまり、40 IOPSで制限されていることが分かります。
avg-cpu: %user %nice %system %iowait %steal %idle
1.02 0.00 3.06 95.92 0.00 0.00
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
xvda 7.14 0.00 114.29 0 112
xvdb 0.00 0.00 0.00 0 0
sda 39.80 9926.53 0.00 9728 0
sdb 0.00 0.00 0.00 0 0
比較のために、仮想サーバーのLOCALディスク(xvda)の場合では、約900 IOPS を記録しています。 エンデュランス・ストレージで900 IOPS を得たい場合には、 900 IOPS / 2 IOPS/GB となり、450GB以上の容量を確保する必要があることを意味します。
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 17.53 8.25 0.00 74.23
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
xvda 908.25 70086.60 4931.96 67984 4784
xvdb 0.00 0.00 0.00 0 0
sda 1.03 0.00 8.25 0 8
sdb 0.00 0.00 0.00 0 0
容量と性能の関係の確認
次にfioコマンドを使って、例として 2 IOPS/GB x GB の性能タイプのストレージの性能を確認します。 次のグラフは契約容量(GB)と性能(IOPS)の相関図で、実測値から作成したものです。このグラフから、容量の増加に比例して、性能の実測値が高くなっていることが分かります。そして、このグラフの傾きが およそ 2 IOPS/GB となっていることが分かります。
このグラフを求めるために利用したfioコマンドの導入とテスト条件を以下にご紹介します。CentOSでは、次のコマンドで fioコマンドをインストールします。 debian系Linuxを使う場合は、apt-get fio で導入することができます。
# yum install libaio-devel -y
# wget http://pkgs.repoforge.org/fio/fio-2.0.14-1.el5.rf.x86_64.rpm
# rpm -ivh fio-2.0.14-1.el5.rf.x86_64.rpm
以下は、データを取得するために作成したfioコマンドの実行シェルです。このシェルは測定対象のストレージが、/mnt にマウントされていることを前提にしています。 測定対象のエンデュランス・ストレージを/mntにマウントしてシェルを実行すれば、各条件の測定結果をファイルに出力します。
#/usr/bash
IOENGINE=libaio
#IOENGINE=sync
IODEPTH=8
for BS in 4k 16k
do
for JOBS in 1 16 32 64
do
for MODE in read write randwrite randread randrw
do
echo "[BS=${BS} JOBS=${JOBS} MODE=${MODE}] =============================="
fio --filename=/mnt/testfile --direct=1 --rw=${MODE}
--bs=${BS} --numjobs=${JOBS} --size=5G --runtime=20
--norandommap --ioengine=${IOENGINE}
--invalidate=1 --iodepth=${IODEPTH}
--group_reporting --name=file
|tee rslt_${IOENGINE}_${BS}_${JOBS}_${MODE}.txt
printf "nn"
done
done
done
エンデュランス・ストレージは、これまでのベスト・エフォート型の共用ストレージに替わる新しいタイプのストレージで、共用資源を多くのユーザーで分け合う環境では、なくてならないものですが、このIOPS/GBの関係を把握して適切に使う点で、ノウハウを積む必要がありそうです。
契約容量と必要帯域の関係
エンデュランス・ストレージは、プライベート・ネットワークを使ってストレージを利用するため、サーバーのNICのリンク速度の考慮が必要です。 契約容量(GB)に比例して性能を提供するストレージですから、その性能を十分に発揮するために必要なリンク速度の関係をみていきます。
次のグラフの左側は、2 IOPS/GBの本ストレージで、NICリンク速度1Gbpsの条件で、容量(BG)と性能(IOPS)の相関を調べたものです。(グラフ中 RRはランダムリード、RWはランダムライト、BSはブロックサイズ) ブロックサイズ 16Kの場合、2000GB以上で比例関係が崩れていることがわかります。 そして、その原因調査のために、実測帯域をプロットしたのが右側のグラフです。ストレージ容量8000GBのケースでは、帯域が900Mbpsを超えているため、NICのリンク速度が、原因となって性能が出なかったことが考察されます。
次のグラフは、NICリンク速度を10Gbpsへアップグレード後に計測したものです。 ブロックサイズ16Kのケースでも、ストレージ容量 8000GB まで比例していることがわかります。 2 IOPS/GBのストレージを8000GB 契約した場合、このストレージの性能を発揮させるためには、NICの10Gbpsのリンク速度が必要であったことがわかります。
高速なリンク速度を契約すれば、それに応じて費用も上がります。このため、契約容量と契約リンク速度の関係を適切に把握しておく必要があります。次の表は、実測値から得た計算式に基づいて求めたものです。それぞれの性能タイプの契約容量と必要帯域、そしてNICのリンク速度を把握することができます。
iSCSI ブロック・ストレージとしてのオーダー
カスタマーポータルから「Storage」->「Block Storage」->「Order Block Storage」を選択すると次の画面が表示されます。「Select Storage Type」に「Endurance」を選択し、必要項目をセットして「Continue」をクリックして進みます。 その次の確認ウィンドで修正点がなければ「Place Order」をクリックしてオーダーを確定します。 各項目の解説は、http://knowledgelayer.softlayer.com/topic/endurance-storage にありますので、合わせて参照すると理解が深まります。
しばらくすると、次の画面のようにエンデュランス・ストレージが利用可能になります。「Notes (Clieck cell to edit)」にコメントを記入できますから、システム名や用途などを入力して、管理に役立てることができます。
サーバーへアクセス権限付与
これでiSCSIのブロックデバイスとして利用できるようになったので、LinuxとしてCentOS6から認識させ、ファイルシステムを作成して、マウントする作業をみていきます。 同じ東京データセンターにCentOS6のサーバーと今回注文したストレージを利用可能な状態にしていきます。
このストレージにアクセスする許可をサーバーへ与える為に、この画面の下の方の「Authorize Host」をクリックします。
このストレージに接続を許可するサーバー、もしくはIPアドレスを選択します。
サーバーにアクセス権限を与えると、ユーザーID、パスワード、IQN (iSCSI Qualified Name) が付与されます。次以降で、これらの値をiSCSIの設定ファイルにセットします。
スナップショットの取得
また、設定したスケジュールとは別に手動でスナップショットを作成する事も可能です。手動でスナップショットを作成する場合は、「Storage」->「Block Storage」->「LUN Name」の画面から、Take Manual Snapshot のリンクをクリックします。
スナップショットの利用方法は、http://knowledgelayer.softlayer.com/procedure/endurance-snapshots のリンクにもあります。
LinuxのiSCSIシングルパス設定
当たり前の話ですが、OSを最新状態に更新してから、iscsi関連のパッケージのインストールを開始します。
# yum update -y
iSCSIとの接続方法は、このリンクに記載されているので、合わせて参照すると、より良い理解が得られると思います。http://knowledgelayer.softlayer.com/procedure/connect-iscsi-lun-linux-open-iscsi
# yum install iscsi-initiator-utils -y
/etc/iscsi/initiatorname.iscsi にIQNを設定します。
# pwd
/etc/iscsi
# vi initiatorname.iscsi
# cat initiatorname.iscsi
InitiatorName=iqn.2005-05.com.softlayer:SL01SU294470-1
/etc/iscsi/iscsid.conf に上記のユーザー名などを設定します。 以下のファイルの例は、最小限必要項目を抜き出したものですので、実際のファイルを編集する際は、項目名で探して編集をお願いします。 この例は認証に関わる最小限ですから、タイムアウト値などのチューニング項目は、前述のKnowledge Layerのリンクを参照ねがいます。
# vi iscsid.conf
# cat iscsid.conf
node.startup = automatic
node.session.auth.authmethod = CHAP
node.session.auth.username = SL01SU294470-1
node.session.auth.password = YlvkWZGGPT7bxvkP
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = SL01SU294470-1
discovery.sendtargets.auth.password = YlvkWZGGPT7bxvkP
次のiscsiadmコマンドで割当られたiscsiターゲットを探します。この「-p」以降のIPアドレスは、「Block Storage Detail」の画面の「Target Address」のIPアドレスを利用します。 この画面にアクセスするには、「Storage」->「Block Storage」->「LUN Name」の順に進みます。
# iscsiadm -m discovery -t sendtargets -p 10.3.78.88
iscsid を起動中: [ OK ]
10.3.78.88:3260,1036 iqn.1992-08.com.netapp:tok0201
10.3.78.79:3260,1035 iqn.1992-08.com.netapp:tok0201
iscsiのサービスをリスタートすると、以下のように、ブロック・デバイスが認識できるようになります。
# /etc/init.d/iscsi restart
iscsi を停止中: [ OK ]
iscsi を起動中: [ OK ]
[root@tkr02 iscsi]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 25G 0 disk
├─xvda1 202:1 0 256M 0 part /boot
└─xvda2 202:2 0 24.8G 0 part /
xvdb 202:16 0 2G 0 disk
└─xvdb1 202:17 0 2G 0 part [SWAP]
sda 8:0 0 20G 0 disk
sdb 8:16 0 20G 0 disk
ファイルシステムを作成します。 通常SATAのストレージでは 1000 IOPS 程度の性能があります。 もし0.25 IOPS/GBのストレージを20Gで指定した場合、5 IOPSに性能が制限されるため、非常に時間がかかります。
[root@tkr02 iscsi]# mkfs.ext3 /dev/sda
ファイルシステムの作成が完了したら、マウントしてdfコマンドで、確認します。
[root@tkr02 iscsi]# mount -t ext3 /dev/sda /mnt
[root@tkr02 iscsi]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda2 25544012 1267108 22979344 6% /
tmpfs 508116 0 508116 0% /dev/shm
/dev/xvda1 253871 84527 156237 36% /boot
/dev/sda 20642428 176196 19417656 1% /mnt
これでエンデュランス・ストレージが利用できるようになりました。
マルチパスI/Oの設定
マルチパスI/O(MPIO)は、iSCSIストレージのアクセス経路を複数にするもので、性能と可用性の改善が期待されます。エンデュランス・ストレージはマルチパスI/Oの機能がサポートされますので、設定方法についてみていきます。 設定を行なう前に、/mntをアンマウントしておきます。 これを忘れると、マルチパスI/O化が途中で失敗するので、忘れないように最初で実施します。そして次に必要なモジュールをインストールします。
# yum install device-mapper-multipath -y
iSCSIターゲットのWWIDを調べます。このエンデュランス・ストレージは、最初から二つのデバイスが提供されますが、取り違いがないようにデバイス名を指定してWWIDが同じであることを確認します。
# /sbin/scsi_id -g /dev/sda
3600a098038303468415d466a53645466
# /sbin/scsi_id -g /dev/sdb
3600a098038303468415d466a53645466
次の/etc/multipath.conf のテンプレートに、上記で得たWWIDをセットします。以下では、aliasのyellow が、デバイスマッパーのデバイス名になるので、適当な名前に変更します。この例では変更しません。
defaults {
user_friendly_names yes
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
}
multipaths {
multipath {
wwid 3600a098038303468415d466a53645466
alias yellow
path_grouping_policy multibus
path_selector "round-robin 0"
failback manual
rr_weight priorities
no_path_retry 5
}
}
マルチパスI/Oのサービスを開始します。
# service multipathd start
Starting multipathd daemon: [ OK ]
マルチパスI/Oのデバイスの動作を確認します。これで、エンデュランス・ストレージのsda,sdbにyelloが紐づいていることが分かります。
# multipath -ll
yellow (3600a098038303468415d466a53645466) dm-0 NETAPP,LUN C-Mode
size=20G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=30 status=active
|- 0:0:0:0 sda 8:0 active ready running
`- 1:0:0:0 sdb 8:16 active ready running
マルチパスI/Oのデバイス /dev/mapper/yellow をマウントして、df コマンドで確認します。
[root@tkr03 ~]# mount -t ext3 /dev/mapper/yellow /mnt
[root@tkr03 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda2 25544012 1150940 23095512 5% /
tmpfs 514096 0 514096 0% /dev/shm
/dev/xvda1 253871 78521 162243 33% /boot
/dev/mapper/yellow 20642428 2443792 17150060 13% /mnt
これでマルチパスI/Oの設定が完了しました。 ところで、常にマルチパスにしたら速くなるかと言えば、1コアの条件では逆に遅くなってしまいました。 シングル接続の時は、fioコマンドの結果で40 IOPS程度の性能が出ていたのですが、マルチパスでは、約一割くらい性能が劣化した感じです。
スナップショットの取得
この機能を利用するには、スナップショットの領域が確保されていなければなりません。オーダー時または稼働後にスナップショット領域をオーダーすることができます。 稼働後にスナップショットの領域をオーダーするには、「Storage」->「Block Storage」->「LUN Name」->「Change Snapshot Space」からオーダーします。
スナップショットのスケジュール設定は「Storage」->「Block Storage」->「LUN Name」->「Edit Snapshot Schedule」を選択すると次の画面が表示されます。 スナップショットを取得するタイミングとして、1時間毎、1日毎、1週間毎、それぞれで1回づつ、指定の時分で設定できます。最小のスナップショットの間隔は1時間となります。それからスナップショットの世代数を設定します。
この上記の設定が有効になると、1時間ごと毎時30分にスナップ・ショットが取得され、取得された世代分のリストが表示されます。また、スナップショット領域の残り容量が円グラフで表示されます。 スナップショットの領域の大きさは、スナップショットの保存世代数が一回りする期間を通じて発生するデータの変更量より大きくする必要があります。 例えば、保存世代数の3世代を通じての更新量が2GBであると見込まれる場合、スナップショットの領域サイズで5GBを選択します。
スナップショットの利用方法は、http://knowledgelayer.softlayer.com/procedure/endurance-snapshotsのリンクにもあります。
スナップショットを指定して復元
スナップショットを取得したある時点に戻すには、iSCSIのセッションを解除して、カスタマーポータルからリストアを実行する必要があります。この戻しの手順を確認していきます。 これからデータを削除して、スナップショットから復元します。
# ls /mnt
data lost+found testfile
# rm -fr /mnt/testfile /mnt/data/
# ls /mnt
lost+found
ファイルシステムからアンマウントして、iscsiのサービスを停止します。
# umount /mnt
# /etc/init.d/iscsi stop
カスタマーポータルからスナップショットを指定してリストアを実行します。
次の確認画面で「YES」をクリックすると、最後にスナップショットを取得した以降に更新されたデータは消えてしまい、取り戻すことはできません。 それでも良いことを踏まえて先に進めます。
リストアの進行中は、次のようなメッセージが表示されます。このメッセージが消えたら次の作業を進めます。
再度iSCSIのセッションを再開して、ファイルシステムをマウントして、指定したスナップショットの時点まで戻っていることが確認できました。
# /etc/init.d/iscsi start
iscsi を起動中: [ OK ]
# mount -t ext3 /dev/sda /mnt
# ls /mnt
data lost+found testfile
iSCSIのセッションを終了しないで、カスタマーポータルの画面からリストアを実行してもリストアは実行されません。エラーも出ないので、動作していないように見えます。 正しい手順を取るとデータが復元されますから、うまく動作しない場合は、復元作業が順番どおり正しく実行されいるか確認することをおすすめします。