ユーザーズガイド

(1)

J2X1-8070-01Z0(01)

2016

年

9 月

Linux

FUJITSU Software

ServerView Resource Orchestrator

Standard powered by K5 V3.3.0

(2)

まえがき

本書の目的

本書は、FUJITSU Software ServerView Resource Orchestrator Standard powered by K5 (以降、本製品)の運用、操作について説明しています。

本書の読者

本書は、本製品を運用する管理者を対象にしています。また、システムを運用するにあたっては、以下を前提としています。

・

LinuxとOpenStackに対する一般的な知識があること

・

運用するサーバやストレージ、ネットワーク機器の一般的な知識があること

本書の構成

本書は、以下の構成になっています。第1章概要本製品の概要について説明します。第2章運用本製品利用時の運用について説明します。第3章操作 Horizonの起動と終了、およびHorizonに対する本製品の追加機能について説明します。第4章保守本製品利用時の保守について説明します。第5章本製品利用時の留意点本製品利用時の留意事項について説明します。付録A サービス一覧本製品のサービスについて説明します。付録B HTTPS通信本製品で使用するHTTPS通信のセキュリティについて説明します。付録C Cinderの設定 Cinderのバックアップ、およびスナップショットを利用する場合の領域の設定について説明します。

参照先URLについて

本文中に記載されている参照先URLは、2016年9月時点の情報です。

マニュアル体系と読み方

本製品のマニュアルには、以下のものがあります。必要に応じて、それぞれのマニュアルを読んでください。

(3)

マニュアル名称マニュアル略称目的・用途

FUJITSU Software ServerView Resource Orchestrator Standard powered by K5 V3.3.0

ユーザーズガイド

ユーザーズガイド製品の利用方法を知りたい場合にお読みくださ

い。

FUJITSU Software ServerView Resource Orchestrator Standard powered by K5 V3.3.0 リ

ファレンスガイド (API編) リファレンスガイド (API編) 本製品がサポートするAPIを知りたい場合にお読みください。

本書の表記について

本書中の表記方法は以下のとおりです。

・

参照先は「」でくくります。

・

GUIは[ ]でくくります。

・

メニューの選択順を[ ]-[ ]の形式で示します。

・

ユーザーが入力する文字は太字で示します。

・

可変部分は斜体で示します。

・

