Microsoft Word - qtsi_120246jp_rhev.doc

Transcription

1 Article ID: QTSI JP Created: 2012/02/27 Revised: - Red Hat Enterprise Virtualization(RHEV) 3.0 環境での NetVault Backup を使用した各ノードのシステム保護 1. 概要 Red Hat Enterprise Virtualization(RHEV) は レッドハット社が提供する仮想化環境管理ソリューションです RHEV を構成する要素として Red Hat Enterprise Virtualization Manager(RHEV-M) とハイパーバイザー (KVM) が稼働するホストから成ります ハイパーバイザーとしては 専用の OS である Red Hat Enterprise Virtualization Hypervisor(RHEV-H) または Red Hat Enterprise Linux(RHEL) 上で KVM を稼働させる構成のいずれかを選択可能です これらの個々のノードに障害が発生した場合に備えて 復旧方法を確認しておくことはシステム運用上 大切なことです 本検証では RHEL 上で KVM を稼働させた構成を採用した IBM 社の Linux KVM 仮想化太鼓判構成において 各ノードの障害を想定した NVBU を使用したバックアップ / リストアの動作検証をいたします 2. 環境 Page(s): 1/11

2 NVBU Server ハードウェア Host IBM System x3620 M3 (737662J) CPU Intel Xeon X GHz x 2 Memory 18832MB SCSI Disk 500GB SATA x 2 Disk0: 1TB (RAID0) ServeRAID-M5015( ) NIC Intel 82575EB Gigabit NIC x 2 Tape or VTL 仮想テープドライブ (200GB) ソフトウェア NetVault Core Ver (R2011OCT12-JUNO) NetVault APM Ver VaultDR APM RHEV-M ハードウェア Host IBM System x3250 M4 (2583PAB) CPU Intel Xeon E GH x 1 Memory 4GB Disk 構成 300GB SAS Disk x 2 Disk0:300GB (RAID1) NIC(Firmware Ver) Intel 82574L Gigabit NIC x 2 SCSI(Firmware Ver) ServeRAID-BR10il v2 FC HBA Qlogic FC HBA x 2 ソフトウェア VaultOS Ver パーティション構成 /dev/sda1 /boot ext4 256MB /dev/sda2 / ext4 15GB /dev/sda3 Swap 1GB /dev/sda4 Extended /dev/sda5 /home ext4 1GB KVM ノード 1 ハードウェア Host IBM System x3690 X5 (7147A7J) CPU Intel Xeon E GH x 2 Memory 32GB Disk 構成 146GB SAS Disk x 2 Disk0:146GB (RAID1) NIC(Firmware Ver) Broadcom5709 x 2 SCSI(Firmware Ver) ServeRAID-M5015( ) FC HBA Qlogic FC HBA x 2 ソフトウェア VaultOS Ver パーティション構成 /dev/sda1 /boot ext4 256MB /dev/sda2 / ext4 8GB /dev/sda3 Swap 1GB /dev/sda4 Extended /dev/sda5 /home ext4 1GB Page(s): 2/11

3 KVM ノード 2 ハードウェア Host IBM System x3690 X5(7147A7J) CPU Intel Xeon E GH x 2 Memory 32GB Disk 構成 146GB SAS Disk x 2 Disk0:146GB (RAID1) NIC(Firmware Ver) Broadcom5709 x 2 SCSI(Firmware Ver) ServeRAID-M5015( ) FC HBA Qlogic FC HBA x 2 ソフトウェア VaultOS Ver パーティション構成 /dev/sda1 /boot ext4 256MB /dev/sda2 / ext4 8GB /dev/sda3 Swap 1GB /dev/sda4 Extended /dev/sda5 /home ext4 1GB ストレージ FC スイッチ Vendor Brocade model 300 FC Storage Vendor IBM Model Storwize V7000 Disk 600GB SAS x 12, 300GB SAS x 9, 300GB SSD SAS x 3 仮想マシン環境 仮想マシン 1 仮想マシン 2 3. 検証項目 手順 3.1. 各ノードのシステム バックアップ RHEV3.0 環境を構築後 全てのノードの OS 部分のオフライン システム バックアップを BMR Offline で取得します この時 RHEV マネージャで確認すると仮想マシンは 1 台のみが構成されている状態です Page(s): 3/11

4 RHEV-M のシステム バックアップ FC ストレージと接続している FC ケーブルを抜いて 内蔵ディスクにインストールされた OS のバックアップを行います FC ケーブルを抜くことによって OS が存在する内蔵ディスクだけがバックアップ画面に表示され そこを確実に取得することが可能になります 対象マシンを VaultOS で起動し NVBU サーバ側で NVBU Console からバックアップ操作を行います 下記は バックアップ画面で RHEV-M マシンの内蔵ディスクをバックアップ対象として選択した画面です KVM ノードのシステム バックアップ FC ストレージに接続している FC ケーブルを抜いて 内蔵ディスクにインストールされた OS のバックアップを行います 両ノードとも同じように取得します 下記は バックアップ画面で KVM ノード 1 マシンの内蔵ディスクをバックアップ対象として選択した画面です Page(s): 4/11

