SoftLayer Bare Metal server: QuantaStor でのオブジェクト・ストレージの活用

注意！！：以下の例においては、省略時値をそのまま使用しており、十分なアクセス制御を設定していません。ご自分で試される際にはご注意下さい。

0. はじめに

Bare Metal Server でしかオーダーできない QuantaStor を使って Object Storage を利用したクラウドバックアップを試してみましたので、手順の概要と私の嵌りどころをまとめました。

1. サーバーのオーダー

オーダーの際に QuantaStor を選択できるサーバーの種類は限られており、予算の都合で一番小さな 2 ドライブ・ベイのサーバーを使用することにしました。また、QuantaStor 自体のインストールにドライブ1つ使用されますので、今回の構成ではデータ用に使用できるドライブは1つとなります。とりあえず使ってみたいという私の用途には十分ですが、QuantaStor から共有したいボリュームなどの容量、ハードウェア RAID など要件がある場合、オーダー確定前に要件を満たせるかどうかを十分検討した方が良いでしょう。

2. オブジェクト･ストレージのオーダー

オブジェクト・ストレージは使用量に応じて課金されます。但し、転送データ量にも課金されることにも注意が必要です。
QuantaStor から利用するからといって特に注意すべき点はありません。オーダー完了後にオーダーしたオブジェクト･ストレージの各データ・センターの画面から View Credentials リンクをクリックし、後で使用することになる Username と API Key をコピー＆ペーストできるようにしておきます。

嵌りどころ：
カスタマー・ポータルのログインに Symantec の二要素認証を設定したユーザーで、オブジェクト・ストレージの各データセンターの画面に進むもうとすると Unauthorized とエラー・メッセージが表示され Username や API Key を表示することができませんでした。
各データセンターの画面を正しく表示するにはユーザー設定(Account->Users->ユーザー名) 画面から、"Symantec Validation Settings" の項目の右端の "Update Credential" リンクから表示できるダイアログ・ボックスで "Update State" ボタンをクリックすることにより、一時的に二要素認証を Disabled にした状態で、各データセンター別の画面を一度表示させます。一度表示させたデータセンターについては、同じ手順で二要素認証を Enable に再設定しても問題なく各データセンター別の画面を表示できます。他のデータセンターの画面を表示する場合は同じ手順を繰り返すことで正常に表示可能です。

3. 管理用 Web インターフェースへのログイン

管理用 Web インターフェースには admin ユーザーと QuantaStor の root　パスワード(カスタマー・ポータルから確認します)でログインします。

4. 基本操作に必要な構成

本題のオブジェクト･ストレージ関連の操作前にクライアントにブロック・デバイスを提供する基本操作に必要な構成をおこないます。
Webインターフェースから 「ストレージ管理」のタブを開くと数多くの項目が表示されますが、他のストレージ仮想化などにも同等な概念が存在する以下の項目を簡単に理解しておくと各段階の構成時に、今何をしているかが把握しやすくなります。

• 物理ディスク
  HDD、SSD などの物理的な記憶媒体です。

• ストレージプール
  物理ディスクの集合。QuantaStor のソフトウェア RAID 構成、データ領域のファイルシステム、チューニング・パラメーターを設定/管理単位。
  QuantaStor が提供するストレージボリュームやネットワーク共有はストレージプールから切り出される形で作成されます。

• ネットワーク共有
  QuantaStor が提供する CIFS や NFS プロトコルで提供するファイルシステム共有。

• ストレージボリューム
  QuantaStor が提供するブロック・デバイス。

• ストレージボリュームグループ
  ストレージボリュームをまとめて扱う単位。
  密接な関連のある複数のストレージボリュームをまとめて操作(クローン、スナップショットなど)するために存在します。今回はひとつのストレージボリュームしか操作しない為、作成しません。

• ホスト
  ストレージボリュームへのアクセスを許可するホストの定義。

• ホストグループ
  同じストレージボリュームへのアクセスをまとめて許可する為の定義。
  今回はひとつのアクセスを行うホストがひとつである為、作成しません。

