システムの運用設計として,システムの起動や停止などの日常運用操作,OSパッチや予防保守・点検のための部分閉塞・再開,J2EEアプリケーション入れ替えなどのメンテナンス,運用スケジュール,運用スケジュールの自動化,監視,稼働性能統計などを検討します。
ここでは,次に示すSmart Composer機能を使用した運用作業について説明します。
これらの運用方法については,「9. J2EEアプリケーションを実行するシステムの運用」を参照してください。
なお,ここでは,WebサーバとJ2EEサーバを同じサーバマシンに配置するパターン(combined-tier)で構築したシステムを例に説明しています。ここで説明している運用は,次の構成定義パターンで構築したシステムでも操作できます。
ここで説明している以外の運用については,「9.1.2 アプリケーションサーバで実行できる運用作業」を参照してください。なお,運用作業には,運用を開始する前に設定が必要なものもあります。システムで実施する運用作業を検討し,必要に応じて構築時に設定をしてください。
Smart Composer機能で構築したシステムでは,日常運用の操作としてサービスユニットの一括起動と一括停止ができます。一括起動および一括停止は,Webシステム内のすべてのサービスユニットに対して実施したり,特定のサービスユニットに対して実施したりできます。
一括起動および一括停止の範囲を次の図に示します。
図6-1 一括起動および一括停止の範囲
特定のサービスユニットに対して起動または停止できるので,例えば,サービスユニット1だけを停止させるという操作もできます。
次に,一括起動と一括停止の処理について説明します。
サービスユニットを一括起動すると,サービスユニットを構成する論理サーバは,論理サーバごとに設定した起動順序の昇順に従って起動されます。Smart Composer機能では,一括起動処理中に論理サーバの起動に失敗しても,そのまま処理を続行します。ただし,Webシステムに関連づいていない論理サーバを含むシステムの場合は,論理サーバの起動に失敗すると一括起動処理を中断します。
論理サーバの起動に失敗していると,リクエストの受け付けを開始できない,受け付けたリクエストを処理できないなどの障害が発生します。
一括起動時に-strictオプションを指定すると,論理サーバの起動に失敗した場合に,サービスユニットの一括起動処理を中断できます。
次に示す起動順序で論理J2EEサーバの起動に失敗した場合を例に,それぞれのシステムの処理について説明します。
サービスユニットを一括停止すると,停止対象のサービスユニットを負荷分散機から切り離し,実行中のリクエストを処理したあとに,サービスユニット内のすべての論理サーバを停止します。論理サーバは,論理サーバごとに設定した起動順序の降順に従って停止されます。
一括停止の場合,停止対象のシステムによって,論理サーバの停止に失敗したときの動作が異なります。
Smart Composer機能で構築したシステムで実施できる,メンテナンス時の操作を説明します。
サービスユニット単位での一括停止および一括起動のコマンドを使用して,サービスユニットを閉塞・再開できます。これを利用して,OSのパッチ適用や予防保守・点検などのシステムの部分メンテナンスを,業務を停止しないで実施できます。
システムの部分メンテナンス(サービスユニット1をメンテナンスする場合)について,次の図に示します。
図6-2 システムの部分メンテナンス(サービスユニット1をメンテナンスする場合)
サービスユニットをメンテナンスする場合の流れは次のとおりです。
これらの操作は,Smart Composer機能のコマンドを使用して実施します。
J2EEアプリケーションを修正した場合などに,J2EEアプリケーションを入れ替えられます。J2EEアプリケーションの入れ替えには,リデプロイによる入れ替えと,通常の入れ替えがあります。
J2EEアプリケーションのリデプロイによる入れ替えと通常の入れ替えについて,次の図にそれぞれ示します。
図6-3 J2EEアプリケーションのリデプロイによる入れ替えと通常の入れ替え
J2EEアプリケーションのリデプロイによる入れ替えの流れと,通常の入れ替えの流れは,それぞれ次のとおりです。
Smart Composer機能で構築したシステムでは,システム全体の設定を一括で変更できます。システム全体の設定の一括変更について次の図に示します。
図6-4 システム全体の設定の一括変更
システム全体の設定の一括変更の流れは次のとおりです。
これらの操作はすべてSmart Composer機能のコマンドを使用して実施します。なお,それぞれの操作は,システム内のすべてのサービスユニットに対して一括で実施できます。
Smart Composer機能で構築したシステムで実施できる,システムの構成変更について説明します。
システムのスケールアウトおよびスケールインができます。スケールアウトとは,システム全体の処理性能を向上させることを目的として,サーバの台数を増やすことをいいます。また,スケールインとは,システムの規模を縮小する場合などに,サーバの台数を減らすことをいいます。
スケールアウトおよびスケールインは,サービスユニット単位またはWebシステム単位で実施できます。なお,スケールアウトおよびスケールインは,業務全体を停止することなく実施できます。
スケールアウトおよびスケールインについて次の図に示します。
図6-5 スケールアウトおよびスケールイン
この図では,サービスユニット3をシステムに追加(スケールアウト),またはシステムから削除(スケールイン)しています。サービスユニット3のスケールアウトおよびスケールインに際しては,稼働中のサービスユニット1およびサービスユニット2には影響はないため,業務全体を停止することなく,スケールアウトおよびスケールインができます。
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と連携したスケールアウトの流れは次のとおりです。
テスト環境で構築したシステムを本番環境に移行する場合などに,構築済みのシステムを移行できます。
構築済みのシステムの移行について次の図に示します。
図6-7 構築済みのシステムの移行
構築済みのシステムの移行の流れは次のとおりです。
これらの操作はSmart Composer機能のコマンドを使用して実施します。なお,構築済みのシステムを移行するためには,移行先のシステムで,Management Serverが動作している必要があります。構築済みのシステムを移行する前に,移行先のシステムでインストールと初期設定を済ませておいてください。
不要になったシステムは,Smart Composer機能で提供するコマンドで削除できます。システムを削除する手順については,「9.11 システムの削除」を参照してください。