ユーザーズガイド

Transcription

1 FUJITSU Software ServerView Resource Orchestrator Standard powered by K5 V3.3.0 ユーザーズガイド Linux J2X Z0(01) 2016 年 9 月

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 月時点の情報です マニュアル体系と読み方 本製品のマニュアルには 以下のものがあります 必要に応じて それぞれのマニュアルを読んでください - i -

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: 略称 本書中の略称は以下のとおりです ( 注 ) CentOS 6.6 CentOS 7.1 製品 Red Hat(R) Enterprise Linux(R) 6.n (for Intel64) Red Hat(R) Enterprise Linux(R) 7.n (for Intel64) Red Hat(R) Enterprise Linux(R) 6.n (for Intel64) 仮想化機能 Red Hat(R) Enterprise Linux(R) OpenStack(R) Platform Windows(R) 7 Professional Windows(R) 7 Ultimate CentOS Red Hat Enterprise Linux 6 または RHEL6.n Red Hat Enterprise Linux 7 または RHEL7.n RHEL-KVM RHOSP Windows 略称 Red Hat Enterprise Linux または Linux - ii -

4 Windows(R) 8.n Pro Windows(R) 8.n Enterprise 製品 Windows(R) Internet Explorer(R) 10 Internet Explorer(R) 11 Firefox(R) FUJITSU Storage ETERNUS SF Storage Cruiser FUJITSU Software ServerView Resource Orchestrator Standard powered by K5 注 : "n" には マイナーリリースを示す数字が入ります Internet Explorer Firefox ETERNUS SF/SC ROR-K5 略称 輸出管理規制について 本ドキュメントを輸出または第三者へ提供する場合は お客様が居住する国および米国輸出管理関連法規等の規制をご確認のうえ 必要な手続きをおとりください 商標について 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 版 J2X Z0(00) 2016 年 9 月第 1 版 J2X Z0(01) 著作権表示 Copyright 2016 FUJITSU LIMITED - iii -

5 目次 第 1 章概要 FUJITSU Software ServerView Resource Orchestrator Standard powered by K5 とは システム構成 基本スペック 本製品の特長 スケーラビリティの確保 リソースの有効活用 システム構築パターンの統一 仮想マシンのリソース使用状況把握 冗長性の確保 提供機能一覧 本製品の使用者が利用できる主な操作 第 2 章運用 本製品の起動と停止 ハードウェアの起動順序 ハードウェアの停止順序 業務サーバ ( コンピュートノード ) の起動 停止 HA 構成 すべての業務サーバ ( コンピュートノード ) の起動 すべての業務サーバ ( コンピュートノード ) の停止 サービスの起動 停止 確認 サービスの起動 サービスの停止 サービスの状態確認 バックアップ リストア 資源 バックアップ リストアの共通手順 バックアップ リストア コマンドリファレンス rcx_all_instance_ctl.sh cssnap rcx_service ceilometer...43 第 3 章操作 ログイン ログアウト Horizon の追加機能 管理ソフトウェアの一覧表示 管理ソフトウェアの登録 管理ソフトウェアの編集 管理ソフトウェアの削除...51 第 4 章保守 定期保守 クラスタ構成における業務サーバ ( コンピュートノード ) の定期保守 HA 構成 業務サーバ ( コンピュートノード ) の切離し メンテナンスノードが稼動ノードの場合の切離し メンテナンスノードが待機ノードの場合の切離し 業務サーバ ( コンピュートノード ) の組込み メンテナンスノードが稼動ノードの場合の組込み メンテナンスノードが待機ノードの場合の組込み トラブル発生時の対処 トラブル発生時の対処の流れ 管理サーバ ( ネットワークノード ) の復旧 iv -

6 4.2.3 クラスタ構成の業務サーバ ( コンピュートノード ) の切替え発生時の対処 HA 構成 インスタンスの移動の確認 クラスタ構成の業務サーバ ( コンピュートノード ) の復旧 HA 構成 PRIMECLUSTER の状態確認 ストレージの復旧 業務サーバ ( コンピュートノード ) 上での作業 ETERNUS 上の作業 OS 再起動による業務サーバ ( コンピュートノード ) の復旧 トラブルシューティング 管理サーバ ( コントローラー VM1 とコントローラー VM2) のトラブルシューティング レスポンスで "ERROR:/etc/opt/FJSVrorcpf/availability_zone/nova:read failed" が返却される場合 インスタンスにポートを追加する Nova API のレスポンスで "ERROR:communication error" が返却される場合 Nova API でインスタンスからポートを削除したが 正しく削除されない場合 ライブマイグレーションが失敗した場合 インスタンスの作成 / 削除中に 管理サーバ ( コントローラー VM2) のサービスが停止し インスタンスの Status が "ERROR" になった場合 インスタンスの起動 / 停止処理実行後 インスタンスの Task State が "powering-on" または "powering-off" のままになった場合 ceilometer コマンド API が正常に動作しなくなった場合 業務サーバ ( コンピュートノード ) のトラブルシューティング 本製品で配備したインスタンスが自動起動しない場合 業務サーバ ( コンピュートノード ) 再起動後に 本製品で配備したインスタンスの task_state 値が "deleting" になる場合 libvirt-guests が自動起動に失敗する場合 業務サーバ ( コンピュートノード ) 切替え後 または切替え中に インスタンスに対するリクエストがエラーとなる場合 HA 構成 システムログに multipathd のエラーが出力された場合 システムログに libvirt のエラーが出力された場合 インスタンスに対してボリュームのアタッチ処理実行後 インスタンスにボリュームがアタッチされない場合 インスタンス起動時にボリューム作成が失敗した場合 ダッシュボード (Horizon) のトラブルシューティング ダッシュボード (Horizon) の [ 管理 ] タブにおいて [ リソース使用状況 ] -[ 統計情報 ] をクリックした際にエラーが発生する場合 ダッシュボード (Horizon) の [ プロジェクト ] タブにおいて [ コンピュート ]-[ 概要 ]-[ 利用可能リソース概要 ] の情報が実際の利用状況と一致しない場合 利用可能リソース概要に表示されているリソース数が プロジェクトごとのクォータ上限に到達している場合 管理サーバ (Cinder ノード ) のトラブルシューティング システムログに multipathd のエラーが出力された場合 メッセージ インスタンス一括起動 停止時のメッセージ サービス一括起動 停止時のメッセージ リソース使用状況取得時のメッセージ 管理ソフトウェア運用時のメッセージ 業務サーバ ( コンピュートノード ) のフェイルオーバでエラーが発生した場合のメッセージ HA 構成 第 5 章本製品利用時の留意点 付録 A サービス一覧 付録 B HTTPS 通信 付録 C Cinder の設定 C.1 Cinder バックアップ用の NFS 設定 C.2 Cinder スナップショットの設定 用語集 v -

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 システム構成例 ROR-K5: FUJITSU Software ServerView Resource Orchestrator Standard powered by K5-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) インスタンスのことです 業務サーバ ( コンピュートノード ) コンピュートノードのインスタンスが動作するホストのことです - 2 -

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

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は有効です 注意 他製品との同居はできません - 4 -

11 管理クライアントのソフトウェア 管理クライアントには 以下のソフトウェアが必要です 表 1.2 管理クライアントの必須ソフトウェア 必須ソフトウェア名バージョン備考 Internet Explorer 10 ( 注 1) 11 ( 注 1 注 2) Firefox ESR31 ESR38 注 1: デスクトップ版 Internet Explorer だけサポートします 注 2: Web ブラウザの画面の解像度は 100% にしてください Web ブラウザの設定における注意事項 Horizon を表示する場合 Internet Explorer または Firefox のどちらかが必要です Web ブラウザのセキュリティの設定で JavaScript および Cookie を使用しない設定にしている場合 Horizon が正しく表示できない場合があります Web ブラウザが Internet Explorer の場合は以下の確認も実施してください - Horizon の URL を " 信頼済みサイト " に追加してください 1.4 本製品の特長 ここでは 本製品の特長について説明します スケーラビリティの確保 スタックのテンプレート作成時に仮想マシン数を指定するだけで 負荷の上昇 低下に合わせて 仮想マシンを自動で追加 削除できます スケジュールを指定して 負荷上昇が予測される時期に仮想マシン数を増減できます 図 1.3 スケーラビリティの確保 リソースの有効活用 仮想マシンのスペック (CPU メモリ ストレージ容量) を定義し型決めできます 仮想マシン起動 ( 作成 ) 時に 複数仮想マシン ( インスタンス ) を指定できます 不要になった場合 仮想マシンを削除できるため リソースを有効活用できます - 5 -

12 仮想マシンに対して GUIから以下の操作ができます 起動 停止 再起動 スナップショットの操作 コンソールの操作図 1.4 仮想マシンの作成 削除 操作 システム構築パターンの統一 システム構築パターンを "Heatテンプレート" で作成し 複数サーバを一括で配備できます ひな形のテンプレートを複製し 類似システムのテンプレートを作成できます 図 1.5 Heatテンプレートによる複数サーバの一括配備 - 6 -

13 注 : 仮想ロードバランサを除くテンプレート作成 / 配備が可能 仮想マシンのリソース使用状況把握 すべての仮想マシンの仮想 CPU 数 ディスク メモリ 起動時間を月次で CSV 形式で保存できるため 仮想マシンのリソース使用状況を見える化できます スケーラビリティ確保の基礎データとして使用できます 図 1.6 仮想マシンのリソース使用状況の見える化 冗長性の確保 管理サーバ ( ネットワークノード ) の冗長化 管理サーバ ( ネットワークノード ) を冗長化しています 一方のサーバで異常が検知された場合 異常が検知されたサーバの電源を停止し サーバ上の資源 ( ネットワーク 仮想ルータ ロードバランサ ) をもう一方のサーバに自動的に移動させます 異常の検知は管理サーバ ( コントローラー VM2) で行われます 異常を検知する機構は管理サーバ ( コントローラー VM2) の起動時に自動で起動されます - 7 -

14 図 1.7 管理サーバ ( ネットワークノード ) の冗長化 業務サーバ ( 利用者 VM) の可用性向上 HA 構成 業務サーバ ( コンピュートノード ) に異常が発生した場合 そのうえで起動している業務サーバ ( 利用者 VM) を自動的に別の業務サーバ ( コンピュートノード ) に移動させます クラスタ内の業務サーバ ( コンピュートノード ) に異常が発生した場合 代表ノードが管理サーバ ( コントローラー VM2) に以下の要求を行います 異常が発生した業務サーバ ( コンピュートノード ) 上の業務サーバ ( 利用者 VM) を待機ノードに移動します 異常が発生した業務サーバ ( コンピュートノード ) の OpenStack サービスを無効 (disabled) に変更します 図 1.8 業務サーバ ( 利用者 VM) の可用性向上 - 8 -

15 稼動ノードクラスタ構成の中で インスタンスが動作する業務サーバ ( コンピュートノード ) のことです 待機ノード業務予備サーバ ( コンピュートノード ) のことです 稼動ノードに異常が発生した際 異常が発生した業務サーバ ( コンピュートノード ) 上のインスタンスが待機ノードに移動されます 代表ノードクラスタ内で1ノードだけ選出される業務サーバ ( コンピュートノード ) のことです 1.5 提供機能一覧 ここでは 本製品の提供機能について説明します 本製品の提供機能は以下のとおりです OpenStack の機能の詳細は OpenStack の Web サイトを参照してください 表 1.3 提供機能一覧 コンポーネント 概要 機能提供元 OpenStack 本製品他 OSS コンピュート (Nova) 仮想マシンの生成 管理をサポートします 〇 - - ブロックストレージ (Cinder) オブジェクトストレージ (Swift) ネットワーク (Neutron) アイデンティティー (Keystone) イメージ (Glance) オーケストレーション (Heat) ブロックストレージボリュームの生成 管理をサポートします 〇 - - オブジェクトの格納 取得を管理するサービスを提供します 〇 - - 仮想マシンに対する IP 割り振りやネットワーク接続のサービスを提供します また ロードバランサ (LBaaS) ファイアーウォール (FWaaS) を提供します 〇 - - ID 管理 認証機能を提供します 〇 - - 仮想マシンイメージの管理 ( イメージメタデータの設定 更新を含む ) 仮想イメージデータの取得ができます テンプレートを使用して 複数リソースを組み合わせたシステムの配備 編集ができます また AutoScalingGroup リソースとオートスケールスケジュール機能を組み合わせて 動的なインスタンスの増減を実現できます 〇 - - 〇 - - テレメトリ (Ceilometer) OpenStack 用のメータリング機能を提供します 〇 - - ダッシュボード (Horizon) リージョンマネージャー 上記コンポーネントの WebUI を提供します また 管理者の WebUI を提供します 以下の機能を提供します 物理サーバ管理 (Baremetal) を含む API の振り分け オートスケールのスケジュール機能 〇〇 - - 〇 - HAProxy 冗長構成時に リクエストの振り分けを行います - - 〇 - 9 -

