1. 1
2014/7/30 v1
Tomoaki Nakajima(@irix_jp)
openstackOpen source software to build public and private clouds.
ボリューム編
ボリュームサービスを活用した
データのバックアップ

2. 2
前提環境
step
Instance
<userid>-router
Router
app-server1
Instance
Ext-Net
<userid>-network
10.0.0.0/24
app-server
Instance
10.0.0.1
10.0.0.N
10.0.0.N
10.0.0.N

3. 3
目次
●
ボリュームサービス
●
ボリュームサービスの必要性
●
ボリュームの用途
●
ボリューム・スナップショット、他
●
ボリュームバックアップによる
データの自動バックアップ
●
バックアップパターン
●
VM 環境変更
●
バックアップの自動化
●
バックアップからのリストア

4. 4
ボリュームサービス

5. 5
課題
●
現在のサンプルアプリ環境は DB も含めて 1 インス
タンス内に存在しているため、インスタンス障害時
に、データが消失してしまう危険がある。
VM

6. 6
OpenStack のディスク構成
●
OpenStack ではインスタンスの仮想ディスクが、イ
ンスタンスの起動する物理ホスト上のローカルディ
スクへ保存される (*1)
。このため物理ホスト障害等に
よるデータロストの危険が存在しています。
VM ホスト ストレージ
VM
VM
VM
VM
VM
VM
VM ホストが故障すると
VM も使用不能
→ サービス停止！
VM ホスト ストレージ
VM
VM
VM
VM
VM
VM
VM ホスト ストレージ
VM
VM
VM
VM
VM
VM
(*1)OpenStack サービスを提供する側の構成によっては、インスタンスのデータを共有ディスク等へ集約することも可能です。
OpenStack クラスタ

7. 7
データの永続化方法
●
そのため、 OpenStack にはインスタンスからデー
タを切り離し、重要データを保存すための「ボリュー
ムサービス」が存在しています。
VM ホスト ストレージ
VM
VM
VM
VM
VM
VM
VM ホスト ストレージ
VM
VM
VM
VM
VM
VM
VM ホストが故障すると
VM も使用不能
→ サービス停止！
ボリューム
重要データを入れた仮想ディス
クを別ホスト上の VM で使用
→サービス継続

8. 8
ボリュームサービスとは
●
VM とは独立した VM 用仮想ストレージ（ボリュー
ム）を提供するクラウドサービス
●
OpenStack では Cinder が機能を担当
●
OpenStack Block Storage (Cinder)
– ボリュームのバックアップ・リストア
– ボリュームから別ボリュームを作成
– Boot from Volume 機能をサポート
●
AWS では Amazon Elastic Block Storage (EBS) に相
当する機能

9. 9
ボリュームの用途
ボリューム上に置くべきデータ
●
永続的で重要なデータ
●
外部から入手しづらい／不可能なデータ
●
レプリケーション（複製）に向かないデータ
例
●
データベースサーバ … DB ファイル
●
ファイルサーバ …共有ファイル
●
バックアップサーバ …バックアップデータ

10. 10
ボリュームの特徴
VM （インスタンス）用の外付け仮想ディスク
●
VM とは別管理
●
VM を削除してもボリュームは残る
●
任意の VM に接続できる
VM
VM
付
け
替
え
ボリューム
※ 複数の VM に同時接続できません。

11. 11
ボリュームのスナップショット
ある時点のボリュームのバックアップ
●
１ボリュームから複数のスナップショットを作成できる
●
スナップショットから複数の別ボリュームを作成できる
●
VM には接続できない
スナップ
ショット
VM
ボリューム
スナップ
ショット
ボリューム
スナップショット
作成
別ボリューム作成
VM 接続不可
ボリューム

12. 12
ボリュームのバックアップ・リストア
ボリュームを別ストレージシステム上にバックアップ
●
OpenStack Object Storage (Swift) 等にバックアップできる
VM ボリューム
バックアップ作
成
リストア
ボリューム
バックアップ
ボリューム

13. 13
ボリュームの複製
ボリュームをコピーした新しいボリューム
●
VM に接続できる
●
バックアップ手段として利用できる
VM
ボリューム
ボリューム
別ボリューム作
成
VM 接続可

