Download - H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編
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
ボリュームのスナップショット
ある時点のボリュームのバックアップ● 1ボリュームから複数のスナップショットを作成できる● スナップショットから複数の別ボリュームを作成できる● 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稼働中にボリューム操作が出来る※1
● データ領域のリサイズがやりやすい
● 構造が単純で、VMのシステム構築をしやすい
● VMホスト故障時、別VMホスト上でVMをすぐに再起動できる
デメリット
● 構造がやや複雑で、 VM のシステム構築も一手間かかる
● VMホスト障害時、VMのOS部分は再構築が必要※3
● VM の OS をアップグレード・ダウングレードしにくい
● ボリューム操作時にVMを削除する必要がある※2
※ 1:基本的にボリューム操作時にはボリュームをデタッチする必要がある※ 2:ボリューム起動 VM の場合、 VM 停止時でも VM のデタッチができない※ 3: 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 2virtiopci 0000:00:07.0: irq 32 for MSI/MSIX vdc: unknown partition table
● パーティション作成# fdisk /dev/vdc(略)コマンド (m でヘルプ ): n ¿コマンドアクション e 拡張 p 基本パーティション (14)p ¿パーティション番号 (14): 1 ¿最初 シリンダ (1208050, 初期値 1): ¿初期値 1 を使いますLast シリンダ , + シリンダ数 or +size{K,M,G} (1208050, 初期値 208050): ¿初期値 208050 を使いますコマンド (m でヘルプ ): w ¿パーティションテーブルは変更されました!
ioctl() を呼び出してパーティションテーブルを再読込みします。ディスクを同期しています。
app-server
31
ボリューム上にファイルシステムを構築・マウント
● Ext4ファイルシステム作成# mkfs.ext4 L data /dev/vdc1mke2fs 1.41.12 (17May2010)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 (17May2010)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 上の重要データをコピー
● MySQLサーバ停止# service mysqld stopStopping mysqld: [ OK ]
● MySQLデータベースファイル用ディレクトリ内容確認# 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
● 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=08244660c84848ef8ec73a754e6a38b7 / 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
● 下記1行を追加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
サービスの起動
● MySQLサーバ起動# 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/openstacksampleapp/serversetup/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 のクライアントをインストール
● RPMリポジトリ情報設定# yum install y http://rdo.fedorapeople.org/rdorelease.rpmLoaded plugins: fastestmirror, securityDetermining fastest mirrors(略)Installed: rdorelease.noarch 0:icehouse3
Complete!
● OpenStackクライアント群インストール# yum install y pythonnovaclient \ pythoncinderclient pythonkeystoneclientLoaded plugins: fastestmirror, securityLoading mirror speeds from cached hostfile(略)Installed: pythoncinderclient.noarch 0:1.0.91.el6 pythonkeystoneclient.noarch 1:0.9.01.el6 pythonnovaclient.noarch 1:2.17.02.el6
Complete!
app-server
42
VM 上に OpenStack認証情報作成
● 制御用 VM からデータベース VM にクレデンシャルファイルをコピー# scp /root/openrc root@〈固定IP〉: /root/ *appserver の IP を指定してください。
● データベース VM 上でクレデンシャルファイルをテスト# source openrc# cinder list+++++| ID | Status | Display Name | Size | +++++| ce5e93bb50274a6ab52509fd1dd38047 | available | data | 1 | +++++
step-server
app-server
43
自動バックアップスクリプト準備①
● ツールダウンロード・インストール# git clone https://github.com/yosshy/openstacksampleapp.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=appserver # バックアップ対象ボリュームの UUID (名前不可) → cinder list で確認 VOLUME_ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # バックアップ先 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/openstacksampleapp/serversetup/rest.init.sh
● バックアップスクリプトの中ではアプリの再起動を行っていないので、手動で再起動してください。
46
バックアップの確認
● 取得されたバックアップは、「 Project 」→「 Compute 」→「 Volume 」の、「 Volume Backup 」タブから確認できます。
47
定期バックアップ実行設定
●cron の日次実行(通常毎朝4時頃)で良ければ下記を実行# ln s /usr/local/bin/do_backup.sh /etc/cron.daily/
48
データのリストア
● 最後にバックアップデータから、データの復旧を行います。
● 今回は既に存在している、 app-server1 へ復旧したボリュームを接続します。
app-serverVOL
DBF
SwiftSwift
VOLVOL
app-server1VOL
DBF
49
データの復旧1
● まず新規ボリュームを作成します。[root@stepserver ~]# cinder create availabilityzone az2 1+++| Property | Value |+++| attachments | [] || availability_zone | az2 || bootable | false || created_at | 20140726T20:56:56.899026 || display_description | None || display_name | None || id | ec4e42e6b08d4c518814042ddffad4e6 || metadata | {} || size | 1 || snapshot_id | None || source_volid | None || status | creating || volume_type | standard |+++
AZ にはサーバと同じ場所を指定してください。
50
データの復旧2
● ボリュームの確認● ここで表示される available 状態のボリュームUUID
をメモしておきます。– 以下の場合は
● ec4e42e6-b08d-4c51-8814-042ddffad4e6
[root@stepserver ~]# cinder list++++++++| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to |++++++++| 083a9c97b1af46f0844a58fc90b88b35 | inuse | None | 1 | standard | false | 5c38d93b3dcf44c39b4516cb8d25e1cd || ec4e42e6b08d4c518814042ddffad4e6 | available | None | 1 | standard | false | |++++++++
51
データの復旧3
● バックアップデータの確認● ここで表示されるバックアップデータのUUID をメモしておきます。– 以下の場合は
● 3969164b-0d21-4bd7-bac8-42e06827948e
[root@stepserver ~]# cinder backuplist++++++++| ID | Volume ID | Status | Name | Size | Object Count | Container |++++++++| 3969164b0d214bd7bac842e06827948e | 083a9c97b1af46f0844a58fc90b88b35 | available | 20140726 20:36:36.118086 | 1 | 22 | backup |++++++++
52
データの復旧4
● 作成したボリュームに、バックアップからデータを復旧します。
● cinder backup-restore –volume-id <リストア先のボリューム > <リストア元のバックアップ >
[root@stepserver ~]# cinder backuprestore \volumeid ec4e42e6b08d4c518814042ddffad4e6 \3969164b0d214bd7bac842e06827948e
UUID で指定する必要があるため、指定を間違えないように気をつけてください。
53
データの復旧5
● リストアが完了するのを待ちます。● リストア中は「 restoring-backup 」になり、完了すると
「 available 」に戻ります。
[root@stepserver ~]# cinder list++++| ID | Status | Display Name |++++| 083a9c97b1af46f0844a58fc90b88b35 | inuse | None || ec4e42e6b08d4c518814042ddffad4e6 | restoringbackup | None |++++
[root@stepserver ~]# cinder list+++++| ID | Status | Display Name | Size | V+++++| 083a9c97b1af46f0844a58fc90b88b35 | inuse | None | 1 | | ec4e42e6b08d4c518814042ddffad4e6 | available | None | 1 | +++++
54
ボリュームの接続
● app-server1 へボリュームを接続します。[root@stepserver ~]# nova volumeattach \appserver1 ec4e42e6b08d4c518814042ddffad4e6 /dev/vdc ↑ ↑ ↑接続先インスタンス ボリューム UUID インスタンスに認識させるデバイス名
+++| Property | Value |+++| device | /dev/vdc || id | ec4e42e6b08d4c518814042ddffad4e6 || serverId | 5c38d93b3dcf44c39b4516cb8d25e1cd || volumeId | ec4e42e6b08d4c518814042ddffad4e6 |+++
55
サーバからの認識
● データがリストアされたボリュームなのでフォーマット等は不要なため、マウントすれば即利用できます。
[root@appserver1 ~]# service mysqld stop[root@appserver1 ~]# mount LABEL=data /var/lib/mysql[root@appserver1 ~]# service mysqld start
[root@appserver1 ~]# 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@appserver1 ~]# kill 28932
[root@appserver1 ~]# sh /root/openstacksampleapp/serversetup/rest.init.sh
56
データの確認
● ブラウザで app-server, app-server1 へアクセスし、同じデータになっていることを確認してください。
57
まとめ
これまでの作業をまとめます。● ボリュームサービスについて説明しました
● ボリューム: VM とは独立した仮想ディスク● 既存の VM の重要データをボリューム上に移す
方法を説明しました● ボリュームサービスのバックアップ機能を使った
重要データのバックアップ手法を説明しました● ボリュームバックアップからボリュームデータを
リストアする方法を説明しました。
58
ボリューム編 〜おつかれさまでした〜