今回は、以下の手順で QuantaStor の基本的な操作に必要な構成を完了しました。
1) QuantaStor へのインストールに使用されずに残った 1 ドライブからストレージプールを作成

2) 上記 1) で作成したストレージプールからストレージボリュームを作成

3) 上記 2) で作成したストレージボリュームにアクセスするホストを定義

4) 上記 3) で定義したホストへ 2) で作成したストレージボリュームへのアクセスを 許可

嵌りどころ：
Object Storage を活用するストレージボリュームのクラウドバックアップは、現在、 ZFS をサポートしていません。最初に唯一のストレージプールを ZFS で作成してしまった為、ストレージボリュームのクラウドバックアップをテストするために XFS での再作成が必要でした。
但し、Snapshot は ZFS でのみサポートされている為、スナップショット機能を使用するには ZFS を使用した ストレージプールが必要です。

5. クラウドコンテナの作成

上記 2. でオーダーしたオブジェクト・ストレージを QuantaStor 上のクラウドコンテナとして定義します。
最初に Web インターフェースから
1) 上記 2. で準備しておいた Username と API Key を資格情報として追加します。
(クラウドコンテナ→クラウドストレージプロバイダー→資格情報の追加)

2) 上記 1) で追加した資格情報を元にクラウドストレージコンテナをモントリオールのプライベートネットワーク経由での接続として作成します。以下のダイアログ。ボックスで「～と接続：」のフィールドにはQuantastor のホスト名を指定します。
(クラウドコンテナ→クラウドコンテナ→作成)

嵌りどころ：
クラウドコンテナの作成時に、いろいろ条件を変えて試しても以下のエラーで先に進みませんでした。

{Sun May 17 22:22:18 2015, *ERROR*, bdffb700:service_cloud_backup:618} Failed to persist metadata for cloud container 'swift://mon01.objectstorage.softlayer.net/qs-bucket-23f29e4e-1e70' [err=313]

QuantaStor 上の /var/log/qs_service.log に記録されている内容から、必要な Python モジュールが足りないと思われた為、以下の2つのコマンドを Quantastor上で実行することで pip コマンドおよび、https://github.com/softlayer/softlayer-object-storage-python から提供されている SoftLayer のオブジェクト・ストレージ操作に必要なモジュールを追加することで、クラウドコンテナの作成ができるようになりました。

# apt-get install python-pip
# pip install softlayer-object-storage

6. ストレージボリュームの操作およびクラウドバックアップのテスト

QuantaStor で定義したストレージボリュームを CentOS6 からマウントし、クラウドバックアップ取得前後で内容を変更し、クラウドバックアップのリストア後に、変更前の内容が保持されていることを確認します。

1) iSCSI 経由で提供されているストレージボリュームのディスカバリー
ストレージボリュームを使用する側(以下、CentOS6)から以下のコマンドで 4. において作成したストレージボリュームをディスカバリーします。以下のコマンドで QuantaStor から提供されている iSCSI ボリュームのログインすべき IQN が iSCSI の提供に使用しているIPアドレスと共に表示されます。

# iscsiadm -m discovery -t st -p QuantaStorのIPアドレス

2) iSCSI 経由で提供されているストレージボリュームへのログイン
CentOS6 から上記 1) で取得した IQN を元に、iSCSI ボリュームにログインします。

# iscsiadm -m node -T 表示されたIQN -p QuantaStorのIPアドレス -l

3) iSCSI セッションの状態の表示
iSCSI デバイスのセッションの状態を表示するには CentOS6 から以下のコマンドを実行します。

# iscsiadm -m session -o show

4) iSCSI デバイスのマウントおよびテスト・ファイルの作成
順調にすすんでいれば、この段階で CentOS6 から 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   40G  0 disk

次に、パーティション、ファイルシステムを作成後にマウントして、テスト用のファイルを作成後にアンマウントします。

# fdisk /dev/sda
# mkfs.ext4 /dev/sda1
# mount /dev/sda1 /mnt
# date > /mnt/test.dat && echo this is test >> /mnt/test.dat
# cat /mnt/test.dat
Wed May 20 21:14:57 CDT 2015
this is test
# umount /mnt