特に強調が必要な文字列、数値をダブルクォーテーション( " )でくくります。

・

メニュー名には、設定、操作画面の起動を示す"..."は表記しません。

・

使用例は、プロンプトをLinuxの"#"で表記しています。

・

HA構成の場合、【HA構成】として記述します。

FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Webサイト

FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Webサイトでは、最新のマニュアルを公開しています。

本製品を利用する前に、FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Webサイトを参照してください。

URL: http://www.fujitsu.com/jp/products/computing/integrated-systems/primeflex-cloud/products/k5/

略称

本書中の略称は以下のとおりです。(注) 製品略称 CentOS 6.6 CentOS 7.1 CentOS

Red Hat(R) Enterprise Linux(R) 6.

n

(for Intel64) Red Hat Enterprise Linux 6、また

は RHEL6.

n

Red Hat Enterprise Linux、また

は Linux

n

(for Intel64) Red Hat Enterprise Linux 7、また

は RHEL7.

n

(for Intel64) 仮想化機

能

RHEL-KVM

Red Hat(R) Enterprise Linux(R) OpenStack(R) Platform RHOSP Windows(R) 7 Professional

Windows(R) 7 Ultimate

(4)

製品略称

Windows(R) 8.

n

Pro Windows(R) 8.

n

Enterprise

Windows(R) Internet Explorer(R) 10 Internet Explorer(R) 11

Internet Explorer

Firefox(R) Firefox

FUJITSU Storage ETERNUS SF Storage Cruiser ETERNUS SF/SC FUJITSU Software ServerView Resource Orchestrator

Standard powered by K5 ROR-K5 注: "

n

"には、マイナーリリースを示す数字が入ります。

輸出管理規制について

本ドキュメントを輸出または第三者へ提供する場合は、お客様が居住する国および米国輸出管理関連法規等の規制をご確認のうえ、必要な手続きをおとりください。

商標について

・

Linux(R) は、Linus Torvalds氏の日本およびその他の国における登録商標または商標です。

・

CentOS の名称およびそのロゴは、CentOS ltdの商標または登録商標です。

・

Microsoft、Windows、およびInternet Explorer は、米国Microsoft Corporationの米国およびその他の国における登録商標または

商標です。

・

Firefoxは、米国Mozilla Foundationの米国およびその他の国における商標または登録商標です。

・

Red Hat は、米国およびその他の国において登録されたRed Hat, Inc. の商標です。

・

OpenStack(R)のワードマークと OpenStack のロゴは、米国とその他の国における OpenStack Foundation の登録商標/サービスマー

クまたは商標/サービスマークのどちらかであり、OpenStack Foundation の許諾の下に使用されています。富士通株式会社は、

OpenStack Foundation とOpenStack コミュニティの公認や出資を受けていません。

・

ServerViewは、富士通株式会社の登録商標です。

・

その他の会社名および製品名は、それぞれの会社の商標または登録商標です。

お願い

・

本書を無断でほかに転載しないようお願いします。

・

本書は予告なしに変更されることがあります。

出版年月および版数

版数マニュアルコード 2016年9月第1版 J2X1-8070-01Z0(00) 2016年9月第1版 J2X1-8070-01Z0(01)

著作権表示

(5)

目　次

第1章概要... 1

1.1 FUJITSU Software ServerView Resource Orchestrator Standard powered by K5とは... 1

1.2 システム構成... 1 1.3 基本スペック... 4 1.4 本製品の特長...5 1.4.1 スケーラビリティの確保...5 1.4.2 リソースの有効活用... 5 1.4.3 システム構築パターンの統一... 6 1.4.4 仮想マシンのリソース使用状況把握... 7 1.4.5 冗長性の確保...7 1.5 提供機能一覧... 9 1.6 本製品の使用者が利用できる主な操作... 10 第2章運用... 13 2.1 本製品の起動と停止...13 2.1.1 ハードウェアの起動順序... 13 2.1.2 ハードウェアの停止順序... 13 2.1.3 業務サーバ(コンピュートノード)の起動、停止【HA構成】...14 2.1.3.1 すべての業務サーバ(コンピュートノード)の起動...14 2.1.3.2 すべての業務サーバ(コンピュートノード)の停止...16 2.1.4 サービスの起動、停止、確認...17 2.1.4.1 サービスの起動... 17 2.1.4.2 サービスの停止... 18 2.1.4.3 サービスの状態確認... 19 2.2 バックアップ・リストア...20 2.2.1 資源... 20 2.2.2 バックアップ・リストアの共通手順... 21 2.2.3 バックアップ... 25 2.2.4 リストア...29 2.3 コマンドリファレンス... 36 2.3.1 rcx_all_instance_ctl.sh...36 2.3.2 cssnap...39 2.3.3 rcx_service... 41 2.3.4 ceilometer...43 第3章操作... 47 3.1 ログイン、ログアウト...47 3.2 Horizonの追加機能...49 3.3 管理ソフトウェアの一覧表示... 49 3.4 管理ソフトウェアの登録... 50 3.5 管理ソフトウェアの編集... 51 3.6 管理ソフトウェアの削除... 51 第4章保守... 53 4.1 定期保守... 53 4.1.1 クラスタ構成における業務サーバ(コンピュートノード)の定期保守【HA構成】... 53 4.1.2 業務サーバ(コンピュートノード)の切離し... 54 4.1.2.1 メンテナンスノードが稼動ノードの場合の切離し... 54 4.1.2.2 メンテナンスノードが待機ノードの場合の切離し... 57 4.1.3 業務サーバ(コンピュートノード)の組込み... 58 4.1.3.1 メンテナンスノードが稼動ノードの場合の組込み... 59 4.1.3.2 メンテナンスノードが待機ノードの場合の組込み... 61 4.2 トラブル発生時の対処...63 4.2.1 トラブル発生時の対処の流れ...63 4.2.2 管理サーバ(ネットワークノード)の復旧... 64

(6)

4.2.3 クラスタ構成の業務サーバ(コンピュートノード)の切替え発生時の対処【HA構成】...70 4.2.3.1 インスタンスの移動の確認... 71 4.2.4 クラスタ構成の業務サーバ(コンピュートノード)の復旧【HA構成】... 72 4.2.4.1 PRIMECLUSTERの状態確認...75 4.2.4.2 ストレージの復旧... 76 4.2.4.2.1 業務サーバ(コンピュートノード)上での作業... 76 4.2.4.2.2 ETERNUS上の作業...77 4.2.4.3 OS再起動による業務サーバ(コンピュートノード)の復旧... 78 4.3 トラブルシューティング... 81 4.3.1 管理サーバ(コントローラーVM1とコントローラーVM2)のトラブルシューティング... 81 4.3.1.1 レスポンスで"ERROR:/etc/opt/FJSVrorcpf/availability_zone/nova:read failed"が返却される場合...81

4.3.1.2 インスタンスにポートを追加するNova APIのレスポンスで"ERROR:communication error"が返却される場合... 81

4.3.1.3 Nova APIでインスタンスからポートを削除したが、正しく削除されない場合... 81 4.3.1.4 ライブマイグレーションが失敗した場合...81 4.3.1.5 インスタンスの作成/削除中に、管理サーバ(コントローラーVM2)のサービスが停止し、インスタンスのStatusが"ERROR" になった場合...81 4.3.1.6 インスタンスの起動/停止処理実行後、インスタンスのTask Stateが"powering-on"または"powering-off"のままになった場合... 82 4.3.1.7 ceilometerコマンド、APIが正常に動作しなくなった場合...82 4.3.2 業務サーバ(コンピュートノード)のトラブルシューティング... 82 4.3.2.1 本製品で配備したインスタンスが自動起動しない場合... 82 4.3.2.2 業務サーバ(コンピュートノード)再起動後に、本製品で配備したインスタンスのtask_state値が"deleting"になる場合... 83 4.3.2.3 libvirt-guestsが自動起動に失敗する場合...83 4.3.2.4 業務サーバ(コンピュートノード)切替え後、または切替え中に、インスタンスに対するリクエストがエラーとなる場合【HA 構成】... 83 4.3.2.5 システムログにmultipathdのエラーが出力された場合...83 4.3.2.6 システムログにlibvirtのエラーが出力された場合... 84 4.3.2.7 インスタンスに対してボリュームのアタッチ処理実行後、インスタンスにボリュームがアタッチされない場合...84 4.3.2.8 インスタンス起動時にボリューム作成が失敗した場合...84 4.3.3 ダッシュボード(Horizon)のトラブルシューティング...84 4.3.3.1 ダッシュボード(Horizon)の[管理]タブにおいて、[リソース使用状況] -[統計情報]をクリックした際にエラーが発生する場合84 4.3.3.2 ダッシュボード(Horizon)の[プロジェクト]タブにおいて、[コンピュート]-[概要]-[利用可能リソース概要]の情報が実際の利用状況と一致しない場合...86 4.3.3.3 利用可能リソース概要に表示されているリソース数が、プロジェクトごとのクォータ上限に到達している場合... 86 4.3.4 管理サーバ(Cinderノード)のトラブルシューティング...86 4.3.4.1 システムログにmultipathdのエラーが出力された場合...86 4.4 メッセージ... 87 4.4.1 インスタンス一括起動・停止時のメッセージ... 87 4.4.2 サービス一括起動・停止時のメッセージ... 92 4.4.3 リソース使用状況取得時のメッセージ... 93 4.4.4 管理ソフトウェア運用時のメッセージ... 94 4.4.5 業務サーバ(コンピュートノード)のフェイルオーバでエラーが発生した場合のメッセージ【HA構成】... 95 第5章本製品利用時の留意点... 100 付録A サービス一覧... 104 付録B HTTPS通信... 106 付録C Cinderの設定... 110 C.1 Cinder バックアップ用のNFS設定...110 C.2 Cinderスナップショットの設定... 111 用語集...113

(7)

第

1 章

概要

本章では、本製品の概要について説明します。

1.1 FUJITSU Software ServerView Resource Orchestrator

Standard powered by K5

とは

本製品は、オープン技術を採用したプライベートクラウド基盤ソフトウェアです。

FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Standardに同梱されるソフトウェアです。

リソースをリソースプールで共有管理し、要求に応じたプラットフォームの自動配備を実現します。プラットフォームの自動配備により、システム構築期間の短縮と運用の効率化を実現します。

1.2 システム構成

ここでは、本製品のシステム構成例、および本製品の使用者の役割について説明します。

システム構成例

FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Standardのシステム構成例は、以下のとおりです。

図

1.1 システム構成例

(8)

管理サーバ(コントローラーVM) コントローラーノードのインスタンスが動作するVMのことです。管理サーバ(コントローラーVM1) 以下のコンポーネントが動作します。

-

RabbitMQ

-

HAProxy

-

リージョンマネージャー

-

MariaDB 管理サーバ(コントローラーVM2) 以下のコンポーネントが動作します。

-

Nova

-

Heat

-

Glance

-

Swift

-

Neutron

-

Ceilometer

-

Horizon

-

Keystone 管理サーバ(コントローラーVM3) ネットワークノードの冗長化を管理するためのVMのことです。

ポイント

複数のコントローラーVMを指す場合には、以下のように区別して記述します。

－

管理サーバ(コントローラーVM1)と管理サーバ(コントローラーVM2)を指す場合管理サーバ(コントローラーVM1とコントローラーVM2)

－

すべてのコントローラーVMを指す場合管理サーバ(すべてのコントローラーVM) 管理サーバ(コントローラーノード) コントローラーノードのインスタンスが動作するホストのことです。管理サーバ(Cinderノード) Cinderが動作するサーバのことです。管理サーバ(ネットワークノード) ネットワークノードのインスタンスが動作するサーバのことです。業務サーバ(利用者VM) インスタンスのことです。業務サーバ(コンピュートノード) コンピュートノードのインスタンスが動作するホストのことです。

(9)

業務予備サーバ(コンピュートノード) 【HA構成】業務サーバ(コンピュートノード)がハードウェアの故障などでダウンした場合、切替えて運用を継続するためのホストです。共有ストレージリソースを格納するためのFC-SANストレージアグリゲーションスイッチ業務LAN、制御LAN、マイグレーション用LAN、ストレージLAN、サービスLANを接続するスイッチハード管理LANスイッチハードウェア機器の管理LANを接続するスイッチ FCスイッチ共有ストレージをFC-SAN接続するためのスイッチ FC-SANは、冗長構成になっています。業務LAN 業務で使用するLAN 業務LANは、冗長構成になっています。ハード管理LAN ハードウェアを管理するためのLAN 制御LAN OpenStackコンポーネント間の内部通信やリソースを管理するためのLAN 制御LANは、冗長構成になっています。マイグレーション用LAN マイグレーションで使用するLAN マイグレーション用LANは、冗長構成になっています。サービスLAN API、およびHorizonのアクセスで使用するLAN サービスLANは、冗長構成になっています。外部LAN 利用者が外部ネットワークに接続するためのLAN

使用者の役割

本製品の使用者の役割は、以下のとおりです。管理者仮想マシンのライフサイクル管理や、プライベートイメージ、パブリックイメージの管理などを行います。利用者仮想マシンの作成やライフサイクル管理、プライベートイメージの管理などを行います。

(10)

図

1.2 使用者の役割

1.3 基本スペック

ここでは、本製品の基本スペックについて説明します。本製品の基本スペックは、以下のとおりです。

基本ソフトウェア

基本ソフトウェアは、以下のとおりです。

表

1.1 基本ソフトウェア

(

注

)

対象サーバ基本ソフトウェア名(OS) 管理サーバ(コントローラーVM1) CentOS 6.6 管理サーバ(コントローラーVM2) CentOS 7.1 管理サーバ(コントローラーVM3) CentOS 6.6 管理サーバ(コントローラーノード) CentOS 7.1 (KVM) 管理サーバ(Cinderノード) CentOS 7.1 管理サーバ(ネットワークノード) CentOS 7.1

業務サーバ(コンピュートノード) Red Hat(R) Enterprise Linux(R) OpenStack Platform 7.2

注) SELinuxは有効です。