5 疑似運用各ノードのシステム バックアップを取得したら 各ノードを起動し 運用を行います 本検証では 運用中の操作として 仮想マシン ( RHEL62ADDED ) を追加します RHEV マネージャで確認すると 追加された仮想マシンが確認できます RHEV-M の PostgreSQL DB のバックアップ RHEV の構成情報は RHEV-M 上の PostgreSQL DB で管理されています RHEV の構成に変更を行った際は 下記のコマンドで PostgreSQL DB のバックアップを行います バックアップした結果は ファイルとして保存されます ( ここでは /usr/share/rhevm/db-backups 以下に dump_rhevm_ sql というファイル名で保存されています ) # pg_dump -C -E UTF8 --column-inserts --disable-dollar-quoting --disabletriggers U postgres --format=p -f /usr/share/rhevm/db-backups/dump_rhevm_ sql rhevm バックアップの詳細に関しては RHEV3.0 管理ガイド 15.1 rhevm Postgres データベースのバックアップとリストア に記載があります 合わせてのご参照をお勧めいたします ( Page(s): 5/11

6 PostgreSQL DB バックアップ ファイルのテープへのバックアップ上記コマンドで生成されるファイルを NVBU のファイルシステム プラグインでテープにとっておけばより安全です 取得しておくことをお勧めいたします 下記は NVBU のバックアップ画面でファイルシステム プラグインで対象のファイルを選択した画面です RHEV-M の構成情報のバックアップその他 RHEV-M の構成情報として取得すべきファイルの一覧が RHEV 管理ガイド 15.2 Manager 設定ファイルのバックアップとリストア に記載があります こちらも NVBU のファイルシステム プラグインで取得しておくことをお勧めいたします 本検証では ここのファイル群の変更は無いため この部分の検証は対象外としています 実際の環境では 必要に応じてファイルのリストアを実施して下さい 3.2. リストア RHEV-M のノード障害 RHEV-M のノード障害を想定します RHEV-M マシンをシャットダウンし ハードディスクを別の物に変更して 手順 で取得済みのバックアップをリストアします リストアの際にはバックアップ時と同様に FC ケーブルを抜きます ノードを VaultOS で起動し 取得済みのバックアップをリストアします 下記は NVBU のリストア画面で取得済みの RHEV-M マシンのバックアップ データをリストア対象として選択した画面です Page(s): 6/11

7 リストアが完了したら FC ケーブルを接続し OS 再起動します この時の管理情報は仮想マシンが一台しかないときの DB なので RHEV マネージャで確認すると仮想マシンとしては初期の 1 台のみしか表示されません そのため 手順 で取得した最新の PostgreSQL DB のリストアを行います NVBU のファイルシステム プラグインで取得していた場合は まず ファイルとしてリストアを行います さらに RHEV-M マシン上でリストアしたファイルを利用して下記の操作を行います 詳細は すでに紹介した RHEV3.0 管理ガイドをご参照ください # service jbossas stop Stopping jbossas: [ OK ] # su postgres -bash-4.1$ psql Password: xxxxx Psql (8.4.9) Type help for help. postgres=# DROP DATABASE rhevm; DROP DATABASE Postgres=# \q -bash-4.1$ exit logout # psql -U postgres < /usr/share/rhevm/db-backups/dump_db_ sql SET SET SET ALTER TABLE REVOKE REVOKE GRANT GRANT# # service jbossas start Starting jbossas: [ OK ] # Page(s): 7/11

8 RHEV マネージャを起動して 2 台の仮想マシンが表示されていることを確認します RHEV ノードの障害対応次に KVM ノードが 1 台障害を起こしたことを想定します KVM ノード 1(RHEV1) をシャットダウンします RHEV マネージャ上でノードが 1 台ダウンしていることを確認します Page(s): 8/11

9 RHEV の HA 機能が構成され 仮想マシンごとの設定において HA 対象となっていれば 仮想マシンは別の KVM ノード (RHEV2) 上で自動的に起動し直します RHEV マネージャで仮想マシンが稼働しているホストを確認すると RHEV2 であることが確認出来ます ハードウェアの修復作業時には KVM ノード 1(RHEV1) のハードディスクを入れ替えて VaultOS で起動します その際 バックアップ時と同様に FC ケーブルは抜いておきます 手順 で取得済みのバックアップをリストアします Page(s): 9/11

10 リストア処理が完了したら FC ケーブルを接続し 内蔵ディスクから OS を起動します RHEV マネージャを使用して 復旧したノード (RHEV1) へ仮想マシンを Live Migration で移行できることを確認します また 復旧したノード (RHEV1) 上で仮想マシンのシャットダウンや起動ができることを確認します Page(s): 10/11

11 3.3. 仮想マシンのシステム保護個々の仮想マシンのバックアップは RHEV マネージャを利用して 仮想マシンのイメージを EXPORT することで実現可能です EXPORT した結果は ファイルシステム上にファイルとして存在します 3.4. 仮想マシンのデータ保護 NVBU は RHEL6.x 上の KVM の仮想マシンに NVBU サーバや NVBU クライアントを構成することをサポートしています よって KVM 上の仮想マシンを通常の物理マシンと同様にデータ保護を行うことも可能です 4. まとめ 本検証では RHEV3.0 環境における以下のバックアップ / リストアを確認しました RHEV-M 環境のシステムのバックアップ / リストア 及び KVM 構成上を含んだ PostgreSQL DB のバックアップ リストア KVM ノードのシステムのバックアップ / リストア NVBU を使用すれば KVM 環境における様々なデータ保護要求に対する解決策が得られます お客様の環境に応じて適切なデータ保護ソリューションを組み合わせてご使用ください なお 本検証の結果は特定環境での動作を確認しました お客様の環境で想定通りのご運用が可能かは 事前検証にてご確認下さい 以上 Page(s): 11/11