Smart Composer機能で構築したシステムで実施できる，日常運用の操作を説明します。

(a)　サービスユニットの一括起動と一括停止

サービスユニットの一括起動と一括停止ができます。一括起動および一括停止は，Webシステム内のすべてのサービスユニットに対して実施したり，特定のサービスユニットに対して実施したりできます。

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

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

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

参考

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

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

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

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

システムの部分メンテナンス（サービスユニット1をメンテナンスする場合）について，次の図を使用して説明します。

図5-2　サービスユニット1をメンテナンスする場合

サービスユニットをメンテナンスする場合の流れについて説明します。なお，1.および2.の操作は，Smart Composer機能のコマンドを使用して実施します。

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

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

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

リデプロイによる入れ替えと通常の入れ替えについて，次の図にそれぞれ示します。

図5-3　J2EEアプリケーションの入れ替え

J2EEアプリケーションのリデプロイによる入れ替えと通常の入れ替えの流れそれぞれについて説明します。なお，リデプロイによる入れ替えにはサーバ管理コマンド，通常の入れ替えにはSmart Composer機能のコマンドおよびサーバ管理コマンドを使用します。

• J2EEアプリケーションのリデプロイによる入れ替え
  
  1. 入れ替えるEARファイルのパスを指定して，リデプロイします。
• J2EEアプリケーションの通常の入れ替え
  
  1. システムを閉塞します。
  2. J2EEアプリケーションを停止します。
  3. 入れ替え前のJ2EEアプリケーションを削除します。
  4. 入れ替え後のJ2EEアプリケーションをインポートします。
  5. J2EEアプリケーションに必要な情報を設定，およびカスタマイズします。
  6. J2EEアプリケーションを開始します。
  7. システムを再開します。

Smart Composer機能でできる，システムの設定変更の操作を説明します。

(a)　システムの設定の一括変更

システム全体の設定は，一括で変更できます。システム全体の設定の一括変更について次の図に示します。

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

システム全体の設定の一括変更の流れについて説明します。なお，1.〜3.の操作はすべてSmart Composer機能のコマンドを使用して実施します。それぞれの操作は，システム内のすべてのサービスユニットに対して一括で実施できます。

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

システムの構成変更について説明します。

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

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

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

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

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

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

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

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

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

JP1/SC/DPMと連携してスケールアウトをするときの流れを次の図に示します。

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

JP1/SC/DPMと連携したスケールアウトの流れについて説明します。なお，ここでは，サービスユニット1が構築済みの場合に，JP1/SC/DPMを使用して，サービスユニット2をシステムに追加（スケールアウト）するときの例で説明します。

1. Smart Composer機能で構築済みのサービスユニット1のディスクイメージを，JP1/SC/DPMを使用して複製します。
2. 1.で複製したディスクイメージに従って，追加するサービスユニット2にOSやアプリケーションをインストールします。
3. Smart Composer機能のコマンドを使用して，サービスユニット2をシステムに追加（スケールアウト）します。

参考

JP1/SC/DPMと連携すると，ホスト単位管理モデルのシステムも構築できます。ホスト単位管理モデルのシステムでは，マシン（運用管理ドメイン）単位に，スケールアウトしてサーバの台数を増やしたり，またはスケールインしてサーバの台数を減らしたりできます。ホスト単位管理モデルでのスケールアウトおよびスケールインについては，「7.7.2　ホスト単位管理モデルでのシステムのスケールアウト」，および「7.7.3(2)　ホスト単位管理モデルでのシステムのスケールイン」を参照してください。

システム環境の移行について説明します。

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

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

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

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

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

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

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