注意

(11)

管理クライアントのソフトウェア

管理クライアントには、以下のソフトウェアが必要です。

表

1.2 管理クライアントの必須ソフトウェア

必須ソフトウェア名バージョン備考 Internet Explorer 10 (注1) 11 (注1、注2)

Horizonを表示する場合、Internet Explorer 、またはFirefoxのどち

らかが必要です。 Firefox ESR31 ESR38 注1: デスクトップ版 Internet Explorer だけサポートします。注2: Webブラウザの画面の解像度は100%にしてください。 Webブラウザの設定における注意事項 Webブラウザのセキュリティの設定で、JavaScriptおよびCookieを使用しない設定にしている場合、Horizonが正しく表示できない場合があります。 WebブラウザがInternet Explorer の場合は以下の確認も実施してください。

－

HorizonのURLを"信頼済みサイト"に追加してください。

1.4 本製品の特長

ここでは、本製品の特長について説明します。

1.4.1 スケーラビリティの確保

スタックのテンプレート作成時に仮想マシン数を指定するだけで、負荷の上昇・低下に合わせて、仮想マシンを自動で追加、削除できます。スケジュールを指定して、負荷上昇が予測される時期に仮想マシン数を増減できます。

図

1.3 スケーラビリティの確保

1.4.2 リソースの有効活用

仮想マシンのスペック(CPU、メモリ、ストレージ容量)を定義し型決めできます。仮想マシン起動(作成)時に、複数仮想マシン(インスタンス)を指定できます。不要になった場合、仮想マシンを削除できるため、リソースを有効活用できます。

(12)

仮想マシンに対して、GUIから以下の操作ができます。

・

起動

・

停止

・

再起動

・

スナップショットの操作

・

コンソールの操作

図

1.4 仮想マシンの作成、削除、操作

1.4.3 システム構築パターンの統一

システム構築パターンを"Heatテンプレート"で作成し、複数サーバを一括で配備できます。ひな形のテンプレートを複製し、類似システムのテンプレートを作成できます。

図

1.5 Heat

テンプレートによる複数サーバの一括配備

(13)

注: 仮想ロードバランサを除くテンプレート作成/配備が可能

1.4.4 仮想マシンのリソース使用状況把握

すべての仮想マシンの仮想 CPU 数、ディスク、メモリ、起動時間を月次でCSV形式で保存できるため、仮想マシンのリソース使用状況を見える化できます。スケーラビリティ確保の基礎データとして使用できます。

図

1.6 仮想マシンのリソース使用状況の見える化

1.4.5 冗長性の確保

管理サーバ(ネットワークノード)の冗長化

管理サーバ(ネットワークノード)を冗長化しています。一方のサーバで異常が検知された場合、異常が検知されたサーバの電源を停止し、サーバ上の資源（ネットワーク、仮想ルータ、ロードバランサ）をもう一方のサーバに自動的に移動させます。異常の検知は管理サーバ(コントローラーVM2)で行われます。異常を検知する機構は管理サーバ(コントローラーVM2)の起動時に自動で起動されます。

(14)

図

1.7 管理サーバ

(

ネットワークノード

)

の冗長化

業務サーバ(利用者VM)の可用性向上【HA構成】

業務サーバ(コンピュートノード)に異常が発生した場合、そのうえで起動している業務サーバ(利用者VM)を自動的に別の業務サーバ (コンピュートノード)に移動させます。クラスタ内の業務サーバ(コンピュートノード)に異常が発生した場合、代表ノードが管理サーバ(コントローラーVM2)に以下の要求を行います。

・

異常が発生した業務サーバ(コンピュートノード)上の業務サーバ(利用者VM)を待機ノードに移動します。

・

異常が発生した業務サーバ(コンピュートノード)のOpenStackサービスを無効(disabled)に変更します。

図

1.8 業務サーバ

(

利用者

VM)

の可用性向上

(15)

稼動ノードクラスタ構成の中で、インスタンスが動作する業務サーバ(コンピュートノード)のことです。待機ノード業務予備サーバ(コンピュートノード)のことです。稼動ノードに異常が発生した際、異常が発生した業務サーバ(コンピュートノード)上のインスタンスが待機ノードに移動されます。代表ノードクラスタ内で1ノードだけ選出される業務サーバ(コンピュートノード)のことです。

1.5 提供機能一覧

ここでは、本製品の提供機能について説明します。本製品の提供機能は以下のとおりです。 OpenStackの機能の詳細は、OpenStackのWebサイトを参照してください。

表

1.3 提供機能一覧

コンポーネント概要機能提供元 OpenStack 本製品他OSS コンピュート(Nova) 仮想マシンの生成・管理をサポートします。〇 - -ブロックストレージ (Cinder) ブロックストレージボリュームの生成・管理をサポートします。〇 - -オブジェクトストレージ (Swift) オブジェクトの格納・取得を管理するサービスを提供します。〇 - -ネットワーク(Neutron) 仮想マシンに対するIP割り振りやネットワーク接続のサービスを提供します。また、ロードバランサ(LBaaS)、ファイアーウォール(FWaaS)を提供します。〇 - -アイデンティティー (Keystone) ID管理、認証機能を提供します。〇 - -イメージ(Glance) 仮想マシンイメージの管理(イメージメタデータの設定・更新を含む)、仮想イメージデータの取得ができます。〇 - -オーケストレーション (Heat) テンプレートを使用して、複数リソースを組み合わせたシステムの配備・編集ができます。また、AutoScalingGroupリソースとオートスケールスケジュール機能を組み合わせて、動的なインスタンスの増減を実現できます。〇 - -テレメトリ(Ceilometer) OpenStack用のメータリング機能を提供します。〇 - -ダッシュボード(Horizon) 上記コンポーネントのWebUIを提供します。また、管理者のWebUIを提供します。〇〇 -リージョンマネージャー以下の機能を提供します。

