運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

富士通メインフレームの本質を見る~CPUリプレースの考え方 第3回 CPU統合の考え方
2008年02月20日 18:47

3.1 CPU統合における問題点

 複数のCPUを保有しているお客様では、仮想化技術を使ったCPU統合を進めています。メインフレームでの仮想化技術(AVM)には20年近い歴史がありますが、性能に関する議論は浅く、次のような問題が発生しています。

  1. A、CPU統合時、最適なCPUを選定する見積り手法が確立されていない。
  2. B、CPU統合後、バッチジョブの処理時間が予想以上にばらつく。
  3. C、統合前に比べ遅くなる。
 Aについては、既存のCPU能力をベースにした「CPU能力積上げ方式」でCPUを選定しているケースが見受けられます。この方法について考察します。
 Bについては、不安定な処理時間を生み出すロジックを解明しましたので紹介します。
 Cについては様々なケースが考えられます。同じプログラムでもAVM化によりCPU時間やI/O時間が延びることがあります。本件は性能トラブルであり今回は割愛します。

3.2 CPU能力積上げ方式


image27.PNG
◆解説
 私の予想・・・①が10%、②が60%、③が30%くらいに分かれるのではないでしょうか。  メーカとしての正解は③です。②はAVMのオーバヘッド分を加算した値。私がユーザなら①を期待します。
 CPUの単純移行では移行パスが定着しています。CPU統合でこれに相当するのが「CPU能力積上げ方式」で、図5の例を使って説明します。CPU3台で総CPU能力が200のとき、新システムでは能力220~264(余裕値0~20%)のCPUを選択し、CPU配分をVM1:VM2:VM3=50%:25%:25%と設定します。

ariga080220_1.png
図5 CPU能力積上げ方式

 CPU能力積上げ方式は、1+1→1.5のようなスリム化の統合ではなく、1+1→2.5のオーバスペックの統合です。スリム化の統合は、現在の稼動状況を評価する基本的な性能評価プロセスを実践することで可能です。オーバスペックの統合は、余裕値があるので性能上問題なさそうですが実際には大きな問題が潜んでいます。


3.3 CPU統合後の処理時間

image29.PNG

◆解説
 AVMの設定にもよりますが、10~15分前後で推移します。「前後」とは第1回の問1で説明したバラツキです。ここでは10~15分の幅について説明します。
 処理時間の内訳は以下のようになります。問4ではI/O時間が不変かつ単体処理時間なのでCPU待ち時間=0と考えます。
  旧:処理時間=I/O時間+CPU待ち時間(0)+CPU時間
  新:処理時間=I/O時間+CPU待ち時間(0)+CPU時間他VM待ち時間AVM走行時間

 旧システムでのCPU時間が新システムでどのように変わるかを図6で説明します。
 単体CPU性能が向上することにより、CPU時間は短くなり、新たに他VM待ち時間が発生します。他VM待ち時間は、AVMのLOGICALモードでは固定化し、AUTOMATICモードでは変動します。

ariga080220_2.png

図6 AVMによる待ち時間の考え方

 1号機で単体処理時間が15分(CPU時間10分、I/O時間5分)だったバッチジョブを新システム(AUTOMATICモード)で実行すると、図7のように10分弱~15分で変動します。重要な点は、単体での処理性能が他VMの稼動状況に左右されるということです。

ariga080220_3.png

図7 バッチジョブの処理時間の推移

注)待ちに含まれるAVM走行時間(0.4分)は、他VMが稼動していないと小さくなるため図7の最短モデルでは省略しています。


3.4 事例~不安定な処理時間

 本番機と開発機を統合した事例を紹介します。移行後の本番VMでのバッチ処理の処理時間に注目してください。

  1. システムの概要
    image30.PNG
  2. ジョブの稼動状況

     日中に実行されたバッチジョブの稼動状況を表2に示します。バッチAはI/O中心の処理、バッチBはCPU中心の処理です。

    ariga080220_4.png
    表2 バッチジョブA、Bの稼動状況
  3. 解説

    バッチAについて(I/Oバウンド処理)

    • 処理時間が短縮したのは、DASD性能の向上による効果。
    • 移行後の処理時間に32分の差があるのは、CPU待ちによる影響。

    バッチBについて(CPUバウンド処理)

    • 移行後の1:21:43が速すぎる。(問4での最速時間が出たケース)
    • 移行後の処理時間1時間13分の差は、CPU待ちと他VM待ちによる影響。
    特に、CPU統合直後の速すぎる性能には注意が必要です。

 以上、3回にわたってCPUリプレースの考え方を紹介しました。CPU使用率100%でも正常に稼動する、CPUをダウングレードできるのがメインフレームの強みだと考えています。適切なCPUを選択するには、お客様自身の目を光らせることが重要です。

以 上


運用研究レポート
富士通メインフレームの本質を見る~CPUリプレースの考え方

御社ではメインフレームの性能評価や性能見積りをして機種選定をしていますか? 「富士通メインフレームの本質を見る」の第2弾として「CPUリプレースの考え方」について解説します。第1回は移行パス(見積り不要の機種選定方法)が生まれた背景とその内容について考えます。

記事一覧へ
筆者紹介

有賀 光浩(ありが みつひろ)



株式会社アイビスインターナショナル 代表取締役

1963年生まれ。1985年富士通株式会社入社。1992年~2003年まで社内共通技術部門で国内外のメインフレームの性能コンサルティングを実施、担当したシステム数は1,000を超える。2000年からは大規模SIプロジェクトへの品質コンサルティング部門も立ち上げた。

2004年に株式会社アイビスインターナショナルを設立。富士通メインフレームの性能コンサルティングとIT統制コンサルティングを行っている。

技術情報はhttp://www.ibisinc.co.jp/で公開中。富士通やSI’erからのアクセスが多い。

当サイトには、同名シリーズ「富士通メインフレームの本質を見る~IT全般統制の考え方」を3回、「富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例から」を6回、「富士通メインフレームの本質を見る~CPUリプレースの考え方」を3回、「富士通メインフレームの本質を見る~性能改善の現場」を7回、「富士通メインフレームの本質を見る~2009年度の最新トッピックス」を3回、「富士通メインフレームの本質を見る~2008年度の最新トピックス」を2回にわたり掲載。

コメントを書く
コメントを書く

未ログイン: ログインする

コメント: ログイン(会員登録)すると、コメントを書き込むことができます。

  • 新着Q&A
  • 最新の回答

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

こちらは、システム管理者認定講座の認定試験の受験のみ希望される方の申込みページです。 システム管理者認定講座のアソシエイト(初級)、バチェラー(中級)、マスタ

個人情報保護方針
運営者につい て
利用規約
サイトマップ