14. 14
ボリュームスナップショット、複製、
バックアップの違い
ボリューム
スナップショット、複製
ボリューム
バックアップ
データの保存先
通常はボリュームの
バックエンドストレージ
と同一
通常はボリュームの
バックエンドストレージ
とは別のストレージ
バックアップ・リストア
速度
一般的に早い
（同じストレージ内の
ため）
一般的に遅い
（別ストレージに転送す
るため）
元ボリュームへの
リストア × ○
新規ボリュームへの
リストア
○ ○
可用性 ボリュームバックエンド
ストレージに依存
バックアップ用
ストレージに依存

15. 15
バックエンド
ストレージ
（ Swift 、 Ceph 等）
バックエンド
ストレージ
（ Swift 、 Ceph 等）
ボリューム・ VM テンプレート間コピー
OpenStack Image Service (Glance) との連携
●
ボリュームデータから新しい VM テンプレートを作成
●
VM テンプレートから新しいボリュームを作成
VM
ボリューム
ボリュームから
VM テンプレー
ト作成
VM テンプレー
ト
イメージ
ボリューム
OpenStack
Image
Service
(Glance)
VM テンプレー
ト
からボリューム
作成

16. 16
ボリュームからのゲスト OS 起動
●
Boot from Volume
●
予め VM テンプレートをコピーしたボリュームを用意
●
上記ボリュームを接続した状態の VM を作成・起動
バックエンド
ストレージ
（ Swift 、 Ceph 等）
バックエンド
ストレージ
（ Swift 、 Ceph 等）
VM
VM テンプレー
ト
イメージ
ボリューム
OpenStack
Image
Service
(Glance)
VM テンプレー
ト
からボリューム
作成
ボリューム接続状態の
VM 作成・起動

17. 17
HP Public Cloud
ボリュームサービスの対応機能
操作 可否
ボリューム作成・削除 ○
ボリューム⇒ボリュームスナップショット作成 *1
・削除 ○
ボリュームスナップショット⇒ボリューム作成 ○
ボリューム⇒ボリューム作成 ○
ボリュームバックアップ・リストア *1
○
VM テンプレートイメージ⇒ボリューム作成 ○
ボリューム⇒ VM テンプレートイメージ作成 ×
ボリュームからの VM 起動 ○
*1) ：予めボリュームをデタッチ状態にする必要あり

18. 18
ボリュームバックアップによる
データの自動バックアップ

19. 19
ボリューム利用 VM の方式比較
重要データのみ
ボリューム上に配置
全データを
ボリューム上に配置
VM の起動
ディスク
エフェメラルディスク ボリューム
メリット
● VM の OS をアップグレード・
ダウングレードしやすい
● VM 稼働中にボリューム操作
が出来る※１
●
データ領域のリサイズがやり
やすい
●
構造が単純で、ＶＭのシステム
構築をしやすい
●
ＶＭホスト故障時、別ＶＭホスト上
でＶＭをすぐに再起動できる
デメリット
● 構造がやや複雑で、 VM の
システム構築も一手間かかる
●
ＶＭホスト障害時、ＶＭのＯＳ
部分は再構築が必要※３
● VM の OS をアップグレード・ダウ
ングレードしにくい
●
ボリューム操作時にＶＭを削除す
る必要がある※２
※ １：基本的にボリューム操作時にはボリュームをデタッチする必要がある
※ ２：ボリューム起動 VM の場合、 VM 停止時でも VM のデタッチができない
※ ３： VM の起動用エフェメラルディスクも VM スナップショット作成でバックアップできる

20. 20
バックアップパターン①
全データをボリューム上に配置
バックエンドストレージバックエンドストレージ
VM
ボリューム
② ボリュームの
バックアップを作成
③ 古いバックアップを削除
ボリューム
バックアップ
①VM を削除 ④VM を作成
VM
② 実施に
① 実施が
必要