16 コンポーネント 概要 また LBaaS のエンジンとして機能します 機能提供元 OpenStack 本製品他 OSS RabbitMQ OpenStack 内部でのキュー管理サービスです - - 〇 MariaDB 本製品のデータベースとして MariaDB を使用します - - 〇 OpenStack CLI OpenStack 標準のコマンドラインインターフェースを提供します 〇 本製品の使用者が利用できる主な操作 ここでは 本製品の使用者が利用できる主な操作の概要について説明します 本製品の使用者が利用できる主な操作は 以下のとおりです 操作の詳細は OpenStackのWebサイトを参照してください 表 1.4 本製品の使用者が利用できる主な操作 コンポーネント 利用者の操作 管理者の操作 コンピュート (Nova) 仮想マシンの生成 フレーバーの設定 仮想マシンのライフサイクル管理 - 起動 - 停止 プロジェクトのクォータの変更 サービスの有効 無効 仮想マシンでの操作 ブロックストレージ (Cinder) - サスペンド - レジューム - スナップショットの作成 ブロックストレージ (Cinder) のアタッチ キーペアの設定 また 利用者は ルートパーティションとして Cinder ボリュームを使った VM 起動ができます ボリュームの作成 VM へのアタッチ スナップショット バックアップの採取 VM ブートに使用するブータブルボリュームの作成 ボリュームタイプの設定 ボリュームタイプによるサービス品質との関連付け オブジェクトストレージ (Swift) ネットワーク (Neutron) オブジェクトを格納するコンテナの設定 コンテナファイルの以下の操作 - アップロード - ダウンロード - 削除 以下のリソースの作成 編集 - 仮想ネットワーク - ルータ - サブネット

17 コンポーネント 利用者の操作 管理者の操作 - フローティングIP - セキュリティグループ - ロードバランサ - ファイアーウォール ID 管理 (Keystone) - プロジェクトの作成と編集 利用者の作成と編集 クレデンシャルの設定 イメージ管理 (Glance) オーケストレーション (Heat) テレメトリ (Ceilometer) ダッシュボード (Horizon) リージョンマネージャー プライベートイメージの以下の操作 - 作成 - 編集 - 削除 スタックの以下の操作 - 配備 - 参照 イベントの参照 アラームの登録 削除 変更 監視項目の登録 参照 統計値の取得上記コンポーネントのWebUIを提供します 利用可能リソースの使用状況の参照 仮想マシンの操作 ブロックストレージの操作 イメージの操作 アクセス セキュリティの操作 ネットワークの操作 ルータの操作 オブジェクトストレージのコンテナ操作 オーケストレーションのスタック操作オートスケールスケジュールの以下の操作 登録 パブリックイメージの以下の操作 - 作成 - 編集 - 削除 プライベートイメージの以下の操作 - 作成 - 編集 - 削除 スタックの以下の操作 - 配備 - サスペンド - レジューム - 参照 イベントの参照 アラームの登録 削除 変更 監視項目の登録 参照 統計値の取得 上記コンポーネントの管理者の WebUI を提供します モニタリング (Ceilometer) を使用した リソース使用状況の参照 ハイパーバイザーの情報参照 ホストアグリゲートの操作 インスタンスの参照 ブロックストレージ (Cinder) の操作 フレーバーの操作 イメージの操作 ネットワーク ルータの操作 各システム情報の参照 管理ソフトウェアの操作 オートスケールスケジュールの以下の操作 登録

18 コンポーネント利用者の操作管理者の操作 削除 一覧取得 削除 一覧取得 OpenStack CLI - OpenStack 標準のコマンドラインインターフェー スを提供します

19 第 2 章運用 本章では 本製品利用時の運用について説明します 2.1 本製品の起動と停止 ここでは 本製品の起動と停止方法について説明します ハードウェアの起動順序 以下の順番でハードウェアを起動します 各ハードウェアの起動方法は FUJITSU Integrated System PRIMEFLEX for Cloud K5 モデル Standard 利用ガイド を参照してください 1. スイッチ 2. 共有ストレージ (ETERNUS DX200 S3) 3. 管理サーバ ( コントローラーノード ) 4. 管理サーバ ( ネットワークノード ) 5. 管理サーバ (Cinder ノード ) 6. 業務サーバ ( コンピュートノード ) 各サーバの起動後 サービスの状態確認 にしたがって 本製品のサービスが起動していることを確認してください 注意 手順 4 5 実施時は 一つ前の手順のサーバの OS の起動が完了してから 電源を投入してください 業務サーバ ( コンピュートノード ) を停止状態から起動させた場合 本製品で配備したインスタンスは自動起動しません ハードウェアの停止順序 以下の順番で VM およびハードウェアを停止します 各ハードウェアの停止方法は FUJITSU Integrated System PRIMEFLEX for Cloud K5 モデル Standard 利用ガイド を参照してください 1. 業務サーバ ( コンピュートノード ) 2. 管理サーバ (Cinder ノード ) 3. 管理サーバ ( コントローラー VM2) 4. 管理サーバ ( コントローラー VM1) 5. 管理サーバ ( コントローラーノード ) 6. 管理サーバ ( ネットワークノード ) 7. 共有ストレージ (ETERNUS DX200 S3) 8. スイッチ

20 注意 必ず管理サーバ ( コントローラー VM1 とコントローラー VM2) をシャットダウンしてから 管理サーバ ( コントローラーノード ) を停止してください 業務サーバ ( コンピュートノード ) の起動 停止 HA 構成 ここでは 業務サーバ ( コンピュートノード ) の起動 停止について説明します 業務サーバ ( コンピュートノード ) のノード名が以下の場合の例を示します 稼動ノード compute1 compute2 compute3 待機ノード compute4 図 2.1 業務サーバ ( コンピュートノード ) の構成例 すべての業務サーバ ( コンピュートノード ) の起動 ここでは すべての業務サーバ ( コンピュートノード ) の起動について説明します OSの起動業務サーバ ( コンピュートノード ) のOSが起動していない場合 すべての業務サーバ ( コンピュートノード ) のOSを起動します PRIMECLUSTERの起動 1. 待機ノードにroot 権限でログインします 2. leaderappの起動以下のコマンドを実行し 待機ノードでleaderappを起動します # hvswitch leaderapp compute4rms <RETURN>

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 T06:27: nova-compute compute2 az1 enabled up T06:27: nova-compute compute3 az1 enabled up T06:27: nova-compute compute4 az1 disabled up T06:27: 待機ノードの設定変更 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. 待機ノードのサービスを "disabled" に変更します #. /root/openrc <RETURN> # nova service-disable --reason "rcx_ha_spare" compute4 nova-compute <RETURN>

22 3. 待機ノードの Nova のサービスが "disabled" であることを確認します コマンドの実行結果が 赤文字 かつ下線部のように表示されることを確認します # nova service-list grep compute4 <RETURN> 6 nova-compute compute4 az1 disabled up T07:27: rcx_ha_spare すべての業務サーバ ( コンピュートノード ) の停止 ここでは すべての業務サーバ ( コンピュートノード ) の停止について説明します すべての業務サーバ ( コンピュートノード ) の設定変更 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 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 T05:21: nova-compute compute2 az1 disabled up T05:21: nova-compute compute3 az1 disabled up T05:21: nova-compute compute4 az1 disabled up T05:21: 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> サービスの起動 停止 確認 ここでは 本製品のサービスを意図的に起動 停止する方法 および起動状態の確認方法について説明します サービスは 以下のサーバを起動する際に自動的に起動します 管理サーバ ( コントローラー VM1) 管理サーバ ( コントローラー VM2) 管理サーバ ( ネットワークノード ) 管理サーバ (Cinderノード) 業務サーバ ( コンピュートノード ) 本製品のバックアップ リストアなどの運用時やトラブル対処時に本操作が必要です サービスの起動 ここでは 本製品のサービスの起動について説明します すべてのサービスを起動する場合 以下の順序で起動してください 1. 管理サーバ ( コントローラー VM1) のサービス起動 2. 管理サーバ ( コントローラー VM2) のサービス起動 3. 管理サーバ ( ネットワークノード ) のサービスの起動 4. 管理サーバ (Cinderノード) のサービスの起動 5. 業務サーバ ( コンピュートノード ) のサービスの起動 注意 以下の作業は root ユーザーで行ってください OS 起動後は 本製品のサービスは起動状態です 管理サーバ ( コントローラー VM1) のサービスの起動 以下のコマンドを実行しサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN> 管理サーバ ( コントローラー VM2) のサービスの起動 以下のコマンドを実行しサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN>

24 管理サーバ ( ネットワークノード ) のサービスの起動 1. 以下のコマンドを実行しサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN> 2. 管理サーバ ( コントローラー VM2) のサービスの停止を行わずに 管理サーバ ( ネットワークノード ) のサービスだけを停止している場合は 管理サーバ ( コントローラー VM2) 上で以下のサービスを起動してください # /sbin/service l3-monitoring start <RETURN> # /sbin/service dhcp-monitoring start <RETURN> # /sbin/service lbaas-monitoring start <RETURN> 管理サーバ (Cinder ノード ) のサービスの起動 以下のコマンドを実行しサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN> 業務サーバ ( コンピュートノード ) のサービスの起動 以下のコマンドを実行しサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN> サービスの停止 ここでは 本製品のサービスの停止について説明します すべてのサービスを停止する場合 以下の順序で停止してください 1. 業務サーバ ( コンピュートノード ) のサービスの停止 2. 管理サーバ (Cinderノード) のサービス停止 3. 管理サーバ ( コントローラー VM2) のサービス停止 4. 管理サーバ ( コントローラー VM1) のサービス停止 5. 管理サーバ ( ネットワークノード ) のサービスの停止 注意 以下の作業は root ユーザーで行ってください OS が停止している場合 本製品のサービスを停止する必要はありません 業務サーバ ( コンピュートノード ) のサービスの停止 以下のコマンドを実行しサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> 管理サーバ (Cinder ノード ) のサービスの停止 以下のコマンドを実行しサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN>

25 管理サーバ ( ネットワークノード ) のサービスの停止 1. 管理サーバ ( コントローラー VM2) のサービスの停止を行わずに 管理サーバ ( ネットワークノード ) のサービスだけを停止したい場合は 管理サーバ ( コントローラー VM2) 上で以下のサービスを停止してください # /sbin/service l3-monitoring stop <RETURN> # /sbin/service dhcp-monitoring stop <RETURN> # /sbin/service lbaas-monitoring stop <RETURN> 2. 以下のコマンドを実行しサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> 管理サーバ ( コントローラー VM2) のサービスの停止 以下のコマンドを実行しサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> 管理サーバ ( コントローラー VM1) のサービスの停止 以下のコマンドを実行しサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> サービスの状態確認 ここでは 本製品のサービスの状態確認について説明します 注意 以下の作業はrootユーザーで行ってください OS 起動後は 本製品のサービスは起動状態です 管理サーバ (Cinder ノード ) のサービスの状態確認 以下のコマンドを実行しサービスの状態を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 管理サーバ ( コントローラー VM1) のサービスの状態確認 以下のコマンドを実行しサービスの状態を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 管理サーバ ( コントローラー VM2) のサービスの状態確認 以下のコマンドを実行しサービスの状態を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN>

26 以下のコマンドを実行し 管理サーバ ( ネットワークノード ) の監視状態を確認してください 監視が必要な管理サーバ ( ネットワークノード ) が監視対象外になっている場合は 管理サーバ ( ネットワークノード ) の復旧 の手順に従って 監視対象にしてください # 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> 管理サーバ ( ネットワークノード ) のサービスの状態確認 以下のコマンドを実行しサービスの状態を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 業務サーバ ( コンピュートノード ) のサービスの状態確認 以下のコマンドを実行しサービスの状態を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 2.2 バックアップ リストア ここでは 本製品のバックアップ リストアの運用方法について説明します システム全体の停止が前提になるため バックアップは定期保守時に実施してください なお 前回バックアップ時点以降に実施したシステムの変更はリストアすることはできません 資源 ここでは バックアップ時に採取する資源 およびバックアップのために必要なディスク容量について説明します バックアップ対象の資源バックアップでは 以下のサーバ上で資源を採取します 管理サーバ ( コントローラーノード ) - 管理サーバ ( すべてのコントローラー VM) のVMイメージファイル - 管理サーバ ( すべてのコントローラー VM) のXML 定義ファイル - Swift 内のデータ (glanceイメージ含む) 管理サーバ ( ネットワークノード ) - Neutronの設定ファイル 管理サーバ (Cinderノード) - Cinderの設定ファイル - Cinderのシステムファイル 業務サーバ ( コンピュートノード ) - Novaの設定ファイル - Novaのシステムファイル