・

物理サーバ管理(Baremetal)を含むAPIの振り分け

・

オートスケールのスケジュール機能 - 〇 -HAProxy 冗長構成時に、リクエストの振り分けを行います。 - - 〇

(16)

コンポーネント概要機能提供元

OpenStack 本製品他OSS

また、LBaaSのエンジンとして機能します。

RabbitMQ OpenStack内部でのキュー管理サービスです。 - - 〇 MariaDB 本製品のデータベースとしてMariaDBを使用します。 - - 〇

OpenStack CLI OpenStack標準のコマンドラインインターフェースを提供しま

す。〇 -

-1.6

本製品の使用者が利用できる主な操作

ここでは、本製品の使用者が利用できる主な操作の概要について説明します。本製品の使用者が利用できる主な操作は、以下のとおりです。操作の詳細は、OpenStackのWebサイトを参照してください。

表

1.4 本製品の使用者が利用できる主な操作

コンポーネント利用者の操作管理者の操作コンピュート(Nova)

・

仮想マシンの生成

・

仮想マシンのライフサイクル管理

－

起動

－

停止

－

サスペンド

－

レジューム

－

スナップショットの作成

・

ブロックストレージ(Cinder)のアタッチ

・

キーペアの設定また、利用者は、ルートパーティションとしてCinderボリュームを使ったVM起動ができます。

・

フレーバーの設定

・

プロジェクトのクォータの変更

・

サービスの有効、無効

・

仮想マシンでの操作ブロックストレージ (Cinder)

・

ボリュームの作成

・

VMへのアタッチ

・

スナップショット・バックアップの採取

・

VMブートに使用するブータブルボリュームの作成

・

ボリュームタイプの設定

・

ボリュームタイプによるサービス品質との関連付けオブジェクトストレージ(Swift)

・

オブジェクトを格納するコンテナの設定

・

コンテナファイルの以下の操作

－

アップロード

－

ダウンロード

－

削除 -ネットワーク (Neutron)

・

以下のリソースの作成・編集

－

仮想ネットワーク

－

ルータ

－

サブネット

(17)

-コンポーネント利用者の操作管理者の操作

－

フローティングIP

－

セキュリティグループ

－

ロードバランサ

－

ファイアーウォール ID管理 (Keystone) -

・

プロジェクトの作成と編集

・

利用者の作成と編集

・

クレデンシャルの設定イメージ管理 (Glance)

・

プライベートイメージの以下の操作

－

作成

－

編集

－

削除

・

パブリックイメージの以下の操作

－

作成

－

編集

－

削除

・

プライベートイメージの以下の操作

－

作成

－

編集

－

削除オーケストレーション (Heat)

・

スタックの以下の操作

－

配備

－

参照

・

イベントの参照

・

スタックの以下の操作

－

配備

－

サスペンド

－

レジューム

－

参照

・

イベントの参照テレメトリ (Ceilometer)

・

アラームの登録・削除・変更

・

監視項目の登録・参照・統計値の取得

・

アラームの登録・削除・変更

・

監視項目の登録・参照・統計値の取得ダッシュボード (Horizon) 上記コンポーネントのWebUIを提供します。

・

利用可能リソースの使用状況の参照

・

仮想マシンの操作

・

ブロックストレージの操作

・

イメージの操作

・

アクセス・セキュリティの操作

・

ネットワークの操作

・

ルータの操作

・

オブジェクトストレージのコンテナ操作

・

オーケストレーションのスタック操作上記コンポーネントの管理者のWebUIを提供します。

・

モニタリング(Ceilometer)を使用した、リソース使用状況の参照

・

ハイパーバイザーの情報参照

・

ホストアグリゲートの操作

・

インスタンスの参照

・

ブロックストレージ(Cinder)の操作

・

フレーバーの操作

・

イメージの操作

・

ネットワーク・ルータの操作

・

各システム情報の参照

・

管理ソフトウェアの操作リージョンマネージャーオートスケールスケジュールの以下の操作

・

登録オートスケールスケジュールの以下の操作

・

登録

(18)

コンポーネント利用者の操作管理者の操作

・

削除

・

一覧取得

・

削除

・

一覧取得

OpenStack CLI - OpenStack標準のコマンドラインインターフェー

(19)

第

2 章

運用

本章では、本製品利用時の運用について説明します。

2.1 本製品の起動と停止

ここでは、本製品の起動と停止方法について説明します。

2.1.1 ハードウェアの起動順序

以下の順番でハードウェアを起動します。

各ハードウェアの起動方法は、「FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Standard 利用ガイド」を参照してください。

1.

スイッチ

2.

共有ストレージ(ETERNUS DX200 S3)

3.

管理サーバ(コントローラーノード)

4.

管理サーバ(ネットワークノード)

5.

管理サーバ(Cinderノード)

6.

業務サーバ(コンピュートノード) 各サーバの起動後、「2.1.4.3 サービスの状態確認」にしたがって、本製品のサービスが起動していることを確認してください。

注意

・

手順4、5実施時は、一つ前の手順のサーバのOSの起動が完了してから、電源を投入してください。

・

業務サーバ(コンピュートノード)を停止状態から起動させた場合、本製品で配備したインスタンスは自動起動しません。

2.1.2 ハードウェアの停止順序

以下の順番でVMおよびハードウェアを停止します。

各ハードウェアの停止方法は、「FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Standard 利用ガイド」を参照してください。

1.

業務サーバ(コンピュートノード)

2.

3.

管理サーバ(コントローラーVM2)

4.

5.

6.

7.

共有ストレージ(ETERNUS DX200 S3)

8.

スイッチ

(20)

注意

必ず管理サーバ(コントローラーVM1とコントローラーVM2)をシャットダウンしてから、管理サーバ(コントローラーノード)を停止してください。

2.1.3 業務サーバ

(

コンピュートノード

)

の起動、停止【

HA

構成】

ここでは、業務サーバ(コンピュートノード)の起動、停止について説明します。業務サーバ(コンピュートノード)のノード名が以下の場合の例を示します。稼動ノード compute1、compute2、compute3 待機ノード compute4

図

2.1 業務サーバ

(

コンピュートノード

)

の構成例

2.1.3.1 すべての業務サーバ

(

コンピュートノード

)

の起動

ここでは、すべての業務サーバ(コンピュートノード)の起動について説明します。

OSの起動

業務サーバ(コンピュートノード)のOSが起動していない場合、すべての業務サーバ(コンピュートノード)のOSを起動します。

PRIMECLUSTER

の起動

1.

待機ノードにroot権限でログインします。

2.

leaderappの起動以下のコマンドを実行し、待機ノードでleaderappを起動します。

(21)

3.

leaderappの起動確認

以下のコマンドを実行し、leaderappのStateが"Online"であることを確認します。コマンドの実行結果が、赤文字、かつ下線部のように表示されることを確認します。