21. 21
バックアップパターン②
重要データをボリューム上に配置
バックエンドストレージバックエンドストレージ
VM
ボリューム
④ ボリュームの
バックアップを作成
⑤ 古いバックアップを削除
ボリューム
バックアップ
DB
①DB 等のアプリケーションを停止
⑧DB 等のアプリケーションを起動
② ボリューム上のファイルシステムをアンマウント
⑦ ボリューム上のファイルシステムをマウント
③ ボリュームをデタッチ（切断）
⑥ ボリュームをアタッチ（接続）

22. 22
どちらを使うべきか
バックアップパターン①が適しているケース
●
VM 上のアプリ環境構築が自動化できない場合
●
VM ホスト障害時の迅速な復旧が必要な場合
バックアップパターン②が適しているケース
●
VM 上のアプリ環境構築が自動化できる場合
●
ボリュームのスナップショットやバックアップでデータを
バックアップする場合
●
定期的に OS やアプリケーションのアップグレードを行う
場合
今回はバックアップパターン②を採用します

23. 23
操作の概要
●
サンプルアプリが稼働するインスタンへボリューム
を接続し、 MySQL のデータファイルをボリューム上
へ移動します。
app-server
VOL
DBF

24. 24
VM 環境変更
●
アプリケーション停止
●
新規ボリューム作成
●
VM にボリュームをアタッチ
●
ボリューム上にパーティション作成
●
パーティション上にファイルシステム構築・マウント
●
ファイルシステム上に VM 上の重要データをコピー
●
ファイルシステムのマウント場所を移動
●
自動マウント設定
●
アプリケーション起動

25. 25
操作の前に
●
サンプルアプリにデータを投入しておいてください。

26. 26
新規ボリューム作成①
② 「 Create Volume 」クリック
① 「 Volumes 」クリック

27. 27
新規ボリューム作成②
③ ボリューム名入力
④ サイズ入力 (GB 単位 )
⑥ 「 Create Volume 」クリック⑤ アベイラビリティゾーン指定
（ VM と同じゾーンを指定）
data
1GB

28. 28
VM にボリュームをアタッチ①
① 「 More 」クリック
② 「 Edit Attachment 」クリック

29. 29
VM にボリュームをアタッチ②
③ アタッチする VM を選択 ④ 「 Attach Volume 」クリック
app-server へ
接続します。

30. 30
パーティションを作成
● ディスクデバイス名確認
# dmesg | tail ­2
virtio­pci 0000:00:07.0: irq 32 for MSI/MSI­X
vdc: unknown partition table
● パーティション作成
# fdisk /dev/vdc
（略）
コマンド (m でヘルプ ): n ¿
コマンドアクション
e 拡張
p 基本パーティション (1­4)
p ¿
パーティション番号 (1­4): 1 ¿
最初 シリンダ (1­208050, 初期値 1): ¿
初期値 1 を使います
Last シリンダ , + シリンダ数 or +size{K,M,G} (1­208050, 初期値 208050): ¿
初期値 208050 を使います
コマンド (m でヘルプ ): w ¿
パーティションテーブルは変更されました！
ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。
app-server

31. 31
ボリューム上にファイルシステムを
構築・マウント
● Ｅｘｔ４ファイルシステム作成
# mkfs.ext4 ­L data /dev/vdc1
mke2fs 1.41.12 (17­May­2010)
Filesystem label=data
OS type: Linux
Block size=4096 (log=2)
（略）
This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first. Use tune2fs ­c or ­i to override.
● ファイルシステムの定期チェック無効化、リザーブ率変更
# tune2fs ­c 0 ­i 0 ­r 0 /dev/vdc1
tune2fs 1.41.12 (17­May­2010)
Setting maximal mount count to ­1
Setting interval between checks to 0 seconds
Setting reserved blocks count to 0
● ファイルシステムを仮マウントポイントにマウント
# mkdir /tmp/data
# mount LABEL=data /tmp/data
app-server

32. 32
ファイルシステム上に VM 上の重要
データをコピー
● ＭｙＳＱＬサーバ停止
# service mysqld stop
Stopping mysqld: [ OK ]
● ＭｙＳＱＬデータベースファイル用ディレクトリ内容確認
# ls /var/lib/mysql/
ib_logfile0 ib_logfile1 ibdata1 mysql test
● 全ファイルコピー
# chown mysql:mysql /tmp/data
# cp ­a /var/lib/mysql/. /tmp/data/
● コピー結果確認
# ls /tmp/data
ib_logfile0 ib_logfile1 ibdata1 lost+found mysql test
app-server