27 共有ストレージ (ETERNUS) - 構成設定情報 - ボリューム バックアップ用ストレージ バックアップ用ストレージは 本製品には含まれません 別途 外部ストレージを用意してください バックアップに必要な外部ストレージの容量は 業務サーバ ( 利用者 VM) で使用している容量によって変わります バックアップに必要な外部ストレージ容量 = 管理用データ領域 (6.7TB) + 業務用データ領域 ( 作成された Cinder ボリュームの総容量 ) 上記は 1 世代分のバックアップに必要な容量です 2 世代以上のバックアップを保持する場合は バックアップする世代数分の容量を用意してください バックアップ リストアにかかる処理時間の目安バックアップ リストアにかかる時間の目安は下記のとおりです 余裕を持ったスケジュールでバックアップ リストアを行ってください 3~6 時間 + ボリュームのバックアップ リストアにかかる時間ボリュームのバックアップ リストアにかかる時間は ボリューム数 外部ストレージのIO 性能に依存します バックアップ リストアの共通手順 ここでは バックアップ リストアの共通手順について説明します バックアップボリュームのマウント 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. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. 業務サーバ ( 利用者 VM) の状態を確認します 以下のコマンドを実行し 業務サーバ ( 利用者 VM) の状態が ACTIVE または SHUTOFF になっていることを確認します コマンドの詳細と注意事項は 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. インスタンスのStatusがACTIVEになったことを確認します # nova show インスタンスID <RETURN> SHELVED_OFFLOADED 1. # nova unshelve インスタンス ID <RETURN> 2. インスタンスの Status が ACTIVE になったことを確認します # nova show インスタンス ID <RETURN> RESIZE 1. インスタンスの Status が VERIFY_RESIZE になったことを確認します # nova show インスタンスID <RETURN> 2. 以下のどちらかのコマンドを実行します # nova resize-confirm インスタンスID <RETURN> または # nova resize-revert インスタンスID <RETURN> 3. インスタンスのStatusがACTIVEになったことを確認します

29 インスタンスの Status 対処 # nova show インスタンス ID <RETURN> PAUSED 1. # nova unpause インスタンス ID <RETURN> 2. インスタンスの Status が ACTIVE になったことを確認します # nova show インスタンス ID <RETURN> SUSPENDED 1. # nova resume インスタンス ID <RETURN> 2. インスタンスの Status が ACTIVE になったことを確認します # nova show インスタンス ID <RETURN> ERROR 1. # nova reset-state --active インスタンス ID <RETURN> 2. インスタンスの Status が ACTIVE になったことを確認します # nova show インスタンス ID <RETURN> REVERT_RESIZE REBOOT HARD_REBOOT PASSWORD REBUILD MIGRATING 1. インスタンスの Status が ACTIVE になったことを確認します # nova show インスタンス ID <RETURN> 3. StatusがACTIVEである業務サーバ ( 利用者 VM) の情報を保存します コマンドの詳細は rcx_all_instance_ctl.sh を参照してください ACTIVEに遷移すべき業務サーバ ( 利用者 VM) が存在する場合 コマンド実行後に一覧が表示されます 手順 2. の遷移方法に従って 対処を実施後 再度コマンドを実行してください # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh list <RETURN> 4. 業務サーバ ( 利用者 VM) をすべて停止します コマンドの詳細は rcx_all_instance_ctl.sh を参照してください 停止に失敗した業務サーバ ( 利用者 VM) があれば エラーメッセージに従って対処してください # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh stop <RETURN> 5. 業務サーバ ( 利用者 VM) の停止を確認します 以下のコマンドを実行し すべての業務サーバ ( 利用者 VM) の状態がSHUTOFFになっていることを確認します コマンドの詳細は rcx_all_instance_ctl.sh を参照してください # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh status <RETURN>

30 業務サーバ ( コンピュートノード ) のサービスの停止以下の手順は すべての業務サーバ ( コンピュートノード ) で実施してください 1. 業務サーバ ( コンピュートノード ) にroot 権限でログインします 2. 業務サーバ ( コンピュートノード ) のサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> 3. 業務サーバ ( コンピュートノード ) のサービスの停止を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> PRIMECLUSTERの停止 HA 構成 1. HA 構成の場合 PRIMECLUSTERを停止します すべての業務サーバ ( コンピュートノード ) の停止 の下記項目を実行してください - すべての業務サーバ ( コンピュートノード ) の設定変更 - PRIMECLUSTERの停止 管理サーバ (Cinderノード) のサービスの停止 1. 管理サーバ (Cinderノード) にroot 権限でログインします 2. 管理サーバ (Cinderノード) のサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> 3. 管理サーバ (Cinderノード) のサービスの停止を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 管理サーバ ( ネットワークノード ) のサービスの停止以下の手順は すべての管理サーバ ( ネットワークノード ) で実施してください 1. 管理サーバ ( ネットワークノード ) にroot 権限でログインします 2. 管理サーバ ( ネットワークノード ) のサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN>

31 3. 管理サーバ ( ネットワークノード ) のサービスの停止を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 管理サーバ ( すべてのコントローラー VM) の停止 1. 管理サーバ ( コントローラーノード ) に root 権限でログインします 2. 管理サーバ ( コントローラー VM3) を停止します # virsh shutdown controller-vm3 <RETURN> 3. 管理サーバ ( コントローラー VM2) を停止します # virsh shutdown controller-vm2 <RETURN> 4. 管理サーバ ( コントローラー VM1) を停止します # virsh shutdown controller-vm1 <RETURN> 5. 管理サーバ ( すべてのコントローラー VM) の停止を確認します 以下のコマンドを実行し すべてのコントローラー VM の状態が shut off になっていることを確認します # virsh domstate controller-vm1 <RETURN> # virsh domstate controller-vm2 <RETURN> # virsh domstate controller-vm3 <RETURN> バックアップ ここでは バックアップについて説明します バックアップ リストアの共通手順 バックアップ リストアの共通手順 を参照してください バックアップディレクトリの準備 1. 管理サーバ ( コントローラーノード ) にroot 権限でログインします 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. 管理サーバ ( コントローラーノード ) に root 権限でログインします 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. 管理サーバ (Cinder ノード ) に root 権限でログインします 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> # rm /var/tmp/`hostname`.tar.gz <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. 管理サーバ (Cinder ノード ) に root 権限でログインします 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. 管理サーバ (Cinder ノード ) に root 権限でログインします 6. 管理サーバ (Cinder ノード ) のサービスを停止します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> 7. 管理サーバ (Cinder ノード ) のサービスの停止を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 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. 管理サーバ (Cinder ノード ) 4. 業務サーバ ( コンピュートノード ) 業務サーバ ( 利用者 VM) の起動 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. 業務サーバ ( 利用者 VM) を起動します 起動に失敗した業務サーバ ( 利用者 VM) があれば エラーメッセージに従って対処を実施してください コマンドの詳細は rcx_all_instance_ctl.sh を参照してください #. /root/openrc <RETURN> # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh -l start <RETURN> 3. 業務サーバ ( 利用者 VM) の起動を確認します 以下のコマンドを実行し バックアップ前に起動していたすべての業務サーバ ( 利用者 VM) の状態が ACTIVE になっていることを確認します コマンドの詳細と注意事項は rcx_all_instance_ctl.sh を参照してください # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh status <RETURN> リストア ここでは リストアについて説明します 共有ストレージの構成設定情報のリストア には 当社技術員への連絡が必要です 共有ストレージに接続しているハードウェアの停止 共有ストレージに接続しているハードウェアおよび VM を以下の順序で停止します 管理サーバ (Cinder ノード ) は 以降の手順で使用するため 停止しません

36 各ハードウェアの停止方法は FUJITSU Integrated System PRIMEFLEX for Cloud K5 モデル Standard 利用ガイド を参照してください 1. 業務サーバ ( コンピュートノード ) 2. 管理サーバ ( コントローラー VM2) 3. 管理サーバ ( コントローラー VM1) 4. 管理サーバ ( コントローラーノード ) 5. 管理サーバ ( ネットワークノード ) 共有ストレージの構成設定情報のリストア 本手順は当社技術員が実施します あらかじめ 当社技術員に連絡してください 業務サーバ ( 利用者 VM) のデータのリストア 1. 管理サーバ (Cinder ノード ) に root 権限でログインします 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 \ -affinitygroup $affingrp -add -volume {} -s > /dev/null done <RETURN> 4. 管理サーバ (Cinder ノード ) を再起動します 以下のコマンドを実行し OS を再起動します # shutdown -r now <RETURN> 5. 管理サーバ (Cinder ノード ) に root 権限でログインします 6. 管理サーバ (Cinder ノード ) のサービスを停止します

37 コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> 7. 管理サーバ (Cinder ノード ) のサービスの停止を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 8. バックアップしたデータをリストアします 以下に dd コマンドを利用した例を示します # dd if= バックアップデバイスまたはバックアップファイル \ of= リストア対象デバイス \ bs=1g <RETURN> バックアップデバイスまたはバックアップファイルは 業務サーバ ( 利用者 VM) のデータのバックアップ でバックアップしたデバイスまたはファイルを指定してください リストア対象デバイスは バックアップデバイスまたはバックアップファイルに対応するデバイスを指定してください 9. バックアップ対象のボリュームを 管理サーバ (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> 10. 以下のコマンドを実行し 一時ディレクトリを削除します # rm -rf /tmp/rcx_backup_tmp <RETURN> 11. 管理サーバ (Cinder ノード ) を停止します 以下のコマンドを実行し OS を停止します # shutdown -h now <RETURN> 共有ストレージに接続しているハードウェアの起動 共有ストレージに接続しているハードウェアを以下の順序で起動します 各ハードウェアの起動方法は FUJITSU Integrated System PRIMEFLEX for Cloud K5 モデル Standard 利用ガイド を参照してください 1. 管理サーバ ( コントローラーノード ) 2. 管理サーバ ( ネットワークノード ) 3. 管理サーバ (Cinder ノード ) 4. 業務サーバ ( コンピュートノード )

38 バックアップ リストアの共通手順 バックアップ リストアの共通手順 を参照してください 業務サーバ ( コンピュートノード ) のリストア 以下の手順は すべての業務サーバ ( コンピュートノード ) で実施してください 1. 業務サーバ ( コンピュートノード ) に root 権限でログインします 2. バックアップ時に採取した以下のファイルをリストアします scp コマンドでは 管理サーバ ( コントローラーノード ) のパスワードを求められます # rm -rf /etc/nova/* <RETURN> # rm -rf /var/lib/nova/* <RETURN> # scp root@control:/tmp/backup/ バックアップディレクトリ /`hostname`.tar.gz /var/tmp/ <RETURN> # tar --selinux -C / -xvf /var/tmp/`hostname`.tar.gz <RETURN> # rm /var/tmp/`hostname`.tar.gz <RETURN> 管理サーバ (Cinder ノード ) のリストア 1. 管理サーバ (Cinder ノード ) に root 権限でログインします 2. バックアップ時に採取した以下のファイルをリストアします scp コマンドでは 管理サーバ ( コントローラーノード ) のパスワードを求められます # umount /var/lib/cinder/conversion <RETURN> # rm -rf /etc/cinder/* <RETURN> # rm -rf /var/lib/cinder/* <RETURN> # scp root@control:/tmp/backup/ バックアップディレクトリ /`hostname`.tar.gz /var/tmp/ <RETURN> # tar --selinux -C / -xvf /var/tmp/`hostname`.tar.gz <RETURN> # mount /var/lib/cinder/conversion <RETURN> # rm /var/tmp/`hostname`.tar.gz <RETURN> 管理サーバ ( ネットワークノード ) のリストア 以下の手順は すべての管理サーバ ( ネットワークノード ) で実施してください 1. 管理サーバ ( ネットワークノード ) に root 権限でログインします 2. バックアップ時に採取した以下のファイルをリストアします scp コマンドでは 管理サーバ ( コントローラーノード ) のパスワードを求められます # rm -rf /etc/neutron/* <RETURN> # scp root@control:/tmp/backup/ バックアップディレクトリ /`hostname`.tar.gz /var/tmp/ <RETURN> # tar --selinux -C / -xvf /var/tmp/`hostname`.tar.gz <RETURN> # rm /var/tmp/`hostname`.tar.gz <RETURN> 管理サーバ ( すべてのコントローラー VM) のリストア 1. 管理サーバ ( コントローラーノード ) にroot 権限でログインします 2. 管理サーバ ( すべてのコントローラー VM) のXML 定義ファイルをリストアします