# hvdisp -a <RETURN> Local System: compute4RMS

Configuration: /opt/SMAW/SMAWRrms/build/openstack.us

Resource Type HostName State StateDetails ---compute4RMS SysNode Online

compute3RMS SysNode Online compute2RMS SysNode Online compute1RMS SysNode Online leaderapp userApp Online Machine003_leaderapp andOp compute4RMS Online Machine002_leaderapp andOp compute3RMS

Machine001_leaderapp andOp compute2RMS Machine000_leaderapp andOp compute1RMS

ManageProgram000_Cmd_LEADERAPP gRes Online

本製品の設定変更

稼動ノードの設定変更

1.

管理サーバ(コントローラーVM2)にroot権限でログインします。

2.

稼動ノードのNovaのサービスを"enabled"に変更します。以下のコマンドを実行します。 # . /root/openrc <RETURN>

# nova service-enable compute1 nova-compute <RETURN> # nova service-enable compute2 nova-compute <RETURN> # nova service-enable compute3 nova-compute <RETURN>

3.

稼動ノードのNovaのサービスが"enabled"であることを確認します。以下のコマンドを実行します。

コマンドの実行結果が、赤文字、かつ下線部のように表示されることを確認します。

# nova service-list | grep "nova-compute" <RETURN>

| 6 | nova-compute | compute1 | az1 | enabled | up | 2016-07-12T06:27:38.000000 | | | 7 | nova-compute | compute2 | az1 | enabled | up | 2016-07-12T06:27:38.000000 | | | 8 | nova-compute | compute3 | az1 | enabled | up | 2016-07-12T06:27:34.000000 | | | 10 | nova-compute | compute4 | az1 | disabled | up | 2016-07-12T06:27:33.000000 | | 待機ノードの設定変更

1.

2.

待機ノードのサービスを"disabled"に変更します。以下のコマンドを実行します。 # . /root/openrc <RETURN>

(22)

3.

待機ノードのNovaのサービスが"disabled"であることを確認します。以下のコマンドを実行します。

# nova service-list | grep compute4 <RETURN>

| 6 | nova-compute | compute4 | az1 | disabled | up | 2016-07-11T07:27:51.000000 | rcx_ha_spare |

2.1.3.2 すべての業務サーバ

(

コンピュートノード

)

の停止

ここでは、すべての業務サーバ(コンピュートノード)の停止について説明します。

すべての業務サーバ

(

コンピュートノード

)

の設定変更

1.

2.

すべての業務サーバ(コンピュートノード)のNovaのサービスを"disabled"に変更します。以下のコマンドを実行します。 # . /root/openrc <RETURN>

# nova service-disable compute1 nova-compute <RETURN> # nova service-disable compute2 nova-compute <RETURN> # nova service-disable compute3 nova-compute <RETURN> # nova service-disable compute4 nova-compute <RETURN>

3.

すべての業務サーバ(コンピュートノード)のNovaのサービスが"disabled"であることを確認します。以下のコマンドを実行します。

# nova service-list | grep nova-compute <RETURN>

| 6 | nova-compute | compute1 | az1 | disabled | up | 2016-07-12T05:21:28.000000 | - | | 7 | nova-compute | compute2 | az1 | disabled | up | 2016-07-12T05:21:29.000000 | - | | 8 | nova-compute | compute3 | az1 | disabled | up | 2016-07-12T05:21:24.000000 | - | | 10 | nova-compute | compute4 | az1 | disabled | up | 2016-07-12T05:21:23.000000 | - |

PRIMECLUSTERの停止

1.

任意の業務サーバ(コンピュートノード)にroot権限でログインします。

2.

PRIMECLUSTERに定義したクラスタを停止します。以下のコマンドを実行します。 # hvshut -a <RETURN>

3.

クラスタが停止していることを確認します。以下のコマンドを実行し、"RMS is not running"が出力されることを確認します。 # hvdisp -a <RETURN> hvdisp: RMS is not running

(23)

OSの停止

すべての業務サーバ(コンピュートノード)のOSを停止します。

# shutdown -h now <RETURN>

2.1.4 サービスの起動、停止、確認

ここでは、本製品のサービスを意図的に起動、停止する方法、および起動状態の確認方法について説明します。サービスは、以下のサーバを起動する際に自動的に起動します。

・

業務サーバ(コンピュートノード) 本製品のバックアップ・リストアなどの運用時やトラブル対処時に本操作が必要です。

2.1.4.1 サービスの起動

ここでは、本製品のサービスの起動について説明します。すべてのサービスを起動する場合、以下の順序で起動してください。

1.

管理サーバ(コントローラーVM1)のサービス起動

2.

管理サーバ(コントローラーVM2)のサービス起動

3.

管理サーバ(ネットワークノード)のサービスの起動

4.

管理サーバ(Cinderノード)のサービスの起動

5.

業務サーバ(コンピュートノード)のサービスの起動

注意

・

以下の作業はrootユーザーで行ってください。

・

OS起動後は、本製品のサービスは起動状態です。

管理サーバ

(

コントローラー

VM1)

のサービスの起動

以下のコマンドを実行しサービスを起動します。コマンドの詳細は、「2.3.3 rcx_service」を参照してください。

# /opt/FJSVpf4c/bin/rcx_service start <RETURN>

管理サーバ(コントローラーVM2)のサービスの起動

(24)

管理サーバ(ネットワークノード)のサービスの起動

1.

2.

管理サーバ(コントローラーVM2)のサービスの停止を行わずに、管理サーバ(ネットワークノード)のサービスだけを停止している

場合は、管理サーバ(コントローラーVM2)上で以下のサービスを起動してください。

# /sbin/service l3-monitoring start <RETURN> # /sbin/service dhcp-monitoring start <RETURN> # /sbin/service lbaas-monitoring start <RETURN>

管理サーバ(Cinderノード)のサービスの起動

業務サーバ(コンピュートノード)のサービスの起動

2.1.4.2 サービスの停止

ここでは、本製品のサービスの停止について説明します。すべてのサービスを停止する場合、以下の順序で停止してください。

1.

業務サーバ(コンピュートノード)のサービスの停止

2.

管理サーバ(Cinderノード)のサービス停止

3.

管理サーバ(コントローラーVM2)のサービス停止

4.

管理サーバ(コントローラーVM1)のサービス停止

5.

管理サーバ(ネットワークノード)のサービスの停止

注意

・

OSが停止している場合、本製品のサービスを停止する必要はありません。

業務サーバ(コンピュートノード)のサービスの停止

以下のコマンドを実行しサービスを停止します。コマンドの詳細は、「2.3.3 rcx_service」を参照してください。

# /opt/FJSVpf4c/bin/rcx_service stop <RETURN>

管理サーバ(Cinderノード)のサービスの停止

(25)

管理サーバ(ネットワークノード)のサービスの停止

1.

管理サーバ(コントローラーVM2)のサービスの停止を行わずに、管理サーバ(ネットワークノード)のサービスだけを停止したい場

合は、管理サーバ(コントローラーVM2)上で以下のサービスを停止してください。

# /sbin/service l3-monitoring stop <RETURN> # /sbin/service dhcp-monitoring stop <RETURN> # /sbin/service lbaas-monitoring stop <RETURN>

