1

2014/7/30 v1Tomoaki Nakajima(@irix_jp)

openstackOpen source software to build public and private clouds.

ボリューム編

ボリュームサービスを活用したデータのバックアップ

2

前提環境

stepInstance

<userid>-routerRouter

app-server1Instance

Ext-N

et

<userid>

-network

10.0.0.0/24

app-serverInstance

10.0.0.1

10.0.0.N

10.0.0.N

10.0.0.N

3

目次

● ボリュームサービス● ボリュームサービスの必要性● ボリュームの用途● ボリューム・スナップショット、他

● ボリュームバックアップによるデータの自動バックアップ● バックアップパターン● VM 環境変更● バックアップの自動化

● バックアップからのリストア

4

ボリュームサービス

5

課題

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

VM

6

OpenStack のディスク構成

● OpenStack ではインスタンスの仮想ディスクが、インスタンスの起動する物理ホスト上のローカルディスクへ保存される (*1) 。このため物理ホスト障害等によるデータロストの危険が存在しています。

VM ホスト ストレージ

VMVM

VMVM

VMVM

VM ホストが故障するとVM も使用不能

→ サービス停止！

VM ホスト ストレージ

VMVM

VMVM

VMVM

VM ホスト ストレージ

VMVM

VMVM

VMVM

(*1)OpenStack サービスを提供する側の構成によっては、インスタンスのデータを共有ディスク等へ集約することも可能です。

OpenStack クラスタ

7

データの永続化方法

● そのため、 OpenStack にはインスタンスからデータを切り離し、重要データを保存すための「ボリュームサービス」が存在しています。

VM ホスト ストレージ

VMVM

VMVM

VMVM

VM ホスト ストレージ

VMVM

VMVM

VMVM

VM ホストが故障するとVM も使用不能

→ サービス停止！ボリューム

重要データを入れた仮想ディスクを別ホスト上の VM で使用

→サービス継続

8

ボリュームサービスとは

● VM とは独立した VM 用仮想ストレージ（ボリューム）を提供するクラウドサービス

● OpenStack では Cinder が機能を担当● OpenStack Block Storage (Cinder)

– ボリュームのバックアップ・リストア– ボリュームから別ボリュームを作成– Boot from Volume 機能をサポート

● AWS では Amazon Elastic Block Storage (EBS) に相当する機能

9

ボリュームの用途

ボリューム上に置くべきデータ● 永続的で重要なデータ● 外部から入手しづらい／不可能なデータ● レプリケーション（複製）に向かないデータ

例● データベースサーバ　… DB ファイル● ファイルサーバ　…共有ファイル● バックアップサーバ　…バックアップデータ

10

ボリュームの特徴

VM （インスタンス）用の外付け仮想ディスク● VM とは別管理● VM を削除してもボリュームは残る● 任意の VM に接続できる

VM

VM

付け替え

ボリューム

※ 複数の VM に同時接続できません。

11

ボリュームのスナップショット

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

スナップショットVM

ボリューム

スナップショット

ボリュームスナップショット作成

別ボリューム作成VM 接続不可

ボリューム

12

ボリュームのバックアップ・リストア

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

VM ボリューム

バックアップ作成

リストア

ボリュームバックアップ

ボリューム

13

ボリュームの複製

ボリュームをコピーした新しいボリューム● VM に接続できる● バックアップ手段として利用できる

VM

ボリューム

ボリューム

別ボリューム作成

VM 接続可

14

ボリュームスナップショット、複製、バックアップの違い

ボリュームスナップショット、複製

ボリュームバックアップ

データの保存先通常はボリュームの

バックエンドストレージと同一

通常はボリュームのバックエンドストレージ

とは別のストレージ

バックアップ・リストア速度

一般的に早い（同じストレージ内の

ため）

一般的に遅い（別ストレージに転送す

るため）

元ボリュームへのリストア × ○

新規ボリュームへのリストア ○ ○

可用性 ボリュームバックエンドストレージに依存

バックアップ用ストレージに依存

15

バックエンドストレージ

（ Swift 、 Ceph 等）

バックエンドストレージ

（ Swift 、 Ceph 等）

ボリューム・ VM テンプレート間コピー

OpenStack Image Service (Glance) との連携● ボリュームデータから新しい VM テンプレートを作成● VM テンプレートから新しいボリュームを作成

VM

ボリューム

ボリュームからVM テンプレー

ト作成

VM テンプレート

イメージ

ボリューム

OpenStackImageService(Glance)

VM テンプレート

からボリューム作成

16

ボリュームからのゲスト OS 起動