33. 33
自動マウント設定
● テキストエディタで fstab 編集
# nano /etc/fstab
● ｆｓｔａｂの例
#
# /etc/fstab
# Created by anaconda on Wed Jan 16 10:31:20 2013
#
# Accessible filesystems, by reference, are maintained under '/dev
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for
#
UUID=08244660­c848­48ef­8ec7­3a754e6a38b7 / ext4 defaults 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/vdb /mnt auto defaults,nofail,comment=cloudconfig 0 2
● 下記１行を追加
LABEL=data /var/lib/mysql ext4 defaults,noatime 0 0
app-server

34. 34
ファイルシステムをマウント
● 現状確認
# df ­h
Filesystem Size Used Avail Use% マウント位置
/dev/vda1 9.9G 1.1G 8.4G 12% /
tmpfs 499M 0 499M 0% /dev/shm
/dev/vdb 9.9G 151M 9.2G 2% /mnt
/dev/vdc1 1008M 39M 970M 4% /tmp/data
● マウント先変更
# umount /tmp/data
# mount /var/lib/mysql
● 変更確認
# df ­h
Filesystem Size Used Avail Use% マウント位置
/dev/vda1 9.9G 1.1G 8.4G 12% /
tmpfs 499M 0 499M 0% /dev/shm
/dev/vdb 9.9G 151M 9.2G 2% /mnt
/dev/vdc1 1008M 39M 970M 4% /var/lib/mysql
app-server

35. 35
サービスの起動
● ＭｙＳＱＬサーバ起動
# service mysqld start
Starting mysqld: [ OK ]
● サンプルアプリの再起動
# ps ­ef |grep rest.py
root 28925 1 0 20:17 pts/0 00:00:01 python rest.py
root 28932 28925 1 20:17 pts/0 00:00:02 /usr/bin/python rest.py
root 28949 28632 0 20:20 pts/0 00:00:00 grep python
# kill 28932
# sh /root/openstack­sample­app/server­setup/rest.init.sh

36. 36
確認
●
サンプルアプリへアクセスして、データが保持され
ていることを確認してください。

37. 37
バックアップの設定
●
次は接続したボリュームのバックアップを行っていき
ます。
app-server
VOL
DBF
SwiftSwift
VOL
VOL

38. 38
バックアップの設定
●
バックアップ先コンテナ作成
●
VM 上に Cinder クライアントをインストール
●
VM 上に OpenStack 認証情報作成
●
自動バックアップスクリプト準備
●
定期バックアップ実行設定

39. 39
バックアップ先コンテナ作成①
③ 「 Create Container 」クリック
① 「 Object Store 」クリック
② 「 Containers 」クリック

40. 40
バックアップ先コンテナ作成②
⑤ 「 Create Container 」クリック
④ コンテナ名を入力

41. 41
VM に OpenStack のクライアントを
インストール
● ＲＰＭリポジトリ情報設定
# yum install ­y http://rdo.fedorapeople.org/rdo­release.rpm
Loaded plugins: fastestmirror, security
Determining fastest mirrors
（略）
Installed:
rdo­release.noarch 0:icehouse­3
Complete!
● ＯｐｅｎＳｔａｃｋクライアント群インストール
# yum install ­y python­novaclient
python­cinderclient python­keystoneclient
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
（略）
Installed:
python­cinderclient.noarch 0:1.0.9­1.el6
python­keystoneclient.noarch 1:0.9.0­1.el6
python­novaclient.noarch 1:2.17.0­2.el6
Complete!
app-server

42. 42
VM 上に OpenStack 認証情報作成
● 制御用 VM からデータベース VM にクレデンシャルファイルをコピー
# scp /root/openrc ｒｏｏｔ＠〈固定ＩＰ〉： /root/
*app­server の IP を指定してください。
● データベース VM 上でクレデンシャルファイルをテスト
# source openrc
# cinder list
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­
| ID | Status | Display Name | Size |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­
| ce5e93bb­5027­4a6a­b525­09fd1dd38047 | available | data | 1 |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­
step-server
app-server

