1
2014/7/30 v1
Tomoaki Nakajima(@irix_jp)
openstackOpen source software to build public and private clouds.
ボリューム編
ボリュームサー...
2
前提環境
step
Instance
<userid>-router
Router
app-server1
Instance
Ext-Net
<userid>-network
10.0.0.0/24
app-server
Instance
...
3
目次
●
ボリュームサービス
●
ボリュームサービスの必要性
●
ボリュームの用途
●
ボリューム・スナップショット、他
●
ボリュームバックアップによる
データの自動バックアップ
●
バックアップパターン
●
VM 環境変更
●
バックア...
4
ボリュームサービス
5
課題
●
現在のサンプルアプリ環境は DB も含めて 1 インス
タンス内に存在しているため、インスタンス障害時
に、データが消失してしまう危険がある。
VM
6
OpenStack のディスク構成
●
OpenStack ではインスタンスの仮想ディスクが、イ
ンスタンスの起動する物理ホスト上のローカルディ
スクへ保存される (*1)
。このため物理ホスト障害等に
よるデータロストの危険が存在していま...
7
データの永続化方法
●
そのため、 OpenStack にはインスタンスからデー
タを切り離し、重要データを保存すための「ボリュー
ムサービス」が存在しています。
VM ホスト ストレージ
VM
VM
VM
VM
VM
VM
VM ホスト ...
8
ボリュームサービスとは
●
VM とは独立した VM 用仮想ストレージ(ボリュー
ム)を提供するクラウドサービス
●
OpenStack では Cinder が機能を担当
●
OpenStack Block Storage (Cinder)...
9
ボリュームの用途
ボリューム上に置くべきデータ
●
永続的で重要なデータ
●
外部から入手しづらい/不可能なデータ
●
レプリケーション(複製)に向かないデータ
例
●
データベースサーバ … DB ファイル
●
ファイルサーバ …共有ファ...
10
ボリュームの特徴
VM (インスタンス)用の外付け仮想ディスク
●
VM とは別管理
●
VM を削除してもボリュームは残る
●
任意の VM に接続できる
VM
VM
付
け
替
え
ボリューム
※ 複数の VM に同時接続できません。
11
ボリュームのスナップショット
ある時点のボリュームのバックアップ
●
1ボリュームから複数のスナップショットを作成できる
●
スナップショットから複数の別ボリュームを作成できる
●
VM には接続できない
スナップ
ショット
VM
ボリュ...
12
ボリュームのバックアップ・リストア
ボリュームを別ストレージシステム上にバックアップ
●
OpenStack Object Storage (Swift) 等にバックアップできる
VM ボリューム
バックアップ作
成
リストア
ボリューム...
13
ボリュームの複製
ボリュームをコピーした新しいボリューム
●
VM に接続できる
●
バックアップ手段として利用できる
VM
ボリューム
ボリューム
別ボリューム作
成
VM 接続可
14
ボリュームスナップショット、複製、
バックアップの違い
ボリューム
スナップショット、複製
ボリューム
バックアップ
データの保存先
通常はボリュームの
バックエンドストレージ
と同一
通常はボリュームの
バックエンドストレージ
とは別の...
15
バックエンド
ストレージ
( Swift 、 Ceph 等)
バックエンド
ストレージ
( Swift 、 Ceph 等)
ボリューム・ VM テンプレート間コピー
OpenStack Image Service (Glance) との連...
16
ボリュームからのゲスト OS 起動
●
Boot from Volume
●
予め VM テンプレートをコピーしたボリュームを用意
●
上記ボリュームを接続した状態の VM を作成・起動
バックエンド
ストレージ
( Swift 、 Ce...
17
HP Public Cloud
ボリュームサービスの対応機能
操作 可否
ボリューム作成・削除 ○
ボリューム⇒ボリュームスナップショット作成 *1
・削除 ○
ボリュームスナップショット⇒ボリューム作成 ○
ボリューム⇒ボリューム作成 ...
18
ボリュームバックアップによる
データの自動バックアップ
19
ボリューム利用 VM の方式比較
重要データのみ
ボリューム上に配置
全データを
ボリューム上に配置
VM の起動
ディスク
エフェメラルディスク ボリューム
メリット
● VM の OS をアップグレード・
ダウングレードしやすい
● ...
20
バックアップパターン①
全データをボリューム上に配置
バックエンドストレージバックエンドストレージ
VM
ボリューム
② ボリュームの
 バックアップを作成
③ 古いバックアップを削除
ボリューム
バックアップ
①VM を削除 ④VM を...
21
バックアップパターン②
重要データをボリューム上に配置
バックエンドストレージバックエンドストレージ
VM
ボリューム
④ ボリュームの
 バックアップを作成
⑤ 古いバックアップを削除
ボリューム
バックアップ
DB
①DB 等のアプリ...
22
どちらを使うべきか
バックアップパターン①が適しているケース
●
VM 上のアプリ環境構築が自動化できない場合
●
VM ホスト障害時の迅速な復旧が必要な場合
バックアップパターン②が適しているケース
●
VM 上のアプリ環境構築が自動化...
23
操作の概要
●
サンプルアプリが稼働するインスタンへボリューム
を接続し、 MySQL のデータファイルをボリューム上
へ移動します。
app-server
VOL
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 ­2
virtio­pci 0000:00:07.0: irq 32 for MSI/MSI­X
 vdc: unknown partition table
...
31
ボリューム上にファイルシステムを
構築・マウント
● Ext4ファイルシステム作成
# mkfs.ext4 ­L data /dev/vdc1
mke2fs 1.41.12 (17­May­2010)
Filesystem label=d...
32
ファイルシステム上に VM 上の重要
データをコピー
● MySQLサーバ停止
# service mysqld stop
Stopping mysqld:                                         ...
33
自動マウント設定
● テキストエディタで fstab  編集
# nano /etc/fstab
● fstabの例
#
# /etc/fstab
# Created by anaconda on Wed Jan 16 10:31:20 ...
34
ファイルシステムをマウント
● 現状確認
# df ­h
Filesystem            Size  Used Avail Use%  マウント位置
/dev/vda1             9.9G  1.1G  8.4G...
35
サービスの起動
● MySQLサーバ起動
# service mysqld start
Starting mysqld:                                           [  OK  ]
● サンプルア...
36
確認
●
サンプルアプリへアクセスして、データが保持され
ていることを確認してください。
37
バックアップの設定
●
次は接続したボリュームのバックアップを行っていき
ます。
app-server
VOL
DBF
SwiftSwift
VOL
VOL
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/rdo­release.rpm
Loaded plugi...
42
VM 上に OpenStack 認証情報作成
● 制御用 VM からデータベース VM にクレデンシャルファイルをコピー
# scp /root/openrc   root@〈固定IP〉: /root/
                 ...
43
自動バックアップスクリプト準備①
● ツールダウンロード・インストール
# git clone https://github.com/yosshy/openstack­sample­app.git backup
# backup/inst...
44
自動バックアップスクリプト準備②
● ファイルの先頭部分を編集
# nano /usr/local/bin/do_backup.sh
● 設定部分
   # OpenStack API  アクセス用クレデンシャルファイル(認証情報)のフル...
45
サービスの起動
● サンプルアプリの再起動
# ps ­ef |grep rest.py
root     28925     1  0 20:17 pts/0    00:00:01 python rest.py
root     28...
46
バックアップの確認
●
取得されたバックアップは、
「 Project 」→「 Compute 」→「 Volume 」の、
「 Volume Backup 」タブから確認できます。
47
定期バックアップ実行設定
●cron の日次実行(通常毎朝4時頃)で良ければ下記を実行
# ln ­s /usr/local/bin/do_backup.sh /etc/cron.daily/
48
データのリストア
●
最後にバックアップデータから、データの復旧を行
います。
●
今回は既に存在している、 app-server1 へ復旧し
たボリュームを接続します。
app-server
VOL
DBF
SwiftSwift
VOL...
49
データの復旧1
●
まず新規ボリュームを作成します。
[root@step­server ~]# cinder create ­­availability­zone az2 1
+­­­­­­­­­­­­­­­­­­­­­+­­­­­­­...
50
データの復旧2
●
ボリュームの確認
●
ここで表示される available 状態のボリューム UUID
をメモしておきます。
– 以下の場合は
●
ec4e42e6-b08d-4c51-8814-042ddffad4e6
[root@...
51
データの復旧3
●
バックアップデータの確認
●
ここで表示されるバックアップデータの UUID をメモして
おきます。
– 以下の場合は
●
3969164b-0d21-4bd7-bac8-42e06827948e
[root@step...
52
データの復旧4
●
作成したボリュームに、バックアップからデータを復
旧します。
●
cinder backup-restore –volume-id < リストア先のボリューム > < リストア元のバックアップ >
[root@step...
53
データの復旧 5
●
リストアが完了するのを待ちます。
●
リストア中は「 restoring-backup 」になり、完了すると
「 available 」に戻ります。
[root@step­server ~]# cinder list...
54
ボリュームの接続
●
app-server1 へボリュームを接続します。
[root@step­server ~]# nova volume­attach 
app­server1 ec4e42e6­b08d­4c51­8814­042d...
55
サーバからの認識
●
データがリストアされたボリュームなのでフォーマッ
ト等は不要なため、マウントすれば即利用できます。
[root@app­server1 ~]# service mysqld stop
[root@app­server...
56
データの確認
●
ブラウザで app-server, app-server1 へアクセス
し、同じデータになっていることを確認してください。
57
まとめ
これまでの作業をまとめます。
●
ボリュームサービスについて説明しました
●
ボリューム: VM とは独立した仮想ディスク
●
既存の VM の重要データをボリューム上に移す
方法を説明しました
●
ボリュームサービスのバックアッ...
58
ボリューム編 〜おつかれさまでした〜
Upcoming SlideShare
Loading in …5
×

H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編

1,839 views

Published on

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,839
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
89
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編

  1. 1. 1 2014/7/30 v1 Tomoaki Nakajima(@irix_jp) openstackOpen source software to build public and private clouds. ボリューム編 ボリュームサービスを活用した データのバックアップ
  2. 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. 3 目次 ● ボリュームサービス ● ボリュームサービスの必要性 ● ボリュームの用途 ● ボリューム・スナップショット、他 ● ボリュームバックアップによる データの自動バックアップ ● バックアップパターン ● VM 環境変更 ● バックアップの自動化 ● バックアップからのリストア
  4. 4. 4 ボリュームサービス
  5. 5. 5 課題 ● 現在のサンプルアプリ環境は DB も含めて 1 インス タンス内に存在しているため、インスタンス障害時 に、データが消失してしまう危険がある。 VM
  6. 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. 7 データの永続化方法 ● そのため、 OpenStack にはインスタンスからデー タを切り離し、重要データを保存すための「ボリュー ムサービス」が存在しています。 VM ホスト ストレージ VM VM VM VM VM VM VM ホスト ストレージ VM VM VM VM VM VM VM ホストが故障すると VM も使用不能 → サービス停止! ボリューム 重要データを入れた仮想ディス クを別ホスト上の VM で使用 →サービス継続
  8. 8. 8 ボリュームサービスとは ● VM とは独立した VM 用仮想ストレージ(ボリュー ム)を提供するクラウドサービス ● OpenStack では Cinder が機能を担当 ● OpenStack Block Storage (Cinder) – ボリュームのバックアップ・リストア – ボリュームから別ボリュームを作成 – Boot from Volume 機能をサポート ● AWS では Amazon Elastic Block Storage (EBS) に相 当する機能
  9. 9. 9 ボリュームの用途 ボリューム上に置くべきデータ ● 永続的で重要なデータ ● 外部から入手しづらい/不可能なデータ ● レプリケーション(複製)に向かないデータ 例 ● データベースサーバ … DB ファイル ● ファイルサーバ …共有ファイル ● バックアップサーバ …バックアップデータ
  10. 10. 10 ボリュームの特徴 VM (インスタンス)用の外付け仮想ディスク ● VM とは別管理 ● VM を削除してもボリュームは残る ● 任意の VM に接続できる VM VM 付 け 替 え ボリューム ※ 複数の VM に同時接続できません。
  11. 11. 11 ボリュームのスナップショット ある時点のボリュームのバックアップ ● 1ボリュームから複数のスナップショットを作成できる ● スナップショットから複数の別ボリュームを作成できる ● VM には接続できない スナップ ショット VM ボリューム スナップ ショット ボリューム スナップショット 作成 別ボリューム作成 VM 接続不可 ボリューム
  12. 12. 12 ボリュームのバックアップ・リストア ボリュームを別ストレージシステム上にバックアップ ● OpenStack Object Storage (Swift) 等にバックアップできる VM ボリューム バックアップ作 成 リストア ボリューム バックアップ ボリューム
  13. 13. 13 ボリュームの複製 ボリュームをコピーした新しいボリューム ● VM に接続できる ● バックアップ手段として利用できる VM ボリューム ボリューム 別ボリューム作 成 VM 接続可
  14. 14. 14 ボリュームスナップショット、複製、 バックアップの違い ボリューム スナップショット、複製 ボリューム バックアップ データの保存先 通常はボリュームの バックエンドストレージ と同一 通常はボリュームの バックエンドストレージ とは別のストレージ バックアップ・リストア 速度 一般的に早い (同じストレージ内の ため) 一般的に遅い (別ストレージに転送す るため) 元ボリュームへの リストア × ○ 新規ボリュームへの リストア ○ ○ 可用性 ボリュームバックエンド ストレージに依存 バックアップ用 ストレージに依存
  15. 15. 15 バックエンド ストレージ ( Swift 、 Ceph 等) バックエンド ストレージ ( Swift 、 Ceph 等) ボリューム・ VM テンプレート間コピー OpenStack Image Service (Glance) との連携 ● ボリュームデータから新しい VM テンプレートを作成 ● VM テンプレートから新しいボリュームを作成 VM ボリューム ボリュームから VM テンプレー ト作成 VM テンプレー ト イメージ ボリューム OpenStack Image Service (Glance) VM テンプレー ト からボリューム 作成
  16. 16. 16 ボリュームからのゲスト OS 起動 ● Boot from Volume ● 予め VM テンプレートをコピーしたボリュームを用意 ● 上記ボリュームを接続した状態の VM を作成・起動 バックエンド ストレージ ( Swift 、 Ceph 等) バックエンド ストレージ ( Swift 、 Ceph 等) VM VM テンプレー ト イメージ ボリューム OpenStack Image Service (Glance) VM テンプレー ト からボリューム 作成 ボリューム接続状態の VM 作成・起動
  17. 17. 17 HP Public Cloud ボリュームサービスの対応機能 操作 可否 ボリューム作成・削除 ○ ボリューム⇒ボリュームスナップショット作成 *1 ・削除 ○ ボリュームスナップショット⇒ボリューム作成 ○ ボリューム⇒ボリューム作成 ○ ボリュームバックアップ・リストア *1 ○ VM テンプレートイメージ⇒ボリューム作成 ○ ボリューム⇒ VM テンプレートイメージ作成 × ボリュームからの VM 起動 ○ *1) :予めボリュームをデタッチ状態にする必要あり
  18. 18. 18 ボリュームバックアップによる データの自動バックアップ
  19. 19. 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. 20. 20 バックアップパターン① 全データをボリューム上に配置 バックエンドストレージバックエンドストレージ VM ボリューム ② ボリュームの  バックアップを作成 ③ 古いバックアップを削除 ボリューム バックアップ ①VM を削除 ④VM を作成 VM ② 実施に ① 実施が 必要
  21. 21. 21 バックアップパターン② 重要データをボリューム上に配置 バックエンドストレージバックエンドストレージ VM ボリューム ④ ボリュームの  バックアップを作成 ⑤ 古いバックアップを削除 ボリューム バックアップ DB ①DB 等のアプリケーションを停止 ⑧DB 等のアプリケーションを起動 ② ボリューム上のファイルシステムをアンマウント ⑦ ボリューム上のファイルシステムをマウント ③ ボリュームをデタッチ(切断) ⑥ ボリュームをアタッチ(接続)
  22. 22. 22 どちらを使うべきか バックアップパターン①が適しているケース ● VM 上のアプリ環境構築が自動化できない場合 ● VM ホスト障害時の迅速な復旧が必要な場合 バックアップパターン②が適しているケース ● VM 上のアプリ環境構築が自動化できる場合 ● ボリュームのスナップショットやバックアップでデータを バックアップする場合 ● 定期的に OS やアプリケーションのアップグレードを行う 場合 今回はバックアップパターン②を採用します
  23. 23. 23 操作の概要 ● サンプルアプリが稼働するインスタンへボリューム を接続し、 MySQL のデータファイルをボリューム上 へ移動します。 app-server VOL DBF
  24. 24. 24 VM 環境変更 ● アプリケーション停止 ● 新規ボリューム作成 ● VM にボリュームをアタッチ ● ボリューム上にパーティション作成 ● パーティション上にファイルシステム構築・マウント ● ファイルシステム上に VM 上の重要データをコピー ● ファイルシステムのマウント場所を移動 ● 自動マウント設定 ● アプリケーション起動
  25. 25. 25 操作の前に ● サンプルアプリにデータを投入しておいてください。
  26. 26. 26 新規ボリューム作成① ② 「 Create Volume 」クリック ① 「 Volumes 」クリック
  27. 27. 27 新規ボリューム作成② ③ ボリューム名入力 ④ サイズ入力 (GB 単位 ) ⑥ 「 Create Volume 」クリック⑤ アベイラビリティゾーン指定 ( VM と同じゾーンを指定) data 1GB
  28. 28. 28 VM にボリュームをアタッチ① ① 「 More 」クリック ② 「 Edit Attachment 」クリック
  29. 29. 29 VM にボリュームをアタッチ② ③ アタッチする VM を選択 ④ 「 Attach Volume 」クリック app-server へ 接続します。
  30. 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. 31 ボリューム上にファイルシステムを 構築・マウント ● Ext4ファイルシステム作成 # 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. 32 ファイルシステム上に VM 上の重要 データをコピー ● MySQLサーバ停止 # service mysqld stop Stopping 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/data ib_logfile0  ib_logfile1  ibdata1  lost+found  mysql  test app-server
  33. 33. 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=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 ● 下記1行を追加 LABEL=data  /var/lib/mysql  ext4  defaults,noatime  0 0 app-server
  34. 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. 35 サービスの起動 ● MySQLサーバ起動 # 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. 36 確認 ● サンプルアプリへアクセスして、データが保持され ていることを確認してください。
  37. 37. 37 バックアップの設定 ● 次は接続したボリュームのバックアップを行っていき ます。 app-server VOL DBF SwiftSwift VOL VOL
  38. 38. 38 バックアップの設定 ● バックアップ先コンテナ作成 ● VM 上に Cinder クライアントをインストール ● VM 上に OpenStack 認証情報作成 ● 自動バックアップスクリプト準備 ● 定期バックアップ実行設定
  39. 39. 39 バックアップ先コンテナ作成① ③ 「 Create Container 」クリック ① 「 Object Store 」クリック ② 「 Containers 」クリック
  40. 40. 40 バックアップ先コンテナ作成② ⑤ 「 Create Container 」クリック ④ コンテナ名を入力
  41. 41. 41 VM に OpenStack のクライアントを インストール ● RPMリポジトリ情報設定 # 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! ● OpenStackクライアント群インストール # 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. 42 VM 上に OpenStack 認証情報作成 ● 制御用 VM からデータベース VM にクレデンシャルファイルをコピー # scp /root/openrc   root@〈固定IP〉: /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. 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. 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. 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. 46 バックアップの確認 ● 取得されたバックアップは、 「 Project 」→「 Compute 」→「 Volume 」の、 「 Volume Backup 」タブから確認できます。
  47. 47. 47 定期バックアップ実行設定 ●cron の日次実行(通常毎朝4時頃)で良ければ下記を実行 # ln ­s /usr/local/bin/do_backup.sh /etc/cron.daily/
  48. 48. 48 データのリストア ● 最後にバックアップデータから、データの復旧を行 います。 ● 今回は既に存在している、 app-server1 へ復旧し たボリュームを接続します。 app-server VOL DBF SwiftSwift VOL VOL app-server1 VOL DBF
  49. 49. 49 データの復旧1 ● まず新規ボリュームを作成します。 [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. 50 データの復旧2 ● ボリュームの確認 ● ここで表示される 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. 51 データの復旧3 ● バックアップデータの確認 ● ここで表示されるバックアップデータの 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. 52 データの復旧4 ● 作成したボリュームに、バックアップからデータを復 旧します。 ● 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. 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. 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. 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. 56 データの確認 ● ブラウザで app-server, app-server1 へアクセス し、同じデータになっていることを確認してください。
  57. 57. 57 まとめ これまでの作業をまとめます。 ● ボリュームサービスについて説明しました ● ボリューム: VM とは独立した仮想ディスク ● 既存の VM の重要データをボリューム上に移す 方法を説明しました ● ボリュームサービスのバックアップ機能を使った 重要データのバックアップ手法を説明しました ● ボリュームバックアップからボリュームデータを リストアする方法を説明しました。
  58. 58. 58 ボリューム編 〜おつかれさまでした〜

×