● Boot from Volume● 予め VM テンプレートをコピーしたボリュームを用意● 上記ボリュームを接続した状態の VM を作成・起動

バックエンドストレージ

（ Swift 、 Ceph 等）

バックエンドストレージ

（ Swift 、 Ceph 等）

VMVM テンプレー

トイメージ

ボリューム

OpenStackImage

Service(Glance)

VM テンプレート

からボリューム作成

ボリューム接続状態のVM 作成・起動

17

HP Public Cloudボリュームサービスの対応機能

操作 可否

ボリューム作成・削除 ○ボリューム⇒ボリュームスナップショット作成 *1 ・削除 ○

ボリュームスナップショット⇒ボリューム作成 ○ボリューム⇒ボリューム作成 ○ボリュームバックアップ・リストア *1 ○

VM テンプレートイメージ⇒ボリューム作成 ○

ボリューム⇒VM テンプレートイメージ作成 ×

ボリュームからの VM 起動 ○

*1) ：予めボリュームをデタッチ状態にする必要あり

18

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

19

ボリューム利用 VM の方式比較

重要データのみボリューム上に配置

全データをボリューム上に配置

VM の起動ディスク

エフェメラルディスク ボリューム

メリット

● VM の OS をアップグレード・ダウングレードしやすい

● VM稼働中にボリューム操作が出来る※１

● データ領域のリサイズがやりやすい

● 構造が単純で、ＶＭのシステム構築をしやすい

● ＶＭホスト故障時、別ＶＭホスト上でＶＭをすぐに再起動できる

デメリット

● 構造がやや複雑で、 VM のシステム構築も一手間かかる

● ＶＭホスト障害時、ＶＭのＯＳ部分は再構築が必要※３

● VM の OS をアップグレード・ダウングレードしにくい

● ボリューム操作時にＶＭを削除する必要がある※２

※ １：基本的にボリューム操作時にはボリュームをデタッチする必要がある※ ２：ボリューム起動 VM の場合、 VM 停止時でも VM のデタッチができない※ ３： VM の起動用エフェメラルディスクも VM スナップショット作成でバックアップできる

20

バックアップパターン①全データをボリューム上に配置

バックエンドストレージバックエンドストレージ

VM

ボリューム② ボリュームの　バックアップを作成③ 古いバックアップを削除

ボリュームバックアップ

①VM を削除 ④VM を作成

VM

② 実施に① 実施が

必要

21

バックアップパターン②重要データをボリューム上に配置

バックエンドストレージバックエンドストレージ

VM

ボリューム④ ボリュームの　バックアップを作成⑤ 古いバックアップを削除

ボリュームバックアップ

DB ①DB 等のアプリケーションを停止⑧DB 等のアプリケーションを起動

② ボリューム上のファイルシステムをアンマウント⑦ ボリューム上のファイルシステムをマウント

③ ボリュームをデタッチ（切断）⑥ ボリュームをアタッチ（接続）

22

どちらを使うべきか

バックアップパターン①が適しているケース● VM 上のアプリ環境構築が自動化できない場合● VM ホスト障害時の迅速な復旧が必要な場合

バックアップパターン②が適しているケース● VM 上のアプリ環境構築が自動化できる場合● ボリュームのスナップショットやバックアップでデータを

バックアップする場合● 定期的に OSやアプリケーションのアップグレードを行う場合

今回はバックアップパターン②を採用します

23

操作の概要

● サンプルアプリが稼働するインスタンへボリュームを接続し、 MySQLのデータファイルをボリューム上へ移動します。

app-serverVOL

DBF

24

VM 環境変更

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

25

操作の前に

● サンプルアプリにデータを投入しておいてください。

26

新規ボリューム作成①

② 「 Create Volume 」クリック

① 「 Volumes 」クリック

27

新規ボリューム作成②

③ ボリューム名入力

④ サイズ入力 (GB 単位 )

⑥ 「 Create Volume 」クリック⑤ アベイラビリティゾーン指定（ VM と同じゾーンを指定）

data

1GB

28

VM にボリュームをアタッチ①

① 「 More 」クリック

② 「 Edit Attachment 」クリック

29

VM にボリュームをアタッチ②

③ アタッチする VM を選択 ④ 「 Attach Volume 」クリック

app-server へ接続します。

30

パーティションを作成

● ディスクデバイス名確認# dmesg | tail ­2virtio­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

ボリューム上にファイルシステムを構築・マウント