43. 43
自動バックアップスクリプト準備①
● ツールダウンロード・インストール
# git clone https://github.com/yosshy/openstack­sample­app.git backup
# backup/install.sh
● アプリケーションの通常自動起動無効化を確認
# chkconfig ­­list mysqld
mysqld 0:off 1:off 2:off 3:off 4:off 5:off 6:off
●rc.local の内容確認
# cat /etc/rc.d/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
/sbin/findfs LABEL=data || exit 0
/bin/mount /var/lib/mysql
/sbin/service mysqld start

44. 44
自動バックアップスクリプト準備②
● ファイルの先頭部分を編集
# nano /usr/local/bin/do_backup.sh
● 設定部分
# OpenStack API アクセス用クレデンシャルファイル（認証情報）のフルパス
CREDENTIALS=/root/openrc
# VM インスタンス名（ UUID 可） → nova list で確認
SERVER=app­server
# バックアップ対象ボリュームの UUID （名前不可） → cinder list で確認
VOLUME_ID=XXXXXXXX­XXXX­XXXX­XXXX­XXXXXXXXXXXX
# バックアップ先 Object Storage コンテナ名 → swift list で確認
CONTAINER=backup
# ボリューム上のファイルシステムラベル名
LABEL=data
# ボリューム上のファイルシステムのマウントポイント
MOUNT_POINT=/var/lib/mysql
● テスト実施
# bash ­xe /usr/local/bin/do_backup.sh

45. 45
サービスの起動
● サンプルアプリの再起動
# ps ­ef |grep rest.py
root 28925 1 0 20:17 pts/0 00:00:01 python rest.py
root 28932 28925 1 20:17 pts/0 00:00:02 /usr/bin/python rest.py
root 28949 28632 0 20:20 pts/0 00:00:00 grep python
# kill 28932
# sh /root/openstack­sample­app/server­setup/rest.init.sh
●
バックアップスクリプトの中ではアプリの再起動を
行っていないので、手動で再起動してください。

46. 46
バックアップの確認
●
取得されたバックアップは、
「 Project 」→「 Compute 」→「 Volume 」の、
「 Volume Backup 」タブから確認できます。

47. 47
定期バックアップ実行設定
●cron の日次実行（通常毎朝４時頃）で良ければ下記を実行
# ln ­s /usr/local/bin/do_backup.sh /etc/cron.daily/

48. 48
データのリストア
●
最後にバックアップデータから、データの復旧を行
います。
●
今回は既に存在している、 app-server1 へ復旧し
たボリュームを接続します。
app-server
VOL
DBF
SwiftSwift
VOL
VOL
app-server1
VOL
DBF

49. 49
データの復旧１
●
まず新規ボリュームを作成します。
[root@step­server ~]# cinder create ­­availability­zone az2 1
+­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+
| Property | Value |
+­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+
| attachments | [] |
| availability_zone | az2 |
| bootable | false |
| created_at | 2014­07­26T20:56:56.899026 |
| display_description | None |
| display_name | None |
| id | ec4e42e6­b08d­4c51­8814­042ddffad4e6 |
| metadata | {} |
| size | 1 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| volume_type | standard |
+­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+
AZ にはサーバと同じ場所を指定してください。

50. 50
データの復旧２
●
ボリュームの確認
●
ここで表示される available 状態のボリューム UUID
をメモしておきます。
– 以下の場合は
●
ec4e42e6-b08d-4c51-8814-042ddffad4e6
[root@step­server ~]# cinder list
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­­­­­­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+
| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­­­­­­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+
| 083a9c97­b1af­46f0­844a­58fc90b88b35 | in­use | None | 1 | standard | false | 5c38d93b­3dcf­44c3­9b45­16cb8d25e1cd |
| ec4e42e6­b08d­4c51­8814­042ddffad4e6 | available | None | 1 | standard | false | |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­­­­­­­­­­­­­+­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+