39 # cp -p /tmp/backup/ バックアップディレクトリ /control/etc/libvirt/qemu/controller-vm{1,2,3}.xml \ /etc/libvirt/qemu/ <RETURN> # virsh define /etc/libvirt/qemu/controller-vm1.xml <RETURN> # virsh define /etc/libvirt/qemu/controller-vm2.xml <RETURN> # virsh define /etc/libvirt/qemu/controller-vm3.xml <RETURN> 3. 管理サーバ ( すべてのコントローラー VM) のイメージファイルをリストアします # cp -p \ /tmp/backup/ バックアップディレクトリ /control/var/lib/libvirt/images/controller/controller-vm{1,2,3}.qcow2 \ /var/lib/libvirt/images/controller/ <RETURN> # cp -p \ /tmp/backup/ バックアップディレクトリ /control/var/lib/libvirt/images/data/swiftstorage1.qcow2 \ /var/lib/libvirt/images/data/ <RETURN> 管理サーバ ( すべてのコントローラー VM) の起動 1. 管理サーバ ( コントローラーノード ) に root 権限でログインします 2. 管理サーバ ( コントローラー VM1) を起動します # virsh start controller-vm1 <RETURN> 3. 管理サーバ ( コントローラー VM1) の起動を確認します 以下のコマンドを実行し AMQP と出力されることを確認します # curl -s controller-vm1:5672 grep -a AMQP <RETURN> 4. 管理サーバ ( コントローラー VM2) を起動します # virsh start controller-vm2 <RETURN> 5. 管理サーバ ( コントローラー VM3) 起動します # virsh start controller-vm3 <RETURN> 6. 管理サーバ ( コントローラー VM2 とコントローラー VM3) の起動を確認します 以下のコマンドを実行し controller-vm2 controller-vm3 の状態が running になっていることを確認します # virsh domstate controller-vm2 <RETURN> # virsh domstate controller-vm3 <RETURN> 管理サーバ ( ネットワークノード ) のサービスの起動 以下の手順は すべての管理サーバ ( ネットワークノード ) で実施してください 1. 管理サーバ ( ネットワークノード ) にroot 権限でログインします 2. 管理サーバ ( ネットワークノード ) のサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN>

40 3. 管理サーバ ( ネットワークノード ) のサービスの起動を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 管理サーバ (Cinderノード) のサービスの起動 1. 管理サーバ (Cinderノード) にroot 権限でログインします 2. 管理サーバ (Cinderノード) のサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN> 3. 管理サーバ (Cinderノード) のサービスの起動を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> 業務サーバ ( コンピュートノード ) のサービスの起動 以下の手順は すべての業務サーバ ( コンピュートノード ) で実施してください 1. 業務サーバ ( コンピュートノード ) にroot 権限でログインします 2. 業務サーバ ( コンピュートノード ) のサービスを起動します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service start <RETURN> 3. 業務サーバ ( コンピュートノード ) のサービスの起動を確認します コマンドの詳細は rcx_service を参照してください # /opt/fjsvpf4c/bin/rcx_service status <RETURN> PRIMECLUSTERの起動 HA 構成 1. HA 構成の場合 PRIMECLUSTERを起動します a. 任意の業務サーバ ( コンピュートノード ) にroot 権限でログインします b. # hvcm -a <RETURN> c すべての業務サーバ ( コンピュートノード ) の起動 の下記項目を実行します - PRIMECLUSTERの起動

41 - 本製品の設定変更 不要なインスタンス定義の削除 業務サーバ ( コンピュートノード ) リストア前後の インスタンス定義の差分を抽出し 不要なインスタンス定義を削除します 以下の手順は すべての業務サーバ ( コンピュートノード ) で実施してください 1. 業務サーバ ( コンピュートノード ) に root 権限でログインします 2. Nova 管理下の定義ファイルからインスタンス名を取得します # grep -roi "<name>.*</name>" /var/lib/nova/ cut -d: -f2 sed -e 's;<name>\(.*\)</name>;\1;' sort > /tmp/backup_instances.txt <RETURN> 3. 業務サーバ ( コンピュートノード ) 上のインスタンス名を取得します # virsh list --all tail -n+3 awk '{print $2}' grep -v "^$" sort > /tmp/virsh_instances.txt <RETURN> 4. インスタンス名の差分を抽出します 差分がない場合は出力されません # diff /tmp/backup_instances.txt /tmp/virsh_instances.txt grep "^>" awk '{print $2}' <RETURN> 5. 手順 3. で出力されたインスタンスの状態が SHUTOFF であることを確認します # virsh list --all <RETURN> 6. 手順 4. で出力されたインスタンスの定義を削除します # virsh undefine インスタンス名 --managed-save --snapshots-metadata <RETURN> 7. 一時ファイルを削除します # rm /tmp/backup_instances.txt /tmp/virsh_instances.txt <RETURN> 業務サーバ ( 利用者 VM) の起動 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. 業務サーバ ( 利用者 VM) を起動します コマンドの詳細と注意事項は rcx_all_instance_ctl.sh を参照してください #. /root/openrc <RETURN> # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh -l start <RETURN>

42 3. 業務サーバ ( 利用者 VM) の起動を確認します 以下のコマンドを実行し リストア前に起動していたすべての業務サーバ ( 利用者 VM) の状態が ACTIVE になっていることを確認します コマンドの詳細と注意事項は rcx_all_instance_ctl.sh を参照してください # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh status <RETURN> バックアップボリュームのアンマウント 1. 管理サーバ ( コントローラーノード ) にroot 権限でログインします 2. バックアップボリュームをアンマウントします # umount /tmp/backup/ <RETURN> 2.3 コマンドリファレンス ここでは 本製品が提供するコマンドについて説明します rcx_all_instance_ctl.sh 名前 /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh 形式 rcx_all_instance_ctl.sh [-l] start rcx_all_instance_ctl.sh stop rcx_all_instance_ctl.sh status rcx_all_instance_ctl.sh list 機能説明 rcx_all_instance_ctl.sh は本製品の環境において インスタンスを一括で起動 停止するためのコマンドです オプション -l サブコマンド start を参照してください サブコマンド start -lオプションが指定されていない場合 StatusがSHUTOFFであるインスタンスだけを起動します 結果をコンソール ログに出力します StatusがSHUTOFF 以外のインスタンスは 起動しません また コンソール ログに出力しません

43 -lオプションが指定されている場合 /var/opt/fjsvpf4c/list/instance.listファイル内に存在するインスタンスだけが操作対象になります StatusがSHUTOFFであるインスタンスだけを起動します 結果をコンソール ログに出力します StatusがSHUTOFF 以外のインスタンスは 起動しません 理由をコンソール ログに出力します stop 以下のすべての条件を満たすインスタンスを停止し その結果をコンソールとログに出力します - StatusがACTIVEである - Task StateがNoneである条件を満たさないインスタンスは停止しません その理由をコンソールとログに出力します ただし StatusがSHUTOFFであるインスタンスは 理由をコンソールとログに出力しません status インスタンスの状態を表示します 項目名 ID Name Status Task State 内容インスタンスID インスタンスの名前インスタンスの状態インスタンスのタスクの状態 Status Status( インスタンスの状態 ) で表示される状態は以下のとおりです ACTIVE SHUTOFF RESIZE 状態 VERIFY_RESIZE REVERT_RESIZE RESCUE MIGRATING REBOOT HARD_REBOOT PASSWORD REBUILD PAUSED SUSPENDED SHELVED_OFFLOA DED ERROR 説明起動状態停止状態リサイズ状態リサイズの確定処理中リサイズ前の状態への復帰処理中レスキューモードで起動マイグレーション処理中ソフトリブート処理中ハードリブート処理中パスワード変更中初期化中一時停止状態休止状態退避状態エラー状態 Task State Task State( 現時点でインスタンスが実行しているタスク ) は インスタンスへの処理が実行中の場合にその状態が表示されます たとえば RESCUE の処理中の場合 "RESCUING " と表示されます

44 list Status が ACTIVE であるインスタンスの情報をファイルに出力し インスタンスの状態と統計情報を表示します 使用例 インスタンス一括起動 # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh -l start <RETURN> Starting インスタンス名 ( インスタンス ID) Starting インスタンス名 ( インスタンス ID) ERROR: Failed to start インスタンス名 ( インスタンス ID) Starting インスタンス名 ( インスタンス ID) FJSVpf4c:ERROR:61205 Cannot start インスタンス名 ( インスタンス ID), because Status is PAUSED OK:3 NG:2 Start command is finished. インスタンス一括停止 # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh stop <RETURN> Stopping インスタンス名 ( インスタンス ID) Stopping インスタンス名 ( インスタンス ID) FJSVpf4c:ERROR:61204 Failed to stop インスタンス名 ( インスタンス ID) Stopping インスタンス名 ( インスタンス ID) OK:3 NG:1 Stop command is finished. インスタンス状態確認 # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh status <RETURN> Total: 4 ACTIVE: 1 SHUTOFF: 1 RESIZE: 1 VERIFY_RESIZE: ID Name Status Task State ef926-9f89-461c-be8f-dbf c test1 RESIZE c1a0-5ca4-40d8-b5c6-1c592c714d02 test2 VERIFY_RESIZE - 091fd7e8-4cc5-48b9-a8a9-b326f1e22c56 test3 ACTIVE - b429046e-c8ef-4d99-aa89-d cd test4 SHUTOFF Status command is finished. インスタンス状態出力 # /opt/fjsvpf4c/bin/rcx_all_instance_ctl.sh list <RETURN> Total: 4 ACTIVE: 1 SHUTOFF: 1 RESIZE: 1 VERIFY_RESIZE: ID Name Status Task State ef926-9f89-461c-be8f-dbf c test1 RESIZE c1a0-5ca4-40d8-b5c6-1c592c714d0 test2 VERIFY_RESIZE List command is finished

45 注意 以下のどちらかの条件を満たす場合 バックアップを実施した業務サーバ ( 利用者 VM) が ACTIVE にならないことがあります 業務サーバ ( 利用者 VM) に接続されているストレージ種別がエフェメラルディスク (Ephemeral Disk) の場合 業務サーバ ( 利用者 VM) に対して以下の操作を実施した場合 - delete - migrate - evacuate - resize 業務サーバ ( 利用者 VM) の状態が ACTIVE にならない場合 業務サーバ ( 利用者 VM) を削除してください そのあと業務サーバ ( 利用者 VM) を再作成し データをリストアしてください 必要な権限 実行環境権限 OSのroot 権限前提条件以下のコマンドを実行してください #. /root/openrc <RETURN> 実行環境管理サーバ ( コントローラー VM2) 終了ステータス以下の終了ステータスが返されます 0 正常に処理されました 0 以外起動 / 停止に失敗したインスタンスが存在します cssnap 名前 /opt/fjsvcsoss/bin/cssnap 形式 cssnap [-t 出力先ディレクトリ ] 定義ファイル番号 機能説明 cssnap は本製品の調査資料を採取するためのコマンドです

46 調査資料の格納場所 -t 出力先ディレクトリを指定しない場合 /var/opt/fjsvcsoss/snap/ -t 出力先ディレクトリを指定する場合出力先ディレクトリ /FJSVcsoss/snap/ 調査資料名 cssnapオプション-ホスト名 -yyyymmddhhmmss.tgz yyyymmddhhmmssは コマンドを実行した日時を示します 調査資料一時出力先の格納場所 -t 出力先ディレクトリを指定しない場合 /var/opt/fjsvcsoss/tmp/ 調査資料採取を実行するホスト名 / -t 出力先ディレクトリを指定する場合出力先ディレクトリ /FJSVcsoss/tmp/ 調査資料採取を実行するホスト名 / サブコマンド ありません オプション -t 出力先ディレクトリ - 出力先ディレクトリを変更する場合に指定します - 出力先ディレクトリは 絶対パスまたは相対パスで指定できます - 絶対パスまたは相対パスを含む出力先ディレクトリ名は 3570 文字以下の文字列を指定します - 出力先ディレクトリ名は 以下で構成された 1~255 文字以内の文字列を指定できます - 先頭に指定できる文字 - 半角英数字 - アンダースコア ("_") - ピリオド (".") - 先頭以外に指定できる文字 - 半角英数字 - アンダースコア ("_") - ピリオド (".") - ハイフン ("-") - 出力先ディレクトリのディレクトリ名の部分と同じ名前のファイルが存在する場合には エラーメッセージを出力してコマンドの実行を中止します 定義ファイル番号 0 の場合 初期調査資料を採取する場合に指定します 1 の場合 詳細調査資料を採取する場合に指定します

47 参考 調査資料の採取に必要なディスク容量の目安については トラブル発生時の対処の流れ を参照してください 注意 定義ファイル番号は 省略できません 調査資料採取コマンドを実行中に再度実行しようとした場合 2 回目の実行はエラーメッセージを出力して中止します 調査資料採取コマンド実行中にエラーが発生した場合 その時点でのエラーメッセージが出力されます 調査資料採取コマンド実行時 調査資料の出力先ディレクトリおよび一時出力先ディレクトリが存在することを確認します 存在しない場合は作成されます 調査資料採取コマンド実行時 一時出力先ディレクトリ内にファイルまたはディレクトリが存在する場合には 調査資料採取前にすべて削除されます 必要な権限 実行環境権限 OSのroot 権限実行環境 - 管理サーバ ( コントローラー VM1) - 管理サーバ ( コントローラー VM2) - 管理サーバ (Cinderノード) - 管理サーバ ( ネットワークノード ) - 業務サーバ ( コンピュートノード ) 終了ステータス以下の終了ステータスが返されます 0 正常に処理されました 1 エラーが発生しました rcx_service 名前 /opt/fjsvpf4c/bin/rcx_service