● Ｅｘｔ４ファイルシステム作成# mkfs.ext4 ­L data /dev/vdc1mke2fs 1.41.12 (17­May­2010)Filesystem label=dataOS type: LinuxBlock size=4096 (log=2)（略）This filesystem will be automatically checked every 23 mounts or180 days, whichever comes first.  Use tune2fs ­c or ­i to override.

● ファイルシステムの定期チェック無効化、リザーブ率変更# tune2fs ­c 0 ­i 0 ­r 0 /dev/vdc1tune2fs 1.41.12 (17­May­2010)Setting maximal mount count to ­1Setting interval between checks to 0 secondsSetting reserved blocks count to 0

● ファイルシステムを仮マウントポイントにマウント# mkdir /tmp/data# mount LABEL=data /tmp/data

app-server

32

ファイルシステム上に VM 上の重要データをコピー

● ＭｙＳＱＬサーバ停止# service mysqld stopStopping 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/dataib_logfile0  ib_logfile1  ibdata1  lost+found  mysql  test

app-server

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 1tmpfs     /dev/shm  tmpfs   defaults        0 0devpts    /dev/pts  devpts  gid=5,mode=620  0 0sysfs     /sys      sysfs   defaults        0 0proc      /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

ファイルシステムをマウント

● 現状確認# df ­hFilesystem            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 ­hFilesystem            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

サービスの起動

● ＭｙＳＱＬサーバ起動# service mysqld startStarting mysqld:                                           [  OK  ]

● サンプルアプリの再起動# ps ­ef |grep rest.pyroot     28925     1  0 20:17 pts/0    00:00:01 python rest.pyroot     28932 28925  1 20:17 pts/0    00:00:02 /usr/bin/python rest.pyroot     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

確認

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

37

バックアップの設定

● 次は接続したボリュームのバックアップを行っていきます。

app-server

VOL

DBF

SwiftSwift

VOLVOL

38

バックアップの設定

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

39

バックアップ先コンテナ作成①

③ 「 Create Container 」クリック

① 「 Object Store 」クリック

② 「 Containers 」クリック

40

バックアップ先コンテナ作成②

⑤ 「 Create Container 」クリック

④ コンテナ名を入力

41

VM に OpenStack のクライアントをインストール

● ＲＰＭリポジトリ情報設定# yum install ­y http://rdo.fedorapeople.org/rdo­release.rpmLoaded plugins: fastestmirror, securityDetermining fastest mirrors（略）Installed:  rdo­release.noarch 0:icehouse­3

Complete!

● ＯｐｅｎＳｔａｃｋクライアント群インストール# yum install ­y python­novaclient \  python­cinderclient python­keystoneclientLoaded plugins: fastestmirror, securityLoading 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

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

自動バックアップスクリプト準備①

● ツールダウンロード・インストール# git clone https://github.com/yosshy/openstack­sample­app.git backup# backup/install.sh

● アプリケーションの通常自動起動無効化を確認# chkconfig ­­list mysqldmysqld          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

自動バックアップスクリプト準備②

● ファイルの先頭部分を編集# 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

サービスの起動

● サンプルアプリの再起動# ps ­ef |grep rest.pyroot     28925     1  0 20:17 pts/0    00:00:01 python rest.pyroot     28932 28925  1 20:17 pts/0    00:00:02 /usr/bin/python rest.pyroot     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

バックアップの確認

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

47

定期バックアップ実行設定

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

48

データのリストア

● 最後にバックアップデータから、データの復旧を行います。

● 今回は既に存在している、 app-server1 へ復旧したボリュームを接続します。

app-serverVOL

DBF

SwiftSwift

VOLVOL

app-server1VOL

DBF

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

データの復旧２

● ボリュームの確認● ここで表示される 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

データの復旧３

● バックアップデータの確認● ここで表示されるバックアップデータの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

データの復旧４

● 作成したボリュームに、バックアップからデータを復旧します。

● 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

データの復旧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

ボリュームの接続

● 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

サーバからの認識

● データがリストアされたボリュームなのでフォーマット等は不要なため、マウントすれば即利用できます。

[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.pyroot     28925     1  0 20:17 pts/0    00:00:01 python rest.pyroot     28932 28925  1 20:17 pts/0    00:00:02 /usr/bin/python rest.pyroot     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

データの確認

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

57

まとめ

これまでの作業をまとめます。● ボリュームサービスについて説明しました

● ボリューム： VM とは独立した仮想ディスク● 既存の VM の重要データをボリューム上に移す

方法を説明しました● ボリュームサービスのバックアップ機能を使った

重要データのバックアップ手法を説明しました● ボリュームバックアップからボリュームデータを

リストアする方法を説明しました。

58

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