6.1.1 運用設計

システムの運用設計として,システムの起動や停止などの日常運用操作,OSパッチや予防保守・点検のための部分閉塞・再開,J2EEアプリケーション入れ替えなどのメンテナンス,運用スケジュール,運用スケジュールの自動化,監視,稼働性能統計などを検討します。

ここでは,次に示すSmart Composer機能を使用した運用作業について説明します。

これらの運用方法については,「9. J2EEアプリケーションを実行するシステムの運用」を参照してください。

なお,ここでは,WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン(combined-tier)で構築したシステムを例に説明しています。ここで説明している運用は,次の構成定義パターンで構築したシステムでも操作できます。

ここで説明している以外の運用については,「9.1.2 アプリケーションサーバで実行できる運用作業」を参照してください。なお,運用作業には,運用を開始する前に設定が必要なものもあります。システムで実施する運用作業を検討し,必要に応じて構築時に設定をしてください。

<この項の構成>
(1) 日常運用
(2) メンテナンス
(3) システムの設定変更
(4) システムの構成変更
(5) 構築済みのシステムの移行
(6) システムの削除

(1) 日常運用

Smart Composer機能で構築したシステムでは,日常運用の操作としてサービスユニットの一括起動と一括停止ができます。一括起動および一括停止は,Webシステム内のすべてのサービスユニットに対して実施したり,特定のサービスユニットに対して実施したりできます。

一括起動および一括停止の範囲を次の図に示します。

図6-1 一括起動および一括停止の範囲

[図データ]

特定のサービスユニットに対して起動または停止できるので,例えば,サービスユニット1だけを停止させるという操作もできます。

参考
メモリセッションフェイルオーバ機能を使用したシステムの場合,業務用のサービスユニットとメモリセッションフェイルオーバ用のサービスユニットとの間で依存関係はありません。このため,特定のサービスユニットに対して起動/停止を実施する場合,起動/停止順序に優先順位はありません。なお,通常の場合,起動時はメモリセッションフェイルオーバ用のサービスユニットを先に起動し,停止時はメモリセッションフェイルオーバ用のサービスユニットをあとで停止します。

次に,一括起動と一括停止の処理について説明します。

(a) サービスユニットの一括起動処理

サービスユニットを一括起動すると,サービスユニットを構成する論理サーバは,論理サーバごとに設定した起動順序の昇順に従って起動されます。Smart Composer機能では,一括起動処理中に論理サーバの起動に失敗しても,そのまま処理を続行します。ただし,Webシステムに関連づいていない論理サーバを含むシステムの場合は,論理サーバの起動に失敗すると一括起動処理を中断します。

論理サーバの起動に失敗していると,リクエストの受け付けを開始できない,受け付けたリクエストを処理できないなどの障害が発生します。

一括起動時に-strictオプションを指定すると,論理サーバの起動に失敗した場合に,サービスユニットの一括起動処理を中断できます。

次に示す起動順序で論理J2EEサーバの起動に失敗した場合を例に,それぞれのシステムの処理について説明します。

論理サーバの起動順序
  1. 論理パフォーマンストレーサ
  2. 論理J2EEサーバ
  3. 論理Webサーバ
(b) サービスユニットの一括停止処理

サービスユニットを一括停止すると,停止対象のサービスユニットを負荷分散機から切り離し,実行中のリクエストを処理したあとに,サービスユニット内のすべての論理サーバを停止します。論理サーバは,論理サーバごとに設定した起動順序の降順に従って停止されます。

一括停止の場合,停止対象のシステムによって,論理サーバの停止に失敗したときの動作が異なります。

(2) メンテナンス

Smart Composer機能で構築したシステムで実施できる,メンテナンス時の操作を説明します。

(a) システムの部分メンテナンス

サービスユニット単位での一括停止および一括起動のコマンドを使用して,サービスユニットを閉塞・再開できます。これを利用して,OSのパッチ適用や予防保守・点検などのシステムの部分メンテナンスを,業務を停止しないで実施できます。

システムの部分メンテナンス(サービスユニット1をメンテナンスする場合)について,次の図に示します。

図6-2 システムの部分メンテナンス(サービスユニット1をメンテナンスする場合)

[図データ]

サービスユニットをメンテナンスする場合の流れは次のとおりです。

  1. 一括停止のコマンドを使用して,サービスユニット1だけを閉塞します。
  2. サービスユニット1に対してメンテナンスを実施したあと,一括開始コマンドを使用して,サービスユニット1を再開します。
    サービスユニット2はこの間,業務を続行しています。

これらの操作は,Smart Composer機能のコマンドを使用して実施します。

(b) J2EEアプリケーションの入れ替え

J2EEアプリケーションを修正した場合などに,J2EEアプリケーションを入れ替えられます。J2EEアプリケーションの入れ替えには,リデプロイによる入れ替えと,通常の入れ替えがあります。

J2EEアプリケーションのリデプロイによる入れ替えと通常の入れ替えについて,次の図にそれぞれ示します。