48 形式 rcx_service start rcx_service stop rcx_service status 機能説明 rcx_serviceは 以下のサーバのサービスを一括で起動 停止するためのコマンドです 管理サーバ ( コントローラー VM1) 管理サーバ ( コントローラー VM2) 管理サーバ (Cinderノード) 管理サーバ ( ネットワークノード ) 業務サーバ ( コンピュートノード ) サブコマンド start 対象のサーバ上で サーバごとにサービスを一括して起動する場合に指定します stop 対象のサーバ上で サーバごとにサービスを一括して停止する場合に指定します status 対象のサーバ上で サーバごとにサービスの状態を確認する場合に指定します オプション ありません 必要な権限 実行環境権限 OSのroot 権限実行環境 - 管理サーバ ( コントローラー VM1) - 管理サーバ ( コントローラー VM2) - 管理サーバ (Cinderノード) - 管理サーバ ( ネットワークノード ) - 業務サーバ ( コンピュートノード ) 終了ステータス以下の終了ステータスが返されます 0 startサブコマンド stopサブコマンドの場合正常に処理されました

49 statusサブコマンドの場合サービスが起動しています 0 以外以下のどれかの場合に返されます - 指定したパラメーターに誤りがあった場合 - startサブコマンドを指定し 少なくとも1つのサービスの起動に失敗した場合 - stopサブコマンドを指定し 少なくとも1つのサービスの停止に失敗した場合 - statusサブコマンドを指定し 少なくとも1つのサービスが停止している場合 使用例 業務サーバ ( コンピュートノード ) のサービスの起動に成功した場合 # /opt/fjsvpf4c/bin/rcx_service start <RETURN> Starting libvirtd: [ OK ] Starting neutron-openvswitch-agent: [ OK ] Starting openstack-ceilometer-compute: [ OK ] Starting openstack-nova-compute: [ OK ] Starting libvirt-guests: [ OK ] Successfully started all services. 業務サーバ ( コンピュートノード ) のサービスの停止に成功した場合 # /opt/fjsvpf4c/bin/rcx_service stop <RETURN> Stopping libvirt-guests: [ OK ] Stopping neutron-openvswitch-agent: [ OK ] Stopping openstack-ceilometer-compute: [ OK ] Stopping openstack-nova-compute: [ OK ] Stopping libvirtd: [ OK ] Successfully stopped all services. 業務サーバ ( コンピュートノード ) のサービス起動後の状態を確認する場合 # /opt/fjsvpf4c/bin/rcx_service status <RETURN> libvirtd is running. neutron-openvswitch-agent is running. openstack-ceilometer-compute is running. openstack-nova-compute is running. libvirt-guests is running. 業務サーバ ( コンピュートノード ) のサービス停止後の状態を確認する場合 # /opt/fjsvpf4c/bin/rcx_service status <RETURN> libvirtd is stopped. neutron-openvswitch-agent is stopped. openstack-ceilometer-compute is stopped. openstack-nova-compute is stopped. libvirt-guests is stopped ceilometer 名前 /usr/bin/ceilometer