2. 管理サーバ(コントローラーVM2)のサービスの停止

管理サーバ(コントローラーVM1)のサービスの停止

2.1.4.3 サービスの状態確認

ここでは、本製品のサービスの状態確認について説明します。

注意

・

OS起動後は、本製品のサービスは起動状態です。

管理サーバ(Cinderノード)のサービスの状態確認

以下のコマンドを実行しサービスの状態を確認します。コマンドの詳細は、「2.3.3 rcx_service」を参照してください。

# /opt/FJSVpf4c/bin/rcx_service status <RETURN>

管理サーバ(コントローラーVM1)のサービスの状態確認

管理サーバ(コントローラーVM2)のサービスの状態確認

(26)

以下のコマンドを実行し、管理サーバ(ネットワークノード)の監視状態を確認してください。

監視が必要な管理サーバ(ネットワークノード)が監視対象外になっている場合は、「4.2.2 管理サーバ(ネットワークノード)の復旧」の手

順に従って、監視対象にしてください。

# python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/l3_agent/excluded_list_l3_agent.py <RETURN> # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/dhcp_agent/excluded_list_dhcp_agent.py <RETURN> # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/lbaas_agent/excluded_list_lbaas_agent.py <RETURN>

管理サーバ(ネットワークノード)のサービスの状態確認

業務サーバ(コンピュートノード)のサービスの状態確認

2.2 バックアップ・リストア

ここでは、本製品のバックアップ・リストアの運用方法について説明します。システム全体の停止が前提になるため、バックアップは定期保守時に実施してください。なお、前回バックアップ時点以降に実施したシステムの変更はリストアすることはできません。

2.2.1 資源

ここでは、バックアップ時に採取する資源、およびバックアップのために必要なディスク容量について説明します。

バックアップ対象の資源

バックアップでは、以下のサーバ上で資源を採取します。

・

－

管理サーバ(すべてのコントローラーVM)のVMイメージファイル

－

管理サーバ(すべてのコントローラーVM)のXML定義ファイル

－

Swift内のデータ(glanceイメージ含む)

・

－

Neutronの設定ファイル

・

－

Cinderの設定ファイル

－

Cinderのシステムファイル

・

－

Novaの設定ファイル

－

Novaのシステムファイル

(27)

・

共有ストレージ(ETERNUS)

－

構成設定情報

－

ボリューム

バックアップ用ストレージ

バックアップ用ストレージは、本製品には含まれません。別途、外部ストレージを用意してください。バックアップに必要な外部ストレージの容量は、業務サーバ(利用者VM)で使用している容量によって変わります。バックアップに必要な外部ストレージ容量 = 管理用データ領域(6.7TB) + 業務用データ領域(作成されたCinderボリュームの総容量) 上記は1世代分のバックアップに必要な容量です。2世代以上のバックアップを保持する場合は、バックアップする世代数分の容量を用意してください。

バックアップ・リストアにかかる処理時間の目安

バックアップ・リストアにかかる時間の目安は下記のとおりです。余裕を持ったスケジュールでバックアップ・リストアを行ってください。 3～6時間 + ボリュームのバックアップ・リストアにかかる時間

ボリュームのバックアップ・リストアにかかる時間

は、ボリューム数、外部ストレージのIO性能に依存します。

2.2.2 バックアップ・リストアの共通手順

ここでは、バックアップ・リストアの共通手順について説明します。

バックアップボリュームのマウント

1.

管理サーバ(コントローラーノード)にroot権限でログインします。

2.

バックアップボリュームのマウント先ディレクトリを作成します。以下のコマンドを実行します。

# mkdir -p /tmp/backup/ <RETURN>

3.

SysBackボリュームのUIDを確認します。 ETERNUSのWebGUIから確認します。以下、WebGUIでの確認方法です。

－

ETERNUSのログイン画面にアクセスし、管理者ユーザーでログインします。

－

ボリュームタブを選択します。

－

ボリューム"SysBack"を選択します。

－

ボリューム情報のUIDを控えます。

4.

バックアップボリュームのマルチパスデバイス識別子を確認します。以下のコマンドを実行し、出力結果を

SysBack用マルチパスデバイス識別子

として控えます。

# multipath -ll | awk 'toupper($1) ~ /SysBackボリュームのUID/{print $1}' <RETURN>

5.

バックアップボリュームをマウントします。

(28)

# mount -t xfs /dev/mapper/SysBack用マルチパスデバイス識別子 /tmp/backup/ <RETURN>

業務サーバ(利用者VM)の停止

1.

2.

業務サーバ(利用者VM)の状態を確認します。以下のコマンドを実行し、業務サーバ(利用者VM)の状態がACTIVEまたはSHUTOFFになっていることを確認します。コマンドの詳細と注意事項は、「2.3.1 rcx_all_instance_ctl.sh」を参照してください。 # . /root/openrc <RETURN>

# /opt/FJSVpf4c/bin/rcx_all_instance_ctl.sh status <RETURN>

業務サーバ(利用者VM)のStatusがACTIVE以外の場合、StatusをACTIVEに遷移させます。

StatusとACTIVEへの遷移方法は、以下のとおりです。

表

2.1 Status

と

ACTIVE

への遷移方法

インスタンスのStatus 対処

RESCUE

1.

以下のコマンドを実行します。

# nova unrescue インスタンスID <RETURN>

2.

インスタンスのStatusがACTIVEになったことを確認します。

# nova show インスタンスID <RETURN> VERIFY_RESIZE

1.

以下のどちらかのコマンドを実行します。

# nova resize-confirm インスタンスID <RETURN>

または

# nova resize-revert インスタンスID <RETURN>

2.

# nova show インスタンスID <RETURN> SHELVED_OFFLOADED

1.

# nova unshelve インスタンスID <RETURN>

2.

# nova show インスタンスID <RETURN>

RESIZE

1.

インスタンスのStatusがVERIFY_RESIZEになったことを確認します。

2.

以下のどちらかのコマンドを実行します。

# nova resize-confirm インスタンスID <RETURN>

または

# nova resize-revert インスタンスID <RETURN>

(29)

インスタンスのStatus 対処

# nova show インスタンスID <RETURN> PAUSED

1.

# nova unpause インスタンスID <RETURN>

2.

# nova show インスタンスID <RETURN> SUSPENDED

1.

# nova resume インスタンスID <RETURN>

2.

# nova show インスタンスID <RETURN> ERROR

1.

# nova reset-state --active インスタンスID <RETURN>

2.

# nova show インスタンスID <RETURN> REVERT_RESIZE REBOOT HARD_REBOOT PASSWORD REBUILD MIGRATING

1.

3.

StatusがACTIVEである業務サーバ(利用者VM)の情報を保存します。

コマンドの詳細は、「2.3.1 rcx_all_instance_ctl.sh」を参照してください。

ACTIVEに遷移すべき業務サーバ(利用者VM)が存在する場合、コマンド実行後に一覧が表示されます。

手順2.の遷移方法に従って、対処を実施後、再度コマンドを実行してください。

# /opt/FJSVpf4c/bin/rcx_all_instance_ctl.sh list <RETURN>

4.

業務サーバ(利用者VM)をすべて停止します。

コマンドの詳細は、「2.3.1 rcx_all_instance_ctl.sh」を参照してください。