51. 51
データの復旧３
●
バックアップデータの確認
●
ここで表示されるバックアップデータの UUID をメモして
おきます。
– 以下の場合は
●
3969164b-0d21-4bd7-bac8-42e06827948e
[root@step­server ~]# cinder backup­list
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­+­­­­­­­­­­­­­­+­­­­­­­­­­­+
| ID | Volume ID | Status | Name | Size | Object Count | Container |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­+­­­­­­­­­­­­­­+­­­­­­­­­­­+
| 3969164b­0d21­4bd7­bac8­42e06827948e | 083a9c97­b1af­46f0­844a­58fc90b88b35 | available | 2014­07­26 20:36:36.118086 | 1 | 22 | backup |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­+­­­­­­­­­­­­­­+­­­­­­­­­­­+

52. 52
データの復旧４
●
作成したボリュームに、バックアップからデータを復
旧します。
●
cinder backup-restore –volume-id < リストア先のボリューム > < リストア元のバックアップ >
[root@step­server ~]# cinder backup­restore
­­volume­id ec4e42e6­b08d­4c51­8814­042ddffad4e6
3969164b­0d21­4bd7­bac8­42e06827948e
UUID で指定する必要があるため、指定を間違えないように気をつけてください。

53. 53
データの復旧 5
●
リストアが完了するのを待ちます。
●
リストア中は「 restoring-backup 」になり、完了すると
「 available 」に戻ります。
[root@step­server ~]# cinder list
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­+­
| ID | Status | Display Name |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­+­
| 083a9c97­b1af­46f0­844a­58fc90b88b35 | in­use | None |
| ec4e42e6­b08d­4c51­8814­042ddffad4e6 | restoring­backup | None |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­­­­+­
[root@step­server ~]# cinder list
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­­
| ID | Status | Display Name | Size | V
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­­
| 083a9c97­b1af­46f0­844a­58fc90b88b35 | in­use | None | 1 |
| ec4e42e6­b08d­4c51­8814­042ddffad4e6 | available | None | 1 |
+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+­­­­­­­­­­­+­­­­­­­­­­­­­­+­­­­­­+­­

54. 54
ボリュームの接続
●
app-server1 へボリュームを接続します。
[root@step­server ~]# nova volume­attach
app­server1 ec4e42e6­b08d­4c51­8814­042ddffad4e6 /dev/vdc
↑ ↑ ↑
接続先インスタンス ボリューム UUID インスタンスに認識させるデバイス名
+­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+
| Property | Value |
+­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+
| device | /dev/vdc |
| id | ec4e42e6­b08d­4c51­8814­042ddffad4e6 |
| serverId | 5c38d93b­3dcf­44c3­9b45­16cb8d25e1cd |
| volumeId | ec4e42e6­b08d­4c51­8814­042ddffad4e6 |
+­­­­­­­­­­+­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­+

55. 55
サーバからの認識
●
データがリストアされたボリュームなのでフォーマッ
ト等は不要なため、マウントすれば即利用できます。
[root@app­server1 ~]# service mysqld stop
[root@app­server1 ~]# mount LABEL=data /var/lib/mysql
[root@app­server1 ~]# service mysqld start
[root@app­server1 ~]# ps ­ef |grep rest.py
root 28925 1 0 20:17 pts/0 00:00:01 python rest.py
root 28932 28925 1 20:17 pts/0 00:00:02 /usr/bin/python rest.py
root 28949 28632 0 20:20 pts/0 00:00:00 grep python
[root@app­server1 ~]# kill 28932
[root@app­server1 ~]# sh /root/openstack­sample­app/server­setup/rest.init.sh

56. 56
データの確認
●
ブラウザで app-server, app-server1 へアクセス
し、同じデータになっていることを確認してください。

57. 57
まとめ
これまでの作業をまとめます。
●
ボリュームサービスについて説明しました
●
ボリューム： VM とは独立した仮想ディスク
●
既存の VM の重要データをボリューム上に移す
方法を説明しました
●
ボリュームサービスのバックアップ機能を使った
重要データのバックアップ手法を説明しました
●
ボリュームバックアップからボリュームデータを
リストアする方法を説明しました。

58. 58
ボリューム編 〜おつかれさまでした〜