50 形式 ceilometer [--timeout TIMEOUT] statistics [-q QUERY] -m NAME [-p PERIOD] [-g FIELD] 機能説明統計情報を表示します ceilometerコマンドの詳細は OpenStackのドキュメントを参照してください サブコマンド statistics メータリングの統計情報を表示します オプション --timeout TIMEOUT タイムアウト時間を秒数で指定します 省略した場合のデフォルト値は10 分 (600 秒 ) です "ceilometer" と "statistics" の間に指定してください "statistics" のあとに記述するとエラーになります -q QUERY 取得内容を指定できます QUERY 全体をシングルクォーテーション (') で囲んでください 条件を複数指定する場合はセミコロン (";") で区切ります - 期間を指定する場合期間は不等号 (">","<") を使って範囲指定できます 日時はISO8601 拡張形式で入力してください - プロジェクトを指定する場合 project_id= プロジェクトIDと指定してください - リソースを指定する場合 resource_id= リソースIDと指定してください -m NAME 計測項目を指定します 必須項目です 計測項目は以下から指定してください 他の計測項目の詳細は OpenStackのドキュメントを参照してください instance memory memory.usage cpu 計測項目 説明インスタンスの有無インスタンスに割り当てられたメモリインスタンスのメモリ使用量 CPU 使用時間

51 計測項目 cpu_util disk.read.requests disk.write.requests disk.read.bytes disk.write.bytes network.incoming.bytes network.outgoing.bytes network.incoming.packets network.outgoing.packets instance:m1.tiny instance:m1.small instance:m1.medium instance:m1.large image image.size storage.objects storage.objects.size storage.objects.containers 説明 CPU 平均使用量 readリクエスト数 writeリクエスト数 readサイズ writeサイズ受信バイト量送信バイト量受信パケット量送信パケット量インスタンスm1の有無 (tiny) インスタンスm1の有無 (small) インスタンスm1の有無 (medium) インスタンスm1の有無 (large) イメージの有無アップロードしたイメージのサイズオブジェクト数保存されたオブジェクトの合計サイズコンテナの数 -p PERIOD 統計情報を取得する測定時間 ( 秒 ) を指定します Horizon 画面と同様に10 分ごとの結果を取得するためには600を指定してください -g FIELD グルーピングするフィールドを指定します プロジェクトごとの結果を取得する場合はproject_idを指定してください 使用例 測定期間を指定して統計情報を取得する場合 # ceilometer statistics -m storage.objects.size -p 600 -q 'timestamp< t12:00:00;timestamp> t12:00:00' <RETURN> Period Period Start Period End Max Min Avg Sum Count Duration Duration Start Duration End T00:40: T00:50: T00:48: T00:48: T00:50: T01:00: T00:58: T00:58: T01:00: T01:10: T01:08: T01:08: T01:10: T01:20: T01:18: T01:18: T01:20: T01:30: T01:28: T01:28:

52 T01:30: T01:40: T01:38: T01:38: T01:40: T01:50: T01:48: T01:48: T01:50: T02:00: T01:58: T01:58: T02:00: T02:10: T02:08: T02:08: 表示項目 項目名 説明 Period 統計情報を取得する測定時間 ( 秒 ) Period Start Period End Max Min Avg Sum Count 測定の開始時刻 測定の終了時刻 最大値 最小値 平均値 合計値 計測数 Duration 最新と最古のタイムスタンプの差分 ( 秒 ) Duration Start Duration End 測定結果で最も古いタイムスタンプ 測定結果で最も新しいタイムスタンプ 必要な権限 実行環境権限 OSのroot 権限実行環境管理サーバ ( コントローラー VM2) 終了ステータス以下の終了ステータスが返されます 0 正常に処理されました 1 処理に失敗しました

53 第 3 章操作 本章では Horizon の起動と終了 および Horizon の本製品固有機能について説明します 本製品の固有機能以外の Horizon の操作については OpenStack の Web サイトを参照してください 3.1 ログイン ログアウト ここでは Horizon の起動と終了について説明します 事前準備 Horizon を起動する前に準備と確認が必要な事項は 以下のとおりです Web ブラウザの標準フォントを使用し 以上の画面サイズで使用することを推奨します Web ブラウザのサイズを極端に変更すると表示が崩れる場合があります Web ブラウザのセキュリティの設定で JavaScript アクティブスクリプトおよび Cookie を使用しない設定にしている場合 Horizon が表示できない場合があります Web ブラウザが Firefox の場合は以下の確認も実施してください - [ オプション ]-[ コンテンツ ]-[ フォントと配色 ] の [ 詳細設定 ] において [Web ページが指定したフォントを優先する ] にチェックが入っているか確認してください チェックが入ってない場合 [Web ページが指定したフォントを優先する ] を選択してください - 以下の手順で https と混在時に http のコンテンツをブロックしていないか確認してください 1. アドレスバーに "about:config" と入力して Enter キーを押下します 2. " 動作保証対象外になります!" の警告が表示された場合 " 細心の注意を払って使用する " を押下します 3. 検索に "security.mixed" を入力して絞り込み 以下の項目の設定値を確認してください - security.mixed_content.block_active_content - security.mixed_content.block_display_content 4. true の部分をダブルクリックして false に切り替えてください 自己署名証明書を使用する場合 以下の注意事項があります - Web ブラウザを起動したあと 最初に接続を行う際に セキュリティ証明書に関する警告画面が表示されます 画面に " この Web サイトのセキュリティ証明書には問題があります " と表示されます これは 本製品で通信の暗号化に利用している HTTPS(SSL) のセキュリティ証明書が 自己署名証明書であることへの警告です ファイアーウォールで保護されたイントラネットなど なりすましの危険性がない 通信相手が信頼できるネットワークでは 自己署名証明書を利用しても問題ありません そのまま次に進み ログイン画面を表示してください " このサイトの閲覧を続行する ( 推奨されません ) " を選択すると ログイン画面が表示されます - セキュリティ証明書に関する警告画面や 証明書のエラーの表示を表示したくない場合 以下のどちらかに対応する証明書を作成し Web ブラウザにインストールしてください 詳細は 付録 B HTTPS 通信 を参照してください - 管理サーバ ( コントローラー VM2) のホスト名 (FQDN) - 管理サーバ ( コントローラー VM2) のサービス LAN の IP アドレス 起動 Horizonへの接続方法について説明します 事前にWebブラウザの " 信頼済みサイト " にHorizonのURLを追加してください 管理クライアントでWebブラウザを起動し HorizonのURLを指定して接続します 以下のどちらかを指定します

54 管理サーバ ( コントローラー VM2) のホスト名 (FQDN) URL: 管理サーバ ( コントローラー VM2) のFQDN/ 管理サーバ ( コントローラー VM2) のサービスLANのIPアドレス URL: 管理サーバ ( コントローラー VM2) のサービスLANのIPアドレス / 注意 ログイン画面が表示されない場合 以下を確認してください - URL に誤りがないか - Web ブラウザのプロキシの設定に誤りがないか - 管理サーバ ( コントローラー VM2) のファイアーウォールの設定に誤りがないか 複数の Web ブラウザですでにログインしている場合 ログイン画面を表示せずに自動的にログインが行われることがあります Horizon へのアクセスに使用する FQDN IP アドレスは 事前に Horizon の設定でアクセス許可を実施してください 詳細は Horizon の設定 を参照してください ログイン 起動後 表示されたログイン画面で以下の項目を入力し [ ログイン ] ボタンをクリックします ログインに成功すると Horizon が表示されます ユーザー名 パスワード ただし Web ブラウザの画面で メニューから [ ファイル (F)]-[ 新規ウィンドウ (N)] を選択するなどして複数の Web ブラウザを起動した際 異なるユーザーでログインできない場合があります [ ファイル (F)]-[ 新規セッション (I)] を選択して別の Web ブラウザを起動してください ログアウト ログアウトする場合 グローバルヘッダーの " ログアウト " をクリックします 注意 複数の Web ブラウザで動作している Horizon が存在する場合 それらのログインセッションも切断されることがあります 終了 Web ブラウザを閉じて Horizon を終了します Horizon の設定 ここでは Horizon へのアクセスに使用する FQDN IP アドレスのアクセス許可の設定方法を説明します 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします

55 2. 以下のファイルを編集します Horizonへのアクセスに使用するFQDNまたはIPアドレスをリスト形式で指定します 設定ファイル /etc/openstack-dashboard/local_settings 編集内容 ALLOWED_HOSTS = [' 既存の設定 1',...,' 既存の設定 N', ' 追加の設定 1',..., ' 追加の設定 N'] 3. サービスを再起動します # systemctl restart httpd.service memcached.service <RETURN> 3.2 Horizon の追加機能 ここでは Horizonの本製品固有機能について説明します 本製品では Horizonに以下のメニューを追加しています アドバンスト他製品の管理ソフトウェアにアクセスするための本製品固有のメニューです 3.3 管理ソフトウェアの一覧表示 ここでは 管理ソフトウェアの一覧について説明します ダッシュボードのメニューから [ アドバンスト ]-[ 管理ソフトウェア ] を選択します [ 管理ソフトウェア ] パネルが表示されます 図 3.1 管理ソフトウェア一覧 画面説明 [ 管理ソフトウェアの登録 ] ボタン管理者ロール (admin) だけ表示されます 詳細は 3.4 管理ソフトウェアの登録 を参照してください [ 管理ソフトウェアの削除 ] ボタン管理者ロール (admin) だけ表示されます 詳細は 3.6 管理ソフトウェアの削除 を参照してください

56 管理ソフトウェアの一覧ログインしたユーザーのロールが指定された管理ソフトウェアが一覧で表示されます ただし 管理者ロール (admin) の場合 すべての管理ソフトウェアが表示されます 以下の情報が表示されます ロールとアクション以外の詳細は 3.4 管理ソフトウェアの登録 を参照してください - 名前 - 説明 - URL - ロール管理者ロール (admin) だけ表示されます 管理ソフトウェアに設定されたロールが表示されます 設定されたロールが存在しない場合 ハイフン ("-") が表示されます - アクション管理者ロール (admin) だけ表示されます ドロップダウンメニューの選択肢は以下のとおりです デフォルトは [ 管理ソフトウェアの編集 ] が表示されます - [ 管理ソフトウェアの編集 ] - [ 管理ソフトウェアの削除 ] 3.4 管理ソフトウェアの登録 ここでは 管理ソフトウェアの登録について説明します 管理ソフトウェアの登録は 管理者ロール (admin) だけが利用できます 操作手順 1. [ 管理ソフトウェアの登録 ] ボタンをクリックします 2. 以下の項目を設定して 管理ソフトウェアを登録します 名前管理ソフトウェアの名前を入力します 全半角文字に関係なく255 文字以内の文字列を入力します 説明 ( 省略可 ) 必要に応じて 登録する管理ソフトウェアの説明文を入力します URL 登録する管理ソフトウェアに対してアクセスするURLを入力します ロール登録する管理ソフトウェアにアクセスできるロールを選択します デフォルトは _member_ ロールが選択されます 3. [ 管理ソフトウェアの登録 ] ボタンをクリックします 管理ソフトウェアが登録できます

57 確認手順 管理ソフトウェアの登録を確認するためには 管理ソフトウェアの一覧を表示して確認します 詳細は 3.3 管理ソフトウェアの一覧表示 を参照してください 3.5 管理ソフトウェアの編集 ここでは 管理ソフトウェアの編集について説明します 管理ソフトウェアの編集は 管理者ロール (admin) だけ利用できます 操作手順 1. 変更する管理ソフトウェアの [ アクション ] 欄で [ 管理ソフトウェアの編集 ] ボタンをクリックします 2. 管理ソフトウェアを編集します 編集する項目は 3.4 管理ソフトウェアの登録 を参照してください 3. [ 管理ソフトウェアの編集 ] ボタンをクリックします 管理ソフトウェアの編集が完了します 確認手順 管理ソフトウェアの編集を確認するためには 管理ソフトウェアの一覧を表示して確認します 詳細は 3.3 管理ソフトウェアの一覧表示 を参照してください 3.6 管理ソフトウェアの削除 ここでは 管理ソフトウェアの削除について説明します 管理ソフトウェアの削除は 管理者ロール (admin) だけ利用できます 管理ソフトウェアを1つだけ削除する場合 1. 削除する管理ソフトウェアの [ アクション ] 欄で [ 管理ソフトウェアの削除 ] を選択します [ 管理ソフトウェアの削除の確認 ] ダイアログが表示されます 2. 削除する管理ソフトウェアを確認します 3. [ 管理ソフトウェアの削除 ] ボタンをクリックします 管理ソフトウェアが削除されます 複数の管理ソフトウェアを削除する場合 1. [ 管理ソフトウェア一覧 ] の表の先頭のチェックボックスで 削除する管理ソフトウェアを選択します 2. 表の右上方の [ 管理ソフトウェアの削除 ] ボタンをクリックします [ 管理ソフトウェアの削除の確認 ] ダイアログが表示されます 3. 削除する管理ソフトウェアを確認します 4. [ 管理ソフトウェアの削除 ] ボタンをクリックします 管理ソフトウェアが削除されます

58 確認手順 管理ソフトウェアの削除を確認するためには 管理ソフトウェアの一覧を表示して確認します 詳細は 3.3 管理ソフトウェアの一覧表示 を参照してください

59 第 4 章保守 本章では 本製品利用時の保守について説明します 定期保守本製品の修正適用などにより ソフトウェアの保守が必要な場合 4.1 定期保守 を参照してください トラブル対処本製品利用時にトラブル対処が必要な場合 4.2 トラブル発生時の対処 および 4.3 トラブルシューティング を参照してください 4.1 定期保守 ここでは 本製品の定期保守について説明します クラスタ構成における業務サーバ ( コンピュートノード ) の定期保守 HA 構成 ここでは クラスタ構成における業務サーバ ( コンピュートノード ) の定期保守について説明します 概要 業務サーバ( 利用者 VM) の可用性向上 HA 構成 を参照してください 定期保守の流れ ソフトウェアの修正適用などにより 業務サーバ ( コンピュートノード ) の保守が必要となった場合 業務サーバ ( コンピュートノード ) のうえで動作している業務サーバ ( 利用者 VM) を別の業務サーバ ( コンピュートノード ) で動作させることができます 業務サーバ ( コンピュートノード ) の定期保守は 以下の流れで実施します 1. 業務サーバ ( コンピュートノード ) の切離し 保守対象のノードを一時的にクラスタ環境の監視対象から切り離し 保守を実施します 2. 業務サーバ ( コンピュートノード ) の組込み 保守のために一時的にクラスタ環境の監視対象から切り離したノードをクラスタ環境に組込みます 構成例 本節で説明するノードの名称を説明します

60 図 4.1 ノードの名称 稼動ノードクラスタ構成の中で インスタンスが動作する業務サーバ ( コンピュートノード ) のことです 待機ノード業務予備サーバ ( コンピュートノード ) のことです 業務サーバ ( コンピュートノード ) に異常が発生した際 異常が発生したノード上のインスタンスが待機ノードに移動されます メンテナンスノード保守対象の業務サーバ ( コンピュートノード ) のことです 稼動ノードと待機ノードが含まれます 移行先稼動ノードメンテナンスノードが稼動ノードの場合に メンテナンスノード上で動作するインスタンスの移行先の稼動ノードのことです 業務サーバ ( コンピュートノード ) の切離し ここでは 業務サーバ ( コンピュートノード ) をクラスタ環境の監視対象から切り離す手順について説明します メンテナンスノードが稼動ノードと待機ノードで手順が異なります メンテナンスノードが稼動ノードの場合 メンテナンスノードが稼動ノードの場合の切離し を参照してください メンテナンスノードが待機ノードの場合 メンテナンスノードが待機ノードの場合の切離し を参照してください メンテナンスノードが稼動ノードの場合の切離し ここでは メンテナンスノードが稼動ノードの場合の切離しについて説明します 業務サーバ ( コンピュートノード ) のノード名が以下の場合の例を示します

61 稼動ノード compute2 compute3 メンテナンスノード compute1 待機ノード compute4 図 4.2 メンテナンスノードが稼動ノードの場合の切離し例 本製品の設定 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. メンテナンスノード上に存在するインスタンスの ID を確認します コマンドの実行結果の赤文字 かつ下線部がメンテナンスノード上に存在するインスタンスの ID を示しています #. /root/openrc <RETURN> # nova list --all-tenant --field "host,status" <RETURN> ID Host Status a3038c12-fa9c-495d c3b0ddc019b compute1 ACTIVE dcdb4fd4-643c-4ba6-a54c-e5aa4c compute1 SHUTOFF c-4aa3-bf55-23a24351ad2a compute2 ACTIVE 4fdc0061-db68-4ab6-bb13-64d07e2b4f68 compute2 ACTIVE f-0acb-4163-a4cb-98a2df8a268f compute2 ACTIVE 64f2c3af-1bc e7f-c42afccdf851 compute2 ACTIVE e03794e7-707f-4118-b6c2-6d96ae32f3c3 compute2 ACTIVE f366d83e-7c8b-4bcf-80e cac84 compute2 ACTIVE インスタンスを移動します メンテナンスノード上のすべてのインスタンスを移行先稼動ノードに移動します

62 インスタンスの状態が "ACTIVE" の場合 # nova live-migration a3038c12-fa9c-495d c3b0ddc019b compute3 <RETURN> インスタンスの状態が "SHUTOFF" の場合以下の手順で移動します a. インスタンスを起動します 以下のコマンドを実行後 インスタンスのステータスが "ACTIVE" になることを確認してください # nova start dcdb4fd4-643c-4ba6-a54c-e5aa4c <RETURN> b. インスタンスを移動します 以下のコマンドを実行後 インスタンスのステータスが "ACTIVE" になることを確認してください # nova live-migration dcdb4fd4-643c-4ba6-a54c-e5aa4c compute3 <RETURN> c. 以下のコマンドを実行し インスタンスを停止します 以下のコマンド実行後 インスタンスのステータスが "SHUTOFF" になることを確認してください # nova stop dcdb4fd4-643c-4ba6-a54c-e5aa4c <RETURN> 注意 メンテナンスノード上のインスタンスで インスタンスに接続されているストレージ種別がエフェメラルディスク (Ephemeral Disk) の場合 移行先稼動ノードに移動できません そのため 保守中において当インスタンスは使用できなくなります 4. インスタンスの移動を確認します 以下のコマンドを実行し 移行先稼動ノードに変更されることを確認します コマンドの実行結果の赤文字 かつ下線部が移行先稼動ノードを示しています # nova list --all-tenant --field "host,status" <RETURN> ID Host Status a3038c12-fa9c-495d c3b0ddc019b compute3 ACTIVE dcdb4fd4-643c-4ba6-a54c-e5aa4c compute3 SHUTOFF c-4aa3-bf55-23a24351ad2a compute2 ACTIVE 4fdc0061-db68-4ab6-bb13-64d07e2b4f68 compute2 ACTIVE f-0acb-4163-a4cb-98a2df8a268f compute2 ACTIVE 64f2c3af-1bc e7f-c42afccdf851 compute2 ACTIVE e03794e7-707f-4118-b6c2-6d96ae32f3c3 compute2 ACTIVE f366d83e-7c8b-4bcf-80e cac84 compute2 ACTIVE メンテナンスノードの Nova のサービスを "disabled" に変更します # nova service-disable compute1 nova-compute <RETURN> 6. メンテナンスノードの Nova のサービスが "disabled" であることを確認します コマンドの実行結果が 赤文字 かつ下線部のように表示されることを確認します # nova service-list grep compute1 <RETURN> 6 nova-compute compute1 az1 disabled up T07:27:

63 PRIMECLUSTER のサービスの停止 1. メンテナンスノードに root 権限でログインします 2. PRIMECLUSTER のサービスを停止します # /opt/smaw/smawcf/dep/master unload <RETURN> # /etc/init.d/cf stop <RETURN> 3. PRIMECLUSTER のサービスが停止していることを確認します a. CF の停止確認 以下のコマンドを実行し State が "UNLOADED" になっていることを確認します # cftool -l <RETURN> Node Number State Os Cpu Flags Unknown -- UNLOADED b. RMS の停止確認 以下のコマンドを実行し "RMS is not running" が出力されることを確認します コマンドの実行結果が 赤文字 かつ下線部のように表示されることを確認します # hvdisp -a <RETURN> hvdisp: RMS is not running メンテナンスノードが待機ノードの場合の切離し ここでは メンテナンスノードが待機ノードの場合の切離しについて説明します 業務サーバ ( コンピュートノード ) のノード名が以下の場合の例を示します 稼動ノード compute1 compute2 compute3 メンテナンスノード かつ待機ノード compute4-57 -

64 図 4.3 メンテナンスノードが待機ノードの場合の切離し例 注意 メンテナンスノードが待機ノードの場合の組込み が終わるまでにノードを再起動した場合は 再度この手順で PRIMECLUSTER のサービスを停止してください メンテナンスノードの PRIMECLUSTER の停止 1. PRIMECLUSTER のサービスの停止 を参考にメンテナンスノードの PRIMECLUSTER を停止します 稼動ノードの PRIMECLUSTER の起動確認 1. 任意の稼動ノードに root 権限でログインします 2. leaderapp の起動確認 以下のコマンドを実行し leaderapp が稼働ノード上で起動したことを確認します leaderapp の State が "Online" になっていることを確認します 以下のコマンドの実行例はどちらも compute1 上で leaderapp が起動している場合の出力結果です - ログインした稼動ノード上で leaderapp が起動している場合 # hvdisp -a grep ^leaderapp <RETURN> leaderapp userapp Online - ログインした稼動ノード以外のノード上で leaderapp が起動している場合 # hvdisp -a grep ^leaderapp <RETURN> leaderapp userapp Offline leaderapp compute1rms Online 業務サーバ ( コンピュートノード ) の組込み ここでは 定期保守のためにクラスタ環境の監視対象から切離したメンテナンスノードを 再度クラスタ環境に組み込む手順を説明します

65 メンテナンスノードが稼動ノードと待機ノードで手順が異なります メンテナンスノードが稼動ノードの場合の組込み メンテナンスノードが稼動ノードの場合の組込み を参照してください メンテナンスノードが待機ノードの場合の組込み メンテナンスノードが待機ノードの場合の組込み を参照してください メンテナンスノードが稼動ノードの場合の組込み ここでは メンテナンスノードが稼動ノードの場合の組込みについて説明します 業務サーバ ( コンピュートノード ) のノード名が以下の場合の例を示します 稼動ノード compute2 compute3 メンテナンスノード compute1 待機ノード compute4 図 4.4 メンテナンスノードが稼動ノードの場合の組込み例 インスタンスの切り戻し 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. メンテナンスノードの Nova のサービスを "enabled" に変更します #. /root/openrc <RETURN> # nova service-enable compute1 nova-compute <RETURN>

66 3. メンテナンスノードの Nova のサービスが "enabled" であることを確認します コマンドの実行結果が 赤文字 かつ下線部のように表示されることを確認します # nova service-list grep compute1 <RETURN> 6 nova-compute compute1 az1 enabled up T07:27: 必要に応じてインスタンスを切り戻します インスタンスの状態が "ACTIVE" の場合 a. インスタンスを移動します # nova live-migration 切り戻すインスタンスの ID compute1 <RETURN> インスタンスの状態が "SHUTOFF" の場合 a. インスタンスを起動します 以下のコマンドを実行後 インスタンスの状態が "ACTIVE" になることを確認してください # nova start 切り戻すインスタンスの ID <RETURN> b. インスタンスを移動します 以下のコマンドを実行後 インスタンスのステータスが "ACTIVE" になることを確認してください # nova live-migration 切り戻すインスタンスの ID compute1 <RETURN> c. インスタンスを停止します 以下のコマンドを実行後 インスタンスの状態が "SHUTOFF" になることを確認してください # nova stop 切り戻すインスタンスの ID <RETURN> 5. インスタンスが切り戻し対象のホストに移行したことを確認します コマンドの実行結果の赤文字 かつ下線部にメンテナンスノードが表示されることを確認します # nova show 切り戻したインスタンスの ID grep OS-EXT-SRV-ATTR:host <RETURN> OS-EXT-SRV-ATTR:host compute1 PRIMECLUSTER のサービスの起動 1. メンテナンスノードに root 権限でログインします 2. PRIMECLUSTER のサービスを起動します # /etc/init.d/cf start <RETURN> # /opt/smaw/smawcf/dep/master load <RETURN> 3. PRIMECLUSTER のサービスが起動していることを確認します a. CF の起動確認 以下のコマンドを実行し すべての業務サーバ ( コンピュートノード ) の State が "UP" であることを確認します # cftool -n <RETURN> Node Number State Os Cpu

67 compute1 1 UP Linux EM64T compute2 2 UP Linux EM64T compute3 3 UP Linux EM64T compute4 4 UP Linux EM64T b. RMS の起動確認 以下のコマンドを実行し すべての SysNode の State が "Online" であることを確認します コマンドの実行結果が 赤文字 かつ下線部のように表示されることを確認します # hvdisp -T SysNode <RETURN> Local System: compute1rms Configuration: /opt/smaw/smawrrms/build/openstack.us Resource Type HostName State StateDetails compute4rms SysNode Online compute3rms SysNode Online compute2rms SysNode Online compute1rms SysNode Online メンテナンスノードが待機ノードの場合の組込み ここでは メンテナンスノードが待機ノードの場合の組込みについて説明します 業務サーバ ( コンピュートノード ) のノード名が以下の場合の例を示します 稼動ノード compute1 compute2 compute3 メンテナンスノード かつ待機ノード compute4 図 4.5 メンテナンスノードが待機ノードの場合の組込み例 待機ノードの設定変更 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします

68 2. 待機ノードの Nova のサービスを "disabled" に設定します #. /root/openrc <RETURN> # nova service-disable --reason "rcx_ha_spare" compute4 nova-compute <RETURN> 3. 待機ノードの Nova のサービスが "disabled" であることを確認します コマンドの実行結果が 赤文字 かつ下線部のように表示されることを確認します # nova service-list grep compute4 <RETURN> 6 nova-compute compute4 az1 disabled up T07:27: rcx_ha_spare PRIMECLUSTER の起動 1. 待機ノードに root 権限でログインします 2. PRIMECLUSTER のサービスを起動します # /etc/init.d/cf start <RETURN> # /opt/smaw/smawcf/dep/master load <RETURN> 3. PRIMECLUSTER のサービスが起動していることを確認します a. CF の起動確認 以下のコマンドを実行し すべての業務サーバ ( コンピュートノード ) の State が "UP" であることを確認します # cftool -n <RETURN> Node Number State Os Cpu compute1 1 UP Linux EM64T compute2 2 UP Linux EM64T compute3 3 UP Linux EM64T compute4 4 UP Linux EM64T b. RMS の起動確認 以下のコマンドを実行し すべての SysNode の State が "Online" であることを確認します コマンドの実行結果が 赤文字 かつ下線部のように表示されることを確認します # hvdisp -T SysNode <RETURN> Local System: compute1rms Configuration: /opt/smaw/smawrrms/build/openstack.us Resource Type HostName State StateDetails compute4rms SysNode Online compute3rms SysNode Online compute2rms SysNode Online compute1rms SysNode Online 4. leaderapp の起動 以下のコマンドを実行し 待機ノードで leaderapp を起動します # hvswitch leaderapp compute4rms <RETURN>

69 5. 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 4.2 トラブル発生時の対処 ここでは トラブル発生時の対処方法について説明します 本製品では トラブルに対して原因を追及するために 調査資料を採取することを推奨しています トラブル発生直後の調査資料を採取することにより トラブルに対して 調査および原因追及ができます トラブル発生時の対処の流れ ここでは トラブル発生時の対処の流れについて説明します トラブルが発生してからの手順は 以下のとおりです サーバの採取順番はありません 1. OSの管理者権限で各サーバにログインします 調査資料を採取する場合 OSの管理者権限が必要です 2. 初期調査資料を採取します コマンドの詳細は cssnap を参照してください # /opt/fjsvcsoss/bin/cssnap 0 <RETURN> 3. 手順 2. で採取した調査資料を当社技術員に送付し 調査を依頼してください 当社技術員に調査依頼後 詳細な調査資料の採取を依頼された場合 以下の手順で調査資料を採取します サーバの採取順番はありません 1. OS の管理者権限で当社技術員から指定されたサーバにログインします 調査資料を採取する場合 OS の管理者権限が必要です 2. 詳細調査資料を採取します コマンドの詳細は cssnap を参照してください # /opt/fjsvcsoss/bin/cssnap 1 <RETURN>

70 3. 手順 2. で採取した調査資料を当社技術員に送付し 調査を依頼してください ポイント 調査資料の採取に必要なディスク容量の目安 調査資料の採取に必要なディスク容量の目安は 7G バイト (5G バイトの一時出力ファイルと 2G バイトの調査資料 ) 程度です システム構成や設定に応じて より多くのディスク容量が必要です したがって資料格納先のディスクは 出力先ディレクトリを指定して十分な容量を確保してください 注意 問題が発生した場合 すみやかに調査資料を採取してください 時間の経過と共に 調査に必要な情報が失われてしまう可能性があります 管理サーバ ( ネットワークノード ) の復旧 ここでは 管理サーバ ( ネットワークノード ) の復旧について説明します 概要 管理サーバ( ネットワークノード ) の冗長化 を参照してください 手順 管理サーバ ( ネットワークノード ) の復旧手順は 以下のとおりです 管理サーバ ( ネットワークノード ) が停止している場合 電源を投入して管理サーバ ( ネットワークノード ) を起動します 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. 管理者権限の環境変数を設定します #. /root/openrc <RETURN> 3. 復旧した管理サーバ ( ネットワークノード ) の以下の項目の agent ID を確認します 赤字かつ下線が agent ID です L3 agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/l3_agent/excluded_list_l3_agent.py <RETURN> Excluded L3 agent list id host 6ed9e b-41ea ffe01b7061 network-2 DHCP agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/dhcp_agent/excluded_list_dhcp_agent.py <RETURN> Excluded DHCP agent list

71 id f09ecec3-f782-4f80-8d9b-dbef5619d294 host network-2 Loadbalancer agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/lbaas_agent/excluded_list_lbaas_agent.py <RETURN> Excluded LBaaS agent list id host d628fdd9-43b0-470d-a1d4-bf8de26cf47d network-2 4. neutron agent-list を実行し 復旧した管理サーバ ( ネットワークノード ) の各 agent の alive 欄が ":-)" になっていることを確認します # neutron agent-list <RETURN> id agent_type host alive admin_state_up f09ecec3-f782-4f80-8d9b-dbef5619d294 DHCP agent network-2 :-) True d75c986b-9e6b-45e6-87e8-224e22f4ee54 Metadata agent network-2 :-) True a dbb-4ff f1b46e5f286 Open vswitch agent compute :-) True bb a1-8cd7-ac e L3 agent network-1 :-) True 1d20c95b-d b5c7-bd4777f898d3 Metering agent network-2 :-) True a27d5f89-1eae-4e86-b1bc-afbf69112ebd DHCP agent network-1 :-) True b03f43ef-44fa-415e-8cc8-fe64b20d9cd7 Loadbalancer agent network-1 :-) True 846f2609-bfbb-43fd-bf39-e9b7f726581b Open vswitch agent network-1 :-) True 04420a66-891d-41fd d48ccd5b Metadata agent network-1 :-) True 6ed9e b-41ea ffe01b7061 L3 agent network-2 :-) True 27b d5f-426c-b b7a2d5a3 Metering agent network-1 :-) True d628fdd9-43b0-470d-a1d4-bf8de26cf47d Loadbalancer agent network-2 :-) True bb0c6839-bc12-4c9d-a3bf-f2cc Open vswitch agent network-2 :-) True 各 agent の監視対象外の情報をクリアします 復旧する管理サーバ ( ネットワークノード ) が複数ある場合 管理サーバ ( ネットワークノード ) 数だけ繰り返し実行してください L3 agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/l3_agent/restore_l3_agent.py l3_agent_id <RETURN> 例 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/l3_agent/restore_l3_agent.py 6ed9e b-41ea ffe01b7061 <RETURN> Please use the following neutron commands if you move the v-router. neutron l3-agent-router-remove l3_agent_id router_id neutron l3-agent-router-add l3_agent_id router_id DHCP agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/dhcp_agent/restore_dhcp_agent.py dhcp_agent_id <RETURN> 例 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/dhcp_agent/restore_dhcp_agent.py f09ecec3- f782-4f80-8d9b-dbef5619d294 <RETURN>

72 Please use the following neutron commands if you move the network. neutron dhcp-agent-network-remove dhcp_agent_id network_id neutron dhcp-agent-network-add dhcp_agent_id network_id Loadbalancer agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/lbaas_agent/restore_lbaas_agent.py lbaas_agent_id <RETURN> 例 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/lbaas_agent/restore_lbaas_agent.py d628fdd9-43b0-470d-a1d4-bf8de26cf47d <RETURN> Please use the following neutron Api if you move the loadbalancer-pool. DELETE /v2.0/agents/[uuid of Agent]/loadbalancer-pools/[UUID] POST /v2.0/agents/[uuid of Agent]/loadbalancer-pools 6. 以下のコマンドを実行し "Excluded Agent does not exist." のメッセージが出力され 各 agent が監視対象になったことを確認します L3 agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/l3_agent/excluded_list_l3_agent.py <RETURN> Excluded Agent does not exist. DHCP agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/dhcp_agent/excluded_list_dhcp_agent.py <RETURN> Excluded Agent does not exist. Loadbalancer agent の場合 # python /usr/lib/python2.7/site-packages/tools/monitor_network_agent/lbaas_agent/excluded_list_lbaas_agent.py <RETURN> Excluded Agent does not exist. 管理サーバ ( ネットワークノード ) で異常が発生した場合 管理サーバ ( ネットワークノード ) で異常が発生した場合 ネットワーク関連のリソース ( 仮想ルータ ネットワーク ロードバランサ用プール ) が正常な管理サーバ ( ネットワークノード ) に移動した状態となっています 管理サーバ ( ネットワークノード ) を復旧後は 新たに作成されるリソースはリソース量の少ない管理サーバ ( ネットワークノード ) へ優先的に作成されるため 負荷は次第に平準化されます 管理サーバ ( ネットワークノード ) の復旧直後に負荷を平準化させたい場合は リソースの一部を復旧した管理サーバ ( ネットワークノード ) に移動させます 以降の手順の実行は 通信が一時的に遮断されるため 業務影響のない時間に行ってください なお 以下のケースではネットワークリソースが移動されていないため 以降の手順は不要です 管理サーバ ( ネットワークノード ) の電源が切断されていなかった場合 管理サーバ ( コントローラー VM2) との通信異常などにより すべての管理サーバ ( ネットワークノード ) が同時に異常と認識された場合 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします

73 2. 正常な管理サーバ ( ネットワークノード )( 移動元 ) と復旧した管理サーバ ( ネットワークノード )( 移動先 ) の agent ID をそれぞれ確認します 以下のコマンドを実行し agent_type が以下の項目の agent ID を確認します コマンド # neutron agent-list <RETURN> agent type - "L3 agent" - "DHCP agent" - "Loadbalancer agent" 例 赤字かつ下線が確認する agent ID です # neutron agent-list <RETURN> id agent_type host alive admin_state_up f09ecec3-f782-4f80-8d9b-dbef5619d294 DHCP agent network-2 :-) True d75c986b-9e6b-45e6-87e8-224e22f4ee54 Metadata agent network-2 :-) True a dbb-4ff f1b46e5f286 Open vswitch agent compute :-) True bb a1-8cd7-ac e L3 agent network-1 :-) True 1d20c95b-d b5c7-bd4777f898d3 Metering agent network-2 :-) True a27d5f89-1eae-4e86-b1bc-afbf69112ebd DHCP agent network-1 :-) True b03f43ef-44fa-415e-8cc8-fe64b20d9cd7 Loadbalancer agent network-1 :-) True 846f2609-bfbb-43fd-bf39-e9b7f726581b Open vswitch agent network-1 :-) True 04420a66-891d-41fd d48ccd5b Metadata agent network-1 :-) True 6ed9e b-41ea ffe01b7061 L3 agent network-2 :-) True 27b d5f-426c-b b7a2d5a3 Metering agent network-1 :-) True d628fdd9-43b0-470d-a1d4-bf8de26cf47d Loadbalancer agent network-2 :-) True bb0c6839-bc12-4c9d-a3bf-f2cc Open vswitch agent network-2 :-) True 移動元 L3 agent が管理している仮想ルータ一覧を表示し 仮想ルータの ID を確認します # neutron router-list-on-l3-agent -c id -c name 移動元 _l3_agent_id <RETURN> 例 赤字かつ下線が仮想ルータ ID です # neutron router-list-on-l3-agent -c id -c name bb a1-8cd7-ac e <RETURN> id name e8866c7-ce9a-47a8-9df4-3d04d288ffd9 router1 以下略 4. 仮想ルータの取り外し および取り付けを行います ポイント 移動する仮想ルータの数だけ行います

74 各ネットワークノードの仮想ルータ数が大体均等になるようにしてください a. 仮想ルータを移動元の L3 agent から取り外します # neutron l3-agent-router-remove 移動元 _l3_agent_id router_id <RETURN> 例 # neutron l3-agent-router-remove bb a1-8cd7-ac e 5e8866c7-ce9a-47a8-9df4-3d04d288ffd9 <RETURN> Removed Router 5e8866c7-ce9a-47a8-9df4-3d04d288ffd9 from L3 agent b. 仮想ルータを移動先の L3 agent に取り付けます # neutron l3-agent-router-add 移動先 _l3_agent_id router_id <RETURN> 例 # neutron l3-agent-router-add 6ed9e b-41ea ffe01b7061 5e8866c7-ce9a-47a8-9df4-3d04d288ffd9 <RETURN> Added router 5e8866c7-ce9a-47a8-9df4-3d04d288ffd9 to L3 agent 5. 移動先 L3 agentが移動させた仮想ルータを管理していることを確認します # neutron router-list-on-l3-agent -c id -c name 移動先 _l3_agent_id <RETURN> 6. 移動元 DHCP agentが管理しているネットワーク一覧を表示し ネットワークIDを確認します # neutron net-list-on-dhcp-agent -c id -c name 移動元 _dhcp_agent_id <RETURN> 例 赤字かつ下線がネットワーク ID です # neutron net-list-on-dhcp-agent -c id -c name a27d5f89-1eae-4e86-b1bc-afbf69112ebd <RETURN> id name c-a288-4a74-ad74-f c203 network1 以下略 7. ネットワークの取り外し および取り付けを行います ポイント 以下の手順を移動するネットワークの数だけ行います 各ネットワークノードのネットワーク数が大体均等になるようにしてください

75 a. ネットワークを移動元の DHCP agent から取り外します # neutron dhcp-agent-network-remove 移動元 _dhcp_agent_id network_id <RETURN> 例 # neutron dhcp-agent-network-remove a27d5f89-1eae-4e86-b1bc-afbf69112ebd c-a288-4a74-ad74-f c203 <RETURN> Removed network c-a288-4a74-ad74-f c203 from DHCP agent b. ネットワークを移動先の DHCP agent に取り付けます # neutron dhcp-agent-network-add 移動先 _dhcp_agent_id network_id <RETURN> 例 # neutron dhcp-agent-network-add f09ecec3-f782-4f80-8d9b-dbef5619d c-a288-4a74-ad74-f c203 <RETURN> Added network c-a288-4a74-ad74-f c203 to DHCP agent 8. 移動先 DHCP agentが移動させたネットワークを管理していることを確認します # neutron net-list-on-dhcp-agent -c id -c name 移動先 _dhcp_agent_id <RETURN> 9. 移動元 Loadbalancer agentが管理しているプール一覧を表示し プールのIDを確認します # neutron lb-pool-list-on-agent -c id -c name 移動元 _lbaas_agent_id <RETURN> 例 赤字かつ下線がプール ID です # neutron lb-pool-list-on-agent -c id -c name b03f43ef-44fa-415e-8cc8-fe64b20d9cd7 <RETURN> id name d6d-e6d7-4edc-ae2d-57a908fd273f lb-pool1 以下略 10. プールの取り外し および取り付けを行います ポイント 以下の手順を移動するプールの数だけ行います 各管理サーバ ( ネットワークノード ) のプール数が大体均等になるようにしてください a. プールを移動元の Loadbalancer agent から取り外します curl コマンドを実行します curl コマンド実行にあたっては 認証トークンを変数 "token" に設定します

76 DELETE /v2.0/agents/ 移動元 _lbaas_agent_id/loadbalancer-pools/pool_id 例 # token=`keystone token-get awk '{if( $2 == "id" ) print $4 }'` <RETURN> # curl -i " -H "X-Auth-Token: ${token}" -H "Content-Type: application/json" -X DELETE <RETURN> HTTP/ No Content Content-Length: 0 X-Openstack-Request-Id: req-3ac9ff6e-2a59-4d69-81b d39 Date: Tue, 08 Mar :21:40 GMT 注意 1 つ目のコマンド実行時に以下のメッセージが出力される場合がありますが 異常はありませんので 無視してください /usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient. 'python-keystoneclient.', DeprecationWarning) b. プールを移動先のLoadbalancer agentに取り付けます curlコマンドを実行します POST /v2.0/agents/ 移動先 _lbaas_agent_id/loadbalancer-pools curlコマンドに渡すjsonデータは以下のとおりです { "pool_id": "<pool id>" } 例 # curl -i " -H "X- Auth-Token: ${token}" -H "Content-Type: application/json" -X POST -d "{ \ "pool_id\": \"76373d6d-e6d7-4edc-ae2d-57a908fd273f\" }" <RETURN> HTTP/ Created Content-Type: application/json; charset=utf-8 Content-Length: 4 X-Openstack-Request-Id: req-d919aaae bf-ff35f9c3d380 Date: Tue, 08 Mar :21:40 GMT 11. 移動先 Loadbalancer agent が移動させたプールを管理していることを確認します # neutron lb-pool-list-on-agent -c id -c name 移動先 _lbaas_agent_id <RETURN> クラスタ構成の業務サーバ ( コンピュートノード ) の切替え発生時の対処 HA 構成 ここでは クラスタ構成の業務サーバ ( コンピュートノード ) において 運用時に切替えが発生した場合の対処について説明します 概要 業務サーバ ( 利用者 VM) の可用性向上 HA 構成 を参照してください

77 業務サーバ ( コンピュートノード ) のノード名の例 業務サーバ ( コンピュートノード ) のノード名が以下の場合の例を示します 図 4.6 稼動ノードが故障した場合の例 稼動ノード compute2 compute3 故障した稼動ノード compute1 待機ノード compute インスタンスの移動の確認 業務サーバ ( コンピュートノード ) に異常が発生した後で インスタンスが待機ノードに移動していることを確認します インスタンスの待機ノードへの移行確認 1. 待機ノードに root 権限でログインします 2. evacuated_list.log を確認し インスタンスが待機ノードに移動したことを確認します evacuated_list.log の詳細は ログの格納場所 を参照してください インスタンスの移動状況が "Failure" と表示されている場合 インスタンスを手動で移動します 詳細は インスタンスを手動で移動する方法 を参照してください 3. evacuated_list.log を確認し 移動したインスタンスのインスタンス ID を確認します コマンドの実行結果の赤文字 かつ下線部がインスタンス ID を示しています # cat /var/opt/fjsvpf4c/logs/evacuated_list.log <RETURN> :04:15 Success c70368a4-66f b94-f1186d231ab0 compute1 compute :04:16 Success a3038c12-fa9c-495d c3b0ddc019b compute1 compute :04:18 Success dcdb4fd4-643c-4ba6-a54c-e5aa4c compute1 compute4 4. 管理サーバ ( コントローラー VM2) に root 権限でログインします

78 5. インスタンスが正常に稼働していることを確認します インスタンス ID には 手順 3. で確認したインスタンス ID を指定します インスタンスの状態が "active" または "stopped" であることを確認します #. /root/openrc <RETURN> # nova show インスタンス ID grep vm_state <RETURN> OS-EXT-STS:vm_state インスタンスの状態 クラスタ構成の業務サーバ ( コンピュートノード ) の復旧 HA 構成 ここでは クラスタ構成の業務サーバ ( コンピュートノード ) において 運用時に異常が発生した場合の対処について説明します 復旧の流れクラスタ構成の業務サーバ ( コンピュートノード ) において 運用時に異常が発生した場合の対処の流れは 以下のとおりです 1. PRIMECLUSTERの状態確認 PRIMECLUSTERの状態確認 を参照してください 2. ストレージの復旧 ストレージの復旧 を参照してください 3. 業務サーバ ( コンピュートノード ) の復旧 - 業務サーバ ( コンピュートノード ) のハードウェア故障の場合当社技術員に連絡してください - 業務サーバ ( コンピュートノード ) の再起動後 OSが起動する場合 OS 再起動による業務サーバ ( コンピュートノード ) の復旧 を参照してください ログの格納場所 業務サーバ ( コンピュートノード ) のフェイルオーバが実行されると 代表ノードに以下の情報が出力されます 代表ノードの確認は 代表ノードの確認方法 を参照してください スクリプトログ 業務サーバ ( コンピュートノード ) のフェイルオーバで発生したログのことです - スクリプトログの格納場所 /var/opt/fjsvpf4c/logs/rcx_ha.log システムログ - システムログの格納場所 /var/log/messages - システムログの表示内容 システムログの表示内容は 業務サーバ ( コンピュートノード ) のフェイルオーバでエラーが発生した場合のメッセージ HA 構成 を参照してください evacuated_list.log インスタンスが移動した時の情報です

79 - evacuated_list.logの格納場所 /var/opt/fjsvpf4c/logs/evacuated_list.log - evacuated_list.logの表示内容以下のフォーマットで表示されます 移行開始時刻 [Success Failure] インスタンスID 移行元ノード名移行先ノード名移行元ノード移行元の業務サーバ ( コンピュートノード ) 移行先ノード移行先の業務サーバ ( コンピュートノード ) 例 :37:24 Success 60adcde4-7d ce-9f fe compute2 compute :40:56 Success 1c9436ec cc2-b1d6-4d30d33b7fb5 compute2 compute :40:58 Success 4fdc0061-db68-4ab6-bb13-64d07e2b4f68 compute2 compute :40:59 Success f366d83e-7c8b-4bcf-80e cac84 compute2 compute1 代表ノードの確認方法 1. 管理サーバ ( コントローラー VM2) に root 権限でログインします 2. 稼働ノード名には 任意の稼働ノード名を指定してください # ssh 稼働ノード名 "hvdisp -a grep -w leaderapp" <RETURN> 3. 出力結果から代表ノードを確認します - 指定した稼働ノードが代表ノードの場合 以下の内容が出力されます leaderapp userapp Online - 指定した稼働ノード以外のノードが代表ノードの場合 コマンドの実行結果の赤文字 かつ下線部が代表ノード名を示しています leaderapp userapp Offline leaderapp userapp 代表ノード名 RMS Online 業務サーバ ( コンピュートノード ) のノード名の例 業務サーバ ( コンピュートノード ) のノード名が以下の場合の例を示します

80 図 4.7 稼動ノードが故障した場合の例 稼動ノード compute2 compute3 故障した稼動ノード compute1 待機ノード compute4 図 4.8 待機ノードが故障した場合の例 稼動ノード compute1 compute2 compute3 待機ノード compute4-74 -