図6-3 J2EEアプリケーションのリデプロイによる入れ替えと通常の入れ替え

[図データ]

J2EEアプリケーションのリデプロイによる入れ替えの流れと,通常の入れ替えの流れは,それぞれ次のとおりです。

(3) システムの設定変更

Smart Composer機能で構築したシステムでは,システム全体の設定を一括で変更できます。システム全体の設定の一括変更について次の図に示します。

図6-4 システム全体の設定の一括変更

[図データ]

システム全体の設定の一括変更の流れは次のとおりです。

  1. システムを停止します。
  2. 変更後の設定をシステムに反映させます。
    システム内のすべての設定を一度に変更できます。
  3. システムを起動します。

これらの操作はすべてSmart Composer機能のコマンドを使用して実施します。なお,それぞれの操作は,システム内のすべてのサービスユニットに対して一括で実施できます。

(4) システムの構成変更

Smart Composer機能で構築したシステムで実施できる,システムの構成変更について説明します。

(a) システムのスケールアウトおよびスケールイン

システムのスケールアウトおよびスケールインができます。スケールアウトとは,システム全体の処理性能を向上させることを目的として,サーバの台数を増やすことをいいます。また,スケールインとは,システムの規模を縮小する場合などに,サーバの台数を減らすことをいいます。

スケールアウトおよびスケールインは,サービスユニット単位またはWebシステム単位で実施できます。なお,スケールアウトおよびスケールインは,業務全体を停止することなく実施できます。

スケールアウトおよびスケールインについて次の図に示します。

図6-5 スケールアウトおよびスケールイン

[図データ]

この図では,サービスユニット3をシステムに追加(スケールアウト),またはシステムから削除(スケールイン)しています。サービスユニット3のスケールアウトおよびスケールインに際しては,稼働中のサービスユニット1およびサービスユニット2には影響はないため,業務全体を停止することなく,スケールアウトおよびスケールインができます。

(b) JP1/SC/DPMと連携したスケールアウト

Smart Composer機能でシステムをスケールアウトする際に,JP1/SC/DPMと連携できます。

JP1/SC/DPMでは,システムのディスクイメージを複製し,複製したデータを基にして,OSやアプリケーションを一括でサーバにインストールできます(ディスク複製OSインストール機能)。Smart Composer機能でシステムをスケールアウトするときにJP1/SC/DPMと連携すると,構築済みのシステムの複製した情報を使用して,追加するアプリケーションサーバにOSやアプリケーションを一括インストールできます。

ただし,セッションフェイルオーバ機能を使用するシステムの場合,セッションフェイルオーバサーバマシンでは,JP1/SC/DPMと連携したスケールアウトを利用できません。

JP1/SC/DPMと連携してスケールアウトをするときの流れを次の図に示します。ここでは,サービスユニット1が構築済みの場合に,JP1/SC/DPMを使用して,サービスユニット2をシステムに追加(スケールアウト)することを例にしています。

図6-6 JP1/SC/DPMと連携したスケールアウト

[図データ]

JP1/SC/DPMと連携したスケールアウトの流れは次のとおりです。

  1. Smart Composer機能で構築済みのサービスユニット1のディスクイメージを,JP1/SC/DPMを使用して複製します。
  2. 手順1.で複製したディスクイメージに従って,追加するサービスユニット2にOSやアプリケーションをインストールします。
  3. Smart Composer機能のコマンドを使用して,サービスユニット2をシステムに追加(スケールアウト)します。
    参考
    JP1/SC/DPMと連携すると,ホスト単位管理モデルのシステムも構築できます。ホスト単位管理モデルのシステムでは,マシン(運用管理ドメイン)単位に,スケールアウトしてサーバの台数を増やしたり,またはスケールインしてサーバの台数を減らしたりできます。ホスト単位管理モデルでのスケールアウトおよびスケールインについては,「9.8.2 ホスト単位管理モデルでのシステムのスケールアウト」,および「9.8.3(2) ホスト単位管理モデルでのシステムのスケールイン」を参照してください。

(5) 構築済みのシステムの移行

テスト環境で構築したシステムを本番環境に移行する場合などに,構築済みのシステムを移行できます。

構築済みのシステムの移行について次の図に示します。

図6-7 構築済みのシステムの移行

[図データ]

構築済みのシステムの移行の流れは次のとおりです。

  1. 移行元の環境で,システムの設定内容を簡易構築定義ファイルの形式で出力します。
  2. 移行先の環境で,出力した簡易構築定義ファイルを使用して,システムを構築します。移行先の環境では,移行元の環境のシステムと同じ設定内容のシステムが構築されます。

これらの操作はSmart Composer機能のコマンドを使用して実施します。なお,構築済みのシステムを移行するためには,移行先のシステムで,Management Serverが動作している必要があります。構築済みのシステムを移行する前に,移行先のシステムでインストールと初期設定を済ませておいてください。

(6) システムの削除

不要になったシステムは,Smart Composer機能で提供するコマンドで削除できます。システムを削除する手順については,「9.11 システムの削除」を参照してください。