5) クラウドバックアップ
QuantaStor の管理用 Web インターフェースから CentOS6 へ提供していたストレージボリュームを右クリックし、「クラウドバックアップの作成」を選択します。表示されたダイアログボックスで、クラウドストレージコンテナを選択すれば、SoftLayer のオブジェクト・ストレージ上へのストレージボリュームのバックアップが開始されます。

管理用 Webインターフェースの画面下側にクラウドバックアップの進行状況が表示され、完了時に以下のようなメッセージが表示されます。

Cloud backup 'StorageVolume1_backup000' created from source volume 'StorageVolume1' in storage pool 'StoragePool1'.

また、管理用 Web インターフェース上のクラウドコンテナ→クラウドコンテナストレージにクラウドバックアップとして StorageVolume1_backup000 が表示されます。

6) テスト用ファイルの削除
CentOS6 から以下の要領で、再度ストレージボリュームをマウントし、作成したファイルを削除後に、iSCSI セッションからもログアウトします。

# mount /dev/sda1 /mnt
# rm /mnt/test.dat
rm: remove regular file `/mnt/test.dat'? y
# ls /mnt/
lost+found
# umount /mnt
# iscsiadm -m node -T ストレージボリュームのIQN -p QuantaStorのIPアドレス -u

7) クラウドバックアップのリストア
QuantaStor の管理用 Web インターフェースから 5) で作成したクラウドバックアップ StorageVolume1_backup000 を右クリックし、「ストレージボリュームクラウドバックアップからの復元」を選択します。しばらくすると新しいストレージボリューム StorageVolume1_backup000_recovered000 としてリストアが完了します。

リストア完了後に、CentOS6 から元のストレージボリュームからホストアクセス定義を削除し、代わりにリストアにより作成された新しいストレージボリュームへのホストアクセス定義を追加します。

そして、以下の様に、CentOS6 から iSCSI ターゲットの再ディスカバリー、ログイン、デバイス名の確認、マウントを経て、6) で削除したファイルが参照できることを確認しています。

# iscsiadm -m discovery -t st -p QuantaStorのIPアドレス
# iscsiadm -m node -T (discoveryで表示される)リストアされたストレージボリュームのIQN -p QuantaStorのIPアドレス -l
# 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   40G  0 disk
└─sda1    8:1    0   40G  0 part
# mount /dev/sda1 /mnt
# cat /mnt/test.dat
Wed May 20 21:14:57 CDT 2015
this is test

嵌りどころ：
現在の QuantaStor の動作では、クラウドバックアップのリストア時は「別の」ストレージボリュームとしてリストアされます。別のストレージボリュームですので IQN も変わります。同一ストレージボリュームをリストア対象に選択することも、インターフェース上は可能ですが、タスクがキューされたまま、開始されず、以下のエラーが /var/log/qs_service.log に大量に記録されます。

{Wed May 20 22:34:43 2015, WARN, b2b41700:cmn_lock_manager:190} Invalid object ID specified to lock manager for task with ID 'ebcb4e72-34fc-a82d-b878-c6625d79a7fa'.

そこで、上記の手順では、リストアされるストレージボリュームの省略時値の名前を受け入れ、元々のストレージのボリュームに代わりにアクセスすることとしました。

7. まとめ

これまで、オブジェクト・ストレージを使う機会がほとんどなかったので、ブロック・デバイスをそのままバックアップしてしまう他、今回の記事では触れていませんが、CIFS/NFS 経由でのオブジェクト・ストレージへのアクセスを提供する QuantaStor はオブジェクト・ストレージの活用ツールとして非常に良くできています。
一方で、嵌りどころに記載した以外に、プール上では作成サイズの 20% の容量を消費していたボリュームがリストアすると 100% のサイズになってしまう、マニュアルの記載がそっくり TBD となっている、といった点がありますが、今後改善されていくと思われます。

参考:
QuantaStor Administrators Guide
How to integrate SoftLayer’s Object Storage OSNEXUS QuantaStor