停止に失敗した業務サーバ(利用者VM)があれば、エラーメッセージに従って対処してください。

# /opt/FJSVpf4c/bin/rcx_all_instance_ctl.sh stop <RETURN>

5.

業務サーバ(利用者VM)の停止を確認します。

以下のコマンドを実行し、すべての業務サーバ(利用者VM)の状態がSHUTOFFになっていることを確認します。コマンドの詳細は、「2.3.1 rcx_all_instance_ctl.sh」を参照してください。

(30)

業務サーバ(コンピュートノード)のサービスの停止

以下の手順は、すべての業務サーバ(コンピュートノード)で実施してください。

1.

業務サーバ(コンピュートノード)にroot権限でログインします。

2.

業務サーバ(コンピュートノード)のサービスを停止します。以下のコマンドを実行します。コマンドの詳細は、「2.3.3 rcx_service」を参照してください。

3.

業務サーバ(コンピュートノード)のサービスの停止を確認します。

コマンドの詳細は、「2.3.3 rcx_service」を参照してください。

PRIMECLUSTERの停止【HA構成】

1.

HA構成の場合、PRIMECLUSTERを停止します。「2.1.3.2 すべての業務サーバ(コンピュートノード)の停止」の下記項目を実行してください。

－

すべての業務サーバ(コンピュートノード)の設定変更

－

PRIMECLUSTERの停止

管理サーバ(Cinderノード) のサービスの停止

1.

管理サーバ(Cinderノード)にroot権限でログインします。

2.

管理サーバ(Cinderノード)のサービスを停止します。以下のコマンドを実行します。コマンドの詳細は、「2.3.3 rcx_service」を参照してください。

3.

管理サーバ(Cinderノード)のサービスの停止を確認します。

管理サーバ(ネットワークノード)のサービスの停止

以下の手順は、すべての管理サーバ(ネットワークノード)で実施してください。

1.

管理サーバ(ネットワークノード)にroot権限でログインします。

2.

管理サーバ(ネットワークノード)のサービスを停止します。以下のコマンドを実行します。コマンドの詳細は、「2.3.3 rcx_service」を参照してください。

(31)

3.

管理サーバ(ネットワークノード)のサービスの停止を確認します。以下のコマンドを実行します。

管理サーバ(すべてのコントローラーVM)の停止

1.

2.

管理サーバ(コントローラーVM3)を停止します。

# virsh shutdown controller-vm3 <RETURN>

3.

4.

5.

管理サーバ(すべてのコントローラーVM)の停止を確認します。

以下のコマンドを実行し、すべてのコントローラーVMの状態がshut offになっていることを確認します。

# virsh domstate controller-vm1 <RETURN> # virsh domstate controller-vm2 <RETURN> # virsh domstate controller-vm3 <RETURN>

2.2.3 バックアップ

ここでは、バックアップについて説明します。

バックアップ・リストアの共通手順

「2.2.2 バックアップ・リストアの共通手順」を参照してください。

バックアップディレクトリの準備

1.

2.

マウント先を空にします。マウント先に、ファイル・ディレクトリがある場合は、別途用意したストレージに退避するか、削除してください。削除する場合は、以下のコマンドを実行します。 # rm -rf /tmp/backup/* <RETURN>

3.

バックアップディレクトリを作成します。以下のコマンドを実行し、バックアップディレクトリを作成します。

(32)

バックアップディレクトリ

には、バックアップ取得日時など、バックアップ取得時点を識別できる文字列を入力してください。

# mkdir -p /tmp/backup/バックアップディレクトリ/ <RETURN>

4.

管理サーバ(コントローラーノード)用のバックアップディレクトリを作成します。 # mkdir -p /tmp/backup/バックアップディレクトリ/control/ \ /tmp/backup/バックアップディレクトリ/control/etc/libvirt/qemu/ \ /tmp/backup/バックアップディレクトリ/control/var/lib/libvirt/images/controller/ \ /tmp/backup/バックアップディレクトリ/control/var/lib/libvirt/images/data/ <RETURN>

管理サーバ(すべてのコントローラーVM)のバックアップ

1.

2.

管理サーバ(すべてのコントローラーVM)のXML定義ファイルを取得します。

# virsh dumpxml controller-vm1 \

> /tmp/backup/バックアップディレクトリ/control/etc/libvirt/qemu/controller-vm1.xml <RETURN> # virsh dumpxml controller-vm2 \

> /tmp/backup/バックアップディレクトリ/control/etc/libvirt/qemu/controller-vm2.xml <RETURN> # virsh dumpxml controller-vm3 \

> /tmp/backup/バックアップディレクトリ/control/etc/libvirt/qemu/controller-vm3.xml <RETURN>

3.

管理サーバ(すべてのコントローラーVM)のイメージファイルを取得します。 # cp -p /var/lib/libvirt/images/controller/controller-vm{1,2,3}.qcow2 \ /tmp/backup/バックアップディレクトリ/control/var/lib/libvirt/images/controller/ <RETURN> # cp -p /var/lib/libvirt/images/data/swiftstorage1.qcow2 \ /tmp/backup/バックアップディレクトリ/control/var/lib/libvirt/images/data/ <RETURN>

管理サーバ

(

ネットワークノード

)

のバックアップ

以下の手順は、すべての管理サーバ(ネットワークノード)で実施してください。

1.

管理サーバ(ネットワークノード)にroot権限でログインします。

2.

以下のファイルを採取します。 scpコマンドでは、管理サーバ(コントローラーノード)のパスワードを求められます。

# tar --selinux -C / -zcvf /var/tmp/`hostname`.tar.gz etc/neutron <RETURN> # scp /var/tmp/`hostname`.tar.gz \ root@control:/tmp/backup/バックアップディレクトリ/ <RETURN> # rm /var/tmp/`hostname`.tar.gz <RETURN>

管理サーバ(Cinderノード)のバックアップ

1.

2.

以下のファイルを採取します。 scpコマンドでは、管理サーバ(コントローラーノード)のパスワードを求められます。

# umount /var/lib/cinder/conversion <RETURN>

# tar --selinux -C / -zcvf /var/tmp/`hostname`.tar.gz etc/cinder var/lib/cinder <RETURN> # scp /var/tmp/`hostname`.tar.gz \

root@control:/tmp/backup/バックアップディレクトリ/ <RETURN> # mount /var/lib/cinder/conversion <RETURN>

(33)

業務サーバ(コンピュートノード)のバックアップ

以下の手順は、すべての業務サーバ(コンピュートノード)で実施してください。

1.

業務サーバ(コンピュートノード)にroot権限でログインします。

2.

以下のファイルを採取します。

scpコマンドでは、管理サーバ(コントローラーノード)のパスワードを求められます。

# tar --selinux -C / -zcvf /var/tmp/`hostname`.tar.gz etc/nova var/lib/nova \ --exclude _base --exclude "disk*" <RETURN>

# scp /var/tmp/`hostname`.tar.gz root@control:/tmp/backup/バックアップディレクトリ/ <RETURN> # rm /var/tmp/`hostname`.tar.gz <RETURN>

共有ストレージに接続しているハードウェアの停止

共有ストレージに接続しているハードウェアを以下の順序で停止します。管理サーバ(Cinderノード)は、以降の手順で使用するため、停止しません。

各ハードウェアの停止方法は、「FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Standard 利用ガイド」を参照してください。

1.

2.

3. 業務サーバ(利用者VM)のデータのバックアップ

1.

2.

以下のコマンドを実行し、一時ディレクトリを作成します。

# mkdir -p /tmp/rcx_backup_tmp <RETURN>

3.

管理サーバ(Cinderノード)のAffinityGroupにバックアップ対象のボリュームを追加します。以下のコマンドを実行します。

# ETERNUS_IP=$(cat /etc/cinder/cinder_fujitsu_eternus_dx.xml | tr -d '\r\n' | sed 's;.*<EternusIP>$[^<>]*$</EternusIP>.*;\1;') <RETURN>

# CINDER_AFFINGRP=$(/opt/FJSVssmgr/sbin/storageadm affinity info -ipaddr $ETERNUS_IP -csv | awk -F, '$2 ~ /^Cinder[0-9]*/{print $1}') <RETURN>

# for affingrp in $CINDER_AFFINGRP; do

/opt/FJSVssmgr/sbin/storageadm affinity info -ipaddr $ETERNUS_IP -affinitygroup $affingrp -csv done | awk -F, '/^0x[0-9a-fA-F]{4}/ {print $4}' |

sort -u > /tmp/rcx_backup_tmp/volume_cinder <RETURN>

# /opt/FJSVssmgr/sbin/storageadm volume info -ipaddr $ETERNUS_IP -csv | awk -F, '/^0x[0-9a-fA-F]{4}/ {print $1}' | sort -u > /tmp/rcx_backup_tmp/volume_all <RETURN>

# join -j 1 -v 2 \

/tmp/rcx_backup_tmp/volume_cinder \ /tmp/rcx_backup_tmp/volume_all \ > /tmp/rcx_backup_tmp/volume_added <RETURN> # for affingrp in $CINDER_AFFINGRP; do

cat /tmp/rcx_backup_tmp/volume_added | tr "\r\n" "," | sed 's/,$//' | xargs -i /opt/FJSVssmgr/sbin/storageadm affinity update -ipaddr $ETERNUS_IP \

(34)

-affinitygroup $affingrp -add -volume {} -s > /dev/null done <RETURN>

4.

管理サーバ(Cinderノード)を再起動します。

以下のコマンドを実行し、OSを再起動します。

# shutdown -r now <RETURN>

5.

6.

管理サーバ(Cinderノード)のサービスを停止します。

7.

管理サーバ(Cinderノード)のサービスの停止を確認します。

8.

以下のコマンドを実行し、バックアップ対象のデバイスを確認します。

# find /dev/mapper/ | grep -E "/[0-9a-fA-F]{33}$" | sort <RETURN>

9.

外部ストレージを接続します。バックアップ用の外部ストレージを接続してください。ファイルシステムとして利用する場合は、適切な箇所にマウントしてください。

10.

確認したすべてのバックアップ対象のデバイスをバックアップします。以下に、ddコマンドを利用した例を示します。 # dd if=バックアップ対象デバイス \ of=バックアップデバイスまたはバックアップファイル \ bs=1G <RETURN>

バックアップデバイス

または

バックアップファイル

は、リストア時にリストア先デバイスが識別できるように、名前を付けるなどしてください。

11.

バックアップ対象のボリュームを、管理サーバ(Cinderノード)のAffinityGroupから削除します。以下のコマンドを実行します。 # ETERNUS_IP=$(cat /etc/cinder/cinder_fujitsu_eternus_dx.xml | tr -d '\r\n' | sed 's;.*<EternusIP>$[^<>]*$</EternusIP>.*;\1;') <RETURN>

# CINDER_AFFINGRP=$(/opt/FJSVssmgr/sbin/storageadm affinity info -ipaddr $ETERNUS_IP -csv | awk -F, '$2 ~ /^Cinder[0-9]*/{print $1}') <RETURN>

# for affingrp in $CINDER_AFFINGRP; do

cat /tmp/rcx_backup_tmp/volume_added | tr "\r\n" "," | sed 's/,$//' | xargs -I{} /opt/FJSVssmgr/sbin/storageadm affinity update -ipaddr $ETERNUS_IP \ -affinitygroup $affingrp -delete -volume {} -s > /dev/null

done <RETURN>

12.

以下のコマンドを実行し、一時ディレクトリを削除します。

# rm -rf /tmp/rcx_backup_tmp <RETURN>

13.

管理サーバ(Cinderノード)を停止します。以下のコマンドを実行し、OSを停止します。

(35)

# shutdown -h now <RETURN>

共有ストレージの構成設定情報のバックアップ

共有ストレージの構成設定情報をバックアップします。

構成設定情報のバックアップは、「ETERNUS Web GUI ユーザーズガイド(設定編)」の"構成設定情報バックアップ"、および"構成設定情報採取"の記述を参照してください。

共有ストレージに接続しているハードウェアの起動

共有ストレージに接続しているハードウェアを以下の順序で起動します。

各ハードウェアの起動方法は、「FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Standard 利用ガイド」を参照してください。

1.

2.

3.

4. 業務サーバ(利用者VM)の起動

1.

2.

業務サーバ(利用者VM)を起動します。以下のコマンドを実行します。起動に失敗した業務サーバ(利用者VM)があれば、エラーメッセージに従って対処を実施してください。コマンドの詳細は、「2.3.1 rcx_all_instance_ctl.sh」を参照してください。 # . /root/openrc <RETURN>

# /opt/FJSVpf4c/bin/rcx_all_instance_ctl.sh -l start <RETURN>

3.

業務サーバ(利用者VM)の起動を確認します。

以下のコマンドを実行し、バックアップ前に起動していたすべての業務サーバ(利用者VM)の状態がACTIVEになっていることを確認します。

コマンドの詳細と注意事項は、「2.3.1 rcx_all_instance_ctl.sh」を参照してください。

# /opt/FJSVpf4c/bin/rcx_all_instance_ctl.sh status <RETURN>

2.2.4 リストア

ここでは、リストアについて説明します。「共有ストレージの構成設定情報のリストア」には、当社技術員への連絡が必要です。

共有ストレージに接続しているハードウェアの停止

共有ストレージに接続しているハードウェアおよびVMを以下の順序で停止します。管理サーバ(Cinderノード)は、以降の手順で使用するため、停止しません。

ユーザーズガイド

J2X1-8070-01Z0(01)

2016

年

9

月

Linux

FUJITSU Software

ServerView Resource Orchestrator

Standard powered by K5 V3.3.0

まえがき

本書の目的

本書の読者

・

・

本書の構成

参照先URLについて

マニュアル体系と読み方

本書の表記について

・

・

・

・

・

・

・

・

・

FUJITSU Integrated System PRIMEFLEX for Cloud K5モデル Webサイト

略称

n

n

n

n

n

n

n

n

輸出管理規制について

商標について

・

・

・

・

・

・

・

・

お願い

・

・

出版年月および版数

著作権表示

目 次

第

1

章

概要

1.1 FUJITSU Software ServerView Resource Orchestrator

Standard powered by K5

とは

1.2

システム構成

システム構成例

図

1.1

システム構成例

-

-

-

-

-

-

-

-

-

-

-

-

ポイント

目　次

業務サーバ(利用者VM)の可用性向上【HA構成】